OBJECT tePathName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathConfiguredRoute
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathBandwidth
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathIncludeAny
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathIncludeAll
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathExclude
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathSetupPriority
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHoldPriority
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathProperties
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathAdminStatus
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopAddrType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopAddress
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
::= { teModuleCompliance 3 }
teModuleServerFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "When this MIB module is implemented by a path
computation server with support for read-create,
then the implementation can claim full
compliance.
"
MODULE -- enclosing module, i.e., TE-MIB
MANDATORY-GROUPS {
teTrafficEngineeringGroup
}
GROUP teNotificationGroup
DESCRIPTION "Implementation of this group is optional."
OBJECT teAdminGroupRowStatus
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION "Support for notInService, createAndWait, and
notReady is not required.
"
OBJECT teTunnelRowStatus
SYNTAX RowStatus { active(1), notInService(2) }
WRITE-SYNTAX RowStatus { active(1), notInService(2),
createAndGo(4), destroy(6)
}
DESCRIPTION "Support for createAndWait and notReady is not
required.
"
OBJECT teTunnelSourceAddressType
DESCRIPTION "Write access is required. An implementation
of a path computation server SHOULD support all
types of tunnel source address types.
"
OBJECT tePathRowStatus
SYNTAX RowStatus { active(1), notInService(2) }
WRITE-SYNTAX RowStatus { active(1), notInService(2),
createAndGo(4), destroy(6)
}
DESCRIPTION "Support for createAndWait and notReady is not
required.
"
OBJECT tePathHopRowStatus
SYNTAX RowStatus { active(1), notInService(2) }
WRITE-SYNTAX RowStatus { active(1), notInService(2),
createAndGo(4), destroy(6)
}
DESCRIPTION "Support for createAndWait and notReady is not
required.
"
::= { teModuleCompliance 4 }
END
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[4] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[5] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions
(TCs) for Multiprotocol Label Switching (MPLS) Management", RFC
3811, June 2004.
[6] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing Simple Network Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002.
[7] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", RFC
2702, September 1999.
6.2. Informative References
[8] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[9] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction
and Applicability Statements for Internet-Standard Management
Framework", RFC 3410, December 2002.
[10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.
[11] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
[12] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L.,
Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,
Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-
Based LSP Setup using LDP", RFC 3212, January 2002.
7. Security Considerations
This MIB module relates to the configuration and management of
Traffic Engineering tunnels. The unauthorized manipulation of fields
in the tables teAdminGroupTable, teTunnelTable, tePathTable, and
tePathHopTable may lead to tunnel flapping, tunnel paths being
changed, or traffic being disrupted. In addition, if these tables
are read by unauthorized parties, the information can be used to
trace traffic patterns, traffic volumes, and tunnel paths. This may
be considered proprietary and confidential information by some
providers.
There are a number of management objects defined in this MIB module
with 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. These are the tables and objects and their
sensitivity/vulnerability:
teAdminGroupTable: Changing this will affect the semantics of include
and exclude constraints, and thus traffic takes unintended routes.
teTunnelTable: Changing this affects many properties of traffic
tunnels.
tePathTable: Changing this affects the constraints (including
bandwidth) of tunnel paths, as well as the status of the path.
tePathHopTable: Changing this affects the route followed by a traffic
tunnel path.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
teTunnelTable: Describes tunnel endpoints and traffic volumes.
tePathTable: Describes path properties.
tePathHopTable: Describes path routes.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, 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 module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [9], section 8), including full
support for the SNMPv3 cryptographic mechanisms (for authentication
and privacy).
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.
Acknowledgments
It was Tony Li’s suggestion that the author embark on this MIB. Many
thanks to him and to Der-Hwa Gan for their input and help.
Many thanks, too, to Bert Wijnen for his incredible help, both with
improving the correctness, structure, and readability of the MIB
module, and with the text of the RFC. Thanks also to Adrian Farrel
for his detailed review.
Author’s Address
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.