rfc-3816

Definitions of Managed Objects for RObust Header Compression (ROHC)

J. Quittek, M. Stiemerling, H. Hartenstein
date2004-06 streamIETF areatsv wgrohc statusPROPOSED STANDARD pages53 canonicalhttps://www.rfc-editor.org/rfc/rfc3816 doi10.17487/RFC3816 errataview
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. [STANDARDS-TRACK]

Extracted elements (30)

design-rationale §4.1.4

Context rows persist in rohcContextTable after expiry or termination for a configurable storage time (rohcContextStorageTime), allowing management systems to query historical statistics. However, CID space constraints may force premature row deletion when a CID is reused.

snmp

design-rationale §4

ROHC is described as an evolving technology, so managed objects are split into a general ROHC-MIB module and profile-specific modules (ROHC-UNCOMPRESSED-MIB, ROHC-RTP-MIB). This flexible approach allows future profiles (e.g., TCP, SCTP) to be supported each by its own small, easy-to-design module without modifying the base MIB.

snmp

design-rationale §4.1.2

rohcInstanceType (compressor/decompressor) was added to the rohcInstanceTable index even though rohcChannelID alone uniquely identifies an instance. The reason is that many management use cases need to list all compressors or all decompressors without accessing the other type, which the combined index enables efficiently.

snmp

design-rationale §4

RTP, UDP, ESP, and LLA profiles share the ROHC-RTP-MIB module rather than having individual modules, because analysis showed these profiles are tightly related and can share most managed objects. This reduces the total number of MIB modules while still keeping profile-specific objects separate from the base ROHC-MIB.

snmp, rtp

interoperability-note §5

Compliance with ROHC-MIB requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of IF-MIB (RFC 2863). Compliance with ROHC-UNCOMPRESSED-MIB additionally requires compliance with rohcCompliance of ROHC-MIB. The same chain applies to ROHC-RTP-MIB.

snmp

interoperability-note §5

rohcRtpContextMode exposes the three ROHC operating modes from RFC 3095 Section 4.4: unidirectional(1), optimistic(2), and reliable(3). Implementations using the RTP/UDP/ESP/LLA profile MIB must map the negotiated RFC 3095 mode to these enumerated values.

snmp, rtp

normative-requirement §5 MUST

For compressor contexts (rohcInstanceType = compressor(1)), rohcContextDecompressorDepth MUST be set to zero (0); the object is only valid for decompressor contexts.

snmp

normative-requirement §5 MUST NOT

For compressor contexts (rohcInstanceType = compressor(1)), rohcRtpContextSizesAllowed and rohcRtpContextSizesUsed MUST NOT be instantiated; these objects are only valid for decompressor contexts.

snmp

normative-requirement §5 OPTIONAL

For the ROHC-MIB compliance statement, rohcInstanceGroup and rohcContextGroup are mandatory. rohcStatisticsGroup, rohcTimerGroup, and rohcContextStatisticsGroup are optional. Read-write access to rohcInstanceContextStorageTime and rohcContextStorageTime is also optional.

snmp

normative-requirement §5 SHOULD

ROHC-MIB implementations SHOULD store the value of rohcInstanceContextStorageTime persistently. The default value is 360000 centi-seconds (3600 seconds). Changing this value does not affect previously created rohcContextTable entries.

snmp

normative-requirement §5 REQUIRED

rohcChannelID is REQUIRED to be unique per ROHC MIB implementation independent of the associated interface, and REQUIRED to remain constant across at least one re-initialization of the entity's network management system. Persistence across re-initializations is RECOMMENDED.

snmp

normative-requirement §5 MUST

rohcContextProfile MUST have a corresponding entry in rohcProfileTable using rohcContextProfile as the second index part and the same rohcChannelID as the first index part.

snmp

normative-requirement §5 MUST NOT

rohcRtpContextAlwaysPad and rohcRtpContextLargePktsAllowed are LLA-profile-specific objects; they MUST NOT be instantiated when the corresponding rohcProfile value is other than 0x0005. Similarly, rohcRtpContextNHPs, rohcRtpContextCSPs, rohcRtpContextCCPs, rohcRtpContextPktsLostPhysical, and rohcRtpContextPktsLostPreLink MUST NOT be instantiated for non-LLA profiles.

snmp

normative-requirement §5 MUST

When rohcChannelType is dedicatedFeedback(3), rohcChannelFeedbackFor MUST be different from 0 and MUST identify an existing ROHC channel. When rohcChannelType is notInUse(1), rohcChannelFeedbackFor MUST be 0.

snmp

protocol-element §4

RFC 3816 defines three MIB modules: ROHC-MIB (mib-2 112) for objects shared by all profiles, ROHC-UNCOMPRESSED-MIB (mib-2 113) for profile 0x0000, and ROHC-RTP-MIB (mib-2 114) for profiles 0x0001 (RTP), 0x0002 (UDP), 0x0003 (ESP), and 0x0005 (LLA). This modular structure allows future ROHC profiles to be supported by adding new profile-specific modules.

snmp, yang

protocol-element §4.1.1

rohcChannelTable lists all channels per IP interface used for ROHC compressed packets and/or feedback. Each entry carries rohcChannelID (unique Unsigned32 1..4294967295), rohcChannelType (notInUse/rohc/dedicatedFeedback), rohcChannelFeedbackFor (pointer to data channel), rohcChannelDescr, and rohcChannelStatus (enabled/disabled).

snmp

protocol-element §5

RohcCompressionRatio is a textual convention defined as 1000 * bytes(compressed) / bytes(original), rounded to the nearest integer. Values greater than 1000 are valid since compressed output can exceed original size.

snmp

protocol-element §4.1.4

rohcContextTable lists compressor and decompressor contexts per instance, indexed by rohcChannelID and rohcContextCID (0..16383). It tracks CID state, used profile, decompressor depth, storage time, activation/deactivation times, and optional compression ratio and packet size statistics.

snmp

protocol-element §5

rohcInstanceMRRU specifies the Maximum Reconstructed Reception Unit in octets, including the CRC. If MRRU is negotiated to be 0, no segment headers are allowed on the channel, effectively disabling ROHC segmentation.

snmp

protocol-element §4.1.2

rohcInstanceTable lists properties of running ROHC compressor and decompressor instances, indexed by ifIndex, rohcInstanceType, and rohcChannelID. Key fields include rohcInstanceMaxCID (1..16383), rohcInstanceLargeCIDs (short vs. embedded CID), rohcInstanceMRRU (max reconstructed reception unit), and rohcInstanceContextStorageTime (default 3600 seconds).

snmp

protocol-element §4.1.3

rohcProfileTable lists profiles supported per instance, indexed by rohcChannelID and rohcProfile (0..65535). rohcProfileNegotiated indicates whether the profile has been negotiated with the peer compressor or decompressor.

snmp

protocol-element §4.3.1

rohcRtpContextTable extends rohcContextTable for profiles 0x0001–0x0003 and 0x0005, adding context state/mode, LLA-specific configuration (AlwaysPad, LargePktsAllowed, VerifyPeriod), ACK/NACK/SNACK counters, and LLA-specific NHP/CSP/CCP and packet-loss counters.

snmp, rtp

protocol-element §5

rohcRtpContextVerifyPeriod is an LLA-profile-only object specifying the minimum frequency (every N packets) at which a CRC-bearing packet must be sent to validate the context. A value of 0 disables periodic verification.

snmp, rtp

protocol-element §4.3.2

rohcRtpPacketSizeTable lists per-compressor-context allowed or preferred packet sizes for profiles 0x0001–0x0003 and 0x0005. For LLA (0x0005), entries indicate whether the preferred size applies to NHP only, RHP only, or all packets.

snmp, rtp

protocol-element §4.2.1

rohcUncmprContextTable extends rohcContextTable for profile 0x0000, adding rohcUncmprContextState (initAndRefresh/normal/noContext/fullContext), rohcUncmprContextMode (unidirectional/bidirectional), and the optional rohcUncmprContextACKs counter.

snmp

registry §5

The ROHC profile identifier used in rohcProfile (0..65535) is drawn from the IANA registry 'RObust Header Compression (ROHC) Profile Identifiers'. RFC 3816 assigns OIDs mib-2 112 (ROHC-MIB), mib-2 113 (ROHC-UNCOMPRESSED-MIB), and mib-2 114 (ROHC-RTP-MIB) under the MIB-2 subtree.

snmp, registry

security-consideration §6

The ROHC MIB modules contain read-write objects (rohcInstanceContextStorageTime, rohcContextStorageTime) whose unauthorized modification could affect context retention and management visibility. The MIBs are intended to be accessed via SNMPv3 with authentication and privacy; use of SNMPv1 or SNMPv2c without community-string protection is discouraged given the sensitivity of compression state information.

snmp, security

state-machine §5

rohcContextCIDState tracks CID lifecycle with four states: unused(1) → active(2) when a CID is assigned; active → terminated(4) on explicit signaling or active → expired(3) after inactivity timeout; expired or terminated → active when the CID is re-used for a new context.

snmp

state-machine §5

rohcRtpContextState models profiles 0x0001–0x0003 and 0x0005 context states: compressor states are initAndRefresh(1), firstOrder(2), and secondOrder(3); decompressor states are noContext(4), staticContext(5), and fullContext(6), per RFC 3095.

snmp, rtp

state-machine §5

rohcUncmprContextState models profile 0x0000 context states: compressor states are initAndRefresh(1) and normal(2); decompressor states are noContext(3) and fullContext(4), as defined in RFC 3095 Section 5.10.3.

snmp