draft-ietf-mpls-tc-mib-10.txt   rfc3811.txt 
Network Working Group T. Nadeau Network Working Group T. Nadeau, Ed.
Internet-Draft Cisco Systems, Inc. Request for Comments: 3811 Cisco Systems, Inc.
Expires: April 2004 J. Cucchiara Category: Standards Track J. Cucchiara, Ed.
Artel Marconi Communications, Inc.
(Editors) June 2004
October 2003
Definitions of Textual Conventions for Multiprotocol Label
Switching (MPLS) Management
<draft-ietf-mpls-tc-mib-10.txt> Definitions of Textual Conventions (TCs) for
Multiprotocol Label Switching (MPLS) Management
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC 2026. Internet-Drafts are Internet community, and requests discussion and suggestions for
working documents of the Internet Engineering Task Force (IETF), its improvements. Please refer to the current edition of the "Internet
areas, and its working groups. Note that other groups may also Official Protocol Standards" (STD 1) for the standardization state
distribute working documents as Internet-Drafts. and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
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 Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This memo defines a Management Information Base (MIB) module which This memo defines a Management Information Base (MIB) module which
contains Textual Conventions to represent commonly used Mulitprotocol contains Textual Conventions to represent commonly used Multiprotocol
Label Switching (MPLS) management information. The intent is that Label Switching (MPLS) management information. The intent is that
these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS
related MIB modules that would otherwise define their own related MIB modules that would otherwise define their own
representations. representations.
Table of Contents Table of Contents
1 Introduction ................................................. 4 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2 The Internet-Standard Management Framework ................... 4 2. The Internet-Standard Management Framework. . . . . . . . . . 2
3 MPLS Textual Conventions MIB Definitions ..................... 4 3. MPLS Textual Conventions MIB Definitions. . . . . . . . . . . 2
4 Normative References ......................................... 19 4. References. . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Informative References ....................................... 20 4.1. Normative References. . . . . . . . . . . . . . . . . . 16
6 Security Considerations ...................................... 20 4.2. Informative References. . . . . . . . . . . . . . . . . 17
7 IANA Considerations .......................................... 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8 Contributors ................................................. 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9 Acknowledgements ............................................. 21 7. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 18
10 Intellectual Property Notice ................................ 22 8 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 19
11 Authors' Addresses .......................................... 22 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19
12 Full Copyright Statement .................................... 23 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document defines a MIB module which contains Textual Conventions This document defines a MIB module which contains Textual Conventions
for Multi-Protocol Label Switching (MPLS) networks. These Textual for Multiprotocol Label Switching (MPLS) networks. These Textual
Conventions should be imported by MIB modules which manage MPLS Conventions should be imported by MIB modules which manage MPLS
networks. networks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
For an introduction to the concepts of MPLS, see [RFC3031]. For an introduction to the concepts of MPLS, see [RFC3031].
2. The Internet-Standard Management Framework 2. The Internet-Standard Management Framework
skipping to change at page 4, line 35 skipping to change at page 2, line 35
the Management Information Base or MIB. MIB objects are generally the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP). accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58, module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580]. [RFC2580].
3. MPLS Textual Conventions MIB Definitions 3. MPLS Textual Conventions MIB Definitions
MPLS-TC-STD-MIB DEFINITIONS ::= BEGIN MPLS-TC-STD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, Unsigned32, Integer32, transmission
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
mplsTCStdMIB MODULE-IDENTITY
LAST-UPDATED "200310201200Z" -- 20 October 2003 12:00:00 GMT
ORGANIZATION
"IETF Multiprotocol Label Switching (MPLS) Working
Group."
CONTACT-INFO
" Thomas D. Nadeau
Cisco Systems, Inc.
tnadeau@cisco.com
Joan Cucchiara IMPORTS
Artel
jcucchiara@artel.com
Cheenu Srinivasan MODULE-IDENTITY,
Bloomberg L.P. Unsigned32, Integer32,
cheenu@bloomberg.net transmission FROM SNMPv2-SMI -- [RFC2578]
Arun Viswanathan TEXTUAL-CONVENTION
Force10 Networks, Inc. FROM SNMPv2-TC; -- [RFC2579]
arunv@force10networks.com
Hans Sjostrand mplsTCStdMIB MODULE-IDENTITY
ipUnplugged LAST-UPDATED "200406030000Z" -- June 3, 2004
hans@ipunplugged.com ORGANIZATION
"IETF Multiprotocol Label Switching (MPLS) Working
Group."
CONTACT-INFO
" Thomas D. Nadeau
Cisco Systems, Inc.
tnadeau@cisco.com
Kireeti Kompella Joan Cucchiara
Juniper Networks Marconi Communications, Inc.
kireeti@juniper.net jcucchiara@mindspring.com
Email comments to the MPLS WG Mailing List at Cheenu Srinivasan
mpls@uu.net." Bloomberg L.P.
DESCRIPTION cheenu@bloomberg.net
"Copyright (C) The Internet Society (2003). This
version of this MIB module is part of RFCXXX; see
the RFC itself for full legal notices.
This MIB module defines Textual Conventions Arun Viswanathan
for concepts used in Multi-Protocol Label Force10 Networks, Inc.
Switching (MPLS) networks." arunv@force10networks.com
REVISION "200310201200Z" -- 20 October 2003 12:00:00 GMT Hans Sjostrand
DESCRIPTION ipUnplugged
"Initial version published as part of RFC XXXX." hans@ipunplugged.com
-- Please see the IANA Considerations Section. Kireeti Kompella
-- The requested mplsStdMIB subId is 1, e.g. Juniper Networks
-- ::= { mplsStdMIB 1 } kireeti@juniper.net
::= { mplsStdMIB XXX } -- to be assigned by IANA Email comments to the MPLS WG Mailing List at
mpls@uu.net."
DESCRIPTION
"Copyright (C) The Internet Society (2004). The
initial version of this MIB module was published
in RFC 3811. For full legal notices see the RFC
itself or see:
http://www.ietf.org/copyrights/ianamib.html
mplsStdMIB OBJECT IDENTIFIER This MIB module defines TEXTUAL-CONVENTIONs
for concepts used in Multiprotocol Label
Switching (MPLS) networks."
-- This object identifier needs to be assigned by IANA. REVISION "200406030000Z" -- June 3, 2004
-- Since mpls has been assigned an ifType of 166 we recommend DESCRIPTION
-- that this OID be 166 as well, e.g. "Initial version published as part of RFC 3811."
-- ::= { transmission 166 }
::= { transmission XXX } -- to be assigned by IANA ::= { mplsStdMIB 1 }
MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION mplsStdMIB OBJECT IDENTIFIER
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A Label Switching Router (LSR) that
creates LDP sessions on ATM interfaces
uses the VCI or VPI/VCI field to hold the
LDP Label.
VCI values MUST NOT be in the 0-31 range. ::= { transmission 166 }
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 MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION
the management entity controlling the LDP DISPLAY-HINT "d"
subsystem should reject this with an STATUS current
inconsistentValue error. Also, if DESCRIPTION
the value of 32 is used for a VC which is "A Label Switching Router (LSR) that
NOT the Control VC, this should creates LDP sessions on ATM interfaces
result in an inconsistentValue error." uses the VCI or VPI/VCI field to hold the
REFERENCE LDP Label.
"MPLS using LDP and ATM VC Switching, RFC3035."
SYNTAX Integer32 (32..65535)
MplsBitRate ::= TEXTUAL-CONVENTION VCI values MUST NOT be in the 0-31 range.
DISPLAY-HINT "d" The values 0 to 31 are reserved for other uses
STATUS current by the ITU and ATM Forum. The value
DESCRIPTION of 32 can only be used for the Control VC,
"If the value of this object is greater than zero, although values greater than 32 could be
then this represents the bandwidth of this MPLS configured for the Control VC.
interface (or Label Switched Path) in units of
'1,000 bits per second'.
The value, when greater than zero, represents the If a value from 0 to 31 is used for a VCI
bandwidth of this MPLS interface (rounded to the the management entity controlling the LDP
nearest 1,000) in units of 1,000 bits per second. subsystem should reject this with an
If the bandwidth of the MPLS interface is between inconsistentValue error. Also, if
((n * 1000) - 500) and ((n * 1000) + 499), the value the value of 32 is used for a VC which is
of this object is n, such that n > 0. NOT the Control VC, this should
result in an inconsistentValue error."
REFERENCE
"MPLS using LDP and ATM VC Switching, RFC3035."
SYNTAX Integer32 (32..65535)
If the value of this object is 0 (zero), this MplsBitRate ::= TEXTUAL-CONVENTION
means that the traffic over this MPLS interface is DISPLAY-HINT "d"
considered to be best effort." STATUS current
SYNTAX Unsigned32 (0|1..4294967295) DESCRIPTION
"If the value of this object is greater than zero,
then this represents the bandwidth of this MPLS
interface (or Label Switched Path) in units of
'1,000 bits per second'.
MplsBurstSize ::= TEXTUAL-CONVENTION The value, when greater than zero, represents the
DISPLAY-HINT "d" bandwidth of this MPLS interface (rounded to the
STATUS current nearest 1,000) in units of 1,000 bits per second.
DESCRIPTION If the bandwidth of the MPLS interface is between
"The number of octets of MPLS data that the stream ((n * 1000) - 500) and ((n * 1000) + 499), the value
may send back-to-back without concern for policing. of this object is n, such that n > 0.
The value of zero indicates that an implementation
does not support Burst Size."
SYNTAX Unsigned32 (0..4294967295)
MplsExtendedTunnelId ::= TEXTUAL-CONVENTION If the value of this object is 0 (zero), this
STATUS current means that the traffic over this MPLS interface is
DESCRIPTION considered to be best effort."
"A unique identifier for an MPLS Tunnel. This may SYNTAX Unsigned32 (0|1..4294967295)
represent an IPv4 address of the ingress or egress
LSR for the tunnel. This value is derived from the
Extended Tunnel Id in RSVP or the Ingress Router ID
for CR-LDP."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC 3209.
Constraint-Based LSP Setup using LDP, RFC 3212." MplsBurstSize ::= TEXTUAL-CONVENTION
SYNTAX Unsigned32(0..4294967295) DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The number of octets of MPLS data that the stream
may send back-to-back without concern for policing.
The value of zero indicates that an implementation
does not support Burst Size."
SYNTAX Unsigned32 (0..4294967295)
MplsLabel ::= TEXTUAL-CONVENTION MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A unique identifier for an MPLS Tunnel. This may
represent an IPv4 address of the ingress or egress
LSR for the tunnel. This value is derived from the
Extended Tunnel Id in RSVP or the Ingress Router ID
for CR-LDP."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
[RFC3209].
-- RFC-Editor, pls fill in RFCxxxx as assigned Constraint-Based LSP Setup using LDP, [RFC3212]."
-- to draft-ietf-ccamp-gmpls-architecture-07.txt." SYNTAX Unsigned32(0..4294967295)
"This value represents an MPLS label as defined in MplsLabel ::= TEXTUAL-CONVENTION
(RFC3031), (RFC3032), (RFC3034), (RFC3035) and STATUS current
(RFCxxxx). DESCRIPTION
"This value represents an MPLS label as defined in
[RFC3031], [RFC3032], [RFC3034], [RFC3035] and
[RFC3471].
The label contents are specific to the label being The label contents are specific to the label being
represented, such as: represented, such as:
* The label carried in an MPLS shim header * The label carried in an MPLS shim header
(for LDP this is the Generic Label) is a 20-bit (for LDP this is the Generic Label) is a 20-bit
number represented by 4 octets. Bits 0-19 contain number represented by 4 octets. Bits 0-19 contain
a label or a reserved label value. Bits 20-31 a label or a reserved label value. Bits 20-31
MUST be zero. MUST be zero.
The following is quoted directly from (RFC3032). The following is quoted directly from [RFC3032].
There are several reserved label values: There are several reserved label values:
i. A value of 0 represents the i. A value of 0 represents the
'IPv4 Explicit NULL Label'. This label 'IPv4 Explicit NULL Label'. This label
value is only legal at the bottom of the value is only legal at the bottom of the
label stack. It indicates that the label label stack. It indicates that the label
stack must be popped, and the forwarding stack must be popped, and the forwarding
of the packet must then be based on the of the packet must then be based on the
IPv4 header. IPv4 header.
ii. A value of 1 represents the ii. A value of 1 represents the
'Router Alert Label'. This label value is 'Router Alert Label'. This label value is
legal anywhere in the label stack except at legal anywhere in the label stack except at
the bottom. When a received packet the bottom. When a received packet
contains this label value at the top of contains this label value at the top of
the label stack, it is delivered to a the label stack, it is delivered to a
local software module for processing. local software module for processing.
The actual forwarding of the packet The actual forwarding of the packet
is determined by the label beneath it is determined by the label beneath it
in the stack. However, if the packet is in the stack. However, if the packet is
forwarded further, the Router Alert Label forwarded further, the Router Alert Label
should be pushed back onto the label stack should be pushed back onto the label stack
before forwarding. The use of this label before forwarding. The use of this label
is analogous to the use of the is analogous to the use of the
'Router Alert Option' in IP packets 'Router Alert Option' in IP packets
(RFC2113). Since this label [RFC2113]. Since this label
cannot occur at the bottom of the stack, cannot occur at the bottom of the stack,
it is not associated with a it is not associated with a
particular network layer protocol. particular network layer protocol.
iii. A value of 2 represents the iii. A value of 2 represents the
'IPv6 Explicit NULL Label'. This label 'IPv6 Explicit NULL Label'. This label
value is only legal at the bottom of the value is only legal at the bottom of the
label stack. It indicates that the label label stack. It indicates that the label
stack must be popped, and the forwarding stack must be popped, and the forwarding
of the packet must then be based on the of the packet must then be based on the
IPv6 header. IPv6 header.
iv. A value of 3 represents the iv. A value of 3 represents the
'Implicit NULL Label'. 'Implicit NULL Label'.
This is a label that an LSR may assign and This is a label that an LSR may assign and
distribute, but which never actually distribute, but which never actually
appears in the encapsulation. When an appears in the encapsulation. When an
LSR would otherwise replace the label LSR would otherwise replace the label
at the top of the stack with a new label, at the top of the stack with a new label,
but the new label is 'Implicit NULL', but the new label is 'Implicit NULL',
the LSR will pop the stack instead of the LSR will pop the stack instead of
doing the replacement. Although doing the replacement. Although
this value may never appear in the this value may never appear in the
encapsulation, it needs to be specified in encapsulation, it needs to be specified in
the Label Distribution Protocol, so a value the Label Distribution Protocol, so a value
is reserved. is reserved.
v. Values 4-15 are reserved. v. Values 4-15 are reserved.
* The frame relay label can be either 10-bits or * The frame relay label can be either 10-bits or
23-bits depending on the DLCI field size and the 23-bits depending on the DLCI field size and the
upper 22-bits or upper 9-bits must be zero, upper 22-bits or upper 9-bits must be zero,
respectively. respectively.
* For an ATM label the lower 16-bits represents the * For an ATM label the lower 16-bits represents the
VCI, the next 12-bits represents the VPI and the VCI, the next 12-bits represents the VPI and the
remaining bits MUST be zero. remaining bits MUST be zero.
* The Generalized-MPLS (GMPLS) label contains a * The Generalized-MPLS (GMPLS) label contains a
value greater than 2^24-1 and used in GMPLS value greater than 2^24-1 and used in GMPLS
as defined in (RFCxxxx)." as defined in [RFC3471]."
-- RFC-Editor, pls fill in RFCxxxx as assigned REFERENCE
-- to draft-ietf-ccamp-gmpls-architecture-07.txt." "Multiprotocol Label Switching Architecture,
REFERENCE RFC3031.
"Multiprotocol Label Switching Architecture,
RFC3031.
MPLS Label Stack Encoding, RFC3032. MPLS Label Stack Encoding, [RFC3032].
Use of Label Switching on Frame Relay Networks, Use of Label Switching on Frame Relay Networks,
RFC3034. RFC3034.
MPLS using LDP and ATM VC Switching, RFC3035. MPLS using LDP and ATM VC Switching, RFC3035.
Generalized Multiprotocol Label Switching
(GMPLS) Architecture, [RFC3471]."
SYNTAX Unsigned32 (0..4294967295)
Generalized Multi-Protocol Label Switching MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION
(GMPLS) Architecture, RFCxxxx." STATUS current
-- RFC-Editor, pls fill in RFCxxxx as assigned DESCRIPTION
-- to draft-ietf-ccamp-gmpls-architecture-07.txt "The label distribution method which is also called
SYNTAX Unsigned32 (0..4294967295) the label advertisement mode [RFC3036].
Each interface on an LSR is configured to operate
in either Downstream Unsolicited or Downstream
on Demand."
REFERENCE
"Multiprotocol Label Switching Architecture,
RFC3031.
MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION LDP Specification, RFC3036, Section 2.6.3."
STATUS current SYNTAX INTEGER {
DESCRIPTION downstreamOnDemand(1),
"The label distribution method which is also called downstreamUnsolicited(2)
the label advertisement mode (RFC3036). }
Each interface on an LSR is configured to operate
in either Downstream Unsolicited or Downstream
on Demand."
REFERENCE
"Multiprotocol Label Switching Architecture,
RFC3031.
LDP Specification, RFC3036, Section 2.6.3." MplsLdpIdentifier ::= TEXTUAL-CONVENTION
SYNTAX INTEGER { DISPLAY-HINT "1d.1d.1d.1d:2d"
downstreamOnDemand(1), STATUS current
downstreamUnsolicited(2) DESCRIPTION
} "The LDP identifier is a six octet
quantity which is used to identify a
Label Switching Router (LSR) label space.
MplsLdpIdentifier ::= TEXTUAL-CONVENTION The first four octets identify the LSR and
DISPLAY-HINT "1d.1d.1d.1d:2d" must be a globally unique value, such as a
STATUS current 32-bit router ID assigned to the LSR, and the
DESCRIPTION last two octets identify a specific label
"The LDP identifier is a six octet space within the LSR."
quantity which is used to identify a SYNTAX OCTET STRING (SIZE (6))
Label Switching Router (LSR) label space.
The first four octets identify the LSR and MplsLsrIdentifier ::= TEXTUAL-CONVENTION
must be a globally unique value, such as a STATUS current
32-bit router ID assigned to the LSR, and the DESCRIPTION
last two octets identify a specific label "The Label Switching Router (LSR) identifier is the
space within the LSR." first 4 bytes of the Label Distribution Protocol
SYNTAX OCTET STRING (SIZE (6)) (LDP) identifier."
SYNTAX OCTET STRING (SIZE (4))
MplsLdpLabelType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Layer 2 label types which are defined for MPLS
LDP and/or CR-LDP are generic(1), atm(2), or
frameRelay(3)."
SYNTAX INTEGER {
generic(1),
atm(2),
frameRelay(3)
}
MplsLsrIdentifier ::= TEXTUAL-CONVENTION MplsLSPID ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The Label Switching Router (LSR) identifier is the "A unique identifier within an MPLS network that is
first 4 bytes of the Label Distribution Protocol assigned to each LSP. This is assigned at the head
(LDP) identifier." end of the LSP and can be used by all LSRs
SYNTAX OCTET STRING (SIZE (4)) to identify this LSP. This value is piggybacked by
the signaling protocol when this LSP is signaled
within the network. This identifier can then be
used at each LSR to identify which labels are
being swapped to other labels for this LSP. This
object can also be used to disambiguate LSPs that
share the same RSVP sessions between the same
source and destination.
MplsLdpLabelType ::= TEXTUAL-CONVENTION For LSPs established using CR-LDP, the LSPID is
STATUS current composed of the ingress LSR Router ID (or any of
DESCRIPTION its own IPv4 addresses) and a locally unique
"The Layer 2 label types which are defined for MPLS CR-LSP ID to that LSR. The first two bytes carry
LDP and/or CR-LDP are generic(1), atm(2), or the CR-LSPID, and the remaining 4 bytes carry
frameRelay(3)." the Router ID. The LSPID is useful in network
SYNTAX INTEGER { management, in CR-LSP repair, and in using
generic(1), an already established CR-LSP as a hop in
atm(2), an ER-TLV.
frameRelay(3)
}
MplsLSPID ::= TEXTUAL-CONVENTION For LSPs signaled using RSVP-TE, the LSP ID is
STATUS current defined as a 16-bit (2 byte) identifier used
DESCRIPTION in the SENDER_TEMPLATE and the FILTER_SPEC
"A unique identifier within an MPLS network that is that can be changed to allow a sender to
assigned to each LSP. This is assigned at the head share resources with itself. The length of this
end of the LSP and can be used by all LSRs object should only be 2 or 6 bytes. If the length
to identify this LSP. This value is piggybacked by of this octet string is 2 bytes, then it must
the signaling protocol when this LSP is signaled identify an RSVP-TE LSPID, or it is 6 bytes,
within the network. This identifier can then be it must contain a CR-LDP LSPID."
used at each LSR to identify which labels are REFERENCE
being swapped to other labels for this LSP. This "RSVP-TE: Extensions to RSVP for LSP Tunnels,
object can also be used to disambiguate LSPs that [RFC3209].
share the same RSVP sessions between the same
source and destination.
For LSPs established using CR-LDP, the LSPID is Constraint-Based LSP Setup using LDP,
composed of the ingress LSR Router ID (or any of [RFC3212]."
its own IPv4 addresses) and a locally unique SYNTAX OCTET STRING (SIZE (2|6))
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 MplsLspType ::= TEXTUAL-CONVENTION
defined as a 16-bit (2 byte) identifier used STATUS current
in the SENDER_TEMPLATE and the FILTER_SPEC DESCRIPTION
that can be changed to allow a sender to "Types of Label Switch Paths (LSPs)
share resources with itself. The length of this on a Label Switching Router (LSR) or a
object should only be 2 or 6 bytes. If the length Label Edge Router (LER) are:
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 unknown(1) -- if the LSP is not known
"RSVP-TE: Extensions to RSVP for LSP Tunnels, to be one of the following.
RFC3209.
Constraint-Based LSP Setup using LDP, terminatingLsp(2) -- if the LSP terminates
RFC3212." on the LSR/LER, then this
SYNTAX OCTET STRING (SIZE (2|6)) is an egressing LSP
which ends on the LSR/LER,
MplsLspType ::= TEXTUAL-CONVENTION originatingLsp(3) -- if the LSP originates
STATUS current from this LSR/LER, then
DESCRIPTION this is an ingressing LSP
"Types of Label Switch Paths (LSPs) which is the head-end of
on a Label Switching Router (LSR) or a the LSP,
Label Edge Router (LER) are:
unknown(1) -- if the LSP is not known crossConnectingLsp(4) -- if the LSP ingresses
to be one of the following. and egresses on the LSR,
then it is
cross-connecting on that
LSR."
SYNTAX INTEGER {
unknown(1),
terminatingLsp(2),
originatingLsp(3),
crossConnectingLsp(4)
}
terminatingLsp(2) -- if the LSP terminates MplsOwner ::= TEXTUAL-CONVENTION
on the LSR/LER, then this STATUS current
is an egressing LSP DESCRIPTION
which ends on the LSR/LER, "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:
originatingLsp(3) -- if the LSP originates unknown(1) - the local network management
from this LSR/LER, then subsystem cannot discern which
this is an ingressing LSP component created the object.
which is the head-end of
the LSP,
crossConnectingLsp(4) -- if the LSP ingresses other(2) - the local network management
and egresses on the LSR, subsystem is able to discern which component
then it is created the object, but the component is not
cross-connecting on that listed within the following choices,
LSR." e.g., command line interface (cli).
SYNTAX INTEGER {
unknown(1),
terminatingLsp(2),
originatingLsp(3),
crossConnectingLsp(4)
}
MplsOwner ::= TEXTUAL-CONVENTION snmp(3) - The Simple Network Management Protocol
STATUS current was used to configure this object initially.
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 ldp(4) - The Label Distribution Protocol was
subsystem cannot discern which used to configure this object initially.
component created the object.
other(2) - the local network management crldp(5) - The Constraint-Based Label Distribution
subsystem is able to discern which component Protocol was used to configure this object
created the object, but the component is not initially.
listed within the following choices,
e.g. command line interface (cli).
snmp(3) - The Simple Network Management Protocol rsvpTe(6) - The Resource Reservation Protocol was
was used to configure this object initially. used to configure this object initially.
ldp(4) - The Label Distribution Protocol was policyAgent(7) - A policy agent (perhaps in
used to configure this object initially. combination with one of the above protocols) was
used to configure this object initially.
crldp(5) - The Constraint-Based Label Distribution An object created by any of the above choices
Protocol was used to configure this object MAY be modified or destroyed by the same or a
initially. different choice."
SYNTAX INTEGER {
unknown(1),
other(2),
snmp(3),
ldp(4),
crldp(5),
rsvpTe(6),
policyAgent(7)
}
rsvpTe(6) - The Resource Reservation Protocol was MplsPathIndexOrZero ::= TEXTUAL-CONVENTION
used to configure this object initially. 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)
policyAgent(7) - A policy agent (perhaps in MplsPathIndex ::= TEXTUAL-CONVENTION
combination with one of the above protocols) was STATUS current
used to configure this object initially. DESCRIPTION
"A unique value to index (by Path number) an
entry in a table."
SYNTAX Unsigned32(1..4294967295)
An object created by any of the above choices MplsRetentionMode ::= TEXTUAL-CONVENTION
MAY be modified or destroyed by the same or a STATUS current
different choice." DESCRIPTION
SYNTAX INTEGER { "The label retention mode which specifies whether
unknown(1), an LSR maintains a label binding for a FEC
other(2), learned from a neighbor that is not its next hop
snmp(3), for the FEC.
ldp(4),
crldp(5),
rsvpTe(6),
policyAgent(7)
}
MplsPathIndexOrZero ::= TEXTUAL-CONVENTION If the value is conservative(1) then advertised
STATUS current label mappings are retained only if they will be
DESCRIPTION used to forward packets, i.e., if label came from
"A unique identifier used to identify a specific a valid next hop.
path used by a tunnel. A value of 0 (zero) means
that no path is in use."
SYNTAX Unsigned32(0..4294967295)
MplsPathIndex ::= TEXTUAL-CONVENTION If the value is liberal(2) then all advertised
STATUS current label mappings are retained whether they are from
DESCRIPTION a valid next hop or not."
"A unique value to index (by Path number) an REFERENCE
entry in a table." "Multiprotocol Label Switching Architecture,
SYNTAX Unsigned32(1..4294967295) RFC3031.
MplsRetentionMode ::= TEXTUAL-CONVENTION LDP Specification, RFC3036, Section 2.6.2."
STATUS current SYNTAX INTEGER {
DESCRIPTION conservative(1),
"The label retention mode which specifies whether liberal(2)
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 MplsTunnelAffinity ::= TEXTUAL-CONVENTION
label mappings are retained only if they will be STATUS current
used to forward packets, i.e. if label came from DESCRIPTION
a valid next hop. "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)
If the value is liberal(2) then all advertised MplsTunnelIndex ::= TEXTUAL-CONVENTION
label mappings are retained whether they are from STATUS current
a valid next hop or not." DESCRIPTION
REFERENCE "A unique index into mplsTunnelTable.
"Multiprotocol Label Switching Architecture, For tunnels signaled using RSVP, this value
RFC3031. should correspond to the RSVP Tunnel ID
used for the RSVP-TE session."
SYNTAX Unsigned32 (0..65535)
LDP Specification, RFC3036, Section 2.6.2." MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION
SYNTAX INTEGER { STATUS current
conservative(1), DESCRIPTION
liberal(2) "The tunnel entry with instance index 0
} should refer to the configured tunnel
interface (if one exists).
MplsTunnelAffinity ::= TEXTUAL-CONVENTION Values greater than 0, but less than or
STATUS current equal to 65535, should be used to indicate
DESCRIPTION signaled (or backup) tunnel LSP instances.
"Describes the configured 32-bit Include-any, For tunnel LSPs signaled using RSVP,
include-all, or exclude-all constraint for this value should correspond to the
constraint-based link selection." RSVP LSP ID used for the RSVP-TE
REFERENCE LSP.
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC3209, Section 4.7.4."
SYNTAX Unsigned32(0..4294967295)
MplsTunnelIndex ::= TEXTUAL-CONVENTION Values greater than 65535 apply to FRR
STATUS current detour instances."
DESCRIPTION SYNTAX Unsigned32(0|1..65535|65536..4294967295)
"A unique index into mplsTunnelTable.
For tunnels signaled using RSVP, this value
should correspond to the RSVP destination
port used for the RSVP-TE session."
SYNTAX Unsigned32 (0..65535)
MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION TeHopAddressType ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The tunnel entry with instance index 0 "A value that represents a type of address for a
should refer to the configured tunnel Traffic Engineered (TE) Tunnel hop.
interface (if one exists).
Values greater than 0, but less than or unknown(0) An unknown address type. This value
equal to 65535, should be used to indicate MUST be used if the value of the
signaled (or backup) tunnel LSP instances. corresponding TeHopAddress object is a
For tunnel LSPs signaled using RSVP, zero-length string. It may also be
this value should correspond to the used to indicate a TeHopAddress which
RSVP source port used for the RSVP-TE is not in one of the formats defined
session. below.
Values greater than 65535 apply to FRR ipv4(1) An IPv4 network address as defined by
detour instances." the InetAddressIPv4 TEXTUAL-CONVENTION
SYNTAX Unsigned32(0|1..65535|65536..4294967295) [RFC3291].
TeHopAddressType ::= TEXTUAL-CONVENTION ipv6(2) A global IPv6 address as defined by
STATUS current the InetAddressIPv6 TEXTUAL-CONVENTION
DESCRIPTION [RFC3291].
"A value that represents a type of address a
Traffic Engineered (TE) Tunnel hop.
unknown(0) An unknown address type. This value asnumber(3) An Autonomous System (AS) number as
MUST be used if the value of the defined by the TeHopAddressAS
corresponding TeHopAddress object is a TEXTUAL-CONVENTION.
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 unnum(4) An unnumbered interface index as
the InetAddressIPv4 TEXTUAL-CONVENTION defined by the TeHopAddressUnnum
(RFC3291). TEXTUAL-CONVENTION.
ipv6(2) A global IPv6 address as defined by lspid(5) An LSP ID for TE Tunnels
the InetAddressIPv6 TEXTUAL-CONVENTION (RFC3212) as defined by the
(RFC3291). MplsLSPID TEXTUAL-CONVENTION.
asnumber(3) An Autonomous System (AS) number as Each definition of a concrete TeHopAddressType
defined by the TeHopAddressAS value must be accompanied by a definition
TEXTUAL-CONVENTION. of a TEXTUAL-CONVENTION for use with that
TeHopAddress.
unnum(4) An unnumbered interface index as To support future extensions, the TeHopAddressType
defined by the TeHopAddressUnnum TEXTUAL-CONVENTION SHOULD NOT be sub-typed in
TEXTUAL-CONVETION. 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.
lspid(5) An LSP ID for TE Tunnels Implementations must ensure that TeHopAddressType
(RFC3212) as defined by the objects and any dependent objects
MplsLSPID TEXTUAL-CONVENTION. (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))."
Each definition of a concrete TeHopAddressType REFERENCE
value must be accompanied by a definition "TEXTUAL-CONVENTIONs for Internet Network
of a textual convention for use with that Addresses, RFC3291.
TeHopAddress.
To support future extensions, the TeHopAddressType Constraint-Based LSP Setup using LDP,
TEXTUAL-CONVENTION SHOULD NOT be sub-typed in [RFC3212]"
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 SYNTAX INTEGER {
objects and any dependent objects unknown(0),
(e.g. TeHopAddress objects) are consistent. ipv4(1),
An inconsistentValue error must be generated ipv6(2),
if an attempt to change a TeHopAddressType asnumber(3),
object would, for example, lead to an unnum(4),
undefined TeHopAddress value that is lspid(5)
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 TeHopAddress ::= TEXTUAL-CONVENTION
"Textual Conventions for Internet Network STATUS current
Addresses, RFC3291. 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.
Constraint-Based LSP Setup using LDP, A TeHopAddress value is always interpreted within
RFC3212." 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.
SYNTAX INTEGER { The value of a TeHopAddress object must always be
unknown(0), consistent with the value of the associated
ipv4(1), TeHopAddressType object. Attempts to set a
ipv6(2), TeHopAddress object to a value which is
asnumber(3), inconsistent with the associated TeHopAddressType
unnum(4), must fail with an inconsistentValue error."
lspid(5) SYNTAX OCTET STRING (SIZE (0..32))
}
TeHopAddress ::= TEXTUAL-CONVENTION TeHopAddressAS ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Denotes a generic Tunnel hop address, "Represents a two or four octet AS number.
that is, the address of a node which The AS number is represented in network byte
an LSP traverses, including the source order (MSB first). A two-octet AS number has
and destination nodes. An address may be the two MSB octets set to zero."
very concrete, for example, an IPv4 host REFERENCE
address (i.e., with prefix length 32); "Textual Conventions for Internet Network
if this IPv4 address is an interface Addresses, [RFC3291]. The
address, then that particular interface InetAutonomousSystemsNumber TEXTUAL-CONVENTION
must be traversed. An address may also has a SYNTAX of Unsigned32, whereas this TC
specify an 'abstract node', for example, has a SYNTAX of OCTET STRING (SIZE (4)).
an IPv4 address with prefix length Both TCs represent an autonomous system number
less than 32, in which case, the LSP but use different syntaxes to do so."
can traverse any node whose address SYNTAX OCTET STRING (SIZE (4))
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 TeHopAddressUnnum ::= TEXTUAL-CONVENTION
the context of an TeHopAddressType value. Every STATUS current
usage of the TeHopAddress TEXTUAL-CONVENTION DESCRIPTION
is required to specify the TeHopAddressType object "Represents an unnumbered interface:
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 octets contents encoding
consistent with the value of the associated 1-4 unnumbered interface network-byte order
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 The corresponding TeHopAddressType value is
STATUS current unnum(5)."
DESCRIPTION SYNTAX OCTET STRING(SIZE(4))
"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 END
STATUS current
DESCRIPTION
"Represents an unnumbered interface:
octets contents encoding 4. References
1-4 unnumbered interface network-byte order
The corresponding TeHopAddressType value is 4.1. Normative References
unnum(5)."
SYNTAX OCTET STRING(SIZE(4))
END [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
4. Normative References [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 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP: 26, RFC 2434, IANA Considerations Section in RFCs", BCP: 26, RFC 2434,
October 1998. October 1998.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
Rose, M. and S. Waldbusser, "Structure of Management "Structure of Management Information Version 2 (SMIv2)",
Information Version 2 (SMIv2)", STD 58, RFC 2578, April STD 58, RFC 2578, April 1999.
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual
Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", Conventions for SMIv2", STD 58, RFC 2579, April 1999.
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
Rose, M. and S. Waldbusser, "Conformance Statements for "Conformance Statements for SMIv2", STD 58, RFC 2580, April
SMIv2", STD 58, RFC 2580, April 1999. 1999.
[RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., [RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
Federokow, G., Li, T., and A. Conta, "MPLS Label Stack Federokow, G., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label
on Frame Relay Networks Specification", RFC 3034, January Switching on Frame Relay Networks Specification", RFC 3034,
2001. January 2001.
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP
Switching", RFC 3035, January 2001. and ATM VC Switching", RFC 3035, January 2001.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
Thomas, "LDP Specification", RFC 3036, January 2001. B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3212] Jamoussi, B., (editor), et. al. "Constraint-Based LSP Setup [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R.,
using LDP", RFC 3212, January 2002. 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. [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 3291, May 2002. Addresses", RFC 3291, May 2002.
[GMPLS-ARCH] [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Mannie, E., (editor), et. al. "Generalized Multi-Protocol Switching (GMPLS) Architecture", RFC 3471, January 2003.
Label Switching (GMPLS) Architecture", draft-ietf-ccamp-
gmpls-architecture-07.txt, May 2003.
5. Informative References 4.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
6. Security Considerations 5. Security Considerations
This module does not define any management objects. Instead, it This module does not define any management objects. Instead, it
defines a set of textual conventions which may be used by other MPLS defines a set of textual conventions which may be used by other MPLS
MIB modules to define management objects. MIB modules to define management objects.
Meaningful security considerations can only be written in the MIB Meaningful security considerations can only be written in the MIB
modules that define management objects. Therefore, this document has modules that define management objects. Therefore, this document has
no impact on the security of the Internet. no impact on the security of the Internet.
7. IANA Considerations 6. IANA Considerations
IANA is requested to make a MIB OID assignment under the transmission IANA has made a MIB OID assignment under the transmission branch,
branch, that is, assign the mplsStdMIB under { transmission 166 }. that is, assigned the mplsStdMIB under { transmission 166 }. This
This sub-id is requested because 166 is the ifType for mpls(166) and sub-id is requested because 166 is the ifType for mpls(166) and is
is available under transmission. available under transmission.
In the future, MPLS related standards track MIB modules should be In the future, MPLS related standards track MIB modules should be
rooted under the mplsStdMIB subtree. The IANA is requested to manage rooted under the mplsStdMIB subtree. The IANA is requested to manage
that namespace. New assignments can only be made via a Standards that namespace. New assignments can only be made via a Standards
Action as specified in [RFC2434]. Action as specified in [RFC2434].
This document also requests IANA to assign { mplsStdMIB 1 } to the The IANA has also assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB
MPLS-TC-STD-MIB specified in this document. specified in this document.
8. Contributors 7. Contributors
This document was created by combining TEXTUAL-CONVENTIONS from This document was created by combining TEXTUAL-CONVENTIONS from
current MPLS MIBs and a TE-WG MIB. Co-authors on each of these MIBs 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 to the TEXTUAL-CONVENTIONS contained in this MIB and also
contributed greatly to the revisions of this document. These co- contributed greatly to the revisions of this document. These co-
authors addresses are included here because they are useful future authors addresses are included here because they are useful future
contacts for information about this document. These co-authors are: contacts for information about this document. These co-authors are:
Cheenu Srinivasan Cheenu Srinivasan
Bloomberg L.P. Bloomberg L.P.
499 Park Ave. 499 Park Ave.
New York, NY 10022 New York, NY 10022
Phone: +1-212-893-3682
Email: cheenu@bloomberg.net
Arun Viswanathan Phone: +1-212-893-3682
Force10 Networks, Inc. EMail: cheenu@bloomberg.net
1440 McCarthy Blvd
Milpitas, CA 95035
Phone: +1-408-571-3516
Email: arunv@force10networks.com
Hans Sjostrand Arun Viswanathan
ipUnplugged Force10 Networks, Inc.
P.O. Box 101 60 1440 McCarthy Blvd
S-121 28 Stockholm, Sweden Milpitas, CA 95035
Phone: +46-8-725-5930
Email: hans@ipunplugged.com
Kireeti Kompella Phone: +1-408-571-3516
Juniper Networks EMail: arunv@force10networks.com
1194 Mathilda Ave
Sunnyvale, CA 94089
Phone: +1-408-745-2000
Email: kireeti@juniper.net
9. Acknowledgements 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 This document is a product of the MPLS Working Group. The editors
and contributors would like to thank Mike MacFadden and Adrian Farrel and contributors would like to thank Mike MacFadden and Adrian Farrel
for their helpful comments on several reviews. Also, the editors and for their helpful comments on several reviews. Also, the editors and
contributors would like to give a special acknowledgement to Bert contributors would like to give a special acknowledgement to Bert
Wijnen for his many detailed reviews. Bert's assistance and guidance Wijnen for his many detailed reviews. Bert's assistance and guidance
is greatly appreciated. is greatly appreciated.
10. Intellectual Property Notice 9. Authors' Addresses
Thomas D. Nadeau
Cisco Systems, Inc.
BXB300/2/
300 Beaver Brook Road
Boxborough, MA 01719
Phone: +1-978-936-1470
EMail: tnadeau@cisco.com
Joan E. Cucchiara
Marconi Communications, Inc.
900 Chelmsford Street
Lowell, MA 01851
Phone: +1-978-275-7400
EMail: jcucchiara@mindspring.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11 [RFC2028]. found in BCP 78 and BCP 79.
Copies of claims of rights made available for publication and any
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat. specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
11. Authors' Addresses
Thomas D. Nadeau
Cisco Systems, Inc.
BXB300/2/
300 Beaver Brook Road
Boxborough, MA 01719
Phone: +1-978-936-1470
Email: tnadeau@cisco.com
Joan Cucchiara
Artel
237 Cedar Hill Street
Marlborough, MA 01752
Phone: +1-508-303-8200 x302
Email: jcucchiara@artel.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Acknowledgement
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an Funding for the RFC Editor function is currently provided by the
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Internet Society.
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 141 change blocks. 
728 lines changed or deleted 703 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/