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]
