One document matched: draft-ietf-pwe3-pw-tc-mib-02.txt
Differences from draft-ietf-pwe3-pw-tc-mib-01.txt
Internet Draft Thomas D. Nadeau
Expires: April 2004 Cisco Systems, Inc.
David Zelig
Corrigent Systems
Editors
October 2003
Definitions for Textual Conventions and OBJECT-IDENTITIES
for Pseudo-Wires Management
draft-ietf-pwe3-pw-tc-mib-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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.
Copyright (C) The Internet Society (2001). All rights reserved.
1 Abstract
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community. In particular, it describes the textual
conventions to be used in the various Pseudo Wire (PW) MIB modules.
Table of Contents
1 Abstract 1
2 Introduction 2
3 Terminology 2
4 The SNMP Management Framework 3
4.1 Object Definitions 4
5 Object definitions 4
6 Security Considerations 7
7 References 7
8 Author's Addresses 9
9 Full Copyright Statement 9
2 Introduction
This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines Textual Conventions used in
IETF PW and PW-related MIBs.
Comments should be made directly to the MPLS mailing list at
pwe3@ietf.org.
For an introduction to the concepts of Pseudo-Wires, see [PWREQ]
and [FRMWK].
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119
[BCP14].
3 Terminology
This document uses terminology from the document describing the PW
framework [FRMWK].
4 The SNMP Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
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
[RFC2580].
5 Object definitions
PW-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, Unsigned32, Integer32, experimental
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TruthValue
FROM SNMPv2-TC;
pwTCMIB MODULE-IDENTITY
LAST-UPDATED "200307281200Z" -- 28 July 2003 12:00:00 GMT
ORGANIZATION "Pseudo Wire Edge to Edge Emulation (PWE3) Working
Group"
CONTACT-INFO
" Thomas D. Nadeau
Postal: Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Tel: +1-978-497-3051
Email: tnadeau@cisco.com
Dave Danenberg
Postal: Litchfield Communications, Inc.
76 Westbury Park Rd
Princeton Building East
Watertown, CT 06795
Tel: +1-860-945-1573 x3180
Email: dave_danenberg@litchfieldcomm.com
David Zelig
Postal: Corrigent Systems.
126, Yigal Alon St.
Tel Aviv, ISRAEL
Phone: +972-3-6945273
E-mail: davidz@corrigent.com
Andrew G. Malis
Postal: Tellabs, Inc.
2730 Orchard Parkway
San Jose, CA 95134
Email: Andy.Malis@tellabs.com
PWE3 Working Group Mailing List: pwe3@ietf.org"
DESCRIPTION
"This MIB Module provides Textual Conventions
and OBJECT-IDENTITY Objects to be used PW services."
-- Revision history.
REVISION "200307281200Z" -- 28 July 2003 12:00:00 GMT
DESCRIPTION "Adding objects to cover new control draft.
Adapt VC types for current values in WG documents."
REVISION "200305011200Z" -- 1 May 2003 12:00:00 GMT
DESCRIPTION "Adding PwVcAttachmentIdentifierType,
Adapt VC types for current values in WG documents."
REVISION "0205281200Z" -- 28 May 2002 12:00:00 GMT
DESCRIPTION "Adding PwVcType, and enhance some descriptions."
REVISION "0201301200Z" -- 30 January 2002 12:00:00 GMT
DESCRIPTION "Adding PwVcVlanCfg, PwAddressType and
PwOperStatus."
REVISION "200112201200Z" -- 20 Dec 2001 12:00:00 GMT
DESCRIPTION "Remove PwVcInstance"
REVISION "200107121200Z" -- 12 July 2001 12:00:00 GMT
DESCRIPTION "Initial version."
::= { pwMIB 1 } -- pwMIB To Be Assigned by IANA
pwMIB OBJECT IDENTIFIER
::= { experimental 8888 } -- To be assigned by IANA
-- Textual Conventions defined below are organized alphabetically
PwGroupID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An administrative identification mechanism for grouping a
set of service-specific pseudo-wire services. May only
have local significance."
SYNTAX Unsigned32
PwVcIDType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Virtual Circuit Identifier. Used to identify the VC
(together with some other fields) in the signaling
session. Zero if the VC is set-up manually."
SYNTAX Unsigned32
PwVcIndexType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Virtual Circuit Index. Locally unique index for indexing
several MIB tables associated with a particular VC."
SYNTAX Unsigned32
PwVcVlanCfg ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"VLAN configuration for Ethernet PW.
Values between 0 to 4095 indicate the actual VLAN field
value.
A value of 4096 indicates that the object refer to
untagged frames, i.e. frames without 802.1Q field.
A value of 4097 indicates that the object is not
relevant."
SYNTAX Integer32 (0..4097)
PwOperStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicate the operational status of the PW VC.
- up: Ready to pass packets.
- down: If PW signaling has not yet finished, or
indications available at the service
level indicate that the VC is not
passing packets.
- testing: If AdminStatus at the PW level is set to
test.
- dormant: The PW is not available because of the
required resources are occupied PW with
higher priority PWs .
- notPresent: Some component is missing to accomplish
the set up of the PW.
- lowerLayerDown: The underlying PSN or outer tunnel is not
in OperStatus 'up'.
"
SYNTAX INTEGER {
up(1),
down(2),
testing(3),
unknown(4),
dormant(5),
notPresent(6),
lowerLayerDown(7)
}
PwVcType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicate the VC type (i.e. the carried service).
Note: the exact set of VC types is yet to be worked
out by the WG.
"
SYNTAX INTEGER {
other(0),
frameRelayDlci(1),
atmAal5SduVcc(2),
atmTransparent(3),
ethernetTagged(4),
ethernet(5),
hdlc(6),
ppp(7),
cem(8), -- old format
atmCellNto1Vcc(9),
atmCellNto1Vpc(10),
ipLayer2Transport(11),
atmCell1to1Vcc(12),
atmCell1to1Vpc(13),
atmAal5PduVcc(14),
frameRelayPortMode(15),
cep(16)
}
PwVcAttachmentIdentifierType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An octet string used in the generalized FEC element for
identifying attachment forwarder and groups. The NULL
identifier is of zero length.
"
SYNTAX OCTET STRING (SIZE (0..255))
PwVcCw ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"If true, indicate the existence or configuration
of control word.
"
SYNTAX TruthValue
PwVcRemoteCwStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicate the status of the control word as advertized by
the remote.
notApplicable is set by the agent for manulaly configured PW.
waitingForNextMsg indicate that the node is waiting for
another
label mapping from the remote.
sentWrongBitErrorCode indicate that the local node has
notified the
peer about mismatch in the C bit.
rxWithdrawWithWrongBitErrorCode indicate that a withdraw
message
has been recieved with wrong C-bit error code.
illegalRecievedBit indicate a C bit configuration with the
remote
which is not compatible with the PW type.
sameAsSent indicate consistent C bit setting between the
peers.
notYetKnown indicate that a label mapping has not yet
recieved
from the peer.
"
SYNTAX INTEGER {
notApplicable (0),
waitingForNextMsg (1),
sentWrongBitErrorCode (2),
rxWithdrawWithWrongBitErrorCode (3),
illegalRecievedBit (4),
sameAsSent (5),
notYetKnown(6)
}
PwVcCapabilities ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicate the optional capabilities of the control protocol.
A value of zero indicate the basic LDP PW signaling.
Values may be added in the future based on
new capabilities introduced in IETF documents.
"
SYNTAX BITS {
pwStatusIndication (0)
}
PwVcStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The status of the PW and the interfaces affecting this PW.
"
SYNTAX BITS {
pwNotForwarding (0),
customerFacingPwRxFault (1),
customerFacingPwTxFault (2),
psnFacingPwRxFault (3),
psnFacingPwTxFault (4)
}
PwVcFragSize ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"If set to value other than zero, it indicates desired
fragmantation
to the value set. If set to zero, fragmantation is not desired
for
PSN bound packets.
"
SYNTAX Unsigned32
PwVcFragStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The status of the fragmantation process based on local
configuration
and the remote capability.
noFragmantation bit indicate that local configuration is for no
fragmantation.
cfgFragGreaterThanPsnMtu bit indicate the local desire to
fragment, but the
fragamentation size desired is greater than the MTU available at
the PSN between
peers. Fragmantation is not done in this case.
cfgFragButRemoteIncapable bit
indicate local configuration indicate the desire for
fragmantation but the remote
is not capable of fragmantation. remoteFragCapable bit indicate
that the remote
has advertized it's fragmantation capability.
fragmantationEnabled bit indicate that both the local was
configured for
fragmantation and the remote has the cabability
to accept fragmented packets.
"
SYNTAX BITS {
noFragmantation (0),
cfgFragGreaterThanPsnMtu (1),
cfgFragButRemoteIncapable (2),
remoteFragCapable (3),
fragmantationEnabled (4)
}
END
6 Security Considerations
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.
7 References
[PWREQ] Xiao et al, "Requirements for Pseudo Wire Emulation
Edge-to-Edge (PWE3)", work-in-progress.
[Assigned] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
1700, October 1994. See also: http://www.isi.edu/in-
notes/iana/assignments/smi-numbers
[IANAFamily]Internet Assigned Numbers Authority (IANA), ADDRESS
FAMILY NUMBERS,(http://www.isi.edu/in-
notes/iana/assignements/address-family-numbers), for
MIB see:
ftp://ftp.isi.edu/mib/ianaaddressfamilynumbers.mib
[IFMIB] McCloghrie, K., and F. Kastenholtz, "The Interfaces
Group MIB using SMIv2", RFC 2863, June 2000.
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management
Frameworks", RFC 2571, April 1999.
[RFC1155] Rose, M., and K. McCloghrie, "Structure and
Identification of Management Information for TCP/IP-
based Internets", STD 16, RFC 1155, May 1990.
[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1215] M. Rose, "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J, Rose, M., and S. Waldbusser, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC
2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J, Rose, M., and S. Waldbusser, "Textual Conventions
for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J, Rose, M., and S. Waldbusser, "Conformance Statements
for SMIv2", STD 58, RFC 2580, April 1999.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", RFC 2572, April
1999.
[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security
Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905,
January 1996.
[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
Applications", RFC 2573, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC 2570, April 1999.
8 Author's Addresses
Thomas D. Nadeau
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Email: tnadeau@cisco.com
Dave Danenberg
Litchfield Communications, Inc.
76 Westbury Park Rd
Princeton Building East
Watertown, CT 06795
Email: dave_danenberg@litchfieldcomm.com
David Zelig
Corrigent Systems
126, Yigal Alon st.
Tel Aviv, ISRAEL
Phone: +972-3-6945273
Email: davidz@corrigent.com
Andrew G. Malis
Tellabs, Inc.
2730 Orchard Parkway
San Jose, CA 95134
Email: Andy.Malis@tellabs.com
9 Full Copyright Statement
Copyright (C) The Internet Society (2000). 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
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
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.
| PAFTECH AB 2003-2026 | 2026-04-21 13:24:27 |