One document matched: draft-kumar-mpls-fec-to-nhlfe-mib-00.txt
Network Working Group S. Kumar, Ed.
Internet-Draft R. Bonica
Obsoletes: 3814 (if approved) Juniper Networks
Intended status: Standards Track December 19, 2008
Expires: June 22, 2009
draft-kumar-mpls-fec-to-nhlfe-mib-00
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 22, 2009.
Copyright Notice
Copyright (c) 2008 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.
Abstract
This memo defines a portion of the Management Information Base for
Kumar & Bonica Expires June 22, 2009 [Page 1]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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).
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 June 22, 2009 [Page 2]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 3]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 4]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 5]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 6]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 7]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 "200812100000Z" -- December 10, 2008
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
"200812100000Z" -- December 10, 2008
Kumar & Bonica Expires June 22, 2009 [Page 8]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 9]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 10]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 11]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 12]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 13]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
::= { 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 June 22, 2009 [Page 14]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 15]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 16]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 17]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 18]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 19]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
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 June 22, 2009 [Page 20]
Internet-Draft draft-kumar-mpls-fec-to-nhlfe-mib-00 December 2008
Authors' Addresses
Subodh Kumar (editor)
Juniper Networks
EMail: subodh@juniper.net
Ron Bonica
Juniper Networks
EMail: rbonica@juniper.net
Kumar & Bonica Expires June 22, 2009 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 16:13:17 |