Request for Comments: 4327 T. Nadeau
Category: Standards Track Cisco Systems
J. Lang
Sonos, Inc.
E. McGinnis
Hammerhead Systems
January 2006
Link Management Protocol (LMP) Management Information Base (MIB)
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) The Internet Society (2006).
Abstract
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 managed objects for modeling the Link
Management Protocol (LMP).
Table of Contents
1. The Internet-Standard Management Framework ......................2
2. Introduction ....................................................2
3. Terminology .....................................................3
4. Feature Checklist ...............................................3
5. Outline .........................................................4
6. Brief Description of MIB Objects ................................4
6.1. lmpNbrTable ................................................4
6.2. lmpControlChannelTable .....................................4
6.3. lmpControlChannelPerfTable .................................4
6.4. lmpTeLinkTable .............................................5
6.5. lmpLinkVerificationTable ...................................5
6.6. lmpTeLinkPerfTable .........................................5
6.7. lmpDataLinkTable ...........................................5
6.8. lmpDataLinkPerfTable .......................................5
7. Example of LMP Control Channel Setup ............................5
8. Application of the Interfaces Group to LMP ......................8
8.1. Support of the LMP Layer by ifTable ........................9
9. LMP MIB Module Definitions .....................................11
10. Security Considerations .......................................77
11. Contributors ..................................................78
12. Acknowledgements ..............................................78
13. IANA Considerations ...........................................78
13.1. IANA Considerations for lmp ifType .......................78
13.2. IANA Considerations for LMP-MIB ..........................78
14. References ....................................................79
14.1. Normative References .....................................79
14.2. Informative References ...................................80
1. 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 the 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].
2. Introduction
Current work is under way in the IETF to specify a suite of protocols
to be used as a common control plane and a separate common
measurement plane. Generalized MPLS (GMPLS) [RFC3471] and the Link
Management Protocol [RFC4204] are key components of this
standardization activity. The primary purpose of LMP is to manage
traffic engineering (TE) links. Primary goals of LMP are the
maintenance of the control channel connectivity, correlation of link
properties, verification of data-bearing links, and detection and
isolation of link faults.
We describe in this document a MIB module that can be used to manage
LMP implementations. This MIB module covers both configuration and
performance monitoring aspects of LMP.
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 RFC 2119 [RFC2119].
3. Terminology
This document uses terminology from the document describing the Link
Management Protocol [RFC4204]. An "LMP adjacency" is formed between
two nodes that support the same capabilities, and LMP messages are
exchanged between the node pair over control channels that form this
adjacency. Several control channels can be active at the same time.
With the exception of messages related to control channel management,
anytime an LMP message needs to be transferred to a neighbor node, it
can be sent on any of the active control channels. The control
channels can also be used to exchange MPLS control plane information
or routing information.
LMP is designed to support aggregation of one or more data-bearing
links into a traffic-engineering (TE) link. The data-bearing links
can be either component links or ports depending on their
multiplexing capability (see [RFC4204] for distinction between port
and component link).
Each TE link is associated with an LMP adjacency, and one or more
control channels are used to exchange LMP messages for a particular
adjacency. In turn, control channels are used to manage the TE links
associated with the LMP adjacency.
4. Feature Checklist
The Link Management Protocol MIB module (LMP-MIB) is designed to
satisfy the following requirements and constraints:
- The MIB module supports the enabling and disabling of LMP
capability on LMP-capable interfaces of a photonic switch, optical
cross-connect, or router.
- The MIB module is used to provide information about LMP
adjacencies.
- Support is provided for configuration of the keep alive and link
verification parameters.
- The MIB module is used to express the mapping between local and
remote TE links, as well as local and remote interface identifiers
for port or component link.
- Performance counters are provided for measuring LMP performance on
a per-control channel basis. Performance counters are also
provided for measuring LMP performance on the data-bearing links.
Note that the LMP MIB module goes hand-in-hand with the TE Link
(TE-LINK-STD-MIB) MIB module [RFC4220]. The TE link table, which is
used to associate data-bearing links to TE links, is defined in the
TE Link MIB. The TE link table in the LMP MIB module contains TE
link information specific to LMP.
5. Outline
Configuring LMP through an optical device involves the following
steps:
- Enabling LMP on LMP-capable interfaces through control channel
configuration.
- Optionally specifying link verification parameters.
- Configuring the data-bearing links and associating them to the
appropriate TE link (this association is stored in the
ifStackTable of the Interfaces Group MIB).
TE links are managed by the control channels that run between the
same pair of nodes (LMP adjacency).
6. Brief Description of MIB Objects
Sections 6.1-6.8 describe objects pertaining to LMP. The MIB objects
were derived from the LMP document [RFC4204].
6.1. lmpNbrTable
The remote node table is used to identify the pair of nodes that
exchange LMP messages over control channels.
6.2. lmpControlChannelTable
The control channel table is used for enabling the LMP protocol on
LMP-capable interfaces. A photonic switch, optical cross-connect, or
router creates an entry in this table for every LMP-capable interface
in that device.
6.3. lmpControlChannelPerfTable
The control channel performance table is used for collecting LMP
performance counts on a per-control channel basis. Each entry in the
lmpControlChannelTable has a corresponding entry in the
lmpControlChannelPerfTable.
6.4. lmpTeLinkTable
The TE link table is used for specifying LMP information associated
with TE links.
6.5. lmpLinkVerificationTable
The link verification table is used for configuring the LMP link
verification parameters of TE links. For every TE link entry in the
lmpTeLinkTable that supports the link verification procedure, there
is a corresponding entry in the lmpLinkVerificationTable.
6.6. lmpTeLinkPerfTable
The TE link performance table is used for collecting LMP performance
counts on a per-TE link basis. Each entry in the lmpTeLinkTable has
a corresponding entry in the lmpTeLinkPerfTable.
6.7. lmpDataLinkTable
The data-bearing link table is used to specify the data-bearing links
that are associated with TE links.
6.8. lmpDataLinkPerfTable
The data-bearing link performance table is used for collecting LMP
performance counts on data-bearing links.
7. Example of LMP Control Channel Setup
In this section, we provide a brief example of using the MIB
objects described in section 9 to set up an LMP control channel.
While this example is not meant to illustrate every nuance of the
MIB module, it is intended as an aid to understanding some of the
key concepts. It is meant to be read after going through the MIB
itself.
Suppose that one would like to form an LMP adjacency between two
nodes using two control channels. Suppose also that there are
three data-bearing links. We also assume that the data-bearing
links are ports (lambdas). We also assume that the link
verification procedure is not enabled. The following example
illustrates which rows and corresponding objects might be created
to accomplish this.
First, LMP must be enabled between the pair of nodes.
In lmpNbrTable:
{
lmpNbrNodeId = ’c0000201’H, -- 192.0.2.1
lmpNbrAdminStatus = up(1),
lmpNbrRowStatus = createAndGo(4),
lmpNbrStorageType = nonVolatile(3)
}
Then, the control channels must be set up. These are created in
the lmpControlChannelTable.
In lmpControlChannelTable:
{
lmpCcId = 1,
lmpCcUnderlyingIfIndex = 1,
lmpCcIsIf = false(1),
lmpCcAuthentication = false(1),
lmpCcHelloInterval = 15,
lmpCcHelloIntervalMin = 15,
lmpCcHelloIntervalMax = 1000,
lmpCcHelloDeadInterval = 45,
lmpCcHelloDeadIntervalMin = 45,
lmpCcHelloDeadIntervalMax = 1000,
lmpCcAdminStatus = up(1),
lmpCcRowStatus = createAndGo(4),
lmpCcStorageType = nonVolatile(3)
}
{
lmpCcId = 2,
lmpCcUnderlyingIfIndex = 2,
lmpCcIsIf = false(1),
lmpCcAuthentication = false(1),
lmpCcHelloInterval = 15,
lmpCcHelloIntervalMin = 15,
lmpCcHelloIntervalMax = 1000,
lmpCcHelloDeadInterval = 45,
lmpCcHelloDeadIntervalMin = 45,
lmpCcHelloDeadIntervalMax = 1000,
lmpCcAdminStatus = up(1),
lmpCcRowStatus = createAndGo(4),
lmpCcStorageType = nonVolatile(3)
}
Next, the three data-bearing links are created. For each data-
bearing link, an ifEntry with the same ifIndex needs to be created
beforehand.
In lmpDataLinkTable:
{
ifIndex = 41,
lmpDataLinkAddressType = unknown(0),
lmpDataLinkIpAddr = ’’H,
lmpDataLinkRemoteIpAddress = ’’H,
lmpDataLinkRemoteIfId = 47,
lmpDataLinkRowStatus = createAndGo(4),
lmpDataLinkStorageType = nonVolatile(3)
}
{
ifIndex = 43,
lmpDataLinkAddressType = unknown(0),
lmpDataLinkIpAddr = ’’H,
lmpDataLinkRemoteIpAddress = ’’H,
lmpDataLinkRemoteIfId = 42,
lmpDataLinkRowStatus = createAndGo(4),
lmpDataLinkStorageType = nonVolatile(3)
}
{
ifIndex = 44,
lmpDataLinkAddressType = unknown(0),
lmpDataLinkIpAddr = ’’H,
lmpDataLinkRemoteIpAddress = ’’H,
lmpDataLinkRemoteIfId = 48,
lmpDataLinkRowStatus = createAndGo(4),
lmpDataLinkStorageType = nonVolatile(3)
}
Note that the data-bearing link type (lmpDataLinkType) does
not need to be provisioned as it is automatically populated by the
node. The definition of the protection role (primary or
secondary) for the data-bearing links is stored in the
componentLinkTable of the TE Link MIB module [RFC4220].
Then, a TE link is created as an ifEntry with ifType teLink in
the ifTable.
Once the TE link is created in the ifTable, a TE link entry
is created in the LMP MIB module to specify TE link information
specific to LMP.
In lmpTeLinkTable:
{
ifIndex = 20,
lmpTeLinkVerification = true(2),
lmpTeLinkFaultManagement = true(2),
lmpTeLinkDwdm = false(1),
lmpTeLinkRowStatus = createAndGo(4),
lmpTeLinkStorageType = nonVolatile(3)
}
and in lmpLinkVerificationTable:
{
ifIndex = 20,
lmpLinkVerifyInterval = 100,
lmpLinkVerifyDeadInterval = 300,
lmpLinkVerifyTransportMechanism = j0Trace(3),
lmpLinkVerifyAllLinks = true(2),
lmpLinkVerifyTransmissionRate = 100000,
lmpLinkVerifyWavelength = 0,
lmpLinkVerifyRowStatus = createAndGo(4),
lmpLinkVerifyStorageType = nonVolatile(3)
}
The association between the data-bearing links and the TE links is
stored in the ifStackTable [RFC2863].
In parallel with the entry created in the lmpTeLinkTable, an entry
may be created in the teLinkTable of TE Link MIB module
[RFC4220].
8. Application of the Interfaces Group to LMP
The Interfaces Group [RFC2863] defines generic managed objects for
managing interfaces. This memo contains the media-specific
extensions to the Interfaces Group for managing LMP control channels
that are modeled as interfaces. If the control channel as defined in
the lmpControlChannelTable is modeled as an ifEntry, then the
following definition applies. An lmpControlChannelTable entry is
designated as being represented as an Interfaces MIB ifEntry if the
lmpControlChannelEntry object lmpCcIsIf is set to true (2). In this
case, the control channel SHOULD be modeled as an ifEntry and
provide appropriate interface stacking as defined below.
This memo assumes the interpretation of the Interfaces Group to be
in accordance with [RFC2863], which states that the interfaces table
(ifTable) contains information on the managed resource’s
interfaces and that each sub-layer below the internetwork layer of
a network interface is considered an interface. Since the LMP
interface only carries control traffic, it is considered to be below
the internetwork layer. Thus, the LMP interface may be represented
as an entry in the ifTable. The interrelation of entries in the
ifTable is defined by Interfaces Stack Group defined in [RFC2863].
When LMP control channels are modeled as interfaces, the interface
stack table must appear as follows for the LMP control channel
interfaces:
+----------------------------------------+
| LMP-interface ifType = lmp(227) +
+----------------------------------------+
| Underlying Layer... +
+----------------------------------------+
In the above diagram, "Underlying Layer..." refers to the ifIndex
of any interface type over which the LMP interface will transmit
its traffic. Note that if the underlying layer provides multiple
access to its media (i.e., Ethernet), then it is possible to stack
multiple LMP interfaces on top of this interface in parallel.
Note that it is not a requirement that LMP control channels be
modeled as interfaces. It is acceptable that control channels
simply exist as logical connections between adjacent LMP-capable
nodes. In this case, lmpCcIsIf is set to false(2) and no
corresponding entry is made in the ifTable.
8.1. Support of the LMP Layer by ifTable
Some specific interpretations of ifTable for the LMP layer
follow.
Object Use for the LMP layer.
ifIndex Each LMP interface may be represented by an ifEntry.
ifDescr Description of the LMP interface.
ifType The value that is allocated for LMP is 227.
This number has been assigned by the IANA.
ifSpeed The total bandwidth in bits per second for use by
the LMP layer.
ifPhysAddress Unused.
ifAdminStatus This variable indicates the administrator’s intent
as to whether LMP should be enabled, disabled, or
running in some diagnostic testing mode on this
interface. Also see [RFC2863].
ifOperStatus This value reflects the actual or operational
status of LMP on this interface.
ifLastChange See [RFC2863].
ifInOctets The number of received octets over the interface,
i.e., the number of octets received as LMP
packets.
ifOutOctets The number of transmitted octets over the
interface, i.e., the number of octets transmitted
as LMP packets.
ifInErrors The number of LMP packets dropped due to
uncorrectable errors.
ifInUnknownProtos
The number of received packets discarded during
packet header validation, including packets with
unrecognized label values.
ifOutErrors See [RFC2863].
ifName Textual name (unique on this system) of the
interface or an octet string of zero length.
ifLinkUpDownTrapEnable
Default is disabled (2).
ifConnectorPresent
Set to false (2).
ifHighSpeed See [RFC2863].
ifHCInOctets The 64-bit version of ifInOctets; supported if
required by the compliance statements in [RFC2863].
ifHCOutOctets The 64-bit version of ifOutOctets; supported if
required by the compliance statements in [RFC2863].
ifAlias The nonvolatile ’alias’ name for the interface as
specified by a network manager.
ifCounterDiscontinuityTime
See [RFC2863].
9. LMP MIB Module Definitions
This MIB module IMPORTs objects from [RFC2578], [RFC2579], [RFC2580],
[RFC2863], [RFC4001], and [RFC4220], and it has REFERENCE clauses to
[RFC4204], [RFC4207], [RFC4209], [RFC3471], and [RFC2914].
LMP-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
transmission, Unsigned32, Counter32, TimeTicks
FROM SNMPv2-SMI -- [RFC2578]
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF -- [RFC2580]
TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType,
TimeStamp
FROM SNMPv2-TC -- [RFC2579]
InterfaceIndexOrZero, ifIndex
FROM IF-MIB -- [RFC2863]
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB -- [RFC4001]
teLinkRemoteIpAddr, teLinkIncomingIfId, TeLinkEncodingType
FROM TE-LINK-STD-MIB; -- [RFC4220]
lmpMIB MODULE-IDENTITY
LAST-UPDATED "200601110000Z" -- 11 January 2006
ORGANIZATION "Common Control and Measurement Protocols (CCAMP)
Working Group"
CONTACT-INFO
" Martin Dubuc
Email: dubuc.consulting@sympatico.ca
Thomas D. Nadeau
Email: tnadeau@cisco.com
Jonathan P. Lang
Email: jplang@ieee.org
Evan McGinnis
Email: emcginnis@hammerheadsystems.com"
DESCRIPTION
"Copyright (C) 2006 The Internet Society. This version of
the MIB module is part of RFC 4327; see the RFC itself
for full legal notices.
This MIB module contains managed object definitions for
the Link Management Protocol (LMP) as
defined in ’Link Management Protocol’."
-- Revision history.
REVISION
"200601110000Z" -- 11 January 2006
DESCRIPTION
"Initial version published as RFC 4327"