Network Working Group
Internet-Draft M. Venkatesan
Intended status: Standards Track Kannan KV Sampath
Expires: August, 16, 2011 Aricent
Sam K. Aldrin
Thomas D. Nadeau
Huawei
February, 16, 2011
MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)
draft-vkst-mpls-tp-te-mib-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2011.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Venkatesan, et al. Expires August 2011 [Page 1]
MPLS-TP MIB February 3, 2011
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 Multiprotocol Label
Switching (MPLS) based Transport Profile (TP) extending
MPLS-TE-STD-MIB.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
(PWE3) architectures to support the capabilities and functionalities
of a packet transport network as defined by the ITU-T.
Table of Contents
1. Introduction.................................................2
2. The Internet-Standard Management Framework...................3
3. Overview.....................................................3
3.1. Conventions used in this document.......................3
3.2. Terminology.............................................3
3.3. Acronyms................................................3
4. Motivations..................................................4
5. Feature List.................................................4
6. Brief description of MIB Objects.............................4
6.1. mplsNodeConfigTable....................................5
6.2. mplsNodeIpMapTable.....................................5
6.3. mplsNodeIccMapTable....................................5
6.4. mplsTunnelExtTable.....................................6
7. Example of MPLS-TP tunnel setup..............................6
8. MPLS-TP Tunnel MIB definitions...............................10
9. Security Consideration.......................................23
10. IANA Considerations.........................................24
11. References..................................................24
11.1 Normative References...................................24
11.2 Informative References.................................25
12. Acknowledgments.............................................25
13. Authors' Addresses..........................................25
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 describes managed objects for modeling a
Multiprotocol Label Switching (MPLS) [RFC3031] based transport
profile.
Venkatesan, et al. Expires August 2011 [Page 2]
MPLS-TP MIB February 3, 2011
This MIB module should be used in conjunction with the MPLS traffic
Engineering MIB [RFC3812] and companion document [RFC3813] for
MPLS based traffic engineering configuration and management.
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 BCP 14, RFC2119.
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
RFC3410 [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,
RFC2578, STD 58, RFC2579 and STD58, RFC2580.
3. Overview
3.1 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 RFC-2119 [RFC2119].
3.2 Terminology
This document uses terminology from the MPLS architecture document
[RFC3031], MPLS Traffic Engineering Management information [RFC3812],
MPLS Label Switch Router MIB [RFC3813] and MPLS-TP Identifiers
document [TPIDS].
3.3 Acronyms
GMPLS: Generalized Multi-Protocol Label Switching
ICC: ITU Carrier Code
IP: Internet Protocol
LSP: Label Switching Path
LSR: Label Switching Router
MIB: Management Information Base
MPLS: Multi-Protocol Label Switching
MPLS-TP: MPLS Transport Profile
OSPF: Open Shortest Path First
Venkatesan, et al. Expires August 2011 [Page 3]
MPLS-TP MIB February 3, 2011
PW: Pseudowire
TE: Traffic Engineering
TP: Transport Profile
4. Motivations
The existing MPLS TE and GMPLS MIBs do not provide for the management
of the MPLS-TP tunnels.
5. Feature List
The MPLS transport profile MIB module is designed to satisfy the
following requirements and constraints:
- The MIB module supports point-to-point, co-routed bi-directional,
associated bi-directional MPLS-TP tunnels.
- MPLS-TP tunnels need not be interfaces, but it is possible to
configure a TP tunnel as an interface.
- The mplsTunnelTable to be also used for MPLS-TP tunnels
- The MIB module supports read-only objects related to MPLS-TP
tunnels by extending the mplsTunnelTable of the MPLS-TE-STD-MIB.
- The mplsTunnelTable is extended to support MPLS-TP specific
objects.
- A node configuration table is used to map the GlobalID::NodeId or
ICC-id to the local number to be used in indexing mplsTunnelTable.
- The MIB module supports persistent, as well as non-persistent
tunnels.
6. Brief description of MIB Objects
The objects described in this section support the functionality
described in documents [RFC5654] and [TPIDS]. The tables support
both IP compatible and ICC based tunnel configurations.
6.1. mplsNodeConfigTable
The mplsNodeConfigTable is used to assign a local map number for a
given ICC-id or GlobalID::NodeID combination. An ICC-id is a string
of one to six characters, each character being either alphabetic
(i.e. A-Z) or numeric (i.e. 0-9) characters. Alphabetic characters
in the ICC should be represented with upper case letters. In the IP
compatible mode, Global ID :: Node ID, is used to uniquely identify
a node.
Venkatesan, et al. Expires August 2011 [Page 4]
MPLS-TP MIB February 3, 2011
Each ICC-id or GlobalID::NodeID contains one unique entry in the
table representing a node. Every node is assigned a local map number
within a range of 0 to 16777215. This local map number is used for
indexing into mplsTunnelTable as mplsTunnelIngressLSRId and
mplsTunnelEgressLSRId.
For IP compatible environment, MPLS-TP tunnel is indexed by Tunnel
Index, Tunnel Instance, Source Global ID, Source Node ID,
Destination Global ID and Destination Node ID.
For ICC based environment, MPLS-TP tunnel is indexed by Tunnel
Index, Tunnel Instance, Source ICC Identifier and Destination ICC
identifier.
As mplsTunnelTable is indexed by mplsTunnelIndex,
mplsTunnelInstance, mplsTunnelIngressLSRId, and
mplsTunnelEgressLSRId, the MPLS-TP tunnel identifiers cannot be
used directly.
The mplsNodeConfigTable will be used to store an entry for ICC-id or
GlobalID::Node ID with a local number to be used as LSR ID
in mplsTunnelTable. As the regular TE tunnels use IP address as LSR
ID, the local number should be below the first valid IP address,
which is 16777216 (decimal).
6.2. mplsNodeIpMapTable
The read-only mplsNodeIpMaptable is used to query the local number
assigned and stored in mplsNodeConfigTable for a given
GloablID::NodeID. In order to query the local number, the table is
indexed with GlobalID and NodeID. In the IP compatibility mode for
a TP tunnel, GlobalID and NodeID is used. A query is made to get
the local number for both Ingress or Egress LSR. These local
numbers are used as mplsTunnelIngressLSRId and
mplsTunnelEgressLSRId, while indexing mplsTunnelTable.
6.3. mplsNodeIccMapTable
The read-only mplsNodeIccMapTable is used to query the local number
assigned and stored in the mplsNodeConfigTable for a given ICC-id.
The table is indexed with ICC-id and is used for querying both,
Ingress LSR and Egress LSR local numbers. These local numbers are
used as Ingress mplsTunnelIngressLSRId and mplsTunnelEgressLSRId,
while indexing mplsTunnelTable.
6.4.mplsTunnelExtTable
mplsTunnelTable do not have the objects specific to MPLS-TP tunnel.
Venkatesan, et al. Expires August 2011 [Page 5]
MPLS-TP MIB February 3, 2011
mplsTunnelExtTable extends the mplsTunnelTable to add MPLS-TP tunnel
specific objects. All the attributes specific to TP tunnel are
contained in this extened table and could be accessed with the
mplsTunnelTable indices.
7. Example of MPLS-TP tunnel setup
In this section, we provide an example of the MPLS-TP co-routed
bidirectional tunnel setup. This example provides the usage of
TE Tunnel MIB along with the new MIB table introduced in this
document.
Do note that a MPLS-TP tunnel could be setup statically as well as
signalled via control plane. This example considers configuration
on a head-end LSR to setup a MPLS-TP tunnel. Only relavent objects
which are applicable for MPLS-TP tunnel are illustrated here.
In mplsNodeConfigTable:
{
-- Non-IP Ingress LSR-Id (Index to the table)
mplsNodeConfigLocalNum = 1,
mplsNodeConfigGlobalId = 1234,
mplsNodeConfigNodeId = 10,
-- Mandatory parameters needed to activate the row go here
mplsNodeConfigRowStatus = createAndGo (4)
-- Non-IP Egress LSR-Id (Index to the table)
mplsNodeConfigLocalNum = 2,
mplsNodeConfigGlobalId = 1234,
mplsNodeConfigNodeId = 20,
-- Mandatory parameters needed to activate the row go here
mplsNodeConfigRowStatus = createAndGo (4)
}
This will create an entry in the mplsNodeConfigTable for a
GlobalID::NodeID. A separate entry is made for both Ingress LSR
and Egress LSR.
The following table is used to retrieve the local number for the
given GlobalID and NodeId.
In mplsNodeIpMapTable:
{
-- Global identifier (Index to the table)
mplsNodeIpMapGlobalId = 1234,
-- Node Identifier (Index to the table)
mplsNodeIpMapNodeId = 10,
Venkatesan, et al. Expires August 2011 [Page 6]
MPLS-TP MIB February 3, 2011
mplsNodeIpMapLocalNum = 1
-- Global identifier (Index to the table)
mplsNodeIpMapGlobalId = 1234,
-- Node Identifier (Index to the table)
mplsNodeIpMapNodeId = 20,
mplsNodeIpMapLocalNum = 2
}
The following denotes the configured tunnel "head" entry:
In mplsTunnelTable:
{
mplsTunnelIndex = 1,
mplsTunnelInstance = 0,
-- Local map number created in mplsNodeConfigTable for Ingress
LSR-Id
mplsTunnelIngressLSRId = 1,
-- Local map number created in mplsNodeConfigTable for Egress
LSR-Id
mplsTunnelEgressLSRId = 2,
mplsTunnelName = "My first TP tunnel",
mplsTunnelDescr = "Here to there and back again",
mplsTunnelIsIf = true (1),
-- RowPointer MUST point to the first accessible column
mplsTunnelXCPointer =
mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.12,
mplsTunnelSignallingProto = none (1),
mplsTunnelSetupPrio = 0,
mplsTunnelHoldingPrio = 0,
mplsTunnelSessionAttributes = 0,
mplsTunnelLocalProtectInUse = false (0),
-- RowPointer MUST point to the first accessible column
mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5,
mplsTunnelInstancePriority = 1,
mplsTunnelHopTableIndex = 1,
mplsTunnelIncludeAnyAffinity = 0,
mplsTunnelIncludeAllAffinity = 0,
mplsTunnelExcludeAnyAffinity = 0,
mplsTunnelRole = head (1),
-- Mandatory parameters needed to activate the row go here
mplsTunnelRowStatus = createAndGo (4)
}
Now the TP specific Tunnel parameters are configured in the extended
Tunnel table
In mplsTunnelExtTable:
Venkatesan, et al. Expires August 2011 [Page 7]
MPLS-TP MIB February 3, 2011
{
Index = same as one used for mplsTunnelTable,
-- For co-routed bidirectional tunnel, mplsTunnelExtDestTnlIndex
-- should be same as mplsTunnelIndex i.e one tunnel entry is used
-- for both forward and reverse directions by having the two XC
entries.
-- For associated bidirectional tunnel, mplsTunnelExtDestTnlIndex
-- should be same as reverse mplsTunnelIndex i.e two tunnel
-- entries
-- with single XC entry are created seperately and then associated
-- using the mplsTunnelExtDestTnlIndex object.
mplsTunnelExtDestTnlIndex = 1,
-- This object signifies the tunnel operating mode (IP (0) or
NON-IP (1))
mplsTunnelExtOperMode = 1,
-- This object signifies the tunnel application (mpls (0) or
mpls-tp (1))
mplsTunnelExtTnlApp = 1
}
We must next create the appropriate in-segment and out-segment
entries. These are done in [RFC3813] using the mplsInSegmentTable
and mplsOutSegmentTable. Note that the row status for each row is
set to createAndWait(5) to allow corresponding entries in
the mplsInSegmentExtTable and mplsOutSegmentExtTable to be created.
For the forward direction.
In mplsOutSegmentTable:
{
mplsOutSegmentIndex = 0x00000012,
mplsOutSegmentInterface = 13, -- outgoing interface
mplsOutSegmentPushTopLabel = true(1),
mplsOutSegmentTopLabel = 22, -- outgoing label
-- RowPointer MUST point to the first accessible column.
mplsOutSegmentTrafficParamPtr = 0.0,
mplsOutSegmentRowStatus = createAndWait(5)
}
For the reverse direction.
In mplsInSegmentTable:
{
mplsInSegmentIndex = 0x00000016
mplsInSegmentLabel = 21, -- incoming label
mplsInSegmentNPop = 1,
Venkatesan, et al. Expires August 2011 [Page 8]
MPLS-TP MIB February 3, 2011
mplsInSegmentInterface = 13, -- incoming interface
-- RowPointer MUST point to the first accessible column.
mplsInSegmentTrafficParamPtr = 0.0,
mplsInSegmentRowStatus = createAndWait(5)
}
These table entries are extended by entries in the
mplsInSegmentExtTable and mplsOutSegmentExtTable. Note that the
nature of the 'extends' relationship is a sparse augmentation so
that the entry in the mplsInSegmentExtTable has the same index
values as the entry in the mplsInSegmentTable. Similarly, the
entry in the mplsOutSegmentExtTable has the same index values as
the entry in the mplsOutSegmentTable.
First for the forward direction:
In mplsOutSegmentExtTable(0x00000012)
{
mplsOutSegmentExtDirection = forward(1)
}
Next for the reverse direction:
In mplsInSegmentExtTable(0x00000016)
{
mplsInSegmentExtDirection = reverse(2)
}
Next, two cross-connect entries are created in the mplsXCTable of the
MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created
segments together.
In mplsXCTable:
{
mplsXCIndex = 0x01,
mplsXCInSegmentIndex = 0x00000000,
mplsXCOutSegmentIndex = 0x00000012,
mplsXCLspId = 0x0102 -- unique ID
mplsXCLabelStackIndex = 0x00, -- only a single outgoing label
mplsXCRowStatus = createAndGo(4)
}
In mplsXCTable:
{
mplsXCIndex = 0x02,
mplsXCInSegmentIndex = 0x00000016,
mplsXCOutSegmentIndex = 0x00000000,
mplsXCLspId = 0x0102 -- unique ID
Venkatesan, et al. Expires August 2011 [Page 9]
MPLS-TP MIB February 3, 2011
mplsXCLabelStackIndex = 0x00, -- only a single outgoing label
mplsXCRowStatus = createAndGo(4)
}
Finally, the in-segments and out-segments are activated.
In mplsOutSegmentTable(0x00000012):
{
mplsOutSegmentRowStatus = active(1)
}
In mplsInSegmentTable(0x00000016):
{
mplsInSegmentRowStatus = active(1)
}
8. MPLS-TP Tunnel MIB definitions
MPLS-TE-EXT-STD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Gauge32,
NOTIFICATION-TYPE
FROM SNMPv2-SMI -- [RFC2578]
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF -- [RFC2580]
RowStatus, DisplayString, TruthValue
FROM SNMPv2-TC -- [RFC2579]
mplsStdMIB, MplsTunnelIndex
FROM MPLS-TC-STD-MIB -- [RFC3811]
mplsTunnelEntry
FROM MPLS-TE-STD-MIB -- [RFC3812]
;
mplsTeExtStdMIB MODULE-IDENTITY
LAST-UPDATED
"201102160000Z" -- February 16, 2011
ORGANIZATION
"Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO
"
Venkatesan Mahalingam
Aricent,
India
Email: venkatesan.mahalingam@aricent.com
Kannan KV Sampath
Aricent,
India
Venkatesan, et al. Expires August 2011 [Page 10]
MPLS-TP MIB February 3, 2011
Email: Kannan.Sampath@aricent.com
Sam Aldrin
Huawei Technologies, co.
2330 Central Express Way,
Santa Clara, CA 95051, USA
Email: aldrin.ietf@gmail.com
Thomas D. Nadeau
Huawei
Email: tnadeau@lucidvision.com
"
DESCRIPTION
"Copyright (c) 2011 IETF Trust and the persons identified
as the document authors. All rights reserved.
This MIB module contains generic object definitions for
MPLS Traffic Engineering in transport networks."
-- Revision history.
REVISION
"201102160000Z" -- February 16, 2011
DESCRIPTION
"MPLS-TP specific mib objects extension"
::= { mplsStdMIB xxx } -- xxx to be replaced with correct value
-- Top level components of this MIB module.
-- traps
mplsTeExtNotifications OBJECT IDENTIFIER ::= { mplsTeExtStdMIB 0 }
-- tables, scalars
mplsTeExtScalars OBJECT IDENTIFIER ::= { mplsTeExtStdMIB 1 }
mplsTeExtObjects OBJECT IDENTIFIER ::= { mplsTeExtStdMIB 2 }
-- conformance
mplsTeExtConformance OBJECT IDENTIFIER ::= { mplsTeExtStdMIB 3 }
-- MPLS Tunnel Extension scalars.
mplsGlobalId OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object allows the administrator to assign a unique
operator identifier also called MPLS-TP Global
Identifier.
Venkatesan, et al. Expires August 2011 [Page 11]
MPLS-TP MIB February 3, 2011
The Global Identifier can contain the 2-octet or
4-octet value of the operator's Autonomous System
Number (ASN)."
REFERENCE
"MPLS-TP Identifiers draft version 03, Section 3.1"
::= { mplsTeExtScalars 1 }
mplsIcc OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..6))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object allows the operator or service provider to
assign a unique MPLS-TP ITU-T Carrier Code (ICC) to a
network.
The ICC is a string of one to six characters, each
character being either alphabetic (i.e. A-Z) or
numeric (i.e. 0-9) characters. Alphabetic characters in
the ICC should be represented with upper case letters."
REFERENCE
"MPLS-TP Identifiers draft version 03, Section 3.2"
::= { mplsTeExtScalars 2 }
mplsNodeId OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object allows the operator or service provider to
assign a unique MPLS-TP Node Identifier.
The Node Identifier is assigned within the scope of the
Global Identifier or Operator Identifier.
The value 0(or 0.0.0.0 in dotted decimal notation) is
reserved and MUST NOT be used.
When IPv4 addresses are in use, the value of this object
can be derived from the LSR's /32 IPv4 loopback address.
Note that, when IP reachability is not needed, the 32-bit
Node Identifier is not required to have any association
with the IPv4 address space."
REFERENCE
"MPLS-TP Identifiers draft version 03, Section 4"
::= { mplsTeExtScalars 3 }
Venkatesan, et al. Expires August 2011 [Page 12]
MPLS-TP MIB February 3, 2011
mplsTpTunnelsConfigured OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of MPLS-TP tunnels configured on this device.
A MPLS-TP tunnel is considered configured if an entry for
the tunnel exists in the mplsTunnelExtTable and the
associated mplsTunnelRowStatus is active(1)."
::= { mplsTeExtScalars 4 }
mplsTpTunnelsActive OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of MPLS-TP tunnels active on this device. A
MPLS-TP tunnel is considered active if there is an entry
in the mplsTunnelExtTable and the associated
mplsTunnelOperStatus for the tunnel is up(1)."
::= { mplsTeExtScalars 5 }
-- End of MPLS Tunnel Extension scalars.
-- Start of MPLS Transport Profile Node configuration table
mplsNodeConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsNodeConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table allows the administrator to map a node or LSR
with an operator or service provider."
::= { mplsTeExtObjects 1 }
mplsNodeConfigEntry OBJECT-TYPE
SYNTAX MplsNodeConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table represents a mapping identification
for the operator or service provider with node or LSR.
As per [TPIDS], this mapping is
represented as Global_ID::Node_ID.
Note: Each entry in this table should have a unique global
ID and Node ID combination."
INDEX { mplsNodeConfigLocalNum }
Venkatesan, et al. Expires August 2011 [Page 13]
MPLS-TP MIB February 3, 2011
::= { mplsNodeConfigTable 1 }
MplsNodeConfigEntry ::= SEQUENCE {
mplsNodeConfigLocalNum Unsigned32,
mplsNodeConfigGlobalId Unsigned32,
mplsNodeConfigNodeId Unsigned32,
mplsNodeConfigIccId DisplayString,
mplsNodeConfigRowStatus RowStatus
}
mplsNodeConfigLocalNum OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object allows the administrator to assign a unique
identifier to map operator or global identifier and node
identifier."
::= { mplsNodeConfigEntry 1 }
mplsNodeConfigGlobalId OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object Indicates the Global Operator Identifier.
This object identifies an operator."
::= { mplsNodeConfigEntry 2 }
mplsNodeConfigNodeId OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates the node identifier within the
operator."
::= { mplsNodeConfigEntry 3 }
mplsNodeConfigIccId OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..6))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object allows the operator or service provider to
configure a unique MPLS-TP ITU-T Carrier Code (ICC)
either for Ingress ID or Egress ID.
The ICC is a string of one to six characters, each
character being either alphabetic (i.e. A-Z) or
Venkatesan, et al. Expires August 2011 [Page 14]
MPLS-TP MIB February 3, 2011
numeric (i.e. 0-9) characters. Alphabetic characters in
the ICC should be represented with upper case letters."
REFERENCE
"MPLS-TP Identifiers draft version 03, Section 3.2"
::= { mplsNodeConfigEntry 4 }
mplsNodeConfigRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object allows the administrator to create, modify,
and/or delete a row in this table."
::= { mplsNodeConfigEntry 5 }
-- End MPLS Transport Profile Node Map table
-- Start of MPLS Transport Profile Node IP compatible mapping table
mplsNodeIpMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsNodeIpMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This read-only table allows the administrator to retrieve
the local number for a given GlobalID and Node Id in an IP
compatible operator environement."
::= { mplsTeExtObjects 2 }
mplsNodeIpMapEntry OBJECT-TYPE
SYNTAX MplsNodeIpMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table represents a mapping identification
for the operator or service provider with node or LSR.
As per [TPIDS], this mapping is
represented as Global_ID::Node_ID.
Note: Each entry in this table should have a unique global
ID and Node ID combination."
INDEX { mplsNodeIpMapGlobalId,
mplsNodeIpMapNodeId
}
::= { mplsNodeIpMapTable 1 }
MplsNodeIpMapEntry ::= SEQUENCE {
mplsNodeIpMapGlobalId Unsigned32,
Venkatesan, et al. Expires August 2011 [Page 15]
MPLS-TP MIB February 3, 2011
mplsNodeIpMapNodeId Unsigned32,
mplsNodeIpMapLocalNum Unsigned32
}
mplsNodeIpMapGlobalId OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object Indicates the Global Operator Identifier.
This object identifies an operator."
::= { mplsNodeIpMapEntry 1 }
mplsNodeIpMapNodeId OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the node identifier within the
operator."
::= { mplsNodeIpMapEntry 2 }
mplsNodeIpMapLocalNum OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object allows the administrator to assign a unique
identifier to
map operator or global identifier and node identifier."
::= { mplsNodeIpMapEntry 3 }
-- End MPLS Transport Profile Node IP compatible table
-- Start of MPLS Transport Profile Node ICC based table
mplsNodeIccMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsNodeIccMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This read-only table allows the administrator to retrieve
the local number for a given ICC operator in an ICC
operator environment."
::= { mplsTeExtObjects 3 }
mplsNodeIccMapEntry OBJECT-TYPE
SYNTAX MplsNodeIccMapEntry
MAX-ACCESS not-accessible
Venkatesan, et al. Expires August 2011 [Page 16]
MPLS-TP MIB February 3, 2011
STATUS current
DESCRIPTION
"An entry in this table represents a mapping identification
for the operator or service provider with node or LSR.
As per [TPIDS], this mapping is
represented as ICC identifier. "
INDEX { mplsNodeIccMapIccId }
::= { mplsNodeIccMapTable 1 }
MplsNodeIccMapEntry ::= SEQUENCE {
mplsNodeIccMapIccId DisplayString,
mplsNodeIccMapLocalNum Unsigned32
}
mplsNodeIccMapIccId OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..6))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object allows the operator or service provider to
configure a unique MPLS-TP ITU-T Carrier Code (ICC)
either for Ingress ID or Egress ID.
The ICC is a string of one to six characters, each
character being either alphabetic (i.e. A-Z) or
numeric (i.e. 0-9) characters. Alphabetic characters in
the ICC should be represented with upper case letters."
REFERENCE
"MPLS-TP Identifiers draft version 03, Section 3.2"
::= { mplsNodeIccMapEntry 1 }
mplsNodeIccMapLocalNum OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object allows the administrator to assign a unique
identifier to map the ICC identifier."
::= { mplsNodeIccMapEntry 2 }
-- End MPLS Transport Profile Node ICC based table
-- Start of MPLS-TP Tunnel table
mplsTunnelExtTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsTunnelExtEntry
MAX-ACCESS not-accessible
STATUS current
Venkatesan, et al. Expires August 2011 [Page 17]
MPLS-TP MIB February 3, 2011
DESCRIPTION
"This table represents MPLS-TP specific extensions to
mplsTunnelTable.
As per MPLS-TP Identifiers draft, LSP_ID is
Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::
Dst-Tunnel_Num::LSP_Num for IP operator and
Src-ICC::Src-Tunnel_Num::Dst-ICC::Dst-Tunnel_Num::LSP_Num
for ICC operator,
mplsTunnelTable is reused for forming the LSP_ID as follows,
Source Tunnel_Num is mapped with mplsTunnelIndex,
Source node identifier is mapped with
mplsTunnelIngressLSRId, Destination node identifier is
mapped with mplsTunnelEgressLSRId LSP_Num is mapped with
mplsTunnelInstance.
Source Global identifier/ICC and Destination
Global identifier/ICC are maintained in the
mplsNodeConfigTable and mplsNodeConfigLocalNum is used to
create an entry in mplsTunnelTable."
REFERENCE
"MPLS-TP Identifiers draft version 03, section 5.2"
::= { mplsTeExtObjects 4 }
mplsTunnelExtEntry OBJECT-TYPE
SYNTAX MplsTunnelExtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table represents MPLS-TP
specific tunnel configurations."
AUGMENTS { mplsTunnelEntry }
::= { mplsTunnelExtTable 1 }
MplsTunnelExtEntry ::= SEQUENCE {
mplsTunnelExtDestTnlIndex MplsTunnelIndex,
mplsTunnelExtOperMode INTEGER,
mplsTunnelExtTnlApp INTEGER
}
mplsTunnelExtDestTnlIndex OBJECT-TYPE
SYNTAX MplsTunnelIndex
MAX-ACCESS read-create
STATUS current
DESCRIPTION
Venkatesan, et al. Expires August 2011 [Page 18]
MPLS-TP MIB February 3, 2011
"This object allows the administrator to configure the tunnel
index of the reverse tunnel.
For co-routed bidirectional tunnel, this object will have
the value same as the object mplsTunnelIndex.
This object helps to associate a forward tunnel with the
reverse tunnel in case of associated bidirectional tunnel."
::= { mplsTunnelExtEntry 1 }
mplsTunnelExtOperMode OBJECT-TYPE
SYNTAX INTEGER {
ipMode (0),
nonIpMode (1)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object allows the administrator to configure the tunnel
operating environment (IP or NON-IP).
This object helps to identify the tunnel source and
destination identifiers (IP address or local map number)."
DEFVAL { ipMode }
::= { mplsTunnelExtEntry 2 }
mplsTunnelExtTnlApp OBJECT-TYPE
SYNTAX INTEGER {
mpls (0),
mplsTp (1)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object allows the administrator to configure the tunnel
application (mpls or mpls-tp)."
DEFVAL { mpls }
::= { mplsTunnelExtEntry 3 }
-- End of MPLS-TP Tunnel table
-- Notifications.
mplsTunnelExtNotifEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If this object is true, then it enables the
Venkatesan, et al. Expires August 2011 [Page 19]
MPLS-TP MIB February 3, 2011
generation of mplsTunnelExtOperMode
trap, otherwise these traps are not emitted."
DEFVAL { false }
::= { mplsTeExtObjects 5 }
mplsTunnelExtOperEnv NOTIFICATION-TYPE
OBJECTS { mplsTunnelExtOperMode }
STATUS current
DESCRIPTION
"This notification is generated when a
operating environment (IP/ICC) for the tunnel
is configured."
::= { mplsTeExtNotifications 1 }
-- End of notifications.
-- Module compliance.
mplsTeExtGroups
OBJECT IDENTIFIER ::= { mplsTeExtConformance 1 }
mplsTeExtCompliances
OBJECT IDENTIFIER ::= { mplsTeExtConformance 2 }
-- Compliance requirement for fully compliant implementations.
mplsTeExtModuleFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for agents that provide full
support the MPLS-TE-EXT-STD-MIB module."
MODULE -- this module
-- The mandatory group has to be implemented by all
-- LSRs that originate/terminate MPLS-TP tunnels.
-- In addition, depending on the type of tunnels
-- supported, other groups become mandatory as
-- explained below.
MANDATORY-GROUPS {
mplsTunnelExtGroup,
mplsTunnelExtScalarGroup
}
GROUP mplsTunnelIpOperatorGroup
DESCRIPTION
"This group is mandatory for devices which support
configuration of IP based identifier tunnels."
Venkatesan, et al. Expires August 2011 [Page 20]
MPLS-TP MIB February 3, 2011
GROUP mplsTunnelIccOperatorGroup
DESCRIPTION
"This group is mandatory for devices which support
configuration of ICC based identifier tunnels."
GROUP mplsTeExtNotificationGroup
DESCRIPTION
"This group is mandatory for those implementations
which can implement the notifications
contained in this group."
::= { mplsTeExtCompliances 1 }
-- Compliance requirement for read-only implementations.
mplsTeExtModuleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for agents that provide full
support the MPLS-TE-EXT-STD-MIB module."
MODULE -- this module
-- The mandatory group has to be implemented by all
-- LSRs that originate/terminate MPLS-TP tunnels.
-- In addition, depending on the type of tunnels
-- supported, other groups become mandatory as
-- explained below.
MANDATORY-GROUPS {
mplsTunnelExtGroup,
mplsTunnelExtScalarGroup
}
GROUP mplsTunnelIpOperatorGroup
DESCRIPTION
"This group is mandatory for devices which support
configuration of IP based identifier tunnels."
GROUP mplsTunnelIccOperatorGroup
DESCRIPTION
"This group is mandatory for devices which support
configuration of ICC based identifier tunnels."
GROUP mplsTeExtNotificationGroup
DESCRIPTION
"This group is mandatory for those implementations
which can implement the notifications
Venkatesan, et al. Expires August 2011 [Page 21]
MPLS-TP MIB February 3, 2011
contained in this group."
::= { mplsTeExtCompliances 2 }
-- Units of conformance.
mplsTunnelExtGroup OBJECT-GROUP
OBJECTS {
mplsTunnelExtDestTnlIndex,
mplsTunnelExtOperMode,
mplsTunnelExtTnlApp,
mplsTunnelExtNotifEnable
}
STATUS current
DESCRIPTION
"Necessary, but not sufficient, set of objects to
implement tunnels. In addition, depending on the
operating environement, the following groups are
mandatory."
::= { mplsTeExtGroups 1 }
mplsTunnelIpOperatorGroup OBJECT-GROUP
OBJECTS { mplsNodeConfigGlobalId,
mplsNodeConfigNodeId,
mplsNodeConfigRowStatus,
mplsNodeIpMapLocalNum
}
STATUS current
DESCRIPTION
"Object(s) needed to implement IP compatible tunnels."
::= { mplsTeExtGroups 2 }
mplsTunnelIccOperatorGroup OBJECT-GROUP
OBJECTS { mplsNodeConfigIccId,
mplsNodeConfigRowStatus,
mplsNodeIccMapLocalNum
}
STATUS current
DESCRIPTION
"Object(s) needed to implement ICC based tunnels."
::= { mplsTeExtGroups 3 }
mplsTunnelExtScalarGroup OBJECT-GROUP
OBJECTS {
mplsGlobalId,
mplsIcc,
mplsNodeId,
mplsTpTunnelsConfigured,
mplsTpTunnelsActive
Venkatesan, et al. Expires August 2011 [Page 22]
MPLS-TP MIB February 3, 2011
}
STATUS current
DESCRIPTION
"Scalar object needed to implement MPLS-TP tunnels."
::= { mplsTeExtGroups 4 }
mplsTeExtNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { mplsTunnelExtOperEnv }
STATUS current
DESCRIPTION
"Set of notifications implemented in this module.
None is mandatory."
::= { mplsTeExtGroups 5 }
END
9. Security Consideration
There is a number of management objects defined in this MIB module
that has a MAX-ACCESS clause of read-write.. Such objects may be
considered sensitive or vulnerable in some network environments. The
support for SET operations in a non-secure environment without proper
protection can have a negative effect on network operations.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. 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. These are the tables and objects and their
sensitivity/vulnerability:
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 supports 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 principles (users) that have legitimate
Venkatesan, et al. Expires August 2011 [Page 23]
MPLS-TP MIB February 3, 2011
rights to indeed GET or SET (change/create/delete) them.
10. IANA Considerations
To be added in a later version of this document.
11. References
11.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.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
11.2 Informative References
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, June
2004.
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching
(LSR) Router Management Information Base (MIB)", RFC 3813,
June 2004.
[RFC3410] J. Case, R. Mundy, D. pertain, B.Stewart, "Introduction
and Applicability Statement for Internet Standard
Management Framework", RFC 3410, December 2002.
[RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of
Textual Conventions (TCs) for Multiprotocol Label
Venkatesan, et al. Expires August 2011 [Page 24]
MPLS-TP MIB February 3, 2011
Switching (MPLS) Management", RFC 3811, June 2004.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, September 2009.
[TPIDS] M. Bocci, et al, "MPLS-TP Identifiers",
draft-ietf-mpls-tp-identifiers-03, October 25, 2010
12. Acknowledgments
To be added in a later version of this document.
13. Authors' Addresses
Sam Aldrin
Huawei Technologies, co.
2330 Central Express Way,
Santa Clara, CA 95051, USA
Email: aldrin.ietf@gmail.com
Thomas D. Nadeau
Huawei
Email: tnadeau@lucidvision.com
Venkatesan Mahalingam
Aricent
India
Email: venkatesan.mahalingam@aricent.com
Kannan KV Sampath
Aricent
India
Email: Kannan.Sampath@aricent.com
Venkatesan, et al. Expires August 2011 [Page 25]
