draft-ietf-mpls-tc-mib-03.txt   draft-ietf-mpls-tc-mib-04.txt 
Network Working Group Thomas D. Nadeau Network Working Group Thomas D. Nadeau
Internet Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: July 2002 Expires: April 2003 Joan Cucchiara
Joan Cucchiara
Crescent Networks Crescent Networks
Cheenu Srinivasan Cheenu Srinivasan
Parama Networks, Inc. Parama Networks, Inc.
Arun Viswanathan Arun Viswanathan
Force10 Networks, Inc. Force10 Networks, Inc.
Hans Sjostrand Hans Sjostrand
ipUnplugged ipUnplugged
January 2002 October 2002
Definition of Textual Conventions and OBJECT-IDENTITIES for Definitions of Textual Conventions for Multiprotocol Label
Multiprotocol Label Switching (MPLS) Management Switching (MPLS) Management
draft-ietf-mpls-tc-mib-03.txt <draft-ietf-mpls-tc-mib-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full This document is an Internet-Draft and is in full conformance with
conformance with all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
Internet-Drafts are working documents of the Internet areas, and its working groups. Note that other groups may also
Engineering Task Force (IETF), its areas, and its working distribute working documents as Internet-Drafts.
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of six months
six months and may be updated, replaced, or obsoleted by and may be updated, replaced, or obsoleted by other documents at any
other documents at any time. It is inappropriate to use time. It is inappropriate to use Internet-Drafts as reference
Internet-Drafts as reference material or to cite them other material or to cite them other than as "work in progress".
than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be The list of Internet-Draft Shadow Directories can be accessed at
accessed at http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
Distribution of this document is unlimited. Please send comments to
the Multiprotocol Label Switching (mpls) Working Group, mpls@uu.net.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This memo describes Textual Conventions and OBJECT- This memo describes Textual Conventions for use in definitions of
IDENTITIES common to the Management Information Bases management information for Multiprotocol Label Switching (MPLS)
(MIBs) for managing Multiprotocol Label Switching (MPLS)
networks. networks.
Table of Contents Table of Contents
1. Introduction .............................................. 2 1 Introduction ................................................. 3
2. The SNMP Management Framework ............................. 2 2 The SNMP Management Framework ................................ 3
3. MPLS TC MIB Definitions ................................... 3 3 MPLS Textual Conventions MIB Definitions ..................... 4
4. Security Considerations ................................... 9 4 References ................................................... 15
5. References ................................................ 9 5 Security Considerations ...................................... 16
6. Authors' Addresses ........................................ 11 6 Authors' Addresses ........................................... 17
7. Full Copyright Statement .................................. 12 7 Full Copyright Statement ..................................... 17
1. Introduction 1. Introduction
This memo defines a portion of the Management Information This document defines a MIB which contains Textual Conventions for
Base (MIB) for use with network management protocols in the use in definitions of management information for Multi-Protocol Label
Internet community. In particular, it defines Textual Switching (MPLS) networks.
Conventions used in IETF MPLS and MPLS-related MIBs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
and "OPTIONAL" in this document are to be interpreted as document are to be interpreted as described in RFC 2119 [21].
described in RFC 2119, reference [RFC2119].
For an introduction to the concepts of MPLS, see [RFC3031]. For an introduction to the concepts of MPLS, see [RFC3031].
2. The SNMP Management Framework 2. The SNMP Management Framework
The SNMP Management Framework presently consists of five The SNMP Management Framework presently consists of five major
major components: components:
- An overall architecture, described in RFC 2571 o An overall architecture, described in RFC 2571 [RFC2571].
[RFC2571].
- Mechanisms for describing and naming objects and events o Mechanisms for describing and naming objects and events for the
for the purpose of management. The first version of purpose of management. The first version of this Structure of
this Structure of Management Information (SMI) is Management Information (SMI) is called SMIv1 and described in
called SMIv1 and described in STD 16, RFC 1155 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
[RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 1215 [RFC1215]. The second version, called SMIv2, is described
[RFC1215]. The second version, called SMIv2, is in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
described in STD 58, RFC 2578 [RFC2578], STD 58, RFC STD 58, RFC 2580 [RFC2580].
2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
- Message protocols for transferring management o Message protocols for transferring management information. The
information. The first version of the SNMP message first version of the SNMP message protocol is called SNMPv1 and
protocol is called SNMPv1 and described in STD 15, RFC described in STD 15, RFC 1157 [RFC1157]. A second version of
1157 [RFC1157]. A second version of the SNMP message the SNMP message protocol, which is not an Internet standards
protocol, which is not an Internet standards track track protocol, is called SNMPv2c and described in RFC 1901
protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the
[RFC1901] and RFC 1906 [RFC1906]. The third version of message protocol is called SNMPv3 and described in RFC 1906
the message protocol is called SNMPv3 and described in [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574
[RFC2574].
- Protocol operations for accessing management o Protocol operations for accessing management information. The
information. The first set of protocol operations and first set of protocol operations and associated PDU formats is
associated PDU formats is described in STD 15, RFC 1157 described in STD 15, RFC 1157 [RFC1157]. A second set of
[RFC1157]. A second set of protocol operations and protocol operations and associated PDU formats is described in
associated PDU formats is described in RFC 1905 RFC 1905 [RFC1905].
[RFC1905].
- A set of fundamental applications described in RFC 2573 o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism [RFC2573] and the view-based access control mechanism described
described in RFC 2575 [RFC2575]. in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management A more detailed introduction to the current SNMP Management Framework
Framework can be found in RFC 2570 [RFC2570]. can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information Managed objects are accessed via a virtual information store, termed
store, termed the Management Information Base or MIB. the Management Information Base or MIB. Objects in the MIB are
Objects in the MIB are defined using the mechanisms defined defined using the mechanisms defined in the SMI.
in the SMI.
This memo specifies a MIB module that is compliant to the This memo specifies a MIB module that is compliant to the SMIv2. A
SMIv2. A MIB conforming to the SMIv1 can be produced MIB conforming to the SMIv1 can be produced through the appropriate
through the appropriate translations. The resulting translations. The resulting translated MIB must be semantically
translated MIB must be semantically equivalent, except equivalent, except where objects or events are omitted because no
where objects or events are omitted because no translation translation is possible. Some machine readable information in SMIv2
is possible (use of Counter64). Some machine readable will be converted into textual descriptions in SMIv1 during the
information in SMIv2 will be converted into textual translation process. However, this loss of machine readable
descriptions in SMIv1 during the translation process. information is not considered to change the semantics of the MIB.
However, this loss of machine readable information is not
considered to change the semantics of the MIB.
3. MPLS TC MIB Definitions 3. MPLS Textual Conventions MIB Definitions
MPLS-TC-MIB DEFINITIONS ::= BEGIN MPLS-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, Unsigned32, Integer32
MODULE-IDENTITY, Unsigned32, Integer32, transmission
FROM SNMPv2-SMI FROM SNMPv2-SMI
transmission
FROM RFC1213-MIB
TEXTUAL-CONVENTION TEXTUAL-CONVENTION
FROM SNMPv2-TC; FROM SNMPv2-TC;
mplsTCMIB MODULE-IDENTITY mplsTCMIB MODULE-IDENTITY
LAST-UPDATED LAST-UPDATED "200210091200Z" -- 9 October 2002 12:00:00 GMT
"200101041200Z" -- 4 January 2002 12:00:00 GMT
ORGANIZATION ORGANIZATION
"Multiprotocol Label Switching (MPLS) Working Group" "IETF Multiprotocol Label Switching (MPLS) Working
Group."
CONTACT-INFO CONTACT-INFO
" Thomas D. Nadeau " Thomas D. Nadeau
Cisco Systems, Inc. Cisco Systems, Inc.
tnadeau@cisco.com tnadeau@cisco.com
Joan Cucchiara Joan Cucchiara
Crescent Networks Crescent Networks
jcucchiara@crescentnetworks.com jcucchiara@crescentnetworks.com
Cheenu Srinivasan Cheenu Srinivasan
skipping to change at page 4, line 31 skipping to change at page 5, line 9
Force10 Networks, Inc. Force10 Networks, Inc.
arun@force10networks.com arun@force10networks.com
Hans Sjostrand Hans Sjostrand
ipUnplugged ipUnplugged
hans@ipunplugged.com hans@ipunplugged.com
Email comments to the MPLS WG Mailing List at Email comments to the MPLS WG Mailing List at
mpls@uu.net." mpls@uu.net."
DESCRIPTION DESCRIPTION
"This MIB module defines Textual Conventions and "This MIB module defines Textual Conventions
OBJECT-IDENTITIES for use in documents defining for use in definitions of management
management information bases (MIBs) for managing information for Multi-Protocol Label Switching
MPLS networks." (MPLS) networks."
-- Revision history.
REVISION REVISION "200210091200Z" -- 9 October 2002 12:00:00 GMT
"200101041200Z" -- 4 January 2002 12:00:00 GMT
DESCRIPTION DESCRIPTION
"Initial version published as part of RFC XXXX." "Initial version published as part of RFC XXXX."
::= { mplsMIB 1 } ::= { mplsMIB 1 }
-- This object identifier needs to be assigned by IANA. -- This object identifier needs to be assigned by IANA.
-- Since mpls has been assigned an ifType of 166 we recommend -- Since mpls has been assigned an ifType of 166 we recommend
-- that this OID be 166 as well. -- that this OID be 166 as well.
mplsMIB OBJECT IDENTIFIER mplsMIB OBJECT IDENTIFIER
::= { transmission xxx } ::= { transmission XXX }
-- Textual Conventions are in alphabetical order.
MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The VCI value for a VCL. The maximum VCI value "A Label Switching Router (LSR) that
cannot exceed the value allowable by creates LDP sessions on ATM interfaces
atmInterfaceMaxVciBits defined in ATM-MIB. The uses the VCI or VPI/VCI field to hold the
minimum value is 32, values 0 to 31 are reserved LDP Label.
for other uses by the ITU and ATM Forum. 32 is
typically the default value for the Control VC." VCI values MUST NOT be in the 0-31 range.
The values 0 to 31 are reserved for other uses
by the ITU and ATM Forum. The value
of 32 can only be used for the Control VC,
although values greater than 32 could be
configured for the Control VC.
If a value from 0 to 31 is used for a VCI
the management entity controlling the LDP
subsystem should reject this with an
inconsistentValue error. Also, if
the value of 32 is used for a VC which is
NOT the Control VC, this should
result in an inconsistentValue error."
REFERENCE REFERENCE
"Definitions of Textual Conventions and OBJECT- "[RFC3035] Davie, B., Lawerence J., McCloghrie, K.,
IDENTITIES for ATM Management, RFC 2514, Feb. Rosen, E., Swallow G., Rekhter, Y., and
1999." P. Doolan, 'MPLS using LDP and ATM VC Switching',
RFC 3035, January 2001."
SYNTAX Integer32 (32..65535) SYNTAX Integer32 (32..65535)
MplsBitRate ::= TEXTUAL-CONVENTION MplsBitRate ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d" DISPLAY-HINT "d"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An estimate of bandwidth in units of 1,000 bits per "An estimate of bandwidth in units of 1,000 bits per
second. If this object reports a value of 'n' then second. If this object reports a value of 'n' then
the rate of the object is somewhere in the range of the rate of the object is somewhere in the range of
'n-500' to 'n+499'. For objects which do not vary 'n-500' to 'n+499'. For objects which do not vary
in bit rate, or for those where no accurate in bit rate, or for those where no accurate
estimation can be made, this object should contain estimation can be made, this object should contain
the nominal bit rate." the nominal bit rate. A value of 0 indicates best
SYNTAX Integer32 (1..2147483647) effort treatment."
SYNTAX Integer32 (0|500..2147483647)
MplsBurstSize ::= TEXTUAL-CONVENTION MplsBurstSize ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d" DISPLAY-HINT "d"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of octets of MPLS data that the stream "The number of octets of MPLS data that the stream
may send back-to-back without concern for may send back-to-back without concern for policing.
policing." The value of zero indicates that an implementation
SYNTAX Unsigned32 (1..4294967295) does not support Burst Size."
SYNTAX Unsigned32 (0..4294967295)
MplsExtendedTunnelId ::= TEXTUAL-CONVENTION MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A unique identifier for an MPLS Tunnel. This MAY "A unique identifier for an MPLS Tunnel. This may
represent an IpV4 address of the ingress or egress represent an IPv4 address of the ingress or egress
LSR for the tunnel. This value is derived from the LSR for the tunnel. This value is derived from the
Extended Tunnel Id in RSVP or the Ingress Router ID Extended Tunnel Id in RSVP or the Ingress Router ID
for CR-LDP." for CR-LDP."
REFERENCE REFERENCE
"1. Awduche, D., et al., RSVP-TE: Extensions to RSVP "[RFC3209] Awduche, D., et al., 'RSVP-TE: Extensions
for LSP Tunnels, RFC 3209, December 2001. to RSVP for LSP Tunnels', RFC 3209, December 2001.
2. Constraint-Based LSP Setup using LDP, Jamoussi,
B., et al., draft-ietf-mpls-cr-ldp-06.txt, November [RFC3212] Jamoussi, B., et al., 'Constraint-Based
2001." LSP Setup using LDP', RFC 3212, January 2002."
SYNTAX Unsigned32 SYNTAX Unsigned32
MplsInitialCreationSource ::= TEXTUAL-CONVENTION MplsOwner ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The entity that originally created the object in "The entity that originally created the object in
question. The values of this enumeration are question. The values of this enumeration are
defined as follows: defined as follows:
other(1) - This is used when an entity which has not other(1) - This is used when an entity which has not
been enumerated in this textual convention but been enumerated in this textual convention but
which is known by the agent. which is known by the agent.
skipping to change at page 6, line 35 skipping to change at page 7, line 28
crldp(5) - The Constraint-Based Label Distribution crldp(5) - The Constraint-Based Label Distribution
Protocol was used to configure this object Protocol was used to configure this object
initially. initially.
policyAgent(6) - A policy agent (perhaps in policyAgent(6) - A policy agent (perhaps in
combination with one of the above protocols) was combination with one of the above protocols) was
used to configure this object initially. used to configure this object initially.
unknown(7) - the agent cannot discern which unknown(7) - the agent cannot discern which
component created the object." component created the object.
An object created by the ldp(3), rsvp(4), crldp(5)
or policyAgent(6) MAY be modified through operator
intervention using other(1) or snmp(2). In
particular, operators may bring rows in and
out of service or modify their values.
In all other respects, the MplsOwner is
the only source allowed to modify the status of
the object.
Agents receiving requests which violate these
guidelines MUST return an inconsistentValue(12)
error."
SYNTAX INTEGER { SYNTAX INTEGER {
other(1), other(1),
snmp(2), snmp(2),
ldp(3), ldp(3),
rsvp(4), rsvp(4),
crldp(5), crldp(5),
policyAgent(6), policyAgent(6),
unknown (7) unknown (7)
} }
MplsLSPID ::= TEXTUAL-CONVENTION MplsLSPID ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An identifier that is assigned to each LSP and is "A unique identifier within an MPLS network that is
used to uniquely identify it. This is assigned at assigned to each LSP. This is assigned at the head
the head end of the LSP and can be used by all LSRs end of the LSP and can be used by all LSRs
to identify this LSP. This value is piggybacked by to identify this LSP. This value is piggybacked by
the signaling protocol when this LSP is signaled the signaling protocol when this LSP is signaled
within the network. This identifier can then be within the network. This identifier can then be
used at each LSR to identify which labels are being used at each LSR to identify which labels are being
swapped to other labels for this LSP. For IPv4 swapped to other labels for this LSP. This object
addresses this results in a 6-octet long cookie." can also be used to disambiguate LSPs that
SYNTAX OCTET STRING (SIZE (0..31)) share the same RSVP sessions between the same
source and destination.
For LSPs established using CR-LDP, the LSPID is
composed of the ingress LSR Router ID (or any of
its own IPv4 addresses) and a locally unique
CR-LSP ID to that LSR. The first two bytes carry
the CR-LSPID, and the remaining 4 bytes carry
the Router ID. The LSPID is useful in network
management, in CR-LSP repair, and in using
an already established CR-LSP as a hop in an ER-TLV.
For LSPs signaled using RSVP-TE, the LSP ID is
defined as a 16-bit (2 byte) identifier used
in the SENDER_TEMPLATE and the FILTER_SPEC
that can be changed to allow a sender to
share resources with itself. The length of this
object should only be 2 or 6 bytes. If the length
of this octet string is 2 bytes, then it must
identify an RSVP-TE LSPID, or it is 6 bytes,
it must contain a CR-LDP LSPID."
REFERENCE
"See [RFC3209] for RSVP-TE LSPID and [RFC3212] for
LSPID in CR-LDP."
SYNTAX OCTET STRING (SIZE (2|6))
MplsLabel ::= TEXTUAL-CONVENTION MplsLabel ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This value represents an MPLS label as defined in "This value represents an MPLS label as defined in
[RFC3031], [RFC3032], [RFC3034] and [RFC3035]." [RFC3031], [RFC3032], [RFC3034], [RFC3035] and
[CCAMP-ARCH].
The label contents are specific to the label being
represented, such as:
* The label carried in an MPLS shim header
(for LDP this is the Generic Label) is a 20-bit
number represented by 4 octets. Bits 0-19 contain
a label or a reserved label value. Bits 20-31
MUST be zero.
The following is quoted directly from [RFC3032].
There are several reserved label values:
i. A value of 0 represents the
'IPv4 Explicit NULL Label'. This label
value is only legal at the bottom of the
label stack. It indicates that the label
stack must be popped, and the forwarding
of the packet must then be based on the
IPv4 header.
ii. A value of 1 represents the
'Router Alert Label'. This label value is
legal anywhere in the label stack except at
the bottom. When a received packet
contains this label value at the top of
the label stack, it is delivered to a
local software module for processing.
The actual forwarding of the packet
is determined by the label beneath it
in the stack. However, if the packet is
forwarded further, the Router Alert Label
should be pushed back onto the label stack
before forwarding. The use of this label
is analogous to the use of the
'Router Alert Option' in IP packets [5]
[Reference to RFC2113]. Since this label
cannot occur at the bottom of the stack,
it is not associated with a
particular network layer protocol.
iii. A value of 2 represents the
'IPv6 Explicit NULL Label'. This label
value is only legal at the bottom of the
label stack. It indicates that the label
stack must be popped, and the forwarding
of the packet must then be based on the
IPv6 header.
iv. A value of 3 represents the
'Implicit NULL Label'.
This is a label that an LSR may assign and
distribute, but which never actually
appears in the encapsulation. When an
LSR would otherwise replace the label
at the top of the stack with a new label,
but the new label is 'Implicit NULL',
the LSR will pop the stack instead of
doing the replacement. Although
this value may never appear in the
encapsulation, it needs to be specified in
the Label Distribution Protocol, so a value
is reserved.
v. Values 4-15 are reserved.
* The frame relay label can be either 10-bits or
23-bits depending on the DLCI field size and the
upper 22-bits or upper 9-bits must be zero,
respectively.
* For an ATM label the lower 16-bits represents the
VCI, the next 12-bits represents the VPI and the
remaining bits MUST be zero.
* The Generalized-MPLS (GMPLS) label contains a
value greater than 2^24-1 and used in GMPLS
as defined in [CCAMP-ARCH]."
REFERENCE REFERENCE
"1. Multiprotocol Label Switching Architecture, Rosen "[RFC3031] Multiprotocol Label Switching
et al, RFC 3031, August 1999. Architecture, Rosen et al., RFC 3031, August 1999.
2. MPLS Label Stack Encoding, Rosen et al, RFC 3032,
January 2001. [RFC3032] MPLS Label Stack Encoding, Rosen et al.,
3. Use of Label Switching on Frame Relay Networks, RFC 3032, January 2001.
Conta et al, RFC 3034, January 2001.
4. MPLS using LDP and ATM VC switching, Davie et al, [RFC3034] Use of Label Switching on Frame Relay
RFC 3035, January 2001." Networks, Conta et al., RFC 3034, January 2001.
[RFC3035] MPLS using LDP and ATM VC Switching,
Davie et al., RFC 3035, January 2001.
[CCAMP-ARCH] Generalized Multi-Protocol Label
Switching (GMPLS) Architecture, Mannie (Editor),
draft-ietf-ccamp-gmpls-architecture-02.txt,
March 2002."
SYNTAX Unsigned32 (0..4294967295) SYNTAX Unsigned32 (0..4294967295)
MplsLdpGenAddr ::= TEXTUAL-CONVENTION MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of an network layer or data link layer "The label distribution method which is also called
address." the label advertisement mode (see LDP Specification).
SYNTAX OCTET STRING (SIZE (0..64)) Each interface on an LSR is configured to operate
in either Downstream Unsolicited or Downstream
on Demand."
REFERENCE
"[RFC3031] Multiprotocol Label Switching
Architecture, Rosen et al., RFC 3031, August 1999.
[RFC3036] LDP Specification, Andersson, L., et. al.,
RFC 3036, Section 2.6.3., January 2001."
SYNTAX INTEGER {
downstreamOnDemand(1),
downstreamUnsolicited(2)
}
MplsLspType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Types types of Label Switch Paths (LSPs)
on an Label Switching Router (LSR) are:
unknown(1) -- if the LSP is not known
to be one of the following.
terminatingLsp(2) -- if the LSP terminates
on the LSR, then this
is an ingressing LSP
which ends on the LSR,
originatingLsp(3) -- if the LSP originates
from the LSR, then this
is an egressing 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)
}
MplsLsrIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a generic index used throughout the
MPLS-LSR-MIB as a general index in the
mplsInSegmentTable, mplsOutSegmentTable
and mplsXCTable."
SYNTAX OCTET STRING (SIZE(1..34))
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
"[RFC3031] Multiprotocol Label Switching
Architecture, Rosen et al., RFC 3031, August 1999.
[RFC3036] LDP Specification, Andersson, L., et. al.,
RFC 3036, Section 2.6.2., January 2001."
SYNTAX INTEGER {
conservative(1),
liberal(2)
}
MplsLdpIdentifier ::= TEXTUAL-CONVENTION MplsLdpIdentifier ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The LDP identifier is a six octet quantity which is "The LDP identifier is a six octet quantity which is
used to identify an Label Switch Router (LSR) label used to identify an Label Switching Router (LSR)
space. label space.
The first four octets identify the LSR and must be a The first four octets identify the LSR and must be
globally unique value, such as a 32-bit router ID a globally unique value, such as a 32-bit router ID
assigned to the LSR, and the last two octets assigned to the LSR, and the last two octets
identify a specific label space within the LSR." identify a specific label space within the LSR."
SYNTAX OCTET STRING (SIZE (6)) SYNTAX OCTET STRING (SIZE (6))
MplsLdpLabelTypes ::= TEXTUAL-CONVENTION MplsLdpLabelType ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The Layer 2 label types which are defined for MPLS "The Layer 2 label types which are defined for MPLS
LDP/CRLDP are generic(1), atm(2), or LDP and/or CR-LDP are generic(1), atm(2), or
frameRelay(3)." frameRelay(3)."
SYNTAX INTEGER { SYNTAX INTEGER {
generic(1), generic(1),
atm(2), atm(2),
frameRelay(3) frameRelay(3)
} }
MplsLsrIdentifier ::= TEXTUAL-CONVENTION MplsLsrIdentifier ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The Label Switch Router (LSR) identifier is the "The Label Switching Router (LSR) identifier is the
first 4 bytes of the Label Distribution Protocol first 4 bytes of the Label Distribution Protocol
(LDP) identifier." (LDP) identifier."
SYNTAX OCTET STRING (SIZE (4)) SYNTAX OCTET STRING (SIZE (4))
MplsPathIndex ::= TEXTUAL-CONVENTION MplsPathIndex ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A unique identifier used to identify a specific path "A unique value to index (by Path number) an entry
used by a tunnel." in a table."
SYNTAX Unsigned32 SYNTAX Unsigned32(1..4294967295)
MplsPathIndexOrZero ::= TEXTUAL-CONVENTION MplsPathIndexOrZero ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A unique identifier used to identify a specific path "A unique identifier used to identify a specific path
used by a tunnel. If this value is set to 0, it used by a tunnel. A value of 0 (zero) means that
indicates that no path is in use." no path is in use."
SYNTAX Unsigned32 SYNTAX Unsigned32
MplsPortNumber ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A TCP or UDP port number. Along with an IP address
identifies a stream of IP traffic uniquely."
SYNTAX Integer32 (0..65535)
MplsTunnelAffinity ::= TEXTUAL-CONVENTION MplsTunnelAffinity ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Include-any, include-all, or exclude-all constraint "Describes the configured 32-bit Include-any,
for link selection." include-all, or exclude-all constraint for
constraint-based link selection."
REFERENCE
"See section 4.7.4 in [RFC3209]."
SYNTAX Unsigned32 SYNTAX Unsigned32
MplsTunnelIndex ::= TEXTUAL-CONVENTION MplsTunnelIndex ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Index into mplsTunnelTable." "A unique index into mplsTunnelTable.
SYNTAX Integer32 (1..65535) For tunnels signaled using RSVP, this value
should correspond to the RSVP destination
port used for the RSVP-TE session."
SYNTAX Integer32
MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Instance index into mplsTunnelTable." "Instance index into mplsTunnelTable. The
tunnel entry with instance index 0 should
refer to the configured tunnel interface
(if one exists), and values greater an 0
should be used to indicate signaled (or backup)
tunnel LSP instances. For tunnel LSPs signaled using
RSVP, this value should correspond to the
RSVP source port used for the RSVP-TE session."
SYNTAX Unsigned32 (0..65535) SYNTAX Unsigned32 (0..65535)
END END
4. Security Considerations 4. References
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.
5. References
[RFC1155] Rose, M., and K. McCloghrie, "Structure and [RFC3212] Jamoussi, B., (editor), et. al. "Constraint-Based LSP Setup
Identification of Management Information for using LDP", RFC 3212, January 2002.
TCP/IP-based Internets", STD 16, RFC 1155,
May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Davin, "Simple Network Management Protocol", Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
STD 15, RFC 1157, May 1990. RFC 3209, December 2001.
[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB [RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol
Definitions", STD 16, RFC 1212, March 1991. Label Switching Architecture", RFC 3031, January 2001.
[RFC1213] McCloghrie, K, and M. Rose, "Management [RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
Information Base for Network Management of Federokow, G., Li, T., and A. Conta, "MPLS Label Stack
TCP/IP Based Internets", RFC 1213, March Encoding", RFC 3032, January 2001.
1991.
[RFC1215] M. Rose, "A Convention for Defining Traps [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching
for use with the SNMP", RFC 1215, March on Frame Relay Networks Specification", RFC 3034, January
1991. 2001.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow,
Waldbusser, "Introduction to Community-based G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC
SNMPv2", RFC 1901, January 1996. Switching", RFC 3035, January 2001.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
Waldbusser, "Protocol Operations for Version Thomas, "LDP Specification", RFC 3036, January 2001.
2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
Waldbusser, "Transport Mappings for Version for Describing SNMP Management Frameworks", RFC 2571, April
2 of the Simple Network Management Protocol 1999.
(SNMPv2)", RFC 1906, January 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification
Indicate Requirement Levels", BCP 14, RFC of Management Information for TCP/IP-based Internets", STD
2119, March 1997. 16, RFC 1155, May 1990.
[RFC2514] Noto, et. al., "Definitions of Textual [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD
Conventions and OBJECT-IDENTITIES for ATM 16, RFC 1212, March 1991.
Management", RFC 2514, Feb. 1999
[RFC2570] Case, J., Mundy, R., Partain, D., and B. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the
Stewart, "Introduction to Version 3 of the SNMP", RFC 1215, March 1991.
Internet-standard Network Management
Framework", RFC 2570, April 1999.
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
"An Architecture for Describing SNMP Rose, M., and S. Waldbusser, "Structure of Management
Management Frameworks", RFC 2571, April Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999. 1999.
[RFC2572] Case, J., Harrington D., Presuhn R., and B. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Wijnen, "Message Processing and Dispatching Rose, M., and S. Waldbusser, "Textual Conventions for
for the Simple Network Management Protocol SMIv2", STD 58, RFC 2579, April 1999.
(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 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Security Model (USM) for version 3 of the Rose, M., and S. Waldbusser, "Conformance Statements for
Simple Network Management Protocol SMIv2", STD 58, RFC 2580, April 1999.
(SNMPv3)", RFC 2574, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
"View-based Access Control Model (VACM) for Network Management Protocol", STD 15, RFC 1157, May 1990.
the Simple Network Management Protocol
(SNMP)", RFC 2575, April 1999.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
J., Case, J., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January
"Structure of Management Information Version 1996.
2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
J., Case, J., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network
"Textual Conventions for SMIv2", STD 58, RFC Management Protocol (SNMPv2)", RFC 1906, January 1996.
2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
J., Case, J., Rose, M., and S. Waldbusser, Processing and Dispatching for the Simple Network Management
"Conformance Statements for SMIv2", STD 58, Protocol (SNMP)", RFC 2572, April 1999.
RFC 2580, April 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model
"Multiprotocol Label Switching (USM) for version 3 of the Simple Network Management
Architecture", RFC 3031, August 1999. Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC3032] Rosen, E., Rekhter, Y., Tappan, D., [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
Farinacci, D., Federokow, G., Li, T., and A. "Protocol Operations for Version 2 of the Simple Network
Conta, "MPLS Label Stack Encoding", RFC Management Protocol (SNMPv2)", RFC 1905, January 1996.
3032, January 2001.
[RFC3034] Conta, A., Doolan, P., Malis, A., "Use of [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
Label Switching on Frame Relay Networks RFC 2573, April 1999.
Specification", RFC 3034, January 2001.
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Rosen, E., Swallow, G., Rekhter, Y., and P. Access Control Model (VACM) for the Simple Network
Doolan, "MPLS using LDP and ATM VC Management Protocol (SNMP)", RFC 2575, April 1999.
switching", RFC 3035, January 2001.
[RFC3036] Anderson, L., Doolan, P., Feldman, N., [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart,
Fredette, A., and B. Thomas, "LDP "Introduction to Version 3 of the Internet-standard Network
Specification", RFC 3036, January 2001. Management Framework", RFC 2570, April 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 5. Security Considerations
Srinivasan, V., and G. Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[Assigned] Reynolds, J., and J. Postel, "Assigned This module does not define any management objects. Instead, it
Numbers", RFC 1700, October 1994. See also: defines a set of textual conventions which may be used by other MPLS
http://www.iana.org/assignments/smi-numbers MIB modules to define management objects.
[CRLDP] B. Jamoussi (Editor), "Constraint-Based LSP Meaningful security considerations can only be written in the MIB
Setup using LDP", draft-ietf-mpls-cr-ldp- modules that define management objects. Therefore, this document has
06.txt, November 2001." no impact on the security of the Internet.
6. Authors' Addresses 6. Authors' Addresses
Thomas D. Nadeau Thomas D. Nadeau
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: +1-978-244-3051 Phone: +1-978-244-3051
Email: tnadeau@cisco.com Email: tnadeau@cisco.com
skipping to change at page 12, line 30 skipping to change at page 17, line 44
Hans Sjostrand Hans Sjostrand
ipUnplugged ipUnplugged
P.O. Box 101 60 P.O. Box 101 60
S-121 28 Stockholm, Sweden S-121 28 Stockholm, Sweden
Phone: +46-8-725-5930 Phone: +46-8-725-5930
Email: hans@ipunplugged.com Email: hans@ipunplugged.com
7. Full Copyright Statement 7. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Copyright (C) The Internet Society (2002). All Rights Reserved.
Reserved.
This document and translations of it may be copied and This document and translations of it may be copied and furnished to
furnished to others, and derivative works that comment on others, and derivative works that comment on or otherwise explain it
or otherwise explain it or assist in its implementation may or assist in its implementation may be prepared, copied, published
be prepared, copied, published and distributed, in whole or and distributed, in whole or in part, without restriction of any
in part, without restriction of any kind, provided that the kind, provided that the above copyright notice and this paragraph are
above copyright notice and this paragraph are included on included on all such copies and derivative works. However, this
all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing
document itself may not be modified in any way, such as by the copyright notice or references to the Internet Society or other
removing the copyright notice or references to the Internet Internet organizations, except as needed for the purpose of
Society or other Internet organizations, except as needed developing Internet standards in which case the procedures for
for the purpose of developing Internet standards in which copyrights defined in the Internet Standards process must be
case the procedures for copyrights defined in the Internet followed, or as required to translate it into languages other than
Standards process must be followed, or as required to English.
translate it into languages other than English.
The limited permissions granted above are perpetual and The limited permissions granted above are perpetual and will not be
will not be revoked by the Internet Society or its revoked by the Internet Society or its successors or assigns.
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE This document and the information contained herein is provided on an
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/