Network Working Group S. Kumar, Ed. Internet-Draft R. Bonica Obsoletes: 3814 (if approved) Juniper Networks Expires: January 14, 2010 July 13, 2009 draft-kumar-mpls-fec-to-nhlfe-mib-01 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 January 14, 2010. Abstract This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for FEC-to-NHLFE for use in Multiprotocol Label Switching (MPLS)network. The MIB module defined in this document is used for configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). Kumar & Bonica Expires January 14, 2010 [Page 1] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Improvements over MPLS-FTN-STD-MIB (RFC3814) . . . . . . . . . 4 5.1. Difficulty in associating incoming packet with FTN Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Removal of mplsFTNPerfTable . . . . . . . . . . . . . . . 5 6. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. mplsFTNRuleTable . . . . . . . . . . . . . . . . . . . . . 5 6.2. mplsFTNRuleTable . . . . . . . . . . . . . . . . . . . . . 5 7. Example Illustrating MIB Module Components . . . . . . . . . . 5 7.1. Creating FTN Entries . . . . . . . . . . . . . . . . . . . 6 8. MPLS-FTN-RULE-MIB Definitions . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 12.3. URL References . . . . . . . . . . . . . . . . . . . . . . 20 Kumar & Bonica Expires January 14, 2010 [Page 2] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 1. Introduction This document defines a portion of the Management Information Base (MIB) for use in managing objects related to the Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for Multiprotocol Label Switching (MPLS).Using this document, user can configure LSRs to redirect non- MPLS traffic into an MPLS cloud. At the ingress of a MPLS cloud, depending on the matching parameters a packets entering the MPLS domain are assigned to an FEC. The "FEC to NHLFE" (FTN) maps each FEC to a set of NHLFE's. It is used for forwarding packets that arrive unlabeled i.e packets received from outside the MPLS domain at the ingress, but which are to be labeled before being forwarded. This document implements the FTN table functionality using the Forwarding Information Base (FIB) to map all packets destined for a prefix to an LSP. Along with the packet destination, this MIB module also extends the matching criteria to certain other parameters. This document use a simple indexing structure, making it easier to implement. 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 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]. 3. Terminology Although all of the terminology used in this document is either covered in the MPLS Architecture [RFC3031] or in the SNMP Architecture [RFC3411], it is informational to define some immediately pertinent acronyms/terminology here. Kumar & Bonica Expires January 14, 2010 [Page 3] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 MPLS Multiprotocol Label Switching FEC Forwarding Equivalence Class NHLFE Next-Hop Label Forwarding Entry FTN FEC-to-NHLFE MIB Management Information Base 4. Conventions 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]. 5. Improvements over MPLS-FTN-STD-MIB (RFC3814) 5.1. Difficulty in associating incoming packet with FTN Rules. In RFC3814, mplsFTNMapTable table provides the capability to activate or map FTN entries defined in mplsFTNTable to specific interfaces in the system. Packets received on an interface are compared against FTN entries in the order in which entries are applied to the interface. To find the FTN rules applied on an incoming packet at interface (ifIndex) which is destined for address "a.b.c.d" with source address "w.x.y.z" with a specified source and destination port, the network management station will need the following actions: - The network management station will first need to perform SNMPWALK (repeated GETNEXT) operation on mplsFTNMapRowStatus.ifIndex.0.0; the returned i object, if one exists is (say) mplsFTNMapRowStatus.ifIndex.n.m. - Then for all 'm's retrieved from the above step, the network management station shall perform GET on mplsFTNTable objects. - The network management station then need some intelligence to compare the packet parameters (src/dest address, src/dest port etc) with the mplsFTNTable objects. e.g. mplsFTNSourceAddrMin, mplsFTNSourceAddrMax, mplsFTNDestAddrMin, mplsFTNDestAddrMax, mplsFTNSourcePortMin etc. Because of the above listed efforts, a network administrator using RFC3814 will need some extra effort in extracting some meaningful data. Also, the i complex indexing structure makes it difficult to implement. This document simplifies the indexing structure by using a structure similar to the forwarding table [RFC4292]. Kumar & Bonica Expires January 14, 2010 [Page 4] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 5.2. Removal of mplsFTNPerfTable The table mplsFTNPerfTable that maintains per route performance statistics is of questionable usefulness. It is highly unlikely that anybody maintains such statistics. This document doesn't list any table for statistics. 6. Outline This MIB module shall be supported on any LSR that does the FEC-to- NHLFE mapping in order to map traffic into the MPLS domain. This MIB module consists of following tables: 6.1. mplsFTNRuleTable Each entry in this table (also referred to as an "FTN entry" in this document) defines a rule to be applied to packets which are to be forwarded to a destination. To map the FEC-to-NHLFE, this table use the destination address and a pointer to mplsFTNRulePolicyTable as the index. mplsFTNRulePolicyTable further extends the packet matching conditions to source address range, source port range, destination port range, IPv4 Protocol field [RFC791] or IPv6 next-header field [RFC2460], and the DiffServ Code Point (DSCP, [RFC2474]). This table also defines Packet redirection action to be performed on successful mapping. This is based on an action pointer (mplsFTNRuleActionPointer) which points either at an mplsXCEntry in MPLS-LSR-STD-MIB [RFC3813] when the NHLFE is a non-TE LSP, or at an mplsTunnelEntry in MPLS-TE-STD-MIB [RFC3812] when the NHLFE is the origin of a TE tunnel. mplsFTNRuleTable use an index structure similar to the forwarding table [RFC4292] making it easier to implement. 6.2. mplsFTNRuleTable The mplsFTNRulePolicyTable provides extended optional rules to be applied on an entry in mplsFTNRuleTable. 7. Example Illustrating MIB Module Components In this section, we use an example to illustrate how the objects defined in MPLS-FTN-RULE-MIB work together to perform FEC to NHLFE mapping. Note that for the various table entries involved in this example, we only show the objects that help illustrate this example. Kumar & Bonica Expires January 14, 2010 [Page 5] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 7.1. Creating FTN Entries Suppose that we wish to create entries in mplsFTNRuleTable and mplsFTNRulePolicyTable which match the following conditions: - Packet is destined to IPv4 address matching 192.0.2.50 - Source IPv4 address matching 192.0.2.63 - An LSP with and outgoing label = 150 where the specified LSP is represented by the following entries in mplsXCTable and mplsOutSegmentTable. Kumar & Bonica Expires January 14, 2010 [Page 6] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 July 2009 In mplsXCTable: { mplsXCIndex = 0x02, mplsXCInSegmentIndex = 0x00, mplsXCOutSegmentIndex = 0x03, mplsXCLabelStackIndex = 0 } -- The value 0x00 for mplsXCInSegmentIndex represents an originating -- LSP [RFC3813]. In mplsOutSegmentTable: { mplsOutSegmentIndex = 0x03, mplsOutSegmentIfIndex = 50, mplsOutSegmentPushTopLabel = true, mplsOutSegmentTopLabel = 150 } The above condition can be implemented by the following entry in mplsFTNRuleTable and mplsFTNRulePolicyTable: mplsFTNRuleTable: { mplsFTNRuleAddrType = ipv4, mplsFTNRuleDestAddr = 192.0.2.50, mplsFTNRuleDestPfxLen = 32, -- index of entry in mplsFTNRulePolicyTable mplsFTNRulePolicyPointer = 1, mplsFTNRuleActionType = redirectTunnel(2), mplsFTNRuleActionPointer = mplsXCLspId.1.2.1.0.1.3 } mplsFTNRulePolicyTable: { mplsFTNRulePolicyIndex = 1, mplsFTNRulePolicyMask = 0x80, mplsFTNRulePolicySrcAddr = 192.0.2.63, mplsFTNRulePolicySrcPfxLen = 32, mplsFTNRulePolicySrcPortMin = 0, mplsFTNRulePolicySrcPortMax = 0, mplsFTNRulePolicyDestPortMin = 0, mplsFTNRulePolicyDestPortMax = 0, mplsFTNRulePolicyProtocol = 0, mplsFTNRulePolicyDscp = 0 } Kumar & Bonica Expires January 14, 2010 [Page 7] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 July 2009 8. MPLS-FTN-RULE-MIB Definitions MPLS-FTN-RULE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter64, Integer32 FROM SNMPv2-SMI -- [RFC2578] RowStatus, StorageType, RowPointer, TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] InterfaceIndexOrZero, ifGeneralInformationGroup, ifCounterDiscontinuityGroup FROM IF-MIB -- [RFC2863] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] Dscp FROM DIFFSERV-DSCP-TC -- [RFC3289] InetAddressType, InetAddress, InetPortNumber, InetAddressPrefixLength FROM INET-ADDRESS-MIB -- [RFC3291] mplsStdMIB FROM MPLS-TC-STD-MIB -- [RFC3811] ; mplsFTNRuleMIB MODULE-IDENTITY LAST-UPDATED "200907060000Z" -- July 06, 2009 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Subodh Kumar Juniper Networks Email: subodh@juniper.net Ron Bonica Juniper Networks Email: rbonica@juniper.net Comments about this document should be emailed directly to the MPLS working group mailing list at mpls@lists.ietf.org" DESCRIPTION "This draft contains managed object definitions for specifying FEC to NHLFE (FTN) mappings." -- Revision history. REVISION "200907060000Z" -- July 06, 2009 Kumar & Bonica Expires January 14, 2010 [Page 8] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 July 2009 DESCRIPTION "Initial version of the draft." ::= { mplsStdMIB XX } -- XX to be assigned by IANA -- TEXTUAL-CONVENTIONs used in this MIB. MplsFTNRuleIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Index for an entry in mplsFTNTable." SYNTAX Unsigned32 (1..4294967295) MplsFTNRuleEntryIndexOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Index for an entry in mplsFTNRulePolicyTable or the special value zero. The value zero is object-specific and must therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations when none or all entries in mplsFTNRulePolicyTable need to be referenced." SYNTAX Unsigned32 (0..4294967295) -- Top-Level Components of this MIB. mplsFTNRuleObjects OBJECT IDENTIFIER ::= { mplsFTNRuleMIB 1 } mplsFTNRuleConformance OBJECT IDENTIFIER ::= { mplsFTNRuleMIB 2 } -- Table of FTN entries. mplsFTNRuleTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsFTNRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the entries that defines FEC to NHLFE mappings. Each entry in this table defines a rule to be applied to incoming packets and an action to be taken on matching packets (mplsFTNRuleActionPointer). This table supports matching rules based on source address range, destination address range and entry in in mplsFTNRulePolicyTable. Kumar & Bonica Expires January 14, 2010 [Page 9] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 The action pointer points either to instance of mplsXCEntry in MPLS-LSR-STD-MIB when the NHLFE is a non-TE LSP, or to an instance of mplsTunnelEntry in the MPLS-TE-STD-MIB when the NHLFE is an originating TE tunnel." ::= { mplsFTNRuleObjects 1 } mplsFTNRuleEntry OBJECT-TYPE SYNTAX MplsFTNRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry defines a FTN Rule to compare incoming packets with and an action to be taken on matching packets." INDEX { mplsFTNRuleAddrType, mplsFTNRuleDestAddr, mplsFTNRuleDestPfxLen, mplsFTNRulePolicyPointer } ::= { mplsFTNRuleTable 1 } MplsFTNRuleEntry ::= SEQUENCE { mplsFTNRuleAddrType InetAddressType, mplsFTNRuleDestAddr InetAddress, mplsFTNRuleDestPfxLen InetAddressPrefixLength, mplsFTNRulePolicyPointer MplsFTNRuleIndex, mplsFTNRuleActionType INTEGER, mplsFTNRuleActionPointer RowPointer, mplsFTNRuleStorageType StorageType, mplsFTNRuleRowStatus RowStatus } mplsFTNRuleAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the mplsFTNRuleDestAddr and mplsFTNRulePolicySrcAddr address, as defined in the InetAddress MIB." ::= { mplsFTNRuleEntry 1 } mplsFTNRuleDestAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current Kumar & Bonica Expires January 14, 2010 [Page 10] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 DESCRIPTION "The Destination IP address. The type of this object is determined by the corresponding mplsFTNRuleAddrType object." ::= { mplsFTNRuleEntry 2 } mplsFTNRuleDestPfxLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the number of leading one bits that form the mask to be logical-ANDed with the destination address before being compared to the value in the mplsFTNRuleDestAddr field. The values for the index objects mplsFTNRuleDestAddr and mplsFTNRuleDestPfxLen must be consistent. When the value of mplsFTNRuleDestAddr (excluding the zone index, if one is present) is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object mplsFTNRuleDestPfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests." ::= { mplsFTNRuleEntry 3 } mplsFTNRulePolicyPointer OBJECT-TYPE SYNTAX MplsFTNRuleIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the mplsFTNRulePolicyTable. Its purpose is to serve as an additional index that may delineate between multiple entries to source and destination. The value '0' shall be used as the default value for this object. A value '0' signifies that other than source and destination address, there are no other constraints applied on incoming packets." ::= { mplsFTNRuleEntry 4 } mplsFTNRuleActionType OBJECT-TYPE SYNTAX INTEGER { redirectLsp(1), -- redirect into LSP redirectTunnel(2) -- redirect into tunnel } Kumar & Bonica Expires January 14, 2010 [Page 11] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 MAX-ACCESS read-create STATUS current DESCRIPTION "The type of action to be taken on packets matching this FTN entry." ::= { mplsFTNRuleEntry 5 } mplsFTNRuleActionPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsFTNRuleActionType is redirectLsp(1), then this object MUST contain zeroDotZero or point to a instance of mplsXCEntry indicating the LSP to redirect matching packets to. If mplsFTNRuleActionType is redirectTunnel(2), then this object MUST contain zeroDotZero or point to a instance of mplsTunnelEntry indicating the MPLS TE tunnel to redirect matching packets to. If this object points to a conceptual row instance in a table consistent with mplsFTNRuleActionType but this instance does not currently exist then no action will be taken on packets matching such an FTN entry till this instance comes into existence. If this object contains zeroDotZero then no action will be taken on packets matching such an FTN entry till it is populated with a valid pointer consistent with the value of mplsFTNRuleActionType as explained above." ::= { mplsFTNRuleEntry 6 } mplsFTNRuleStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this FTN entry. Conceptual rows having the value 'permanent' need not allow write- access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsFTNRuleEntry 7 } mplsFTNRuleRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Kumar & Bonica Expires January 14, 2010 [Page 12] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 STATUS current DESCRIPTION "Used for controlling the creation and deletion of this row. All writeable objects in this row may be modified at any time. When creating a row in this table with a non-zero value of mplsFTNRulePolicyPointer, a row with similar index must be present in mplsFTNRulePolicyTable" ::= { mplsFTNRuleEntry 8 } -- Next free index in mplsFTNTable. mplsFTNRulePolicyIndexNext OBJECT-TYPE SYNTAX MplsFTNRuleEntryIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the next available valid value to be used for mplsFTNRulePolicyIndex when creating entries in the mplsFTNRulePolicyTable. When creating a new conceptual row (configuration entry) in mplsFTNRulePolicyTable with an SNMP SET operation, the Network Management application must first issue a management protocol retrieval operation to obtain the current value of this object. If the command responder (agent) does not wish to allow creation of more entries in mplsFTNTable, possibly because of resource exhaustion, this object MUST return a value of 0. If a non-zero value is returned the Network Management Application must determine whether the value is indeed still unused since two Network Management Applications may attempt to create a row simultaneously and use the same value. If it is currently unused and the SET succeeds, the agent MUST change the value of this object to a currently unused non-zero value (according to an implementation specific algorithm) or zero (if no further row creation will be permitted). If the value is in use, however, the SET fails and the Network Management Application must then reread this object to obtain a new usable value." Kumar & Bonica Expires January 14, 2010 [Page 13] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 ::= { mplsFTNRuleObjects 2 } -- FTN Policy table. mplsFTNRulePolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsFTNRulePolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table extends the rule defined in mplsFTNRuleTable (source and destination address). These optional rules are applied on the incoming packets and based on the matching an action defined by mplsFTNRuleActionType is taken." ::= { mplsFTNRuleObjects 3 } mplsFTNRulePolicyEntry OBJECT-TYPE SYNTAX MplsFTNRulePolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry extends the additional set of optional rules to be applied on incoming packets." INDEX { mplsFTNRulePolicyIndex } ::= { mplsFTNRulePolicyTable 1 } MplsFTNRulePolicyEntry ::= SEQUENCE { mplsFTNRulePolicyIndex MplsFTNRuleIndex, mplsFTNRulePolicyMask BITS, mplsFTNRulePolicySrcAddr InetAddress, mplsFTNRulePolicySrcPfxLen InetAddressPrefixLength, mplsFTNRulePolicySrcPortMin InetPortNumber, mplsFTNRulePolicySrcPortMax InetPortNumber, mplsFTNRulePolicyDestPortMin InetPortNumber, mplsFTNRulePolicyDestPortMax InetPortNumber, mplsFTNRulePolicyProtocol Integer32, mplsFTNRulePolicyDscp Dscp, mplsFTNRulePolicyStorageType StorageType, mplsFTNRulePolicyRowStatus RowStatus } mplsFTNRulePolicyIndex OBJECT-TYPE SYNTAX MplsFTNRuleIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is the unique index for a conceptual row in Kumar & Bonica Expires January 14, 2010 [Page 14] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 mplsFTNRulePolicyTable. To create a new conceptual row in mplsFTNRulePolicyTable a Network Management Application SHOULD retrieve the current value of mplsFTNRulePolicyIndexNext to determine the next valid available value of mplsFTNRulePolicyIndex." ::= { mplsFTNRulePolicyEntry 1 } mplsFTNRulePolicyMask OBJECT-TYPE SYNTAX BITS { sourceAddr(0), sourcePort(1), destPort(2), protocol(3), dscp(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bit map indicates which of the fields described next, source port range, destination port range, IPv4 Protocol field or IPv6 next-header field and Differentiated Services Code Point (DSCP) is active for this FTN entry. If a particular bit is set to zero then the corresponding field in the packet MUST be ignored for comparison purposes." ::= { mplsFTNRulePolicyEntry 2 } mplsFTNRulePolicySrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Source IP address. The type of this object is determined by the corresponding mplsFTNRuleAddrType object." ::= { mplsFTNRulePolicyEntry 3 } mplsFTNRulePolicySrcPfxLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the number of leading one bits that form the mask to be logical-ANDed with the source address before being compared to the value in the mplsFTNRulePolicySrcAddr field. The values for the index objects mplsFTNRulePolicySrcAddr Kumar & Bonica Expires January 14, 2010 [Page 15] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 and mplsFTNRulePolicySrcPfxLen must be consistent. When the value of mplsFTNRulePolicySrcAddr (excluding the zone index, if one is present) is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object mplsFTNRulePolicySrcPfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests." ::= { mplsFTNRulePolicyEntry 4 } mplsFTNRulePolicySrcPortMin OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The lower end of the source port range." DEFVAL { 0 } ::= { mplsFTNRulePolicyEntry 5 } mplsFTNRulePolicySrcPortMax OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The higher end of the source port range " DEFVAL { 65535 } ::= { mplsFTNRulePolicyEntry 6 } mplsFTNRulePolicyDestPortMin OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The lower end of the destination port range." DEFVAL { 0 } ::= { mplsFTNRulePolicyEntry 7 } mplsFTNRulePolicyDestPortMax OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The higher end of the destination port range." DEFVAL { 65535 } ::= { mplsFTNRulePolicyEntry 8 } mplsFTNRulePolicyProtocol OBJECT-TYPE SYNTAX Integer32 (0..255) Kumar & Bonica Expires January 14, 2010 [Page 16] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 MAX-ACCESS read-create STATUS current DESCRIPTION "The IP protocol to match against the IPv4 protocol number or IPv6 Next-Header number in the packet. A value of 255 means match all. Note that the protocol number of 255 is reserved by IANA, and Next-Header number of 0 is used in IPv6." DEFVAL { 255 } ::= { mplsFTNRulePolicyEntry 9 } mplsFTNRulePolicyDscp OBJECT-TYPE SYNTAX Dscp MAX-ACCESS read-create STATUS current DESCRIPTION "The contents of the DSCP field." REFERENCE "Nichols, K., Blake, S., Baker, F. and D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1998." ::= { mplsFTNRulePolicyEntry 10 } mplsFTNRulePolicyStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this FTN Policy. Conceptual rows having the value 'permanent' need not allow write- access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsFTNRulePolicyEntry 11 } mplsFTNRulePolicyRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Used for controlling the creation and deletion of this row. All writeable objects in this row may be modified at any time. A row must be created in this table before being indexed by mplsFTNRuleTable." ::= { mplsFTNRulePolicyEntry 12 } END Kumar & Bonica Expires January 14, 2010 [Page 17] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 9. Security Considerations This MIB contains readable objects whose values provide information related to FEC to NHLFE mapping. There are also a number of objects that have a MAX-ACCESS clause of read-create, such as those which allow an administrator to dynamically configure LSRs to redirect non- MPLS traffic into an MPLS cloud. While unauthorized access to the readable objects is relatively innocuous, unauthorized access to the write-able objects could cause traffic being redirected to unintended destinations resulting into denial of service to the end user. Hence, the support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec [24]), even then, there is no control as to who on the secure network is allowed to access and SET (change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. IANA Considerations As described in [MPLSMGMT] and as requested in [RFC3811], MPLS related standards-track MIB modules should be rooted under the mplsStdMIB subtree. New assignments can only be made by a standards action as specified in [RFC2434]. 11. Contributors The authors wish to thank Ina Minei for her valuble inputs to this work. Comments should be made directly to the MPLS mailing list at mpls@lists.ietf.org Kumar & Bonica Expires January 14, 2010 [Page 18] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 12. References 12.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., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "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. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [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 Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. [RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) Forwarding Kumar & Bonica Expires January 14, 2010 [Page 19] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)", RFC 3814, June 2004. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 12.2. Informative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. 12.3. URL References [idguidelines] IETF Internet Drafts editor, "http://www.ietf.org/ietf/1id-guidelines.txt". Kumar & Bonica Expires January 14, 2010 [Page 20] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 Authors' Addresses Subodh Kumar (editor) Juniper Networks EMail: subodh@juniper.net Ron Bonica Juniper Networks EMail: rbonica@juniper.net Kumar & Bonica Expires January 14, 2010 [Page 21] Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-01 July 2009 Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Intellectual Property The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Kumar & Bonica Expires January 14, 2010 [Page 22]