MPLS-TP Operations, Administration, and Management (OAM) Identifiers Management Information Base (MIB)
draft-ietf-mpls-tp-oam-id-mib-09
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7697.
|
|
|---|---|---|---|
| Authors | Sam Aldrin , Venkatesan Mahalingam , Kannan KV Sampath , Thomas Nadeau | ||
| Last updated | 2015-09-03 (Latest revision 2015-09-01) | ||
| Replaces | draft-vkst-mpls-tp-oam-id-mib | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-08)
by Peter Yee
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Associated WG milestone |
|
||
| Document shepherd | Mach Chen | ||
| Shepherd write-up | Show Last changed 2015-08-27 | ||
| IESG | IESG state | Became RFC 7697 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass. |
||
| Responsible AD | Deborah Brungard | ||
| Send notices to | mach@huawei.com, mpls-chairs@ietf.org, draft-ietf-mpls-tp-oam-id-mib.ad@ietf.org, draft-ietf-mpls-tp-oam-id-mib@ietf.org, draft-ietf-mpls-tp-oam-id-mib.shepherd@ietf.org | ||
| IANA | IANA review state | IANA - Not OK |
draft-ietf-mpls-tp-oam-id-mib-09
Network Working Group
INTERNET-DRAFT Sam Aldrin
Intended Status: Standards Track Google, Inc.
Expires: March 1, 2016 M.Venkatesan
Dell, Inc.
Kannan KV Sampath
Redeem
Thomas D. Nadeau
Brocade
September 1, 2015
MPLS-TP Operations, Administration, and Management (OAM) Identifiers
Management Information Base (MIB)
draft-ietf-mpls-tp-oam-id-mib-09
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 to configure the
Operations, Administration, and Management (OAM) identifiers for
Multiprotocol Label Switching (MPLS) and MPLS-based Transport Profile
(TP).
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 March 4, 2016.
Aldrin, et al. Expires March 4, 2016 [Page 1]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
Copyright and License Notice
Copyright (c) 2015 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.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Feature List . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Brief description of MIB Objects . . . . . . . . . . . . . . . 4
5.1. mplsOamIdMegTable . . . . . . . . . . . . . . . . . . . . 4
5.2. mplsOamIdMeTable . . . . . . . . . . . . . . . . . . . . . 5
6. MPLS OAM identifier configuration for MPLS LSP example . . . . 5
7. MPLS OAM Identifiers MIB definitions . . . . . . . . . . . . . 6
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1 Normative References . . . . . . . . . . . . . . . . . . . 28
10.2 Informative References . . . . . . . . . . . . . . . . . . 29
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
Aldrin, et al. Expires March 4, 2016 [Page 2]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
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.
This MIB module should be used for performing the OAM (Operations,
Administration, and Maintenance) operations for MPLS Tunnel LSP
(Label Switched Path), Pseudowires, and Sections.
At the time of writing, SNMP SET is no longer recommended as a way to
configure MPLS networks as was described in [RFC3812]. However,
since the MIB modules specified in this document are intended to work
in parallel with the MIB modules for MPLS specified in [RFC3812],
certain objects defined here are specified with MAX-ACCESS of read-
write or read-create so that specifications of the base tables in
[RFC3812] and the new MIB modules in this document are consistent.
Although the examples described in Section 6 specify means to
configure OAM identifiers for MPLS-TP tunnels, this should be seen as
indicating how the MIB values would be returned in the specified
circumstances having been configured by alternative means.
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 with the SMIv2, which is described in STD
58(RFC2578, RFC2579, RFC2580).
3. Overview
3.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT" (Section 5.2.1 of this document).
Assume that the target SSP has offered, as part of its SED, to share
one or more Ingress Routes and that the originating SSP has accepted
the offer. In order to add the Egress Route to the Registry, the
originating SSP uses a valid regular expression to rewrite the
Ingress Route in order to include the egress SBE information. Also,
more than one Egress Route can be associated with a given Ingress
Route in support of fault-tolerant configurations. The supporting
SPPF structure provides a way to include route precedence information
to help manage traffic to more than one outbound egress SBE.
The substrate protocol MUST support the ability to Add, Get, and
Delete Egress Routes (refer to Section 7 for a generic description of
various operations). The EgrRteType object structure is defined as
follows:
<complexType name="EgrRteType">
<complexContent>
<extension base="sppfb:BasicObjType">
<sequence>
<element name="egrRteName" type="sppfb:ObjNameType"/>
<element name="pref" type="unsignedShort"/>
<element name="regxRewriteRule" type="sppfb:RegexParamType"/>
<element name="ingrSedGrp" type="sppfb:ObjKeyType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Cartwright, et al. Standards Track [Page 35]
RFC 7877 SSPF August 2016
The EgrRteType object is composed of the following elements:
o base: All first-class objects extend BasicObjType (see
Section 5.1).
o egrRteName: The name of the Egress Route.
o pref: The preference of this Egress Route relative to other Egress
Routes that may get selected when responding to a resolution
request.
o regxRewriteRule: The regular expression rewrite rule that should
be applied to the regular expression of the ingress NAPTR(s) that
belongs to the Ingress Route.
o ingrSedGrp: The ingress SED Group that the Egress Route should be
used for.
o svcs: ENUM service(s) that is served by an Egress Route. This
element is used to identify the ingress NAPTRs associated with the
SED Group to which an Egress Route's regxRewriteRule should be
applied. If no ENUM service(s) is associated with an Egress
Route, then the Egress Route's regxRewriteRule should be applied
to all the NAPTRs associated with the SED Group. This field's
value must be of the form specified in [RFC6116] (e.g.,
E2U+pstn:sip+sip). The allowable values are a matter of policy
and are not limited by this protocol.
o ext: Point of extensibility described in Section 3.3.
7. Framework Operations
In addition to the operation-specific object types, all operations
MAY specify the minor version of the protocol that when used in
conjunction with the major version (which can be, for instance,
specified in the protocol Namespace) can serve to identify the
version of the SPPF protocol that the client is using. If the minor
version is not specified, the latest minor version supported by the
SPPF server for the given major version will be used. Additionally,
operations that may potentially modify persistent protocol objects
SHOULD include a transaction ID as well.
Cartwright, et al. Standards Track [Page 36]
RFC 7877 SSPF August 2016
7.1. Add Operation
Any conforming substrate "protocol" specification MUST provide a
definition for the operation that adds one or more SPPF objects into
the Registry. If the object, as identified by the request attributes
that form part of the object's key, does not exist, then the Registry
MUST create the object. If the object does exist, then the Registry
MUST replace the current properties of the object with the properties
passed in as part of the Add operation.
Note that this effectively allows modification of a preexisting
object.
If the entity that issued the command is not authorized to perform
this operation, an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types"
(Section 5.3 of this document).
7.2. Delete Operation
Any conforming substrate "protocol" specification MUST provide a
definition for the operation that deletes one or more SPPF objects
from the Registry using the object's key.
If the entity that issued the command is not authorized to perform
this operation, an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types"
(Section 5.3 of this document).
When an object is deleted, any references to that object must of
course also be removed as the SPPF server implementation fulfills the
deletion request. Furthermore, the deletion of a composite object
must also result in the deletion of the objects it contains. As a
result, the following rules apply to the deletion of SPPF object
types:
o Destination Groups: When a Destination Group is deleted, any
cross-references between that destination group and any SED Group
must be automatically removed by the SPPF implementation as part
of fulfilling the deletion request. Similarly, any cross-
references between that Destination Group and any Public
Identifier must be removed by the SPPF implementation.
o SED Groups: When a SED Group is deleted, any references between
that SED Group and any Destination Group must be automatically
removed by the SPPF implementation as part of fulfilling the
deletion request. Similarly, any cross-references between that
SED Group and any SED Records must be removed by the SPPF
Cartwright, et al. Standards Track [Page 37]
RFC 7877 SSPF August 2016
implementation as part of fulfilling the deletion request.
Furthermore, SED Group Offers relating to that SED Group must also
be deleted.
o SED Records: When a SED Record is deleted, any cross-references
between that SED Record and any SED Group must be removed by the
SPPF implementation as part of fulfilling the deletion request.
Similarly, any reference between that SED Record and any Public
Identifier must be removed by the SPPF implementation.
o Public Identifiers: When a Public Identifier is deleted, any
cross-references between that Public Identifier and any referenced
Destination Group must be removed by the SPPF implementation as
part of fulfilling the deletion request. Any references to SED
Records associated directly to that Public Identifier must also be
deleted by the SPPF implementation.
Deletes MUST be atomic.
7.3. Get Operations
At times, on behalf of the Registrant, the Registrar may need to get
information about SPPF objects that were previously provisioned in
the Registry. A few examples include logging, auditing, and pre-
provisioning dependency checking. This query mechanism is limited to
aid provisioning scenarios and should not be confused with query
protocols provided as part of the resolution system (e.g., ENUM and
SIP).
Any conforming "protocol" specification MUST provide a definition for
the operation that queries the details of one or more SPPF objects
from the Registry using the object's key. If the entity that issued
the command is not authorized to perform this operation, an
appropriate error message MUST be returned from among the response
messages defined in Section 5.3.
If the response to the Get operation includes an object(s) that
extends the BasicObjType, the Registry MUST include the "cDate" and
"mDate", if applicable.
7.4. Accept Operations
In SPPF, a SED Group Offer can be accepted or rejected by, or on
behalf of, the Registrant to which the SED Group has been offered
(refer to Section 6.5 of this document for a description of the SED
Group Offer object). The Accept operation is used to accept the SED
Group Offers. Any conforming substrate "protocol" specification MUST
provide a definition for the operation to accept SED Group Offers by,
Cartwright, et al. Standards Track [Page 38]
RFC 7877 SSPF August 2016
or on behalf of, the Registrant, using the SED Group Offer object
key.
Not until access to a SED Group has been offered and accepted will
the Registrant's organization ID be included in the peeringOrg list
in that SED Group object, and that SED Group's peering information
becomes a candidate for inclusion in the responses to the resolution
requests submitted by that Registrant. A SED Group Offer that is in
the "offered" status is accepted by, or on behalf of, the Registrant
to which it has been offered. When the SED Group Offer is accepted,
the SED Group Offer is moved to the "accepted" status and the data
recipient's organization ID is added into the list of peerOrgIds for
that SED Group.
If the entity that issued the command is not authorized to perform
this operation, an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types"
(Section 5.3 of this document).
7.5. Reject Operations
In SPPF, a SED Group Offer object can be accepted or rejected by, or
on behalf of, the Registrant to which the SED Group has been offered
(refer to "Framework Data Model Objects", Section 6 of this document,
for a description of the SED Group Offer object). Furthermore, that
offer may be rejected, regardless of whether or not it has been
previously accepted. The Reject operation is used to reject the SED
Group Offer. When the SED Group Offer is rejected, that SED Group
Offer is deleted, and, if appropriate, the data recipient's
organization ID is removed from the list of peeringOrg IDs for that
SED Group. Any conforming substrate "protocol" specification MUST
provide a definition for the operation to reject SED Group Offers by,
or on behalf of, the Registrant, using the SED Group Offer object
key.
If the entity that issued the command is not authorized to perform
this operation, an appropriate error message MUST be returned from
among the response messages defined in "Response Message Types"
(Section 5.3 of this document).
7.6. Get Server Details Operation
In SPPF, the Get Server Details operation can be used to request
certain details about the SPPF server that include the SPPF server's
current status and the major/minor version of the SPPF protocol
supported by the SPPF server.
Cartwright, et al. Standards Track [Page 39]
quot;, "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
3.2 Terminology
Aldrin, et al. Expires March 4, 2016 [Page 3]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
This document uses terminology from the Multiprotocol Label Switching
Architecture [RFC3031], MPLS Traffic Engineering (TE) MIB [RFC3812],
MPLS Label Switching Router (LSR) MIB [RFC3813], OAM Framework for
MPLS-Based Transport Networks [RFC6371], MPLS Transport Profile
(MPLS-TP) Identifiers [RFC6370], MPLS-TP Identifiers Following ITU-T
Conventions [RFC6923], and OAM in MPLS Transport Networks [RFC5860].
3.3 Acronyms
BFD: Bidirectional Forwarding Detection
ICC: ITU Carrier Code
IP: Internet Protocol
LSP: Label Switched Path
LSR: Label Switching Router
MIB: Management Information Base
ME: Maintenance Entity
MEG: Maintenance Entity Group
MEP: Maintenance Entity Group End Point
MIP: Maintenance Entity Group Intermediate Point
MPLS: Multi-Protocol Label Switching
MPLS-TP: MPLS Transport Profile
PW: Pseudowire
TE: Traffic Engineering
TP: Transport Profile
4. Feature List
The MPLS transport profile OAM identifiers MIB module is designed
to satisfy the following requirements and constraints:
- The MIB module supports configuration of OAM identifiers for
MPLS point-to-point Tunnels, point-to-multipoint LSPs, co-
routed bidirectional LSPs, associated bidirectional LSPs, and
Pseudowires.
5. Brief description of MIB Objects
The objects described in this section support the functionality
described in documents [RFC5654] and [RFC6370]. The tables support
both IP-compatible and ICC-based OAM identifiers configurations
for MPLS Tunnels, LSPs, and Pseudowires.
5.1. mplsOamIdMegTable
The mplsOamIdMegTable is used to manage one or more
Maintenance Entities (MEs) that belong to the same transport path.
Aldrin, et al. Expires March 4, 2016 [Page 4]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
When a new entry is created with mplsOamIdMegOperatorType set to
ipCompatible (1), then as per [RFC6370] (MEG_ID for LSP
is LSP_ID and MEG_ID for PW is PW_Path_ID), MEP_ID can be
automatically formed.
For ICC-based transport path, the user is expected to configure
the ICC identifier explicitly in this table for MPLS Tunnels, LSPs,
and Pseudowires.
5.2. mplsOamIdMeTable
The mplsOamIdMeTable defines a relationship between two points
(source and sink) of a transport path to which maintenance and
monitoring operations apply. The two points that define
a maintenance entity are called Maintenance Entity Group
End Points (MEPs).
In between MEPs, there are zero or more intermediate points,
called Maintenance Entity Group Intermediate Points (MIPs).
MEPs and MIPs are associated with the MEG and can be shared by
more than one ME in a MEG.
6. MPLS OAM identifier configuration for MPLS LSP example
In this section, we provide an example of the OAM identifier
configuration for an MPLS co-routed bidirectional LSP.
This example provides usage of MEG and ME tables for management and
monitoring operations of an MPLS LSP.
This example considers the OAM identifiers configuration on a
head-end LSR to manage and monitor an MPLS LSP.
Only relevant objects which are applicable for IP-based OAM
identifiers of MPLS co-routed bidirectional LSP are illustrated here.
In mplsOamIdMegTable:
{
-- MEG index (Index to the table)
mplsOamIdMegIndex = 1,
mplsOamIdMegName = "MEG1",
mplsOamIdMegOperatorType = ipCompatible (1),
mplsOamIdMegServicePointerType = lsp (1),
mplsOamIdMegMpLocation = perNode(1),
-- Mandatory parameters needed to activate the row go here
Aldrin, et al. Expires March 4, 2016 [Page 5]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
mplsOamIdMegRowStatus = createAndGo (4),
mplsOamIdMegPathFlow
= coRoutedBidirectionalPointToPoint (2)
}
This will create an entry in the mplsOamIdMegTable to manage and
monitor the MPLS tunnel.
The following ME table is used to associate the path information
to a MEG.
In mplsOamIdMeTable:
{
-- ME index (Index to the table)
mplsOamIdMeIndex = 1,
-- MP index (Index to the table)
mplsOamIdMeMpIndex = 1,
mplsOamIdMeName = "ME1",
mplsOamIdMeMpIfIndex = 0,
-- Source MEP id is derived from the IP-compatible MPLS LSP
mplsOamIdMeSourceMepIndex = 0,
-- Sink MEP id is derived from the IP-compatible MPLS LSP
mplsOamIdMeSinkMepIndex = 0,
mplsOamIdMeMpType = mep (1),
mplsOamIdMeMepDirection = down (2),
-- RowPointer MUST point to the first accessible column of an
-- MPLS LSP
mplsOamIdMeServicePointer = mplsTunnelName.1.1.10.20,
-- Mandatory parameters needed to activate the row go here
mplsOamIdMeRowStatus = createAndGo (4)
}
7. MPLS OAM Identifiers MIB definitions
MPLS-OAM-ID-STD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Unsigned32
FROM SNMPv2-SMI -- [RFC2578]
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF -- [RFC2580]
RowStatus, RowPointer, StorageType
FROM SNMPv2-TC -- [RFC2579]
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- [RFC3411]
Aldrin, et al. Expires March 4, 2016 [Page 6]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
IndexIntegerNextFree
FROM DIFFSERV-MIB -- [RFC3289]
mplsStdMIB
FROM MPLS-TC-STD-MIB -- [RFC3811]
InterfaceIndexOrZero, ifGeneralInformationGroup,
ifCounterDiscontinuityGroup
FROM IF-MIB; -- [RFC2863]
mplsOamIdStdMIB MODULE-IDENTITY
LAST-UPDATED
"201508290000Z" -- August 29, 2015
ORGANIZATION
"Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO
"
Sam Aldrin
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA
Email: aldrin.ietf@gmail.com
Thomas D. Nadeau
Email: tnadeau@lucidvision.com
Venkatesan Mahalingam
Dell, Inc.
5450 Great America Parkway,
Santa Clara, CA 95054, USA
Email: venkat.mahalingams@gmail.com
Kannan KV Sampath
Redeem,
India
Email: kannankvs@gmail.com
Ping Pan
Infinera
Email: ppan@infinera.com
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: sboutros@cisco.com
Aldrin, et al. Expires March 4, 2016 [Page 7]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
"
DESCRIPTION
"Copyright (c) 2015 IETF Trust and the persons identified
as the document authors. All rights reserved.
This MIB module contains generic object definitions for
MPLS OAM maintenance identifiers."
-- Revision history.
REVISION
"201508290000Z" -- August 29, 2015
DESCRIPTION
"MPLS OAM Identifiers MIB objects for Tunnels, LSPs,
Pseudowires, and Sections"
::= { mplsStdMIB xxx } -- xxx to be replaced with the correct
-- OID value assigned by
-- IANA (see section 9).
-- Top level components of this MIB module.
-- notifications
mplsOamIdNotifications
OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 0 }
-- tables, scalars
mplsOamIdObjects OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 1 }
-- conformance
mplsOamIdConformance
OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 2 }
-- Start of MPLS Transport Profile MEG table
mplsOamIdMegIndexNext OBJECT-TYPE
SYNTAX IndexIntegerNextFree (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains an unused value for
mplsOamIdMegIndex, or a zero to indicate
that none exist. Negative values are not allowed,
as they do not correspond to valid values of
mplsOamIdMegIndex."
::= { mplsOamIdObjects 1 }
mplsOamIdMegTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsOamIdMegEntry
Aldrin, et al. Expires March 4, 2016 [Page 8]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains information about the Maintenance
Entity Groups (MEG).
MEG as mentioned in MPLS-TP OAM framework defines a set
of one or more maintenance entities (ME).
Maintenance Entities define a relationship between any
two points of a transport path in an OAM domain to which
maintenance and monitoring operations apply."
::= { mplsOamIdObjects 2 }
mplsOamIdMegEntry OBJECT-TYPE
SYNTAX MplsOamIdMegEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table represents MPLS-TP MEG.
An entry can be created by a network administrator
or by an SNMP agent as instructed by an MPLS-TP OAM
Framework.
When a new entry is created with
mplsOamIdMegOperatorType set to ipCompatible (1),
then as per [RFC6370] (MEG_ID for LSP is LSP_ID and
MEG_ID for PW is PW_Path_ID), MEP_ID can be
automatically formed.
For co-routed bidirectional LSP, MEG_ID is
A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::
Node_ID::Tunnel_Num}::LSP_Num.
For associated bidirectional LSP, MEG_ID is A1-
{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::Z9-
{Global_ID::Node_ID::Tunnel_Num::LSP_Num}
For LSP, MEP_ID is formed using,
Global_ID::Node_ID::Tunnel_Num::LSP_Num
For PW, MEG_ID is formed using AGI::A1-
{Global_ID::Node_ID::AC_ID}::Z9-
{Global_ID::Node_ID::AC_ID}.
For PW, MEP_ID is formed using
AGI::Global_ID::Node_ID::AC_ID
MEP_ID is retrieved from the mplsOamIdMegServicePointer
Aldrin, et al. Expires March 4, 2016 [Page 9]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
object based on the mplsOamIdMegServicePointerType value.
ICC MEG_ID for LSP and PW is formed using the objects
mplsOamIdMegIdIcc and mplsOamIdMegIdUmc.
MEP_ID can be formed using MEG_ID::MEP_Index."
REFERENCE
"1. RFC 5860, Requirements for OAM in MPLS Transport
Networks, May 2010.
2. RFC 6371, Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks,
September 2011 Section 3.
3. RFC 6370, MPLS Transport Profile (MPLS-TP) Identifiers.
4. RFC 6923, MPLS Transport Profile (MPLS-TP) Identifiers
Following ITU-T Conventions."
INDEX { mplsOamIdMegIndex }
::= { mplsOamIdMegTable 1 }
MplsOamIdMegEntry ::= SEQUENCE {
mplsOamIdMegIndex Unsigned32,
mplsOamIdMegName SnmpAdminString,
mplsOamIdMegOperatorType INTEGER,
mplsOamIdMegIdCc SnmpAdminString,
mplsOamIdMegIdIcc SnmpAdminString,
mplsOamIdMegIdUmc SnmpAdminString,
mplsOamIdMegServicePointerType INTEGER,
mplsOamIdMegMpLocation INTEGER,
mplsOamIdMegPathFlow INTEGER,
mplsOamIdMegOperStatus INTEGER,
mplsOamIdMegSubOperStatus BITS,
mplsOamIdMegRowStatus RowStatus,
mplsOamIdMegStorageType StorageType
}
mplsOamIdMegIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for the conceptual row identifying a MEG within
this MEG table. Managers should obtain new values for row
creation in this table by reading
mplsOamIdMegIndexNext."
::= { mplsOamIdMegEntry 1 }
mplsOamIdMegName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..48))
MAX-ACCESS read-create
STATUS current
Aldrin, et al. Expires March 4, 2016 [Page 10]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
DESCRIPTION
"Each Maintenance Entity Group has a unique name amongst
all those used or available to a service provider or
operator. It facilitates easy identification of
administrative responsibility for each MEG."
::= { mplsOamIdMegEntry 2 }
mplsOamIdMegOperatorType OBJECT-TYPE
SYNTAX INTEGER {
ipCompatible (1),
iccBased (2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the operator type for MEG. Conceptual rows
having 'iccBased' as operator type, MUST have valid
values for the objects mplsOamIdMegIdIcc and
mplsOamIdMegIdUmc when the row status is active."
REFERENCE
"1. RFC 6370, MPLS Transport Profile (MPLS-TP)
Identifiers.
2. RFC 6923, MPLS Transport Profile (MPLS-TP) Identifiers
Following ITU-T Conventions. Section 3.1"
DEFVAL { ipCompatible }
::= { mplsOamIdMegEntry 3 }
mplsOamIdMegIdCc OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..2))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Global uniqueness is assured by concatenating the ICC
with a Country Code (CC). The Country Code (alpha-2)
is a string of two alphabetic characters represented
with upper case letters (i.e., A-Z).
This object MUST contain a non-null value if
the MplsOamIdMegOperatorType value is iccBased(2),
otherwise a null value with octet size 0
should be assigned."
REFERENCE
"RFC 6923, MPLS Transport Profile (MPLS-TP) Identifiers
Following ITU-T Conventions. Section 3."
DEFVAL {""}
::= { mplsOamIdMegEntry 4 }
Aldrin, et al. Expires March 4, 2016 [Page 11]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
mplsOamIdMegIdIcc OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..6))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Unique code assigned to Network Operator or Service
Provider maintained by ITU-T. The ITU Carrier Code
used to form MEGID.
This object MUST contain a non-null value if
the MplsOamIdMegOperatorType value is iccBased(2),
otherwise a null value with octet size 0
should be assigned."
REFERENCE
"RFC 6923, MPLS Transport Profile (MPLS-TP) Identifiers
Following ITU-T Conventions. Section 3.1."
DEFVAL {""}
::= { mplsOamIdMegEntry 5 }
mplsOamIdMegIdUmc OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..7))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Unique code assigned by Network Operator or Service
Provider, which is appended to mplsOamIdMegIdIcc to form
the MEGID.
This object MUST contain a non-null value if
the MplsOamIdMegOperatorType value is iccBased(2),
otherwise a null value with octet size 0
should be assigned."
REFERENCE
"RFC 6923, MPLS Transport Profile (MPLS-TP) Identifiers
Following ITU-T Conventions. Section 7.1."
DEFVAL {""}
::= { mplsOamIdMegEntry 6 }
mplsOamIdMegServicePointerType OBJECT-TYPE
SYNTAX INTEGER {
tunnel (1),
lsp (2),
pseudowire (3),
section (4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
Aldrin, et al. Expires March 4, 2016 [Page 12]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
"Indicates the service type for the MEG.
If the service type indicates tunnel, the service pointer
in mplsOamIdMeTable points to an entry in
the point-to-point mplsTunnelTable [RFC3812].
If the service type indicates lsp, the service pointer
in mplsOamIdMeTable points to an entry in
the co-routed or associated bidirectional mplsTunnelTable.
If the value is pseudowire (3) service type, the service
pointer in mplsOamIdMeTable points to an entry in
the pwTable [RFC5601].
If the value is section service type, the service
pointer in mplsOamIdMeTable points to an entry in
the mplsTunnelTable [RFC3812]."
REFERENCE
"1. RFC 3812, Multiprotocol Label Switching (MPLS)
Traffic Engineering (TE) Management Information
Base (MIB), June 2004.
2. RFC 5601, Pseudowire (PW) Management Information
Base (MIB), July 2009."
DEFVAL { lsp }
::= { mplsOamIdMegEntry 7 }
mplsOamIdMegMpLocation OBJECT-TYPE
SYNTAX INTEGER {
perNode (1),
perInterface (2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the MP location type for this MEG.
If the value is perNode, then the MEG in the LSR supports
only perNode MEP/MIP, i.e., only one MEP/MIP in an LSR.
If the value is perInterface, then the MEG in the LSR
supports perInterface MEPs/MIPs, i.e., two MEPs/MIPs in
an LSR."
REFERENCE
"RFC 6371, Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks,
September 2011."
DEFVAL { perNode }
::= { mplsOamIdMegEntry 8 }
Aldrin, et al. Expires March 4, 2016 [Page 13]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
mplsOamIdMegPathFlow OBJECT-TYPE
SYNTAX INTEGER {
unidirectionalPointToPoint (1),
coRoutedBidirectionalPointToPoint (2),
associatedBidirectionalPointToPoint (3),
unidirectionalPointToMultiPoint (4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the transport path flow for this MEG.
In case of a unidirectional point-to-point transport path,
a single unidirectional Maintenance Entity is defined to
monitor it.
In case of associated bidirectional point-to-point transport
paths, two independent unidirectional Maintenance Entities are
defined to independently monitor each direction.
In case of co-routed bidirectional point-to-point transport
paths, a single bidirectional Maintenance Entity is defined to
monitor both directions congruently.
In case of unidirectional point-to-multipoint transport paths,
a single unidirectional Maintenance Entity for each leaf is
defined to monitor the transport path from the root to
that leaf."
REFERENCE
"RFC 6371, Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks,
September 2011."
DEFVAL { coRoutedBidirectionalPointToPoint }
::= { mplsOamIdMegEntry 9 }
mplsOamIdMegOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up (1),
down (2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the operational status of the
Maintenance Entity Group (MEG). This object is used to
send the notification to the SNMP manager about the MEG.
The value up (1) indicates that the MEG and its monitored
path are operationally up. The value down (2) indicates
that the MEG is operationally down.
When the value of mplsOamIdMegOperStatus is up (1), all
Aldrin, et al. Expires March 4, 2016 [Page 14]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
the bits of mplsOamIdMegSubOperStatus must be cleared.
When the value of mplsOamIdMegOperStatus is down (2),
at least one bit of mplsOamIdMegSubOperStatus must be
set."
::= { mplsOamIdMegEntry 10 }
mplsOamIdMegSubOperStatus OBJECT-TYPE
SYNTAX BITS {
megDown (0),
meDown (1),
oamAppDown (2),
pathDown (3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the reason why the MEG operational
status as mentioned by the object mplsOamIdMegOperStatus
is down. This object is used to send the notification to
the SNMP manager about the MEG.
The bit 0 (megDown) indicates the MEG is down.
The bit 1 (meDown) indicates the ME table is
down.
The bit 2 (oamAppDown) indicates that the
OAM application has notified that the entity (LSP or PW)
monitored by this MEG is down. Currently, BFD is the
only supported OAM application.
The bit 3 (pathDown) indicates that the underlying
LSP or PW is down."
::= { mplsOamIdMegEntry 11 }
mplsOamIdMegRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable is used to create, modify, and/or delete
a row in this table. When a row in this table is in
active (1) state, no objects in that row can be modified
by the agent except mplsOamIdMegRowStatus."
::= { mplsOamIdMegEntry 12 }
mplsOamIdMegStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
Aldrin, et al. Expires March 4, 2016 [Page 15]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
DESCRIPTION
"This variable indicates the storage type for this
object.
Conceptual rows having the value 'permanent'
need not allow write-access to any columnar
objects in the row."
DEFVAL { volatile }
::= { mplsOamIdMegEntry 13 }
-- End of MPLS Transport Profile MEG table
-- Start of MPLS Transport Profile ME table
mplsOamIdMeIndexNext OBJECT-TYPE
SYNTAX IndexIntegerNextFree (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains an unused value for
mplsOamIdMeIndex, or a zero to indicate
that none exist. Negative values are not allowed,
as they do not correspond to valid values of
mplsOamIdMeIndex."
::= { mplsOamIdObjects 3 }
mplsOamIdMeMpIndexNext OBJECT-TYPE
SYNTAX IndexIntegerNextFree (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains an unused value for
mplsOamIdMeMpIndex, or a zero to indicate
that none exist. Negative values are not allowed,
as they do not correspond to valid values of
mplsOamIdMeMpIndex."
::= { mplsOamIdObjects 4 }
mplsOamIdMeTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsOamIdMeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains MPLS-TP maintenance entity
information.
ME is some portion of a transport path that requires
management bounded by two points (called MEPs), and the
Aldrin, et al. Expires March 4, 2016 [Page 16]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
relationship between those points to which maintenance
and monitoring operations apply.
This table is generic enough to handle MEPs and MIPs
information within a MEG."
::= { mplsOamIdObjects 5 }
mplsOamIdMeEntry OBJECT-TYPE
SYNTAX MplsOamIdMeEntry
MAX-ACCESS not-accessible STATUS current
DESCRIPTION
"An entry in this table represents MPLS-TP maintenance
entity. This entry represents the ME if the source and
sink MEPs are defined.
A ME is a point-to-point entity. One ME has two such MEPs.
A MEG is a group of one or more MEs. One MEG can have
two or more MEPs.
For point-to-point LSP, one MEG has one ME and this ME
is associated two MEPs (source and sink MEPs) within
a MEG. Each mplsOamIdMeIndex value denotes the ME within
a MEG.
In case of unidirectional point-to-point transport paths,
a single unidirectional Maintenance Entity is defined to
monitor it and mplsOamIdMeServicePointer points to
unidirectional point-to-point path.
In case of associated bidirectional point-to-point
transport paths, two independent unidirectional
Maintenance Entities are defined to independently monitor
each direction and each mplsOamIdMeServicePointer MIB
object points to unique unidirectional transport path.
This has implications for transactions that terminate at
or query a MIP, as a return path from MIP to source MEP
does not necessarily exist within the MEG.
In case of co-routed bidirectional point-to-point
transport paths, a single bidirectional Maintenance Entity
is defined to monitor both directions congruently and
mplsOamIdMeServicePointer MIB object points to co-routed
bidirectional point-to-point transport path.
In case of unidirectional point-to-multipoint transport
paths, a single unidirectional Maintenance entity for each
leaf is defined to monitor the transport path from the
root to that leaf and each leaf has different transport
Aldrin, et al. Expires March 4, 2016 [Page 17]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
path information in mplsOamIdMeServicePointer MIB object.
Note that the MplsOamIdMeEntry should be created manually
once the MEG is configured for OAM operations."
INDEX { mplsOamIdMegIndex,
mplsOamIdMeIndex,
mplsOamIdMeMpIndex
}
::= { mplsOamIdMeTable 1 }
MplsOamIdMeEntry ::= SEQUENCE {
mplsOamIdMeIndex Unsigned32,
mplsOamIdMeMpIndex Unsigned32,
mplsOamIdMeName SnmpAdminString,
mplsOamIdMeMpIfIndex InterfaceIndexOrZero,
mplsOamIdMeSourceMepIndex Unsigned32,
mplsOamIdMeSinkMepIndex Unsigned32,
mplsOamIdMeMpType INTEGER,
mplsOamIdMeMepDirection INTEGER,
mplsOamIdMeServicePointer RowPointer,
mplsOamIdMeRowStatus RowStatus,
mplsOamIdMeStorageType StorageType
}
mplsOamIdMeIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Uniquely identifies a maintenance entity index within
a MEG. Managers should obtain new values for row
creation in this table by reading
mplsOamIdMeIndexNext."
::= { mplsOamIdMeEntry 1 }
mplsOamIdMeMpIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Indicates the maintenance point index, used to create
multiple MEPs in a node of single ME. The value of this
object can be MEP index or MIP index. Managers should
obtain new values for row creation in this table by reading
mplsOamIdMeMpIndexNext."
::= { mplsOamIdMeEntry 2 }
mplsOamIdMeName OBJECT-TYPE
Aldrin, et al. Expires March 4, 2016 [Page 18]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
SYNTAX SnmpAdminString (SIZE(1..48))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object denotes the ME name, each
Maintenance Entity has unique name within MEG."
::= { mplsOamIdMeEntry 3 }
mplsOamIdMeMpIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the maintenance point interface.
If the mplsOamIdMegMpLocation object value
is perNode (1), the MP interface index should point
to incoming interface or outgoing interface or
zero (indicates the MP OAM packets are initiated
from forwarding engine).
If the mplsOamIdMegMpLocation object value is
perInterface (2), the MP interface index should point to
incoming interface or outgoing interface."
REFERENCE
"1. RFC 6371, Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks,
September 2011.
2. RFC 2863 - The Interfaces Group MIB, McCloghrie, K.,
and F. Kastenholtz, June 2000."
DEFVAL { 0 }
::= { mplsOamIdMeEntry 4 }
mplsOamIdMeSourceMepIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the source MEP Index of the ME. This object
should be configured if mplsOamIdMegOperatorType object
in the mplsOamIdMegEntry is configured as iccBased (2).
If the MEG is configured for IP-based operator,
the value of this object should be set zero and the MEP
ID will be automatically derived from the service
Identifiers(MPLS-TP LSP/PW Identifier)."
DEFVAL { 0 }
::= { mplsOamIdMeEntry 5 }
Aldrin, et al. Expires March 4, 2016 [Page 19]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
mplsOamIdMeSinkMepIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the sink MEP Index of the ME. This object
should be configured if mplsOamIdMegOperatorType object
in the mplsOamIdMegEntry is configured as iccBased (2).
If the MEG is configured for IP-based operator,
the value of this object should be set to zero and the MEP
ID will be automatically derived from the service
Identifiers (MPLS-TP LSP/PW Identifier)."
DEFVAL { 0 }
::= { mplsOamIdMeEntry 6 }
mplsOamIdMeMpType OBJECT-TYPE
SYNTAX INTEGER {
mep (1),
mip (2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the maintenance point type within the MEG.
The object should have the value mep (1), only in the
Ingress or Egress nodes of the transport path.
The object can have the value mip (2), in
the Intermediate nodes and possibly in the Egress
nodes of the transport path."
DEFVAL { mep }
::= { mplsOamIdMeEntry 7 }
mplsOamIdMeMepDirection OBJECT-TYPE
SYNTAX INTEGER {
up (1),
down (2),
notApplicable (3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the direction of the MEP. This object
should be configured if mplsOamIdMeMpType is
configured as mep (1) else notApplicable (3) is set."
DEFVAL { down }
::= { mplsOamIdMeEntry 8 }
Aldrin, et al. Expires March 4, 2016 [Page 20]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
mplsOamIdMeServicePointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable represents a pointer to the MPLS-TP
transport path. This value MUST point at an entry in the
mplsTunnelEntry if mplsOamIdMegServicePointerType
is configured as tunnel (1) or lsp (2) or section (4) or
at an entry in the pwEntry if
mplsOamIdMegServicePointerType is configured
as pseudowire (3).
Note: This service pointer object is placed in the ME table
instead of the MEG table since it will be useful in case of
point-to-multipoint, where each ME will point to different
branches of a P2MP tree."
::= { mplsOamIdMeEntry 9 }
mplsOamIdMeRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable is used to create, modify, and/or
delete a row in this table. When a row in this
table is in active (1) state, no objects in that row
can be modified by the agent except
mplsOamIdMeRowStatus."
::= { mplsOamIdMeEntry 10 }
mplsOamIdMeStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable indicates the storage type for this
object.
Conceptual rows having the value 'permanent'
need not allow write-access to any columnar
objects in the row."
DEFVAL { volatile }
::= { mplsOamIdMeEntry 11 }
-- End of MPLS Transport Profile ME table
-- End of MPLS-TP OAM Tables
Aldrin, et al. Expires March 4, 2016 [Page 21]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
-- Notification Definitions of MPLS-TP identifiers
mplsOamIdDefectCondition NOTIFICATION-TYPE
OBJECTS {
mplsOamIdMegName,
mplsOamIdMeName,
mplsOamIdMegOperStatus,
mplsOamIdMegSubOperStatus
}
STATUS current
DESCRIPTION
"This notification is sent whenever the operational
status of MEG is changed."
::= { mplsOamIdNotifications 1 }
-- End of Notifications.
-- Module Compliance.
mplsOamIdCompliances
OBJECT IDENTIFIER ::= { mplsOamIdConformance 1 }
mplsOamIdGroups
OBJECT IDENTIFIER ::= { mplsOamIdConformance 2 }
-- Compliance requirement for fully compliant implementations.
mplsOamIdModuleFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "Compliance statement for agents that provide full
support for MPLS-TP-OAM-STD-MIB. Such devices can
then be monitored and also be configured using
this MIB module."
MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.
MANDATORY-GROUPS {
ifGeneralInformationGroup,
ifCounterDiscontinuityGroup
}
MODULE -- This module.
MANDATORY-GROUPS {
mplsOamIdMegGroup,
mplsOamIdMeGroup
}
GROUP mplsOamIdNotificationObjectsGroup
Aldrin, et al. Expires March 4, 2016 [Page 22]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
DESCRIPTION "This group is only mandatory for those
implementations which can efficiently implement
the notifications contained in this group."
GROUP mplsOamIdNotificationGroup
DESCRIPTION "This group is only mandatory for those
implementations which can efficiently implement
the notifications contained in this group."
::= { mplsOamIdCompliances 1 }
-- Compliance requirement for read-only implementations.
mplsOamIdModuleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for agents that only provide
read-only support for the MPLS-TP-OAM-STD-MIB module."
MODULE -- this module
MANDATORY-GROUPS {
mplsOamIdMegGroup,
mplsOamIdMeGroup
}
GROUP mplsOamIdNotificationObjectsGroup
DESCRIPTION "This group is only mandatory for those
implementations which can efficiently implement
the notifications contained in this group."
GROUP mplsOamIdNotificationGroup
DESCRIPTION "This group is only mandatory for those
implementations which can efficiently implement
the notifications contained in this group."
-- mplsOamIdMegTable
OBJECT mplsOamIdMegName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMegOperatorType
MIN-ACCESS read-only
DESCRIPTION
Aldrin, et al. Expires March 4, 2016 [Page 23]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
"Write access is not required."
OBJECT mplsOamIdMegIdCc
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMegIdIcc
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required.&RFC 7877 SSPF August 2016
Any conforming substrate "protocol" specification MUST provide a
definition for the operation to request such details from the SPPF
server. If the entity that issued the command is not authorized to
perform this operation, an appropriate error message MUST be returned
from among the response messages defined in "Response Message Types"
(Section 5.3 of this document).
8. XML Considerations
XML serves as the encoding format for SPPF, allowing complex
hierarchical data to be expressed in a text format that can be read,
saved, and manipulated with both traditional text tools and tools
specific to XML.
XML is case sensitive. Unless stated otherwise, the character casing
of XML specifications in this document MUST be preserved to develop a
conforming specification.
This section discusses a small number of XML-related considerations
pertaining to SPPF.
8.1. Namespaces
All SPPF elements are defined in the Namespaces in the "IANA
Considerations" and "Formal Framework Specification" sections of this
document.
8.2. Versioning and Character Encoding
All XML instances SHOULD begin with an <?xml?> declaration to
identify the version of XML that is being used, optionally identify
use of the character encoding used, and optionally provide a hint to
an XML parser that an external schema file is needed to validate the
XML instance.
Conformant XML parsers recognize both UTF-8 (defined in [RFC3629])
and UTF-16 (defined in [RFC2781]); per [RFC2277], UTF-8 is the
RECOMMENDED character encoding for use with SPPF.
Character encodings other than UTF-8 and UTF-16 are allowed by XML.
UTF-8 is the default encoding assumed by XML in the absence of an
"encoding" attribute or a byte order mark (BOM); thus, the "encoding"
attribute in the XML declaration is OPTIONAL if UTF-8 encoding is
used. SPPF clients and servers MUST accept a UTF-8 BOM if present,
though emitting a UTF-8 BOM is NOT RECOMMENDED.
Cartwright, et al. Standards Track [Page 40]
RFC 7877 SSPF August 2016
Example XML declarations:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
9. Security Considerations
Many SPPF implementations manage data that is considered confidential
and critical. Furthermore, SPPF implementations can support
provisioning activities for multiple Registrars and Registrants. As
a result, any SPPF implementation must address the requirements for
confidentiality, authentication, and authorization.
9.1. Confidentiality and Authentication
With respect to confidentiality and authentication, the substrate
protocol requirements section of this document contains security
properties that the substrate protocol must provide, so that
authenticated endpoints can exchange data confidentially and with
integrity protection. Refer to Section 4 of this document and
[RFC7878] for the specific solutions to authentication and
confidentiality.
9.2. Authorization
With respect to authorization, the SPPF server implementation must
define and implement a set of authorization rules that precisely
address (1) which Registrars will be authorized to create/modify/
delete each SPPF object type for a given Registrant(s) and (2) which
Registrars will be authorized to view/get each SPPF object type for a
given Registrant(s). These authorization rules are a matter of
policy and are not specified within the context of SPPF. However,
any SPPF implementation must specify these authorization rules in
order to function in a reliable and safe manner.
9.3. Denial of Service
In general, guidance on Denial-of-Service (DoS) issues is given in
"Internet Denial of Service Considerations" [RFC4732], which also
gives a general vocabulary for describing the DoS issue.
SPPF is a high-level client-server protocol that can be implemented
on lower-level mechanisms such as remote procedure call and web-
service API protocols. As such, it inherits any Denial-of-Service
issues inherent to the specific lower-level mechanism used for any
implementation of SPPF. SPPF also has its own set of higher-level
exposures that are likely to be independent of lower-layer mechanism
choices.
Cartwright, et al. Standards Track [Page 41]
RFC 7877 SSPF August 2016
9.3.1. DoS Issues Inherited from the Substrate Mechanism
In general, an SPPF implementation is dependent on the selection and
implementation of a lower-level substrate protocol and a binding
between that protocol and SPPF. The archetypal SPPF implementation
uses XML [W3C.REC-xml-20081126] representation in a SOAP [SOAPREF]
request/response framework over HTTP [RFC7230], probably also uses
Transport Layer Security (TLS) [RFC5246] for on-the-wire data
integrity and participant authentication, and might use HTTP Digest
authentication [RFC2069].
The typical deployment scenario for SPPF is to have servers in a
managed facility; therefore, techniques such as Network Ingress
Filtering [RFC2827] are generally applicable. In short, any DoS
mechanism affecting a typical HTTP implementation would affect such
an SPPF implementation; therefore, the mitigation tools for HTTP in
general also apply to SPPF.
SPPF does not directly specify an authentication mechanism; instead,
it relies on the lower-level substrate protocol to provide for
authentication. In general, authentication is an expensive
operation, and one apparent attack vector is to flood an SPPF server
with repeated requests for authentication, thereby exhausting its
resources. Therefore, SPPF implementations SHOULD be prepared to
handle authentication floods, perhaps by noting repeated failed login
requests from a given source address and blocking that source
address.
9.3.2. DoS Issues Specific to SPPF
The primary defense mechanism against DoS within SPPF is
authentication. Implementations MUST tightly control access to the
SPPF service, SHOULD implement DoS and other policy control
screening, and MAY employ a variety of policy violation reporting and
response measures such as automatic blocking of specific users and
alerting of operations personnel. In short, the primary SPPF
response to DoS-like activity by a user is to block that user or
subject their actions to additional review.
SPPF allows a client to submit multiple-element or "batch" requests
that may insert or otherwise affect a large amount of data with a
single request. In the simplest case, the server progresses
sequentially through each element in a batch, completing one before
starting the next. Mid-batch failures are handled by stopping the
batch and rolling back the data store to its pre-request state. This
"stop and roll back" design provides a DoS opportunity. A hostile
client could repeatedly issue large batch requests with one or more
failing elements, causing the server to repeatedly stop and roll back
Cartwright, et al. Standards Track [Page 42]
RFC 7877 SSPF August 2016
large transactions. The suggested response is to monitor clients for
such failures and take administrative action (such as blocking the
user) when an excessive number of rollbacks is reported.
An additional suggested response is for an implementer to set their
maximum allowable XML message size and their maximum allowable batch
size at a level that they feel protects their operational instance,
given the hardware sizing they have in place and the expected load
and size needs that their users expect.
9.4. Information Disclosure
It is not uncommon for the logging systems to document on-the-wire
messages for various purposes, such as debugging, auditing, and
tracking. At the minimum, the various support and administration
staff will have access to these logs. Also, if an unprivileged user
gains access to the SPPF deployments and/or support systems, it will
have access to the information that is potentially deemed
confidential. To manage information disclosure concerns beyond the
substrate level, SPPF implementations MAY provide support for
encryption at the SPPF object level.
9.5. Non-repudiation
In some situations, it may be required to protect against denial of
involvement (see [RFC4949]) and tackle non-repudiation concerns in
regard to SPPF messages. This type of protection is useful to
satisfy authenticity concerns related to SPPF messages beyond the
end-to-end connection integrity, confidentiality, and authentication
protection that the substrate layer provides. This is an optional
feature, and some SPPF implementations MAY provide support for it.
9.6. Replay Attacks
Anti-replay protection ensures that a given SPPF object replayed at a
later time won't affect the integrity of the system. SPPF provides
at least one mechanism to fight against replay attacks. Use of the
optional client transaction identifier allows the SPPF client to
correlate the request message with the response and to be sure that
it is not a replay of a server response from earlier exchanges. Use
of unique values for the client transaction identifier is highly
encouraged to avoid chance matches to a potential replay message.
Cartwright, et al. Standards Track [Page 43]
RFC 7877 SSPF August 2016
9.7. Compromised or Malicious Intermediary
The SPPF client or Registrar can be a separate entity acting on
behalf of the Registrant in facilitating provisioning transactions to
the Registry. Therefore, even though the substrate layer provides
end-to-end protection for each specific SPPP connection between
client and server, data might be available in clear text before or
after it traverses an SPPP connection. Therefore, a
man-in-the-middle attack by one of the intermediaries is a
possibility that could affect the integrity of the data that belongs
to the Registrant and/or expose peering data to unintended actors.
10. Internationalization Considerations
Character encodings to be used for SPPF elements are described in
Section 8.2. The use of time elements in the protocol is specified
in Section 3.2. Where human-readable messages that are presented to
an end user are used in the protocol, those messages SHOULD be tagged
according to [RFC5646], and the substrate protocol MUST support a
respective mechanism to transmit such tags together with those human-
readable messages.
11. IANA Considerations
11.1. URN Assignments
This document uses URNs to describe XML Namespaces and XML Schemas
conforming to a Registry mechanism described in [RFC3688].
Two URI assignments have been made:
Registration for the SPPF XML Namespace:
urn:ietf:params:xml:ns:sppf:base:1
Registrant Contact: The IESG
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the XML Schema:
URI: urn:ietf:params:xml:schema:sppf:1
Registrant Contact: IESG
XML: See "Formal Specification" (Section 12 of this document).
Cartwright, et al. Standards Track [Page 44]
RFC 7877 SSPF August 2016
11.2. Organization Identifier Namespace Registry
IANA has created and will maintain a registry titled "SPPF OrgIdType
Namespaces". The formal syntax is described in Section 5.1.
Assignments consist of the OrgIdType Namespace string and the
definition of the associated Namespace. This document makes the
following initial assignment for the OrgIdType Namespaces:
OrgIdType Namespace string Namespace
-------------------------- ---------
IANA Enterprise Numbers iana-en
Future assignments are to be made through the well-known IANA Policy
"RFC Required" (see Section 4.1 of [RFC5226]). Such assignments will
typically be requested when a new Namespace for identification of SPs
is defined.
12. Formal Specification
This section provides the XSD for the SPPF protocol.
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"
xmlns="http://www.w3.org/2001/XMLSchemaquot;
OBJECT mplsOamIdMegIdUmc
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMegServicePointerType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMegMpLocation
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMegOperStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMegSubOperStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMegPathFlow
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMegRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
Aldrin, et al. Expires March 4, 2016 [Page 24]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
OBJECT mplsOamIdMegStorageType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
-- mplsOamIdMeTable
OBJECT mplsOamIdMeName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMeMpIfIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMeSourceMepIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMeSinkMepIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMeMpType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMeMepDirection
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMeServicePointer
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsOamIdMeRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
Aldrin, et al. Expires March 4, 2016 [Page 25]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
OBJECT mplsOamIdMeStorageType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { mplsOamIdCompliances 2 }
-- Units of conformance.
mplsOamIdMegGroup OBJECT-GROUP
OBJECTS {
mplsOamIdMegIndexNext,
mplsOamIdMegName,
mplsOamIdMegOperatorType,
mplsOamIdMegIdCc,
mplsOamIdMegIdIcc,
mplsOamIdMegIdUmc,
mplsOamIdMegServicePointerType,
mplsOamIdMegMpLocation,
mplsOamIdMegOperStatus,
mplsOamIdMegSubOperStatus,
mplsOamIdMegPathFlow,
mplsOamIdMegRowStatus,
mplsOamIdMegStorageType
}
STATUS current
DESCRIPTION
"Collection of objects needed for MPLS MEG information."
::= { mplsOamIdGroups 1 }
mplsOamIdMeGroup OBJECT-GROUP
OBJECTS {
mplsOamIdMeIndexNext,
mplsOamIdMeMpIndexNext,
mplsOamIdMeName,
mplsOamIdMeMpIfIndex,
mplsOamIdMeSourceMepIndex,
mplsOamIdMeSinkMepIndex,
mplsOamIdMeMpType,
mplsOamIdMeMepDirection,
mplsOamIdMeServicePointer,
mplsOamIdMeRowStatus,
mplsOamIdMeStorageType
}
STATUS current
DESCRIPTION
"Collection of objects needed for MPLS ME information."
Aldrin, et al. Expires March 4, 2016 [Page 26]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
::= { mplsOamIdGroups 2 }
mplsOamIdNotificationObjectsGroup OBJECT-GROUP
OBJECTS {
mplsOamIdMegOperStatus,
mplsOamIdMegSubOperStatus
}
STATUS current
DESCRIPTION
"Collection of objects needed to implement notifications."
::= { mplsOamIdGroups 3 }
mplsOamIdNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
mplsOamIdDefectCondition
}
STATUS current
DESCRIPTION
"Set of notifications implemented in this module."
::= { mplsOamIdGroups 4 }
END
8. Security Consideration
This MIB relates to a system that will provide network connectivity
and packet forwarding services. As such, improper manipulation of the
objects represented by this MIB may result in denial of service to a
large number of end-users.
There are number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-create. 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 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:
- mplsOamIdMegTable and mplsOamIdMeTable collectively show
Aldrin, et al. Expires March 4, 2016 [Page 27]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
the MPLS OAM characteristics. If an Administrator does not want to
reveal this information, then these tables should be considered
sensitive/vulnerable.
SNMP versions prior to SNMPv3 did not include adequate security. Even
if the network itself is secure (for example by using IPsec), 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.
Implementations SHOULD provide the security features described by the
SNMPv3 framework (see [RFC3410]), and implementations claiming
compliance to the SNMPv3 standard MUST include full support for
authentication and privacy via the User-based Security Model (USM)
[RFC3414] with the AES cipher algorithm [RFC3826]. Implementations
MAY also provide support for the Transport Security Model (TSM)
[RFC5591] in combination with a secure transport such as SSH
[RFC5592] or TLS/DTLS [RFC6353].
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 principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
9. IANA Considerations
IANA is requested to assign an OID for the MIB module from the "MIB
Transmission Group - MPLS STD" sub-registry of the "Internet-standard
MIB - Transmission Group" registry for the MPLS-TP OAM ID MIB module
specified in this document.
10. References
10.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.
Aldrin, et al. Expires March 4, 2016 [Page 28]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group
MIB ", RFC 2863, June 2000
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management
Information Base for the Differentiated Services
Architecture", RFC 3289, May 2002.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC
3411, December 2002.
[RFC5601] Zelig, D., Ed., and T. Nadeau, Ed., "Pseudowire (PW)
Management Information Base (MIB)", RFC 5601, July 2009.
10.2 Informative References
[RFC3410] J. Case, R. Mundy, D. pertain, B.Stewart, "Introduction
and Applicability Statement for Internet Standard
Management Framework", RFC 3410, December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security
Model(USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)", STD 62, RFC 3414,
December 2002.
[RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of
Textual Conventions (TCs) for Multiprotocol Label
Switching (MPLS) Management", RFC 3811, June 2004.
[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.
Aldrin, et al. Expires March 4, 2016 [Page 29]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
[RFC3826] Blumenthal, U., F. Maino and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in
the SNMP User-based Security Model", RFC 3826, June
2004.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security
Model for the Simple Network Management Protocol
(SNMP)",RFC 5591, June 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009.
[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.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol
(SNMP)", STD 78, RFC 6353, July 2011.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS-TP
Identifiers", RFC 6370, September 2011.
[RFC6371] Busi, I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM
Framework and Overview", RFC 6371, September 2011.
[RFC6923] R. Winter, Ed, E. Gray, Ed., H. van Helvoort, and M.
Betts, "MPLS-TP Identifiers Following ITU-T
Conventions", RFC 6923, May 2013.
[RFC5860] M. Vigoureux, Ed, D. Ward, Ed, M. Betts, Ed, "OAM in MPLS
Transport Networks", RFC 5860, May 2010.
11. Acknowledgments
We wish to thank Muly Ilan, Adrian Farrel, Joan Cucchiara,
Weiying Cheng, Mach Chen, Peter Yee, and Tina TSOU for their
valuable comments on this document.
12. Authors' Addresses
Venkatesan Mahalingam
Dell, Inc.
5450 Great America Parkway,
Santa Clara, CA 95054, USA
Email: venkat.mahalingams@gmail.com
Aldrin, et al. Expires March 4, 2016 [Page 30]
INTERNET DRAFT MPLS-TP OAM ID MIB September 1, 2015
Sam Aldrin
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA
Email: aldrin.ietf@gmail.com
Thomas D. Nadeau
Brocade
Email: tnadeau@lucidvision.com
Kannan KV Sampath
Redeem,
India
Email: kannankvs@gmail.com
Ping Pan
Infinera
Email: ppan@infinera.com
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: sboutros@cisco.com
Aldrin, et al. Expires March 4, 2016 [Page 31]