o P e R A T I o N S A N D M A I N T e N A N C e U S I N G C L I PDF

Alcatel 7302
INTELLIGENT SERVICES ACCESS MANAGER | RELEASE 3.2

OPERATIONS AND MAINTENANCE USING CLI
3HH-04065-AAAA-TQZZA Edition 02 Released

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

All rights reserved.
Disclaimers
Alcatel 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, licence or other distribution
of the products for any such application without the prior written consent of Alcatel, shall be at the
customer's sole risk. The customer hereby agrees to defend and hold Alcatel harmless from any claims
for loss, cost, damage, expense or liability that may arise out of or in connection with the use, sale,
licence or other distribution of the products in such applications.
This document may contain information regarding the use and installation of non-Alcatel products.
Please note that this information is provided as a courtesy to assist you. While Alcatel tries to ensure
that this information accurately reflects information provided by the supplier, please refer to the
materials provided with any non-Alcatel product and contact the supplier for confirmation. Alcatel
assumes no responsibility or liability for incorrect or incomplete information provided about
non-Alcatel products.
However, this does not constitute a representation or warranty. The warranties provided for Alcatel
products, if any, are set forth in contractual documentation entered into by Alcatel 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.
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 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 7302 ISAM R3.2 February 2007 iii

Operations and Maintenance Using CLI 3HH-04065-AAAA-TQZZA Edition 02 Released
Preface
Documents
Table 1 lists the documents that make up the 7302 ISAM Release 3.2 documentation
set.
Table 1 7302 ISAM documentation set
Title Description Part number
General documentation
Product Information Provides general system information for the 7302 ISAM 3HH-04069-AAAA-TCZZA
System Description Provides conceptual information for the 7302 ISAM and the 3HH-04064-AAAA-TQZZA
7330 ISAM FTTN
Safety Manual Provides general safety guidelines when handling, installing, 3HH-04071-AAAA-TCZZA
or operating the 7302 ISAM equipment
Operations and Maintenance Provides task-oriented procedures for operating and 3HH-04065-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 7302 ISAM 3HH-04072-AAAA-TQZZA
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-03591-AAAA-RJZZA
Guide equipment
HD/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-04067-AAAA-TCZZA
7330 ISAM FTTN
TL1 Commands and Describes the TL1 commands and messages for the 3HH-04068-AAAA-TCZZA
Messages 7302 ISAM and the 7330 ISAM FTTN
Software documentation
Software Management User Describes the software management of the 7302 ISAM 3HH-03390-AAAA-RJZZA
Guide equipment
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.
iv February 2007 Alcatel 7302 ISAM R3.2

Edition 02 Released 3HH-04065-AAAA-TQZZA Operations and Maintenance Using CLI
Preface
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.
Alcatel 7302 ISAM R3.2 February 2007 v

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 Système international d’unités
(SI) standard for abbreviation of metric units.
vi February 2007 Alcatel 7302 ISAM R3.2

Contents
Preface iii
Scope .............................................................................................................................. iii
Audience .............................................................................................................................. iii
Prerequisite knowledge ......................................................................................................... iii
Safety information.................................................................................................................. iii
Documents ............................................................................................................................ iv
Special information ................................................................................................................ iv
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
Alcatel 7302 ISAM R3.2 February 2007 vii

Contents
Non-Trouble Procedures (NTP)
NTP 100 —CLI session set-up and user configuration NTP 100-1
NTP 101 —Script files NTP 101-1
NTP 102 —System installation and configuration NTP 102-1
NTP 103 —Equipment configuration NTP 103-1
NTP 104 —Configuration of a cross-connect VLAN NTP 104-1
NTP 105 —Configuration of 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 —Service installation NTP 108-1
NTP 109 —Configuration of 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 —Equipment repair NTP 114-1
NTP 115 —Monitor alarms NTP 115-1
viii February 2007 Alcatel 7302 ISAM R3.2

Contents
NTP 116 —Software management NTP 116-1
NTP 117 —System parameter modification NTP 117-1
NTP 118 —Performance monitoring and configuration

viewing NTP 118-1
NTP 119 —Service adaptation NTP 119-1
NTP 120 —Troubleshooting commands NTP 120-1
NTP 121 —SNMP proxy CPE management 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 —System logging management NTP 126-1
NTP 127 —SHDSL configuration NTP 127-1
NTP 128 —IPProxy CPE management NTP 128-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
Alcatel 7302 ISAM R3.2 February 2007 ix

Contents
DLP 102 —Configure dual IP address DLP 102-1
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 —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
x February 2007 Alcatel 7302 ISAM R3.2

Contents
DLP 120 —Create an iBridge VLAN DLP 120-1
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
Alcatel 7302 ISAM R3.2 February 2007 xi

Contents
DLP 138 —Configure IGMP snooping DLP 138-1
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
xii February 2007 Alcatel 7302 ISAM R3.2

Contents
DLP 155 —Monitor alarms DLP 155-1
DLP 156 —Management of the SHub database DLP 156-1
DLP 157 —Manage the SHub database DLP 157-1
DLP 158 —Management of the system database DLP 158-1
DLP 159 —Management of OSWP DLP 159-1
DLP 160 —View version of the SHub software DLP 160-1
DLP 161 —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 command DLP 164-1
DLP 165 —Traceroute command 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 —EMS management DLP 171-1
Alcatel 7302 ISAM R3.2 February 2007 xiii

Contents
DLP 172 —Create a default operator profile DLP 172-1
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
xiv February 2007 Alcatel 7302 ISAM R3.2

Contents
DLP 189 —Configure VDSL2 virtual noise values DLP 189-1
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
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
Alcatel 7302 ISAM R3.2 February 2007 xv

Contents
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
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
xvi February 2007 Alcatel 7302 ISAM R3.2

Contents
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 subtendingTNG 112-1
TNG 113 —Multi-ADSL parameters TNG 113-1
TNG 114 —DLP configuration examples TNG 114-1
Glossary
Index
Alcatel 7302 ISAM R3.2 February 2007 xvii

Contents
xviii February 2007 Alcatel 7302 ISAM R3.2

1 — Introduction
1.1 Introduction 1-2
1.2 How to Use this Document 1-2
1.3 Configuration examples 1-5
Alcatel 7302 ISAM R3.2 February 2007 1-1

1 — Introduction
1.1 Introduction
This document provides instructions on CLI operation and maintenance tasks and
procedures for the Alcatel 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 February 2007 Alcatel 7302 ISAM R3.2

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 7302 ISAM R3.2 February 2007

February 2007 Alcatel 7302 ISAM R3.2
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

CLI session set-up and user configuration NTP 100
Cluster management NTP 122
Configuration of a cross-connect VLAN NTP 104

Configuration of an iBridge VLAN NTP 105
Configuration of PPPoE termination NTP 109
Configure an IP-aware bridge NTP 106
Configure an IP router NTP 107
SNMP proxy CPE management NTP 121
Equipment configuration NTP 103
Equipment repair NTP 114
IPProxy CPE management NTP 128
Maintain the system NTP 124
Monitor alarms NTP 115
Performance monitoring and configuration viewing NTP 118
Script files NTP 101
Secure shell NTP 123
(1 of 2)
Alcatel 7302 ISAM R3.2 February 2007 IXL 100-1

Title NTP number
Service adaptation NTP 119
Service installation NTP 108
SHDSL configuration NTP 127
Software management NTP 116
System installation and configuration NTP 102
System logging management NTP 126

System parameter modification NTP 117
Troubleshooting commands 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 ARP table entry DLP 150
Configure cluster management DLP 169

Configure SNMP proxy CPE management DLP 166
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 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
Configure local authentication DLP 143
Configure multicast on the LT DLP 136
(1 of 4)
IXL 100-2 February 2007 Alcatel 7302 ISAM R3.2

Title DLP number
Configure multicast on the SHub DLP 198
Configure NACP session DLP 185
Configure network interfaces DLP 104
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 QoS on layer 2 DLP 133

Configure QoS on layer 3 DLP 134
Configure QoS on the SHub DLP 199
Configure RADIUS DLP 144
Configure RIP DLP 108
Configure RSTP DLP 106
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 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
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
(2 of 4)

Title DLP number
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 bonding group DLP 131
Create an xDSL user DLP 124

Create operator profiles and instances DLP 101
Create xDSL profiles DLP 129
EMS management DLP 171
Enable dual tagging in the SHub DLP 191
Enable IPProxy CPE management DLP 193
Enable the PPPoE server DLP 148
Lock and unlock equipment DLP 112

Manage alarms DLP 110
Manage the SHub database DLP 157
Management of OSWP DLP 159
Management of the SHub database DLP 156
Management of the system database DLP 158
Modify the external management VLAN DLP 162

Modify the system management IP parameters DLP 168
Modifying xDSL profiles DLP 163
Monitor alarms DLP 155

NT redundancy DLP 114
Performance monitoring commands DLP 176
Ping command 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
Software licenses counters DLP 161
Switching a user from ADSL to VDSL DLP 173
Traceroute command DLP 165
(3 of 4)

Title DLP number
View port configuration and operational data DLP 197
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
Specifying 7330 ISAM FTTN remote expansion units using the CLI TNG 106
(1 of 2)

Title TNG number
VBAS TNG 103
VDSLx parameters TNG 107
(2 of 2)

NTP 100 — CLI session set-up and user configuration
NTP 101 — Script files
NTP 102 — System installation and configuration
NTP 103 — Equipment configuration
NTP 104 — Configuration of a cross-connect VLAN
NTP 105 — Configuration of an iBridge VLAN
NTP 106 — Configure an IP-aware bridge
NTP 107 — Configure an IP router
NTP 108 — Service installation
NTP 109 — Configuration of 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 — Equipment repair
NTP 115 — Monitor alarms

NTP 116 — Software management
NTP 117 — System parameter modification
NTP 118 — Performance monitoring and configuration viewing
NTP 119 — Service adaptation
NTP 120 — Troubleshooting commands
NTP 121 — SNMP proxy CPE management
NTP 122 — Cluster management
NTP 123 — Secure shell
NTP 124 — Maintain the system
NTP 125 — Add an IPoA cross-connect user
NTP 126 — System logging management
NTP 127 —SHDSL configuration

Alcatel 7302 ISAM R3.2 February 2007 -3

-4 February 2007 Alcatel 7302 ISAM R3.2

NTP 100 — CLI session set-up and
user configuration
Purpose
This procedure provides the steps to set up a CLI session with the NE and create a user
using the Alcatel-developed CLI.
General
Figure NTP 100-1 shows the management topology of the NE system.
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
Alcatel 7302 ISAM R3.2 February 2007 NTP 100-1

NTP 100 — CLI session set-up and user configuration
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.
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.
NTP 100-2 February 2007 Alcatel 7302 ISAM R3.2

Purpose
A script file is a file containing CLI commands, which can be used to restore a
configuration.
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.


NTP 102 — System installation and
configuration
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 AWS traffic to be routed
to the NT OBC.
• Encryption via keys must be promoted compared to passwords

NTP 102 — System installation and configuration
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 Configure the SHub database save location and the restore source file; 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
midfield.
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 — Configuration of 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
Two levels of VLAN tags are used, which allow support of hierarchical addressing:
• The customer VLAN: C-VLAN
• The service provider VLAN: S-VLAN
In this mode, 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.
• 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 — Configuration of 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.

NTP 105 — Configuration of an iBridge
VLAN
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

NTP 105 — Configuration of an iBridge VLAN
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 For each of the n Network Service Providers (NSP), create a L2 terminated

forwarder VLAN; 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).
This procedure provides the steps to configure an IP router on the NE.

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.

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.
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 Rapid Spanning Tree Protocol (RSTP). This is a protocol

that is running between switches/routers to avoid that there are loops in the network.
RSTP can be enabled/disabled on system level and on port level. By default, the
RSTP on system level is on and enabled on all network and subtending ports.
For the configuration of RSTP management; see DLP 106.
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.


NTP 109 — Configuration of PPPoE
termination
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.

NTP 109 — Configuration of PPPoE termination

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


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 117 — System parameter
modification
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 117 — System parameter modification

NTP 118 — Performance monitoring and
configuration viewing
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: see DLP 197

NTP 118 — Performance monitoring and configuration viewing

Purpose
This procedure provides the steps to adapt the following services on the NE:
• modifying existing xDSL profiles

• switching a nexisting user from ADSL to VDSL.
Procedure
To adapt a service, you can perform the following tasks:
1 Modify an xDSL profile; see DLP 163.
2 Switch 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.


NTP 121 — SNMP proxy CPE
management
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
carrier’s 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

NTP 121 — SNMP proxy CPE management
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 an IPoA cross- connect user; see DLP 174.
2 Create a C-VLAN or SC-VLAN; see DLP 117 or DLP 119.

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

NTP 127 — SHDSL configuration
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.

NTP 127 — SHDSL configuration

NTP 128 — IPProxy CPE management
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

NTP 128 — IPProxy CPE management
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.

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 — 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 139 — Configure DHCP relay agent in iBridge mode
DLP 140 — Configure DHCP relay agent in router mode
DLP 141 — Configure DHCP relay agent in forwarder 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 — Management of the system database
DLP 159 — Management of OSWP
DLP 160 — View version of the SHub software
DLP 161 — Software licenses counters
DLP 162 — Modify the external management VLAN
DLP 163 — Modifying xDSL profiles
DLP 164 — Ping command
DLP 165 — Traceroute command
DLP 166 — Configure SNMP proxy CPE management
DLP 167 — Script files
DLP 168 — Modify the system management IP parameters
DLP 169 — Configure cluster management

DLP 170 — Configure SSH
DLP 171 — 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 181 — Configure operator authentication via RADIUS
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 194 — Configure IPProxy CPE management session
DLP 195 — Configure general bridge parameters
DLP 196 — Configure Voice SIP

DLP 197 — View port configuration and operational data
DLP 198 — Configure multicast 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 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 7302 ISAM R3.2 February 2007 DLP 100-1

DLP 100-2 February 2007 Alcatel 7302 ISAM R3.2

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 user’s
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 8
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

iv 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
8 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)
9 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)
10 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 line ID format is configured with the parameter

port-num-inpro. The different values of this parameter are:
• log-slot-num: Logical slot ID (that is, the numbering method defined

for equipment identification in the MIB.)
• position-based: Position-based numbering (the numbers of the
boards are based on the position in the shelf and starting from
offset 1.)
• type-based: Type-based numbering (flat numbering per slot type from
left to right starting with 1, TL1 format.)
• legacy-num: This numbering is identical to position-based except for
some very specific configurations (for example, ARAM-B/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).
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]


Purpose
The NE can be configured with several network interfaces. They can be used to connect
the NE to multiple Ethernet switches.
The Rapid Spanning Tree Protocol (RSTP) is a link management protocol that provides
path redundancy while preventing undesirable loops in the network.
This procedure provides the steps to configure RSTP management on the NE.
Prerequisite
The following prerequisite must be fullfilled before RSTP can be configured:
The port-type of the network port must be different from unused.
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 RSTP management:
1 Specify RSTP settings applicable to the SHub with the following command:
configure rstp
(no) disable-rstp
(no) priority <Shub::RstpPriority>
(no) max-age <Shub::RstpMaxAge>
(no) hello-time <Shub::RstpHello>
(no) forward-delay <Shub::RstpFwdDelay>
(no) version <Shub::RstpVersion>
(no) tx-hold-count <Shub::RstpTxHold>
path-cost-type <Shub::RstpPathCost>
Note — Parameters in this command are settings that apply to the

bridge as a whole.
2 Specify RSTP settings applicable to a particular port of the SHub with the following
command:
configure rstp network-port (port)

(no) priority <Shub::RstpPortPriority>
(no) disable-stp
path-cost <Shub::PortPathCost>
(no) edge-port
(no) admin-p2p <Shub::AdminP2p>
Note — RSTP operates on a port rather than on a VLAN.
3 In addition to the previous configuration command, there is a need to trigger a

specific SHub Port to revert to RSTP protocol, versus stp-compatible protocol. Use
admin bridge rstp port (port)

(clear-det-proto)
Note — RSTP operates on a port rather than on a VLAN.
4 View the bridge RSTP operational information (port states, port roles, and so on)
with the following command:
show rstp port-info (port)

configure rstp max-age 2500 hello-time 200 forward-delay 2000

tx-hold-count 3
configure rstp network-port 7 priority 160 admin-p2p force-true
admin bridge rstp port 7
show rstp port-info 7


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 vlan shub id 80 mode layer2-term-nwport
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

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 hthe 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
must be implemented.

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 50
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 ospf redistribution rip
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
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 Tune the alarm reporting for individual ports (for example, xDSL lines) with the
following command:
configure interface port (port)

(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 — Refer to TNG 106 for more information on the planning of

remote expansion units.

Procedure
Proceed as follows to plan, replan, and unplan equipment:
1 Plan a shelf 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 New

Equipment Practice (NEP) subracks. For more information on NEP
subracks, see the Product Information.
2 Unplan a shelf with the following command:

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

description can be changed.
3 Plan a plug-in unit other than an applique 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.

4 Unplan a plug-in unit other than an applique in any given slot position with the
following command:

no planned-type
5 If necessary, plan an applique with the following command:
configure equipment applique (index)

planned-type <Equipm::AppliqueType>

6 If necessary, unplan an applique with the following command:
configure equipment applique (index)

no planned-type
7 View the slot status with the following command:
show equipment slot
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


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
sleep 60
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 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
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)
i 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.
ii 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)
iii 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>
iv 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::Rack>/<Eqpt::Shelf>/
<Eqpt::LtSlot>/<Eqpt::Port>:<Atm::DefaultVpi>:
<Atm::DefaultVci>
| <Ip::V4Address>:network:vlan:stacked:
<Vlan::SVlanIndex>:<Vlan::CVlanIndex>
| <Ip::V4Address>:network:vlan:<Vlan::UVlanIndex>
| <Ip::V4Address>:network:any
| network:stacked:<Vlan::SVlanIndex>:<Vlan::CVlanIndex>
| direct: network:<Vlan::UVlanIndex>
| direct:user-bridgeport:<Eqpt::Rack>/<Eqpt::Shelf>/
<Eqpt::LtSlot>/<Eqpt::Port>:<Atm::DefaultVpi>:
<Atm::DefaultVci>

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 DHCP relay agent per VRF (for handling broadcast frames) 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) mac-concent <Dhcp::MacConcentration>
(no) dhcp-linerate <Dhcp::Dhcp-linerate>
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>

21 Configure the DHCP relay agent per VRF (for handling broadcast frames) with the
following command:

(no) option-82
(no) mac-concent <Dhcp::MacConcentration>
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 interface’s
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 interface‘s preconfigured S-VLAN will
be assigned. In case of untagged/priority tagged frames, the subscriber interface’s
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) 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
(no) link-updown-trap
(no) user <Itf::asamIfExtCustomerId>
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) pvid <Vlan::StackedVlan>
(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 set the priorities
applicable for that port with the following command:
configure bridge port (port) vlan-id (index)

(no) (tag)
(no) qos-profile none | name:<Vlan::IgnoredQosProfileName>
(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-ctr
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)

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)

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-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 the CLI Commands and Messages document and TNG 107 for a full description of
all 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 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>
5 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>
6 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

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

9 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>
10 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-index)

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.
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
2 Configure the SHub MAC filter to a port with the following command:
configure transport shub mac-filter (index-num)

(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
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
DSL port with the following command:
configure qos dsl-port (index)

scheduler-profile <Qos::ProfileName>
cac-profile <Qos::ProfileName>
13 Attach the created queue profile (see step 6) to a DSL port with the following
command:
configure qos dsl-port (index) queue (queue)

queue-profile <Qos::QosProfileName>

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
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 a
DSL port with the following command:
configure qos dsl-port (index)

scheduler-profile <Qos::ProfileName>
cac-profile <Qos::ProfileName>
13 Attach the created queue profile (see step 6) to a DSL port with the following
command:
configure qos dsl-port (index) queue (queue)

queue-profile <Qos::QosProfileName>
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 etm-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 50000 mean-bit-rate 10000
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>
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 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::MembQueryIntv>
(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 <Igmp::igmpSystemCdrAdmin>
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 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) report-fwd-intv <Igmp::ForwardInterval>
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>
query-timer <Igmp::VlanRouterQueryTimer>
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
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

query-timer 120
show igmp shub vlan-router-port 500 network-port 3
configure igmp shub vlan-filter 4090 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 DHCPRel10
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:

(no) option-82
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) 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:
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 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)

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 restart the NT.
Procedure
Proceed as follows to restart the SHub:
1 Prepare the system for shutdown with the following command:
admin equipment prepare-sys-shutdown
2 Pull out the NT.
3 Make the necessary changes to the NT.
4 Insert the NT.
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.
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
sleep 60
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)
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 | tca-xdsl |
eo-conversion | authentication | bonding-group | ipox | redundancy
| custom | sfp | llu-relay | custom-ext-alarm | plug-in-unit-ext
(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)
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-app-server
| sip-user-agent | sip-plugin-unit | sip-termination
| shdsl | shdsl-isam | ima-group | ima-link (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 command to view the current alarms:
show alarm current table | 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-app-server
| sip-user-agent | sip-plugin-unit | sip-termination
| shdsl | shdsl-isam | ima-group | ima-link (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
The SHub database can be saved manually with the following command:
admin software-mngt shub database save
Procedure
Proceed as follows to manage the SHub database:
1 Save the SHub database with the following command:
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

DLP 158 — Management of the system
database
Note
The correct procedure is described in RTP 100.

DLP 158 — Management of the system database

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>
Note — The parameters “download-set” and “autofetch” are obsolete

parameters whose settings will be ignored by the system.
2 Start the actual OSWP download with the following command:
admin software-mngt oswp (index) download <SwMngt::oswpName>
3 Abort an OSWP download with the following command:
admin software-mngt oswp (index) abort-download

4 Activate an OSWP with the following command:
admin software-mngt oswp (index) activate

<SwMngt::activationType>
5 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
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

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

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>
ping 10.176.5.5 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 Initiate a 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>
2 Terminate a traceroute action with the following command:
traceroute (ip-addr) no first-hop

traceroute 10.176.5.5 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 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, which can be used to restore a
configuration.
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 and restoring 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:

ip-addr <Ip::V4Address>/<Ip::PrefixLengthHost>
9 Change the administrative status of the management vlan on the SHub to “up” with

admin-status up
10 Configure the default route in the SHub with the following command:

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 node’s 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 server’s 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) cli <SSH::ChannelCLISSH>
(no) tl1 <SSH::ChannelTL1SSH>

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>
(no) security <Sec::Security>

DLP 172 — Create a default operator profile
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.

DLP 173 — Switching a user from ADSL to VDSL
3 Create the new forwarding model. Refer to DLP 115 to DLP 127 for the correct
procedure for the different modes.

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 user’s
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

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 — For more information on the command syntax and the

command parameters, refer to the CLI Commands and Messages.
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 RSTP counters:
show rstp port-info (port)
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 total
9 Use the following command to show the IGMP statistics:
show igmp channel counter (port)
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)
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


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:
• if you connect a SEM directly to downlink ports 8, 9, or 10, the SEM is automatically
assigned rack 3, shelf 1, 2, or 3 respectively without requiring configuration; however,
you are still required to configure the slot number for the SFP port
• to use any downlink port other than ports 8, 9, and 10, you must configure a rack,
shelf, and slot ID for those downlink ports
• use only rack 3
• the slot number is always slot 4
• up to three shelves are supported in a rack
The following conditions apply specifically to the ES:
• shelf jumper settings override the default rack and shelf assignments of downlink
ports 8, 9, and 10.
• 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
• use only racks 1 and 2
• the slot number is the LT slot on the ES that contains the remote LT unit connected
to the downlink port
• up to three 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 downlink ports 8, 9, or 10 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 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.
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 View direction of the configurable ports:
info configure equipment external-link-host (SFP index 6 or 7)
3 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 AUTH

CLI configuration changes CLI_CONFIG
TL1 configuration changes TL1_CONFIG
CLI messages CLI_MSG
TL1 messages TL1_MSG
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.

DLP 181 — Configure operator authentication via RADIUS
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 12.
5 Remove the single IP address mode configuration with the following command:
configure system no single-public-ip
6 Change the administrative status of the management vlan on the SHub to “down”

admin-status down
7 Configure the new IP address to the management vlan on the SHub via the following
command:

ip-addr <Ip::V4Address>/<Ip::PrefixLengthHost>
8 Change the administrative status of the management vlan on the SHub to “up” with

admin-status up
9 Configure the default route in the SHub with the following command:

vlan-id 4093
10 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

11 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::PriorityMap>
(no) pvid-usage <Vlan::PvidUsage>
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
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).
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:
• 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 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>
configure xdsl line 1/1/5/6 tca-line-threshold enable

ses-day-nearend 30

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>
(no) link-updown-trap
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) must be planned; see DLP 111.
Procedure
Proceed as follows to configure Voice SIP:
1 Manage the Voice SIP server profile with the following command:
configure voice sip server (name)

admin-status up
domain <Sip::ApplicationServerDomain>
primary-ip-addr <Sip::ApplicationServerIpAddr>
(no) primary-udpport <Sip::ApplicationServerUdpPort>
secondary-ip-addr <Sip::ApplicationServerIpAddr>
(no) secondary-udpport <Sip::ApplicationServerUdpPort>
(no) server_type <Sip::ApplicationServerType>
Note — The parameter server_type is not visible when a new Voice SIP
server profile is created, but only when an existing profile is modified.

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 To configure the Voice SIP user agent profile:
a by DHCP: go to step 4
b manually: go to step 6
4 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-server <Sip::ApplicationServerName>
associated-dialplan <Sip::DialPlanName>
(no) user-agent-domain <Sip::UserAgentUaDomain>
admin-status <Sip::UserAgentAdminStatus>
(no) udp-port <Sip::UserAgentUdpPort>
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 Go to step 7.
6 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-server <Sip::ApplicationServerName>
associated-dialplan <Sip::DialPlanName>
(no) user-agent-domain <Sip::UserAgentUaDomain>
admin-status <Sip::UserAgentAdminStatus>
ip-address <Sip::UserAgentIpAddr>
prefix-length <Sip::PrefixLength>
gateway-ip <Sip::UserAgentIpAddr>
domain-server <Sip::UserAgentIpAddr>
(no) udp-port <Sip::UserAgentUdpPort>
vlan-id <Sip::UserAgentVlanId>
(no) signal-dscp <Sip::UserAgentSignalDscp>
(no) signal-pbits <Sip::UserAgentSignalPbits>
(no) rtp-dscp <Sip::UserAgentRtpDscp>
(no) rtp-pbits <Sip::UserAgentRtpPbits>
7 Manage the Voice SIP dial plan digitmap with the following command:
configure voice sip digitmap (name)

type <Sip::DialPlanDigitmapType>
rule <Sip::DialPlanDigitmapValue>
(no) access-type <Sip::DialPlanDigitmapAccessType>

Note — 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.
8 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>
9 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 domain SIPDomain

primary-ip-addr 200.200.1.1
configure voice sip server SIPServer1 server_type alcatel
configure voice sip server SIPServer1 admin-status up
configure voice sip dialplan SIPDialplan1
configure voice sip user-agent-dhcp SIPAgent1

associated-slot 1/1/6 associated-server SIPServer1
associated-dialplan SIPDialplan1 admin-status up vlan-id 650
configure voice sip digitmap Digitmap1 type regular rule 120
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 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 a 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 a 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

DLP 197 — View port configuration and operational data
show xdsl config-data-port 1/1/5/12
show xdsl oper-data-port 1/1/5/12

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

DLP 199 — Configure QoS on the SHub
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>

DLP 199 — Configure QoS on the SHub
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

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 7302 ISAM R3.2 February 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 February 2007 Alcatel 7302 ISAM R3.2

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
sleep 100

actual-active:10.176.5.5:dm_complete.tar
sleep 100


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
sleep 60
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 Printed Board Assembly code of the code
inventory-fpba The Alcatel 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 7302 ISAM R3.2 February 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 February 2007 Alcatel 7302 ISAM R3.2

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.
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 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 CLI Commands document for information on CLI syntax. See the TL1
Commands and Messages document for information on 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. If this is the case, Alcatel recommends that a
UNIX system administrator perform the troubleshooting.

Alarms are grouped by alarm type in Table TAP 104-1 and 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 (CLI alarm name in parenthesis)
• Class:
• communication (Com)
• processing errors (Proc)
• quality of service (QoS)
• environmental (Envir)
• equipment (Equip)
• Severity level assigned to the alarm:
• indeterminate
• warning
• minor
• major
• critical
• Service affecting (✓): a check mark indicates that the alarm is service-affecting
• Description of the alarm
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 the 5526 AMS, see NTP 111 — Manage 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 Chapter 3 — AWS Admin
overview in the 5523 AWS ADMIN User Guide.
c To access the alarms using CLI, see NTP 115 — Monitor 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 order listed
below:
• Critical (red)
• Major (orange)
• Minor (yellow)

3 Use Tables TAP 104-1 and 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.
Note — Tables TAP 104-1 and TAP 104-2 list in parentheses the alarm
names as they appear for the CLI configure command. Alarm names as
they appear in the CLI show alarm commands are slightly different.
Table TAP 104-1: Alarm definitions for the 7302 ISAM and the 7330 ISAM FTTN
Alarm (grouped by alarm type) Description Applies to
No. Name (CLI) (1) Class Severity SA 7302 7330
Alarm type = Equip (1); Index1 = eqptHolderld (index in equipment holder Table), Index22 = not used
0 — — — — No defects ✓ ✓
1 Persistent data loss Equip Critical ✓ System has lost all persistent data after ✓ ✓
(persist-data-loss) RESTART. System is not configured.
2 SNTP server not Equip Major — The SNTP server does not respond to ✓ ✓
responding the requested messages.
(sntp-comm-lost)
4 NT disk 90% full Equip Major — The NT disk has reached a 90% full ✓ ✓
(nt-disk-90%full) level.
5 System clock not using Com Major ✓ The system is configured to work in ✓ ✓
preferred timing mode autonomous mode with both timing
(preferred-mode) modes allowed and is not using the
preferred timing mode because all timing
references corresponding to the
preferred timing mode are in failure.
6 System clock in holdover Com Critical ✓ The system is configured to work in ✓ ✓

mode or in free-run autonomous mode and is in holdover or
mode free-run mode because all timing
(timing-reference) references are in failure.
8 Communication lost with Equip Critical ✓ The NT cannot communicate with the ✓ ✓
SHub (shub-loc) SHub.
25 Back panel type invalid Equip Major — The NEP back panel type read from ✓ —
(back-pnl-inv) SMAS case is an unknown type.
28 SHub configuration loss Equip Critical ✓ The SHub configuration saved on the NT ✓ —
(lost) unit differs from the current SHub
configuration. The last changes on the
SHub 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 — — — — ✓ ✓
1 Rack power alarm Equip Minor — Power fuse broken. ✓ —

(rack-power)
(1 of 17)

2 Rack fan unit 1 alarm Equip Major — Fan unit 1 in rack is failing. ✓ —
(rack-fan-unit1)
3 Rack fan unit 2 alarm Equip Major — Fan unit 2 in rack is failing. ✓ —
(rack-fan-unit2)
7 Shelf-type mismatch Equip Minor — Shelf detected, but its actual shelf type is ✓ ✓
alarm unknown or it differs from the planned
(shelf-type-mismatch) shelf type.
8 Extension chain Equip Critical ✓ A consistency problem has been ✓ ✓

installation alarm detected with the installation of the
(ext-chain-instl) extension chain or multiple chains.
9 Shelf missing alarm Equip Major ✓ Shelf is planned, but no shelf detected. A — ✓
(shelf-missing) shelf has been detected at least once
since it was planned.
Alarm type = EquipHolder (2); Index 1 = eqptHolderId (index in equipment holder table to identify a shelf), Index 2 =
not used
0 No defects — — — — ✓ ✓
15 Door alarm Envir Minor — Open NEP cabinet door. ✓ —

(door)
17 Fuse alarm Equip Critical — An indication has been detected that ✓ ✓

(fuse) exactly one power feed is inoperative
within a shelf. This can be due to no input
power or a blown fuse.
18 Single fan failure Equip Major — One or more of the shelf’s fans has — ✓
(single-fan-fail) failed.
19 Double fan failure Equip Critical ✓ Two or more fans in the ARAM-D shelf — ✓
(double-fan-fail) have failed, or the fan tray was removed.
The shelf on which the failure occurred
automatically powers down after
approximately 2 min. (2)
The shelf can be a standalone, a host, or
an expansion shelf.
20 System ac power failure Envir Critical ✓ The shelf will shut down in 15 min. — ✓
(ac-power-fail) This alarm is externally provided.
Alarm type = PlugInUnit (3); Index1 = eqptSlotId (index in equipment Board Table), Index2 = not used
0 No defects — — — — ✓ ✓
3 Board-type mismatch Equip Minor — Unit detected, but its actual unit type is ✓ ✓
alarm (1) unknown or it differs from the planned
(board-mismatch) unit type. This alarm applies to all unit
types: NT, LSM, and ACU units.
(2 of 17)

4 Waiting for software Equip Major — This alarm is raised when the system ✓ ✓
(sw-download) cannot 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 exceeded Equip Major — The temperature threshold on the unit is ✓ ✓
(temperature) exceeded. This alarm applies to NT and
LSM units.
12 Temperature shutdown Equip Major ✓ The unit has powered off as a result of ✓ ✓
alarm temperatures that are too high. This
(temp-shutoff) alarm applies only to LSM units.
13 Defense alarm Equip Critical ✓ The plug-in unit is disconnected from the ✓ ✓
(defense) 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
14 Board missing alarm (1) Equip Major ✓ Unit is planned, no unit is detected, but a ✓ ✓
(board-present) 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 Minor — Unit is planned, no unit is detected, and ✓ ✓
missing alarm (1) no unit has ever been detected since it
(board-inserted) was planned. This alarm applies to all
unit types: NT, LSM, and ACU units.
16 Board initialization Equip Major ✓ A unit initialization failure has been ✓ ✓

alarm (1) detected. This alarm applies only to LSM
(board-init) units.
17 Board reset protection (1) Equip Major ✓ The number of unit resets within a ✓ ✓
(number-of-resets) certain timeframe exceeded the
threshold. This alarm applies only to
LSM units.
28 SEM external power Equip Critical ✓ Power to the external power supply — ✓
failure (sem-power-fail) failed. SEM is running on battery power.
29 SEM external power Equip Critical ✓ External SEM power supply or the — ✓
supply failure batteries failed. The external AC power
(sem-ups-fail) supply can still provide power, but needs
to be checked to ensure uninterruptible
power service.
30 Board reset or Equip Major ✓ The LT unit has reset (alarm ON followed — —
communication failure (1) by alarm OFF), or there is a
(board-reset-cf) communication failure (alarm ON).
(3 of 17)

31 SHub uplink breakdown Equip Critical ✓ The SHub uplink is broken. The alarm is — —
(shub-uplink) forwarded to the NT, then to the ACU.
Alarm type = ATM (8); Index1 = ifIndex (of ATM physical port), Index2 = see specific alarm number
0 No defects — — — — ✓ ✓
2 Cell discarded in the QoS Minor ✓ ATM cell discarded in the upstream ✓ ✓
upstream direction direction.
(cell-discard-up) Index2 = VPI/VCI
Report mode = disabled
Logging mode = disabled
3 Cell discarded in the QoS Minor ✓ ATM cell discarded in the downstream ✓ ✓
downstream direction direction.
(cell-discard-down) Index2 = VPI/VCI
6 Duplicate MAC address Com Minor ✓ Duplicate MAC address from this PVC ✓ ✓
from this pvc (the port with the latter coming MAC
(mac-conflict) 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. (3)
Index2 = VPI/VCI
Alarm type = CustomizableAlarm (10); Index1 = Rack_ID (position of the rack, range 0 to 5), Index2 = not used
0 No defects — — — — ✓ —
1 CustomizableAlarm 1 Envir Indeter- — Customizable alarm 1 alarm. ✓ —

(custom1) minate

(custom2) minate

(custom3) minate

(custom4) minate

(custom5) minate
Alarm type = CustomizableAlarm (10); Index1 = eqptHolderID (shelf index in equipment holder table), Index2 = not
used
0 No defects — — — — ✓
11 HECustomizableAlarm 1 Envir Indeter- — HE Customizable alarm 1 alarm. — ✓

(he-custom1) minate

(he-custom2) minate
(4 of 17)


(he-custom3) minate

(he-custom4) minate

(he-custom5) minate

(he-custom6) minate This alarm applies only to the ARAM-D
shelf.
Alarm type = IMA-group (13)l Index1 = IfIndex (of IMA-group), Index2 = not used
0 No defects — — — — ✓ ✓
Alarm type = IMA-link (14); Index1 = IfIndex (of IMA-link), Index2 = not used
0 No defects — — — — ✓ ✓
Alarm type = Redundancy (20); Index1 = not used, Index2 = not used
0 No defects — — — — ✓ ✓
1 Switchover capability Equip Major The switchover capability in a redundant ✓ ✓
lost (loss-swo-cap) system has been lost.
Alarm type = EthItf (24); Index1 = ifIndex (of Ethernet port), Index2 = see specific alarm number
0 — — — — No defects ✓ ✓
2 Ethernet link down Com Critical ✓ The Ethernet link is down. ✓ ✓

(ether-linkdown) Index2 = not used.
Alarm type = SwMgnt (29); Index1 = eqptSlotId (index in equipment board table for the NT), Index2 = not used
0 No defects — — — — ✓ ✓
1 Implicit software rollback Proc Major ✓ The system cannot make the NotActive ✓ ✓
(sw-rollback) OSWP and linked database operational
(although no error in the database is
detected). The system performs an
implicit rollback to the previous active
OSWP (and linked database).
2 Implicit database Proc Major ✓ The system cannot make the selected ✓ ✓
rollback OSWP and linked database operational
(db-rollback) (an error is detected in the linked
database). The system comes up with
the selected OSWP and the previous
linked database (if possible).
Alarm type = TmpFilter (34); Index1 = 0, Index2 = 0 Remark: These values are inherited from the related basic alarm
0 No defects — — — — ✓ ✓
1 Derived alarm for Com Indeter- — Derived alarm for temporal filter. ✓ ✓
temporal filter minate Report mode = disabled
(der-temp1) Logging mode = disabled
(5 of 17)

(6 of 17)

Alarm type = SpaFilter (35); Index1 = 1, Index2 = not used
0 No defects — — — — ✓ ✓
1 Derived alarm for spatial Com Indeter- — Derived alarm for spatial filter. ✓ ✓
filter (der-spa1) minate Report mode = disabled
(7 of 17)

(8 of 17)

Alarm type = xDSL (38); Index1 = ifIndex (of xDSL physical port), Index2 = not used
0 No defects — — — — ✓ ✓
1 xdsl near end loss of Com Minor ✓ Specifies whether a near end loss of ✓ ✓
signal (xdsl-ne-los) signal has occurred
frame (xdsl-ne-lof) frame has occurred
margin (xdsl-ne-lom) margin has occurred
4 xdsl near end excessive Com Minor ✓ Specifies whether near end excessive ✓ ✓
server errors server errors occurred
(xdsl-ne-ese)
(9 of 17)

5 Activation failure — Com Critical ✓ Line configuration data cannot be used. ✓ ✓

configuration error
(line-config)
6 Activation failure — Com Major ✓ Line capacity not high enough to set up ✓ ✓
configuration not requested profile
feasible (line-capacity)
7 Near end — bit rate Com Minor ✓ Upstream planned bit rate not reached ✓ ✓
threshold after initialization
(near-end-bitrate)
8 xdsl near end - no cell Com Minor ✓ Specifies whether a near end cell ✓ ✓
delineation (xdsl-ne-ncd) delineation has occurred
9 xdsl near end - loss of Com Minor ✓ Specifies whether a loss of near end cell ✓ ✓
cell delineation delineation has occurred
(xdsl-ne-lcd)
10 xdsl far end - loss of Com Minor ✓ Specifies whether a far end loss of signal ✓ ✓
signal (xdsl-fe-los) has occurred
11 xdsl far end - loss of Com Minor ✓ Specifies whether a far end loss of frame ✓ ✓
frame (xdsl-fe-lof) has occurred
12 xdsl far end - loss of Com Minor ✓ Specifies whether a far end loss of power ✓ ✓
power (xdsl-fe-lpr) was detected
13 xdsl far end - loss of link Com Minor ✓ Specifies whether a far end loss of link ✓ ✓
(xdsl-fe-lol) was detected
14 xdsl far end - loss of Com Minor ✓ Specifies whether a far end loss of ✓ ✓
margin (xdsl-fe-lom) margin has occurred
15 xdsl far end - excessive Com Minor ✓ Specifies whether far end excessive ✓ ✓
severe errors server errors occurred
(xdsl-fe-ese)
16 Activation failure — Com Major ✓ Unsuccessful initialization as a result of ✓ ✓

Communication problem communication problems.
(xdsl-init)
17 Activation failure — No Com Minor ✓ Peer modem not detected ✓ ✓

peer modem detected
(peer-modem)
18 Far end — bit rate Com Minor ✓ Downstream planned bit rate not ✓ ✓
threshold reached after initialization.
(far-end-bitrate)
19 xdsl far end - no cell Com Minor ✓ Specifies whether a far end cell ✓ ✓
delineation (xdsl-fe-ncd) delineation has occurred
20 xdsl far end - loss of cell Com Minor ✓ Specifies whether there is a far end loss ✓ ✓
delineation (xdsl-fe-lcd) of cell delineation
Alarm type = xDSLTca (39); Index1 = ifIndex (of xDSL physical port), Index2 = not used
0 No defects — — — — ✓ ✓
1 xdsl near end TCA alarm QoS Minor — The number of errored seconds ✓ ✓
- errored seconds in 15 encountered by the ADSL line in the
min (xtca-ne-es) current 15-minute interval has reached
its threshold value.
(10 of 17)

2 xdsl near end TCA alarm QoS Minor — The number of severely errored seconds ✓ ✓
- severely errored encountered by the ADSL line in the
seconds in 15 min current 15-minute interval has reached
(xtca-ne-ses) its threshold value.
3 xdsl near end TCA alarm QoS Minor — The number of unavailable seconds ✓ ✓
- unavailable seconds encountered by the ADSL line in the
(xtca-ne-uas) current 15-minute interval has reached
4 xdsl near end TCA alarm QoS Minor — The number of errored seconds ✓ ✓
- errored seconds in 1 encountered by the ADSL line in the
day (xtca-ne-day-es) current one-day interval has reached its
threshold value.
5 xdsl near end TCA alarm QoS Minor — The number of severely errored seconds ✓ ✓
- severely errored encountered by the ADSL line in the
seconds in 1 day current one-day interval has reached its
(xtca-ne-day-ses) threshold value.
6 xdsl near end TCA alarm QoS Minor — The number of unavailable seconds ✓ ✓
- unavailable seconds in encountered by the ADSL line in the
1 day (xtca-ne-day-uas) current one-day interval has reached its
threshold value.
7 xdsl far end TCA alarm - QoS Minor — The number of errored seconds ✓ ✓
errored seconds in encountered by the ADSL far-end line in
15 min (xtca-fe-es) the current 15-minute interval has
reached its threshold value.
8 xdsl far end TCA alarm - QoS Minor — The number of severely errored seconds ✓ ✓
severely errored encountered by the ADSL far-end line in
seconds in 15 min the current 15-minute interval has
(xtca-fe-ses) reached its threshold value.
9 xdsl far end TCA alarm - QoS Minor — The number of unavailable seconds ✓ ✓
unavailable seconds encountered by the ADSL far-end line in
(xtca-fe-uas) the current 15-minute interval has
reached its threshold value.
10 xdsl far end TCA alarm - QoS Minor — The number of errored seconds ✓ ✓
errored seconds in 1 day encountered by the ADSL far-end line in
(xtca-fe-day-es) the current one-day interval has reached
11 xdsl far end TCA alarm - QoS Minor — The number of severely errored seconds ✓ ✓
severely errored encountered by the ADSL far-end line in
seconds in 1 day the current one-day interval has reached
(xtca-fe-day-ses) its threshold value.
12 xdsl far end TCA alarm - QoS Minor — The number of unavailable seconds ✓ ✓
unavailable seconds in encountered by the ADSL far-end line in
1 day (xtca-fe-day-uas) the current one-day interval has reached
Alarm type = eoConversion (50); Index1 = 100BASE-FX port identification (1 to 4 for ISAM), Index2 = not used
0 No defects — — — — ✓ ✓
1 E/O conversion LOS Equip Major ✓ E/O conversion module loss of signal. ✓ ✓
(loss-of-signal)
2 E/O conversion Tx fault Equip Major ✓ E/O conversion module transmission ✓ ✓

(transmission) fault.
(11 of 17)

Alarm type = bonding (54); Index1 = IfIndex (of bonding group), Index2 = not used
0 No defects — — — — ✓ ✓
1 Bonding group upstream Com Minor ✓ Group upstream actual bit rate is above ✓ ✓
planned bit rate group upstream minimum bit rate but
threshold below group upstream planned bit rate.
(up-plan-bitrate)
2 Bonding group upstream Com Minor ✓ Group upstream actual bit rate dropped ✓ ✓
minimum bit rate below group upstream minimum bit rate.
threshold
(up-min-bitrate)
3 Bonding group upstream Com Major ✓ Group upstream actual bit rate is not ✓ ✓
configuration not high enough to set up the configured
feasible (up-config) group upstream minimum bit rate.
4 Bonding group Com Minor ✓ Group downstream actual bit rate is ✓ ✓

downstream planned bit above group downstream minimum bit
rate threshold rate but below group downstream
(down-plan-bitrate) planned bit rate.
5 Bonding group Com Minor ✓ Group downstream actual bit rate ✓ ✓

downstream minimum dropped below group downstream
bit rate threshold minimum bit rate.
(down-min-bitrate)
6 Bonding group Com Major ✓ Group downstream actual bit rate is not ✓ ✓
downstream high enough to set up the configured
configuration not group downstream minimum bit rate.
feasible
(down-config-not-feas)
7 Bonding group no peer Com Minor ✓ CPE modem is not connected to the ✓ ✓
modem detected group lines.
(no-peer-cpe)
8 Bonding group no Com Minor ✓ Bonding CPE modem is not connected ✓ ✓

bonding CPE 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
0 No defects — — — — ✓ ✓
1 VRF assignment failure Proc Major ✓ Failure to assign a VRF for a user ✓ ✓
(vrf-assign-fail) session:
• unknown VRF: VRF returned by
RADIUS 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.
(12 of 17)

2 VLAN assignment failure Proc Major ✓ Failure to assign a VLAN for a user ✓ ✓
(vlan-assign-fail) session:
• unknown VLAN: VLAN returned by
RADIUS server is not locally
• no VLAN: RADIUS server did not
return a VLAN while no default VRF
is locally configured for the domain.
3 IP Address pool Proc Major ✓ Failure to assign an IP address pool: ✓ ✓

assignment failure • unknown pool-id: pool-id returned by
(ip-pool-assign-fail) the RADIUS server is not locally
• 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
4 QoS parameters Proc Major ✓ Failure to assign QoS parameters for a ✓ ✓

assignment failure user session:
(qos-assign-fail) • unknown QoS profile: 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 assignment Proc Major ✓ Failure to assign IP address for a user ✓ ✓

failure session:
(ip-addr-assign-fail) • IP address already in 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 Major ✓ RADIUS server should always specify a ✓ ✓

(rad-pool-id) pool-id when it returns a VRF.
Alarm type = IpoX (68); Index1 = ifIndex of IpoX interface on which session takes place, Index2 = not used
0 No defects — — — — ✓ ✓
(13 of 17)

1 IP address preempt Com Major ✓ A new IP session is established with a ✓ ✓

(ip-addr-preempt) user IP address previously assigned to
another IP 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); Index 1 = ifIndex of IPoX interface on which the session takes place, Index 2 = not used
0 No defects — — — — — ✓
1 Host SFP LOS Com Critical ✓ Host shelf downlink SFP loss of signal. — ✓
(host-sfp-los) This alarm applies only to a host
ARAM-D shelf.
2 Host SFP Tx fail Com Critical ✓ Host shelf downlink SFP transmission — ✓
(host-sfp-tx-fail) failure. This alarm applies only to a host
ARAM-D shelf.
3 Host SFP not present Com Critical ✓ Host SFP missing. Host shelf downlink — ✓
(host-sfp-not-prst) SFP detected but later removed. This
alarm applies only to a host ARAM-D
shelf.
4 Host SFP invalid Alcatel Com Critical ✓ Host shelf downlink SFP does not have a — ✓
ID (host-sfp-inv-id) valid Alcatel ID. This alarm applies only
to a host ARAM-D shelf.
5 Host SFP control fail Com Critical ✓ Host shelf downlink SFP control failure. — ✓
(host-sfp-ctrl-fail) This alarm applies only to a host
ARAM-D shelf.
Alarm type = SFP (76); Index 1 = eqptSlotId of corresponding LSM in ES, Index 2 = not used
0 No defects — — — — — ✓
11 Expansion Shelf SFP Com Critical ✓ Expansion Shelf SFP loss of signal. This — ✓
LOS alarm applies only to an ES shelf.
(exp-sfp-los)
12 Expansion Shelf SFP Tx Com Critical ✓ Expansion Shelf SFP transmission — ✓

fail failure. This alarm applies only to an ES
(exp-sfp-tx-fail) shelf.
13 Expansion shelf SFP not Com Critical ✓ ES SFP missing. Expansion Shelf SFP — ✓
present detected but later removed. This alarm
(exp-sfp-not-prst) applies only to an ES shelf.
14 Expansion shelf SFP Com Critical ✓ Expansion Shelf SFP does not have a — ✓
invalid Alcatel ID valid Alcatel ID. This alarm applies only
(exp-sfp-inv-id) to an ES shelf.
15 Expansion Shelf SFP Com Critical ✓ The SFP alarm for the expansion shelf — ✓
control fail downlink SFP control failure.
(exp-sfp-ctrl-fail) This alarm applies only to an ES shelf.
Alarm type = LLURelay (78); Index 1 = eqptSlotId (index in equipment board table), Index 2 = not used
0 No defects — — — — ✓ —
1 Wrong applique for LLU Com Major ✓ LLU relay set for some ports but applique ✓ —
(wrong-or-no-applq) inserted in slot is not compatible with
LLU relay.
(14 of 17)

Alarm type = SHDSL_ISAM (82); Index1 = IfIndex (of SHDSL physical port), Index2 = linkID (higher 16 bits) + device
ID (lower 16 bits)
0 No defects — — — — ✓ ✓
Alarm type = CustomExternalAlarms (83); Index1 = eqptSlodId (index in equipment board table), Index2 = not used
0 No defects — — — — — ✓
1 CustomizableExternalAl Equip Major — REM customizable external alarm 1 — ✓

arm1 (ext-alarm1)

arm2 (ext-alarm2)
arm3 (ext-alarm3)

arm4 (ext-alarm4)

arm5 (ext-alarm5)
Alarm type = PlugInUnit2 (84); Index1 = eqptSlotId (index in equipment board table), Index2 = not used
0 No defects — — — — — ✓
1 Fan Equip Major — REM fan power alarm — ✓

(fan-alarm)
2 DC A Equip Major — REM DC A voltage low. DC B takes over. — ✓

(dc-a-alarm)
3 DC B Equip Major — REM DC B voltage low. DC A takes over. — ✓
(dc-b-alarm)
4 Dying gasp Equip Critical ✓ REM dying gasp alarm. REM going out — ✓
(dg-alarm) of service due to power shutdown.
Possible causes: power failure, mains
switch off, excessive over temperature,
etc.
5 Applique power supply Equip Critical ✓ Applique power supply malfunction. The ✓ —
failure relays are no longer configurable and are
(apsf-alarm) switched to the hardware default
position.
Alarm type: LANX (51); Index1 = not used, Index2 = not used
0 No defects — — — — ✓ ✓
1 LANX fan failure (fan) Eqp Major — SHub fan failure. This alarm is not — —
currently supported on the system.
2 LANX power fan failure Eqp Major — SHub power fan failure. This alarm is not — —
(power-fan) currently supported on the system.
3 LANX database restore Eqp Major ✓ The SHub database restore has failed. ✓ ✓
(db-restore)
4 Emergency reboot Eqp Major — The SHub has rebooted from the ✓ ✓
(emergency-reboot) emergency boot package.
(15 of 17)

5 LANX SNTP Eqp Major — SHub SNTP communication lost. The ✓ ✓

Communication Lost SNTP server does not respond to the
(sntp-comm) requested messages from the SHub.
6 No ARP reply received Com Major ✓ An ARP request has been sent for a ✓ ✓
for next IP hop statistically configured next hop, but no
(arp-reply) ARP reply has been received in the
specified time interval.
Index1 = VRF ID
Index2 = IP address of next hop
Alarm type = ethLanx (52); Index1 = port identification of LANX Ethernet port, Index2 = see specific alarm number
0 No defects — — — — ✓ ✓
1 Ethernet link down Com Critical ✓ Specifies the Ethernet link status. ✓ ✓
(link-down) Index 2 not used.
3 SHub MAC conflict COM Minor ✓ Duplicate MAC address from Ethernet — —
(mac-conflict) port of LAN switch.
Index 1 = port with the later coming MAC
address that causes conflict.
Index 2 = VLAN ID of domain on which
the conflict happened.
Alarm type = OSPF (69); Index 1 = VRF-ID (VRF unique ID), Index 2 = see specific alarm number
0 No defects — — — — ✓ ✓
1 OSPF interface Com Minor — Received a packet with: ✓ ✓

configuration error • OSPF version mismatch
(config) • area mismatch (area ID or subnet ID
not matching)
• netmask mismatch
• hello interval mismatch
• dead interval mismatch
• options mismatch
Index2 = interface index
2 OSPF interface Com Minor — Received a packet with: ✓ ✓

authentication error • authentication type mismatch
(authen) • authentication failure
Index2 = interface index
3 OSPF interface received Com Critical ✓ Received a packet that cannot be ✓ ✓

bad packet parsed.
(rcv-bad-pkt) Index2 = interface index
4 OSPF LSDB Com Major — The external LSA database has reached ✓ ✓
approaching overflow 90% of the external LSA limit.
(lsdb-90) Index2 = LSDB limit (percentage utilized)
5 OSPF LSDB overflow Com Major — The external LSA count has reached the ✓ ✓
(lsdb-ovfl) external LSA overflow limit.
Index2 = LSDB limit (percentage used)
(16 of 17)

6 OSPF neighbor state Com Minor ✓ An OSPF neighborship is newly ✓ ✓

change established or dismantled.
(nhbr-statchg) Index2 = interface index (interface on
which the neighbor was learned)
7 OSPF interface state Com Minor ✓ The OSPF interface status has changed ✓ ✓
change (the DR or BDR may have been changed
(nhbr-itfchg) according to this OSPF interface).
Index2 = interface index (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 Minor ✓ Received a packet with: ✓ ✓

configuration error • RIP version mismatch
(config-err) • netmask mismatch
2 RIP interface Com Minor ✓ Received a packet with: ✓ ✓

authentication error • authentication type mismatch
(auth-fail) • authentication failure
3 RIP interface received Com Minor ✓ Received a packet that cannot be ✓ ✓

bad packet (rcv-bad-pkt) parsed.
Alarm type = LANXuplinkgroup (75); Index1 = uplink group number, Index2 = not used
0 No defects — — — — ✓ ✓
7 LANX uplink group down Com Major ✓ The SHub uplink group is down. ✓ ✓
(uplink-down)
(17 of 17)
Notes
(1) The alarm names are listed exactly as they appear in the CLI configure command. 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.
(2) No rack shutdown occurs on an ARAM-D shelf that has the following PWIO-B cards installed: 3FE 24323 AC or
3FE 24323 AD.
(3) See the Duplicate Mac Alarm Status command in the CLI Commands document for more information.
Table TAP 104-2: Troubleshooting alarms
Alarm (grouped by alarm type) Description Recommendation
No. Name (CLI) (1)
Alarm type = Equip (1)
1 persist-data-loss Persistent data loss Reconfigure system.
2 sntp-comm-lost SNTP communication lost Check SNTP server.
4 nt-disk-90%full NT disk 90% full Clean up disk space.
(1 of 11)

No. Name (CLI) (1)
5 preferred-mode System clock not using preferred timing Check all timing references that correspond to
mode the preferred timing mode for the peer
equipment and the link between the peer
equipment and the system.
6 timing-reference System clock in holdover or free-run Check all timing references for the peer
mode equipment and the link between the peer
equipment and the system.
8 shub-loc SHub loss of contact Check the external LAN switch.
25 BackPanel-type invalid NEP back panel type invalid System will start up with default back panel.
(back-pnl-inv) Check back panel type configuration when
system is running.
28 lost SHub configuration loss Check the SHub configuration with respect to
the database (last database changes may be
lost).
Alarm type = EquipHolder (2)

1 rack-power Rack power Check power supplies.
2 rack-fan-unit1 Rack fan 1 Check the fan.
3 rack-fan-unit2 Rack fan 2 on ARAM-D shelf Check the fan.
7 shelf-type-mismatch Shelf-type mismatch Check equipment.

Check configuration.
8 ext-chain-instl Extension chain installation Check cabling of the extension cable.
9 shelf-missing Shelf missing Check presence of GENC on host shelf.

Check cabling to ES.
Check presence of EDSE on ES.
Check presence of LT on ES.
Check presence of PWIO-B on ES.
Check fan on ES.
Check power cable on ES.
15 door Door Close the door.

17 fuse Fuse Check fuse.
Check power feed.
18 single-fan-fail Single fan Check fan tray (the LED of the faulty fan’s tray
is lit red).
19 double-fan-fail Double fan (2) Check fan tray of shelf that raised the alarm.
The shelf will power off within 3 min. of the
alarm.
20 ac-power-fail System ac power failure Check power installation.
Alarm type = PlugInUnit (3)
3 board-mismatch (1) Board-type mismatch Check configuration.
4 sw-download Waiting for software Check configuration.

Download software.
8 temperature Temperature exceeded Check fans and restarts unit.
(2 of 11)

No. Name (CLI) (1)
12 temp-shutoff Temperature shutdown Check ambient temperature.

Check operation of fans.
Check unit.
13 defense Defense Replace unit.
Alarm type = PlugInUnit (3)
14 board-present (1) Board missing Check unit presence.
15 board-inserted (1) Board installation missing Insert unit.
16 board-init (1) Board initialization Force a cold reset of unit, and if this fails
again, repair unit.
17 number-of-resets Board reset protection Force a cold reset of unit, and if this fails
again, repair unit.
28 sem-power-fail SEM AC fail Check the power to the external power

supply.
29 sem-ups-fail SEM PS fail Check the external power supply.

30 board-reset-cf (1) Board Reset or Communication Failure Check cabling if alarm is persistent.
If alarm toggles frequently, the board will go in
Board Reset Protection mode (alarm 3, 17)
and power down.
31 shub-uplink LANX uplink breakdown Check the SHub uplink cable for loose
contacts or missing connections.
Alarm type = ATM (8)
2 cell-discard-up Cell discard up (CDU) No local repair action. Sender must lower
shaping rate.
3 cell-discard-down Cell discard down (CDD) No local repair action. Sender must lower
shaping rate.
6 mac-conflict ASAM MAC conflict Use the diagnostic tool to find the detailed
information. (3)
Alarm type = CustomizableAlarm (10)

1 custom1 Customizable alarm 1 –

11 he-custom1 HE Customizable alarm 1 –

(3 of 11)

No. Name (CLI) (1)
Alarmtype = Redundancy (20)
1 loss-swo-cap Switchover capability lost Check link on standby NT.

Check standby boards. (1)
Wait for Quench timeout.
Alarm type = Ethltf(24)
2 ether-linkdown Ethernet link down Check the Ethernet link.
Alarm type = SwMgnt (29)
1 sw-rollback Implicit software rollback Remove the corrupted OSWP (ABORT

operation).
Download the desired OSWP again.
Activate the downloaded OSWP.
2 db-rollback Implicit database rollback Download the desired database again.
Alarm type = TmpFilter (34)
1 der-temp1 Derived alarm for temporal filter 1 Check the cause of the related basic alarm.
Check the setting of the related temporal filter.
(4 of 11)

No. Name (CLI) (1)
19 der-temp19 Derived alarm for temporal filter1 9 Check the cause of the related basic alarm.
Alarm type = SpaFilter (35)
1 der-spa1 Derived alarm for spatial filter 1 Check the cause of the related basic alarm.
Check the setting of the related spatial filter.
(5 of 11)

No. Name (CLI) (1)
(6 of 11)

No. Name (CLI) (1)
Alarm type = xDSL (38)
1 xdsl-ne-los Near end LOS Check the physical line.

2 xdsl-ne-lof Near end LOF Check modem equipment.
3 xdsl-ne-lom Near end LOM Check the physical line (new distributors).
4 xdsl-ne-ese Near end ESE Check the physical communication medium.

5 line-config Activation failure - configuration error Update the profile parameters.
Ensure that the pilot tones are not marked.
If Glite is used, ensure that the bit rates fit
within the standard.
6 line-capacity Activate failure - configuration not Check configuration data.

feasible Check physical line (length and noise).
7 near-end-bitrate Near end - bit rate threshold Lower planned upstream bit rate.
8 xdsl-ne-ncd Near end - NCD Check the quality of the line.
9 xdsl-ne-lcd Near end - LCD Check the quality of the line
10 xdsl-fe-los Far end - LOS Check the physical line.

11 xdsl-fe-lof Far end - LOF Check modem equipment.
12 xdsl-fe-lpr Far end - LPR There is no repair required because this is the
normal power-down of CPE.
13 xdsl-fe-lol Far end - LOL Check the physical line.

14 xdsl-fe-lom Far end - LOM Check the physical line (new distributors).
15 xdsl-fe-ese Far end - ESE Check the physical line.
16 xdsl-init Activation failure - communication Check the peer modem type.

problem Check the physical line.
(7 of 11)

No. Name (CLI) (1)
17 peer-modem Activation failure - no peer modem Wait until the modem is connected.
detected Check the physical line.
18 far-end-bitrate Far end - bit rate threshold Lower the planned downstream bit rate.
19 xdsl-fe-ncd Far end - NCD Check the quality of the line.
20 xdsl-fe-lcd Far end - LCD Check the quality of the line.
Alarm type = xDSLTca (39)
1 xtca-ne-es Near end - errored seconds Check the physical line.

Check the modem equipment.
2 xtca-ne-ses Near end - severely errored seconds Check the physical line.
3 xtca-ne-uas Near end - unavailable seconds Check the physical line.

4 xtca-ne-day-es Near end - errored seconds in a day Check the physical line.
5 xtca-ne-day-ses Near end - severely errored seconds in Check the physical line.
a day Check the modem equipment.
6 xtca-ne-day-uas Near end - unavailable seconds in a Check the physical line.

day Check the modem equipment.
7 xtca-fe-es Far end - errored seconds Check the physical line.

8 xtca-fe-ses Far end - severely errored seconds Check the physical line.
9 xtca-fe-uas Far end - unavailable seconds Check the physical line.
10 xtca-fe-day-es Far end - errored seconds in a day Check the physical line.
11 xtca-fe-day-ses Far end - severely errored seconds in a Check the physical line.
day Check the modem equipment.
12 xtca-fe-day-uas Far end - unavailable seconds in a day Check the physical line.
Alarm type = eoConversion (50)
1 loss-of-signal E/O conversion LOS Check the E/O conversion module.

Check the optic link.
2 transmission E/O conversion TX fault Check the E/O conversion module.
Alarm type = bonding (54)
1 up-plan-bitrate Bonding group upstream planned bit Lower group upstream planned bit rate.
rate threshold
2 up-min-bitrate Bonding group upstream minimum bit Check physical line.
rate threshold Check line state.
(8 of 11)

No. Name (CLI) (1)
3 up-config Bonding group upstream configuration Check configuration data.

not feasible Check physical line.
4 down-plan-bitrate Bonding group downstream planned bit Lower group downstream planned bit rate.
rate threshold
5 down-min-bitrate Bonding group downstream minimum Check physical line.

bit rate threshold Check line state.
6 down-config-not-feas Bonding group downstream Check configuration data.
configuration not feasible Check physical line.
7 no-peer-cpe Bonding group no modem connected Check the modem.

Check the physical lines.
8 no-bonding-cpe Bonding group no bonding modem Check the modem.

connected Check the physical lines.
Alarm type = authentication (55)
1 vrf-assign-fail VRF assignment failure Check the system configuration.

Check the RADIUS server configuration.
2 vlan-assign-fail VLAN assignment failure Check the system configuration.

3 ip-pool-assign-fail IP address pool assignment failure Check the system configuration.

4 qos-assign-fail QoS parameters assignment failure Check the system configuration.

5 ip-addr-assign-fail IP address assignment failure Check the system configuration.

6 rad-pool-id Missing attributes Check the system configuration.

Alarm type = IpoX (68)
1 ip-addr-preempt IP address preemption Check IP address pool on DHCP server.

Check local IP address pool.
Alarm type = SFP (76)
1 host-sfp-los Host SFP LOS Check the physical line.
2 host-sfp-tx-fail Host SFP Tx fail Check the host shelf SFP module.
3 host-sfp-not-prst Host SFP missing Check the host shelf SFP presence.
4 host-sfp-inv-id Host SFP invalid Alcatel ID Check the host shelf SFP module ID.
5 host-sfp-ctrl-fail Host SFP control fail Check the host shelf SFP module or I2C bus.
If control of all host shelf SFPs fails, check the
GENC-E.
11 exp-sfp-los ES SFP LOS Check the physical line.
12 exp-sfp-tx-fail ES SFP Tx fail Check the Expansion Shelf SFP module.
13 exp-sfp-not-prst ES SFP missing Check the Expansion Shelf SFP presence.
14 exp-sfp-inv-id ES SFP invalid Alcatel ID Check the Expansion Shelf SFP module ID.
(9 of 11)

No. Name (CLI) (1)
15 exp-sfp-ctrl-fail ES SFP control fail Check the Expansion Shelf SFP module or
I2C bus.
Alarm type = LLURelay (78)
1 wrong-or-no-applq Wrong applique for LLU Replace the applique by an applique

compatible with the LLU relay.
Alarm type = CustomExternalAlarms (83)
1 ext-alarm1 REM customizable external alarm 1 —

Alarm type = plugInUnit2 (84)
1 fan-alarm REM fan Check the REM fan.
2 dc-a-alarm REM DC A Check the fuse.

Check the cabling.
3 dc-b-alarm REM DC B Check the fuse.

Check the cabling.
4 dg-alarm REM dying gasp Check the following at the REM and the
cabinet: cabling, fuse, temperature, on and off
switch.
5 apsf-alarm Applique power supply failure Check applique power supply.
Alarm type = LANX (51)
1 fan LANX fan failure Check the SHUB fan module.
2 power-fan LANX power fan failure Check the fan module in SHUB (redundant)
power supply.
3 db-restore LANX database restore Check local flash.

Check remote file system.
Check availability of MIB database.
4 emergency-reboot Emergency reboot Check local flash.
Check remote file system.
Check availability of software package.
5 sntp-comm LANX SNTP communication lost Check SNTP server.
6 arp-reply No ARP reply received for next IP HOP Check existence of configured Nexthop.
Check connection with configured Nexthop.
Alarm type = ethLANX (52)
1 link-down LANX Ethernet link down Check the Ethernet link.
3 mac-conflict LANX MAC conflict No special repair action required. The conflict
MAC address can be manually prohibited or
permitted if needed.
(10 of 11)

No. Name (CLI) (1)

Alarm type = OSPF (69)
1 config OSPF interface configuration error Check the configuration of the OSPF and
OSPF interface.
Check the configuration on the IP interface.
Check the OSPF hello packets received on
the OSPF interface.
2 authen OSPF interface authentication error Check the authentication type and password
configured on the OSPF area and the OSPF
interface.
Check the authentication time range.
3 rx-bad-pkt OSPF interface received bad packet Check the connection between the RIP
interface and the cable.
4 lsdb-90 OSPF LSDB approaching overflow Don’t input external routes anymore, except
for major external network routes.
Configure the OSPF area as a stub area if
possible.
5 lsdb-ovfl OSPF LSDB overflow Remove some external routes in the OSPF
domain.
Configure the OSPF area as a stub area if
possible.
Only input major external network routes.
6 nhbr-statchg OSPF neighbor state change Check the OSPF neighbor table.
• If the neighbor is established correctly,
the situation is normal.
• If the neighbor is down unexpectedly,
check the OSPF process status or the
interface-related parameters.
7 nhbr-itfchg OSPF interface state change No special repair action required. Check and
modify the OSPF interface parameters if
desired to change the OSPF interface status.
Alarm type = RIP (70)
1 config-err RIP interface configuration error Check the configuration of the RIP send and
receive version.
Check the configuration of the IP interface.
Check the RIP request and update packets
received on the interface.
2 auth-fail RIP interface authentication failure Check the authentication type and password
configuration of the RIP interface.
Check the authentication time range.
3 rcv-bad-pkt RIP interface received bad packet Check the connection between the RIP
interface and the cable.
Alarm type = LANXuplinkgroup (75)
7 uplink-down LANX uplink group down —
(11 of 11)
Notes
(1) The alarm names are listed exactly as they appear in the CLI configure command. 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.

(2) No rack shutdown occurs on an ARAM-D shelf that has either of the following PWIO-B cards installed: 3FE 24323 AC or
3FE 24323 AD.
(3) See the Duplicate Mac Alarm Status command in the CLI Commands document for more information.

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 112 — 7330 ISAM FTTN configuration for subtending
TNG 113 — Multi-ADSL parameters
TNG 114 — DLP configuration examples

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 7302 ISAM R3.2 February 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 February 2007 Alcatel 7302 ISAM R3.2

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 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 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 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.
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.
(1 of 2)

Logical Flow Supported Supported Remarks

Type Markers 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 - All frames on a subscriber-side

IBridge port, where encapsulation
mode is IPoE.
PPPoE IBridge single dot1p - 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 — 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.
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
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-3 shows the supported marker types.
Table TNG 101-3: 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 don’t 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, let’s 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
iSAM 7300 Internet

or
7330 FTTN
Video
server
User watching movie
Joint Message
Mcast Downstream
Query Message
17705

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 2 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. 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 4095
• VPI:
Ranges from 32 to 65535
Refer to the 7302 ISAM 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-1 describes the commands available that allow you to view the IGMP
related parameters.
Table TNG 102-1: 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 package-to-src (package-id) Show the IGMP package to multicast source
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 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 subscriber’s
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 SEM remote
expansion units. You can connect up to five ES and three 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 populate up to three racks in an expansion configuration. Each rack can

have up to three shelves. Figure TNG 106-1 shows the rack and shelf assignments for
expansion configurations with multiple shelves.

TNG 106 — Specifying 7330 ISAM FTTN remote expansion units using the CLI
Figure TNG 106-1: Rack and shelf assignments
Rack #1 Rack #2 Rack #3
Shelf #1 Shelf #1 Shelf #1
18027
Rack 1 must always contain the host 7330 ISAM FTTN ARAM-D shelf in the topmost
position and the host shelf must be assigned rack 1, shelf 1. Up to five ES can be installed
in racks 1 and 2. Rack 3 is reserved for the SEM. Although the SEM is a remote
expansion module and not a shelf, the 7330 ISAM FTTN system and management
software identifies each SEM according to the rack and shelf designation shown in
Figure TNG 106-1.
The SEM will nearly always be installed in remote locations, away from the host shelf that
is installed in the CO. Expansion shelves can be co-located with the host shelf or be
installed in remote locations. As such, racks 2 and 3 are virtual racks. This means that
they do not necessarily need to be physical racks installed in the same CO location as
rack 1, which contains the host shelf. Shelves 2 and 3 in rack 1 can also be assigned to
remotely located ES.
Note — You can assign expansion shelves to rack 1 and rack 2 only.
Rack 3 is reserved for SEM remote expansion units.
For the ES, rack and shelf assignments are derived from the shelf jumper settings. For
the SEM, the rack and shelf assignment is derived from the downlink port on the GENC-E
or GENC-F card to which the SEM is connected. Rack and shelf assignments for
downlink ports are configurable using CLI.
Configurable rack and shelf ID assignments

The downlink ports on the GENC-E or GENC-F card to which you connect a remote
expansion unit have configurable rack and shelf ID assignments. Each ES and SEM 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. The SEM does not use jumpers to set the rack and shelf ID.
For the SEM, the rack and shelf ID are derived from the downlink port settings of the
GENC-E or GENC-F card. 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.

When you connect a SEM to downlink ports 8, 9, or 10 on the GENC-E or GENC-F card,
the SEM is automatically assigned rack 3, shelf 1, 2, or 3 respectively. Only downlink
ports 8, 9, and 10 automatically assign a rack and shelf ID to the SEM. The jumper
settings of the ES override the default rack and shelf assignments of downlink ports 8, 9,
and 10 without requiring 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 downlink ports 8, 9, or 10 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 or GENC-F card. Configuration using the CLI overrides the default rack
and shelf assignments of downlink ports 8, 9, and 10. 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 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.
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.
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 ES always appears in rack 1 or rack 2
• the SEM always appears in rack 3
• the slot ID for the SEM is always slot 4 using CLI
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-1 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-1: 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

LP slot 4 (LP4) Matching applique for LT unit installed in LT4 —
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 LT unit installed in slot LT1 for shelf 2 in rack 1 is
as follows:
configure equipment slot 1/2/4 planned type <card type>
where <card type> is the mnemonic of the LT unit installed in LT

slot 1; for example evlt-a
An example command to configure a SEM connected to downlink port 9 on the GENC-E

or GENC-F card is as follows:
configure equipment slot 3/2/4 planned type <card type>
where <card type> is the mnemonic of the SEM, which is vsem-a


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

Re-initialization triggers
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
Line operation configuration

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
Notes
(1) Alcatel 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
Flavor-dependent configuration parameters

All parameters grouped under this requirement have a common for all DSL flavours
supported in Alcatel 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
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”
Notes
(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)
Notes
(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 shouldn’t 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)

Supported operational data parameters

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)los 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

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 don’t 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-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 line’s 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-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-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-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-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-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: 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
(1 of 2)

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)
(2 of 2)
Worst Case Downstream Target Noise Margin
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: 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: 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: 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: 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: 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: 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: Loopback Timeout
Name Loopback Timeout
Description Specifies the Loopback Timeout duration in minutes.

A value of 0 disables timeout.
Instances Unit
Values 0-4095
Granularity & Unit 1minute

Supported segment termination operation configuration parameters
Loopback Config
Table TNG 108-18: Loopback Config
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: 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: 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: Span State
Name Span State

Description Indicates the overall state of this SHDSL span
Instances Span
Values unknown
unequipped
faulty
idle
startup
active
Initialization value “Idle”
Showtime value: “Active”

Update frequency NA

Detected Units
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: 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
Update frequency NA

Span Status
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: 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: 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: 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: 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: 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: 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: 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: 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: 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.2, 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 7330 ISAM FTTN Operations
and Maintenance Using CLI 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/[1…48]: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 [101…124] 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 [101…124] egress-port network:2
configure vlan shub id [101…124] 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 [101…124] 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/[4…7]
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.[1…100] 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 [101…124] 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 information about configuring the 7330 ISAM FTTN ES.
General
Table TNG 111-1 lists the correlation between the LT port number entered in CLI and the
GENC-E downlink port linked by fiber to the EDSE-A card on the ES.
Table TNG 111-1: LT port numbers: GENC-E to CLI correlation
GENC-E downlink port number LT port number in CLI
6 (1) 8
7 (1) 9
8 10
9 11
10 12
11 13
12 14
13 15
14 16
15 17
16 18
17 19

Note
(1) Dual-mode port. This port can be configured as an uplink or downlink port. The default setting is
uplink. The SFP alarms behave differently depending on whether the port is configured as uplink or
downlink.
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 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:
9 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 port as shown in Table TNG 111-1; you can enter a single
port number or a range of port numbers
Example:
configure equipment external-link-host [6...7] direction

remote-lt

10 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
7302 ISAM | 7330 ISAM FTTN System Description.
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
• Line operation configuration
• Multi-ADSL common configuration parameters
• Flavor-dependent configuration parameters
• ADSL2plus-specific configuration parameters
• Supported operational data 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)los 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
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
Line operation configuration

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-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-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
Notes
(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 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)
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
Description Only applicable in case of RA mode 3 (dynamic).

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 [0¨255; c ; 0¨255] 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
Flavor-dependent configuration parameters

All parameters grouped under this requirement have a common for all DSL flavours
supported in Alcatel 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
Notes
(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

Supported operational data parameters

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
Notes
(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 10 11 12 13 14 15 16 17 18 19 0 1 2 3 4 5 6 7
56 residential-bridge
70 layer2-term-netwport T
100 residential-bridge residential-bridge x x x x U
101 layer2-terminated residential-bridge x x x x x x x x x x x x x x x x T
200 residential-bridge residential-bridge x x x x x x T

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-terminated
500:600 cross-connect
512 layer2-terminated x
560 residential-bridge
2200 cross-connect cross-connect
4090 layer2-terminated v-vlan x x x x x x
4093 reserved T
Notes
(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


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 7302 ISAM R3.2 February 2007 GL-1

Glossary
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 Intelligent Services Access Manager
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 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.
AACU-C ADSL Alarm Control Unit
A plug-in board that performs alarm control functions and provides
connectivity for a craft terminal and Ethernet 10Base-T connectivity for
maintenance access.
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 February 2007 Alcatel 7302 ISAM R3.2

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-K ADSL Fan Unit
An ARAM-B component that cools the shelf.
AFAN-L ADSL Fan Unit
An ARAM-D component that cools the shelf.
AIS Alarm Indication Signal
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-B Two-LT-Slot Shelf
The shelf type used for the 7330 ISAM FTTN that has two LT slots and
holds all the other shelf components. The ARAM-B shelf has mounting
flanges that enable it to be mounted horizontally in a 23-inch rack, or
horizontally or vertically in a CO, CEV, and OSP cabinet.
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 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.

Glossary
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.
ASCII American Standard Code for Information Interchange
Coding method used to convert letters, numbers, punctuation, and control
codes into digital form.
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.
ATU-C ADSL Transceiver Unit - CO side
ATU-R ADSL Transceiver Unit - Remote side
AVPC-A Low-pass Filter Applique
An ADSL and POTS splitter applique that provides connectivity between
POTS CO lines, high-bandwidth IP services (through an LT unit) and 48
ADSL subscriber drop lines on the ARAM-D shelf.
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.

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

Glossary
CMOS Complementary Metal Oxide Semiconductor

CMP Communications Plenum Cable
CO Central Office
Telephone switching center that connects subscribers within a telephone
network.
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 board 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.
DSNC-A DSx Network Combiner
A general facilities board that provides power to the other units in the
ARAM-B shelf, including the fan unit. It also provides connectivity for five
user-definable external alarm inputs and an ac failure alarm input.
DSP Digital Service Provider
EAPOL Extensible Authentication Protocol Over LAN
EBLT-C Multi-ADSL Line Termination unit
A board that supports connectivity between the NT unit, PSTN, and
multi-ADSL subscribers through the AVPC-A, HLPC-H, or HLPC-J
applique.

Glossary
EBLT-E Multi-ADSL Line Termination unit

A board that supports connectivity between the NT unit, PSTN, and
multi-ADSL subscribers through the AVPC-A, HLPC-H, or HLPC-J
applique.
EBLT-K Multi-ADSL Line Termination unit with system level bonding
A board 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.
EDSE-A Expansion Shelf Controller
An expansion shelf controller that provides some control functions for the
expansion shelf. The EDSE-A board also provides four Ethernet expansion
links for inter-shelf communications and for connecting the remote LT units
on the ES to the ARAM-D 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 (ARAM-D) as the
7330 ISAM FTTN host 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 xDSL Line Termination Unit
A board that supports connectivity between an NT unit and ADSL, VDSL,
and VDSL2 subscribers through the VPSC-D applique.
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.
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.

Glossary
GFC General Facilities Card

See DSNC-A and 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-B or 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-B or ARAM-D shelf.
HSI High Speed Internet
IACM Intelligent Control, Access Termination and Management
iBridge Intelligent Bridging mode, also known as residential bridging mode
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.
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.

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

Glossary
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 board 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.
LPF Low-pass Filter
LFP is a single transmission band extending from zero frequency up to a
specified cutoff frequency, not infinite.
LP slot A slot in the 7330 ISAM FTTN shelf where an applique is installed.
LSA Link State Advertisement
Message of the OSPF routing protocol that informs about network topology
changes.
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

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

Glossary
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 board 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
OSWP Overall Software Package
PADI PPPoE Active Discovery Initiation
POTS Plain Old Telephone Service
Term used to describe narrowband, voice-only telephone service.
PPP Point-to-Point Protocol

Glossary
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.
PVC Permanent Virtual Connection
PVIC Port VLAN Identifier
PWIO-B Power I/O board
A general facilities board that provides power to the other units in the
ARAM-D shelf, including the fan unit. Two variants of the board 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.
RA Rate Adaptation
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

Glossary
READSL2 Reach Extended ADSL2

RED Random Early Detection
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.
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
RTU Remote Test Unit
RU Rack Unit
A rack unit is a unit of vertical space in a standard 19-inch equipment rack.
One RU is 1.75 in. (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

Glossary
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 A 24-port VDSL and POTS splitter remote expansion module for the 7330
ISAM FTTN ARAM-D shelf. The SEM features a flood resistant,
environmentally hardened enclosure that is compliant with GR-950-CORE.
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 board Ethernet
switch (also known as LANX).
SI Système international d’unités
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.
SRA Seamless Rate Adaptation
SSCS Service-Specific Convergence Sublayer
SSH Secure Shell

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

Glossary
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
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.
VP/VC Virtual Path/Virtual Channel
VPI Virtual Path Identifier
Identifier in ATM cell that distinguishes data of one VP from data of
another.

Glossary
VPSC-D xDSL POTS Splitter board

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.
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.
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 encapsulation A general term used to refer to an unspecified type of encapsulation over
ATM.

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-3 example, TNG 110-12
maintaining, NTP 124-1 iBridge VLAN configuration example,
802.1x TNG 110-11
configuring, DLP 145-1 basic management connectivity
disabling, DLP 145-1 configuration example, TNG 110-2
802.1x parameters bridge
configuring, DLP 145-1 configure
general parameters, DLP 195-1
A configure IP-aware bridge, NTP 106-2
ADSL profile C
configuration example, TNG 110-3
alarms CC-VLAN, NTP 104-2, TNG 100-2
creating snapshots, DLP 154-2 configure QoS-aware VLAN, DLP 135-2
fault isolation, TAP 104-1 create S-VLAN, DLP 118-1
managing, DLP 110-2 create SC-VLAN, DLP 119-2
monitoring, NTP 115-1, DLP 155-1 CLI session
troubleshooting, TAP 104-1 setting up, DLP 100-1
viewing alarm logs, DLP 110-2 cluster management, NTP 122-2
viewing current alarms, DLP 110-2 configure, DLP 169-2
viewing snapshots, DLP 154-2 configuration
7330 ISAM FTTN ES, TNG 111-1
7330 ISAM FTTN subtending, TNG 112-1
backing up, RTP 100-3
Alcatel 7302 ISAM R3.2 February 2007 IN-1

Index
CPE management — IP multicast
CPE management, NTP 121-2 identifying, TNG 106-1

configure, DLP 166-1 MAC address, TNG 106-1, TNG 106-3
cross-connect VLAN events
configuration example, TNG 110-12 fault isolation, TAP 104-1
troubleshooting, TAP 104-1
D expansion links
EDSE-A, TNG 106-3
database GENC-E, TNG 106-3
restore, RTP 101-1
DHCP Option 82, TNG 104-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-3
E
I
EDSE-A
expansion links, TNG 106-3 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 configuring IGMP proxy, DLP 137-1
repairing, NTP 114-1, TAP 102-1 parameters, TNG 102-2
replanning, DLP 111-2 system parameters
restarting, DLP 153-1 configuring, DLP 137-1
shutting down, DLP 153-1 viewing configuration, TNG 102-4
unplanning, DLP 111-2 IMA
equipment planning configure, DLP 183-1
configuration example, TNG 110-2 IP address
ES convert to dual IP address, DLP 184-1
CLI commands, TNG 106-1 convert to single IP address, DLP 184-1
configuration, TNG 111-1 IP address allocation, TNG 104-2
expansion link connections, TNG 106-3 IP multicast
configuration guidelines, TNG 102-4
IN-2 February 2007 Alcatel 7302 ISAM R3.2

Index
IP router — QoS
IP router OSFP
configure, NTP 107-2 configuring, DLP 107-2
IP-aware bridge
configure, NTP 106-2 P
IPoA
add cross-connect user, NTP 125-1 password
create cross-connect user, DLP 174-1 rules, DLP 101-1
create user, DLP 125-1 performance monitoring, NTP 118-1
IPoE commands, DLP 176-1
add user, NTP 112-1 ping, DLP 164-1, DLP 182-1
create user, DLP 126-1 planning equipment
IPProxy CPE configuration example, TNG 110-2
configure management, DLP 192-1 plug-in unit
configure session, DLP 194-1 locking, DLP 112-1
enable management, DLP 193-1 unlocking, DLP 112-1
IPProxy CPE management, NTP 128-2 plug-in units
configuring, NTP 103-1
L port
view configuration, DLP 197-1
L2CP view operational data, DLP 197-1
configure session, DLP 185-2 PPPoA-PPPoE relay
layer 2 termination, TNG 100-2 disabling, DLP 147-1
link aggregation enabling, DLP 147-1
configuring, DLP 105-2 PPPoE
local authentication add user, NTP 113-1
configuring, DLP 143-1 create user, DLP 127-1
enable PPPoE server, DLP 148-1
M PPPoE profile
configure, DLP 149-1
MAC address, TNG 106-3 PPPoE relay
MAC concentration disabling, DLP 146-2
configuration, DLP 186-2 enabling, DLP 146-2
MAC learning, TNG 100-5 PPPoE termination
multicast configure, NTP 109-1
configure on LT, DLP 136-1
configure on the SHub, DLP 198-1 Q
configuring, DLP 137-1
QoS
N configuring
L2, DLP 133-1
NT redundancy L3, DLP 134-1
configuring, DLP 114-2 QoS-aware VLAN, DLP 135-2
configuring on the SHub, DLP 199-1
O
operator
create default profile, DLP 172-1

Index
R — system parameter
R configure links, DLP 182-1

operational parameters
rack segment, TNG 108-19
configuring, DLP 113-1 span, TNG 108-14
RADIUS unit, TNG 108-18
configuring, DLP 144-1 shelf
operator authentication, DLP 181-1 configuring, DLP 113-1
remote expansion units, TNG 110-1 SHub
remote inventory dual tagging
retrieving information, RTP 102-1 enable, DLP 191-1
RIP managing the database, DLP 157-1
configuring, DLP 108-1 restarting, DLP 151-1
RSTP RSTP management, DLP 106-2
configuring, DLP 106-2 shutting down, DLP 151-1
SHub MAC filters, TNG 100-6
S software
management, NTP 116-1
S-VLAN
SSH, NTP 123-1
create, DLP 118-1
SC-VLAN
subrack
create, DLP 119-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 domain
system
creating, DLP 142-1
creating default domain, DLP 178-1
forwarding modes, TNG 100-2
SELT, TAP 103-1
IP address
SEM
configure single IP address,
CLI commands, TNG 106-1
DLP 175-1
expansion link connections, TNG 106-3
maintaining, NTP 124-1
identifying, TNG 106-1
modigy management IP parameters,
MAC address, TNG 106-1
DLP 168-1
planning, TNG 106-3
reboot modes, DLP 152-1
services
rebooting, DLP 152-1
adaptation, NTP 119-1
system description
SHDSL
system IP address
configuration parameters
configure dual IP address, DLP 102-1,
segment, TNG 108-13
DLP 102-1
span, TNG 108-3
system logging
unit, TNG 108-12
system parameter
modification, NTP 117-1

Index
T — xDSL profile
T Voice SIP
TCA VRF
configure, DLP 190-2 creating, DLP 121-1
traceroute, DLP 165-1 forwarding VRF, DLP 122-1
traffic router VRF, DLP 123-1
trap X
reporting modes, DLP 109-1 xDSL
troubleshooting create user, DLP 124-1
alarms, TAP 104-1 xDSL bonding group
events, TAP 104-1 create, DLP 130-2
troubleshooting commands, NTP 120-1 create profile, DLP 130-2
xDSL profile
U create, DLP 173-1
custom PSD points
unicast configuration, TNG 100-5 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
create xDSL user, DLP 124-1 VDSL2 virtual noise, DLP 189-2
creating and configuring, DLP 101-2
V
VDSL profile
verifying configuration, DLP 113-1
VLAN
add an LT to a VLAN, DLP 128-1
add network interfaces, DLP 121-1
configure iBridge VLAN, NTP 105-2,
NTP 127-1
configuring global parameters, DLP 187-1
creating, DLP 115-3, DLP 116-3
cross-connect VLAN configuration
example, TNG 110-12
iBridge VLAN configuration example,
TNG 110-11
modifying
external management VLAN,
DLP 162-1
subtending configuration for 7330 ISAM
FTTN, TNG 112-1

Index

Customer documentation and product support
Customer documentation
http://www.alcatel.com/osds/
Product manuals and documentation updates are available through the Alcatel Support
Documentation and Software Download service at Alcatel.com. If you are a new user and
require access to this service, please contact your Alcatel sales representative.
Technical support
http://www.alcatel.com/support/
Customer documentation feedback

documentation.feedback@alcatel.com
© 2007 Alcatel. All rights reserved.
3HH-04065-AAAA-TQZZA Edition 02 Released

o P e R A T I o N S A N D M A I N T e N A N C e U S I N G C L I PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

o P e R A T I o N S A N D M A I N T e N A N C e U S I N G C L I PDF

Uploaded by

Copyright:

Available Formats

Alcatel 7302

INTELLIGENT SERVICES ACCESS MANAGER | RELEASE 3.2

3HH-04065-AAAA-TQZZA Edition 02 Released

Copyright 2007 Alcatel.

Alcatel 7302 ISAM R3.2 February 2007 iii

Table 1 7302 ISAM documentation set

Title Description Part number

Warning — Warning indicates that the described activity or situation

iv February 2007 Alcatel 7302 ISAM R3.2

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.

Alcatel 7302 ISAM R3.2 February 2007 v

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.

vi February 2007 Alcatel 7302 ISAM R3.2

Index List (IXL)

IXL 100 —Master Task Index List IXL 100-1

Alcatel 7302 ISAM R3.2 February 2007 vii

Non-Trouble Procedures (NTP)

NTP 101 —Script files NTP 101-1

NTP 102 —System installation and configuration NTP 102-1

NTP 103 —Equipment configuration NTP 103-1

NTP 104 —Configuration of a cross-connect VLAN NTP 104-1

NTP 105 —Configuration of 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 —Service installation NTP 108-1

NTP 109 —Configuration of 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 —Equipment repair NTP 114-1

NTP 115 —Monitor alarms NTP 115-1

viii February 2007 Alcatel 7302 ISAM R3.2

NTP 116 —Software management NTP 116-1

NTP 117 —System parameter modification NTP 117-1

NTP 118 —Performance monitoring and configuration

NTP 119 —Service adaptation NTP 119-1

NTP 120 —Troubleshooting commands NTP 120-1

NTP 121 —SNMP proxy CPE management 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 —System logging management NTP 126-1

NTP 127 —SHDSL configuration NTP 127-1

NTP 128 —IPProxy CPE management NTP 128-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

Alcatel 7302 ISAM R3.2 February 2007 ix

DLP 102 —Configure dual IP address DLP 102-1

DLP 103 —Configure system parameters DLP 103-1

DLP 104 —Configure network interfaces DLP 104-1