DESCRIPTION
"Types of Label Switch Paths (LSPs)
on a Label Switching Router (LSR) or a
Label Edge Router (LER) are:
unknown(1) -- if the LSP is not known
to be one of the following.
terminatingLsp(2) -- if the LSP terminates
on the LSR/LER, then this
is an egressing LSP
which ends on the LSR/LER,
originatingLsp(3) -- if the LSP originates
from this LSR/LER, then
this is an ingressing LSP
which is the head-end of
the LSP,
crossConnectingLsp(4) -- if the LSP ingresses
and egresses on the LSR,
then it is
cross-connecting on that
LSR."
SYNTAX INTEGER {
unknown(1),
terminatingLsp(2),
originatingLsp(3),
crossConnectingLsp(4)
}
MplsOwner ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This object indicates the local network
management subsystem that originally created
the object(s) in question. The values of
this enumeration are defined as follows:
unknown(1) - the local network management
subsystem cannot discern which
component created the object.
other(2) - the local network management
subsystem is able to discern which component
created the object, but the component is not
listed within the following choices,
e.g., command line interface (cli).
snmp(3) - The Simple Network Management Protocol
was used to configure this object initially.
ldp(4) - The Label Distribution Protocol was
used to configure this object initially.
crldp(5) - The Constraint-Based Label Distribution
Protocol was used to configure this object
initially.
rsvpTe(6) - The Resource Reservation Protocol was
used to configure this object initially.
policyAgent(7) - A policy agent (perhaps in
combination with one of the above protocols) was
used to configure this object initially.
An object created by any of the above choices
MAY be modified or destroyed by the same or a
different choice."
SYNTAX INTEGER {
unknown(1),
other(2),
snmp(3),
ldp(4),
crldp(5),
rsvpTe(6),
policyAgent(7)
}
MplsPathIndexOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier used to identify a specific
path used by a tunnel. A value of 0 (zero) means
that no path is in use."
SYNTAX Unsigned32(0..4294967295)
MplsPathIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique value to index (by Path number) an
entry in a table."
SYNTAX Unsigned32(1..4294967295)
MplsRetentionMode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The label retention mode which specifies whether
an LSR maintains a label binding for a FEC
learned from a neighbor that is not its next hop
for the FEC.
If the value is conservative(1) then advertised
label mappings are retained only if they will be
used to forward packets, i.e., if label came from
a valid next hop.
If the value is liberal(2) then all advertised
label mappings are retained whether they are from
a valid next hop or not."
REFERENCE
"Multiprotocol Label Switching Architecture,
RFC3031.
LDP Specification, RFC3036, Section 2.6.2."
SYNTAX INTEGER {
conservative(1),
liberal(2)
}
MplsTunnelAffinity ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Describes the configured 32-bit Include-any,
include-all, or exclude-all constraint for
constraint-based link selection."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC3209, Section 4.7.4."
SYNTAX Unsigned32(0..4294967295)
MplsTunnelIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique index into mplsTunnelTable.
For tunnels signaled using RSVP, this value
should correspond to the RSVP Tunnel ID
used for the RSVP-TE session."
SYNTAX Unsigned32 (0..65535)
MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The tunnel entry with instance index 0
should refer to the configured tunnel
interface (if one exists).
Values greater than 0, but less than or
equal to 65535, should be used to indicate
signaled (or backup) tunnel LSP instances.
For tunnel LSPs signaled using RSVP,
this value should correspond to the
RSVP LSP ID used for the RSVP-TE
LSP.
Values greater than 65535 apply to FRR
detour instances."
SYNTAX Unsigned32(0|1..65535|65536..4294967295)
TeHopAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a type of address for a
Traffic Engineered (TE) Tunnel hop.
unknown(0) An unknown address type. This value
MUST be used if the value of the
corresponding TeHopAddress object is a
zero-length string. It may also be
used to indicate a TeHopAddress which
is not in one of the formats defined
below.
ipv4(1) An IPv4 network address as defined by
the InetAddressIPv4 TEXTUAL-CONVENTION
[RFC3291].
ipv6(2) A global IPv6 address as defined by
the InetAddressIPv6 TEXTUAL-CONVENTION
[RFC3291].
asnumber(3) An Autonomous System (AS) number as
defined by the TeHopAddressAS
TEXTUAL-CONVENTION.
unnum(4) An unnumbered interface index as
defined by the TeHopAddressUnnum
TEXTUAL-CONVENTION.
lspid(5) An LSP ID for TE Tunnels
(RFC3212) as defined by the
MplsLSPID TEXTUAL-CONVENTION.
Each definition of a concrete TeHopAddressType
value must be accompanied by a definition
of a TEXTUAL-CONVENTION for use with that
TeHopAddress.
To support future extensions, the TeHopAddressType
TEXTUAL-CONVENTION SHOULD NOT be sub-typed in
object type definitions. It MAY be sub-typed in
compliance statements in order to require only a
subset of these address types for a compliant
implementation.
Implementations must ensure that TeHopAddressType
objects and any dependent objects
(e.g., TeHopAddress objects) are consistent.
An inconsistentValue error must be generated
if an attempt to change a TeHopAddressType
object would, for example, lead to an
undefined TeHopAddress value that is
not defined herein. In particular,
TeHopAddressType/TeHopAddress pairs
must be changed together if the address
type changes (e.g., from ipv6(2) to ipv4(1))."
REFERENCE
"TEXTUAL-CONVENTIONs for Internet Network
Addresses, RFC3291.
Constraint-Based LSP Setup using LDP,
[RFC3212]"
SYNTAX INTEGER {
unknown(0),
ipv4(1),
ipv6(2),
asnumber(3),
unnum(4),
lspid(5)
}
TeHopAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic Tunnel hop address,
that is, the address of a node which
an LSP traverses, including the source
and destination nodes. An address may be
very concrete, for example, an IPv4 host
address (i.e., with prefix length 32);
if this IPv4 address is an interface
address, then that particular interface
must be traversed. An address may also
specify an ’abstract node’, for example,
an IPv4 address with prefix length
less than 32, in which case, the LSP
can traverse any node whose address
falls in that range. An address may
also specify an Autonomous System (AS),
in which case the LSP can traverse any
node that falls within that AS.
A TeHopAddress value is always interpreted within
the context of an TeHopAddressType value. Every
usage of the TeHopAddress TEXTUAL-CONVENTION
is required to specify the TeHopAddressType object
which provides the context. It is suggested that
the TeHopAddressType object is logically registered
before the object(s) which use the TeHopAddress
TEXTUAL-CONVENTION if they appear in the
same logical row.
The value of a TeHopAddress object must always be
consistent with the value of the associated
TeHopAddressType object. Attempts to set a
TeHopAddress object to a value which is
inconsistent with the associated TeHopAddressType
must fail with an inconsistentValue error."
SYNTAX OCTET STRING (SIZE (0..32))
TeHopAddressAS ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a two or four octet AS number.
The AS number is represented in network byte
order (MSB first). A two-octet AS number has
the two MSB octets set to zero."
REFERENCE
"Textual Conventions for Internet Network
Addresses, [RFC3291]. The
InetAutonomousSystemsNumber TEXTUAL-CONVENTION
has a SYNTAX of Unsigned32, whereas this TC
has a SYNTAX of OCTET STRING (SIZE (4)).
Both TCs represent an autonomous system number
but use different syntaxes to do so."
SYNTAX OCTET STRING (SIZE (4))
TeHopAddressUnnum ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an unnumbered interface:
octets contents encoding
1-4 unnumbered interface network-byte order
The corresponding TeHopAddressType value is
unnum(5)."
SYNTAX OCTET STRING(SIZE(4))
END
4. References
4.1. Normative References
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP: 26, RFC 2434,
October 1998.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580, April
1999.
[RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[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., and A. Malis, "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] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3209] 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.
[RFC3212] Jamoussi, B., Ed., 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.
[RFC3291] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 3291, May 2002.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3471, January 2003.
4.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.
5. Security Considerations
This module does not define any management objects. Instead, it
defines a set of textual conventions which may be used by other MPLS
MIB modules to define management objects.
Meaningful security considerations can only be written in the MIB
modules that define management objects. Therefore, this document has
no impact on the security of the Internet.
6. IANA Considerations
IANA has made a MIB OID assignment under the transmission branch,
that is, assigned the mplsStdMIB under { transmission 166 }. This
sub-id is requested because 166 is the ifType for mpls(166) and is
available under transmission.
In the future, MPLS related standards track MIB modules should be
rooted under the mplsStdMIB subtree. The IANA is requested to manage
that namespace. New assignments can only be made via a Standards
Action as specified in [RFC2434].
The IANA has also assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB
specified in this document.
7. Contributors
This document was created by combining TEXTUAL-CONVENTIONS from
current MPLS MIBs and a TE-WG MIB. Co-authors on each of these MIBs
contributed to the TEXTUAL-CONVENTIONS contained in this MIB and also
contributed greatly to the revisions of this document. These co-
authors addresses are included here because they are useful future
contacts for information about this document. These co-authors are:
Cheenu Srinivasan
Bloomberg L.P.
499 Park Ave.
New York, NY 10022
Phone: +1-212-893-3682
EMail: cheenu@bloomberg.net
Arun Viswanathan
Force10 Networks, Inc.
1440 McCarthy Blvd
Milpitas, CA 95035
Phone: +1-408-571-3516
EMail: arunv@force10networks.com
Hans Sjostrand
ipUnplugged
P.O. Box 101 60
S-121 28 Stockholm, Sweden
Phone: +46-8-725-5900
EMail: hans@ipunplugged.com
Kireeti Kompella
Juniper Networks
1194 Mathilda Ave
Sunnyvale, CA 94089
Phone: +1-408-745-2000
EMail: kireeti@juniper.net
8. Acknowledgements
This document is a product of the MPLS Working Group. The editors
and contributors would like to thank Mike MacFadden and Adrian Farrel
for their helpful comments on several reviews. Also, the editors and
contributors would like to give a special acknowledgement to Bert
Wijnen for his many detailed reviews. Bert’s assistance and guidance
is greatly appreciated.
9. Authors’ Addresses
Thomas D. Nadeau
Cisco Systems, Inc.
BXB300/2/
300 Beaver Brook Road
Boxborough, MA 01719