Pseudowire MIB TCs: Definitions of Textual Conventions for Pseudowire (PW) Management
A shared set of SNMP textual conventions so pseudowire management modules describe the same values the same way.
Nadeau, T., Ed., Zelig, D., Ed., and O. Nicklass, Ed., "Definitions of Textual Conventions for Pseudowire (PW) Management", RFC 5542, DOI 10.17487/RFC5542, May 2009, <https://www.rfc-editor.org/info/rfc5542>.
@misc{rfc5542,
series = {Request for Comments},
number = 5542,
howpublished = {RFC 5542},
publisher = {RFC Editor},
doi = {10.17487/RFC5542},
url = {https://www.rfc-editor.org/info/rfc5542},
author = {T. Nadeau and D. Zelig and O. Nicklass},
title = {{Definitions of Textual Conventions for Pseudowire (PW) Management}},
pagetotal = 11,
year = 2009,
month = may,
} RFC text
Contents
Network Working Group T. Nadeau, Ed.
Request for Comments: 5542 BT
Category: Standards Track D. Zelig, Ed.
Oversi
O. Nicklass, Ed.
RADVISION
May 2009
Definitions of Textual Conventions for Pseudowire (PW) Management
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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract
This memo defines a Management Information Base (MIB) module that
contains textual conventions (TCs) to represent commonly used
pseudowire (PW) management information. The intent is that these TCs
will be imported and used in PW-related MIB modules that would
otherwise define their own representations.
Table of Contents
1. Introduction ....................................................2
2. The Internet-Standard Management Framework ......................2
3. Conventions Used in This Document ...............................2
4. Object Definitions ..............................................3
5. Security Considerations .........................................9
6. IANA Considerations .............................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines textual conventions used for pseudowire
(PW) technology and for Pseudowire Edge-to-Edge Emulation (PWE3) MIB
modules.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through Simple Network Management Protocol (SNMP). Objects
in the MIB are defined using the mechanisms defined in the Structure
of Management Information (SMI). This memo specifies a MIB module
that is compliant to the SMIv2, which is described in STD 58, RFC
2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
3. Conventions Used in This Document
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].
4. Object Definitions
PW-TC-STD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, Unsigned32, mib-2
FROM SNMPv2-SMI -- [RFC2578]
TEXTUAL-CONVENTION
FROM SNMPv2-TC; -- [RFC2579]
pwTcStdMIB MODULE-IDENTITY
LAST-UPDATED "200904210000Z" -- 21 April 2009 00:00:00 GMT
ORGANIZATION "Pseudowire Edge-to-Edge Emulation (PWE3) Working
Group"
CONTACT-INFO
" Thomas D. Nadeau
Email: tom.nadeau@bt.com
David Zelig
Email: davidz@oversi.com
Orly Nicklass
Email: orlyn@radvision.com
The PWE3 Working Group (email distribution pwe3@ietf.org,
http://www.ietf.org/html.charters/pwe3-charter.html)
"
DESCRIPTION
"This MIB module defines TEXTUAL-CONVENTIONS
for concepts used in pseudowire edge-to-edge
networks.
Copyright (c) 2009 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met:
- Redistributions of source code must retain the above
copyright notice, this list of conditions and the following
disclaimer.
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor
the names of specific contributors, may be used to endorse or
promote products derived from this software without specific
prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This version of this MIB module is part of RFC 5542;
see the RFC itself for full legal notices."
-- Revision history.
REVISION "200904210000Z" -- 21 April 2009 00:00:00 GMT
DESCRIPTION
"Original Version"
::= { mib-2 188 }
PwGroupID ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"An administrative identification for grouping a
set of service-specific pseudowire services."
SYNTAX Unsigned32
PwIDType ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Pseudowire Identifier. Used to identify the PW
(together with some other fields) in the signaling
session."
SYNTAX Unsigned32
PwIndexType ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Pseudowire Index. A unique value, greater than zero,
for each locally defined PW. Used for indexing
several MIB tables associated with the particular PW.
It is recommended that values are assigned contiguously
starting from 1. The value for each PW MUST remain
constant at least from one re-initialization
to the next re-initialization."
SYNTAX Unsigned32 (1..4294967295)
PwIndexOrZeroType ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This TEXTUAL-CONVENTION is an extension of the
PwIndexType convention. The latter defines a greater-
than-zero value used to identify a pseudowire
in the managed system. This extension permits the
additional value of zero. The zero value is object-specific
and MUST therefore be defined as part of the description of
any object that uses this syntax. Examples of the usage of
zero might include situations where pseudowire was unknown,
or where none or all pseudowires need to be referenced."
SYNTAX Unsigned32 (0..4294967295)
PwOperStatusTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates the operational status of the PW.
- up(1): Ready to pass packets.
- down(2): PW signaling is not yet finished, or
indications available at the service
level indicate that the PW is not
passing packets.
- testing(3): AdminStatus at the PW level is set to
test.
- dormant(4): The PW is not in a condition to pass
packets but is in a 'pending' state,
waiting for some external event.
- notPresent(5): Some component is missing to accomplish
the setup of the PW. It can be
configuration error, incomplete
configuration, or a missing H/W component.
- lowerLayerDown(6): One or more of the lower-layer interfaces
responsible for running the underlying PSN
is not in OperStatus 'up' state."
SYNTAX INTEGER {
up(1),
down(2),
testing(3),
dormant(4),
notPresent(5),
lowerLayerDown(6)
}
PwAttachmentIdentifierType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An octet string used in the generalized Forward Error
Correction (FEC) element for identifying attachment forwarder
and groups. A NULL identifier is of zero length.
"
SYNTAX OCTET STRING (SIZE (0..255))
PwGenIdType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents the Attachment Group Identifier (AGI) Type and
Attachment Individual Identifier (AII) Type in generalized FEC
signaling and configuration.
"
SYNTAX Unsigned32( 0..254 )
PwCwStatusTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates the status of the control word (CW) negotiation
based on the local configuration and the indications received
from the peer node.
waitingForNextMsg(1) indicates that the node is waiting for
another label mapping from the peer.
sentWrongBitErrorCode(2) indicates that the local node has
notified the peer about a mismatch in the C-bit.
rxWithdrawWithWrongBitErrorCode(3) indicates that a withdraw
message has been received with the wrong C-bit error code.
illegalReceivedBit(4) indicates a C-bit configuration with
the peer that is not compatible with the PW type.
cwPresent(5) indicates that the CW is present for this PW.
If signaling is used, the C-bit is set and agreed upon between
the nodes. For manually configured PW, the local
configuration requires the use of the CW.
cwNotPresent(6) indicates that the CW is not present for this
PW. If signaling is used, the C-bit is reset and agreed upon
between the nodes. For manually configured PW, the local
configuration requires that the CW not be used.
notYetKnown(7) indicates that a label mapping has not yet
been received from the peer.
"
REFERENCE
"Martini, et al., 'Pseudowire Setup and Maintenance Using
the Label Distribution Protocol', [RFC4447]."
SYNTAX INTEGER {
waitingForNextMsg(1),
sentWrongBitErrorCode(2),
rxWithdrawWithWrongBitErrorCode(3),
illegalReceivedBit(4),
cwPresent(5),
cwNotPresent(6),
notYetKnown(7)
}
PwStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates the status of the PW and the interfaces affecting
this PW. If none of the bits are set, it indicates no faults
are reported.
"
SYNTAX BITS {
pwNotForwarding(0),
servicePwRxFault(1),
servicePwTxFault(2),
psnPwRxFault(3),
psnPwTxFault(4)
}
PwFragSize ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"If set to a value other than zero, it indicates the desired
fragmentation length in bytes. If set to zero,
fragmentation is not desired for PSN bound packets.
"
SYNTAX Unsigned32
PwFragStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates the status of the fragmentation/reassembly process
based on local configuration and peer capability.
noFrag(0) bit indicates that local configuration is for no
fragmentation.
cfgFragGreaterThanPsnMtu(1) bit indicates that the local node
is set to fragment, but the fragmentation size is greater
than the MTU available at the PSN between the nodes.
Fragmentation is not done in this case.
cfgFragButRemoteIncapable(2) bit indicates that the local
configuration conveys the desire for fragmentation but
the peer is not capable of reassembly.
remoteFragCapable(3) bit indicates that the remote node
is capable to accept fragmented PDUs.
fragEnabled(4) bit indicates that fragmentation will be used
on this PW. Fragmentation can be used if the local node was
configured for fragmentation, the peer has the capability
to accept fragmented packets, and the CW is in use for this
PW."
REFERENCE
"Malis, A. and M. Townsley, 'Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly', [RFC4623]."
SYNTAX BITS {
noFrag(0),
cfgFragGreaterThanPsnMtu(1),
cfgFragButRemoteIncapable(2),
remoteFragCapable(3),
fragEnabled(4)
}
PwCfgIndexOrzero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Index in any of the relevant configuration tables for
supplement information regarding configuration of the
specific technology. Value zero implies no additional
configuration information is applicable."
SYNTAX Unsigned32 (0..4294967295)
END
5. Security Considerations
This module does not define any management objects. Instead, it
defines a set of textual conventions that may be used by other PWE3
MIB modules to define management objects.
Meaningful security considerations can only be written in the MIB
modules that define management objects. Therefore, this document has
no impact on the security of the Internet.
6. IANA Considerations
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER value recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
pwTcStdMIB { mib-2 188 }
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006.
7.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.
Authors' Addresses
Thomas D. Nadeau (editor)
BT
BT Centre
81 Newgate Street
London EC1A 7AJ
United Kingdom
EMail: tom.nadeau@bt.com
David Zelig (editor)
Oversi Networks
1 Rishon Letzion St.
Petah Tikva
Israel
Phone: +972 77 3337 750
EMail: davidz@oversi.com
Orly Nicklass (editor)
RADVISION
24 Raul Wallenberg
Tel Aviv
Phone: +972 3 776 9444
EMail: orlyn@radvision.com
ISO Plain Language
On this page
§1Why a Shared Set of Conventions
This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it defines textual conventions used for pseudowire (PW) technology and for Pseudowire Edge-to-Edge Emulation (PWE3) MIB modules.
A textual convention is not a managed object and does not hold a value that a manager reads. It is a named type: it says what a value means, how it should be displayed, and what values it is allowed to take. The MIB module defined here, named PW-TC-STD-MIB, contains only such conventions, and its intent is that they will be imported and used in pseudowire-related MIB modules that would otherwise define their own representations.
Several teams write management modules for pseudowires, and each tends to describe the same idea in its own way. This document gives them one shared vocabulary, so a value called an operational status means the same thing everywhere.
§2The Management Framework This Builds On
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, the RFC points the reader to section 7 of RFC 3410.
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol. Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information. This memo specifies a MIB module that is compliant to SMIv2, which is described in RFC 2578, RFC 2579 and RFC 2580, all of which are STD 58.
A MIB is a named list of values on a device. A manager reads it over SNMP. The names and the shapes of those values follow a common notation, and this document uses that notation to define its conventions.
§4Identifiers, Indexes and Groups
The module is identified as pwTcStdMIB, is rooted at { mib-2 188 }, and carries a single revision dated 21 April 2009, described as the original version. Each convention has a display hint of d, meaning that the value is shown as a decimal number, and a status of current.
PwGroupID is an administrative identification for grouping a set of service-specific pseudowire services, with syntax Unsigned32. PwIDType is the pseudowire identifier, used to identify the pseudowire, together with some other fields, in the signaling session; it too has syntax Unsigned32.
PwIndexType is the pseudowire index: a unique value, greater than zero, for each locally defined pseudowire, used for indexing several MIB tables associated with that pseudowire. It is recommended that values are assigned contiguously starting from 1, and the value for each pseudowire MUST remain constant at least from one re-initialization to the next re-initialization. Its syntax is Unsigned32 (1..4294967295).
PwIndexOrZeroType extends that convention by permitting the additional value of zero. The zero value is object-specific and MUST therefore be defined as part of the description of any object that uses this syntax; examples of its use include situations where the pseudowire was unknown, or where none or all pseudowires need to be referenced. Its syntax is Unsigned32 (0..4294967295).
PwAttachmentIdentifierType is an octet string used in the generalized Forward Error Correction element for identifying attachment forwarders and groups. A NULL identifier is of zero length, and the syntax is OCTET STRING (SIZE (0..255)). PwGenIdType represents the Attachment Group Identifier type and the Attachment Individual Identifier type in generalized FEC signaling and configuration, with syntax Unsigned32 (0..254).
PwCfgIndexOrzero is an index in any of the relevant configuration tables for supplementary information regarding the configuration of the specific technology. The value zero implies that no additional configuration information is applicable, and the syntax is Unsigned32 (0..4294967295).
These conventions name the values that identify a pseudowire and the rows that hold its information. A pseudowire gets a number of its own that stays the same across restarts, and a second number that indexes the tables where its details are kept.
- IdentifiersPwGroupID groups services, PwIDType identifies a pseudowire in the signaling session.
- IndexesPwIndexType numbers each locally defined pseudowire; PwIndexOrZeroType allows zero as well.
- Configuration indexPwCfgIndexOrzero points at a row in a technology-specific configuration table.
- FEC identifiersPwAttachmentIdentifierType and PwGenIdType name attachment forwarders and groups.
- Operational statusPwOperStatusTC gives six states, from up to lowerLayerDown.
- FaultsPwStatus carries five bits covering forwarding and receive or transmit faults.
- Control wordPwCwStatusTC reports the outcome of control word negotiation with the peer.
- FragmentationPwFragSize and PwFragStatus describe the desired and actual fragmentation state.
§4Status, Control Word and Fragmentation Values
PwOperStatusTC indicates the operational status of the pseudowire. It has six values. up(1) means ready to pass packets. down(2) means the pseudowire signaling is not yet finished, or indications available at the service level indicate that the pseudowire is not passing packets. testing(3) means the administrative status at the pseudowire level is set to test. dormant(4) means the pseudowire is not in a condition to pass packets but is in a pending state, waiting for some external event. notPresent(5) means some component is missing to accomplish the setup of the pseudowire, which can be a configuration error, incomplete configuration, or a missing hardware component. lowerLayerDown(6) means one or more of the lower-layer interfaces responsible for running the underlying packet switched network is not in the up state.
PwStatus indicates the status of the pseudowire and the interfaces affecting it, as a set of bits: pwNotForwarding(0), servicePwRxFault(1), servicePwTxFault(2), psnPwRxFault(3) and psnPwTxFault(4). If none of the bits are set, it indicates that no faults are reported.
PwCwStatusTC indicates the status of the control word negotiation, based on the local configuration and the indications received from the peer node. waitingForNextMsg(1) means the node is waiting for another label mapping from the peer. sentWrongBitErrorCode(2) means the local node has notified the peer about a mismatch in the C-bit. rxWithdrawWithWrongBitErrorCode(3) means a withdraw message has been received with the wrong C-bit error code. illegalReceivedBit(4) means a C-bit configuration with the peer that is not compatible with the pseudowire type. cwPresent(5) means the control word is present for this pseudowire: if signaling is used, the C-bit is set and agreed upon between the nodes, and for a manually configured pseudowire the local configuration requires the use of the control word. cwNotPresent(6) means the opposite. notYetKnown(7) means a label mapping has not yet been received from the peer.
PwFragSize gives the desired fragmentation length in bytes; if set to zero, fragmentation is not desired for packets bound for the packet switched network. PwFragStatus indicates the status of the fragmentation and reassembly process, based on local configuration and peer capability, as a set of bits: noFrag(0), meaning the local configuration is for no fragmentation; cfgFragGreaterThanPsnMtu(1), meaning the local node is set to fragment but the fragmentation size is greater than the MTU available between the nodes, so fragmentation is not done in that case; cfgFragButRemoteIncapable(2), meaning the local configuration conveys the desire for fragmentation but the peer is not capable of reassembly; remoteFragCapable(3), meaning the remote node is capable of accepting fragmented protocol data units; and fragEnabled(4), meaning that fragmentation will be used on this pseudowire, which requires that the local node was configured for fragmentation, that the peer can accept fragmented packets, and that the control word is in use.
These conventions say what state a pseudowire is in. There is a list of six operational states, from up through down and testing to dormant and not present, and a set of fault bits for the cases where something is wrong with forwarding or with the packet network underneath.
Two more sets of values cover the optional features. The control word states say whether the two ends agreed on the control word, and the fragmentation bits say whether packets are being split to fit a smaller link.
- up(1)up — Ready to pass packets.
- down(2)down — Signaling is not yet finished, or service-level indications say the pseudowire is not passing packets.
- testing(3)testing — AdminStatus at the pseudowire level is set to test.
- dormant(4)dormant — Not in a condition to pass packets, but waiting for some external event.
- notPresent(5)notPresent — Some component is missing to accomplish the setup of the pseudowire.
- lowerLayerDown(6)lowerLayerDown — One or more lower-layer interfaces running the underlying packet switched network is not up.
- waitingForNextMsg(1)waitingForNextMsg — Waiting for another label mapping from the peer.
- sentWrongBitErrorCode(2)sentWrongBitErrorCode — The local node has told the peer about a mismatch in the C-bit.
- rxWithdrawWithWrongBitErrorCode(3)rxWithdrawWithWrongBitErrorCode — A withdraw message was received with the wrong C-bit error code.
- illegalReceivedBit(4)illegalReceivedBit — A C-bit configuration with the peer that is not compatible with the pseudowire type.
- cwPresent(5)cwPresent — The control word is present for this pseudowire.
- cwNotPresent(6)cwNotPresent — The control word is not present for this pseudowire.
- notYetKnown(7)notYetKnown — A label mapping has not yet been received from the peer.
§5Security Considerations
This module does not define any management objects. Instead, it defines a set of textual conventions that may be used by other PWE3 MIB modules to define management objects.
Meaningful security considerations can only be written in the MIB modules that define management objects. The RFC therefore states that this document has no impact on the security of the Internet.
The module defines no values that can be read or set, so it adds nothing that could be attacked. The security questions belong to the modules that use these conventions to publish real objects.
§6IANA Considerations
The MIB module in this document uses the IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry. The descriptor pwTcStdMIB is assigned the value { mib-2 188 }.
The module is registered under a fixed number so that other modules can point at it and import from it.