The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] latest versions of TC and FTN MIBs posted
I sent emails about this yesterday but didn't see it on the list somehow ... I posted the latest version of the TC MIB (v01) and FTN MIB (v02) yesterday. Copies are attached. Note that v02 of the FTN MIB needs v01 of the TC MIB. Cheenu
Network Working Group Thomas D. Nadeau
Internet Draft Cisco Systems, Inc.
Expires: January 2002
Joan Cucchiara
Crescent Networks
Cheenu Srinivasan
Alphion Corp.
Arun Viswanathan
Force10 Networks, Inc.
Hans Sjostrand
ipUnplugged
August 16, 2001
Definition of Textual Conventions and OBJECT-IDENTITIES for
Multi-Protocol Label Switching (MPLS) Management
draft-ietf-mpls-tc-mib-01.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.
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.
Table of Contents
1. Abstract 2
2. Introduction 2
3. The SNMP Management Framework 2
4. MPLS TC MIB Definitions 3
5. Security Considerations 10
6. References 10
Nadeau et al Expires February 2002 [Page 1]
IETF Draft MPLS TC MIB August 2001
7. Authors' Addresses 12
8. Full Copyright Statement 12
1. Abstract
This memo describes Textual Conventions and OBJECT-
IDENTITIES used for managing MPLS networks.
2. Introduction
This memo defines a portion of the Management Information
Base (MIB) for use with network management protocols in the
Internet community. In particular, it defines Textual
Conventions used in IETF MPLS and MPLS-related MIBs.
Comments should be made directly to the MPLS mailing list
at mpls@uu.net.
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, reference [RFC2119].
For an introduction to the concepts of MPLS, see [RFC3031].
3. The SNMP Management Framework
The SNMP Management Framework presently consists of five
major components:
- An overall architecture, described in RFC 2571
[RFC2571].
- Mechanisms for describing and naming objects and events
for the purpose of management. The first version of
this Structure of Management Information (SMI) is
called SMIv1 and described in STD 16, RFC 1155
[RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
[RFC1215]. The second version, called SMIv2, is
described in STD 58, RFC 2578 [RFC2578], STD 58, RFC
2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
- Message protocols for transferring management
information. The first version of the SNMP message
protocol is called SNMPv1 and described in STD 15, RFC
1157 [RFC1157]. A second version of the SNMP message
Nadeau et al Expires February 2002 [Page 2]
IETF Draft MPLS TC MIB August 2001
protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901
[RFC1901] and RFC 1906 [RFC1906]. The third version of
the message protocol is called SNMPv3 and described in
RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574
[RFC2574].
- Protocol operations for accessing management
information. The first set of protocol operations and
associated PDU formats is described in STD 15, RFC 1157
[RFC1157]. A second set of protocol operations and
associated PDU formats is described in RFC 1905
[RFC1905].
- A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism
described in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management
Framework can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information
store, termed the Management Information Base or MIB.
Objects in the MIB are defined using the mechanisms defined
in the SMI.
This memo specifies a MIB module that is compliant to the
SMIv2. A MIB conforming to the SMIv1 can be produced
through the appropriate translations. The resulting
translated MIB must be semantically equivalent, except
where objects or events are omitted because no translation
is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual
descriptions in SMIv1 during the translation process.
However, this loss of machine readable information is not
considered to change the semantics of the MIB.
4. MPLS TC MIB Definitions
MPLS-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, Unsigned32, Integer32
FROM SNMPv2-SMI
transmission
FROM RFC1213-MIB
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
Nadeau et al Expires February 2002 [Page 3]
IETF Draft MPLS TC MIB August 2001
mplsTCMIB MODULE-IDENTITY
LAST-UPDATED
"200108161200Z" -- 16 August 2001 12:00:00 GMT
ORGANIZATION
"Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO
" Thomas D. Nadeau
Cisco Systems, Inc.
tnadeau@cisco.com
Joan Cucchiara
Crescent Networks
jcucchiara@crescentnetworks.com
Cheenu Srinivasan
Alphion Corp.
cheenu@alphion.com
Arun Viswanathan
Force10 Networks, Inc.
arun@force10networks.com
Hans Sjostrand
ipUnplugged
hans@ipunplugged.com
Email comments to the MPLS WG Mailing List at
mpls@uu.net."
DESCRIPTION
"This MIB module defines Textual Conventions and
OBJECT-IDENTITIES for use in documents defining
management information bases (MIBs) for managing
MPLS networks."
-- Revision history.
REVISION
"200108161200Z" -- 16 August 2001 12:00:00 GMT
DESCRIPTION
"Updates based on IESG review."
REVISION
"200104101200Z" -- 10 April 2001 12:00:00 GMT
DESCRIPTION
"Initial version."
::= { mplsMIB 1 }
-- This object identifier needs to be assigned by IANA.
-- Since mpls has been assigned an ifType of 166 we recommend
-- that this OID be 166 as well.
Nadeau et al Expires February 2002 [Page 4]
IETF Draft MPLS TC MIB August 2001
mplsMIB OBJECT IDENTIFIER
::= { transmission xxx }
-- Textual Conventions.
MplsBitRate ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"An estimate of bandwidth in units of 1,000 bits per
second. If this object reports a value of 'n' then
the rate of the object is somewhere in the range of
'n-500' to 'n+499'. For objects which do not vary
in bit rate, or for those where no accurate
estimation can be made, this object should contain
the nominal bit rate."
SYNTAX Integer32 (1..2147483647)
MplsBurstSize ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The number of octets of MPLS data that the stream
may send back-to-back without concern for
policing."
SYNTAX Unsigned32 (1..4294967295)
MplsPortAddr ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A TCP or UDP port number. Along with an IP address
identifies a stream of IP traffic uniquely."
SYNTAX INTEGER (0..65535)
MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier for an MPLS Tunnel. This MAY
represent an IpV4 address of the ingress or egress
LSR for the tunnel. This value is derived from the
Extended Tunnel Id in RSVP or the Ingress Router ID
for CR-LDP."
REFERENCE
"1. Awduche, D., et al., RSVP-TE: Extensions to RSVP
for LSP Tunnels, draft-ietf-mpls-rsvp-lsp-tunnel-
08.txt, February 2001.
2. Constraint-Based LSP Setup using LDP, Jamoussi,
B., et al., draft-ietf-mpls-cr-ldp-05.txt, February
2001."
Nadeau et al Expires February 2002 [Page 5]
IETF Draft MPLS TC MIB August 2001
SYNTAX Unsigned32
MplsLabel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This value represents an MPLS label as defined in
[RFC3031], [RFC3032], [RFC3034] and [RFC3035]."
REFERENCE
"1. Multiprotocol Label Switching Architecture, Rosen
et al, RFC 3031, August 1999.
2. MPLS Label Stack Encoding, Rosen et al, RFC 3032,
January 2001.
3. Use of Label Switching on Frame Relay Networks,
Conta et al, RFC 3034, January 2001.
4. MPLS using LDP and ATM VC switching, Davie et al,
RFC 3035, January 2001."
SYNTAX Unsigned32 (0..4294967295)
MplsLdpGenAddr ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The value of an network layer or data link layer
address."
SYNTAX OCTET STRING (SIZE (0..64))
MplsLdpIdentifier ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The LDP identifier is a six octet quantity which is
used to identify an Label Switch Router (LSR) label
space.
The first four octets identify the LSR and must be a
globally unique value, such as a 32-bit router ID
assigned to the LSR, and the last two octets
identify a specific label space within the LSR."
SYNTAX OCTET STRING (SIZE (6))
MplsLdpLabelTypes ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Layer 2 label types which are defined for MPLS
LDP/CRLDP are generic(1), atm(2), or
frameRelay(3)."
SYNTAX INTEGER {
generic(1),
atm(2),
frameRelay(3)
}
Nadeau et al Expires February 2002 [Page 6]
IETF Draft MPLS TC MIB August 2001
MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The VCI value for a VCL. The maximum VCI value
cannot exceed the value allowable by
atmInterfaceMaxVciBits defined in ATM-MIB. The
minimum value is 32, values 0 to 31 are reserved
for other uses by the ITU and ATM Forum. 32 is
typically the default value for the Control VC."
REFERENCE
"Definitions of Textual Conventions and OBJECT-
IDENTITIES for ATM Management, RFC 2514, Feb.
1999."
SYNTAX Integer32 (32..65535)
MplsLSPID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An identifier that is assigned to each LSP and is
used to uniquely identify it. This is assigned at
the head end of the LSP and can be used by all LSRs
to identify this LSP. This value is piggybacked by
the signaling protocol when this LSP is signaled
within the network. This identifier can then be
used at each LSR to identify which labels are being
swapped to other labels for this LSP. For IPv4
addresses this results in a 6-octet long cookie."
SYNTAX OCTET STRING (SIZE (0..31))
MplsLsrIdentifier ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Label Switch Router (LSR) identifier is the
first 4 bytes of the Label Distribution Protocol
(LDP) identifier."
SYNTAX OCTET STRING (SIZE (4))
MplsInitialCreationSource ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The entity that originally created the object in
question. The values of this enumeration are
defined as follows:
other(1) - This is used when an entity which has not
been enumerated in this textual convention but
which is known by the agent.
snmp(2) - The Simple Network Management Protocol was
used to configure this object initially.
Nadeau et al Expires February 2002 [Page 7]
IETF Draft MPLS TC MIB August 2001
ldp(3 - The Label Distribution Protocol was used to
configure this object initially.
rsvp(4) - The Resource Reservation Protocol was used
to configure this object initially.
crldp(5) - The Constraint-Based Label Distribution
Protocol was used to configure this object
initially.
policyAgent(6) - A policy agent (perhaps in
combination with one of the above protocols) was
used to configure this object initially.
unknown(7) - the agent cannot discern which
component created the object."
SYNTAX INTEGER {
other(1),
snmp(2),
ldp(3),
rsvp(4),
crldp(5),
policyAgent(6),
unknown (7)
}
MplsPathIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier used to identify a specific path
used by a tunnel."
SYNTAX Unsigned32
MplsPathIndexOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier used to identify a specific path
used by a tunnel. If this value is set to 0, it
indicates that no path is in use."
SYNTAX Unsigned32
MplsTunnelAffinity ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Include-any, include-all, or exclude-all constraint
for link selection."
SYNTAX Unsigned32
MplsTunnelIndex ::= TEXTUAL-CONVENTION
Nadeau et al Expires February 2002 [Page 8]
IETF Draft MPLS TC MIB August 2001
STATUS current
DESCRIPTION
"Index into mplsTunnelTable."
SYNTAX Integer32 (1..65535)
MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Instance index into mplsTunnelTable."
SYNTAX Unsigned32 (0..65535)
MplsFTNIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Index for an FEC-to-NHLFE (FTN) entry."
SYNTAX Integer32(1..2147483647)
MplsFTNIndexOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Index for an FTN entry or zero."
SYNTAX Integer32(0..2147483647)
END
5. Security Considerations
This memo defines textual conventions and object identities
for use in MPLS MIB modules. Security issues for these MIB
modules are addressed in the memos defining those modules.
6. References
[RFC1155] Rose, M., and K. McCloghrie, "Structure and
Identification of Management Information for
TCP/IP-based Internets", STD 16, RFC 1155,
May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J.
Davin, "Simple Network Management Protocol",
STD 15, RFC 1157, May 1990.
[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB
Definitions", STD 16, RFC 1212, March 1991.
[RFC1215] M. Rose, "A Convention for Defining Traps
for use with the SNMP", RFC 1215, March
1991.
Nadeau et al Expires February 2002 [Page 9]
IETF Draft MPLS TC MIB August 2001
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based
SNMPv2", RFC 1901, January 1996.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version
2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for Version
2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC
2119, March 1997.
[RFC2514] Noto, et. al., "Definitions of Textual
Conventions and OBJECT-IDENTITIES for ATM
Management", RFC 2514, Feb. 1999
[RFC2570] Case, J., Mundy, R., Partain, D., and B.
Stewart, "Introduction to Version 3 of the
Internet-standard Network Management
Framework", RFC 2570, April 1999.
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen,
"An Architecture for Describing SNMP
Management Frameworks", RFC 2571, April
1999.
[RFC2572] Case, J., Harrington D., Presuhn R., and B.
Wijnen, "Message Processing and Dispatching
for the Simple Network Management Protocol
(SNMP)", RFC 2572, April 1999.
[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
Applications", RFC 2573, April 1999.
[RFC2574] Blumenthal, U., and B. Wijnen, "User-based
Security Model (USM) for version 3 of the
Simple Network Management Protocol
(SNMPv3)", RFC 2574, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie,
"View-based Access Control Model (VACM) for
the Simple Network Management Protocol
(SNMP)", RFC 2575, April 1999.
Nadeau et al Expires February 2002 [Page 10]
IETF Draft MPLS TC MIB August 2001
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder,
J., Case, J., Rose, M., and S. Waldbusser,
"Structure of Management Information Version
2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder,
J., Case, J., Rose, M., and S. Waldbusser,
"Textual Conventions for SMIv2", STD 58, RFC
2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder,
J., Case, J., Rose, M., and S. Waldbusser,
"Conformance Statements for SMIv2", STD 58,
RFC 2580, April 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching
Architecture", RFC 3031, August 1999.
[RFC3032] Rosen, E., Rekhter, Y., Tappan, D.,
Farinacci, D., Federokow, G., Li, T., and A.
Conta, "MPLS Label Stack Encoding", RFC
3032, January 2001.
[RFC3034] Conta, A., Doolan, P., Malis, A., "Use of
Label Switching on Frame Relay Networks
Specification", RFC 3034, January 2001.
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K.,
Rosen, E., Swallow, G., Rekhter, Y., and P.
Doolan, "MPLS using LDP and ATM VC
switching", RFC 3035, January 2001.
[RFC3036] Anderson, L., Doolan, P., Feldman, N.,
Fredette, A., and B. Thomas, "LDP
Specification", RFC 3036, January 2001.
[Assigned] Reynolds, J., and J. Postel, "Assigned
Numbers", RFC 1700, October 1994. See also:
http://www.isi.edu/in-
notes/iana/assignments/smi-numbers
[RSVPTE] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., Swallow, G., RSVP-TE:
Extensions to RSVP for LSP Tunnels, draft-
ietf-mpls-rsvp-lsp-tunnel-08.txt, February
2001.
[CRLDP] Jamoussi, B., Aboul-Magd, O., Andersson, L.,
Nadeau et al Expires February 2002 [Page 11]
IETF Draft MPLS TC MIB August 2001
Ashwood-Smith, P., Hellstrand, F., Sundell,
K., Callon, R., Dantu, R., Wu, L., Doolan,
P., Worster, T., Feldman, N., Fredette, A.,
Girish, M., Gray, E., Halpern, J., Heinanen,
J., Kilty, T., Malis, A., Vaananen, P.,
Constraint-Based LSP Setup using LDP, draft-
ietf-mpls-cr-ldp-05.txt, February 2001."
7. Authors' Addresses
Thomas D. Nadeau
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1-978-244-3051
Email: tnadeau@cisco.com
Joan Cucchiara
Crescent Networks
900 Chelmsford Street
Lowell, MA 01851
Phone: +1-978-275-3183
email: jcucchiara@crescentnetworks.com
Cheenu Srinivasan
Alphion Corp.
4 Industrial Way West
Eatontown, NJ 07724
Phone: +1-732-676-7066
Email: cheenu@alphion.com
Arun Viswanathan
Force10 Networks, Inc.
1440 McCarthy Blvd
Milpitas, CA 95035
Phone: +1-408-571-3516
Email: arun@force10networks.com
Hans Sjostrand
ipUnplugged
P.O. Box 101 60
S-121 28 Stockholm, Sweden
Phone: +46-8-725-5930
Email: hans@ipunplugged.com
8. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights
Nadeau et al Expires February 2002 [Page 12]
IETF Draft MPLS TC MIB August 2001
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
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Nadeau et al Expires February 2002 [Page 13]
Network Working Group Thomas D. Nadeau
Internet Draft Cisco Systems, Inc.
Expires: February 2002
Cheenu Srinivasan
Alphion Corp.
Arun Viswanathan
Force10 Networks, Inc.
August 2001
Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN)
Management Information Base
draft-ietf-mpls-ftn-mib-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of 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 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.
Abstract
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community. In particular, it describes managed objects
for defining FEC-to-NHLFE mapping and corresponding actions for use
with Multiprotocol Label Switching (MPLS).
Table of Contents
Status of this Memo 1
Nadeau et al. Expires February 2002 [Page 1]
Internet Draft MPLS FTN MIB August 2001
Abstract 1
1. Introduction 2
2. Terminology 2
3. The SNMP Management Framework 2
3.1. Object Definitions 3
4. Motivation 4
5. Outline 4
5.1. mplsFTNTable 4
5.2. mplsFTNMapTable 5
5.3. mplsFTNPerfTable 5
6. Example 6
7. The Use of RowPointer 7
8. MPLS FTN MIB Definitions 8
9. Security Considerations 21
10. References 22
11. Authors' Addresses 23
12. Acknowledgements 24
13. Full Copyright Statement 24
1. Introduction
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community. In particular, it describes managed objects
for specifying FEC to NHLFE mappings and corresponding actions for
Multiprotocol Label Switching (MPLS).
This memo does not, in its draft form, specify a standard for the
Internet community.
2. Terminology
Although all of the terminology used in this draft is either covered
in the MPLS Architecture [RFC3031] or in the SNMP Architecture
[RFC2271], it is informational to define some immediately pertinent
acronyms/terminology here.
MPLS Multi-Protocol Label Switching
FEC Forwarding Equivalency Class
NHLFE Next-Hop Label Forwarding Entry
FTN FEC-to-NHLFE
MIB Management Information Base
3. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
Nadeau et al. Expires February 2002 [Page 2]
Internet Draft MPLS FTN MIB August 2001
components:
- An overall architecture, described in RFC 2271 [RFC2271].
- Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in RFC
1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The
second version, called SMIv2, is described in RFC 1902 [RFC1902],
RFC 1903 [RFC1903] and RFC 1904 [RFC1904].
- Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in RFC 1157 [RFC1157]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2 and described in RFC 1901 [RFC1901]
and RFC 1906 [RFC1906]. The third version of the message
protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
RFC 2272 [RFC2272] and RFC 2274 [RFC2274].
- Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in RFC 1157 [RFC1157]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[RFC1905].
- A set of fundamental applications described in RFC 2273 [RFC2273]
and the view-based access control mechanism described in RFC 2275
[RFC2275]. Managed objects are accessed via a virtual
information store, termed the Management Information Base or MIB.
Objects in the MIB are defined using the mechanisms defined in
the SMI. This memo specifies a MIB module that is compliant to
the RFC1902. A MIB conforming to the RFC1155 can be produced
through the appropriate translations. The resulting translated
MIB must be semantically equivalent, except where objects or
events are omitted because no translation is possible (use of
Counter64). Some machine-readable information in RFC1902 will be
converted into textual descriptions in RFC1155 during the
translation process. However, this loss of machine-readable
information is not considered to change the semantics of the MIB.
3.1. Object Definitions
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object type is named by an
OBJECT IDENTIFIER, an administratively assigned name. The object
type together with an object instance serves to uniquely identify a
Nadeau et al. Expires February 2002 [Page 3]
Internet Draft MPLS FTN MIB August 2001
specific instantiation of the object. For human convenience, we
often use a textual string, termed the descriptor, to also refer to
the object type.
4. Motivation
On the ingress of an MPLS network, packets entering the MPLS domain
are assigned to a FEC. Those packets belonging to a forwarding
equivalency class (FEC) are associated with an NHLFE via the FEC-to-
NHLFE (FTN) mapping [MPLS-Arch]. This relationship defines how the
LSR will impose MPLS labels onto an incoming flow. It is important to
note that an NHLFE entry can redirect packets to either an LSP or a
Traffic Engineered (TE) Tunnel.
Conceptually, some of the FTN table functionality could be
implemented using the Forwarding Information Base (FIB) to map all
packets destined for a prefix to an LSP. However, this mapping is
coarse in nature.
Similar functionality is already being used in other contexts, such
as security filters, access filters, and for RSVP flow
identification. All of these require various combinations of
matching based on IP header and upper-layer header information to
identify packets for a particular treatment. When packets match a
particular rule, a corresponding action is executed against those
packets. For example, two popular actions to take when a successful
match is detected are allowing the packet to be forwarded or to
discard it. However, other actions are possible, such as modifying
the TOS byte, or redirecting a packet to a particular outgoing
interface.
This draft attempts to consolidate the various matching requirements
and associated action options needed for MPLS into a single
specification.
5. Outline
This MIB resides on any LSR which does the FEC-to-NHLFE mapping in
order to map traffic into the MPLS domain. The MIB consists of three
tables: The mplsFTNTable defines the rule base against which incoming
packets are matched and actions taken on matching packets. The
mplsFTNMapTable defines the application of these rules to specific
interfaces. Finally, the mplsFTNPerfTable provides performance
counters for every FTN entry that is active, on a per-interface
basis.
5.1. mplsFTNTable
Nadeau et al. Expires February 2002 [Page 4]
Internet Draft MPLS FTN MIB August 2001
This table allows FEC to NHLFE mappings to be specified. Each entry
in this table defines a rule to be applied to incoming packets (on
interfaces that the FTN entry is activated on using mplsFTNMapTable;
see Section 5.2) and an action to be taken on matching packets.
mplsFTNTable provides a 6-tuple matching and allows addresses, port
ranges and the exp bits to be specified. The action pointer points
at either an MPLS LSR MIB [LSRMIB] mplsXCEntry when the NHLFE entry
is a non-TE LSP, or it points at an mplsTunnelEntry in the MPLS TE
MIB [TEMIB] if we wish to make the NHLFE the start of a TE tunnel.
5.2. mplsFTNMapTable
This table provides the capability to activate or map FTN entries
defined in mplsFTNTable to specific interfaces in the system. FTN
entries are compared with incoming packets in the order in which they
are applied on an interface. For this reason, this table provides a
mechanism to 'insert' an FTN entry between two existing FTN entries
already applied on an interface.
Using this linked-list structure, one can retrieve FTN entries in the
order of application on a per-interface basis as follows:
- To determine the first FTN entry on an interface with index
ifIndex perform a GETNEXT retrieval operation on
mplsFTNMapIfIndex.ifIndex.0.0; the returned object, if one
exists, is (say) mplsFTNMapIfIndex.ifIndex.0.n. Then the index of
the first FTN entry applied on this interface is n.
- To determine the FTN entry applied after the one indexed by n
perform a GETNEXT retrieval operation on
mplsFTNMapIfIndex.ifIndex.n.0; the returned object, if one
exists, is (say) mplsFTNMapIfIndex.ifIndex.n.m. Then the index of
the next FTN entry applied on this interface is m.
Use the above steps to retrieve all the applied FTN entries on a per-
interface basis in application order. Note that the number of
retrieval operations is the same as the number of applied FTN entries
(i.e. the minimum number of GETNEXT operations needed using any
indexing scheme).
5.3. mplsFTNPerfTable
This table provides performance counters for each FTN entry on a per-
interface basis. High capacity counters are provided for situations
where 32-bit counters would wrap around too quickly.
Nadeau et al. Expires February 2002 [Page 5]
Internet Draft MPLS FTN MIB August 2001
6. Example
Suppose that we want to activate the following FTN entries.
1. in ifIndex=1, dest addr=1.2.0.0 -> out ifIndex=50, out label=150
2. in ifIndex=1, dest addr=1.3.0.0 -> tunnel=4
In this case the tables will look as follows in the MPLS LSR, TE and
FTN MIBs (we only show fields of interest in each case).
Entry #1 results in the following.
In mplsFTNTable:
{
mplsFTNIndex = 1,
mplsFTNDescr = "FTN-1 for net 1.2.0.0",
mplsFTNMask = 0x40, -- destination address only
mplsFTNAddrType = ipv4,
mplsFTNDestIpv4AddrMin = 1.2.0.0,
mplsFTNDestIpv4AddrMax = 1.2.0.0,
mplsFTNActionType = redirectLsp,
mplsFTNActionPointer = mplsXCIndex.2.0.0.3
}
We indicate the LSP to redirect packets to by setting
mplsFTNActionPointer to the first column object of the XC entry
corresponding to this LSP, in this case mplsXCIndex.2.0.0.3 which
represents the following XC entry.
In mplsXCTable:
{
mplsXCIndex = 2,
mplsInSegmentIfIndex = 0, -- originating LSP
mplsInSegmentLabel = 0, -- originating LSP
mplsOutSegmentIndex = 3,
mplsXCLabelStackIndex = 0
}
Note that mplsInSegmentIfIndex and mplsInSegmentLabel values used to
index this XC entry are zero as is required for an originating LSP
[LSRMIB].
In mplsOutSegmentTable:
{
mplsOutSegmentIndex = 3,
mplsOutSegmentIfIndex = 50,
mplsOutSegmentPushTopLabel = true,
mplsOutSegmentTopLabel = 150
}
In mplsFTNMapTable:
Nadeau et al. Expires February 2002 [Page 6]
Internet Draft MPLS FTN MIB August 2001
{
mplsFTNMapIfIndex = 1,
mplsFTNPrevIndex = 0, -- first FTN entry on this interface
mplsFTNMapCurrIndex = 1,
}
Entry #2 results in the following.
In mplsFTNTable:
{
mplsFTNIndex = 2,
mplsFTNDescr = "FTN-2 for net 1.2.0.0",
mplsFTNMask = 0x40, -- destination address only
mplsFTNAddrType = ipv4,
mplsFTNDestIpv4AddrMin = 1.3.0.0,
mplsFTNDestIpv4AddrMax = 1.3.0.0,
mplsFTNActionType = redirectTunnel,
-- We assume that the ingress and egress LSR IDs are 1.1.1.1 and
-- 2.2.2.2 respectively for this tunnel.
mplsFTNActionPointer = mplsTunnelIndex.4.0.1.1.1.1.2.2.2.2
}
In mplsTunnelTable:
{
mplsTunnelIndex = 4,
mplsTunnelInstance = 0, -- primary tunnel
mplsTunnelIngressLSRID = 1.1.1.1,
mplsTunnelEgressLSRID = 2.2.2.2
}
In mplsFTNMapTable:
{
mplsFTNMapIfIndex = 1,
mplsFTNPrevIndex = 1,
mplsFTNMapCurrIndex = 2
}
7. The Use of RowPointer
RowPointer is a textual convention used to identify a conceptual row
in an SNMP Table by pointing to one of its objects. In this MIB, in
mplsFTNTable, the RowPointer object mplsFTNActionPointer indicates
the LSP or TE Tunnel to redirect packets matching an FTN entry to.
This object MUST point to the first column of the appropriate
conceptual row in order to allow the manager to find the appropriate
corresponding entry in either the MPLS LSR MIB [LSRMIB] or MPLS TE
MIB [TEMIB]. If this object returns zeroDotZero it implies that there
is no currently defined action that is associated with that
particular FTN entry.
Nadeau et al. Expires February 2002 [Page 7]
Internet Draft MPLS FTN MIB August 2001
8. MPLS FTN MIB Definitions
MPLS-FTN-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Integer32, Unsigned32, Counter32, experimental
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION, TruthValue, RowStatus,
StorageType, DisplayString
FROM SNMPv2-TC
InterfaceIndexOrZero
FROM IF-MIB
MplsTunnelIndex, MplsPortAddr, MplsFTNIndex,
MplsFTNIndexOrZero
FROM MPLS-TC-MIB
InetAddressIPv4, InetAddressIPv6, InetAddressType
FROM INET-ADDRESS-MIB;
mplsFTNMIB MODULE-IDENTITY
LAST-UPDATED "200108161200Z" -- 16 August 2001 12:00:00 GMT
ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO
" Thomas D. Nadeau
Postal: Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Tel: +1-978-244-3051
Email: tnadeau@cisco.com
Cheenu Srinivasan
Postal: Alphion Corp.
4 Industrial Way West
Eatontown, NJ 07724
+1-732-676-7066
Email: cheenu@alphion.com
Arun Viswanathan
Postal: Force10 Networks, Inc.
1440 McCarthy Blvd
Milpitas, CA 95035
Tel: +1-408-571-3516
Email: arun@force10networks.com"
DESCRIPTION
"This MIB module contains managed object definitions for
Nadeau et al. Expires February 2002 [Page 8]
Internet Draft MPLS FTN MIB August 2001
specifying FEC to NHLFE (FTN) mappings and corresponding
performance for MPLS."
-- Revision history.
REVISION
"200108161200Z" -- 16 August 2001 12:00:00 GMT
DESCRIPTION
"Updates to example section, which was TBD in the
previous version.
Added expBits to mplsFTNMask.
Added mplsFTNExpBits to mplsFTNEntry.
General cleanup of editorial issues including updating
references."
REVISION
"200104011200Z" -- 1 April 2001 12:00:00 GMT
DESCRIPTION
"Updates based on MPLS working group feedback."
REVISION
"200009201200Z" -- 20 September 2000 12:00:00 GMT
DESCRIPTION
"First draft version issued as MPLS working group document."
REVISION
"200007141200Z" -- 14 July 2000 12:00:00 GMT
DESCRIPTION
"Updated draft version."
REVISION
"200003032030Z" -- 03 March 2000 20:30:00 GMT
DESCRIPTION
"Initial draft version."
::= { experimental 111 }
-- Top-Level Components of this MIB.
mplsFTNNotifications OBJECT IDENTIFIER ::= { mplsFTNMIB 0 }
mplsFTNObjects OBJECT IDENTIFIER ::= { mplsFTNMIB 1 }
mplsFTNConformance OBJECT IDENTIFIER ::= { mplsFTNMIB 2 }
-- FTN table.
mplsFTNIndexNext OBJECT-TYPE
SYNTAX MplsFTNIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Nadeau et al. Expires February 2002 [Page 9]
Internet Draft MPLS FTN MIB August 2001
"This object contains the next appropriate value to be
used for mplsFTNIndex when creating entries in the
mplsFTNTable. If the number of unassigned entries is
exhausted, this object MUST return a value of 0. To
obtain the mplsFTNIndex value for a new entry, the
manager must first issue a management protocol
retrieval operation to obtain the current value of this
object. The agent should modify the value to reflect
the next unassigned index after each retrieval
operation. After a manager retrieves a value the agent
will determine through its local policy when this index
value will be made available for reuse."
::= { mplsFTNObjects 1 }
mplsFTNTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsFTNEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the currently defined FTN entries."
::= { mplsFTNObjects 2 }
mplsFTNEntry OBJECT-TYPE
SYNTAX MplsFTNEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry represents one FTN entry which defines a
rule to compare against incoming packets and an action
to be taken on matching packets."
INDEX { mplsFTNIndex }
::= { mplsFTNTable 1 }
MplsFTNEntry ::= SEQUENCE {
mplsFTNIndex MplsFTNIndex,
mplsFTNRowStatus RowStatus,
mplsFTNDescr DisplayString,
mplsFTNApplied TruthValue,
mplsFTNMask BITS,
mplsFTNAddrType InetAddressType,
mplsFTNSourceIpv4AddrMin InetAddressIPv4,
mplsFTNSourceIpv6AddrMin InetAddressIPv6,
mplsFTNSourceIpv4AddrMax InetAddressIPv4,
mplsFTNSourceIpv6AddrMax InetAddressIPv6,
mplsFTNDestIpv4AddrMin InetAddressIPv4,
mplsFTNDestIpv6AddrMin InetAddressIPv6,
mplsFTNDestIpv4AddrMax InetAddressIPv4,
mplsFTNDestIpv6AddrMax InetAddressIPv6,
mplsFTNSourcePortMin MplsPortAddr,
mplsFTNSourcePortMax MplsPortAddr,
Nadeau et al. Expires February 2002 [Page 10]
Internet Draft MPLS FTN MIB August 2001
mplsFTNDestPortMin MplsPortAddr,
mplsFTNDestPortMax MplsPortAddr,
mplsFTNProtocol INTEGER,
mplsFTNActionType INTEGER,
mplsFTNActionPointer RowPointer,
mplsFTNExpBits Unsigned32,
mplsFTNStorageType StorageType
}
mplsFTNIndex OBJECT-TYPE
SYNTAX MplsFTNIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Unique index for the this entry."
::= { mplsFTNEntry 1 }
mplsFTNRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Used for controlling the creation and deletion of this
row."
::= { mplsFTNEntry 2 }
mplsFTNDescr OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The description of this FTN entry. Due to the arbitrary
indexing of this table, this object should contain some
meaningful text that an operator could use to further
distinguish entries in this table."
::= { mplsFTNEntry 3 }
mplsFTNApplied OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates whether this FTN entry is being applied on
any interface (using mplsFTNMapTable) or not."
::= { mplsFTNEntry 4 }
mplsFTNMask OBJECT-TYPE
SYNTAX BITS {
sourceAddr(0),
destAddr(1),
Nadeau et al. Expires February 2002 [Page 11]
Internet Draft MPLS FTN MIB August 2001
sourcePort(2),
destPort(3),
protocol(4),
expBits(5)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This bit map indicates which of the fields described
next, namely source address range, destination address
range, source port range, destination port range,
protocol and exp bits is active for this FTN entry. If
a particular bit is inactive (i.e., set to zero) then
the corresponding field in the packet is ignored for
comparison purposes."
::= { mplsFTNEntry 5 }
mplsFTNAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Type of IP packet that this entry will match against.
If this object has the value ipv4(1) then the objects
in this entry of type InetAddressIpv6 MUST be ignored
by management applications. If this object has the
value ipv6(1) then the objects in this entry of type
InetAddressIpv4 MUST be ignored by management
applications."
DEFVAL { ipv4 }
::= { mplsFTNEntry 6 }
mplsFTNSourceIpv4AddrMin OBJECT-TYPE
SYNTAX InetAddressIPv4
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of source address range - IPv4 version."
::= { mplsFTNEntry 7 }
mplsFTNSourceIpv6AddrMin OBJECT-TYPE
SYNTAX InetAddressIPv6
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of source address range - IPv6 version."
::= { mplsFTNEntry 8 }
mplsFTNSourceIpv4AddrMax OBJECT-TYPE
SYNTAX InetAddressIPv4
Nadeau et al. Expires February 2002 [Page 12]
Internet Draft MPLS FTN MIB August 2001
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The upper end of source address range - IPv4 version."
::= { mplsFTNEntry 9 }
mplsFTNSourceIpv6AddrMax OBJECT-TYPE
SYNTAX InetAddressIPv6
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The upper end of source address range - IPv4 version."
::= { mplsFTNEntry 10 }
mplsFTNDestIpv4AddrMin OBJECT-TYPE
SYNTAX InetAddressIPv4
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of destination address range - IPv4
version."
::= { mplsFTNEntry 11 }
mplsFTNDestIpv6AddrMin OBJECT-TYPE
SYNTAX InetAddressIPv6
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of destination address range - IPv6
version."
::= { mplsFTNEntry 12 }
mplsFTNDestIpv4AddrMax OBJECT-TYPE
SYNTAX InetAddressIPv4
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The upper end of destination address range - IPv4
version "
::= { mplsFTNEntry 13 }
mplsFTNDestIpv6AddrMax OBJECT-TYPE
SYNTAX InetAddressIPv6
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The upper end of destination address range - IPv6
version "
::= { mplsFTNEntry 14 }
Nadeau et al. Expires February 2002 [Page 13]
Internet Draft MPLS FTN MIB August 2001
mplsFTNSourcePortMin OBJECT-TYPE
SYNTAX MplsPortAddr
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of source port range."
::= { mplsFTNEntry 15 }
mplsFTNSourcePortMax OBJECT-TYPE
SYNTAX MplsPortAddr
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The higher end of source port range "
::= { mplsFTNEntry 16 }
mplsFTNDestPortMin OBJECT-TYPE
SYNTAX MplsPortAddr
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of the destination port range."
::= { mplsFTNEntry 17 }
mplsFTNDestPortMax OBJECT-TYPE
SYNTAX MplsPortAddr
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The higher end of the destination port range."
::= { mplsFTNEntry 18 }
mplsFTNProtocol OBJECT-TYPE
SYNTAX INTEGER (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The contents of the protocol ID field in the IP
header."
::= { mplsFTNEntry 19 }
mplsFTNActionType OBJECT-TYPE
SYNTAX INTEGER {
drop(1), -- discard this packet
redirectLsp(2), -- redirect into LSP
redirectTunnel(3) -- redirect into tunnel
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
Nadeau et al. Expires February 2002 [Page 14]
Internet Draft MPLS FTN MIB August 2001
"The type of action to be taken on packets matching this
FTN entry."
::= { mplsFTNEntry 20 }
mplsFTNActionPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If mplsFTNActionType is redirectLsp(2), then this
object indicates the instance of mplsXCEntry for the
LSP to redirect matching packets to. If
mplsFTNActionType is redirectTunnel(3), then this
object indicates the instance of mplsTunnelEntry for
the MPLS tunnel to redirect matching packets to. For
other values of mplsFTNActionType this object MUST be
ignored by management applications. Agents SHOULD
return zeroDotZero as the value of this object to
indicate this to management stations."
::= { mplsFTNEntry 21 }
mplsFTNExpBits OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the contents of the exp bits
field to match incoming traffic against."
::= { mplsFTNEntry 22 }
mplsFTNStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this FTN entry."
::= { mplsFTNEntry 23 }
-- End of mplsFTNTable.
-- FTN to interface mapping table.
mplsFTNMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsFTNMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains objects for mapping previously
defined entries in mplsFTNTable to interfaces."
Nadeau et al. Expires February 2002 [Page 15]
Internet Draft MPLS FTN MIB August 2001
::= { mplsFTNObjects 3 }
mplsFTNMapEntry OBJECT-TYPE
SYNTAX MplsFTNMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry indicates the application of a particular
entry as defined in mplsFTNTable on an interface. The
order of application of FTN entries on an interface is
the order in which they will be compared against
incoming packets for a match. Each entry of this table
is indexed by the interface index that the FTN entry is
applied to, with the value 0 representing all
interfaces, the index of the previous FTN entry applied
on the interface and the index of the current FTN
entry. This linked-list structure allows FTN entries to
be inserted at arbitrary positions in the list. Agents
MUST NOT allow the same FTN entries to be applied
multiple times to the same interface. Agents MUST not
allow the creation of rows in this table until the
corresponding rows are created in the mplsFTNTable. If
the corresponding row in the FTN table is destroyed,
the agent MUST destroy the corresponding entries in
this table as well."
INDEX {
mplsFTNMapIfIndex,
mplsFTNMapPrevIndex,
mplsFTNMapCurrIndex
}
::= { mplsFTNMapTable 1 }
MplsFTNMapEntry ::= SEQUENCE {
mplsFTNMapIfIndex InterfaceIndexOrZero,
mplsFTNMapPrevIndex MplsFTNIndexOrZero,
mplsFTNMapCurrIndex MplsFTNIndex,
mplsFTNMapRowStatus RowStatus,
mplsFTNMapStorageType StorageType
}
mplsFTNMapIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The interface index that this FTN entry is being
applied to. Zero represents all interfaces."
::= { mplsFTNMapEntry 1 }
mplsFTNMapPrevIndex OBJECT-TYPE
Nadeau et al. Expires February 2002 [Page 16]
Internet Draft MPLS FTN MIB August 2001
SYNTAX MplsFTNIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The index of the previous FTN entry that was applied to
this interface. Zero indicates that this should be the
first FTN entry in the list."
::= { mplsFTNMapEntry 2 }
mplsFTNMapCurrIndex OBJECT-TYPE
SYNTAX MplsFTNIndex
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Index of the current FTN entry that is being applied to
this interface."
::= { mplsFTNMapEntry 3 }
mplsFTNMapRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"For controlling the creation and deletion of this row."
::= { mplsFTNMapEntry 4 }
mplsFTNMapStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this entry."
::= { mplsFTNMapEntry 5 }
-- End of mplsFTNMapTable
-- FTN entry performance table
mplsFTNPerfTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsFTNPerfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains performance statistics on FTN
entries on a per-interface basis."
::= { mplsFTNObjects 4 }
mplsFTNPerfEntry OBJECT-TYPE
SYNTAX MplsFTNPerfEntry
MAX-ACCESS not-accessible
Nadeau et al. Expires February 2002 [Page 17]
Internet Draft MPLS FTN MIB August 2001
STATUS current
DESCRIPTION
"Each entry contains performance information for the
specified interface and FTN entry activated/mapped to
this interface."
INDEX { mplsFTNMapIfIndex, mplsFTNMapCurrIndex }
::= { mplsFTNPerfTable 1 }
MplsFTNPerfEntry ::= SEQUENCE {
mplsFTNMatchedPackets Counter32,
mplsFTNMatchedOctets Counter32,
mplsFTNMatchedHCPackets Counter64,
mplsFTNMatchedHCOctets Counter64
}
mplsFTNMatchedPackets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of packets that matched the specified FTN entry
if it is applied/mapped to the specified interface."
::= { mplsFTNPerfEntry 1 }
mplsFTNMatchedOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of octets that matched the specified FTN entry
if it is applied/mapped to the specified interface."
::= { mplsFTNPerfEntry 2 }
mplsFTNMatchedHCPackets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"High-capacity counter for the number of packets that
matched the specified FTN entry if it is applied/mapped
to the specified interface."
::= { mplsFTNPerfEntry 3 }
mplsFTNMatchedHCOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"High-capacity counter for the number of octets that
matched the specified FTN entry if it is applied/mapped
Nadeau et al. Expires February 2002 [Page 18]
Internet Draft MPLS FTN MIB August 2001
to the specified interface."
::= { mplsFTNPerfEntry 4 }
-- End of mplsFTNPerfTable
-- Module compliance.
mplsFTNGroups
OBJECT IDENTIFIER ::= { mplsFTNConformance 1 }
mplsFTNCompliances
OBJECT IDENTIFIER ::= { mplsFTNConformance 2 }
mplsFTNModuleCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for agents that support the MPLS
FTN MIB."
MODULE -- this module
-- The mandatory groups have to be implemented
-- by all LSRs. However, they may all be supported
-- as read-only objects in the case where manual
-- configuration is unsupported.
MANDATORY-GROUPS {
mplsFTNRuleGroup,
mplsFTNMapGroup
}
GROUP mplsFTNHCPerfGroup
DESCRIPTION
"This group is mandatory for those performance entries
for which the object mplsFTNMatchedHCOctets and
mplsFTNMatchedHCPackets wrap around too quickly."
::= { mplsFTNCompliances 1 }
-- Units of conformance.
mplsFTNRuleGroup OBJECT-GROUP
OBJECTS {
mplsFTNIndexNext,
mplsFTNRowStatus,
mplsFTNDescr,
mplsFTNApplied,
mplsFTNMask,
mplsFTNAddrType,
mplsFTNSourceIpv4AddrMin,
mplsFTNSourceIpv6AddrMin,
mplsFTNSourceIpv4AddrMax,
Nadeau et al. Expires February 2002 [Page 19]
Internet Draft MPLS FTN MIB August 2001
mplsFTNSourceIpv6AddrMax,
mplsFTNDestIpv4AddrMin,
mplsFTNDestIpv6AddrMin,
mplsFTNDestIpv4AddrMax,
mplsFTNDestIpv6AddrMax,
mplsFTNSourcePortMin,
mplsFTNSourcePortMax,
mplsFTNDestPortMin,
mplsFTNDestPortMax,
mplsFTNProtocol,
mplsFTNActionType,
mplsFTNActionPointer,
mplsFTNExpBits,
mplsFTNStorageType
}
STATUS current
DESCRIPTION
"Collection of objects needed for MPLS FTN
configuration."
::= { mplsFTNGroups 1 }
mplsFTNMapGroup OBJECT-GROUP
OBJECTS {
mplsFTNMapIfIndex,
mplsFTNMapPrevIndex,
mplsFTNMapCurrIndex,
mplsFTNMapRowStatus,
mplsFTNMapStorageType
}
STATUS current
DESCRIPTION
"Collection of objects needed for MPLS FTN activation."
::= { mplsFTNGroups 2 }
mplsFTNPerfGroup OBJECT-GROUP
OBJECTS {
mplsFTNMatchedPackets,
mplsFTNMatchedOctets
}
STATUS current
DESCRIPTION
"Collection of objects needed for MPLS FTN performance
monitoring."
::= { mplsFTNGroups 3 }
mplsFTNHCPerfGroup OBJECT-GROUP
OBJECTS {
mplsFTNMatchedHCPackets,
mplsFTNMatchedHCOctets
}
Nadeau et al. Expires February 2002 [Page 20]
Internet Draft MPLS FTN MIB August 2001
STATUS current
DESCRIPTION
"Collection of objects needed for MPLS FTN performance
monitoring using high-capacity counters."
::= { mplsFTNGroups 4 }
END
9. Security Considerations
It is clear that this MIB can be used for configuration of certain
objects, and anything that can be configured can be incorrectly
configured, with potentially disastrous results.
At this writing, no security holes have been identified beyond those
that SNMP Security [RFC2271] is itself intended to address. These
relate to primarily controlled access to sensitive information and
the ability to configure a device - or which might result from
operator error, which is beyond the scope of any security
architecture.
There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. The use of SNMP Version 3 is recommended over
prior versions, for configuration control, as its security model is
improved.
SNMPv1 or SNMPv2 are by themselves not a secure environment. Even if
the network itself is secure (for example by using IPSec [IPSEC]),
there is no control as to who on the secure network is allowed to
access and GET/SET (read/change/create/delete) the objects in this
MIB. 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 [RFC2274] and the View-based Access
Control [RFC2275] is recommended. It is then a customer/user
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB 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.
There are a number of managed objects in this MIB that may contain
information that may be sensitive from a business perspective, in
that they represent a customer's interface to the MPLS network.
Allowing uncontrolled access to these objects could result in
malicious and unwanted disruptions of network traffic or incorrect
configurations for these customers. There are no objects that are
Nadeau et al. Expires February 2002 [Page 21]
Internet Draft MPLS FTN MIB August 2001
particularly sensitive in their own right, such as passwords or
monetary amounts.
10. References
[LSRMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS
Label Switch Router Management Information Base Using
RFC1902", Internet Draft <draft-ietf-mpls-lsr-mib-
07.txt>, January 2001.
[TEMIB] Srinivasan, C., Viswanathan, A. and Nadeau, T., "MPLS
Traffic Engineering Management Information Base Using
RFC1902", Internet Draft <draft-ietf-mpls-te-mib-
06.txt>, March 2001.
[TCMIB] Nadeau, T., Cucchiara, J., Srinivasan, C, Viswanathan,
A. and H. Sjostrand, "Definition of Textual
Conventions and OBJECT-IDENTITIES for Multi-Protocol
Label Switching (MPLS) Management", Internet Draft
<draft-ietf-mpls-tc-mib-01.txt>, August 2001.
[RFC1155] Rose, M., and K. McCloghrie, "Structure and
Identification of Management Information for TCP/IP-
based Internets", RFC 1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol", RFC 1157, May
1990.
[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB
Definitions", RFC 1212, March 1991.
[RFC1215] M. Rose, "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
[RFC1902] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Structure of Management Information for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC
1902, January 1996.
[RFC1903] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, SNMP
Research, Inc., Cisco Systems, Inc., January 1996.
Nadeau et al. Expires February 2002 [Page 22]
Internet Draft MPLS FTN MIB August 2001
[RFC1904] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Conformance Statements for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1904,
January 1996.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905,
January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1906,
January 1996.
[RFC2233] McCloghrie, K. and F. Kastenholtz, "The Interface
Group MIB Using RFC1902", RFC 2233, November 1997.
[RFC2271] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management
Frameworks", RFC 2271, January 1998.
[RFC2272] Case, J., Harrington D., Presuhn R., and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", RFC 2272, January
1998.
[RFC2273] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
Applications", RFC 2273, January 1998
[RFC2274] Blumenthal, U., and B. Wijnen, "User-based Security
Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)", RFC 2274, January 1998.
[RFC2275] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-
based Access Control Model (VACM) for the Simple
Network Management Protocol (SNMP)", RFC 2275, January
1998.
[RFC2851] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet
Network Addresses", RFC 2851, June 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
11. Authors' Addresses
Nadeau et al. Expires February 2002 [Page 23]
Internet Draft MPLS FTN MIB August 2001
Thomas D. Nadeau
Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA 01824
Phone: +1-978-244-3051
Email: tnadeau@cisco.com
Cheenu Srinivasan
Alphion Corp.
4 Industrial Way West
Eatontown, NJ 07724
Phone: +1-732-676-7066
Email: cheenu@alphion.com
Arun Viswanathan
Force10 Networks, Inc.
1440 McCarthy Blvd
Milpitas, CA 95035
Phone: +1-408-571-3516
Email: arun@force10networks.com
12. Acknowledgements
We would like to thank Joan Cucchiara and Adrian Grise for their
insightful comments and additions to this draft.
13. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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 in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
Nadeau et al. Expires February 2002 [Page 24]
Internet Draft MPLS FTN MIB August 2001
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Nadeau et al. Expires February 2002 [Page 25]
|
|