[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 04 05 06 07 08 09 10 11 rfc4319                      
Network Working Group                                         C. Sikes
Category: Internet Draft                                      Paradyne
                                                                B. Ray
                                                PESA Switching Systems
                                                            March 2004



         Definitions of Managed Objects for G.SHDSL.BIS Lines
                   draft-ietf-adslmib-gshdslbis-00.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.htmlBIS.TXT.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document defines a portion of the Management Information Base
   (MIB) module for use with network management protocols in the
   Internet community.  In particular, it introduces extensions to
   several objects and textual conventions defined in the HDSL2-SHDSL
   Line MIB (RFC 3276) [RFC3276] to manage a G.SHDSL.bis interface.












Expires September 16, 2004                                      [Page 1]


INTERNET-DRAFT            G-SHDSL-BIS-LINE-MIB                March 2004


Table of Contents

   1.  The Internet-Standard Management Framework . . . . . . . . . .  2
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
       2.1.  Relationship of G.SHDSL.bis to RFC 3276  . . . . . . . .  2
       2.2.  Changes to RFC 3276 Textual Conventions. . . . . . . . .  3
       2.3.  Changes to RFC 3276 Objects  . . . . . . . . . . . . . .  4
       2.4.  Changes to RFC 3276 Compliance Section . . . . . . . . .  6
       2.5.  Updated MIB Location . . . . . . . . . . . . . . . . . .  7
   3.  Implementation Analysis. . . . . . . . . . . . . . . . . . . .  7
   4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  8
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       5.1.  Normative References . . . . . . . . . . . . . . . . . .  8
       5.2.  Informative References . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10

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

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

2.  Overview

   This document describes extensions to several objects and textual
   conventions defined in the HDSL2-SHDSL Line MIB (RFC 3276) [RFC3276]
   to support equivalent management of a G.SHDSL.bis interface.  These
   extensions are based upon the specifications for G.SHDSL.bis
   as defined in the ITU documentation [ITUXXXX].

2.1.   Relationship of G.SHDSL.bis to G.SHDSL

   As discussed in RFC3276, G.SHDSL supports up to two wire pairs in
   a G.SHDSL line.  With G.SHDSL.bis, the ITU has extended the
   specification of G.SHDSL to support an additional two pairs of wires.


Expires September 16, 2004                                      [Page 2]


INTERNET-DRAFT            G-SHDSL-BIS-LINE-MIB                March 2004

   Thus, to support G.SHDSL.bis, several textual conventions and objects
   must have their ranges and enumerations changed.

   A modified version of Figure 2 from RFC3276, section 4.3.1, is below:

    <-- Network Side                            Customer Side -->

    |<///////////// HDSL2/SHDSL/G.SHDSL.bis Span //////////////>|

            <~~~>       <~~~> HDSL2/SHDSL Segments  <~~~>

    +-------+   +-------+   +-------+       +-------+   +-------+
    +       C=1=N       C=1=N       C=..1..=N       C=1=N       +
    | xtuC  |   |  xru1 |   |  xru2 |       |  xru8 |   |  xtuR |
    +       C=2=N       C=2=N       C=..2..=N       C=2=N       +
    |       |   |       |   |       |       |       |   |       |
    +       C=3=N       C=3=N       C=..3..=N       C=3=N       +
    |       |   |       |   |       |       |       |   |       |
    +       C=4=N       C=4=N       C=..4..=N       C=4=N       +
    +-------+   +-------+   +-------+       +-------+   +-------+

    Key:  <////> HDSL2/SHDSL Span
          <~~~~> HDSL2/SHDSL Segment
          =1=    HDSL2/SHDSL wire-pair-1
          =2=    SHDSL optional wire-pair-2 (Not applicable to HDSL2)
          =3=    G.SHDSL.bis optional wire-pair-3 (Not applicable to
                        HDSL2 or SHDSL)
          =4=    G.SHDSL.bis optional wire-pair-4 (Not applicable to
                        HDSL2 or SHDSL)
          C      Customer Side Segment Endpoint (modem)
          N      Network Side Segment Endpoint (modem)

       Figure 1: General topology for an HDSL2/SHDSL/G.SHDSL.bis Line

2.2.  Changes to RFC 3276 Textual Conventions

    The textual convention, Hdsl2ShdslWirePair, is found in RFC3276:

    Hdsl2ShdslWirePair ::= TEXTUAL-CONVENTION
       STATUS    current
       DESCRIPTION
         "This is the referenced pair of wires in a HDSL2/SHDSL Segment.
          HDSL2 only supports a single pair (wirePair1), while SHDSL
          supports an optional second pair (wirePair2)."
       SYNTAX    INTEGER
               {
               wirePair1(1),
               wirePair2(2)
               }

    The introduction of two additional wire pairs on the line leads to
    the following:

Expires September 16, 2004                                      [Page 3]


INTERNET-DRAFT            G-SHDSL-BIS-LINE-MIB                March 2004


    Hdsl2ShdslWirePair ::= TEXTUAL-CONVENTION
       STATUS    current
       DESCRIPTION
         "This is the referenced pair of wires in a HDSL2/SHDSL Segment.
          HDSL2 only supports a single pair (wirePair1), while SHDSL
          supports an optional second pair (wirePair2).  G.SHDSL.bis
          supports optional third and fourth wire pairs (wirePair3
          and wirePair4)."
       SYNTAX    INTEGER
               {
               wirePair1(1),
               wirePair2(2),
               wirePair2(3),
               wirePair2(4)
               }

2.3.  Changes to RFC 3276 Objects

   The addition of two (optional) wire pairs leads to one direct
   and several indirect changes.

2.3.1.   Changes to hdsl2ShdslConfWireInterface

   From RFC3276:

   hdsl2ShdslSpanConfWireInterface OBJECT-TYPE
       SYNTAX      INTEGER
                   {
                   twoWire(1),
                   fourWire(2)
                   }
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
         "This object configures the two-wire or optional four-wire
          operation for SHDSL Lines."
       DEFVAL      { twoWire }
       ::= { hdsl2ShdslSpanConfProfileEntry 2 }

   Two additional enumerations are required to support G.SHDSL.bis.

   hdsl2ShdslSpanConfWireInterface OBJECT-TYPE
       SYNTAX      INTEGER
                   {
                   twoWire(1),
                   fourWire(2),
                   sixWire(3),
                   eightWire(4)
                   }
       MAX-ACCESS  read-create
       STATUS      current

Expires September 16, 2004                                      [Page 4]


INTERNET-DRAFT            G-SHDSL-BIS-LINE-MIB                March 2004

       DESCRIPTION
         "This object configures the number of wire pairs to be used
          in the line.  HDSL2 supports one pair (twoWire), SHDSL lines
          support an optional, addition pair (fourWire), and
          G.SHDSL.bis lines support up to four pairs (sixWire or
          eightWire)."
       DEFVAL      { twoWire }
       ::= { hdsl2ShdslSpanConfProfileEntry 2 }

2.3.2.   Changes to Line Rate Objects

   Four objects in the HDSL2/SHDSL Line MIB have rate limitations.
   In each case, these objects have the syntax

        SYNTAX      Unsigned32(0..4112000)

   Changes introduced in G.SHDSL.bis support an increased upper rate
   of 5696 kbits/s, leading to the updated syntax

        SYNTAX      Unsigned32(0..5696000).

   These objects with updated syntax are listed below:

       hdsl2ShdslStatusMaxAttainableLineRate OBJECT-TYPE
          SYNTAX      Unsigned32(0..5696000)
          UNITS       "bps"
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
          "Contains the maximum attainable line rate in this
          HDSL2/SHDSL span.  This object provides the maximum rate
          the line is capable of achieving.  This is based upon
          measurements made during line probing."
       ::= { hdsl2ShdslSpanStatusEntry 2 }

       hdsl2ShdslStatusActualLineRate OBJECT-TYPE
           SYNTAX      Unsigned32(0..5696000)
           UNITS       "bps"
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
           "Contains the actual line rate in this HDSL2/SHDSL span.
           This should equal ifSpeed."
       ::= { hdsl2ShdslSpanStatusEntry 3 }

       hdsl2ShdslSpanConfMinLineRate OBJECT-TYPE
           SYNTAX      Unsigned32(0..5696000)
           UNITS       "bps"
           MAX-ACCESS  read-create
           STATUS      current
           DESCRIPTION
           "This object configures the minimum transmission rate for

Expires September 16, 2004                                      [Page 5]


INTERNET-DRAFT            G-SHDSL-BIS-LINE-MIB                March 2004

           the associated SHDSL Line in bits-per-second (bps).  If
           the minimum line rate equals the maximum line rate
           (hdsl2ShdslSpanMaxLineRate), the line rate is considered
           'fixed'.  If the minimum line rate is less than the maximum
           line rate, the line rate is considered 'rate-adaptive'."
           DEFVAL      { 1552000 }
       ::= { hdsl2ShdslSpanConfProfileEntry 3 }

       hdsl2ShdslSpanConfMaxLineRate OBJECT-TYPE
           SYNTAX      Unsigned32(0..5696000)
           UNITS       "bps"
           MAX-ACCESS  read-create
           STATUS      current
           DESCRIPTION
           "This object configures the maximum transmission rate for
           the associated SHDSL Line in bits-per-second (bps).  If
           the minimum line rate equals the maximum line rate
           (hdsl2ShdslSpanMaxLineRate), the line rate is considered
           'fixed'.  If the minimum line rate is less than the maximum
           line rate, the line rate is considered 'rate-adaptive'."
           DEFVAL      { 1552000 }
      ::= { hdsl2ShdslSpanConfProfileEntry 4 }

2.4.  Changes to RFC 3276 Compliance Section

    To maintain dual compliance with the existing HDSL2-SHDSL-LINE-MIB,
    the compliance section must be extended.  To accomplish this,
    the objects identified above are restated with their original
    ranges from RFC 3276.

        OBJECT hdsl2ShdslSpanConfWireInterface
           SYNTAX      INTEGER
                       {
                       twoWire(1),
                       fourWire(2)
                       }
           DESCRIPTION
              "An implementation only has to support the range
              as applicable for the original g.shdsl specification."

        OBJECT hdsl2ShdslStatusMaxAttainableLineRate
        SYNTAX      Unsigned32(0..4112000)
           DESCRIPTION
              "An implementation only has to support the range
              as applicable for the original g.shdsl specification."

        OBJECT hdsl2ShdslStatusActualLineRate
        SYNTAX      Unsigned32(0..4112000)
           DESCRIPTION
              "An implementation only has to support the range
              as applicable for the original g.shdsl specification."


Expires September 16, 2004                                      [Page 6]


INTERNET-DRAFT            G-SHDSL-BIS-LINE-MIB                March 2004

        OBJECT hdsl2ShdslSpanConfMinLineRate
        SYNTAX      Unsigned32(0..4112000)
           DESCRIPTION
              "An implementation only has to support the range
              as applicable for the original g.shdsl specification."

        OBJECT hdsl2ShdslSpanConfMaxLineRate
        SYNTAX      Unsigned32(0..4112000)
           DESCRIPTION
              "An implementation only has to support the range
              as applicable for the original g.shdsl specification."

2.5.  Updated MIB Location

    A version of the MIB object definitions found in RFC3276 modified
    to contain the above changes is available at:

           www.ietf.org/internet-drafts/SHDSL-BIS-LINE-MIB.mib

3.  Implementation Analysis

   A management application which supports RFC3276 could mistakenly
   flag a unit which responds with a rate or wire pair which exceeds
   the ranges and/or enumerations specified in RFC3276.  For example,
   a G.SHDSL.bis line with four wire pairs would report statistics
   for wire pairs that do not exist in RFC3276.  That is, a GET-NEXT
   request issued with the object identifier:

        hdsl2ShdslEndpointCurrAtn.1.1.1.2

   might return

        hdsl2ShdslEndpointCurrAtn.1.1.1.3 = 0

   with a G.SHDSL.bis unit and

        hdsl2ShdslEndpointCurrSnrMgn.1.1.1.1 = 0

   with an HDSL2 unit as these objects are indexed by

       INDEX  { ifIndex, hdsl2ShdslInvIndex, hdsl2ShdslEndpointSide,
                hdsl2ShdslEndpointWirePair }

   A management application which intends to manage G.SHDSL.bis
   agents, should be modified to accept this sequence.

   One should note that this same unmodified management application
   is still capable of managing G.SHDLS.bis agents albiet to the
   degree of G.SHDSL (non-bis) limitations.  That is, it can create
   and monitor configurations limited to two wire pairs with an
   upper rate limit of 4112000 bits/second.


Expires September 16, 2004                                      [Page 7]


INTERNET-DRAFT            G-SHDSL-BIS-LINE-MIB                March 2004

4.  Security Considerations

   In addition to the security considerations presented in RFC3276,
   it is conceivable that a management application could be broken
   by a G.SHDSL.bis agent which reports objects for additional
   wire pairs (as noted in section 3).

   For example, if a management application blindly loaded object
   instances into an array until the an object changes (during
   repeated GET-NEXT requests).   It is anticipated that the
   modifications to the management application code would be
   straightforward.  Perhaps, of the form:

                if (name[12] > 2)   reject();

   or

                if (*val > 4112000) reject();

5.  References

5.1.  Normative References

   [ITUXXXX]   ITU-T G.shdsl.bis, October 2003.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3276]   Ray, B., and R. Abbi, "Definitions of Managed Objects
               for High Bit-Rate DSL - 2nd generation (HDSL2) and
               Single-Pair High-Speed Digital Subscriber Line (SHDSL)
               Lines", RFC 3276, May 2002.

   [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for Describing Simple Network Management
               Protocol (SNMP) Management Frameworks", RFC 3411,
               December 2002.

   [RFC3418]   Presuhn, R., "Management Information Base (MIB) for the

Expires September 16, 2004                                      [Page 8]


INTERNET-DRAFT            G-SHDSL-BIS-LINE-MIB                March 2004

               Simple Network Management Protocol (SNMP)", STD 62, RFC
               3418, December 2002.

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

   [RFC3415]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3415, December
               2002.

6.  Acknowledgements

   Matt Beanland (Extel)

   Steve Turner (IBEC)

   Bert Wijnen (Lucent)

7.  Authors' Addresses

   Clay Sikes
   Paradyne Corporation
   8545 126th Ave. N.
   Largo, FL 33773
   USA

   Phone: +1 727 530 8257
   Fax:   +1 727 532 5698
   EMail: csikes@paradyne.com

   Bob Ray
   PESA Switching Systems, Inc.
   330-A Wynn Drive
   Huntsville, AL 35805
   USA

   Phone: +1 256 726 9200 ext.  142
   Fax: +1 256 726 9271
   EMail: rray@pesa.com










Expires September 16, 2004                                      [Page 9]


INTERNET-DRAFT            G-SHDSL-BIS-LINE-MIB                March 2004

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















Expires September 16, 2004                                     [Page 10]