summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4801.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4801.txt')
-rw-r--r--doc/rfc/rfc4801.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc4801.txt b/doc/rfc/rfc4801.txt
new file mode 100644
index 0000000..4a72239
--- /dev/null
+++ b/doc/rfc/rfc4801.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group T. Nadeau, Ed.
+Request for Comment: 4801 Cisco Systems, Inc.
+Category: Standards Track A. Farrel, Ed.
+ Old Dog Consulting
+ February 2007
+
+
+ Definitions of Textual Conventions for
+ Generalized Multiprotocol Label Switching (GMPLS) Management
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document defines a Management Information Base (MIB) module that
+ contains textual conventions (TCs) to represent commonly used
+ Generalized Multiprotocol Label Switching (GMPLS) management
+ information. The intent is that these textual conventions will be
+ imported and used in GMPLS-related MIB modules that would otherwise
+ define their own representations.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. The Internet-Standard Management Framework ......................2
+ 3. GMPLS Textual Conventions MIB Definitions .......................3
+ 4. Security Considerations .........................................5
+ 5. IANA Considerations .............................................6
+ 6. References ......................................................6
+ 6.1. Normative References .......................................6
+ 6.2. Informative References .....................................7
+ 7. Acknowledgements ................................................7
+
+
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 1]
+
+RFC 4801 TCs for GMPLS Management February 2007
+
+
+1. Introduction
+
+ This document defines a MIB module that contains textual conventions
+ (TCs) for Generalized Multiprotocol Label Switching (GMPLS) networks.
+ These textual conventions should be imported by MIB modules that
+ manage GMPLS networks.
+
+ This MIB module supplements the MIB module in [RFC3811] that defines
+ textual conventions for Multiprotocol Label Switching (MPLS)
+ management. [RFC3811] may continue to be used without this MIB
+ module in networks that support only MPLS.
+
+ 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 BCP 14, RFC 2119
+ [RFC2119].
+
+ For an introduction to the concepts of GMPLS, see [RFC3945].
+
+2. The Internet-Standard 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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 2]
+
+RFC 4801 TCs for GMPLS Management February 2007
+
+
+3. GMPLS Textual Conventions MIB Definitions
+
+ This MIB module makes reference to the following documents:
+ [RFC2578], [RFC2579], [RFC3471], and [RFC3811].
+
+ GMPLS-TC-STD-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY
+ FROM SNMPv2-SMI -- RFC 2578
+ TEXTUAL-CONVENTION
+ FROM SNMPv2-TC -- RFC 2579
+ mplsStdMIB
+ FROM MPLS-TC-STD-MIB -- RFC 3811
+ ;
+
+ gmplsTCStdMIB MODULE-IDENTITY
+ LAST-UPDATED
+ "200702280000Z" -- 28 February 2007 00:00:00 GMT
+ ORGANIZATION
+ "IETF Common Control and Measurement Plane (CCAMP) Working Group"
+ CONTACT-INFO
+ " Thomas D. Nadeau
+ Cisco Systems, Inc.
+ Email: tnadeau@cisco.com
+
+ Adrian Farrel
+ Old Dog Consulting
+ Email: adrian@olddog.co.uk
+
+ Comments about this document should be emailed directly to the
+ CCAMP working group mailing list at ccamp@ops.ietf.org"
+ DESCRIPTION
+ "Copyright (C) The IETF Trust (2007). This version of
+ this MIB module is part of RFC 4801; see the RFC itself for
+ full legal notices.
+
+ This MIB module defines TEXTUAL-CONVENTIONs for concepts used in
+ Generalized Multiprotocol Label Switching (GMPLS) networks."
+ REVISION
+ "200702280000Z" -- 28 February 2007 00:00:00 GMT
+ DESCRIPTION
+ "Initial version published as part of RFC 4801."
+ ::= { mplsStdMIB 12 }
+
+ GmplsFreeformLabelTC ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+
+
+
+Nadeau & Farrel Standards Track [Page 3]
+
+RFC 4801 TCs for GMPLS Management February 2007
+
+
+ "This TEXTUAL-CONVENTION can be used as the syntax of an object
+ that contains any GMPLS Label. Objects with this syntax can be
+ used to represent labels that have label types that are not
+ defined in any RFCs. The freeform GMPLS Label may also be used
+ by systems that do not wish to represent labels that have
+ label types defined in RFCs using type-specific syntaxes."
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
+ Functional Description, RFC 3471, section 3.2."
+ SYNTAX OCTET STRING (SIZE (0..64))
+
+ GmplsLabelTypeTC ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Determines the interpretation that should be applied to an
+ object that encodes a label. The possible types are:
+
+ gmplsMplsLabel(1) - The label is an MPLS Packet, Cell,
+ or Frame Label and is encoded as
+ described for the TEXTUAL-
+ CONVENTION MplsLabel defined in
+ RFC 3811.
+
+ gmplsPortWavelengthLabel(2) - The label is a Port or Wavelength
+ Label as defined in RFC 3471.
+
+ gmplsFreeformLabel(3) - The label is any form of label
+ encoded as an OCTET STRING using
+ the TEXTUAL-CONVENTION
+ GmplsFreeformLabel.
+
+ gmplsSonetLabel(4) - The label is a Synchronous Optical
+ Network (SONET) Label as
+ defined in RFC 4606.
+
+ gmplsSdhLabel(5) - The label is a Synchronous Digital
+ Hierarchy (SDH) Label as defined
+ in RFC 4606.
+
+ gmplsWavebandLabel(6) - The label is a Waveband Label as
+ defined in RFC 3471."
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
+ Functional Description, RFC 3471, section 3.
+ 2. Definition of Textual Conventions and for Multiprotocol Label
+ Switching (MPLS) Management, RFC 3811, section 3.
+ 3. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
+ for Synchronous Optical Network (SONET) and Synchronous
+
+
+
+Nadeau & Farrel Standards Track [Page 4]
+
+RFC 4801 TCs for GMPLS Management February 2007
+
+
+ Digital Hierarchy (SDH) Control, RFC 4606."
+ SYNTAX INTEGER {
+ gmplsMplsLabel(1),
+ gmplsPortWavelengthLabel(2),
+ gmplsFreeformGeneralizedLabel(3),
+ gmplsSonetLabel(4),
+ gmplsSdhLabel(5),
+ gmplsWavebandLabel(6)
+ }
+
+ GmplsSegmentDirectionTC ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "The direction of data flow on an Label Switched Path (LSP)
+ segment with respect to the head of the LSP.
+
+ Where an LSP is signaled using a conventional signaling
+ protocol, the 'head' of the LSP is the source of the signaling
+ (also known as the ingress) and the 'tail' is the destination
+ (also known as the egress). For unidirectional LSPs, this
+ usually matches the direction of flow of data.
+
+ For manually configured unidirectional LSPs, the direction of
+ the LSP segment matches the direction of flow of data. For
+ manually configured bidirectional LSPs, an arbitrary decision
+ must be made about which LER is the 'head'."
+ SYNTAX INTEGER {
+ forward(1), -- data flows from head-end of LSP toward tail-end
+ reverse(2) -- data flows from tail-end of LSP toward head-end
+ }
+
+ END
+
+4. Security Considerations
+
+ This module does not define any management objects. Instead, it
+ defines a set of textual conventions which may be used by other GMPLS
+ MIB modules to define management objects.
+
+ Meaningful security considerations can only be written in the MIB
+ modules that define management objects. Therefore, this document has
+ no impact on the security of the Internet.
+
+
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 5]
+
+RFC 4801 TCs for GMPLS Management February 2007
+
+
+5. IANA Considerations
+
+ IANA has rooted MIB objects in this MIB module under the mplsStdMIB
+ subtree by assigning an OID to gmplsTCStdMIB.
+
+ IANA has made the following assignments in the "NETWORK MANAGEMENT
+ PARAMETERS" registry located at http://www.iana.org/assignments/smi-
+ numbers in table:
+
+ ...mib-2.transmission.mplsStdMIB (1.3.6.1.2.1.10.166)
+
+ Decimal Name References
+ ------- ----- ----------
+ 12 GMPLS-TC-STD-MIB [RFC4801]
+
+ In the future, GMPLS-related standards-track MIB modules should be
+ rooted under the mplsStdMIB (sic) subtree. IANA has been requested
+ to manage that namespace in the SMI Numbers registry [RFC3811]. New
+ assignments can only be made via a Standards Action as specified in
+ [RFC2434].
+
+6. References
+
+6.1. 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
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+ "Structure of Management Information Version 2 (SMIv2)",
+ STD 58, RFC 2578, April 1999.
+
+ [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual
+ Conventions for SMIv2", STD 58, RFC 2579, April 1999.
+
+ [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+ "Conformance Statements for SMIv2", STD 58, RFC 2580, April
+ 1999.
+
+ [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
+ (GMPLS) Signaling Functional Description", RFC 3471,
+ January 2003.
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 6]
+
+RFC 4801 TCs for GMPLS Management February 2007
+
+
+ [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual
+ Conventions (TCs) for Multiprotocol Label Switching (MPLS)
+ Management", RFC 3811, June 2004.
+
+ [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
+ Protocol Label Switching (GMPLS) Extensions for Synchronous
+ Optical Network (SONET) and Synchronous Digital Hierarchy
+ (SDH) Control", RFC 4606, August 2006.
+
+6.2. Informative References
+
+ [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+ "Introduction and Applicability Statements for Internet-
+ Standard Management Framework", RFC 3410, December 2002.
+
+ [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
+ (GMPLS) Architecture", RFC 3945, October 2004.
+
+7. Acknowledgements
+
+ This document is a product of the CCAMP Working Group.
+
+ Special thanks to Joan Cucchiara for her help with compilation issues
+ and her very thorough MIB Doctor review. Thanks also to Lars Eggert,
+ David Harrington, Harrie Hazewinkel, Dan Romascanu, and Bert Wijnen
+ for their review comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 7]
+
+RFC 4801 TCs for GMPLS Management February 2007
+
+
+Contact Information
+
+ Thomas D. Nadeau
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+
+ EMail: tnadeau@cisco.com
+
+
+ Adrian Farrel
+ Old Dog Consulting
+
+ Phone: +44 1978 860944
+ EMail: adrian@olddog.co.uk
+
+
+ Cheenu Srinivasan
+ Bloomberg L.P.
+ 731 Lexington Ave.
+ New York, NY 10022
+
+ Phone: +1-212-617-3682
+ EMail: cheenu@bloomberg.net
+
+
+ Tim Hall
+ Data Connection Ltd.
+ 100 Church Street
+ Enfield, Middlesex
+ EN2 6BQ, UK
+
+ Phone: +44 20 8366 1177
+ EMail: tim.hall@dataconnection.com
+
+
+ Ed Harrison
+ Data Connection Ltd.
+ 100 Church Street
+ Enfield, Middlesex
+ EN2 6BQ, UK
+
+ Phone: +44 20 8366 1177
+ EMail: ed.harrison@dataconnection.com
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 8]
+
+RFC 4801 TCs for GMPLS Management February 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ 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, THE IETF TRUST 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
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ 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
+ such proprietary rights by implementers or users of this
+ 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
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 9]
+