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