ZXR10-CFM-MIB

An integer which may be used as a new Index in a table.
The special value of 0 indicates that no more new entries can
be created in the relevant table.
When a MIB is used for configuration, an object with this
SYNTAX always contains a legal value (if non-zero) for an
index that is not currently used in the relevant table. The
Command Generator (Network Management Application) reads this
variable and uses the (non-zero) value read when creating a
new row with an SNMP SET. When the SET is performed, the
Command Responder (agent) must determine whether the value is
indeed still unused; Two Network Management Applications may
attempt to create a row (configuration entry) simultaneously
and use the same value. If it is currently unused, the SET
succeeds and the Command Responder (agent) changes the value
of this object, according to an implementation-specific
algorithm. If the value is in use, however, the SET fails.
The Network Management Application must then re-read this
variable to obtain a new usable value.
An OBJECT-TYPE definition using this SYNTAX MUST specify the
relevant table for which the object is providing this
functionality.

Indicates the interval at which CCMs are sent by a MEP.
The possible values are:
intervalInvalid(0) No CCMs are sent (disabled).
interval300Hz(1) CCMs are sent every 3 1/3 milliseconds
(300Hz).
interval10ms(2) CCMs are sent every 10 milliseconds.
interval100ms(3) CCMs are sent every 100 milliseconds.
interval1s(4) CCMs are sent every 1 second.
interval10s(5) CCMs are sent every 10 seconds.
interval1min(6) CCMs are sent every minute.
interval10min(7) CCMs are sent every 10 minutes.
Note: enumerations start at zero to match the 'CCM Interval
field' protocol field.

Value equal to MD Level.

Possible values returned in the egress action field

Indicates the diferent states of the MEP Fault Notification
Generator State Machine.
fngReset(1) No defect has been present since the
dot1agCfmMepFngResetTime timer
expired, or since the state machine
was last reset.
fngDefect(2) A defect is present, but not for a
long enough time to be reported
(dot1agCfmMepFngAlarmTime).
fngReportDefect(3) A momentary state during which the
defect is reported by sending a
dot1agCfmFaultAlarm notification,
if that action is enabled.
fngDefectReported(4) A defect is present, and some defect
has been reported.
fngDefectClearing(5) No defect is present, but the
dot1agCfmMepFngResetTime timer has
not yet expired.

An enumerated value, equal to the contents of the variable
highestDefect (20.33.9 and Table 20-1), indicating the
highest-priority defect that has been present since the MEP
Fault Notification Generator State Machine was last in the
FNG_RESET state, either:
none(0) no defects since FNG_RESET
defRDICCM(1) DefRDICCM
defMACstatus(2) DefMACstatus
defRemoteCCM(3) DefRemoteCCM
defErrorCCM(4) DefErrorCCM
defXconCCM(5) DefXconCCM
The value 0 is used for no defects so that additional higher
priority values can be added, if needed, at a later time, and
so that these values correspond with those in
Dot1agCfmLowestAlarmPri.

Indicates what, if anything, is to be included in the Sender
ID TLV transmitted in CCMs, LBMs, LTMs, and LTRs. The valid
values are:
sendIdNone(1) The Sender ID TLV is not to be sent.
sendIdChassis(2) The Chassis ID Length, Chassis ID
Subtype, and Chassis ID fields of the
Sender ID TLV are to be sent.
sendIdManage(3) The Management Address Length and
Management Address of the Sender ID TLV
are to be sent.
sendIdChassisManage(4) The Chassis ID Length, Chassis ID
Subtype, Chassis ID, Management Address
Length and Management Address fields are
all to be sent.
sendIdDefer(5) The contents of the Sender ID TLV are
determined by the corresponding
Maintenance Domain variable
(dot1agCfmMaIdPermission).

Possible values returned in the ingress action field.

Sequence number/transaction identifier received in
a Loopback Reply.

An integer value specifying the lowest priority defect
that is allowed to generate a Fault Alarm (20.9.5), either:
allDef(1) DefRDICCM, DefMACstatus, DefRemoteCCM,
DefErrorCCM, and DefXconCCM;
macRemErrXcon(2) Only DefMACstatus, DefRemoteCCM,
DefErrorCCM, and DefXconCCM (default);
remErrXcon(3) Only DefRemoteCCM, DefErrorCCM,
and DefXconCCM;
errXcon(4) Only DefErrorCCM and DefXconCCM;
xcon(5) Only DefXconCCM; or
noXcon(6) No defects DefXcon or lower are to be
reported;

Integer identifying the Maintenance Domain Level (MD Level).
Higher numbers correspond to higher Maintenance Domains,
those with the greatest physical reach, with the highest
values for customers' CFM PDUs. Lower numbers correspond
to lower Maintenance Domains, those with more limited
physical reach, with the lowest values for CFM PDUs
protecting single bridges or physical links.

Denotes a generic Maintenance Association Name. It is the
part of the Maintenance Association Identifier which is
unique within the Maintenance Domain Name and is appended
to the Maintenance Domain Name to form the Maintenance
Association Identifier (MAID).
A Dot1agCfmMaintAssocName value is always interpreted within
the context of a Dot1agCfmMaintAssocNameType value. Every
usage of the Dot1agCfmMaintAssocName textual convention is
required to specify the Dot1agCfmMaintAssocNameType object
that provides the context. It is suggested that the
Dot1agCfmMaintAssocNameType object be logically registered
before the object(s) that use the Dot1agCfmMaintAssocName
textual convention, if they appear in the same logical row.
The value of a Dot1agCfmMaintAssocName object must
always be consistent with the value of the associated
Dot1agCfmMaintAssocNameType object. Attempts to set
an Dot1agCfmMaintAssocName object to a value inconsistent
with the associated Dot1agCfmMaintAssocNameType must fail
with an inconsistentValue error.
When this textual convention is used as the syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, IETF STD 58. In this
case, the object definition MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers;
otherwise the applicable constraints MUST be stated in
the appropriate conceptual row DESCRIPTION clauses, or
in the surrounding documentation if there is no single
DESCRIPTION clause that is appropriate.

A value that represents a type (and thereby the format)
of a Dot1agCfmMaintAssocName. The value can be one of
the following:
ieeeReserved(0) Reserved for definition by IEEE 802.1
recommend to not use zero unless
absolutely needed.
primaryVid(1) Primary VLAN ID.
12 bits represented in a 2-octet integer:
- 4 least significant bits of the first
byte contains the 4 most significant
bits of the 12 bits primary VID
- second byte contains the 8 least
significant bits of the primary VID
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|0 0 0 0| (MSB) |
+-+-+-+-+-+-+-+-+
| VID LSB |
+-+-+-+-+-+-+-+-+
charString(2) RFC2579 DisplayString, except that the
character codes 0-31 (decimal) are not
used. (1..45) octets
unsignedInt16 (3) 2-octet integer/big endian
rfc2865VpnId(4) RFC 2685 VPN ID
3 octet VPN authority Organizationally
Unique Identifier followed by 4 octet VPN
index identifying VPN according to the OUI:
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| VPN OUI (MSB) |
+-+-+-+-+-+-+-+-+
| VPN OUI |
+-+-+-+-+-+-+-+-+
| VPN OUI (LSB) |
+-+-+-+-+-+-+-+-+
|VPN Index (MSB)|
+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+
|VPN Index (LSB)|
+-+-+-+-+-+-+-+-+
iccString(32) ICC-based string. It consists of two subfields:
the ITU carrier code (ICC) followed by a unique MEG ID code (UMC).
The ITU Carrier Code consists of 1 6 left-justified characters,
alphabetic, or leading alphabetic with trailing numeric. The UMC
code immediately follows the ICC and shall consist of 7-12 characters,
with trailing NULLs, completing the 13-character MEG ID Value.
The UMC shall be a matter for the organization to which the ICC
has been assigned, provided that uniqueness is guaranteed.
ieeeReserved(xx) Reserved for definition by IEEE 802.1
xx values can be [5..31] and [64..255]
ituReserved(xx) Reserved for definition by ITU-T Y.1731
xx values range from [33..63]
To support future extensions, the Dot1agCfmMaintAssocNameType
textual convention SHOULD NOT be sub-typed in object type
definitions. It MAY be sub-typed in compliance statements in
order to require only a subset of these address types for a
compliant implementation.
Implementations must ensure that Dot1agCfmMaintAssocNameType
objects and any dependent objects (e.g.,
Dot1agCfmMaintAssocName objects) are consistent. An
inconsistentValue error must be generated if an attempt to
change an Dot1agCfmMaintAssocNameType object would, for
example, lead to an undefined Dot1agCfmMaintAssocName value.
In particular,
Dot1agCfmMaintAssocNameType/Dot1agCfmMaintAssocName pairs
must be changed together if the nameType changes.
The Maintenance Domain name and Maintenance Association name,
when put together into the CCM PDU, MUST total 48 octets or
less. If the Dot1agCfmMaintDomainNameType object contains
none(1), then the Dot1agCfmMaintAssocName object MUST be
45 octets or less in length. Otherwise, the length of
the Dot1agCfmMaintDomainName object plus the length of the
Dot1agCfmMaintAssocName object, added together, MUST total
less than or equal to 44 octets.

Denotes a generic Maintenance Domain Name.A Dot1agC
fmMaintDomainName value is always interpreted within
the context of a Dot1agCfmMaintDomainNameType value. Every
usage of the Dot1agCfmMaintDomainName textual convention is
required to specify the Dot1agCfmMaintDomainNameType object
that provides the context. It is suggested that the
Dot1agCfmMaintDomainNameType object be logically registered
before the object(s) that use the Dot1agCfmMaintDomainName
textual convention, if they appear in the same logical row.
The value of a Dot1agCfmMaintDomainName object must always
be consistent with the value of the associated
Dot1agCfmMaintDomainNameType object. Attempts to set
an Dot1agCfmMaintDomainName object to a value inconsistent
with the associated Dot1agCfmMaintDomainNameType must fail
with an inconsistentValue error.
When this textual convention is used as the syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, IETF STD 58. In this
case, the object definition MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers;
otherwise the applicable constraints MUST be stated in
the appropriate conceptual row DESCRIPTION clauses, or
in the surrounding documentation if there is no single
DESCRIPTION clause that is appropriate.
A value of none(1) in the associated
Dot1agCfmMaintDomainNameType object means that no Maintenance
Domain name is present, and the contents of the
Dot1agCfmMaintDomainName object are meaningless.
See the DESCRIPTION of the Dot1agCfmMaintAssocNameType
TEXTUAL-CONVENTION for a discussion of the length limits on
the Maintenance Domain name and Maintenance Association name.

A value that represents a type (and thereby the format)
of a Dot1agCfmMaintDomainName. The value can be one of
the following:
ieeeReserved(0) Reserved for definition by IEEE 802.1
recommend to not use zero unless
absolutely needed.
none(1) No format specified, usually because
there is not (yet) a Maintenance
Domain Name. In this case, a zero
length OCTET STRING for the Domain
Name field is acceptable.
dnsLikeName(2) Domain Name like string, globally unique
text string derived from a DNS name.
macAddrAndUint(3) MAC address + 2-octet (unsigned) integer.
charString(4) RFC2579 DisplayString, except that the
character codes 0-31 (decimal) are not
used.
ieeeReserved(xx) Reserved for definition by IEEE 802.1
xx values can be [5..31] and [64..255]
ituReserved(xx) Reserved for definition by ITU-T Y.1731
xx values range from [32..63]To
support future extensions, the Dot1agCfmMaintDomainNameType
textual convention SHOULD NOT be sub-typed in object type
definitions. It MAY be sub-typed in compliance statements in
order to require only a subset of these address types for a
compliant implementation.
Implementations must ensure that Dot1agCfmMaintDomainNameType
objects and any dependent objects (e.g.,
Dot1agCfmMaintDomainName objects) are consistent. An
inconsistentValue error must be generated if an attempt to
change an Dot1agCfmMaintDomainNameType object would, for
example, lead to an undefined Dot1agCfmMaintDomainName value.
In particular,
Dot1agCfmMaintDomainNameType/Dot1agCfmMaintDomainName pairs
must be changed together if the nameType changes.

A MEP can detect and report a number of defects, and multiple
defects can be present at the same time. These defects are:
bDefRDICCM(1) A remote MEP is reported the RDI bit in its
last CCM.
bDefMACstatus(2) Either some remote MEP is reporting its
Interface Status TLV as not isUp, or all remote
MEPs are reporting a Port Status TLV that
contains some value other than psUp.
bDefRemoteCCM(3) The MEP is not receiving valid CCMs from at
least one of the remote MEPs.
bDefErrorCCM(4) The MEP has received at least one invalid CCM
whose CCM Interval has not yet timed out.
bDefXconCCM(5) The MEP has received at least one CCM from
either another MAID or a lower MD Level whose
CCM Interval has not yet timed out.

Indicates if the Management Entity can create MHFs.
The valid values are:
defMHFnone(1) No MHFs can be created for this VID.
defMHFdefault(2) MHFs can be created on this VID on any
Bridge port through which this VID can
pass.
defMHFexplicit(3) MHFs can be created for this VID only on
Bridge ports through which this VID can
pass, and only if a MEP is created at some
lower MD Level.
defMHFdefer(4) The creation of MHFs is determined by the
corresponding Maintenance Domain variable
(dot1agCfmMaMhfCreation).

Indicates the direction in which the Maintenance
association (MEP or MIP) faces on the bridge port:
down(1) Sends Continuity Check Messages away from the
MAC Relay Entity.
up(2) Sends Continuity Check Messages towards the
MAC Relay Entity.

Possible values the Relay action field can take.

Maintenance association End Point Identifier (MEPID): A small
integer, unique over a given Maintenance Association,
identifying a specific MEP.

This textual convention is an extension of the
InterfaceIndex convention. The latter defines a
greater than zero value used to identify an interface
or interface sub-layer in the managed system. This
extension permits the additional value of zero. the
value zero is object-specific and must therefore be
defined as part of the description of any object which
uses this syntax. Examples of the usage of zero might
include situations where interface was unknown, or
when none or all interfaces need to be referenced.

The VLAN-ID that uniquely identifies a VLAN. This
is the 12-bit VLAN-ID used in the VLAN Tag header.
The range is defined by the REFERENCEd specification.

The VLAN-ID that uniquely identifies a specific VLAN,
or no VLAN. The special value of zero is used to
indicate that no VLAN-ID is present or used. This can
be used in any situation where an object or a table entry
must refer either to a specific VLAN, or to no VLAN.

Note that a MIB object that is defined using this
TEXTUAL-CONVENTION should clarify the meaning of
'no VLAN' (i.e., the special value 0).