[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

IP over InfiniBand
Internet Draft                                           Hal Rosenstock
draft-ietf-ipoib-ibmib-tc-mib-08.txt                     HNR Consulting
Expires: December 2006                                        June 2006


                    Definitions of Textual Conventions
                         and OBJECT-IDENTITIES for
                 IP Over InfiniBand (IPOVERIB) Management

                  <draft-ietf-ipoib-ibmib-tc-mib-08.txt>


Status of this Memo
   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.


Abstract

   This memo defines a Management Information Base (MIB) module that
   contains Textual Conventions and OBJECT-IDENTITIES for use in
   definitions of management information for IP Over InfiniBand
   (IPOVERIB) networks.  The intent is that these TEXTUAL
   CONVENTIONs (TCs) will be imported and used in IPOVERIB related
   MIB modules.


Copyright Notice

   Copyright (C) The Internet Society (2006).



Rosenstock              Expires December 2006                [Page 1]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


Table of Contents

   1. Introduction...................................................3
   2. The Internet-Standard Management Framework.....................3
   3. IPOVERIB Textual Conventions MIB Definitions...................4
   4. Security Considerations.......................................12
   5. IANA Considerations...........................................12
   6. Revision History..............................................12
      6.1 Changes from <draft-ietf-ipoib-ibmib-tc-mib-07.txt>.......12
   7. References....................................................12
      7.1 Normative References......................................13
      7.2 Informative References....................................13
   8. Acknowledgements..............................................13
   9. Author's Address..............................................13
   10. Intellectual Property Notice.................................14
   11. Full Copyright Statement.....................................14



































Rosenstock              Expires December 2006                [Page 2]


Internet-Draft          IPOVERIB TC MIB Module               June 2006



1. Introduction

   This memo defines a portion of the Management Information Base for
   use with network management protocols in the Internet community.
   In particular, it defines Textual Conventions used in IETF IPOVERIB
   and IPOVERIB-related MIBs.

   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 [RFC2119].

   For an introduction to the concepts of InfiniBand, see [IBTAARCH].

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].























Rosenstock              Expires December 2006                [Page 3]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


3. IPOVERIB Textual Conventions MIB Definitions

   IB-TC-MIB DEFINITIONS ::= BEGIN

   IMPORTS
          experimental, MODULE-IDENTITY, Unsigned32
             FROM SNMPv2-SMI                           -- [RFC 2578]

          TEXTUAL-CONVENTION
             FROM SNMPv2-TC;                           -- [RFC 2579]

   ibTcMIB MODULE-IDENTITY
       LAST-UPDATED "200606270000Z"  -- 27 June 2006 00:00:00 GMT
       ORGANIZATION
                    "IETF IP over IB (IPOIB) Working Group"
       CONTACT-INFO
                    "Hal Rosenstock
             Postal: HNR Consulting
                     200 Old Harvard Road
                     Boxboro MA 01719-1834
                     United States
             Email:  hnrose@earthlink.net

             Email comments to the IPOIB WG Mailing List at
             ipoverib@ietf.org."
       DESCRIPTION
          "Copyright (C) The Internet Society (2006).  The initial
           version of this MIB module was published in RFC XXXX; for
           full legal notices see the RFC itself.  Supplementary
           information may be available on
           http://www.ietf.org/copyrights/ianamib.html.

           This MIB contains managed object definitions and textual
           conventions for managing InfiniBand devices that support
           the IP Over InfiniBand (IPOIB) protocols and procedures."

       REVISION
            "200606270000Z"  -- 27 June 2006 00:00:00 GMT
       DESCRIPTION
            "Initial version published as part of RFC XXXX."
       ::= { infinibandMIB 1 }

   -- The IANA has currently defined the InfiniBand MIB on the
   -- experimental branch.

   infinibandMIB OBJECT IDENTIFIER ::= { experimental 117 }
   -- This object identifier needs to be reassigned by IANA.
   -- Since infiniband has been assigned an ifType of 199 a
   -- recommendation is made that this OID be 199 as well, e.g.


Rosenstock              Expires December 2006                [Page 4]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


   --   ::= { transmission 199 }
   --
   -- The updated Object Identifier definition would be:
   --
   -- infinibandMIB OBJECT IDENTIFIER ::= { transmission 199 }
   --


   -- Textual Conventions.

   IbPort ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION
          "Identifies an InfiniBand (IB) Port.  The InfiniBand
           Architecture (IBA) defines a maximum of 254 physical ports
           numbered Port 1 to Port 254.  A port is the location on a
           Channel Adapter, IB Router, or IB Switch to which a link is
           connected.  If a device has N ports, the physical ports are
           always numbered from 1 to N.  The relationship between an
           InfiniBand port and an ifIndex is one-to-one.  As such, the
           value of an ifIndex object instance can be directly used to
           identify corresponding instances of the objects defined
           herein as IB ports.  Note: this definition does include
           enhanced switch port 0 but not base switch port 0. In the
           case of a switch with enhanced switch port 0, the ifIndex is
           offset by 1 from the ibPort. In all other cases, the ifIndex
           is identical to the ibPort."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 18.2.4.1 (C18-10.a1) for switches and (C18-14.a1)
            for switch port 0, Section 17.2.1.3 (C17-7.a1) for Channel
            Adapters, and Section 19.2.4.2 for routers."
       SYNTAX Unsigned32 (0..254)

   IbPhysPort ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION
          "Identifies a physical InfiniBand (IB) Port.  The InfiniBand
           Architecture (IBA) defines a maximum of 254 physical ports
           numbered Port 1 to Port 254.  A port is the location on a
           Channel Adapter, IB Router, or IB Switch to which a link is
           connected.  If a device has N ports, the ports are always
           numbered from 1 to N.  Note: this definition does NOT include
           switch Port 0, which is not a physical port."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3


Rosenstock              Expires December 2006                [Page 5]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


            (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for
            routers."
       SYNTAX Unsigned32 (1..254)

   IbPhysPortAndInvalid ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION
          "Identifies a physical IB port plus an invalid port number.
           The invalid port number has a value of 255.  Note: this
           definition does NOT include switch logical Port 0, which is
           not a physical port."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3
            (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for
            routers."
       SYNTAX Unsigned32 (1..255)

   IbDataPort ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      deprecated
       DESCRIPTION
          "Identifies a physical InfiniBand (IB) Port.  The InfiniBand
           Architecture (IBA) defines a maximum of 254 physical ports
           numbered Port 1 to Port 254.  A port is the location on a
           Channel Adapter, IB Router, or IB Switch to which a link is
           connected.  If a device has N ports, the ports are always
           numbered from 1 to N.  The relationship between an InfiniBand
           port and an ifIndex is one-to-one.  As such, the value of an
           ifIndex object instance can be directly used to identify
           corresponding instances of the objects defined herein as IB
           data ports.  Note: this definition does NOT include logical
           Port 0, which is reserved for IB management packets."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3
            (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for
            routers."
       SYNTAX Unsigned32 (1..254)

   IbDataPortAndInvalid ::= TEXTUAL-CONVENTION
       STATUS      deprecated
       DESCRIPTION
          "Identifies a physical IB port plus an invalid port number.
           The invalid port number has a value of 255.  Note: this
           definition does NOT include logical Port 0, which is reserved
           for IB management packets."
       REFERENCE


Rosenstock              Expires December 2006                [Page 6]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3
            (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for
            routers."
       SYNTAX Unsigned32 (1..255)

   IbVirtualLane ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION
          "Identifies a Virtual Lane (VL) instance on a given interface
           (i.e., IB port).  VLs provide a mechanism for creating
           multiple virtual links within a physical link.  IBA defines
           VL 0 through VL 14 for data and VL 15 exclusively for Subnet
           Management.  The actual data VLs that a port uses are
           configured by the Subnet Manager.  The default data VL is
           always VL 0."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 3.5.7."
       SYNTAX Unsigned32 (0..15)

   IbDataVirtualLane ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION
          "Identifies a Data Virtual Lane instance on a given interface
           (i.e., IB port).  This TC definition excludes the management
           Virtual Lane (VL 15).  The actual data VLs that a port uses
           are configured by the Subnet Manager.  The default data VL is
           always the first VL (VL 0)."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 3.5.7."
       SYNTAX Unsigned32 (0..14)

   IbDlid ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION
          "Identifies the Destination Local Identifier (DLID).  The IBA
           defines LID 0 as reserved and valid Local Identifier (LID)
           values from 1 to 65535.  LID 65535 is defined as a permissive
           DLID.

           This value is stored in IBA defined bit order, that is, the
           high-order bit of the Local Identifier byte 0 is positioned
           as the high-order bit of the first byte of the integer
           representation."


Rosenstock              Expires December 2006                [Page 7]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 4.1.3."
       SYNTAX Unsigned32 (0..65535)

   IbUnicastLid ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION
          "Identifies a Unicast LID.  Value is stored in IBA defined bit
           order, that is, the high-order bit of the Local Identifier
           byte 0 is positioned as the high-order bit of the first byte
           of the integer representation."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 4.1.3."
       SYNTAX Unsigned32 (0..49151)

   IbMulticastLid ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION
          "Identifies a Multicast LID.  Value is stored in IBA defined
           bit order, that is, the high-order bit of the Local
           Identifier byte 0 is positioned as the high-order bit of the
           first byte of the integer representation."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 4.1.3."
       SYNTAX Unsigned32 (49152..65535)

   IbGuid ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "1x:"
       STATUS      current
       DESCRIPTION
          "Globally Unique Identifier (GUID) is a number that uniquely
           identifies an IB device or component.  It is a compliant
           IEEE-defined 64-bit extended unique identifier (EUI-64)
           for Host Channel Adapters (HCA), Terminal Channel Adpaters
           (TCA), routers, and switches.  This 64-bit value is created
           by concatenating a 24-bit company ID value and a 40-bit
           extension.  The IEEE Registration Authority assigns the
           company ID. The extension ID is assigned by the particular
           company.  Each HCA, TCA, switch, and router as well as each
           endport shall be assigned an EUI-64 GUID by the
           manufacturer."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 4.1."


Rosenstock              Expires December 2006                [Page 8]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


       SYNTAX OCTET STRING (SIZE(8))

   IbSmaPortList ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
          "Each bit mapping within this value specifies a port presence
           within the managed IB device.  This definition includes bit0
           as IB Port 0, the switch management port.  Valid physical
           port mappings are from bit1 to bit254.  Bit255 is invalid
           and MUST always be zero."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 18.2.4.1 (C18-10.a1) for switches and (C18-14.a1)
            for switch port 0, Section 17.2.1.3 (C17-7.a1) for Channel
            Adapters, and Section 19.2.4.2 for routers."
       SYNTAX OCTET STRING (SIZE(32))

   IbSmPortList ::= TEXTUAL-CONVENTION
       STATUS       deprecated
       DESCRIPTION
          "Each bit mapping within this value specifies a port presence
           within the managed IB device.  This definition includes bit0
           as IB Port 0, the logical port used exclusively for
           management packets. Valid data port mappings are from bit1 to
           bit254.  Bit255 is invalid and MUST always be zero."
       REFERENCE
           "InfiniBand Architecture Release 1.2 Vol. 1. [IBTAARCH]
            Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3
            (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for
            routers."
       SYNTAX OCTET STRING (SIZE(32))

   IbIpoibClientIdentifier ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
          "The IPOIB Client Identifier uniquely identifies an IPOIB link
           layer address associated with the InfiniBand port.  It
           comprises three fields.
              1. Global Identifier (GID)
              2. Queue Pair Number field (QPN)
              3. reserved

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1:GID(0-7)     |2:GID(8-15)    |3:GID(16-23)   |4:GID(24-31)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |5:GID(32-39)   |6:GID(40-47)   |7:GID(48-55)   |8:GID(56-63)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Rosenstock              Expires December 2006                [Page 9]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


       |9:GID(64-71)   |10:GID(72-79)  |11:GID(80-87)  |12:GID(88-95)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |13:GID(96-103) |14:GID(104-111)|15:GID(112-119)|16:GID(120-127)|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |17:QPN(0-7)    |18:QPN(8-15)   |19:QPN(16-23)  |20:(reserved)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           The Global Identifier field is a 16 octet field (octets 1
           through 16) that is formed by the combination of the IB
           subnet prefix and the port's GUID.  It is unique in the
           InfiniBand fabric.  NOTE: An IPOIB interface may have more
           than 1 GID associated with it.

           The Queue Pair Number field is a 3 octet field (octets 17,
           18, & 19) that identifies the destination queue pair.  Note:
           The reserved field and the QPN field are collectively
           referred to as the interface-id.  If an IPOIB interface has
           only 1 GID associated with it, the interface-id MAY contain
           all zeroes.

           The reserved field is octet 20.  It is reserved for future
           use.  These bits SHOULD be set to zero."
       SYNTAX OCTET STRING (SIZE(20))

   IbSmSubnetPrefix ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "2x:"
       STATUS      current
       DESCRIPTION
          "The 64-bit value used to identify an InfiniBand subnet."
       SYNTAX OCTET STRING (SIZE(8))

   IbSmState ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
          "Subnet Manager's state:
              notActive(0)    SM is not active
              discovering(1)  SM is discovering subnet
              standby(2)      SM is in standby role
              master(3)       SM is in master role."
       SYNTAX INTEGER   {
                  notActive(0),
                  discovering(1),
                  standby(2),
                  master(3)
               }

   IbNodeType ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION


Rosenstock              Expires December 2006               [Page 10]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


          "Type of InfiniBand node."
       SYNTAX INTEGER   {
                  unknown(0),
                  channelAdapter(1),
                  switch(2),
                  router(3)
              }

   IbMtu ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
          "The MTU size of this InfiniBand link."
       SYNTAX INTEGER   {
                  mtu256(1),
                  mtu512(2),
                  mtu1024(3),
                  mtu2048(4),
                  mtu4096(5)
              }

   IbPartitionKey ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "x"
       STATUS      current
       DESCRIPTION
          "The 16-bit Partition Key."
       SYNTAX Unsigned32 (0..65535)

   IbPartition ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "x"
       STATUS      current
       DESCRIPTION
          "The 15-bit Partition Key Base (without the membership bit)."
       SYNTAX Unsigned32 (0..32767)

   IbTransportTime ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
          "The time value used to calculate the InfiniBand network
           delay or response.  The duration of time is calculated
           by the following formula:
           delay/response = (4.096 microseconds * 2 ^ IbTransportTime)."
       SYNTAX Unsigned32 (0..31)

   END







Rosenstock              Expires December 2006               [Page 11]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


4. Security Considerations

   This memo defines textual conventions and object identities for use
   in IPOVERIB MIB modules. Security issues for these MIB modules are
   addressed in the memos defining those modules.  Because this memo
   does not define management objects, the memo has no impact on the
   security of the Internet.


5. IANA Considerations

   IANA is requested to make a MIB OID assignment under the transmission
   branch, that is, assign the infinibandMIB under { transmission 199 }.
   This sub-id is requested because 199 is the ifType for
   infiniband(199) and is available under transmission.

   In the future, IPOIB related standards track MIB modules should be
   rooted under the infinibandMIB subtree.  The IANA is requested to
   manage that namespace.  New assignments can only be made via a
   Standards Action as specified in [RFC2434].

   This document also requests IANA to assign { infinibandMIB 1 } to the
   IB-TC-MIB specified in this document.


6. Revision History

   This section should be removed when this document is published as an
   RFC.

6.1 Changes from <draft-ietf-ipoib-ibmib-tc-mib-07.txt>

   Added IbPort, IbPhysPort, and IbPhysPortAndInvalid and deprecated
   IbDataPort and IbDataPortAndInvalid

   Added IbSmaPortList and deprecated IbSmPortList

   Added IbPartition

   Updated to InfiniBand Architecture Revision 1.2 from 1.1

   Resolved nits with <draft-ietf-ipoib-ibmib-tc-mib-07.txt>

   Added revision history


7. References




Rosenstock              Expires December 2006               [Page 12]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


7.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., 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.

   [IBTAARCH] InfiniBand Architecture Specification Volume 1,
              Release 1.2, October, 2004, Final Release.


7.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.


8. Acknowledgements

   This MIB module was updated based on the original work done by Sean
   Harnedy. Bill Anderson, and Bill Strahm.


9. Author's Address

   Hal Rosenstock
   HNR Consulting
   200 Old Harvard Road
   Boxboro, MA 01719-1834
   USA
   Email: hnrose@earthlink.net



Rosenstock              Expires December 2006               [Page 13]


Internet-Draft          IPOVERIB TC MIB Module               June 2006



10. Intellectual Property Notice

   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.



11. Full Copyright Statement

   Copyright (C) The Internet Society (2006).
   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.

   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


Rosenstock              Expires December 2006               [Page 14]


Internet-Draft          IPOVERIB TC MIB Module               June 2006


   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.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

































Rosenstock              Expires December 2006               [Page 15]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/