--- 1/draft-ietf-mpls-mgmt-overview-06.txt 2006-02-05 00:41:50.000000000 +0100 +++ 2/draft-ietf-mpls-mgmt-overview-07.txt 2006-02-05 00:41:50.000000000 +0100 @@ -1,23 +1,24 @@ Network Working Group Thomas D. Nadeau Internet Draft Cisco Systems, Inc. Category: Informational -Expires: November 2003 Cheenu Srinivasan +Expires: December 2003 Cheenu Srinivasan + Bloomberg L.P. Adrian Farrel - Movaz Networks, Inc. + Old Dog Consulting - June 2003 + July 2003 Multiprotocol Label Switching (MPLS) Management Overview - draft-ietf-mpls-mgmt-overview-06.txt + draft-ietf-mpls-mgmt-overview-07.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. 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 @@ -37,91 +38,92 @@ 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. - This memo describes the management architecture for MPLS + This document describes the management architecture for MPLS and indicates the inter-relationships between the different MIB modules used for MPLS network management. Table of Contents 1. Introduction 3 2. Terminology 3 3. The SNMP Management Framework 4 4. An Introduction to the MPLS Working Group MIB Modules 4 4.1. Structure of the MPLS MIB OID Tree 5 4.2. MPLS-TC-STD-MIB 5 4.3. MPLS-LSR-STD-MIB 5 4.4. MPLS-LDP-STD-MIB 6 4.5. MPLS-LDP-GENERIC-STD-MIB 6 4.6. MPLS-LDP-ATM-STD-MIB 6 4.7. MPLS-LDP-FRAME-RELAY-STD-MIB 7 4.8. MPLS-TE-STD-MIB 7 4.9. MPLS-FTN-STD-MIB 7 4.10. TE-LINK-STD-MIB 7 4.11. MIB Module Interdependencies 8 - 4.12. Dependencies on External MIB Modules 8 + 4.12. Dependencies on External MIB Modules 9 5. Tables, Scalars and Notifications in MPLS-LSR-STD-MIB 9 5.1. Tables 9 5.2. Scalars 10 - 5.3. Notifications 10 - 5.4. Dependencies Between MIB Module Tables 10 - 6. Tables, Scalars and Notifications in the LDP MIB 11 - 6.1. MIB Modules 11 - 6.2. Tables 11 - 6.3. Scalars 12 - 6.4. Notifications 12 - 6.5. Dependencies Between MIB Module Tables 13 - 7. Tables, Scalars and Notifications in MPLS-TE-STD-MIB 13 - 7.1. Tables 13 - 7.2. Scalars 14 - 7.3. Notifications 15 - 7.4. Dependencies Between MIB Module Tables 15 - 8. Tables, Scalars and Notifications in MPLS-FTN-STD-MIB 15 - 8.1. Tables 15 - 8.2. Scalars 16 - 8.3. Notifications 16 - 8.4. Dependencies Between MIB Module Tables 16 - 9. Tables and Objects in TE-LINK-STD-MIB 16 - 9.1. Tables 16 - 9.2. Scalars 17 - 9.3. Notifications 17 - 9.4. Dependencies Between MIB Module Tables 17 - 10. Table Dependencies Between MPLS MIB Modules 18 - 11. A Note on Interfaces 18 - 11.1. MPLS Tunnels as Interfaces 18 - 11.2. Application of the Interfaces Group to TE Links 19 - 11.3. References to Interface MIB Objects from MPLS MIB Modules 20 - 12. Management Options 21 - 13. Related IETF MIB Modules 22 - 13.1. pwe3 Working Group MIB Modules 22 - 13.2. ppvpn Working Group MIB Modules 22 - 13.2.1. PPVPN-MPLS-VPN-STD-MIB 22 - 13.3. ccamp Working Group MIB Modules 23 - 14. Traffic Engineering Working Group TE MIB 23 - 14.1. Choosing Between TE MIB Modules 23 - 15. Security Considerations 24 - 16. Acknowledgements 25 - 17. Intellectual Property Consideration 25 - 18. Normative References 25 - 19. Informative References 26 - 20. Authors' Addresses 28 - 21. Full Copyright Statement 28 + 5.3. Indexing 10 + 5.4. Notifications 11 + 5.5. Dependencies Between MIB Module Tables 12 + 6. Tables, Scalars and Notifications in the LDP MIB 12 + 6.1. MIB Modules 12 + 6.2. Tables 12 + 6.3. Scalars 13 + 6.4. Notifications 14 + 6.5. Dependencies Between MIB Module Tables 14 + 7. Tables, Scalars and Notifications in MPLS-TE-STD-MIB 15 + 7.1. Tables 15 + 7.2. Scalars 16 + 7.3. Notifications 16 + 7.4. Dependencies Between MIB Module Tables 16 + 8. Tables, Scalars and Notifications in MPLS-FTN-STD-MIB 17 + 8.1. Tables 17 + 8.2. Scalars 17 + 8.3. Notifications 17 + 8.4. Dependencies Between MIB Module Tables 17 + 9. Tables and Objects in TE-LINK-STD-MIB 17 + 9.1. Tables 17 + 9.2. Scalars 18 + 9.3. Notifications 18 + 9.4. Dependencies Between MIB Module Tables 18 + 10. Table Dependencies Between MPLS MIB Modules 19 + 11. A Note on Interfaces 19 + 11.1. MPLS Tunnels as Interfaces 19 + 11.2. Application of the Interfaces Group to TE Links 20 + 11.3. References to Interface MIB Objects from MPLS MIB Modules 21 + 12. Management Options 22 + 13. Related IETF MIB Modules 23 + 13.1. pwe3 Working Group MIB Modules 23 + 13.2. ppvpn Working Group MIB Modules 23 + 13.2.1. PPVPN-MPLS-VPN-STD-MIB 23 + 13.3. ccamp Working Group MIB Modules 24 + 14. Traffic Engineering Working Group TE MIB 24 + 14.1. Choosing Between TE MIB Modules 24 + 15. Security Considerations 25 + 16. Acknowledgements 26 + 17. Intellectual Property Consideration 26 + 18. Normative References 26 + 19. Informative References 27 + 20. Authors' Addresses 29 + 21. Full Copyright Statement 29 1. Introduction - This memo describes the Management Architecture for Multi- + This document describes the Management Architecture for Multi- Protocol Label Switching (MPLS) [RFC3031]. In particular, it describes how the managed objects defined in various MPLS related Management Information Base (MIB) documents model different aspects of MPLS. Furthermore, this document explains the interactions and dependencies between each of these MIB modules. For additional information, this document also includes a brief note on MIB modules produced by the Pseudo Wire Emulation Edge to Edge (pwe3), Provider Provisioned Virtual @@ -161,24 +163,24 @@ 3. The SNMP Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the - Structure of Management Information (SMI). This memo specifies a MIB - module that is compliant to the SMIv2, which is described in STD 58, - RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 - [RFC2580]. + Structure of Management Information (SMI). This document specifies a + MIB module that is compliant to the SMIv2, which is described in + STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, + RFC 2580 [RFC2580]. 4. An Introduction to the MPLS Working Group MIB Modules This section addresses the MIB documents produced by the MPLS working group, namely MPLS TC MIB, MPLS LSR MIB, MPLS TE MIB, MPLS LDP MIB, MPLS FTN MIB, and TE LINK MIB. The rest of this section briefly describes the following: - the MPLS Object Identifier (OID) tree structure and the position of different MPLS related MIB modules on this tree; @@ -232,21 +234,21 @@ For example, labels are a central part of MPLS and need to be presented in many of the MIB modules. The textual convention for representing an MPLS label is defined in MPLS-TC-STD-MIB. All of the other MPLS MIB modules import textual convetions from this MIB module. 4.3. MPLS-LSR-STD-MIB - MPLS-LSR-STD-MIB describes managed objects for modeling a MPLS + 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. This MIB module is used to model and manage the basic label switching behavior of an MPLS LSR. It represents the label forwarding information base (LFIB) of the LSR and provides a view of the LSPs that are being switched by the LSR in question. Since basic MPLS label switching is common to all MPLS @@ -256,32 +258,32 @@ In general, MPLS-LSR-STD-MIB provides a model of incoming labels on MPLS-enabled interfaces being mapped to outgoing labels on MPLS-enabled interfaces via a conceptual object called an MPLS cross-connect. MPLS cross-connect entries and their properties are represented in MPLS-LSR-STD-MIB and are typically referenced by other MIB modules in order to refer to the underlying MPLS LSP. For example, MPLS-TE-STD-MIB models traffic engineered tunnels. These tunnels map to one or more underlying MPLS LSPs. - MPLS-TE-STD-MIB refers to the underlying LSP by pointing to + MPLS-TE-STD-MIB refers to the underlying LSPs by pointing to cross-connect entries in MPLS-LSR-STD-MIB. 4.4. MPLS-LDP-STD-MIB MPLS-LDP-STD-MIB describes managed objects used to model and manage the MPLS Label Distribution Protocol (LDP) [RFC3036]. LDP is one of the MPLS protocols used to distribute labels and establish LSPs. This MIB module contains objects common to all LDP - implementations. For an LDP implementation, that provides + implementations. For an LDP implementation that provides standard MIB support, this MIB module provides the core set of objects that are needed along with one or more of the other LDP MIB modules from the following sections. 4.5. MPLS-LDP-GENERIC-STD-MIB This MIB module provides objects for managing the LDP Per Platform Label Space and is typically implemented along with the MPLS-LDP-STD-MIB module. This MIB Module contains tables for configuring MPLS Generic Label Ranges. Although @@ -304,300 +306,363 @@ as the Layer 2 medium. Tables in this MIB module allow for configuration of LDP to use Frame Relay. 4.8. MPLS-TE-STD-MIB MPLS-TE-STD-MIB describes managed objects that are used to model and manage MPLS Traffic Engineered (TE) Tunnels. This MIB module is based around a table that represents TE tunnels that either originate from, traverse via or - terminate on the LSR in question or. The MIB module - provides configuration and statistics objects needed for TE - tunnels. + terminate on the LSR in question. The MIB module provides + configuration and statistics objects needed for TE tunnels. 4.9. MPLS-FTN-STD-MIB MPLS-FTN-STD-MIB describes managed objects that are used to model and manage the MPLS FEC-to-NHLFE (FTN) mappings that take place at an ingress Label Edge Router (LER). - A LER is an LSR placed at the edge of an MPLS domain and + An LER is an LSR placed at the edge of an MPLS domain, and passes traffic into and out of the MPLS domain. An ingress LER is responsible for classifying data and assigning it to - a suitable LSP. + a suitable LSP or tunnel. - This classification is done using Forwarding Equivalency + This classification is done using Forwarding Equivalence Classes (FECs) that define the common attributes of data (usually packets) that will be treated in the same way. Once data has been classified it can be handed off to an - LSP through the Next Hop Label Forwarding Entry (NHLFE). + LSP or tunnel through the Next Hop Label Forwarding Entry + (NHLFE). In the case of an IP-to-MPLS mapping, the FEC objects describe IP 6-tuples representing source and destination address ranges, source and destination port ranges, IPv4 Protocol field or IPv6 next-header field and the DiffServ Code Point (DSCP). 4.10. TE-LINK-STD-MIB TE-LINK-STD-MIB describes managed objects that are used to model and manage TE links, including bundled links, in an MPLS network. The TE link feature is designed to aggregate one or more similar data channels or TE links between a pair of LSRs. A TE link - and is a sub-interface capable of carrying traffic engineered - MPLS traffic. + is a sub-interface capable of carrying traffic engineered MPLS + traffic. A bundled link is a sub-interface that bonds the traffic of - a group of one or more TE links." + a group of one or more TE links. 4.11. MIB Module Interdependencies This section provides an overview of the relationship between the MPLS MIB modules described above. More details of these relationships are given below once the MIB modules have been discussed in more detail. The arrows in the following diagram show a 'depends on' relationship. A "MIB module A depends on MIB module B" relationship means that MIB module A uses a structure or textual convention defined in MIB module B, or that MIB module A contains a pointer (index or RowPointer) to an object in MIB module B. +-------> MPLS-TC-STD-MIB | ^ | | - | MPLS-LSR-STD-MIB <-----------------+ + | MPLS-LSR-STD-MIB <------------------+ | | - +<------- MPLS-LDP-STD-MIB ----------------->+ + +<----------------------- MPLS-LDP-STD-MIB -->+ | ^ | | | | - | +<-- MPLS-LDP-GENERIC-STD-MIB | + +<-- MPLS-LDP-GENERIC-STD-MIB ------>+ | | | | - | +<-- MPLS-LDP-ATM-STD-MIB | + +<-- MPLS-LDP-ATM-STD-MIB ---------->+ | | | | - | +<-- MPLS-LDP-FRAME-RELAY-STD-MIB | + +<-- MPLS-LDP-FRAME-RELAY-STD-MIB -->+ | | | - +<------- MPLS-TE-STD-MIB ------------------>+ + +<------- MPLS-TE-STD-MIB ------------------->+ | ^ | | | | - +<------- MPLS-FTN-STD-MIB ----------------->+ + +<------- MPLS-FTN-STD-MIB ------------------>+ Thus: - All the MPLS MIB modules depend on MPLS-TC-STD-MIB. - MPLS-LDP-STD-MIB, MPLS-TE-STD-MIB and MPLS-FTN-STD-MIB contain references to objects in MPLS-LSR-STD-MIB. - MPLS-LDP-GENERIC-STD-MIB, MPLS-LDP-ATM-STD-MIB and MPLS-LDP- FRAME-RELAY-STD-MIB contain references to objects in MPLS- LDP-STD-MIB. - MPLS-FTN-STD-MIB contains references to objects in MPLS-TE- STD-MIB. + Note that there is a textual convention (MplsIndexType) defined + in MPLS-LSR-STD-MIB that is imported by MPLS-LDP-STD-MIB. + 4.12. Dependencies on External MIB Modules With the exception of MPLS-TC-STD-MIB, all the MPLS MIB modules have dependencies on the Interfaces MIB [RFC2863]. MPLS-FTN-STD-MIB references IP-capable interfaces on which received traffic is to be classified using indexes in the Interface Table (ifTable) of - this MIB module. The other MPLS MIB modules reference MPLS- + IF-MIB [RFC2863]. The other MPLS MIB modules reference MPLS- capable interfaces in ifTable. The Interfaces Group of the IF-MIB [RFC2863] defines generic managed objects for managing interfaces. The MPLS MIB modules contain media-specific extensions to the Interfaces Group for managing MPLS interfaces. The MPLS MIB modules assume the interpretation of the Interfaces Group to be in accordance with [RFC2863] which states that ifTable contains information on the managed resource's interfaces and that each sub-layer below the internetwork layer of a network interface is considered an - interface. - - Thus, the MPLS interface is represented as an entry in - ifTable. + interface. Thus, the MPLS interface is represented as an + entry in ifTable. The inter-relation of entries in ifTable is defined by the Interfaces Stack Group defined in [RFC2863]. + Additionally, MPLS-LDP-ATM-STD-MIB imports the textual convention + AtmVpIdentifier from ATM-TC-MIB to represent an ATM virtual path + identifier, while MPLS-LDP-FRAME-RELAY-STD-MIB imports the textual + convention DLCI from FRAME-RELAY-DTE-MIB to represent a Data + Link Channel identifier. + + 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. This is business + as usual for a MIB module and is not discussed further in + this document. + 5. Tables, Scalars and Notifications in MPLS-LSR-STD-MIB 5.1. Tables MPLS-LSR-STD-MIB contains the following tables. - - The interface configuration table - (mplsInterfaceConfTable) is used for enabling MPLS on - MPLS-capable interfaces. + - The interface configuration table (mplsInterfaceTable) + is used for enabling MPLS on MPLS-capable interfaces. - The in-segment (mplsInSegmentTable) and out-segment (mplsOutSegmentTable) tables are used to configure and monitor LSP segments carrying data into and out of the LSR, respectively. + - The in-segment mapping table (mplsInSegementMapTable) + provides a look-up table that enables the discovery of + an in-segment in mplsInSegmentTable from the known + incoming interface and incoming label. + - The cross-connect table (mplsXCTable) is used to associate in and out segments in order to form a cross- connect (i.e. to represent an LSP transiting the LSR). - The label stack table (mplsLabelStackTable) allows the specification of multi-label stacks to be imposed on a given LSP at this LSR - The Traffic Parameter table (mplsTrafficParamTable) is - used to specify and record LSP related traffic - parameters. + used to specify and record LSP related traffic parameters. - The MPLS in-segment (mplsInSegmentPerfTable) and out- segment (mplsOutSegmentPerfTable) performance tables contain objects to measure the performance of LSPs. - - The MPLS interface performance table - (mplsInterfacePerfTable) has objects to measure MPLS - performance on a per-interface basis. + - The MPLS interface performance table (mplsInterfacePerfTable) + has objects to measure MPLS performance on a per-interface basis. 5.2. Scalars - Where tables in the MIB module have arbitrary indexes, - scalars are provided to supply the next available index. - This applies to mplsOutSegmentTable, mplsXCTable, - mplsLabelStackTable and mplsTrafficParamTable. + Where tables in the MIB module have arbitrary indexes, scalars are + provided to supply the next available index. This applies to + mplsInSegmentTable, mplsOutSegmentTable, mplsXCTable, + mplsLabelStackTable and mplsTrafficParamTable, but see the section + on indexing, below. - mplsMaxLabelStackDepth defines the maximum size of a - imposed label stack supported at this LSR. + mplsMaxLabelStackDepth defines the maximum size of a imposed label + stack supported at this LSR (and not, as the description in + MPLS-LSR-STD-MIB states, the maximum label stack depth supported by + the LSR). - mplsXCTrapEnable is used to enable and disable - notifications from MPLS-LSR-STD-MIB. + mplsXCNotificationsEnable is used to enable and disable notifications + from MPLS-LSR-STD-MIB. -5.3. Notifications +5.3. Indexing + + Note that the indexing used by the tables in MPLS-LSR-STD-MIB is + unusual. A specific textual convention, MplsIndexType, is defined + in the MIB module and is used as the type for indexes to + mplsInSegmentTable, mplsOutSegmentTable, mplsXCTable and + mplsLabelStackTable. The textual convention is defined as an + octet string of between one and twenty four octets inclusive. + + While this convention can be used to map simple integers and so + preserve the normal indexing techniques, it may also be used to + encode more complex indexing rules that may be useful to + implementations that subdivide their label spaces according to + physical or implementation constraints (such as placing the + responsibility for a subset of labels with a line card). + + Note that it would be unusual, but not impossible, to make + sophisticated use of these indexes in a write-access MIB since + it would be hard to determine the 'next' index value. Thus, + non-simple values are likely only to be used in read-only MIBs + where the indexes are generated as a reuslt of signaling protocol + implementations or other configuration means. The formatting and + interpretation of non-simple indexes is out of the scope of the + MIB module definition and is expected to be part of the + manageability statement for a particualr device. When the + formatting is not known by an agent, it should treat the index as + a plain octet string containing an integer of between one and twenty + four octets. + + As described in the previous section, scalars are provided to + allow agents to discover a suitable value to use as an index when + creating a new row in one of these tables. These scalars all use + a second textual convention, MplsIndexNextType, also defined within + MPLS-LSR-STD-MIB. This textual convention allows the 'null string', + that is a string of length one octet with value 0x00. The null string + is used to indicate that either write access is not supported or no + more indexes are currently available. + + Note that the usage of the nextIndex scalars is such that at any time + a scalar supplies a value that is currently unused as an index to the + specific table. In order to avoid lacunae in the indexing of a table + under normal usage, implementations are recommended to only change + the value in an nextIndex scalar when the index is used (that is, + when a row is created) and not when the nextIndex scalar is read. In + a 'busy' table this may result in row creation attempts failing and + agents having to re-read the scalar before making a second row + creation attempt. The desire to avoid this issue is in oposition to + the desire to avoid lacunae. + +5.4. Notifications MPLS-LSR-STD-MIB can issue two notifications (if notifications are enabled). - mplsXCUp reports when a cross-connect becomes active. - mplsXCDown reports when a cross-connect becomes inactive. -5.4. Dependencies Between MIB Module Tables +5.5. Dependencies Between MIB Module Tables The tables in MPLS-LSR-STD-MIB are related as shown on the diagram below. The arrows indicate a reference from one table to another. mplsInterfacePerfTable ^ | - mplsInterfaceConfTable + V + mplsInterfaceTable ^ ^ - | | - +----+ +----+ - | | - | mplsTrafficParamTable | mplsLabelStackTable - | ^ ^ | ^ - | | | | | + mplsInSegmentMapTable | | mplsLabelStackTable + | | | ^ + | +----+ +----+ | + | | | | + | | mplsTrafficParamTable | | + | | ^ ^ | | + V | | | | | mplsInSegmentTable mplsOutSegmentTable + ^ ^ ^ ^ | | | | | +----> mplsXCTable <----+ | V V mplsInSegmentPerfTable mplsOutSegmentPerfTable 6. Tables, Scalars and Notifications in the LDP MIB 6.1. MIB Modules The MIB document for LDP contains four MIB modules. This structure makes it easier for an implementation to select only those modules that are relevant to it. The MIB Modules - are the MPLS-LDP-STD-MIB, the MPLS-LDP-GENERIC-STD-MIB, the MPLS- - LDP-ATM-STD-MIB and the MPLS-LDP-FRAME-RELAY-STD-MIB. + are MPLS-LDP-STD-MIB, MPLS-LDP-GENERIC-STD-MIB, MPLS-LDP- + ATM-STD-MIB and MPLS-LDP-FRAME-RELAY-STD-MIB. - The MPLS-LDP-STD-MIB defines objects which are specific to LDP - without any Layer 2 objects. The MPLS-LDP-GENERIC-STD-MIB + MPLS-LDP-STD-MIB defines objects which are specific to LDP + without any Layer 2 objects. MPLS-LDP-GENERIC-STD-MIB defines Layer 2 Per Platform Label Space objects for use - with the MPLS-LDP-STD-MIB and for use on Ehternet. The MPLS- - LDP-ATM-STD-MIB defines Layer 2 Asynchronous Transfer Mode - (ATM) objects for use with the MPLS-LDP-STD-MIB. The MPLS-LDP- - FRAME-RELAY-STD-MIB defines Layer 2 FRAME-RELAY objects for use - with the MPLS-LDP-STD-MIB. + with MPLS-LDP-STD-MIB and for use on Ehternet. MPLS-LDP-ATM- + STD-MIB defines Layer 2 Asynchronous Transfer Mode (ATM) + objects for use with MPLS-LDP-STD-MIB. MPLS-LDP-FRAME-RELAY- + STD-MIB defines Layer 2 FRAME-RELAY objects for use with + MPLS-LDP-STD-MIB. The MPLS-LDP-STD-MIB module provides the core support and is typically supported along with at least one of the Layer 2 MIB modules. 6.2. Tables The tables in the LDP MIB for configuring the LDP behavior of an LSR are as follows. - - The LDP Entity Table (mplsLdpEntityTable) provides a - way to configure the LSR for using LDP. There must be - at least one LDP Entity for the LSR to support LDP. - Each entry/row in this table represents a single LDP - Entity. + - The LDP Entity Table (mplsLdpEntityTable) provides a way to + configure the LSR for using LDP. There must be at least one LDP + Entity for the LSR to support LDP. Each entry/row in this table + represents a single LDP Entity. - - Several tables exist to help configure LDP's use of - labels. These are spread through the MIB modules - described in the previous section. They are: - mplsLdpEntityGenLRTable, mplsLdpEntityAtmParmsTable and - mplsLdpEntityAtmLRTable, - mplsLdpEntityFrameRelayParmsTable and - mplsLdpEntityFrLRTable. They are used to configure - generic, ATM and Frame Relay labels as their names - suggest. + - Several tables exist to help configure LDP's use of labels. These + are spread through the MIB modules described in the previous + section. They are: mplsLdpEntityGenLRTable, + mplsLdpEntityAtmParmsTable and mplsLdpEntityAtmLRTable, + mplsLdpEntityFrameRelayParmsTable and mplsLdpEntityFrLRTable. + They are used to configure generic, ATM and Frame Relay labels as + their names suggest. - - The LDP Peer Table (mplsLdpPeerTable) is a read-only - table, that contains information about LDP Peers known - to LDP Entities. + - The LDP Peer Table (mplsLdpPeerTable) is a read-only table, that + contains information about LDP Peers known to LDP Entities. - - The LDP Hello Adjacencies Table - (mplsLdpHelloAdjacencyTable) is a table of all - adjacencies between all LDP Entities and all LDP Peers. + - The LDP Hello Adjacencies Table (mplsLdpHelloAdjacencyTable) is a + table of all adjacencies between all LDP Entities and all LDP + Peers. - - Several tables exist to monitor and control LDP - sessions. The LDP Session Table (mplsLdpSessionTable) - represents sessions between an LDP Entity and a Peer. - The mplsLdpAtmSesTable and mplsLdpFrameRelaySesTable - contain session information specific to ATM. + - Several tables exist to monitor and control LDP sessions. The LDP + Session Table (mplsLdpSessionTable) represents sessions between an + LDP Entity and a Peer. mplsLdpAtmSesTable and + mplsLdpFrameRelaySesTable contain session information specific to + ATM. - - The MPLS LDP Session Peer Address Table - (mplsLdpSesPeerAddrTable) stores addresses learned - after session initialization via Address Message - advertisement. + - The MPLS LDP Session Peer Address Table (mplsLdpSesPeerAddrTable) + stores addresses learned after session initialization via Address + Message advertisement. - - The LDP FEC Table (mplsFecTable) represents FEC - (Forwarding Equivalence Class) information that may be - in use on one or more LSPs. The LDP LSP FEC Table - (mplsLdpLspFecTable) shows the FECs associated with - each LSP. + - The LDP FEC Table (mplsFecTable) represents FEC (Forwarding + Equivalence Class) information that may be in use on one or more + LSPs. The LDP LSP FEC Table (mplsLdpLspFecTable) shows the FECs + associated with each LSP. - - MPLS-LDP-STD-MIB has a mapping table (mplsLdpLspTable) - which maps the LDP MIB's representation of LDP sessions - to the underlying LSR MIB's representation of the LSPs - created by these sessions by pointing to - mplsInSegmentTable, mplsOutSegmentTable and + - MPLS-LDP-STD-MIB has a mapping table (mplsLdpLspTable) which maps + the LDP MIB's representation of LDP sessions to the underlying LSR + MIB's representation of the LSPs created by these sessions by + pointing to mplsInSegmentTable, mplsOutSegmentTable and mplsXCTable, respectively. - - Statistics may be gathered through the LDP Entity - Statistics Table (mplsLdpEntityStatsTable) and the LDP - Session Statistics Table (mplsLdpSesStatsTable) + - Statistics may be gathered through the LDP Entity Statistics Table + (mplsLdpEntityStatsTable) and the LDP Session Statistics Table + (mplsLdpSesStatsTable) 6.3. Scalars Where tables in the MIB modules have arbitrary indexes, scalars are provided to supply the next available index. - This applies to the mplsLdpEntityTable and the mplsFecTable. + This applies to mplsLdpEntityTable and mplsFecTable. Two scalars exist to configure the LSR. The LSR ID is set in mplsLdpLsrId, and the loop detection capabilities are reported in mplsLdpLsrLoopDetectionCapable 6.4. Notifications MPLS-LDP-STD-MIB defines four notifications that a device can issue. @@ -651,50 +716,49 @@ 7. Tables, Scalars and Notifications in MPLS-TE-STD-MIB 7.1. Tables MPLS-TE-STD-MIB contains the following tables. - The Tunnel table (mplsTunnelTable) is used to configure and report MPLS tunnels. Note that reporting of tunnels in this table at transit LSRs is optional. - Entries in the mplsTunnelTable are indexed by four + Entries in mplsTunnelTable are indexed by four objects. The source and destination LSR Ids give - context to the entry, and an index - (mplsTunnelIndexIndex) identifies the tunnel itself. - However, the fourth index (mplsTunnelInstance) may give - rise to some confusion since its usage is not clearly - explained. + context to the entry, and an index (mplsTunnelIndex) + identifies the tunnel itself. However, the fourth index + (mplsTunnelInstance) may give rise to some confusion since + its usage is not clearly explained. The description says: "Uniquely identifies an instance of a tunnel. It is useful to identify multiple instances of tunnels for the purposes of backup and parallel tunnels." In the case of backup tunnels, multiple instances of the same tunnel may be defined, but only one is active at any time. Different instances may have different properties (such as explicit routes), and one instance may be set up to protect against failure of another. Parallel tunnels may be used to provide load sharing or protection. The mplsTunnelInstancePriority object is used to indicate the precedence of tunnels with the same LSR - Ids and mplsTunnelIndexIndex value. The - mplsTunnelPrimaryInstance object gives a quick - reference back to the preferred instance of the tunnel. + Ids and mplsTunnelIndex value. The mplsTunnelPrimaryInstance + object gives a quick reference back to the preferred instance + of the tunnel. - The mplsTunnelIndexIndex value is typically signaled as + The mplsTunnelIndex value is typically signaled as the Tunnel ID, and the mplsTunnelInstance as the LSP Id in protocols where both fields exist. In protocols where there is only one identifying index (usually - known as the LSP Id), only the mplsTunnelIndexIndex is + known as the LSP Id), only the mplsTunnelIndex is signaled. - The Resource table (mplsTunnelResourceTable) is used to configure resources to be requested on this tunnel. The CRLDP resource table (mplsTunnelCRLDPResTable) is used to request additional resource details that are specific to tunnels signaled using CR-LDP. - The routes requested, computed and actually used for a tunnel are found in the Tunnel Hop Table @@ -703,76 +767,82 @@ (mplsTunnelARHopTable). - Statistics about the performance of tunnels may be gathered through the Tunnel Performance Table (mplsTunnelPerfTable). 7.2. Scalars Where tables in the MIB module have arbitrary indexes, scalars are provided to supply the next available index. This applies - to the mplsTunnelTable, the mplsTunnelResourceTable and the + to mplsTunnelTable, mplsTunnelResourceTable and mplsTunnelHopTable. Two scalars exist to configure the support for MPLS tunnels on the LSR. mplsTunnelTEDistProto lists the signaling methods and protocols supported. mplsTunnelMaxHops defines the size of route that may be configured on the LSR. Two further scalars enhance the statistics on the LSR by counting the number of configured (mplsTunnelConfigured) and active (mplsTunnelActive) tunnels. - The scalar mplsTunnelTrapEnable is used to enable and - disable notifications from MPLS-TE-STD-MIB. + The scalar mplsTunnelNotificationMaxRate is used to control the rate + at which notifications are issued from MPLS-TE-STD-MIB. A rate of + zero means that notifications must not be issued. If notifications + would be generated faster than the configured rate an implementation + may choose to discard notifications or queue them for distribution + at a quieter time. 7.3. Notifications MPLS-TE-STD-MIB defines four notifications that a device can - issue. + issue. The rate of despatch of notifications is controlled as + described in the previous section. - mplsTunnelUp and mplsTunnelDown report the transition of Tunnel state. - Rerouting and re-optimization of Tunnels paths are reported by mplsTunnelRerouted and mplsTunnelReoptimized. 7.4. Dependencies Between MIB Module Tables The tables in MPLS-TE-STD-MIB are related as shown on the diagram below. The arrows indicate a reference from one table to another. mplsTunnelPerfTable + ^ | V mplsTunnelTable - ^ ^ | | - mplsTunnelResourceTable +---mplsTunnelHopTable + V | + mplsTunnelResourceTable +--> mplsTunnelHopTable ^ | - | +---mplsTunnelCHopTable - mplsTunnelCRLDPResTable | - +---mplsTunnelARHopTable + | +--> mplsTunnelCHopTable + V | + mplsTunnelCRLDPResTable +--> mplsTunnelARHopTable 8. Tables, Scalars and Notifications in MPLS-FTN-STD-MIB 8.1. Tables MPLS-FTN-STD-MIB contains the following tables. - - The FEC to NHLFE Table (mplsFTNTable) defines the FEC + - The FEC-to-NHLFE Table (mplsFTNTable) defines the FEC to NHLFE rules to be applied to incoming packets, and the actions to be taken on matching packets. - - The FEC to NHLFE Map Table (mplsFTNMapTable) provides + - The FEC-to-NHLFE Map Table (mplsFTNMapTable) provides the capability to activate FTN rules defined in the mplsFTNTable on specific interfaces in the system. - Performance statistics for FTN rules are found in the mplsFTNPerfTable. 8.2. Scalars This MIB module contains the scalars mplsFTNTableLastChanged and mplsFTNMapTableLastChanged to indicate the last time an @@ -802,27 +872,25 @@ TE-LINK-STD-MIB contains the following tables. - The TE link table (teLinkTable) is used to specify TE links, including bundled links, and their generic traffic engineering parameters. - The TE link descriptor table (teLinkDescriptorTable) is used to list the TE link descriptors. - - The shared risk link group (SRLG) table - (teLinkSrlgTable) is used to specify the SRLGs - associated with TE links. + - The shared risk link group (SRLG) table (teLinkSrlgTable) is used + to specify the SRLGs associated with TE links. - - The TE link bandwidth table (teLinkBandwidthTable) is - used to report priority-based bandwidth values - associated with TE links. + - The TE link bandwidth table (teLinkBandwidthTable) is used to + report priority-based bandwidth values associated with TE links. - The component link table (componentLinkTable) is used to identify the data- bearing component links that are associated with the TE links and specify the data-bearing link generic traffic engineering parameters. - The component link descriptor table (componentLinkDescriptorTable) is used to list the data-bearing component link descriptors. @@ -892,21 +960,21 @@ The Interfaces Group of the IF-MIB [RFC2863] defines generic managed objects for managing interfaces. The MPLS MIB modules make references to interfaces in order that it can be clearly determined where the procedures managed by the MIB modules should be performed. Additionally, the MPLS MIB modules (notably MPLS-TE-STD-MIB and TE-LINK-STD-MIB) utilize interface stacking within the Interface Group. 11.1. MPLS Tunnels as Interfaces - The MPLS-TE-STD-MIB builds on the concept of managing MPLS + MPLS-TE-STD-MIB builds on the concept of managing MPLS Tunnels as logical interfaces. [RFC2863] states that the interfaces table (ifTable) contains information on the managed resource's interfaces, and that each sub-layer below the internetwork layer of a network interface is considered an interface. Thus, an MPLS Tunnel managed as an interface is represented as an entry in the ifTable. The interrelation of entries in the ifTable is defined by the Interfaces Stack Group defined in [RFC2863]. When using MPLS Tunnels as interfaces, the interface stack @@ -983,104 +1051,104 @@ Each TE Link interface is represented by a separate entry in the ifTable with a unique ifIndex. The type of an interface represented by an entry in the ifTable is indicated by the ifType object. The value that is allocated to identify a TE Link 200. 11.3. References to Interface MIB Objects from MPLS MIB Modules - The MPLS-TE-STD-MIB contains two objects that reference the + MPLS-TE-STD-MIB contains two objects that reference the management of an MPLS tunnel as an interface. mplsTunnelIsIf is a TRuthValue that indicates whether the tunnel is present in the ifTable. If the tunnel is managed as an interface, the mplsTunnelIfIndex object contains the ifIndex that identifies the corresponding entry in the ifTable. - The MPLS-LSR-STD-MIB includes a table (mplsInterfaceConfTable) + MPLS-LSR-STD-MIB includes a table (mplsInterfaceTable) for configuring the support for MPLS on specific interfaces. A conceptual row in this table is created automatically by an LSR for every interface that is capable of and configured for support of MPLS. A conceptual row in this table will exist if and only if a corresponding entry in ifTable exists with ifType = mpls(166). The fate of the entries in the two tables are closely linked so that if the entry in the ifTable is operationally disabled, the entry - in the mplsInterfaceConfTable is deleted. During the life - of an entry in the mplsInterfaceConfTable a corresponding - entry is managed in the mplsInterfacePerfTable to show + in mplsInterfaceTable is deleted. During the life + of an entry in mplsInterfaceTable a corresponding + entry is managed in mplsInterfacePerfTable to show performance counters for the MPLS-capable interface. The ifIndex that identifies MPLS-capable interfaces also - plays an important indexing role in the MPLS-LSR-STD-MIB. In- + plays an important indexing role in MPLS-LSR-STD-MIB. In- segments (that is incoming LSP labels) are represented in - the mplsInSegmentTable which is indexed by the + mplsInSegmentTable which is indexed by the mplsInSegmentIfIndex and mplsInSegmentLabel objects. mplsInSegmentIfIndex is set to the ifIndex of the incoming MPLS-capable interface. mplsInSegmentLabel identifies the incoming MPLS label. Note that the corresponding mplsOutSegmentTable contains an mplsOutSegmentIfIndex object to identify the outgoing MPLS-capable interface, but that this does not form part of the index of the table. - The MPLS-LDP-STD-MIB use ifIndex extensively to identify the + MPLS-LDP-STD-MIB use ifIndex extensively to identify the interface over which MPLS is active. - Within the MPLS-FTN-STD-MIB, the mplsFTNMapTable maps entries - in the mplsFTNTable to interfaces on which the mplsFTNTable + Within MPLS-FTN-STD-MIB, mplsFTNMapTable maps entries + in mplsFTNTable to interfaces on which mplsFTNTable entries should be used. Interfaces are identified using their ifIndex values. 12. Management Options It is not the intention of this document to provide instructions or advice to implementers of Management Stations, 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. - All MPLS LSPs may appear in the MPLS-LSR-STD-MIB. At transit + All MPLS LSPs may appear in MPLS-LSR-STD-MIB. At transit nodes they are seen as full cross-connects between incoming labels on incoming interfaces and outgoing labels on outgoing interfaces. At ingress or egress points the cross- connections are unbalanced having spoof upstream or downstream legs respectively. Split and merge points of LSPs may be represented as more - complex cross-connects in the MPLS-LSR-STD-MIB. Similarly, + complex cross-connects in MPLS-LSR-STD-MIB. Similarly, bidirectional LSPs can be represented by using the same cross-connect index for each of the forward and reverse cross-connections. The modules in the LDP MIB are intended solely for use with LDP and CR-LDP. LSPs that are signaled through other means - may conveniently be stored in the mplsLdpLspTable for + may conveniently be stored in mplsLdpLspTable for consistency with LSPs set up using LDP, but there is little further value to this since the table gives only pointers - into the MPLS-LSR-STD-MIB. If, however, the LSPs are + into MPLS-LSR-STD-MIB. If, however, the LSPs are established with associated FECs using some signaling method other than LDP (for example, BGP) it may be - advantageous to use the mplsLdpLspTable, mplsFecTable and + advantageous to use mplsLdpLspTable, mplsFecTable and mplsLdpLspFecTable to correlate the LSPs. Note that if CR-LDP is the signaling protocol there is no requirement to use the LSP-related tables in the LDP MIB - since the LSP will be adequately represented in the MPLS-TE- - MIB and the MPLS-LSR-STD-MIB. + since the LSP will be adequately represented in MPLS-TE- + MIB and MPLS-LSR-STD-MIB. - MPLS tunnels may be represented in the MPLS-TE-STD-MIB with - their cross-connects indicated in the MPLS-LSR-STD-MIB. + MPLS tunnels may be represented in MPLS-TE-STD-MIB with + their cross-connects indicated in MPLS-LSR-STD-MIB. Tunnels are often (although not always) set up with a - series of constraints that may be represented in the MPLS- + series of constraints that may be represented in MPLS- TE-STD-MIB. Note that a distinguishing feature of a tunnel is that it has an ingress and an egress, where LSPs established through LDP may be end-to-end or may be hop-by- hop. All LSPs (tunnels and non-tunnels) may be established as a result of signaling protocols already defined or for future study. In addition, LSPs may be manually set up by issuing configuration commands to each of the LSRs on the LSP. These commands may utilize SNMP by performing SET @@ -1163,21 +1231,21 @@ 14. Traffic Engineering Working Group TE MIB The tewg has produced a traffic engineering MIB (the TE-MIB) [TEWGMIB] containing objects for monitoring traffic engineered at their ingress points. In many senses the TE-MIB contains the same information as MPLS-TE-STD-MIB. Both MIB modules can be used to monitor MPLS tunnels; however, the TE-MIB is minimalistic and caters best to TE tunnels as tunnels, at the expense of not having many advanced - features of the MPLS-TE-STD-MIB, whereas the MPLS-TE-STD-MIB can + features of MPLS-TE-STD-MIB, whereas MPLS-TE-STD-MIB can deconstruct tunnels into hop-by-hop cross-connects, at the expense of more complexity. The TE-MIB module imports textual conventions from the MPLS-TC- STD-MIB module and so is dependent on that document. 14.1. Choosing Between TE MIB Modules The TE-MIB is a flexible MIB module designed to manage traffic engineering tunnels regardless of the implementation @@ -1195,21 +1263,21 @@ - Some of the objects in the TE-MIB are encoded as octet strings. Type discrimination is provided by a separate object and it is left to the Management System to decode the octet string for display purposes according to the display hint, and encode the string in the same way for SET operations. This is in contrast to the MPLS MIB modules which have individual objects with explicit encodings. Extensibility of the TE-MIB to related concepts such as DiffServ and Fast Reroute, and integrations with other MIB - modules such as that in the MPLS-LSR-STD-MIB is not a work item + modules such as that in MPLS-LSR-STD-MIB is not a work item at the time of writing. The MPLS MIB modules are more closely integrated as described in this document. Write/create access to the TE-MIB is only available at the ingress, where it can be used to configure an ingress to signal a tunnel with constraints. It cannot be used to configure hop-by-hop cross-connects to build a tunnel. 15. Security Considerations @@ -1243,22 +1311,21 @@ Many small pieces of text in this document have been borrowed from the documents that define the MIB modules described here. The authors would like to express appreciation to all who worked on those MIB documents. Thanks also to all those who attended the November 2002 MPLS MIB open meeting and gave constructive feedback, and in particular to Sharon Chisholm for her thoughts on Management Options. - Thanks to Kireeti Kompella for revising the text on the - TE-MIB. + Thanks to Kireeti Kompella for revising the text on the TE-MIB. Without the consistent pressure and encouragement from Bert Wijnen, this document would not have been written. 17. Intellectual Property Consideration The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to @@ -1275,60 +1342,60 @@ from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 18. Normative References - [FTNMIB] Nadeau, T., Srinivasan, C., and A. - Viswanathan, "Multiprotocol Label Switching - (MPLS) FEC-To-NHLFE (FTN) Management - Information Base", Internet Draft , April 2003 - (work in progress). + [FTNMIB] Nadeau, T., Srinivasan, C., and A. Viswanathan, + "Multiprotocol Label Switching (MPLS) Forwarding + Equivalence Class To Next Hop Label Forwarding + Entry (FEC-To-NHLFE) Management Information Base", + Internet Draft , + June 2003 (work in progress). [LDPMIB] J. Cucchiara, et al., "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol - (LDP)", , - April 2003 (work in progress). + (LDP)", , + June 2003 (work in progress). [LSRMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Label Switching Router Management Information Base", Internet - Draft , - October 2002 (work in progress). + Draft , + June 2003 (work in progress). [RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group MIB ", RFC 2863, June 2000. [TCMIB] Nadeau, T., Cucchiara, J., (Editors) "Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management", Internet Draft , March 2003 (work in + mpls-tc-mib-08.txt>, June 2003 (work in progress). [TELMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J. Lang, "Traffic Engineering Management Information Base", Internet Draft , May 2003 (work in progress). [TEMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Traffic Engineering Management Information Base Using SMIv2", Internet - Draft , - November 2002 (work in progress). + Draft , + June 2003 (work in progress). 19. Informative References [PPVPNFW] Callon, R., Suzuki, M., (Editors) "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Internet Draft , March 2003 (work in progress). [PWE3FW] Pate, P., (Editor), "Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)", Internet Draft @@ -1408,28 +1475,29 @@ 20. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Email: tnadeau@cisco.com Cheenu Srinivasan - Email: cheenu@alumni.princeton.edu + Bloomberg L.P., + 499 Park Avenue, + New York, NY 10022 + Tel: (212) 893-3682 + Email: cheenu@bloomberg.net Adrian Farrel - Movaz Networks, Inc. - 7926 Jones Branch Drive, Suite 615 - McLean, VA 22102 - Phone: +1-703-847-1867 - Email: afarrel@movaz.com + Old Dog Consulting + Email: adrian@olddog.co.uk 21. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or