ietf-corpus

rfc-3811

Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management

T. Nadeau (Editor), J. Cucchiara (Editor)
date2004-06 streamIETF areartg wgmpls statusPROPOSED STANDARD pages20 canonicalhttps://www.rfc-editor.org/rfc/rfc3811 doi10.17487/RFC3811 errataview
This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

updated by

Extracted elements (26)

design-rationale §3

TeHopAddressAS uses OCTET STRING (SIZE (4)) rather than Unsigned32 (as used by InetAutonomousSystemsNumber in RFC 3291) to represent AS numbers, allowing both 2-octet and 4-octet AS numbers to be carried in the same field with a consistent network-byte-order encoding.

mpls, snmp

design-rationale §1

This MIB module defines only TEXTUAL-CONVENTIONs rather than management objects, consolidating TC definitions from multiple existing MPLS MIBs to avoid each MPLS MIB module defining its own representations. This avoids duplication and inconsistency across MPLS-related MIB modules.

mpls, snmp

normative-requirement §3 MUST

For MPLS shim header labels, bits 20-31 MUST be zero. Reserved label values are: 0 (IPv4 Explicit NULL), 1 (Router Alert), 2 (IPv6 Explicit NULL), 3 (Implicit NULL), and 4-15 are reserved.

mpls

normative-requirement §3 SHOULD NOT

TeHopAddressType SHOULD NOT be sub-typed in object type definitions to support future extensions; it MAY be sub-typed in compliance statements. Implementations MUST ensure TeHopAddressType and dependent TeHopAddress objects remain consistent, generating an inconsistentValue error on violations.

mpls, snmp

normative-requirement §3 MUST NOT

VCI values MUST NOT be in the 0-31 range when used as an LDP label on ATM interfaces. A management entity controlling the LDP subsystem should reject such values with an inconsistentValue error.

mpls, snmp

protocol-element §3

MplsAtmVcIdentifier defines the VCI field used by an LSR creating LDP sessions on ATM interfaces to hold the LDP Label. Valid range is 32..65535; values 0-31 are reserved by ITU and ATM Forum.

mpls, snmp

protocol-element §3

MplsBitRate represents bandwidth of an MPLS interface or LSP in units of 1,000 bits per second (rounded to nearest 1,000). A value of 0 indicates best-effort traffic with no bandwidth constraint.

mpls, snmp

protocol-element §3

MplsBurstSize represents the number of octets of MPLS data a stream may send back-to-back without policing concern. A value of zero indicates burst size is not supported by the implementation.

mpls, snmp

protocol-element §3

MplsExtendedTunnelId is a Unsigned32 (0..4294967295) unique identifier for an MPLS tunnel, derived from the Extended Tunnel Id in RSVP-TE or the Ingress Router ID for CR-LDP, and may represent an IPv4 address of the ingress or egress LSR.

mpls, snmp

protocol-element §3

MplsLabel is a 32-bit Unsigned32 (0..4294967295) encoding MPLS labels across multiple transport types: 20-bit shim header labels (bits 20-31 MUST be zero), 10- or 23-bit Frame Relay DLCI labels, 28-bit ATM VPI/VCI labels, and GMPLS labels exceeding 2^24-1.

mpls, snmp

protocol-element §3

MplsLabelDistributionMethod enumerates the two LDP label advertisement modes per interface: downstreamOnDemand(1) and downstreamUnsolicited(2), as defined in RFC 3036 section 2.6.3.

mpls, snmp

protocol-element §3

MplsLdpIdentifier is a 6-octet quantity identifying an LSR label space: the first 4 octets are a globally unique LSR identifier (e.g., 32-bit router ID), and the last 2 octets identify a specific label space within the LSR.

mpls, snmp

protocol-element §3

MplsLSPID uniquely identifies an LSP within an MPLS network, assigned at the head end and carried by the signaling protocol. For CR-LDP, it is 6 bytes (2-byte CR-LSPID + 4-byte Router ID); for RSVP-TE, it is 2 bytes.

mpls, snmp

protocol-element §3

MplsLspType enumerates four LSP roles on an LSR/LER: unknown(1), terminatingLsp(2) for egress, originatingLsp(3) for ingress/head-end, and crossConnectingLsp(4) for transit nodes.

mpls, snmp

protocol-element §3 MAY

MplsOwner enumerates the management subsystem that created an MPLS object: unknown(1), other(2), snmp(3), ldp(4), crldp(5), rsvpTe(6), or policyAgent(7). Objects created by any of these MAY be modified or destroyed by the same or a different subsystem.

mpls, snmp

protocol-element §3

MplsRetentionMode enumerates conservative(1) — retain only labels from valid next hops — and liberal(2) — retain all advertised label mappings regardless of next-hop validity, as defined in RFC 3036 section 2.6.2.

mpls, snmp

protocol-element §3

MplsTunnelIndex is a Unsigned32 (0..65535) uniquely indexing the mplsTunnelTable. For RSVP-signaled tunnels, this value should correspond to the RSVP Tunnel ID used in the RSVP-TE session.

mpls, snmp

protocol-element §3

MplsTunnelInstanceIndex distinguishes tunnel instances: 0 = configured tunnel interface, 1..65535 = signaled/backup LSP instances (corresponding to RSVP LSP ID for RSVP-TE), and 65536..4294967295 = FRR detour instances.

mpls, snmp

protocol-element §3

TeHopAddressType enumerates address types for TE tunnel hops: unknown(0), ipv4(1), ipv6(2), asnumber(3), unnum(4), and lspid(5). Each concrete value requires a corresponding TEXTUAL-CONVENTION for use with TeHopAddress.

mpls, snmp

registry §6

IANA assigned the mplsStdMIB OID under { transmission 166 }, with { mplsStdMIB 1 } assigned to the MPLS-TC-STD-MIB. Future MPLS standards-track MIB modules must be rooted under mplsStdMIB, with new assignments only via Standards Action.

mpls, snmp, registry

security-consideration §5

This module defines no management objects, only textual conventions for use by other MPLS MIB modules. Meaningful security considerations can only be written in MIB modules that define management objects; therefore this document has no direct security impact on the Internet.

mpls, snmp, security

wire-format §3

MplsLdpIdentifier has DISPLAY-HINT '1d.1d.1d.1d:2d' and SYNTAX OCTET STRING (SIZE (6)), encoding four octets of LSR ID followed by two octets of label space ID.

mpls, snmp

wire-format §3

MplsLSPID has SYNTAX OCTET STRING (SIZE (2|6)): 2 bytes for RSVP-TE LSP ID, or 6 bytes for CR-LDP LSPID (first 2 bytes = CR-LSPID, remaining 4 bytes = Router ID).

mpls, snmp

wire-format §3

TeHopAddress has SYNTAX OCTET STRING (SIZE (0..32)) and must always be interpreted in the context of an associated TeHopAddressType object. Attempts to set it to a value inconsistent with its TeHopAddressType must fail with an inconsistentValue error.

mpls, snmp

wire-format §3

TeHopAddressAS is an OCTET STRING (SIZE (4)) representing a 2- or 4-octet AS number in network byte order (MSB first); a 2-octet AS number has the two MSB octets set to zero.

mpls, snmp

wire-format §3

TeHopAddressUnnum is an OCTET STRING (SIZE (4)) encoding an unnumbered interface index in network byte order; used with TeHopAddressType value unnum(4).

mpls, snmp