FS-NMS-LLDP-MIB

This TC describes the format of a chassis identifier string.
Objects of this type are always used with an associated
LldpChassisIdSubtype object, which identifies the format of
the particular LldpChassisId object instance.

If the associated LldpChassisIdSubtype object has a value of
'chassisComponent(1)', then the octet string identifies
a particular instance of the entPhysicalAlias object
(defined in IETF RFC 2737) for a chassis component (i.e.,
an entPhysicalClass value of 'chassis(3)').

If the associated LldpChassisIdSubtype object has a value
of 'interfaceAlias(2)', then the octet string identifies
a particular instance of the ifAlias object (defined in
IETF RFC 2863) for an interface on the containing chassis.
If the particular ifAlias object does not contain any values,
another chassis identifier type should be used.

If the associated LldpChassisIdSubtype object has a value
of 'portComponent(3)', then the octet string identifies a
particular instance of the entPhysicalAlias object (defined
in IETF RFC 2737) for a port or backplane component within
the containing chassis.

If the associated LldpChassisIdSubtype object has a value of
'macAddress(4)', then this string identifies a particular
unicast source address (encoded in network byte order and
IEEE 802.3 canonical bit order), of a port on the containing
chassis as defined in IEEE Std 802-2001.

If the associated LldpChassisIdSubtype object has a value of
'networkAddress(5)', then this string identifies a particular
network address, encoded in network byte order, associated
with one or more ports on the containing chassis. The first
octet contains the IANA Address Family Numbers enumeration
value for the specific address type, and octets 2 through
N contain the network address value in network byte order.

If the associated LldpChassisIdSubtype object has a value
of 'interfaceName(6)', then the octet string identifies
a particular instance of the ifName object (defined in
IETF RFC 2863) for an interface on the containing chassis.
If the particular ifName object does not contain any values,
another chassis identifier type should be used.

If the associated LldpChassisIdSubtype object has a value of
'local(7)', then this string identifies a locally assigned
Chassis ID.

This TC describes the source of a chassis identifier.

The enumeration 'chassisComponent(1)' represents a chassis
identifier based on the value of entPhysicalAlias object
(defined in IETF RFC 2737) for a chassis component (i.e.,
an entPhysicalClass value of 'chassis(3)').

The enumeration 'interfaceAlias(2)' represents a chassis
identifier based on the value of ifAlias object (defined in
IETF RFC 2863) for an interface on the containing chassis.

The enumeration 'portComponent(3)' represents a chassis
identifier based on the value of entPhysicalAlias object
(defined in IETF RFC 2737) for a port or backplane
component (i.e., entPhysicalClass value of 'port(10)' or
'backplane(4)'), within the containing chassis.

The enumeration 'macAddress(4)' represents a chassis
identifier based on the value of a unicast source address
(encoded in network byte order and IEEE 802.3 canonical bit
order), of a port on the containing chassis as defined in
IEEE Std 802-2001.

The enumeration 'networkAddress(5)' represents a chassis
identifier based on a network address, associated with
a particular chassis. The encoded address is actually
composed of two fields. The first field is a single octet,
representing the IANA AddressFamilyNumbers value for the
specific address type, and the second field is the network
address value.

The enumeration 'interfaceName(6)' represents a chassis
identifier based on the value of ifName object (defined in
IETF RFC 2863) for an interface on the containing chassis.

The enumeration 'local(7)' represents a chassis identifier
based on a locally defined value.

This TC describes the basis of a particular type of
interface associated with the management address.

The enumeration 'unknown(1)' represents the case where the
interface is not known.

The enumeration 'ifIndex(2)' represents interface identifier
based on the ifIndex MIB object.

The enumeration 'systemPortNumber(3)' represents interface
identifier based on the system port numbering convention.

The value of a management address associated with the LLDP
agent that may be used to reach higher layer entities to
assist discovery by network management.

It should be noted that appropriate security credentials,
such as SNMP engineId, may be required to access the LLDP
agent using a management address. These necessary credentials
should be known by the network management and the objects
associated with the credentials are not included in the
LLDP agent.

This TC describes the format of a port identifier string.
Objects of this type are always used with an associated
LldpPortIdSubtype object, which identifies the format of the
particular LldpPortId object instance.

If the associated LldpPortIdSubtype object has a value of
'interfaceAlias(1)', then the octet string identifies a
particular instance of the ifAlias object (defined in IETF
RFC 2863). If the particular ifAlias object does not contain
any values, another port identifier type should be used.

If the associated LldpPortIdSubtype object has a value of
'portComponent(2)', then the octet string identifies a
particular instance of the entPhysicalAlias object (defined
in IETF RFC 2737) for a port or backplane component.

If the associated LldpPortIdSubtype object has a value of
'macAddress(3)', then this string identifies a particular
unicast source address (encoded in network byte order
and IEEE 802.3 canonical bit order) associated with the port
(IEEE Std 802-2001).

If the associated LldpPortIdSubtype object has a value of
'networkAddress(4)', then this string identifies a network
address associated with the port. The first octet contains
the IANA AddressFamilyNumbers enumeration value for the
specific address type, and octets 2 through N contain the
networkAddress address value in network byte order.

If the associated LldpPortIdSubtype object has a value of
'interfaceName(5)', then the octet string identifies a
particular instance of the ifName object (defined in IETF
RFC 2863). If the particular ifName object does not contain
any values, another port identifier type should be used.

If the associated LldpPortIdSubtype object has a value of
'agentCircuitId(6)', then this string identifies a agent-local
identifier of the circuit (defined in RFC 3046).

If the associated LldpPortIdSubtype object has a value of
'local(7)', then this string identifies a locally
assigned port ID.

This TC describes the source of a particular type of port
identifier used in the LLDP MIB.

The enumeration 'interfaceAlias(1)' represents a port
identifier based on the ifAlias MIB object, defined in IETF
RFC 2863.

The enumeration 'portComponent(2)' represents a port
identifier based on the value of entPhysicalAlias (defined in
IETF RFC 2737) for a port component (i.e., entPhysicalClass
value of 'port(10)'), within the containing chassis.

The enumeration 'macAddress(3)' represents a port identifier
based on a unicast source address (encoded in network
byte order and IEEE 802.3 canonical bit order), which has
been detected by the agent and associated with a particular
port (IEEE Std 802-2001).

The enumeration 'networkAddress(4)' represents a port
identifier based on a network address, detected by the agent
and associated with a particular port.

The enumeration 'interfaceName(5)' represents a port
identifier based on the ifName MIB object, defined in IETF
RFC 2863.

The enumeration 'agentCircuitId(6)' represents a port
identifier based on the agent-local identifier of the circuit
(defined in RFC 3046), detected by the agent and associated
with a particular port.

The enumeration 'local(7)' represents a port identifier
based on a value locally assigned.

Each octet within this value specifies a set of eight ports,
with the first octet specifying ports 1 through 8, the second
octet specifying ports 9 through 16, etc. Within each octet,
the most significant bit represents the lowest numbered port,
and the least significant bit represents the highest numbered
port. Thus, each port of the system is represented by a
single bit within the value of this object. If that bit has
a value of '1' then that port is included in the set of ports;
the port is not included if its bit has a value of '0'.

Each port contained in the chassis (that is known to the
LLDP agent) is uniquely identified by a port number.

A port number has no mandatory relationship to an
InterfaceIndex object (of the interfaces MIB, IETF RFC 2863).
If the LLDP agent is a IEEE 802.1D, IEEE 802.1Q bridge, the
LldpPortNumber will have the same value as the dot1dBasePort
object (defined in IETF RFC 1493) associated corresponding
bridge port. If the system hosting LLDP agent is not an
IEEE 802.1D or an IEEE 802.1Q bridge, the LldpPortNumber
will have the same value as the corresponding interface's
InterfaceIndex object.

Port numbers should be in the range of 1 and 4096 since a
particular port is also represented by the corresponding
port number bit in LldpPortList.

This TC describes the system capabilities.

The bit 'other(0)' indicates that the system has capabilities
other than those listed below.

The bit 'repeater(1)' indicates that the system has repeater
capability.

The bit 'bridge(2)' indicates that the system has bridge
capability.

The bit 'wlanAccessPoint(3)' indicates that the system has
WLAN access point capability.

The bit 'router(4)' indicates that the system has router
capability.

The bit 'telephone(5)' indicates that the system has telephone
capability.

The bit 'docsisCableDevice(6)' indicates that the system has
DOCSIS Cable Device capability (IETF RFC 2669 & 2670).

The bit 'stationOnly(7)' indicates that the system has only
station capability and nothing else.

To be used for the index to a table. Allows an application
to download only those rows changed since a particular time.
A row is considered changed if the value of any object in the
row changes or if the row is created or deleted.

When sysUpTime is equal to zero, this table shall be empty.

One entry exists for each past value of sysUpTime, except that
the whole table is purged should sysUpTime wrap.

As this basic row is updated new conceptual rows are created
(which still share the now updated object values with all
other instances). The number of instances which are created
is determined by the value of sysUpTime at which the basic row
was last updated. One instance will exist for each value of
sysUpTime at the last update time for the row. A new
timeMark instance is created for each new sysUpTime value.
Each new conceptual row will be associated with the timeMark
instance which was created at the value of sysUpTime with
which the conceptual row is to be associated.

By definition all conceptual rows were updated at or after
time zero and so at least one conceptual row (associated with
timeMark.0) must exist for each underlying (basic) row.

See the appendix for further discussion of this variable.

Consider the following fooTable:

fooTable ...
INDEX { fooTimeMark, fooIndex }

FooEntry {
fooTimeMark TimeFilter
fooIndex INTEGER,
fooCounts Counter
}

Should there be two basic rows in this table (fooIndex == 1,
fooIndex == 2) and row 1 was updated most recently at time 6,
while row 2 was updated most recently at time 8, and both rows
had been updated on several earlier occasions such that the
current values were 5 and 9 respectively then the following
fooCounts instances would exist.

fooCounts.0.1 5
fooCounts.0.2 9
fooCounts.1.1 5

fooCounts.1.2 9
fooCounts.2.1 5
fooCounts.2.2 9
fooCounts.3.1 5
fooCounts.3.2 9
fooCounts.4.1 5
fooCounts.4.2 9
fooCounts.5.1 5
fooCounts.5.2 9
fooCounts.6.1 5
fooCounts.6.2 9
fooCounts.7.2 9 -- note that row 1 doesn't exist for
fooCounts.8.2 9 -- times 7 and 8

This TC describes an object which counts events with the
following semantics: objects of this type will be set to
zero(0) on creation and will thereafter count appropriate
events, wrapping back to zero(0) when the value 2^32 is
reached.

Provided that an application discovers the new object within
the minimum time to wrap it can use the initial value as a
delta since it last polled the table of which this object is
part. It is important for a management station to be aware of
this minimum time and the actual time between polls, and to
discard data if the actual time is too long or there is no
defined minimum time.

Typically this TC is used in tables where the INDEX space is
constantly changing and/or the TimeFilter mechanism is in use.