RFC 5542

Definitions of Textual Conventions for Pseudowire (PW) Management

πŸ“… published May 2009, from ietf

RFC 5542 πŸŽ€ Definitions of Textual Conventions for Pseudowire (PW) Management

okay bestie, so this is RFC 5542 πŸ’–, called Definitions of Textual Conventions for Pseudowire (PW) Management. It's a Standards Track document from May 2009 🌸, and it came from the Network Working Group. Three editors wrote it: T. Nadeau (BT), D. Zelig (Oversi), and O. Nicklass (RADVISION) ✨. Nothing in its header says it obsoletes or updates another RFC, so it's standing on its own πŸ’….


Status of This Memo ✨

This document is a standards track protocol spec for the Internet community πŸ¦‹. It's asking for discussion and suggestions for improvements πŸ’¬. For the current standardization state and status of this protocol, go check the latest edition of the "Internet Official Protocol Standards" (STD 1) πŸ“š. Distribution of this memo is unlimited 🌈.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved πŸ’œ.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which are in effect on the date this document was published. You can find them at http://trustee.ietf.org/license-info. Please read these carefully, because they describe your rights and restrictions for this document πŸ™ˆ.

This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🧚. The person or people who control the copyright in some of that material might not have given the IETF Trust permission to allow changes to it outside the IETF Standards Process 😭. Without getting a proper license from whoever controls the copyright in that material, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🫢.

Abstract πŸ¦‹

This memo defines a Management Information Base (MIB) module that has textual conventions (TCs) for representing commonly used pseudowire (PW) management information πŸ“. The goal is for these TCs to be imported and used by PW-related MIB modules, which would otherwise have to define their own representations πŸ”₯.

Table of Contents 🌸

   1. Introduction ....................................................2
   2. The Internet-Standard Management Framework ......................2
   3. Conventions Used in This Document ...............................2
   4. Object Definitions ..............................................3
   5. Security Considerations .........................................9
   6. IANA Considerations .............................................9
   7. References .....................................................10
      7.1. Normative References ......................................10
      7.2. Informative References ....................................10

1. Introduction πŸ’–

This memo defines a piece of the Management Information Base (MIB) for network management protocols used in the Internet community 🌐. Specifically, it defines the textual conventions used for pseudowire (PW) technology and for Pseudowire Edge-to-Edge Emulation (PWE3) MIB modules ✨.

2. The Internet-Standard Management Framework πŸŽ€

If you want a detailed overview of the documents that describe the current Internet-Standard Management Framework, check out section 7 of RFC 3410 [RFC3410] πŸ“–.

Managed objects are accessed through a virtual information store called the Management Information Base, or MIB 🧚. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP) πŸ’œ. Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI) 🌈. This memo specifies a MIB module that is compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580] πŸ‘‘.

3. Conventions Used in This Document πŸ¦‹

Okay, the BCP 14 key words are the important ones here πŸ”₯. 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 [RFC2119] πŸ’….

4. Object Definitions ✨

okay so this is the actual MIB module, the bit where everything gets defined πŸŽ€ it's a whole PW-TC-STD-MIB module that imports stuff from SNMPv2-SMI and SNMPv2-TC, and then it's basically a big drawer of textual conventions for pseudowire stuff. the module's own metadata is up top (who wrote it, when, the legal boilerplate), and then each convention gets its own little definition, from PwGroupID all the way down to PwCfgIndexOrzero 🧚

   PW-TC-STD-MIB DEFINITIONS ::= BEGIN

   IMPORTS
      MODULE-IDENTITY, Unsigned32, mib-2
         FROM SNMPv2-SMI               -- [RFC2578]

      TEXTUAL-CONVENTION
         FROM SNMPv2-TC;               -- [RFC2579]

   pwTcStdMIB MODULE-IDENTITY
      LAST-UPDATED "200904210000Z"  -- 21 April 2009 00:00:00 GMT
      ORGANIZATION "Pseudowire Edge-to-Edge Emulation (PWE3) Working
                    Group"
      CONTACT-INFO
      " Thomas D. Nadeau
        Email:  tom.nadeau@bt.com

        David Zelig
        Email: davidz@oversi.com

        Orly Nicklass
        Email: orlyn@radvision.com

        The PWE3 Working Group (email distribution pwe3@ietf.org,
        http://www.ietf.org/html.charters/pwe3-charter.html)
       "

      DESCRIPTION
         "This MIB module defines TEXTUAL-CONVENTIONS
         for concepts used in pseudowire edge-to-edge
         networks.

         Copyright (c) 2009 IETF Trust and the persons identified
         as authors of the code.  All rights reserved.

         Redistribution and use in source and binary forms, with or
         without modification, are permitted provided that the following
         conditions are met:

         - Redistributions of source code must retain the above
           copyright notice, this list of conditions and the following
           disclaimer.

         - Redistributions in binary form must reproduce the above
           copyright notice, this list of conditions and the following
           disclaimer in the documentation and/or other materials
           provided with the distribution.

         - Neither the name of Internet Society, IETF or IETF Trust, nor
           the names of specific contributors, may be used to endorse or
           promote products derived from this software without specific
           prior written permission.

         THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
         CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
         INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
         MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
         DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
         CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
         SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
         NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
         LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
         HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
         CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
         OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
         EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

         This version of this MIB module is part of RFC 5542;
         see the RFC itself for full legal notices."

      -- Revision history.

      REVISION "200904210000Z"  -- 21 April 2009 00:00:00 GMT
      DESCRIPTION
           "Original Version"
         ::= { mib-2 188 }

   PwGroupID ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS      current
      DESCRIPTION
           "An administrative identification for grouping a
            set of service-specific pseudowire services."
      SYNTAX  Unsigned32

   PwIDType ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS      current
      DESCRIPTION
           "Pseudowire Identifier.  Used to identify the PW
            (together with some other fields) in the signaling
            session."
      SYNTAX  Unsigned32

   PwIndexType ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS      current
      DESCRIPTION
           "Pseudowire Index.  A unique value, greater than zero,
           for each locally defined PW.  Used for indexing
           several MIB tables associated with the particular PW.
           It is recommended that values are assigned contiguously
           starting from 1.  The value for each PW MUST remain
           constant at least from one re-initialization
           to the next re-initialization."
      SYNTAX  Unsigned32 (1..4294967295)

   PwIndexOrZeroType ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS      current
      DESCRIPTION
           "This TEXTUAL-CONVENTION is an extension of the
            PwIndexType convention.  The latter defines a greater-
            than-zero value used to identify a pseudowire
            in the managed system.  This extension permits the
            additional value of zero.  The zero value is object-specific
            and MUST therefore be defined as part of the description of
            any object that uses this syntax.  Examples of the usage of
            zero might include situations where pseudowire was unknown,
            or where none or all pseudowires need to be referenced."
       SYNTAX  Unsigned32 (0..4294967295)

   PwOperStatusTC ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
        "Indicates the operational status of the PW.

        - up(1):             Ready to pass packets.
        - down(2):           PW signaling is not yet finished, or
                             indications available at the service
                             level indicate that the PW is not
                             passing packets.
        - testing(3):        AdminStatus at the PW level is set to
                             test.

        - dormant(4):        The PW is not in a condition to pass
                             packets but is in a 'pending' state,
                             waiting for some external event.
        - notPresent(5):     Some component is missing to accomplish
                             the setup of the PW.  It can be
                             configuration error, incomplete
                             configuration, or a missing H/W component.
        - lowerLayerDown(6): One or more of the lower-layer interfaces
                             responsible for running the underlying PSN
                             is not in OperStatus 'up' state."
    SYNTAX   INTEGER {
        up(1),
        down(2),
        testing(3),
        dormant(4),
        notPresent(5),
        lowerLayerDown(6)
        }

   PwAttachmentIdentifierType ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
         "An octet string used in the generalized Forward Error
          Correction (FEC) element for identifying attachment forwarder
          and groups.  A NULL identifier is of zero length.
         "
     SYNTAX    OCTET STRING (SIZE (0..255))

   PwGenIdType ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
         "Represents the Attachment Group Identifier (AGI) Type and
          Attachment Individual Identifier (AII) Type in generalized FEC
          signaling and configuration.
         "
     SYNTAX    Unsigned32( 0..254 )

   PwCwStatusTC ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
         "Indicates the status of the control word (CW) negotiation
          based on the local configuration and the indications received
          from the peer node.

          waitingForNextMsg(1) indicates that the node is waiting for
          another label mapping from the peer.

          sentWrongBitErrorCode(2) indicates that the local node has
          notified the peer about a mismatch in the C-bit.

          rxWithdrawWithWrongBitErrorCode(3) indicates that a withdraw
          message has been received with the wrong C-bit error code.

          illegalReceivedBit(4) indicates a C-bit configuration with
          the peer that is not compatible with the PW type.

          cwPresent(5) indicates that the CW is present for this PW.
          If signaling is used, the C-bit is set and agreed upon between
          the nodes.  For manually configured PW, the local
          configuration requires the use of the CW.

          cwNotPresent(6) indicates that the CW is not present for this
          PW.  If signaling is used, the C-bit is reset and agreed upon
          between the nodes.  For manually configured PW, the local
          configuration requires that the CW not be used.

          notYetKnown(7) indicates that a label mapping has not yet
          been received from the peer.
         "
      REFERENCE
         "Martini, et al., 'Pseudowire Setup and Maintenance Using
          the Label Distribution Protocol', [RFC4447]."

      SYNTAX    INTEGER {
                 waitingForNextMsg(1),
                 sentWrongBitErrorCode(2),
                 rxWithdrawWithWrongBitErrorCode(3),
                 illegalReceivedBit(4),
                 cwPresent(5),
                 cwNotPresent(6),
                 notYetKnown(7)
                 }

   PwStatus ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
         "Indicates the status of the PW and the interfaces affecting
          this PW.  If none of the bits are set, it indicates no faults
          are reported.
         "

      SYNTAX   BITS {
        pwNotForwarding(0),
        servicePwRxFault(1),
        servicePwTxFault(2),
        psnPwRxFault(3),
        psnPwTxFault(4)
        }

   PwFragSize ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS      current
      DESCRIPTION
         "If set to a value other than zero, it indicates the desired
          fragmentation length in bytes.  If set to zero,
          fragmentation is not desired for PSN bound packets.
         "
      SYNTAX   Unsigned32

   PwFragStatus ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
         "Indicates the status of the fragmentation/reassembly process
          based on local configuration and peer capability.

          noFrag(0) bit indicates that local configuration is for no
          fragmentation.

          cfgFragGreaterThanPsnMtu(1) bit indicates that the local node
          is set to fragment, but the fragmentation size is greater
          than the MTU available at the PSN between the nodes.
          Fragmentation is not done in this case.

          cfgFragButRemoteIncapable(2) bit indicates that the local
          configuration conveys the desire for fragmentation but
          the peer is not capable of reassembly.

          remoteFragCapable(3) bit indicates that the remote node
          is capable to accept fragmented PDUs.

          fragEnabled(4) bit indicates that fragmentation will be used
          on this PW.  Fragmentation can be used if the local node was
          configured for fragmentation, the peer has the capability
          to accept fragmented packets, and the CW is in use for this
          PW."

      REFERENCE
          "Malis, A. and M. Townsley, 'Pseudowire Emulation Edge-to-
           Edge (PWE3) Fragmentation and Reassembly', [RFC4623]."

      SYNTAX   BITS {
         noFrag(0),
         cfgFragGreaterThanPsnMtu(1),
         cfgFragButRemoteIncapable(2),
         remoteFragCapable(3),
         fragEnabled(4)
         }

   PwCfgIndexOrzero ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS      current
      DESCRIPTION
           "Index in any of the relevant configuration tables for
           supplement information regarding configuration of the
           specific technology.  Value zero implies no additional
           configuration information is applicable."
      SYNTAX  Unsigned32 (0..4294967295)
   END

5. Security Considerations πŸ’€

okay this one's short but it's SO important, so listen up πŸ‘‘ this module doesn't define any management objects at all. what it does instead is define a set of textual conventions that other PWE3 MIB modules can use when they go define their management objects 🫢

meaningful security considerations can only be written in the MIB modules that actually define management objects. so this document, on its own, has no impact on the security of the Internet. that's the whole thing, bestie, the security story lives in the modules that use these conventions, not here πŸ”’βœ¨

6. IANA Considerations ✨

okay bestie, IANA stuff time πŸŽ€ the MIB module in this document uses one OBJECT IDENTIFIER value that's already been assigned by IANA and recorded in the SMI Numbers registry πŸ¦‹ it's giving official paperwork energy, and the value is:

      Descriptor        OBJECT IDENTIFIER value
      ----------        -----------------------
      pwTcStdMIB         { mib-2 188 }

so the descriptor pwTcStdMIB is the one to know, and it lives at { mib-2 188 } πŸ’–

7. References πŸ“š

7.1. Normative References πŸ’…

these are the must-read refs, the ones the doc leans on hard πŸ”₯

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🌸 this is the one that explains the capital-letter key words, so it's literally the reason I've been yelling MUST all over the place 😭

[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. πŸ’œ

[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. πŸ¦‹

[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006. ✨

7.2. Informative References 🌈

this one's more of a "go read this if you want the big picture" vibe 🫢

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. πŸ‘‘

Authors' Addresses πŸŽ€

the people who wrote this, with their contact deets πŸ’…

Thomas D. Nadeau (editor) BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom

EMail: tom.nadeau@bt.com

David Zelig (editor) Oversi Networks 1 Rishon Letzion St. Petah Tikva Israel

Phone: +972 77 3337 750 EMail: davidz@oversi.com

Orly Nicklass (editor) RADVISION 24 Raul Wallenberg Tel Aviv

Phone: +972 3 776 9444 EMail: orlyn@radvision.com


okay that's the whole doc bestie, the authors are the legends who made it happen πŸ«ΆπŸŒˆπŸ’–

πŸ“¦ where this page comes from