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]