RFC 6825
Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS
Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS π¦
okay bestie, this is RFC 6825 πβ¨ It's an IETF document, filed under the Standards Track category, published in January 2013, with ISSN 2070-1721. The authors are M. Miyazawa (KDDI R&D Labs), T. Otani, K. Kumaki (KDDI Corporation), and T. Nadeau (Juniper Networks). The title block doesn't list anything it obsoletes or updates, so no other RFC is being replaced or amended here π
Abstract
this memo defines the Management Information Base (MIB) objects for managing Traffic Engineering Database (TED) information, with extensions for Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) and Generalized MPLS (GMPLS), so network management protocols can read it πΈ
Status of This Memo
this is an Internet Standards Track document π«Ά
it comes from the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. it went through public review and the Internet Engineering Steering Group (IESG) approved it for publication. if you want more on how Internet Standards work, check Section 2 of RFC 5741.
for the current status, any errata, and where to send feedback, go to http://www.rfc-editor.org/info/rfc6825 π
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. π
this document is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. please read those carefully, because they spell out your rights and restrictions for this document. any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.
this document may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. the people who control the copyright in some of that material may not have given the IETF Trust permission to allow changes to it outside the IETF Standards Process. unless you get a proper license from those copyright holders, this document must not be modified outside the IETF Standards Process, and derivative works of it must not be created outside the IETF Standards Process. the one exceptions are formatting it for publication as an RFC or translating it into languages other than English π
Table of Contents
1. The Internet-Standard Management Framework ......................3
2. Introduction ....................................................3
3. Overview ........................................................4
3.1. Conventions Used in This Document ..........................4
3.2. Terminology ................................................4
3.3. Acronyms ...................................................5
4. Motivations .....................................................5
5. Brief Description of MIB Module .................................5
5.1. tedTable ...................................................5
5.2. tedLocalIfAddrTable ........................................5
5.3. tedRemoteIfAddrTable .......................................5
5.4. tedSwCapTable ..............................................6
5.5. tedSrlgTable ...............................................6
6. Example of the TED MIB Module Usage .............................6
7. TED MIB Module Definitions in Support of GMPLS ..................9
8. Security Considerations ........................................35
9. IANA Considerations ............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
11. Acknowledgments ...............................................39
1. The Internet-Standard Management Framework β¨
if you want the full tour of the documents behind the current Internet-Standard Management Framework, check section 7 of RFC 3410 [RFC3410] π
managed objects live in a virtual information store called the Management Information Base, or MIB. you usually reach MIB objects through the Simple Network Management Protocol (SNMP). the objects are defined using the rules in the Structure of Management Information (SMI). this memo specifies a MIB module that complies with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580] π
2. Introduction
the OSPF MIB was first defined for OSPF version 2 to support IPv4 [RFC4750], and then extended to support the Internet Protocol version 6 (IPv6) as the OSPF version 3 MIB [RFC5643]. the IS-IS MIB is defined in [RFC4444] too. on the other side, MPLS and GMPLS traffic engineering has so far extended the OSPF and IS-IS routing protocols with TE functionality [RFC4202] [RFC3630] [RFC5329] [RFC5307] [RFC5305]. to manage these MPLS-TE and GMPLS networks well, it's preferred that network management use routing information tied to the MPLS and GMPLS TE parameters π§ the problem is that there's no clear definition of MPLS or GMPLS TE information in the existing MIBs for OSPF (v2 and v3) or IS-IS, so that's the gap this memo fills.
this memo defines the MIB objects for managing TED in support of MPLS-TE and GMPLS, for use with network management protocols π¦
this MIB module should be used together with the OSPFv2 MIB, the OSPF v3 MIB, and the IS-IS MIB, as well as the other MIBs defined in [RFC3812], [RFC3813], [RFC4802], and [RFC4803] for managing MPLS and GMPLS traffic engineering information. when you implement those MIB modules, you can understand the entire MPLS/GMPLS network at once, like seeing routing information and LSP information together in a management system. but here's the lowkey good news: this MIB module can be implemented and used without the other MIB modules, for example when the management system only needs MPLS/GMPLS topology information, like TE link information π
3. Overview
3.1. Conventions Used in This Document
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] π«Ά
3.2. Terminology
the definitions of key terms for MPLS Operations, Administration, and Maintenance (OAM) and GMPLS are in [RFC4377] and [RFC3945]. the reader is assumed to already know those definitions, so they aren't repeated here π
3.3. Acronyms
GMPLS: Generalized Multiprotocol Label Switching
IS-IS: Intermediate System to Intermediate System
LSA: Link State Advertisement
LSP: Label Switching Path
LSR: Label Switching Router
MIB: Management Information Base
OSPF: Open Shortest Path First
PSC: Packet Switch Capable
SRLG: Shared Risk Link Group
TE: Traffic Engineering
TED: Traffic Engineering Database
TDM: Time Division Multiplexing
4. Motivations
the existing OSPFv2, OSPFv3, IS-IS, MPLS, and GMPLS MIBs don't give you a management interface for pulling the topology information of MPLS and GMPLS networks. ngl that's the whole reason this module exists ππ
5. Brief Description of MIB Module
the objects in this section support managing the TED as described in [RFC4202], [RFC4203], and [RFC5307] for the GMPLS extensions, and in [RFC3630] and [RFC5305] for MPLS/GMPLS πΈ
5.1. tedTable
the TED table is basically used to show TED information for OSPF-TE or ISIS-TE. the catch is that this table doesn't hold the Local/Remote Interface IP Address, the Interface Switching Capability Descriptor, or the Shared Risk Link Group information that lives in the sub-TLVs of the Link-TLV π
5.2. tedLocalIfAddrTable
the tedLocalIfAddrTable matches the Local Interface IP Address information in a sub-TLV of the Link-TLV. it's defined on its own because the Interface IP Address sub-TLV can show up more than once with the same Link-TLV π
5.3. tedRemoteIfAddrTable
the tedRemoteIfAddrTable matches the Remote Interface IP Address information in a sub-TLV of the Link-TLV. it's defined on its own for the same reason: the Interface IP Address sub-TLV can appear more than once with the same Link-TLV β¨
5.4. tedSwCapTable
the tedSwCapTable matches the Interface Switching Capability Descriptor information in a sub-TLV of the Link-TLV. it's defined separately because the Interface Switching Capability Descriptor sub-TLV can appear more than once with the same Link-TLV π
5.5. tedSrlgTable
the tedSrlgTable matches the Shared Risk Link Group information in a sub-TLV of the Link-TLV. it's defined on its own because the Shared Risk Link Group sub-TLV can appear more than once with the same Link-TLV π
part 1 is done, bestie π more parts are coming, so stay tuned π«Ά
6. Example of the TED MIB Module Usage π
okay so this section is the fun one π we're walking through a real example of the TED MIB module in action. the info below is for a numbered TE link that starts in a GMPLS-controlled node. heads up though: if you're pulling TE link info from an MPLS network, the GMPLS-specific stuff (tedLocalIfAddrTable, tedRemoteIfAddrTable, tedSwCapTable, and tedSrlgTable) is not supported π
if the management system keeps retrieving this info on a regular schedule, it can totally map out the detailed topology of MPLS/GMPLS networks β¨ the basic TED info comes from tedTable. the Local and Remote Interface IP Address info for MPLS/GMPLS networks comes from tedLocalIfAddrTable and tedRemoteIfAddrTable. the attribute info for GMPLS TE links comes from tedSwCapTable and tedSrlgTable. fault management?? not this MIB module π there's no way in here to notify you about network failures. BUT if the network topology changes, the module can tell the management system about it using tedStatusChange, tedEntryCreated, and tedEntryDeleted π¦
the main thing to remember: the TED MIB module is limited to "read-only" access, except for tedCreatedDeletedNotificationMaxRate and tedStatusChangeNotificationMaxRate π it's designed to be independent of the OSPF or IS-IS MIBs, but the info for each TE link still belongs to a node or a link that the routing protocol manages. it's giving well-organized π
In tedTable:
{
tedLinkInformationData.2.3232235777.3232235778.16777264 zeroDotZero
tedLinkType.2.3232235777.3232235778.16777264 pointToPoint(1)
tedLinkState.2.3232235777.3232235778.16777264 up(1)
tedAreaId.2.3232235777.3232235778.16777264 0
tedTeRouterIdAddrType.2.3232235777.3232235778.16777264 ipv4(1)
tedTeRouterIdAddr.2.3232235777.3232235778.16777264 192.0.2.1
tedLinkIdAddrType.2.3232235777.3232235778.16777264 ipv4(1)
tedLinkIdAddr.2.3232235777.3232235778.16777264 192.0.2.10
tedMetric.2.3232235777.3232235778.16777264 1
tedMaxBandwidth.2.3232235777.3232235778.16777264 4d9450c0
tedMaxReservableBandwidth.2.3232235777.3232235778.16777264 4d9450c0
tedUnreservedBandwidthPri0.2.3232235777.3232235778.16777264 4d9450c0
tedUnreservedBandwidthPri1.2.3232235777.3232235778.16777264 4d9450c0
tedUnreservedBandwidthPri2.2.3232235777.3232235778.16777264 4d9450c0
tedUnreservedBandwidthPri3.2.3232235777.3232235778.16777264 4d9450c0
tedUnreservedBandwidthPri4.2.3232235777.3232235778.16777264 4d9450c0
tedUnreservedBandwidthPri5.2.3232235777.3232235778.16777264 4d9450c0
tedUnreservedBandwidthPri6.2.3232235777.3232235778.16777264 4d9450c0
tedUnreservedBandwidthPri7.2.3232235777.3232235778.16777264 4d9450c0
tedAdministrativeGroup.2.3232235777.3232235778.16777264 0
tedLocalId.2.3232235777.3232235778.16777264 0
tedRemoteId.2.3232235777.3232235778.16777264 0
tedLinkProtectionType.2.3232235777.3232235778.16777264 01 00 00 00 7
}
In tedLocalIfAddrTable:
{
tedLocalIfAddrType.16777264.192.0.2.21 ipv4(1)
}
In tedRemoteIfAddrTable:
{
tedRemoteIfAddrType.16777264.192.0.2.22 ipv4(1)
}
In tedSwCapTable:
{
tedSwCapType.16777264.1 lsc(150)
tedSwCapEncoding.16777264.1 ethernet(2)
tedSwCapMaxLspBandwidthPri0.16777264.1 4d9450c0
tedSwCapMaxLspBandwidthPri1.16777264.1 4d9450c0
tedSwCapMaxLspBandwidthPri2.16777264.1 4d9450c0
tedSwCapMaxLspBandwidthPri3.16777264.1 4d9450c0
tedSwCapMaxLspBandwidthPri4.16777264.1 4d9450c0
tedSwCapMaxLspBandwidthPri5.16777264.1 4d9450c0
tedSwCapMaxLspBandwidthPri6.16777264.1 4d9450c0
tedSwCapMaxLspBandwidthPri7.16777264.1 4d9450c0
tedSwCapMinLspBandwidth.16777264.1 0
tedSwCapIfMtu.16777264.1 0
tedSwCapIndication.16777264.1 standard(0)
}
In tedSrlgTable:
{
tedSrlg.16777264.1 0
}
7. TED MIB Module Definitions in Support of GMPLS π§
this MIB module references the following documents, so bookmark these bestie π
[RFC2328], [RFC2578], [RFC2580], [RFC3630], [RFC4001], [RFC4203], [RFC4220], [RFC4444], [RFC4801], [RFC4802], [RFC5305], [RFC5307], [RFC5329], [RFC5340], [RFC6340], and [ISO10589].
okay, here's the actual MIB module. the formatting is strict, so I've copied it exactly π
TED-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, transmission,
NOTIFICATION-TYPE
FROM SNMPv2-SMI -- RFC 2578
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF -- RFC 2580
TEXTUAL-CONVENTION, RowPointer
FROM SNMPv2-TC -- RFC 2579
IANAGmplsLSPEncodingTypeTC, IANAGmplsSwitchingTypeTC
FROM IANA-GMPLS-TC-MIB -- RFC 4802
InetAddress, InetAddressType
FROM INET-ADDRESS-MIB -- RFC 4001
Float32TC
FROM FLOAT-TC-MIB -- RFC 6340
;
tedMIB MODULE-IDENTITY
LAST-UPDATED "201212210000Z" -- 21 Dec. 2012 00:00:00 GMT
ORGANIZATION "IETF CCAMP Working Group."
CONTACT-INFO
" Tomohiro Otani
Tm-otani@kddi.com
Masanori Miyazawa
ma-miyazawa@kddilabs.jp
Thomas D. Nadeau
tnadeau@juniper.net
Kenji Kumaki
ke-kumaki@kddi.com
Comments and discussion to ccamp@ietf.org"
DESCRIPTION
"This MIB module contains managed object definitions for TED in
support of MPLS/GMPLS TE Database.
Copyright (c) 2013 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in
Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
Documents (http://trustee.ietf.org/license-info)."
-- Revision history.
REVISION
"201212210000Z" -- 21 Dec. 2012 00:00:00 GMT
DESCRIPTION
"Initial version. Published as RFC 6825."
::= { transmission 273 }
-- assigned by IANA; see Section 9 for details.
-- Textual Conventions.
TedAreaIdTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The area identifier of the IGP. If OSPF is used to advertise
LSA, this represents an ospfArea. If IS-IS is used, this
represents an area address."
SYNTAX OCTET STRING (SIZE (0..20))
TedRouterIdTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The router identifier. If OSPF is used to advertise LSA, this
represents a Router ID. If IS-IS is used, this represents a
System ID."
SYNTAX OCTET STRING (SIZE (0..6))
TedLinkIndexTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The link identifier. If OSPF is used, this represents an
ospfLsdbID. If IS-IS is used, this represents an isisLSPID.
If a locally configured link is used, this object represents an
arbitrary value, which is locally defined in a router."
SYNTAX OCTET STRING (SIZE (0..8))
-- Top-level components of this MIB module.
tedNotifications OBJECT IDENTIFIER ::= { tedMIB 0 }
tedObjects OBJECT IDENTIFIER ::= { tedMIB 1 }
tedConformance OBJECT IDENTIFIER ::= { tedMIB 2 }
-- TED Table
tedTable OBJECT-TYPE
SYNTAX SEQUENCE OF TedEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table indicates multiple TED information, which has been
supported by RFC 3630 and RFC 5305."
::= { tedObjects 1 }
tedEntry OBJECT-TYPE
SYNTAX TedEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This entry contains TED information commonly utilized in both
MPLS and GMPLS."
INDEX { tedLocalRouterId, tedRemoteRouterId,
tedLinkInformationSource, tedLinkIndex }
::= { tedTable 1 }
TedEntry ::= SEQUENCE {
tedLinkInformationSource INTEGER,
tedLocalRouterId TedRouterIdTC,
tedRemoteRouterId TedRouterIdTC,
tedLinkIndex TedLinkIndexTC,
tedLinkInformationData RowPointer,
tedLinkState INTEGER,
tedAreaId TedAreaIdTC,
tedLinkType INTEGER,
tedTeRouterIdAddrType InetAddressType,
tedTeRouterIdAddr InetAddress,
tedLinkIdAddrType InetAddressType,
tedLinkIdAddr InetAddress,
tedMetric Integer32,
tedMaxBandwidth Float32TC,
tedMaxReservableBandwidth Float32TC,
tedUnreservedBandwidthPri0 Float32TC,
tedUnreservedBandwidthPri1 Float32TC,
tedUnreservedBandwidthPri2 Float32TC,
tedUnreservedBandwidthPri3 Float32TC,
tedUnreservedBandwidthPri4 Float32TC,
tedUnreservedBandwidthPri5 Float32TC,
tedUnreservedBandwidthPri6 Float32TC,
tedUnreservedBandwidthPri7 Float32TC,
tedAdministrativeGroup Integer32,
tedLocalId Integer32,
tedRemoteId Integer32,
tedLinkProtectionType BITS
}
tedLinkInformationSource OBJECT-TYPE
SYNTAX INTEGER {
unknown(0),
locallyConfigured(1),
ospfv2(2),
ospfv3(3),
isis(4),
other(5)
}
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the source of the information about the
TE link."
::= { tedEntry 1 }
tedLocalRouterId OBJECT-TYPE
SYNTAX TedRouterIdTC
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object represents the Router ID of the router originating
the LSA. If OSPF is used to advertise LSA, this represents a
Router ID. If IS-IS is used, this represents a System ID.
Otherwise, this represents zero."
REFERENCE
"OSPF Version 2, RFC 2328, Appendix C.1
OSPF for IPv6, RFC 5340, Appendix C.1
ISO10589, Section 7.1"
::= { tedEntry 2 }
tedRemoteRouterId OBJECT-TYPE
SYNTAX TedRouterIdTC
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the router at the remote end of the link
from the originating router. If OSPF is used to advertise LSA,
this represents a Link ID in the Link TLV. If IS-IS is used,
this represents a neighbor System ID defined in RFC 5305.
Otherwise, this represents zero."
REFERENCE
"OSPF Version 2, RFC 2328, Appendix C.1
OSPF for IPv6, RFC 5340, Appendix C.1
ISO10589, Section 7.1"
::= { tedEntry 3 }
Okay so, the MIB objects are where this spec gets really real π Every one of these is a read-only slot in the TED table, and each has its own little job, so let's go through them.
First up is the link identifier, which is basically the name tag for each link π
tedLinkIndex OBJECT-TYPE
SYNTAX TedLinkIndexTC
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the link state identifier. If OSPF is
used, this represents an ospfLsdbID. If IS-IS is used, this
represents an isisLSPID. Otherwise, this represents a unique
identifier within a node."
REFERENCE
"OSPF Version 2, RFC 2328, Appendix A.4.1,
OSPF for IPv6, RFC 5340, Appendix A.4.2
ISO10589, Section 9.8 "
::= { tedEntry 4 }
tedLinkInformationData OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If tedLinkInformationSource has the value unknown(0), this
object MUST contain a value of zeroDotZero.
If tedLinkInformationSource has the value locallyConfigured(1),
an implementation can use this object to supply the identifier
of the corresponding row entry in the teLinkTable of TE-LINK-
STD-MIB (RFC 4220), the identifier of the corresponding row in
a local proprietary TE link MIB module, or the value of
zeroDotZero.
If tedLinkInformationSource has the value ospfv2(2) and
ospfv3(3), an implementation can use this object to supply the
identifier of the corresponding row entry in the
ospfLocalLsdbTable (OSPFv2-MIB) and the ospfv3AreaLsdbTable
(OSPFv3-MIB), or the value of zeroDotZero.
If tedLinkInformationSource has the value isis(4), an
implementation can use this object to supply the identifier of
the corresponding row entry in the isisAreaAddr of ISIS-MIB
(RFC 4444), or the value of zeroDotZero.
If tedLinkInformationSource has the value other(5), an
implementation can use this object to supply the identifier of
the corresponding row entry in the local proprietary MIB module,
or the value of zeroDotZero."
::= { tedEntry 5 }
tedLinkState OBJECT-TYPE
SYNTAX INTEGER {
unknown (0),
up (1),
down (2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object represents the actual operational state of this TE
link. For instance, if a row is created in the TED table, but
the actual TE link is not available for some reason (e.g., when
there is not yet a physical link or the link has been manually
disabled), then the object would be down(2) state.
In contrast, if a row is added and the TE link is available,
this would be operationally up(1)."
::= { tedEntry 6 }
tedAreaId OBJECT-TYPE
SYNTAX TedAreaIdTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the area identifier of the IGP. If OSPF
is used to advertise LSA, this represents an ospfArea. If IS-IS
is used, this represents an area address. Otherwise, this
represents zero."
REFERENCE
"OSPF Version 2, RFC 2328, Appendix C.2
OSPF for IPv6, RFC 5340, Appendix C.2
ISO10589, Section 9.8"
::= { tedEntry 7 }
tedLinkType OBJECT-TYPE
SYNTAX INTEGER {
pointToPoint (1),
multiAccess (2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the type of the link, such as point to point or
multi-access."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.1"
::= { tedEntry 8 }
tedTeRouterIdAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the TE-Router ID address type. Only
values unknown(0), ipv4(1), or ipv6(2) are supported."
::= { tedEntry 9 }
tedTeRouterIdAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the TE-Router ID."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.4.1
IS-IS extensions for TE, RFC 5305, Section 4.3"
::= { tedEntry 10 }
tedLinkIdAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the address type of the TE Link ID. Only
values unknown(0), ipv4(1), or ipv6(2) are supported."
::= { tedEntry 11 }
tedLinkIdAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the Router ID of the neighbor in the case of
point-to-point links. This also indicates the interface
address of the designated router in the case of multi-access
links."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.2
IS-IS extensions for TE, RFC 5305, Section 4.3"
::= { tedEntry 12 }
Next up are the link stats and the bandwidth crew, which are all read-only and all measured in Byte per second π
tedMetric OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the traffic engineering metric value of the TE
link."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.5
IS-IS extensions for TE, RFC 5305, Section 3.7"
::= { tedEntry 13 }
tedMaxBandwidth OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the maximum bandwidth that can be used on this
link in this direction."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.6
IS-IS extensions for TE, RFC 5305, Section 3.4"
::= { tedEntry 14 }
tedMaxReservableBandwidth OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the maximum bandwidth that may be reserved on
this link in this direction."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.7
IS-IS extensions for TE, RFC 5305, Section 3.5"
::= { tedEntry 15 }
tedUnreservedBandwidthPri0 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the amount of bandwidth not yet reserved at the
priority 0."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.8
IS-IS extensions for TE, RFC 5305, Section 3.6"
::= { tedEntry 16 }
tedUnreservedBandwidthPri1 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the amount of bandwidth not yet reserved at the
priority 1."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.8
IS-IS extensions for TE, RFC 5305, Section 3.6"
::= { tedEntry 17 }
tedUnreservedBandwidthPri2 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the amount of bandwidth not yet reserved at the
priority 2."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.8
IS-IS extensions for TE, RFC 5305, Section 3.6"
::= { tedEntry 18 }
tedUnreservedBandwidthPri3 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the amount of bandwidth not yet reserved at the
priority 3."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.8
IS-IS extensions for TE, RFC 5305, Section 3.6"
::= { tedEntry 19 }
tedUnreservedBandwidthPri4 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the amount of bandwidth not yet reserved at the
priority 4."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.8
IS-IS extensions for TE, RFC 5305, Section 3.6"
::= { tedEntry 20 }
tedUnreservedBandwidthPri5 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the amount of bandwidth not yet reserved at the
priority 5."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.8
IS-IS extensions for TE, RFC 5305, Section 3.6"
::= { tedEntry 21 }
tedUnreservedBandwidthPri6 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the amount of bandwidth not yet reserved at the
priority 6."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.8
IS-IS extensions for TE, RFC 5305, 3.6"
::= { tedEntry 22 }
tedUnreservedBandwidthPri7 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the amount of bandwidth not yet reserved at the
priority 7."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.8
IS-IS extensions for TE, RFC 5305, Section 3.6"
::= { tedEntry 23 }
Last but definitely not least, the group colour and the unnumbered-link IDs π
tedAdministrativeGroup OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the Administrative Group to which the link
belongs. Since the value is a bit mask, the link can belong
to multiple groups. This is also called Resource Class/Color."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.9
IS-IS extensions for TE, RFC 5305, Section 3.1"
::= { tedEntry 24 }
tedLocalId OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the Link Local Identifier of an unnumbered
link."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.1
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.1"
::= { tedEntry 25 }
tedRemoteId OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the Link Remote Identifier of an unnumbered
link."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.1
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.1"
::= { tedEntry 26 }
The admin group is basically a bit mask, so one link can wear multiple colours at once. Iconic π¦
Okay bestie, the TED MIB tables are next, and they're giving structure πβ¨
The first thing is the protection type object, tedLinkProtectionType π
tedLinkProtectionType OBJECT-TYPE
SYNTAX BITS {
extraTraffic(0),
unprotected(1),
shared (2),
dedicatedOneToOne (3),
dedicatedOnePlusOne(4),
enhanced(5)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the protection type of the TE link."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.2
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.2"
::= { tedEntry 27 }
-- TED Local Interface IP Address Table
tedLocalIfAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF TedLocalIfAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the IP address information of a local TE
link."
::= { tedObjects 2 }
tedLocalIfAddrEntry OBJECT-TYPE
SYNTAX TedLocalIfAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This entry contains the IP address information of the local TE
link."
INDEX { tedLinkIndex, tedLocalIfAddr }
::= { tedLocalIfAddrTable 1 }
TedLocalIfAddrEntry ::= SEQUENCE {
tedLocalIfAddrType InetAddressType,
tedLocalIfAddr InetAddress
}
tedLocalIfAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the address type of the local TE link.
Only values unknown(0), ipv4(1), or ipv6(2) have to be
supported."
::= { tedLocalIfAddrEntry 1 }
tedLocalIfAddr OBJECT-TYPE
SYNTAX InetAddress (SIZE (1..20))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the address of the local TE link."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.3,
Traffic Engineering Extensions to OSPF Version 3, RFC 5329,
Section 4.3
IS-IS extensions for TE, RFC 5305, Section 3.4"
::= { tedLocalIfAddrEntry 2 }
-- TED Remote Interface IP Address Table
tedRemoteIfAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF TedRemoteIfAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the IP address information of a remote TE
link."
::= { tedObjects 3 }
tedRemoteIfAddrEntry OBJECT-TYPE
SYNTAX TedRemoteIfAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This entry contains the IP address information of the remote
TE link."
INDEX { tedLinkIndex, tedRemoteIfAddr }
::= { tedRemoteIfAddrTable 1 }
TedRemoteIfAddrEntry ::= SEQUENCE {
tedRemoteIfAddrType InetAddressType,
tedRemoteIfAddr InetAddress
}
tedRemoteIfAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the address type of the remote TE link."
::= { tedRemoteIfAddrEntry 1 }
tedRemoteIfAddr OBJECT-TYPE
SYNTAX InetAddress(SIZE (1..20))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the address of the remote TE link."
REFERENCE
"Traffic Engineering (TE) Extensions to OSPF Version 2,
RFC 3630, Section 2.5.4,
Traffic Engineering Extensions to OSPF Version3, RFC 5329,
Section 4.4
IS-IS extensions for TE, RFC 5305, Section 3.3"
::= { tedRemoteIfAddrEntry 2 }
-- TED Switching Capability Table
tedSwCapTable OBJECT-TYPE
SYNTAX SEQUENCE OF TedSwCapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the GMPLS TED switching capability
information."
::= { tedObjects 4 }
tedSwCapEntry OBJECT-TYPE
SYNTAX TedSwCapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This entry relates each TE link with its GMPLS TE switching
capability information. If the MIB module deals with only OSPF-
TE information, the value of each object related with GMPLS TE
extensions should be null."
INDEX { tedLinkIndex, tedSwCapIndex }
::= { tedSwCapTable 1 }
TedSwCapEntry ::= SEQUENCE {
tedSwCapIndex Unsigned32,
tedSwCapType IANAGmplsSwitchingTypeTC,
tedSwCapEncoding IANAGmplsLSPEncodingTypeTC,
tedSwCapMaxLspBandwidthPri0 Float32TC,
tedSwCapMaxLspBandwidthPri1 Float32TC,
tedSwCapMaxLspBandwidthPri2 Float32TC,
tedSwCapMaxLspBandwidthPri3 Float32TC,
tedSwCapMaxLspBandwidthPri4 Float32TC,
tedSwCapMaxLspBandwidthPri5 Float32TC,
tedSwCapMaxLspBandwidthPri6 Float32TC,
tedSwCapMaxLspBandwidthPri7 Float32TC,
tedSwCapMinLspBandwidth Float32TC,
tedSwCapIfMtu Integer32,
tedSwCapIndication INTEGER
}
tedSwCapIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This index is utilized to identify multiple switching
functions on a local or remote TE link according to definitions
of textual conventions of GMPLS, RFC 4801."
::= { tedSwCapEntry 1 }
tedSwCapType OBJECT-TYPE
SYNTAX IANAGmplsSwitchingTypeTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the GMPLS switching capability assigned
to the TE link according to definitions of textual conventions
of GMPLS, RFC 4801."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 2 }
tedSwCapEncoding OBJECT-TYPE
SYNTAX IANAGmplsLSPEncodingTypeTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the GMPLS encoding type assigned to the
TE link."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 3 }
tedSwCapMaxLspBandwidthPri0 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum bandwidth of the TE link at
the priority 0 for GMPLS LSP creation."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 4 }
tedSwCapMaxLspBandwidthPri1 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum bandwidth of the TE link at
the priority 1 for GMPLS LSP creation."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 5 }
tedSwCapMaxLspBandwidthPri2 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum bandwidth of the TE link at
the priority 2 for GMPLS LSP creation."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 6 }
tedSwCapMaxLspBandwidthPri3 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum bandwidth of the TE link at
the priority 3 for GMPLS LSP creation."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 7 }
tedSwCapMaxLspBandwidthPri4 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum bandwidth of the TE link at
the priority 4 for GMPLS LSP creation."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 8 }
tedSwCapMaxLspBandwidthPri5 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum bandwidth of the TE link at
the priority 5 for GMPLS LSP creation."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 9 }
tedSwCapMaxLspBandwidthPri6 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum bandwidth of the TE link at
the priority 6 for GMPLS LSP creation."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 10 }
tedSwCapMaxLspBandwidthPri7 OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum bandwidth of the TE link at
the priority 7 for GMPLS LSP creation."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 11 }
tedSwCapMinLspBandwidth OBJECT-TYPE
SYNTAX Float32TC
UNITS "Byte per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the minimum bandwidth of the TE link for
GMPLS LSP creation if the switching capability field is TDM,
PSC-1, PSC-2, PSC-3, or PSC-4."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 12 }
That's the whole switching capability block, and the MIB objects keep coming, so stay tuned π¦π
Okay so we're picking up right where the switching capability entries wrap up π
tedSwCapIfMtu OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the MTU of the local or remote TE link."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 13 }
tedSwCapIndication OBJECT-TYPE
SYNTAX INTEGER {
standard (0),
arbitrary (1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates whether the interface supports Standard
or Arbitrary SONET/SDH."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3"
::= { tedSwCapEntry 14 }
So tedSwCapIfMtu is the MTU for the local or remote TE link π¦, and tedSwCapIndication tells you if the interface does Standard or Arbitrary SONET/SDH π. Both get their definitions from RFC 4203 and RFC 5307, which is giving very well-sourced energy π§
Next up is the SRLG table, which is where each TE link gets its shared risk link group info π
-- TED SRLG Table
tedSrlgTable OBJECT-TYPE
SYNTAX SEQUENCE OF TedSrlgEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the SRLG information of the TE link."
::= { tedObjects 5 }
tedSrlgEntry OBJECT-TYPE
SYNTAX TedSrlgEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This entry relates each TE link with its SRLG information."
INDEX { tedLinkIndex, tedSrlgIndex }
::= { tedSrlgTable 1 }
TedSrlgEntry ::= SEQUENCE {
tedSrlgIndex Unsigned32,
tedSrlg Integer32
}
tedSrlgIndex OBJECT-TYPE
SYNTAX Unsigned32(1..255)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This index is utilized to identify multiple SRLG values on a
local or remote TE link. This object represents an arbitrary
value, which is locally defined in a router."
REFERENCE
"OSPF Extensions in support of GMPLS, RFC 4203, Section 1.3
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.4"
::= { tedSrlgEntry 1 }
tedSrlg OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the SRLG value assigned to a local or
remote TE link."
REFERENCE
"OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.3
IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.4"
::= { tedSrlgEntry 2 }
Quick vibe check: tedSrlgIndex is the one that tells multiple SRLG values apart on a link, and it's a locally defined value inside the router, so it's basically the router's own little label system π
The actual SRLG value lives in tedSrlg β¨
Now the notification config, which is all about not letting your router get overwhelmed by a flood of alerts π
-- Notification Configuration
tedStatusChangeNotificationMaxRate OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A lot of notifications relating to the status change are
expected to generate in a node, especially when a network
failure occurs and might cause a performance degradation of the
node itself. To avoid such a defect, this object provides the
maximum number of notifications generated per minute. If
events occur more rapidly, the implementation may simply fail
to emit these notifications during that period, or may queue
them until an appropriate time. A value of 0 means no
throttling is applied and events may be notified at the rate at
which they occur."
DEFVAL {1}
::= { tedObjects 6 }
tedCreatedDeletedNotificationMaxRate OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A lot of notifications relating to new registration in the TED
table by receiving new TE link information or deletion of
existing entries in the TED table are expected to generate in a
node. This object provides the maximum number of notifications
generated per minute."
DEFVAL {1}
::= { tedObjects 7 }
Honestly the big idea is that a network failure can make a node spam notifications and tank its own performance π So these two objects cap how many get sent per minute π«Ά Default is {1}, and a value of 0 means no throttling at all, so events go out as fast as they happen πΈ
Next are the notifications themselves π
-- Notifications
tedStatusChange NOTIFICATION-TYPE
OBJECTS {
tedLinkState
}
STATUS current
DESCRIPTION
"This notification signifies that there has been change in the
TE information of tedTable, tedLocalIfAddrTable,
tedRemoteIfAddrTable, tedSwCapTable, and/or tedSrlgTable. For
example, this should be generated when tedUnreservedBandwidth is
changed to create or delete LSP using the registered TE link."
::= { tedNotifications 1 }
tedEntryCreated NOTIFICATION-TYPE
OBJECTS {
tedLinkState
}
STATUS current
DESCRIPTION
"This notification signifies that there has been new
registration in the TED table by receiving new TE link
information. For example, this should be generated when a new
index (tedLinkIndex) is registered in the TED table."
::= { tedNotifications 2 }
tedEntryDeleted NOTIFICATION-TYPE
OBJECTS {
tedLinkState
}
STATUS current
DESCRIPTION
"This notification signifies that there has been deletion of an
entry in the TED table. For example, this should be generated
when one of the existing entries is deleted in the TED table."
::= { tedNotifications 3 }
So there are three alarms here: tedStatusChange for when the TE info changes, tedEntryCreated for a brand new entry, and tedEntryDeleted when an entry goes poof π Each one carries tedLinkState as its object β¨
Now the conformance stuff, aka the checklists for who's doing what π
-- Conformance Statement
tedCompliances
OBJECT IDENTIFIER ::= { tedConformance 1 }
tedGroups
OBJECT IDENTIFIER ::= { tedConformance 2 }
-- Module Compliance
tedModuleFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for agents provides full support for the
TED MIB."
MODULE -- this module
MANDATORY-GROUPS { tedMainGroup,
tedObjectsGroup,
tedNotificationGroup
}
GROUP tedUnnumberedLinkGroup
DESCRIPTION
"This group is mandatory for TE links that support the
unnumbered links."
GROUP tedNumberedLinkGroup
DESCRIPTION
"This group is mandatory for TE links that support the
numbered links."
GROUP tedSwCapGroup
DESCRIPTION
"This group is mandatory for TE links that support GMPLS
switching capability."
GROUP tedSwCapMinLspBandwidthGroup
DESCRIPTION
"This group is mandatory for TE links if the switching
capability field is TDM, PSC-1, PSC-2, PSC-3, or PSC-4."
GROUP tedSwCapIfMtuGroup
DESCRIPTION
"This group is mandatory for TE links that support the MTU of
the local or remote TE link."
GROUP tedSwCapIndicationGroup
DESCRIPTION
"This group is mandatory for TE links that support Standard or
Arbitrary SONET/SDH."
GROUP tedSrlgGroup
DESCRIPTION
"This group is mandatory for TE links that support SRLG
information."
::= { tedCompliances 1 }
--
-- ReadOnly Compliance
--
tedModuleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance requirement for implementations only provides read-
only support for TED. Such devices can then be monitored but
cannot be configured using this MIB module."
MODULE -- this module
MANDATORY-GROUPS { tedMainGroup
}
GROUP tedUnnumberedLinkGroup
DESCRIPTION
"This group is mandatory for TE links that support the
unnumbered links."
GROUP tedNumberedLinkGroup
DESCRIPTION
"This group is mandatory for TE links that support the
numbered links."
GROUP tedSwCapGroup
DESCRIPTION
"This group is mandatory for TE links that support some GMPLS
switching capabilities."
GROUP tedSwCapMinLspBandwidthGroup
DESCRIPTION
"This group is mandatory for TE links if the switching
capability field is TDM, PSC-1, PSC-2, PSC-3, or PSC-4."
GROUP tedSwCapIfMtuGroup
DESCRIPTION
"This group is mandatory for TE links that support the MTU of
the local or remote TE link."
GROUP tedSwCapIndicationGroup
DESCRIPTION
"This group is mandatory for TE links that support Standard or
Arbitrary SONET/SDH."
GROUP tedSrlgGroup
DESCRIPTION
"This group is mandatory for TE links that support SRLG
information."
::= { tedCompliances 2 }
Two flavours of compliance here π The full one is for agents that support the whole TED MIB, and the read-only one is for devices you can monitor but not configure through this module π Notice the read-only one only requires tedMainGroup as mandatory, so it's a bit more chill π§
Last bit for this part: the units of conformance, which is basically the bundle of objects grouped together π
-- Units of conformance
tedMainGroup OBJECT-GROUP
OBJECTS {
tedLinkState,
tedAreaId,
tedLinkType,
tedTeRouterIdAddrType,
tedTeRouterIdAddr,
tedLinkIdAddrType,
tedLinkIdAddr,
tedMetric,
tedMaxBandwidth,
tedMaxReservableBandwidth,
tedUnreservedBandwidthPri0,
tedUnreservedBandwidthPri1,
tedUnreservedBandwidthPri2,
tedUnreservedBandwidthPri3,
tedUnreservedBandwidthPri4,
tedUnreservedBandwidthPri5,
tedUnreservedBandwidthPri6,
tedUnreservedBandwidthPri7,
tedAdministrativeGroup,
tedLinkProtectionType,
tedLinkInformationData
}
STATUS current
DESCRIPTION
"Collection of objects for TED management"
::= { tedGroups 1 }
tedObjectsGroup OBJECT-GROUP
OBJECTS {
tedStatusChangeNotificationMaxRate,
tedCreatedDeletedNotificationMaxRate
}
STATUS current
DESCRIPTION
"The objects needed to implement notification."
::= { tedGroups 2 }
tedNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
tedStatusChange,
tedEntryCreated,
tedEntryDeleted
}
STATUS current
DESCRIPTION
"This group is mandatory for those implementations that can
implement the notifications contained in this group."
::= { tedGroups 3 }
tedUnnumberedLinkGroup OBJECT-GROUP
OBJECTS {
tedLocalId,
tedRemoteId
}
STATUS current
DESCRIPTION
"The objects needed to implement the unnumbered links."
::= { tedGroups 4 }
tedNumberedLinkGroup OBJECT-GROUP
OBJECTS {
tedLocalIfAddrType,
tedRemoteIfAddrType
}
STATUS current
DESCRIPTION
"The objects needed to implement the numbered links."
::= { tedGroups 5 }
tedSwCapGroup OBJECT-GROUP
OBJECTS {
tedSwCapType,
tedSwCapEncoding,
tedSwCapMaxLspBandwidthPri0,
tedSwCapMaxLspBandwidthPri1,
tedSwCapMaxLspBandwidthPri2,
tedSwCapMaxLspBandwidthPri3,
tedSwCapMaxLspBandwidthPri4,
tedSwCapMaxLspBandwidthPri5,
tedSwCapMaxLspBandwidthPri6,
tedSwCapMaxLspBandwidthPri7
}
STATUS current
DESCRIPTION
"The objects needed to implement the TE links with GMPLS TE
switching capability information."
::= { tedGroups 6 }
tedSwCapMinLspBandwidthGroup OBJECT-GROUP
OBJECTS {
tedSwCapMinLspBandwidth
}
STATUS current
DESCRIPTION
"The objects needed to implement the minimum bandwidth of the
TE link for GMPLS LSP creation."
::= { tedGroups 7 }
tedSwCapIfMtuGroup OBJECT-GROUP
OBJECTS {
tedSwCapIfMtu
}
STATUS current
DESCRIPTION
"The objects needed to implement the MTU information of the
local or remote TE link."
::= { tedGroups 8 }
Groups are basically the packs of objects you implement together, so you can tell at a glance what each feature needs π The next groups are the SW cap indication one and the SRLG one, so stay tuned π
tedSwCapIndicationGroup OBJECT-GROUP
OBJECTS {
tedSwCapIndication
}
STATUS current
DESCRIPTION
"The objects needed to implement the indication of whether the
interface supports Standard or Arbitrary SONET/SDH."
::= { tedGroups 9 }
tedSrlgGroup OBJECT-GROUP
OBJECTS {
tedSrlg
}
STATUS current
DESCRIPTION
"The objects needed to implement multiple SRLG values with
GMPLS TE information."
::= { tedGroups 10 }
END
Okay, and that's the MIB module wrapped up πβ¨ tedSwCapIndicationGroup covers the indication of whether an interface supports Standard or Arbitrary SONET/SDH π₯, and tedSrlgGroup covers multiple SRLG values with GMPLS TE information π§
8. Security Considerations π
Okay bestie, this part is serious π Several objects in this MIB module have a MAX-ACCESS clause of read-write. Those objects can be sensitive or vulnerable in some network environments. Doing SET operations in a non-secure environment without proper protection can really mess up network operations π
Some of the readable objects in this MIB module (so, objects with a MAX-ACCESS other than not-accessible) can also be sensitive or vulnerable in some environments. So it's important to control even GET and/or NOTIFY access to them, and maybe even encrypt their values when they're sent over the network with SNMP π The tables and objects, and why they're sensitive, are: tedTable, tedLocalIfAddrTable, tedRemoteIfAddrTable, tedSwCapTable, and tedSrlgTable, which all hold topology information for the MPLS/GMPLS network πΊοΈ If an administrator doesn't want to reveal that info, then these tables should be treated as sensitive/vulnerable.
There are only two write-access objects in this MIB module: tedStatusChangeNotificationMaxRate and tedCreatedDeletedNotificationMaxRate. Malicious modification of these objects could overload the management agent, the network, or the router with notifications when there's a lot of churn in the network π¨
SNMP versions before SNMPv3 did not include adequate security π Even if the network itself is secure (for example by using IPsec), there's still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Not it π ββοΈ
Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353] π¦
Further, deploying SNMP versions before SNMPv3 is NOT RECOMMENDED π Instead, it is RECOMMENDED to deploy SNMPv3 and enable cryptographic security π₯ It's then a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is configured so the objects are only accessible to principals (users) who have legitimate rights to GET or SET (change/create/delete) them π
9. IANA Considerations π
IANA has assigned 273 to the TED-MIB module specified in this document, in the "Internet-standard MIB - Transmission Group" registry π New assignments can only be made via Specification Required as specified in [RFC5226].
IANA has also marked value 273 (the corresponding transmission value allocated according to this document) as "Reserved" in the "ifType definitions" registry β¨
10. References π
10.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
- [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., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
- [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
- [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
- [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006.
- [RFC4801] Nadeau, T., Ed., and A. Farrel, Ed., "Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management", RFC 4801, February 2007.
- [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008.
- [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
- [RFC5643] Joyal, D., Ed., and V. Manral, Ed., "Management Information Base for OSPFv3", RFC 5643, August 2009.
- [RFC6340] Presuhn, R., "Textual Conventions for the Representation of Floating-Point Numbers", RFC 6340, August 2011.
10.2. Informative References
- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
- [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, 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.
- [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004.
- [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
- [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
- [RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
- [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
- [RFC4444] Parker, J., Ed., "Management Information Base for Intermediate System to Intermediate System (IS-IS)", RFC 4444, April 2006.
- [RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
- [RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, February 2007.
- [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
- [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
- [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
- [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011.
- [ISO10589] ISO 10589, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002.
11. Acknowledgments π«Ά
The authors want to thank these lovely people for their valuable comments on this document: Ken Nagami, Shuichi Okamoto, Adrian Farrel, Diego Caviglia, and Acee Lindem π
Authors' Addresses π
Masanori Miyazawa
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino
Saitama, 356-8502
Japan
EMail: ma-miyazawa@kddilabs.jp
Tomohiro Otani
KDDI Corporation
KDDI Bldg,
2-3-2, Nishishinjuku, Shinjuku-ku
Tokyo, 163-8003
Japan
EMail: Tm-otani@kddi.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chyoda-ku
Tokyo, 102-8460
Japan
EMail: ke-kumaki@kddi.com
Thomas D. Nadeau
Juniper Networks
10 Technology Park Drive
Westford, MA
USA
EMail: tnadeau@juniper.net
π¦ where this page comes from
- ietf: rfc6825 2013-01
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms