--- 1/draft-ietf-mpls-tp-mib-management-overview-05.txt 2012-01-31 12:14:00.826837470 +0100 +++ 2/draft-ietf-mpls-tp-mib-management-overview-06.txt 2012-01-31 12:14:00.874837587 +0100 @@ -1,19 +1,19 @@ Network Working Group D. King (Editor) Internet-Draft Old Dog Consulting Intended status: Informational M. Venkatesan (Editor) -Expires: February 5, 2012 Aricent - August 5, 2011 +Expires: June 30, 2012 Aricent + January 31, 2012 Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview - draft-ietf-mpls-tp-mib-management-overview-05.txt + draft-ietf-mpls-tp-mib-management-overview-06.txt Abstract A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS @@ -39,25 +39,25 @@ 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 February 5, 2012. + This Internet-Draft will expire on June 30, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 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 @@ -83,53 +83,52 @@ 4.2.9. Fault Management and Performance Management......10 4.2.10. MIB Module Interdependencies....................11 4.2.11. Dependencies on External MIB Modules............13 5. Applicability of MPLS MIB modules to MPLS-TP.................14 5.1 MPLS-TP Tunnel...........................................14 5.1.1 Gap Analysis.......................................14 5.1.2 Recommendations....................................15 5.2 MPLS-TP Pseudowire.......................................15 5.2.1 Gap Analysis.......................................15 5.2.2 Recommendations....................................15 - 5.3 MPLS-TP Sections.........................................16 - 5.3.1 Gap Analysis.......................................16 - 5.3.2 Recommendations....................................16 + 5.3 MPLS-TP Sections.........................................15 + 5.3.1 Gap Analysis.......................................15 + 5.3.2 Recommendations....................................15 5.4 MPLS-TP OAM..............................................16 5.4.1 Gap Analysis.......................................16 5.4.2 Recommendations....................................16 - 5.5 MPLS-TP Protection Switching and Recovery................16 5.5.1 Gap Analysis.......................................16 5.5.2 Recommendations....................................17 5.6 MPLS-TP Interfaces.......................................17 5.6.1 Gap Analysis.......................................17 5.6.2 Recommendations....................................17 6. An Introduction to the MPLS-TP MIB Modules...................17 - 6.1 MPLS-TP MIB Modules......................................18 - 6.1.1 Structure of the MPLS-TP MIB OID Tree.............18 + 6.1 MPLS-TP MIB Modules......................................17 + 6.1.1 Structure of the MPLS-TP MIB OID Tree.............17 6.1.2 Textual Conventions for MPLS-TP...................18 6.1.3 Identifiers for MPLS-TP...........................18 6.1.4 LSR MIB Extensions for MPLS-TP....................18 - 6.1.5 Tunnel Extensions for MPLS-TP.....................19 + 6.1.5 Tunnel Extensions for MPLS-TP.....................18 6.2 PWE3 MIB Modules for MPLS-TP.............................19 6.2.1 Structure of the PWE3 MIB OID Tree for MPLS-TP....19 6.2.2 Pseudowire Textual Conventions for MPLS-TP........19 6.2.3 Pseudowire Extensions for MPLS-TP.................19 6.2.4 Pseudowire MPLS Extensions for MPLS-TP............19 6.3 OAM MIB Modules for MPLS-TP..............................20 6.3.1 Structure of the OAM MIB OID Tree for MPLS-TP.....20 6.3.2 BFD MIB module....................................20 6.3.3 Common OAM MIB modules............................20 6.4. Protection Switching and Recovery MIB Modules for MPLS-TP.............................................20 6.4.1 Structure of the Protection Switching - and Recovery MIB OID Tree for MPLS-TP.............21 + and Recovery MIB OID Tree for MPLS-TP.............20 6.4.2 Linear Protection Switching MIB module............21 6.4.3 Ring Protection Switching MIB module..............21 6.4.4 Mesh Protection Switching MIB module..............21 7. Management Options...........................................21 8. Security Considerations......................................21 9. IANA Considerations..........................................22 10. Acknowledgements............................................22 11. References..................................................22 11.1. Normative References...................................22 11.2. Informational References...............................24 @@ -190,22 +189,22 @@ 3. The SNMP Management Framework 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). For a detailed overview of the documents that describe the current - Internet-Standard Management Framework, please refer to section 7 of - RFC 3410 [RFC3410]. + Internet-Standard Management Framework, please refer to Section 7. of + [RFC3410]. This document discusses MIB modules that are compliant to the SMIv2, which is described in [RFC2578], [RFC2579] and [RFC2580]. 4. Overview of Existing Work This section describes the existing tools and techniques for managing and modeling MPLS networks, devices, and protocols. It is intended to provide a description of the tool kit that is already available. @@ -233,23 +232,24 @@ [RFC5654] describes the requirements for the optional use of a control plane to support dynamic provisioning of MPLS-TP transport paths. The MPLS-TP LSP control plane is based on GMPLS and is described in [RFC3945]. 4.2. An Introduction to the MPLS and Pseudowire MIB Modules 4.2.1. Structure of the MPLS MIB OID Tree - The MPLS MIB OID tree has the following structure. It is based on the - tree originally set out in section 4.1 of [RFC4221] and has been - enhanced to include other relevant MIB modules. + The MPLS MIB Object Identifiers (OID) tree has the following + structure. It is based on the tree originally set out in section + 4.1 of [RFC4221] and has been enhanced to include other relevant MIB + modules. mib-2 -- RFC 2578 [RFC2578] | +-transmission | | | +- mplsStdMIB | | | | | +- mplsTCStdMIB -- MPLS-TC-STD-MIB [RFC3811] | | | | | +- mplsLsrStdMIB -- MPLS-LSR-STD-MIB [RFC3813] @@ -294,37 +294,37 @@ MPLS-TC-STD-MIB [RFC3811], GMPLS-TC-STD-MIB [RFC4801], IANA-GMPLS-TC-MIB [RFC4802] and PW-TC-STD-MIB [RFC5542] contains the Textual Conventions for MPLS and GMPLS networks. These Textual Conventions should be imported by MIB modules which manage MPLS and GMPLS networks. Section 4.2.11. highlights dependencies on additional external MIB modules 4.2.3. Label Switched Path (LSP) Modules An LSP is a path over which a labeled packet travels across the - sequence of LSRs for a given FEC. When a packet, with or without - label, arrives at an ingress LER of an LSP, it is encapsulated with - the label corresponding to the FEC and sent across the LSP. The - labeled packet traverses across the LSRs and arrives at the egress - LER of the LSP, where, it gets forwarded depending on the packet type - it came with. LSPs could be nested using label stacking, such that, - an LSP could traverse over another LSP. A further description of - an LSP can be found in [RFC3031]. + sequence of LSRs for a given Forward Equivalence Class (FEC). When a + packet, with or without label, arrives at an ingress LER of an LSP, + it is encapsulated with the label corresponding to the FEC and sent + across the LSP. The labeled packet traverses across the LSRs and + arrives at the egress LER of the LSP, where, it gets forwarded + depending on the packet type it came with. LSPs could be nested using + label stacking, such that, an LSP could traverse over another LSP. A + further description of an LSP can be found in [RFC3031]. MPLS-LSR-STD-MIB [RFC3813] describes the required objects to define the LSP. 4.2.4. Label Edge Router (LER) Modules - Ingress and Egress LSRs of an LSP are known as Label Edge Routers. - An ingress LER takes the incoming unlabeled or labeled packets and - encapsulates it with the corresponding label of the LSP it + Ingress and Egress LSRs of an LSP are known as Label Edge Routers + (LER). An ingress LER takes the incoming unlabeled or labeled packets + and encapsulates it with the corresponding label of the LSP it represents, and forwards it, over to the adjacent LSR of the LSP. Each FEC is mapped to a label forwarding entry, so that packet could be encapsulated with one or more label entries, referred as label stack. The packet traverses across the LSP, and upon reaching the Egress LER, further action will be taken to handle the packet, depending on the packet it received. MPLS Architecture [RFC3031] details the functionality of an Ingress and Egress LERs. @@ -345,67 +345,67 @@ MPLS-LSR-STD-MIB [RFC3813] describes the managed objects for modeling a Multiprotocol Label Switching (MPLS) [RFC3031] LSR. MPLS-LSR-STD-MIB [RFC3813] contains the managed objects to maintain mapping of in-segments to out-segments. 4.2.6. Pseudowire Modules The PW (Pseudowire) MIB architecture provides a layered modular model into which any supported emulated service such as Frame Relay, ATM, - Ethernet, TDM and SONET/SDH can be connected to any supported packet - switched network (PSN) type. This MIB architecture is modeled based + Ethernet, TDM and SONET/SDH can be connected to any supported Packet + Switched Network (PSN) type. This MIB architecture is modeled based on PW3 architecture [RFC3985]. Emulated Service Layer, Generic PW Layer and PSN VC Layer constitute the different layers of the model. A combination of the MIB modules belonging to each layer provides the glue for mapping the emulated service onto the native PSN service. At least three MIB modules each belonging to a different layer are required to define a PW emulated service. - o Service-Specific module is dependent on the emulated signal type + - Service-Specific module is dependent on the emulated signal type and helps in modeling emulated service layer. PW-ENET-STD-MIB [RFC5603] describes a model for managing Ethernet pseudowire services for transmission over a PSN. This MIB module is generic and common to all types of PSNs supported in the Pseudowire - Emulation Edge-to-Edge (PWE3) architecture [RFC3985], which describes + Emulation Edge-to-Edge (PWE3) Architecture [RFC3985], which describes the transport and encapsulation of L1 and L2 services over supported PSN types. In particular, the MIB module associates a port or specific VLANs on top of a physical Ethernet port or a virtual Ethernet interface (for Virtual Private LAN Service (VPLS)) to a point-to-point PW. It is complementary to the PW-STD-MIB [RFC5601], which manages the generic PW parameters common to all services, including all supported PSN types. PW-TDM-MIB [RFC5604] describes a model for managing TDM pseudowires, i.e., TDM data encapsulated for transmission over a Packet Switched Network (PSN). The term TDM in this document is limited to the scope of Plesiochronous Digital Hierarchy (PDH). It is currently specified to carry any TDM Signals in either Structure Agnostic Transport mode (E1, T1, E3, and T3) or in Structure Aware Transport mode (E1, T1, and NxDS0) as defined in the Pseudowire Emulation Edge-to-Edge (PWE3) TDM Requirements document [RFC4197]. - o Generic PW Module configures general parameters of the PW that are + - Generic PW Module configures general parameters of the PW that are common to all types of emulated services and PSN types. PW-STD-MIB [RFC5601] defines a MIB module that can be used to manage pseudowire (PW) services for transmission over a Packet Switched Network (PSN) [RFC3931] [RFC4447]. This MIB module provides generic management of PWs that is common to all types of PSN and PW services defined by the IETF PWE3 Working Group. - o PSN-specific module associate the PW with one or more "tunnels" + - PSN-specific module associate the PW with one or more "tunnels" that carry the service over the PSN. There is a different module for each type of PSN. PW-MPLS-STD-MIB [RFC5602] describes a model for managing pseudowire services for transmission over different flavors of MPLS tunnels. The general PW MIB module [RFC5601] defines the parameters global to the PW regardless of the underlying Packet Switched Network (PSN) and emulated service. This document is applicable for PWs that use MPLS PSN type in the PW-STD-MIB. Additionally this document describes the MIB objects that define pseudowire association to the MPLS PSN, @@ -428,32 +428,34 @@ Multiprotocol Label Switching (MPLS) [RFC3031] based traffic engineering. This MIB module should be used in conjunction with the companion document [RFC3813] for MPLS based traffic engineering configuration and management. 4.2.8. Resiliency The purpose of MPLS resiliency is to ensure minimal interruption to traffic when the failure occurs within the system or network. - Various components of MPLS resiliency solutions are, - 1) Graceful restart in LDP and RSVP-TE modules - 2) Make Before Break - 3) Protection Switching for LSPs - 4) Fast ReRoute for LSPs - 5) PW redundancy + Various components of MPLS resiliency solutions are; + + 1) Graceful restart in LDP and RSVP-TE modules, + 2) Make Before Break, + 3) Protection Switching for LSPs, + 4) Fast ReRoute for LSPs, + 5) PW redundancy. + The below modules only support the SNMP based MIB management for MPLS resiliency. - MPLS Fast Reroute is a restoration network resiliency mechanism used - in MPLS TE to redirect the traffic onto the backup LSP's in 10s of - milliseconds in case of link or node failure across the LSP. + MPLS Fast Reroute (FRR) is a restoration network resiliency mechanism + used in MPLS TE to redirect the traffic onto the backup LSP's in 10s + of milliseconds in case of link or node failure across the LSP. MPLS-FRR-GENERAL-STD-MIB [draft-ietf-mpls-fastreroute-mib-14] contains objects that apply to any MPLS LSR implementing MPLS TE fast reroute functionality. MPLS-FRR-ONE2ONE-STD-MIB [draft-ietf-mpls-fastreroute-mib-14] contains objects that apply to one-to-one backup method. MPLS-FRR-FACILITY-STD-MIB [draft-ietf-mpls-fastreroute-mib-14] contains objects that apply to facility backup method. @@ -622,22 +624,22 @@ an entry in ifTable. The interrelation of entries in ifTable is defined by the Interfaces Stack Group defined in [RFC2863]. The MPLS MIB modules have dependencies with the TE-LINK-STD-MIB for maintaining the traffic engineering information. The MPLS MIB modules depend on the constrained shortest path first (CSPF) module to obtain the path required for an MPLS tunnel to reach - the end point of the tunnel and BFD module to verify the data-plane - failures of LSPs and PWs. + the end point of the tunnel and Bidirectional Forwarding Detection + (BFD) module to verify the data-plane failures of LSPs and PWs. Finally, all of the MIB modules import standard textual conventions such as integers, strings, timestamps, etc., from the MIB modules in which they are defined. 5. Applicability of MPLS MIB modules to MPLS-TP This section highlights gaps in existing MPLS MIB modules in order to determine extensions or additional MIB modules that are required to support MPLS-TP in MPLS networks @@ -659,36 +661,34 @@ reused for MPLS based transport network management. Fault management and performance management form key parts of the Operations, Administration, and Maintenance (OAM) function. MPLS-TP OAM is described in [MPLS-TP-OAM-FWK]. 5.1 MPLS-TP Tunnel 5.1.1 Gap Analysis - MPLS-TP tunnel can be operated over IP and/or ICC environments, - below points capture the gaps in existing MPLS MIB modules - for managing the MPLS-TP networks. + MPLS-TP tunnel can be operated over IP and/or ITU-T Carrier Code + (ICC) environments, below points capture the gaps in existing MPLS + MIB modules for managing the MPLS-TP networks. - IP based environment i. MPLS-TE-STD-MIB [RFC3812] does not support tunnel Ingress/Egress identifier based on Global_ID and Node_ID - [MPLS-TP-IDENTIFIERS]. + [RFC6370]. ii. MPLS-TE-STD-MIB [RFC3812] does not support co-routed/associated bidirectional tunnel configurations. - ICC based environment i. MPLS-TE-STD-MIB [RFC3812] does not support tunnel LSR identifier based on ICC. - ii. MPLS tunnel does not support forwarding other than the nexthop - IP address. 5.1.2 Recommendations - New MIB definitions may be created for Global_Node_ID and/or ICC configurations. - MPLS-LSR-STD-MIB [RFC3813] MIB modules may be enhanced to identify the nexthop based on MAC address for IP-less environments. OutSegment may be extended to hold the MAC-address also for IP-less environments. @@ -698,52 +698,46 @@ extensions for co-routed/associated bidirectional LSPs. 5.2 MPLS-TP Pseudowire 5.2.1 Gap Analysis MPLS-TP Pseudowire can be operated over IP and/or ICC environments, below points capture the gaps in existing PW MIB modules for managing the MPLS-TP networks. - [MPLS-TP-IDENTIFIERS] specifies an initial set of identifiers to be + [RFC6370] specifies an initial set of identifiers to be used in MPLS-TP. These identifiers were chosen to be compatible with existing MPLS, GMPLS, and PW definitions. - IP based environment i. PW-STD-MIB [RFC5601] does not support PW end point identifier based on Global_ID and Node_ID. ii. PW-MPLS-STD-MIB [RFC5602] does not support its operation over co-routed/associated bidirectional tunnels. - ICC based environment i. PW-STD-MIB [RFC5601] does not support PW end point identifier based on ICC. - ii. Pseudowire does not support forwarding other - than the nexthop IP address. 5.2.2 Recommendations - PW-MPLS-STD-MIB [RFC5602] can be enhanced to operate over co-routed/associated bi-directional tunnel. - - Pseudowire 129 FEC type-2 can be used in non-IP and IP - environments with the required changes. - 5.3 MPLS-TP Sections 5.3.1 Gap Analysis The existing MPLS MIB modules does not support MPLS-TP sections. 5.3.2 Recommendations - Link specific and/or path/segment specific sections can be achieved by enhancing the IF-MIB [RFC2863], MPLS-TE-STD-MIB [RFC3812] and PW-STD-MIB [RFC5601] MIB modules. 5.4 MPLS-TP OAM 5.4.1 Gap Analysis MPLS manages the LSP and pseudowire faults through LSP ping [RFC4379], VCCV [RFC5085], BFD for LSPs [RFC5884] and BFD for VCCV @@ -779,36 +773,35 @@ available. 5.5.2 Recommendations New MIB modules can be created to address all the gaps mentioned in the 5.5.1 Gap Analysis section. 5.6 MPLS-TP Interfaces 5.6.1 Gap Analysis - - As per [MPLS-TP-IDENTIFIERS], an LSR requires identification of the + As per [RFC6370], an LSR requires identification of the node itself and of its interfaces. An interface is the attachment point to a server layer MPLS-TP section or MPLS-TP tunnel. The MPLS MIB modules do not provide support for configuring the interfaces within the context of an operator. 5.6.2 Recommendations New MIB definitions can be created to address the gaps mentioned in the 5.6.1 Gap Analysis section. 6. An Introduction to the MPLS-TP MIB Modules - This section highlights new MIB modules that have been identified + This section highlights MIB modules that have been identified as being required for MPLS-TP. This section also provides an overview of the following: - the MPLS Object Identifier (OID) tree structure and the position of different MPLS related MIB modules on this tree; - the purpose of each of the MIB modules within the MIB documents, what it can be used for, and how it relates to the other MIB modules. @@ -819,60 +812,60 @@ define the MIB modules or in separate Applicability Statements, will define which Compliance Statements need to be conformed to in order to provide specific MPLS-TP function. This document does not set any requirements in that respect although some recommendations are included in the sections that follow. 6.1 MPLS-TP MIB Modules 6.1.1 Structure of the MPLS-TP MIB OID Tree - The MPLS-TP MIB OID tree has the following structure. + The MPLS-TP MIB OID tree as proposed in [MPLS-TP-TE-MIB] has the + following structure: transmission -- RFC 2578 [RFC2578] | +- mplsStdMIB | +- Textual Conventions for MPLS-TP | +- Identifiers for MPLS-TP | +- LSR MIB Extensions for MPLS-TP | +- TE MIB Extensions for MPLS-TP - Note that the MIB modules mentioned here are applicable + Note that the MIB modules described above are applicable for MPLS operations as well. Note: The OIDs for MIB modules are yet to be assigned and managed by IANA. 6.1.2 Textual Conventions for MPLS-TP - A new textual convention MIB module will define textual - conventions [RFC2579] for MPLS-TP related MIB modules. - These conventions allow multiple MIB modules to use the - same syntax and format for a concept that is shared between - the MIB modules. + A new MIB module needs to be written that will define textual + conventions [RFC2579] for MPLS-TP related MIB modules. These + conventions allow multiple MIB modules to use the same syntax and + format for a concept that is shared between the MIB modules. For example, MEP identifier is used to identify maintenance entity group end point within MPLS-TP networks. The textual convention representing the MEP identifier should be defined in a new textual convention MIB module. All new extensions related to MPLS-TP are defined in the MIB module and will be referenced by other MIB modules to support MPLS-TP. 6.1.3 Identifiers for MPLS-TP New Identifiers describe managed objects that are used to model - common MPLS-TP identifiers [MPLS-TP-IDENTIFIERS]. + common MPLS-TP identifiers [RFC6370]. 6.1.4 LSR MIB Extensions for MPLS-TP MPLS-LSR-STD-MIB describes managed objects for modeling an MPLS Label Switching Router (LSR). This puts it at the heart of the management architecture for MPLS. In the case of MPLS-TP, the MPLS-LSR-STD-MIB is extended to support the MPLS-TP LSP's, which are co-routed or associated bidirectional. This extended MIB is also applicable for modeling MPLS-TP tunnels. @@ -905,31 +897,32 @@ | +- Pseudowire Textual Conventions for MPLS-TP Note: The OIDs for MIB modules are yet to be assigned and managed by IANA. 6.2.2 Pseudowire Textual Conventions for MPLS-TP PW-TC-STD-MIB MIB defines textual conventions used for pseudowire (PW) technology and for Pseudowire Edge-to-Edge Emulation (PWE3) MIB - Modules. A new textual convention MIB module will define textual - definitions for MPLS-TP specific Pseudowire attributes. + Modules. A new textual convention MIB module is required to define + textual definitions for MPLS-TP specific Pseudowire attributes. 6.2.3 Pseudowire Extensions for MPLS-TP PW-STD-MIB describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. This MIB module is extended to support MPLS-TP specific attributes related to Pseudowires. 6.2.4 Pseudowire MPLS Extensions for MPLS-TP + PW-MPLS-STD-MIB defines the managed objects for Pseudowire operations over MPLS LSR's. This MIB supports both, manual and dynamically signaled PW's, point-to-point connections, enables the use of any emulated service, MPLS-TE as outer tunnel and no outer tunnel as MPLS-TE. The newly extended MIB defines the managed objects, extending PW-MPLS-STD-MIB, by supporting with or without MPLS-TP as outer tunnel. @@ -948,31 +941,32 @@ | +- OAM MIB module Note: The OIDs for MIB modules are yet to be assigned and managed by IANA. 6.3.2 BFD MIB module BFD-STD-MIB defines managed objects for performing BFD operation in IP networks. This MIB is modeled to support BFD protocol [RFC5880]. - A new MIB module will be an extension to BFD-STD-MIB managed objects - to support BFD operations on MPLS LSPs and PWs. + A new MIB module needs to be written that will be an extension to + BFD-STD-MIB managed objects to support BFD operations on MPLS LSPs + and PWs. 6.3.3 Common OAM MIB modules - A new MIB module will define managed objects for OAM maintenance - identifiers i.e. Maintenance Entity Group Identifiers (MEG), - Maintenance Entity Group End-point (MEP), Maintenance Entity Group - Intermediate Point (MIP). Maintenance points are uniquely - associated with a MEG. Within the context of a MEG, MEPs and MIPs - must be uniquely identified. + A new MIB module needs to be written that will define managed objects + for OAM maintenance identifiers i.e. Maintenance Entity Group + Identifiers (MEG), Maintenance Entity Group End-point (MEP), + Maintenance Entity Group Intermediate Point (MIP). Maintenance points + are uniquely associated with a MEG. Within the context of a MEG, MEPs + and MIPs must be uniquely identified. 6.4. Protection Switching and Recovery MIB Modules for MPLS-TP This section provides an overview of protection switching and recovery MIB modules for MPLS LSPs and Pseudowires. 6.4.1 Structure of the MPLS Protection Switching and Recovery MIB OID Tree for MPLS-TP mib-2 -- RFC 2578 [RFC2578] @@ -983,32 +977,32 @@ | +- Ring Protection Switching MIB module | +- Mesh Protection Switching MIB module Note: The OIDs for MIB modules are yet to be assigned and managed by IANA. 6.4.2 Linear Protection Switching MIB module - A new MIB module will define managed objects for linear protection - switching of MPLS LSPs and Pseudowires. + A new MIB module needs to be written that will define managed objects + for linear protection switching of MPLS LSPs and Pseudowires. 6.4.3 Ring Protection Switching MIB module - A new MIB module will defined managed objects for ring protection + A new MIB module will define managed objects for ring protection switching of MPLS LSPs and Pseudowires. 6.4.4 Mesh Protection Switching MIB module - A new MIB module will defined managed objects for Mesh protection - switching of MPLS LSPs and Pseudowires. + A new MIB module needs to be written that will define managed objects + for Mesh protection switching of MPLS LSPs and Pseudowires. 7. Management Options This document applies only to scenarios where MIB modules are used to manage the MPLS-TP network. It is not the intention of this document to provide instructions or advice to implementers of management systems, management agents, or managed entities. It is, however, useful to make some observations about how the MIB modules described above might be used to manage MPLS systems, if SNMP is used in the management interface. @@ -1235,46 +1229,48 @@ RFC5885, June 2010. [RFC5950] Gray, E., Mansfield, S., Lam, K., "MPLS-TP Network Management Framework", RFC 5950, September 2010. [RFC5951] Gray, E., Mansfield, S., Lam, K., "MPLS TP Network Management Requirements", RFC 5951, September 2010. - [MPLS-TP-IDENTIFIERS] Bocci, M., Swallow, G., Gray, E., - "MPLS-TP Identifiers" draft-ietf-mpls-tp-identifiers-07, - July 2011 and Winter, R., Van Helvoort, H., Betts, M., - "MPLS-TP Identifiers Following ITU-T Conventions" - draft-ietf-mpls-tp-itu-t-identifiers-00, July 2011. + [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport + Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. [MPLS-TP-OAM-FWK] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and Overview", 2009, . + [MPLS-TP-TE-MIB] Venkatesan, M., Sampath, Kannan KV., Nadeau, T., + Aldrin, S., "MPLS-TP Traffic Engineering (TE) + Management Information Base (MIB)", 2011, + . + 12. Authors' Addresses Adrian Farrel Old Dog Consulting UK Email: adrian@olddog.co.uk Daniel King Old Dog Consulting UK Email: daniel@olddog.co.uk Venkatesan Mahalingam Aricent India - Email: venkatesan.mahalingam@aricent.com + Email: venkat.mahalingams@gmail.com Scott Mansfield Ericsson 300 Holger Way, San Jose, CA 95134, US Phone: +1 724 931 9316 Email: scott.mansfield@ericsson.com Jeong-dong Ryoo ETRI 161 Gajeong, Yuseong, Daejeon, 305-700, South Korea Phone: +82 42 860 5384