packet losses on the link between compressor and
decompressor, that have been indicated to the decompressor.
Discontinuities in the value of this counter can
occur at re-initialization of the management
system, and at other times as indicated by the
value of ifCounterDiscontinuityTime. For checking
ifCounterDiscontinuityTime, the interface index is
required. It can be determined by reading the
rohcChannelTable of the ROHC-MIB.
The value of this object is only valid for LLA profiles,
i.e., if the corresponding rohcProfile has a value of
0x0005. If the corresponding rohcProfile has a value
other than 0x0005, then this object MUST NOT be
instantiated."
REFERENCE
"RFC 3242, Section 5.1.2."
::= { rohcRtpContextEntry 16 }
rohcRtpContextPktsLostPreLink OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is only applicable to decompressor contexts
using the LLA profile. It contains the number of pre-link
packet losses on the link between compressor and
decompressor, that have been indicated to the decompressor.
Discontinuities in the value of this counter can
occur at re-initialization of the management
system, and at other times as indicated by the
value of ifCounterDiscontinuityTime. For checking
ifCounterDiscontinuityTime, the interface index is
required. It can be determined by reading the
rohcChannelTable of the ROHC-MIB.
The value of this object is only valid for LLA profiles,
i.e., if the corresponding rohcProfile has a value of
0x0005. If the corresponding rohcProfile has a value
other than 0x0005, then this object MUST NOT be
instantiated."
REFERENCE
"RFC 3242, Section 5.1.2."
::= { rohcRtpContextEntry 17 }
--
-- Packet Sizes Table
--
-- The rohcPacketSizeTable lists allowed, preferred, and used
-- packet sizes per compressor context.
rohcRtpPacketSizeTable OBJECT-TYPE
SYNTAX SEQUENCE OF RohcRtpPacketSizeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists all allowed, preferred, and used packet
sizes per compressor context and channel.
Note, that the sizes table represents implementation
parameters that are suggested by RFC 3095 and/or RFC 3242,
but that are not mandatory."
::= { rohcRtpObjects 2 }
rohcRtpPacketSizeEntry OBJECT-TYPE
SYNTAX RohcRtpPacketSizeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry of a particular packet size."
INDEX {
rohcChannelID,
rohcContextCID,
rohcRtpPacketSize
}
::= { rohcRtpPacketSizeTable 1 }
RohcRtpPacketSizeEntry ::= SEQUENCE {
rohcRtpPacketSize Unsigned32,
rohcRtpPacketSizePreferred TruthValue,
rohcRtpPacketSizeUsed TruthValue,
rohcRtpPacketSizeRestrictedType INTEGER
}
rohcRtpPacketSize OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A packet size used as index."
::= { rohcRtpPacketSizeEntry 3 }
rohcRtpPacketSizePreferred OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is only applicable to compressor contexts
using the LLA profile. When retrieved, it will have
the value true(1) if the packet size is preferred.
Otherwise, its value will be false(2).
The value of this object is only valid for LLA profiles,
i.e., if the corresponding rohcProfile has a value of
0x0005. If the corresponding rohcProfile has a value
other than 0x0005, then this object MUST NOT be
instantiated."
REFERENCE
"RFC 3242, Section 5.1.1"
::= { rohcRtpPacketSizeEntry 4 }
rohcRtpPacketSizeUsed OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is only applicable to compressor contexts
using the UDP, RTP, or ESP profile. When retrieved,
it will have the value true(1) if the packet size is
used. Otherwise, its value will be false(2).
The value of this object is only valid for UDP, RTP,
and ESP profiles, i.e., if the corresponding rohcProfile
has a value of either 0x0001, 0x0002 or 0x0003. If
the corresponding rohcProfile has a value other than
0x0001, 0x0002 or 0x0003, then this object MUST NOT be
instantiated."
REFERENCE
"RFC 3095, Section 6.3.1"
::= { rohcRtpPacketSizeEntry 5 }
rohcRtpPacketSizeRestrictedType OBJECT-TYPE
SYNTAX INTEGER {
nhpOnly(1),
rhpOnly(2),
noRestrictions(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is only applicable to preferred packet
sizes of compressor contexts using the LLA profile.
When retrieved, it will indicate whether the packet
size is preferred for NHP only, for RHP only, or
for both of them.
The value of this object is only valid for LLA profiles,
i.e., if the corresponding rohcProfile has a value of
0x0005. If the corresponding rohcProfile has a value
other than 0x0005, then this object MUST NOT be
instantiated."
REFERENCE
"RFC 3242, Section 5.1.1"
::= { rohcRtpPacketSizeEntry 6 }
--
-- conformance information
--
rohcRtpCompliances OBJECT IDENTIFIER ::= { rohcRtpConformance 1 }
rohcRtpGroups OBJECT IDENTIFIER ::= { rohcRtpConformance 2 }
--
-- compliance statements
--
rohcRtpCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities that implement
the ROHC-RTP-MIB.
Note that compliance with this compliance
statement requires compliance with the
rohcCompliance MODULE-COMPLIANCE statement of the
ROHC-MIB and with the ifCompliance3 MODULE-COMPLIANCE
statement of the IF-MIB (RFC2863)."
MODULE -- this module
MANDATORY-GROUPS {
rohcRtpContextGroup
}
GROUP rohcRtpPacketSizesGroup
DESCRIPTION
"A compliant implementation does not have to implement
the rohcRtpPacketSizesGroup."
GROUP rohcRtpStatisticsGroup
DESCRIPTION
"A compliant implementation does not have to implement
the rohcRtpStatisticsGroup."
::= { rohcRtpCompliances 1 }
rohcRtpContextGroup OBJECT-GROUP
OBJECTS {
rohcRtpContextState,
rohcRtpContextMode,
rohcRtpContextAlwaysPad,
rohcRtpContextLargePktsAllowed,
rohcRtpContextVerifyPeriod
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
ROHC RTP compressors and decompressors."
::= { rohcRtpGroups 1 }
rohcRtpPacketSizesGroup OBJECT-GROUP
OBJECTS {
rohcRtpContextSizesAllowed,
rohcRtpContextSizesUsed,
rohcRtpPacketSizePreferred,
rohcRtpPacketSizeUsed,
rohcRtpPacketSizeRestrictedType
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
allowed and used packet sizes at a ROHC RTP compressor."
::= { rohcRtpGroups 2 }
rohcRtpStatisticsGroup OBJECT-GROUP
OBJECTS {
rohcRtpContextACKs,
rohcRtpContextNACKs,
rohcRtpContextSNACKs,
rohcRtpContextNHPs,
rohcRtpContextCSPs,
rohcRtpContextCCPs,
rohcRtpContextPktsLostPhysical,
rohcRtpContextPktsLostPreLink
}
STATUS current
DESCRIPTION
"A collection of objects providing ROHC compressor and
decompressor statistics."
::= { rohcRtpGroups 3 }
END
6. Security Considerations
The managed objects defined by the ROHC-MIB module, the ROHC-
UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not have a
MAX-ACCESS value of read-write and/or read-create except
rohcInstanceContextStorageTime and rohcContextStorageTime, both of
which have a MAX-ACCESS value of read-write. These objects determine
how long context information is stored after its termination.
Unauthorized access to these objects can have one of two negative
effects. If they are set to a value lower than required, e.g., to
zero, then context information about past contexts might get lost.
If they are set to a very high value, then context information will
not be deleted and memory consumption of the agent implementation
might become very high. However, unauthorized access to these
objects cannot cause harm to existing ROHC connections nor can it
allow manipulation of running instances of ROHC in a malicious way.
Another security issue is unauthorized access to readable objects in
the MIB modules for getting information about existing communication
sessions. It is thus important to control even GET and/or NOTIFY
access to these objects and possibly to even encrypt the values of
these objects when sending them over the network via SNMP. However,
the only information that might be disclosed is the use of channels.
Users and their addresses are not visible in the MIB. This
information can only be mis-used in conjunction with the mis-use of
further information.
SNMP versions prior to SNMPv3 did not include adequate security.
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
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
7. Acknowledgements
Many thanks to Lars-Erik Jonsson and Mark West for their guidance
through the ROHC world and to Ghyslain Pelletier for explaining how
the ROHC LLA profile works. Further thanks to Frank Strauss for his
advice on tricky SMI issues. Special thanks to Mike Heard who acted
as MIB doctor. He studied every tiny detail, raised a long list of
issues and helped to significantly improve this document.
8. References
8.1. Normative References
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP,
UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3242] Jonsson, L. and G. Pelletier, "RObust Header Compression
(ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP",
RFC 3242, April 2002.
[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.
[RFC3759] Jonsson, L., "RObust Header Compression (ROHC):
Terminology and Channel Mapping Examples", RFC 3759,
April 2004.
8.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
9. Authors’ Addresses
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-15
EMail: quittek@netlab.nec.de
Martin Stiemerling
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-13
EMail: stiemerling@netlab.nec.de
Hannes Hartenstein
University of Karlsruhe
Computing Center and Institute of Telematics
76128 Karlsruhe
Germany
Phone: +49 721 608 8104
EMail: hartenstein@rz.uni-karlsruhe.de
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.