7302 7330 OAM Using CLI

Alcatel-Lucent 7302
INTELLIGENT SERVICES ACCESS MANAGER | RELEASE 3.3.X |

FEATURE GROUP 3.4
Alcatel-Lucent 7330
INTELLIGENT SERVICES ACCESS MANAGER FIBER TO THE NODE |
RELEASE 3.3.X | FEATURE GROUP 3.4
OPERATIONS AND MAINTENANCE USING CLI
3HH-04387-AAAA-TQZZA Edition 02 Released

Alcatel-Lucent assumes no responsibility for the accuracy of the information presented, which is
subject to change without notice.
Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All
other trademarks are the property of their respective owners.
Copyright 2007 Alcatel-Lucent.

All rights reserved.
Disclaimers
Alcatel-Lucent products are intended for commercial uses. Without the appropriate network design
engineering, they must not be sold, licensed or otherwise distributed for use in any hazardous
environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft
navigation or communication systems, air traffic control, direct life-support machines, or weapons
systems, in which the failure of products could lead directly to death, personal injury, or severe physical
or environmental damage. The customer hereby agrees that the use, sale, license or other distribution
of the products for any such application without the prior written consent of Alcatel-Lucent, shall be at
the customer's sole risk. The customer hereby agrees to defend and hold Alcatel-Lucent harmless from
any claims for loss, cost, damage, expense or liability that may arise out of or in connection with the
use, sale, license or other distribution of the products in such applications.
This document may contain information regarding the use and installation of non-Alcatel-Lucent
products. Please note that this information is provided as a courtesy to assist you. While Alcatel-Lucent
tries to ensure that this information accurately reflects information provided by the supplier, please refer
to the materials provided with any non-Alcatel-Lucent product and contact the supplier for
confirmation. Alcatel-Lucent assumes no responsibility or liability for incorrect or incomplete
information provided about non-Alcatel-Lucent products.
However, this does not constitute a representation or warranty. The warranties provided for
Alcatel-Lucent products, if any, are set forth in contractual documentation entered into by
Alcatel-Lucent and its customers.
This document was originally written in English. If there is any conflict or inconsistency between the
English version and any other version of a document, the English version shall prevail.
When printed by Alcatel-Lucent, this document is printed on recycled paper.

Preface
This preface provides general information about the documentation set for the
7302 Intelligent Services Access Manager (7302 ISAM) and the 7330 Intelligent
Services Access Manager Fiber to the Node (7330 ISAM FTTN).
Scope
This documentation set provides information about safety, features and
functionality, ordering, hardware installation and maintenance, CLI and TL1
commands, and software upgrade and migration procedures.
Audience
This documentation set is intended for planners, administrators, operators, and
maintenance personnel involved in installing, upgrading, or maintaining the
7302 ISAM or the 7330 ISAM FTTN.
Prerequisite knowledge
The reader must be familiar with general telecommunications principles.
Safety information
For ETSI safety information, see the 7302 ISAM Safety Manual. For ANSI safety
information, see the Mandatory Regulations chapter in the 7330 ISAM FTTN ANSI
documentation.
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 iii
3HH-04387-AAAA-TQZZA Edition 02 Released Operations and Maintenance Using CLI
Preface
ETSI and ANSI release naming

Table 1 shows the ETSI and ANSI release naming.
Table 1 ETSI and ANSI release naming
Market Release name
ETSI Release 3.3
ANSI Feature Group 3.4
Documents
Table 2 lists the documents that make up the 7302 ISAM Release 3.3 documentation
set.
Table 2 7302 ISAM Release 3.3 documentation set
Title Description Part number
General documentation
Product Information Provides general system information for the 7302 ISAM 3HH-04392-AAAA-TCZZA
System Description Provides conceptual information for the 7302 ISAM and the 3HH-04386-AAAA-TQZZA
7330 ISAM FTTN
Safety Manual Provides general safety guidelines when handling, installing, 3HH-04389-AAAA-TCZZA
or operating the 7302 ISAM equipment
Operations and Maintenance Provides task-oriented procedures for operating and 3HH-04387-AAAA-TQZZA
Using CLI maintaining the 7302 ISAM and 7330 ISAM FTTN using the
CLI
Migration User Guide Provides information for installing or upgrading the 3HH-04391-AAAA-TQZZA
7302 ISAM
Hardware documentation
XD Modular Hardware Describes the hardware installation for the 7302 ISAM XD 3FE-21578-AAAA-RJZZA
Installation Guide Modular equipment
FD Hardware Installation Describes the hardware installation for the 7302 ISAM FD 3FE-03689-AAAA-RJZZA
Guide equipment
UD Hardware Installation Describes the hardware installation for the 7302 ISAM UD 3FE-21575-AAAA-RJZZA
Guide equipment
CLI and TL1 documentation
CLI Commands Describes the CLI commands for the 7302 ISAM and the 3HH-04416-CDAA-TCZZA
7330 ISAM FTTN
TL1 Commands and Describes the TL1 commands and messages for the 3HH-04388-AAAA-TCZZA
Messages 7302 ISAM and the 7330 ISAM FTTN
Software documentation
(1 of 2)
iv June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Operations and Maintenance Using CLI Edition 02 Released 3HH-04387-AAAA-TQZZA
Preface
Software Installation Guide Describes the software management of the 7302 ISAM 3HH-03390-AAAA-RJZZA
equipment
Software Upgrade and Provides instructions for using the automated tools for 3HH-05301-AAAA-TCZZA
Migration Application upgrading and migrating the software for the 7302 ISAM and
Procedures the 7330 ISAM FTTN
(2 of 2)
Table 3 lists the documents that make up the 7330 ISAM FTTN Feature Group 3.4
documentation set.
Table 3 7330 ISAM FTTN Feature Group 3.4 documentation set
Documentation CD
7330 ISAM FTTN CD CD containing all the documents in the 7330 ISAM FTTN 3HH-04090-AAAA
documentation set (1)
General documentation
Product Information Provides general system information, features and 3HH-04087-AAAA-TCZZA

functionality, and hardware unit data sheets for the
7330 ISAM FTTN
System Description Provides conceptual information for the 7302 ISAM and the 3HH-04386-AAAA-TQZZA
7330 ISAM FTTN
Planning and Ordering Provides information for planning and ordering the 3HH-04088-AAAA-TCZZA
7330 ISAM FTTN
Hardware Installation and Provides task-oriented procedures for installing and 3HH-04089-AAAA-TCZZA
Maintenance Practices maintaining the 7330 ISAM FTTN hardware
Operations and Provides task-oriented procedures for operating and 3HH-04387-AAAA-TQZZA

Maintenance Using CLI maintaining the 7302 ISAM and 7330 ISAM FTTN using the
CLI
CLI and TL1 documentation
CLI Commands Describes the CLI commands for the 7302 ISAM and the 3HH-04416-CDAA-TCZZA
7330 ISAM FTTN
TL1 Commands and Describes the TL1 commands and messages for the 3HH-04388-AAAA-TCZZA
Messages 7302 ISAM and the 7330 ISAM FTTN
Software documentation (1)
Software Upgrade and Provides instructions for using the automated tools for 3HH-05301-AAAA-TCZZA
Migration Application upgrading and migrating the software for the 7302 ISAM and
Procedures the 7330 ISAM FTTN
Note
(1) Software documentation is not included on the 7330 ISAM FTTN documentation CD
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 v
Preface
Special information
The following are examples of how special information is presented in this
document.
Danger Danger indicates that the described activity or situation

may result in serious personal injury or death; for example, high
voltage or electric shock hazards.
Warning Warning indicates that the described activity or situation

may, or will, cause equipment damage or serious performance
problems.
Caution Caution indicates that the described activity or situation

may, or will, cause service interruption.
Note A note provides information that is, or may be, of special

interest.
Procedures with options or substeps

When there are options in a procedure, they are identified by letters. When there are
required substeps in a procedure, they are identified by Roman numerals.
Procedure 1 Example of options in a procedure
At step 1, you can choose option a or b. At step 2, you must do what the step indicates.
1 This step offers two options. You must choose one of the following:
a This is one option.
b This is another option.
2 You must perform this step.
vi June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Preface
Procedure 2 Example of required substeps in a procedure
At step 1, you must perform a series of substeps within a step. At step 2, you must do
what the step indicates.
1 This step has a series of substeps that you must perform to complete the step. You
must perform the following substeps:
i This is the first substep.
ii This is the second substep.
iii This is the third substep.
2 You must perform this step.
Measurement conventions
Measurements in this document are expressed in imperial units. If metric
measurements are included, they appear in brackets following the imperial
measurement. The metric measurements follow the Systme international dunits
(SI) standard for abbreviation of metric units.
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 vii
Preface
viii June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Contents
Preface iii
Scope .............................................................................................................................. iii
Audience .............................................................................................................................. iii
Prerequisite knowledge ......................................................................................................... iii
Safety information.................................................................................................................. iii
ETSI and ANSI release naming............................................................................................. iv
Documents ............................................................................................................................ iv
Special information ................................................................................................................ vi
1 Introduction 1-1
1.1 Introduction ........................................................................................................ 1-2
1.2 How to Use this Document ................................................................................ 1-2
1.3 Configuration examples ..................................................................................... 1-5
Index List (IXL)
IXL 100 Master Task Index List IXL 100-1
Non-Trouble Procedures (NTP)
NTP 100 Set up a CLI session and configure users NTP 100-1
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 ix
Contents
NTP 101 Execute script files NTP 101-1
NTP 102 Configure the system NTP 102-1
NTP 103 Configure equipment NTP 103-1
NTP 104 Configure a cross-connect VLAN NTP 104-1
NTP 105 Configure an iBridge VLAN NTP 105-1
NTP 106 Configure an IP-aware bridge NTP 106-1
NTP 107 Configure an IP router NTP 107-1
NTP 108 Configure services NTP 108-1
NTP 109 Configure PPPoE termination NTP 109-1
NTP 110 Add an iBridge user NTP 110-1
NTP 111 Add an IPoA user NTP 111-1
NTP 112 Add an IPoE user NTP 112-1
NTP 113 Add a PPPoE user NTP 113-1
NTP 114 Perform equipment repairs NTP 114-1
NTP 115 Monitor alarms NTP 115-1
NTP 116 Perform software management NTP 116-1
NTP 117 Modify system parameters NTP 117-1
x June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Contents
NTP 118 Monitor performance and view configuration

NTP 118-1
NTP 119 Modify configured services NTP 119-1
NTP 120 Troubleshooting NTP 120-1
NTP 121 Manage an SNMP proxy CPE NTP 121-1
NTP 122 Cluster management NTP 122-1
NTP 123 Secure shell NTP 123-1
NTP 124 Maintain the system NTP 124-1
NTP 125 Add an IPoA cross-connect user NTP 125-1
NTP 126 Manage system logging NTP 126-1
NTP 127 Configure SHDSL NTP 127-1
NTP 128 Manage an IPProxy CPE NTP 128-1
NTP 129 Configure a loopback interface on the SHub NTP 129-1
Detailed Level Procedures (DLP)
DLP 100 Set up a CLI session DLP 100-1
DLP 101 Create operator profiles and instances DLP 101-1
DLP 102 Configure dual IP address DLP 102-1
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 xi
Contents
DLP 103 Configure system parameters DLP 103-1
DLP 104 Configure network interfaces DLP 104-1
DLP 105 Configure link aggregation usage DLP 105-1
DLP 106 Configure RSTP DLP 106-1
DLP 107 Configure OSPF DLP 107-1
DLP 108 Configure RIP DLP 108-1
DLP 109 Configure SNMP and trap management DLP 109-1
DLP 110 Manage alarms DLP 110-1
DLP 111 Plan, replan, and unplan equipment DLP 111-1
DLP 112 Lock and unlock equipment DLP 112-1
DLP 113 Configure the equipment DLP 113-1
DLP 114 Configure NT redundancy DLP 114-1
DLP 115 Create a layer2-terminated forwarder VLAN DLP 115-1
DLP 116 Create a layer2-terminated router VLAN DLP 116-1
DLP 117 Create a C-VLAN DLP 117-1
DLP 118 Create an S-VLAN DLP 118-1
DLP 119 Create an SC-VLAN DLP 119-1
DLP 120 Create an iBridge VLAN DLP 120-1
xii June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Contents
DLP 121 Add network interfaces to a VLAN DLP 121-1
DLP 122 Create a forwarding VRF DLP 122-1
DLP 123 Create a router VRF DLP 123-1
DLP 124 Create an xDSL user DLP 124-1
DLP 125 Create an IPoA user DLP 125-1
DLP 126 Create an IPoE user DLP 126-1
DLP 127 Create a PPPoE user DLP 127-1
DLP 128 Add an LT port to a VLAN DLP 128-1
DLP 129 Create xDSL profiles DLP 129-1
DLP 130 Configure xDSL bonding DLP 130-1
DLP 131 Create an xDSL bonding group DLP 131-1
DLP 132 Configure filtering on SHub DLP 132-1
DLP 133 Configure QoS on layer 2 DLP 133-1
DLP 134 Configure QoS on layer 3 DLP 134-1
DLP 135 Configure a QoS-aware VLAN DLP 135-1
DLP 136 Configure multicast on the LT DLP 136-1
DLP 137 Configure IGMP proxy DLP 137-1
DLP 138 Configure IGMP snooping DLP 138-1
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 xiii
Contents
DLP 139 Configure DHCP relay agent in iBridge mode

DLP 139-1
DLP 140 Configure DHCP relay agent in router mode DLP 140-1
DLP 141 Configure DHCP relay agent in forwarder mode

DLP 141-1
DLP 142 Configure the security domain DLP 142-1
DLP 143 Configure local authentication DLP 143-1
DLP 144 Configure RADIUS DLP 144-1
DLP 145 Configure 802.1x DLP 145-1
DLP 146 Configure PPPoE relay DLP 146-1
DLP 147 Configure PPPoX relay DLP 147-1
DLP 148 Enable the PPPoE server DLP 148-1
DLP 149 Configure PPPoE profiles DLP 149-1
DLP 150 Configure ARP table entry DLP 150-1
DLP 151 Shut down and restart the NT DLP 151-1
DLP 152 Reboot the system DLP 152-1
DLP 153 Shut down and restart individual equipment DLP 153-1
DLP 154 Create a snapshot alarm table DLP 154-1
DLP 155 Monitor alarms DLP 155-1
xiv June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Contents
DLP 156 Management of the SHub database DLP 156-1
DLP 157 Manage the SHub database DLP 157-1
DLP 158 Manage the system database DLP 158-1
DLP 159 Manage OSWP DLP 159-1
DLP 160 View version of the SHub software DLP 160-1
DLP 161 View software licenses counters DLP 161-1
DLP 162 Modify the external management VLAN DLP 162-1
DLP 163 Modifying xDSL profiles DLP 163-1
DLP 164 Ping another host DLP 164-1
DLP 165 Perform a traceroute action DLP 165-1
DLP 166 Configure SNMP proxy CPE management DLP 166-1
DLP 167 Script files DLP 167-1
DLP 168 Modify the system management IP parameters

DLP 168-1
DLP 169 Configure cluster management DLP 169-1
DLP 170 Configure SSH DLP 170-1
DLP 171 Enable EMS management DLP 171-1
DLP 172 Create a default operator profile DLP 172-1
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 xv
Contents
DLP 173 Switching a user from ADSL to VDSL DLP 173-1
DLP 174 Create an IPoA cross-connect user DLP 174-1
DLP 175 Configure single IP address DLP 175-1
DLP 176 Performance monitoring commands DLP 176-1
DLP 177 Configure SFP downlink ports DLP 177-1
DLP 178 Configure the default security domain DLP 178-1
DLP 179 Configure system logging DLP 179-1
DLP 180 Configure static MAC addresses DLP 180-1
DLP 181 Configure operator authentication via RADIUS

DLP 181-1
DLP 182 Configure SHDSL links DLP 182-1
DLP 183 Configure IMA on SHDSL links DLP 183-1
DLP 184 Convert the ISAM IP address DLP 184-1
DLP 185 Configure NACP session DLP 185-1
DLP 186 Configure DHCP MAC concentration in forwarder

mode DLP 186-1
DLP 187 Configure global VLAN parameters DLP 187-1
DLP 188 Configure custom PSD points DLP 188-1
DLP 189 Configure VDSL2 virtual noise values DLP 189-1
xvi June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Contents
DLP 190 Configure threshold crossing alerts DLP 190-1
DLP 191 Enable dual tagging in the SHub DLP 191-1
DLP 192 Configure IPProxy CPE management DLP 192-1
DLP 193 Enable IPProxy CPE management DLP 193-1
DLP 194 Configure IPProxy CPE management session

DLP 194-1
DLP 195 Configure general bridge parameters DLP 195-1
DLP 196 Configure Voice SIP DLP 196-1
DLP 197 View port configuration and operational data

DLP 197-1
DLP 198 Configure multicast on the SHub DLP 198-1
DLP 199 Configure QoS on the SHub DLP 199-1
DLP 200 Configure MSTP DLP 200-1
DLP 201 Configure protocol tracing DLP 201-1
DLP 202 Configure QoS threshold crossing alerts DLP 202-1
DLP 203 Configure general security settings DLP 203-1
DLP 204 Configure an unnumbered IP interface on the

SHub DLP 204-1
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 xvii
Contents
Routine Task Procedure (RTP)
RTP 100 Backup the configuration RTP 100-1
RTP 101 Restore the configuration RTP 101-1
RTP 102 Retrieve remote inventory RTP 102-1
Trouble Analysis Procedure (TAP)
TAP 100 Metallic test access TAP 100-1
TAP 101 F5 loopback test TAP 101-1
TAP 102 Equipment repair TAP 102-1
TAP 103 Single ended line testing TAP 103-1
TAP 104 Fault isolation and troubleshooting TAP 104-1
Training (TNG)
TNG 100 Service installation TNG 100-1
TNG 101 QoS configuration TNG 101-1
TNG 102 IGMP and multicast configuration TNG 102-1
TNG 103 VBAS TNG 103-1
TNG 104 DHCP relay agent configuration TNG 104-1
xviii June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Contents
TNG 105 Overall software packages TNG 105-1
TNG 106 Specifying 7330 ISAM FTTN remote expansion

units using the CLI TNG 106-1
TNG 107 VDSLx parameters TNG 107-1
TNG 108 SHDSL parameters TNG 108-1
TNG 109 Performance management counters TNG 109-1
TNG 110 Configuration examples TNG 110-1
TNG 111 7330 ISAM FTTN ES configuration TNG 111-1
TNG 112 7330 ISAM FTTN configuration for subtending

TNG 112-1
TNG 113 Multi-ADSL parameters TNG 113-1
TNG 114 DLP configuration examples TNG 114-1
TNG 115 Slot numbering schemes TNG 115-1
Glossary
Index
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 xix
Contents
xx June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
1 Introduction
1.1 Introduction 1-2
1.2 How to Use this Document 1-2
1.3 Configuration examples 1-5
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 1-1
1 Introduction
1.1 Introduction
This document provides instructions on CLI operation and maintenance tasks and
procedures for the Alcatel-Lucent 7302 ISAM and the 7330 ISAM FTTN.
These tasks and procedures are identical for the 7302 ISAM and the
7330 ISAM FTTN, unless specified otherwise.
Throughout the document, the 7302 ISAM and the 7330 ISAM FTTN will be
referred to as the Network Element (NE).
See the CLI Commands document for more detailed information about the CLI
command syntax.
1.2 How to Use this Document
This document uses the task-oriented practice (TOP) method. The TOP method is a
documentation system that supports the installation, operation, and maintenance of
telecommunications equipment and software through different layers of
documentation. Most layers in the TOP system are programmed documents that
provide step-by-step instructions for the successful completion of a specific task or
procedure.
A task document is structured to provide information in such a way that both
experienced and inexperienced users can effectively use the material to perform
work assignments. Less-experienced users can refer to detailed step-by-step
procedure documents referred to by the task document to easily comprehend and
complete the task. Experienced users can bypass the procedure documents and use
only the level of information they need to do the task.
TOP layers
The TOP documentation method uses the following layers:
IXL Index List
NTP Non-Trouble Procedure
DLP Detailed Level Procedure
RTL Routine Task List
RTP Routine Task Procedure
TAP Trouble Analysis Procedure
TAD Trouble Analysis Data
TNG Training
Figure 1-1 shows the layers and logical path of the TOP documentation method.
1-2 June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
1 Introduction
Figure 1-1 TOP Layers and Documentation Path
Task index List (IXL) or User Training

Overview Flowchart Package
(TNG)
Non-Trouble
Clearing Procedure Routine Task List
(NTP) (RTL)
Trouble Analysis
Procedure
(TAP)
Routine Task
Procedure
(RTP)
Trouble Analysis
Detailed Level Procedure Data
(DLP) or Chart (TAD)
All layers do not apply to all documents. This document contains only contains the
layers needed to complete operation and maintenance tasks and procedures specific
to the NE through the EMS.
Index List (IXL)

The IXL lists each task and procedure (for example, Log on to the 5526 AMS), along
with related supporting information and the identification number of the
corresponding document (for example, DLP 500). This lets users know where to find
the appropriate documentation.
Non-Trouble Procedure (NTP)

NTPs are procedures that describe how to perform a task (what to do), such as how
to accept a system after it has been installed, turn up a system for service, or maintain
a system according to a maintenance plan. NTPs are made up of steps that refer to
detailed procedures (DLPs) or to supporting information (provided in TNGs). This
allows inexperienced users (or experienced users who want more information) to go
to the DLP or TNG for the additional information they need to complete the task. If
user go to the referenced DLP or TNG, they must return to the NTP to continue the
task.
NTPs are typically referenced from the IXL.
Detailed Level Procedure (DLP)

A DLP describes how to perform a procedure. In addition to step-by-step
information, DLPs contain any tables or illustrations that are required to perform the
procedure.
DLPs can be referenced from the IXL, an NTP, a lower-level TAP, another DLP, or
from a TNG. When a DLP is completed, the user returns to the point from which the
DLP was referenced.
1 Introduction
Routine Task List (RTL)

An RTL provides a listing of routine maintenance procedures (what to do). The
detailed steps for each procedure listed in the RTL are provided in RTPs.
RTLs are typically referenced from the IXL.

An RTP describes how to perform a routine maintenance procedure.
RTPs are typically referenced from an RTL, but references can be made from the
IXL if there is no RTL.

TAPs are intended to help identify and clear trouble in the system. TAPs may be
organized in levels (what and how to do). A high-level TAP is designed to categorize
the trouble through a series of decisions and instructions. Once categorized, a
lower-level TAP is referenced. This lower-level TAP addresses only the isolated
topic and is structured to isolate and clear the trouble through a series of decisions
and instructions without returning to the higher-level TAP. For inexperienced users
(or experienced users who want more information), a TAP may provide a references
to a TAD, DLP, or TNG. If users go to the referenced TAD, DLP, or TNG, they need
to return to the TAP to continue the procedure.
TAPs are typically referenced from the IXL or other TAPs.
Trouble Analysis Data (TAD)

A TAD contains supporting information (other than procedural steps) to be used as
a trouble-clearing aid. It may be a functional schematic, text, or trouble-clearing
chart.
TADs are typically referenced from a TAP.
Training (TNG)
A TNG contains supplementary information about a task or procedure.
TNGs are typically referenced from an IXL, but references are also made from other
TOP layers such as NTPs and DLPs.
Step Procedure Details

NTPs, DLPs, RTPs, and TAPs use procedural steps and decision steps.
Procedural steps provide instructions, and decision steps provide a go-to choice.
Procedural steps may contain notations that refer to additional information such as
notes, tables, figures, examples, and other procedures.
All mandatory information required to complete a step is shown at the beginning of
the step.
1 Introduction
Optional information, which can be accessed according to experience level, is

enclosed in parentheses as shown in the example below:
Log on to the system (for details, see DLP-500).
The completion of a specific task or procedure is indicated as follows:
STOP. This procedure is complete.
1.3 Configuration examples
Configuration examples are provided in the DLPs.

TNG 114 gives a summary of the configuration used in these examples.
1 Introduction
Index List (IXL)
IXL 100 Master Task Index List
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007
June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Table IXL 100-1: Non-Trouble Procedures (NTPs)
Title NTP number
Add a PPPoE user NTP 113
Add an iBridge user NTP 110
Add an IPoA cross-connect user NTP 125
Add an IPoA user NTP 111
Add an IPoE user NTP 112
Cluster management NTP 122
Configure a cross-connect VLAN NTP 104
Configure a loopback interface on the SHub NTP 129

Configure an iBridge VLAN NTP 105
Configure an IP router NTP 107
Configure an IP-aware bridge NTP 106

Configure equipment NTP 103
Configure PPPoE termination NTP 109
Configure services NTP 108
Configure SHDSL NTP 127
Configure the system NTP 102
Execute script files NTP 101
Maintain the system NTP 124
Manage an IPProxy CPE NTP 128
Manage an SNMP proxy CPE NTP 121
Manage system logging NTP 126
(1 of 2)
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 IXL 100-1
Title NTP number
Modify configured services NTP 119
Modify system parameters NTP 117
Monitor alarms NTP 115

Monitor performance and view configuration NTP 118
Perform equipment repairs NTP 114
Perform software management NTP 116
Secure shell NTP 123
Set up a CLI session and configure users NTP 100
Troubleshooting NTP 120
(2 of 2)
Table IXL 100-2: Detailed Level Procedures (DLP)
Title DLP number
Add an LT port to a VLAN DLP 128
Add network interfaces to a VLAN DLP 121
Configure 802.1x DLP 145
Configure a QoS-aware VLAN DLP 135
Configure an unnumbered IP interface on the SHub DLP 204
Configure ARP table entry DLP 150
Configure cluster management DLP 169
Configure custom PSD points DLP 188

Configure DHCP MAC concentration in forwarder mode DLP 186
Configure DHCP relay agent in forwarder mode DLP 141
Configure DHCP relay agent in iBridge mode DLP 139

Configure DHCP relay agent in router mode DLP 140
Configure dual IP address DLP 102
Configure filtering on SHub DLP 132
Configure general bridge parameters DLP 195
Configure general security settings DLP 203
Configure global VLAN parameters DLP 187
Configure IGMP proxy DLP 137
Configure IGMP snooping DLP 138
Configure IMA on SHDSL links DLP 183
Configure IPProxy CPE management DLP 192
Configure IPProxy CPE management session DLP 194
Configure link aggregation usage DLP 105
(1 of 4)
IXL 100-2 June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Title DLP number
Configure local authentication DLP 143
Configure MSTP DLP 200
Configure multicast on the LT DLP 136

Configure multicast on the SHub DLP 198
Configure NACP session DLP 185
Configure NT redundancy DLP 114
Configure operator authentication via RADIUS DLP 181
Configure OSPF DLP 107
Configure PPPoE profiles DLP 149
Configure PPPoE relay DLP 146
Configure PPPoX relay DLP 147
Configure protocol tracing DLP 201

Configure QoS on layer 2 DLP 133
Configure QoS on layer 3 DLP 134
Configure QoS on the SHub DLP 199
Configure QoS threshold crossing alerts DLP 202
Configure RADIUS DLP 144
Configure RIP DLP 108
Configure SFP downlink ports DLP 177
Configure SHDSL links DLP 182
Configure single IP address DLP 175
Configure SNMP and trap management DLP 109

Configure SNMP proxy CPE management DLP 166
Configure SSH DLP 170
Configure static MAC addresses DLP 180

Configure system logging DLP 179
Configure system parameters DLP 103
Configure the default security domain DLP 178
Configure the equipment DLP 113
Configure the security domain DLP 142
Configure threshold crossing alerts DLP 190
Configure VDSL2 virtual noise values DLP 189
Configure Voice SIP DLP 196
Configure xDSL bonding DLP 130
Convert the ISAM IP address DLP 184
Create a C-VLAN DLP 117
Create a default operator profile DLP 172
(2 of 4)
Title DLP number
Create a forwarding VRF DLP 122
Create a layer2-terminated forwarder VLAN DLP 115
Create a layer2-terminated router VLAN DLP 116

Create a PPPoE user DLP 127
Create a router VRF DLP 123
Create a snapshot alarm table DLP 154
Create an iBridge VLAN DLP 120
Create an IPoA cross-connect user DLP 174
Create an IPoA user DLP 125
Create an IPoE user DLP 126
Create an SC-VLAN DLP 119
Create an S-VLAN DLP 118

Create an xDSL user DLP 124
Create operator profiles and instances DLP 101
Create xDSL profiles DLP 129
Enable dual tagging in the SHub DLP 191
Enable EMS management DLP 171
Enable IPProxy CPE management DLP 193
Enable the PPPoE server DLP 148
Lock and unlock equipment DLP 112
Manage alarms DLP 110
Manage OSWP DLP 159

Manage the SHub database DLP 157
Modify the external management VLAN DLP 162
Modify the system management IP parameters DLP 168

Modifying xDSL profiles DLP 163
Monitor alarms DLP 155
Perform a traceroute action DLP 165
Performance monitoring commands DLP 176
Ping another host DLP 164
Plan, replan, and unplan equipment DLP 111
Reboot the system DLP 152
Script files DLP 167
Set up a CLI session DLP 100
Shut down and restart individual equipment DLP 153
Shut down and restart the NT DLP 151
Switching a user from ADSL to VDSL DLP 173
(3 of 4)
Title DLP number
View port configuration and operational data DLP 197
View software licenses counters DLP 161
View version of the SHub software DLP 160
(4 of 4)
Table IXL 100-3: Routine Task Procedure (RTP)
Title RTP number
Backup the configuration RTP 100
Restore the configuration RTP 101
Retrieve remote inventory RTP 102
Table IXL 100-4: Trouble Analysis Procedure (TAP)
Title TAP number
Equipment repair TAP 102
F5 loopback test TAP 101
Fault isolation and troubleshooting TAP 104
Metallic test access TAP 100
Single ended line testing TAP 103
Table IXL 100-5: Training (TNG)
Title TNG number
7330 ISAM FTTN configuration for subtending TNG 112
7330 ISAM FTTN ES configuration TNG 111
Configuration examples TNG 110

DHCP relay agent configuration TNG 104
DLP configuration examples TNG 114
IGMP and multicast configuration TNG 102

Multi-ADSL parameters TNG 113
Overall software packages TNG 105
Performance management counters TNG 109
QoS configuration TNG 101
Service installation TNG 100
SHDSL parameters TNG 108
(1 of 2)
Title TNG number
Slot numbering schemes TNG 115
Specifying 7330 ISAM FTTN remote expansion units using the CLI TNG 106
VBAS TNG 103

VDSLx parameters TNG 107
(2 of 2)
Non-Trouble Procedures (NTP)
NTP 100 Set up a CLI session and configure users
NTP 101 Execute script files
NTP 102 Configure the system
NTP 103 Configure equipment
NTP 104 Configure a cross-connect VLAN
NTP 105 Configure an iBridge VLAN
NTP 106 Configure an IP-aware bridge
NTP 107 Configure an IP router
NTP 108 Configure services
NTP 109 Configure PPPoE termination
NTP 110 Add an iBridge user
NTP 111 Add an IPoA user
NTP 112 Add an IPoE user
NTP 113 Add a PPPoE user
NTP 114 Perform equipment repairs
NTP 115 Monitor alarms
NTP 116 Perform software management
NTP 117 Modify system parameters
NTP 119 Modify configured services
NTP 120 Troubleshooting
NTP 121 Manage an SNMP proxy CPE
NTP 122 Cluster management
NTP 123 Secure shell
NTP 124 Maintain the system
NTP 125 Add an IPoA cross-connect user
NTP 126 Manage system logging
NTP 127 Configure SHDSL
NTP 128 Manage an IPProxy CPE
NTP 129 Configure a loopback interface on the SHub
NTP 100 Set up a CLI session and
configure users
Purpose
This procedure provides the steps to set up a CLI session with the NE and create a user
using the Alcatel-Lucent-developed CLI.
General
Figure NTP 100-1 shows the management topology of the NE system.
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 NTP 100-1
Figure NTP 100-1: Management Topology

EMS TL1 CLI
(e.g. AWS 5523) Terminal Terminal
SNMP Telnet SSH Telnet SSH

UDP161/ TCP1023 TCP1022 TCP23 TCP22
162 TL1 TL1 CLI
TL1 Gateway Craft Terminal Craft Terminal
TL1 RS232 RS232

UDP13001
ISAM
TL1
agent
CLI IACM
agent
subsystem
SHub
SNMP SNMP
agent agent subsystem
MIB NT Controller / LIMs MIB SHub Active DB
Note The figure above is valid when the system operates in single IP
address mode.
When the system operates in dual IP address mode, then there is also a
direct access from the EMS to the SHub SNMP agent.
Table NTP 100-1 lists the three types of system managers.
Table NTP 100-1: System Managers
Manager type Description
EMS Element Management System based on SNMP
TL1 CT Craft Terminal using TL1 commands
CLI CT Craft Terminal using Command Line Interface (CLI) commands
See the CLI Commands and Messages document for detailed information about the CLI
command syntax.
The use of TL1 commands is still supported.
Procedure
Proceed as follows to set up the CLI session and configure the CLI users:
1 Set up a CLI session; see DLP 100.
NTP 100-2 June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
2 Create and configure an Operator Profile; see DLP 101.
3 Create a default Operator Profile; see DLP 172.
4 STOP. This procedure is complete.
Purpose
A script file is a file containing CLI commands.
A script file must follow the same syntax rules as commands entered interactively. Only
the tab and the question mark lose their special meaning in a script, so command
expansion and single-line help are not available.
The script will be aborted if one of the commands in the script fails. A command may be
preceded by a minus '-' to prevent the script from being aborted in case of a semantic
error; for example, when you try to delete a node instance that does not exist.
By default, a command script does not interact with the user. The execution of the script
will be aborted if a command or filter requires interaction with the user. Interactivity can
be enabled by specifying the interactive option with the exec command.
Command scripts may not be nested.
Procedure
In order to use script files, you need to perform the following tasks:
1 Create and execute script files; see DLP 167.
Purpose
This document describes the procedure to be used to configure the system.
Prerequisite
A CLI session must have been set up; see DLP 100.
Security Considerations
Note The following must be taken into account with regard to system
security:
It is NOT advised to use insecure management channels: CLI/Telnet,

TL1/UDP, SNMPv1/2, dual IP address mode (only SNMPv1/2 on
SHub), TFTP.
If SNMPv1/2 is used anyway, it is advised not to use community string
= public.
It is advised to use secure management channels (CLI/SSH,
TL1/SSH, SNMPv3, single IP address mode, SFTP). This implies
closing the insecure management channels!
SHub ACLs must be configured to allow only the traffic coming from
the Element Management System (EMS) (such 5526 AMS or 5523
AWS) to be routed to the NT OBC.
Encryption via keys must be promoted compared to passwords.
Procedure
Proceed as follows to configure the system:
1 Configure the management IP parameters and network interfaces:
see DLP 175 for configuring the system in single IP address mode
see DLP 102 for configuring the system in dual IP address mode
Note To convert the system IP address mode, that is from dual mode
to single mode or from single mode to dual mode; see DLP 184.
2 Configure the system parameters; see DLP 103.
3 Configure Simple Network Management Protocol (SNMP) and trap management;

see DLP 109.
4 Enable the management of EMS; see DLP 171.
5 Configure the alarm management; see DLP 110.
6 Save the SHub database; see DLP 157.
Purpose
This procedure provides the steps to plan, unplan, or replan the equipment and to lock or
unlock the equipment. Some equipment-related items, such as the shelf, are
auto-created at system startup and do not need to be created. However, they can be
modified.
General
The NE consists of a single shelf with plug-in units. You can perform the actions
described in Table NTP 103-1 to configure the equipment.
Table NTP 103-1: Configure plug-in units
Action Description
Planning equipment Planning a piece of equipment is possible before and after the equipment is
physically present and detected by the system (at startup). The system
verifies the configuration parameters and checks if the required equipment
is available.
Note: As long as equipment is not planned, it is impossible to offer service.
Units and other equipment are only available from an operation and
maintenance point of view.
Unplanning equipment If necessary, you can unplan any equipment. Unplanning, however, may be
rejected in case of hierarchical dependencies. For example, it is impossible
to unplan a shelf as long as one or more units in it are still planned.
(1 of 2)
Action Description
Replanning equipment Replanning is done when changing the current equipment.
Locking and unlocking When necessary, you can lock any equipment, most often a unit, to put it out
equipment of service. Locking a unit renders it inactive. No traffic is generated or
received by the units. However, the unit is not removed from the
configuration, and as soon as you unlock the unit, it becomes active again.
It goes back to operational mode without restart or initialization, and traffic
can resume immediately.
Similarly, you can power down the unit and restart it at a later time. In this
case, however, the unit will go through a complete startup cycle before
traffic is possible.
(2 of 2)
Procedure
Proceed as follows to configure or modify the system equipment:
1 Plan, replan, or unplan equipment; see DLP 111.
2 Lock or unlock the equipment; see DLP 112.
3 Modify the configuration of the system equipment; see DLP 113.
4 Configure NT redundancy; see DLP 114.
5 Configure SFP downlink ports; see DLP 177.
NTP 104 Configure a cross-connect
VLAN
Purpose
The NE supports several VLAN cross-connect models:
Customer VLAN (C-VLAN) cross-connect:

This is the most straightforward VLAN cross-connect model where a single VLAN ID
at the EMAN side is associated with a given PVC at the user side. Any kind of traffic
issued by the subscriber is passed transparently towards the network using the
selected VLAN ID.
Service provider VLAN (S-VLAN) cross-connect: VLAN stacking for business users.
In this cross-connect model, the S-VLAN ID at the EMAN side is associated with a
single subscriber interface at the user side. The C-VLANs carried within the S-VLAN
are passed transparently to the end user. This allows the end user to specify its own
end-to-end connectivity, while remaining transparent for the EMAN.
Two levels of VLAN tags are used, which allow support of hierarchical addressing:
The customer VLAN: C-VLAN
The service provider VLAN: S-VLAN
S-VLAN/C-VLAN cross-connect: VLAN stacking for residential users:
The basic VLAN cross-connect mode suffers from the fact the that number of VLAN
identifiers is limited to 4K. Since the VLAN is a EMAN wide identifier, one ends up with
a scalability issue: there cannot be more than 4K end users connected to the whole
EMAN. To solve this issue, two VLANs are stacked and the cross-connection is then
performed on the combination (S-VLAN, C-VLAN) allowing to theoretically reach up
to 16M end users.
NTP 104 Configure a cross-connect VLAN
Figure NTP 104-1: CC-CLAN
NE
VLAN X
VLAN Y
VLAN A
VLAN B
Figure NTP 104-2: CC-VLAN: traffic flow

Source MAC address = PC
Destination MAC address = Network
NE
PC
Network
Source MAC address = Network

Destination MAC address = PC
Procedure
The procedures for creating a cross-connect VLAN are described in the following DLPs:
1 For the configuration of global VLAN parameters: see DLP 187.
2 For the creation of a C-VLAN; see DLP 117.
3 For the creation of an S-VLAN; see DLP 118.
4 For the creation of an SC-VLAN; see DLP 119.
5 For the creation of an Qos aware VLAN; see DLP 135.
Purpose
The concept of a VLAN in intelligent bridging (iBridge) mode is that multiple NSPs are
each connected to the NE with a VLAN. The user ports are connected to the VLAN of
their corresponding NSP.
Note The NE supports up to 128 iBridges
Figure NTP 105-1: iBridge VLAN

VLAN X
NE Video VLAN
Internet
Video
Figure NTP 105-2: iBridge VLAN: traffic flow

NE
PC
Network

Procedure
Proceed as follows to configure an iBridge VLAN:
1 For the configuration of global VLAN parameters: see DLP 187.
2 For the creation of an iBridge VLAN; see DLP 120.
3 Add the network interface to the iBridge VLAN; see DLP 121.
Purpose
In this mode, the NE can be seen as an IP-aware bridge without being seen as an IP
next-hop. Users connected to the NE are seen as being directly attached to the edge
router IP interfaces.
The end-users use the IP address of the edge router as their default gateway, while the
IP edge router sees the end-user subnets as directly attached networks. The NE sits in
between and perform packet forwarding at L3.
This procedure provides the steps to configure an IP-aware bridge on the NE.
Figure NTP 106-1: IP-aware Bridge

VLAN X
NE Video VLAN
Internet
Video
Video VLAN is
always in iBridge
Figure NTP 106-2: IP-aware Bridge: Traffic Flow

NE Source MAC address = NE

PC
Network

Destination MAC address = NE

Procedure
Proceed as follows to configure an IP-aware bridge:
1 Create a forwarder Virtual Routing Forwarding (VRF); see DLP 122.
2 Create a L2 terminated forwarder VLAN for each of the Network Service Providers
(NSP); see DLP 115.
3 Add the network interfaces to the L2 terminated forwarder VLANs; see DLP 121.
Purpose
In this mode, the NE is seen as an IP next-hop by the edge routers to route the IP packets
to the users connected to the NE. A single Virtual Router can be configured in this mode,
which can co-exist in the same system with a number of VRs that are configured in
IP-aware Bridge mode (see NTP 106).
At the user side of the system (xDSL line), unnumbered IP interfaces are used, while user
subnets are configured on a user gateway interface. In order to achieve maximum
efficiency in the allocation of IP addresses, several users (on different xDSL lines) can
share a same subnet.
Host routes towards the end-user devices are either dynamically created in the NE in
case of dynamic DHCP or PPPoE sessions, or statically provisioned in case of static IP
address assignment.
Towards the network, IP interfaces are numbered (meaning that the NE IP addresses
and subnets are configured).
Figure NTP 107-1: IP Router

VLAN X
NE Video VLAN
Internet
Video
VLAN Y
Video VLAN is Virtual VLAN

always in iBridge
Figure NTP 107-2: IP Router: traffic flow

NE Source MAC address = NE

PC
Network

Source MAC address = NE

Procedure
Proceed as follows to configure an IP router:
1 Create a router VRF; see DLP 123.
2 Create a L2-terminated router VLAN; see DLP 116.
3 Add users; see DLP 125 for adding IPoA user or DLP 126 for adding IPoE user.
Purpose
This procedure provides the steps to configure the following services on the NE:
xDSL profiles
Quality of Service (QoS)
Internet Group Management Protocol (IGMP) and multicast
Dynamic Host Configuration Protocol (DHCP) relay agent and Option 82
Authentication
Point-to-Point Protocol (PPP) configuration
NT redundancy
Link aggregation
Rapid Spanning Tree Protocol (RSTP)
Routing protocols (optional)
Voice Session Initiation Protocol (SIP)
Network Access Control Protocol (NACP) session
Procedure
To configure a service, you need to perform the following tasks:
1 Configure xDSL profiles:
i For the configuration of the service profiles and the spectrum profiles; see
DLP 129.
ii For the configuration of custom PSD points; see DLP 188.
iii For the configuration of virtual noise values for VDSL2; see DLP 189
2 Configure xDSL bonding; see DLP 130.
3 Configure general bridge parameters for LT and SHub; see DLP 195.
4 Configure QoS:
i For the configuration of a QoS-aware VLAN; see DLP 135.
ii For the configuration of QoS on L2; see DLP 133.
iii For the configuration of QoS on L3; see DLP 134.
iv For the configuration of QoS on the SHub; see DLP 199.
v For the configuration of QoS Threshold Crossing Alerts (TCA); see DLP 202.
5 Configure IGMP and multicast:
i For the configuration of multicast on the LT; see DLP 136.
ii For the configuration of multicast on the SHub; see DLP 198.
iii For the configuration of IGMP proxy on the LT; see DLP 137.
iv For the configuration of IGMP snooping on the SHub; see DLP 138.
6 Configure DHCP Relay:
i For the configuration of the DHCP relay agent in iBridge mode; see DLP 139.
ii For the configuration of the DHCP relay agent in router mode; see DLP 140.
iii For the configuration of the DHCP relay agent in forwarder mode; see
DLP 141.
iv For the configuration of DHCP MAC concentration in forwarder mode; see

DLP 186.
7 Configure the authentication settings:
i For the configuration of the security domain: see DLP 142.
ii For the configuration of local authentication; see DLP 143.
iii For the configuration of RADIUS; see DLP 144.
iv For the configuration of 802.1x authentication; see DLP 145.
v For the configuration of operator authentication via RADIUS; see DLP 181.
vi For the configuration of the default security domain; see DLP 178.
8 Configure the PPP relay settings:
i For the configuration of PPPoE relay; see DLP 146.
ii For the configuration of PPPoA-PPPoE relay; see DLP 147.
9 Configure NT redundancy; see DLP 114.
Note If NT redundancy is not required, then this has to be specifically

disabled to avoid a missing redundancy alarm; see DLP 114.
10 If necessary, configure link aggregation. Link aggregation is used to aggregate two

or more physical links from one switch to another.
For the configuration of link aggregation; see DLP 105.
11 If necessary, configure Multiple Spanning Tree Protocol (MSTP); see DLP 200.
12 If necessary, configure routing protocols such as OSPF and RIP. the configuration
is optional (depends if the network elements which are connected to the ISAM, are
using those protocols). The routing protocols are handled in the Shub.
i For the configuration of Open Shortest Path First (OSPF) management; see
DLP 107.
ii For the configuration of Routing Information Protocol (RIP) management; see

DLP 108.
13 Configure Voice SIP; see DLP 196.
14 Configure an NACP session; see DLP 185.
Purpose
This procedure provides the steps to configure Point-to-Point Protocol (PPP) on the NE.
Procedure
To configure PPPoE termination, you need to perform the following tasks:
1 For the configuration of the PPPoE server; see DLP 148.
2 For the configuration of PPPoE profiles; see DLP 149.
Purpose
This procedure provides the steps to add an iBridge user on the NE.
Prerequisites
The following prerequisites must be fulfilled before an iBridge user can be created:
The LT must be planned; see DLP 111.

The xDSL profiles must have been created; see DLP 129.
An iBridge VLAN should be created; see DLP 120.
Procedure
Proceed as follows to add an iBridge user:
1 Add the LT to the VLAN, for the first user to be created on the LT for that VLAN; see
DLP 128.
2 Create an iBridge user; see DLP 124.
Purpose
An IPoA user interface is a L2 interface created on a PVC which is configured in
RFC2684 LLCSNAP routed or RFC2684 VC-MUX routed encapsulation modes.
An IPoA interface is attached to a Virtual Router (VR) by configuring an unnumbered IP

interface on top of it. The VR is always determined via configuration.
Multiple user sessions (or users) may exist on the same IPoA interface. A session
corresponds to all the traffic originating from or destined to a host whose IP address is
seen by the NE in the customer environment.
This procedure provides the steps to add an IPoA user on the NE.
Prerequisites
The following prerequisites must be fulfilled before an IPoA user can be created:

xDSL profiles must have been created; see DLP 129.
An IP-aware bridge (see NTP 106) or an IP router (see NTP 107) must have been
created.
Procedure
Proceed as follows to add an IPoA user:
1 If the first IPoA user to be created on a VLAN needs DHCP, configure the VRF for
DHCP; see DLP 140.
2 Create an IPoA user; see DLP 125.
3 Add the LT to the VLAN, for the first user to be created on the LT for that VLAN; see
DLP 128.
Note This VLAN is a residential bridge VLAN if an IP-aware bridge

(see NTP 106) was created before or a virtual VLAN if an IP router (see
NTP 107) was created before.
Purpose
An IPoE(oA) user interface is a L2 interface created on a PVC which is configured in
RFC2684 LLCSNAP bridged or RFC2684 VC-MUX bridged encapsulation modes.
An IPoE(oA) interface is attached to a VR by configuring an unnumbered IP interface on

top of it. The VR is always determined via configuration (802.1x authentication is not
supported in combination with IP forwarding).
Multiple user sessions (or users) may exist on the same IPoE(oA) interface. A session
corresponds to all traffic originated from or destined to a host whose IP address is seen
by the NE in the customer environment.
This procedure provides the steps to add an IPoE user on the NE.
Prerequisites
The following prerequisites must be fulfilled before an IPoE user can be created:

created.
Procedure
Proceed as follows to add an IPoE user:
1 If the first IPoE user to be created on a VLAN needs DHCP, configure the VRF for
DHCP; see DLP 140.
2 Create an IPoE user; see DLP 126.
3 Add the LT to the correct VLAN (service), for the first user to be created on the LT
for that VLAN; see DLP 128.
Purpose
A PPPoE(oA) user interface is a L2 interface created on a PVC which is configured in
RFC2684 LLCSNAP bridged or RFC2684 VC-MUX bridged encapsulation modes.
A PPPoE session is an unnumbered IP interface established by a user on a PPPoE(oA)

interface. IP interface is a notion to group traffic and treat as a single entity for different
purposes being authentication, accounting, service provisioning, and security.
Multiple PPPoE sessions can be established on the same PPPoE(oA) interface. The
system can also limit the max number of PPPoE session per PPPoE(oA) via
configuration.
This procedure provides the steps to add a PPPoE user on the NE.
Prerequisites
The following prerequisites must be fulfilled before an PPPoE user can be created:

created.
PPPoE termination (that is, enabling PPPoE server and configuration of PPPoE
profiles) must have been configured; see NTP 109.
Procedure
Proceed as follows to add a PPPoE user:
1 Create a PPPoE user; see DLP 127.
2 Add the LT to the correct VLAN (service), for the first user to be created on the LT
for that VLAN; see DLP 128.
Purpose
This procedure provides the steps to perform equipment repair on the NE.
Procedure
Proceed as follows to perform equipment repair tasks:
1 Plan, unplan, and replan equipment (for example, plug-in units); see DLP 111.
2 Pull out and plug in equipment. For the procedures, refer to the XD Modular
Hardware Installation Manual for the 7302 ISAM or the Hardware Installation and
Maintenance Practices for the 7330 ISAM FTTN.
3 Lock and unlock equipment (mostly plug-in units); see DLP 112.
4 Start up or shut down the system, select one of:
a Shut down or restart the SHub; see DLP 151.
b Reboot the entire system; see DLP 152.
c Shut down individual equipment; see DLP 153.
Purpose
This procedure provides the steps to monitor the alarms on the NE.
Procedure
Proceed as follows to monitor the alarms:
1 Create an alarm snapshot table; see DLP 154.
2 Monitor the alarms; see DLP 155.
NTP 116 Perform software
management
Purpose
This procedure provides the steps to perform software management on the NE.
Procedure
The following steps can be used to perform software management:
1 Management of the NT and SHub database; see RTP 100.
2 Management of the Overall Software Packages; see DLP 159.
3 View the version of the SHub software; see DLP 160.
4 Management of the software licenses; see DLP 161.
NTP 116 Perform software management
Purpose
This procedure lists the procedures for system parameter modification.
Procedure
The steps below show the procedures for modifying different system parameters:
1 Modify the management IP parameters; see DLP 168.
2 Change the external management VLAN; see DLP 162.
3 Configure an ARP table entry; see DLP 150.
4 Configure filtering on the SHub; see DLP 132.
5 Configure static MAC addresses; see DLP 180.
NTP 118 Monitor performance and
view configuration
Purpose
This procedure list the procedures that can be used for:
Performance Monitoring (PM)

viewing the configuration and operational data of a port
Procedure
The following tasks can be performed:
1 Configure the Treshold Crossing Alert (TCA); see DLP 190
2 Viewing the PM counters; see DLP 176
3 Viewing the configuration and operational data of a port (xDSL or Ethernet); see
DLP 197
Purpose
This procedure provides the steps to adapt the following services on the NE:
xDSL profiles
switching a user from ADSL to VDSL
Procedure
You can perform the following tasks:
1 Modify an xDSL profile; see DLP 163.
2 Switching a user from ADSL to VDSL; see DLP 173.
Purpose
The following troubleshooting commands can be used:
Ping:
The ping command lets you verify that a particular IP address exists and can accept
requests. Ping is used diagnostically to ensure that a host computer you are trying to
reach is actually operating. Ping can also be used with a host that is operating to see
how long it takes to get a response back.
Traceroute:
Traceroute is a utility that traces the route in the network for an IP address. It also
calculates and displays the amount of time each hop took.
The utility initiates the sending of a packet (using the Internet Control Message
Protocol (ICMP)), including in the packet a Time To Live (TTL) value that is designed
to be exceeded by the first router that receives it, which will return a Time Exceeded
message. This enables traceroute to determine the time required for the hop to the
first router. Increasing the time limit value, it sends the packet again so that it will reach
the second router in the path to the destination, which returns another Time Exceeded
message, and so forth.
Traceroute determines when the packet has reached the destination by including a
port number that is outside the normal range. When it's received, a Port Unreachable
message is returned, enabling traceroute to measure the time length of the final hop.
As the tracerouting progresses, the records are displayed for you hop by hop.
Procedure
The following troubleshooting commands can be used:
1 Ping command; see DLP 164.
2 Traceroute command; see DLP 165.
Purpose
The Customer Premises Equipment (CPE) management functionality allows to
troubleshoot a CPE at all protocol layers when problems are experienced with either
misconfiguration of the CPE or with the end-user's terminals. It allows to have a clear
indication if a problem is situated before or after the demarcation point of a telecom
carriers responsibility.
Additionally, CPE management offers the possibility to control the SW upgrade of CPEs
by downloading from the network.
The function of xDSL CPE remote management includes configuration, monitoring,

maintenance and upgrade of an xDSL Remote Terminal. The network reference model
is illustrated in Figure NTP 121-1.
Figure NTP 121-1: Network Reference Model
Network Management Entity
CPE-MM
RMI User Management Entity
LMI
NE xDSL CPE
The CPE-MM is responsible for the management of CPE. The following interfaces are
defined:
LMI: interface between NE and CPE

RMI: interface between CPE-MM and NE
Three channels are present on the LMI interface:
Service data channel:

This channel is used to carry data traffic (for example, HSI traffic).
Basic management channel:
This channel is used to carry CPE remote management information.
Auxiliary management channel:
This channel is used to carry SW download, PPPoE testing, PING testing, bandwidth
testing and so on.
The NE relays the SNMP messages between CPE-MM and CPE.
Note This NTP is for CPE management using SNMP. For IPProxy
CPE management; see NTP 128.
Procedure
To configure SNMP proxy CPE management, you need to perform the following tasks:
1 Configure SNMP proxy CPE management; see DLP 166.
Support
Cluster management is supported on the 7302 ISAM only.
Purpose
As a result of the massive deployment of xDSL, many more DSLAMs are provisioned in
the network. They are mostly managed separately, which makes the management
workload heavy and complicated.
To simplify the management workload of the operator, cluster management groups

multiple DSLAMs as one logical management domain. The logical management domain
of a cluster is formed by a physically interconnected group of DSLAMs. The operator can
organize its clusters according to, for example, physical location.
Topology display will present the connectivity and status of DSLAMs in a connected
environment, possibly over more than one cluster. Moreover, separately managed
DSLAMs use more public IP addresses, which are limited.
Figure NTP 122-1 shows an example of the cluster management topology.
Figure NTP 122-1: Cluster Management Topology
Management
Cluster No. 2 Command
(A logical DSLAM) to Cluster 2
EMS (AWS) Management
Command
to Cluster 1
Single Logical
Management Path Cluster No.1
(A logical DSLAM)
DSLAM
No. 7 DSLAM
No. 8
DSLAM
DSLAM No. 2
No. 1
DSLAM
DSLAM
No. 9
No. 10
DSLAM DSLAM DSLAM DSLAM DSLAM

No. 11 No. 3 No. 4 No. 5 No. 6
Procedure
To configure cluster management, you need to perform the following tasks:
1 Configure the cluster; see DLP 169.
Purpose
Secure Shell (SSH) is a protocol that provides authentication, encryption, and data
integrity to secure network communications. On top of this protocol, Secure Shell
implementations offer secure replacements for rsh, rlogin, rcp, ftp, and telnet, all of which
transmit data over the network as clear text.
The Secure Shell protocol consists of several subprotocols:
SSH Transport Protocol

This subprotocol is responsible for setting up the secure channel that can be used by
the other SSH subprotocols. The SSH transport protocol handles secure key
exchange, server authentication, encryption, replay, and integrity protection. It runs
on top of any reliable transport protocol (for example, TCP).
SSH User Authentication Protocol
This subprotocol provides client-side user authentication. It runs on top of the SSH
Transport protocol.
SSH Connection Protocol
This subprotocol provides interactive login sessions and forwarded TCP connections.
Procedure
To configure the SSH functionality, you need to perform the following tasks:
1 Configure the SSH functionality; see DLP 170.
Purpose
This NTP provides the steps for system maintenance of the NE.
Procedure
Perform this procedure to maintain the system:
1 Back up the system configuration; see RTP 100.
2 Restore the system configuration; see RTP 101.
3 Retrieve the remote inventory; see RTP 102.
NTP 125 Add an IPoA cross-connect
user
Purpose
An Inter-Working Layer (IWL) is created on a PVC that is configured in RFC2684
LLC-SNAP routed or RFC 2684 VC-MUX routed encapsulation modes.
Only one C-VLAN or SC-VLAN is configured in cross-connect mode. This VLAN must
then be associated with a bridge port, which is created on the same PVC as the IWL.
This procedure provides the steps to add an IPoA Cross-Connect User on the NE.
Prerequisites
The following prerequisites must be fulfilled before an IPoA cross-connect user can be
created:

Procedure
Proceed as follows to add an IPoA cross-connect user:
1 Create a C-VLAN or SC-VLAN; see DLP 117 or DLP 119.
2 Create an IPoA cross- connect user; see DLP 174.
NTP 125 Add an IPoA cross-connect user
Purpose
This NTP provides the steps to manage system logging (SYSLOG) for the NE.
General
System statistics logs are user configurable and you can create up to 64 system logs.
System logs can be saved locally, to a remote server, or to all active CLI or all active TL1
terminals.
You can perform the following three main tasks using CLI:
enable and disable logging for all system logs

create and configure up to 64 system logs
monitor system logs
Using filters, you can determine which messages are sent to the system log file, as well
as set the severity level of the system log.
The following applies when using SYSLOG in an operational (E2E) environment:
The NE supports SYSLOG according to RFC3164 (aka BSD SYSLOG)

The SYSLOG application on the external server has to listen to UDP port 514:
everything that comes in via this port should be considered as being a SYSLOG
message. The NE sends out its SYSLOG messages on this port.
The severity of the various application messages is predefined. It is reported as
follows:
Service Affecting alarm messages: EMERGENCY
Authentication messages: ALERT
Configuration change messages: NOTICE
Other CLI/TL1 messages (admin, Show, retrieve): INFO
protocol tracing: DEBUG
videoCDR reporting: NOTICE
See the 7302 ISAM | 7330 ISAM FTTN CLI Command Guide document for more
information about CLI commands used to configure system logging.
See the 7302 ISAM | 7330 ISAM FTTN System Description document for more
information about system and security statistics logging.
Procedure
Use this procedure to manage system logging for the NE. See the references for detailed
procedures and safety information.
1 Enable and disable logging for all system logs; see DLP 179.
2 Create, configure, and monitor system logs; see DLP 179.
Purpose
Single-pair High-speed Digital Subscriber Line (SHDSL) is a physical layer standard
based on the ITU-T Recommendation G.991.2. It describes a versatile transmission
method for data transport in the telecommunication access networks, capable of
supporting whichever network protocol deployed currently while enabling higher
bandwidth and reach (for example, TDM, ATM, Frame Relay and so on).
SHDSL transceivers are designed primarily for duplex operation over mixed gauges of
two wire twisted metallic pairs. Four-wire and m-pair operations are included as options
for extended reach. The use of signal regenerators for both the two-wire and multi-wire
operations is optional.
Inverse Multiplexing for ATM (IMA) permits a broadband cell stream to be transported on
a number of lower-rate physical links (for example, several SHDSL span lines) by
grouping these physical links into a single logical channel. The specification includes
means to maintain cell order and a method to allow in-service loss and restore of
individual physical links.
Note For a more detailed description of the different parameters for

SHDSL span, unit and segment configuration, refer to TNG 108.
Procedure
Proceed as follows to configure SHDSL:
1 To configure SHDSL links; see DLP 182.
2 To configure IMA on SHDSL links; see DLP 183.
Purpose
IPProxy CPE Management allows configuration, monitoring, maintenance and upgrade
of ADSL Remote Terminals. These functions can be executed from a CPE Management
Module (CPE-MM).
The network reference model is illustrated in Figure NTP 128-1.
Figure NTP 128-1: Network Reference Model
Network Management Entity
EMS CPE-MM
IP@/UDP IP@/UDP
IP@/TCP IP@/TCP
Telnet/ TCP/ IP/VLAN
TFTP/UDP/ IP/ VLAN
RMI RMI
User Management Entity
NE
Relay xDSL CPE
LMI
Telnet/ IP/AAL5/ATM/DSL
TFTP/ IP/AAL5/ATM/DSL
For IPProxy CPE Management, the CPE must support both Telnet & TFTP server
functions. The CPE-MM must support Telnet & TFTP client functions. The NE relays the
Telnet and TFTP messages between the CPE-MM and the CPE.
The TFTP function is for the CPE firmware upgrade

The Telnet function is for the configuration and operation of the CPE
The CPE-MM is responsible for the management of CPE. The following interfaces are
defined:
LMI: interface between NE and CPE

RMI: interface between CPE-MM and NE
Two channels are present on the LMI interface:
Management channel
Data channel
The management channel is used to carry CPE remote management information, to

upload performance statistics, and to download CPE firmware. The protocol stack of the
management channel is TELNET and TFTP over TCP/UDP/IP. The IP packets are
RFC1483R encapsulated on AAL5/ATM over PVC (VPI = 1, VCI = 39).
The protocol stack on the RMI is the same as for the NE management interface, that is,
Telnet and TFTP over TCP/UDP/IP is supported.
Prerequisites
The following prerequisites must be fulfilled:
The CPE must have a Telnet and TFTP service on IPoA over ATM PVC 1,39
The CPE IP must be configured to be 192.168.1.1 for IPoA on ATM PVC 1,39
Procedure
To configure IPProxy CPE management, you need to perform the following tasks:
1 If not already done, enable the dual tagging mode in the SHub; see DLP 191
2 Configure the S-VLAN to be used for IPProxy CPE Management; see DLP 192
3 Enable the IPProxy CPE Management function; see DLP 193
4 Configure one or more IPProxy CPE Management sessions; see DLP 194
5 On the session configured, use Telnet or TFTP to the modem(s) to communicate

using the connection (<CpeProxy::cpeIpProxySessionProtocolPort>) port allocated
for the session.
NTP 129 Configure a loopback
interface on the SHub
Purpose
Configure a loopback interface on the SHub.
Prerequisites
The following prerequisites must be fulfilled:
The system must run in single ip-address mode.
Procedure
To configure a loopback interface on the Shub, you need to perform the following tasks:
1 Configure a host IP address on the NT using a mask 32.
2 Configure an unnumbered interface on the Shub (that is, a VLAN which has the
network IP address as numbered interface); see DLP 204.
3 Configure VRF routes on the SHub:
a route <host-ip-address-nt/32> via the management VLAN 4093 directly

attached.
a default route via IP address out of address range of 2.
4 Configure a default route on the NT via the IP address of the numbered VLAN
interface on the SHub.
NTP 129 Configure a loopback interface on the SHub
Detailed Level Procedures (DLP)
DLP 100 Set up a CLI session
DLP 101 Create operator profiles and instances
DLP 102 Configure dual IP address
DLP 103 Configure system parameters
DLP 104 Configure network interfaces
DLP 105 Configure link aggregation usage
DLP 106 Configure RSTP
DLP 107 Configure OSPF
DLP 108 Configure RIP
DLP 109 Configure SNMP and trap management
DLP 110 Manage alarms
DLP 111 Plan, replan, and unplan equipment
DLP 112 Lock and unlock equipment
DLP 113 Configure the equipment
DLP 114 Configure NT redundancy
DLP 115 Create a layer2-terminated forwarder VLAN
DLP 116 Create a layer2-terminated router VLAN
DLP 117 Create a C-VLAN
DLP 118 Create an S-VLAN
DLP 119 Create an SC-VLAN
DLP 120 Create an iBridge VLAN
DLP 121 Add network interfaces to a VLAN
DLP 122 Create a forwarding VRF
DLP 123 Create a router VRF
DLP 124 Create an xDSL user
DLP 125 Create an IPoA user
DLP 126 Create an IPoE user
DLP 127 Create a PPPoE user
DLP 128 Add an LT port to a VLAN
DLP 129 Create xDSL profiles
DLP 130 Configure xDSL bonding
DLP 131 Create an xDSL bonding group
DLP 132 Configure filtering on SHub
DLP 133 Configure QoS on layer 2
DLP 135 Configure a QoS-aware VLAN
DLP 136 Configure multicast on the LT
DLP 137 Configure IGMP proxy
DLP 138 Configure IGMP snooping
DLP 140 Configure DHCP relay agent in router mode
DLP 142 Configure the security domain
DLP 143 Configure local authentication
DLP 144 Configure RADIUS
DLP 145 Configure 802.1x
DLP 146 Configure PPPoE relay
DLP 147 Configure PPPoX relay
DLP 148 Enable the PPPoE server
DLP 149 Configure PPPoE profiles
DLP 150 Configure ARP table entry
DLP 151 Shut down and restart the NT
DLP 152 Reboot the system
DLP 153 Shut down and restart individual equipment
DLP 154 Create a snapshot alarm table
DLP 155 Monitor alarms
DLP 156 Management of the SHub database
DLP 157 Manage the SHub database
DLP 158 Manage the system database
DLP 159 Manage OSWP
DLP 160 View version of the SHub software
DLP 161 View software licenses counters
DLP 162 Modify the external management VLAN
DLP 163 Modifying xDSL profiles
DLP 164 Ping another host
DLP 165 Perform a traceroute action
DLP 166 Configure SNMP proxy CPE management
DLP 167 Script files
DLP 169 Configure cluster management
DLP 170 Configure SSH
DLP 171 Enable EMS management
DLP 172 Create a default operator profile
DLP 173 Switching a user from ADSL to VDSL
DLP 174 Create an IPoA cross-connect user
DLP 175 Configure single IP address
DLP 176 Performance monitoring commands
DLP 177 Configure SFP downlink ports
DLP 178 Configure the default security domain
DLP 179 Configure system logging
DLP 180 Configure static MAC addresses
DLP 182 Configure SHDSL links
DLP 183 Configure IMA on SHDSL links
DLP 184 Convert the ISAM IP address
DLP 185 Configure NACP session
DLP 186 Configure DHCP MAC concentration in forwarder mode
DLP 187 Configure global VLAN parameters
DLP 188 Configure custom PSD points
DLP 189 Configure VDSL2 virtual noise values
DLP 190 Configure threshold crossing alerts
DLP 191 Enable dual tagging in the SHub
DLP 192 Configure IPProxy CPE management
DLP 193 Enable IPProxy CPE management
DLP 195 Configure general bridge parameters
DLP 196 Configure Voice SIP
DLP 198 Configure multicast on the SHub
DLP 199 Configure QoS on the SHub
DLP 200 Configure MSTP
DLP 201 Configure protocol tracing
DLP 202 Configure QoS threshold crossing alerts
DLP 203 Configure general security settings
DLP 204 Configure an unnumbered IP interface on the SHub
Purpose
This procedure provides the steps to set up a CLI session with the NE.
Procedure
Proceed as follows to set up a CLI session:
1 Enter LOGIN to start up the command line interface.
The logon prompt appears.
2 After the question Would you like a CLI(C) or a TL1 login(T) or TL1 normal
session(N)? [N]:, type C and press Enter.
3 Enter the default user name (isadmin) and password (i$@mad-) that were provided
to you with the system. If you do not have the default user name and password,
contact Alcatel-Lucent technical support.
Note 1 For security purposes, change the default user name and
password. The system will prompt you to do this when you log in for the
first time.
Note 2 For remote CLI, after you set up the management channel,
you can set up a remote CLI session using Telnet.
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 DLP 100-1
DLP 100-2 June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
DLP 101 Create operator profiles and
instances
Purpose
Before an operator instance can be created, an operator profile must be created
An operator profile determines most of the properties of the operator. It is used to limit the
commands a group of operators can execute to those for which they have the necessary
skills and for which they are responsible.
This document describes the procedure to configure and create an operator profile and
to create an operator instance.
Operator Profile Rules

The following rules apply to an operator profile:
The permissions of an operator profile cannot be changed as long as one operator

belongs to the profile.
The operator profile is assigned at the moment the operator is created. It cannot be
changed afterwards. If an operator profile needs to be changed, then the operators
with this operator profile must first be deleted. Only then can the properties of the
profile be changed.
Password Rules
The following rules apply to a plain text password:
the password must consist of a minimum of 6 and a maximum of 20 characters

the password must contain a minimum of 1 non-alphanumeric character
a new password must be different from the last three passwords
Never specify a new password in an encrypted format, because you can enter any
hexadecimal string that is not necessarily linked to a password. It is almost impossible to
calculate a password from an encrypted string. This method of specifying passwords is
only intended to restore an existing configuration.
An operator will be requested to enter a new password after logging in for the first time
after a password change.
Procedure
Proceed as follows to create an operator instance:
1 Create and configure the operator profile to which the operator will belong with the
following command:
configure system security profile (name)

(no) prompt <Sec::Prompt>
(no) password-timeout <Sec::PasswordTimeout>
(no) terminal-timeout <Sec::InactivityTimeout>
(no) slot-numbering <Sec::SlotDesc>
(no) description <Sec::ProfileDesc>
(no) aaa <Sec::Aaa>
(no) atm <Sec::Atm>
(no) alarm <Sec::Alarm>
(no) dhcp <Sec::Dhcp>
(no) equipment <Sec::Equipment>
(no) igmp <Sec::Igmp>
(no) ip <Sec::Ip>
(no) pppoe <Sec::Pppoe>
(no) qos <Sec::Qos>
(no) software-mngt <Sec::Sw>
(no) transport <Sec::Transport>
(no) vlan <Sec::Vlan>
(no) xdsl <Sec::Xdsl>
(no) security <Sec::Security>
Note No capitals may be used in the profile name.
2 Create an operator instance with the following command:
configure system security operator (name)

profile <Sec::ProfileName>
password prompt | plain:<Sec::PlainPassword>
| encrypted:<Sec::EncryptedPassword>
(no) description <Sec::OperatorDesc>
(no) more
Note No capitals and blanks may be used in the

operator name/profile name.
Configuration example:
configure system security profile profile1 no prompt

password-timeout 10 terminal-timeout 30 description Profile1
aaa read atm read alarm write no dhcp equipment write igmp write
ip write pppoe write qos write no software-mngt transport write
vlan write xdsl write security write
configure system security operator jimphelpsmi profile admin

password plain:isam123! prompt %s:%n%d%c description Operator
for MI
Purpose
This document describes the procedure to configure the system management IP
parameters.
security:
It is NOT advised to use insecure management channels, such as

dual IP address mode.
It is advised to use secure management channels, such as single IP
address mode. This implies closing the insecure management
channels!
Procedure
Proceed as follows to configure the system management IP parameters:
1 By default, the system will start up in single IP address mode. You can set the
mode to dual IP address (refer also to DLP 103, step 1) with the following
command:
configure system id <Sys::systemId>

no single-public-ip
2 The system can receive an IP address either statically by manual configuration or

dynamically via BOOTP. Configure the host IP address of the system with the
following command:
configure system management host-ip-address bootp |

manual:<Ip::V4Address>/<Ip::PrefixLengthHost>
Note 1 In case of manual configuration of the IP address:

If the system IP address is not configured (default 0.0.0.0), the users
session setup requests are refused.
Note 2 In case of dynamic configuration via BOOTP:

you can view the IP address that you received from the server with the
following command:
show transport ip-address

3 Configure the network port management (inband or outband) with the following
command:
configure interface shub port (network-port)

port-type <Sys::Type>
where port-type can be:

user: port to a directly connected user
subtending: port to a subtended ISAM
network: port to the service provider (ISP)
unused: port is not in use
outband-mngt: port is used for outband-management
Select network for inband management or outband-mngt for outband management
Inband or outband management can be checked with the following commands (output of the
commands is an example):
show vlan global
----------------------------------------------------------------
vlan parameters
----------------------------------------------------------------
configured-vlans : 16 management : inband
max-rb-vlan : 128 max-layer2-term-vlan : 1280

===============================================================
show interface shub port
================================================================
port table
================================================================
port admin-status oper-status speed type duplex
----------------------------------------------------------------
1 down down one-gb unused full
2 up up one-gb outband full
3 up down one-gb user full
4 up down one-gb subtending full
5 up down one-gb network full
6 up up hundred-mbps network full
7 up up hundred-mbps network half
----------------------------------------------------------------
4 Configure the SHub system IP group configuration with the following command:
configure system shub entry ip ip-cfg-mode <Sys::DefIpAddr>
Note Set the parameter <Sys::DefIpAddr> to:
dynamic in case of dynamic configuration (BOOTP)

manual in case of manual configuration (default value)
5 Do one of the following:
In case of manual configuration, continue with step 6

In case of dynamic configuration, continue with step 9
6 Configure the default route of the system with the following command:
configure system management default-route (default-route)
7 Configure the SHub IP address as follows:
i Set the adminstrative status of the OAM VLAN to down with the following
command:
configure interface shub ip 4093 admin-status down
ii Configure the SHub IP address with the following command:
configure interface shub ip 4093
ip-addr <Ip::V4Address>/<Ip::PrefixLengthFull>
iii Set the adminstrative status of the OAM VLAN to up with the following
command:
configure interface shub ip 4093 admin-status up
8 Configure the default route in the SHub with the following command:
configure ip shub vrf 0 route-dest 0.0.0.0/0

next-hop <gateway-ip-address>
vlan-id 4093
9 Specify the set of ports which are statically allocated as egress ports for the SHub
management VLAN with the following command:
configure vlan shub id 4093 egress-port (port)
10 Specify the egress ports which should transmit packets for the SHub management
VLAN as untagged with the following command:
configure vlan shub id 4093 untag-port (network-port)
11 Configure the bridge port with the following command:
configure bridge shub port (network-port) pvid 4093
Configuration example for dynamic configuration via BOOTP (for

tagged network):
configure system id SystemID02 no single-public-ip
configure system management host-ip-address bootp
configure interface shub port 7 port-type network
configure system shub entry ip ip-cfg-mode dynamic
configure vlan shub id 4093 egress-port network:7
configure bridge shub port 7 pvid 4093
Configuration example for static configuration via manual

configuration (for tagged network):
configure system id SystemID02 no single-public-ip
configure system management host-ip-address

manual:10.177.0.112/17
show vlan global
configure system shub entry ip ip-cfg-mode manual
configure system management default-route 10.177.127.254
configure interface shub vlan-id 4093 admin-status down
configure interface shub ip 4093 ip-addr 10.177.0.113/17
configure interface shub vlan-id 4093 admin-status up

next-hop 10.177.127.254 vlan-id 4093
DLP 103 Configure system
parameters
Purpose
This document describes the procedure to configure system parameters on the system
and on the SHub, such as:
System and SHub ID

SNTP
date and time
system clock management
error log handling
Note The following applies for the commands shown below:
If names with blanks are used, these names have to be enclosed in

captions ().
Procedure
Proceed as follows to configure the system parameters:
1 Configure the system ID parameters with the following command:

name <PrintableString-0-255>
location <PrintableString-0-255>
contact-person <PrintableString-0-255>
(no) en-snmp-auth-trap <Transport::SnmpAuthTraps>
(no) ether-shape-rate <Sys::etherShapeRate>
mgnt-vlan-id <Vlan::VlanId>
system-mac <Sys::MacAddr>/<Sys::MacAddr>/<Sys::Range>
(no) single-public-ip
(no) port-num-in-proto <Sys::PortNumberInprotocol>
Note 1 The numbering scheme for the line ID format is configured

with the parameter port-num-in-proto. For a more detailed explanation on
the different numbering schemes, see TNG 115.
Note 2 The system MAC address must only be configured when the
system has no System MAC Address Storage (SMAS) functionality (that
is, when no SMAS board or GFC board are present in the system).
2 Configure the SHub ID with the following command:
configure system shub entry id

contact <PrintableString>
location <PrintableString>
3 If necessary, configure the system loop ID syntax with the following command:
configure system loop-id-syntax

(no) atm-based-dsl <Sys::AtmBasedDsl>
(no) efm-based-dsl <Sys::EfmBasedDsl>
Note For the loop ID syntax:
The parameter atm-based-dsl defines the syntax of the loop ID for

ATM based DSL lines. The default value is
Access_Node_ID atm Rack/Frame/Slot/Port:VPI.
The parameter efm-based-dsl defines the syntax of the loop ID for
EFM based DSL lines. The default value is
Access_Node_ID efm Rack/Frame/Slot/Port.
4 To configure the system time, do one of the following:
a Set the system time with the following command:
admin sntp system-time <Sys::Time>
b Configure SNTP on the LT shelf with the following command:
configure system sntp

server-ip-addr <Ip::V4Address>
(no) server-port <Sys::portNumber>
(no) polling-rate <Sys::pollingRate>
enable
(no) timezone-offset <Sys::timeZoneOffset>
5 Configure the system clock source and the clock source priority scheme with the
following command:
configure system clock-mgmt

(no) priority-scheme <Sys::SysClkSrcPriorityScheme>
(no) ext-source <Sys::SysClkExtSource>
Note The last parameter is not available on 7330 ISAM FTTN

systems.
6 Configure the error log handling with the following command:
configure error
(no) log-full-action <Error::errorLogFullAction>
7 View information about the SNTP and its related parameters with the following
command:
show sntp
configure system id SystemID02 name Test_Asam location Magabir

contact-person Ewan Tendunnit (Phone ext 345) mgnt-vlan-id 4093
configure system shub entry id contact Hugh Shuckman (Phone ext

003) location Magabir
configure system loop-id-syntax atm-based-dsl

Access_Node_ID atm Rack-Frame-Slot-Port:VPI.VCI
configure system loop-id-syntax efm-based-dsl

Access_Node_ID eth Rack-Frame-Slot-Port:0.0
admin sntp system-time 2007-01-01:23:55:00
configure system sntp server-ip-addr 10.176.5.5 enable

timezone-offset 6
configure system clock-mgmt priority-scheme local
configure error log-full-action wrap
show sntp
Note
This procedure is redundant and has been incorporated in DLP 175 and DLP 102 from
Release 3.1 on.
DLP 105 Configure link aggregation
usage
Purpose
Link aggregation or trunking is a method of combining physical network links into a single
logical link for increased bandwidth.
The following link aggregation combinations can be used in the NE:
Network links:
The number of aggregation links depends on the NT board type
For ECNT-A: an aggregation can exist of maximum 7 component links.
For ECNT-C, NANT-A: an aggregation can exist of maximum 8 component links.
Subtending links:
For an FE type link or a GE type link, an aggregation can exist of maximum 7
component links
Note Link aggregation cannot be used for user links.
This document describes the procedure to configure the link aggregation usage.
General
This node allows specification of Link Aggregation Group parameters.
A Link Aggregation Group is identified by means of the primary link, also referred to as
aggregator-port. The primary link for an Aggregation Group is the link with the lowest port
number within the group, provided the operational state of the link is UP.
The configuration should be performed for the primary link. The settings configured for
the primary link of the Aggregation Group apply to each and every link that is a member
of the Link Aggregation Group.
The link which is denoted as primary link may change during the lifetime of the
aggregation group. To cope with this phenomenon, the operator is advised to repeat the
configurations described in this procedure for each link of the Aggregation Group. Care
must be taken to configure identical settings for all links within the Aggregation Group.
Prerequisite
The following prerequisites must be fullfilled before link aggregation can be configured:
The port-type of the network port must be network or subtending.
This can be verified with the command
and, if necessary, changed with the command
configure interface shub port (network-port) port-type <Sys::Type>
Procedure
Proceed as follows to configure link aggregation usage:
1 Specify the Link Aggregation Group parameters with the following command:
configure la aggregator-port (network-port)

name <Shub::AggName>
(no) link-up-down-trap
(no) actor-sys-prio <Shub::LaPortActorSysPriority>
selection-policy <Shub::AggSelectPolicy>
actor-key <Shub::LacpKey>
(no) actor-port-prio <Shub::LaPortActorPortPriority>
(no) active-lacp
(no) short-timeout
(no) aggregatable
lacp-mode <Shub::LacpMode>
2 Use the following command to configure Link Aggregation on the SHub. It merely
allows to enable or disable the Link Aggregation feature:
configure la no disable-lacp
Note This command is only necessary if the Link Aggregation system

was shut down manually. By default, Link Aggregation is enabled.
3 If necessary, use the following command to disable Link Aggregation:
configure la disable-lacp
4 View information for a Link Aggregation Group configured on the Service Hub with
the following command:
show la aggregator-info (port)
5 View information for a member of a Link Aggregation Group configured on the

Service Hub with the following command:
show la network-port-info (port)
configure interface shub port [1...2] port-type subtending
configure la aggregator-port [1...2] aggregatable name testsub

lacp-mode enable-lacp active-lacp actor-key 1234
link-up-down-trap
configure la no disable-lacp
show la aggregator-info [1...2]
show la network-port-info [1...2]
Note
This procedure is no longer valid and is replaced by DLP 200 from R3.3/FGN 3.4 on.
Purpose
This procedure provides the steps to configure Open Shortest Path First (OSPF)
management on the NE.
General
An OSPF network is divided into areas. These are logical groupings of routers whose
information may be summarized towards the rest of the network. Several special area
types are defined:
Backbone area:
The backbone area (also known as area zero) forms the core of an OSPF network.
All other areas are connected to it, and inter-area routing happens via a router
connected to the backbone area. It is the logical and physical structure for the
Autonomous System (AS) and is attached to multiple areas. The backbone area is
responsible for distributing routing information between non-backbone areas. The
backbone must be contiguous, but it does not need to be physically contiguous;
backbone connectivity can be established and maintained through the configuration
of virtual links.
Note: All OSPF areas must connect to the backbone area
Stub area:
A stub area is an area which does not receive external routes. External routes are
defined as routes which were distributed in OSPF from another routing protocol.
Therefore, stub areas typically need to rely on a default route to send traffic to routes
outside the present domain. This implies that AS external routes are not fed into stub
areas
Not-so-stubby area:
A not-so-stubby area (NSSA) is a type of stub area that can import AS external routes
and send them to the backbone, but cannot receive AS external routes from the
backbone or other areas.
Procedure
Proceed as follows to configure OSPF management:
1 Configure the OSPF parameters and attributes with the following command:
configure ospf enable

router-id <Ip::V4Address>
(no) as-border-router
(no) enable-opaque-lsa
(no) overflow-state-it <Ospf::OvrflowIntrvl>
(no) dis-rfc1583-comp
(no) abr-type <Ospf::AbrType>
(no) passive-interface
2 Configure the OSPF backbone area parameters:
i Configure the OSPF backbone area ID:
configure ospf area (area-id)
ii Configure the OSPF interface parameters with the following command:
configure ospf area (area-id) interface (ip-addr)

(no) disable
(no) router-priority <Ospf::Priority>
(no) passive
(no) itf-type <Ospf::ITFType>
(no) authentication <Ospf::AuthType>
iii Configure the OSPF interface timers with the following command:
configure ospf area (area-id) interface (ip-addr) timers

(no) transit-delay <Ospf::TransDelay>
(no) retransmit-itvl <Ospf::RetransIntvl>
(no) hello-interval <Ospf::HelloIntvl>
(no) dead-interval <Ospf::DeadIntvl>
(no) poll-interval <Ospf::PollIntvl>
iv When MD5 is selected as authentication mode for an OSPF interface, use the
following command to configure the MD5 key:

md5-key (index)
key prompt | plain: <Ospf::MD5key>
| encrypted: <Ospf::MD5encryptedKey>
(no) accept-starts <Ospf::MD5startDelay>
(no) generate-starts <Ospf::MD5startDelay>
v Confirm the MD5 authentication with the following command:

authentication md5
Note If MD5 authentication is to be implemented, first the MD5 key

must be set using the command in step iv, then the command from step v
must be implemented.
Both commands must be implemented for MD5 authentication.
vi Configure the metric for an OSPF interface with the following command:

(no) metric value <Ospf::Metric>
vii Inter-area route summarization is done on ABRs and it applies to routes from
within the AS. It does not apply to external routes injected into OSPF via
redistribution. In order to take advantage of summarization, network numbers
in areas should be assigned in a contiguous way to be able to lump these
addresses into one range. Configure an OSPF aggregate with the following
command:
configure ospf area (area-id) aggregate-addr (dest-ip)

(no) omit-advertise
viii External route summarization is specific to external routes that are injected into
OSPF via redistribution. Also, make sure that external ranges that are being
summarized are contiguous. Summarization overlapping ranges from two
different routers could cause packets to be sent to the wrong destination.
Configure an OSPF aggregate from external autonomous system with the
following command:
configure ospf area (area-id) extern-aggr-addr (dest-ip)

(no) advertise <Ospf::ExtAggregateEffect>
3 Configure the OSPF stub area parameters:
i Configure the OSPF stub area with the following command:
configure ospf stub-area (area-id)

(no) metric-type <Ospf::MetricType>
(no) metric <Ospf::StubMetric>
(no) summary]
ii Configure the OSPF stub area interface with the following command:
configure ospf stub-area (area-id) interface (ip-addr)

(no) disable
(no) passive
iii Configure the OSPF stub area interface timers with the following command:
configure ospf stub-area (area-id) interface (ip-addr) timers

iv When MD5 is selected as authentication mode for an OSPF stub area

interface, use the following command to configure the MD5 key:

md5-key (index)
key <Ospf::AuthTypeMd5>

authentication md5


vi Configure the metric for an OSPF stub area interface with the following
command:

vii Configure an OSPF stub aggregate with the following command:
configure ospf stub-area (area-id) aggregate-addr (dest-ip)

(no) omit-advertise
4 Configure the OSPF NSSA area parameters with the following command:
i Configure the OSPF NSSA area with the following command:
configure ospf nssa-area (area-id)

(no) summary
(no) translation <Ospf::Trnsltn>
(no) trans-itvl <Ospf::TrnltnIntvl>
(no) asbr-rtr-trans
(no) metric-type <Ospf::NSSAMetricType>]
ii Configure the OSPF NSSA area interface with the following command:
configure ospf nssa-area (area-id) interface (ip-addr)

(no) disable
(no) passive
iii Configure the OSPF NSSA area interface timers with the following command:
configure ospf nssa-area (area-id) interface (ip-addr) timers


iv When MD5 is selected as authentication mode for an OSPF NSSA area

interface, use the following command to configure the MD5 key:

md5-key (index)
key <Ospf::AuthTypeMd5>

authentication md5


vi Configure the metric for an OSPF NSSA area interface with the following
command:

vii Configure an OSPF NSSA aggregate with the following command:
configure ospf nssa-area (area-id) aggregate-addr (dest-ip)

lsa-type <Ospf::LSAType>
(no) omit-advertise
viii Configure an OSPF NSSA aggregate from external autonomous systems with
configure ospf nssa-area (area-id) extern-aggr-addr (dest-ip)

(no) advertise <Ospf::ExtAggregateEffect>
5 Configure the redistribution of the OSPF with the following command:
configure ospf redistribution

(no) enable
(no) local
(no) static
(no) rip
6 Configure the redistribution of the OSPF route parameters with the following
command:
configure ospf redistribution route-destination (dest-ip)

(no) metric-type <Ospf::RouteMetricType>
(no) metric <Ospf::RouteMetric>
7 Display the different OSPF values with the following commands:
show ospf area detail
show ospf link-state-adv link-type detail
show ospf link-state-adv asbr-external detail
show ospf interface detail
show ospf neighbour detail
show ospf routing-table detail
show ospf statistics detail
show ospf status detail
configure interface shub port [4...5] port-type network
configure ip shub vrf 15 name routervrf15
fast-path-mode:dis-user-user-com
configure vlan shub id 70 mode layer2-term-nwport
configure interface shub vlan-id 70
configure interface shub ip 70 vrf-id 15
configure interface shub vlan-id 70 admin-status auto-up
configure interface shub vlan-id 80 admin-status auto-up
configure ospf enable
configure ospf router-id 192.168.70.39 as-border-router
configure ospf area 0.0.0.0
configure ospf area 0.0.0.0 interface 192.168.70.39
configure ospf area 0.0.0.0 interface 192.168.70.39 md5-key 2 key

plain:ALCATEL

authentication md5

metric value 10

metric value 10
configure ospf redistribution enable
configure ospf redistribution static
configure ospf redistribution local
configure ospf stub-area 1.1.1.1 metric 1 metric-type
ospf summary
configure ospf nssa-area 2.2.2.2
configure ospf as-border-router
configure ospf abr-type standard
show ospf area detail
show ospf link-state-adv link-type detail
show ospf link-state-adv asbr-external detail
show ospf interface detail
show ospf neighbour detail
show ospf routing-table detail
show ospf statistics detail
show ospf status detail
Purpose
This procedure provides the steps to configure Routing Information Protocol (RIP)
management on the NE.
Limitations
The following limitations apply:
RIP support is only offered for IPoA interfaces.

Only plain RIP messages will be handled, the triggered RIP protocol is not supported.
RIP message propagation is enabled/disabled on the user gateway interface of the
SHub, not per user PVC.
Procedure
Proceed as follows to configure RIP management:
1 Configure the maximum number of peers that can be simultaneously in

conversation with the RIP2 with the following command:
configure rip max-peer <Rip::Rip2Peer>
2 Configure RIP distribution with the following command:
configure rip redistribution

(no) enable
(no) default-metric <Rip::RouteMetric>
(no) local
(no) static
(no) ospf
Note 1 RIP redistribution enables or disables RIP to participate in

Route Redistribution.
If set to enabled then RIP will start advertising the routes learned by
other protocols.
If set to disabled then RIP will stop the redistribution of routes but will
continue to send updates to the VRF routing table.
Note 2 The protocols from which the routes have to be imported to

RIP:
Local: the routes have to be imported from the local interface.

Static: the routes have to be imported from the static route.
OSPF: the routes have to be imported from OSPF.
Note 3 RIP redistribution filters apply to all interfaces

3 Configure RIP interface parameters with the following command:
configure rip interface (ip-addr)

(no) authentication <Rip::AuthType>
default-metric <Rip::DefMetric>
(no) send <Rip::ConfSend>
(no) receive <Rip::ConfRcv>
(no) split-horizon <Rip::SpltHorizon>
4 Configure the RIP interface timers with the following command:
configure rip interface (ip-addr) timers

(no) update-timer <Rip::UpdateTmr>
(no) route-age-out <Rip::RouteAgeTmr>
(no) junk-collection <Rip::GrbTmr>
5 If the MD5 authentication method is selected for a RIP interface (see step 5), then
the MD5 key can be configured with the following command:
i Configure the MD5 key wit the following command:
configure rip interface (ip-addr) md5-key (index)

key <Rip::AuthTypeMD5>
starts <Rip::MD5startDelay>
expires <Rip::MD5expiryDelay>
ii Confirm the MD5 configuration with the following command:
configure rip interface (ip-addr)

authentication md5

must be set using the command in step i, then the command from step ii
6 An MD5 key for a RIP interface can be managed with the following command:
admin rip interface (ip-addr) md5-key <Rip::Md5KeyIndex>

expires <Rip::MD5expiryDelay>
7 Add or delete a route aggregation with the following command:
configure rip (no) aggregation (ip-addr)
8 Define a route map with the following command:
configure rip route-map (vlan-id) sub-index <Rip::SubIndex>

(no) direction <Rip::RouteMapDirection>
(no) deny
9 View the information for RIP with the following command:
show rip statistics
show rip peer
show rip routing-table
show rip global
configure rip max-peer 20
configure rip redistribution enable default-metric 2
configure rip interface 192.168.80.39 default-metric 1 receive

rip2
send rip2 split-horizon poison-reverse
configure rip interface 192.168.80.39 timers update-timer 30
route-age-out 180 junk-collection 120
configure rip interface 192.168.80.39 md5-key 4

key plain:AlcatelTest expires 2147483647 starts 0
configure rip interface 192.168.80.39 authentication md5
configure rip redistribution enable static ospf
configure rip route-map 70 sub-index 1 ip-addr 192.168.145.1/32
no deny
show rip statistics
show rip peer
show rip routing-table
show rip global
DLP 109 Configure SNMP and trap
management
Purpose
SNMP
SNMP uses community names as a kind of password without user name to verify if a
request may be executed or not.
Note The following conditions must be fulfilled:
There must be at least one community with read-write privileges

An existing community cannot be modified.
Trap management
An SNMP manager will receive traps when an event occurs in the system.
The manager can be easily flooded by events in the case where something happens with
the system. It can be specified in which traps the manager is interested (trap filtering) and
how the traps must be spread in time (trap shaping).
Traps that can not be delivered will be dropped:
cold-start
link-down
link-up
auth-failure
change-occurred
init-started
license-key-change-occurred
You can also set the minimum priority to be reported when a trap occurs. The priority can
be urgent, high, medium, or low.
security:
It is NOT advised to use insecure management channels such as

SNMPv1 or SNMPv2.
If SNMPv1/2 is used anyway, it is advised not to use community string
= public
It is advised to use secure management channels such as SNMPv3.
Procedure
Proceed as follows to configure SNMP and trap management:
1 Configure a view of a subtree with the following command:
configure system security snmp view (notify-view)

subtree <Snmp::ViewSubtree>
type <Snmp::FilterType>
2 Configure the SNMP community name with the following command:
configure system security snmp community (name)

host-address <Ip::V4Address>/<Ip::PrefixLengthFull>
(no) context <Transport::Context>
(no) privilege <Snmp::CommunityPrivilege>
(no) read-view <Snmp::ViewName>
(no) write-view <Snmp::ViewName>
(no) notify-view <Snmp::ViewName>
a If SNMP version 1 or version 2 is used, continue with step 7.
b If SNMP version 3 is used, continue with step 4.
4 Configure an SNMPv3 group with the following command:
configure system security snmp group (name)

security-level <Snmp::SecurityLevel>
context single : nt | shub | epon | all
(no) read-view <Snmp::ViewName>
(no) write-view <Snmp::ViewName>
(no) notify-view <Snmp::ViewName>
5 Configure an SNMPv3 user with the following command:
configure system security snmp user (name)

(no) authentication none | [md5|sha1]:prompt
| [md5|sha1]:plain:<Sec::PlainPassword>
| [md5|sha1]:encrypted:<Snmp::AuthEncryptedKey>
(no) privacy none | des:prompt | des:plain:<Sec::PlainPassword>
| des : encrypted : <Snmp::PrivacyEncryptedKey>
(no) public <Snmp::Identifier>
6 Map an SNMPv3 user to an SNMPv3 group with the following command:
configure system security snmp map-user-group (name)

group-name <Snmp::GroupName>
7 Configure an SNMP notification profile with the following command:
configure system security snmp notify-profile (name)

snmp-version v1 : <Snmp::CommunityString>
| v2 : <Snmp::CommunityString>
| v3 : <Snmp::SecurityName>: none | authentication
| privacy-and-auth
8 Configure a filter for a notification profile with the following command:
configure system security snmp notify-profile (name)

filter notify-view <Snmp::ViewName>
9 Configure an SNMP element manager with the following command:
configure system security snmp manager (name)

destination <Snmp::IpAddress>:<Snmp::AddressPort>
notify-profile <Snmp::NotifyProfile>
(no) nt
(no) shub
(no) epon
10 Configure community names on the SHub with the following command:
configure system security snmp shub community (index)

(no) privilege <Snmp::SHubCommunityPrivilege>
(no) ip-addr <Ip::V4Address>
11 Configure the SNMP trap manager with the following command:
configure trap manager <Ip::V4Address> : <Trap::Port>

(no) priority <Trap::Priority>
(no) cold-start-trap
(no) link-down-trap
(no) link-up-trap
(no) auth-fail-trap
(no) change-trap
(no) init-started-trap
(no) lic-key-chg-occr
(no) alarm-chg-trap
(no) phys-line-trap
(no) eqpt-change-trap
(no) success-set-trap
(no) other-alarm-trap
(no) warning-trap
(no) minor-trap
(no) major-trap
(no) critical-trap
(no) redundancy-trap
(no) eqpt-prot-trap
(no) max-per-window <Trap::WindowCount>
(no) window-size <Trap::WindowSize>
(no) max-queue-size <Trap::QueueSize>
(no) min-interval <Trap::Interval>
(no) min-severity <Alarm::alarmSeverity>
12 Configure an SNMP manager of the SHub with the following command:
configure trap shub manager <Ip::V4Address> : <Trap::Port>

(no) cold-start-trap
(no) auth-fail-trap
(no) change-trap
(no) community-string <PrintableString-0-255>
(no) snmp-version <Snmp::SHubVersion>
(no) min-severity <Snmp::SHubAlarmSeverity>
13 Configure the trap definition table with the following command:
configure trap definition (name) priority <Trap::Priority>
14 If necessary, reset the trap table with the following command:
admin trap manager <Ip::V4Address> : <Trap::Port>

reset-trap-buffer
Example for SNMPv1 or SNMPv2:
configure system security snmp view view1 subtree * type include
configure system security snmp view view1

subtree 1.3.6.1.4.1.637.61.1.48.* type exclude
configure system security snmp community public

host-address 10.176.0.0/15 context nt privilege read-write
configure system security snmp community NETMAN

host-address 10.176.0.0/15 context shub
configure system security snmp community comm1

host-address 10.176.0.0/15 context nt read-view protected
write-view view1 notify-view everything
configure system security snmp shub community 3 name NETMAN

privilege read-write ip-addr 10.176.8.8
configure system security snmp notify-view nview1 subtree *

type include
configure system security snmp notify-view nview1

subtree bondingMIB.* type exclude
configure system security snmp notify-profile nprof1
snmp-version v1:trapcomm
configure system security snmp notify-profile nprof1 filter

notify-view nview1
configure system security snmp manager Manager01

destination 10.176.25.25:6666 notify-profile nprof1 nt shub
configure trap manager 10.176.25.25:6666 cold-start-trap

auth-fail-trap eqpt-change-trap warning-trap minor-trap
major-trap critical-trap min-severity warning
configure trap definition auth-failure priority high
admin trap manager 10.176.25.25:6666 reset-trap-buffer
Example for SNMPv3:
configure system security snmp view view2 subtree * type include
configure system security snmp view view2 subtree bondingMIB.*

type exclude
configure system security snmp view view2

subtree .1.3.6.1.4.1.637.61.1.48.10.1.* type include

host-address 10.176.0.0/15 context nt privilege read-write

configure system security snmp community comm1

host-address 10.176.0.0/15 context nt read-view protected
write-view view1 notify-view everything

configure system security snmp group Group1 security-level none

context all read-view protected write-view nothing
configure system security snmp group Group1 security-level

privacy-and-auth context all read-view protected
write-view everything
configure system security snmp user user1

authentication md5:plain:pswuser1 privacy des:plain:priuser1
configure system security snmp map-user-group user1 group-name

Group1
configure system security snmp notify-view nview2 subtree * type

include

subtree bondingMIB.* type exclude
subtree 1.3.6.1.4.1.637.61.1.48.10.1.* type include
configure system security snmp notify-profile nprof2

snmp-version v3:snmpuser1:privacy-and-auth
configure system security snmp notify-profile nprof2 filter

notify-view nview2
configure system security snmp manager Manager02

destination 10.176.25.25:6666 notify-profile nprof2 nt shub epon
configure trap manager 10.176.25.25:6666

cold-start-trap auth-fail-trap eqpt-change-trap warning-trap
minor-trap major-trap critical-trap min-severity warning
configure trap definition auth-failure priority high
admin trap manager 10.176.25.25:6666 reset-trap-buffer
Purpose
This procedure provides the steps to manage the alarms in the NE.
Alarm management includes:
Managing the alarm logs

Configuring an alarm profile for remote LT boards:
If required, an external alarm profile can be configured. This alarm profile can be
assigned to a remote LT board. The profile reflects a configuration of external alarms
parameters that corresponds to a certain environment where the remote board is
located (in an outdoor cabinet, basement cabinet,...). The use of a profile avoids the
need to specify the parameters for each remote board separately. The alarm profile
groups all five external alarms parameters. The profile contains a
description/meaning of each alarm, as well as an indication that tells us whether or
not any alarm outputs are to be triggered if the corresponding external input alarm is
raised. On top of these parameters, a mnemonic (short for the description), the
polarity and the severity are configurable.
Note The commands for viewing the different alarms are described in
DLP 155.
Prerequisite
The following prerequisite must be fullfilled:
The board must have been planned; see DLP 111.
Procedure
Proceed as follows to manage alarms:
1 Manage the alarm logs as follows:
i Configure the alarm log settings (alarm severity level, action to be taken when
the log buffer is full, minimum severity level for non-interface alarms) with the
following command:
configure alarm
log-sev-level <Alarm::alarmSeverity>
log-full-action <Alarm::alarmLogFullAction>
non-itf-rep-sev-level <Alarm::alarmSeverity>
ii Modify the alarm severity and actions on individual alarms with the following
command:
configure alarm entry (index)

severity <Alarm::alarmSeverity>
(no) service-affecting
(no) reporting
(no) logging
iii Configure the action to be taken when the alarm log buffer is completely full
with the following command:
configure alarm delta-log

indet-log-full-action <Alarm::alarmDeltaLogFullAction>
warn-log-full-action <Alarm::alarmDeltaLogFullAction>
minor-log-full-action <Alarm::alarmDeltaLogFullAction>
major-log-full-action <Alarm::alarmDeltaLogFullAction>
crit-log-full-act <Alarm::alarmDeltaLogFullAction>
If the action is set to Wrap, then older log records are overwritten by recent ones.
If the action is set to Halt, then logging is stopped until the log buffer is reset.
iv Configure interface management parameters with the following command:
configure interface port (port)

(no) admin-up
(no) link-updown-trap
(no) user <Itf::asamIfExtCustomerId>
(no) severity <Itf::asamIfExtAlmReportingSeverity>
v Configure the default severity for an alarm on a type of interface with the
following command:
configure interface alarm (index)

(no) default-severity
<Itf::asamIfExtAlmReportingSeverityDefault>
vi Configure the alarm SHub parameters with the following command:
configure alarm shub entry (index)

severity <Alarm::alarmSeverity>
(no) service-affecting
(no) reporting
2 Configure an alarm profile for remote LT boards with the following command:
configure alarm custom-profile (name)

(no) mnemonic1 <Alarm::AlarmMnemonic>
(no) description1 <Alarm::AlarmDescription>
(no) visible1 <Alarm::VisibleOutput>
(no) audible1 <Alarm::AudibleOutput>
(no) polarity1 <Alarm::InversePolarity>
(no) severity1 <Alarm::AlarmSeverity>
configure alarm log-sev-level warning log-full-action wrap

non-itf-rep-sev-level minor
configure alarm entry xdsl-act-not-feas severity major

service-affecting reporting logging
configure alarm entry no-bonding-cpe severity major

service-affecting reporting logging
configure alarm delta-log indet-log-full-action wrap

warn-log-full-action wrap minor-log-full-action wrap
major-log-full-action halt crit-log-full-act halt
configure interface port xdsl-line:1/1/5/12 severity major
configure interface alarm xdsl-line default-severity critical
DLP 111 Plan, replan, and unplan
equipment
Purpose
This document describes the procedure to be used to plan, replan, and unplan
equipment.
The following applies for the commands used below:
The main subrack can not be planned or unplanned.

The extension subrack depends on the main subrack. For example, no extention
subrack for XD equipment.
The active NT (NT-A) can not be planned or unplanned.
To replan equipment (except NTs), it must first be unplanned before it can be
replanned. Use the same command as for configuring equipment.
Note 1 Refer to TNG 106 for more information on the planning of

remote expansion units.
Note 2 The configuration examples in this procedure use the default

slot numbering scheme (legacy-based). Refer to TNG 115 for more
information on slot numbering schemes.
Procedure
Proceed as follows to plan, replan, and unplan equipment:
1 Plan units in main subracks as follows:
i Plan a subrack with the following command:
configure equipment shelf (index)

class <Equipm::ShelfClass>
planned-type <Equipm::ShelfType>
unlock
(no) lock
(no) extended-lt-slots
(no) description <Description-127>
Note The parameter extended-lt-slots is only applicable for Flexible

Density (FD) subracks. For more information on FD subracks, see the
Product Information.
ii For each plug-in unit other than an applique, plan the unit in any given slot
position with the following command:
configure equipment slot (index)

planned-type <Equipm::BoardType>
(no) power-down
(no) unlock
(no) alarm-profile <Equipm::AlarmProf>
capab-profile <Equipm::CapabilityProfile>
Note The possible values for the parameter capab-profile depend

on the actual configuration and software.
The currently allowed values can be shown with online-help.

iii If necessary, for each applique, plan the unit with the following command:
configure equipment applique (index)

planned-type <Equipm::AppliqueType>
2 Unplan a subrack with the following command:
i If necessary, unplan an applique with the following command:
configure equipment applique (index)

no planned-type
ii Unplan a plug-in unit other than an applique in any given slot position with the
following command:

no planned-type
iii Unplan a subrack with the following command:

no planned-type
Note The main subrack cannot be planned or unplanned, only the

description can be changed.
3 Plan remote equipment (such as remote subracks, REM or SEM) as follows:
i If not done already, plan the I/O NT unit in the host subrack with the following
command:
configure equipment slot acu:<Eqpt::RackId>/<Eqpt::ShelfId>

ii Plan the remote subrack with the following command:
configure equipment shelf <Eqpt::RackId>/<Eqpt::ShelfId>

planned-type <Equipm::ShelfType>
iii Configure the SFP downlink port to the remote LT(and SHub VLAN) with the
following command:
configure equipment external-link-assign (sfp-index)

remote <Eqpt::ExpRack>/<Eqpt::ExpShelf>/<Eqpt::ExpSlot>
Note The range for the parameter sfp-index depends on the NT

board type, see TNG 106 subsection SFP port mapping for more
information.
iv Plan the remote LT with the following command:
configure equipment slot

<Eqpt::ExpRack>/<Eqpt::ExpShelf>/<Eqpt::ExpSlot>
4 Unplan remote equipment (such as remote subracks, REM or SEM) as follows:
i Unconfigure the SFP downlink port with the following command:

no remote
ii Unplan the remote LT with the following command:
configure equipment slot acu:<Eqpt::RackId>/<Eqpt::ShelfId>

planned-type not-planned
iii Unplan the remote subrack with the following command:
configure equipment shelf <Eqpt::RackId>/<Eqpt::ShelfId>

planned-type not-planned
5 View the slot status with the following command:
show equipment slot
Configuration example for planning a subrack:
configure equipment shelf 1/1 description "***Mainshelf***"
configure equipment slot 1/1/1 planned-type aacu-c
configure equipment slot nt-b planned-type ecnt-c
configure equipment applique iont:1/1 planned-type ecnc-a
configure equipment slot lt:1/1/4 planned-type evlt-c
configure equipment slot lt:1/1/5 planned-type eblt-c
configure equipment slot lt:1/1/6 planned-type polt-b
configure equipment slot lt:1/1/7 planned-type eblt-k
configure equipment slot lt:1/1/8 planned-type eblt-k
configure equipment slot 1/1/9 planned-type smlt-k
info configure equipment slot flat
show equipment slot
Configuration example for planning a remote subrack:
configure equipment slot acu:1/1 planned-type genc-e
configure equipment shelf 3/1 planned-type rems-a
configure equipment external-link-assign 10 remote 3/1/4
configure equipment slot 3/1/4 planned-type rvlt-a
Configuration example for unplanning a remote subrack:
configure equipment slot 3/1/4 planned-type not-planned
configure equipment external-link-assign 10 no remote
configure equipment shelf 3/1 planned-type not-planned
configure equipment slot acu:1/1 planned-type not-planned
Configuration example for planning multiple remote subracks:
configure equipment applique iont:1/1 planned-type ncnc-c
Configuration example for unplanning multiple remote subracks:
Purpose
This procedure provides the steps to lock and unlock plug-in units.
Procedure
Proceed as follows to lock and unlock a plug-in unit:
1 Lock a plug-in unit with the following command:

no unlock
2 Unlock a plug-in unit with the following command:

unlock
configure equipment slot 1/1/5 no unlock
configure equipment slot 1/1/5 unlock
Purpose
The system will auto-configure a number of equipment items and detect the presence of
the equipment at startup. It may therefore not be necessary to configure or reconfigure
all equipment. The procedure in this section is a guideline only.
Refer to the CLI Commands and Messages document for a complete description of the
commands used in this procedure.
Procedure
Proceed as follows to configure the NE equipment:
1 Configure the description of the system with the following command:
configure equipment isam

(no) description <Description>
2 Configure the rack with the following command:
configure equipment rack <Eqpt::Rack>

(no) description <Description>
3 Configure the subrack or shelf with the following command:

class <Equipm::ShelfClass>
(no) planned-type
(no) unlock
(no) extended-lt-slots
(no) description <Description-127>
4 Enable or disable environment monitoring with the following command:
configure equipment envbox

(no) enable-supervise
5 Use any of the following commands to view and verify the configuration of the
system:
show equipment isam detail
This command shows the system configuration and status. This configuration is
fixed and hardcoded.
show equipment rack (rack) detail
This command shows the rack configuration and status.
show equipment shelf (shelf) detail
This command shows the shelf configuration and status.
show equipment slot (slot) detail
This command shows the configuration and status of all slots.
show equipment applique (applique) detail
This command shows the configuration and status of all appliques.
show equipment capab-profile (profilename) detail
This command shows the profile-id associated with a profile name, the description
of the profile and the board type associated with a given profile.
configure equipment isam description Magabir Plant
configure equipment rack 1 description ***Main Rack***
configure equipment shelf 1/1 description Testshelf_Antwerp
configure equipment envbox enable-supervise
show equipment rack 1 detail
show equipment shelf 1/1 detail
show equipment slot 1/1/5 detail
show equipment applique 1/1/2 detail
Purpose
The NE supports line protection and Equipment Protection Switching (EPS). EPS is a
mechanism that provides protection against internal failure of the active NT board, if a
second redundant NT board is equipped (NT redundancy).
For EPS, the concept of protection group is used.
A protection group is a group composed of protection and working elements, where the
protection element takes over the functionalities of a working element in case it is needed
(for example, failure of the working element).
For NT redundancy, the protection group consists of both protection elements. Each
element represents one NT board. In general, protection elements are defined on
slot-level. The protection group and elements are created implicitly by the system, as part
of the default configuration.
Procedure
The following commands can be used to configure NT redundancy or to view the NT
redundancy configuration:
1 Configure the administrative status of the protection group with the following
command:
configure equipment protection-group (index)

(no) admin-status <Equipm::PortGroupAdminStatus>
(no) eps-quenchfactor <TimeTicks>
Note 1 The default administrative status of the protection group is

unlocked (that is, NT redundancy is enabled).
If NT redundancy is not required, then NT redundancy must be

specifically disabled to avoid missing redundancy alarms. Use the
following command:
configure equipment protection-group 1 admin-status lock
Note 2 For the parameter eps-quenchfactor:
This timer is used to prevent continuous switchovers in case of unstable

EPS and APS. The following must be observed when configuring this
timer:
The value 0 is used to disable the EPS quenchfactor timer.

The default value is 1440000 (in units of 1/100 seconds). This is a very
large value (1440000 = 4 hours). This means that there will be a delay
of 4 hours between 2 subsequent operational NT switchover events.
You should set this value up front to a more normal value of, for
example, 10 seconds (= 1000)
2 Configure the redundancy control status of a protection group element with the
following command:
configure equipment protection-element (index)

(no) redcy-ctrl-status <Equipm::ProtElementRedcyCtrlStatus>
3 Configure the ports of an SHub interface as follows:
i Configure the parameters related to port control configuration of an SHub

interface with the following command:

(no) mode <Sys::PortCtrlMode>
(no) port-type <Sys::Type>
(no) mc-flooding
ii Set the adminstrative status of the port(s) to up with the following command:

admin-status up
4 Configure redundancy (Link protection and Equipment protection can be coupled or

decoupled) in the SHub as follows:
i Configure the NT 1+1 protection group on the SHub with the following
command:
configure interface shub group (group-id)
ii Lock the protection group (the system must be in hot-standby configuration

first) with the following command:
configure equipment protection-group (group-id) admin-status

lock
Note The NT protection group must be locked to avoid the immediate

switchover which occurs while configuring the SHub uplink-group
threshold value from the default value 0 (= no coupled APS/EPS) towards
a value > 1. This switchover would result in an SHub configuration loss.
iii Add 1 (or more) network port(s) to the NT 1+1 protection group with the
following command:
configure interface shub group (group-id) port (port)
iv By default, there is no APS-EPS coupling in the NE. That means that the
minimum number of links to be in state operational UP in the protection-group
is 0 by default. Or in other words, a link failure will not trigger a switchover from
the active NT to the standby NT.
If a coupling is required (that is NT switchover in case of link failure), the SHub
has to be configured with a threshold > 0 as follows:
configure interface shub group (group-id)

threshold <Itf::Threshold>
v Unlock the protection group with the following command:
configure equipment protection-group (group-id) admin-status

unlock
5 You can view the protection group configuration parameters with the following
command:
show equipment protection-group (prot-group-id)
6 You can view the protection element configuration parameters with the following
command:
show equipment protection-element (slot-id)
configure equipment protection-group 1 admin-status unlock

eps-quenchfactor 60000
configure equipment protection-element nt-a

redcy-ctrl-status normal
configure interface shub port [1...2] mode automatic

port-type subtending
configure interface shub port [1...2] admin-status up
configure interface shub group 1
configure equipment protection-group 1 admin-status lock
configure interface shub group 1 port [1...2]
configure interface shub group 1 threshold 2
configure equipment protection-group 1 admin-status unlock
configure equipment protection-element nt-b

redcy-ctrl-status normal
DLP 115 Create a layer2-terminated
forwarder VLAN
Purpose
In the forwarder mode, the LTs operate as IP forwarder and the SHub operates as a
bridge.
For the LTs, the following applies:
The user-gateway interface is auto-created by the system when the operator

configures the VRF.
Subnets of the static users must be configured on the user-gateway interface.
Numbered IP interface (trusted or un-trusted) is configured on each network VLAN.
For the SHub, the following applies:
The SHub operates as a bridge.

IP addresses that are configured on the network VLANs are owned by the SHub.
Figure DLP 115-1: Layer2-terminated Forwarder VLAN
LT
SHub
PPPoE/A Session VRF VRF ISP
P-VLAN
DHCP
PPPoE/A ARP Relay P-VLAN
Interface Proxy
VB
P-VLAN
LT
P-VLAN
IPoE/A Session VRF ISP
IPoE/A ARP DHCP ARP

Interface Proxy Relay Proxy
PPPoE/PPPoA, IPoE/IPoA IPoE IPoE

always untagged (P-VLAN) (P-VLAN)
This procedure provides the steps to configure a Layer2-terminated forwarder VLAN.
Prerequisites
The following prerequisites must be fulfilled before a Layer2-terminated forwarder VLAN
can be configured:
A forwarder VRF; see DLP 122.

Note In the configuration example, it is assumed that the VRF index
of the forwarder VRF is 16.
Procedure
Proceed as follows to configure a Layer2-terminated forwarder VLAN:
1 Create a Layer2-terminated VLAN on the NT with the following command:
configure vlan id <Vlan::UVlanIndex>

name <Vlan::AdminString>
mode layer2-terminated
(no) priority <Vlan::Priority>
(no) broadcast-frames
(no) protocol-filter <Vlan::ProtGroup>
2 Create a bridged VLAN on the SHub with the following command:
configure vlan shub id (vlanid)

(no) name <Vlan::AdminString>
mode residential-bridge
(no) mac-move-allow
3 Create an unnumbered network IP interface on the IPoX interface with the following
command:
configure ip vrf (vrf-index) network-itf (vlanid)

(no) arp-policy <Vrf::ArpPolicy>
unnumbered
4 Define the gateway IP interface with the following command:
configure ip vrf (vrf-index) gateway-itf

ip-address (ip-address)
5 Add the IP route with the following command:
configure ip vrf (index) route-dest (dest-ip-address)

next-hop direct:user-port:<Eqpt::RackId>/<Eqpt::ShelfId>
/<Eqpt::SlotId>/<Eqpt::PortId>:<Eqpt::VpiId>:
<Eqpt::VciId>
| <Ip::V4Address>:network:vlan:<Eqpt::VlanId>
| <Ip::V4Address>:network:any
| direct:network:<Eqpt::VlanId>
| direct:user-bridgeport:<Eqpt::RackId>/<Eqpt::ShelfId>
<Eqpt::VciId>
| direct:vlan:<Eqpt::RackId>/<Eqpt::ShelfId>
<Eqpt::VciId>:<Eqpt::UnstackedVlan>
| direct:vlan:<Eqpt::RackId>/<Eqpt::ShelfId>
/<Eqpt::SlotId>/<Eqpt::PortId>:<Eqpt::UnstackedVlan>
| direct:user-port:<Eqpt::RackId>/<Eqpt::ShelfId>/
<Eqpt::SlotId>/<Eqpt::PortId>
| direct:user-bridgeport:<Eqpt::RackId>/<Eqpt::ShelfId>/
<Eqpt::SlotId>/<Eqpt::PortId>
6 Create and configure an SHub network port:
i Configure the SHub network egress port on the network with the following
command:
configure vlan shub id (vlanid) egress-port

network:<Shub::NetworkPort>
ii Configure the SHub network egress port on the LT with the following
command:

lt:<Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::LtSlot>
7 Configure the broadcast VLAN with the following command:
configure dhcp-relay agent (vrfid) bcast-vlan <Dhcp::VlanId>
configure vlan id 101 name ISPforwVLAN-101

configure vlan shub id 101 name ISPforwVLAN-101

configure ip vrf 16 network-itf 101 arp-policy trusted unnumbered
configure ip vrf 16 gateway-itf ip-address 192.168.116.1/21
configure ip vrf 16 route-dest 0.0.0.0/0

next-hop 10.179.136.1:network:vlan:101
configure vlan shub id 101 egress-port lt:1/1/[4...19]
configure dhcp-relay agent 16 bcast-vlan l2-vlan:101
DLP 116 Create a layer2-terminated
router VLAN
Purpose
In the router mode, the LTs operate as an IP forwarder and the SHub operates as a
router.
Between the LTs and the SHub, one VLAN per VRF must be created to indicate the VRF
to which the IP packets belong. This VLAN is called as V-VLAN (VRF VLAN).
For the LTs, the following applies:
The user-gateway interface is auto-created by the system when the operator

configures the VRF.
Subnets of the static users must be configured on the user-gateway interface.
At least one IP address must be configured on the user-gateway interface.
Only one network VLAN (V-VLAN) can be created since LTs will have only one
network interface connected to LANX as gateway.
An unnumbered IP interface (trusted) is created on the V-VLAN since LTs don't have
an IP address on the network interface towards the SHub.
For the SHub, the following applies:
IP interfaces are created on the network VLANs towards the edge routers. IP interface
addresses are seen as the Next-Hop addresses in the downstream from edge routers
to ISAM.
User-gateway interface is the interface towards the users and it is created on V-VLAN.
IP address configured on the user-gateway interface represents the gateway IP
address for the users, and subnet configured on the user-gateway interface
represents the subnet of the users.
Figure DLP 116-1: Layer2-terminated Router VLAN
LT
VRF SHub
PPPoE/A Session V-VLAN Routing Protocols
(OSPF, RIPv2)
PPPoE/A ARP P-VLAN
Interface Proxy
VRF ISP
LT DHCP
ARP Relay
V-VLAN
IPoE/A Session VRF
IPoE/A ARP DHCP ARP

Interface Proxy Relay Proxy
PPPoE/PPPoA, IPoE/IPoA IPoE IPoE

always untagged (V-VLAN per VR) (P-VLAN)
This procedure provides the steps to configure a Layer2-terminated router VLAN.
Prerequisites
The following prerequisites must be fulfilled before a Layer2-terminated router VLAN can
be configured:
A router VRF; see DLP 123.

Note In the configuration example, it is assumed that the index of the
router VRF of the LT is 16 and the index of the router VRF on the SHub
is 5.
Procedure
Proceed as follows to configure a Layer2-terminated router VLAN:
1 Create a virtual Layer2-terminated VLAN on the LT with the following command:

2 Create a virtual VLAN on the SHub with the following command:

mode v-vlan
(no) mac-move-allow
3 Add the virtual VLAN to the LT port where the Layer2-terminated router is active with

egress-port lt:<Eqpt::RackId>/<Eqpt::ShelfId>/<Shub::SlotId>
4 Create an IP interface on the virtual VLAN on the SHub with the following command:
configure interface shub vlan-id (vlanid)
5 Attach the IP interface to a VRF:
configure interface shub ip (vlanid) vrf-id <Vrf::VrfIndex>
6 Configure the IP address of the internal IP interface with the following command:
configure interface shub ip (vlanid)

ip-address <Ip::V4Address>/<Ip::PrefixLengthFull>
7 Set the administrative state of the VLAN interface to up with the following command:
configure interface shub vlan-id (vlanid) admin-status up
8 Create a L2 network terminated VLAN on the Shub with the following command:

mode layer2-term-nwport
(no) mac-move-allow
9 Create and configure an SHub network port with the following command:

(no) mode automatic | 10mbps:full | 10mbps:half | 100mbps:full
| 100mbps:half | 1gbps:full | 1gbps:half
port-type network-port
(no) mc-flooding
10 Change the administrative status of the SHub network port with the following
command:

admin-status up
11 Configure an egress port for the L2 network terminated VLAN on the SHub with the
following command:

12 Configure the SHub network egress port for untagged packets with the following
command:
configure vlan shub id (vlanid) untag-port <Shub::NetworkPort>
13 Configure the port VLAN ID for the untagged packets with the following command:
configure bridge shub port <Shub::NetworkPort>

pvid <Vlan::VlanOamIndex>
14 Create an IP interface on the L2 network terminated VLAN with the following

command:
configure interface shub vlan-id (vlanid)
15 Attach the IP interface to a VRF with the following command:
configure interface shub ip (vlanid) vrf-id <Vrf::VrfIndex>
16 Configure the IP address of the external IP interface with the following command:
configure interface shub ip (vlanid) ip-address (ip-address)
17 Set the administrative state of the VLAN interface to up with the following command:
configure interface shub vlan-id (vlanid) admin-status up
18 Create an unnumbered IP interface on the IPoX interface with the following

command:
configure ip vrf (vrf-index) network-itf (vlanid)

(no) arp-policy <Vrf::ArpPolicy>
unnumbered
19 Configure the gateway IP interface with the following command:
configure ip vrf (vrf-index) gateway-itf

ip-address (ip-address)
20 Add the IP route with the following command:
configure ip shub vrf (index) route-dest (dest)

next-hop <Ip::NextHopV4Address>
vlan-id <Vlan::VlanId>
(no) metric <Vrf::ShubRouteMetric>
Configuration example (for tagged network):
Note: In the configuration example, it is assumed that the index

of the router VRF of the LT is 5 and the index of the router VRF
on the SHub is 15.
configure vlan id 4090 name ISProutingVLAN

configure vlan shub id 4090 name ISPvvlanSHub mode v-vlan
configure vlan shub id 1450 name ISProutingVLAN

mode layer2-term-nwport
configure interface shub port 7 mode automatic port-type network
configure interface shub port 7 admin-status up
configure ip vrf 5 network-itf 4090 arp-policy trusted unnumbered
configure ip vrf 5 gateway-itf ip-address 10.178.14.97/27

next-hop 10.178.14.65 vlan-id 1450
Purpose
This is the most straightforward VLAN cross-connect model where a single VLAN ID at
the EMAN side is associated with a given PVC at the user side. Any kind of traffic issued
by the subscriber is passed transparently towards the network using the selected VLAN
ID.
Cross-connect VLANs can be enabled to be protocol aware for IGMP and 802.1x and
support the configuration of DHCP Option 82 and PPPoE relay.
This procedure provides the steps to configure a Customer VLAN (C-VLAN).
Prerequisite
The following prerequisite must be fulfilled before a C-VLAN can be configured:

Procedure
Proceed as follows to configure a C-VLAN:
1 Create a C-VLAN:
i Create a C-VLAN on the LT with the following command:

mode cross-connect
(no) pppoe-relay
(no) pppoe-relay-tag <Vlan::PppoeRelayEnableR3.1>
ii If required, configure the C-VLAN on the LT with the following command:

(no) pppoe-relay
(no) dhcp-opt-82
(no) circuit-id-dhcp <Vlan::CircuitIdDhcp>
(no) remote-id-dhcp <Vlan::RemoteIdDhcp>
(no) dhcp-linerate <Vlan::Dhcp-linerate>
(no) pppoe-linerate <Vlan::Pppoe-linerate>
(no) circuit-id-pppoe <Vlan::CircuitIdPppoe>
(no) remote-id-pppoe <Vlan::RemoteIdPppoe>
iii Create a C-VLAN on the SHub with the following command:
configure vlan shub id <Vlan::UVlanIndex>

mode cross-connect
i Create and configure an SHub network port with the following command:

port-type network
(no) mc-flooding
admin-status up
ii Configure the SHub network egress port on the network with the following
command:

iii Configure the SHub network egress port on the LT with the following
command:

3 Create an xDSL user; see DLP 124.
1. Example for ADSL line:
configure vlan id 300 name "ISP_C_VLAN_300" mode cross-connect
configure vlan id 300 dhcp-opt-82 circuit-id-dhcp physical-id

remote-id-dhcp customer-id
configure vlan shub id 300 name "ISP_C_VLAN_300"

mode cross-connect
configure interface shub port 7 port-type network admin-status up
configure vlan shub id 300 egress-port lt:1/1/5
configure xdsl line 1/1/5/1 service-profile 7 spectrum-profile 5

admin-up
configure atm pvc 1/1/5/1:8:35 aal5-encap-type

vc-mux-bridged-8023
configure bridge port 1/1/5/1:8:35
configure bridge port 1/1/5/1:8:35 vlan-id 300
configure bridge port 1/1/5/1:8:35 pvid 300
2. Example for VDSL or VDSL2 line:
configure vlan id 301 name "ISP_C_VLAN_301" mode cross-connect

configure vlan shub id 301 name "ISP_C_VLAN_301"

mode cross-connect

admin-up
configure bridge port 1/1/4/1
configure bridge port 1/1/4/1 vlan-id 301
configure bridge port 1/1/4/1 pvid 301
Purpose
In this mode, the Service Provider VLAN (S-VLAN) ID at the EMAN side is associated
with a single subscriber interface at the user side. The C-VLANs carried within the
S-VLAN are passed transparently to the end user. This allows the end user to specify its
own end-to-end connectivity, while remaining transparent for the EMAN.
The NE acts as an S-VLAN aware bridge, with the restriction that only one subscriber
interface can be attached. Forwarding is only done based on the S-VLAN forwarding
context. The forwarding is transparent for the C-VLANs. Frames on the subscriber
interface may or may not have an S-VLAN tag. In case of an absent S-VLAN tag (that is
for C-VLAN tagged and untagged/priority tagged frames), the subscriber interfaces
pre-configured S-VLAN ID will be assigned.
This procedure provides the steps to configure an S-VLAN.
Prerequisite
The following prerequisite must be fulfilled before an S-VLAN can be configured:

Procedure
Proceed as follows to configure an S-VLAN:
1 Create an S-VLAN:
i Create an S-VLAN on the LT with the following command:
configure vlan id
stacked:<Vlan::SVlanIndex>:<Vlan::CVlanIndex>
mode cross-connect

(no) pppoe-relay
ii If required, configure the S-VLAN on the LT with the following command:
configure vlan id
(no) pppoe-relay
(no) dhcp-opt-82
iii Create and configure an SHub network port with the following command:

mode cross-connect

port-type network
(no) mc-flooding
admin-status up
command:

command:

configure vlan id stacked:400:0 name IPS_S_VLAN-400

mode cross-connect
configure vlan shub id 400 name ISP_S_VLAN-400

mode cross-connect

admin-up

vc-mux-bridged-8023
configure bridge port 1/1/5/2:8:35 vlan-id stacked:400:0
configure bridge port 1/1/5/2:8:35 pvid stacked:400:0
2. Example for VDSL or VDSL2 line:
configure vlan id stacked:401:0 name IPS_S_VLAN-401

mode cross-connect
configure vlan shub id 401 name ISP_S_VLAN-401

mode cross-connect

admin-up
configure bridge port 1/1/4/2 vlan-id stacked:401:0
configure bridge port 1/1/4/2 pvid stacked:401:0
Purpose
The basic VLAN cross-connect mode suffers from the fact the that number of VLAN
identifiers is limited to 4K. Since the VLAN is a EMAN wide identifier, one ends up with a
scalability issue: there cannot be more than 4K end users connected to the whole EMAN.
To solve this issue, two VLANs are stacked and the cross-connection is then performed
on the combination (S-VLAN, C-VLAN) allowing to theoretically reach up to 16M end
users.
The NE acts as a C-VLAN aware bridge, with the restriction that only one subscriber
interface can be attached. Frames on the subscriber interface may be C-VLAN tagged or
untagged/priority tagged. In case of C-VLAN tagged frames, a check will be performed
on the received C-VLAN ID, while the subscriber interfaces preconfigured S-VLAN will
be assigned. In case of untagged/priority tagged frames, the subscriber interfaces
pre-configured C-VLAN and S-VLAN will be assigned.
This procedure provides the steps to configure or delete a stacked VLAN.
Prerequisite
The following prerequisite must be fulfilled before an SC-VLAN can be configured:

Procedure
Proceed as follows to configure an SC-VLAN:
1 Create an SC-VLAN:
i Create an S-VLAN on the LT with the following command:
configure vlan id
(no) pppoe-relay
ii If required, configure the S-VLAN on the LT with the following command:
configure vlan id
(no) pppoe-relay
(no) dhcp-opt-82
iii Create a stacked SC-VLAN on the LT with the following command:
configure vlan id
mode cross-connect
iv Create an cross-connect VLAN on the SHub with the following command:

mode cross-connect

port-type network-port
(no) mc-flooding
admin-status up
command:

command:

configure vlan id stacked:500:0 name ISP_SC_VLAN-500

configure vlan id stacked:500:600 name ISP_SC_VLAN-500-600

mode cross-connect
configure vlan shub id 500 name ISP_SC_VLAN-500

mode cross-connect

admin-up
configure atm pvc 1/1/5/3:8:35
aal5-encap-type vc-mux-bridged-8023
2. Example for VDSL or VDSL 2 line:
configure vlan id stacked:501:0 name ISP_SC_VLAN-501

configure vlan id stacked:501:601 name ISP_SC_VLAN-501-601

mode cross-connect
configure vlan shub id 501 name ISP_SC_VLAN-501

mode cross-connect

admin-up
configure bridge port 1/1/4/3 vlan-id stacked:501:601
configure bridge port 1/1/4/3 pvid stacked:501:601
Purpose
The concept of a VLAN in intelligent bridging (iBridge) mode is that multiple NSPs are
each connected to the NE with a VLAN. The user ports are connected to the VLAN of
their corresponding NSP.
Note The NE supports up to 128 iBridges.
This procedure provides the steps to create or delete an iBridge VLAN.
Procedure
Proceed as follows to configure an iBridge VLAN:
1 Create an iBridge VLAN on the LT with the following command:

(no) pppoe-relay
2 If required, configure the iBridge VLAN with the following command:

(no) dhcp-opt-82
3 Create an iBridge VLAN on the SHub with the following command:

Configuration examples:
configure vlan id 56 name vlan56 mode residential-bridge
configure vlan id 100 name iBridge-vlan mode residential-bridge
configure vlan id 100 circuit-id-dhcp physical-id

configure vlan shub id 100 name iBridge-vlan

configure vlan id 200 name MC-vlan mode residential-bridge
configure vlan id 200 circuit-id-dhcp physical-id

configure vlan shub id 200 name MC-vlan mode residential-bridge
DLP 121 Add network interfaces to a
VLAN
Purpose
This procedure provides the steps to add network interface(s) (that is, network port(s)) to
a VLAN.
Prerequisite
The following prerequisite must be fulfilled before network interfaces can be added to a
VLAN:
A VLAN must have been created; see DLP 117, DLP 118, DLP 119 or DLP 120.
Procedure
Proceed as follows to add a network interface to a VLAN:
1 Create and configure an SHub network port with the following command:

(no) mc-flooding
2 Change the administrative status of the SHub network port with the following
command:

admin-status auto-up
3 Configure the SHub network egress port with the following command:

DLP 121 Add network interfaces to a VLAN
4 Configure the SHub network egress port for untagged packets with the following
command:
configure vlan shub id (vlanid) untag-port

5 Configure the port VLAN ID for the untagged packets with the following command:
configure bridge shub port <Shub::NetworkPort>

configure interface shub port 3 mode automatic port-type network
configure interface shub port 3 admin-status auto-up
configure vlan shub id 100 untag-port network:3
Purpose
In the forwarder mode, the NE is not seen as a hop in the IP path by the edge routers.
NE users are seen as directly attached hosts on the IP interfaces of the edge routers.
Multiple VRs can be supported.
User-to-user communication is not provided by the NE.
This procedure provides the steps to configure a Virtual Routing Forwarding (VRF)
context in forwarding mode on the NT.
Procedure
Proceed as follows to configure the forwarding VRF:
1 Create a VRF in forwarding mode on the NT with the following command:
configure ip vrf (index)

name <Vrf::VrfName>
(no) desc <Vrf::VrfDescription>
(no) contact <Vrf::VrfContact>
(no) my-ipaddress <Ip::V4Address>
(no) default-ttl <Vrf::DefaultTTL>
(no) reassem-timeout<Gauge>
mode forwarder
Note The parameter my-ipaddress is an optional parameter.

However, if the VRF will be used for PPPoE sessions, then the parameter
must be filled in. If this parameter is not filled in, the IP address is
assumed to be 0.0.0.0. Most PPPoE clients (running on the PC of the
customers), will reject a PPPoE session with a PPPoE server with IP
address 0.0.0.0.
configure ip vrf 16 name forwardingvrf16 mode forwarder
Purpose
In router mode, the NE is seen as an IP next-hop by the edge routers to route the IP
packets to the users connected to the NE.
Only one VR in router mode can be configured.
The advantages of the router mode are:
Redundancy for the network routes.

ARP table scalability at the edge routers
User-to-user communication can be provided by NE at IP level; user-to-user
communication can be disabled by ACL filters.
This procedure provides the steps to configure a VRF in routing mode.
Procedure
Proceed as follows to configure a VRF in routing mode:
1 Create a VRF in routing mode on the NT with the following command:
configure ip vrf (index)

name <Vrf::VrfName>
(no) desc <Vrf::VrfDescription>
(no) contact <Vrf::VrfContact>
(no) my-ipaddress <Ip::V4Address>
(no) default-ttl <Vrf::DefaultTTL>
(no) reassem-timeout<Gauge>
mode router
2 Create a VRF in routing mode on the SHub with the following command:
configure ip shub vrf (index)

name <Vrf::SHubVrfName>
fast-path-mode:ena-user-user-com
Note The VRF on the SHub must always be created with mode
fast-path-mode.
configure ip vrf 5 name routervrf5 mode router
configure ip shub vrf 15 name routervrf15

fast-path-mode:ena-user-user-com
Purpose
This procedure provides the steps to create an xDSL user.
Prerequisites
The following prerequisites must be fulfilled before an iBridge user can be created:

An VLAN must have been created:
for creation of a cross-connect VLAN; see NTP 104
for creation of an iBridge VLAN; see NTP 105.
Procedure
Proceed as follows to create an xDSL user:
1 Create an xDSL line with the following command:
configure xdsl line (if-index)

service-profile none | <Xdsl::ProfilePointer>
| name: <PrintableString>
spectrum-profile none | <Xdsl::ProfilePointer>
| name:<PrintableString>
(no) ansi-t1413
(no) etsi-dts
(no) g992-1-a
(no) g992-1-b
(no) g992-2-a
(no) g992-3-a
(no) g992-3-b
(no) g992-3-l1
(no) g992-3-l2
(no) g992-3-am
(no) g992-5-a
(no) g992-5-b
(no) ansi-t1.424
(no) etsi-ts
(no) itu-g993-1
(no) ieee-802.3ah
(no) g992-5-am
(no) g993-2-8a
(no) g993-2-8b
(no) g993-2-8c
(no) g993-2-8d
(no) g993-2-12a
(no) g993-2-12b
(no) g993-2-17a
(no) g993-2-30a
(no) carrier-data-mode <Xdsl::CarrierDataMode>
(no) admin-up
(no) bonding-mode <Xdsl::BondingMode>
(no) transfer-mode <Xdsl::TpsTcMode>
Note The value of the parameter transfer-mode must be set to atm if

an ADSL service is required. The value of the parameter can be left on
ptm (default value) if a VDSL or VDSL 2 service is required.
2 Configure the xDSL interface with the following command:
configure interface port

xdsl line:<Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::LtSlot>/<Eqpt::Port>
admin-up
a For a user on an ADSL line, continue with step 4
b For a user on a VDSL or VDSL 2 line, continue with step 5.
4 Create an ATM PVC (or the necessary ATM PVCs) with the following command:
configure atm pvc (port-index)

(no) admin-down
(no) aal5-encap-type llc-snap | llc-snap-routed | llc-nlpid
| vc-mux-bridged-8023 | vc-mux-routed
| vc-mux-pppoa | automatic:ip
| automatic:ppp | automatic:pppoa
5 For each of the created PVCs, create a bridge port with the following command:
configure bridge port (port)

(no) default-priority <Vlan::Priority
(no) mac-learn-off
(no) max-unicast-mac <Vlan::MaxMac>
(no) accept-frame-type <Vlan::VlanFrameTypes>
(no) qos-profile <Vlan::QosProfileName>
(no) prio-regen-prof <Vlan::PrioRegenProfile>
6 For each created bridge port, assign a VLAN to the bridge port and, if required, set
the priorities applicable for that port with the following command:
configure bridge port (port) vlan-id (index)

(no) tag <Vlan::PortUntagStatus>
(no) network-vlan <Vlan::StackedVlan>
(no) vlan-scope <Vlan::VlanScope>
(no) qos <Vlan::QosPolicy>
(no) qos-profile <Vlan::QosProfileName>
(no) prior-best-effort
(no) prior-background
(no) prior-spare
(no) prior-exc-effort
(no) prior-ctrl-load
(no) prior-less-100ms
(no) prior-less-10ms
(no) prior-nw-ctrl
7 Set the PVID with the following command:
configure bridge port (port) pvid (vlan-id)
Note When it needs to be possible to receive single tagged frames at

the user side (S-VLAN cross-connect), a specific C-VLAN ID must be
used, namely 4097. The command is then:

pvid stacked:<Vlan::SVlanIndex>:4097
1. For an ADSL user:

transfer-mode atm admin-up

vc-mux-bridged-8023
2. For a VDSL or VDSL2 user:
configure xdsl line 1/1/4/12 service-profile 7

spectrum-profile 4 admin-up
Purpose
This procedure provides the steps to create an IPoA user.
Prerequisites
The following prerequisites must be fulfilled before an IPoA user can be created:

configured.
Procedure
Proceed as follows to create an IPoA user:

(no) ansi-t1413
(no) etsi-dts
(no) g992-1-a
(no) g992-1-b
(no) g992-2-a
(no) g992-3-a
(no) g992-3-b
(no) g992-3-l1
(no) g992-3-l2
(no) g992-3-am
(no) g992-5-a
(no) g992-5-b
(no) ansi-t1.424
(no) etsi-ts
(no) itu-g993-1
(no) ieee-802.3ah
(no) g992-5-am
(no) admin-up
2 Configure the xDSL line with the following command:

xdsl-line:<Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::LtSlot>
/<Eqpt::Port>
admin-up
3 Create an ATM PVC with the following command:

(no) admin-down
(no) aal5-encap-type llc-snap-routed | vc-mux-routed
| automatic:ip
a If an IP router is being used (see Prerequisites), continue with step 5
b If an IP-aware bridge is being used (see Prerequisites), continue with step 6.
5 Create a route in the SHub towards the modem with the following command:
configure ip shub vrf (index) route-dest (dest)

next-hop <Ip::NextHopV4Address>
where:
route-dest is the subnet which is assigned to the user
next-hop is the IP address of the WAN side of the modem.
6 Create a user port interface with the following command:
configure ip vrf (index) user-itf port (port-interface)

(no) qos-profile none | name:<Vlan::QosProfileName>
7 If the user is a static user, continue with the next step, else go to 9.
8 Configure the IP address to the IP interface with the following command:
configure ip vrf (index) route-dest (dest-ip-address)

next-hop direct:user-port <Eqpt::Rack>/<Eqpt::Shelf>/
<Eqpt::LtSlot>/<Eqpt::Port>
Note This command must be repeated for each IP address assigned

to that particular user.

admin-up
configure atm pvc 1/1/5/13:8:35 no admin-down

aal5-encap-type vc-mux-routed
configure ip vrf 16 user-itf port 1/1/5/13:8:35
configure ip vrf 16 route-dest 10.178.14.53/32

next-hop direct:user-port:1/1/5/13:8:35
Purpose
This procedure provides the steps to create an IPoE user.
Prerequisites
The following prerequisites must be fulfilled before an IPoE user can be created:

created.
Procedure
Proceed as follows to create an IPoE user:

(no) ansi-t1413
(no) etsi-dts
(no) g992-1-a
(no) g992-1-b
(no) g992-2-a
(no) g992-3-a
(no) g992-3-b
(no) g992-3-l1
(no) g992-3-l2
(no) g992-3-am
(no) g992-5-a
(no) g992-5-b
(no) ansi-t1.424
(no) etsi-ts
(no) itu-g993-1
(no) ieee-802.3ah
(no) g992-5-am
(no) admin-up


xdsl-line:<Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::LtSlot>/<Eqpt::Port>
admin-up

(no) admin-down
(no) aal5-encap-type llc-snap | vc-mux-bridged | automatic
5 Create a bridge port with the following command:
6 Create a user port interface with the following command:
configure ip vrf (index) user-itf bridgeport (port-interface)

(no) qos-profile none | name:<Vlan::IgnoredQosProfileName>
7 If the user is a static user, continue with the next step, else go to 4.
8 Configure the IP address to the IP interface with the following command:
configure ip vrf (index) route-dest (dest-ip-address) next-hop

direct:user-bridgeport:<Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::LtSlot>
/<Eqpt::Port>:<Atm::DefaultVpi>:<Atm::DefaultVci>

configure atm pvc 1/1/5/14:8:35 aal5-encap-type vc-mux-bridged
configure ip vrf 16 user-itf bridgeport 1/1/5/14:8:35
2. For a VDSL or VDSL 2 user:

admin-up
configure ip vrf 16 user-itf bridgeport 1/1/4/14
Purpose
This procedure provides the steps to create a PPPoE user.
Prerequisites
The following prerequisites must be fulfilled before an PPPoE user can be created:

created.
A PPP profile must have been created; see DLP 149.
The PPP server must be enabled; see DLP 148.
Procedure
Proceed as follows to create a PPPoE user:

(no) ansi-t1413
(no) etsi-dts
(no) g992-1-a
(no) g992-1-b
(no) g992-2-a
(no) g992-3-a
(no) g992-3-b
(no) g992-3-l1
(no) g992-3-l2
(no) g992-3-am
(no) g992-5-a
(no) g992-5-b
(no) ansi-t1.424
(no) etsi-ts
(no) itu-g993-1
(no) ieee-802.3ah
(no) g992-5-am
(no) admin-up


xdsl-line:<Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::LtSlot>/<Eqpt::Port>
admin-up

(no) admin-down
(no) aal5-encap-type llc-snap | vc-mux-bridged | automatic
configure bridge port (port) max-unicast-mac <Vlan::MaxMac>
6 Create a user PPPoX interface with the following command:
configure pppoe pppox-interface (port)

(no) max-num-session <PPPoE::MaxNumSessions>
(no) ppp-profile-name <AsamProfileName>

configure interface port xdsl-line:1/1/5/15 user TestUser1
configure atm pvc 1/1/5/15:8:35 aal5-encap-type llc-snap
configure bridge port 1/1/5/15:8:35 max-unicast-mac 4
configure pppoe pppox-interface 1/1/5/15:8:35 max-num-session 16

ppp-profile-name PPPProf1
2. For a VDSL or VDSL 2 user:

admin-up
configure interface port xdsl-line:1/1/4/15 user TestUser2
configure bridge port 1/1/4/15 max-unicast-mac 4
configure pppoe pppox-interface 1/1/4/15 max-num-session 16

ppp-profile-name PPPProf1
Purpose
This procedure provides the steps to add an LT port to a VLAN.
Procedure
Proceed as follows to add an LT to the correct VLAN service:
1 Configure an LT port on the SHub with the following command:

lt:<Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::Slot>
Purpose
This procedure provides the steps to create xDSL profiles.
General
Before you can create an xDSL line, you need to create the necessary profiles.
Table DLP 129-1 describes the two types of profiles.
Table DLP 129-1: xDSL profiles
Profile Description
Service Profile Groups a number of parameters related to the xDSL service

Spectrum Profile Groups a number of parameters related to the xDSL spectrum
The parameters of the xDSL spectrum depend largely on the xDSL flavour (ADSL,
READSL, ADSL2(+), VDSL, or VDSL2). That is why the configuration of an xDSL
spectrum is done in two steps:
1 Configure the general xDSL spectrum parameters:

used profiles
noise margins
power management mode
Seamless Rate Adaptation (SRA) parameters
2 Configure the xDSL flavour specific parameters.
Refer to the System Description for more information on power management mode,
SRA,...
See TNG 113 for a full description of the multi-ADSL related parameters and TNG 107
for a full description of the VDSL related parameters.
Procedure
Proceed as follows to create an xDSL profile:
1 Create an xDSL service profile with the following command:
configure xdsl service-profile (index)

name <AsamProfileName>
(scope)
version <SignedInteger>
(no) ra-mode-down <Xdsl::RAModeDownType>
(no) ra-mode-up <Xdsl::RAModeUpType>
(no) min-bitrate-down <Xdsl::BitRate>
(no) min-bitrate-up <Xdsl::BitRate>
(no) plan-bitrate-down <Xdsl::BitRate>
(no) plan-bitrate-up <Xdsl::BitRate>
(no) max-bitrate-down <Xdsl::BitRate>
(no) max-bitrate-up <Xdsl::BitRate>
(no) max-delay-down <Xdsl::InterleavingDelay>
(no) max-delay-up <Xdsl::InterleavingDelay>
(no) imp-noise-prot-dn <Xdsl::ImpNoiseProtection>
(no) imp-noise-prot-up <Xdsl::ImpNoiseProtection>
(no) inp-wo-erasure-dn
(no) inp-wo-erasure-up
(no) min-l2-br-down <Xdsl::BitRate>
Note The value of min-bitrate-down is also used for the calculation

of the available bandwidth for multicast; see DLP 136.
2 Activate an xDSL service profile with the following command:
configure xdsl service-profile (index)

active
Note 1 The xDSL service profile must be activated within 15 minutes

after it has been created, otherwise it will be deleted.
Note 2 The activation parameter can also be included in step 1, but

then no modification of the parameters is possible afterwards (except
name, scope and version; see DLP 163).
3 Create an xDSL spectrum profile and configure the parameters common to all the
DSL flavors with the following command:
configure xdsl spectrum-profile (index)

local-profile
(no) dis-ansi-t1413
(no) dis-etsi-dts
(no) dis-g992-1-a
(no) dis-g992-1-b
(no) dis-g992-2-a
(no) dis-g992-3-a
(no) dis-g992-3-b
(no) g992-3-l1
(no) g992-3-l2
(no) g992-3-am
(no) g992-5-a
(no) g992-5-b
(no) ansi-t1.424
(no) dis-etsi-ts
(no) itu-g993-1
(no) ieee-802.3ah
(no) g992-5-am
(no) g993-2-8a
(no) g993-2-8b
(no) g993-2-8c
(no) g993-2-8d
(no) g993-2-12a
(no) g993-2-12b
(no) g993-2-17a
(no) g993-2-30a
(no) min-noise-down <Xdsl::NoiseMargin>
(no) min-noise-up <Xdsl::NoiseMargin>
(no) trgt-noise-down <Xdsl::NoiseMargin>
(no) trgt-noise-up <Xdsl::NoiseMargin>
(no) max-noise-down <Xdsl::NoiseMarginPlus>
(no) max-noise-up <Xdsl::NoiseMarginPlus>
(no) carrier-mask-down <Xdsl::CarrierMaskDown>
(no) carrier-mask-up <Xdsl::CarrierMaskUp>
(no) rf-band-list <Xdsl::RFBand>
(no) power_mgnt_mode <Xdsl::LinePowerMgtMode>
(no) l0-time <Xdsl::LineTime>
(no) l2-time <Xdsl::LineTime>
(no) l2-agpow-red-tx <Xdsl::L2Atpr>
(no) modification <Xdsl::ModifyStatus>
(no) rau-noise-down <Xdsl::NoiseMargin>
(no) rau-noise-up <Xdsl::NoiseMargin>
(no) rau-time-down <Xdsl::RaTime>
(no) rau-time-up <Xdsl::RaTime>
(no) rad-noise-down <Xdsl::NoiseMargin>
(no) rad-noise-up <Xdsl::NoiseMargin>
(no) rad-time-down <Xdsl::RaTime>
(no) rad-time-up <Xdsl::RaTime>
(no) l2-agpw-to-red-tx <Xdsl::LineL2Atpr>
4 Configure the artificial noise (that is, the transmitter-referred artificial noise level to
be used as additional noise source at the downstream transmitter) with the following
command:

artificial-noise-down (psd-point)
(no) frequency <Xdsl::CustFreq>
(no) psd <Xdsl::CustPsd>
5 If the xDSL type is ADSL or ADSL2, then the ADSL and ADSL2 specific part of an
xDSL spectrum profile can be managed with the following command:
configure xdsl spectrum-profile (index) adsl-adsl2

(no) proprietary-feat
(no) max-agpowlev-down <Xdsl::PowerLevel>
(no) max-agpowlev-up <Xdsl::PowerLevel>
(no) max-psd-down <Xdsl::Adsl2PowerSpectralDensityDown>
(no) max-psd-up <Xdsl::Adsl2PowerSpectralDensityUp>
(no) pbo-mode-up
(no) max-recv-power-up <Xdsl::RxPowerLevel>
6 If the xDSL type is ADSL2+, then the ADSL2+ specific part of an xDSL spectrum
profile can be managed with the following command:
configure xdsl spectrum-profile (index) adsl2-plus

(no) max-psd-down <Xdsl::Adsl2PlusPowerSpectralDensityDown>
(no) max-psd-up <Xdsl::Adsl2PlusPowerSpectralDensityUp>
(no) pbo-mode-up
(no) psd-shape-down <Xdsl::Adsl2PlusPsdShapeDown>
7 If the xDSL type is Reach Extended ADSL2 (READSL2), then the READSL2
specific part of an xDSL spectrum profile can be managed with the following
command:
configure xdsl spectrum-profile (index) re-adsl

(no) max-psd-down <Xdsl::ReAdsl2PowerSpectralDensityDown>
(no) max-psd-up <Xdsl::ReAdsl2PowerSpectralDensityUp>
(no) pbo-mode-up
8 If the xDSL type is VDSL, then the VDSL specific part of an xDSL spectrum profile
can be managed with the following command:
configure xdsl spectrum-profile (index) vdsl

(no) vdsl-band-plan <Xdsl::VdslBandPlan>
(no) optional-band <Xdsl::OptionalBandUsage>
(no) optional-endfreq <Xdsl::OptionalBandEndFreq>
(no) adsl-band <Xdsl::AdslBandUsage>
(no) max-agpowlev-down <Xdsl::VdslPowerLevel>
(no) max-agpowlev-up <Xdsl::VdslPowerLevel>
(no) psd-shape-down <Xdsl::VdslPsdShapeDown>
(no) psd-shape-up <Xdsl::VdslPsdShapeUp>
(no) pbo-mode-down
(no) rx-psd-shape-up <Xdsl::RxVdslPsdShapeUp>
(no) ghstones-pwr-mode <Xdsl::GhsTonesTxPwr>
(no) max-band <Xdsl::VdslMaxBandNum>
(no) max-freq <Xdsl::VdslMaxFrequency>
(no) m-psd-level-down <Xdsl::MaxPsdDown>
(no) m-psd-level-up <Xdsl::MaxPsdUp>
(no) psd-pbo-par-a-up <Xdsl::ABParamType>
(no) psd-pbo-par-b-up <Xdsl::ABParamType>
(no) cust-psd-sc-down <Xdsl::PsdScaleBit>
(no) cust-psd-ty-down <Xdsl::PsdTypeBit>
(no) cust-rx-psd-sc-up <Xdsl::PsdScaleBit>
(no) cust-rx-psd-ty-up <Xdsl::PsdTypeBit>
9 Configure the transmission power of the G.hs tones in VDSL environment. with the
following command:
configure xdsl spectrum-profile (index) vdsl ghstone-set-pwr-ctrl

(no) a43 standard | auto | manual:<Xdsl::GhsTonesTxPwrLvl>
(no) b43 standard | auto | manual:<Xdsl::GhsTonesTxPwrLvl>
(no) a43c standard | auto | manual:<Xdsl::GhsTonesTxPwrLvl>
(no) v43 standard | auto | manual:<Xdsl::GhsTonesTxPwrLvl>
10 If the xDSL type is VDSL2, then the VDSL2 specific part of an xDSL spectrum profile
can be managed with the following command:
configure xdsl spectrum-profile (index) vdsl2

(no) max-agpowlev-down <Xdsl::VdslPowerLevel>
(no) max-agpowlev-up <Xdsl::VdslPowerLevel>
(no) psd-shape-down <Xdsl::Vdsl2PsdShapeDown>
cs-psd-shape-dn <Xdsl::Vdsl2CustPsdShape>
cs-psd-shape-up <Xdsl::Vdsl2CustPsdShape>
(no) psd-shape-up <Xdsl::Vdsl2PsdShapeUp>
(no) rx-psd-shape-up <Xdsl::RxVdslPsdShapeUp>
(no) psd-pbo-e-len-up <Xdsl::PsdPboElectrLength>
(no) m-psd-level-down <Xdsl::MaxPsdDown>
(no) m-psd-level-up <Xdsl::MaxPsdUp>
(no) psd-pbo-par-a-up <Xdsl::ABParamType>
(no) psd-pbo-par-b-up <Xdsl::ABParamType>
(no) v-noise-snr-down <Xdsl::SnrmMode>
(no) v-noise-snr-up <Xdsl::SnrmMode>
(no) v-noise-psd-down <Xdsl::VirtualNoisePsdDownType>
(no) v-noise-psd-up <Xdsl::VirtualNoisePsdUpType>
(no) cust-psd-sc-down <Xdsl::PsdScaleBit>

(no) cust-psd-ty-down <Xdsl::PsdTypeBit>
(no) cust-psd-sc-up <Xdsl::PsdScaleBit>
(no) cust-psd-ty-up <Xdsl::PsdTypeBit>
(no) cust-rx-psd-sc-up <Xdsl::PsdScaleBit>
(no) cust-rx-psd-ty-up <Xdsl::PsdTypeBit>
11 Activate an xDSL spectrum profile with the following command:

active
configure xdsl service-profile 7 name ADSL_profile version 1
configure xdsl service-profile 7 active
configure xdsl service-profile 8 name VDSL_profile version 1

min-bitrate-down 25000 min-bitrate-up 25000 plan-bitrate-down
40000 plan-bitrate-up 27000 max-bitrate-down 262143
max-bitrate-up 262143
configure xdsl service-profile 10 name XSRVC_0_0 version 1

min-l2-br-down 0
configure xdsl service-profile 10 ra-mode-up automatic

min-bitrate-up 0 plan-bitrate-up 0 max-bitrate-up 0
max-delay-up 16 imp-noise-prot-up 0 no inp-wo-erasure-up
configure xdsl service-profile 10 ra-mode-down automatic

min-bitrate-down 0 plan-bitrate-down 0 max-bitrate-down 0
max-delay-down 16 imp-noise-prot-dn 0 no inp-wo-erasure-dn
configure xdsl spectrum-profile 4 name vdsl_profile version 1
configure xdsl spectrum-profile 4 dis-ansi-t1413 dis-etsi-dts

dis-g992-1-a dis-g992-1-b dis-g992-2-a dis-g992-3-a dis-g992-3-b
dis-etsi-ts g993-2-8a g993-2-8b g993-2-8c g993-2-8d g993-2-12a
g993-2-12b g993-2-17a g993-2-30a
configure xdsl spectrum-profile 4 active
configure xdsl spectrum-profile 5 name adsl_profile version 1
configure xdsl spectrum-profile 22 name "approved-profile"
Purpose
xDSL bonding allows to carry the traffic to and from a single logical subscriber interface
over multiple physical multi-ADSL lines. It offers the following services:
Extended reach of DSL service

Provision of standard multi-ADSL services to subscribers that cannot receive these
services over a single ADSL line
Higher bit rate services (up to 30 Mbit/s downstream and 5.5 Mbit/s upstream).
This procedure provides the steps to configure xDSL bonding.
Prerequisites
The following prerequisites must be fulfilled before xDSL bonding can be configured:

A cross-connect VLAN (see NTP 104), an iBridge VLAN (see NTP 105), an IP-aware
bridge (see NTP 106) or an IP router (see NTP 107) must have been configured.
Procedure
Proceed as follows to create an xDSL bonding group profile:
1 Configure the xDSL lines to be bonded with bonding mode atm-bonding with the
following command:

service-profile <AsamProfilePointer>
spectrum-profile <AsamProfilePointer>
(no) op-mode <Xdsl::OpModeTypeLinePreDef>
(no) admin-up
bonding-mode atm-bonding
Note 1 The following applies for these xDSL lines in case of chipset
level bonding:
The two lines used for xDSL bonding must be subsequent lines
The first line must be an odd line
Note 2 The following applies for the first line (also known as bonding
group index):
Configuration of parameters such as atm pvc, bridge port, and so on,

must be done on that first line. Refer to DLP 124, DLP 125, DLP 126
or DLP 127 for the configuration procedure.
2 Configure an xDSL bonding group profile with the following command:
configure xdsl-bonding group-profile (index)

local-profile | network-profile
(no) min-bitrate-up <Xdsl::Bitrate>
(no) min-bitrate-down <Xdsl::Bitrate>
(no) plan-bitrate-up <Xdsl::Bitrate>
(no) plan-bitrate-down <Xdsl::Bitrate>
(no) max-bitrate-up <Xdsl::Bitrate>
(no) max-bitrate-down <Xdsl::Bitrate>
(no) max-delay-down <Xdsl::InterleavingDelay>
(no) max-delay-up <Xdsl::InterleavingDelay>
(no) imp-noise-prot-dn <Xdsl::SignedIntegerSYMBOL>
(no) imp-noise-prot-up <Xdsl::SignedIntegerSYMBOL>
(no) active
Note A bonding group profile can be created in one step (that is, with
all the necessary parameters and activation of the bonding group profile).
It can also be created in several steps by specifying a few parameters in
each step and by activating the bonding group profile in the last step.
3 Configure an xDSL bonding group with the following command:
configure xdsl-bonding group (bonding-group-idx)

group-profile none | <Xdsl::GroupProfileIndexWithRemove>
(no) admin-up
a In case of chipset level bonding; go to step 7.
b In case of system level bonding; go to step 5.
5 Create an xDSL bonding group with the following command:
configure xdsl-bonding group (bonding-group-idx)

link (bonding-link-id)
6 Activate the xDSL bonding group with the following command:
configure xdsl-bonding group (if-index) admin-up
7 Configure the bonding group assembly timeout with the following command:
configure xdsl-bonding group-assembly-time <SignedInteger>
Note The default value is 0, and is interpreted as disabling the timer.
configure xdsl-bonding group-assembly-time 0
configure xdsl-bonding group-profile 1 name XBOND_0_0

local-profile version 1
configure xdsl-bonding group-profile 1 min-bitrate-up 0

plan-bitrate-up 0 max-bitrate-up 0 max-delay-up 16
imp-noise-prot-up 0
configure xdsl-bonding group-profile 1 min-bitrate-down 0

plan-bitrate-down 0 max-bitrate-down 0 max-delay-down 16
imp-noise-prot-dn 0
configure xdsl-bonding group-profile 1 active
configure xdsl-bonding group-profile 2 name GroupProfile1

local-profile version 1
configure xdsl-bonding group-profile 2 min-bitrate-up 800

plan-bitrate-up 1500 max-bitrate-up 2200 max-delay-up 16
imp-noise-prot-up 0
configure xdsl-bonding group-profile 2 min-bitrate-down 10000

plan-bitrate-down 20000 max-bitrate-down 40000 max-delay-down 16
imp-noise-prot-dn 0
configure xdsl-bonding group-profile 2 active
configure xdsl line 1/1/8/47 service-profile name:XSRVC_0_0

spectrum-profile 5 bonding-mode atm-bonding admin-up

configure xdsl-bonding group 1/1/8/47 group-profile

name:GroupProfile1 up


configure xdsl-bonding group 1/1/7/21 group-profile 2 no up
configure xdsl-bonding group 1/1/7/21 link 1/1/8/25
configure xdsl-bonding group 1/1/7/21 up
DLP 131 Create an xDSL bonding
group
Note
This procedure is no longer valid.
The correct procedure for configuring xDSL bonding is described in DLP 130.
DLP 131 Create an xDSL bonding group
Purpose
This procedure provides the steps to configure filtering on the SHub.
The IP filters for the different protocols take into account source and/or destination IP
addresses; either or both must be specified. Optionally the ICMP message type and/or
the ICMP message code can be specified.
The physical ports where the filters have to be applied are configured subsequently, by
means of dedicated configuration commands.
When the filter is to be applied to incoming traffic, the command to configure the in-port
is to be used. When the filter is to be applied to outgoing traffic, the command to configure
the out-port is to be used.
Creating a filter for a specific set of streams

Proceed as follows to create a filter that lets a specific set of streams through, but blocks
all other traffic:
1 Create filters on the SHub that let certain streams with specific MAC addresses pass
through
2 Create one filter that blocks all the traffic (see Note after step 1).
Note The behaviour of the filters depends on the type of NT board:
For ECNT-C and NANT-A; the filters are ORed.

For ECNT-A: the filters are overruled in order of creation. The filter
that was created as first gets the highest priority.
Procedure
Proceed as follows to configure filtering on the SHub:
1 Configure the SHub MAC filter with the following command:
configure transport shub mac-filter (index-num)

(no) protocol-type <Sys::ProtocolType>
filter any-<Sys::MacAddr> | <Sys::MacAddr>-any
| <Sys::MacAddr>-<Sys::MacAddr>
vlan-id <Sys::FilterVlanId>
(no) action-drop
Note To configure a filter which will filter and drop all upstream straffic
irrespective of the MAC source address, use the following command

filter 00:00:00:00:00:00-any vlan-id <Sys::FilterVlanId>
action-drop
2 Configure the SHub MAC filter to a port with the following command:

(no) in-port (port)
3 Configure an ICMP filter on the SHub with the following command:
configure system shub filter ip-filter icmp (index-num)

(no) action-drop
(no) dst-ip-addr <Ip::V4Address>/<Ip::PrefixLengthFull>
(no) src-ip-addr <Ip::V4Address>/<Ip::PrefixLengthFull>
(no) msg-type <Sys::MsgType>
(no) msg-code <Sys::MsgCode>
(no) direction <Sys::Direction>
(no) vlan-id <Vlan::VlanFilterIndex>
4 Configure the physical ports where the ICMP filter related to incoming traffic is to be
applied with the following command:

(no) in-port (network-port)
5 Configure the physical ports where the ICMP filter related to outgoing traffic is to be
applied:

(no) out-port (port)
6 Configure a TCP filter on the SHub with the following command:
configure system shub filter ip-filter tcp (index-num)

(no) action-drop
(no) min-dst-port <Sys::Port>
(no) max-dst-port <Sys::Port>
(no) min-src-port <Sys::Port>
(no) max-src-port <Sys::Port>
(no) ack <Sys::AckBit>

(no) rst <Sys::RstBit>
(no) tos <Sys::Tos>
7 Configure the physical ports where the TCP filter related to incoming traffic is to be

8 Configure the physical ports where the TCP filter related to outgoing traffic is to be
applied:

(no) out-port (network-port)
9 Configure an UDP filter on the SHub with the following command:
configure system shub filter ip-filter udp (index-num)

(no) action-drop
(no) min-dst-port <Sys::Port>
(no) max-dst-port <Sys::Port>
(no) min-src-port <Sys::Port>
(no) max-src-port <Sys::Port>
10 Configure the physical ports where the UDP filter related to incoming traffic is to be

11 Configure the physical ports where the UDP filter related to outgoing traffic is to be
applied:

12 Configure an IP filter, for protocols other than ICMP, TCP or UDP, on the SHub with
configure system shub filter ip-filter port-filter (filter-rule)

(no) protocol <Sys::RestrictedProtocol>
(no) action-drop
13 Configure the physical ports where the IP filter related to incoming traffic is to be

(no) in-port (port)
14 Configure the physical ports where the IP filter related to outgoing traffic is to be

configure transport shub mac-filter 450 protocol-type 2222 filter

any-56:0d:9d:47:dd:aa vlan-id 100 action-drop
configure transport shub mac-filter 451 protocol-type 2222 filter

any-56:0d:9d:47:dd:bb vlan-id 100 action-drop
configure transport shub mac-filter [450...451] in-port lt:1/1/4
configure system shub filter ip-filter icmp 12 action-drop

src-ip-addr 192.168.0.1/16 direction out
configure system shub filter ip-filter icmp 12 in-port 3
configure system shub filter ip-filter icmp 12 out-port lt:1/1/4
configure system shub filter ip-filter tcp 12 action-drop

configure system shub filter ip-filter tcp 12 in-port 3
configure system shub filter ip-filter tcp 12 out-port network:3
configure system shub filter ip-filter udp 14 action-drop

configure system shub filter ip-filter udp 14 in-port 3
configure system shub filter ip-filter udp 14 out-port network:3
configure system shub filter ip-filter port-filter 10 protocol

rsvp action-drop src-ip-addr 192.168.0.1/16
configure system shub filter ip-filter port-filter 10 in-port 4
configure system shub filter ip-filter port-filter 10

out-port lt:1/1/5
Purpose
This procedure provides the steps to configure QoS on layer 2.
Note For more information about QoS and the configuration of QoS,
refer to TNG 101.
Procedure
Proceed as follows to configure QoS on layer 2 level:
1 Configure general QoS parameters (if necessary):
i Configure the ATM overhead factor with the following command:
configure qos
(no) atm-overhead-fact <Qos::AtmFactor>
(no) eth-efm-fact <Qos::EthEfmFactor>
(no) enable-alignment
(no) cac-mode <Qos::CacMode>
Note The parameter cac-mode stores a global CAC mode selection

switch:
nocac: no CAC in the system

msr: base on minimum synchronized rate
alr: base on actual line rate
ii Configure the upstream QoS DSL Control Packet Policer for incoming packets
configure qos dsl-ctrl-pkt-policer

(no) sustained-rate <Qos::SustainedRate>
(no) burst-size <Qos::DslCtrlBurstSize>
iii If required, configure the downstream traffic class mapping table with the
following command:
configure qos tc-map-dot1p (index) queue <Qos::Queues>
2 Configure the QoS policer profiles with the following command:
configure qos profiles policer (name)

committed-info-rate <Qos::InfoRate>
committed-burst-size <Qos::CommittedBurstSize>
Note For more information on configured and actual values for

Committed Info Rate (CIR) and Committed Burst size (CBS), see QoS
Policer Profile in TNG 101.
3 Create one of the following marker profiles:
i Configure a marker for single dot-1P with the following command:
configure qos profiles marker d1p (name)

default-dot1p <Qos::ExtVlanSysPrio>
ii Configure a marker for single DSCP with the following command:
configure qos profiles marker dscp (name)

default-dscp <Qos::DscpToDot1PAlignmentDscpIndex>
(no) alignment
iii Configure a marker for a DSCP contract table with the following command:
configure qos profiles marker dscp-contract (name)

(no) alignment
iv Configure a codepoint for a DSCP contract table with the following command:

codepoint (codepoint)
(on) dscp-value <Qos::DscpToDot1PAlignmentDscpIndex>
v Configure a marker for Dot1P and the DSCP contract table with the following
command:
configure qos profiles marker d1p-dscp-contract (name)

dot1p-value <Qos::ExtVlanSysPrio>
(no) alignment
vi Configure a codepoint for Dot1P and the DSCP contract table with the
following command:

(no) dscp-value <Qos::DscpToDot1PAlignmentDscpIndex>
vii Configure a marker for Dot1P and single DSCP with the following command:
configure qos profiles marker d1p-dscp (name)

viii Configure a marker for Dot1P alignment with the following command:
configure qos profiles marker d1p-alignment (name)

(alignment) enable
4 Configure a scheduler profile with the following command:
configure qos profiles scheduler (name)

wfq-q1-weight <Qos::WfqQ1Weight>
5 Configure a CAC profile with the following command:
configure qos profiles cac (name)

res-voice-bandwidth <Qos::BandWidthKBPS>
max-mcast-bandwidth <Qos::BandWidthKBPS>
res-data-bandwidth <Qos::BandWidthKBPS>
6 Configure a queue profile (that is, the used algorithm (tail-drop or Random Early
Detection (RED) and threshold(s)) with the following command:
configure qos profiles queue (name)

tail-drop:<Qos::MaxThreshold> |
red:<Qos::MinThreshold>:<Qos::MaxThreshold>:
<Qos::DiscardProbability>
7 Configure a layer 2 filter with the following command:
configure qos profiles l2-filter (name)

(no) dst-mac-addr <Qos::MacAddrAndMask>
(no) src-mac-addr <Qos::MacAddrAndMask>
(no) ethertype <Qos::FilterEthernetType>
(no) dot1p-priority <Qos::MatchDot1pValue>
(no) canonical-format <Qos::FilterCfi>
(no) vlan-id <Qos::FilterVlanId>
8 Configure QoS policy actions, using the policer profiles created in step 2, with the
following command:
configure qos profiles policy-action (name)

(no) dscp-value <Qos::SetDscpValue>
(no) dot1p-value <Qos::SetDot1pValue>
(no) discard-packet
(no) shared-policer
(no) policer-profile <Policer Profile name>
9 Configure QoS policy profiles with a set of associated actions.
A policy rule contains:
Filter type (here: L2 filter)

L2 filter (see step 7)
Precedence of this policy rule
Policy action (see step 8).
configure qos profiles policy (name)

filter l2-name:<Qos::IgnoredQosProfileName>
(no) precedence <Qos::PolicyPrecedence>
(no) policy-action <Qos::QosProfileName>
10 Create the QoS session profile:
i Configure the session profile table (using policer profiles created in step 1 and
marker profiles used in step 3) with the following command:
configure qos profiles session (name)

logical-flow-type <Qos::LogicalFlowType>
(no) up-policer none | name:<Policer Profile name>
(no) down-policer none | name:<Policer Profile name>
(no) up-marker none | name:<Marker Profile name>
ii Configure a list of upstream policy profiles (minimum 2, maximum 16), using

policy profiles created in step 9, with the following command:

up-policy (Policy name)
iii Configure a list of downstream policy profiles (minimum 2, maximum 16), using
policies created in step 9, with the following command:

down-policy (Policy name)
11 Attach the created session profile to a bridge port with the following command:
configure bridge port <Rack/Shelf/Slot/Port:VCI:VPI>

(no) qos-profile <Session-profile>
12 Attach the created scheduler profile (see step 4) and CAC profile (see step 5) to:
a a DSL port with the following command:
configure qos dsl-port (index)

scheduler-profile <Qos::ProfileName>
cac-profile <Qos::ProfileName>
b an SHDSL interface with the following command:
configure qos shdsl-port (index)

c an Ethernet link with the following command:
configure qos interface eth-itf (index)
13 Attach the created queue profile (see step 6) to:
configure qos dsl-port (index) queue (queue)

queue-profile <Qos::QosProfileName>
configure qos shdsl-port (index) queue (queue)

configure qos interface eth-itf (index) queue (queue)

configure qos atm-overhead-fact 87 eth-efm-fact 84

no enable-alignment
configure qos dsl-ctrl-pkt-policer sustained-rate 14 burst-size

11
configure qos profiles policer 300k committed-info-rate 300

committed-burst-size 1600
configure qos profiles marker d1p mrkr_d1p default-dot1p 0
configure qos profiles marker dscp mrkr_dscp default-dscp 62

alignment
configure qos profiles marker dscp-contract mrkr_dscp-contract

alignment

codepoint 52 dscp-value 6

codepoint 23 dscp-value 5
configure qos profiles marker

d1p-dscp-contract mrkr_d1p-dscp-contract dot1p-value 3
no alignment
configure qos profiles marker

d1p-dscp-contract mrkr_d1p-dscp-contract codepoint 44
dscp-value 2
configure qos profiles marker d1p-dscp mrkr_d1p-dscp default-dscp
55 default-dot1p 4
configure qos profiles marker d1p-alignment mrkr_d1p-alignment

enable
configure qos profiles scheduler sched1 wfq-q1-weight 77
configure qos profiles cac FD_TriplePlay res-voice-bandwidth 100

max-mcast-bandwidth 6000 res-data-bandwidth 250
configure qos profiles queue FD_VideoQ tail-drop:20
configure qos profiles l2-filter l2filter src-mac-addr

00:00:00:00:00:13/48 dst-mac-addr 00:00:00:00:00:23/48
dot1p-priority -1 vlan-id 200
configure qos profiles policy-action 1 discard-packet
configure qos profiles policy pol1 filter l2-name:l2filter

policy-action name:1 precedence 20
configure qos profiles session session1 logical-flow-type pvc
configure qos profiles session session1 down-policy pol1
configure qos profiles session qos-sess1 logical-flow-type

generic up-policer name:300k down-policer name:300k
configure bridge port 1/1/5/1:8:35 qos-profile name:qos-sess1
configure qos dsl-port 1/1/4/1 scheduler-profile name:CL_66

cac-profile name:FD_Default
configure qos dsl-port 1/1/4/1 queue 0 queue-profile name:FD_CLQ
configure qos dsl-port 1/1/4/1 queue 1 queue-profile name:FD_BEQ
configure qos dsl-port 1/1/4/1 queue 3 queue-profile

name:FD_VoiceQ
Purpose
This procedure provides the steps to configure QoS on layer 3 level.
refer to TNG 101.
Procedure
Proceed as follows to configure QoS on layer 3 level:
1 Configure general QoS parameters (if necessary):
i Configure the ATM overhead factor with the following command:
configure qos
(no) atm-overhead-fact <Qos::AtmFactor>
(no) eth-efm-fact <Qos::EthEfmFactor>
(no) enable-alignment
(no) cac-mode <Qos::CacMode>
ii Configure the upstream QoS DSL Control Packet Policer for incoming packets
configure qos dsl-ctrl-pkt-policer

(no) sustained-rate <Qos::SustainedRate>
(no) burst-size <Qos::DslCtrlBurstSize>
iii If required, configure the DSCP to Dot1P Alignment Table for layer 3 forwarded
traffic with the following command:
configure qos dscp-map-dot1p (index)

dot1p-value <Qos::DscpToDot1PAlign>
2 Configure the QoS policer profiles with the following command:
configure qos profiles policer (name)

committed-info-rate <Qos::InfoRate>
committed-burst-size <Qos::CommittedBurstSize>
Note For more information on configured and actual values for

Committed Info Rate (CIR) and Committed Burst size (CBS), see QoS
Policer Profile in TNG 101.
3 Create one of the following marker profiles:
i Configure a marker for single dot-1P with the following command:
configure qos profiles marker d1p (name)

ii Configure a marker for single DSCP with the following command:
configure qos profiles marker dscp (name)

(no) alignment
iii Configure a marker for a DSCP contract table with the following command:

(no) alignment
iv Configure a codepoint for a DSCP contract table with the following command:

(on) dscp-value <Qos::DscpToDot1PAlignmentDscpIndex>
v Configure a marker for Dot1P and the DSCP contract table with the following
command:

dot1p-value <Qos::ExtVlanSysPrio>
(no) alignment
vi Configure a codepoint for Dot1P and the DSCP contract table with the
following command:

(no) dscp-value <Qos::DscpToDot1PAlignmentDscpIndex>
vii Configure a marker for Dot1P and single DSCP with the following command:
configure qos profiles marker d1p-dscp (name)

viii Configure a marker for Dot1P alignment with the following command:
configure qos profiles marker d1p-alignment (name)

(alignment) enable
4 Configure a scheduler profile with the following command:
configure qos profiles scheduler (name)

wfq-q1-weight <Qos::WfqQ1Weight>
5 Configure a CAC profile with the following command:
configure qos profiles cac (name)

res-voice-bandwidth <Qos::BandWidthKBPS>
max-mcast-bandwidth <Qos::BandWidthKBPS>
res-data-bandwidth <Qos::BandWidthKBPS>
6 Configure a queue profile (that is, the used algorithm (tail-drop or Random Early
Detection (RED) and threshold(s)) with the following command:
configure qos profiles queue (name)

tail-drop:<Qos::MaxThreshold> |
red:<Qos::MinThreshold>:<Qos::MaxThreshold>:
<Qos::DiscardProbability>
7 Configure a layer 3 filter with the following command:
configure qos profiles l3-filter (name)

(no) dst-ip-addr <Ip::AddressAndMaskFull>
(no) src-ip-addr <Ip::AddressAndMaskFull>
(no) min-dst-port <Qos::L4PortNumber>
(no) max-dst-port <Qos::L4PortNumber>
(no) min-src-port <Qos::L4PortNumber>
(no) max-src-port <Qos::L4PortNumber>
(no) dscp-value <Qos::MatchDscpValue>
(no) protocol <Qos::Protocol>
8 Configure QoS policy actions, using the policer profiles created in step 2, with the
following command:
configure qos profiles policy-action (name)

(no) dscp-value <Qos::SetDscpValue>
(no) dot1p-value <Qos::SetDot1pValue>
(no) discard-packet
(no) shared-policer
(no) policer-profile <Policer Profile name>
9 Configure QoS policy profiles with a set of associated actions.
A policy rule contains:
Filter type (here: L3 filter)

L3 filter (see step 7)
Precedence of this policy rule
Policy action (see step 8).
configure qos profiles policy (name)

filter l3-name:<Qos::IgnoredQosProfileName>
(no) precedence <Qos::PolicyPrecedence>
(no) policy-action <Qos::QosProfileName>
10 Create the QoS session profile:
i Configure the session profile table (using policer profiles created in step 1 and
marker profiles used in step 3) with the following command:

logical-flow-type <Qos::LogicalFlowType>
(no) up-policer none | name:<Policer Profile name>
(no) down-policer none | name:<Policer Profile name>
(no) up-marker none | name:<Marker Profile name>
ii Configure a list of upstream policy profiles (minimum 2, maximum 16), using

policy profiles created in step 9, with the following command:

up-policy (Policy name)
iii Configure a list of downstream policy profiles (minimum 2, maximum 16), using
policies created in step 9, with the following command:

down-policy (Policy name)
11 Attach the created session profile to a bridge port with the following command:
configure bridge port <Rack/Shelf/Slot/Port:VCI:VPI>

(no) qos-profile <Session-profile>
12 Attach the created scheduler profile (see step 4) and CAC profile (see step 5) to:
configure qos dsl-port (index)

configure qos shdsl-port (index)

configure qos interface eth-itf (index)

13 Attach the created queue profile (see step 6) to:
configure qos dsl-port (index) queue (queue)

configure qos shdsl-port (index) queue (queue)

configure qos interface eth-itf (index) queue (queue)

configure qos profiles policer ppUsSap256k

committed-info-rate 256 committed-burst-size 32000
configure qos profiles policer ppDsSap3M committed-info-rate 3000

configure qos profiles policer ppVoice100k

committed-info-rate 100 committed-burst-size 3000
configure qos profiles marker d1p mpUsSap default-dot1p 0
configure qos profiles l3-filter f3pUsVoiceIp

src-ip-addr 192.170.0.0/16
configure qos profiles l3-filter f3pDsVoiceIp

dst-ip-addr 192.170.0.0/16
configure qos profiles l3-filter l3pUsVodIp

dst-ip-addr 192.180.2.2/0
configure qos profiles l3-filter l3pDsVodIp

src-ip-addr 192.180.2.2/0
configure qos profiles policy-action apVoice dot1p-value 6

policer-profile name:ppVoice100k
configure qos profiles policy-action apVod dot1p-value 3
configure qos profiles policy pcyUpVoice

policy-action name:apVoice no precedence
filter l3-name:f3pUsVoiceIp
configure qos profiles policy pcyDnVoice

policy-action name:apVoice no precedence
filter l3-name:f3pDsVoiceIp
configure qos profiles policy pcyUpVod policy-action name:apVod

filter l3-name:l3pUsVodIp
configure qos profiles policy pcyDnVod policy-action name:apVod

filter l3-name:l3pDsVodIp
Purpose
The QoS-aware VLAN cross-connect is not a new cross-connect mode on its own, but it
adds the possibility to support PVC-bundles as subscriber interfaces.
Note The QoS-aware VLAN cross-connect mode can be applied to

all other VLAN cross-connect modes defined above, i.e. C-VLAN,
S-VLAN and S-VLAN/C-VLAN cross-connects. In the last case, the
cross-connect will consider the p-bits of the S-VLAN, the C-VLAN p-bits
remaining transparent.
In the downstream direction, the egress bridge port is found by means of the combination
of VLAN tag and p-bit. The p-bits are hence only used for a routing decision. There are
no additional QoS requirements besides the generic QoS-handling available from the
'regular' cross-connect or residential bridging.
This procedure provides the steps to configure a QoS-aware VLAN.
Prerequisites
The following prerequisites must be fulfilled before a QoS-aware VLAN can be
configured:

A QoS policer profile must have been created
A QoS session profile must have been created
A QoS profile must have been created
Procedure
Proceed as follows to configure a QoS-aware VLAN:
1 Create a QoS-aware VLAN:
i Create a QoS-aware VLAN on the LT with the following command:

mode qos-aware
ii Create a C-VLAN on the SHub with the following command:

mode cross-connect

port-type network
(no) mc-flooding
ii Change the administrative status of the SHub network port with the following
command:
configure interface shub port (network-port) admin-status up
iii Configure the SHub network egress port with the following command:

iv Configure the SHub network egress port on the LT with the following
command:

configure vlan id 350 name ISP_C_VLAN-350 mode qos-aware
configure vlan shub id 350 name ISP_C_VLAN-350

mode cross-connect

admin-up
configure bridge port 1/1/5/4:8:35 vlan-id 350 prior-ctrl-load

prior-less-100ms prior-less-10ms prior-nw-ctrl
configure bridge port 1/1/5/4:8:36 vlan-id 350 prior-best-effort

prior-background prior-spare prior-exc-effort
configure bridge port 1/1/5/4:8:35 pvid 350 default-priority 5

prio-regen-prof cl-all-prio-3
DLP 136 Configure multicast on the
LT
Purpose
This procedure provides the steps to configure multicast on the LT (general parameters,
capacity and source table) on the NE.
Procedure
Proceed as follows to configure multicast on the LT:
1 Configure the general multicast parameters with the following command:
configure mcast general

(no) package-member <Igmp::Pkg>
(no) fast-change
(no) pkg-memb-bitmap <Igmp::PkgMemBitMap>
(no) max-bitrate <Igmp::GeneralMcastMaxBitRate>
(no) mean-bit-rate <Igmp::GeneralMcastMeanBitRate>
Note 1 The minimum bitrate available for multicast is configured with

the command configure xdsl service-profile; see DLP 129.
Note 2 The parameter pkg-memb-bitmap is kept for backward

compatibility with previous releases.
2 Configure the multicast capacity parameters with the following command:
configure mcast capacity

(no) max-num-group <Igmp::McastCapacityMaxNumGroup>
(no) max-num-uncfg <Igmp::McastCapacityMaxNumUnCfg>
(no) cfg-res-time <Igmp::reserveTim>
(no) uncfg-res-time <Igmp::reserveTim>
DLP 136 Configure multicast on the LT
3 Configure the multicast source with the following command:
configure mcast src (class-d-addr)

(no) dis-fast-change
(no) pkg-mem-bitmap <Igmp::PkgMemBitMap>
(no) name <Igmp::multicastSrcName>
(no) guaranteed-serv
(no) atm-peak-bit-rate <Igmp::McastSrcAtmPeakBitRate>
(no) eth-peak-bit-rate <Igmp::McastSrcEtherPeakBitRate>
(no) atm-sus-bit-rate <Igmp::McastSrcAtmSustainBitRate>
(no) eth-sus-bit-rate <Igmp::McastSrcEtherSustainBitRate>
vlan-id <Igmp::McastSrcVLANID>
(no) service-name <Igmp::multicastSrcServiceName>
(no) preview-duration <Igmp::multicastSrcMaxPreDuration>
(no) preview-number <Igmp::multicastSrcMaxPreNumber>
(no) preview-blackout <Igmp::multicastSrcPreBlackout>
Note 1 The parameter pkg-memb-bitmap is kept for backward

Note 2 The parameters atm-peak-bit-rate and atm-sus-bit-rate are

obsolete and are replaced by eth-peak-bit-rate and eth-sus-bit-rate
respectively.
4 Configure the multicast source package members with the following command:
configure mcast src (class-d-addr)

(no) packagemember (package)
configure mcast general package-member 50
configure mcast general max-bitrate 5000 mean-bit-rate 1000
configure mcast capacity max-num-group 128 max-num-uncfg 20
configure mcast src 224.1.1.10 eth-peak-bit-rate 5000

eth-sus-bit-rate 3000 vlan-id 100
configure mcast src 224.1.1.10 packagemember 50
Purpose
This procedure provides the steps to configure IGMP proxy on the LT.
Procedure
Proceed as follows to configure proxy on the LT:
1 Configure the IGMP source channel parameters with the following command:
configure igmp channel (port)

(no) perm-pkg-bitmap <Igmp::PkgMemBitMap>
(no) max-num-group <Igmp::ChannelMaxNumGroup>
(no) cac-disable
(no) ip-anti-spoof-dis
(no) igmp-version <Igmp::UserItfVersion>
Note The parameter pkg-memb-bitmap is kept for backward

2 Configure the IGMP channel permission package members with the following
command:

(no) fullview-packages (package)
3 Configure the IGMP channel preview package members with the following
command:

(no) preview-packages (package)
4 Configure the package bitmaps. The package is intended primarily for use by a
network element manager, such as AWS, to support multiple sets of packages in
different regions.
A package is a group of zero or more multicast sources that share a common access
permission. By grouping the source channels into one or more packages, it provides
flexibility for the service provider to deliver different levels of services to the
end-users, for example, Basic Package, Middle-Tier Package, and Premium
Package.
Use the following command:
configure igmp package (index)

(no) name <PrintableString-0-32>
(no) template-name <PrintableString-0-32>
template-version <Igmp::igmpPackageTemplateVersion>
5 Configure the IGMP parameters on a per-VLAN basis with the following command:
configure igmp vlan (vlan-id)

netw-igmp-version <Igmp::VlanV3ProcessStatus>
(no) v3-max-num-rec <Igmp::V3MaxNumRecordReport>
Note The IGMP system may not be started when the IGMP version
is configured. If the system has been started, then it must first be stopped
before the IGMP version can be configured. Use the following command:
configure igmp system no start
After configuration, the IGMP system must be started again with the
command
configure igmp system start

6 Configure the IGMP system parameters with the following command:
configure igmp system

src-ip-address <Ip::V4Address>
(no) verify-checksum
(no) query-interval <Igmp::SystemQueryInterval>
(no) max-rsp-time <Igmp::SystemQueryMaxResponseTime>
(no) robustness <Igmp::SystemRobustness>
(no) mem-query-int <Igmp::MembQueryIntvl>
(no) last-memb-cnt <Igmp::MembQueryCount>
(no) last-max-resp-tim <Igmp::SystemLastMembMaxRespTime>
(no) host-report-intv <Igmp::SystemUnsolicitedReportIntvl>
(no) start
(no) preview-valid <Igmp::SystemPrevalidIntval>
(no) cdr-validation <Igmp::SystemPrecdrvalidIntval>
(no) cdr-generation
(no) except-cdr-rate <Igmp::CDRGenerationForSingles>
(no) cdr-export <Igmp::CDRGenerationMethod>
(no) cdr-file-aging <Igmp::CDRFileAgingTime>
(no) cdr-polling <Igmp::CDRSystemPollingCycle>
(no) user-igmp-version <Igmp::igmpSystemGMQToUserSideVersion>
(no) netw-igmp-version <Igmp::V3ProcessingAdminStatus>
(no) v3-max-num-rec <Igmp::V3MaxNumRecordsReport>
Note 1 The networkside IGMP version must be the same as the IGMP
version configured at the SHub. The user side IGMP version can be
different, the IGMP system will do the translations.
Note 2 The default version is IGMPv3.

7 Configure the IGMP system system Call Detail Record (CDR) with the following
command:
configure igmp system cdr-type

(no) periodic
(no) period <Igmp::IntermGenCDRPeriod>
(no) attempt-max-pview
(no) attempt-blackout
(no) attempt-no-perm
configure igmp channel 1/1/5/1:8:35 max-num-group 2
configure igmp channel 1/1/5/1:8:35 fullview-packages 20
configure igmp channel 1/1/5/1:8:35 preview-packages 49
configure igmp package 20 name IGMPpack20 template-version 1
configure igmp system no start
configure igmp vlan 200 netw-igmp-version 2
configure igmp system start
configure igmp system src-ip-address 192.168.100.100 start

cdr-generation
Purpose
This procedure provides the steps to configure IGMP snooping on the SHub.
Procedure
Proceed as follows to configure IGMP snooping on the SHub:
1 Configure the IGS system parameters with the following command:
configure igmp shub igs-system

(no) start-snooping
(no) enable-snooping
self-ip-addr-mode configure | from-ip
(no) self-ip-addr <Ip::V4Address>
trace-selection <SignedInteger>
(no) router-purge-intv <Igmp::RouterInterval>
(no) host-purge-intv <Igmp::HostInterval>
(no) max-mcast-learn <Igmp::MaxMulticastLearn>
(no) glb-leave <Igmp::GlobalLeaveMessageStatus>
(no) reduced-resp-int <Igmp::ReducedResponseInterval>
(no) remove-root-int <Igmp::RemoveRootTimer>
2 Configure the SHub response timer for a VLAN with the following command:
configure igmp shub response-timer (vlan-id)

(no) leave-rsp-timer <Igmp::LeaveResponse>
3 Configure the router port with the following command:
configure igmp shub vlan-router-port (vlan-id)

network-port <Shub::NetworkPort>
4 View the status of the IGMP VLAN router ports with the following command:
show igmp shub vlan-router-port (vlan-id)

5 Configure the VLAN filter to enable or disable IGMP snooping on that specific VLAN
configure igmp shub vlan-filter (filter-id)

(no) snoop-filter
(no) igmp-version <Igmp::VlanVersion>
(no) operation-mode <Igmp::VlanMode>
(no) self-ip-addr-mode <Igmp::VlanSelfIpAddressMode>
(no) self-ip-addr <Ip::V4Address>
(no) querier <Igmp::VlanQuerier>
(no) query-int <Igmp::VlanQueryInterval>
(no) v2-max-rsp-time <Igmp::V2VlanMaxResponseTime>
(no) v3-max-rsp-time <Igmp::V3VlanMaxResponseTime>
(no) v3-max-num-rec <Igmp::VlanMaxV3AllowedGrps>
(no) drop-rpt-network <Igmp::ReportAcptOnAllPorts>
(no) robustness <Igmp::VlanRobustnessVar>
(no) unsolicit-rpt-int <Igmp::VlanUnsolicitedReportInterval>
(no) retry-count <Igmp::VlanRetryCount>
Note 1 The IGMP version configured at the SHub must be the same
as the networkside IGMP version.
Note 2 If the IGMP version needs to be changed, then the snoop filter
must first be enabled with the command
configure igmp shub vlan-filter (filter-id) snoop-filter
After configuration, the snoop filter must be disabled again wit hthe
command
configure igmp shub vlan-filter (filter-id) no

snoop-filter
6 Configure the IGMP Connection Admission Control (CAC) bundle with the following
command:
configure igmp shub bundle (bundle)

(no) bandwidth <Igmp::BundleBandWidth>
(no) max-num-channel <Igmp::BundleMaxChannel>
configure igmp shub igs-system start-snooping

enable-snooping self-ip-addr-mode configure
self-ip-addr 192.168.100.100
configure igmp shub response-timer 500 leave-rsp-timer 3
configure igmp shub vlan-router-port 500 network-port 3
show igmp shub vlan-router-port 500 network-port 3
configure igmp shub vlan-filter 500 snoop-filter
configure igmp shub vlan-filter 500 igmp-version 2
configure igmp shub vlan-filter 500 no snoop-filter
configure igmp shub bundle MyBundle bandwidth 5000

max-num-channel 10
DLP 139 Configure DHCP relay agent
in iBridge mode
Purpose
In the iBridge mode, the user subnets need to be configured on the user gateway
interface of the SHub. This is needed to advertise the user subnet routes into the network
via routing protocols and also to forward user IP packets in downstream direction to LTs
(in the routing table of Shub, direct subnet routes need to be created on the V-VLAN).
DHCP Relay is configured per VLAN:
Enable/disable DHCP relay agent on the SHub.

Enable/disable Option-82 insertion.
Option-82 insertion is configurable irrespective of the DHCP relay agent status.
The DHCP relay agent IP address (separate configuration parameter) is the IP
address of one of the VRF IP interfaces.
This procedure provides the steps to configure the DHCP relay agent in iBridge mode.
Prerequisite
The following prerequisite must be fulfilled before DHCP relay agent can be configured
on an iBridge VLAN:
The iBridge VLAN must have been created; see DLP 120.
Procedure
Proceed as follows to configure the DHCP relay agent:
1 Create a VRF on the SHub with the following command:
configure ip shub vrf (index) name <Vrf::ShubVrfName>

slow-path-mode
2 Add DHCP Option-82 to the iBridge VLAN with the following command:
configure vlan id (vlanid)

dhcp-opt-82
circuit-id-dhcp <Vlan::CircuitIdDhcp>
remote-id <Vlan::RemoteId>
3 Add an IP address to the iBridge VLAN, and add the VLAN to the VRF with the
following commands:
i Change the administrative status of the iBridge VLAN to down with the
following command:
configure interface shub vlan-id (vlan-id)

admin-status down
ii Add an IP address to the iBridge VLAN with the following command:
configure interface shub ip (vlan-id)

iii Add the VLAN to the VRF with the following command:
configure interface shub ip (vlan-id) vrf-id <Vrf::ShubVrfID>
iv Change the administrative status of the iBridge VLAN to up with the following
command:

admin-status up
4 Enable the SHub relay agent with the following command:
configure dhcp-relay shub relaying
5 Configure the list of DHCP relay server to a particular VRF with the following
command:
configure dhcp-relay shub server (index)

ip-addr <Ip::V4Address>
server-name <PrintableString-0-32>
6 Configure the DHCP relay agent parameters to a particular VRF with the following
command:
configure dhcp-relay shub agent (vrfid)

(no) enable-relaying
(no) secs-threshold <Dhcp::SecsThreshold>
(no) hops-threshold <Dhcp::HopThreshold>
(no) context-lifetime <Dhcp::ContextLife>
(no) agent-ip-addr <Ip::V4Address>
configure ip shub vrf 10 name ibridge-relay-vrf10 slow-path-mode

remote-id customer-id
configure dhcp-relay shub server 10 ip-addr 192.168.100.13

server-name DHCPRell0
configure dhcp-relay shub agent 10 enable-relaying

agent-ip-addr 192.168.100.2
in router mode
Purpose
In the router mode, the user subnets need to be configured on the user-gateway interface
of SHub. This is needed to advertise user subnet routes into network via routing protocols
and also to forward user IP packets in downstream to LTs (in the routing table of SHub,
direct subnet routes need to be created on the V-VLAN).
Enable/disable DHCP relay agent

Enable/disable Option-82 insertion
Option-82 insertion is configurable irrespective of the DHCP relay agent status.
This procedure provides the steps to configure the DHCP relay agent.
Prerequisite
The following prerequisite must be fulfilled before a DHCP Relay Agent in router mode
can be configured:
a V-VLAN must have been created; see DLP 116.
DLP 140 Configure DHCP relay agent in router mode
Procedure
1 Configure the DHCP relay agent per VRF interface with the following command:
configure dhcp-relay agent (vrfid)

bcast-vlan <Dhcp::VlanId>
(no) option-82
(no) circuit-id <Dhcp::CircuitId>
(no) remote-id <Dhcp::RemoteId>
(no) dhcp-linerate <Dhcp::Dhcp-linerate>
3 Configure the list of DHCP Relay Server to a particular VRF with the following
command:
configure dhcp-relay shub server (index)

4 Configure the DHCP relay agent parameters to a particular VRF with the following
command:
configure dhcp-relay shub agent (index)

agent-ip-addr <Ip::V4Address>

option-82 circuit-id physical-id remote-id customer-id

server-name Antwerp15

in forwarder mode
Purpose
The DHCP relay port functionality provided by LTs is exactly the same as in the router
mode. One difference is that, in the forwarder mode, there is no need to have a dedicated
V-VLAN to be used as a broadcast VLAN for DHCP relay. Instead, one of the network
VLANs is used at the same time as a broadcast VLAN by LTs.
Enable/disable DHCP relay agent

Enable/disable Option-82 insertion
Option-82 insertion is configurable, irrespective of the DHCP relay agent status.
This procedure provides the steps to configure the DHCP relay agent.
Procedure
1 Create a VRF on the SHub with the following command:
configure ip shub vrf (index) name <Vrf::ShubVrfName>

slow-path-mode
2 Add DHCP Option-82 to the forwarder VLAN on the LT with the following command:

(no) option-82
(no) circuit-id <Dhcp::CircuitId>
(no) remote-id <Dhcp::RemoteId>
(no) client-hw-address <Dhcp::ChaddrMode>
3 Add an IP address to the forwarder VLAN, and add the VLAN to the VRF with the
following commands:
i Change the administrative status of the VLAN to down with the following
command:

admin-status down
ii Add an IP address to the VLAN with the following command:

iii Add the VLAN to the VRF with the following command:
configure interface shub ip (vlan-id) vrf-id <Vrf::ShubVrfID>
iv Change the administrative status of the VLAN to up with the following

command:

admin-status up
5 Configure the list of DHCP relay servers to the VRF with the following command:
configure dhcp-relay shub server (vrfid)

ip-addr<Ip::V4Address>
6 Configure the DHCP relay agent parameters to the VRF with the following
command:
configure dhcp-relay shub agent (vrfid)

agent-ip-addr <Ip::V4Address>
configure ip shub vrf 17 name forw-relay-vrf17 slow-path-mode

option-82 circuit-id physical-id remote-id customer-id

server-name Antwerp17

DLP 142 Configure the security
domain
Purpose
This procedure provides the steps to configure the security domain.
Procedure
Proceed as follows to configure the security domain:
1 Configure the security domain with the following command:
configure system security domain (name)

vrf-index <Aaa::DomainVrfIndex>
(no) vlan-id <Vlan::VlanIndexOrZero>
(no) primary-dns <Ip::V4Address>
(no) second-dns <Ip::V4Address>
(no) primary-nbns <Ip::V4Address>
(no) second-nbns <Ip::V4Address>
(no) sess-timeout <Aaa::DomainSessionTimeout>
(no) qos-policy none | name:<Aaa::IgnoredQosProfileName>
authenticator local | radius:<Aaa::RadPolicyName>
(no) admin-down
2 Define the security domain IP pool with the following command:
configure system security ip-addr-pool (name)

vrf-index <Aaa::IpVrfIndex>
start-addr <Ip::V4Address>/<Ip::PrefixLength>
(no) size <Aaa::IpAddressPoolSize>
(no) admin-down
DLP 142 Configure the security domain
3 Assign the security domain IP pool with the following command:
configure system security domain (name) ip-pool (name)

vrf-index <Aaa::VrfIndex>
priority <SignedInteger>
configure system security domain Domain1 vrf-index 16 vlan-id 56

authenticator local
configure system security ip-addr-pool PoolDomain1 vrf-index 16

start-addr 10.179.16.100/24 size 100 no admin-down
configure system security domain Domain1 ip-pool PoolDomain1

vrf-index 16 priority 3
DLP 143 Configure local
authentication
Purpose
This procedure provides the steps to configure local authentication.
Prerequisite
The following prerequisite must be fulfilled before local authentication can be configured:
A VRF must have been created.
Procedure
Proceed as follows to configure local authentication:

authenticator local
2 Define the domain users with the following command:
configure system security domain (name) user (name)

password <Password>
3 Change the password for a specific user with the following command:
configure system security domain (name) user (name) password

<new Password>
4 Delete a user from the authentication table with the following command:
configure system security domain (name) no user (name)
DLP 143 Configure local authentication
configure system security domain Domain1 vrf-index 16

authenticator local
configure system security domain Domain1 user JohnDoe

password zxspr12
configure system security domain Domain1 user JohnDoe

password acdd35d
configure system security domain Domain1 no user JohnDoe
Purpose
This procedure provides the steps to configure the Remote Authentication Dial-In User
Service (RADIUS).
Procedure
Proceed as follows to configure RADIUS:
1 Configure the RADIUS authentication server with the following command:
configure system security radius auth-server (name)

ip-address <Ip::V4Address>
(no) port <Aaa::InetPortNumber>
secret <Password>
(no) retry-limit <Aaa::RadiusRetryLimit>
(no) timeout-limit <Aaa::RadiusTimeout>
(no) admin-down
(no) dead-interval <Aaa::RadiusDeadInterval>
2 Configure the RADIUS accounting server with the following command:
configure system security radius acc-server (name)

secret <Password>
(no) admin-down
3 Configure the RADIUS policy with the following command:
configure system security radius policy (name)

nas-id <Printable-0-64>
nas-ip-address <Ip::V4Address>
(no) keep-domain-name
(no) disable-accnt-msg
(no) acc-interval <Aaa::AccInt>
(no) disable-eap
4 Configure the RADIUS server set with the following command:
configure system security radius policy (name) servers (index)

auth-server none | name:<Aaa::RadAuthServerName>
vrf-index-auth <Aaa::VrfIndex>
(no) acc-server none | name: <Aaa::RadAccServerName>
(no) vrf-index-acc <Aaa::VrfIndex>
priority <Aaa::Priority>
5 Enable the RADIUS relay on the SHub with the following command:
configure system security radius

(no) relay
(no) auth-super-user <Aaa::SuperUserAuth>
oper-policy-name <Aaa::OperatorRadPolicyName>

(no) primary-dns <Ip::V4Address>
(no) second-dns <Ip::V4Address>
(no) primary-nbns <Ip::V4Address>
(no) second-nbns <Ip::V4Address>
(no) qos-policy none | name:<Aaa::IgnoredQosProfileName>
authenticator radius:<Aaa::RadPolicyName>
(no) admin-down
7 Configure the RADIUS Dynamic Authorization Clients with the following command:
configure system security radius dyn-auth-client (name) vrf-index

<Aaa::VrfIndex>
secret <Password>
(no) admin-down
configure ip vrf 1 name Dummy
configure system security radius auth-server RADAuthServ1

vrf-index 0 ip-address 10.176.5.5 secret Khinghkhongh
timeout-limit 5
configure system security radius acc-server RADAccServ1 vrf-index

0 ip-address 10.176.5.55 secret Ahlakazam
configure system security radius policy RADPol23 nas-id MyNASID

nas-ip-address 192.168.122.122
configure system security radius policy RADPol23 servers 2

auth-server name:RADAuthServ1 vrf-index-auth 0 acc-server
name:RADAccServ1 vrf-index-acc 0 priority 162
configure system security domain SecDomain1 vrf-index 1

authenticator radius:RADPol23
configure system security radius dyn-auth-client DynAuth1

Purpose
This procedure provides the steps to enable, disable, and configure parameters for
802.1x.
Procedure
Proceed as follows to configure 802.1x:
1 Enable 802.1x with the following command:
configure system security pae port-access
2 Configure the 802.1x parameters with the following command:
configure system security pae authenticator (port)

(no) controlled-port <Aaa::PaeControlledPortControl>
(no) quiet-period <Aaa::paeQuitTime>
(no) tx-period <Aaa::paeTime>
(no) supp-timeout <Aaa::paeTime>
(no) server-timeout <Aaa::paeTime>
(no) max-req <Aaa::paeMaxReq>
3 Configure the remote authenticator and enable authentication and handshake with
configure system security pae ext-authenticator (port)

(no) authentication
(no) init-authreq-off
(no) handshake
(no) handshake-period <Aaa::PortHandShakePeriod>
4 Enable initialization control for a port with the following command:
configure system security pae port (port)

(no) initialize
configure system security pae authenticator 1/1/5/1:8:35

controlled-port force-unauthorized server-timeout 20 max-req 5
configure system security pae ext-authenticator 1/1/5/1:8:35

authentication handshake
configure system security pae port 1/1/5/1:8:35 initialize
Purpose
PPPoE relay needs no configuration. It should only be enabled or disabled on a specific
VLAN.
Behavior of the Line ID

The behavior of the line ID is determined by the value of the parameter pppoe-relay-tag.
The value of the parameter pppoe-relay-tag can be:
true:
if pppoe-relay-tag is set to true, then the values of circuit-id-pppoe and of
remote-id-pppoe are irrelevant.
The NE adds the vendor-specific tag and always puts the customer-id parameter into
the remote-id suboption, and will always generate a string (access node, rack,...) to
put in the circuit-id suboption.
false (default):
if pppoe-relay-tag is false, then the values of circuit-id-pppoe and of remote-id-pppoe
are irrelevant.
The NE does not add the vendor-specific tag.
configurable:
if pppoe-relay-tag is set to configurable, then the values of circuit-id-pppoe and of
remote-id-pppoe are relevant and subject to the same rules as for DHCP.
The NE adds the vendor specific tag according the settings of these suboptions. The
DHCP-like rules that apply are that the values of both suboptions cannot be identical
(2 x customer-id would result in adding the same configurable string in both
suboptions, 2 x notAdd would result in a vendor-specific tag with without suboptions).
In both cases where a string is to be generated (that is, the case where pppoerelaytag is
configurable and circuit-id-pppoe is set to physcial-id; and the case where pppoerelaytag
is set to true), the string format is identified by:
the configurable syntax parameters (ADSL/EFM): configurable via the loop-id-syntax;

see DLP 103, step 1.
the port numbering method: configurable via the parameter port-num-inpro; see
DLP 103, step 3.
Prerequisite
The following prerequisite must be fulfilled before PPPoE can be enabled on a VLAN:
Procedure
Proceed as follows to enable or disable PPPoE relay:
1 Enable PPPoE relay and, if required, configure the vendor-specific tag with the
following command:

2 Disable PPPoE relay with the following command:
configure vlan id (vlanid) no pppoe-relay-tag
configure vlan id 560 mode residential-bridge name PPPoXVlan560
configure vlan id 560 pppoe-relay-tag configurable

circuit-id-pppoe physical-id remote-id-pppoe customer-id
pppoe-linerate addactuallinerate
configure vlan id 560 no pppoe-relay-tag
Purpose
This procedure provides the steps to configure PPPoX relay.
Prerequisites
The following prerequisites must be fulfilled before PPPoX relay can be configured:
An iBridge VLAN must have been created; see NTP 105.
Procedure
Proceed as follows to configure PPPoX relay:
1 Configure PPPoX CC global parameters with the following command:
configure pppox-relay cross-connect global-session

(no) pado-timeout <PPPoX::PadTimeOut>
(no) pads-timeout <PPPoX::PadTimeOut>
(no) max-pad-attempts <PPPoX::PadRRetrials>
(no) trans-max-age <PPPoX::TransactionMaxAge>
(no) cc-max-age <PPPoX::CcMaxAge>
2 Configure the PPPoX CC engine with the following command:
configure pppox-relay cross-connect engine (vlan-id)

(no) max-payload-tag <PPPoX::MaxPayLoadTag>
(no) name <PPPoX::EngineName>
(no) lock
(no) service-name <PPPoX::EngineName>
3 Enable monitoring of the PPPoX CC engine with the following command:
configure pppox-relay cross-connect engine (vlan-id) monitor
4 Configure PPPoX CC client port with the following command:
configure pppox-relay cross-connect client-port (port)

vlan-id <Vlan::UVlanIndex>
| stacked:<Vlan::SVlanIndex>:<Vlan::CVlanIndex>
default-priority <PPPoX::DefaultPriority>
(no) max-cc <PPPoX::MaxNumPppCc>
(no) qos-profile none | name:<PPPoX::IgnoredQosProfileName>
5 Enable monitoring of the PPPoX CC client port with the following command:
configure pppox-relay cross-connect client-port (port) monitor
configure pppox-relay cross-connect global-session

trans-max-age 250 cc-max-age 600
configure pppox-relay cross-connect engine 560 name PPPoXRelay560
configure pppox-relay cross-connect engine 560 monitor
configure pppox-relay cross-connect engine 560 max-payload-tag

insert

admin-up
configure interface port xdsl-line:1/1/5/10 user Line1152:8.35

aal5-encap-type automatic:ppp
configure pppox-relay cross-connect client-port 1/1/5/10:8:35

vlan-id 560 default-priority 4
Purpose
This procedure provides the steps to create the PPPoE server and the state of the PPPoE
server.
By default, the PPPoE server is disabled.
Procedure
Proceed as follows to configure the PPPoE server:
1 Configure the PPPoE server with the following command:
configure pppoe server-name <PPPoE::ServerName> enable-server
configure pppoe server-name PPPoEServer1 enable-server
Purpose
This procedure provides the steps to create and configure the PPPoE profiles.
Procedure
Proceed as follows to configure the PPPoE profiles:
1 Create and configure a PPPoE profile with the following command:
configure pppoe ppp-profile (index)

(no) auth-type <PPPoE::pppProfileAuthenType>
(no) keep-alive-intvl <PPPoE::ProfileKeepAliveInterval>
configure pppoe ppp-profile PPPProf1 auth-type chap-pap
Purpose
This procedure provides the steps to configure an ARP table entry.
Prerequisite
The following prerequisite must be fulfilled before an ARP table entry can be configured:
Procedure
Use the following procedure to configure an ARP table entry:
1 Configure the IP Shub ARP parameters with the following command:
configure ip shub arp

(no) cache-timeout <Ip::ArpCacheTimeOut>
(no) cache-pending <Ip::ArpCachePendingTime>
(no) cache-refresh <Ip::ArpCacheRefreshTime>
(no) cache-retry-time <Ip::ArpCacheRetryTime>
(no) max-retry-itvl <Ip::ArpCacheMaxRetryTime>
(no) max-retries <Ip::ArpMaxRetries>
2 Configure the IP Shub ARP parameters per VLAN with the following command:
configure ip shub arp vlan (vlanid)

(no) gratuitous-arp
configure ip shub arp cache-timeout 10000 cache-pending 35

max-retries 5
configure ip shub arp vlan 4093 gratuitous-arp
Purpose
This procedure provides the steps to change the flash disk on the NT board and to restart
the NT.
Caution The following procedure should be executed during

low-traffic hours as the functional working of the NE is affected.
Warning All precautions and warnings with respect to the safety

guidelines and electrostatic dangers should be read and followed.
Note It is recommended to take a backup of the NE before executing

the procedure.
Location of the flash disk on the NT board

The flash disk is located at the top of the board next to the top rear connector; see Figure
DLP 151-1.
Figure DLP 151-1: Location of the flash disk on the NT board
Note Observe how the flash disk is plugged in on the NT board

before removing the flash disk.
Procedure
Proceed as follows to restart the NT:
1 Prepare the system for shutdown with the following command:
admin equipment prepare-sys-shutdown
2 Pull out the NT board.
3 Swap the flash disk from the old NT board with the new NT board (see Figure DLP
151-1 for the location of the flash disk).
4 Insert the new NT board in the NE.
5 Observe that the NT is loaded properly.
6 Verify that the previously activated features are working again.
7 Send the old NT board back to Alcatel-Lucent.
admin equipment prepare-sys-shutdown
Purpose
You can reboot the whole system in the following modes:
restart with self-test

restart without self-test
system hot restart
Procedure
Proceed as follows to reboot the system:
1 Reboot the system with the following command:
admin equipment reboot-isam <Equipm::SystemRestart>
admin equipment reboot-isam with-self-test
DLP 153 Shut down and restart
individual equipment
Purpose
This procedure provides the steps to shut down and restart slots containing plug-in units
on the NE shelf.
Note This procedure is not valid for the Remote Expansion Module
(REM).
General
The only individual pieces of equipment that may be necessary to restart are plug-in units
such as LTs. These can be shut down and restarted by powering down the slot in which
the plug-in unit is inserted.
Procedure
Proceed as follows to shut down and restart individual equipment:
1 Power down a plug-in unit with the following command:
configure equipment slot <Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::Slot>

power-down
2 Restore power to a plug-in unit with the following command:
configure equipment slot <Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::Slot>

no power-down
DLP 153 Shut down and restart individual equipment
configure equipment slot 1/1/5 power-down
configure equipment slot 1/1/5 no power-down
DLP 154 Create a snapshot alarm
table
Purpose
This procedure provides the steps to create a snapshot alarm table.
General
In the NE, a lot of different alarms may occur. This can sometimes make it difficult for an
operator to investigate, since alarms can appear, disappear, and so on.
Therefore, the snapshot principle exists. A snapshot is in fact a picture of all the alarms
that are present on the moment the snapshot is taken.
A table is created which contains a copy of the alarms which are present in the system at
the time the snapshot was taken.
The operator can filter this table by specifying a minimum alarm level. Only alarms with
a level equal or higher than the specified level, will be present in the table.
This table is only temporary and exist only for 4 minutes. After the 4 minutes, the table is
cleared automatically (the alarms are not displayed anymore), and a new snapshot can
be taken.
The operator can also clear the table manually if he wants to take a new snapshot
immediately (that is, not wait for the 4 minute timer to expire).
Procedure
Proceed as follows to create a snapshot alarm table:
1 Create an alarm snapshot table for a minimum severity level with the following
command:
admin alarm snap-shot

start:indeterminate:<Alarm::alarmSnapShotOwner>
| start:warning:<Alarm::alarmSnapShotOwner>
| start:minor:<Alarm::alarmSnapShotOwner>
| start:major:<Alarm::alarmSnapShotOwner>
| start:critical:<Alarm::alarmSnapShotOwner>
| start:<SignedInteger>:<Alarm::alarmSnapShotOwner>
Note The command will fail if the snap-shot is already in use. The
snap-shot is only kept for a limited time and will be automatically cleared.
2 The alarm snapshot table can be viewed with the following command:
show alarm snap-shot table | equipment | eqpt-holder

| plug-in-unit | atm | ether-itf | sw-mgmt | xdsl | xdsl-tca
| eo-conversion | authentication | bonding-group | ipox
| redundancy | custom | sfp | llu-relay | custom-ext-alarm
| plug-in-unit-ext | sip-user-agent | sip-plugin-unit
| sip-termination | shdsl | shdsl-isam | ima-group | ima-link
| ether-tca | ether-sfp | qos-slot | qos-queue | filetransfer
| external-device (index)
Note The command can be given with or without extra parameters:
When NO parameter is given, all the alarms will be shown.

More detailed information can be displayed by specifying the type of
alarm.
3 Create an alarm snapshot table on the SHub with the following command:
admin alarm shub snap-shot

start:indeterminate:<Alarm::alarmSnapShotOwner>
| start:warning:<Alarm::alarmSnapShotOwner>
| start:minor:<Alarm::alarmSnapShotOwner>
| start:major:<Alarm::alarmSnapShotOwner>
| start:critical:<Alarm::alarmSnapShotOwner>
| start:<SignedInteger>:<Alarm::alarmSnapShotOwner>
4 The SHub alarm snapshot table can be viewed with the following command:
show alarm shub snap-shot table (index)
Note The command can be given with or without extra parameters:
When NO parameter is given, all the tables will be shown.

More detailed information can be displayed by specifying the type of
alarm.
5 The alarm snapshot table can be cleared with the following command:
admin alarm snap-shot stop
Note The alarms are not shown anymore and a new snapshot can
now be taken, if required.
6 The alarm snapshot table on the SHub can be cleared with the following command:
admin alarm shub snap-shot stop
Note The alarms are not shown anymore and a new snapshot can
now be taken, if required.
The following command creates an alarm snapshot table for

snap-shot owner "tom" showing all the alarms with severity-level
"major" and higher.
admin alarm snap-shot start:major:tom
The following command displays the complete alarm table.
show alarm snap-shot table
The following command displays more information for the alarm type
"equipment".
show alarm snap-shot equipment
The following command creates an alarm snapshot table on the SHub

for snap-shot owner "tomtom" showing all the alarms with
severity-level "indeterminate" and higher.
admin alarm shub snap-shot start:indeterminate:tomtom
The following command displays the complete alarm table for the
SHub.
show alarm shub snap-shot table
The following command displays more information for the alarm type
"eth-shub" on the SHub.
show alarm shub snap-shot eth-shub
The following command clears the alarm snap shot.
admin alarm snap-shot stop
The following command clears the alarm snap shot on the SHub.
admin alarm shub snap-shot stop
Purpose
This procedure provides the steps to monitor alarms. Monitoring alarms includes viewing
current alarms, a snapshot of the NE alarms, and the current configuration of the alarm
delta logs.
General
Refer to the CLI Commands and Messages document for a full description of all the
commands related to alarm monitoring. The most common commands are listed in the
procedure below.
Procedure
Proceed as follows to monitor alarms:
1 Use the following commands to show the alarm log tables:
i View the general alarm log table with the following command:
show alarm log table
ii View a specific alarm log table with the following command:
show alarm log equipment | eqpt-holder | plug-in-unit

| atm | ether-itf | sw-mgmt | xdsl misc | xdsl near-end
| xdsl far-end | xdsl-tca | eo-conversion | authentication
| bonding-group | redundancy | custom | sfp | llu-relay
| custom-ext-alarm | plug-in-unit-ext | sip-user-agent
| sip-plugin-unit | sip-termination | shdsl | shdsl-isam
| ima-group | ima-link | ether-tca | ether-sfp | qos-slot
| qos-queue | filetransfer | external-device (index)
2 Use the following command to view the common values related to the alarm delta
logs:
show alarm delta-log alarm-changes
3 Use the following commands to view the current alarms:
i View the general alarm log table with the following command:
show alarm current table
ii View a specific alarm log table with the following command:
show alarm current equipment | eqpt-holder | plug-in-unit

| atm | ether-itf | sw-mgmt | xdsl misc | xdsl near-end
| xdsl far-end | xdsl-tca | eo-conversion | authentication
| bonding-group | redundancy | custom | sfp | llu-relay
| custom-ext-alarm | plug-in-unit-ext | sip-user-agent
| sip-plugin-unit | sip-termination | shdsl | shdsl-isam
| ima-group | ima-link | ether-tca | ether-sfp | qos-slot
| qos-queue | filetransfer | external-device (index)
Note The detail mode can be used to obtain more detailed

information on the alarm.
4 To view values related to the alarm delta log entries, use any of the following
commands:
a To display common values related to the delta log alarm, use the following
command:
b To display indeterminate values related to the delta log alarm, use the following
command:
show alarm delta-log indeterminate (index)
c To display warning values related to the delta log alarm, use the following
command:
show alarm delta-log warning (index)
d To display minor values related to the delta log alarm, use the following
command:
show alarm delta-log minor (index)
e To display major values related to the delta log alarm, use the following
command:
show alarm delta-log major (index)
f To display critical values related to the delta log alarm, use the following
command:
show alarm delta-log critical (index)
show alarm log table
show alarm log equipment 1
show alarm log xdsl misc
show alarm current table
show alarm delta-log indeterminate
show alarm delta-log warning
show alarm delta-log minor
show alarm delta-log major
show alarm delta-log critical
DLP 156 Management of the SHub
database
Note
The correct procedure is described in RTP 100.
DLP 156 Management of the SHub database
Purpose
This document provides the steps to save the SHub configuration database.
Caution The SHub database is part of the NT database. The system

automatically saves the SHub database every 10 minutes. If a change is
made to the SHub database and the system is reset prior to the database
being saved, the changes can be lost. The operator can check if the
database has been saved since the last change with the following
command.
show system shub entry status
Procedure
Proceed as follows to manage the SHub database:
1 Save the SHub database with the following command:
admin software-mngt shub database save
2 The status of the save operation (successful, failed, or still in progress) can be
viewed with the following command:
show software-mngt shub config-file
show software-mngt shub config-file
Note
The correct procedure is described in RTP 100.
DLP 159 Manage OSWP
Purpose
This procedure provides the steps to manage the Operational Software Package
(OSWP).
Prerequisite
The NE contains one OSWP, which is committed and active on all the boards.
Procedure
Proceed as follows to manage the OSWP in the NE:
1 Configure the download of an OSWP with the following command:
configure software-mngt oswp (index)

primary-file-server-id <SwMngt::serverId>
second-file-server-id <SwMngt::serverId>
download-set <SwMngt::downloadSet>
autofetch <SwMngt::autoFetch>
activate manually | after-download
Note The parameters download-set and autofetch are obsolete

parameters whose settings will be ignored by the system.
2 Configure database automatic activation and automatic backup states and

attributes. with the following command:
configure software-mngt database

(no) activate <SwMngt::DbAutoAct>
(no) backup <SwMngt::DbAutoBackup>
(no) auto-backup-intvl <SwMngt::DbAutoBackIntvl>
DLP 159 Manage OSWP
3 Start the actual OSWP download with the following command:
admin software-mngt oswp (index) download <SwMngt::oswpName>
4 Abort an OSWP download with the following command:
admin software-mngt oswp (index) abort-download
5 Activate an OSWP with the following command:
admin software-mngt oswp (index)

activate manually | after-download
6 Commit an OSWP with the following command:
admin software-mngt oswp (index) commit
configure software-mngt oswp 2

primary-file-server-id 192.168.111.112
second-file-server-id 192.168.111.212
activate manually
admin software-mngt oswp 2 download OSWP_packages/OSWP1
admin software-mngt oswp 2 activate with-linked-db
admin software-mngt oswp 2 commit
DLP 160 View version of the SHub
software
Purpose
This procedure provides the steps to view the software version number for the SHub.
Procedure
Proceed as follows to view the software version number for the SHub:
1 View the software version of the SHub system parameters with the following
command:
show system shub entry version
show system shub entry version
DLP 160 View version of the SHub software
DLP 161 View software licenses
counters
Description
The NE supports licensing counters. By these counters, the NE management station is
able to license a set of features provided by the NE in its network. The licensing counters
are defined at the level of the DSL interfaces.
Features
The feature counters can be retrieved by a manager for monitoring. The following
features are monitored in the NE:
ADSL2+
READSL2
ADSL2/ADSL2+ Annex M
IGMP
IP-Forwarding
PPPoX Relay
PPPoX Termination
802.1x
IPoA-CC
Procedure
Proceed as follows to retrieve the feature counters:
1 View the number of software licenses for the feature with the following command:
show system license adsl2-plus | readsl2 | igmp | ip-forward |

pppox-relay | pppox-termination | 802dot1x | annex-m | ipoa-cc
DLP 161 View software licenses counters
show system license
DLP 162 Modify the external
management VLAN
Purpose
This procedure gives the steps to change the external management VLAN.
Procedure
Proceed as follows to change the external management VLAN:
1 If required, you can view the current configuration as follows:
i View the external VLAN in the system with the following command:
info configure system
ii View the external VLAN in the SHub with the following command:
info configure system shub entry vlan
iii View the PVID on the management port with the following command:
info configure bridge shub port 1
2 Change the external VLAN in the system with the following command:

location <PrintableString-0-255>
contact-person <PrintableString-0-255>
(no) en-snmp-auth-traps <Transport::SnmpAuthTraps>
(no) ether-shape-rate <Sys::etherShapeRate>
mgnt-vlan-id <Vlan::VlanOamIndex>
system-mac <Sys::MacAddr>/<Sys::MacAddr>/<Sys::Number>
(no) single-public-ip
(no) port-num-inpro <Sys::PortNumberInprotocol>
DLP 162 Modify the external management VLAN
Note It is not possible to change the system MAC address or the

SHub MAC range when a SMAS board is available in the system.
3 Change the external VLAN in the SHub with the following command:
configure system shub entry vlan ext-vlan-id <Vlan::ExtVlanIndex>
Note When operating in single IP mode:
This command only serves to save the VLAN ID in protected data.
4 Configure the network port as egress port with the following command:

egress-port network:<Shub::NetworkPort>
5 If the management traffic is untagged, do the following:
i Configure the untag port and the PVID with the following commands:

untag-port network:<Shub::NetworkPort>
ii Change the PVID on the management port with the following command:
configure bridge shub port (network-port)

info configure system
info configure system shub entry vlan
info configure bridge shub port 7
configure system mgnt-vlan-id 72
configure system shub entry vlan ext-vlan-id 72
Purpose
This procedure provides the steps to modify xDSL spectrum profiles.
You can modify:
xDSL service profiles

Only the parameters name, scope and version can be changed for an existing xDSL
service profile. If other parameters need to be changed, then a new xDSL service
profile must be created.
xDSL spectrum profiles
Prerequisite
The following prerequisite must be fullfilled before an xDSL spectrum profile can be
modified:
The xDSL spectrum profile must have been created; see DLP 129.
Procedure
Proceed as follows to modify an xDSL spectrum profile:
1 Start the modification of an xDSL spectrum profile with the following command:
configure xdsl spectrum-profile (index) modification start
2 Modify the parameters of an xDSL spectrum profile with the following command:

local-profile
(no) dis-ansi-t1413
(no) dis-etsi-dts
(no) dis-g992-1-a
(no) dis-g992-1-b
(no) dis-g992-2-a
(no) dis-g992-3-a
(no) dis-g992-3-b
(no) g992-3-l1
(no) g992-3-l2
(no) g992-3-am
(no) g992-5-a
(no) g992-5-b
(no) ansi-t1.424
(no) dis-etsi-ts
(no) itu-g993-1
(no) ieee-802.3ah
(no) g992-5-am
(no) g993-2-8a
(no) g993-2-8b
(no) g993-2-8c
(no) g993-2-8d
(no) g993-2-12a
(no) g993-2-12b
(no) g993-2-17a
(no) g993-2-30a
(no) min-noise-down <Xdsl::NoiseMargin>
(no) min-noise-up <Xdsl::NoiseMargin>
(no) trgt-noise-down <Xdsl::NoiseMargin>
(no) trgt-noise-up <Xdsl::NoiseMargin>
(no) max-noise-down <Xdsl::NoiseMarginPlus>
(no) max-noise-up <Xdsl::NoiseMarginPlus>
(no) carrier-mask-down <Xdsl::CarrierMaskDown>
(no) carrier-mask-up <Xdsl::CarrierMaskUp>
(no) rf-band-list <Xdsl::RFBand>
(no) power_mgnt_mode <Xdsl::LinePowerMgtMode>
(no) l0-time <Xdsl::LineL0Time>
(no) l2-time <Xdsl::LineL2Time>
(no) l2-agpow-red-tx<Xdsl::LineL2Atpr>
(no) rau-noise-down <Xdsl::NoiseMargin>
(no) rau-noise-up <Xdsl::NoiseMargin>
(no) rau-time-down <Xdsl::RaTime>
(no) rau-time-up <Xdsl::RaTime>
(no) rad-noise-down <Xdsl::NoiseMargin>
(no) rad-noise-up <Xdsl::NoiseMargin>
(no) rad-time-down <Xdsl::RaTime>
(no) rad-time-up <Xdsl::RaTime>
(no) l2-agpw-to-red-tx <Xdsl::LineL2Atpr>
3 Use one of the following commands to complete the modification of the xDSL
spectrum profile:
a When the modifications must be kept:
configure xdsl spectrum-profile (index) modification complete
b When the modifications must be cancelled:
configure xdsl spectrum-profile (index) modification cancel
configure xdsl spectrum-profile 22 modification start
configure xdsl spectrum-profile 22 name test_profile
configure xdsl spectrum-profile 22 modification complete
Purpose
This procedure provides the steps to ping another host.
Procedure
Proceed as follows:
1 Ping another host with the following command:
ping (ip-addr)
(no) timeout <Ip::PingTimeout>
(no) tries <Ip::PingTries>
(no) mtu-size <Ip::PingMtu>
2 Ping another host in a given VRF (from the SHub) with the following command:
ping (ip-addr) vrf (vrf)

(no) timeout <Ip::PingTimeout>
(no) tries <Ip::PingTries>
(no) mtu-size <Ip::PingMtu>
ping 10.176.5.5 tries 3
ping 192.168.116.1 vrf 15 tries 3
Purpose
This procedure provides the steps to perform a traceroute action, aiming at determining
the route to a destination address.
Note 1 The traceroute command can only be executed on systems

operating in dual IP address mode, because this command runs on the
SHub. On systems operating in single IP address mode, the command
will not be accepted.
Note 2 The following applies for traceroute actions:
Only one traceroute can be ongoing at any point in time

A traceroute action must be explicitly terminated before a new
traceroute action can be initiated.
Procedure
Proceed as follows to perform a traceroute action:
1 For a traceroute action:
i Initiate the traceroute action with the following command:
traceroute (ip-addr)
first-hop <Ip::TracerouteTTL>
last-hop <Ip::TracerouteTTL>
(no) timeout <Ip::TracerouteTimeout>
(no) mtu-size <Ip::TracerouteMtu>
ii Terminate the traceroute action with the following command:
traceroute (ip-addr) no first-hop
2 For a traceroute action in a given VRF (from the SHub):
i Initiate the traceroute action with the following command:
traceroute (ip-addr) vrf (vrf)

first-hop <Ip::TracerouteTTL>
last-hop <Ip::TracerouteTTL>
(no) timeout <Ip::TracerouteTimeout>
(no) mtu-size <Ip::TracerouteMtu>
ii Terminate the traceroute action with the following command:
traceroute (ip-addr) vrf (vrf) no first-hop
traceroute 10.176.5.5 first-hop 2 last-hop 4 mtu-size 30
traceroute 10.177.5.5 vrf 15 first-hop 2 last-hop 4 mtu-size 30
DLP 166 Configure SNMP proxy CPE
management
Purpose
This procedure provides the steps to configure the CPE management functionality.
The configuration of the remote SNMP proxy CPE management functionality involves:
Enabling the CPE remote management function

Configuring the IP address of the CPE remote manager
Note Up to 5 managers can be configured.
Configuring the UDP trap port of the CPE remote manager
Procedure
Proceed as follows:
1 Configure the CPE remote management function with the following command:
configure cpe-management proxy-mode snmp
2 Configure the CPE manager with the following command:
configure cpe-management
(no) manager <CpeProxy::IPaddress>:<CpeProxy::PortNumber>
3 Configure a management session to a CPE with the following command:
configure cpe-management
(no) session (dslport)
(no) connection <CpeProxy::cpeIpProxySessionProtocolPort>
DLP 166 Configure SNMP proxy CPE management
4 Configure on the SHub the VLAN that will be used to transport IP packets for a CPE
management session inside the system with the following command:
configure cpe-management shub vlan-id (vlan-id)
5 View the global statistics and the statistics per CPE managerwith the following
command:
show cpe-management snmpproxy-statistics
configure cpe-management proxy-mode snmp vlan-id 400
configure cpe-management manager 192.168.200.200:2000
configure cpe-management shub vlan-id 400
configure cpe-management no proxy-mode
Purpose
A script file is a file containing CLI commands.
CLI scripts can be executed when they are stored on the flash-disk. Script files are
typically stored in the /var/cmd directory.
Warning: the /var/cmd is cleaned when the system resets, so the configuration file must
be transferred to another system with TFTP before resetting the system.
Note Saving the configuration will not work for areas in which
resource identifiers are assigned dynamically by the system.
Procedure
Proceed as follows to create and execute a script file:
1 The complete configuration of the system can be stored in a script with the following
command:
info configure | tee <file.txt>
info configure | tee config
info configure alarm flat | tee alaflat.cli
exec /var/cmd/alaflat.cli
DLP 168 Modify the system
management IP parameters
Purpose
This document describes the procedure to modify the system management IP
parameters.
Procedure
Proceed as follows to modify the system management IP parameters:
1 If a default route was defined at the time of creation (see DLP 102 or DLP 175),
remove the default route with the following command:
configure system management no default-route
2 Configure the system IP address allocation to dynamic with the following

command:
3 Configure the new host IP address of the system with the following command:

4 Configure the new default route of the system with the following command:
configure system management default-route <Ip::V4Address>
a If the system is a single IP address system; go to step 13
b If the system is a dual IP address system; go to step 6.
6 Change the administrative status of the management vlan on the SHub to down
configure interface shub vlan-id <Vlan::UVlanIndex>

admin-status down
7 Optionally, remove the IP address connected to the management vlan on the SHub
via the following command:
configure interface shub ip <Vlan::UVlanIndex>

no ip-addr <Ip::V4Address>/<Ip::PrefixLengthHost>
8 Configure the new IP address to the management vlan on the SHub via the following
command:
configure interface shub ip <Vlan::UVlanIndex>

ip-addr <Ip::V4Address>/<Ip::PrefixLengthHost>
9 Change the administrative status of the management vlan on the SHub to up with
configure interface shub vlan-id <Vlan::UVlanIndex>

admin-status up

vlan-id 4093
11 Save the changes on the NT disk with the following command:
12 To make the changes effective, the SHub must be restarted with the following
command:
admin equipment reboot-shub systemreset
1. Configuration example for a single IP address system:

manual:192.168.204.147/24
2. Configuration example for a dual IP address system:

manual:192.168.204.147/24

next-hop 192.168.204.1 vlan-id 4093
admin equipment reboot-shub systemreset
DLP 169 Configure cluster
management
Purpose
Cluster management in the NE is implemented as follows:
Each node of a cluster still keeps its public IP address.

The EMS manages each node independently via its public IP address, but offers the
possibility to the operator to define clusters at the EMS Graphical User Interface
(GUI) level, and give commands which are valid for the complete cluster (profile
management, backup and restore, software management, alarm management). EMS
then executes the commands sequentially to each DSLAM of the cluster.
The EMS supports topology display, which is made possible by a topology collection
process in the NE. For this topology collection, the NE supports the
neighbor-discovery and topology-collection protocols as defined in the CCSA
cluster management standard.
The EMS defines a command and a backup node for each cluster. Both the command
and the backup node will perform topology collection for the cluster. EMS retrieves the
collected cluster topology from the command node. If the command node fails, EMS
retrieves topology information from the backup node.
The neighbor-discovery protocol is supported in each node of the cluster. It sends
neighbor-discovery packets (with information of its own node) on each of its up- and
subtending links in a regular time-interval (default 60s). Through these packets, each
NE learns its directly connected environment.
A topology-collection protocol is started from the command node. Topology collection
can be done automatically and periodically by the NE (in this case, the EMS is trapped
by the NE if the topology is changed), or the operator on the EMS can start a manual
topology collection request. The NE sends topology request messages on all the links
to its neighbours learned through neighbor discovery. Each neighbor answers with a
topology reply containing info on its directly connected environment. Each neighbor
also forwards the original topology request on its other links, and the second-level
neighbours will answer with topology response messages directly to the command
node using the command nodes MAC address.
With the information received in the topology response messages, the command and
backup nodes are able to construct tables giving the complete topology of a cluster
(including the MAC and IP address of each node).
This procedure provides the steps to configure cluster management.
Procedure
Proceed as follows to configure cluster management:
1 Configure the role of the NE and cluster name with the following command:
configure cluster system name <Cluster::clusterName>

role <Cluster::ClusterRole>
Note Use this command for each NE that must be part of the cluster.
2 Configure the neighbour discovery on system level with the following command:
configure cluster neighbour

(no) discov-mode-off <Cluster::DiscoverySystemMode>
(no) interval <Cluster::DiscoveryInterval>
(no) hold-time <Cluster::DiscoveryHoldTime>
Note By default, the automatic neighbour discovery mode is enabled.
3 Configure the topology collection on system level with the following command:
configure cluster collection

(no) collect-sys-off
(no) hop-delay <Cluster::CollectionHopDelay>
(no) port-delay <Cluster::CollectionPortDelay>
(no) scope <Cluster::CollectScope>
(no) interval <Cluster::CollectionInterval>
(no) manual <Cluster::CollectionManualMode>
Note By default, the automatic topology-collection mode is enabled.
4 Configure the neighbour discovery and topology collection on port level with the
following command:
configure cluster port (port)

(no) discov-port-off
(no) collect-port-off
Note By default, the automatic neighbour-discovery and

topology-collection modes are enabled on port level.
5 View the status of the cluster with the folliwng commands:
show cluster counter
show cluster neighbour
show cluster device
show cluster connect
configure cluster system name cluster1 role command
configure cluster neighbour no discov-mode-off interval 60

hold-time 180
configure cluster collection interval 3000
configure cluster port 7 discov-port-off
show cluster counter
show cluster neighbour
show cluster device
show cluster connect
Purpose
This procedure provides the steps to configure the SSH functionality.
General
When configuring SSH, the following must be taken into consideration:
SSH can only be configured by the CLI security administrator.

SSH can use password or public key authentication:
In case of password authentication:
The operator can login via SSH without any further configuration (that is, other
than the configuration described in DLP 101). Once logged in, it is advised to
disable the non-secure channels (such as Telnet and TFTP). The operator can
now configure the client username/password for the SFTP client in the NE.
In case of public key authentication:
Before being able to login with a public key, the operator has to configure the
username/public key to the system, so the NE can authenticate the user. In order
to do this, the operator has to login via username/password, configure the
username/key combinations and change to key authentication.
Again, the operator must make sure that the non-secure channels are closed.
For SFTP:
When the NE acts as an SFTP server, both password and public key
authentication can be used.
When the NE acts as an SFTP client (to another external SFTP server), only
password authentication can be used.
Procedure
Proceed as follows to configure the SSH functionality:
1 Configure the SSH server profile (retries, timeout, authentication algorithm, and
encryption algorithm) with the following command:
configure system security ssh server-profile

(no) server-retries <SSH::ServerRetries>
(no) idle-timeout <SSH::ServerIdleTimeOut>
(no) dis-hmac-sha-1
(no) dis-hmac-sha-1-96
(no) dis-aes
(no) dis-des-3
(no) dis-blowfish
(no) dis-des-56
a If public key authentication is used, go to step 3
b If password authentication is used, go to step 4
3 Configure the SSH user and the public key, to be used while connecting, with the
following command:
configure system security ssh user (name)

key <SSH::SshClientPublicKey>
Note 1 The private/public key pair is generated by the operator by an

external key generator program on the EMS. The generated key is placed
in a file by the generator program. This file can be downloaded to the NE
in the SSH directory /pub/SSH/Download via TFTP. Based on the file
name and file extension (for example, isadmin.pk2), the NE stores the
public key automatically in its database, associated with an operator
name. Now the NE can use this key to authenticate the operator when he
logs in via CLI. A maximum of 10 users can be configured.
Note 2 Once the session is set up, it is advised to try the login first
before continuing with the next step.
Note 3 When the operator notices that the private/public key pair of
the NE has been compromised, the servers public key can be
regenerated with the following command:
configure system security ssh

key-regen <SSH::RegenerateKey>
4 Configure the access channels (for example, disable the non-secure channels) with
configure system security ssh access

(no) ftp <SSH::ChannelFTP>
(no) protocol <SwMngt::Protocol>
(no) cli <SSH::ChannelCLISSH>
(no) tl1 <SSH::ChannelTL1SSH>
Note The parameter ftp is obsolete and is replaced by the parameter

protocol.
5 Configure an SFTP user name and password for when the NE has to connect to an
external SFTP server with the following command:
configure system security ssh sftp-user (username)

password prompt | plain:<SSH::SftpPassword>
Note The SFTP user created with the command above, is unique in
the system. In case of a second attempt to create such an SFTP user, the
first one will be overwritten.
configure system security ssh server-profile server-retries 3

idle-timeout 1800 no dis-hmac-sha-1 no dis-hmac-sha-1-96
no dis-aes no dis-des-3 no dis-blowfish no dis-des-56
configure system security ssh user SSH01
configure system security ssh user SSH02

key AAAAB3NzaC1yc2EAAAABJQAAAIEAnDR5OYM3lhz3tYC3wGQhumJhrum9pyGJ
3Ic0WGW0nJ7SW5CkMm7WfDUXujqwY09I2vZ2s1fMtpPHr/yrSAQ29qnLvmnhAeMd
can1YoVMgp0TAEjWKdKonn9SlGH9oPe6FFRb+1eJoPNNH3CGpGk03mqROeM0KQWo
U/nRlcYFa9c=
configure system security ssh access cli telnet-ssh
configure system security ssh sftp-user JohnDoe password

plain:sshpsw01
Purpose
This procedure provides the steps to enable the management of EMS.
Procedure
Proceed as follows to enable the management of EMS:
1 Determine the task to perform and go to the appropriate step
a To enable the management of EMS in single IP address mode, go to step 2.
b To enable the management of EMS in dual IP address mode, go to step 5.
2 Configure the SNMP community name public with the following command:

3 Configure the SNMP community name NETMAN with the following command:

context shub
4 Go to step 8.
5 Configure the SNMP community name public with the following command:

6 Configure the SHub management VLAN filter IP address with the following
command:
configure system shub filter shub-manager (index)

src-ip-addr <Ip::V4Address>
where <Ip::V4Address> is the IP address of the EMS
7 Configure the SHub security SNMP community with the following command:
configure system security snmp shub community (index)

name <name>
privilege read-write
no ip-addr
Configuration example for single IP address mode

host-address 10.176.0.0/15

Configuration example for dual IP address mode

host-address 192.168.203.189/24
configure system shub filter shub-manager 1

src-ip-addr 10.176.8.8
configure system security snmp shub community 2 name PUBLIC

privilege read-only

DLP 172 Create a default operator
profile
Purpose
This command allows the superuser to specify a default operator profile.
This default profile is used when an operator is authenticated via a RADIUS server, but
the RADIUS server does not support Vendor Specific Attributes.
This operator profile determines most of the operator properties.
Procedure
Proceed as follows to create a default operator profile:
1 Create a default operator profile with the following command:
configure system security default-profile (name)

(no) password-timeout <Sec::PasswordTimeout>
(no) terminal-timeout <Sec::InactivityTimeout>
(no) slot-numbering <Sec::SlotDesc>
(no) description <Sec::ProfileDesc>
(no) aaa <Sec::Aaa>
(no) atm <Sec::Atm>
(no) alarm <Sec::Alarm>
(no) dhcp <Sec::Dhcp>
(no) equipment <Sec::Equipment>
(no) igmp <Sec::Igmp>
(no) ip <Sec::Ip>
(no) ppoe <Sec::Ppoe>
(no) qos <Sec::Qos>
(no) software-mngt <Sec::Sw>
(no) transport <Sec::Transport>
(no) vlan <Sec::Vlan>
(no) xdsl <Sec::Xdsl>
DLP 172 Create a default operator profile
(no) security <Sec::Security>
configure system security default-profile no prompt

password-timeout 10 terminal-timeout 30 description defaultprof
aaa read atm read alarm write no dhcp equipment write no igmp
ip write pppoe write qos write software-mngt write transport write
vlan write xdsl write security write
DLP 173 Switching a user from ADSL
to VDSL
Purpose
This procedure provides the steps to change the configuration of a user from an ADSL
service to a VDSL (1 or 2) service.
Procedure
Proceed as follows to switch a user from ADSL service to VDSL (1 or 2) service:
1 At the creation of the service and spectrum profiles, fill in the correct values both for
the ADSL and VDSL profiles; see DLP 129.
2 Enable the modification by changing the value of the parameter transfer-mode from
atm to ptm with the following command:

transfer-mode ptm admin-up
Note The existing interfaces on top of the xDSL line (such as pvc,
bridge port and so on) will be automatically removed.
3 Create the new forwarding model. Refer to DLP 115 to DLP 127 for the correct
procedure for the different modes.
DLP 173 Switching a user from ADSL to VDSL

transfer-mode ptm admin-up
DLP 174 Create an IPoA
cross-connect user
Purpose
This procedure provides the steps to create an IPoA cross-connect user.
Prerequisites
The following prerequisites must be fulfilled before an IPoA cross-connect user can be
created:

Procedure
Proceed as follows to create an IPoA cross-connect user:
1 Create a cross-connect VLAN on the NT with the following command:

mode cross-connect
2 Create a cross-connect VLAN on the SHub with the following command:

mode cross-connect

(no) ansi-t1413
(no) etsi-dts
(no) g992-1-a
(no) g992-1-b
(no) g992-2-a
(no) g992-3-a
(no) g992-3-b
(no) g992-3-l1
(no) g992-3-l2
(no) g992-3-am
(no) g992-5-a
(no) g992-5-b
(no) ansi-t1.424
(no) etsi-ts
(no) itu-g993-1
(no) ieee-802.3ah
(no) g992-5-am
(no) admin-up

xdsl-line:<Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::LtSlot>
/<Eqpt::Port>
admin-up

admin-up
aal5-encap-type llc-snap-routed
6 Create an IWL with the following command:
configure atm ip-cross-connect (interworking-port)

cpe <Ip::V4Address>
next-hop <Ip::V4Address>
configure bridge port (port) mac-learn-off
8 Assign a VLAN to the bridge port with the following command:
configure bridge port (port) vlan-id (index)
9 Set the PVID with the following command:
configure bridge port (port) pvid (vlan-id)
configure vlan id 2200 name ISP_C_VLAN mode cross-connect
configure vlan shub id 2200 name ISP_C_VLAN mode cross-connect

admin-up
configure interface port xdsl-line:1/1/5/7

user IPoA cross-connect

configure atm ip-cross-connect 1/1/5/7:8:35 next-hop

192.168.150.1 cpe 192.168.150.2
configure bridge port 1/1/5/7:8:35 mac-learn-off
Purpose
This document describes the procedure to configure the system management IP
parameters.
Prerequisites
Communities must be configured on the SHub. The following commands give an
example:
configure system security snmp shub community 1 name NETMAN privilege

read-write ip-addr 127.0.0.2
configure system security snmp shub community 2 name PUBLIC
Procedure
Proceed as follows to configure the system management IP parameters:
1 Configure the system to use a single IP address with the following command:

single-public-ip
2 The system can receive an IP address either statically by manual configuration or

dynamically via BOOTP. Configure the host IP address of the system with the
following command:
configure system management host-ip-address bootp |

Note 1 In case of manual configuration of the IP address:

If the system IP address is not configured (default 0.0.0.0), the users
session setup requests are refused.
Note 2 In case of dynamic configuration via BOOTP:

you can view the IP address that you received from the server with the
following command:

3 Configure the default route of the system with the following command:
configure system management default-route (default-route)
4 Configure the network port management (inband or outband) with the following
command:

(no) admin-status <Shub::AdminStatus>
(no) mc-flooding
where port-type can be:

user: port to a directly connected user
subtending: port to a subtended ISAM
network: port to the service provider (ISP)
unused: port is not in use
outband-mngt: port is used for outband-management
Select network for inband management or outband-mngt for outband management
Inband or outband management can be checked with the following commands (output of the
commands is an example):
show vlan global
----------------------------------------------------------------
vlan parameters
----------------------------------------------------------------
configured-vlans : 16 management : inband
max-rb-vlan : 128 max-layer2-term-vlan : 1280

===============================================================
================================================================
port table
================================================================
port admin-status oper-status speed type duplex
----------------------------------------------------------------
1 down down one-gb unused full
2 up up one-gb outband full
3 up down one-gb user full
4 up down one-gb subtending full
5 up down one-gb network full
6 up up hundred-mbps network full
7 up up hundred-mbps network half
----------------------------------------------------------------
5 Specify the set of ports which are statically allocated as egress ports for the SHub
management VLAN with the following command:
configure vlan shub id 4093 egress-port (port)
6 Specify the egress ports which should transmit packets for the SHub management
VLAN as untagged with the following command:
configure vlan shub id 4093 untag-port (network-port)
7 Configure the bridge port with the following command:
configure bridge shub port (network-port) pvid 4093
Configuration example for dynamic configuration via BOOTP (for

tagged network):
configure system id SystemID01 single-public-ip
show vlan global
Configuration example for static configuration via manual

configuration (for tagged network):
configure system id SystemID02 single-public-ip
configure system management

host-ip-address manual:10.177.0.112/17
show vlan global
DLP 176 Performance monitoring
commands
Purpose
This procedure provides the commands for performance monitoring on the NE.
Note 1 For more information on the command syntax and the

command parameters, refer to the CLI Commands and Messages.
Note 2 On the SHub, the available memory for counters is 32 kbit.
Procedure
The following steps can be used for performance monitoring:
1 Use the following commands to show the xDSL counters:
show xdsl counters near-end line current-interval (if-index)

detail
show xdsl counters far-end line current-interval (if-index)

detail
show xdsl counters near-end line current-1day (if-index) detail
show xdsl counters far-end line current-1day (if-index) detail
show xdsl counters near-end line previous-interval (if-index)

detail
show xdsl counters far-end line previous-interval (if-index)

detail
show xdsl counters near-end line previous-1day (if-index) detail
show xdsl counters far-end line previous-1day (if-index) detail
Note The previous-1day counters are not available until 96 15-min

intervals (that is, 24 hours) have passed.
2 Use the following commands to show the ATM counters:
show atm tc-current-int one-day (port)
show atm tc-current-int fifteen-min (port)
3 Use the following command to show the bridge port counters:
show interface port bridge-port (port) detail
4 Use the following commands to show the link aggregation counters:
show la aggregator-info (port)
show la aggregator-list (port)
show la network-port-info
5 Use the following command to show the MSTP counters:
show mstp bridge
show mstp instance
show mstp network-port
show mstp port-instance
6 Use the following command to show the SHub port statistics:
show bridge network-port (port)
7 Use the following commands to show the PPPoE statistics:
show pppoe statistics-pppoe-itf tx-pkt (port)
show pppoe statistics-pppoe-itf rx-pkt (port)
show pppoe statistics-pppoe-itf stats (port)
show pppoe ppp-statistics (port)
8 Use the following command to show the QoS statistics:
show qos statistics buffer-overflow prev-15min (equip-slot)
show qos statistics buffer-overflow current-15min (equip-slot)
show qos statistics buffer-overflow prev-1day (equip-slot)
show qos statistics buffer-overflow current-1day (equip-slot)
show qos statistics buffer-overflow total
show qos statistics queue prev-15min (index)
show qos statistics queue current-15min (index)
show qos statistics fan-out prev-15min (equip-slot)
show qos statistics fan-out current-15min (equip-slot)
show qos statistics fan-out prev-1day (equip-slot)
show qos statistics fan-out current-1day (equip-slot)
9 Use the following commands to show the IGMP statistics:
show igmp channel counter (port)
show igmp channel miscellaneous (port)
show igmp channel protocol (port)
show igmp module-mcast-src (slot)
show igmp module counter (slot-index)
show igmp shub igs-stats (vlan-id)
show igmp shub system-stats
show igmp shub mcast-stats (src)
show igmp shub bundle-stats (bundle-name)
show igmp shub bundle-stats (bundle-name)
10 Use the following command to show the IP forwarding statistics:
show ip vrf-statistics (vrf-id)
11 Use the following command to show the IP SHub ARP Statistics per VRF forwarding
statistics:
show ip shub arp (vrf-id)
12 Use the following commands to show the DHCP relay port counters and the
statistics of DHCP relay agent per VRF:
show dhcp-relay port (port-interface)
show dhcp-relay shub vrf-agent-stats (vrf)
13 Use the following commands to show the PPoX relay statistics:
show pppox-relay cross-connect statistics engine (vlan-id)
show pppox-relay cross-connect statistics client-port

(client-port)
show pppox-relay cross-connect monitor-statistics engine

(vlan-id)
show pppox-relay cross-connect monitor-statistics client-port

(client-port)
14 Use the following commands to show the RADIUS statistics:
show security radius auth-server auth-stats (name) vrf-index

<Aaa::VrfIndex>
show security radius acc-server acc-stats (name) vrf-index

<Aaa::VrfIndex>
15 Use the following command to show the EAPOL statistics:
show security pae eapol-stats (port)
16 Use the following command to show the statistics related to the SNMP protocol:
show transport snmp protocol-stats
17 Use the following command to show the MAU statistics:
show transport ether-ifmau (if-index) index <Transport::Index>
18 Use the following command to show the SHub L2 information:
show transport shub mac (index-num)
19 Use the following commands to show the IMA information:
show ima group state (if-index)
show ima group counters near-end current-interval (if-index)
show ima group counters near-end previous-interval (if-index)

interval-no <Ima::GroupIntervalNumber>
show ima group counters far-end current-interval (if-index)
show ima group counters far-end previous-interval (if-index)

interval-no <Ima::GroupFarEndIntervalNumber>
show ima link state (if-index)
show ima link counters near-end current-interval (if-index)
show ima link counters near-end previous-interval (if-index)

interval-no <Ima::LinkIntervalNumber>
show ima link counters far-end current-interval (if-index)
show ima link counters far-end previous-interval (if-index)
interval-no <Ima::LinkFarEndIntervalNumber>
20 Use the following commands to show the SHDSL information:
show shdsl inventory (if-index) unit-id <Shdsl::UnitId>
show shdsl span-status (if-index)
show shdsl unit-status (if-index) unit-id <Shdsl::UnitId>
show shdsl segment-status (if-index) unit-id <Shdsl::UnitId>

side <Shdsl::SegmentSide>
wire-pair <Shdsl::SegmentTerminationWirePair>
show shdsl segment-counters current-interval (if-index)

unit-id <Shdsl::UnitId>
show shdsl segment-counters current-1day (if-index)

show shdsl segment-counters previous-interval (if-index)

int-no <Shdsl::IntervalNumber>
show shdsl segment-counters previous-1day (if-index)

int-no <Shdsl::Interval1DayNumber>
show shdsl span-counters current-15min (if-index)
show shdsl span-counters current-1day (if-index)
show shdsl span-counters previous-15min (if-index)

interval-number <Shdsl::PM15MinIntervalNumber>
show shdsl span-counters previous-1day (if-index)

interval-number <Shdsl::PM1DayIntervalNumber>
21 Use the following command to show the statistics related to CPE management:
show cpe-management snmpproxy-statistics (address)
show cpe-management ipproxy-statistics (dslport)
22 Use the following command to show the statistics related to Ethernet:
show ethernet counters near-end line current-interval (if-index)
show ethernet counters near-end line current-1day (if-index)
show ethernet counters near-end line previous-interval (if-index)
show ethernet counters near-end line previous-1day (if-index)
show ethernet eth-int (if-index)
23 Use the following command to show the statistics related to VLANs:
show vlan port-curr-15min-stats (port)
show vlan port-curr-day-stats (port)
show vlan port-15min-stats (port)

interval-number <Vlan::SignedInteger>
show vlan port-prev-day-stats (port)

show vlan current-15min-stats (vlanid)

port <Itf::AtmInterfaceVpiVci> ]
show vlan current-day-stats (vlanid)

port <Itf::AtmInterfaceVpiVci>
show vlan previous-15min-stats (vlanid)

port <Itf::AtmInterfaceVpiVci>
show vlan vlan-day-stats (vlanid) port <Itf::AtmInterfaceVpiVci>

show xdsl counters near-end line current-interval
show xdsl counters far-end line current-interval
show xdsl counters near-end line current-1day
show xdsl counters far-end line current-1day
show xdsl counters near-end line previous-interval
show xdsl counters far-end line previous-interval
show xdsl counters near-end line previous-1day
show xdsl counters far-end line previous-1day
show atm tc-current-int one-day
show atm tc-current-int fifteen-min
show interface port bridge-port:1/1/4/1
show la aggregator-info
show la aggregate-list
show la network-port-info
show rstp port-info
show bridge network-port
show pppoe statistics-pppoe-itf tx-pkt
show pppoe statistics-pppoe-itf rx-pkt
show pppoe statistics-pppoe-itf stats
show pppoe ppp-statistics
show qos statistics buffer-overflow total 1/1/4
show igmp channel counter
show ip vrf-statistics
show ip shub arp
show dhcp-relay port
show dhcp-relay shub vrf-agent-stats
show pppox-relay cross-connect statistics engine
show pppox-relay cross-connect statistics client-port
show pppox-relay cross-connect monitor-statistics engine
show pppox-relay cross-connect monitor-statistics client-port
show security radius auth-server auth-stats
show security radius acc-server acc-stats
show security pae eapol-stats
show transport snmp protocol-stats
show transport ether-ifmau
show transport shub mac
show ima group state
show ima group counters near-end current-interval
show ima group counters near-end previous-interval
show ima group counters far-end current-interval
show ima group counters far-end previous-interval
show ima link state
show ima link counters near-end current-interval
show ima link counters near-end previous-interval
show ima link counters far-end current-interval
show ima link counters far-end previous-interval
show shdsl inventory
show shdsl span-status
show shdsl unit-status
show shdsl segment-status
show shdsl segment-counters current-15min
show shdsl segment-counters current-1day
show shdsl segment-counters previous-15min
show shdsl segment-counters previous-1day
show shdsl span-counters current-15min
show shdsl span-counters current-1day
show shdsl span-counters previous-15min
show shdsl span-counters previous-1day
show cpe-management ipproxy-statistics
show vlan port-curr-15min-stats 1/1/5
show vlan port-curr-day-stats 1/1/5
show vlan port-15min-stats 1/1/5 interval-number 2
show vlan port-prev-day-stats 1/1/5 interval-number 2
show vlan current-15min-stats 200 port 1/1/5:8:35]
show vlan current-day-stats 200 port 1/1/5:8:35
show vlan previous-15min-stats 200 port 1/1/5:8:35

interval-number 2
show vlan vlan-day-stats (vlanid) 200 port 1/1/5:8:35

interval-number 2
DLP 177 Configure SFP downlink
ports
Purpose
This DLP provides the steps to configure rack, shelf, and slot IDs for SFP downlink ports
on a GENC-E or GENC-F card installed in a 7330 ISAM FTTN ARAM-D host shelf in
expansion configurations.
General
Downlink SFP ports on a GENC-E or GENC-F card installed in a host shelf are
configurable using CLI. You can set the rack, shelf, and slot ID for each downlink port.
For the 7330 ISAM FTTN ES, the SFP port settings must match the shelf jumper settings
of the connected ES and the slot number must match the number of the LT slot in which
the connected remote LT unit is installed. The 7330 ISAM FTTN SEM derives its rack and
shelf IDs from the SFP port.
Figure DLP 177-1 shows the downlink port assignments on the faceplate of the GENC-E
card. The port assignments for the GENC-F card are identical.
Figure DLP 177-1: GENC-E card faceplate port assignments

Configuration up or down
7
6
Rx
Tx
5
11
13
15
17
ACU
11
13
15
17
5
7
9
10
12
14
16
4
Port
Rx
Tx
4
6
8
10
12
14
16
Up links Down links LEDs

5 9 11 13 15 17
4 8 10 12 14 16
Note Configuration fails if SFP ports 6 and 7 are configured as

uplinks
Each SFP port must have a unique rack, shelf, and slot ID. The host shelf is always
assigned to rack 1, shelf 1 in an expansion configuration. As such, the rack, shelf, and
slot combination used for SFP ports cannot be on the host shelf; for example, do not
assign rack 1, shelf 1, slot 1 to an SFP port.
The following conditions apply specifically to the SEM:
you are required to configure a rack, shelf, and slot ID for for each SFP port to which
a SEM is connected
the slot number is slot 4 (using legacy based numbering) or 1 (using position-based
or type-based numbering)
up to four shelves are supported in a rack
The following conditions apply specifically to the ES:
you are required to configure the rack, shelf, and slot ID for each SFP port to which
an ES is connected
if the SFP port is preplanned using CLI, you must set the shelf jumpers to match and
connect the corresponding remote LT unit
the slot number is the LT slot on the ES that contains the remote LT unit connected
to the downlink port
up to four shelves are supported in a rack
Warning Do not swap optical expansion link cables between

downlink expansion ports on the GENC-E or GENC-F card, or between
expansion ports on the EDSE-A card, after the remote expansion unit is
configured. Service disruptions will result and an alarm is raised.
If the rack and shelf assignment for a downlink port is already configured using CLI and
you connect a remote LT unit from an ES that has a different rack and shelf jumper
setting, an alarm is raised and the remote LT unit does not come in to service. If you
connect a remote LT unit from an ES to a downlink port after a SEM unit was previously
connected and commissioned, an alarm is raised and the remote LT unit does not come
in to service.
Do not change shelf and rack ID assignments using CLI after remote expansion units are
connected and operational. Service disruptions will result and an alarm is raised. Service
and port configurations are mapped to the optical expansion link. All affected port and
service configurations will require reconfiguration.
See 7302 ISAM Product Information or 7330 ISAM FTTN Product Information for more
information about expansion configurations and configurable SFP ports.
See TNG 106 for more information about rack and shelf assignments for remote
expansion units.
Prerequisite
The subrack associated with the remote LT needs to be planned first, either the operator
can explicitly plan the subrack or, for ARAM-D, it can be auto-planned by the system upon
detection.
Procedure
Proceed as follows to configure the rack, shelf, and rack IDs for an SFP port on a
GENC-E or GENC-F card.
1 Configure the traffic direction of the two configurable external-links on the host
expansion card with the following command:
configure equipment external-link-host (SFP index 6 or 7)

(no) direction <Equipm::ExternalLinkConfigType>
2 Configure the association between a host shelf SFP and a remote LT with the
following command:

(no) remote <Equipm::ExpansionSlotIndex>
3 View direction of the configurable ports:
info configure equipment external-link-host (SFP index 6 or 7)
4 View actual rack, shelf, and slot settings of the connected remote LT unit:
show equipment external-link-host (index 6-17) detail
configure equipment external-link-host 6 direction remote-lt
info configure equipment external-link-host
show equipment external-link-host detail
DLP 178 Configure the default
security domain
Purpose
This procedure provides the steps to configure a default security domain to be used in
case PPP clients do not provide a domain name.
Prerequisites
The following prerequisites must be fulfilled before a default security domain can be
created:
A RADIUS server must have been configured; see DLP 144.
Procedure
Proceed as follows to configure the default security domain:

(no) primary-dns <Aaa::InetAddress>
(no) second-dns <Aaa::InetAddress>
(no) primary-nbns <Aaa::InetAddress>
(no) second-nbns <Aaa::InetAddress>
(no) qos-policy <Aaa::QosProfileName>
authenticator <Aaa::Authenticator>
DLP 178 Configure the default security domain
2 Configure the connection profile parameters with the following command:
configure system security conn-profile (name)

(no) reject-no-domain
(no) reject-inv-domain
domain-name <Aaa::DomainName>
3 Configure the security connection policy with the following command:
configure system security conn-policy conn-profile-name

<AsamProfileName>
In the following example, a default security domain with name

unspecified is created. The connection profile is named no-domain.
configure system security domain unspecified authenticator

radius:RADPol23 vrf-index 1
configure system security conn-profile no-domain version 1

no reject-no-domain domain-name unspecified
configure system security conn-policy conn-profile-name no-domain
Purpose
Use this DLP to configure system logging (SYSLOG).
General
There are three main tasks you can perform using CLI when configuring system logging:
enable and disable logging for all system logs

create and configure up to 64 system logs
monitor system logs
The NE supports up to 64 system log files and up to 64 remote system log servers. You
can enable or disable logging for all system logs and view system-wide information for
system logs.
You can view system-wide information for local system logs, such as the maximum
message size allowed and statistics about how much combined disk space the local
system logs utilize. System-wide information for local system log files are displayed using
the show CLI command and can be displayed in four different formats.
You can create and configure up to 64 system logs. The combined maximum size of all
locally saved system log files is 2 Mbytes. For each system log file, you can set the
method of cycling messages when the system log file is full. Cycling of system log
messages is performed in one of two ways: wrap new entries to overwrite the oldest
entries, or discard all new entries.
You can configure the following parameters for each system log file:
system log filename (local only), entered using up to eight alphanumeric characters
followed by a dot separator and a three-alphanumeric character extension; for
example, Alrmhigh.txt
destination server type:
all active TL1 and CLI terminals (all-users)
all active CLI terminals (all-CLI)
all active TL1 terminals (all-TL1)
single active TL1 terminal (tl1-user)
local file (file:name:size)
remote host (udp:port:serv-ip-addr)
destination server address, entered as an alphanumeric host name or in standard dot
format (maximum value 255.255.255.255); where 0.0.0.0 is entered for local files
action taken when the system log file is full (wrap or discard)
activate and deactivate logging
delete a system log file
view the configuration of a system log file
By default, all message types are logged to the system log files. In addition, alarms
generated in the system and the errors encountered are logged to the system log files.
You can configure filters to define which messages get logged to which system log file
based on message type.
Table DLP 179-1 lists the possible message type and log severity parameters. You can
select which messages are sent to specific system log files using filters and can group
multiple message types.
Table DLP 179-1: Message type and log severity parameters
Item Description Parameter
Message type Authentication actions authentication

CLI configuration changes cli-config-chgs
TL1 configuration changes tl1-config-chgs
CLI messages cli-msgs
TL1 messages tl1-msgs
Protocol tracing messages tracing1
tracing2
tracing3
Video CDR messages video-cdr
All message types all
(1 of 2)
Item Description Parameter
Log severity Emergency EM
Alert AL
Critical CR
Error ER
Warning WN
Notice NO
Information IN
Debug DBG
(2 of 2)
When activating or deactivating system logs, you must specify the following information:
index number of the system log file (1 to 64)

message type, or types if grouped, being sent to that system log file
severity level set for that particular system log file
The index number is an integer from 1 to 64. Use the information command to view the
settings of a system log file before entering the message type and log severity of the
system log file to activate or deactivate.
To monitor remote system logs dynamically, set the destination server type to all active
CLI or all active TL1 terminals for a particular system log. This sends all messages to the
active terminals that have a management session with the NE. When you are done
monitoring, deactivate system logging for that server. You can view the static contents of
a system log file that is saved to a remote server location using any text-based editor.
You can also configure system and security logging using TL1 or SNMP. See the
7302 ISAM | 7330 ISAM FTTN TL1 Commands and Messages or the latest MIB for more
information.
Procedure
Proceed as follows to configure system logs:
1 View system-wide information for local system logs with the following command:
show system syslog (type)
Where:
Type is how to display the information, which can be either detail, hierarchical, flat, or xml.
2 Create the system log and set the system log filename and configure the destination
server type with the following command:
configure system syslog destination (name)

type <Sys::ServerType>
no disable
3 Delete a system log server with the following command:
configure system syslog destination (name)

disable
4 Configure which messages must be sent to a given system log destination and
assign the appropriate system log parameters to them with the following command:
configure system syslog route (name) msg-type <Sys::MessageType>

facility <Sys::LogFacility>
(no) emergency
(no) alert
(no) critical
(no) error
(no) warning
(no) notice
(no) information
(no) debug
5 Configure the system transaction parameters with the following command:
configure system transaction

(no) time-out-value <Trans::TimeoutValue>
(no) log-full-action <Trans::logFullaction>
6 Retrieve the configuration of a specific system log with the following command:
info configure system syslog destination (name)

type <Sys::ServerType> detail
7 Retrieve the configuration for all configured system logs with the following
command:
info configure system syslog destination detail
8 Force the system log file to rotate with this command:
admin system syslog destination (name) rotate
show system syslog
configure system syslog destination server1 type

file:filename.c:20000 no disable
configure system syslog route server1 msg-type authentication

facility user no debug
configure system transaction log-full-action halt
info configure system syslog destination server1 detail
admin system syslog destination server1 rotate
DLP 180 Configure static MAC
addresses
Purpose
The operator can specify entries in the layer 2 filtering database for a specific VLAN and
unicast MAC address. This information is used by the bridge to determine how to
propagate a received frame.
This document describes the commands to configure static MAC addresses in the NE.
Prerequisite
The following prerequisite must be fulfilled before static MAC addresses can be
configured:
A VLAN must exist; see DLP 117, DLP 118, DLP 119 or DLP 120.
Procedure
Proceed as follows to configure static MAC addresses:
1 Configure a static MAC address on the LT with the following command:
configure vlan unicast-mac (unicast-mac)

vlan-id <Vlan::UVlanIndex>
| <Vlan::SVlanIndex>:<Vlan::CVlanIndex>
forward-port <Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::LtSlot>
/<Eqpt::Port>:<Atm::DefaultVpi>:<Atm::DefaultVci>
DLP 180 Configure static MAC addresses
2 Configure a static MAC address on the SHub with the following command:
configure vlan shub unicast-mac (unicast-mac)

vlan-id <Vlan::VlanIndex>
forward-port lt:<Eqpt::RackId>/<Eqpt::ShelfId>/<Eqpt::SlotId>
| network:<Shub::NetworkPort>
| nt
configure vlan unicast-mac 00:00:00:00:00:05 vlan-id 200

forward-port 1/1/5/12:8:35
configure vlan shub unicast-mac 00:00:00:00:00:01 vlan-id 200

forward-port network:7
DLP 181 Configure operator
authentication via RADIUS
Purpose
This procedure provides the steps to configure the authentication for an operator via
RADIUS.
Note This procedure can be used for the default superuser isadmin.
Procedure
Proceed as follows to configure operator authentication via RADIUS:
1 Configure the RADIUS authentication server with the following command:
configure system security radius auth-server (name)

vrf-index 0
secret <Password>
(no) admin-down
where vrf-index is the index of the management VRF, that is 0.
2 Configure the RADIUS policy with the following command:
configure system security radius policy (name)

nas-id <Printable-0-64>
nas-ip-address <Ip::V4Address>
(no) keep-domain-name
disable-accnt-msg
(no) acc-interval <Aaa::AccInt>
disable-eap
3 Configure the RADIUS server set with the following command:
configure system security radius policy (name) servers (index)

auth-server none | name:<Aaa::RadAuthServerName>
vrf-index-auth <Aaa::VrfIndex>
(no) acc-server none | name: <Aaa::RadAccServerName>
(no) vrf-index-acc <Aaa::VrfIndex>
priority <Aaa::Priority>
where vrf-index-auth is the index of the management VRF, that is 0.
4 Enable the operator policy with the following command:

(no) relay
(no) auth-super-user <Aaa::SuperUserAuth>
oper-policy-name <Aaa::OperatorRadPolicyName>
5 Enable the RADIUS for the superuser with the following command:

(no) relay
auth-super-user
configure system security radius auth-server RADAuthServ1

timeout-limit 5 no admin-down dead-interval 1
configure system security radius policy oper_e14 nas-id E14

nas-ip-address 10.177.0.112 disable-accnt-msg disable-eap
configure system security radius policy oper_e14 servers 1

auth-server name:RADAuthServ1 vrf-index-auth 0 no acc-server
priority 1
configure system security radius operator-policy name:oper_e14
Purpose
This procedure provides the steps for configuring SHDSL links.
Note 1 Refer to the System Description for a more detailed

description of SHDSL.
Note 2 For a more detailed description of the different parameters for

SHDSL span, unit and segment configuration, refer to TNG 108.
Procedure
Proceed as follows:
1 Manage the SHDSL span profile with the following command:
configure shdsl span (if-index)

(no) active
(admin-up | admin-down)
(no) repeaters <Shdsl::SpanConfNumRepeaters>
(no) op-mode <Shdsl::SpanOperationalMode>
(no) spectral-profile <Shdsl::SpanSpectralProfile>
(no) wire-mode <Shdsl::SpanWireMode>
(no) mgmt-by-stu-r
(no) regi-set <Shdsl::SpanRegionalSetting>
(no) min-line-rate <Shdsl::BitRate>
(no) max-line-rate <Shdsl::BitRate>
(no) margin-down-worst <Shdsl::NoiseMarginWC>
(no) margin-down-curr <Shdsl::NoiseMarginCC>
(no) margin-up-worst <Shdsl::NoiseMarginWC>
(no) margin-up-curr <Shdsl::NoiseMarginCC>
(no) probe <Shdsl::SpanLineProbeEnable>
(no) tc-pam-sele <Shdsl::SpanTCPAMSelection>
Note The parameters min-line-rate and max-line-rate must be set to

the same value.
2 Manage the SHDSL unit profile in one SHDSL span with the following command:
configure shdsl unit (if-index) unit-id <Shdsl::UnitId>

(no) loop-attenuation <Shdsl::UnitLoopAttenThreshold>
(no) snr-margin <Shdsl::UnitSnrMarginThreshold>
(no) loopback-timeout <Shdsl::UnitLoopbackTimeout>
3 Configure the SHDSL segment points on either side of an SHDSL unit with the
following command:
configure shdsl segment (if-index) unit-id <Shdsl::UnitId>

(no) loopback <Shdsl::SegmentTermLoopbackConf>
pbo-mode <Shdsl::SegmentTermPowerBackoff>
4 Manage an SHDSL segment points with the following command:
admin shdsl-seg (if-index) unit-id <Shdsl::UnitId>

(no) soft-restart
5 Activate the SHDSL line with one of the following commands:
configure shdsl span (if-index) admin-up
The first configuration example is for 4-wire Multi-pair bonding,

the second configuration example is for IMA and the third
configuration example is for EFM (4-wire EFM, no bonding).
configure shdsl span 1/1/9/1 active wire-mode four-wire

min-line-rate 2048 max-line-rate 5120 margin-down-worst 5
margin-up-worst 5 admin-up

margin-up-worst 5 admin-up
configure shdsl unit 1/1/9/1 unit-id stu-r loopback-timeout 10
configure shdsl segment 1/1/9/1 unit-id stu-c side customer

loopback normal

aal5-encap-type llc-snap

aal5-encap-type llc-snap
configure shdsl span 1/1/9/16 min-line-rate 2304

max-line-rate 2304 margin-down-worst 5 margin-up-worst 5
op-mode ima active admin-up




margin-up-worst 5 op-mode efm admin-up
DLP 183 Configure IMA on SHDSL
links
Purpose
This procedure provides the steps for configuring Inverse Multiplexing for ATM (IMA).
Note Refer to the System Description for a more detailed description

of the IMA functionality.
Prerequisite
The following prerequisite must be fulfilled before IMA can be configured on SHDSL links:
the SHDSL links must have been created (and have operational mode ima); see
DLP 182.
Procedure
Proceed as follows:
1 Manage the IMA group profile with the following command:
configure ima group (if-index)

(no) activate
(admin-up | admin-down)
(no) min-tx-links <Ima::GroupMinNumTxLinks>
(no) min-rx-links <Ima::GroupMinNumRxLinks>
near-end-ima-id <Ima::GroupTxImaId>
2 Manage the IMA link profile with the following command:
configure ima link (link-if-index) grp-index <Itf::ImaLine>
DLP 183 Configure IMA on SHDSL links
3 Activate the IMA line interface with one of the following commands:
configure ima group (if-index) admin-up

ima-line:<Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::LtSlot>/<Eqpt::Port>
admin-up
configure ima group 1/1/9/16 active admin-up min-tx-links 2

min-rx-links 2
configure ima link 1/1/9/16 grp-index 1/1/9/16

vc-mux-bridged-8023 no admin-down
Purpose
This DLP provides the steps to convert the NE from single to dual IP address mode, or
from dual to single IP address mode.
General
The EMS (5526 AMS or 5523 AWS) supports the creation of an NE using a single IP
address for the NE only or dual IP addresses for the NE and SHub. After you have
created the NE and configured it to use a single or dual IP address, you can convert the
node from single to dual IP address mode, or from dual to single IP address mode, using
the CLI commands in this DLP. SNMPv3 is only supported in single IP address mode.
You cannot convert a system configured with SNMPv3 to dual IP mode.
Before you perform the steps in this DLP, you must have already set up the NE for EMS
(5526 AMS or 5523 AWS) management and have configured the system for single or
dual IP address mode.
Note You can lose communication with the NE when you change the
IP address. To ensure that the connection is maintained, perform these
procedures from the craft port.
Note For a redundant EMS (5526 AMS or 5523 AWS) server

configuration, you must perform the IP address configuration commands
(for example, when you configure the SNMP community string or SHub
filter) for the IP address of each of the active and redundant server.
Prerequisites
The NE must be administered by the EMS (5526 AMS or 5523 AWS).
Procedure
Proceed as follows to convert the IP address mode on the NE:
1 Establish a CLI session; see DLP 100.
2 Determine the task to perform and go to the appropriate step.
a To convert the NE from dual to single IP address mode, go to step 3.
b To convert the NE from single to dual IP address mode, go to step 5.
3 Configure a single IP address on the system with the following command:
configure system single-public-ip
Note The IP interface previously configured on the management

VLAN will automatically be removed.
4 Go to step 10.
5 Remove the single IP address mode configuration with the following command:
configure system no single-public-ip
6 Configure the SHub IP address as follows:
i Set the adminstrative status of the OAM VLAN to down with the following
command:
configure interface shub ip 4093 admin-status down
ii Configure the SHub IP address with the following command:

iii Set the adminstrative status of the OAM VLAN to up with the following
command:
configure interface shub ip 4093 admin-status up

vlan-id 4093
8 Configure the SHub filter (access list) with the following command:
configure system shub filter shub-manager <index> src-ip-addr

<Ip::V4Address>
where <Ip::V4Address> is the IP address of the EMS
9 Configure the SNMP SHub community string with the following command:
configure system security snmp shub community <index> name <name>

privilege read-write no ip-addr
Note The name of the SNMP community can be 1 to 32 characters.
The following example shows the procedure to convert from dual to

single IP address:
The following example shows the procedure to convert from single

to dual IP address:
configure system no single-public-ip

next-hop 10.177.127.254 vlan-id 4093
configure system shub filter shub-manager 1

src-ip-addr 10.176.8.8

privilege read-write no ip-addr
Purpose
Currently, Network Access Control Protocol (NACP) is only supported on top of TCP/IP.
Once the IP address of a Broadband Network Gateway (BNG) is configured, and

depending on the setting of the GSMP Retry Timer, the NE will start the GSMP Adjacency
Protocol to setup a NACP session with that BNG.
Note A BNG can be:
a Service Router/Switch (for example, Alcatel 7450 ESS or Alcatel

7750 SR)
a BRAS
The NE does not reply to requests for a TCP connection from an unknown BNG.
This means:
If the TCP Retry Timer is zero, the NE will not start the TCP connection.
If the TCP Retry Timer is not zero, the NE will start the setup of a TCP connection to
the BNG whose IP address has been configured.
If the GSMP Retry Timer is zero, the NE will not start the GSMP Adjacency Protocol,
but instead be prepared to handle GSMP Adjacency Protocol messages from that
BNG.
If the GSMP Retry Timer is not zero, the NE starts the GSMP Adjacency Protocol in
addition to being prepared to handle GSMP Adjacency Protocol messages from that
BNG.
Procedure
Proceed as follows to configure an NACP session:
1 Configure the NACP session parameters for a given session ID with the following
command:
configure l2cp session (index)

bras-ip-address <L2cp::InetAddress>
(no) gsmp-version <L2cp::Version>
(no) gsmp-sub-version <L2cp::SubVersion>
(no) encap-type <L2cp::EncapType>
(no) topo-discovery <L2cp::AccessTopologyDiscovery>
(no) layer2-oam <L2cp::Layer2OAM>
(no) alive-timer <L2cp::AliveTimer>
(no) port-reprt-shaper <L2cp::ReportShaper>
(no) aggr-reprt-shaper <L2cp::AggrReportShaper>
(no) tcp-retry-time <L2cp::TcpRetryTimer>
(no) gsmp-retry-time <L2cp::GsmpRetryTimer>
(no) dslam-name <L2cp::DslamName>
(no) window-size <L2cp::WindowSize>
(no) tcp-port <L2cp::InetPortNumber>
(no) vrf-id <L2cp::VrfIndex>
2 Stop the NACP session with the following command:
configure l2cp no session (index)
configure l2cp session 1 bras-ip-address 192.168.200.100

gsmp-retry-time 0
configure l2cp no session 1
DLP 186 Configure DHCP MAC
concentration in forwarder
mode
Purpose
The DHCP MAC concentration functionality is only provided in forwarder mode. When the
DHCP MAC concentration is enabled, Option 82 must be configured.
When the MAC concentration configuration is changed (enabled or disabled), this is

considered as a behavior of operator, so it is up to the operator to guarantee that the
corresponding already set-up sessions are released by the DHCP server and to
acknowledge the DHCP clients
Activating the MAC address concentration feature of DHCP has the following impacts:
Enlarged IP-aware Bridge scalability: allows a large number of subscribers in the

same shared VLAN
Requires the DHCP server to be able to allocate multiple IP addresses to the same
chaddr (that is, LT MAC addresses). Consequently, the IP address assignment must
be based on other DHCP fields than the chaddr, that is:
Option 82 (Relay Agent Info, that is Line ID): this option allows to allocate one IP
address per PVC (ATM) or line (EFM)
Option 60 (Class ID): this option is used together with option 82 and allows to
allocate one IP address per {service, PVC} or {service, line} couple
Option 61 (Client ID): if supported by the subscriber's device, this option allows
to have a unique identifier of the device (typically filled with the MAC address)
and consequently, the same full flexibility as the chaddr regarding IP address
assignment
DHCP MAC concentration is configured per VRF:
Enable Option-82 insertion

Enable DHCP MAC concentration
DLP 186 Configure DHCP MAC concentration in forwarder mode
Procedure
Proceed as follows to configure the DHCP MAC concentration:
1 Add DHCP option to the forwarder VRF on the LT with the following command:

option-82
circuit-id <Dhcp::CircuitId>
remote-id <Dhcp::RemoteId>
2 Enable DHCP MAC concentration with the following command:

client-hw-address copysourcemac
configure dhcp-relay agent 16 bcast-vlan l2-vlan:101 option-82

circuit-id physical-id remote-id customer-id
configure dhcp-relay agent 16 client-hw-address copysourcemac
DLP 187 Configure global VLAN
parameters
Purpose
This procedure provides the steps to specify VLAN parameters which are globally
applicable to VLANs:
broadcast-frames:
This parameter determines whether broadcast frames must be switched for each
VLAN.
This parameter applies to iBridge VLANs.
priority-policy:
This parameter specifies how to deal with ethernet priority of the upstream frames.
This parameter applies to iBridge VLANs, cross-connect VLANs and QoS-aware
VLANs.
Procedure
Proceed as follows to configure the general VLAN parameters:
1 Configure the general VLAN parameters with the following command:
configure vlan
priority-policy vlan-specific | port-default
(no) pvid-usage c-vlan-translation | standard
configure vlan broadcast-frames

priority-policy port-default
pvid-usage standard
DLP 187 Configure global VLAN parameters
DLP 188 Configure custom PSD
points
Purpose
Many operators tend to have locations where copper binders have pairs coming from a
CO and pairs coming from a remote cabinet. When the remote cabinet locations get
broadband enabled this often creates spectral compatibility issues in the network: the
strong ADSL signal coming from the remote cabinet creates strong cross talk to the weak
signal coming from the CO. This results in a very unstable line for the one connected to
the CO.
To resolve this, a custom Power Spectral Density (PSD) shape is configurable via the
xDSL spectrum profile. A custom defined PSD allows:
for a better spectrum usage (and better performance as a consequence)

to protect xDSL coming from the CO
Customized PSD values can be configured for:
ADSL2+
VDSL
VDSL2
Up to 20 breakpoints can be configured. When configuring a custom PSD shape, a

minimum of 2 PSD points must be configured.
Customized PSD points can be configured while creating a new spectrum profile (see
DLP 129) or by modifying an existing spectrum profile (see DLP 163).
The commands below help the operator to enter the custom PSD shape in a user-friendly
way. Instead of entering octets, the operator can enter numbers corresponding to
frequency and PSD.
See the CLI Commands and Messages document and also TNG 107 for a full description
of all related parameters.
Procedure
Proceed as follows to configure custom PSD points:
1 For the configuration of:
custom PSD points for ADSL2+, go to step 2

custom downstream PSD points for VDSL, go to step 3
custom upstream PSD points for VDSL, go to step 4
custom downstream PSD points for VDSL2, go to step 5
custom upstream Rx PSD points for VDSL2, go to step 6
custom upstream PSD points for VDSL2, go to step 7
2 Configure the custom PSD points for ADSL2+ as follows:
i Configure a xDSL spectrum profile with the following command:

ii Configure the PSD for ADSL2+ as custom PSD with the following command:

psd-shape-down custom-psd-down
iii Configure the PSD values with the following command:

cust-psd-pt-down (psdpt)
frequency <Xdsl::CustFrqAdsl2>
psd <Xdsl::CustomAdsl2Psd>
iv Go to step 8
3 Configure the custom downstream PSD points for VDSL as follows:

ii Configure the downstream PSD for VDSL as custom PSD with the following
command:
configure xdsl spectrum-profile (index) vdsl psd-shape-down

custom-psd-down
iii Configure the downstream PSD scale and type with the following command:

cust-psd-sc-down linear | logarithmic
cust-psd-ty-down mask | template
iv Configure the downstream PSD values with the following command:

frequency <Xdsl::CustFreq>
psd <Xdsl::CustPsd>
v Go to step 8
4 Configure the custom upstream PSD points for VDSL as follows:

ii Configure the upstream PSD for VDSL as custom PSD with the following
command:
configure xdsl spectrum-profile (index) vdsl rx-psd-shape-up

custom-rx-psd-up
iii Configure the upstream PSD scale and type with the following command:

cust-rx-psd-sc-up linear | logarithmic
cust-rx-psd-ty-up mask | template
iv Configure the upstream PSD values with the following command:

cust-rx-psd-pt-up (psdpt)
psd <Xdsl::CustPsd>
v Go to step 8
5 Configure the custom downstream PSD points for VDSL2 as follows:

ii Configure the downstream PSD for VDSL2 as custom PSD with the following
command:
configure xdsl spectrum-profile (index) vdsl2 psd-shape-down

custom-psd-down
iii Configure the downstream PSD scale and type with the following command:

cust-psd-sc-down linear | logarithmic
cust-psd-ty-down mask | template
iv Configure the downstream PSD values with the following command:

psd <Xdsl::CustPsd>
v Go to step 8
6 Configure the upstream Rx PSD points for VDSL2 as follows:

ii Configure the upstream Rx PSD for VDSL2 as custom PSD with the following
command:
configure xdsl spectrum-profile (index) vdsl2 rx-psd-shape-up

custom-rx-psd-up
iii Configure the upstream Rx PSD scale and type with the following command:

cust-rx-psd-sc-up linear | logarithmic
cust-rx-psd-ty-up mask | template
iv Configure the upstream Rx PSD values with the following command:

cust-rx-psd-pt-up (psdpt)
psd <Xdsl::CustPsd>
v Go to step 8
7 Configure the upstream PSD points for VDSL2 as follows:

ii Configure the upstream PSD for VDSL2 as custom PSD with the following
command:
configure xdsl spectrum-profile (index) vdsl2 psd-shape-up

custom-psd-up
iii Configure the upstream PSD scale and type with the following command:

cust-psd-sc-up linear | logarithmic
cust-psd-ty-up mask | template
iv Configure the upstream PSD values with the following command:

cust-psd-pt-up (psdpt)
psd <Xdsl::CustPsd>
8 Activate the xDSL spectrum profile with the following command:

active
Configuration example for ADSL2+:
configure xdsl spectrum-profile 11 name adsl2-plus version 1
configure xdsl spectrum-profile 11 adsl2-plus psd-shape-down

custom-psd-down:12:34:56:78:90:ab:cd
configure xdsl spectrum-profile 11 adsl2-plus cust-psd-pt-down 1

frequency 1000 psd 55
configure xdsl spectrum-profile 11 adsl2-plus cust-psd-pt-down 2

Configuration example for VDSL (downstream):
configure xdsl spectrum-profile 12 name vdsl1-1
configure xdsl spectrum-profile 12 vdsl psd-shape-down

custom-psd-down
configure xdsl spectrum-profile 12 vdsl cust-psd-sc-down

logarithmic cust-psd-ty-down mask
configure xdsl spectrum-profile 12 vdsl cust-psd-pt-down 1

configure xdsl spectrum-profile 12 vdsl cust-psd-pt-down 2

Configuration example for VDSL (upstream):
configure xdsl spectrum-profile 13 name vdsl1-2 version 1
configure xdsl spectrum-profile 13 vdsl rx-psd-shape-up

custom-rx-psd-up
configure xdsl spectrum-profile 13 vdsl cust-rx-psd-sc-up

logarithmic cust-rx-psd-ty-up template
configure xdsl spectrum-profile 13 vdsl cust-rx-psd-pt-up 1

configure xdsl spectrum-profile 13 vdsl cust-rx-psd-pt-up 2

Configuration example for VDSL2 (downstream):
configure xdsl spectrum-profile 14 vdsl2 psd-shape-down

custom-psd-down
configure xdsl spectrum-profile 14 vdsl2 cust-psd-sc-down

logarithmic cust-psd-ty-down template
configure xdsl spectrum-profile 14 vdsl2 cust-psd-pt-down 1

configure xdsl spectrum-profile 14 vdsl2 cust-psd-pt-down 2

Configuration example for VDSL2 (Rx upstream):
configure xdsl spectrum-profile 15 vdsl2 rx-psd-shape-up

custom-rx-psd-up
configure xdsl spectrum-profile 15 vdsl2 cust-rx-psd-sc-up

logarithmic cust-rx-psd-ty-up template
configure xdsl spectrum-profile 15 vdsl2 cust-rx-psd-pt-up 1

configure xdsl spectrum-profile 15 vdsl2 cust-rx-psd-pt-up 2
Configuration example for VDSL2 (upstream):
configure xdsl spectrum-profile 16 vdsl2 psd-shape-up

custom-psd-up
configure xdsl spectrum-profile 16 vdsl2 cust-psd-sc-up

logarithmic cust-psd-ty-up template
configure xdsl spectrum-profile 16 vdsl2 cust-psd-pt-up 1

configure xdsl spectrum-profile 16 vdsl2 cust-psd-pt-up 2

DLP 189 Configure VDSL2 virtual
noise values
Purpose
This procedure provides the steps to configure virtual noise values for VDSL2, both in
downstream and upstream direction.
The commands below help the operator to enter the virtual noise values in a user-friendly
way. Instead of entering octets, the operator can enter numbers corresponding to
frequency and PSD.
Note At least 2 values must be configured.
For more detailed information on the parameters, refer to TNG 107.
DLP 189 Configure VDSL2 virtual noise values
Procedure
Proceed as follows to configure virtual noise values for VDSL2:
1 Configure the virtual noise values in downstream direction with the following
command:

v-noise-psd-pt-down (psdpt)
psd <Xdsl::CustPsd>
2 Configure the virtual noise values in upstream direction with the following command:

v-noise-psd-pt-up (psdpt)
psd <Xdsl::CustPsd>
3 Activate an xDSL spectrum profile with the following command:

active
configure xdsl spectrum-profile 17 vdsl2 v-noise-psd-pt-down 1

configure xdsl spectrum-profile 17 vdsl2 v-noise-psd-pt-down 2

configure xdsl spectrum-profile 17 vdsl2 v-noise-psd-pt-up 1

configure xdsl spectrum-profile 17 vdsl2 v-noise-psd-pt-up 2

DLP 190 Configure threshold crossing
alerts
Purpose
This document provides the necessary steps to configure Threshold Crossing Alerts
(TCA) on xDSL lines and on Ethernet lines.
Note Ensure that the TCA alarm is set to reporting and has a severity
equal to or greater than the non-itf-rep-sev-level; see DLP 110.
Prerequisites
The following prerequisites must be fulfilled before a TCA can be configured:
For a TCA on an xDSL line: the xDSL line must be configured; see DLP 124.
DLP 190 Configure threshold crossing alerts
Procedure
Proceed as follows to configure and enable a TCA:
1 Configure and enable a TCA on an xDSL line with the following command:
configure xdsl line (if-index) tca-line-threshold

(no) enable
(no) es-nearend <Xdsl::IntervalTcaThreshold>
(no) ses-nearend <Xdsl::IntervalTcaThreshold>
(no) uas-nearend <Xdsl::IntervalTcaThreshold>
(no) es-day-nearend <Xdsl::DayTcaThreshold>
(no) ses-day-nearend <Xdsl::DayTcaThreshold>
(no) uas-day-nearend <Xdsl::DayTcaThreshold>
(no) es-farend <Xdsl::IntervalTcaThreshold>
(no) ses-farend <Xdsl::IntervalTcaThreshold>
(no) uas-farend <Xdsl::IntervalTcaThreshold>
(no) es-day-farend <Xdsl::DayTcaThreshold>
(no) ses-day-farend <Xdsl::DayTcaThreshold>
(no) uas-day-farend <Xdsl::DayTcaThreshold>
2 Configure and enable a TCA on an Ethernet line with the following command:
configure ethernet line (if-index) tca-line-threshold

(no) enable
(no) los <ETHITF::IntervalTcaThreshold>
(no) fcs <ETHITF::IntervalTcaThreshold>
(no) los-day <ETHITF::DayTcaThreshold>
(no) fcs-day <ETHITF::DayTcaThreshold>
1. For xDSL line:
configure xdsl line 1/1/5/6 tca-line-threshold enable

ses-day-nearend 30
2. For Ethernet line:
configure ethernet line 1/1/5/14 tca-line-threshold enable los 40
DLP 191 Enable dual tagging in the
SHub
Purpose
This procedure provides the steps to specify the tagging mode globally applicable to
SHub VLANs.
When the dual tag mode is set, the SHub works as a stacked-VLAN bridge.
Procedure
Proceed as follows to configure dual tagging mode:
1 Set the dual tag mode in the SHub with the following command:
configure vlan shub dual-tag-mode
2 Disable the dual tag mode in the SHub with the following command:
configure vlan shub no dual-tag-mode
configure vlan shub dual-tag-mode
DLP 191 Enable dual tagging in the SHub
DLP 192 Configure IPProxy CPE
management
Purpose
This procedure provides the steps required to configure the S-VLAN to be used for
IPProxy CPE Management
Prerequisites
The following prerequisites must be fulfilled before IPProxy CPE management can be
configured:
Dual tagging must be enabled in the SHub; see DLP 191

The S-VLAN must not be configured for any other (that is, non-IPProxy) traffic in the
system
IPProxy CPE Management must be disabled
Procedure
Proceed as follows to configure IPProxy CPE management:
1 Create the S-VLAN to be used for IPProxy CPE management in the system with the
following command:
configure vlan id stacked:<Vlan::SVlanIndex>:0 name

<Vlan::AdminString> mode layer2-terminated
2 Associate the S-VLAN created with the IPProxy CPE management function with the
following command:
configure cpe-management vlan-id <CpeProxy::VlanIndex>
3 Create the S-VLAN in the SHub with the following command:
configure vlan shub id <Sys::VlanId> mode layer2-terminated
DLP 192 Configure IPProxy CPE management
4 Associate the S-VLAN created in the SHub with the IPProxy CPE management
function with the following command:
configure cpe-management shub vlan-id <CpeProxy::ShubVlanIndex>
configure vlan id stacked:512:0 name IPProxyVLAN

configure cpe-management vlan-id 512
configure vlan shub id 512 mode layer2-terminated
configure cpe-management shub vlan-id 512
DLP 193 Enable IPProxy CPE
management
Purpose
This procedure provides the steps required to enable IPProxy CPE Management
Prerequisites
The following prerequisites must be fulfilled before IPProxy CPE management can be
enabled:
CPE management mode must be disabled

The IPProxy CPA management S-VLAN must have been configured; see DLP 192
Procedure
Proceed as follows to enable IPProxy CPE management:
1 Configure the CPE Management mode as IP with the following command:
configure cpe-management proxy-mode ip
configure cpe-management proxy-mode ip
DLP 193 Enable IPProxy CPE management
DLP 194 Configure IPProxy CPE
management session
Purpose
In order to be able to use Telnet or TFTP to manage a CPE connected to an LT port, a
IPProxy CPE management session has to be configured first.
This procedure provides the steps to configure an IPProxy CPE Management session.
Prerequisites
The following prerequisites must be fulfilled before IPProxy CPE management session
can be configured:
The IPProxy CPE Management S-VLAN must have be configured; see DLP 192
The IPProxy CPE Management S-VLAN function must have be enabled; see
DLP 193
The LT to which the CPE is connected must be planned and unlocked; see DLP 111
and DLP 112 respectively.
Procedure
Proceed as follows to configure a IPProxy CPE management session:
1 Configure the xDSL line to which the CPE is connected with the following command:
configure xdsl line

<Eqpt::RackId>/<Eqpt::ShelfId>/<Eqpt::SlotId>/<Eqpt::PortId>
service-profile <Xdsl::LineServiceProfile>
spectrum-profile <Xdsl::LineSpectrumProfile>
admin-up
2 Configure xDSL line interface port with the following command:

xdsl-line:<Eqpt::RackId>/<Eqpt::ShelfId>/<Eqpt::SlotId>/
<Eqpt::PortId>
3 Add the SHub LT port to which the CPE is connected to the IPProxy CPE
Management S-VLAN (if not already added) with the following command:
configure vlan shub id <Sys::VlanId> egress-port

lt:<Eqpt::RackId>/<Eqpt::ShelfId>/<Eqpt::SlotId>
4 If the NT type is not of type ECNT-C, add the SHub NT port to the S-VLAN (if not
already added) with the following command:
configure vlan shub id <Sys::VlanId> egress-port nt
5 Configure the SC-VLAN to be used for this session. In this step, the CVlanIndex
given must be calculated as follows based on the LT port on which the IPProxy
session must be configured:
CVlanIndex = 48 x (LT slot# - 1) + LT port# + 1
where:
LT slot# has the range [1..16] (1 for left most LT slot on rack 1, shelf 1 and 16 for the last LT slot on
rack 1, shelf 1)
LT port# has the range [1..48] (1 for the first LT port and 48 for the last LT port).
configure vlan id stacked:<Vlan::SVlanIndex>:<Vlan::CVlanIndex>

name <Vlan::AdminString> mode cross-connect
6 Configure the PVC for this session with the following command:
configure atm pvc <Eqpt::RackId>/<Eqpt::ShelfId>/

<Eqpt::SlotId>/<Eqpt::PortId>:<Eqpt::VpiId>:Eqpt::VciId>
7 Configure an IPoA cross-connect for this session with the following command:
configure atm ip-cross-connect <Eqpt::RackId>/<Eqpt::ShelfId>/

<Eqpt::SlotId>/<Eqpt::PortId>::<Eqpt::VpiId>:<Eqpt::VciId>
cpe <Ip::V4AddressHex>
next-hop <Ip::V4AddressHex>
8 Configure a bridge port for this session with the following command:
configure bridge port <Eqpt::RackId>/<Eqpt::ShelfId>/

<Eqpt::SlotId>/<Eqpt::PortId>:<Eqpt::VpiId>:<Eqpt::VciId>
mac-learn-off
9 Configure the SC-VLAN on the bridge port with the following command:

vlan-id stacked:<Vlan::SVlanIndex>:<Vlan::CVlanIndex>
10 Configure a PVID on the bridge port as the SC-VLAN with the following command:

pvid stacked:<Vlan::SVlanIndex>:<Vlan::CVlanIndex>
11 Create the session with the following command:
configure cpe-management session <Eqpt::RackId>/<Eqpt::ShelfId>

/<Eqpt::SlotId>/<Eqpt::PortId>
[connection <CpeProxy::cpeIpProxySessionProtocolPort>]
where the connection parameter can be optionally specified as an unused (that is, unused by any
other session) port in the range [13410..13457] or omitted. If omitted, the system will automatically
assign a free connection port.

admin-up
configure interface port xdsl-line:1/1/5/8 user IPProxy CPE M
configure vlan id stacked:512:57 name IPProxyCPE54

mode cross-connect
configure atm pvc 1/1/5/8:1:39 aal5-encap-type llc-snap-routed
configure atm ip-cross-connect 1/1/5/8:1:39 cpe 192.168.1.1

next-hop 192.168.1.2
configure bridge port 1/1/5/8:1:39 mac-learn-off
configure cpe-management session 1/1/5/8
DLP 195 Configure general bridge
parameters
Purpose
This procedure provides the steps to configure the system parameters for all bridge ports.
Procedure
Proceed as follows to configure the system parameters for all bridge ports:
1 Configure specify the aging time for dynamically learned MAC addresses in the
filtering database of the LT with the following command:
configure bridge
ageing-time <Vlan::AgingTime>
Note The setting is applicable to the entire bridge.
2 Configure specify the aging time for dynamically learned MAC addresses in the
filtering database of the SHub with the following command:
configure bridge shub

ageing-time <Shub::AgingTime>
Note The setting is applicable to the entire SHub bridge.
DLP 195 Configure general bridge parameters
3 Configure specify the MAC learning states with the following command:
configure bridge shub mac-learning

(no) disable-nw-port
Note The setting is applicable to the entire SHub bridge.
configure bridge ageing-time 360
configure bridge shub ageing-time 360
configure bridge shub mac-learning no disable-nw-port
Purpose
This document provides the steps to configure the Voice Session Initiation Protocol (SIP).
Prerequisite
The following prerequisite must be fullfilled before Voice SIP can be configured:
The board (POLT-B) and the applique (PTCP-A) must be planned; see DLP 111.
A VLAN in mode voice-vlan must have been created
configure vlan shub id <Sys::VlanId> mode voice-vlan
Network interfaces must have been added to the VLAN; see DLP 121.
Procedure
Proceed as follows to configure Voice SIP:
1 To manage the Voice SIP server profile, do one of the following:
a Manage the Voice SIP server profile by IPv4 with the following command
configure voice sip server (name)

admin-status up
address ipv4:<Ip::V4Address>
(no) port <Sip::ServerPort>
(no) server_type <Sip::ServerType>
b Manage the Voice SIP server profile by DNS with the following command:
configure voice sip server (name)

admin-status up
address dns:<Sip::ServerAddr>
(no) port <Sip::ServerPort>
(no) server_type <Sip::ServerType>
2 Manage the Voice SIP dial plan profile with the following command:
configure voice sip dialplan (name)

(no) pre-activated <Sip::DialPlanPreActivated>
(no) static-prefix <Sip::DialPlanStaticPrefix>
(no) static-suffix <Sip::DialPlanStaticSuffix>
3 Manage the Voice SIP dial plan digitmap profile with the following command:
configure voice sip digitmap (name)

type <Sip::DialPlanDigitmapType>
rule <Sip::DialPlanDigitmapValue>
(no) access-type <Sip::DialPlanDigitmapAccessType>
Note 1 The name of the Voice SIP dial plan digitmap profile must be
the same as the name of the Voice SIP dial plan profile (see step 2).
Note 2 The parameter access_type is not visible when a new Voice

SIP dial plan digitmap is created, but only when an existing digitmap is
modified.
4 To configure the Voice SIP user agent profile, do one of the following:
a Configure the Voice SIP user agent profile management by DHCP with the
following command:
configure voice sip user-agent-dhcp (name)

associated-slot <Equipm::LtSlotIndex>
associated-proxyserver none | name:<Sip::ServerName>
associated-regserver none | name:<Sip::ServerName>
associated-dialplan none | name:<Sip::DialPlanName>
(no) user-agent-domain <Sip::UserAgentUaDomain>
admin-status up | down
(no) port <Sip::UserAgentPort>
vlan-id <Sip::UserAgentVlanId>
(no) signal-dscp <Sip::UserAgentSignalDscp>
(no) signal-pbits <Sip::UserAgentSignalPbits>
(no) rtp-dscp <Sip::UserAgentRtpDscp>
(no) rtp-pbits <Sip::UserAgentRtpPbits>
b Configure the Voice SIP user agent profile mangement manually with the
following command:
configure voice sip user-agent-manual (name)

associated-slot <Equipm::LtSlotIndex>
associated-proxyserver none | name:<Sip::ServerName>
associated-regserver none | name:<Sip::ServerName>
associated-dialplan none | name:<Sip::DialPlanName>
(no) user-agent-domain <Sip::UserAgentUaDomain>
admin-status up | down
ip-address <Sip::UserAgentIpAddr>
prefix-length <Sip::PrefixLength>
gateway-ip <Sip::UserAgentIpAddr>
domain-server <Sip::UserAgentIpAddr>
(no) port <Sip::UserAgentPort>
vlan-id <Sip::UserAgentVlanId>
(no) signal-dscp <Sip::UserAgentSignalDscp>
(no) signal-pbits <Sip::UserAgentSignalPbits>

(no) rtp-dscp <Sip::UserAgentRtpDscp>
(no) rtp-pbits <Sip::UserAgentRtpPbits>
5 Manage the Voice SIP termination profile with the following command:
configure voice sip termination (termination)

user-agent <Sip::UserAgentName>
(no) directory-number <Sip::TermDnumber>
(no) user-name <Sip::TermUserName>
(no) uri <Sip::TermUri>
(no) direct-uri <Sip::TermUri>
(no) line-feed <Sip::TermLineCharacter>
(no) md5-realm <Sip::MD5Realm>
(no) md5-password <Sip::MD5Realm>
(no) admin-status <Sip::TermAdminStatus>
6 Manage the Voice SIP port Local Loop Unbundling with the following command:
configure voice sip local-loop (line)

(no) unbundle
Note This command can only be used when ALTS-U subracks are
being used.
configure voice sip server SIPServer1 address ipv4:200.200.1.1
configure voice sip server SIPServer1 admin-status up
configure voice sip dialplan SIPDialplan1
configure voice sip digitmap SIPDialplan1 type regular rule 120
configure voice sip user-agent-dhcp SIPAgent1

associated-slot 1/1/6 associated-proxyserver name:SIPServer1
associated-regserver name:SIPServer1
associated-dialplan name:SIPDialplan1 admin-status up vlan-id 650
configure voice sip termination 1/1/6/1 user-agent SIPAgent1

directory-number 123456 admin-status up
DLP 197 View port configuration and
operational data
Purpose
This procedure provides the commands for viewing the configuration and operational
data of xDSL ports and Ethernet ports on the NE.
Note For more information on the command syntax and the

command parameters, refer to the CLI Commands and Messages.
Procedure
The following commands can be used for viewing the configuration and operational data
of ports:
1 Use the following commands to show the configuration data of an xDSL port:
show xdsl config-data-port (if-index) xdsl

| atm-pvc (port-index) | interface-atm-pvc | interface-port
| igmp (port) | security-pae (port) | bridge-port (port) | qos
| pppox-relay (port) | pppoe (port) | bonding-group
2 Use the following commands to show the operational data of an xDSL port:
show xdsl oper-data-port (if-index) xdsl

| bridge-port (port) | atm-pvc (port-index) | interface-port
| igmp (port) | ip-bridge-port (ip-bridge-port) | qos
3 Use the following commands to show the configuration data of an Ethernet port:
show config-data-port (if-index) interface-port

| igmp (port) | security-pae (port) | bridge-port (port) | qos
| pppoe (port)
4 Use the following commands to show the operational data of an Ethernet port:
show oper-data-port (if-index) ethernet | bridge-port (port)

| interface-port | igmp (port) | ip-bridge-port (ip-bridge-port)
| qos
show xdsl config-data-port 1/1/5/12
show xdsl oper-data-port 1/1/5/12
show config-data-port 1/1/5/14
show oper-data-port 1/1/5/14
DLP 198 Configure multicast on the
SHub
Purpose
This procedure provides the steps to configure multicast on the SHub (general
parameters, capacity and source table) on the NE.
Prerequisites
The following prerequisites must be fulfilled before multicast on the SHub can be
configured:
IGMP snooping must be activated; see DLP 138.

The egress port must have been added to the VLAN; see DLP 128.
Procedure
Proceed as follows to configure multicast on the SHub:
1 Configure the multicast related parameters applicable to the SHub with the following
command:
configure mcast shub

(no) active-streams <Igmp::MaxMcastLearn>
(no) max-bw <Igmp::SystemMaxbandwidth>
(no) max-no-rate-based <Igmp::SystemMaxNoRateBased>
2 Configure entries in the IP multicast table for the SHub with the following command:
configure mcast shub mcast-addr (mcast-addr)

DLP 198 Configure multicast on the SHub
3 Configure the ports to which the traffic related to the specified multicast IP address
will be forwarded with the following command:
configure mcast shub mcast-addr (mcast-addr)

(no) egress-port (port)
4 Configure the CAC Multicast Source with the following command:
configure mcast shub src (src) vlan-id <Igmp::McastSrcVLANID>

(no) eth-sus-bit-rate <Igmp::McastSrcEtherSustainBitRate>
(no) guaranteed-serv <Igmp::MulticastGuaranteedServ>
(no) bundle name <Igmp::IgnoredBundleName>
configure mcast shub active-streams 200
configure mcast shub mcast-addr 224.1.1.10 vlan-id 200
configure mcast shub mcast-addr 224.1.1.10 vlan-id 200

egress-port lt:1/1/5
configure mcast shub src 224.1.1.1 vlan-id 200 ip-addr 0.0.0.0

eth-sus-bit-rate 4250 guaranteed-serv bundle name:MyBundle
Purpose
This procedure provides the steps to configure QoS on the SHub.
refer to TNG 101.
Prerequisites
The following prerequisites must be fulfilled before QoS on the SHub can be configured:
The egress port must have been added to the VLAN; see DLP 128.
Procedure
Proceed as follows to configure QoS on the SHub:
1 Configure the queues on the SHub ports with the following command:
configure qos shub queue-config (port)

(no) queue0-weight <Qos::ShubQueueWeight1>
(no) queue1-weight <Qos::ShubQueueWeight1>
(no) rx-pause
(no) egress-rate <Qos::ShubPortRate>
(no) dscp2p-enable
2 Configure the traffic classes on the SHub with the following command:
configure qos shub tc-map-dot1p (port)

traffic-class <Qos::ShubTrafficClass>
3 Configure the mapping of the DSCP value to the 802.1p value with the following
command:
configure qos shub dscp-map-dot1p (dscp-index)

dot1p-value <Qos::ShubDSCPPriority>
4 Configure the ingress policing parameters on SHub port with the following
command:
configure qos shub meter (index)

(no) name <Qos::DisplayString>
max-ingress-rate <Qos::MeterIngressRate>
burst-size <Qos::MeterBurstSize>
5 Configure the various flows to be policed with the following command:
configure qos shub flow (index)

(no) name <Qos::DisplayString>
(no) (type)
6 Configure the policing association with the following command:
configure qos shub policer (port-id)

flow <Qos::PolicerFlowIndex>
meter <Qos::PolicerMeterIndex>
configure qos shub queue-config 3 queue0-weight 4

queue1-weight 6 egress-rate 800
configure qos shub tc-map-dot1p 2 traffic-class 1
configure qos shub dscp-map-dot1p 13 dot1p-value 2
configure qos shub meter 32 name QoSShubMeter32

max-ingress-rate 8192 burst-size 4
configure qos shub flow 22 name VLANFLow vlan:300
configure qos shub policer 3 flow 22 meter 32
Purpose
The Multiple Spanning Tree Protocol (MSTP), which uses RSTP for rapid convergence,
enables VLANs to be grouped into a spanning-tree instance, with each instance having
a spanning-tree topology independent of other spanning-tree instances. This architecture
provides multiple forwarding paths for data traffic, enables load balancing, and reduces
the number of spanning-tree instances required to support a large number of VLANs.
Prerequisite
The following prerequisite must be fulfilled before MSTP can be configured:
A VLAN in iBridge mode must have been created on the SHub; see DLP 120 step 3.
The port-type of the network port must be different from unused.
This can be verified with the command
and, if necessary, changed as follows:
Set the port type to no-type with the command:
configure interface shub port (network-port) no port-type
Change the port type with the command:
configure interface shub port (network-port) port-type <Sys::Type>
Procedure
Proceed as follows to configure MSTP:
1 Configure the general MSTP parameters with the following command:
configure mstp general

(no) disable-stp
(no) priority <Shub::StpPriority>
(no) max-age <Shub::StpMaxAge>
(no) hello-time <Shub::StpHelloTime>
(no) forward-delay <Shub::StpFwDelay>
(no) version stp-compatible | rstp | mstp
(no) tx-hold-count <Shub::StpTxHoldCount>
(no) path-cost-type 16-bit | 32-bit
(no) max-hop-count <Shub::StpMaxHopCount>
region-name <Shub::StpRegionName>
(no) region-version <Shub::StpRegionVersion>
(no) config-id-sel <Shub::StpConfigIdSelector>
Note 1 The configuration of the parameters applies for the whole

bridge.
Note 2 This configuration applies to the SHub.
Note 3 When configuring RSTP, this command has to be split. Refer

to the configuration example for RSTP at the end of this procedure.
2 Configure the MSTP parameters for a specific MSTP instance with the following
command:
configure mstp instance (instance)

(no) priority <Shub::StpPriority>
3 Map/unmap the VLAN on the MSTP instance with the following command:
configure mstp instance (instance)

(no) associate-vlan (vlan) <Shub::MstpVlanId>
Note 1 The VLAN can be associated with the MSTP instance without
being configured first.
Note 2 One or more VLANs can be associated to an instance, but one

VLAN can not be assigned to different instances.
4 Configure the port parameters for the Common Instance with the following
command:
configure mstp port <Shub::MstpNetworkPort>

(no) priority <Shub::MstpPortPriority>
(no) disable-stp
path-cost <Shub::MstpPathCost>
(no) edge-port
(no) admin-p2p <Shub::MstpAdminP2PPort>
(no) hello-time <Shub::StpHelloTime>
Note By default MSTP is enabled on the network and outband ports.
5 Configure the MSTP parameters for a specific port-instance configuration with the
following command:
configure mstp port-instance (network-port)

instance <Shub::MstpInstance>
(no) priority <Shub::MstpPortPriority>
(no) disable-stp
path-cost <Shub::MstpPathCost>
6 Manage MSTP related to a port (that is, clear the list of detected protocols) with the
following command:
admin mstp port (network-port)

clear-protocols
7 View the MSTP operational information:
a View all the common spanning tree instances for the whole bridge with the
following command:
show mstp bridge
b View the parameters of a multiple spanning tree instance with the following
command:
show mstp instance (instance)
c View the MSTP network port information with the following command:
show mstp network-port (port)
d View all the MSTP port instances with the following command:
show mstp port-instance (network-port)

instance (instance)
In MSTP mode:
configure mstp general priority 61440 max-age 1000 path-cost-type

32-bit version mstp region-name region1 region-version 1
config-id-sel 1 forward-delay 2000
configure mstp instance 1
configure mstp instance 1 associate-vlan 100
configure interface shub port 2 no port-type
configure mstp port 2 hello-time 100 admin-p2p force-true no

disable-stp priority 48
configure mstp port-instance 2 instance 1 priority 32 no

disable-stp path-cost 40000
admin mstp port 2 clear-protocols
In RSTP mode:
configure mstp general version rstp
configure mstp general max-age 2100
configure mstp general hello-time 500 forward-delay 2500

no disable-stp priority 4096 path-cost-type 32-bit
configure mstp port 2 admin-p2p force-true no disable-stp

priority 48
Purpose
This procedure allows the operator to enable or disable protocol tracing. The operator
can enter the protocol, the port and the level of detail for which tracing can be enabled.
Procedure
Proceed as follows to configure protocol tracing:
1 Configure protocol tracing with the following command:
configure debug protocol-trace (trace-subject)

protocol igmp | dhcp | arp
syslog <Debug::SyslogMsgType>
(no) events
(no) packet-summary
configure debug protocol-trace dsl-line:1/1/4/15

protocol dhcp syslog tracing2 events packet-summary
DLP 202 Configure QoS threshold
crossing alerts
Purpose
This procedure provides the steps to configure QoS Threshold Crossing Alerts (TCA).
Prerequisites
The following prerequisites must be fulfilled before QoS TCAs can be configured:
Procedure
Proceed as follows to configure QoS TCAs:
1 Configure the QoS global variable with the following command:
configure qos global (index)

(no) buffer-occ-thresh <Qos::PercentThresh>
(no) enable-queuestat
(no) fan-out-tca
(no) fan-out-thresh <Qos::PercentThresh>
(no) buffer-tca
(no) up-buf-thresh
<Qos::QosStatsSettingUpAggrBufOvflwTcaThreshold>
(no) up-obc-thresh
<Qos::QosStatsSettingUpObcAggrBufOvflwTcaThreshold>
(no) dn-obc-thresh
<Qos::QosStatsSettingDnObcAggrBufOvflwTcaThreshold>
(no) dn-buf-thresh
<Qos::QosStatsSettingDnUcAggrBufOvflwTcaThreshold>
(no) part-buf-thresh <Qos::PartBufThresh>
DLP 202 Configure QoS threshold crossing alerts
2 Configure the QoS TCA table with the following command:
configure qos tca (index) queue <Qos::TcaQueues>

(no) tca-enable
(no) load-thresh <Qos::PercentThresh>
(no) dis-frame-th <Qos::QosQueueStatsDiscFramesTcaThreshold>
configure qos global lt:1/1/5 enable-queuestat fan-out-tca

fan-out-thresh 80
configure qos tca 1/1/5/12 queue 1 tca-enable load-thresh 75
DLP 203 Configure general security
settings
Purpose
This procedure provides the steps to configure general security settings such as:
password policy
file transfer attributes
Procedure
Proceed as follows to configure general security settings:
1 Configure the password policy with the following command:
configure system security password

min-length <Sec::PwdLength>
min-num-numeric-char <Sec::PwdNumChars>
min-num-special-char <Sec::PwdSpeChars>
(no) mixed-case <Sec::MixCase>
2 Configure file transfer states and attributes with the following command:
configure system security filetransfer

(no) protocol <SwMngt::Protocol>
3 Configure the file transfer server attributes with the following command:
configure system security filetransfer

server (serverid)
user-name <SwMngt::UserName>
password <SwMngt::Password>
DLP 203 Configure general security settings
configure system security password min-length 8

min-num-special-char 2 mixed-case mandatory
configure system security filetransfer protocol sftp
configure system security filetransfer server 192.168.210.1

user-name JohnDoe password My#Pass&
DLP 204 Configure an unnumbered IP
interface on the SHub
Purpose
This procedure provides the steps to configure an unnumbered IP interface on the SHub.
Note An unnumbered interface can only be configured for the

external management VLAN 4093.
Prerequisites
The following prerequisites must be fulfilled before an unnumbered IP interface can be
configured:
The system must run in single IP address mode
Procedure
Proceed as follows to configure the unnumbered IP interface:
1 Configure a layer2 terminated VLAN on the network port of the Shub with the
following command:
configure vlan shub id (vlan-id) mode layer2-term-nwport
2 Configure a VLAN on the SHub with the following command:
3 Configure an IP interface on the VLAN with the following command:
DLP 204 Configure an unnumbered IP interface on the SHub
4 Configure a VLAN on the SHub with as egress port the SHub port configured in:
configure interface shub ip (vlan-id) ip-addr

<Ip::V4Address>/<Ip::PrefixLengthFull>
5 Set the administrative status of the VLAN to up with the following command:
configure interface shub vlan-id (vlan-id) admin-status up
6 Configure a management VLAN on the SHub with the following command:
7 Configure an unnumbered interface on the management VLAN with the following

command:
8 Associate the numbered interface with the management VLAN with the following
command:
configure interface shub ip 4093 unnumbered-as (vlan-id)
where vlan-id is the VLAN created in step 2.
configure interface shub ip 4093 unnumbered-as 600
RTP 100 Backup the configuration
RTP 101 Restore the configuration
RTP 102 Retrieve remote inventory
Purpose
This procedure provides the steps to back up the NT database.
Caution 1 The SHub database is part of the NT database. The

system automatically saves the SHub database every 10 minutes. If a
change is made to the SHub database and the system is reset prior to the
database being saved, the changes can be lost. The operator can check
if the database has been saved since the last change with the following
command.
The SHub database can be saved manually with the following command:
Caution 2 If the system is reset within 10-20 seconds after an NT

database changes has been made, it is possible that this latest change
could be lost. The operator should ensure that no changes to the
database have been made 30 seconds prior to resetting or removing the
NT or shutting down the power to the system.
General
The TFTP daemon on the AWS assumes a default home directory
/var/opt/aws/equipment.
The TFTP daemon on the AMS assumes a default home directory

/opt/ALAams/systemdata.
This means that all the TFTPs initiated from the NE result in a file written relative to this
point.
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 RTP 100-1
Note 1 It is highly recommended to name the file to which the

database is to be saved dm_complete.tar. The protected database will
then be saved including the configured security SNMP community (which
is necessary for communication with the AWS/AMS after a restore).
If another filename (for example dm.tar) is chosen, then the security

SNMP community must be recreated manually after a restore.
Note 2 Only 2 file names are allowed:
dm_complete.tar
dm.tar: This is the dm_complete.tar without the management data
Prerequisite
An empty file dm_complete.tar must exist in the specified path on the TFTP server before
the upload is started. Otherwise, the upload will fail (error upload-error:file-not-found).
Note The superuser must create this file.
Create the dm_complete.tar file on the TFTP server with the following commands
($ prompt is regular user, # prompt is superuser):
$ su
# cd /var/opt/aws/equipment/temp (*)
# touch dm_complete.tar
# chmod 666 dm_complete.tar
# exit
The NT database can now be backed up.
Note (*) For AMS, the command is cd /opt/ALAams/systemdata
RTP 100-2 June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Procedure
Proceed as follows to back up the NT database:
2 Back up the NT database (and SHub database) with the following command:
admin software-mngt database upload

actual-active:<Ip::V4Address>:<SwMngt::path>
where <IP::V4Address> is the IP address of the AMS or AWS server.
3 View the status of the database upload process and, in case of an upload failure,
the reason, with the following command:
show software-mngt upload-download

actual-active:10.176.5.5:dm.tar
actual-active:10.176.5.5:dm_complete.tar
Purpose
This procedure provides the steps to restore the NT database (and SHub database).
The filename of the database is dm_complete.tar.
Procedure
Proceed as follows to restore the NT database:
1 Download the database with the following command:
admin software-mngt database download

<Ip::V4Address>:<SwMngt::path>
where <IP::V4Address> is the IP address of the AMS or AWS server.
2 View the status of the database download process and, in case of an download
failure, the reason, with the following command:
3 Activate the downloaded database with the following command:
admin software-mngt oswp (index current oswp) activate

with-linked-db
admin software-mngt database download 10.176.5.5:dm_complete.tar
admin software-mngt oswp 1 activate with-linked-db
Purpose
This procedure provides the steps to retrieve and show the remote inventory information.
Table RTP 102-1 describes the RI information that is shown.
Table RTP 102-1: RI information
RI information Description
manufacturer An identification of the board manufacturer

inventory-pba The Alcatel-Lucent Printed Board Assembly code of the code
inventory-fpba The Alcatel-Lucent Printed Board Assembly code of the board, which also
identifies the boot software
inventory-ics The Item Change Status iteration code of the board

inventory-clie The (USA) Common Language Equipment Identification code of the board
serial-no The serial number of the board
Procedure
Proceed as follows to retrieve and show remote inventory information:
1 View the RI information with the following command:
show equipment slot <Eqpt::Rack>/<Eqpt::Shelf>/<Eqpt::Slot>

detail
show equipment applique

<Eqpt::RackId>/<Eqpt::ShelfId>/<Eqpt::AppliqueSlotId>
detail
show equipment slot detail
show equipment applique detail
TAP 100 Metallic test access
TAP 101 F5 loopback test
TAP 102 Equipment repair
TAP 103 Single ended line testing
TAP 104 Fault isolation and troubleshooting
Purpose
This procedure provides the steps for Metallic Test Access (MTA) using TL1 commands.
Note Depending on the capabilities of the applique/splitter card,

either full test access (that is, MTA) or limited test access (that is, outward
test access) is supported.
The setup for MTA sessions is shown in Figure TAP 100-1.
Figure TAP 100-1: Metallic test access setup
To filter, modem and phone To PSTN

A special cable modified
from serial cable, the Shelf
outward and inward bos
Test TAU SPLITTER
NTIO
Power
TL1 gateway Test Head
-48v
installed NT LT
Computer/WS Lab
(Median Device Network
software installed) SHub
Computer
(test head
Software installed)
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 TAP 100-1
Useful TL1 Commands

The following TL1 commands are useful for MTA:
ACT-USER command
CONN-LPACC-MET command
CONN-TACC-MET command
CHG-SPLIT command
CONN-MON command
DISC-TACC command
REPT-STAT command
REPT-INITZN command
REPT-OPSTAT-TACC command
CANC-USER command
ACT-USER Command
Command Syntax
ACT-USER:[tid]:uid:[ctag]::pid;
Command Description
This command activates the user session.
Configuration Example
ACT-USER::SUPERUSER:::PASWD;
CONN-LPACC-MET Command
Command Syntax
CONN-LPACC-MET:[tid]:aid_circuit:[ctag]::[tap]:[configrn];
Command Description
This command controls TAP selection, access point designation, and TAP loop around
for the remote test unit to calibrate for the next test.
CONN-LPACC-MET: LAB: XDSL-1-1-1-1:::1:2WA;
TAP 100-2 June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
CONN-TACC-MET Command
Command Syntax
CONN-TACC-MET:[tid]:[tap]:[ctag];
Command Description
This command enables the NE to provide a zero-loss, high-impedance monitor

connection to the transmission pair of the circuit and complete circuit access.
It also removes the TAP loop around and connects the appropriate TAP lead pair to the
access point.
CONN-TACC-MET:LAB:1:;
CHG-SPLIT Command
Command Syntax
CHG-SPLIT:[tid]:[tap]:[ctag];
Command Description
This command instructs the NE to provide the necessary connection to the TAP and split,
at the access point, the pair or pairs specified by the access command of the circuit under
test.
Use this command to provide access to the lead pair in order to induce TDR testing.
CHG-SPLIT:LAB:1:;
CONN-MON Command
Command Syntax
CONN-MON: [tid]:[tap]:[ctag];
Command Description
This command is used to establish a monitor state without having to re-access the circuit
under test. Use this command to get from the SPLIT mode to MONITOR mode.
CONN-MON:LAB:1:;
DISC-TACC Command
Command Syntax
DISC-TACC:[tid]:[tap]:[ctag];
Command Description
This command causes the NE to restore the circuit under test to its through state and
release all TAP connections to that access point.
DISC-TACC:LAB:1:;
REPT-STAT Command
Command Syntax
REPT-STAT:[tid]::[ctag];
Command Description
This command is sent from the OS to the RTU or the NE to check that the link between
them is in operation. Additionally, if the NE does not receive this command from the OS
or the RTU for a period of 75 seconds, it shall release any access at the TAP.
REPT-STAT:LAB::;
REPT-INITZN Command
Command Syntax
REPT-INITZN:[tid]::[ctag];
Command Description
This input command message is used to indicate an initialization by an OS to a RTU or

by a RTU to NE or by NE to RTU.
As input command, it is sent from the OS to the RTU or NE to indicate the OS has
initialized. The RTU and NE will disconnect any accesses that are up at the request of
the OS sending this command.
If the RTU initializes, this command is sent to all NE's providing test access causing the
accesses to release.
If the NE initializes, this input command will be send to the RTU providing test access
causing the RTU to release all resources.
REPT-INITZN:LAB::;
REPT-OPSTAT-TACC Command
Command Syntax
REPT-OPSTAT-TACC:[tid]:[tap]:[ctag];
Command Description
This command reports the status of the test access port (TAP).
Following options are supported for STATE:
IDLE = No test access active.

LPACC = The TAP has been assigned to a circuit, but it is in loopback mode.
MON = The TAP is passively monitoring a circuit.
SPLIT = The TAP is intrusively accessing the equipment and the circuit in full split
mode.
REPT-OPSTAT-TACC:LAB:1:;
CANC-USER Command
Command Syntax
CANC-USER:[tid]:[uid]:[ctag];
Command Description
This command terminates the user session and releases all TAP resources on the NE.
CANC-USER: LAB::;
Purpose
This procedure provides the steps to perform an F5 loopback end-to-end test on the NE.
Note The result of the test is displayed in microseconds.
Procedure
Proceed as follows to perform an F5 loopback test:
1 Start an F5 loopback test with the following command:
admin atm port (port) f5-loopback-ete start
2 View the result of the test with the following command:
info admin atm port (port)
admin atm port 1/1/5/1:8:35 f5-loopback-ete start
info admin atm port 1/1/5/1:8:35
Purpose
This procedure provides the steps to perform equipment repair on the NE.
Procedure
Proceed as follows to perform equipment repair tasks:
1 Lock equipment (mostly plug-in units); see DLP 112.
2 Shut down individual equipment; see DLP 153.
3 Pull out equipment; see the XD Modular Hardware Installation Manual for the 7302
ISAM or the Hardware Installation and Maintenance Practices for the 7330 FTTN.
Note The NE does not keep time while the card is unplugged from the
shelf. In order for the time to be synchronized when the card boots up, it
must be set to use SNTP time synchronization with the management
station. See DLP 103.
4 Replan equipment (for example, plug-in units); see DLP 111.
5 Plug in equipment; see the XD Modular Hardware Installation Manual for the 7302
ISAM or the Hardware Installation and Maintenance Practices for the 7330 FTTN.
6 Power up individual equipment; see DLP 153.
7 Unlock equipment (mostly plug-in units); see DLP 112.
8 Start up or shut down the system. Do one of the following:
a Shut down or restart the SHub; see DLP 151.
b Reboot the entire system; see DLP 152.
General Description
Single Ended Line Testing (SELT) is a modem-based feature which allows to measure
loop characteristics between the U-C and U-R interface. No CPE modem is to be
connected. SELT will help in cooperation with a centralized Network Analyser (NA) for
loop pre-qualification and maintenance of the network.
Refer to the System Description for more detailed information.
TAP 104 Fault isolation and
troubleshooting
Purpose
This TAP provides steps to use the EMS (5526 AMS or 5523 AWS) or CLI to isolate a
problem indicated by an alarm.
General
Resolve alarms that affect service before the alarms that do not affect service.
Use local procedures to correct problems associated with customized alarms.
Contact Alcatel-Lucent customer technical assistance at 1-888-252-2832

(1-888-ALCATEC) when a problem cannot be corrected.
Use alarm information obtained from the EMS Event Viewer during analysis. Use the TL1
or CLI autonomous messages generated during trouble locating and additional data,
such as visual or audible alarms, when available. Service states should also be
considered.
Caution When an alarm has been disabled by the user, it is not

generated or displayed in the Event Viewer.
See the 7302 ISAM|7330 ISAM FTTN CLI Commands document for information about
CLI syntax. See the 7302 ISAM|7330 ISAM FTTN TL1 Commands and Messages
document for information about TL1 syntax.
Several of the protocols in this TAP may require the assistance of someone familiar with
UNIX systems and commands. Many of the UNIX troubleshooting protocols and most of
the UNIX commands require root access. In these cases, Alcatel-Lucent recommends
that a UNIX system administrator perform the troubleshooting.
Alarms are grouped by alarm type in Table TAP 104-1 and Table TAP 104-2. Each alarm
has the following parameters listed in the order they appear in the table:
Alarm ID (No.): unique identification of the alarm

Alarm name: descriptive alarm name followed by the alarm name as it appears in the
CLI configure command (the CLI alarm name is in parenthesis)
Class:
communication (Com)
processing errors (Proc)
quality of service (QoS)
environmental (Envir)
equipment (Equip)
Severity level assigned to the alarm:
Indeterminate (Ind)
warning (Warn)
minor (Min)
major (Maj)
critical (Crit)
Service affecting: indicates whether the alarm is service affecting (SA) or non-service
affecting (NSA)
The NE type: indicates whether the alarm applies to the 7302 ISAM (7302), the
7330 ISAM FTTN (7330), or both
Description of the alarm
Troubleshooting recommendations
Note Except where otherwise specified, the report and logging

modes for each alarm are enabled.
Procedure
Use this procedure to isolate a fault indicated by an alarm.
1 Choose one of the following methods to access the alarms:
a To access the alarms using 5526 AMS, see the NTP for managing alarms and
events in the 7330 ISAM FTTN Operations and Maintenance Using the 5526
AMS guide.
b To access the alarms using 5523 AWS, see the AWS administration overview
chapter in the 5523 AWS ADMIN User Guide.
c To access the alarms using CLI, see the NTP for monitoring alarms in the
7330 ISAM FTTN Operations and Maintenance Using CLI guide.
2 Select the alarm you want to view.
An associated message appears at the bottom of the window.
Note If multiple alarms are present, resolve alarms in the following

order:
Critical (red)
Major (orange)
Minor (yellow)
3 Use Table TAP 104-1 and Table TAP 104-2 to help you determine the cause of the
alarm and the appropriate action for resolving the alarm. Alarms are grouped by
type. You can use the class column of the table to help locate an alarm in the table.
Some alarms are not currently supported and are indicated as such.
Note 1 In Table TAP 104-1 and Table TAP 104-2, the CLI alarm
names shown in parentheses are listed exactly as they appear in the CLI
configure command. Alarm names as they appear in the CLI show alarm
commands are slightly different.
Note 2 Note that the term board as it appears in the CLI alarms is
referred to as either unit or card throughout the 7330 ISAM FTTN
documentation. For example, the ECNT-A card is a type of NT unit and
the EVLT-A card is a type of LT unit.
Table TAP 104-1: System alarm definitions for the 7302 ISAM and the 7330 ISAM FTTN
Alarm (grouped by alarm type) NE Description Troubleshooting

type recommendations
No. Name (CLI) Class Sev. SA
Alarm type = Equip (1); Index1 = eqptHolderld (index in equipment holder Table), Index2 = not used
0 No defects
1 Persistent data loss Equip Crit SA 7302 System has lost all Reconfigure the system.
(persist-data-loss) 7330 persistent data after
RESTART. System is not
configured.
2 SNTP server not Equip Maj NSA 7302 The SNTP server does not Check the SNTP server.
responding 7330 respond to the requested
(sntp-comm-lost) messages.
4 NT disk 90% full Equip Maj NSA 7302 The NT disk has reached Clean up the disk space.
(nt-disk-90%full) 7330 a 90% full level.
5 System clock not Com Maj SA 7302 The system is configured Check all timing references
using preferred timing 7330 to work in autonomous that correspond to the
mode mode with both timing preferred timing mode for
(preferred-mode) modes allowed and is not the peer equipment and
using the preferred timing the link between the peer
mode because all timing equipment and the system.
references corresponding
to the preferred timing
mode are in failure.
(1 of 29)

6 System clock in Com Crit SA 7302 The system is configured Check all timing references
holdover mode or in 7330 to work in autonomous for the peer equipment and
free-run mode mode and is in holdover or the link between the peer
(timing-reference) free-run mode because all equipment and the system.
timing references are in
failure.
8 Communication lost Equip Crit SA 7302 The NT cannot Check the external LAN
with SHub 7330 communicate with the switch.
(shub-loc) SHub.
25 Back panel type Equip Maj NSA 7302 The NEP back panel type The system will start up
invalid read from SMAS case is with the default back panel.
(back-pnl-inv) an unknown type. Check the back panel type
configuration when the
system is running.
28 SHub configuration Equip Crit SA 7302 The SHub configuration Check the SHub
loss saved on the NT unit configuration with respect
(shub-conf-loss) differs from the current to the database (last
SHub configuration. The database changes may be
last changes on the SHub lost).
database (in between two
configuration save
actions) were lost due to a
subsystem reset.
Alarm type = EquipHolder (2); Index1 = eqptHolderId (index in equipment holder table), Index2 = not used
0 No defects No defects
1 Rack power alarm Equip Min NSA 7302 Power fuse is broken. Check power supplies.
(rack-power)
2 Rack fan unit 1 alarm Equip Maj NSA 7302 Fan unit 1 in rack is failing. Check the fan.
(rack-fan-unit1)
3 Rack fan unit 2 alarm Equip Maj NSA 7302 Fan unit 2 in rack is failing. Check the fan.
(rack-fan-unit2)
7 Shelf-type mismatch Equip Min NSA 7302 Shelf detected, but its Check equipment.
alarm 7330 actual shelf type is Check configuration.
(shelf-mismatch) unknown or it differs from
the planned shelf type.
8 Extension chain Equip Crit SA 7302 A consistency problem Check cabling of the
installation alarm 7330 has been detected with extension cable.
(ext-chain-instl) the installation of the
extension chain or
multiple chains.
(2 of 29)

9 Shelf missing alarm Equip Maj SA 7330 Shelf is planned, but no Check presence of
(shelf-missing) shelf detected. A shelf has GENC-E or GENC-F on
been detected at least host shelf.
once since it was planned. Check cabling to ES.
Check presence of
EDSE-A on ES.
Check presence of LT on
ES.
Check presence of
PWIO-B on ES.
Check fan on ES.
Check power cable on ES.
10 Shelf installation Equip Min NSA 7330 Shelf is planned, but no Check presence of
missing alarm shelf detected. No shelf GENC-E or GENC-F on
(shelf-install-missing) has been detected since it host shelf.
is was planned. Check cabling to ES.
Check presence of
EDSE-A on ES.
Check presence of LT on
ES.
Check presence of
PWIO-B on ES.
Check fan on ES.
Check power cable on ES.
Alarm type = EquipHolder (2); Index1 = eqptHolderId (index in equipment holder table to identify a shelf), Index2 = not
used
15 Door alarm Envir Min NSA 7302 Open NEP cabinet door Close the door.
(door)
17 Fuse alarm Equip Crit NSA 7302 An indication has been Check fuse.
(fuse) 7330 detected that exactly one Check power feed.
power feed is inoperative
within a shelf. This can be
due to no input power or a
blown fuse.
18 Single fan failure Equip Maj NSA 7330 One or more of the shelfs Check fan tray (the LED of
(single-fan-fail) fans has failed. the faulty fans tray is lit
red).
19 Double fan failure Equip Crit SA 7330 Two or more fans in the Check fan tray of shelf that
(double-fan-fail) ARAM-D shelf have failed, raised the alarm. The shelf
or the fan tray was will power off within 3 min.
removed. The shelf on of the alarm.
which the failure occurred
automatically powers
down after approximately
2 min. (1)
The shelf can be a
standalone, a host, or an
expansion shelf.
(3 of 29)

20 System ac power Envir Crit SA 7330 The shelf will shut down in Check power installation.
failure 15 min.
(ac-power-fail) This alarm is externally
provided.
Alarm type = PlugInUnit (3); Index1 = eqptSlotId (index in equipment board table), Index2 = not used
3 Board-type mismatch Equip Min NSA 7392 Unit detected, but its Check configuration.
alarm 7330 actual unit type is
(board-mismatch) unknown or it differs from
the planned unit type. This
alarm applies to all unit
types: NT, LSM, and ACU
units.
4 Waiting for software Equip Maj NSA 7302 This alarm is raised when Check configuration.
(waiting-for-sw) 7330 the system cannot Download software.
download all the
applicable software files
(supported by the active
OSWP) towards the unit.
The following situations
can be distinguished:
The extender/LSM
unit belongs to a unit
type that the active
OSWP does not
support.
The detected LSM
unit belongs to a unit
type that the active
OSWP supports.
However, one or more
of the applicable SW
files are no longer
available on the file
disk of the NT unit.
8 Temperature Equip Maj NSA 7302 The temperature Check fans and restarts
exceeded 7330 threshold on the unit is unit.
(temp-exceeded) exceeded. This alarm In remote units, check for a
applies to NT and LSM dirty fan dust filter.
units. In remote units, the
cause may be a dirty fan
filter.
12 Temperature Equip Maj SA 7302 The unit has powered off Check ambient
shutdown alarm 7330 as a result of temperature.
(temp-shutdown) temperatures that are too Check operation of fans.
high. This alarm applies
only to LSM units. Check unit.
13 Defense alarm Equip Crit SA 7302 The plug-in unit is Replace unit.
(defense) 7330 disconnected from the
system as a means of
defense. The reason for
disconnecting depends on
the plug-in unit type and
the cause of the failure:
LSM: disable or power
down
(4 of 29)

14 Board missing alarm Equip Maj SA 7302 Unit is planned, no unit is Check unit presence.
(board-missing) 7330 detected, but a unit has
been detected at least
once since it was planned.
This alarm applies to all
unit types: NT, EDSE-A,
SATU-A, LSM, and ACU
units.
15 Board installation Equip Min NSA 7302 Unit is planned, no unit is Insert unit.
missing alarm 7330 detected, and no unit has
(board-instl-missing) ever been detected since
it was planned. This alarm
applies to all unit types:
NT, LSM, and ACU units.
16 Board initialization Equip Maj SA 7302 A unit initialization failure Force a cold reset of unit,
alarm 7330 has been detected. This and if this fails, repair unit.
(board-init) alarm applies only to LSM
units.
17 Board reset protection Equip Maj SA 7302 The number of unit resets Force a cold reset of unit,
(board-reset-prot) 7330 within a certain timeframe and if this fails, repair unit.
exceeded the threshold.
This alarm applies only to
LSM units.
28 SEM external power Equip Crit SA 7330 Power to the external Check the power to the
failure power supply failed. SEM external power supply.
(sem-power-fail) is running on battery
power.
29 SEM external power Equip Crit SA 7330 External SEM power Check the external power
supply failure supply or the batteries supply.
(sem-ups-fail) failed. The external AC
power supply can still
provide power, but needs
to be checked to ensure
uninterruptible power
service.
30 Board reset or Equip Maj SA 7302 The LT unit has reset Check cabling if alarm is
communication failure 7330 (alarm ON followed by persistent.
(board-reset-cf) alarm OFF), or there is a If alarm toggles frequently,
communication failure the board will go in Board
(alarm ON). Reset Protection mode
(alarm 3, 17) and power
down.
31 SHub uplink Equip Crit SA 7302 The SHub uplink is Check the SHub uplink
breakdown 7330 broken. The alarm is cable for loose contacts or
(shub-uplink) forwarded to the NT, then missing connections.
to the ACU.
Alarm type = ATM (8); Index1 = ifIndex (of ATM physical port), Index2 = see specific alarm number
1 Connection alarm Equip Maj SA A planned VPI/VCI could
not be marked because of
hardware problems.
Index2 = VPC
This alarm is not currently
supported on the system.
(5 of 29)

2 Cell discarded in the QoS Min SA 7302 ATM cell discarded in the No local repair action.
upstream direction 7330 upstream direction. Sender must lower
(cell-discard-up) Index2 = VPI/VCI shaping rate.
Report mode = disabled
Logging mode = disabled
3 Cell discarded in the QoS Min SA 7302 ATM cell discarded in the No local repair action.
downstream direction 7330 downstream direction. Sender must lower
(cell-discard-down) Index2 = VPI/VCI shaping rate.
Logging mode = disabled
6 Duplicate MAC Com Min SA Duplicate MAC address

address from this pvc from this PVC (the port
(mac-conflict) with the latter coming
MAC address caused the
conflict).
Detailed information, such
as the conflicting MAC
address and the port on
which the MAC address
was first learned, can be
retrieved with the
diagnostics tool.
Index2 = VPI/VCI
supported by the system.
Alarm type = CustomizableAlarm (10); Index1 = Rack_ID (position of the rack, range 0 to 5), Index2 = not used
1 Customizable alarm 1 Envir Ind NSA 7302 Customizable alarm 1

(custom1) alarm

(custom2) alarm

(custom3) alarm

(custom4) alarm

(custom5) alarm
Alarm type = CustomizableAlarm (10); Index1 = eqptHolderID (shelf index in equipment holder table), Index2 = not
used
11 HE customizable Envir Ind NSA 7330 Host/expansion

alarm 1 customizable alarm 1
(he-custom1) alarm

(he-custom2) alarm
(6 of 29)


(he-custom3) alarm

(he-custom4) alarm

(he-custom5) alarm

(he-custom6) alarm
Alarm type = IMA-group (13); Index1 = IfIndex (of IMA-group), Index2 = not used
1 Far-end starting up Com Min SA 7302 The far-end is starting up. Check the IMA group
(ima-grp-fe-su) 7330 configuration at the
far-end.
2 Far-end failed Com Min SA 7302 The far-end is not Check which
configuration 7330 configured properly. configurations are
(ima-grp-fe-cfg) supported at the near-end
and the far-end.
3 Near-end failed Com Min SA 7302 The near-end is not Check which
configuration 7330 configured properly. configurations are
(ima-grp-ne-cfg) supported at the near-end
and the far-end.
4 Insufficient number of Com Min SA 7302 There is an insufficient Check the status of the
links at far-end 7330 number of links at the links at the far-end.
(ima-grp-fe-nl) far-end.
5 Insufficient number of Com Min SA 7302 There is an insufficient Check the status of the
links at near-end 7330 number of links at the links at the near-end.
(ima-grp-ne-nl) near-end.
6 Far-end is blocked Com Min SA 7302 The far-end is blocked. Check the status of the
(ima-grp-fe-blk) 7330 IMA group at the far-end.
Alarm type = IMA-link (14); Index1 = IfIndex (of IMA-link), Index2 = not used
1 Failure in link facility Com Min SA There is a failure in the link

facility.
2 Loss of IMA frame Com Min SA 7302 One or more IMA frames Check the clock
(ima-lnk-lif) 7330 are lost. associated with this link.
3 Link out of delay Com Min SA 7302 The link is out of delay Check the clock
synchronization 7330 synchronization. configuration for the
(ima-lnk-lods) associated group.
(7 of 29)

4 Link misconnect Com Min SA 7302 There is a connection Check the link
(ima-lnk-misc) 7330 problem in the link. configuration at the
far-end.
5 Link remote failure Com Min SA 7302 There is a remote link Check the state of the
indication 7330 failure. associated facility.
(ima-lnk-rfi)
6 Fault in link facility Com Min SA 7302 There is a fault in the link Check for problems with
(ima-lnk-fault) 7330 facility. the associated facility.
7 Transmission blocked Com Min SA 7302 The transmission is Check the link
at far-end 7330 blocked because of a configuration at the
(ima-lnk-txblk) problem at the far-end. far-end.
8 Reception blocked at Com Min SA 7302 The reception is blocked Check the link
far-end 7330 because of a problem at configuration at the
(ima-lnk-rxblk) the far-end. far-end.
Alarm type = Redundancy (20); Index1 = not used, Index2 = not used
1 Switchover capability Equip Maj 7302 The switchover capability Check link on standby NT.
lost 7330 in a redundant system has Check standby boards.
(loss-over-cap) been lost.
Wait for Quench timeout.
Alarm type = SHDSL (23); Index1 = ifIndex (of SHDSL physical port), Index2 = device ID
1 Loss of signal on Com Min SA Loss of signal on the
network side on first network side on the first
pair pair.
(shdsl_n_los_1) This alarm is not currently

customer side on first customer side on the first
pair pair.
(shdsl_c_los_1) This alarm is not currently
3 Loss of Com Min SA Loss of the

synchronization on synchronization word on
network side on first the network side on the
pair first pair.
(shdsl_n_losw_1) This alarm is not currently

customer side on first the customer side on the
pair first pair.
(shdsl_c_losw_1) This alarm is not currently
5 Loop attenuation Com Min SA Loop attenuation alarm on

alarm on network side the network side on the
on first pair first pair.
(shdsl_n_aten_1) This alarm is not currently
(8 of 29)


alarm on customer the customer side on the
side on first pair first pair.
(shdsl_c_aten_1) This alarm is not currently
7 SNR margin alarm on Com Min SA Signal-to-noise margin

network side on first alarm on the network side
pair on the first pair.
(shdsl_n_snr_1) This alarm is not currently

customer side on first alarm on the customer
pair side on the first pair.
(shdsl_c_snr_1) This alarm is not currently
9 DC continuity fault on Com Min SA There is a DC continuity

network side on first fault on the network side
(shdsl_n_dccont_1) This alarm is not currently
customer side on first fault on the customer side
(shdsl_c_dccont_1) This alarm is not currently
11 Loopback active on Com Min SA 7302 Loopback is active on the Testing is in progress.
network side network side
(shdsl_n_loopback)
12 Loopback active on Com Min SA 7302 Loopback is active on the Testing is in progress.
customer side customer side
(shdsl_c_loopback)
13 Configuration error Com Min SA 7302 There is a configuration Check the configuration
(shdsl_conferr) error parameters supported by
the device.
14 Loss of ATM cell Com Min SA 7302 Loss of ATM cell Check the clock
delineation delineation subsystem or the ATM
(shdsl_atm_lcd) configuration.
15 Loss of power at Com Min SA 7302 Loss of power at STU-R Check the power supply at
STU-R the STU-R.
(shdsl_lpr)
16 Unable to disable Com Min SA 7302 Unable to disable STU-R Check for devices that do
STU-R access access not support disabling the
(shdsl_secu_err) STU-R access.
17 Device fault Equip Min SA 7302 Device fault Check the equipment.
(shdsl_dev_fault)
18 No ATM cell Com Min SA 7302 No ATM cell delineation Check the clock
delineation subsystem or the ATM
(shdsl_atm_ncd) configuration.
(9 of 29)


network side on network side on the
second pair second pair.
(shdsl_n_los_2) This alarm is not currently

customer side on customer side on the
(shdsl_c_los_2) This alarm is not currently

network side on the network side on the
(shdsl_n_losw_2) This alarm is not currently
customer side on the customer side on the
(shdsl_c_losw_2) This alarm is not currently

alarm on network side the network side on the
on second pair second pair.
(shdsl_n_aten_2) This alarm is not currently

alarm on customer the customer side on the
side on second pair second pair.
(shdsl_c_aten_2) This alarm is not currently

network side on alarm on the network side
second pair on the second pair.
(shdsl_n_snr_2) This alarm is not currently
customer side on alarm on the customer
second pair side on the second pair.
(shdsl_c_snr_2) This alarm is not currently

network side on fault on the network side
(shdsl_n_dccont_2) This alarm is not currently

customer side on fault on the customer side
(shdsl_c_dccont_2) This alarm is not currently
(10 of 29)

Alarm type = EthItf (24); Index1 = ifIndex (of Ethernet port), Index2 = see specific alarm number
1 IP address conflict on Com Crit NSA IP address conflict on

Ethernet port Ethernet port.
(eth_itf_ip_addr_cnflc This alarm is not currently
t) supported on the system.
Alarm type = SwMgnt (29); Index1 = eqptSlotId (index in equipment board table for the NT), Index2 = not used
1 Implicit software Proc Maj SA 7302 The system cannot make Remove the corrupted
rollback 7330 the NotActive OSWP and OSWP (abort operation).
(sw-rollback) linked database Download the desired
operational (although no OSWP again.
error in the database is
detected). The system Activate the downloaded
performs an implicit OSWP.
rollback to the previous
active OSWP (and linked
database).
2 Implicit database Proc Maj SA 7302 The system cannot make Download the desired
rollback 7330 the selected OSWP and database again.
(db-rollback) linked database
operational (an error is
detected in the linked
database). The system
comes up with the
selected OSWP and the
previous linked database
(if possible).
3 Autofetch failure Proc Min NSA The system cannot fetch a

specific file from the
corresponding file server.
The name of the file that
caused the failure is sent
with the alarm.
Alarm type = TmpFilter (34); Index1 = 0, Index2 = 0 Remark: These values are inherited from the related basic alarm
1 Derived alarm for Com Ind NSA 7302 Derived alarm for Check the cause of the
temporal filter 7330 temporal filter. related basic alarm.
(der-temp1) Report mode = disabled Check the setting of the
Logging mode = disabled related temporal filter.
(11 of 29)

(12 of 29)

(13 of 29)

Alarm type = SpaFilter (35); Index1 = 1, Index2 = not used
1 Derived alarm for Com Ind NSA 7302 Derived alarm for spatial Check the cause of the
spatial filter 7330 filter. related basic alarm.
(der-spa1) Report mode = disabled Check the setting of the
Logging mode = disabled related spatial filter.
(14 of 29)

(15 of 29)

(16 of 29)

Alarm type = xDSL (38); Index1 = ifIndex (of xDSL physical port), Index2 = not used
1 Near-end loss of Com Min SA 7302 Specifies whether a Check the physical line.
signal 7330 near-end loss of signal
(xdsl-ne-los) has occurred
2 Near-end loss of Com Min SA 7302 Specifies whether a Check modem equipment.
frame 7330 near-end loss of frame
(xdsl-ne-lof) has occurred
3 Near-end loss of Com Min SA 7302 Specifies whether a Check the physical line
margin 7330 near-end loss of margin (new distributors).
(xdsl-ne-lom) has occurred
4 Near-end excessive Com Min SA 7302 Specifies whether Check the physical
server errors 7330 near-end excessive server communication medium.
(xdsl-ne-ese) errors occurred
5 Activation failure Com Crit SA 7302 Line configuration data Update the profile
configuration error 7330 cannot be used. parameters.
(xdsl-act-cfg-error) Ensure that the pilot tones
are not marked.
If Glite is used, ensure that
the bit rates fit within the
standard.
6 Activation failure Com Maj SA 7302 Line capacity not high Check configuration data.
configuration not 7330 enough to set up Check physical line (length
feasible requested profile and noise).
(xdsl-act-not-feas)
7 Near-end bit rate Com Min SA 7302 Upstream planned bit rate Lower planned upstream
threshold alarm 7330 not reached after bit rate.
(xdsl-up-br-reach) initialization
8 Near-end no cell Com Min SA 7302 Specifies whether a Check the quality of the
delineation 7330 near-end cell delineation line.
(xdsl-ne-ncd) has occurred
9 Near-end loss of cell Com Min SA 7302 Specifies whether a loss Check the quality of the
delineation 7330 of near-end cell line
(xdsl-ne-lcd) delineation has occurred
10 Far-end loss of signal Com Min SA 7302 Specifies whether a Check the physical line.
(xdsl-fe-los) 7330 far-end loss of signal has
occurred
11 Far-end loss of frame Com Min SA 7302 Specifies whether a Check modem equipment.
(xdsl-fe-lof) 7330 far-end loss of frame has
occurred
12 Far-end loss of power Com Min SA 7302 Specifies whether a There is no repair required
(xdsl-fe-lpr) 7330 far-end loss of power was because this is the normal
detected power-down of CPE.
13 Far-end loss of link Com Min SA 7302 Specifies whether a Check the physical line.
(xdsl-fe-lol) 7330 far-end loss of link was
detected
(17 of 29)

14 Far-end loss of Com Min SA 7302 Specifies whether a Check the physical line
margin 7330 far-end loss of margin has (new distributors).
(xdsl-fe-lom) occurred
15 Far-end - excessive Com Min SA 7302 Specifies whether far-end Check the physical line.
severe errors 7330 excessive server errors
(xdsl-fe-ese) occurred
16 Activation failure Com Maj SA 7302 Unsuccessful initialization Check the peer modem
communication 7330 as a result of type.
problem communication problems Check the physical line.
(xdsl-act-comm)
17 Activation failure Com Min SA 7302 Peer modem not detected Wait until the modem is
No peer modem 7330 connected.
detected Check the physical line.
(xdsl-act-modem)
18 Far-end bit rate Com Min SA 7302 Downstream planned bit Lower the planned
threshold 7330 rate not reached after downstream bit rate.
(xdsl-do-br-reach) initialization
19 Far-end no cell Com Min SA 7302 Specifies whether a Check the quality of the
delineation 7330 far-end cell delineation line.
(xdsl-fe-ncd) has occurred
20 Far-end loss of cell Com Min SA 7302 Specifies whether there is Check the quality of the
delineation 7330 a far-end loss of cell line.
(xdsl-fe-lcd) delineation
Alarm type = xDSLTca (39); Index1 = ifIndex (of xDSL physical port), Index2 = not used
1 Near-end TCA alarm QoS Min NSA 7302 The number of errored Check the physical line.
errored seconds in 15 7330 seconds encountered by Check the modem
min the ADSL line in the equipment.
(xtca-ne-es) current 15-minute interval
has reached its threshold
value.
2 Near-end TCA alarm QoS Min NSA 7302 The number of severely Check the physical line.
severely errored 7330 errored seconds Check the modem
seconds in 15 min encountered by the ADSL equipment.
(xtca-ne-ses) line in the current
15-minute interval has
reached its threshold
value.
3 Near-end TCA alarm QoS Min NSA 7302 The number of Check the physical line.
unavailable seconds 7330 unavailable seconds Check the modem
(xtca-ne-uas) encountered by the ADSL equipment.
line in the current
value.
4 Near-end TCA alarm QoS Min NSA 7302 The number of errored Check the physical line.
day the ADSL line in the equipment.
(xtca-ne-day-es) current one-day interval
has reached its threshold
value.
(18 of 29)

5 Near-end TCA alarm QoS Min NSA 7302 The number of severely Check the physical line.
seconds in 1 day encountered by the ADSL equipment.
(xtca-ne-day-ses) line in the current one-day
interval has reached its
threshold value.
6 Near-end TCA alarm QoS Min NSA 7302 The number of Check the physical line.
in 1 day encountered by the ADSL equipment.
(xtca-ne-day-uas) line in the current one-day
threshold value.
7 Far-end TCA alarm QoS Min NSA 7302 The number of errored Check the physical line.
errored seconds in 7330 seconds encountered by Check the modem
15 min the ADSL far-end line in equipment.
(xtca-fe-es) the current 15-minute
threshold value.
8 Far-end TCA alarm QoS Min NSA 7302 The number of severely Check the physical line.
seconds in 15 min encountered by the ADSL equipment.
(xtca-fe-ses) far-end line in the current
value.
9 Far-end TCA alarm QoS Min NSA 7302 The number of Check the physical line.
(xtca-fe-uas) encountered by the ADSL equipment.
far-end line in the current
value.
10 Far-end TCA alarm QoS Min NSA 7302 The number of errored Check the physical line.
day the ADSL far-end line in equipment.
(xtca-fe-day-es) the current one-day
threshold value.
11 Far-end TCA alarm QoS Min NSA 7302 The number of severely Check the physical line.
seconds in 1 day encountered by the ADSL equipment.
(xtca-fe-day-ses) far-end line in the current
one-day interval has
value.
12 Far-end TCA alarm QoS Min NSA 7302 The number of Check the physical line.
in 1 day encountered by the ADSL equipment.
(xtca-fe-day-uas) far-end line in the current
one-day interval has
value.
Alarm type = bonding (54); Index1 = IfIndex (of bonding group), Index2 = not used
(19 of 29)

1 Bonding group Com Min SA 7302 Group upstream actual bit Lower group upstream
upstream planned bit 7330 rate is above group planned bit rate.
rate threshold upstream minimum bit
(up-plan-bitrate) rate but below group
upstream planned bit rate.
2 Bonding group Com Min SA 7302 Group upstream actual bit Check physical line.
upstream minimum bit 7330 rate dropped below group Check line state.
rate threshold upstream minimum bit
(up-min-bitrate) rate.
3 Bonding group Com Maj SA 7302 Group upstream actual bit Check configuration data.
upstream 7330 rate is not high enough to Check physical line.
configuration not set up the configured
feasible group upstream minimum
(up-config-not-feas) bit rate.
4 Bonding group Com Min SA 7302 Group downstream actual Lower group downstream
downstream planned 7330 bit rate is above group planned bit rate.
bit rate threshold downstream minimum bit
(down-plan-bitrate) rate but below group
downstream planned bit
rate.
5 Bonding group Com Min SA 7302 Group downstream actual Check physical line.
downstream minimum 7330 bit rate dropped below Check line state.
bit rate threshold group downstream
(down-min-bitrate) minimum bit rate.
6 Bonding group Com Maj SA 7302 Group downstream actual Check configuration data.
downstream 7330 bit rate is not high enough Check physical line.
configuration not to set up the configured
feasible group downstream
(down-config-not-feas minimum bit rate.
)
7 Bonding group no Com Min SA 7302 CPE modem is not Check the modem.
peer modem detected 7330 connected to the group Check the physical lines.
(no-peer-cpe) lines.
8 Bonding group no Com Min SA 7302 Bonding CPE modem is Check the modem.
bonding CPE 7330 not connected Check the physical lines.
connected
(no-bonding-cpe)
Alarm type = authentication (55); Index1 = ifIndex of interface on which authentication occurs (for example, the bridge
port interface for 802.1x, the PPPoE interface for PPPoE), Index2 = not used
1 VRF assignment Proc Maj SA 7302 Failure to assign a VRF for Check the system
failure 7330 a user session: configuration.
(vrf-assign-fail) unknown VRF: VRF Check the RADIUS server
returned by RADIUS configuration.
server is not locally
configured in the
system; or
no VRF: RADIUS
server did not return a
VRF while no default
VRF is locally
configured for the
domain.
(20 of 29)

2 VLAN assignment Proc Maj SA 7302 Failure to assign a VLAN Check the system
failure 7330 for a user session: configuration.
(vlan-assign-fail) unknown VLAN: Check the RADIUS server
VLAN returned by configuration.
RADIUS server is not
locally configured in
the system; or
no VLAN: RADIUS
server did not return a
VLAN while no default
VRF is locally
configured for the
domain.
3 IP address pool Proc Maj SA 7302 Failure to assign an IP Check the system
assignment failure 7330 address pool: configuration.
(ip-pool-assign-fail) unknown pool-id: Check the RADIUS server
pool-id returned by the configuration.
RADIUS server is not
locally configured in
the system; or
no pool-id: no pool id
is returned by the
RADIUS server while
no pool is assigned to
the domain; or
pool administratively
locked: pool-id
returned by the
RADIUS server is
administratively
locked; or
VRF of the pool is not
consistent: this can
occur in the following
cases:
RADIUS server
returns a pool-id: VRF
of the returned pool-id
is different from the
VRF of the configured
domain
RADIUS server
returns pool-id and
VRF: VRF of the
returned pool-id is
different from the
returned VRF
(21 of 29)

4 QoS parameters Proc Maj SA 7302 Failure to assign QoS Check the system
assignment failure 7330 parameters for a user configuration.
(qos-assign-fail) session: Check the RADIUS server
unknown QoS profile: configuration.
QoS profile returned
by the RADIUS server
is not locally
configured in the
system; or
QoS parameters
syntax error: QoS
parameters returned
by the RADIUS server
contain a syntax error.
5 IP address Proc Maj SA 7302 Failure to assign IP Check the system

assignment failure 7330 address for a user configuration.
(ip-addr-assign-fail) session: Check the RADIUS server
IP address already in configuration.
use: IP address
returned by the
RADIUS server is
already allocated for
another user; or
no IP address
available: no IP
address available in
the IP address pool of
the domain or in the IP
address pool returned
by the RADIUS
server.
6 Missing attributes Proc Maj SA 7302 RADIUS server should Check the system
(missing-attributes) 7330 always specify a pool-id configuration.
when it returns a VRF. Check the RADIUS server
configuration.
Alarm type = IpoX (68); Index1 = ifIndex of IpoX interface on which session takes place, Index2 = not used
1 IP address preempt Com Maj SA 7302 A new IP session is Check IP address pool on
(ip-addr-preempt) 7330 established with a user IP DHCP server.
address previously Check local IP address
assigned to another IP pool.
session and the previous
session has lower or equal
precedence with the new
one. The previous session
is terminated and its IP
address preempted.
Alarm type = SFP (76); Index1 = ifIndex of IPoX interface on which the session takes place, Index2 = not used
1 Host SFP LOS Com Crit SA 7330 Host shelf downlink SFP Check the physical line.
(host-sfp-los) loss of signal. This alarm
applies only to a host
ARAM-D shelf.
(22 of 29)

2 Host SFP transmit fail Com Crit SA 7330 Host shelf downlink SFP Check the host shelf SFP
(host-sfp-tx-fail) transmission failure. This module.
alarm applies only to a
host ARAM-D shelf.
3 Host SFP not present Com Crit SA 7330 Host SFP missing. Host Check the host shelf SFP
(host-sfp-not-prst) shelf downlink SFP presence.
detected but later
removed. This alarm
applies only to a host
ARAM-D shelf.
4 Host SFP invalid Com Crit SA 7330 Host shelf downlink SFP Check the host shelf SFP
Alcatel-Lucent ID does not have a valid module ID.
(host-sfp-inv-id) Alcatel-Lucent ID. This
alarm applies only to a
host ARAM-D shelf.
5 Host SFP control fail Com Crit SA 7330 Host shelf downlink SFP Check the host shelf SFP
(host-sfp-ctrl-fail) control failure. This alarm module or I2C bus.
applies only to a host If control of all host shelf
ARAM-D shelf. SFPs fails, check the
GENC-E or GENC-F.
6 Host SFP unexpected Equip Min NSA 7330 The host SFP is not Check for missing host
remote LT assigned to any remote LT SFP assignment
(host-sfp-rmtlt) cards but a connection to configuration.
a remote LT card is Check if the remote LT
detected. card is cabled to the wrong
host SFP.
7 Host SFP assignment Equip Maj SA 7330 The detected slot ID of the Check for cabling error.
mismatch remote LT cabled to the Check for host SFP
(host-sfp-mismatch) host SFP does not match assignment configuration
the assigned remote LT error.
slot ID configured for that
host SFP.
8 Host SFP Equip Min NSA 7330 The actual shelf type of Check for cabling error.
incompatible shelf the remote LT cabled to Check for shelf type
(host-sfp-incompt) the host SFP does not planning error.
match the planned shelf
type of the assigned Check for assignment
remote LT configured for configuration error.
that host SFP.
Alarm type = SFP (76); Index1 = eqptSlotId of corresponding LSM in ES, Index2 = not used
11 ES SFP loss of signal Com Crit SA 7330 ES SFP loss of signal. Check the physical line.
(exp-sfp-los) This alarm applies only to
the ES.
12 ES SFP transmit fail Com Crit SA 7330 ES SFP transmission Check the ES SFP module.
(exp-sfp-tx-fail) failure. This alarm applies
only to the ES.
13 ES SFP not present Com Crit SA 7330 ES SFP missing. ES SFP Check the ES SFP
(exp-sfp-not-prst) detected but later presence.
removed. This alarm
applies only to the ES.
(23 of 29)

14 ES SFP invalid Com Crit SA 7330 ES SFP does not have a Check the ES SFP module
Alcatel-Lucent ID valid Alcatel-Lucent ID. ID.
(exp-sfp-inv-id) This alarm applies only to
the ES.
15 ES SFP control fail Com Crit SA 7330 The SFP alarm for the ES Check the ES SFP module
(exp-sfp-ctrl-fail) downlink SFP control or I2C bus.
failure. This alarm applies
only to the ES.
Alarm type = LLURelay (78); Index1 = eqptSlotId (index in equipment board table), Index2 = not used
1 Wrong applique for Com Maj SA 7302 LLU relay set for some Replace the applique by an
LLU ports, but applique applique compatible with
(llu-relay-status) inserted in slot is not the LLU relay.
compatible with LLU relay.
Alarm type = SHDSL_ISAM (82); Index1 = IfIndex (of SHDSL physical port), Index2 = linkID (higher 16 bits) + device
ID (lower 16 bits)

network side on each network side on each pair.
pair This alarm is not currently
(shdsl_n_los) supported on the system.

customer side on customer side on each
each pair pair.
(shdsl_c_los) This alarm is not currently
3 Loss of Com Min SA 7302 Loss of synchronization Check the signal on the
synchronization on word on the network side network side.
network side on each on each pair
pair
(shdsl_n_losw)
4 Loss of Com Min SA 7302 Loss of synchronization Check the signal on the
synchronization on word on the customer side customer side.
customer side on on each pair
each pair
(shdsl_c_losw)
5 Loop attenuation Com Min SA 7302 Loop attenuation alarm on Check the signal on the
alarm on network side the network side on each network side.
on each pair pair
(shdsl_n_aten)
6 Loop attenuation Com Min SA 7302 Loop attenuation alarm on Check the signal on the
alarm on customer the customer side on each customer side.
side on each pair pair
(shdsl_c_aten)
7 SNR margin alarm on Com Min SA 7302 Signal-to-noise ratio alarm Check the signal on the
network side on each on the network side on network side.
pair each pair
shdsl_n_snr)
(24 of 29)

8 SNR margin alarm on Com Min SA 7302 Signal-to-noise ratio alarm Check the signal on the
customer side on on the customer side on customer side.
each pair each pair
(shdsl_c_snr)
9 DC continuity fault on Com Min SA 7302 DC continuity fault on the Check the equipment and
network side on each network side on each pair wiring on the network side.
pair
(shdsl_n_dccont)
10 DC continuity fault on Com Min SA 7302 DC continuity fault on the Check the equipment and
customer side on customer side on each wiring on the customer
each pair pair side.
(shdsl_c_dccont)
Alarm type = CustomExternalAlarms (83); Index1 = eqptSlodId (index in equipment board table), Index2 = not used
1 Customizable Equip Maj NSA 7330 REM customizable

external alarm 1 external alarm 1
(custextalarm1)

(custextalarm2)
(custextalarm3)

(custextalarm4)

(custextalarm5)
Alarm type = PlugInUnit2 (84); Index1 = eqptSlotId (index in equipment board table), Index2 = not used
1 Fan Equip Maj NSA 7330 REM fan power alarm Check the REM fan.
(pluginfan)
2 DC A Equip Maj NSA 7330 REM DC A voltage low. Check the fuse.
(plugin-dc-a) DC B takes over. Check the cabling.
3 DC B Equip Maj NSA 7330 REM DC B voltage low. Check the fuse.
(plugin-dc-b) DC A takes over. Check the cabling.
4 Dying gasp Equip Crit SA 7330 REM dying gasp alarm. Check the following at the
(plugin-dg) REM going out of service REM and the cabinet:
due to power shutdown. cabling, fuse, temperature,
Possible causes: power on and off switch.
failure, mains switch off,
excessive over
temperature, an so on.
(25 of 29)

5 Applique power Equip Crit SA 7302 Applique power supply Check applique power
supply failure malfunction. The relays supply.
(apsf-alarm) are no longer configurable
and are switched to the
hardware default position.
6 NTR-A loss Equip Maj SA 7302 The LT card reports an Check the status of the
(ntr-a-loss) 7330 NTR loss event when the NT-A NTR.
NTR signal is not
available. An NTR-A loss
is reported even when
there is no NT unit in the
NT-A slot.
7 NTR-B loss Equip Maj SA 7302 The LT card reports an Check the status of the
(ntr-b-loss) 7330 NTR loss event when the NT-B NTR.
NTR signal is not
available. An NTR-B loss
is reported even when
there is no NT unit in the
NT-B slot.
10 Loss of signal on Equip Maj SA 7302 Loss of signal on the Check the noise level of
remote LT card 7330 downstream optical path the REM or SEM SFP.
(ds-los-or-high-attn) due to high attenuation.
The optical link is missing,
broken, or too long. This
alarm applies only to the
SEM and REM.
Alarm type = SIP User Agent (98); Index1 = sipUaId (index in SIP user agent table), Index2 = not used
1 DHCP server Com Crit SA 7302 The DHCP server is Check the link between the
unreachable 7330 unreachable for the SIP system and the DHCP
(dhcp-unreach) user agent. server.
2 SIP proxy server Com Crit SA 7302 The SIP proxy server is Check the link between the
unreachable 7330 unreachable for the SIP system and the SIP proxy
(proxy-srv-unreach) user agent. server.
3 SIP registrar server Com Crit SA 7302 The SIP registrar server is Check the link between the
unreachable 7330 unreachable for the SIP system and the SIP
(reg-srv-unreach) user agent. registrar server.
Alarm type = SIP PlugInUnit (99); Index1 = eqpSlotId (index in equipment board table), Index2 = not used
1 Invalid CDE file Proc Crit SA 7302 The CDE file in the board Contact Alcatel technical
(inval-cdefile) 7330 is invalid. This alarm is support at 1-888-252-2832
raised in the following (1-888-ALCATEC) to get a
situations: new load.
The CDE file does not
exist.
The CDE file is of
invalid format.
(26 of 29)

2 Short of resource Proc Crit SA 7302 The board is short of Wait until one of the busy
(short-res) 7330 resources for more calls. calls is terminated.
For example, if there are
24 user ports already in
conversation using G.729,
the board does not have
any resources left to
accept more calls on any
other user ports.
Alarm type = SIP Termination (100); Index1 = ifIndex (of PSTN physical port), Index2 = not used
1 Unknown SIP Com Maj SA 7302 The SIP subscriber Verify if the directory
subscriber 7330 information configured in number, the user name, or
(unknown-sub) the SIP termination does the URI of the SIP
not exist on the SIP termination is valid.
application server.
2 Ground key Equip Maj SA 7302 The current threshold of Check the cabling of the
(ground-key) 7330 the physical line of the port port.
is exceeded. The usual
root causes are:
The tip and ring are
shorted together.
The tip is connected to
the ground or to an ac
source.
The ring is connected
to a source of high
voltage or to ac.
3 Port high temperature Equip Maj SA 7302 The temperature Check the ambient
(port-hightemp) 7330 threshold on the physical temperature.
PSTN port is exceeded. Check the operation of the
The port is automatically fans.
shut down.
Check the port.
Alarm type = NonAlcateldev (104); Index1 = not used, Index2 = not used
1 No environment box Equip Crit NSA 7302 The environment box Verify if there is an
(loss_env_mon) 7330 does not exist or is not environment box.
alive.
Alarm type = FileTransfer (105); Index1 = file server ID (IP address), Index2 = not used
1 File server Com Maj NSA 7302 The system is not able to Check if the file transfer
unavailable 7330 connect to the file server server is correctly
(fileserv-unavailable) for a file transfer. configured.
Check the network-to-file
transfer server.
Alarm type = TrafficOverflow (106); Index1 = eqptSlotId (index in NT equipment board table), Index2 = not used
1 LT load overflow QoS Min SA 7302 LT load overflow Check the LT load.
(fanout) 7330
(27 of 29)

2 Upstream load QoS Min SA 7302 Upstream load overflow Check the LT load in
overflow 7330 upstream.
(up-overflow)
3 Upstream load to QoS Min SA 7302 Upstream load to OBC Check the LT load to OBC
OBC overflow 7330 overflow in upstream.
(upobc-overflow)
4 Downstream load to QoS Min SA 7302 Downstream load to OBC Check the LT load to OBC
OBC overflow 7330 overflow in downstream.
(dwobc-overflow)
5 Downstream load QoS Min SA 7302 Downstream load Check the LT load in
overflow 7330 overflow downstream.
(dw-overflow)
6 BE and CF packets QoS Min SA 7302 The number of BE and CF Check the voice and video
dropped exceeds 7330 packets dropped exceeds loads.
threshold the threshold.
(lwpri-overflow)
Alarm type = EthTca (107); Index1 = ifIndex (of Ethernet interface), Index2 = not used
1 LOS errors QoS Min NSA 7302 The number of LOS errors Check the physical line.
encountered in 7330 encountered by the Check the modem
current 15-min Ethernet interface in the equipment.
interval has reached current 15-minute interval
threshold value has reached its threshold
(etca-los) value.
2 FCS errors QoS Min NSA 7302 The number of FCS errors Check the physical line.
current 15-min Ethernet interface in the equipment.
interval has reached current 15-minute interval
threshold value has reached its threshold
(etca-fcs) value.
3 LOS errors QoS Min NSA 7302 The number of LOS errors Check the physical line.
current 1-day interval Ethernet interface in the equipment.
has reached threshold current one-day interval
value has reached its threshold
(etca-day-los) value.
4 FCS errors QoS Min NSA 7302 The number of FCS errors Check the physical line.
current 1-day interval Ethernet interface in the equipment.
has reached threshold current one-day interval
value has reached its threshold
(etca-day-fcs) value.
Alarm type = EthSFP (108); Index1 = ifIndex (of Ethernet interface), Index2 = not used
1 Ethernet SFP LOS Com Min SA 7302 User SFP loss of signal Check the physical line.
(user-sfp-los) 7330
2 Ethernet SFP transmit Com Min SA 7302 User SFP transmission Check the SFP module.
fail (user-sfp-tx-fail) 7330 failure
(28 of 29)

3 Ethernet SFP not Com Min SA 7302 User SFP is not detected. Check if the SFP is
present 7330 present.
(user-sfp-not-prst)
4 Ethernet SFP invalid Com Min SA 7302 User SFP does not have a Check the module ID of the
Alcatel-Lucent ID 7330 valid Alcatel-Lucent ID. SFP.
(user-sfp-inv-id)
Alarm type = L2Forward (109); Index1 = ifIndex (of bridge port), Index2 = see specific alarm number
1 Duplicate MAC Com Min SA 7302 Duplicate MAC address No special repair action
address 7330 on the bridge port required. Open or close the
(dupadr) indicated by index1. The conflicted port manually if
bridge port with the next needed.
MAC address is causing
the conflict.
Index2 = Layer 2
forwarder ID (VLAN ID)
Alarm type = QueueCounter (112); Index1 = ifIndex (of physical line), Index2 = queue index
1 Packets dropped by QoS Min SA 7302 The number of packets Check the corresponding
queue exceed 7330 dropped by the queue queue load.
threshold exceeds the threshold.
(queue-drop)
2 Queue load exceeds QoS Min SA 7302 The queue load exceeds Check the corresponding
threshold 7330 the threshold. queue load.
(queue-load)
(29 of 29)
Notes
(1) No rack shutdown occurs on an ARAM-D shelf that has the following PWIO-B cards installed: 3FE 24323 AC or
3FE 24323 AD.
Table TAP 104-2: SHub alarm definitions for the 7302 ISAM and the 7330 ISAM FTTN

Alarm type: LANX (51); Index1 = not used, Index2 = not used
0 No defects
1 SHub fan failure Eqp Maj NSA SHub fan failure.

(fan) This alarm is not currently
2 SHub power fan Eqp Maj NSA SHub power fan failure.
failure This alarm is not currently
(power-fan) supported on the system.
(1 of 4)

3 SHub database Eqp Maj SA 7302 The SHub database Check local flash.
restore 7330 restore has failed. Check remote file system.
(db-restore) Check availability of MIB
database.
4 Emergency reboot Eqp Maj NSA 7302 The SHub has rebooted Check local flash.
(reboot) 7330 from the emergency boot Check remote file system.
package.
Check availability of
software package.
5 SHub SNTP Eqp Maj NSA 7302 SHub SNTP Check SNTP server.
Communication Lost 7330 communication lost. The
(sntp-comm) SNTP server does not
respond to the requested
messages from the SHub.
6 No ARP reply Com Maj SA 7302 An ARP request has been Check existence of
received for next IP 7330 sent for a statistically configured Nexthop.
hop configured next hop, but Check connection with
(no-arp-reply) no ARP reply has been configured Nexthop.
received in the specified
time interval.
Index1 = VRF ID
Index2 = IP address of
next hop
Alarm type = ethLanx (52); Index1 = port identification of SHub Ethernet port, Index2 = see specific alarm number
0 No defects
1 Ethernet link down Com Crit SA 7302 The Ethernet link is down. Check the Ethernet link.
(ether-link-down) 7330 Index2 = not used.
2 Ethernet frame QoS Min SA The Ethernet frame has
discarded been discarded due to
buffer overflow.
Index2 = not used
3 SHub MAC conflict COM Min SA 7302 Duplicate MAC address No special repair action
(mac-conflict) 7330 from Ethernet port of LAN required. The conflict MAC
switch. address can be manually
Index1 = port with the later prohibited or permitted if
coming MAC address that needed.
causes conflict.
Index2 = VLAN ID of
domain on which the
conflict happened.
(2 of 4)

4 SHub MAC learning Com Min SA The MAC address cannot

be learned, because it is
learned on a high-priority
Ethernet port of the LAN
switch.
Index1 = the port with the
lower priority
Index2 = VLAN ID (the
VLAN domain on which
the conflict occurred)
Alarm type = OSPF (69); Index1 = VRF-ID (VRF unique ID), Index2 = see specific alarm number
0 No defects
1 OSPF interface Com Min NSA 7302 Received a packet with: Check the configuration of
configuration error 7330 OSPF version the OSPF and OSPF
(ospf-itf-err) mismatch interface.
area mismatch (area Check the configuration on
ID or subnet ID not the IP interface.
matching) Check the OSPF hello
netmask mismatch packets received on the
hello interval OSPF interface.
mismatch
dead interval
mismatch
options mismatch
Index2 = interface index

2 OSPF interface Com Min NSA 7302 Received a packet with: Check the authentication
authentication error 7330 authentication type type and password
(ospf-auth-err) mismatch configured on the OSPF
area and the OSPF
authentication failure interface.
Index2 = interface index Check the authentication
time range.
3 OSPF interface Com Crit SA 7302 Received a packet that Check the connection
received bad packet 7330 cannot be parsed. between the RIP interface
(ospf-rx-bad-err) Index2 = interface index and the cable.
4 OSPF LSDB Com Maj NSA 7302 The external LSA Do not input external
approaching overflow 7330 database has reached routes anymore, except for
(ospf-lsdb-oflow-90) 90% of the external LSA major external network
limit. routes.
Index2 = LSDB limit Configure the OSPF area
(percentage utilized) as a stub area if possible.
5 OSPF LSDB overflow Com Maj NSA 7302 The external LSA count Remove some external
(ospf-lsdb-oflow) 7330 has reached the external routes in the OSPF
LSA overflow limit. domain.
Index2 = LSDB limit Configure the OSPF area
(percentage used) as a stub area if possible.
Only input major external
network routes.
(3 of 4)

6 OSPF neighbor state Com Min SA 7302 An OSPF neighbor Check the OSPF neighbor
change 7330 connection is newly table.
(ospf-nhbr-statchg) established or dismantled. If the neighbor is
Index2 = interface index established correctly,
(interface on which the the situation is normal.
neighbor was learned) If the neighbor is down
unexpectedly, check
the OSPF process
status or the
interface-related
parameters.
7 OSPF interface state Com Min SA 7302 The OSPF interface status No special repair action
change 7330 has changed (the DR or required. Check and
(ospf-itf-statchg) BDR may have been modify the OSPF interface
changed according to this parameters if desired to
OSPF interface). change the OSPF interface
Index2 = interface index status.
(interface on which the
neighbor was learned)
Alarm type = RIP (70); Index1 = VRF ID (VRF unique ID), Index2 = interface index
0 No defects
1 RIP interface Com Min SA 7302 Received a packet with: Check the configuration of
configuration error 7330 RIP version mismatch the RIP send and receive
version.
(rip-config-err) netmask mismatch
Check the configuration of
the IP interface.
Check the RIP request and
update packets received
on the interface.
2 RIP interface Com Min SA 7302 Received a packet with: Check the authentication
authentication error 7330 authentication type type and password
(rip-auth-fail) mismatch configuration of the RIP
interface.
authentication failure
Check the authentication
time range.
3 RIP interface received Com Min SA 7302 Received a packet that Check the connection
bad packet 7330 cannot be parsed between the RIP interface
(rip-rcv-bad-pkt) and the cable.
Alarm type = LANXuplinkgroup (75); Index1 = uplink group number, Index2 = not used
0 No defects
1 SHub uplink group Equip Maj NSA 7302 The SHub uplink group is Check the SHub uplink
down 7330 down. group.
(uplink-down)
(4 of 4)
Training (TNG)
TNG 100 Service installation
TNG 101 QoS configuration
TNG 102 IGMP and multicast configuration
TNG 103 VBAS
TNG 104 DHCP relay agent configuration
TNG 105 Overall software packages
TNG 106 Specifying 7330 ISAM FTTN remote expansion units using the
CLI
TNG 107 VDSLx parameters
TNG 108 SHDSL parameters
TNG 109 Performance management counters
TNG 110 Configuration examples
TNG 111 7330 ISAM FTTN ES configuration
TNG 113 Multi-ADSL parameters
TNG 114 DLP configuration examples
TNG 115 Slot numbering schemes
General Information
This TNG provides information on:
Forwarding Modes
Dynamic MAC Learning and Static Unicast MAC Addresses
MAC Learning Rules
MAC Learning on SHub and LT board (LIMs)
MAC Learning and Unicast Configuration
SHub MAC Filters
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 TNG 100-1
Forwarding Modes
The system has the following forwarding modes:
Intelligent bridging VLAN (iBridge VLAN):

In this mode, several User Logical Ports (ULPs) can be associated with a single
VLAN.
The following applies (see Figure TNG 100-1):
1 VLAN per ISAM
1 IP subnet per ISAM
Complex IP address space management, complexity reinforced by static IP
subnet provisioning
Cross-connect VLAN:
In this mode, only one ULP can be associated with a VLAN. In this VLAN, MAC
learning is disabled.
There are several VLAN cross-connect models supported:
Basic VLAN cross-connect: C-VLAN cross-connect
VLAN stacking for business users: S-VLAN cross-connect
VLAN stacking for residential users: S-VLAN/C-VLAN cross-connect
QoS aware VLAN cross-connect: VLAN + p-bits cross-connect
Layer 2 termination:
In this mode, you can configure the system to use Point-to-Point Protocol over
Ethernet (PPPoE).
PPPoAoE Relay
IPoA/IPoE Forwarding:
In this mode, the NE can be seen as an IP-aware bridge without being as an IP
next-hop. Users connected to the NE are seen as being directly attached to the edge
router IP interfaces.
1 VLAN for all ISAMs
1 IP subnet for all ISAMs
One single IP pool: IP addresses distributed at random over the whole access
network
IPoA/IPoE Routing:
In this mode, the NE is seen as an IP next-hop on the IP path towards the users. A
single Virtual Router (VR) can be configured in this mode, which can co-exist in the
same system with a number of VRs that are configured in IP-aware bridge mode.
1 VLAN for all ISAMs
1 IP subnet per ISAMs
Complex IP address space management but some automation possible through
routing protocols
TNG 100-2 June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Figure TNG 100-1: Intelligent Bridging

Edge EMAN ISAM CPE
I-Bridge
VRF Bridge
I-Bridge
IP subnet IP address
Figure TNG 100-2: IP Routing
Edge EMAN ISAM CPE
IP
Router
VRF Bridge
IP
Router
Figure TNG 100-3: IP Forwarding
Edge EMAN ISAM CPE
IP
Fwder
VRF Bridge
IP
Fwder
Deleting a VLAN on the LT board is impossible unless all egress ports have been
removed from the VLAN. There is no such restriction for the SHub.
Dynamic MAC Learning and Static Unicast MAC Addresses

The system provides standard Layer 2 MAC learning functionality. MAC address learning
and configuring is done independently on the SHub and LT board (LIM), as is MAC aging.
The system also supports static unicast MAC addresses on user logical ports, network
(trunk) ports, cascade (trunk) ports, and user Ethernet ports. MAC learning and
configuring are governed by secure MAC learning rules.
MAC Learning Rules

Different port types have different priorities for learning. The order of priority for learning
(lowest to highest) is:
ASAM/USER/SUBTENDING - NETWORK - CONTROL
This means that learning an address on a control port takes higher priority than any other
port. Similarly, NETWORK ports have a higher precedence than ASAM, USER, and
SUBTENDING ports. ASAM, USER, and SUBTENDING ports have the same priority.
Example:
1 MAC 'X' is learned on ASAM port. If packets with the same MAC address appear later
on the control port, then MAC 'X' is learned on the control port and the same entry is
removed from the ASAM port.
2 MAC 'X' is learned on ASAM port 1. If packets with same MAC address appear on
the USER port, then if MAC movement is enabled for the VLAN, the MAC address is
learned on the USER port. Otherwise, a duplicate alarm is raised and that particular
stream is discarded on the USER port.
A duplicate MAC alarm is raised whenever there is a MAC conflict between same-priority
ports, except when the two ports in question are network ports. This is because MAC
movement is by default enabled on network ports. Also, a duplicate MAC alarm is raised
when a lower-priority port tries to learn a MAC address in case a MAC address has
already been learned on any higher priority port. When the duplicate alarm is raised,
traffic with the same MAC address is blocked on the second port. The alarm is cleared
when the MAC address ages out on the first port.
Duplicate MAC alarms will not be raised when MAC movement is enabled. The MAC
address will always be learned on the port where the packet arrives. If a dynamic MAC
entry already exists on an other port, it is removed before learning the new MAC address
on that port.
MAC Learning on SHub and LT board (LIMs)

There are some differences as well as some similarities between MAC learning on the
SHub and MAC learning on a LIM in the LT board. Table TNG 100-1 compares the SHub
with the LT board.
Table TNG 100-1: MAC learning: SHub versus LT board
SHub LT board (LIM)
MAC learning cannot be disabled MAC address learning can be disabled or

enabled on an ASAM LIM. MAC address learning
is disabled on a LIM in CC-VLAN mode.
Maximum number of MAC addresses that can be Maximum number of MAC addresses that can be
learned on SHub is 16384. Once the maximum learned on a LIM is 1024.
limit is reached new addresses are not learned
and the packets are discarded.
Secure MAC learning rules are applicable to NA

different port types
Static MAC address can be configured. There is Static MAC address can be configured
a limit of 25 static MAC entries.
Default aging time: 300 s Default aging time: 300 s
Aging time range: 10 to 1000000 s Aging time range: 10 to 1000000 s
MAC Learning and Unicast Configuration
Static MAC addresses can be configured per VLAN on both the Shub and LIMs. The
egress port for a particular MAC address is specified by these static MAC entries. Unlike
dynamically learned MAC entries, static addresses can be configured to be permanent.
When configuring a static unicast MAC address for a port, the system removes the old
entry if the MAC address has been learned as a dynamic one in any port within the same
VLAN. The system then either accepts or rejects this configuration. It rejects the
configuration if the MAC address has been configured as a static one on another port
within the same VLAN or the port is not in a valid VLAN.
If the number of MAC addresses learned or configured has reached the limit, then one
dynamic entry is removed from the database when configuring a new static entry.
A duplicate MAC alarm is raised when a packet with the same MAC address as a
statically configured one on another port is encountered. The static entry is retained while
the dynamic entry is discarded.
SHub MAC Filters
The system supports global MAC filters. These filters are supported in the SHub. There
are no filters supported per user logical port. The system provides facilities to configure
MAC address filtering based on destination MAC address, source MAC address, or both
source MAC address and destination MAC address. The filter action is either Drop or
Allow on packet match.
Introduction
The Alcatel-Lucent ISAM (7302 ISAM, 7330 ISAM FTTN) as an access concentrator
provides sophisticated means for enforcing subscriber SLAs, protect network resources,
prevent service theft and impose security policies.
This application note helps to understand the Alcatel-Lucent ISAM QoS policies and to
choose the appropriate set of functionalities to support your deployment scenario.
This application note presents the concepts and functions behind the Alcatel-Lucent 7302
ISAM and 7330 ISAM FTTN QoS Session and related profiles. First the main concepts
are explained, followed by relatively simple step-by-step examples. This document
explains the following concepts:
Service Access Point and logical flow type

QoS Session profile
QoS Policer profile
QoS Marker profile
QoS Policy framework
L2 and L3 filters
Policy Action profiles
Service Access Points

In a traditional ATM-based DSLAM the logical subscriber interface used to be typically an
ATM VC. On the DSLAM the combination of subscriber DSL interface and the VPI/VCI
numbers uniquely identified the service. On the BRAS the VPI/VCI numbers were the
sole identifiers of the subscriber and the service. This model is still true in some network
deployment cases, but the possibilities are proliferating.
In general, the entity that identifies a subscriber interface (a logical flow) is called a
Service Access Point (SAP).
On the ISAM a subscriber interface can be:
a DSL interface
an ATM PVC on a DSL interface
a PPPoE session
a VLAN
an IP interface
The basic paradigm of subscriber SLA enforcement revolves around applying the correct
policies to the subscriber SAP. Therefore, the solution is to attach QoS rules to such
SAPs.
QoS Session Profile

The typical way of approaching residential customers is to offer a small set of service
plans from which subscribers can choose, rather than negotiating a deal per subscriber.
Therefore a convenient way to configure subscriber policies is via reusable profiles.
The main building block of subscriber QoS policies is the QoS Session profile.
In principle one such Session profile is required per service. When configuring a new
subscriber, it is sufficient to name the appropriate QoS Session profile that applies to the
SAP of the customer, and all settings are automatically populated in hardware. This not
only provides for fast configuration, but also reduces the chances of erroneous
configuration.
Contents of the Session Profile

The QoS Session profile contains settings related to rate enforcement, marking, filtering
and basic ACL. More concretely, a QoS Session profile is made of (see Figure TNG
101-1):
1 a logical flow type

2 two policer profiles (upstream, downstream)
3 one marker profile (for upstream)
4 two lists of sub-flow based policies.
Figure TNG 101-1: QoS Session Profile Structure
QoS Session Profile
Logical Flow QoS Policer QoS Policer QoS Marker Qos Policy Qos Policy
Type Profile Up Profile Down Profile Up List Up List Down
In general a profile that is a component of a session profile cannot be modified while it is

associated to a Session profile. However, a Policer and Marker profile referenced in a
Session profile can be changed while the Session profile is in use, and settings will be
automatically replicated to the live SAPs.
Other profiles that are not session-related (buffer acceptance, scheduler, connection
admission control) can be modified while in use, but not deleted.
The Logical Flow Type

The Logical Flow Type parameter determines the user interface encapsulation type and
forwarding mode. This parameter is important for consistency reasons to parse the
supported parameters that can be added, as well as to make sure that the policy can only
be applied to the SAP type for which it was intended.
The Logical Flow Type parameter is mandatory at profile creation time and cannot be
changed later. Therefore it is important to know in advance the logical flow type of the
forwarding mode for which the session profile is prepared.
Table TNG 101-1 lists the supported logical flow types.
Table TNG 101-1: Logical Flow Types
Logical Flow Supported Supported Remarks

Type Markers Filters
Generic all L2, L3 May be used for all logical flow types,
mainly for test purposes. The system
will silently ignore unsupported
contents from this profile.
PVC all (L2, L3) Designates all frames on a PVC. In

case sub-flow policies need to be
used, it is recommended to use one of
the specific logical flow types for the
forwarding mode rather than PVC,
since unsupported filters will be
ignored silently. This logical flow type
passes also for the default bridge port
of an EFM line.
802.1x session all - Designates all frames on a bridge port

that was opened via 802.1x
authentication
PVC.VLAN all L2, L3 This flow type is used to apply policies

(for cross-connect on a certain VLAN for tagged frames
from the subscriber side. Often the
mode only) PVC on ATM-based DSL flavors
represents a bridge port. However this
logical flow type can also be used on
EFM DSL ports, where the PVC
represents the sole bridge port
supported on top of EFM lines.
PPP all L3 ISAM terminated PPP sessions can

use this flow type
IP all L3 Designates frames on an IP interface.

This can be used for both IPoE and
IPoA IP-aware bridges.
(1 of 2)
Logical Flow Supported Supported Remarks

Type Markers Filters
IPoE VLAN CC all L2, L3 All frames on a bridge port that is

configured in VLAN CC mode and
carries IPoE frames. It is important to
distinguish among encapsulation
types of the same forwarding mode for
being able to determine the supported
filters. This flow type supports both L2
and L3 filters.
PPPoE VLAN CC single dot1p L2 A cross-connect mode that transports

PPP encapsulated frames.
PPPoA CC single dot1p - All frames on a PVC where PPPoATM

encapsulation is used and is
cross-connected to a VLAN.
IPoE IBridge all L2, L3 All frames on a subscriber-side

IBridge port, where encapsulation
mode is IPoE.
PPPoE IBridge single dot1p L2 All frames on a subscriber-side

IBridge port, where encapsulation
mode is PPPoE.
PPPoA relay single dot1p - Designates all frames on a PVC that
uses PPPoA encapsulation but the
PPP session is terminated in a central
BRAS, therefore PPP packets are
relayed with 802.1q encapsulation.
IPoE IP-aware all L3 All frames on an IP-aware bridge
Bridge subscriber interface, using IPoE
encapsulation
IPoA IP-aware all L3 All frames on an IP-aware bridge

Bridge subscriber interface, using IP
encapsulation directly over ATM.
(2 of 2)
To create a QoS Session profile via CLI, use the following command:
> configure qos profile session <qosSessionProfileName> log-flow-type

<flowType>
QoS Policer Profile

The Policer profile contains information regarding the parameters of a policer resource.
To date the Single Token Bucket policer is supported with two parameters:
Committed Information Rate (CIR): designates the token accumulation rate in Kbit/s
Committed Burst Size (CBS): designates the maximum token count in the bucket
A Policer profile can be referenced by a Session profile in both upstream and

downstream direction, and can be reused by many Session profiles. For instance, a
Policer profile created for a Voice over IP connection is likely to be reusable both
upstream and downstream in many Session profiles that allow the user a VoIP
connection.
A Policer profile cannot be changed while in use (i.e., while it is associated to at least one
Session Profile). However, in a Session profile the referenced Policer profile can be
replaced by another one, even while the Session profile is in use (i.e., is instantiated in
hardware on SAPs). This allows seamless service upgrades in the field.
If there is at least one policer profile on the SAP level, it is not possible to remove it while
the Session profile is in use. This is due to policer inheritance. Similarly, if previously there
was no policer profile at all, then while the Session profile is in use it cannot be added to
the Session profile. It is possible however, to add a second policer or to remove one when
previously there were two.
Note 1 The big tolerance for small rate is caused by unit conversion.
The CIR unit in NP is KBytes, so integers are accepted. Values are
rounded up. As such, any roundup value will have a tolerance of
0.00000...01 to 0.9999...9 KBytes, which is obvious for small rate.
Example: take a CIR of 10 Kbit. This corresponds to 1.25 KB (=10/8). The

roundup value becomes to 2 KB in NP.
The actual result is 8 x 2KB = 16Kbits. This matches the actual CIR value
in NP.
For other CIR values: see Table TNG 101-2.
Note 2 Due to the same reasons, the policer works with an error of
about 15% for 64B Ethernet frames, both in upstream as in downstream
direction; see Table TNG 101-3.
Table TNG 101-2: Upstream Policer Characterization
CIR CBS Result CIR in HW Description
10K 1600 16K 16K Big tolerance due to SW conversion

100K 1600 104K 102K
300K 1600 305K 297K
500K 1600 506K 492K
800K 1600 690K 781K Rate limited by modem in upstream
Table TNG 101-3: Illustration Policer Error
Packet length DS US
no policer policer no policer policer
64 435 345 544 323
128 409 314 512 314
256 409 309 614 309
512 409 306 819 306
1024 819 305 491 305
1280 1023 304 614 303

1518 1214 304 729 304
Values in the table above are for a policer with committed-info-rate 300 and committed-burst-size 1600
To create a QoS policer profile, use the following command:
> configure qos profile policer <policerProfileName>

committed-info-rate <CIR_Kbps> committedburst-size <CBS_bytes>
QoS Marker Profile

The Marker profile contains upstream marking configuration settings for the SAP. Since
various encapsulation modes exist, the Marker profile itself is rather complex. Please
note that under normal circumstances only a very small subset of the offered functionality
is required in a certain deployment scenario.
Basic concepts
Port default code point:

all frames of a certain SAP get the same upstream code point (P-bits or DSCP)
regardless of the incoming value.
Alignment:
process of setting a code point based on another code point (typically setting P-bits
according to the DSCP).
Contract table:
a table that marks a code point based on the incoming value of the same code point.
This is a 8x2 table for P-bits and 64x2 table for DSCP. Note that P-bit re-marking table
is outside from the Marker profile, and can be configured on bridge ports that accept
tagged frames.
Trusted port:
a subscriber SAP where ingress code points (P-bits or DSCP) are accepted as they
are received.
In principle there is always a dominant entity that determines the code points to be
applied on a frame. Such entities are for example: a parent bridge port, port default VLAN,
ingress DSCP, ingress P-bits, or other header information (see marking based on
sub-flow policies 4.7). One notable exception is when the port is trusted. For trusted ports
received frames will keep their DSCP and P-bits, and un-tagged frames will get code
point P=0 in the 802.1q header.
Note that a port default P-bit marking can be configured on bridge ports even in the
absence of a QoS Session profile. The convention is that the QoS Session profile
provided it contains a marker for P-bits has precedence over a bridge port-based
default. Also note, that there is a system-wide switch that determines whether code points
are derived from bridge-port default settings or are VLAN-based.
> configure vlan priority-policy <vlan-specific | port-default>
Last, setting the DSCP is not supported for non-IP packets (including when IP packets
are bridged with PPP-encapsulation). For such packets, the set-DSCP rule is
automatically skipped.
Marker Profile Structure

The Marker profile contains a marker type, port default P-bits, DSCP, DSCP contract
table and DSCP-to-P-bits alignment flag. Figure TNG 101-2 shows the marker profile
structure.
Figure TNG 101-2: Marker Profile Structure
QoS Marker Profile
Marker Type
Default P-bits
DSCP
DSCP Contract
Table
DSCP-to-P-bits
Alignment Table
The Marker type determines which of the following parameters apply.

The port default P-bits enforces a given P-bit setting to all frames that emerge from
the subscriber, and overwrites bridge-port-based defaults.
The DSCP works similarly. Note that setting the DSCP is only supported for PPP
termination, IPoA and IPoE frames. If the forwarding mode is bridging and the packet
is PPPoE encapsulated, then setting the DSCP is not supported. It is however
supported for bridged IPoE packets.
The DSCP contract table maps incoming DSCP values to outgoing DSCP values. It
is possible to map multiple incoming DSCP values to a singe outgoing DSCP value.
The DSCP-to-P-bits alignment table on the subscriber side is unique system-wide
and resides outside the QoS Marker profile. Not to be confused by a similar function
on the SHub that can be applied on ISAM network interfaces and is configurable
independently. The Marker profile contains only a flag that enables this alignment for
upstream subscriber-originated frames or not.
Table TNG 101-4 shows the supported marker types.
Table TNG 101-4: Supported Marker Types
Marker Type P-bits DSCP DSCP Alignment Comments

Contract Flag
Table
singleDot1P Y - - - Sets a single P-bit for

upstream frames on the
SAP. Recommended
marker type for bridged
mono-QoS SAPs.
singleDscp - Y - Y Sets a single DSCP value

for upstream frames.
Alignment is optional.
dscpContract - - Y Y Allows a set of DSCP

values based on incoming
DSCP values. The contract
table can enforce that only
the agreed sub-set of code
points passes by. Use
DSCP-to-P-bits alignment
to set in a subsequent step
the P-bits based on the
altered DSCP value.
dot1PandDscp Y Y - - Sets a single DSCP and

P-bit for all upstream
frames of a SAP.
Recommended marker for
mono-QoS routed SAPs or
IPoE CC.
dot1PandDscp Y - Y - This marker type allows

Contract enforcing a permitted set of
DSCP values to be used in
a later part of the network.
In the access part a single
P-bit code point is set and
used.
dscpToDot1P - - - Y Accepts incoming DSCP

Alignment values and set P-bits
accordingly, to be used in
the L2-part of the access
network.
In general, a code point can suffer multiple alterations, but this is not the purpose. P-bits
can be set port-based, then altered in the policy processor block. Also, P-bits specified
by the policy processor could be altered by the alignment. This is not the intention.
The intention is to set either both code points in one shot according to the determining
entity (like parent port) or mark the incoming DSCP with a contract table and align P-bits
to it. The complex things are there not to be used for simple cases, but to suit the needs
of special deployment scenarios.
QoS Policy Framework

The QoS Sub-flow Policy is used to provide special treatment to selected flows from
within a SAP. In general rate limitation and marking can and should be done on the SAP
level. However, in some cases multiple applications that demand differentiated treatment
are deployed over the same SAP. Therefore, the solution is to isolate these flows via a
filter and apply special treatment on the flow, like permit/deny, marking or rate limitation.
A policy is made of a filter and an associated set of actions.
Policies also have a precedence value, which allows ordering them in the service access
point, in case some of the filters define overlapping sets of the flows. 255 priority levels
are supported. A defined policy can be reused in many QoS Session profiles. The policy
will always use the same precedence within all Session profiles, since the precedence is
an attribute of the policy. Policies with unspecified precedence get precedence 10 (0
lowest, 255 highest). Policies with the same precedence will get instantiated in hardware
with random ordering, therefore it is good practice to use correct precedence levels for
policies that can be potentially conflicting.
The rule is that within a session, the first filtering match will carry out the associated
actions on the packet, and no other sub-flow policies are checked.
L2 and L3 Filters
L2 and L3 filters are stored as profiles, and are reusable in both upstream and
downstream direction. Filters are multi-field classifiers. In other words, they contain a set
of protocol headers, where each can be enabled or ignored or partially masked. However,
the total evaluation of the fields is an AND function. Therefore a full-match is required.
When an OR function is desired, several sub-flow policies can be used to achieve the
desired behavior (see Policy Sharing).
Figure TNG 101-3: L2 and L3 Filter Structure
L2 Filter L3 Filter
MAC Destination Address Address Type
MAC DA Prefix IP Destination Address
MAC Source Address IP DA Prefix
MAC SA Prefix IP Source Address
Ethertype IP SA Prefix
P-bits DSCP
CFI bit Protocol Type
VLAN ID Destination Port Range
Source Port Range
MAC address prefixes in L2 filters can be used for ACL functionality, for instance to
specify a certain category of access boxes (like a residential gateway or STB of a certain
type from a specific vendor). To specify a L2 policy that applies for all ingress frames,
mask out the complete source or destination MAC address.
L3 filters presently do not support IPv6 addresses.
Ranges of TCP and UDP ports are supported, which is a more convenient way for
specifying L3+ policies than port masks.
Note that protocol extraction, IP and MAC anti-spoofing and blocking special Ether-types
happens before the policy processor block. Therefore, QoS filters cannot be used to
disable the reception of certain protocols. They can be used to block certain protocols
from being transmitted further to the network that are not extracted and treated by the
ISAM control-plane processors. Filters look to potentially modified fields (such as VLAN
ID, P-bits, DSCP) since the policy processor is located after the L2, L3 engines and the
port-based marker block.
The supported filter type (L2 or L3) depends on the SAP forwarding and encapsulation
mode (see Table 1). The ISAM policy processor will forbid non-supported configurations
already at the moment when a policy is attached to a session profile. For instance an
IPoA virtual router SAP will not support a L2 filter since there is no incoming Ethernet
header. Even if there was like the case of IPoE VR we still dont support L2 filters due
to the fact that the L2 header is replaced by the L3 forwarding engine. Presently L2 filters
are supported for the VLAN cross-connect mode. L2 and L3 filters can be used in the
same Session profile if the flow type allows it.
Policy Action Profiles

Policy actions also stored as reusable profiles are grouping a set of nonconflicting
actions that can be attached to a policy. These actions are: pass/discard packet, set
P-bits, set DSCP, police sub-flow with a certain policer and policy sharing.
Figure TNG 101-4: Policy Action Profile
Policy Action
Default Disposition
Set DSCP
Set P-bits
Police
Sharing
The default disposition is a simple permit/deny statement. The deny statement is

provided for building ACLs. By default the disposition is pass.
Setting P-bits on the policy-level is supported for all forwarding modes, since upstream
all packets will be tagged. However, setting P-bits in the downstream direction is still not
useless in case frames are forwarded to subscribers downstream. An altered P-bit for
internal purposes can be used to modify the scheduling priority of a downstream packet.
This feature is useful to pull out a selected sub-flow (like VoD control traffic) from a
best-effort aggregate into the controlled-load queue.
Setting the DSCP is only supported for IP frames (which includes terminated PPP
sessions, since the system does have an IP interface at hand). Setting DSCP is not
supported for bridged PPP traffic, as well as for SAPs at layer 2 that are not yet supported
by the policy framework.
Policing a certain sub-flow means that the selected traffic is not subject to the port-level
policer. Therefore is a SAP has a port policer of 1Mbps and two sub-flow policies of
100Kbps, then the total traffic that can pass is 1.2Mbps. However, if the sub-flow policy
does not contain policing, then the frame is subject to the port policer. This concept is
some times referred as policer inheritance, which applies also across service access
points that are on top of each other (like PPP sessions over a bridge port). Marking and
sub-flow policies are not inherited across SAPs.
Policy Sharing
There are cases when a certain policy should apply to a set of micro-flows within a SAP
that is difficult or impossible to capture with one filter. If this is the case when the policy
is to apply an upper bound on the bandwidth to be used in common by such micro-flows,
then policy sharing comes to help.
Basically, policy sharing if enabled will cause the policies within a QoS Session profile
that use the same Policy Action profile in the same direction more than once to share the
instantiated policer. This way a common upper bound is placed on the rate of a set of
ingress flows. It makes no sense to use policy sharing if no policer is named inside the
policy action profile.
The Complete Marking Pipeline

Now that we introduced the policy framework, we can give the complete chain of policy
decision points that may come into the picture for marking. We also give an overview
which policy decision point gets its settings from where.
Figure TNG 101-5: Sequence of Policy decision Points for Upstream Marking
May come from:
1. Bridge port default
Global Table QoS Marker profile QoS Marker profile 2. VLAN default
3. QoS Session Profile
Marker
DSCP to Set P and Port default Port default

P-bits DSCP for DSCP Yes, P-bits
alignment Yes subflow if Yes port No
specified default
No, (2) Yes, (1)
Alignment Filter trusted DSCP trusted Tagged?
enabled? match? set?
Yes,
(3) DSCP Yes, untrusted
(4) P-bit contract
contract contract
table
table
QoS Marker profile QoS Session profile Choose from factory
Policy List QoS Marker profile defaults
No QoS Marker
involvement
As mentioned earlier, in a typical deployment scenario only a small fraction of all this is
needed. For instance, it is rather common to set only a port default P-bit value.
Downstream marking is typically not done in the DSLAM. The ISAM can do downstream
P-bit and DSCP modification via the policy processors, but there are no explicit means to
do session-based downstream marking. If for some reason this is required, a
downstream generic filter has to be defined with action to modify the desired code point
to the desired value.
Policy Decision Point (1)

Policy decision point (1) deals with the SAP-based P-bit marking. We distinguish 3 cases:
1 untagged frames from user, where a port default P-bit is always applied
2 tagged or priority tagged frames, where subscriber marking is trusted
3 tagged or priority tagged frames where correct P-bit marking is enforced via a P-bit
contract table.
Port default P-bits can be configured also without a QoS profile, simply by configuring a
P-bit on the bridge port level or using VLAN-based defaults. In case a QoS Session profile
is attached that contains P-bit settings, this latter will overwrite port or VLA-based
defaults.
P-bit contract table is not yet possible to specify within a QoS marker profile, and only
possible to configure on top of bridge ports (so no IP interfaces).

Policy decision point (2) is very similar to (1). Settings for this policy decision point can
only come from a Marker profile, therefore the use of a QoS Session profile is mandatory.
In principle the first two policy decision points are nonconflicting, therefore their order is
irrelevant.

Policy decision point (3) is the sub-flow policy processing block. Filters on P-bits and
DSCP already look to altered code points in the previous tow policy decision points. This
is key, as it is much simpler to enforce first the usage of a few allowed code points and
apply the desired policies rather than defining a policy for all undesired code points. In
this policy decision point both P and DSCP bits can be altered and the settings come
exclusively from within the QoS Session profile.

Policy decision point (4) uses a global DSCP to P-bits alignment table. This table (defined
for upstream use) is typically used when end applications set the DSCP value. In policy
decision point 2 an allowed set of DSCP values can be enforced, which in turn is aligned
to appropriate P-bits, using it for traffic segregation in the access network. The QoS
Marker profile contains a flag whether the global DSCP-to-P-bits alignment table is
applicable for a given SAP or not.
Please note that the service hub has an independent DSCP to P-bits alignment table, that
can be enabled or disabled on a per network interface basis. In principle the service hub
alignment table can have a different set of mapping values than the subscriber-side
mapping table.
This section explains the steps required to create and configure a QoS Session profile
and its components through an example.
Figure TNG 101-6: The QoS Session profile and component objects
QoS Session Profile
Logical Flow QoS Policer QoS Policer QoS Marker Qos Policy Qos Policy
Type Profile Up Profile Down Profile Up List Up List Down
1..16 1..4
QoS Policer QoS Marker Qos Policy

Profiles Profiles Table
or
L2 Filter L3 Filter Policy Action

Table Table Table
Example: Create a multi-QoS Session profile for an IP-aware bridge interface, with voice
traffic limited in both direction to 100Kbps, VoD control traffic with enhanced priority and
to limit the rest of traffic to 3Mbps downstream and 256Kbps upstream.
Before we create the session profile, it is required that the components are created first.
Step 1: Create the Policer profiles
Create a Policer profile for upstream rate limitation for the service access point to
256Kbps, with burst tolerance of 32 Kbytes:
> configure qos profiles policer ppUsSap256k committed-info-rate 256

Create a Policer profile for downstream rate limitation for the service access point to
3Mbps, with burst tolerance of 96 Kbytes:
> configure qos profiles policer ppDsSap3M committed-info-rate 3000

Create a Policer profile for voice rate limitation to 100Kbps, with burst tolerance of 3
Kbytes:
> configure qos profiles policer ppVoice100k committed-info-rate 100

Step 2: Create the Marker profile
The default P-bits for upstream packets are to be set to zero, for voice to 6 and for VoD
to 3. In this example we identify voice packets as having a source IP address subnet of
192.170.xx.xx and VoD packets are using source IP addresses in the range of
192.172.xx.xx.
Since by default packets get code point 0 if nothing is specified, and the ingress code
points are not used for determining the outgoing code point, we can simply leave out the
marker profile. However, just for the sake of the example, lets make a marker that sets
P-bits equal to 0.
> configure qos profiles marker d1p mpUsSap default-dot1p 0
Step 3: Create the Filters
To identify upstream voice traffic we need a filter on the source IP address:
> configure qos profiles l3-filter f3pUsVoiceIp src-ip-addr

192.170.0.0/16
Downstream we could use the same address for the IP destination addresses, or the
used DiffServ code point. We choose to use the IP subnet.
> configure qos profiles l3-filter f3pDsVoiceIp dst-ip-addr

192.170.0.0/16
To identify VoD control packets upstream we can use the IP destination address of the
VoD portal (e.g.: 192.180.2.2):
> configure qos profiles l3-filter l3pUsVodIp dst-ip-addr

192.180.2.2/0
The same IP address (this time as source) we can use for identifying VoD control traffic
in the downstream direction:
> configure qos profiles l3-filter l3pDsVodIp src-ip-addr

192.180.2.2/0
Step 4: Create the Policy actions
For voice, the action is setting the outgoing P-bits to 6 and policing the traffic to 100Kbps.
The same policy can be used upstream and downstream, since it does not harm in our
scenario to alter the downstream P-bits.
> configure qos profiles policy-action apVoice dot1p-value 6

policer-profile name:ppVoice100k
For VoD, the policy action is simply to raise it out of the BE traffic class, which can be
again used both upstream and downstream.
> configure qos profiles policy-action apVod dot1p-value 3
Step 5: Create the Policies
The voice policy upstream uses the upstream voice filter (f3pUsVoiceIp) to identify
upstream voice packets and do the voice actions (apVoice) both upstream and
downstream.
> configure qos profiles policy pcyUpVoice policy-action name:apVoice

no precedence filter l3-name:f3pUsVoiceIp
> configure qos profiles policy pcyDnVoice policy-action name:apVoice

no precedence filter l3-name:f3pDsVoiceIp
The VoD policy used the VoD filters to simply set the code point to 3. Upstream this will
cause packets being marked with P-bit = 3, downstream it will cause the packet being
redirected to the controlled load queue.
> configure qos profiles policy pcyUpVod policy-action name:apVod

filter l3-name:l3pUsVodIp
> configure qos profiles policy pcyDnVod policy-action name:apVod

filter l3-name:l3pDsVodIp
Step 6: Create the Session Profile
Create the session profile for an IP-aware bridge, and add basic building blocks (policies
come in a second command):
> configure qos profiles session spSapIpoeVr logical-flow-type

ipoe-ip-aware-bridge up-policer name:ppUsSap256k
down-policer name:ppDsSap3M up-marker name:mpUsSap
> configure qos profiles session spSapIpoeVr down-policy pcyDnVoice
> configure qos profiles session spSapIpoeVr down-policy pcyDnVod
> configure qos profiles session spSapIpoeVr up-policy pcyUpVoice2
> configure qos profiles session spSapIpoeVr up-policy pcyUpVod
Remarks:
1 VoD control traffic - although treated via a sub-flow policy for marking - is still policed
with the entire session. This may cause that from time to time subscriber data traffic
consumes the allowed bandwidth for the session and VoD control traffic will be
impacted as well. This will not happen to voice traffic, since the voice policy contains
a dedicated policer. Therefore, it may be useful to add a policer to the VoD subflow
policy such that the session-based policer does not apply to VoD control frames.
2 Although some of the profiles can be reused for many building blocks, it may be wise
to reuse them only when they refer to the same entity. Example, the reuse of the
voice policy in many session profiles is probably wise to do. If it has to change (e.g.,
the rate or the filter IP address) it is likely that most of them will change. However,
reusing the upstream policer on the session profile for the downstream policing of the
VoD control traffic may cause some complications if later one or the other has to
change.
TNG 102 IGMP and multicast
configuration
General Description
IP multicasting is the transmission of an IP datagram to a host group. A host group is a
set of one or more hosts identified by a single destination IP address.
IP hosts report their multicast group memberships to any neighboring multicast routers
using the Internet Group Management Protocol (IGMP). IGMP is an integral part of IP and
must be implemented for all hosts wanting to receive IP multicasts. IGMP messages are
encapsulated in IP datagrams, with an IP protocol of 2.
Figure TNG 102-1 shows a typical IGMP configuration of a subscriber connected to the
system watching a movie sent from the remote server connected on the network.
Figure TNG 102-1: Typical IGMP Configuration
7302 ISAM Internet

or
7330 FTTN
Video
server
User watching movie
Joint Message
Mcast Downstream
Query Message
IGMPv3
IGMPv3 works basically the same as IGMPv2, except for some protocol improvements,
which allow to enhance the scalability of the overall IGMP solution. For example, IGMPv3
allows to aggregate information about multiple multicast streams in a single IGMP report.
In addition, IGMPv3 has the ability to support multicast source filters, which enables a
system to report interest in receiving a given multicast stream only from specific source
addresses or from all but specific source addresses. This is commonly referred to as
Source Specific Multicast (SSM).
IGMPv3 is the default. Support for IGMPv2 is now seen as a backward compatibility
aspect. The IGMPv3 standard specifies that an IGMPv3 system must also be backward
compatible towards peer systems with older versions. In practice, for the ISAM, this is
realized as follows:
The operator can control/configure which IGMP version to use at 2 points:
The version to be used towards the network side is configurable per VLAN. If the
value of this parameter is set to v3, the NE will discard v2 messages received from
this VLAN, and vice versa.
The version towards the user side is primarily needed to tell the NEwhich IGMP
version it has to use when sending GMQ messages. This version is configurable
system-wide, and per DSL line (that is, the system-wide parameter is the default and
the parameter per DSL line allows to overrule the default):
When the value is set to IGMPv2, the NE will generate IGMPv2 GMQ messages
to the user (which tells the client to switch to IGMPv2 if it was operating in
IGMPv3), and will not accept IGMPv3 reports from the user.
When the value is set to IGMPv3, the NE will generate IGMPv3 GMQ messages
to the user. In this mode, both IGMPv2 and IGMPv3 reports are accepted from
the user.
The default value is IGMPv3
IGMP Message Types

There are three types of IGMP messages related to the host-router interaction:
membership query (MQ):

general query, used to learn group members
group-specific query, used to learn if a particular group has any members
version membership report
leave group message
IGMP Parameter Tables

IGMP is managed using a set of parameters arranged in various tables:
IGMP channel table

multicast source table
IGMP module table
IGMP package to multicast source table
IGMP system parameters
IGMP Channel Table

The IGMP channel table consists of multicast capacity parameters as well as statistics
and counters related to IGMP that are multicast per bridge.
Table TNG 102-1: Multicast Capacity Parameters
Parameter Description Range Default
max-num-group Maximum number of groups supported by the 0..1024 1024

system in enough bandwidth
max-num-uncfg Maximum number of unconfigured groups 0..128 64

supported by the system in enough bandwidth
cfg-res-time Time to reserve the unused configured groups 0..2147483647 125
uncfg-res-time Time to reserve the unused unconfigured groups 0..2147483647 0
You can configure the characteristics of an IGMP channel by specifying a unique index,
a VCI, and a VPI for each channel, as well as the following parameters:
port index:
Ranges from 1/1/3/0 to 1/1/18/47
VCI:
Ranges from 0 to 255
VPI:
Ranges from 32 to 65535
Refer to the CLI Command and Messages document for a description of all parameters.
Multicast source table

This table determines the characteristics of the multicast groups, which should be
multicast in cross-VLAN mode. The table contains a maximum of 1024 multicast source
entries.
IGMP module table

This table determines the distribution of statistic information maintained by the IGMP
proxy.
IGMP Package to Multicast Source Table

The IGMP package to multicast source table is intended primarily for use by a Element
Management System (EMS) (for example, the 5526 AMS). It allows the EMS to support
multiple sets of packages in different regions.
A package is a group of one or more multicast sources that share a common access
permission. By grouping the source channels in one or more packages, a service
provider is able to support and deliver services at various levels to the end users.
The IGMP package to multicast source table shows the following parameters for a
package:
The multicast group address

The multicast group source address
IGMP System Parameters

These parameters are used to maintain active memberships of connected multicast
channels and to process IGMP join, leave, and query messages.
It is highly recommended that all default values be left as is. However, should there be a
need to change the IGMP parameters, make sure to set all dependencies first. Failing to
do this may lead to rejection of a set, since some of the valid ranges are dependent on
other objects.
IGMP Snooping Configuration on the SHub

You can configure IGMP Snooping, Virtual LAN router port related parameters and the
Virtual LAN filter for the IGMP Snooping for a particular VLAN.
Viewing the IGMP Related Parameters

Table TNG 102-2 describes the commands available that allow you to view the IGMP
related parameters.
Table TNG 102-2: Parameter display commands
Command Description
show igmp system Show all the IGMP system-related parameters
show igmp channel counter (port) Show the IGMP channel counter details
show igmp channel miscellaneous (port) Show the IGMP channel source details
show igmp channel protocol (port) Show the IGMP protocol statistics for an IGMP
channel
show igmp package-to-src (package-id) Show the IGMP package to multicast source
parameters
show igmp grp-to-package (mcast-addr) Show the IGMP group to package parameters
show igmp module-mcast-src (slot) Show the distribution of statistic information

mcast-addr <MulticastAddress> maintained by IGMP channels
show igmp module counter (slot-index) Show the IGMP Module counters
show igmp module time (slot-index) Show the time-related parameters of the IGMP
module
show igmp module miscellaneous (slot-index) Show miscellaneous parameters of the IGMP
module
show igmp shub vlan-router-port (vlan-id) Show the status of the IGMP VLAN router ports
show igmp shub igs-stats (vlan-id) Show the IGMP protocol statistics for the SHub
show igmp shub system-stats Show the CAC system-related parameters and
statistics
show igmp shub mcast-stats (src) Show the CAC multicast-related channel statistics
show igmp shub bundle-stats (bundle-name) Show the CAC multicast-related bundle statistics
show igmp shub bundle-to-src (bundle-name) Show the CAC bundle to multicast source
class-d-addr <Igmp::MulticastAddress> parameters
Multicast Configuration Guidelines

When configuring multicast, the sequence of configuration actions is very important.
When you are adding a multicast stream to the multicast source table, you need to
configure the VLAN ID on which this stream can be received.
You need to create and configure this VLAN ID prior to creating the multicast source table
entry. Failing to do this may cause difficulty in joining the multicast group.
TNG 103 VBAS
General Description
The Virtual Broadband Access Server (VBAS) protocol is used between the Broadband
Access Server (BAS) and the system to get detailed information on the subscribers
physical address. The VBAS protocol has two phases. After completing these phases,
the BAS can get the physical address of any new subscriber. The two phases are:
VBAS Query
VBAS sends a VBAS Query Packet to the system to gather physical-port information
corresponding to the MAC address of the new subscriber.
VBAS Response
Upon receiving the request packet, the system sends a VBAS Response Packet to
the BAS. This packet includes the physical-port information of the new subscriber.
All VBAS packets carry a destination. If the packet is not destined for a specific system,
it will forward the packet to all subtending systems until it has reached its intended
destination.
In normal operation, the network port towards the BAS is tagged. This means that the
network port is able to process and respond to tagged VBAS frames.
If untagged packets are to be handled, then the network port is explicitly set as untagged.
Also a PVID is configured for the port. When the system receives a VBAS query, user
information is retrieved from the VLAN configured as PVID.
VBAS Configuration
No specific VBAS configuration as such is necessary on this system. However, as an
Operator, you need to make sure that the network port is configured in order to properly
communicate with the BAS.
There are two modes in which the network port can operate: tagged or untagged.
TNG 103 VBAS
VBAS Configuration in Tagged Mode

If the network port is set up as a tagged port, it should be a part of all related VLANs. The
port will handle all tagged VBAS packets.
VBAS Configuration in Untagged Mode

If untagged VBAS frames are to be handled by the system, the network port must be
untagged and a PVID must be configured.
Example
A user with MAC address 00-B0-D0-BC-D5-D3 is connected to slot 7, port 23 on LIM1.
LIM1 is connected to ASAM port 1. The VLAN configured for the user is VLAN 100 on
both LIM and SHub.
When the VBAS request arrives from the server on the SHub, the MAC address of the
user is retrieved in VLAN 100. Since the user MAC address is learned in VLAN 100, the
request is forwarded to LIM1.
LIM1 replies with VBAS response containing user information such as the slot and port
number. The SHub forwards the VBAS response to the server.
The process is shown in Figure TNG 103-1.
Figure TNG 103-1: VBAS Example

ISAM/L Shub:
06.00.00.00.00.80
ETHERNET
VBAS Resp:
VBAS VBAS DA: 02.00.40.00.00.80
Req Resp VL AN: 100
User: 00.b0.d0.bc. d5.d3
User:
MAC: 00.b0.d0.bc. d5.d3
Slot: 2
Port: 23
VLAN: 100
TNG 104 DHCP relay agent
configuration
General Description
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing
configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap
Protocol (BOOTP), adding the capability of automatic allocation of reusable network
addresses and additional configuration options. DHCP consists of two components: a
protocol for delivering host-specific configuration parameters from a DHCP server to a
host and a mechanism for allocation of network addresses to hosts. DHCP is built on a
client-server model, where designated DHCP server hosts allocate network addresses
and deliver configuration parameters to dynamically configured hosts.
Figure TNG 104-1 shows a typical DHCP configuration.
Figure TNG 104-1: Typical DHCP Configuration
iSAM 7302 Internet

or
7330 FTTN
DHCP
server
Upstream packet
Downstream
17704
IP Address Allocation Mechanisms
DHCP supports three mechanisms for IP address allocation:
automatic allocation
DHCP assigns a permanent IP address to a client.
dynamic allocation
DHCP assigns an IP address to a client for a limited period of time (or until the client
explicitly relinquishes the address).
manual allocation
A client's IP address is assigned by the network administrator, and DHCP is used
simply to convey the assigned address to the client.
A particular network will use one or more of these mechanisms, depending on the policies
of the network administrator.
DHCP Option 82
An option called Option 82 is inserted by the DHCP relay agent running on the system
when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing
Option 82 may use the information to implement an IP address or other parameter
assignment policies. The DHCP server echoes the option back to the relay agent in
server-to-client replies. The system strips the option before forwarding the reply to the
client. Option 82 is organized as a single DHCP option that contains one or more
suboptions that convey information known by the relay agent.
DHCP Relay Parameters

Table TNG 104-1 describes the parameters used to configure DCHP.
Table TNG 104-1: DHCP parameter descriptions
Parameter Description
Relaying When enabled, the relay agent is active

Server When enabled, the relay agent forwards the packets to a specific
DHCP server
Server IP Address of the DHCP server to which the packets are to be

forwarded
secs-threshold/hops-threshold Thresholds for Option 82
Conditions and Restrictions

Note the following conditions and restrictions.
Before you can enable the DHCP relay agent, you need to configure the DHCP
servers on a VRF IP interface.
The DHCP relay agent can only be configured on one VRF IP interface.
A maximum of four DHCP servers can be configured on a VRF.
The DHCP servers configured on a VRF IP interface must be part of the set of DHCP
servers configured on the VRF.
Viewing the DHCP Configuration

There are several commands available that allow you to view the DHCP configuration.
Table TNG 104-2 describes each command.
Table TNG 104-2: Configuration display commands
Command Description
show dhcp-relay port Show DHCP relay port counters.

show dhcp-relay bridgeport Shows DHCP relay bridge port counters
show dhcp-relay shub vrf-agent-stats Shows DHCP DHCP relay agent statistics for each VRF.
See the CLI Commands and Messages document for more information on these
commands.
Introduction
This TNG provides more information about:
Downloading a new OSWP.

Aborting an OSWP.
Activating a non-active OSWP.
Committing an OSWP.
Download a New OSWP

The following prerequisites must be fulfilled before a new OSWP can be downloaded:
The system must have only one Enabled/Active/Committed OSWP.

The management channel between the system and the manager has been
established.
The system is not involved in another OSWP download process.
The manager requests the system to download a new OSWP. He specifies:
The path name of the overall descriptor files

The TFTP-servers where the overall descriptor files can be found.
The set of overall descriptor files he wants to have available on the system before
activating the new OSWP.
The system downloads the overall descriptor files and stores it persistently.
The system downloads the software files that are specified in the downloaded overall
descriptor files on condition that sufficient resources are available for their persistent
storage.
The manager has the possibility to monitor the progress of the download process with
granularity.
The download of the process can be implicitly or explicitly interrupted:
The implicit interruption can occur due to the following:

the unavailability of sufficient resources to store SWP files.
the system is not able to download or interpret the overall descriptor file.
the system is not able to download a selected SWP descriptor file.
The explicit interruption can occur when the manager requests the system to abort the
ongoing download process.
In case there are no exceptions, finally the system will have two OSWPs:
the Enabled/Active/Committed OSWP.

the new downloaded OSWP. The status of the new OSWP is
Enabled/NotActive/UnCommitted.
Abort an OSWP
The manager can abort an OSWP when the system has 2 OSWPs. The status of the first
OSWP is Enabled/Active/Committed while the second one will be in one of the following
three states:
Enabled/NotActive/UnCommitted
Downloading/NotActive/UnCommitted
Disabled/NotActive/UnCommitted.
The management channel between the system and the manager is established and the
system is not involved in any other SW download process.
The manager requests the system to remove the NotActive/UnCommitted OSWP. The
system removes all the persistent stored files and databases not related to the
Enabled/Active/Committed OSWP. The status of the OSWP to be removed will be
Aborting/NotActive/UnCommitted during the complete remove operation.
After the abort is successful the system will have only one OSWP. The status of this
OSWP will be Enabled/Active/Committed. Only files and databases related to this OSWP
are stored persistently in the system.
Activate a Non-active OSWP

To activate a not-active OSWP, the system must have two OSWPs:
The first OSWP has the status Enabled/Active, while the second OSWP has the status
Enabled/NotActive.
The management channel between the system and the manager is established and the
system is not involved in another SW download process.
The manager requests the system to activate the Enabled/NotActive OSWP:
1 The system selects the database that is compatible with and linked to the
Enabled/NotActive OSWP among the available databases.
2 The system starts the activation procedure of the NotActive OSWP.

3 When the activation of the NotActive OSWP is successful, the system has two
OSWPs.
The previously NotActive OSWP is now active together with the selected compatible
database. The previously Active OSWP is still available but its status is now
Enabled/NotActive.
Commit an OSWP
To commit an OSWP, the system has two OSWPs. The first OSWP has the status
Enabled/Active/Uncommitted, while the status of the second OSWP is
Enabled/NotActive/Committed.
The manager requests the system to commit the active OSWP:
1 The system removes all the persistent stored files and databases that do not belong
to the Enabled/Active OSWP.
Note The status of the OSWP to be committed will be

Enabled/Active/Committing during the entire commit operation.
2 After commit is successful, the system will have only one OSWP. The status of this
OSWP is Enabled/Active/Committed. Only files related to this OSWP are stored
persistently in the system.
TNG 106 Specifying 7330 ISAM FTTN
remote expansion units
using the CLI
Purpose
This TNG provides information about how the system software of a 7330 ISAM FTTN
host shelf identifies connected remote expansion units and how you can access remote
components to configure them using a CLI management session from the host shelf.
Rack and shelf IDs

The expansion configuration for the 7330 ISAM FTTN consists of an ARAM-D host shelf
connected to a combination of 7330 ISAM FTTN ES and 7330 ISAM FTTN REM or SEM
remote expansion units. You can connect up to five ES and 12 REM or SEM as long as
the total number of remote LT units does not exceed 12.
Rack and shelf assignments

The 7330 ISAM FTTN system and management software identify each 7330 ISAM FTTN
according to a rack and shelf ID. A standalone 7330 ISAM FTTN always uses rack 1,
shelf 1. In expansion configurations, the host shelf and each remote expansion unit
require a unique rack and shelf ID. The rack and shelf ID, along with the MAC address,
is used for routing traffic to subscribers connected to the shelf. The assigned rack and
shelf IDs can reflect the actual installation of shelves within co-located racks, or be logical
assignments for remote installations.
It is possible to configure up to 7 racks in an expansion configuration, each rack with up

to 4 shelves, for 28 possible rack/shelf combinations. However, because the host shelf
supports a maximum of 12 downlinks, you can only connect 12 remote shelves to a host
shelf.
TNG 106 Specifying 7330 ISAM FTTN remote expansion units using the CLI
Rack 1 must always contain the host ARAM-D shelf in the topmost position and the host
shelf must be assigned rack 1, shelf 1. A combination of ES (maximum 5) and SEM or
REM (maximum 12) can be installed in racks 1 through 7 to a maximum of 12 shelves.
The SEM and the REM are nearly always installed in remote locations, away from the
host shelf installed in the CO. Expansion shelves may be co-located with the host shelf
or installed in remote locations. For this reason, racks 2 through 7 are virtual racks: they
do not necessarily need to be physical racks installed in the same CO location as rack 1
containing the host shelf. Shelves 2 to 4 in rack 1 may also be assigned to remotely
located ES, SEM or REM.
For the ES, rack and shelf assignments are derived from the shelf jumper settings.
For the SEM or REM, the rack and shelf assignment is derived from the downlink port on
the board to which the SEM is connected (GENC-E, GENC-F, NCNC-B or NCNC-C), i.e.
their positioning is provisioned by the operator by provisioning the mapping of the SFP
port ID on the shelf expander unit (GENC/NTIO) to a remote LT slot position
(rack/shelf/slot). Rack and shelf assignments for downlink ports are configurable using
CLI.
Configurable rack and shelf ID assignments

The downlink ports on the GENC-E, GENC-F, NCNC-B or NCNC-C board to which you
connect a remote expansion unit have configurable rack and shelf ID assignments. Each
ES and SEM or REM must have a unique rack and shelf ID.
For the ES, you do not have to configure the rack and shelf assignments for the downlink
ports; shelf jumper settings are used by default to assign rack and shelf IDs.
Note The assignment is not required for the ES shelf itself (due to ES
shelf autoplanning), but the assignment is required for VLAN
configuration. Without the assignment it is not possible to configure VLAN
on the LTs in ES. Therefore, it is highly recommended to configure the
aasignements.
The SEM or REM does not use jumpers to set the rack and shelf ID. For the SEM or REM,
the rack and shelf ID are derived from the downlink port settings of the GENC-E,
GENC-F, NCNC-B or NCNC-C board. The CLI is used to configure rack and shelf ID
assignments for downlink ports.
Note A management session must be initiated on the host shelf. No

direct management connection can be made to remote expansion units
for configuration using CLI.
After an ES is connected to a downlink port and is operational, swapping expansion link

cables disrupts communications over the affected expansion links and an alarm is raised
in the system software. If the rack and shelf assignment for a downlink port is already
configured using CLI and you connect a remote LT unit from an ES that has a different
rack and shelf jumper setting, an alarm is raised and the remote LT unit does not come
in to service. If you connect a remote LT unit from an ES to a downlink port after a SEM
unit was previously connected and commissioned, an alarm is raised and the remote LT
unit does not come in to service.
Using the CLI, you can change the shelf and rack ID assignments for all downlink ports
on the GENC-E, GENC-F, NCNC-B or NCNC-C board. Do not change shelf and rack ID
assignments using CLI after remote expansion units are connected and operational.
Service disruptions will result and an alarm is raised. Service and port configurations are
mapped to the optical expansion link. All affected port and service configurations that
were affected will require reconfiguration.
Warning Do not swap optical expansion link cables between

downlink expansion ports on the GENC-E, GENC-F, NCNC-B or
NCNC-C board, or between expansion ports on the EDSE-A board, after
the remote expansion unit is configured. Service disruptions will result
and an alarm is raised.
SFP port mapping

For VLAN configuration commands, the user enters a rack, shelf and slot as identifiers to
apply the VLAN configuration. For LTs in the expansion shelf, the rack, shelf, and slot
must be mapped to an SFP unit on the faceplate of the GENC (or NCNC-B/NCNC-C for
FD).
Table TNG 106-1: Available SFP ports
Board Available links SFP number on SFP to be cabled to

faceplate
GENC 14 links: 4...17 rack/shelf/slot

SPFs 4 and 5 are uplinks
SPFs 6 and 7 are configurable
(uplink or downlink)
SFPs 8 to 17 are downlinks
NCNC-B 6 links: 2...7

NCNC-C 12 links: 2...13

The SFP to be cabled to field that contains the rack-shelf-slot of the desired LT to be
cabled to that SFP requires that the shelf of the LT being referenced must be planned;
only the shelf must be planned. This is required to check on the valid rack-shelf-slot
ranges. Un-planning of a shelf will be blocked if the shelf is part of any of the
rack-shelf-slot entries in the host SFP configuration extension table.
For the configurable SFPs (SFP 6 and SFP 7 on GENC boards):
If the SFP is configured as uplink then the association to an LT will be blocked. Similarly
if the SFP is configured as downlink and there is an LT associated with that SFP, the
configuration of the SFP to uplink will be blocked.
Specifying remote expansion units using CLI

You can configure the 7330 ISAM FTTN host shelf and connected remote expansion
units using CLI. A management session must be initiated on the host shelf. No direct
management connection can be made to remote expansion units for configuration using
CLI.
Slot and port identification

After you initiate a management session with the host shelf and are ready to enter
configuration commands, you need to know what parameters to enter that will apply the
configuration command to the appropriate piece of equipment. For expansion
configurations, you can configure operating parameters and services for the host shelf,
the ES, or the SEM or REM.
You must enter the unique rack and shelf ID for the host shelf or remote expansion unit.
Depending on what you are configuring, you may also need to enter the slot number of a
particular card and a specific port number.
The following standard conditions apply:
a standalone 7330 ISAM FTTN always uses rack 1 and shelf 1

the host shelf in an expansion configuration always uses rack 1, shelf 1
the slot ID for the SEM or REM is slot 4 (using legacy based numbering) or 1 (using
position-based or type-based numbering).
For shelves, you must enter the LT slot number that contains the card you want to
configure. For a horizontally mounted ARAM-D shelf, the bottommost LT slot is LT1. The
LT slot number increments for each successive LT slot in the shelf. The topmost LT slot
in a horizontally mounted shelf is LT4.
Table TNG 106-2 lists the ES shelf contents and indicates what you must enter using the
CLI to reference a specific slot. The orientation of the table rows is the same as the slots
of a horizontally mounted ARAM-D shelf, where the GFC slot has the topmost position in
the shelf and slot LP1 has the bottommost position.
Table TNG 106-2: ES slot designations for CLI
Slot type ES slot content Slot identifier to

enter using CLI
GFC PWIO-B card
ATI SATU-A card 1
NT slot B (NTB) Filler plate
NT slot A (NTA) EDSE-A card 2
LT slot 4 (LT4) Any supported LT unit 7
(1 of 2)
Slot type ES slot content Slot identifier to

enter using CLI
LP slot 4 (LP4) Matching applique for LT unit installed in LT4
(2 of 2)
Note The default legacy-based slot numbering is used here. See

TNG 115 for slot numbering using other slot numbering schemes.
Subscriber ports are uniquely identified by the rack, shelf, slot, and port number. The port
number is determined by the cable pinout when subscriber lines are connected to the
applique installed in the shelf, or to the SEM xDSL drop line break-out cable.
Example CLI configuration commands

An example command to configure an EVLT-A board installed in slot LT1 for shelf 2 in
rack 1 is as follows:
1 Plan the shelf

configure equipment shelf 1/2
2 Plan the EVLT-A board
configure equipment slot 1/2/4 planned type evlt-a
An example command to configure a SEM as an LT unit in slot 4 of rack 3, shelf 1 is as

follows:
1 Plan the NT I/O board:

configure equipment slot acu:1/1 planned-type genc-e
2 Plan the REM:
configure equipment shelf 3/1 type sems-a
3 Configure the association between a host shelf SFP and a remote LT:
4 Plan the board:
configure equipment slot 3/1/4 planned type vsem-a
An example command to configure 3 REMs as an LT unit in slot 4 of rack 3, shelves 2, 3

and 4 is as follows:
1 Plan the NT I/O board:

configure equipment applique iont:1/1 planned-type ncnc-c
2 Plan the REMs:
3 Configure the association between the host shelf SFPs and the REMs:
4 Plan the boards:
Introduction
This TNG provides more information about the parameters used by the VDSLx modem:
Re-initialization triggers
VDSLx configuration management
Line operation configuration
VDSLx common configuration parameters
Flavor-dependent configuration parameters
Flavor-specific configuration parameters
Supported operational data parameters
During showtime (L0 line state), the VDSLx Modem Subsystem performs
persistency/severity checking and correlation on the defects/anomalies, in order to detect
re-initialization triggers. Table TNG 107-1 lists them for the VTU-O and includes the
required persistency time for each showtime error.
Table TNG 107-1: Re-initialization triggers
Related Defect/Anomaly Needed persistency to trigger re-start
Near-End Far-End
(f)los 5 1 sec 6 1 sec
sef/rdi 5 1 sec 6 1 sec
(f)lom 60 1 sec 60 1 sec
(f)se 10 1 sec 10 1 sec
(f)ncd 15 1 sec 17 1 sec
(f)lcd 15 1 sec 17 1 sec
(f)npd/(f)lpd 15 1 sec 15 1 sec
The VDSLx modem subsystem triggers/initiates re-activation of the modem when any of
those triggers is fired. No other re-initialization triggers (annex timer values) are used by
the modem subsystem than the ones mentioned in Table TNG 107-1.
All the far-end countdown timers are frozen when any near-end defect occurs. When all
the near-end defects have disappeared, the ar-end count-down timers resume from the
frozen values (ignoring the in-between time).
All the near-end defects are correlated independent from each other. The same holds for
all the far-end defects in absence of near-end defects.
VDSLx configuration management

The VDSLx modem subsystem accepts the configuration parameters listed hereunder.
Based on the required levels, the required modem reaction on each parameter is:
In case a parameter is indicated as optional, the input value is do not care, and any
value is accepted without having impact on the modem subsystem behavior.
In case a parameter is indicated to be required to a certain level (for example, only a
limited set of defined number of input values), only input values corresponding to the
required level are accepted. If the input parameter is not accepted, the modem
subsystem raises a failure indication to the xDSL manager indicating Configuration
Error
In case extra consistency checks need to be performed on a parameter or between
parameters and the configuration should be rejected, rejection always means that
the modem subsystem raises a failure indication to the xDSL Manager indicating
Configuration Error, rather that a returned error of the considered xDSL API call.
An xDSL API configuration request is replied with an error only when the call is done
in a wrong administrative state.
The VDSLx modem subsystem allows the configuration to be independently set on

individual line basis.
VDSLx common configuration parameters

All the following parameters are common for all supported DSL flavours (includes VDSL
and VDSL2). There is only one instance per parameters, whatever the number of
operating modes selected.
Operating modes
Rate adaptation mode
Target noise margin
Minimum noise margin
Maximum noise margin
Carrier mask
RF band data
Minimum bitrate
Maximum bitrate
Rate adaptation ratio
Maximum interleaving delay
Minimum impulse noise protection
Band plan:
Custom band plan
Predefined band plan
Maximum number of bands
Maximum usable frequency
ADSL band mode
ADSL band mode end frequency
Optional band mode
Optional band mode end frequency
US power backoff mode
DS G.HS tones power:
DS G.hs tones power mode
DS G.hs tones power manual level
Table TNG 107-2: Operating modes
Name Operating Modes
Description Specifies which xDSL standard shall be applicable: ANSI T1.424 (old trial use
standard), ETSI TS 101 270, ITU-T G993.1, IEEE 802.3ah, or ITU-T G.993.2
(VDSL2) different Profiles.
Instances Line
(1 of 2)
Values Bitmap:
OpModesITU_G993_2_8A_Bit
OpModesITU_G993_2_8B_Bit
OpModesITU_G993_2_8C_Bit
OpModesITU_G993_2_8D_Bit
OpModesITU_G993_2_12B_Bit
OpModesANSI_T1_424Bit
OpModesETSI_TS_101_270Bit
OpModesITU_G993_1Bit
OpModesIEEE802.3ah_Bit
Granularity & Unit -
(2 of 2)
Table TNG 107-3: Rate adaptation mode
Name Rate Adaptation Mode
Description Specifies the Rate Adaptive mode of operation:

RA mode 1 (manual): The VTU initializes at the specified Minimum Bitrate,
During showtime, the VTU tries to maintain that bitrate with at least the specified
Minimum Noise Margin.
RA mode 2 (atInit): The VTU initializes at the bitrate corresponding with a noise
margin of at least the specified Target Noise Margin and a BER better than 10-7
at 0 dB noise margin, provided that the bitrate is not less than the specified
Minimum Bitrate and not greater than the specified Maximum Bitrate. During
showtime, the VTU does not perform dynamic rate adaptation but instead, tries
to maintain the initial bitrate with at least the specified Minimum Noise Margin.
The modem optimizes according to the list of priorities defined by requirement.
Instances Line DS, US
Values raModeManual
raModeAtInit
Table TNG 107-4: Target noise margin
Name Target Noise Margin

Description Specifies the required noise margin, relative to a BER of 10-7 at 0 dB noise
margin, the modem achieves in order to successfully complete the initialization.
This parameter is not used in showtime.
Instances DS, US
Values 0..31
Granularity & Unit 0.1 dB
Table TNG 107-5: Minimum noise margin
Name Minimum Noise Margin
Description Specifies the minimum noise margin, relative to a BER of 10-7 at 0 dB noise
margin, the modem tolerates in order to maintain showtime. This parameter is
only used in showtime.
The VDSLx modem subsystem raises failure indication Configuration Error for
configurations where Minimum Noise Margin > Target Noise Margin for one of
the directions.
Instances DS, US
Values 0..31
Table TNG 107-6: Maximum noise margin
Name Maximum Noise Margin
Description Specifies the maximum noise margin sustained by the modem. This parameter
is both used during initialization and in showtime.
during initialization:
When the noise margin for transport configuration is higher than the
Maximum Noise Margin, then the modem takes action to reduce the
power to get the actual noise margin below this value.
When the noise margin is lower than the Maximum Noise Margin, then
the modem tries to optimize the Receive Power below the configured
masks to get the noise margin as high as possible (still below the
Maximum Noise Margin).
in showtime:
When the current noise margin gets above the Maximum Noise Margin,
the modem attempts to reduce the far-end output power to get the noise
margin below this limit (by means of bit-swap actions).
When the current noise margin gets below the Maximum Noise Margin,
then the ATU attempts to increase the far-end output power (still below
the maximum allowed templates or masks) to get the noise margin as
high as possible (by means of bits-swap actions).
If the Maximum Noise Margin is configured lower than the Target Noise Margin,
the configuration is rejected, and the configuration error failure is raised.
The special value NoMaximumNoiseMargin is interpreted as meaning that no
Maximum Noise Margin limit must be applied.
Other values strictly bigger than 31.0 are converted to the special value
NoMaximumNoiseMargin.
Instances DS, US
Values 0..51 and NoMaximumNoiseMargin
For clarification, Figure TNG 107-1 gives an overview of the noise margin parameters,
and the required actions from the modem.
Figure TNG 107-1: Noise margin parameters
Reduce Output Power at peer modem

Maximum Noise Margin
Maximum Additional Noise Margin

Increase Output Power at peer modem
Target Noise Margin
Minimum Noise Margin
Modem restarts if persistent in this region

0 dB Margin
Table TNG 107-7: Carrier mask
In VDSL the carrier masking is not defined using bitmap. Instead carrier masking is defined via RF
bands (see RF band data).
Table TNG 107-8: RF band data
Name RF Band Data
Description Specifies the list of RF bands (HAM band or AM band) for egress control and
ingress cancelling. Band RF type, ingress level and egress control parameters
can be set independently from each other.
Up to 16 bands shall be supported: RFBandi (i = 0..15).
Egress control can be requested and applied in up to 16 bands
simultaneously.Ingress level can be specified for each RF band such that it can
be taken into account by the modem at initialization (usage for RFI cancelling
purposes is vendor discretionary). However, when different ingress settings are
configured for RF bands being in the downstream bandplan (gDS RF bandsh),
the stronger ingress setting shall be assumed for all those DS RF bands.
Instances Line
(1 of 2)
Values Maximum 16 RF bands can be specified and are supported:

RF band = [Start frequency, Stop frequency, RF type, Egress control, Ingress
level]
Frequency: 0 30000 kHz
RF type: HAM band (rfHam) or AM band (rfAm)
Egress control:
egressNotched: PSD level in the band is below -80 dBm/Hz
egressMasked: tones in the bands are turned off
egressNotchedMasked: PSD level in the band is below -80 dBm/Hz,
and tones in the bands are turned off
egressNoControl: PSD notching is not required
Ingress level:
(ingressLow): ingress level can be neglected
(ingressWeak): expected ingress level is weak at
-30dBm@LT/-20dBm@NT level
(ingressStrong): expected ingress level is strong at
-10dBm@LT/0dBm@NT level
(2 of 2)
Table TNG 107-9: Minimum bitrate
Name Minimum Bitrate

Description Defines the minimum requested transport bitrate which is set up and which is
maintained during showtime by the VTU.
Instances Bearer DS, US
Values 0..262143
Granularity & Unit 1 kbit/s
Table TNG 107-10: Maximum bitrate
Name Maximum Bitrate
Description Defines the maximum allowed transport bitrate which is set up and which is
maintained during showtime by the VTU. This parameter is relevant only in
'atInit' RA Mode. When RA Mode is manual, the Maximum Bitrate parameter
is ignored.
The VDSLx modem subsystem raises failure indication Configuration Error for
configurations where Maximum Bitrate < Minimum Bitrate for one of the
directions in case of the atInit RA Mode.
Values 0..262143
Table TNG 107-11: Rate adaptation ratio
Name Rate Adaptation Ratio
Description The Rate Adaptation Ratio specifies the ratio that should be taken into account
for allocating available data rate (in excess of the minimum data rate summed
over all bearer channels) among the different bearer channels in a given
direction.
The ratio is defined as a percentage from 0 to 100. The sum of the raRatios for
all bearers must be 100.
The excessive bitrate (that is, the available bitrate minus the sum of the
minimum bitrates) must be distributed among the different bearers according to
their respective raRatio.
When the maximum bitrate is achieved for one of the bearers, the raRatio of that
bearer must be distributed to the other bearers according to their respective
raRatio share.
This parameter is only meaningful in case multiple bearers are used (for
example, 2 for dual latency) and is ignored in case of single latency.

Values 0..100
Granularity & Unit 1%
Table TNG 107-12: Maximum interleaving delay
Name Maximum Interleaving Delay
Description Specifies the maximum allowed delay introduced by the interleaving and
deinterleaving function in the corresponding direction.
The VTU-O and VTU-R choose their interleaving and coding parameters within
the maxDelay and minInp constraints.
Values 0..63, and special value onems.

0 is a special value used as don't care indication, that is, the interleaving
delay is not restricted.
1 is a special value used to disable the interleaving (fast mode).
onems is a special value used to select 1 ms maximum interleaving delay.
Other values directly give the maximum impulse noise protection, in
milliseconds.
Granularity & Unit 1 ms
Table TNG 107-13: Minimum impulse noise protection
Name Minimum Impulse Noise Protection
Description Specifies the minimum required impulse noise protection as a number of

protected DMT symbols at PMD output (de-interleaver input).
Values 0..16 DMT Symbols
Granularity & Unit 0.1 DMT symbol
Table TNG 107-14: Custom band plan
Name VDSLx Custom Band Plan
Description Specifies custom band plan in case Predefined Band Plan selection
(see Predefined band plan) is set to bandPlanCustom, ignored otherwise. It
always excludes the Upstream or Downstream optional Band control.
Instances Line
Values Maximum 8 bands can be specified:

band = [Start frequency, Stop frequency, Direction]
Frequency: 0..30000 kHz,
Direction: Upstream (dirUp) or Downstream (dirDown)
Granularity & Unit 1 kHz
Table TNG 107-15: Predefined band plan
Name Predefined Band Plan
Description Specifies the type of Band Plan.
Instances Line
Values bandPlanCustom: custom defined band plan (see also VDSLx Custom Band
Plan parameter)
bandPlanA: 998 band plan
bandPlanB: 997 band plan
bandPlanC: Fx band plan (see also Fx Band Plan Parameter)
bandPlanAext: ITU-T G.993.2 VDSL2 Annex C band plan
bandPlanChina1: China band plan 1
bandPlanChina2: China band plan 2
bandPlanAnnexA: ITU-T G.993.2 VDSL2 Annex A (extended) band plan
bandPlanAnnexB998E: ITU-T G.993.2 VDSL2 Annex B band plan type 998E
bandPlanAnnexB997E: ITU-T G.993.2 VDSL2 Annex B band plan type 997E
bandPlanAnnexB998ADE: ITU-T G.993.2 VDSL2 Annex B band plan type
998ADE
bandPlanAnnexBHPE: ITU-T G.993.2 VDSL2 Annex B band plan type HPE
Table TNG 107-16: Maximum number of bands
Name Maximum Number of Bands
Description Specifies the maximum number of bands to be supported for the given band
plan. In case the selected band plan (see Custom band plan and Predefined
band plan) contains more bands, the modem disables bands located at higher
frequencies first.
Otherwise, this parameter has no effect.
The optional band is NOT counted as a band, and does not take part to the
number of bands (example: if the maximum number of bands is set to 3, the
modem is allowed to use the optional band + DS1 + US1 + DS2).
The special value unlimited disables the maximum number of band constraint.
Instances Line
Values unlimited, 2..8
Unit Bands
Table TNG 107-17: Maximum usable frequency
Name Maximum Usable Frequency
Description Specifies the maximum frequency usable both VTU-O and VTU-R VDSL
modems, in showtime.
The special value unlimited disables the maximum usable frequency
constraint.
In case the configuration of this parameter would conflict with other parameters,
the configuration is rejected.
Note: This parameter is not equivalent to the MUF parameter commonly used
when dealing with CO-RT mixed deployment and PSD shaping. This last MUF
parameter is equivalent to the ADSL band mode end frequency parameter.
Instances Line
Values unlimited, 1104..30000 kHz
Unit kHz
Table TNG 107-18: ADSL band mode
Name ADSL Band Mode
Description Specifies whether the VDSLx modem is allowed to use the ADSL spectrum or
not in DS. The end frequency of the ADSL band is specified by the ADSL band
mode end frequency.
It controls the use of the ADSL spectrum within the defined VDSLx band plan,
with the exception of the optional band, which is not impacted by this parameter.
Note: whatever the value of this parameter, the modem is never allowed to
exceed the configured PSD mask (see PSD ceiling).
Instances Line
Values 0: usage of ADSL spectrum is allowed.

1: usage of the ADSL spectrum is not allowed.
Table TNG 107-19: ADSL band mode end frequency
Name ADSL Band Mode End Frequency
Description This parameter specifies the ADSL band end frequency. The start frequency is
always 25 kHz. It is used together with parameter 0 (see ADSL band mode).
It controls the use of the ADSL spectrum within the defined VDSLx band plan,
with the exclusion of the optional band, which is only controlled through
the Optional band mode.
This parameter is ignored when the ADSL spectrum usage is allowed.This
parameter is assumed 1104 kHz if no value, or if the special 0 kHz value is
configured.
Instances Line
Values 0 kHz, 276..2208kHz
Table TNG 107-20: Optional band mode
Name Optional Band Mode
Description Indicates if the VDSLx modem is allowed to use the optional band
(25 kHz..x kHz) or not and defines its direction in case the use is allowed.
The x value is a parameter specified by the ADSL band mode end frequency.
This parameter is ignored and the optional band usage prohibited if not
supported by the HW.
The optional band usage is independent of the ADSL band mode parameter (0):
in case the ADSL band mode is set to not allowed, and the optional band mode
is enabled, the modem is still allowed to use the optional band.
Note: on ISDN boards, the optional band start frequency is shifted from 25 kHz
to 138 kHz.
Instances Line
Values Optional band usage On/Off, and direction US/DS.
Table TNG 107-21: Optional band mode end frequency
Name Optional Band Mode End Frequency
Description When the optional band usage is enabled (see Optional band mode), this
parameter specifies the optional band end frequency. The start frequency is
always 25 kHz on POTS cards, and 138 kHz on ISDN cards.
The beginning of the first DS band is shifted accordingly (no spectrum overlap).
When the optional band usage is disabled, this parameter still fixes the
beginning of the normal DS band. It is assumed 138 kHz if no value, or if the
special 0 kHz value is configured.
Instances Line
Values 0 kHz, 138..1104 kHz
Table TNG 107-22: US power backoff mode
Name US Power Backoff Mode
Description Specifies the upstream power backoff mode:

PBO Off (PBO with Transmit PSD Mask): The VTU directly uses the US
PSD Mask parameter (see above) as the transmit PSD mask.
PBO On (PBO with Receive PSD Mask): The VTU derives the transmit PSD
mask from the US Power BackOff PSD Mask parameter.
Instances Line US
Values psdPboOff
psdPboOn
Table TNG 107-23: DS G.hs tones power mode
Name DS G.hs tones power mode
Description This parameter determines the mode of DS tones used during G.hs
(handshake) sequence. It is defined as an array of 4 mode values: one per
possibly used DS tone set in VDSLx mode: A43, B43, A43c, and V43:
GhsPSDMode = [GhsPSDMode_A43; GhsPSDMode_B43;
GhsPSDMode_A43c; GhsPSDMode_V43]
The following possible modes are defined:
The special value default is translated as the maximum power allowed in
the ITU-T G.994.1 standard for that tone set.
The special value manual is fetched from the DS G.hs tones power
manual level requirements.
The special value automatic is translated as the maximum power derived
from the configured Tx DS PSD (see MGMT_R11.1.1for VDSL1 or
MGMT_R11.2.1for VDSL2), according to the following formula and table:
If fi is the frequency of the middle tone of the tone set #i, if xi is the
maximum DS template PSD allowed by the MIB at frequency fi, then the
power of each tone of the tone set #i is:
Pi = 36.35 + min(max(xi + 3, mi), Si), where:
Si is the maximum standard value for tone set #I, and
mi is the minimum PSD floor, defined in Table TNG 107-24.
An NSIF field is introduced for V43 back off communication from VTU-O to
VTU-R. If the final derived value falls below the minimum value handled by the
G.994.1 standard for the considered set, that minimum allowed value is used.
Instances Line
Values {default; automatic; manual}
Table TNG 107-24: Minimum PSD Floor
Tone set i Si Si in conservative

mode(1)
A43 TBD dBm/Hz -65 dBm/Hz
B43 TBD dBm/Hz -70 dBm/Hz

A43c TBD dBm/Hz -70 dBm/Hz
V43 TBD dBm/Hz -70 dBm/Hz
Note
(1) Alcatel-Lucent will determine if the conservative mode shall be used or not. This has to be hardcoded
in the chipset implementation.
Table TNG 107-25: DS G.hs tones power manual level
Name DS G.hs tones power manual level
Description This parameter determines the maximum power of DS tones used during G.hs
(handshake) sequence, in case the manual mode is selected. It is defined as an
array of 4 PSD values: one per possibly used DS tone set in VDSLx mode: A43,
B43, A43c, and V43:
GhsPSD = [manual_A43; manual_B43; manual_A43c; manual_V43]
Each value is given in dBm/Hz. The power of each tone of a considered set is
equivalent to the given PSD value integrated in a total bandwidth of 4.3125 kHz.
One special value is defined: the value -99 dBm/Hz indicates that the full set is
not used (that is, no power allowed).
Instances Line
Values -99..-40 dBm/Hz
Granularity & Unit 0.5 dBm/Hz

All parameters grouped under this requirement have a common for all DSL flavours
supported in Alcatel-Lucent DSLAM products (including VDSL and VDSL2). However,
the configured value, assigned by the operator, can be flavor dependent. Consequently,
all parameters will have several instances: one per flavor.
Modem features
Maximum aggregate transmit power
PSD ceiling
Custom MIB PSD Mask
US Power BackOff PSD:
US power backOff PSD mask selection
US power backOff PSD AB parameters
US power backoff PSD full custom parameters
Table TNG 107-26: Modem features
Name Modem Features
Description Specifies modem features which can be allowed or not by the operator.
Currently, only bit 0 (LSB) of this bitmap is interpreted by the VDSLx modem
subsystem.
BIT0 Standard Compliancy: if active (1), the modem subsystem must turn off
all features not strictly compliant to the standard. If not active (0), the modem
subsystem is allowed to use non-standard features, via the NSIF G.hs bits.
Instances Line
Values Bitmap
Table TNG 107-27: Maximum aggregate transmit power
Name Maximum Aggregate Transmit Power
Description Specifies the maximum total power level that is allowed to be transmitted in the
corresponding direction.
This parameter is used to reduce the maximum allowed PSD derived
from Custom MIB PSD Mask, VDSL 1 Limit Tx PSD mask or VDSL 2 Limit Tx
PSD mask.
Note that this parameter overrules maximum aggregate Tx power standard
restrictions, except if the special value standard is configured.
The special value standard is used as special value:
For VDSL1:
If the selected PSD is referring to a predefined PSD, then the maximum
aggregate transmit power defined in the corresponding DSL standard
must be used, in accordance with the deployment type PSD: FTTEx or
FTTCab.
Otherwise (customized PSD): no power limitation has to be applied.
For VDSL2:
The applicable maximum power constraint is the one corresponding to
the selected VDSL2 profile.

Values -31..25.4 dBm or standard
Granularity & Unit 0.1 dBm
Table TNG 107-28: PSD ceiling
Name Maximum PSD (1)
Description The PSD ceiling parameter specifies the maximum power spectral density level
allowed on the line at the transmitter output (upstream and downstream) for
initialization and showtime signals.
This parameter shall be used to further restrict the maximum Tx PSD mask
derived from Custom MIB PSD Mask, VDSL 1 Limit Tx PSD mask or VDSL 2
Limit Tx PSD mask.
The value no_constraint is used as special value, which avoids restrictions to
the maximum Tx PSD mask.
Note that this parameter is defined on the PSD template, not on the PSD mask.
Values 0..-95.5 dBm/Hz or no_constraint
Note
(1) The Maximum PSD parameter cannot be used to boost the PSD beyond the configured LimitTxPSD
and MIB Mask (See Custom MIB PSD Mask, VDSL 1 Limit Tx PSD mask or VDSL 2 Limit Tx PSD
mask), it can only be used to put additional constraints, i.e. to further lower the PSD. The modem
supports extended maximum PSD range under to -80 dBm/Hz.
Table TNG 107-29: Custom MIB PSD Mask
Name Custom MIB PSD Mask
Description Specifies custom PSD Mask.

Specifies the maximum transmit PSD allowed for the corresponding direction on
a VDSLx line
In VDSL1 mode, this parameter will be missing, in case a predefined limit Tx
PSD mask other than psdMaskCustom is defined (see VDSL 1 Limit Tx PSD
mask).
In VDSL2 mode, this parameter can be missing, in case a predefined limit Tx
PSD mask other than psdMaskCustom is defined (see VDSL 2 Limit Tx PSD
mask).
If neither this parameter nor a Tx limit pre-defined PSD mask is configured, the
configuration shall be rejected.
If both this parameter and a Tx limit PSD mask is configured, the modem shall
take the minimum of the two masks, tone per tone (VDSL2 only).
The PSD mask is made by connecting the points with straight lines, considering
a linear PSD axis in [dBm/Hz], and either a linear, either a logarithmic frequency
axis in [Hz], depending on the psdFreqScale parameter.
The PSD has to be considered as a Mask or a Template, depending on the
PsdType parameter.
Values Up to 20 PSD points can be specified and are supported for US

Up to 32 PSD points can be specified and are supported for DS
PSD point = [Frequency, PSD value]
Frequency: 0..12000 kHz
PSD value: -25 to -127.5 dBm/Hz
For VDSL2, the following rules apply:

Each breakpoint used to specify the MIB PSD mask consists of a
sub-carrier index tn and a PSD mask value PSDn at that sub-carrier
expressed in dBm/Hz. The sub-carrier indices are derived from the given
frequency in Hz, by selecting a close sub-carrier, assuming f = 4.3125
kHz sub-carrier spacing (i.e., independent of the sub-carrier spacing
actually used (see Actual tone spacing). The term a close is translated as
the nearest located on or above the point for lower band edges, as the
nearest located on or below the point for higher band edges, and as the
nearest for all other points.
Breakpoints for each utilized band are internally represented as the set [(t1,
PSD1), (t2, PSD2), , (tn, PSDn), (tN, PSDN)]. The value of t1 corresponds
to the lowest-index sub-carrier in the band, and the value of tN corresponds
to the highest-index sub-carrier in the band. The MIB PSD mask is a
concatenation of the sets of breakpoints for all utilized bands.
(1 of 2)
Values For VDSL1, the following rules apply:

(continued) The successive PSD points must have increasing (>) frequencies.
It is allowed that for two successive PSD points, different PSD levels are
defined at the same frequency f (brickwall):
point x: PSDx, f
point x+1: PSDx+1,f
For the latter case, conversion to discrete carriers C(i) is done as follows:
1) in case of an increasing PSD level (PSDx+1 > PSDx)
- If C(i-1) < f < C(i): point x: PSDx, C(i-1)
point x+1: PSDx+1, C(i)
- If f = C(i): point x: PSDx, C(i)
point x+1: PSDx+1, C(i+1)
2) in case of a decreasing PSD level (PSDx+1 < PSDx)
- If C(i-1) < f < C(i): point x: PSDx, C(i-1)
- If f = C(i): point x: PSDx, C(i-1)
PsdFreqScale is lin or log.

PsdType is Mask or Template
Granularity & Unit 0.1 dBm/Hz for PSD value

1 kHz for Frequency
PsdFreqScale and PsdType are boolean
(2 of 2)
Table TNG 107-30: US power backOff PSD mask selection
Name US Power BackOff PSD
Description Specifies the maximum receive PSD allowed for the US direction on a VDSLx
line in case of psdPboOn (see US power backoff mode), ignored otherwise.
The VDSLx modem subsystem checks consistency between the PSD Mask
settings and other configuration parameters. If not consistent, the configuration
is rejected by raising the Configuration Error failure (for example, the modem
subsystem rejects configurations with inconsistent DS and US PSD mask
settings).
Instances US Power BackOff
(1 of 2)
Values Following special configurations are supported:

PsdMaskABParameters (see also US power backOff PSD AB parameters)
psdMaskFullCustom (See also US power backoff PSD full custom
parameters)
Following masks are supported:

psdMaskANSI_A
psdMaskANSI_F
psdMaskANSI_CustomEx (1)
psdMaskANSI_CustomCab (1)
psdMaskETSI_A
psdMaskETSI_B
psdMaskETSI_C
psdMaskETSI_D
psdMaskETSI_E
psdMaskETSI_F
psdMaskETSI_CustomEx (1)
psdMaskETSI_CustomCab (1)
Remarks:
The ANSI noise profiles are not defined yet for types B, C, D and E. The
modem subsystem rejects the configuration of those ones.
The ETSI UPBO masks for noise types A and B are the same.
The modem subsystem rejects the configuration if an ANSI UPBO mask is
used together with the ETSI operating mode, and vice versa (VDSL1 only).
The _CustomEx/Cab masks allow the modem subsystem to use
customized and pre-defined UPBO masks for specific deployment
scenarios.
(2 of 2)
Note
(1) This psdMask is outphasing
Table TNG 107-31: US power backOff PSD AB parameters
Name US Power BackOff PSD AB Parameters

Description Specifies the a and b values in order to compute the PSDREF to be used for
USPBO.
If US Power Back Off is psdMaskABParameters, it is applied as follows:
PSDREF(f) = -(a + b f)
They are structured as an array [a b], f is the frequency in MHz.

This parameter is only used when the mask selection is set to
PsdMaskABParameters (see US power backOff PSD mask selection).
Instances US Power BackOff (per upstream Bands)
Values [40..80.95; 0..40.95]

Granularity & Unit 0.01 dBm/Hz; 0.01 dBm/Hz
Table TNG 107-32: US power backoff PSD full custom parameters
Name US Power BackOff PSD Full Custom Parameters
Description This parameter is only used when the mask selection is set to
psdMaskFullCustom (see US power backOff PSD mask selection).
US Power BackOff PSD Full Custom Mask is only supported for VDSL1.
Instances US Power BackOff (per upstream Bands)
Values [40..80.95; 0..40.95]
Granularity & Unit 0.01 dBm/Hz; 0.01 dBm/Hz
Flavor-specific configuration parameters

The following parameters are VDSL1 specific:
VDSL 1 Limit Tx PSD mask

Fx band plan frequency
Table TNG 107-33: VDSL 1 Limit Tx PSD mask
Name Limit Tx PSD Mask
Description For DS and US: specifies the maximum transmit PSD allowed for the
corresponding direction on a VDSL1 line.
A pre-defined set of standard PSD masks is defined. It is the responsibility of
the VDSL1 modem subsystem to translate the PSD Mask number into the
standard definition.
The VDSL1 modem subsystem checks consistency between the PSD Mask
settings).
(1 of 2)
Values psdMaskCustom: custom defined PSD Mask (see Custom MIB PSD Mask)
Line DS/US:
psdMaskANSI_FTTEx_M1
psdMaskANSI_FTTEx_M2
psdMaskANSI_FTTCab_M1
psdMaskANSI_FTTCab_M2
psdMaskANSI_FTTCab_M1_ADSL: FTTCab.M1 used for US
psdMaskANSI_FTTCab_M2_ADSL: FTTCab.M2 used for US
psdMaskANSI_FTTCab_M1_ADSL2+: FTTCab.M1 used for US
psdMaskANSI_FTTCab_M2_ADSL2+: FTTCab.M2 used for US
Remarks:
The modem subsystem rejects the configuration if another band plan than
998 has been selected in combination with ANSI PSD masks.
The modem subsystem rejects the configuration if the ETSI Operating
Mode has been selected in combination with those ANSI PSD masks.
psdMaskETSI_PexP1.M1: P.M1 used for US

psdMaskETSI_Pcab.M1: P.M1 used for US
psdMaskETSI_Pcab.M2: P.M2 used for US
psdMaskETSI_PcabX.M1_ADSL: P.M1 used for US
psdMaskETSI_PcabX.M2_ADSL: P.M2 used for US
psdMaskETSI_Pcab.M1_ADSL2+: P.M1 used for US
psdMaskETSI_Pcab.M2_ADSL2+: P.M2 used for US
psdMaskETSI_PexP2.M2_ADSL_Sample1: P.M2 used for US
Remarks:
The modem subsystem uses the value of the Optional Band Mode
parameter whether to use one of both variants for the P.M1 and P.M2 US
masks.
The modem subsystem uses the value of the ADSL Band Mode parameter
whether to use variant A or B for the Pcab masks.
The modem subsystem uses the value of the VDSLx Band Plan parameter
whether to use the 998 or 997 variants of the ETSI PSD masks.
The modem subsystem rejects the configuration if another band plan than
998 or 997 has been selected in combination with ETSI PSD masks.
The modem subsystem rejects the configuration if the ANSI Operating
Mode has been selected in combination with those ETSI PSD masks.
(2 of 2)
Table TNG 107-34: Fx band plan frequency
Name Fx Band Plan Frequency
Description Specifies Fx frequency in case of bandPlanC band plan, ignored otherwise.
Instances Line
Values 3750..12000
The following parameters are VDSL2 specific:
VDSL 2 Limit Tx PSD mask

US Power Back-off electrical length override
Virtual Noise PSD
Virtual Noise SNRM_MODE
US0 mode restriction
Erasure detection in INP
Table TNG 107-35: VDSL 2 Limit Tx PSD mask
Name Limit Tx PSD Mask

Description For DS and US: specifies the maximum transmit PSD allowed for the
corresponding direction on a VDSL2 line.
A pre-defined set of standard PSD masks is defined. It is the responsibility of
the VDSL2 modem subsystem to translate the PSD Mask number into the
standard definition.
The VDSL2 modem subsystem checks consistency between the PSD Mask
settings).
(1 of 2)
Values psdMaskCustom: custom defined PSD Mask (see Custom MIB PSD Mask).
In this case, there is no limit mask (unlimited), and the maximum Tx PSD
mask envelope is determined by the Custom MIB PSD mask.
PsdMaskRegionA: refers to North American standard Annex A
Remarks:
Detailed PSD Mask for region A can be derived from the MGMT_R9.34
parameter, which fixes US0/DS1 transition frequency.
PsdMaskRegionB_M1
PsdMaskRegionB_M2: refers to European standard Annex B
Remarks:
Detailed PSD Mask for region B has to be used in combination with
the Predefined band plan parameter to check validity.
Detailed PSD Mask for region B can be derived from other parameters.
The modem subsystem shall reject the configuration if another band
plan than 998 or 997 has been selected in combination with ETSI PSD
masks.
PsdMaskRegionC: refers to Japanese standard Annex C
PsdMaskRegionC corresponds to the G993.2 [5] AnnexC (Japan region)
and shouldnt be misinterpreted as the G993.1 [4] AnnexC. It is also
associated to the BandPlanAext band plan (see Band plan).
(2 of 2)
Table TNG 107-36: US Power Back-off electrical length override
Name US Power Back-off electrical length override

Description This parameter tells the VTU-O to override the kl0 (electrical length) estimated
by the VTU-R.
One special value is defined: the value electricalLengthEstimated indicates
that the US Power Back-off electrical length estimated by the VTU-T is not
overwritten by the VTU-O.
Instances Line
Values 0..127.5; Electrical Length Estimated

Default Value is Electrical Length Estimated
Note: We consider here that electrical length is positive when the loop gain is
negative in dB (smaller than one in linear).
Granularity & Unit 0.1 dB @ 1 MHz
Table TNG 107-37: Virtual Noise PSD
Name Virtual Noise PSD
Description TXREFVNL defines the Transmitter Referred Virtual Noise Level to be used in
determining the SNR margin. It is defined as an array of 32 breakpoints for
downstream bands and 16 breakpoints for upstream ones.
Breakpoints definition is identical to the VDSL2 MIB PSD defined in Custom MIB
PSD Mask. Points are given in frequency [kHz] and PSD [dBm/Hz] components,
and are translated to sets of arrays per US band: TXREFVNL[..] [] = [(t1, PSD1),
(t2, PSD2), , (tN, PSDN)], where t1 and tN are, respectively, the lower and
higher band edge frequencies of the band. Arrays are then concatenated to
make one unique array.
When the VTU operates with 8.625 kHz sub-carrier spacing, all odd sub carriers
are converted by the VTU, to the closest even value, and values t1 and tN are
rounded (up and down, respectively) to even values.
Instances Line
Values PSD component of breakpoint: -40 dBm/Hz..-140 dBm/Hz

Special Value (default):NoVirtualNoise (- dBm/Hz)
Frequency component of breakpoint: 0..30000 kHz
Granularity & Unit 1 kHz; 0,5 dBm/Hz
Table TNG 107-38: Virtual Noise SNRM_MODE
Name Virtual Noise SNRM_MODE
Description Selects the reference noise PSD that shall be considered when evaluating the
noise margin.
Instances US, DS
Values SNRM_MODE_1: the reference noise PSD is the external noise PSD
present at U interface.
SNRM_MODE_2: the reference noise PSD is the maximum (tone per tone)
between the external noise PSD present at U interface and the received
virtual noise derived from parameter Virtual Noise PSD.
Note:
If SNRM_MODE_2 for US is selected, and the virtual noise is not supported
by the VTU-O, the VTU-O raises a configuration error failure.
If SNRM_MODE_2 for DS is selected, and the virtual noise is not supported
by the VTU-R, the VTU-O falls back to DS SNRM_MODE_1, and proceeds
normally.
Table TNG 107-39: US0 mode restriction
Name US0 mode restriction
Description This parameter allows the operator to forbid some US0 modes.
Contain the following data structure: MaskContent, Mode, and
NoMatchBehaviour
MaskContent:
Three 32 bits words, one per VDSL2 annex:
W0 = a31 a30 a29 ... a2 a1 a0 for VDSL2 annex A
W1 = b31 b30 b29 ... b2 b1 b0 for VDSL2 annex B
W2 = c31 c30 c29 ... c2 c1 c0 for VDSL2 annex C
The MSB (that is, the bit #31) of each word is ignored (the applicable VDSL2
annex type is derived from the selected VDSL 2 Limit Tx PSD mask).
Other mode bits are mapped to G.994.1 US0 octets of the corresponding
annex, from LSB to MSB: G.994.1 octet #k shall be mapped to bits x(k-1)*6
-> xk*6-1.
Bits not explicitly mapped to G.994.1 mode are ignored.
Mode:
Indicates how to restrict US0 modes:
disabled: no restriction applies (MaskContent is ignored).
mask: the MaskContent bitmap defines a mask to be applied on top of
the negotiated US0 mode capabilities (that is, a cleared bit indicates a
forbidden mode).
NoMatchBehaviour:
Defined what to do when, after the restriction, there is no matching US0
mode:
noUS0: no match: US0 is turned off (standard behavior).
noInit: no match: the initialization sequence is aborted, and the modem
raises a configuration not feasible failure.
Instances Line
Values See above.
Table TNG 107-40: Erasure detection in INP
Name Erasure detection in INP
Description When VTUs select internal FEC and interleaving parameters according to
configured minimum INP and maximum interleaver delay, fixes whether the
Erasure detection mechanism has to be ignored or not.
Instances Bearer US, DS
Values When set to 1, it indicates that the VTU receiver shall select framing parameters
so that INP_no_erasurep > INP_minConfigured. This means that the minimum
configured INP (together with maximum interleaver delay) will already be
achieved with the erasure detection mechanism disabled.
When set to 0, it indicates that VTUs receivers are not required to select framing
parameters that ensures INP_no_erasurep > INP_minp. In all cases, the VTU-R
receiver meets the requirement, INPp > INP_minConfigured.
This applies to all latency paths.
Unit Binary (0/1)

The Initialization value is the parameter value when entering the showtime (L0) state.
Consequently, the value has to be derived during initialization. The Showtime value is the
(current if updated) parameter value during the showtime state. The Update frequency is
the update frequency of the parameter during showtime (L0) state.
The VDSLx Modem Subsystem assures that the Showtime values (if applicable for the
considered parameter) are available for retrieval over the xDSL API within 10 seconds
after entering the L0 state. During the first 10 seconds of the L0 state, the VDSL Modem
Subsystem returns the Initialization values (if applicable for the considered parameter) if
the Showtime value for the considered parameter is not available yet.
The following operational data parameters are supported:
Current operational mode

Operational mode capabilities
SNR margin
Loop attenuation
Signal attenuation
Aggregate output power
Actual average PSD
Last state transmitted
Attainable line bitrate
Actual line bitrate
Line relative capacity occupation
Attainable transport bitrate (per bearer channel)
Actual transport bitrate (per bearer channel)
Actual interleaving delay (per bearer channel)
Actual impulse noise protection (per bearer channel)
Actual TPS-TC mode
TPS-TC mode capabilities
Actual tone spacing
Actual US PBO electrical length
Actual VTU-R timing advance
Actual highest frequency used
Actual sub-carrier group size
Actual maximum PSD
VDSL2 annex modes capabilities
VDSL2 actual standard limit PSD
VDSL2 limit PSD mapping
Actual DS virtual noise SNRM_MODE
Actual use of Trellis Coding
Actual used cyclic extension
Actual framing parameters
Table TNG 107-41: Current operational mode
Name Current Operational Mode
Description The operational mode used for the current operation of the VDSLx modem
subsystem (see Operating modes).
Instances Line
Values See Operating modes. Only 1 bit can be set to 1 at a time.
Initialization value Defined during configuration and G.hs.

Update frequency NA
Table TNG 107-42: Operational mode capabilities
Name Operational mode Capabilities
Description The total set of operational modes supported by the VTU-O and the VTU-R
respectively.
Instances Near-end/Far-end
Values See Operating modes.
Update frequency NA
Table TNG 107-43: SNR margin
Name SNR Margin
Description Indicates the current showtime noise margin: the maximum increase (in dB) of
the reference noise PSD (at all relevant frequencies), such that the BER of each
TPSTC stream does not exceed the maximum BER specified, without any
change of PMD parameters (that is, bits and gains) and PMS-TC parameters
(for example, FEC parameters). The BER is referenced to the output of the
PMS-TC function (that is, the / interface). * the maximum increase (in dB) of
the reference noise power that can be tolerated such that the VTU can still meet
the target BER requirement.
The reference noise PSD, in VDSL2 mode, does not correspond with the total
(internal + external) noise.
The SNR Margin in a given band shall assume a PSD noise increase in the
relevant band only.
Instances Global DS/US for VDSLx, and per band for VDSL2 on top (including US0 band).
Values -64..+63 dB
Update frequency DS: each = 10 seconds via EOC @ VTU-O

US: each < 10 seconds @ VTU-O
Table TNG 107-44: Loop attenuation
Name Loop Attenuation
Description The difference in dB between the power received at one end and that
transmitted at the opposite end over all subcarriers during initialization. It is not
updated during showtime.
Instances Global US for VDSLx

Global DS, and on top per band for VDSL2 (including US0/DS0 band).
Values 0..102.3 dB
Note: when the actual loop attenuation is exceeding an extremum value that can
be represented, clamping to this extremum representable value is done.
Accuracy 0.5 dB
Update frequency NA
Table TNG 107-45: Signal attenuation
Name Signal Attenuation
transmitted at the opposite end over all subcarriers during showtime. It
corresponds to the Line Attenuation as defined in G.997.1, 7.4.4/5.
Note: difference with Loop Attenuation is that the transmit power has changed
for the subcarriers and that the total number of subcarriers during showtime
typically will be less than during initialization.
Instances Global US for VDSLx

Global DS, and on top per band for VDSL2 (including US0/DS0 band).
Values 0..102.3 dB

Table TNG 107-46: Aggregate output power
Name Aggregate Output Power
Description Actual aggregate output power (that is, the total output power for the carriers of
the corresponding direction) when the modem is in showtime.
Instances DS/US
Values -31..+31 dBm

Note: when the actual aggregate transmit power is exceeding an extremum
value that can be represented, clamping to this extremum representable value
is done.
Accuracy 1 dB (maximum admissible deviation with actual measured value)
Update frequency DS: each bit swap

US: each bit swap
Table TNG 107-47: Actual average PSD
Name Aggregate average PSD
Description Actual Average (in dB) Transmit power spectrum density over the loaded
subcarriers.
Instances DS/US
Values -95..0 dBm/Hz.
A special value Out of Range indicates the parameter is out of range to be
represented.
Accuracy 0.1 dBm/Hz

Update frequency DS/US: each bit swap
Table TNG 107-48: Last state transmitted
Name Last state transmitted
Description This parameter represents the last successful transmitted (VTU-O instance)
and received (VTU-R instance) SOC message ID during initialization sequence
in the relevant direction, in the last full initialization performed on the line.
Thus, initialization states are defined as the SOC message code IDs.
Instances DS (VTU-O)/US (VTU-R)
Values 0x0 -> 0xFF
Granularity & Unit 1
Update frequency Not Applicable
Table TNG 107-49: Attainable line bitrate
Name Attainable Line Bitrate
Description Indicates the maximum bitrate the modem can sustain on the line (that is, the
transported payload plus all overhead from the PMD (If a Trellis encoder would
be used, the overhead shall be included in the Attainable Line Bitrate), PMS-TC
and TPS-TC layers) taking the current configuration into account (for example,
the Attainable Line Bitrate assumes that the current interleaver and coding
settings are not changed). If multiple bearer channels are active, the calculation
assumes that all capacity would be allocated to the bearer channel with the
highest coding gain.
The value only depends on the actual noise margin on the line.
Instances DS/US
Values 0..65535
Remark: in case of no EOC, the initialization value for Attainable DS Line Bitrate
is returned.
Granularity & Unit 1 kbps

Table TNG 107-50: Actual line bitrate
Name Actual Line Bitrate

Description The line rate corresponding to the Actual transport Bitrate (that is, the actual
transported payload plus all overhead information from the PMD (If a Trellis
encoder would be used, the overhead shall be included in the Attainable Line
Bitrate), PMS-TC and TPS-TC layers). The line rate is given by the number of
bits per DMT symbol, multiplied with the number of DMT symbols per second,
divided by 1000 (kbps).
Instances DS/US
Values 0..262143
Update frequency NA
Table TNG 107-51: Line relative capacity occupation
Name Line Relative Capacity Occupation
Description The ratio of the Actual Line Bitrate and the Attainable Line Bitrate when both are
available.
In case of an activation error Configuration not feasible, it is set to 100 % for
each direction where the minimum bitrate cannot be sustained.
Instances DS/US
Values 0..100%
(1 of 2)
Update frequency DS: derived from Actual and Attainable Line Bitrate
US: derived from Actual and Attainable Line Bitrate
(2 of 2)
Table TNG 107-52: Attainable transport bitrate (per bearer channel)
Name Attainable transport Bitrate
Description Indicates the maximum net data bitrate (that is, transported payload plus
TPS-TC layer overhead) the VTU can sustain on the line taking the current
configuration into account, with margin not lower than Target Noise Margin. This
parameter is provided for each activated bearer channel. The calculation
estimates the attainable transport Bitrate assuming that all available capacity is
allocated to that bearer channel and that current interleaver and Reed-Solomon
settings are not changed.
The value depends on the actual noise margin on the line.
Instances Per bearer channel
Values 0..262143

Table TNG 107-53: Actual transport bitrate (per bearer channel)
Name Actual transport Bitrate
Description The actual transport rate (that is, the transported payload plus header bytes)
expressed in kbps.
Values 0..262143
Update frequency NA
Table TNG 107-54: Actual interleaving delay (per bearer channel)
Name Actual Interleaving Delay
Description Actual delay caused by the interleaving and coding functionality.
Values 0..63
Update frequency NA
Table TNG 107-55: Actual impulse noise protection (per bearer channel)
Name Actual Impulse Noise Protection
Description Actual value of the impulse noise protection offered by the interleaving and
coding functionality.
Values 0..16 DMT symbols

Note: Care should be taken to the Carrier Spacing (see also Actual tone
spacing)
Granularity & Unit 0.1 DMT symbols
Update frequency NA
Table TNG 107-56: Actual TPS-TC mode
Name Current TPS-TC Mode
Description The TPS-TC layer mode used for the current operation of the VDSLx modem
subsystem.
Instances Per line
Values Same bitmap as TPS-TC mode capabilities. Only 1 bit can be set to 1 at a time.
Update frequency NA
Table TNG 107-57: TPS-TC mode capabilities
Name TPS-TC Mode Capabilities

Description The total set of TPS-TC modes supported by the VTU-O and the VTU-R
respectively.
Instances Line Near-end/Far-end
Values Bitmap:
TPSTCModesATMBit
TPSTCModesPTM_64_65Bit
TPSTCModesPTM_HDLCBit
Update frequency NA
Table TNG 107-58: Actual tone spacing
Name Current Tone Spacing
Description DMT tone spacing currently used by the PMD layer.
Instances DS/US
Values Bitmap:
SingleToneSpacingBit
DoubleToneSpacingBit
Update frequency NA
Table TNG 107-59: Actual US PBO electrical length
Name Actual US Power Back-off electrical length
Description Estimated modem kl0 (electrical length).

For VTU-R instance, gives the electrical length estimated by the VTU-R.
For VTU-O instance, gives the final values set by the VTU-O (can be identical if
VTU-O does not correct it).
Instances VTU-R/VTU-O
Note: We consider here that electrical length is positive when the loop gain is
negative in dB (smaller than one in linear).
This is data is only available in VDSL2 operational mode.
Values 0..127.5
Granularity & Unit 0.1 dB @ 1 MHz
Table TNG 107-60: Actual VTU-R timing advance
Name Actual VTU-R Timing Advance
Description Defines the VTU-R timing advance. Positive values indicates that the
transmitted symbol will be advanced more with respect to the received symbol.
The VTU-R instance represents the initial TA as proposed by the VTU-R, and
the VTU-O instance represents the final VTU-R TA value, after VTU-O
correction (if any).
Instances Line VTU-R and VTU-O

This is data is only available in VDSL2 operational mode.
Values -250..+250
Granularity & Unit 10 ns
Accuracy +/- 25 ns
Table TNG 107-61: Actual highest frequency used
Name Actual Highest Frequency used
Description Defines the highest carrier for which the SNR is sufficient, such that the bit
loading allocates at least 1 bit.
Rounding rule: Value is rounded to the lowest frequency bigger or equal to the
highest used carrier.
Instances US/DS
Values 0..30000
Table TNG 107-62: Actual sub-carrier group size
Name Actual Sub-Carrier Group Size
Description Defines the sub-carrier spacing used in some carrier related test parameters.
In VDSL1 mode, the report value shall always be 1.
Instances US/DS
Values 1, 2, 4, or 8.
Unit Number of carriers
Table TNG 107-63: Actual maximum PSD
Name Actual Maximum PSD
Description Actual Maximum Transmit power spectrum density over the loaded subcarriers.
Instances US/DS
Values -95..0
A special value Out of Range indicates the parameter is out of range to be
represented.
Accuracy 0.1 dBm/Hz
Table TNG 107-64: VDSL2 annex modes capabilities
Name VDSL2 Annex modes capabilities
Description VDSL2 Annex capability bitmap.

Contain three 32 bits words, one per VDSL2 annex:
W0 = a31 a30 a29 ... a2 a1 a0 for VDSL2 annex A
W1 = b31 b30 b29 ... b2 b1 b0 for VDSL2 annex B
W2 = c31 c30 c29 ... c2 c1 c0 for VDSL2 annex C
The MSB (that is, the bit #31) of each word is set if the VTU supports the
corresponding annex.
Other mode bits are mapped to G.994.1 US0 octets of the corresponding annex,
from LSB to MSB: G.994.1 octet #k shall be mapped to bits x(k-1)*6 -> xk*6-1.
Instances VTU-O/VTU-R
Values Three times 32 bits word: [W2, W1, W0], according to parameter description
above.
Table TNG 107-65: VDSL2 actual standard limit PSD
Name VDSL2 Actual Standard Limit PSD
Description Returns the actual applicable ITU-T.993.2 ([5]) standard limit PSD mask,
including the US0 mode/variant.
The returned data are three 32 bits words, and a limit PSD indicator: [W2, W1,
W0, M].
The first three words (Mx) identify the actual standard annex and US0
mode/variant, following the format defined in VDSL2 annex modes capabilities.
Up to one word has raised bits: the word associated with the actual standard
annex. In this word, the MSB (that is, the bit #31) is raised, together with up to
one other bit identifying the actual US0 mode.
The PSD indicator (M) identifies the actual limit PSD mask, taken from
Table TNG 107-66
The unknown answer type is used when the transceiver does not find any
match with standard PSDs, or when no direct match is found (that is, short name
if PSD is NONE).
The other answer type is used when a match is found with the current
standard, but the corresponding PSD or Annex is missing from the PSD list.
(see Table TNG 107-66).
Instances Line
Values Three times 32 bits word: [W2, W1, W0], according to parameter description
above.
Table TNG 107-66: VDSL2 limit PSD mapping
Annex PSD
- Invalid
- Unknown
- Other Annex
A Unknown in Annex A
A Other in Annex A
A PSD mask for operation over POTS

A PSD mask for all-digital mode operation
B Unknown in Annex B
B Other in Annex B
B 997-M1c-A-7
B 997-M1x-M-8
B 997-M1x-M
B 997-M2x-M-8
B 997-M2x-A
B 997-M2x-M
B 998-M1x-A
B 998-M1x-B
B 998-M1x-NUS0
B 998-M2x-A
B 998-M2x-M
B 998-M2x-B
B 998-M2x-NUS0
C Unknown in Annex C
C Other in Annex C
C PSD mask for operation above POTS
C PSD mask for operation above TCMISDN
Table TNG 107-67: Actual DS virtual noise SNRM_MODE
Name Actual DS Virtual Noise SNRM_MODE
Description VDSL2 only

This operational data is matched with DS configuration parameter Virtual Noise
SNRM_MODE when the VTU-R support virtual noise. Otherwise, it shall be
SNRM_MODE1.
Instances DS
Values SNRM_MODE1, SNRM_MODE2
Table TNG 107-68: Actual use of Trellis Coding
Name Actual Use of Trellis Coding
Description Indicates the actual use of Trellis coding.
Instances DS/US
Values 0: Not used

1: Used
Granularity & Unit Boolean.
Table TNG 107-69: Actual used cyclic extension
Name Actual Used Cyclic Extension
Description Indicates the actual cyclic extension used on the line (in showtime).
Instances Line
Values 2, 3, 4, 5, , 16.
Granularity & Unit Unit of N/32 samples, where 2*N is the IFFT size.
Table TNG 107-70: Actual framing parameters
Name Actual Framing Parameters
Description Indicates the following actual used framing parameters, per bearer. and linked
to the latency path that carries that bearer:
Nfec: actual size of Reed Solomon codeword
Rfec: actual number of Reed Solomon redundancy bytes
Lsymb: actual number of bits per symbol assigned to the latency path
transporting the bearer (excluded Trellis overhead)
Dintlv: actual interleaving depth
Iintlv: actual interleaving block length
Values Nfec: bytes, ranging from 0 to 255. The value 0 indicates no Reed Solomon
coding.
Rfec: bytes, ranging from 0 to 16. The value 0 indicates no Reed Solomon
coding.
Lsymb: bits (per symbol), ranging from 0 to 65536.
Dintlv: ranges from 1 to 4096. The value 1 indicates no interleaving.
Iintlv: ranges from 4 to 255, plus the 1 value that indicates no interleaving.
Granularity & Unit See Values.
Introduction
This training document gives more information about the parameters used by the SHDSL
modem:
Supported span operation configuration parameters
Supported unit operation configuration parameters
Supported segment termination operation configuration parameters
Supported span operational data parameters
Supported unit operational data parameters
Supported segment termination operational data parameters
During showtime (L0 line state), the SHDSL Modem Subsystem performs
re-initialization triggers. Table TNG 108-1 lists them for the SHDSL Transceiver Unit at
the Central office side (STU-C) and includes the required persistency time for each
showtime error.
Near-End Far-End

(f)se 10 1 sec 10 1 sec

The SHDSL Modem Subsystem triggers/initiates re-activation of the modem when any of
those triggers is fired. No other re-initialization triggers (annex timer values) are used by
the Modem Subsystem than the ones mentioned in Table TNG 108-1.
All far-end count-down timers are frozen when any near-end defect occurs. When all
near-end defects have disappeared, far-end count-down timers resume from frozen
values (ignoring the in-between time).
All near-end defects are correlated independent from each other. The same holds for all
far-end defects in absence of near-end defects.
Supported span operation configuration parameters

The SHDSL Modem Subsystem accepts the configuration parameters listed hereunder.
Based on the required levels, the required modem reaction on each parameter is:
In case a parameter is indicated as optional, the input value is dont care, and any
In case a parameter is indicated to be required to a certain level (for example, only
subsystem raises a failure indication to the xDSL Manager indicating Configuration
Error
parameters and the configuration should be rejected, 'rejection' always means that
the modem subsystem raises a failure indication to the SHDSL Manager indicating
Configuration Error, rather that a returned error of the considered SHDSL API call.
An SHDSL API configuration request is replied with an error only when the call is done
The SHDSLx Modem Subsystem allows that the configuration can be independently set
on individual line basis.
M-pair (1 < M < 4) stands for a multiple-pair operation over SHDSL span for some
applications having higher data rate requirements for end users.
Four-wire mode is identical to M-pair mode with M = 2, except for the method of assigning
ordinal numbers to the wire pairs.
Data Rates: M-pair operational mode is capable of supporting user (payload) data
rates from M *192 kbit/s to M *2.312 Mbit/s in increments of M * 8 kbit/s, where 1 < M
< 4. Note that optional extensions described in Annex F/G allow user data rates up to
M *5696 kbit/s. Four-wire mode is identical to M-pair mode with M = 2, except for the
method of assigning ordinal numbers to the wire pairs.
Embedded Operations Channel (EOC): For optional M-pair operation, each EOC
message is sent in parallel such that redundant and identical messages are sent over
all M loops. In M-pair mode, eoc01 - eoc20 on Pair 1 carries the primary EOC data.
The corresponding Pair 2 to Pair M eoc bits are duplicates of the Pair 1 eoc bits.
SHDSL Transceiver Unit at the Remote side (STU-R) Power Status: In M-pair mode,
ps on Pair 1 carries the primary power status indication. The ps bit on all other pairs
are duplicates of the Pair 1 ps bit.
Power Feeding/Wetting Current: In the optional M-pair mode, the requirements for
remote power feeding or wetting current for each of the M pairs are identical to the
requirements for a single pair.
Activation Procedure: In devices supporting the optional M-pair mode, the core
activation procedure is considered as an independent procedure for each pair. Such
devices are capable of detecting the completion of activation for all pairs and upon
completion will initiate the transmission of user data over all pairs.
Line Probe: In the optional M-pair mode, STU-R remote probe signal Pri and STU-C
central probe signal Pci are sent in parallel on all wire pairs.
G.994.1: In the optional 4-wire mode, Pair 1 and Pair 2 are determined during the
preactivation sequence procedures defined in Annex B/G.994.1 entitled, Operation
over multiple wire pairs. Pair 1 is defined as the pair on which the final G.994.1
transaction is conducted. In the optional M-pair mode, the G.994.1 exchange follows
the defined procedures for multi pair operation.
Operating Modes
Table TNG 108-1 describes the operating modes parameter.
Table TNG 108-2: Operating Modes
Description Specifies which operational protocol/standard are applicable for a span:

(1) ATM-Native
(2) ATM-IMA (ATM Forum)
(3) PTM-64/65B
(4) PTM-HDLC
The standards that need to be supported for the current projects are listed in
SHDSL_R24.
Operational modes not supported by the STU-C shall be ignored (that is, they
are not considered selected).
Multiple mode selection is not allowed.
The operational mode is selected by the SHDSL Manager before startup the
line, each lines operational mode are independent to the other lines, with
exception of M-pair mode which requires all lines belong to a M-pair
configuration in the same operational mode.
Operational modes are not exchanged by G.hs.
The modem rejects the configuration and raises the Configuration error
activation failure in the following scenarios:
No mode is selected (or no STU-C supported mode is selected)
In IMA Mode, Minimum and Maximum Requested Data Rates are to be set to
the same value, which would be the same for all links in the IMA group. For this
reason, the IMA mode selection and Group assignment needs to be made at the
same time as the initial provisioning.
IMA is not supported over M-pair links.
Instances Span
Values shdsl_native_mode
shdsl_ima_mode
shdsl_efm_mode
Number of Repeaters
Table TNG 108-2 describes the number of repeaters parameter.
Table TNG 108-3: Number of Repeaters
Name Number of Repeaters
Description Configures the number of SRU (repeater) units to be configured for this SHDSL
span. It controls the number of SRU (repeater) entries in the unit configuration.
Instances Span
(1 of 2)
Values 0-8
(2 of 2)
Spectral Profile
Table TNG 108-3 describes the spectral profile parameter.
Table TNG 108-4: Spectral Profile
Name SHDSL Spectral Profile
Description Specifies the spectral mode in which this SHDSL span is to be configured with.
Two options are supported:
AsymmetricProfile
SymmetricProfile
In case of AsymmetricProfile the valid data rates are restricted as follows:

Region 1/Annex A/M-pair: M * 768 kb/s & M * 1536 kb/s
Region 2/Annex B/M-pair: M * 2048 kb/s & M * 2304 kb/s
Examples:
Annex A/2-Wire: 768 kb/s & 1536 kb/s
Annex A/4-Wire: 1536 kb/s & 3072 kb/s
Annex B/2-Wire: 2048 kb/s & 2304 kb/s
Annex B/4-Wire: 4096 kb/s & 4608 kb/s
Instances Span
Values symmetricProfile
asymmetricProfile
Wire Mode
Table TNG 108-4 describes the wire mode parameter.
Table TNG 108-5: Wire Mode
Name Wire Mode
Description Specifies whether 2-Wire or 4-Wire or 6-Wire or 8-Wire operation is in place.

The supported wire mode depend on the actual lines of modem ASIC.
IMA is not supported over M-pair links.
The modem rejects the configuration and raise the Configuration error
No wire mode is selected (or no STU-C supported mode is selected)
IMA operational mode is selected for multi-wire operation
Instances Span
(1 of 2)
Values shdsl_two_wire
shdsl_four_wire
shdsl_six_wire
shdsl_eight_wire
(2 of 2)
Support Management from STU-R

Table TNG 108-5 describes the support management from STU-R parameter.
Table TNG 108-6: Support Management from STU-R
Name Managed from STU-R
Description Specifies whether the STU-R initiated management flow is enabled/disabled by

the STU-C.
Instances Span
Values disabled
enabled
Regional Setting
Table TNG 108-6 describes the regional setting parameter.
Table TNG 108-7: Regional Setting
Name Regional Setting
Description Specifies the regional setting for the SHDSL line per the ITU-T G.992.1
Annexes (Annex A/F and Annex B/G).
Region 1 - G.991.2 Annex A/F
Region 2 - G.991.2 Annex B/G
Only a single setting (region 1 or region 2) can be provisioned.

In Asymmetric Spectral Profile Mode, the regional setting cannot be modified.
The modem rejects the configuration and raises the Configuration error
No region is selected (or no STU-C supported region is selected)
Region 1 and region 2 are selected together
Instances Span
Values BitMap:
Bit Setting
--- ---------
0 Region 1
1 Region 2
Minimum and Maximum Data Rate

Table TNG 108-8 and Table TNG 108-9 describe the minimum and maximum requested
data rate parameters.
Table TNG 108-8: Minimum Requested Data Rate
Name Minimum Requested Data Rate
Description Defines the minimum requested transport payload bitrate which shall be set up
and which shall be maintained during showtime by the STU.
When line probe is enabled, the SHDSL line is probed for levels between this rate
and the maximum requested data rate. The Line will not be activated at a lower
rate.
Only ATM/EFM Mapping is supported, this limits the resulting data rates to
multiples of 64k (192 to 5696) in TwoWire mode; and to multiples of 128k (384 to
11,392) in FourWire mode, to multiples of 192k (576 to 17,088) in SixWire mode,
to multiples of 256k (768 to 22,784) in EightWire mode.
In IMA Mode, Minimum and Maximum Requested Data Rates are to be set to the
same value which would be the same for all links in the IMA group. This result in
a constraint to use exact 64 kb/s multiples in provisioning.
Instances Span
Values 2-wire: 192 to 5696 in multiple of 64, and 2312

4-wire: 384 to 11,392 in multiple of 128
Granularity & Unit 64 kbit/s * M (pair number)
Table TNG 108-9: Maximum Bitrate
Description Specifies the maximum requested SHDSL data rate which can range from 192 to
5696 kb/s in Two Wire mode, plus the rate of 2312; and from 384 to 11.392 kb/s
in FourWire mode; from 576 to 17,088 kb/s in SixWire mode; from 768 to 22.784
kb/s in EightWire mode
The SHDSL line is probed for levels between this rate and the minimum
requested data rate. The Line will not be activated at a higher rate.
Only the ATM/EFM Mapping is supported, this limits the resulting data rates to
multiples of 64k (192 to 5696) in TwoWire mode; and to multiples of 128k (384 to
11.392) in FourWire mode, to multiples of 192k (576 to 17.088) in SixWire mode,
to multiples of 256k (768 to 22.784) in EightWire mode.
In IMA Mode, Minimum and Maximum Requested Data Rates are to be set to the
same value which would be the same for all links in the IMA group. This result in
a constraint to use exact 64 kb/s multiples in provisioning.
This parameter is relevant only in line probe enabled mode. When line probe is
not enabled, the Maximum Bitrate parameter is ignored.
As the data rate granularity is in multiple of 64 kbps, the following rounding
scheme for Minimum and Maximum Bitrates is implemented:
The Minimum Bitrate is rounded up and the Maximum Bitrate is rounded
down according to the data rate granularity when for the corresponding
direction Maximum Bitrate Minimum Bitrate after rounding.
Otherwise, both bitrates are rounded up and Minimum Bitrate = Maximum
Bitrate after rounding up.
The SHDSL modem subsystem raises failure indication Configuration Error for
configurations where Maximum Bitrate < Minimum Bitrate for one of the
directions when line probe is enabled.
Instances Span
Values 2-wire: 192 to 5696 in multiple of 64, and 2312
4-wire: 384 to 11.392 in multiple of 128
Granularity & Unit 64 kbit/s * M (pair number)
Worst Case Downstream Target Noise Margin

Table TNG 108-10 describes the worst case downstream target noise margin parameter.
Table TNG 108-10: Worst Case Downstream Target Noise Margin
Name Worst Case Downstream Target Noise Margin
Description Specifies the Target Margin in the Downstream direction, relative to the
reference Worst Case, to be used during handshake and line-probe procedure
in gauging a Bit Error Rate (BER) better than 1E-7.
Target margin is used by the receiver to determine if a data rate can be
supported with this margin under current noise measured during line probe
and/or reference worst-case noise specified in Annexes A and B. A data rate
may be included in the capabilities list resulting from line probe only if the
estimated Signal-to-Noise Ratio (SNR) associated with that data rate minus the
SNR required for BER = 1E-7 is greater than or equal to the target margin in dB.
If both worst-case target margin and current-condition target margin are
specified, then the capabilities exchanged shall be the intersection of data rates
calculated using each noise condition separately.
The use of negative target margins with respect to reference worst-case noise
corresponds to reference noise with fewer disturbers. This may be applicable
when the number of disturbers is known to be substantially fewer than specified
by the reference worst-case noise. Use of negative target margins with respect
to current conditions is not advised. Use of the current-condition target margin
mode may result in retrains if the noise environment changes significantly.
The negotiation of the target margins is done as follows:
The target margins to be used by both the STU-C and the STU-R for
determining the supported data rates are under the control of the STU-C. In the
PMMS parameter exchange, the STU-C shall set the upstream and
downstream PMMS target margins to identical values. This does not imply that
the worst-case and current-conditions target margins are the same.
To determine which data rates the STU-C can support, the STU-C can choose
to use the upstream PMMS target margin transmitted by the STU-R in the
PMMS parameter exchange, or the STU-C may choose to use an alternative
internal value for the PMMS target margins. The STU-R shall use the
downstream PMMS target margin parameters sent by the STU-C for
determining which data rates the STU-R can support. This procedure is
applicable to both the current-condition and the worst-case target margins.
In M-pair operation, the same Downstream Target Noise Margin is used on all
pairs.
A value of -11 indicates not to use the Worst Case method in the downstream
direction.
Instances Span
Values -11to 10
Granularity & Unit 1 dB
Current Case Downstream Target Noise Margin

Table TNG 108-11 describes the current case downstream target noise margin
parameter.
Table TNG 108-11: Current Case Downstream Target Noise Margin
Name Current Case Downstream Target Noise Margin
Description Specifies the Target Margin in the Downstream direction, relative to the Current
noise conditions, to be used during handshake and line-probe procedure in
gauging a BER better than 1E-7.
estimated SNR associated with that data rate minus the SNR required for BER
= 1E-7 is greater than or equal to the target margin in dB. If both worst-case
target margin and current-condition target margin are specified, then the
capabilities exchanged shall be the intersection of data rates calculated using
each noise condition separately.
pairs.
direction.
Instances Span
Values -11to 10
Worst Case Upstream Target Noise Margin

Table TNG 108-12 describes the worst case upstream target noise margin parameter.
Table TNG 108-12: Worst Case Upstream Target Noise Margin
Name Worst Case Upstream Target Noise Margin
Description Specifies the Target Margin in the Upstream direction, relative to the reference
Worst Case, to be used during handshake and line-probe procedure in gauging
a BER better than 1E-7.
pairs.
direction.
Instances Span
Values -11to 10
Current Case Upstream Target Noise Margin

Table TNG 108-13 describes the current case upstream target noise margin parameter.
Table TNG 108-13: Current Case Upstream Target Noise Margin
Name Current Case Upstream Target Noise Margin
Description Specifies the Target Margin in the Upstream direction, relative to the Current
noise conditions, to be used during handshake and line-probe procedure in
gauging a BER better than 1E-7.
pairs.
direction.
Instances Span
Values -11to 10
Line Probe Enable

Table TNG 108-14 describes the line probe enable parameter.
Table TNG 108-14: Line Probe Enable
Name Line Probe Enable
Description Specifies support for Line Probe (rate adaptation) of the units in a SHDSL line.
When Line Probe is enabled, the system performs Line Probing to find the best
possible rate. If Line probe is disabled, the rate adaptation phase is skipped to
shorten set up time.
Instances Span
Values disabled
enabled
Granularity & Unit
Supported unit operation configuration parameters
Loop Attenuation Threshold

Table TNG 108-15 describes the loop attenuation threshold parameter.
Table TNG 108-15: Loop Attenuation Threshold
Name Loop Attenuation Threshold
Description Specifies the Loop Attenuation Threshold Value in dBs, for generated
associated alarms.
A value of 0 disables alarm generation.
Instances Unit
Values 0-127
SNR Margin Threshold

Table TNG 108-16 describes the SNR margin threshold parameter.
Table TNG 108-16: SNR Margin Threshold
Name SNR Margin Threshold
Description Specifies the SNR Margin Threshold Value in dBs, for generated associated
alarms.
A value of 0 disables alarm generation.
Instances Unit
Values 0-15
Loopback Timeout
Table TNG 108-17 describes the loopback timeout parameter.
Table TNG 108-17: Loopback Timeout
Name Loopback Timeout
Description Specifies the Loopback Timeout duration in minutes.

A value of 0 disables timeout.
Instances Unit
(1 of 2)
Values 0-4095
Granularity & Unit 1minute
(2 of 2)
Supported segment termination operation configuration parameters
Loopback Configuration
Table TNG 108-18 describes the loopback configuration parameter.
Table TNG 108-18: Loopback Configuration
Name Loopback Config
Description Specifies the loopbacks for the associated side of an SHDSL unit.
Only Network Side loopbacks are supported for SRU and STU-R units
Instances Segment Termination
Values NoLoopback
NormalLoopback
Power Backoff Mode

Table TNG 108-19 describes the power backoff mode parameter.
Table TNG 108-19: Power Backoff Mode
Name Power Backoff Mode
Description Specifies the Power Backoff rule at the associated Segment Termination.
Values Default
Selected
Soft Restart
Table TNG 108-20 describes the soft restart parameter.
Table TNG 108-20: Soft Restart
Name Soft Restart
Description Initiate a Soft Restart message towards the relevant segment termination.
When the value of this object is set from 0 to 1, a Soft Restart EOC message is
initiated. After 5 minutes the value of the object is automatically set back to 0.
Values 0 (Normal Operation)

1 (Soft Restart)
Supported span operational data parameters

The Initialisation value is the parameter value when entering the active/data/showtime
(Operational Up) state. Consequently, the value has to be derived during initialisation.
The Showtime value is the (current if updated) parameter value during the active/data
state. The Update frequency is the update frequency of the parameter during
active/data/showtime (Operational Up) state.
The SHDSL Modem Subsystem assures that the Showtime values (if applicable for the
considered parameter) are available for retrieval over the SHDSL API within 10 seconds
after entering the Operational Up state. During the first 10 seconds of the Operational Up
state, the SHDSL Modem Subsystem returns the Initialisation values (if applicable for the
considered parameter) if the Showtime value for the considered parameter is not
available yet.
Span State
Table TNG 108-21 describes the span state parameter.
Table TNG 108-21: Span State
Name Span State
Description Indicates the overall state of this SHDSL span
Instances Span
Values unknown
unequipped
faulty
idle
startup
active
(1 of 2)
Initialization value Idle
Showtime value: Active
Update frequency NA
(2 of 2)
Detected Units
Table TNG 108-22 describes the detected units parameter.
Table TNG 108-22: Detected Units
Name Detected Units
Description Indicates the units that have been detected on this SHDSL span, bits are set(1)
for detected units.
Instances Span
Values Bitmap:
Bit Unit
--- ------
0 STU-C
1 STU-R
2 SRU-1
3 SRU-2
4 SRU-3
5 SRU-4
6 SRU-5
7 SRU-6
8 SRU-7
9 SRU-8
Initialization value NA
Showtime value: Derived from EOC
Update frequency NA
Configured Units
Table TNG 108-23 describes the configured units parameter.
Table TNG 108-23: Configured Units
Name Configured Units
Description Indicates the units in the SHDSL span which have been successfully
configured, bits are set (1) for units which have been successfully configured.
Instances Span
Values Bitmap:
Bit Unit
--- ------
0 STU-C
1 STU-R
(1 of 2)
Update frequency NA
(2 of 2)
Span Status
Table TNG 108-24 describes the span status parameter.
Table TNG 108-24: Span Status
Name Span Status
Description Indicates the overall status of this SHDSL span.

Status conditions are associated with individual SHDSL segments. This object
represents collective span status by logically-OR-ing individual segment status
bits.
Instances Span
Values Bitmap:
Bit Condition
--- ---------
0 No Error
1 LOSW
2 Loop Attenuation Alarm
3 SNR Margin Alarm
4 DC Continuity Fault
5 Device Fault
6 Configuration Error
7 Loopback(s) Active
8 Non-Conform to STU-C Enable/Disable of STU-R Initiated Management
Flow
9 ATM LCD/PTM LPD
10 Loss of Power
11 ATM NCD/PTM NPD

Update frequency NA
Wire Pair Assignment

Table TNG 108-25 describes the wire pair assignment parameter.
Table TNG 108-25: Wire Pair Assignment
Name Wire Pair Assignment
Description Provides the correlation between the actual ports and their dynamic designation
as fistPair and secondPair and thirdPair and fourthPair (if M>2 is supported) as
a result of the pre-activation sequence in a modem ASIC. (firstPair is defined as
the pair on which the final G.994.1 transaction is conducted)
For 4-wire mode:
00000100b: if the first port is the first pair, second port is the second pair
00000001b: if the second port is the first pair
6-wire mode examples:

00100100b: if the first port is the first pair, second port is the second pair,
third port is the third pair
00010010b: if the second port is the first pair, third port is the second pair
00001001b: if the third port is the first pair, first port is the second pair
8-wire mode examples:

11100100b: if the first port is the first pair, second port is the second pair,
third port is the third pair, fourth port is the fourth pair
10010011b: if the second port is the first pair
01001110b: if the third port is the first pair
00111001b: if the fourth port is the first pair
Instances Span
Values Bitmap:
Bit Condition
--- ---------
1,0 wirePair of the 1st modem ASIC port for 6/8-wire, 1st/3rd numbered port
for 4-wire
3,2 wirePair of the 2nd modem ASIC port for 6/8-wire, 2nd/4th numbered port
for 4-wire
5,4 wirePair of the 3rd modem ASIC port for 6/8-wire, set to 0 for 4-wire
7,6 wirePair of the 4th modem ASIC port for 8-wire, set to 0 for 4/6-wire
wirePair value
---------- --------
1stPair 00
2ndPair 01
3rdPair 10
4thPair 11
Update frequency NA
Supported unit operational data parameters

state, the SHDSL Modem Subsystem returns the Initialisation values (if applicable for the
considered parameter) if the Showtime value for the considered parameter is not
available yet.
Unit Operational Data only exist for those units that are configured as indicated by the
shdslSpanConfiguredUnits, and which support SHDSL EOC Performance Status
messages defined in ITU-T G.991.2[1].
Unit DC Powering
Table TNG 108-26 describes the unit DC powering parameter.
Table TNG 108-26: Unit DC Powering
Name Unit DC Powering
Description Indicates whether this unit is powered locally, or derives power from the SHDSL
span.
Instances Unit
Values LocalPowered
spanPowered
Update frequency NA
Supported segment termination operational data parameters

state, the SHDSL Modem Subsystem shall return the Initialisation values (if applicable for
the considered parameter) if the Showtime value for the considered parameter is not
available yet.
Segment Termination Operational Data only exist for those units that are configured as
indicated by the shdslSpanConfiguredUnits, and which support SHDSL EOC
Performance Status messages defined in ITU-T G.991.2[1].
Segment Termination Status

Table TNG 108-27 describes the segment termination status parameter.
Table TNG 108-27: Segment Termination Status
Name Segment Termination Status
Description Indicates any exception conditions active at this SHDSL segment termination
Values Bitmap:
Bit Condition
--- ---------
0 No Error
1 LOSW
2 Loop Attenuation Alarm
3 SNR Margin Alarm
4 DC Continuity Fault
5 Device Fault
6 Configuration Error
7 Loopback(s) Active
8 Non-Conform to STU-C Enable/Disable of STU-R Initiated Management
Flow
9 ATM LCD/PTM LPD
10 Loss of Power
11 ATM NCD/PTM NPD
Update frequency NA
Loopback State
Table TNG 108-28 describes the loopback state parameter.
Table TNG 108-28: Loopback State
Name Loopback State
Description Indicates any loopback active at this SHDSL segment termination.

In M-pair mode, the loopbacks can only be set-up and torn-down simultaneously
on all pairs.
Values noLoopback
normalLoopback
specialLoopback
Initialization value noloopback

Update frequency NA
SNR Margin
Table TNG 108-29 describes the SNR margin parameter.
Table TNG 108-29: SNR Margin
Name SNR Margin

Description Indicates the currently measured SNR Margin in dB at this SHDSL segment
termination.
A value of 127 indicates that this information is unavailable.
Values -128 to 127 dB

Accuracy 1 dB
Initialization value DS: passed via initialization messages

US: locally at the STU-C
Showtime value: DS: passed via EOC
Remark: In case no EOC, the initialization value for the DS SNR Margin shall be
returned.
US: local at the STU-C
Update frequency DS: each = 10 seconds via EOC @ STU-C

US: each < 10 seconds @ STU-C
Loop Attenuation
Table TNG 108-30 describes the loop attenuation parameter.
Table TNG 108-30: Loop Attenuation
Description Indicates the currently measured Loop Attenuation in dB at this SHDSL

segment termination.
A value of -128 indicates that this information is unavailable.
Values -128 to 127 dB
Accuracy 1 dB
Initialization value US: Measured during initialization.

DS: Not Available
Showtime value: NA
Update frequency NA
Power Backoff Level

Table TNG 108-31 describes the power backoff level parameter.
Table TNG 108-31: Power Backoff Level
Name Power Backoff Level
Description Indicates the current Power Backoff value in dB at this SHDSL segment
termination.

Values 0 to 31 dB
Accuracy 1 dB

DS: Not Available
Showtime value: NA
Update frequency NA
Tip Ring Reversal

Table TNG 108-32 describes the tip ring reversal parameter.
Table TNG 108-32: Tip Ring Reversal
Name Tip Ring Reversal
Description Indicates the current state of the Tip/Ring pair at this SHDSL segment
termination.
Values normal
reversed
Accuracy -

DS: Not Available
Showtime value: NA
Update frequency NA
Power Backoff Status

Table TNG 108-33 describes the power backoff status parameter.
Table TNG 108-33: Power Backoff Status
Name Power Backoff Status
Description Indicates the Power Backoff status at this SHDSL segment termination.
This value indicates the mode that will be selected at the next reset.

Values default
selected
Accuracy -

DS: Not Available
Showtime value: NA
Update frequency NA
TNG 109 Performance management
counters
Introduction
This TNG document is not used for Release 3.3, but is reserved for future releases.
TNG 109 Performance management counters
Introduction
This TNG provides configuration examples for:
Basic management connectivity

Equipment planning
DSL profile creation and assignment
Basic data traffic
Multicast
802.1x authentication
Both ADSL and VDSL port configuration examples are provided. Unless otherwise
specified, the examples in this TNG apply to both the 7302 ISAM and 7330 ISAM FTTN.
Note The examples in this TNG use the command repetition (also
called ranging) feature of CLI. This feature can be used to execute a
command over a group of ports. See the 7302 ISAM | 7330 ISAM FTTN
CLI Commands document for more information about command
repetition.
Parameters for examples

All of the examples in this TNG assume that the NE has the following settings.
The name of the NE is ISAM-1.

The NE has the following LT units:
two VDSL LT units, LT1 and LT2
two multi-ADSL LT units, LT3 and LT4
The IP address of the NE is 192.168.1.1.
The default gateway address (netmask) of the NE is 192.168.1.254.
The management network is attached to port 1 of the NT unit.
The management network is assigned to VLAN 4093.
Basic management connectivity

This section shows an example of the steps required to configure the network
connectivity of the NE for remote management using telnet.
1 Give the NE a name:

configure system id ISAM-1
2 Enable single IP address mode. See the 7302 ISAM | 7330 ISAM FTTN System
Description document for more information about single IP address mode.
3 Set the IP address and default gateway address on the NE:
manual:192.168.1.1/24
4 Configure the network management port on the NT unit:
configure interface shub port 1 port-type network admin-status
auto-up
5 Attach the management VLAN to the network management port on the NT unit:
6 If the management network is untagged, configure the network management as
untagged:
You can now manage the NE remotely using telnet.
Equipment planning
This section shows an example of the steps required to plan the equipment of an NE.
This example assumes that the NE is a 7330 ISAM FTTN ARAM-D shelf with the
following cards installed:
GENC-E interface unit

PWIO-B general facilities card
two EVLT-A VDSL LT units (LT1 and LT2) with VPSC-D appliques
two EBLT-C multi-ADSL LT units (LT3 and LT4) with HLPC-H appliques
The configuration procedure is as follows:
1 Plan the GENC-E:

configure equipment slot 1/1/1 planned-type genc-e unlock
2 Plan the LT units:
Note In CLI, LT1 is identified as 1/1/4, LT2 as 1/1/5, LT3 as 1/1/6, and
LT4 as 1/1/7.
configure equipment slot 1/1/4 planned-type evlt-a unlock

configure equipment slot 1/1/5 planned-type evlt-a unlock
configure equipment slot 1/1/6 planned-type eblt-c unlock
3 Plan the PWIO-B and the appliques:
configure equipment applique 1/1/2 planned-type pwio-b
configure equipment applique 1/1/4 planned-type vpsc-d
configure equipment applique 1/1/5 planned-type vpsc-d
configure equipment applique 1/1/6 planned-type hlpc-h
The equipment is now planned and ready for further configuration.
DSL profile creation and assignment

This section shows examples of the steps required to configure and assign profiles for
multi-ADSL and VDSL service.
Configure and assign VDSL profiles:

1 Configure a VDSL spectrum profile. This profile is called g993_vdsl11 and supports
only VDSL without upstream power backoff.
configure xdsl spectrum-profile 1 name g9931_vdsl1 dis-etsi-dts
dis-ansi-t1413 dis-g992-1-a dis-g992-1-b dis-g992-2-a
dis-g992-3-a dis-g992-3-b dis-etsi-ts itu-g993-1
2 Configure the VDSL options for the profile, such as band plan and upstream power
backoff mode:
configure xdsl spectrum-profile 1 vdsl vdsl-band-plan
band-plan-a4 optional-band up adsl-band allow-adsl
max-agpowlev-down 145 max-agpowlev-up 145 psd-shape-down
ansi-ftt-cab-m2 psd-shape-up ansi-ftt-cab-m2 pbo-mode-down
rx-psd-shape-up ansi-a
3 Activate the spectrum profile:
4 Configure a service profile for 25 Mb/s downstream and 3 Mb/s upstream service.
The profile is called 25Mpbs_3Mbps.
configure xdsl service-profile 1 name 25Mbs_3Mbps
min-bitrate-down 32 min-bitrate-up 32 plan-bitrate-down 512
plan-bitrate-up 512 max-bitrate-down 25024 max-bitrate-up 3008
max-delay-down 8 max-delay-up 8 imp-noise-prot-dn 10
imp-noise-prot-up 10
5 Activate the service profile:
6 Assign the spectrum and service profiles to the VDSL ports and put the ports in
service:
For a single port, use the following command:
For a range of ports, use the following commands:
configure xdsl line 1/1/4/[1...24] service-profile 1
If all the physical connections are made, you can now train a VDSL modem on LT1 and
LT2.
Configure and assign multi-ADSL profiles:

1 Configure a spectrum profile. The profile is called multi_adsl and supports ADSL,
ADSL2, READSL, and ADSL2+.
configure xdsl spectrum-profile 2 name multi_adsl g992-3-l1
g992-3-l2 g992-3-am g992-5-a
2 Activate the spectrum profile:
3 Configure a service profile for 15 Mb/s downstream and 1 Mb/s upstream service.
The profile is called 15Mpbs_1Mbps and has minimum delay and impulse noise
protection configured.
configure xdsl service-profile 2 name 15Mbps_1Mbps
min-bitrate-down 32 min-bitrate-up 32 plan-bitrate-down 1024
plan-bitrate-up 256 max-bitrate-down 15360 max-bitrate-up 1024
max-delay-down 1 max-delay-up 1 imp-noise-prot-dn 0
imp-noise-prot-up 0
4 Activate the service profile:
5 Assign the spectrum and service profiles to the multi-ADSL ports and put the ports in
service:
For a single port, use the following command:
For a range of ports, use the following commands:
If all the physical connections are made, you can now train a multi-ADSL modem on LT3
and LT4.
Basic data traffic

This section shows examples of the steps required to configure a basic data service using
the iBridge and cross-connect VLAN models.
To configure basic data traffic, you must:
configure the VLANs

assign bridge ports to the VLANs; this step assigns a VLAN ID and a PVID to each
bridge port.
The following parameters must be defined for each port:
vlan-id; the vlan-id parameter makes the port a member of the VLAN so traffic can
flow through the system
pvid; the pvid parameter is used to place the untagged Ethernet frames from the xDSL
port into the correct VLAN; by default, all traffic is sent toward the end user with no
VLAN tag
max-unicast-mac; the max-unicast-max parameter limits the number of devices that
can be active on a bridge port
Configure basic data traffic for the iBridge VLAN model

The iBridge model, also known as residential bridging mode, allows multiple DSL ports
to belong to the same VLAN. iBridge VLANs also enforce some rules regarding
user-to-user communication within the shelf and broadcast message control. See the
7302 ISAM / 7330 ISAM FTTN System Description document for more detailed
information about iBridge VLANs.
This example assumes that the NE has the following settings.
The data traffic is carried on network port 2.

The VDSL ports, LT1 and LT2, are connected to VLAN 101.
The multi-ADSL ports, LT3 and LT4, are connected to VLAN 102.
Note Multi-ADSL and VDSL ports can be members of the same

VLAN. In this example, they are part of separate VLANs for the sake of
clarity.
1 Configure the data traffic network port:

up
2 Create the VDSL and multi-ADSL VLANs on the SHub:
configure vlan shub id 101 mode residential-bridge
3 Assign the data traffic and VDSL ports to VLAN 101 on the SHub. This ensures the
traffic is bridged from the network port to the appropriate VDSL LT unit.
4 Assign the data traffic and multi-ADSL ports to VLAN 102 on the SHub. This ensures
the traffic is bridged from the network port to the appropriate multi-ADSL LT unit.
5 Create the VLANs on the NT subsystem:
configure vlan id 101 mode residential-bridge
6 For each multi-ADSL port, create an ATM PVC that matches the PVC configured on
the multi-ADSL modem. This step is not required for VDSL ports.
For a single port on each LT unit, use the following command:
For a range of ports on each LT unit, use the following commands:
configure atm pvc 1/1/6/[148]:8:35
7 Create the bridge port for each xDSL port. You must specify a vpi:vci identifier for
each multi-ADSL port. This step is not required for VDSL ports.
configure bridge port 1/1/4/[1...24]
configure bridge port 1/1/6/[1...48]:8:35
8 Assign all VDSL ports to VLAN 101:

configure bridge port 1/1/4/[1...24] vlan-id 101
configure bridge port 1/1/4/[1...24] pvid 101 max-unicast-mac 4
configure bridge port 1/1/5/[1...24] vlan-id 101
configure bridge port 1/1/5/[1...24] pvid 101 max-unicast-mac 4
9 Assign all multi-ADSL ports to VLAN 102:
configure bridge port 1/1/6/[1...48]:8:35 vlan-id 102
configure bridge port 1/1/6/[1...48]:8:35 pvid 102
max-unicast-mac 4
configure bridge port 1/1/7/[1...48]:8:35 vlan-id 102
configure bridge port 1/1/7/[1...48]:8:35 pvid 102
max-unicast-mac 4
The system can now pass data traffic. Data traffic from the VDSL ports is carried out of
the system on VLAN 101 and traffic from the multi-ADSL ports is carried out of the system
on VLAN 102. Figure TNG 110-1 shows an example of the traffic flow from the network
to the VDSL ports on LT1 for the iBridge VLAN model.
Figure TNG 110-1: Example of traffic flow for iBridge VLAN model
SHub VLAN 101 with egress Bridge port mapping VLAN to

ports to network and LT1 VDSL ports on LT1
NT
LT1
SHub
3
It:1/1/4 BP 1
VLAN 101 CPE
2 VLAN 101
BP 24
1
CPE
Backplane connection All ports members

between NT and LT of same VLAN 101
VLAN tagged Ethernet Frames

18725
Configure basic data traffic for the cross-connect VLAN model

The cross-connect model enforces a one-to-one mapping of VLANs to VDSL ports or to
ATM PVCs. See the chapter on layer 2 forwarding in the 7302 ISAM / 7330 ISAM FTTN
System Description document for more detailed information about cross-connect VLANs.
The data traffic is carried on network port 2.

The ports are connected as follows:
ports on VDSL LT unit LT1 are connected to VLANs 101 to 124.
ports on VDSL LT unit LT2 are connected to VLANs 201 to 224.
ports on multi-ADSL LT unit LT3 are connected to VLANs 301 to 348.
ports on multi-ADSL LT unit LT4 are connected to VLANs 401 to 448.
1 Configure the data traffic network port:

up
2 Create the VDSL and multi-ADSL VLANs on the SHub:
configure vlan shub id [101124] mode cross-connect
3 Assign the data traffic and xDSL ports to the appropriate VLANs on the SHub. This
ensures the traffic is bridged from the network port to the appropriate LT unit:
assign the VDSL ports on LT1 to VLANs 101 to 124:
configure vlan shub id [101124] egress-port network:2
configure vlan shub id [101124] egress-port lt:1/1/4
assign the VDSL ports on LT2 to VLANs 201 to 224:
assign the multi-ADSL ports on LT3 to VLANs 301 to 348:
assign the multi-ADSL ports on LT4 to VLANs 401 to 448:
4 Create the VLANs on the NT subsystem:
configure vlan id [101124] mode cross-connect
5 For each multi-ADSL port, create an ATM PVC that matches the PVC configured on
the multi-ADSL modem. This step is not required for VDSL ports.
For a single port on each LT unit, use the following commands:
For a range of ports on each LT unit, use the following commands:
6 Create the bridge port for each xDSL port. You must specify a vpi:vci identifier for
each multi-ADSL port. This step is not required for VDSL ports.
7 Assign each VDSL port on LT1 to the corresponding VLAN:
configure bridge port 1/1/4/1 pvid 101 max-unicast-mac 4
...
8 Assign each VDSL port on LT2 to the corresponding VLAN:
...
9 Assign each multi-ADSL port on LT3 to the corresponding VLAN:

configure bridge port 1/1/6/1:8:35 pvid 301 max-unicast-mac 4
...
10 Assign each multi-ADSL port on LT4 to the corresponding VLAN:
...
The system can now pass data traffic. Data traffic from each xDSL port is carried out of
the system on a separate VLAN. Figure TNG 110-1 shows an example of the traffic flow
from the network to the VDSL ports on LT1 for the cross-connect VLAN model.
Figure TNG 110-2: Example of traffic flow for cross-connect VLAN model
SHub VLANs 101 to 124 Bridge port mapping VLANs to

with egress ports to VDSL ports on LT1
network and LT1
NT VLAN101
LT1
SHub VLAN 101
VLAN 101
3 It:1/1/4 BP 1
CPE
2 VLAN 124
BP 24
VLAN 124 1
CPE
Backplane connection VLAN 124

between NT and LT
VLAN tagged Ethernet Frames
18726
Multicast
This example shows one of the ways you can configure multicast for a 7302 ISAM or
7330 ISAM FTTN. Multicast is the transmission from a single device (such as an IPTV
host) to a group of recipients (such as xDSL subscribers). See the
information on multicast.
The system is configured for basic data traffic using the cross-connect VLAN model.
This configuration allows for all multicast traffic to be delivered to the NE on a single
VLAN separate from the VLAN configured on the subscriber bridge port. The system
then connects the subscriber to a multicast group and forwards it to the subscriber
VLAN when the subscriber requests the group using IGMP. See the
information about multicast and IGMP.
All multicast traffic is delivered on network port 2, with a VLAN ID of 10.
The multicast sources available to subscribers are 224.1.1.1 to 224.1.1.100.
There is an IGMP router connected to the NE on network port 2.
The NE is not required to restrict multicast connections based on bandwidth.
The IP addresses used by the NE for IGMP messaging are:
toward the subscribers: 192.168.1.1
toward the network: 10.10.10.1
1 Configure VLAN 10 on the SHub so that multicast traffic can be delivered to all LT
units:
configure vlan shub id 10 egress-port lt:1/1/[47]
2 Configure VLAN 10 on the NT subsystem:
3 Configure the multicast source table on the NE. This table contains the list of all
multicast groups available to subscribers and the corresponding VLAN group for
each multicast group.
configure mcast src 224.1.1.[1100] vlan-id 10
atm-peak-bit-rate 0 atm-sus-bit-rate 0
4 Configure the system to disallow the joining of unconfigured multicast groups for
iBridge subscribers:
configure mcast general no package-member [1...1024]
configure mcast capacity max-num-uncfg 0
5 Set the maximum number of unique groups that can be active on a single LT unit:
configure mcast capacity max-num-group 256
6 Start the IGMP system and configure the IP address used for IP messaging toward
the subscribers and the SHub. This address is not used for messaging toward the
router.
configure igmp system src-ip-address 192.168.1.1 start
7 Configure the VLAN IP address used for IGMP messaging toward the upstream
router:
8 Enable snooping on the SHub:
configure igmp shub igs-system enable-snooping
9 Configure the port and VLAN ID connection for the router upstream of the NE:
configure igmp shub vlan-router-port 10 network-port 2
query-timer 125
10 Disable the snooping filter on the multicast VLAN. This step enables snooping on the
VLAN.
configure igmp shub vlan-filter 10 no snoop-filter
11 Enable the snooping filter on the subscriber VLANs. This disables snooping on the
VLANs, since there should be no IGMP on these VLANs.
configure igmp shub vlan-filter [101124] snoop-filter
12 Enable IGMP on the subscriber interface and limit the maximum number of multicast
groups to which a subscriber can belong at any one time:
configure igmp channel 1/1/4/[1...24] max-num-group 10
configure igmp channel 1/1/5/[1...24] max-num-group 10
configure igmp channel 1/1/6/[1...48]:8:35 max-num-group 10
configure igmp channel 1/1/7/[1...48]:8:35 max-num-group 10
Subscribers can now join configured multicast groups from xDSL ports using IGMP.
802.1x authentication
This example shows how to set up 802.1x authentication. See the
information about 802.1x authentication on a 7302 ISAM or 7330 ISAM FTTN.
The system is configured for basic data traffic using the iBridge or cross-connect
VLAN model.
A RADIUS server is available upstream of the NE.
The RADIUS server is configured as follows:
accessible over management VLAN 4093
authentication server IP address is 192.168.2.22
accounting server IP address is 192.168.2.23
default domain is ALCATEL
NAS-ID for the NE is ISAM-1
NAS-IP for the NE is 192.168.1.1
1 Configure the server used for authentication. The shared RADIUS secret key is
mysecret.
configure system security radius auth-server sampleAuth
vrf-index 0 ip-address 192.168.2.22 secret mysecret
2 Configure the server used for accounting. The shared RADIUS secret key is
mysecret.
configure system security radius acc-server sampleAcc vrf-index
0 ip-address 192.168.2.23 secret mysecret
3 Configure a RADIUS policy for the NE specifying the NAS-ID and the NAS-IP:
configure system security radius policy sampleRadPol nas-id
ISAM-1 nas-ip-address 192.168.1.1
4 Configure the policy to use the authentication and accounting servers. These servers
were created in steps 1 and 2.
configure system security radius policy sampleRadPol servers 1
auth-server name:sampleAuth vrf-index-auth 0 priority 40
acc-server name:sampleAcc vrf-index-acc 0
5 Configure the domain used by the RADIUS policy:
configure system security domain ALCATEL vrf-index -1
authenticator radius:sampleRadPol
6 Create a connection profile for the ALCATEL domain and configure handling of
requests without a domain:
configure system security conn-profile sampleConnProf version
1 domain-name ALCATEL no reject-no-domain reject-inv-domain
7 Configure the connection profile for the connection policy defined in step 6:
configure system security conn-policy conn-profile-name
sampleConnProf
8 Enable 802.1x authentication at the system level:

9 Enable 802.1x authentication on each xDSL port:
configure system security pae ext-authenticator 1/1/4/[1...24]
authentication
configure system security pae ext-authenticator 1/1/5/[1...24]
authentication
configure system security pae ext-authenticator
1/1/6/[1...48]:8:35 authentication
configure system security pae ext-authenticator
1/1/7/[1...48]:8:35 authentication
The system can now authenticate xDSL ports using 802.1x toward the subscribers and
RADIUS as the backend authentication server.
TNG 111 7330 ISAM FTTN ES
configuration
Purpose
This TNG provides the steps to configure the 7330 ISAM FTTN ES.
General
The ES must have at least one LT unit installed so the ES can be detected by the host
shelf when the expansion link connections are made and the ES configuration is
complete.
Note Beginning with the Release 3.3 (Feature Group 3.4), ES VLAN
configuration commands support multishelf notation. In previous
releases, users were required to use single shelf notation when
configuring an ES VLAN. Single shelf notation is still supported for
backwards compatibility; for more information about configuring an ES
VLAN using single shelf notation, consult an earlier version of this
document.
Procedure
Use this procedure to configure the ES.
1 Perform the initial configuration of the ES:
configure system id systemname
configure system management host-ip-address manual:hostIP
configure system management default-route defaultgwaddress
configure interface shub port shubport# port-type shubporttype

admin-status adminstatus
configure vlan shub id shubvlanid egress-port
network:networkport#
configure vlan shub id shubvlanid untag-port network:networkport#
configure bridge shub port networkport# pvid shubvlanid
where
systemname is the name of the ES
hostIP is the IP address and mask of the host shelf, in the format xxx.xxx.xxx.xxx/yy
defaultgwaddress is the IP address of the default gateway
shubport# is the port number for the SHub; you can enter a single port number or a range of port
numbers
shubporttype is the type of SHub port
adminstatus is the administrative status of the SHub port
shubvlanid is the number of the SHub VLAN
networkport# is the port number for the network; the network port number must match the SHub port
number
Example:
configure system id 7330-ES1

manual:138.120.217.171/24
configure interface shub port [1...5] port-type network

admin-status auto-up
2 Plan the ECNT-A and GENC-E or GENC-F cards on the host shelf:
configure equipment slot 1/1/1 planned-type genc-e|genc-f unlock
configure equipment slot nt-b planned-type ecnt-a unlock
Example:
configure equipment slot 1/1/1 planned-type genc-e unlock
configure equipment slot nt-b planned-type ecnt-a unlock
3 Plan the ES:
configure equipment shelf rack/shelf planned-type aram-d
where
rack is the rack number of the ES
shelf is the shelf number of the ES
Example:
configure equipment shelf 1/2 planned-type aram-d
4 Plan the EDSE-A and SATU-A cards on the ES:
configure equipment slot rack/shelf/2 planned-type edse-a unlock
configure equipment applique rack/shelf/2 planned-type satu-a
where
Example:
configure equipment slot 1/2/2 planned-type edse-a unlock
configure equipment applique 1/2/2 planned-type satu-a
5 Plan the installed LT cards and appliques on the ES:
configure equipment slot rack/shelf/slot planned-type LT unlock
configure equipment applique rack/shelf/slot planned-type

applique
where
slot is the slot number of the unit
LT is the designation of the LT card
applique is the designation of the applique
Example:
6 Configure the modem service profile:
configure xdsl service-profile servprofile# name servprofilename

local-profile
configure xdsl service-profile servprofile# version version#

min-bitrate-down minbrdown min-bitrate-up minbrup
plan-bitrate-down planbrdown plan-bitrate-up planbrup
max-bitrate-down maxbrdown max-bitrate-up maxbrup max-delay-down
maxbrdelaydown max-delay-up maxbrdelayup
configure xdsl service-profile servprofile# active
where
servprofile# is the number of the service profile
servprofilename is the name of the service profile
version# is the version number of the service profile
minbrdown is the minimum downstream bit rate
minbrup is the minimum upstream bit rate
planbrdown is the planned downstream bit rate
planbrup is the planned upstream bit rate
maxbrdown is the maximum downstream bit rate
maxbrup is the maximum upstream bit rate
maxbrdelaydown is the maximum downstream bit rate delay
maxbrdelayup is maximum upstream bit rate delay
Example:
configure xdsl service-profile 1 name xsrvc1 local-profile
configure xdsl service-profile 1 version 1 min-bitrate-down 22500

min-bitrate-up 384 plan-bitrate-down 22500 plan-bitrate-up 784
max-bitrate-down 25000 max-bitrate-up 1500 max-delay-down 1
max-delay-up 1
7 Configure the spectrum profile:
configure xdsl spectrum-profile specprofile# name specprofilename

local-profile version version# dis-etsi-dts dis-g992-1-b
dis-g992-3-b g992-3-l1 g992-3-l2 g992-5-a max-noise-down
maxnoisedown max-noise-up maxnoiseup rf-band-list rfbandlist
configure xdsl spectrum-profile specprofile# active
where
specprofile# is the number of the spectrum profile
specprofilename is the name of the spectrum profile
version# is the version number of the spectrum profile
maxnoisedown is the maximum downstream noise
maxnoiseup is the maximum upstream noise
rfbandlist is the RF band list
Example:
configure xdsl spectrum-profile 1 name xlne1 local-profile

version 1 dis-etsi-dts dis-g992-1-b dis-g992-3-b g992-3-l1
g992-3-l2 g992-5-a max-noise-down 100 max-noise-up 100
rf-band-list
07:12:07:d0:16:0d:ac:0e:d8:19:1b:58:1b:bc:19:27:74:27:a6:19
8 Configure a downlink port on the host shelf where the remote LT is connected:
configure equipment external-link-assign sfpindex
no remote|remote rack/shelf/slot
Where
sfpindex is the number of the downlink port on the GENC-E or GENC-F card on the host shelf
slot is the slot number of the LT unit
Example:
9 Configure the VLANs:
configure vlan id sysvlanid mode residential-bridge
configure vlan shub id shubvlanid mode residential-bridge
configure vlan shub id shubvlanid egress-port network:networkport
configure vlan shub id shubvlanid egress-port lt:rack/shelf/slot
where
sysvlanid is the number of the ES VLAN
shubvlanid is the number of the SHub VLAN
networkport is the port number for the network; the network port number must match one of the
SHub port numbers
shelf is the shelf number of the SHub
slot is the slot number of the SHub
port is the port number of the SHub
Example:
10 If one or more dual-mode ports are used to connect the GENC-E to the EDSE-A on
the ES, configure the dual-mode ports as downlink ports:
configure equipment external-link-host dualport# direction

remote-lt
where
dualport# is the number of the dual-mode (6 or 7); you can enter a single port number or a range of
port numbers
Example:
configure equipment external-link-host [6...7] direction

remote-lt
11 Train the modems:
configure xdsl line rack/shelf/slot/port service-profile
servprofile# spectrum-profile specprofile# admin-up
configure atm pvc rack/shelf/slot/port:vpi:vci
configure bridge port rack/shelf/slot/port:vpi:vci
configure bridge port rack/shelf/slot/port:vpi:vci vlan-id

sysvlanid
configure bridge port rack/shelf/slot/port:vpi:vci pvid sysvlanid

no mac-learn-off max-unicast-mac macaddress
where
slot is the slot number of the xDSL line
port is the port number of the xDSL line
servprofile# is the number of the service profile
specprofile# is the number of the spectrum profile
vpi is the VPI number of the ATM PVC and bridge port
vci is the VCI number of the ATM PVC and bridge port
sysvlanid is the number of the ES VLAN
macaddress is the unicast MAC address; you can enter a single address or a range of addresses
Example:

admin-up
configure bridge port 1/2/4/1:8:35 pvid 101 no mac-learn-off

max-unicast-mac 4
TNG 112 7330 ISAM FTTN
configuration for subtending
Purpose
This TNG provides information about configuring a 7330 ISAM FTTN system in a
subtended configuration.
General
Subtending allows several 7330 ISAM FTTN nodes to be connected to the network
through a single node. For more information about subtending, see the 7330 ISAM FTTN
Product Information.
Figure TNG 112-1 shows an example of subtended 7330 ISAM FTTN nodes.
Figure TNG 112-1: 7330 ISAM FTTN subtending example
VLAN associations:
4093 400
VLAN associations:
4093 200 400
Node #2 Node #4
Traffic on Traffic on
Network VLAN 200 VLAN 400
Subtended NE
VLAN associations: Node #1 (subtending host: Node #2)
4093 100 200 Traffic on
300 400 VLAN 100
VLAN associations:
4093 300 Node #3
Traffic on
VLAN 300
Subtended NEs
(subtending host: Node #1)
18850
In this example:
Node 1 is a subtending node to Node 2 and Node 3

Node 2 is subtended to Node 1 and is a subtending node to Node 4
Node 3 is subtended to Node 1
Node 4 is subtended to Node 2
The master subtending node, Node 1 in Figure TNG 112-1, receives the management
and customer traffic from the network and distributes it to the appropriate node.
Management traffic is sent to all nodes. Customer traffic is sent only to the appropriate
node, which is determined by the VLAN associated with the customer traffic. In the
example in Figure TNG 112-1, the customer traffic is distributed as follows.
Customer traffic on VLAN 100 is sent to the LT units of Node 1.

Customer traffic on VLAN 200 is sent to Node 2 via the appropriate subtending port.
Node 2 then sends the customer traffic to its LT units.
Node 3 then sends the customer traffic to its LT units.
Node 2, the subtending node for Node 4, sends the customer traffic to Node 4 via the
appropriate subtending port. Node 4 then sends the customer traffic to its LT units.
Configuring VLANs for subtending and subtended nodes

This section shows how to configure VLANs on subtending and subtended nodes, using
the example in Figure TNG 112-1.
1 For each node (Node 1, Node 2, Node 3, and Node 4), configure the network port
and the SHub management VLAN.
2 For each subtending node (Node 1 and Node 2), configure the management
VLAN ID:
3 For each node (Node 1, Node 2, Node 3, and Node 4), configure the VLAN
associated with the node:
4 For each node (Node 1, Node 2, Node 3, and Node 4), configure the egress ports
associated to each VLAN:
5 For each subtending node (Node 1 and Node 2), create and configure the VLAN
associated with the nodes subtended to it:
i Node 1:
ii Node 2:
6 For each subtending node (Node 1 and Node 2), configure the subtending ports for
each subtending node:
i Node 1:
configure interface shub port 3 port-type subtending
ii Node 2:
configure interface shub port 3 port-type subtending
Introduction
This TNG provides more information about the parameters used by the Multi-ADSL
modem:
Multi-ADSL configuration management
Multi-ADSL common configuration parameters
ADSL2plus-specific configuration parameters
During showtime (L0 line state), the Multi-ADSL Modem Subsystem performs
re-initialization triggers. Table TNG 113-1 lists them for the ATU-C and includes the
required persistency time for each showtime error.
Near-End Far-End
(f)se 10 1 sec 10 1 sec
Note All the triggers, except los and sef based triggers, make up the
high-ber-hs condition, specified in G.992.3 ([6]), annex D. The
Multi-ADSL modem subsystem implements correct state behavior as
specified in the different standards, according to the actual operation
mode,
The Multi-ADSL modem subsystem triggers/initiates re-activation of the modem when

any of those triggers is fired. No other re-initialization triggers (annex timer values) are
used by the modem subsystem than the ones mentioned in Table TNG 113-1.
All the far-end countdown timers are frozen when any near-end defect occurs. When all
the near-end defects have disappeared, the far-end count-down timers resume from the
frozen values (ignoring the in-between time).
All the near-end defects are correlated independent from each other. The same holds for
all the far-end defects in absence of near-end defects.
Note For ADSL2x standards, fese cannot be derived through IB-bits,

instead Management Counters are used. As soon as the UAS counter is
different from 0 in the FE Management Counters, and the CPE did not
restart the line, the ATU-C shall force re-initialization.
Multi-ADSL configuration management

The Multi-ADSL modem subsystem accepts the configuration parameters listed
hereunder. Based on the required levels, the required modem reaction on each
parameter is:
In case a parameter is indicated as optional, the input value is do not care, and any
In case a parameter is indicated to be required to a certain level (for example, only a
subsystem raises a failure indication to the xDSL manager indicating Configuration
Error
parameters and the configuration should be rejected, rejection always means that
the modem subsystem raises a failure indication to the xDSL Manager indicating
Configuration Error, rather that a returned error of the considered xDSL API call.
An xDSL API configuration request is replied with an error only when the call is done
The Multi-ADSL modem subsystem allows the configuration to be independently set on

individual line basis.
Multi-ADSL common configuration parameters

All the following parameters are common for all supported DSL flavours (includes VDSL
and VDSL2). There is only one instance per parameters, whatever the number of
operating modes selected.
Operating modes
Auto-mode criterion
Rate adaptation mode
Target noise margin
Minimum noise margin
Maximum noise margin
Carrier mask
RF band data
Minimum bitrate
Maximum bitrate
Rate adaptation ratio
Maximum interleaving delay
Minimum impulse noise protection
L3 Power State Permission
L2 Power State Permission
L0 Time
L2 Time
L2 ATPR
L2 Bitrate Downstream
L2 ATPRT
Bonding Mode
BondingGroupId
Upshift Noise Margin
Downshift Noise Margin
Minimum Time Interval for Upshift Rate Adaptation
Minimum Time Interval for Downshift Rate Adaptation
Artificial Noise PSD
Impulse Noise Monitor (INM):
INM Sensitivity Threshold
INM Pulse-Gap-Bridging Value
Warm Re-Init Disable
Programmable Resynch Triggers
Table TNG 113-2: Operating modes
Description This parameter defines which standards are allowed for the Modem Subsystem
for line activation.
Different DSL standards can be allowed by the XDSL Manager. The Modem
Subsystem does the following:
check if allowed modes are not conflicting (see MGMT_R12), and raise an
error if there is a conflict.
if allowed modes are accepted, try to initialize with peerend modem in one
of the allowed operation modes. Selection of best-fit mode shall be done
according to MGMT_R13.
Instances Line
Values Bitmap:
ANSI.T1.413 (1998)
Alcatel-Lucent-proprietary ETSI mode
G.992.1 Annex A & B, each overlapped & non-overlapped
G.992.2 Annex A (non-overlapped) & B (overlapped)
G.992.3 Annex A, B, I, J & L, M each overlapped & nonoverlapped
G.992.4 Annex A & I, each overlapped & non-overlapped
G.992.5 Annex A, B & I, M each overlapped & non-overlapped
Table TNG 113-3: Auto-mode criterion
Name Auto-Mode Criterion
Description This parameter shall be used to set the policy to select optimal operation mode
in case READSL2 operation mode has been enabled. If no READSL2 operation
mode has been set by the xDSL Manager, this parameter shall be ignored.
Currently, three policies are defined:
0x0 : chipset proprietary criterion (full freedom)
0x1 : optimize DS bitrate with US bitrate above Minimum Bitrate.
0x2 : optimize US bitrate with DS bitrate above Minimum Bitrate.
The use of this parameter shall be as described in MGMT_R13.
Instances Line
Values Bitmap:
ANSI.T1.413 (1998)
Alcatel-Lucent-proprietary ETSI mode
G.992.1 Annex A & B, each overlapped & non-overlapped
G.992.2 Annex A (non-overlapped) & B (overlapped)
G.992.3 Annex A, B, I, J & L, M each overlapped & nonoverlapped
G.992.4 Annex A & I, each overlapped & non-overlapped
G.992.5 Annex A, B & I, M each overlapped & non-overlapped
Table TNG 113-4: Rate adaptation mode
Name Rate Adaptation Mode
Description Specifies the Rate Adaptive mode of operation:

RA mode 1 (manual): The ATU initializes at the specified Minimum Bitrate,
rounded according to MGMT_R14, with a noise margin of at least the
specified Target Noise Margin and a BER better than 10-7 at 0 dB noise
margin. During showtime, the ATU tries to maintain that bitrate with at least
the specified Minimum Noise Margin.
RA mode 2 (atInit): The ATU initializes at the bitrate corresponding with a
noise margin of at least the specified Target Noise Margin and a BER better
than 10-7 at 0 dB noise margin, provided that the bitrate is not less than the
specified Minimum Bitrate and not greater than the specified Maximum
Bitrate (see MGMT_R14 for applicable bitrate rounding rules).
During showtime, the ATU shall try to maintain that bitrate with at least the
specified Minimum Noise Margin.
The modem optimizes the maximum net bit rate while meeting the quality
requirements as specified by the operator (in particular the burst error
correction capability). But it does not increase the net bit rate at the expense
of the link quality. Description of the list of priorities is defined by
requirement MGMT_R15.
RA mode 3 (dynamic): same as RA mode 2 during initialisation. Once the
line is in showtime however, the bit rate can vary between a configured
minimum and maximum bit rate.
The rate adaptations shall occur in the following 2 cases:
Upshift: the noise margin is above the upshift noise margin during a time
equal to minimum time interval for upshift rate adaptation
Downshift: the noise margin is below the downshift noise margin during a
time equal to minimum time interval for downshift rate adaptation
In both cases, the new bit rate has to be selected such that the noise margin
becomes equal to the target margin unless the upper or lower bitrate
boundary is reached.
It is guaranteed that the SRA (RA mode 3) requests do not violate the
service requirements and framing parameters (See ADSL2_R24.1 and
ADSL2_R24.2) except for the PER restriction. This PER restriction can be
violated if the CRCs are normalized (see section 7.9.1 in G.992.3). The
normalization shall be executed in the Modem Subsystem.
Remarks:
In case the CPE does not support SRA or if a line initializes in an XDSL flavour
(f.i. ADSL1) which does not support SRA, RA mode 3 behavior shall be identical
to RA mode 2. In state L2, no Downstream SRA bit rate change is allowed.
Values RaModeManual
RaModeAtInit
RaModeDynamic
Table TNG 113-5: Target noise margin
Name Target Noise Margin
Description Specifies the required noise margin, relative to a BER of 10-7 (= 0 dB noise
margin), the modem will achieve in order to successfully complete the
initialization. This parameter is not used in showtime.
When the modem cannot initialize at this margin, it fails.
For DS, the parameter is passed to the ATU-R, it is the responsibility of the
ATU-R to use this parameter correctly.
For ADSL2x standards, all values between 0.0 and 31.0 can be passed, while
for ADSL1x standards, only values 0 to 31 with 1 dB granularity can be passed.
In that case, non-integer values shall be rounded to the nearest value of the
standard
Instances DS, US
Values 0.0..31.0
Table TNG 113-6: Minimum noise margin
Name Minimum Noise Margin
Description Specifies the minimum noise margin, relative to a BER of 10-7 (= 0 dB noise
margin), the modem shall tolerate in order to maintain showtime. This
parameter is only used in showtime.
For DS, the ATU-C regularly polls the actual DS noise margin to the ATU-R, and
compares this value with the minimum noise margin.
For both US and DS, the Multi-ADSL modem subsystem raises the lom (loss of
margin) defect whenever the actual noise margin is below the Minimum Noise
Margin.
The Modem Subsystem raises failure indication "Configuration Error" for
configurations where Minimum Noise Margin > Target Noise Margin for one of
the directions.
For ADSL2x standards, all values between 0.0 and 31.0 can be passed, while
for ADSL1x standards, only values 0 to 31 with 1 dB granularity can be passed.
In that case, non-integer values shall be rounded to the nearest value of the
standard
Instances DS, US
Values 0.0..31.0
Table TNG 113-7: Maximum noise margin
Name Maximum Noise Margin
Description Specifies the maximum noise margin sustained by the modem. This parameter
is both used during initialization and in showtime.
during initialization:
When the noise margin for transport configuration is higher than the
Maximum Noise Margin, then the modem takes action to reduce the
power to get the actual noise margin below this value.
When the noise margin is lower than the Maximum Noise Margin, then
the modem tries to optimize the Receive Power below the configured
masks to get the noise margin as high as possible (still below the
Maximum Noise Margin).
in showtime:
When the current noise margin gets above the Maximum Noise Margin,
the modem attempts to reduce the far-end output power to get the noise
margin below this limit (by means of bit-swap actions).
When the current noise margin gets below the Maximum Noise Margin,
then the ATU attempts to increase the far-end output power (still below
the maximum allowed templates or masks) to get the noise margin as
high as possible (by means of bits-swap actions).
The special value 51.1 is interpreted as meaning that no Maximum Noise
Margin limit must be applied. Other values strictly bigger than 31.0 are
converted to t51.1 as well.
Note 1: for DS, the parameter has to be passed to the ATU-R during initialization
(C-Msg-1 or C-Msg-RA). For ADSL2x standards, all values between 0.0 and
31.0 plus 51.1 can be passed, while for ADSL1x standards, only values 0 to 31
with 1 dB granularity can be passed. In that case, non-integer values shall be
rounded to the nearest value of the standard, while the special value 51.1 is
translated to 31. It is up to the CPE to interpret this value as infinity or 31.
Note 2: In ADSL1x, the average PSD may not change too much due to SYNC
symbols, which cannot change PSD in showtime. Therefore, the showtime
behavior is different than stated above : far-end output power shall only be
varied within a 1.5 dB range with regard to the initial (that is, before the first bit
swap) showtime output power.
Instances DS, US
Values 0..51.1
For clarification, Figure TNG 113-1 gives an overview of the noise margin parameters,
and the required actions from the modem.
Figure TNG 113-1: Noise margin parameters
Reduce Output Power at peer modem

Maximum Noise Margin
Maximum Additional Noise Margin

Increase Output Power at peer modem
Target Noise Margin
Minimum Noise Margin
Modem restarts if persistent in this region

0 dB Margin
Table TNG 113-8: Carrier mask
Name Carrier mask
Description The Carrier Mask specifies the sub-carriers that can be used for data transport
by the Modem Subsystem. There is one mask for each direction. A sub-carrier
shall be masked, i.e. not used for data transport (bi=gi=0), when the XDSL
manager has set the bit for that sub-carrier to 1.
The total number of carriers for which the mask is specified: 512 (carrier #0 to
carrier #511).
The usage of this information depends on the actual used operation mode:
ADSL1x :
US : modem subsystem shall request no bits and no power on masked
sub-carriers in bit loading process.
DS : modem subsystem shall not transmit masked sub-carriers during
medley signal.
ADSL2x :
US & DS : masked sub-carriers shall be indicated as not supported in
G.hs CL messages.
Note 1: Besides respecting the carrier mask, the modem subsystem must also
respect the standard band plans and configured PSD masks. This means that
the fact that a sub-carrier is not masked in one direction does not necessarily
mean that it can be used for data transmission in that direction.
Note 2 : In ADSL1x operation modes, when carrier masking is applied, and
modem initialization continuously fails, the masking may be suspected as cause
for these init problems. Therefore, when conditions for activation failures CMP
or CNF are met, the modem subsystem replaces them by CE activation failure
if masking is applied on carriers between tone 60 and 100, and the selected
operational mode is ADSL1x mode.
Instances US, DS
Values Bitmap, 1 bit per sub-carrier, 1= masked, 0 = not masked
Table TNG 113-9: RF band data
Name RF Band Data
Description Specifies the list of RF bands (HAM band or AM band) for egress control and
ingress canceling.
Egress requirements shall be used in ADSL2plus operation mode, but with
some minor modifications (see Figure TNG 113-2): the modem subsystem shall
determine all PSD points based on the RF band Start and Stop frequency given
by the operator. For this it will take into account the PSD shape or Custom PSD
shape parameters.
1. PSD(i+1), PSD5,PSD6 and PSD(i+4) to be determined by the modem based
on ALA MIB "Custom Shape" parameter (MGMT_R11.2) (and the PSD shape
(MGMT_R11.1) )
2. PSD(i+2) = PSD(i+3) = -80 dBm/Hz fixed in ALA TRS(MGMT_R9.8)
3. t(i+2)= RFI_f_start and t(i+3)= RFI_f_stop as specified in ALA MIB "RF band"
parameter (MGMT_R9.0)
4. t(i+1) and t(i+4) to be determined by the modem based on MIB specified
"Custom Shape" parameter (MGMT_R11.2) and the PSD shape
(MGMT_R11.1))
In other operation modes, egress control is optional.
Ingress parameter is for information of the Multi-ADSL modem subsystem,
usage for RFI canceling purposes is vendor discretionary.
Egress control of up to 2 different RF bands simultaneously shall be supported.
Any RF bands configured shall affect the PSD shape even if DPBO (see XXXX)
is active.
Instances Line
Values Maximum 8 RF bands can be specified:

RF band = [Start frequency, Stop frequency, RF type, Egress control, Ingress
level]
Frequency: 0 12000 kHz
RF type: HAM band (rfHam) or AM band (rfAm)
Egress control: PSD level is reduced below -80 dBm/Hz (egressNotched) or
PSD notching is not required (egressNoControl)
Ingress level: expected ingress level can be negligeable (ingressLow),
weak (ingressWeak = at -30dBm @ LT / - 20dBm@NT ) or strong
(ingressStrong = at -10dBm @LT / 0dBm@NT ).
From these 8 specified RF bands, only 2 are relevant for the spectra used by
the different ADSLx operation modes (and especially ADSL2plus). All other
bands will be specified for higher frequencies, typically in VDSL bands.
The Modem Subsystem scans the complete set of RF bands, checks the start
frequency for each band, and only considers the bands, which are in-band for
the current operation mode. All other RF bands are ignored.
When the number of RF bands to be considered is higher than the supported
number of RF bands (min 2 for the spectra used by the different ADSLx
operation modes ), the Modem Subsystem generates a configuration error
towards the XDSL Manager.
Figure TNG 113-2: Restrictions on breakpoints and PSD mask for RFI band
specification
PSD in
dBm/Hz
Limitmask(f)
< 33.5 dB
PSD(i+1) < 33.5 dB
PSD5
PSD6
PSD(i+4)
slope < 1.5 dB/tone slope < 1.5 dB/tone
PSD(i+2)
PSD(i+3)
t(i+1) t(i+2) t(i+3) t(i+4) Tone index
ALA MIB Custom Shape PSD mask(f)

ALA Requirement for RF band PSD mask
Table TNG 113-10: Minimum bitrate
Name Minimum Bitrate
Description Defines the minimum requested bitrate which will be set up and which will be
maintained during showtime by the ATU.
Rounding of bitrate parameters is as follows:
For ADSL1x:
The Minimum Bitrate is rounded up and the Maximum Bitrate is rounded
down according to the bitrate granularity (32 kbps) when for the
corresponding direction Maximum Bitrate Minimum Bitrate after rounding.
Otherwise, both bitrates are rounded up and Minimum Bitrate = Maximum
Bitrate after rounding.
In case of the current showtime makes use of s=0.5 in dowstream, the
downstream bitrate granularity is 64 kbps instead of 32 kbps.
For ADSL2:
The accuracy of the bit rates parameters "net_max" and "net_min" passed
in G.Hs have a granularity of 4kb/s.
G9923_net_max = rounddown_to_next_4k ( G9971_maximum_datarate)
G9923_net_min = roundup_to_next_4k ( G9971_minimum_datarate)
For ADSL2plus:
The accuracy of the bit rates parameters "net_max" and "net_min" passed
in G.Hs have a granularity of 8kb/s.
G9925_net_max = rounddown_to_next_8k (G9971_maximum_datarate)
G9925_net_min = roundup_to_next_8k ( G9971_minimum_datarate)
General
If G992x_net_max < G992x_net_min then new G992x_net_max =
G992x_net_min = highest of both
In other words: in case of ADSL2 fixed rate (i.e.
G9923_net_max=G9923_net_min), the value exchanged during the
handshake can be up to 4kb/s above the user specified value and the actual
bitrate value in showtime can be 8kb/s above the value exchanged during
the handshake which means in G992.3 the actual rate can be up to
4kb/s+8kb/s=12 kb/s above the user configured value. For G992.5, the
actual bitrate can be up to 8kb/S+8kb/s=16 kb/s above the user configured
value.
The minimum supported data rate is be 32 kbps. Lower configured rates may
be rounded to 32 kbps.
Instances Path DS, US
Values 0..65535
Note
(1) In G.lite operating mode, supported bitrates are only up to 512 kbps US and up to 1500 kbps DS.
When the minimum bitrate is configured above this limitation, and selected operation mode is G.lite,
the Multi-ADSL modem subsystem might still try to activate at this higher bitrate. If however
initializations continuously fail due to this minimum setting, the modem subsystem raises the
activation failure "Configuration not feasible on line". At the same time, the Relative Capacity
Occupation for the direction causing the problem is set to 100%.
Table TNG 113-11: Maximum bitrate
Description Defines the maximum allowed transport bitrate which is set up and which is
maintained during showtime by the ATU. This parameter is relevant only in
'atInit' RA Mode.
For the rounding of bitrate parameters: see Table TNG 113-10.
The Multi-ADSL modem subsystem raises failure indication Configuration
Error for configurations where Maximum Bitrate < Minimum Bitrate for one of
the directions in case of the atInit RA Mode.When RA Mode is manual, the
Maximum Bitrate parameter will be ignored.
Values 0..65535
Table TNG 113-12: Rate adaptation ratio
Name Rate Adaptation Ratio
Description The Rate Adaptation Ratio specifies the ratio that should be taken into account
for allocating available data rate (in excess of the minimum data rate summed
over all bearer channels) among the different bearer channels in a given
direction.
The ratio is defined as a percentage from 0 to 100. The sum of the raRatios for
all bearers must be 100.
The excessive bitrate (that is, the available bitrate minus the sum of the
minimum bitrates) must be distributed among the different bearers according to
their respective raRatio.
When the maximum bitrate is achieved for one of the bearers, the raRatio of that
bearer must be distributed to the other bearers according to their respective
raRatio share.
This parameter is only meaningful in case multiple bearers are used (for
example, 2 for dual latency) and is ignored in case of single latency.
Values 0..100
Table TNG 113-13: Maximum interleaving delay
Name Maximum Interleaving Delay
Description Specifies the maximum allowed delay introduced by the interleaving and
deinterleaving function in the corresponding direction.
This parameter puts a constraint the parameter PMS-TC delay, but is extended
towards all Multi-ADSL standards.
The Modem Subsystem selects FEC parameters such that
SpxDp/4 < ILVDbc
for the latency path carrying the specified bearer channel bc.
If multiple bearer channels are carried over the same latency path, obviously the
minimum of all Interleaving Delay limits constrains this latency path.
Values 0 - 63. All integer values between these borders shall be supported.
Special Value 0 is used as "No delay bound"
The value 0 indicates that the system chooses the optimal delay value as
follows:
The method used by the receiver to select data rates, power, overhead and
latency is implementation dependent. However, within the raw data rate
provided by the local PMD, the selected values will meet all the constraints
communicated by the operator :
- (message based) overhead data rate: Minimum overhead data rate
- Net data rate: Minimum net data rate
- Impulse Noise Protection: Minimum impulse noise protection for all bearer
channels.
- Delay: Maximum delay for all bearer channels.
Within those constraints, the receiver selects the values to optimize the
modem behavior as listed in the following priority order:
1. Maximize net data rate (within MaximumBitrate constraint).
2. Maximize SNR margin (within MaximumNoiseMargin constraint).
3. Minimize Power consumption.
If within the given constraints, the modem is unable to select a set of
operation parameters for one or both directions, the Modem Subsystem
raises failure indication to XDSL Manager (configuration not feasible on
line). However, it keeps on trying to activate the line.
Special Value 1 is used to specify that no interleaving must be used.
The value 1 indicates that the Fast latency Path shall be used in the G.992.1
and ANSI operating mode and Sp and Dp shall be selected such that Sp<1
and Dp=1 in G.992.2, G.992.3 , G.992.4 and G.992.5 operating modes.
When the ILVD=1 the INP should be set to zero.
Note: due to the choice of 1 as special value, it is impossible to set the max
interleaving delay to a value of 1ms
Exception1:
In G992.1 and Ansi, the Interleaved path shall be selected If delay = 1
and max DS rate is too large to be possible to reach without S=0.5 (i.e.
max DS rate >8128kbps) and If (CPE is able to do S=0.5 ) and (CO
decides to apply S=0.5)
Exception 2
If one of the 2 directions (upstream or downstream) is configured in
interleaved mode and other one in fast. It's allowed to use the
interleaved path for both upstream and downstream direction in order
to avoid possible showtime interoperability issues with some CPEs.
Table TNG 113-14: Minimum impulse noise protection
Name Minimum Impulse Noise Protection
Description Specifies the minimum required impulse noise protection as a number of DMT
symbols.
This parameter puts a constraint the parameter PMS-TC impulse noise
protection but extends towards all Multi-ADSL standards.
The Modem Subsystem selects FEC parameters such that
0.5 SpxDp (Rp / N_FECp) > INPbc
for the latency path carrying the specified bearer channel bc.
If multiple bearer channels are carried over the same latency path, obviously the
maximum of all INP limits constrains this latency path (see also Table TNG
113-13
Values 0.0 to 8.0 DMT Symbols.

INP_min = 0 is a special value indicating no impulse noise protection bound is
being imposed
If the CO modem subsystem is not able to follow the minimum INPrequirement,
it raises the activation failure " configuration not feasible".
The modem subsystem checks standard compliancy of the CPE, i.e. the CO
checks whether the actual INP proposed by the CPE is > the CPE_INP_min.
If the CPE doesn't follow the Minimum INP requirement, the modem subsystem
raises the activation failure.
The INP implementation is applicable both for ADSL2x and ADSL1x operating
mode
Granularity & Unit 0.1 DMT symbol
The multi ADSL modem system shall round up intermediate values to the
nearest higher valid INP value that is supported.
Notes
(1) Support of INP_min values 4 and 8:
The ITU standards require mandatory support of the INP_min values 0.0, 0.5, 1.0 and 2.0 while
support of the INP_min values 4 and 8 is optional. This MGMT-requirement requests support of
INP_min values 4 and 8.
(2) Support of INP_min=2 up to the highest supported DS and US interleaved net data rates.
The ATU-C shall support bitrates up to 2.6 Mbps upstream and 22.8 Mbps downstream for INP_min
=2. This proprietary behaviour shall be coupled to the modem features bitmap.
Note: This means support of higher interleaving depth D_ds > 64, D_us > 8. In case ATU-C or ATU-R
is not supporting these bitrates the following behavior (as mentioned in ITU) is applicable:
Configuration of Minimum Net Data rates such that the sum of all Minimum Net Data rates over all
bearer channels results in values higher than the ITU standard tables with min INP and maxium delay
related net data rates limits may lead to configuration errors by the ATU-C and/or initialization failures
with configuration error failure cause by the ATU-R.
(3) Standard Compliant extension of S and D
The Multi-ADSL Modem Subsystem shall support all optional values for S and D as provisionally
agreed in ITU. Negotiating capabilities with CPE through G.hs and implementation constraints shall
be according to the same amendments.
Table TNG 113-15: L3 Power State Permission
Name L3 Power State Permission
Description This bit controls allowed link state transitions to L3 power management state:
If enabled (bit = 1), the Modem Subsystem is allowed to use orderly
shutdown as a means to reduce power in both US and DS. It also accepts
orderly shutdown requests initiated bythe ATU-R. In this case, the modem
subsystem transitions from L0 to L3 state without failure event.
If disabled (bit = 0), the Modem Subsystem is NOT allowed to use orderly
shutdown. When orderly shutdown procedure is initiated by the ATU-R, the
ATU-C refuses this procedure. This means that no transition to L3 should
be done without failure notification.
This bit has the same interpretation for all ADSL1x and ADSL2x opmodes.
Instances Line
Values Bit : L3-Enabled / L3-Disabled
Table TNG 113-16: L2 Power State Permission
Name L2 Power State Permission
Description This bit controls allowed link state transitions to L2 power management state:
If enabled (bit = 1), the Modem Subsystem is allowed to use L2 as a means
to reduce power in DS. Parameters described in Tables TNG 113-17
to TNG 113-20 will be used by Multi-ADSL modem subsystem to control the
power management.
If disabled (bit = 0), the Modem Subsystem is NOT allowed to enter L2 state.
Parameters described in Tables TNG 113-17 to TNG 113-20 will be
ignored.
This bit is ignored when the operation mode is ADSL1x.
Instances Line
Values Bit : L2-Enabled / L2-Disabled
Table TNG 113-17: L0 Time
Name L0-TIME
Description Specifies the minimum time - after entering L0 - before transition to L2 Power
State.
Note: Any time lower than 10 s will be considered as 10 s.
Instances Line
Values 0 to 1800 s
Unit 1s
Table TNG 113-18: L2 Time
Name L2-TIME
Description Specifies the minimum time between L2 entry and first power trim or 2
consecutive power trims.
Instances Line
Values 0 to 1800 s
Unit 1s
Table TNG 113-19: L2 ATPR
Name L2-ATPR (Aggregate Transmit Power Reduction Per Trim)

Description This parameter specifies the maximum allowed aggregate transmit power
reduction (in dB) that can be performed in the L2 Request (i.e. at transition of L0
to L2 state) or through a single Power Trim in the L2 state. It ranges from 0 dB
to 31 dB.
The maximum PCBds in a L2 request command is limited by following constraint
:
maximum_PCBds - PCBds (L0) < L2_ATPR
where:
maximum_PCBds is the maximum PCBds value in the L2 request
PCBds(L0) is the PCBds value of the L0 state
The proposed value of PCBds (in dB) in any L2 trim command is limited by
following constraint:
PCBds(proposed) - PCBds(current) < L2_ATPR
where
PCBds(proposed) is PCBds value proposed in the L2 trim command
PCBds(current) is the PCBds value currently used in the L2 state
Instances Line
Values 0 to 31 dB
Table TNG 113-20: L2 Bitrate Downstream
Name L2 Bitrate Downstream
Description Specifies the minimum bitrate that shall be set up during L2 state (up to eventual
rounding within 8 kbps, see Description in Table TNG 113-10).
The same value is used by the Modem Subsystem as maximum DS bitrate
measured in fixed, consecutive 1 second intervals that may not be exceeded -
during a time interval MAXIMUM (10s, L0-TIME) - as trigger for transition to L2
state.
In case of multiple used latency paths, the DS actual bitrate must be below the
threshold for each path during MAXIMUM (10s, L0-TIME), before transition to
L2 occurs. The total bitrate during L2 will then be at least the sum of all
configured L2 bitrates.
Note: In case L0min > L2min, additional restrictions are implemented such that
there is no possibility to swap to L2 Mode in case this would lead to a bitrate
increase.
Note: if the actual DS bitrate in L2 state is lower than the configured L2 Bitrate
Downstream (this is always the case if the configured L2 Bitrate Downstream
force an Lp larger than 1024), the modem refuses the transition to L2 state.
Instances Bearer Channel DS

Values 0 to 65535 kbps
Table TNG 113-21: L2 ATPRT
Name L2-ATPRT (Total Maximum Aggregate Transmit Power reduction in L2)
Description This parameter represents the total maximum aggregate transmit power
reduction (in dB) that can be performed in an L2 state. This is the sum of all
reductions of L2 Request (i.e. at transition of L0 to L2 state) and Power Trims.
It ranges from 0 dB to 31 dB.
All PCBds values in the L2 state (i.e. the maximum PCBds in a L2 request
command, and the proposed value of PCBds (in dB) in any L2 trim command)
shall be limited by following constraint :
PCBds - PCBds(L0) < L2_ATPRT
where:
PCBds is any PCBds value in the L2 state
PCBds(L0) is the PCBds value of the L0 state
Instances Line
Values 0 to 31 dB
Figure TNG 113-3: Illustration of the Layer 2 power state control parameters
PSD level
NOMPSD
PCB(L0) PCB1 PCB2 PCB(L0)
REFPSD
L2-ATPR>=
L2-ATPRT>= L2-ATPR>=
L2-ATPR>=
L2-ATPR>=
>= >= >= >= >= >=

L0- L2- L2- L2- L2- L0-
TIME TIME TIME TIME TIME TIME
Time
Initialization Initialization Show- Show- Show- Show-
Channel (other parts) time time time time
Discovery L0 L2 L0 L2
An L2 request message is sent from the CO towards the CPE asking for a transition to the L2 link state
and indicating the maximum allowed first power cutback (smaller than or equal to L2_ATPR). The CPE
will investigate this and respond with an L2 grant message, indicating the actual first power cutback (can
be lower than what was requested by CO).
When entering L2, the bit rate becomes equal to the L2 bit rate, but as a consequence of the (typical) small
first power cutback it is possible that there is still a significant amount of excess margin (compared to the
target margin). Therefore with intervals of L2_TIME power trim messages are sent from the CO to the
CPE, indicating the maximum requested power cutback (smaller than or equal to L2_ATPR). The CPE
will respond with a L2 trim grant message, indicating the actual allowed power trim (can be lower than
what was requested by CO). With each new power trim the power is decreased with the maximum per
trim limited to L2_ATPR until the excess margin has been eliminated.
The total of all these power reductions should not exceed L2_ATPRT.
Table TNG 113-22: Bonding Mode
Name Bonding Mode
Description This parameter indicates whether the bearer channel is used to carry one
complete ATM stream (native mode) or used on a pair within a bonding group
(atmBonding). In the latter case, ATM bonding is be set up according to all
requirements.
In case ATM bonding would not be supported by the chipset, a configuration
error is raised upon startUpLine command if ATM bonding would have been
configured.
Instances Bearer
Values Enumeration:
native : default, line shall not operate in bonding group
atmBonding : line is used for ATM bonding.
Table TNG 113-23: BondingGroupId
Name BondingGroupId
Description This parameter provides the group identification number of the bonding group
the bearer channel belongs to in case the bondingMode (see previous) is set to
atmBonding. The bonding group ID 0 is not used.
Instances Bearer
Values unsigned long
Table TNG 113-24: Upshift Noise Margin
Name Upshift Noise Margin

Description Only applicable in case of RA mode 3 (dynamic).
If the noise margin is higher than the upshift noise margin during a time interval,
which is equal to the minimum time interval for upshift rate adaptation, then an
upshift action of the data rate is performed. The new data rate is such that the
noise margin is equal to the target margin unless the upper bitrate boundary is
reached.
Instances DS, US
Values 0.0..31.0
Table TNG 113-25: Downshift Noise Margin
Name Downshift Noise Margin

If the noise margin is lower than the downshift noise margin during a time
interval, which is equal to the minimum time interval for downshift rate
adaptation, then a downshift action of the data rate is performed. The new data
rate is such that the noise margin is equal to the target margin unless the lower
bitrate boundary is reached.
Instances DS, US
Values 0.0..31.0
Table TNG 113-26: Minimum Time Interval for Upshift Rate Adaptation
Name Minimum Time Interval for Upshift Rate Adaptation

This parameter defines the consecutive time interval during which the noise
margin has to be higher than the upshift noise margin to perform an upshift
action of the data rate. The new data rate is such that the noise margin is equal
to the target margin unless the upper bitrate boundary is reached.
Instances DS, US
Values 0..16383
Granularity & Unit 1s
Table TNG 113-27: Minimum Time Interval for Downshift Rate Adaptation
Name Minimum Time Interval for Downshift Rate Adaptation

This parameter defines the consecutive time interval during which the noise
margin has to be smaller than the downshift noise margin to perform a downshift
action of the data rate. The new data rate is such that the noise margin is equal
to the target margin unless the lower bitrate boundary is reached.
Instances DS, US
Values 0..16383
Granularity & Unit 1s
Table TNG 113-28: Artificial Noise PSD
Name Artificial Noise PSD
Description TXREFANL defines the Transmitter Referred Artificial Noise Level to be used
as additional noise source at the transmitter. It is defined as an array of 32
breakpoints for downstream.
Points are given in frequency [kHz] and PSD [dBm/Hz] components, and are
translated to an array of the following form: TXREFANL = [(t1, PSD1), (t2, PSD2),
, (tN, PSDN)], where t1 < ti < tN.
For ADSL1 and ADSL2 only the frequencies upto 1104 kHz are taken into
account.
Values PSD component of breakpoint:

-40 dBm/Hz..-140 dBm/Hz
Special value (default): NoArtificialNoise
Frequency component of breakpoint: 0..2208 khz
Granularity & Unit 1 kHz; 0,5 dBm/H
Table TNG 113-29: INM Sensitivity Threshold
Name INM Sensitivity Threshold
Description The sensitivity threshold of x dB makes the impulse noise monitor x dB more
sensitive. To make the impulse noise monitor less sensitive, one has to use
negative x values. The expected behaviour is explained in PERF_R.A.1001.3.
A change in the configuration of the sensitivity threshold will trigger a reset of
the histograms at the CPE.
Instances Line DS
Values -40 dB.. 40 dB

Default: 0 dB
Table TNG 113-30: INM Pulse-Gap-Bridging Value
Name INM Pulse-Gap-Bridging Value
Description The pulse-gap-bridging mechanism defines that an impulse that is following a

first impulse within a time interval (from end of impulse 1 to the start of impulse
2) smaller than the Pulse-Gap-Bridging value shall be counted as one long
impulse. The Pulse-Gap-Bridging value is defined as an integer multiple of a
DMT symbol.
Instances Line DS
Values 1 - 10
Default: 0 (no Pulse-Gap-Bridging)
Table TNG 113-31: Warm Re-Init Disable
Name Warm Re-Init Disable
Description This bit controls the enabling/disabling of warm re-inits.

Meaning:
0: disable warm re-inits, only full cold inits are allowed
1: enable warm re-inits
Instances Line
Values Bit: 0/1

Default: 0
Table TNG 113-32: Programmable Resynch Triggers
Name Programmable Resynch Triggers
Description This array of integers controls the values of the required resynch triggers at both
the xTU-C and xTU-R. For each trigger, a special value is used for disabling.
The parameters applicable to the far-end are communicated to the CPE.
Meaning:
Persistency in seconds of [los; sef; lom; se; ncd; lcd; flos; rdi; flom; fse; fncd;
flcd]
Instances Line
Values [0255; c ; 0255] with a minimum of 3 seconds for (f)los
Default: [5; 5; 60; 10; 15; 15; 6; 6; 60; 10; 17; 17]
Special persistency value for each trigger: 0: disable trigger (except for (f)los)
Granularity & Unit 1 second

All parameters grouped under this requirement have a common for all DSL flavours
supported in Alcatel-Lucent DSLAM products (including VDSL and VDSL2). However,
the configured value, assigned by the operator, can be flavor dependent. Consequently,
all parameters will have several instances: one per flavor.
Modem features
Maximum aggregate transmit power
Maximum value of Maximum Aggregate Transmit Power for nonoverlapped operating
modes
Maximum PSD
Maximum value of Maximum PSD
Power backoff mode
Maximum aggregate receive power
Table TNG 113-33: Modem features
Name Modem Features
Description Specifies modem features which can be allowed or not by the operator.
Currently, only bit 0 (LSB) of this bitmap is interpreted by the Multi-ADSL
modem subsystem.
BIT0 Standard Compliancy: if active (1), the modem subsystem must turn off
all features not strictly compliant to the standard. If not active (0), the modem
subsystem is allowed to use to use these features.
The following examples are given to indicate which features shall be mapped to
this bit:
For all ADSLx flavors : transmission of NSIF messages in G.hs (see
GEN_R13.4).
For ADSL2x mode: Support of higher bitrates than allowed in ITU standards
for certain INP values (= support of higher D) (see also Table TNG 113-13)
This bit shall be provided for ADSL/2, READSL2 and ADSL2plus.
Instances Line
(1 of 2)
Values Bitmap
(2 of 2)
Table TNG 113-34: Maximum aggregate transmit power
Name Maximum Aggregate Transmit Power
Description Specifies the maximum total power level that is allowed to be transmitted in the
corresponding direction.
The maximum value (25.5 dBm) is used as special value to indicate that the
value defined in the corresponding Multi-ADSL standard must be used.
The usage of this parameter shall depend upon the used operation mode:
ADSL1x : parameter shall be ignored, since Max. Aggregate Power levels
are fixed within the relevant standards.
ADSL2x : input shall correspond to parameter MAXNOMATP
When the configured value is above the maximum aggregate transmit power
allowed by the relevant standard, the configured value is ignored.
Values 0 to 25.5 dBm
The constraints imposed by the standards are summarized in Table TNG 113-35.
Table TNG 113-35: Maximum value of Maximum Aggregate Transmit Power for
nonoverlapped operating modes
MaxATP US MaxATP DS
ADSL1/ADSL2/ADSL2plus Annex A 12.5 dBm 19.9 dBm
ADSL1/ADSL2/ADSL2plus Annex B 13.3 dBm 19.3 dBm
ADSL2/ ADSL2+ annex M 12.5 dBm 19.3 dBm

READSL2 12.5 dBm 18.8 dBm
Note
(1) The aggregate transmit power across the whole passband and measured at the line terminals, must
not exceed the values of Table TNG 113-35 by more than 0.5 dB, in order to accommodate
implementation tolerances
Table TNG 113-36: Maximum PSD
Name Maximum PSD
Description Maximum PSD parameter specifies the maximum nominal power spectral
density allowed on the line at the transmitter output (upstream and downstream)
for initialization and showtime signals.
Lowering the maximum PSD results in reduction of power consumption, by
paying the price of having a lower capacity.
When the configured value of MAXPSD is above the maximum PSD allowed by
the relevant standard, the configured value is ignored.
If only ADSL1x is enabled in the profile, and the configured value
MAXPSDds_ADSL is below -52 dBm/Hz, the modem subsystem generates a
configuration error only in case it is not able to support this non-standard setting.
Note: only one parameter exists for both READSL2 US masks. The same input
value will thus be interpreted for both modes.
Values US : -60.0 to -32.9 dBm/Hz

DS : -60.0 to -37.0 dBm/Hz
Note
(1) The Maximum PSD parameter cannot be used to boost the PSD beyond the standard PSD, it can
only be used to put additional constraints on top of the standard. The constraints imposed by the
standards are summarized in Table 9.
Table TNG 113-37: Maximum value of Maximum PSD
Maximum PSD Maximum PSD

US DS
ADSL1/ADSL2 -38 dBm/Hz -40 dBm/Hz
READSL2 Mode 1 -36.4 dBm/Hz -37 dBm/Hz
READSL2 Mode 2 -32.9 dBm/Hz -37 dBm/Hz
ADSL2plus -38 dBm/Hz -40 dBm/Hz

ADSL2/ ADSL2plus annex M EU56 mask -40.4 dBm/Hz -40 dBm/Hz
Note Support of MaxPSD down to -80dBm/Hz
Support of extended MAXPSD range down to -80 dBm/Hz in ADSL1x and

ADSL2x mode
Table TNG 113-38: Power backoff mode
Name Power Backoff Mode
Description Specifies the Power BackOff Mode for ADSL2x:

PBO Off: Upstream Power-Backoff mechanism is not used i.e. the parameter
Maximum Aggregate Receive Power US (see Maximum aggregate receive
power) is not interpreted by the Modem Subsystem.
PBO On: The ATU-C requests the Upstream PBO to comply to parameter
Maximum Aggregate Receive Power.
This parameter shall be ignored for ADSL1x.
Instances Line US
Values PsdPboOff
PsdPboOn
Table TNG 113-39: Maximum aggregate receive power
Name Maximum Aggregate Receive Power (3 tones)
Description Specifies the maximum allowed total receive power level allowed for ADSL2x .
This parameter shall only be used when Psd PBO parameter (see Power
backoff mode) is on.
The input shall correspond to parameter MAXRXPWR
This parameter shall be ignored for ADSL1x.
Instances Line US
Values -25.5 to 25.5 dBm
ADSL2plus-specific configuration parameters

The following configuration parameters will only be used when the selected operation
mode is ADSL2+:
PSD shape
Custom PSD shape:
Custom DS PSD Shape
Custom US PSD Shape
In all other operation modes, they will be ignored.
Table TNG 113-40: PSD shape
Name PSD Shape
Description For DS and US: specifies a predefined (standard) PSD shape (mask or
template) to be respected on the line in the corresponding direction.
The different predefined shapes are specified through enumeration. Each PSD
shape is characterized completely by the enumeration tag.
Values Enumeration. Next PSD Shapes Tags are defined for ADSL2plus:
DOWNSTREAM:
PSD_SHAPE_CUSTOM : The Custom PSD Shape (see further) will
specify the PSD shape.
PSD_SHAPE_ADSL2PLUS_CO : Normal PSD Mask for CO deployment.
PSD_SHAPE_ADSL2PLUS_CA_[X] : PSD Masks for Cabinet deployment.
[X] designates the cut-off frequency for the passband. The possible values
for [X] are 100 to 280 in steps of 10 tones.
Further details are given hereunder (Downstream PSD Shape Details)

In case DPBO parameters are specified, the Downstream PSD Shape
parameter is ignored.
UPSTREAM:
PSD_SHAPE_CUSTOM : The Custom PSD Shape (see further) will
specify the PSD shape.
PSD_SHAPE_ADSL2PLUS_DEFAULT : Standard US PSD mask.
DOWNSTREAM PSD SHAPE DETAILS:
In case the Central Office Mask is selected, there shall be no additional PSD shaping on
top of the PSD Mask defined by G.992.5 Annex A, Annex B and Annex M.
In case a Cabinet Mask is selected, the lower part of the spectrum shall be transmitted at
lower PSD level (shaped). The set of Cabinet Masks only differ in the cut-off frequency
for the stopband (see Figure 8).
Figure TNG 113-4: ADSL2+ PSD Masks for Cabinet deployment

PSD in
dBm/ Hz
PSD2 = -36.5
PSD1 = -95
subca rrier index

t1 t2 linea r sca le)
subca rrier index = frequency (kHz)/Df

(Df = 4.3125 kHz)
Each of the Cabinet PSD masks has 2 breakpoints: (t1,PSD1),(t2,PSD2)
PSD1=-95 dBm/Hz
PSD2=-36.5 dBm/Hz
t2 varies from tone 100 to 280 in steps of 10 tones
t1 = rounddown (t2 - (PSD2-PSD1)/2.2 dB/tone) = t2-27
This results in a total of 19 PSD Masks for Cabinet deployment, as illustrated in Table 10
Table TNG 113-41: ADSL2+ PSD masks for Cabinet deployment
PSD Mask t1 t2 f1 (kHz) f2 (kHz)
ADSL2Plus Ca 100 73 100 314.8125 431.25

ADSL2Plus Ca 110 83 110 357.9375 474.375
ADSL2Plus Ca 120 93 120 401.0625 517.5
ADSL2Plus Ca 130 103 130 444.1875 560.625
ADSL2Plus Ca 140 113 140 487.3125 603.75
ADSL2Plus Ca 150 123 150 530.4375 646.875
ADSL2Plus Ca 160 133 160 573.5 625 690
ADSL2Plus Ca 170 143 170 616.6875 733.125
ADSL2Plus Ca 180 153 180 659.8125 776.25
ADSL2Plus Ca 190 163 190 702.9375 819.375
ADSL2Plus Ca 200 173 200 746.0625 862.5
ADSL2Plus Ca 210 183 210 789.1875 905.625
ADSL2Plus Ca 220 193 220 832.3125 948.75
ADSL2Plus Ca 230 203 230 875.4375 991.875
ADSL2Plus Ca 240 213 240 918.5625 1035
ADSL2Plus Ca 250 223 250 961.6875 1078.125
ADSL2Plus Ca 260 233 260 1004.813 1121.25
ADSL2Plus Ca 270 243 270 1047.938 1164.375
ADSL2Plus Ca 280 253 280 1091.063 1207.5
Table TNG 113-42: Custom DS PSD Shape
Name Custom DS PSD Shape
Description Specifies a US PSD shape (mask or template) to be respected on the physical

line in the corresponding direction.
The PSD Shape is specified through the following set of parameters:
PsdShapeFlag: indicates whether the shape is filled in or not by the XDSL
Manager (if not, data are not trustable and should be ignored. In that case,
only limit masks shall apply).
PsdShapeType: indicates whether defined PSD points describe mask or
template. Only mask is supported, template is rejected (*).
PsdFreqScale : indicates whether PSD shape interpolation has to be done
on linear or logarithmic scale. However, the modem subsystem ignores this
parameter.
The modem subsystem allows up to 20 specified PSD points.
Note: 20 PSD points must be available even when the maximum number of
RFI bands (two in ADSL2+) are defined (thise means that in ADSL2+ the
total number of breakpoints to be supported by the modem is 20 for the
custom DS PSD + 2x4 for the RFI bands which means a total of 28
breakpoints).
The PSD shape implemented by the modem subsystem also needs to take
RFI bands into account (see RF band data)
Set of PSD Points:
PSD point = [frequency, max PSD]
Frequency : 0 - 30000 kHz
This range is defined for the VDSL passband. For Multi ADSL the
applicable range is only the passband of ADSL2plus
max PSD : 0 to -95 dBm/Hz
The valid PSD value = lowest value of (max PSD parameter and ITU
standard limit mask PSD level)
The PSD shape is made by connecting the PSD points via linear or logarithmic
interpolation (as in standard).
Following rules apply:
The operator can specify a custom PSD shape with brick wall or with more
strict requirements than specified in section 8.5.1 of G.992.5. It's the
responsibility of the modem subsystem to translate these requirements
according to the section 8.5.1 points 1-4 of G.992.5. As a minimum
requirement the modem subsystem shall at least be able to implement a
custom shape according to these standard requirements. The operator only
gets guarantees on the standard PSD shape. However this doesn't prevent
the modem subsystems to implement a PSD shape that approximates the
operator custom PSD shape more closely.
The RFI band specification is described in RF band data
The successive PSD points must have increasing ( ) frequencies.
defined at the same frequency f (brick wall):
point x: PSDx, f
point x+1: PSDx+1,f
In case DPBO parameters are specified, the Downstream Custom PSD
Shape parameter is ignored.
(*) Reject shall be done by raising the "Configuration Error" failure.
Instances Line DS
Values See details in Description field.

1 kHz for Frequency
Table TNG 113-43: Custom US PSD Shape
Name Custom US PSD Shape
Description Specifies a US PSD shape (mask or template) to be respected on the physical

line in the corresponding direction.
The PSD Shape is specified through the following set of parameters:
PsdShapeFlag: indicates whether the shape is filled in or not by the XDSL
Manager (if not, data are not trustable and should be ignored. In that case,
only limit masks shall apply).
PsdShapeType: indicates whether defined PSD points describe mask or
template. Only mask is supported, template is rejected (*).
PsdFreqScale : indicates whether PSD shape interpolation has to be done
on linear or logarithmic scale. However, the modem subsystem ignores this
parameter.
The modem subsystem allows up to 20 specified PSD points.
The PSD shape implemented by the modem subsystem also needs to take
RFI bands into account (see RF band data)
Set of PSD Points:
PSD point = [frequency, max PSD]
Frequency : 0 - 30000 kHz
This range is defined for the VDSL passband. For Multi ADSL the
applicable range is only the passband of ADSL2plus
max PSD : 0 to -95 dBm/Hz
The valid PSD value = lowest value of (max PSD parameter and ITU
standard limit mask PSD level)
The PSD shape is made by connecting the PSD points via linear or logarithmic
interpolation (as in standard).
Following rules apply:
The operator can specify a custom PSD shape with brick wall or with more
strict requirements than specified in section 8.5.1 of G.992.5. It's the
responsibility of the modem subsystem to translate these requirements
according to the section 8.5.1 points 1-4 of G.992.5. As a minimum
requirement the modem subsystem shall at least be able to implement a
custom shape according to these standard requirements. The operator only
gets guarantees on the standard PSD shape. However this doesn't prevent
the modem subsystems to implement a PSD shape that approximates the
operator custom PSD shape more closely.
The successive PSD points must have increasing ( ) frequencies.
defined at the same frequency f (brick wall):
point x: PSDx, f
point x+1: PSDx+1,f
(*) Reject shall be done by raising the "Configuration Error" failure.
Instances Line US
Values See details in Description field.

1 kHz for Frequency

The Initialization value is the parameter value when entering the showtime (L0) state.
Consequently, the value has to be derived during initialization. The Showtime value is the
(current if updated) parameter value during the showtime state. The Update frequency is
the update frequency of the parameter during showtime (L0) state.
The Multi-ADSL Modem Subsystem assures that the Showtime values (if applicable for
the considered parameter) are available for retrieval over the xDSL API within 10
seconds after entering the L0 state. During the first 10 seconds of the L0 state, the VDSL
Modem Subsystem returns the Initialization values (if applicable for the considered
parameter) if the Showtime value for the considered parameter is not available yet.
The following operational data parameters are supported:
Current operational mode

Operational mode capabilities
SNR margin
Loop attenuation
Signal attenuation
Aggregate output power
Actual Tx PSD
Last state transmitted
Attainable line bitrate
Actual line bitrate
Line relative capacity occupation
Attainable ATM bitrate (per bearer channel)
Actual ATM bitrate (per bearer channel)
Interleaving delay (per bearer channel)
Actual impulse noise protection (per bearer channel)
Actual L2 low power ATM Bitrate (per bearer channel)
Actual Artificial Noise PSD
Table TNG 113-44: Current operational mode
Name Current Operational Mode
Description The operational mode used for the current operation of the Multi-ADSL modem
subsystem (see Operating modes).
Instances Line
Values See Operating modes. Only 1 bit can be set to 1 at a time.
Initialization value Defined during configuration and G.hs.
Update frequency NA
Table TNG 113-45: Operational mode capabilities
Name Operational mode Capabilities
Description The total set of operational modes supported by the ATU-C and the ATU-R
respectively.
Instances ATU-C / ATU-R
Values See Operating modes.
Update frequency NA
Initialization value ATU-C: parameter reflects all the standards the modem chipset is able to
support.
ATU-R: parameter reflects the CPE supported standards indicated in G.hs. If
ANSI or ETSI activation tones have been detected, also the operation mode bits
for these mode are set.
Table TNG 113-46: SNR margin
Name SNR Margin
Description Indicates the current noise margin relative to the noise power that the ATU can
tolerate and still meet the target BER of 10-7 at 0 dB noise margin accounting
for all coding gains included in the design.
The SNR Margin given shall be the average of the margins (expressed in dB) of
all loaded carriers.
ADSL2:
According to ADSL2 standard an SNRM value of -512 is a special value
indicating that signal to noise ratio margin is out of range.
For downstream this special value -512 is translated to 51.2 dB.
For upstream the complete range -64 to 63 dB can be used
Instances DS/US
Values -64.0..+63.0 dB
Accuracy 0.5 dB
Update frequency DS: at least every 10 seconds via overhead channel.

US: at least every 10 seconds @ ATU-C.
Table TNG 113-47: Loop attenuation
transmitted at the opposite end over all subcarriers during initialization. It is not
updated during showtime.
Instances DS/US
(1 of 2)
Values 0..102.3 dB
Accuracy 0.5 dB
Update frequency NA
(2 of 2)
Table TNG 113-48: Signal attenuation
Name Signal Attenuation
transmitted at the opposite end over all subcarriers during showtime.
Note: difference with Loop Attenuation is that the transmit power has changed
for the subcarriers and that the total number of subcarriers during showtime
typically will be less than during initialization.
Instances DS/US
Values 0..102.3 dB
Accuracy 0.5 dB

US: at least every 10 seconds @ ATU-C.
Table TNG 113-49: Aggregate output power
Name Aggregate Output Power
Description Actual aggregate output power (that is, the total output power for the carriers of
the corresponding direction) when the modem is in showtime.
Instances DS/US
Values -31.0..+31.0 dBm

Note: when the actual aggregate transmit power is exceeding an extremum
value that can be represented, clamping to this extremum representable value
is done.
Accuracy 0.1 dB (maximum admissible deviation with actual measured value)
Update frequency DS: each bit swap

US: each bit swap
Table TNG 113-50: Actual Tx PSD
Name Actual Tx PSD
Description Actual transmit power spectrum density over the subcarriers at the U interface,
including artificial noise.
Instances DS/US
Values -127.0 to 0 dBm/Hz.
A value indicated as noPSD is a special value. It indicates that no power is
transmitted on that carrier.
Accuracy 0.1 dBm/Hz

Table TNG 113-51: Last state transmitted
Name Last state transmitted
Description This parameter represents the last successful transmitted initialization state in
the relevant direction in the last full initialization performed on the line.
Initialization states are defined in the individual ADSL Recommendations and
are counted from 0 (if G.994.1 is used) or 1 (if G.994.1 is not used) up to
Showtime (= 32).
The DS parameter is stored in ADSL2x operation modes only and is provided
during loop diagnostics mode. The index of the ATU-C state is represented by
an 8-bit integer value from 0 (G.994.1 phase) and 1 (C-QUIET1) to 31
(C-SEGUE4) and 32 (CSHOWTIME).
The US parameter is retrieved from the ATU-R and provided to the xDSL
Manager only during loop diagnostics mode. The index of the ATU-R state is
represented by an 8-bit integer value from 0 (G.994.1 phase) and 1 (R-QUIET1)
to 30 (R-SEGUE4) and 31 (R-SHOWTIME).
Instances DS/
(1 of 2)
Values 0 to 32
Update frequency Not Applicable
(2 of 2)
Table TNG 113-52: Attainable line bitrate
Name Attainable Line Bitrate

Description Indicates the maximum bitrate the modem can sustain on the line (i.e. the ATM
payload plus all overhead from the PMD, PMS-TC and TPS-TC layers) taking
the current configuration (INP, delay, carriermask, coding ) into account (e.g.
assuming same type of coding gain). If multiple bearer channels are active, the
calculation assumes that all capacity would be allocated to the bearer channel
with the highest coding gain.
Note: the ATU-C takes the CPE capabilities into account (e.g. if the CPE does
not support S=1/2, even if the CO supports S=1/2 the reported rate is the value
without S=1/2 support)
The accuracy of this attainable line bitrate is 10 %. This means that if the modem
retrains - without change in loop or noise conditions - the actual line bitrate is
within 10% of the reported attainable line bitrate before re-initialisation.
Instances DS/US
Values 0..65535
Remark: in case of no EOC, the initialization value for Attainable DS Line Bitrate
is returned.

US: at least every 10 seconds @ ATU-C
Table TNG 113-53: Actual line bitrate
Name Actual Line Bitrate
Description The total line rate currently set up by PMD layer (i.e. the actual ATM payload
plus all overhead information from the PMD, PMS-TC and TPS-TC layers). The
Line Bitrate is given by the number of bits per DMT symbol, multiplied with the
number of DMT symbols per second, divided by 1000 (kbps).
Instances DS/US
Values 0..65535
Update frequency ADSL2x : every time SRA is executed.
Table TNG 113-54: Line relative capacity occupation
Name Line Relative Capacity Occupation
Description The ratio of the Actual Line Bitrate and the Attainable Line Bitrate when both are
available.
In case of an activation error Configuration not feasible, it is set to 100 % for
each direction where the minimum bitrate cannot be sustained.
Note : L2 state transitions shall be transparent, i.e. DS Line Relative Capacity
Occupation shall always be L0 line bitrate, even if line state is L2 !
Instances DS/US
Values 0..100%
Update frequency Every time Actual and/or Attainable Line Rate are updated.
Table TNG 113-55: Attainable ATM bitrate (per bearer channel)
Name Attainable ATM Bitrate
Description Indicates the maximum ATM bitrate (i.e. ATM payload plus header bytes) the
ATU can sustain on the line taking the current configuration (INP, delay,
carriermask, coding ) into account, with margin not lower than Target Noise
Margin. This parameter is provided for each activated bearer channel. The
calculation estimates the attainable ATM Bitrate assuming that all available
capacity is allocated to that bearer channel.
Note: the ATU-C takes the CPE capabilities into account (e.g. if the CPE does
not support S=1/2, even if the CO supports S=1/2 the reported rate is the value
without S=1/2 support)
The accuracy of this attainable ATM bitrate is 10 %. This means that if the
modem retrains - without change in loop or noise conditions - the actual ATM
bitrate is within 10% of the reported attainable ATM bitrate before
re-initialisation.
Values 0..65535
Update frequency DS: each = 10 seconds via overhead channel.

US: each < 10 seconds @ ATU-C
Table TNG 113-56: Actual ATM bitrate (per bearer channel)
Name Actual ATM Bitrate
Description The actual transport rate (that is, the transported payload plus header bytes)
expressed in kbps in the L0 state.
Instances DS/US per bearer channel
Values 0..65535
Update frequency ADSL2x : every time SRA or OLR is executed.
Table TNG 113-57: Interleaving delay (per bearer channel)
Name Actual Interleaving Delay
Description Actual delay caused by the interleaving and de-interleaving functionality.

Values 0..63
Update frequency ADSL2x : updated every time Sp and/or Dp changes (during Initialization or
showtime)
Table TNG 113-58: Actual impulse noise protection (per bearer channel)
Name Actual Impulse Noise Protection
Description Actual value of INP parameter, defined in Minimum impulse noise protection, in
current session:
The Modem Subsystem uses this formula to calculate actual INP
Actual INP = 0.5 * SpxDp* (Rp / N_FECp)
for each latency path p.
Values 0..8.0 DMT symbols. Actual INP values of 16 DMT symbols will be ceiled to
actual INP of 8 DMT symbols.
Granularity & Unit ADSL2x : updated every time Sp, Dp, Rp or N_FECp changes (during
Initialization or showtime)
Update frequency NA
Table TNG 113-59: Actual L2 low power ATM Bitrate (per bearer channel)
Name Actual L2 low power ATM Bitrate
Description The actual ATM rate (i.e. the ATM payload plus header bytes) expressed in
kbps in the L2 state.
Instances DS for each bearer channel
Values 0 65535
Update frequency ADSL2x : every transition from L0 to L2 and during L2
Table TNG 113-60: TPS-TC mode capabilities
Name TPS-TC Mode Capabilities
Description The total set of TPS-TC modes supported by the VTU-O and the VTU-R
respectively.
(1 of 2)
Instances Line Near-end/Far-end
Values Bitmap:
TPSTCModesATMBit
TPSTCModesPTM_64_65Bit
TPSTCModesPTM_HDLCBit
Update frequency NA
(2 of 2)
Table TNG 113-61: Actual Artificial Noise PSD
Name Actual Artificial Noise PSD
Description Actual artificial noise power spectrum density per subcarrier at the constellation
encoder.
Instances For each carrier
Values -140 to 0 dBm/Hz

A value indicated as noPSD is a special value (default). It indicates that no
artificial noise is transmitted on that carrier.
Update frequency DS: at the end of init
Purpose
This document gives a summary of the configuration used in the configuration examples
in the DLP documents
Equipment
Table TNG 114-1 lists the equipment.
Table TNG 114-1: Equipment
Equipment Board Type
Subrack XD
acu aacu-c
nt-a, nt-b ecnt-c
iont ecnc-a
lt:1/1/4 evlt-c
lt:1/1/5 eblt-c
lt:1/1/6 polt-b
lt:1/1/7 eblt-k
lt:1/1/8 eblt-k
lt:1/1/9 smlt-k
xDSL profiles
Table TNG 114-2 lists the configured xDSL profiles.
Table TNG 114-2: xDSL profiles
ID Name
Service profile 7 ADSL_profile
8 VDSL_profile
10 XSRVC_0_0
Spectrum profile 4 vdsl_profile
5 adsl_profile
Bonding 2 GroupProfile1
Note
(1) Other profiles are not used for actual lines
SHub ports
Table TNG 114-3 lists the configured SHub ports.
Table TNG 114-3: SHub ports
Port Port Type

1 Subtending
2 Subtending
3 Network
4 Network
5 Network
6 Network
7 Network
VLANs
Table TNG 114-4 lists the configured VLANs.
Table TNG 114-4: VLANs
VLAN LT mode SHub mode LT 1/1/x Network Port
4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7 8 9
56 residential-bri
dge
70 layer2-term-netw T
port
port
100 residential-bri residential-bridge x x x x U

dge
101 layer2-termina residential-bridge x x x x x x x x x x x x x x x x T

ted
200 residential-bri residential-bridge x x x x x x T

dge
300 cross-connect cross-connect x T
301 cross-connect cross-connect x T
350 qos-aware cross-connect x T

400 cross-connect x T
400:0 cross-connect
401:0 cross-connect
500:0 layer2-termina
ted
500:6 cross-connect
00
ted
501:6 cross-connect
01
512 layer2-terminate x
d
ted
512:5 cross-connect
7
560 residential-bri
dge
(1 of 2)
VLAN LT mode SHub mode LT 1/1/x Network Port
4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7 8 9
port
port
2200 cross-connect cross-connect
4090 layer2-termina v-vlan x x x x x x

ted
4093 reserved T
(2 of 2)
Note
(1) U: untagged - T: tagged
VRFs
Table TNG 114-5 lists the VRFs on the LT.
Table TNG 114-5: LT VRFs
VRF Mode VLAN Gateway
1 Forwarder
5 Router 4090 10.178. 14.97/27
16 Forwarder 101 192.168.116. 1/24
Table TNG 114-6 lists the VRFs on the SHub.
Table TNG 114-6: SHub VRFs
VRF Mode VLAN IP Address DHCP Relay to...
0 Slow-path
10 Slow-path 100 192.168.100.2/24 182.168.100.13
15 Fast-path 70 192.168.70.39/24
80 192.168.80.39/24
1450 10.178.14.85/27 10.178.14.97
4090 10.178.14.97/27
17 Slow-path 101 192.168.116. 2/24 192.168.116. 2
Lines
VDSL
Table TNG 114-7 lists the VDSL lines.
Table TNG 114-7: VDSL lines
Line Mode VLAN VRF CPE IP

Address
1/1/4/1 Cross-connect 301
1/1/4/2 Stacked 401:0
1/1/4/3 Stacked 501:601

1/1/4/12 Residential-bridge 200
1/1/4/14 IPoE 4090 16
1/1/4/15 PPPoE 101
ADSL
Table TNG 114-8 lists the ADSL lines.
Table TNG 114-8: ADSL lines
Line Mode VLAN VRF CPE IP

Address
1/1/5/1 Cross-connect 300
1/1/5/2 Stacked 400:0
1/1/5/3 Stacked 500:600
1/1/5/4 QoS-aware 350

1/1/5/7 IPoA cross-connect 2200 192.168.150.2
1/1/5/8 IPoA cross-connect 512:37 192.168.1.1
1/1/5/10 PPPoA-PPPoE relay
1/1/5/12 Residential-bridge 200
1/1/5/13 IPoA 16 10.178.14.53
1/1/5/14 IPoE 16
1/1/5/15 PPPoE
Bonding
System level: 1/1/7/21, 1/1/8/25

Chipset level: 1/1/8/47, 1/1/8/48
SHDSL
4-wire: 1/1/9/1, 1/1/9/3

EFM: 1/1/9/5
IMA: 1/1/9/16, 1/1/9/18, 1/1/9/21, 1/1/9/24
IP bridge
Figure TNG 114-1: Configuration example IP Bridge

VLAN VLAN
LT-y 100 SHub 100
CPE
RB RB
Network
VRF 10
DHCP
relay
RB: Residential bridge VLAN
IP forwarder
Figure TNG 114-2: Configuration example IP forwarder

VLAN VLAN
LT-y 101 SHub 101
CPE
L2-term RB
VRF 16
Network
VRF 17
DHCP
relay
L2-term: Layer2-terminated VLAN RB: Residential bridge VLAN
IP router
Figure TNG 114-3: Configuration example IP router

VLAN VLAN
LT-y 4090 SHub 1450
CPE
L2-term V-VLAN L2-term-nwp
VRF 5 VRF 15 Network
router
&
DHCP
relay
10.178.14.97/27 10.178.14.85/27
L2-term: Layer2-terminated VLAN V-VLAN: Virtual VLAN L2-term-nwp: Layer2-terminated VLAN

on network port
Purpose
This document describes the numbering schemes that are supported by the NE with
regard to the slot positions in the subracks.
To be able to align the different numbering schemes, an option is provided to the CLI
operator to switch from one numbering scheme to the other; see DLP 103.
Terminology
The different slot position schemes are:
type-based: Type-based numbering (flat numbering per slot type from left to right
starting with 1, TL1 format.)
Position-based:
This slot position scheme is a flat-numbering scheme from left to right (within the
subrack when the boards are positioned vertically) or from bottom to top (within the
subrack when the boards are placed horizontally) starting with 1. This is in fact equal
to the physical position numbering from left to right or from bottom to top starting with
1.
position-based
legacy-num: This numbering is identical to position-based except for some very
specific configurations (for example, ARAM-D and ALTS-M/Q, which are all
characterized by the fact that the first LT position is not equal to the 4th slot position)
where previously a kind of type-based numbering was used (that is, a fixed relation
between CLI slot number and equipment log slot number).
log-slot-num: Logical slot ID (that is, the numbering method defined for equipment
identification in the MIB.)
Translation table
lt x: line board x
lp x: applique x
Subrack: what is printed on the subrack itself
Logical slot ID: ID that is used from and to equipment subsystem to identify a slot
XD equipment
Table TNG 115-1 shows the translation table for the XD splitterless subrack XD-LT
(ALTS-T).
Table TNG 115-1: Translation table for XD-LT
Silk ac nt nt lt lt lt lt lt lt lt lt lt lt1 lt1 lt1 lt1 lt1 lt1 lt1

u a b 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
Type based ac nt nt lt lt lt lt lt lt lt lt lt lt1 lt1 lt1 lt1 lt1 lt1 lt1
u a b 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
Legacy 1 2 3 4 5 6 7 8 9 1 1 1 13 14 15 16 17 18 19
based 0 1 2
Position 1 2 3 4 5 6 7 8 9 1 1 1 13 14 15 16 17 18 19
based 0 1 2
Logical slot 0 1 2 3 4 5 6 7 8 9 1 1 12 13 14 15 16 17 18
ID 0 1
Table TNG 115-2 shows the translation table for the XD-Combo300 subrack (ALTS-U).
Table TNG 115-2: Translation table for XD-Combo300
Silk ac nt nt lt lt lt lt lt lt lt lt lt lt1 lt1 lt1 lt1 lt1 lt1 lt1

u a b 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
Type based ac nt nt lt lt lt lt lt lt lt lt lt lt1 lt1 lt1 lt1 lt1 lt1 lt1

u a b 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
Legacy 1 2 3 4 5 6 7 8 9 1 1 1 13 14 15 16 17 18 19
based 0 1 2
Position 1 2 3 4 5 6 7 8 9 1 1 1 13 14 15 16 17 18 19
based 0 1 2
Logical slot 0 1 2 3 4 5 6 7 8 9 1 1 12 13 14 15 16 17 18
ID 0 1
FD equipment
For FD equipment, legacy-based numbering is equal to position-based numbering.
Table TNG 115-3 shows the translation table for the 7302 FD subrack (NFXS-A).
Table TNG 115-3: Translation table for NFXS-A
Silk l l l l l l l l n iont/lt nbt/lt l lt lt lt lt lt lt lt

t t t t t t t t t 17 18 t 1 1 1 1 1 1 1
1 2 3 4 5 6 7 8 a 9 0 1 2 3 4 5 6
Type based l l l l l l l l n iont/lt nbt/lt l lt lt lt lt lt lt lt

t t t t t t t t t 17 18 t 1 1 1 1 1 1 1
1 2 3 4 5 6 7 8 a 9 0 1 2 3 4 5 6
Legacy 1 2 3 4 5 6 7 8 9 10 11 1 1 1 1 1 1 1 1
based 2 3 4 5 6 7 8 9
Position 1 2 3 4 5 6 7 8 9 10 11 1 1 1 1 1 1 1 1
based 2 3 4 5 6 7 8 9
Logical slot 3 4 5 6 7 8 9 1 1 0/19 2/20 1 1 1 1 1 1 1 1

ID 0 1 2 3 4 5 6 7 8
Table TNG 115-3 shows the translation table for the 7330 FD subrack (NFXS-B).
Table TNG 115-4: Translation table for NFXS-B
Silk n iont/l nbt/lt l l l l l l l l

t t9 10 t t t t t t t t
a 1 2 3 4 5 6 7 8
Type based n iont/l nbt/lt l l l l l l l l

t t9 10 t t t t t t t t
a 1 2 3 4 5 6 7 8
Legacy 1 2 3 4 5 6 7 8 9 1 1
based 0 1
Position 1 2 3 4 5 6 7 8 9 1 1
based 0 1
Logical slot 0 1 2 3 4 5 6 7 8 9 1
ID 0
ARAM-D equipment
Table TNG 115-5 shows the translation table for the 4-LT shelf or ARAM-D shelf.
Table TNG 115-5: Translation table for ARAM-D equipment
Silk lt lt lt lt l l l l lt lt
1 2 3 4 t t t t 6 7
5 6 7 5
Type based lp lp lp lp l l l l n n
1 2 3 4 t t t t t t
1 2 3 4 a b
Legacy (4 (5 (6 (7 4 5 6 7 2 3
based ) ) ) )
(1 of 2)
Position 1 2 3 4 5 6 7 8 9 1
based 0
Logical slot 1 1 1 1 3 4 5 6 1 2
ID 3 3 3 3
1 2 3 4
(2 of 2)
Glossary
10/100Base-T 10- to 100-Mb/s LAN

An IEEE standard for 10/100 Mb/s twisted-pair Ethernet wiring.
10Base-T An IEEE 802.3 LAN transmission standard for Ethernet. 10Base-T carries
data at 10 Mb/s to a maximum distance of 328 ft (100 m) over unshielded
twisted-pair wire.
100Base-TX An IEEE 802.3 LAN transmission standard for Fast Ethernet. 100Base-TX
carries data at 100 Mb/s over two pairs of shielded twisted-pair or
Category 5 unshielded twisted-pair wire.
1000Base-BX10-D (-U) An IEEE 802.3 LAN transmission standard for bidirectional point-to-point
1000 Mb/s Gigabit Ethernet over single-fiber for distances of up to 6.2 mi
(10 km). Always used in pairs, wavelength division multiplexing is
performed in the SFP to split the optical signal into two light paths. The
1000Base-BX10-D (downstream) transmits a 1490 nm signal and receives a
1310 nm signal. The 1000Base-BX10-U (upstream) transmits a 1310 nm
signal and receives a 1490 nm signal.
1000Base-EX An IEEE 802.3 LAN transmission standard for 1000 Mb/s Gigabit Ethernet
using Long Wavelength (LX) laser transmitters over fiber-optic cable for
distances up to 24.9 mi (40 km).
1000Base-LX An IEEE 802.3 LAN transmission standard for 1000 Mb/s Gigabit Ethernet
1000Base-SX An IEEE 802.3 LAN transmission standard for 1000 Mb/s Gigabit Ethernet
using Short Wavelength (SX) laser transmitters over fiber-optic cable.
1000Base-ZX An IEEE 802.3 LAN transmission standard for 1000 Mb/s Gigabit Ethernet
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 GL-1
Glossary
23-in. preconfigured This rack is 23 inches wide, 7 feet high, and has 43 rack spaces. It comes
rack preconfigured with one or two ARAM-D shelves, and can be extended to
9 feet or 11.5 feet in height.
3DES Triple DES
A mode of the DES encryption algorithm that encrypts data three times
instead of once. Three 64-bit keys are used for an overall key length of 192
bits; the first encryption is encrypted with a second key, and the resulting
cipher text is encrypted with a third key.
7302 ISAM Alcatel 7302 ISAM
The 7302 ISAM is a DSL access multiplexer that operates in a packet
aggregation network. The 7302 ISAM enables deployment of triple-play
services, such as video on demand, high-definition TV, and broadcast TV
services for all subscribers simultaneously.
7330 ISAM FTTN Alcatel-Lucent 7330 Intelligent Services Access Manager Fiber to the Node
A standalone xDSL multiplexer designed for the ease and rapid deployment
of high-bandwidth IP services between high-bandwidth, optical fiber-based
transmission media, and copper-based xDSL subscribers.
AAL ATM Adaptation Layer
Protocol used by ATM to segment and reassemble data for insertion into an
ATM cell; also performs error checking and correction.
AAL1 ATM Adaptation Layer 1
Type 1 class of AAL service supporting constant bit rate, and
time-dependent traffic such as voice and video.
Type 2 class of AAL service characterized by voice and video transfer.
Type 5 class of AAL service characterized by high-speed data transfer.
ACL Access Control List
ACO Alarm Cut Off
ACO allows the audible alarms to be extinguished without affecting the
visual alarms. The audible alarms can be toggled as enabled or disabled.
ACU Alarm Control Unit
Collects shelf alarms and provides an alarm interface to the CO alarm
system.
GL-2 June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Glossary
ADSL Asymmetric Digital Subscriber Line

Technology that enables high-speed asymmetric data transmission between
two modems, one at a service provider location and one at the subscriber
premises, over a single twisted-pair copper telephone wire. There is more
than one type of ADSL; collectively, the different types of ADSL (for
example, ADSL, ADSL2, READSL) are referred to as multi-ADSL.
AES Advanced Encryption Standard
A symmetric 128-bit block data encryption algorithm.
AFAN-L ADSL Fan Unit
An ARAM-D shelf component that cools the shelf.
AIS Alarm Indication Signal
ALP-248C cabinet Alcatel Low Profile dual 48-inch remote terminal cabinet
ALP-248E cabinet Alcatel Low Profile dual 48-inch remote terminal cabinet
AMS Access Management System
A UNIX-based, client-server architecture controller for 7330 ISAM FTTN
systems.
AMSL Above Mean Sea Level
ANSI American National Standards Institute
Nonprofit, nongovernmental body supported by over 1000 trade
organizations, professional societies, and companies; ANSI was established
for the creation of voluntary industry standards.
APS Automatic Protection Switching
The capability of a transmission system to detect a failure on a working
facility and switch to a protection facility to recover the traffic, thus
increasing overall system reliability.
ARAM-D Four-LT-Slot Shelf
The shelf type used for the 7330 ISAM FTTN and for the ES that has four
LT slots and holds all the other shelf components. The ARAM-D shelf has
mounting flanges that enable it to be mounted horizontally or vertically in a
23-inch rack, or horizontally or vertically in a CO, CEV, or OSP cabinet.
ARP Address Resolution Protocol
A protocol within TCP/IP that maps IP addresses to Ethernet MAC
addresses. TCP/IP requires ARP for use with Ethernet.
ASAM Advanced Services Access Manager
Alcatel DSLAM that delivers ATM-based services and provides an OC3c
interface to the network side and ATM multiplexing and LT interfaces to the
customer side. The ASAM also provides an OC3c interface to remote
multiplexing equipment.
Glossary
ASCII American Standard Code for Information Interchange

Coding method used to convert letters, numbers, punctuation, and control
codes into digital form.
ASEM-B A 48-port multi-ADSL and POTS splitter remote expansion unit for the
ARAM-D shelf. It features a flood resistant, environmentally hardened
enclosure that is compliant with GR-950-CORE.
ASP Access Service Provider
ATM Asynchronous Transfer Mode
Multiplexed information transfer method in which the information is
organized into fixed-length cells of 53 bytes and transmitted according to the
needs of each user.
AVPC-A Low-pass Filter Applique
A 48-port multi-ADSL, VDSL, and VDSL2 applique and POTS splitter for
the ARAM-D shelf that provides connectivity between POTS CO lines,
high-bandwidth IP services (through an LT unit), and 48 xDSL subscriber
drop lines, and which supports ITSC.
AWG American Wire Gauge
AWG is a standard measuring gauge for non-ferrous conductors.
AWS Alcatel WorkStation
BAC Buffer Acceptance Control
BE Best Effort
BER Bit Error Rate
Measure of transmission quality expressed as the percentage of received bits
in error compared to the total number of bits received.
BITS Building Integrated Timing Source
A BITS is a clock that supplies DS1 (1.554 Mb/s) or composite clock timing
reference to all other clocks in a building.
blowfish A freely available symmetric block cipher designed as a drop-in replacement
for DES or IDEA. Blowfish allows variable-length keys of up to 448 bits.
BNC Bayonet Neil-Concelman
A BNC connector is a locking connector for slim coaxial cables, such as
those used for Ethernet.
BOOTP Bootstrap Protocol
BOOTP is a member of the IP family of protocols that allows a diskless
client machine to learn, among other information, its IP address. BOOTP
starts a networked machine by reading boot information from a server.
BOOTP is commonly used for desktop workstations and LAN hubs.
Glossary
BRAS Broadband Remote Access Server

BRI Basic Rate Interface
One type of interface for the ISDN product. BRI consists of two 64 kb/s
B-channels and one 16 kb/s D-channel for a total of 144 kb/s.
CAC Connection Admission Control
An algorithm that evaluates whether or not a new connection can be added
to the node.
CAC examines QoS objectives defined by the PVC service category, as well
as its configured traffic descriptor and traffic rates. CAC determines whether
the system can satisfy these criteria for the PVC and whether the PVC will
affect the guaranteed QoS that existing PVCs already have on the node.
CBR Constant Bit Rate
CCSA Checkpoint Certified Security Administrator
or
China Communications Standards Association
CDE Component Development Environment
Development discipline based on the reuse of components to ease rapid
time-to-market.
CEV Controlled Environmental Vault
Temperature- and humidity-controlled underground vault that houses the
7330 ISAM FTTN system at a remote location.
CFM Cubic Feet per Minute
CHAP Challenge Handshake Authentication Protocol
A PPP authentication method for identifying a dial-in user. The user is given
an unpredictable number and challenged to respond with an encrypted
version. CHAP does not itself prevent unauthorized access; it only identifies
the remote end.
CL Controlled Load
CLEI Common Language Equipment Identifier
CLI Command Line Interface
A workstation access method interface that uses CLI commands to
communicate to any network element in the 7330 ISAM FTTN network.
CMOS Complementary Metal Oxide Semiconductor
CMP Communications Plenum Cable
Glossary
CO Central Office
Telephone switching center that connects subscribers within a telephone
network.
CODEC Coder decoder
COLO Collocation
CPCS Common Part Convergence Sublayer
CPCS is the portion of the convergence sublayer of an AAL that remains the
same regardless of traffic.
CPE Customer Premises Equipment
Customer-owned telecommunications equipment at customer premises used
to terminate or process information from the public network.
CPE-MM CPE Management Machine
CPR Continuing Property Record
CPR is a six-character code that can be used to classify equipment items into
various property types.
CPRs also provide property record unit identification that allows network
service providers to create asset records for the purpose of equipment
engineering, ordering, invoice processing, asset management, and auditing.
CPU Central Processing Unit
The part of a computer that performs the logic computational and
decision-making functions.
CSMA/CD Carrier Sense Multiple Access with Collision Detection
A data communications mode in a shared medium in which access
contention problems are solved by denying access to one of the contenders.
CT Craft Terminal
Workstation that has element management system software installed on it.
C-VLAN Customer Virtual LAN
CWDM Coarse Wavelength Division Multiplexing
DA Destination Address
DES Data Encryption Standard
An ANSI symmetric-key encryption method that uses a 56-bit key and the
block cipher method, which breaks text into 64-bit blocks and then encrypts
them. DES was standardized by ANSI in 1981 as ANSI X.3.92.
DES-56 See DES.
Glossary
DHCP Dynamic Host Configuration Protocol

DHCP is a client/server service that is an extension of the BOOTP protocol.
DHCP simplifies the configuration of a client workstation since no IP
addresses, subnet masks, default gateways, domain names, or DNSs must be
programmed. With DHCP, this information is dynamically leased from the
DHCP server for a predefined amount of time. Because the information is
stored on a server, it centralizes IP address management, reduces the number
of IP addresses to be used, and simplifies maintenance. RFC 2131 defines
DHCP.
DLC Data Link Connection
A frame relay connection.
or
Digital Loop Carrier
DLP Detailed Level Procedure
DNS Domain Name Server
DSCP Differentiated Services Code Point
A six-bit value encoded in the type-of-service field of an IP packet header.
It identifies the CoS that the packet should receive.
DSL Digital Subscriber Line
A DSL is a single twisted-pair that supports full-duplex transmission at a bit
rate of 160 kb/s (144 kb/s for 2B+D data, 12 kb/s for framing and error
correction, and 4 kb/s for the embedded operations channel).
DSLAM Digital Subscriber Line Access Multiplexer
A DSLAM card converts xDSL signals into ATM traffic. For a service
management application, if the service user is connected to the ATM
network through a DSLAM port, the network access is provisioned using a
DSLAM attachment type.
DSP Digital Service Provider
EAPOL Extensible Authentication Protocol Over LAN
EBLT-C Multi-ADSL Line Termination Unit
A card that supports connectivity between the NT unit, PSTN, and
multi-ADSL subscribers through the AVPC-A, HLPC-H, or HLPC-J
applique.
EBLT-E Multi-ADSL Line Termination Unit
A card that supports connectivity between the NT unit, PSTN, and
multi-ADSL subscribers through the AVPC-A, HLPC-H, or HLPC-J
applique.
Glossary
EBLT-K Multi-ADSL Line Termination Unit with system level bonding

A card with system level bonding capability that supports connectivity
between the NT unit, PSTN, and multi-ADSL subscribers through an
AVPC-A, HLPC-H, or HLPC-J applique.
ECI Equipment Catalog Item
An equipment catalog item is a six-digit numeric code that translates into the
bar code on the bar code label. ECI codes are also used as internal processing
codes.
ECMP Equal Cost Multi-Path routing
ECNT-A Combined Network Termination Unit
An NT unit that provides Ethernet and/or Gigabit Ethernet optical and/or
electrical connectivity to a high-bandwidth IP services network.
ECNT-C Combined Network Termination Unit
An NT unit that provides Ethernet and/or Gigabit Ethernet optical and/or
electrical connectivity to a high-bandwidth IP services network.
EDSE-A Expansion Shelf Controller
An expansion shelf controller that provides some control functions for the
expansion shelf. The EDSE-A card also provides four Ethernet expansion
links for inter-shelf communications and for connecting the remote LT units
on the ES to the 7330 ISAM FTTN host shelf.
EFM Ethernet in the First Mile
A set of copper and fiber-based access technologies that are based entirely
on Ethernet packet transport.
eHCL Electrical High Capacity Link
EIA Electronic Industries Association
A group that specifies electrical transmission standards. The EIA and TIA
have developed numerous well-known communications standards,
including EIA/TIA-232 and EIA/TIA-449.
EMAN Ethernet Metropolitan Area Network
EMS Element Management System
An EMS manages the components of a network.
EPS Equipment Protection Switching
The capability of physical equipment to detect a failure on a working facility
and switch to a protection facility to recover the traffic, thus increasing
overall system reliability.
Glossary
ES Expansion Shelf
An expansion shelf using the same shelf as the 7330 ISAM FTTN host shelf
(ARAM-D shelf), but with some different units installed to provide
additional subscriber line connections for the host shelf.
ESD Electrostatic Discharge
ETR Extended Temperature Range
ETSI European Telecommunications Standards Institute
The European counterpart to ANSI. Established to produce
telecommunication standards integration in the European community for
users, manufacturers, suppliers, and Post Telephone and Telegraph
administration.
EVLT-A 24-port VDSL Line Termination Unit
A 24-port card for the 7330 ISAM FTTN that supports connectivity between
an NT unit and ADSL, VDSL, and VDSL2 subscribers through the VPSC-D
applique.
EVLT-F 48-port VDSL Line Termination Unit
A 48-port card for the ARAM-D shelf that supports connectivity between
the NT unit and ADSL, VDSL, and VDSL2 subscribers through an AVPC-A
applique, which supports ITSC.
FDM Frequency Division Multiplexing
Multiplexing in which several independent signals are allocated separate
frequency bands for transmission over a common channel.
FE Fast Ethernet
FENT Fast Ethernet Network Termination
FIB Forwarding Information Base
The FIB is an internal table containing only the IP routes actually used by a
router to forward IP traffic.
FIFO First In, First Out
FPGA Field Programmable Gate Array
An integrated chip with functions that can be programmed by software.
FTP File Transfer Protocol
GE Gigabit Ethernet
Ethernet interface running at 1000 Mb/s.
Glossary
GENC-E Alarm Control and Host Expansion Interface Unit

An alarm control and host expansion interface unit that performs multiple
functions and provides additional optical Gigabit Ethernet connectivity and
expansion links for the ARAM-D shelf.
GENC-F Alarm Control and Host Expansion Interface Unit
An alarm control and host expansion interface unit that performs multiple
functions, including ITSC, and provides additional optical Gigabit Ethernet
connectivity and expansion links for the ARAM-D shelf.
GFC General Facilities Card
See PWIO-B.
GUI Graphical User Interface
A user screen that includes menus, tables, or icons to query or change data;
usually distinguished from the command line interface.
HCUT-C POTS Cut-Through Applique
An applique that provides connectivity between POTS CO lines and drop
lines for 48 subscribers. The HCUT-C is designed to provide POTS
cut-through for subscribers who have not yet subscribed to xDSL service.
HLPC-H Extreme Density Low-pass Filter Applique
A multi-ADSL and POTS splitter applique that provides connectivity
between POTS CO lines, high-bandwidth IP services (through an LT unit)
and 48 multi-ADSL subscriber drop lines on the ARAM-D shelf.
HLPC-J Extreme Density Low-pass Filter Applique with MTA
A multi-ADSL and POTS splitter applique with MTA capability that
provides connectivity between POTS CO lines, high-bandwidth IP services
(through an LT unit) and 48 multi-ADSL subscriber drop lines on the
ARAM-D shelf.
HSI High Speed Internet
iBridge Intelligent Bridging mode, also known as residential bridging mode
ICS Item Change Status
The ICS identifies the change status of an Alcatel unit or component.
IDEA International Data Encryption Algorithm
A symmetric-key encryption method that uses a 128-bit key and the block
cipher method, which breaks text into 64-bit blocks and then encrypts them.
IEEE Institute of Electrical and Electronics Engineers
The IEEE is a worldwide engineering publishing and standards-making
body. It is the organization responsible for defining many of the standards
used in the computer, electrical, and electronics industries.
Glossary
IETF Internet Engineering Task Force

The IETF is the organization that provides the coordination of standards and
specification development for TCP/IP networking.
IGFET Insulated Gate Field Effect Transistor
IGMP Internet Group Management Protocol
IGMP is a protocol used between hosts and multicast routers on a single
physical network to establish hosts membership in particular multicast
groups. Version 2 of IGMP is described in RFC 2236.
IGS IGMP System on the SHub
INP Impulse Noise Protection
The ability to protect equipment from excessive noise and vibrations, which
cause signal degradation over xDSL lines.
IP Internet Protocol
Connectionless packet-switching protocol that works together with TCP.
IP@ Internet Protocol Address
IPCP IP Control Protocol
A protocol that configures, enables, and disables the IP protocol modules on
both ends of a point-to-point link. IPCP is tied to PPP, and activated when
PPP reaches the network layer-to-protocol phase. If IPCP packets are
received prior to this phase, they are discarded.
IPoA Internet Protocol over ATM
IPoE Internet Protocol over Ethernet
IPTV IP Video/Television
The delivery of video services over an end-to-end IP infrastructure. IPTV
can include various classes of video services including video on demand,
broadcast TV, video conferencing, and mobile video.
ISAM Intelligent Services Access Manager
The Intelligent Services Access Manager is an xDSL access multiplexer that
operates in a packet aggregation network. The ISAM enables deployment of
triple-play services, such as video on demand, high-definition TV and
broadcast TV services for all subscribers simultaneously.
ISDN Integrated Services Digital Network
ISP Internet Service Provider
ITSC Integrated Test and Sealing Current
A feature that includes narrowband line testing functionality as well as
sealing current for subscriber lines connected to the ARAM-D shelf.
Glossary
ITU International Telecommunications Union

Standards organization that develops international telecommunications
recommendations.
IXL Index List
JFET Junction Field Effect Transistor
L2-based LIMs EALT-A, EBLT-A, and EBLT-J cards
L3-based LIMs EBLT-C, EBLT-D, EVLT-A, EVLT-C, EVLT-D, and EVLT-E cards
LACP Link Aggregation Control Protocol
An IEEE specification (802.3ad) that allows you to bundle several physical
ports together to form a single logical channel.
LAN Local Area Network
Type of network that sends and receives communications over a small area,
such as within an office or group of buildings.
LANX 7330 ISAM FTTN Network Termination card Ethernet switch (also known
as SHub)
LCP Link Control Protocol
A protocol that LCP establishes, configures, and tests data-link connections
for use by PPP.
LED Light Emitting Diode
A semiconductor diode that emits light when a current is passed through it.
LIM Line Interface Module
LMI Line Management Interface
LOS Loss of Signal
A condition at the receiver or a maintenance signal transmitted in the
physical overhead, indicating that the receiving equipment has lost the
received signal.
LP slot A slot in the 7330 ISAM FTTN shelf where an applique is installed.
LPF Low-pass Filter
LPF is a single transmission band extending from zero frequency up to a
specified cutoff frequency, not infinite.
LSA Link State Advertisement
Message of the OSPF routing protocol that informs about network topology
changes.
Glossary
LSDB Link State Database

A link state database is used to compute network routes after each change of
topology that has been reported by the routing protocol.
LSM Line Server Module
A generic term including xDSL line interface modules and any other server
application-specific module.
LT Line Termination
MAC Media Access Control
The IEEE sublayer in a LAN that controls access to the shared medium by
LAN attached devices.
MAIP Maintenance Access Interface Port
or
Multipurpose Alarm Interface Panel
A panel, located in the electronics compartment of a 52-type cabinet that
provides fused dc power to the 7330 ISAM FTTN shelf and cabinet fans, as
well as cabinet and power alarm outputs.
MDF Main Distribution Frame
MDI Medium-Dependent Interface
MDI is a type of Ethernet port for use with twisted-pair wiring.
MDIX Medium-Dependent Interface Crossover
The MDIX version of MDI enables the connection of like devices using
straight-through twisted-pair for MDI port-to-MDIX port connections and
crossover twisted-pair for MDI-to-MDI or MDIX-to-MDIX connections.
MIB Management Information Base
MMF Multimode Fiber
An optical fiber with a core diameter of 50 to 100 m. Most commonly used
in short distance LANs. The larger core diameter allows broader light
sources such as LEDs. Modal dispersion is a problem over longer distances.
MOS Metal Oxide Semiconductor
MTA Metallic Test Access
MTAU Metallic Test Access Unit
MTBF Mean Time Between Failures
Multi-ADSL Multi-Asymmetric Digital Subscriber Line
A general term that refers to more than one type of ADSL (for example,
ADSL, ADSL2, and READSL).
Glossary
NAT Network Address Translation

NE Network Element
NFS Network File System
A distributed file system protocol suite developed by Sun Microsystems that
allows remote file access across a network. NFS is one protocol in the suite.
The protocol suite includes NFS, RPC, and XDR. These protocols are part
of a larger architecture that Sun refers to as ONC.
NSA Non-Service Affecting
NSP Network Service Provider
NT Network Termination
A plug-in unit that provides a link to a broadband network, such as ATM or
IP. The 7330 ISAM FTTN uses the ECNT-A or ECNT-C card for network
termination.
NTA slot Network Termination slot A
The slot on the 7330 ISAM FTTN shelf for an NT unit. There are two slots
for NT units, marked as A and B.
NTB slot Network Termination slot B
The slot on the 7330 ISAM FTTN shelf for an NT unit. There are two slots
for NT units, marked as A and B.
NTP Non-Trouble Procedure
OAM Operation, Administration, and Maintenance
Broad categories of functions found in a communications network and/or the
business processes found in network service provider companies.
OBC On-Board Controller
OOS Out-of-service
The status of a primary rate link when it is out of service.
OS Operations System
Standalone software system that supports network-related operations
functions.
OSP Outside Plant
OSPF Open Shortest Path First
Dynamic routing protocol that responds quickly to network topology
changes. As a successor to RIP, it uses an algorithm that builds and
calculates the shortest path to all known destinations.
OSS Operations Support System
Glossary
OSWP Overall Software Package

PADI PPPoE Active Discovery Initiation
PDF Power Distribution Frame
POLT-B POTS-only Line Termination
The POLT-B card is a plug-in unit that works with an NT unit and the
PTPC-A applique to support integrated VoIP-SIP so that the
7330 ISAM FTTN can support transmission of VoIP Ethernet packets over
the IP network in place of POTS signals over the PSTN.
POTS Plain Old Telephone Service
Term used to describe narrowband, voice-only telephone service.
PPP Point-to-Point Protocol
A protocol that allows a computer to use TCP/IP with a standard telephone
line and a high-speed modem to establish a link between two terminal
installations.
PPPoA Point-to-Point Protocol over ATM
PPPoE Point-to-Point Protocol over Ethernet
PPPoE is a specification for connecting multiple computer users on an
Ethernet LAN to a remote site through common CPE. PPPoE allows users
to share a common xDSL, cable modem, or wireless connection to the
Internet. PPPoE combines the PPP protocol, commonly used in dial-up
connections, with the Ethernet protocol, which supports multiple users in a
LAN. The PPP protocol information is encapsulated within an Ethernet
frame.
PSD Power Spectral Density
PSTN Public Switched Telephone Network
Telephone network based on normal telephone signaling and ordinary
switched long distance telephone circuits.
PTC Positive Temperature Coefficient
PTPC-A POTS splitter applique
The PTPC-A applique provides connectivity for subscribers that use
integrated VoIP-SIP through a POLT-B card in the 7330 ISAM FTTN.
Support for integrated VoIP-SIP lets the 7330 ISAM FTTN support
transmission of VoIP Ethernet packets over the IP network in place of POTS
signals over the PSTN.
PVC Permanent Virtual Connection
PVIC Port VLAN Identifier
Glossary
PWIO-B Power I/O card

A general facilities card that provides power to the other units in the
ARAM-D shelf, including the fan unit. Two variants of the card are
available: one provides connectivity for six user-definable external alarm
inputs and the other provides connectivity for three user-definable external
alarm inputs and critical, major, and minor alarm outputs. Both variants
provide an ac failure input, MTA connectivity, and a connection for a craft
terminal.
QoS Quality of Service
Measure of the quality of a data communications link provided to a
subscriber.
RADIUS Remote Authentication Dial-in User Service
RADIUS is a standardized method of information exchange between a
device that provides network access to users (RADIUS client) and a device
that contains authentication and profile information for the users (RADIUS
server).
RAM Remote Access Multiplexer
RARP Reverse Address Resolution Protocol
RB VLAN Residential Bridging VLAN
RDI Remote Defect Indication
READSL2 Reach Extended ADSL2
RED Random Early Detection
REN Ringer Equivalence Number
RFC Request for Comments
RFC is the name of the result and the process for creating a standard on the
Internet. New standards are proposed and published online, as a Request For
Comments. The IETF is the consensus-building body that facilitates
discussion, and eventually a new standard is established.
RFC is the prefix for all published IETF documents for Internet environment
standards; for example, the official standard for e-mail is RFC 822. RFC
documents typically define IP, TCP, and related application layer protocols.
RIP Routing Information Protocol
An interior gateway protocol defined by the IETF (RIPv1 - RFC 1058 and
RIPv2 - RFC 2453) that specifies how routers exchange routing table
information. RIP is a routing protocol based on the distance vector
algorithm. With RIP, routers periodically exchange entire tables.
RJ-45 The RJ-45 is a single-line jack for digital transmission over ordinary phone
wire, either untwisted or twisted. It is the interface for Ethernet standards
10Base-T and 100Base-T.
Glossary
RMI Remote Management Interface

RNM Residential Network Manager
RSTP Rapid Spanning Tree Protocol
RSTP is specified in IEEE 802.1w. It replaces the spanning tree protocol
specified by IEEE 802.1d. RSTP is targeted at switched networks with
point-to-point interconnections, and allows for much quicker
reconfiguration time (approximately 1 s) by allowing a rapid change in port
roles.
RTL Routine Task List
RTP Real-time Transport Protocol
RTU Remote Test Unit
RU Rack Unit
A rack unit is a unit of vertical space in a standard 19-inch or 23-inch
equipment rack. One RU is 1.75 inch (4.45 cm).
Rx receive
To receive or carry signals or data to a device; any part of the equipment that
converts or decodes signals or data entering the equipment into the desired
form for use by the equipment.
SA Service Affecting
or
Source Address
SAP Service Access Point
SATU-A Expansion Shelf Alarm and Test Unit
A metallic test access and alarm unit installed in the 7330 ISAM FTTN ES
that collects expansion shelf alarm information, as well as controls the
MTAU function on the expansion shelf.
SDU Service Data Unit
Unit of information from an upper-layer protocol that defines a service
request to a lower-layer protocol.
SELT Single-Ended Line Testing
SEM Sealed Expansion Module
A remote expansion unit for the 7330 ISAM FTTN. The SEM is a single LT
unit in a flood resistant, environmentally hardened enclosure designed for
remote outside deployment in hard-to-reach or low-density locations.
See also ASEM-B and VSEM-A.
Glossary
SFP Small Form-factor Pluggable

SFP is a specification for a new generation of optical modular transceivers.
The devices are designed for use with small form-factor connectors, and
offer high speed and physical compactness. They are hot-swappable.
SFTP Secured File Transfer Protocol
SHub 7330 ISAM FTTN and 7302 ISAM Network Termination card Ethernet
switch (also known as LANX).
SI Systme international dunits
SIP Session Initiation Protocol
SLIC Subscriber Line Interface
SMF Single Mode Fiber
Optical fiber with a core diameter of less than 10 microns that is used for
high-bandwidth transmission over long distances.
SNMP Simple Network Management Protocol
Protocol used by network management to retrieve information about
connection status, configuration, and performance.
SNTP Simple Network Time Protocol
A method of synchronizing network nodes. An SNTP server can be used by
multiple nodes to synchronize themselves.
SONET Synchronous Optical Network
Transmission network that uses high-speed optical carriers.
SSCS service-specific convergence sublayer
SSH Secure Shell
STP Spanning Tree Protocol
A technique based on an IEEE 802.1d standard that detects and eliminates
forwarding loops in a bridged network. When multiple paths exist, STP
selects the most efficient path for the bridge to use. If that path fails, STP
automatically reconfigures the network to activate another path. This
protocol is used mostly by local bridges.
S-VLAN Stacked VLAN
SWDB SoftWare DataBase
SWP SoftWare Package
TAC Test Access Control
Glossary
TAP Test Access Port

or
Trouble Analysis Procedure
TCA Threshold Crossing Alarm
TCP Transmission Control Protocol
Protocol for establishing a duplex connection between end systems for the
reliable delivery of data.
TCP/IP Transmission Control Protocol/Internet Protocol
TCP/IP is a networking protocol that provides communication across
interconnected networks, and between computers with different hardware
architectures and various operating software.
TFTP Trivial File Transfer Protocol
TIA Telecommunications Industries Association
The group responsible for setting telecommunications standards in the
United States.
TL1 Transaction Language 1
Human-machine language standard for controlling network elements.
TNG Training Document
TOP Task-Oriented Practice
The TOP method is a documentation system that supports the installation,
operation, and maintenance of telecommunications equipment and software
through different layers of documentation.
Tx transmit
To send or carry signals or data from a device; any part of the equipment that
converts or encodes signals or data exiting from the equipment into the
desired form for transmission to other equipment.
UA User Agent
UDP/IP User Datagram Protocol/Internet Protocol
A transport layer, connectionless mode protocol, providing a datagram mode
of communication for delivery to a remote or local user. UDP is part of the
TCP/IP suite.
UDS Unit Data Sheet
UPS Uninterruptible Power Supply
VBAS Virtual Broadcast Access Server
Glossary
VC Virtual Channel
Single communications connection identified by an office equipment
number, VPI, and VCI.
VCC Virtual Channel Connection
VCI Virtual Channel Identifier
Identifier in an ATM cell that distinguishes the data of one VC from the data
of another VC.
VCL Virtual Channel Link
VC/VP/VR Virtual Channel/Virtual Path/Virtual Router
VDSL Very High Bit Rate Digital Subscriber Line
Technology that enables very high-speed asymmetric data transmission
rates over a single twisted-pair copper telephone wire, but at shorter ranges
than other xDSL types. There is more than one type of VDSL.
VLAN Virtual LAN
A VLAN divides a physical LAN into multiple virtual LANs whose
members are not necessarily based on location. VLAN specifications are
contained in IEEE 802.1q.
VoD Voice on Demand
VoIP Voice over IP
VP Virtual Path
Single communications connection identified by an office equipment
number and a VPI.
VPI Virtual Path Identifier
Identifier in ATM cell that distinguishes data of one VP from data of
another.
VPSC-D xDSL POTS Splitter Card
An applique that provides connectivity between POTS CO lines,
high-bandwidth IP services (through an LT unit), and 24 ADSL, VDSL, or
VDSL2 subscriber drop lines.
VP/VC Virtual Path/Virtual Channel
VRF Virtual Routing Forwarder
A logical or virtual routing function with associated routing table that can be
instantiated in a router capable of supporting IP VPN services.
VSEM-A A 24-port VDSL and POTS splitter remote expansion unit for the
7330 ISAM FTTN. It features a flood resistant, environmentally hardened
enclosure that is compliant with GR-950-CORE.
Glossary
WAN Wide Area Network

WFQ Weighted Fair Queue
WRED Weighted Random Early Detection
xDSL x Digital Subscriber Line
A general term that is used to refer to more than one type of unspecified DSL (for
example, ADSL, ADSL2, READSL, SHDSL, VDSL, VDSL2).
XoA A general term used to refer to an unspecified type of encapsulation over ATM.
encapsulation
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 -21
Glossary
-22 June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Index
Numbers B
7330 ISAM FTTN basic data traffic
configuration for subtending, TNG 112-1 configuration example, TNG 110-5
ES configuration, TNG 111-1 cross-connect VLAN configuration
expansion unit management, TNG 106-4 example, TNG 110-13
maintaining, NTP 124-1 iBridge VLAN configuration example,
802.1x TNG 110-11
configure authentication, NTP 108-2 basic management connectivity
configuring, DLP 145-1 configuration example, TNG 110-2
disabling, DLP 145-1 bridge
802.1x parameters configure
configuring, DLP 145-1 general parameters, DLP 195-1
configure IP-aware bridge, NTP 106-2
A
C
ADSL profile
configuration example, TNG 110-3 C-VLAN
alarms create, DLP 117-1
creating snapshots, DLP 154-2 CC-VLAN, NTP 104-2, TNG 100-2
fault isolation, TAP 104-1 configure QoS-aware VLAN, DLP 135-2
managing, DLP 110-2 create C-VLAN, DLP 117-1
monitoring, NTP 115-1, DLP 155-1 create S-VLAN, DLP 118-1
troubleshooting, TAP 104-1 create SC-VLAN, DLP 119-2
viewing alarm logs, DLP 110-2 CLI session
viewing current alarms, DLP 110-2 setting up, DLP 100-1
viewing snapshots, DLP 154-2 cluster management, NTP 122-2
ARP configure, DLP 169-2
configure table entry, DLP 150-1
Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4 June 2007 IN-1
Index
configuration IGMP
configuration equipment planning

7330 ISAM FTTN ES, TNG 111-1 configuration example, TNG 110-2
7330 ISAM FTTN subtending, TNG 112-1 ES
backing up, RTP 100-3 CLI commands, TNG 106-1
CPE management, NTP 121-2 configuration, TNG 111-1
configure, DLP 166-1 expansion link connections, TNG 106-4
cross-connect VLAN identifying, TNG 106-1
configuration example, TNG 110-13 MAC address, TNG 106-1, TNG 106-4
events
D fault isolation, TAP 104-1
troubleshooting, TAP 104-1
database expansion links
restore, RTP 101-1 EDSE-A, TNG 106-4
DHCP Option 82, TNG 104-2 GENC-E, TNG 106-4
DHCP relay
configure, NTP 108-2 F
DHCP relay agent
conditions, TNG 104-3 F5 loopback test, TAP 101-1
configuring fault isolation
forwarder mode, DLP 141-1 alarms, TAP 104-1
iBridge mode, DLP 139-2 events, TAP 104-1
MAC concentration, DLP 186-2 forwarding modes
router mode, DLP 140-2 CC-VLAN, TNG 100-2
general description, TNG 104-1 iBridge VLAN, TNG 100-2
parameters, TNG 104-2 layer 2 termination, TNG 100-2
restrictions, TNG 104-3
viewing, TNG 104-3 G
DSL profile
configuration example, TNG 110-3 GENC-E
expansion links, TNG 106-4
E
I
EDSE-A
expansion links, TNG 106-4 iBridge
EMS add user, NTP 110-1
management, DLP 171-1 iBridge VLAN, TNG 100-2
equipment configuration example, TNG 110-11
configuring, DLP 113-1 creating, DLP 120-1
configuring and modifying, NTP 103-2 IGMP
planning, DLP 111-2 configure, NTP 108-2
repairing, NTP 114-1, TAP 102-1 configuring IGMP proxy, DLP 137-1
replanning, DLP 111-2 parameters, TNG 102-2
restarting, DLP 153-1 system parameters
shutting down, DLP 153-1 configuring, DLP 137-1
unplanning, DLP 111-2 viewing configuration, TNG 102-5
IN-2 June 2007 Alcatel-Lucent 7302 ISAM R3.3.x FGN3.4 | 7330 ISAM FTTN R3.3.x FGN3.4
Index
IMA PPPoE
IMA multicast
configure, DLP 183-1 configure, NTP 108-2
IP address configure on LT, DLP 136-1
convert to dual IP address, DLP 184-1 configure on the SHub, DLP 198-1
convert to single IP address, DLP 184-1 configuring, DLP 137-1
IP address allocation, TNG 104-2
IP multicast N
configuration guidelines, TNG 102-5
IP router NT redundancy
configure, NTP 107-2 configuring, DLP 114-2
IP-aware bridge
O
configure, NTP 106-2
IPoA operator
add cross-connect user, NTP 125-1 create default profile, DLP 172-1
add user, NTP 111-1 OSFP
create cross-connect user, DLP 174-1 configuring, DLP 107-2
create user, DLP 125-1
IPoE P
add user, NTP 112-1
create user, DLP 126-1 password
IPProxy CPE rules, DLP 101-1
configure management, DLP 192-1 performance monitoring, NTP 118-1
configure session, DLP 194-1 commands, DLP 176-1
enable management, DLP 193-1 ping, DLP 164-1, DLP 182-1
IPProxy CPE management, NTP 128-2 planning equipment
configuration example, TNG 110-2
L plug-in unit
locking, DLP 112-1
L2CP unlocking, DLP 112-1
configure session, DLP 185-2 plug-in units
layer 2 termination, TNG 100-2 configuring, NTP 103-1
link aggregation port
configuring, DLP 105-2 view configuration, DLP 197-1
local authentication view operational data, DLP 197-1
configure, NTP 108-2 PPPoA-PPPoE relay
configuring, DLP 143-1 configure, NTP 108-2
loopback interface on SHub, NTP 129-1 disabling, DLP 147-1
enabling, DLP 147-1
M PPPoE
MAC address, TNG 106-4 add user, NTP 113-1
MAC concentration create user, DLP 127-1
configuration, DLP 186-2 enable PPPoE server, DLP 148-1
MAC learning, TNG 100-5 profiles
MSTP configure, DLP 149-1
configuring, DLP 200-2
Index
PPPoE profile subtending
PPPoE profile security domain

configure, DLP 149-1 configure, NTP 108-2
PPPoE relay, NTP 108-2 creating, DLP 142-1
disabling, DLP 146-2 creating default domain, DLP 178-1
enabling, DLP 146-2 SELT, TAP 103-1
PPPoE termination SEM
configure, NTP 109-1 CLI commands, TNG 106-1
protocol tracing expansion link connections, TNG 106-4
configuration, DLP 201-1 identifying, TNG 106-1
MAC address, TNG 106-1
Q planning, TNG 106-4
services
QoS adaptation, NTP 119-1
configure, NTP 108-2 configuring, NTP 108-1
configuring SHDSL
L2, DLP 133-1 configuration parameters
L3, DLP 134-1 segment, TNG 108-16
QoS-aware VLAN, DLP 135-2 span, TNG 108-3
configuring on the SHub, DLP 199-1 unit, TNG 108-15
configuring TCA, DLP 202-1 configure links, DLP 182-1
operational parameters
R
segment, TNG 108-23
RADIUS span, TNG 108-17
configure, NTP 108-2 unit, TNG 108-22
configuring, DLP 144-1 SHub
operator authentication, DLP 181-1 configure filtering, DLP 132-2
remote expansion units, TNG 110-1 dual tagging
remote inventory enable, DLP 191-1
retrieving information, RTP 102-1 loopback interface, NTP 129-1
RIP managing the database, DLP 157-1
configuring, DLP 108-1 MSTP management, DLP 200-2
restarting, DLP 151-3
S shutting down, DLP 151-3
SHub MAC filters, TNG 100-6
S-VLAN software
create, DLP 118-1 management, NTP 116-1
SC-VLAN SSH, NTP 123-1
create, DLP 119-2 configure, DLP 170-2
script files, NTP 101-1 subtending
create, DLP 167-1 configuration for 7330 ISAM FTTN,
secure shell, NTP 123-1 TNG 112-1
security
configuring general settings, DLP 203-1
Index
system xDSL profile
system create xDSL user, DLP 124-1

configuring, NTP 102-2 creating and configuring, DLP 101-2
forwarding modes, TNG 100-2
IP address V
configure single IP address,
DLP 175-1 VDSL profile
maintaining, NTP 124-1 configuration example, TNG 110-3
modigy management IP parameters, VLAN
DLP 168-1 add an LT to a VLAN, DLP 128-1
reboot modes, DLP 152-1 add network interfaces, DLP 121-1
rebooting, DLP 152-1 configure iBridge VLAN, NTP 105-2,
system clock, DLP 103-3 NTP 127-1
system IP address configuring global parameters, DLP 187-1
configure dual IP address, DLP 102-1, creating, DLP 115-2, DLP 116-3
DLP 102-1 cross-connect VLAN configuration
system logging, NTP 126-2 example, TNG 110-13
configure, DLP 179-1 iBridge VLAN configuration example,
system parameter TNG 110-11
modification, NTP 117-1 modifying
system time, DLP 103-3 external management VLAN,
DLP 162-1
T subtending configuration for 7330 ISAM
FTTN, TNG 112-1
TCA Voice SIP
configure, DLP 190-2 configure, DLP 196-1
traceroute, DLP 165-1 VRF
traffic creating, DLP 121-1
configuration example, TNG 110-5 forwarding VRF, DLP 122-1
trap router VRF, DLP 123-1
configuring, DLP 109-2
reporting modes, DLP 109-1 X
troubleshooting
alarms, TAP 104-1 xDSL
events, TAP 104-1 create user, DLP 124-1
troubleshooting commands, NTP 120-1 xDSL bonding group
create, DLP 130-2
U create profile, DLP 130-2
xDSL profile
unicast configuration, TNG 100-5 create, DLP 173-1
unnumbered IP interface custom PSD points
configure, DLP 204-1 ADSL2+, DLP 188-2
user VDSL, DLP 188-2
create IPoA user, DLP 125-1 VDSL2, DLP 188-2
create IPoE user, DLP 126-1 modify, DLP 163-1
create PPPoE user, DLP 127-1 types, DLP 129-1
VDSL2 virtual noise, DLP 189-2
Index
Customer documentation and product support
Customer documentation
https://www1.alcatel-lucent.com/profile/forms/login.jhtml
Product manuals and documentation updates are available through the Alcatel-Lucent Support
Documentation and Software Download service at alcatel-lucent.com. If you are a new user
and require access to this service, please contact your Alcatel-Lucent sales representative.
Technical support
http://www.alcatel-lucent.com/wps/portal/support
Customer documentation feedback

documentation.feedback@alcatel-lucent.com
2007 Alcatel-Lucent. All rights reserved.
3HH-04387-AAAA-TQZZA Edition 02 Released

7302 7330 OAM Using CLI

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

7302 7330 OAM Using CLI

Încărcat de

Drepturi de autor:

Formate disponibile

Alcatel-Lucent 7302

INTELLIGENT SERVICES ACCESS MANAGER | RELEASE 3.3.X |

OPERATIONS AND MAINTENANCE USING CLI

3HH-04387-AAAA-TQZZA Edition 02 Released

Copyright 2007 Alcatel-Lucent.

When printed by Alcatel-Lucent, this document is printed on recycled paper.

ETSI and ANSI release naming

Table 1 ETSI and ANSI release naming

Market Release name

ETSI Release 3.3

ANSI Feature Group 3.4

Table 2 7302 ISAM Release 3.3 documentation set

Title Description Part number

CLI and TL1 documentation

Title Description Part number

Table 3 7330 ISAM FTTN Feature Group 3.4 documentation set

Title Description Part number

Product Information Provides general system information, features and 3HH-04087-AAAA-TCZZA

Operations and Provides task-oriented procedures for operating and 3HH-04387-AAAA-TQZZA

CLI and TL1 documentation

Software documentation (1)

Danger Danger indicates that the described activity or situation

Warning Warning indicates that the described activity or situation

Caution Caution indicates that the described activity or situation

Note A note provides information that is, or may be, of special

Procedures with options or substeps

Procedure 1 Example of options in a procedure

a This is one option.

b This is another option.

2 You must perform this step.

Procedure 2 Example of required substeps in a procedure

i This is the first substep.

ii This is the second substep.

iii This is the third substep.

2 You must perform this step.

Index List (IXL)

IXL 100 Master Task Index List IXL 100-1

Non-Trouble Procedures (NTP)

NTP 101 Execute script files NTP 101-1

NTP 102 Configure the system NTP 102-1

NTP 103 Configure equipment NTP 103-1

NTP 104 Configure a cross-connect VLAN NTP 104-1

NTP 105 Configure an iBridge VLAN NTP 105-1

NTP 106 Configure an IP-aware bridge NTP 106-1

NTP 107 Configure an IP router NTP 107-1

NTP 108 Configure services NTP 108-1

NTP 109 Configure PPPoE termination NTP 109-1

NTP 110 Add an iBridge user NTP 110-1

NTP 111 Add an IPoA user NTP 111-1

NTP 112 Add an IPoE user NTP 112-1

NTP 113 Add a PPPoE user NTP 113-1

NTP 114 Perform equipment repairs NTP 114-1

NTP 115 Monitor alarms NTP 115-1

NTP 116 Perform software management NTP 116-1

NTP 117 Modify system parameters NTP 117-1

NTP 118 Monitor performance and view configuration

NTP 119 Modify configured services NTP 119-1

NTP 120 Troubleshooting NTP 120-1

NTP 121 Manage an SNMP proxy CPE NTP 121-1

NTP 122 Cluster management NTP 122-1

NTP 123 Secure shell NTP 123-1

NTP 124 Maintain the system NTP 124-1

NTP 125 Add an IPoA cross-connect user NTP 125-1