3hh 03573 Aaaa Tqzza 01 Isam r2 5 System Description

Alcatel 7302 ISAM
INTELLIGENT SERVICES ACCESS MANAGER | RELEASE 2.5

SYSTEM DESCRIPTION
3HH-03573-AAAA-TQZZA Edition 01 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 2006 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).
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.
Prerequisite knowledge
The reader must be familiar with general telecommunications principles.
Safety information
For safety information, see the 7302 ISAM Safety Manual.
Alcatel 7302 ISAM R2.5 July 2006 iii

System Description 3HH-03573-AAAA-TQZZA Edition 01 Released
Preface
Documents
Table 1 lists the documents that make up the 7302 ISAM Release 2.5 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-03574-AAAA-TCZZA
System Description Provides conceptual information for the 7302 ISAM and the 3HH-03573-AAAA-TQZZA
7330 ISAM FTTN
Safety Manual Provides general safety guidelines when handling, installing, 3HH-03579-AAAA-TCZZA
or operating the 7302 ISAM equipment
Operations and Maintenance Provides task-oriented procedures for operating and 3HH-03580-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-03576-AAAA-TQZZA
Hardware documentation
Hardware Installation Guide Describes the hardware installation for the 7302 ISAM 3FE-21578-AAAA-RJZZA
equipment
CLI and TL1 documentation
CLI Commands Describes the CLI commands for the 7302 ISAM and the 3HH-03577-AAAA-TCZZA
7330 ISAM FTTN
TL1 Commands and Describes the TL1 commands and messages for the 3HH-03578-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
iv July 2006 Alcatel 7302 ISAM R2.5

Edition 01 Released 3HH-03573-AAAA-TQZZA System Description
Preface
Special information
The following are examples of how special information is presented in this
document.
Danger Danger indicates that the described activity or situation

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

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

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

interest.
Procedures with options or substeps

When there are options in a procedure, they are identified by letters. When there are
required substeps in a procedure, they are identified by Roman numerals.
Procedure 1 Example of options in a procedure
At step 1, you can choose option a or b. At step 2, you must do what the step indicates.
1 This step offers two options. You must choose one of the following:
a This is one option.
b This is another option.
2 You must perform this step.
Alcatel 7302 ISAM R2.5 July 2006 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 Systme international dunits
(SI) standard for abbreviation of metric units.
vi July 2006 Alcatel 7302 ISAM R2.5

Contents
Preface iii
Scope .............................................................................................................................. iii
Audience .............................................................................................................................. iii
Prerequisite knowledge ......................................................................................................... iii
Safety information.................................................................................................................. iii
Documents ............................................................................................................................ iv
Special information .................................................................................................................v
1 System interface overview 1-1

1.1 General .............................................................................................................. 1-2
1.2 Multi-ADSL......................................................................................................... 1-2
1.3 VDSL ................................................................................................................. 1-6
1.4 Configurable impulse noise protection............................................................... 1-9
1.5 Ethernet ........................................................................................................... 1-11
1.6 SHDSL............................................................................................................. 1-13
2 NT redundancy 2-1
2.1 Overview............................................................................................................ 2-2
2.2 Link-only protection............................................................................................ 2-2
2.3 NT-only protection ............................................................................................. 2-4
2.4 Combined link and NT protection ...................................................................... 2-4
2.5 Independent link and NT protection................................................................... 2-6
2.6 NT protection and passive link protection .......................................................... 2-9
2.7 Subtending system protection ......................................................................... 2-10
3 Management functions 3-1

3.1 Single IP address............................................................................................... 3-2
3.2 Cluster management (7302 ISAM only)............................................................. 3-2
Alcatel 7302 ISAM R2.5 July 2006 vii

Contents
3.3 CPE remote management ................................................................................. 3-4

3.4 License management ........................................................................................ 3-6
4 Layer 2 forwarding 4-1

4.1 VLAN forwarding modes.................................................................................... 4-2
4.2 Supported models in VLAN cross-connect mode .............................................. 4-7
4.3 Protocol-aware cross-connect mode ............................................................... 4-12
4.4 VLAN frame tagging ........................................................................................ 4-15
4.5 Port/protocol-based VLAN in iBridge mode ..................................................... 4-16
4.6 IPoA cross-connect mode................................................................................ 4-17
5 Layer 2 protocol handling 5-1

5.1 Introduction ........................................................................................................ 5-2
5.2 Link aggregation ................................................................................................ 5-3
5.3 RSTP ................................................................................................................. 5-4
5.4 ARP ................................................................................................................... 5-6
5.5 VBAS (7302 ISAM only) .................................................................................... 5-7
5.6 DHCP................................................................................................................. 5-8
5.7 IGMP................................................................................................................ 5-10
5.8 802.1x support ................................................................................................. 5-11
5.9 PPPoE ............................................................................................................. 5-12
6 Layer 3 forwarding 6-1

6.1 Network topology ............................................................................................... 6-2
6.2 Layer 3 forwarding modes ................................................................................. 6-3
6.3 Authentication/authorization/accounting ............................................................ 6-5
6.4 Service provider selection.................................................................................. 6-6
6.5 User IP address management ........................................................................... 6-6
7 Layer 3 protocol handling 7-1

7.1 Introduction ........................................................................................................ 7-2
7.2 RIP..................................................................................................................... 7-3
7.3 OSPF-2.............................................................................................................. 7-4
7.4 ARP ................................................................................................................... 7-7
7.5 PPPoE Termination ........................................................................................... 7-8
7.6 DHCP............................................................................................................... 7-11
7.7 IGMP................................................................................................................ 7-12
8 Security 8-1
8.1 IP address anti-spoofing .................................................................................... 8-2
8.2 Secured MAC learning....................................................................................... 8-2
8.3 Management channel security........................................................................... 8-4
8.4 Miscellaneous Security Features....................................................................... 8-9
viii July 2006 Alcatel 7302 ISAM R2.5

Contents
9 RADIUS 9-1
9.1 Introduction ........................................................................................................ 9-2
9.2 RADIUS Features .............................................................................................. 9-2
9.3 RADIUS server and proxy ................................................................................. 9-3
9.4 Operator authentication via RADIUS ................................................................. 9-5
9.5 Encryption of authentication data ...................................................................... 9-6
10 Multicast and IGMP 10-1

10.1 Overview.......................................................................................................... 10-2
10.2 IGMP on the NE............................................................................................... 10-6
10.3 Cross-VLAN and Intra-VLAN multicast .......................................................... 10-10
10.4 Multicast and IGMP parameters .................................................................... 10-12
10.5 Multicast on IPoA........................................................................................... 10-16
10.6 Pay per view .................................................................................................. 10-16
11 Quality of Service 11-1

11.1 Introduction ...................................................................................................... 11-2
11.2 Upstream QoS ................................................................................................. 11-3
11.3 Downstream QoS ............................................................................................ 11-4
11.4 Traffic classes.................................................................................................. 11-4
11.5 Queuing, scheduling, policing and BAC .......................................................... 11-5
11.6 QoS profiles ................................................................................................... 11-10
11.7 Policy framework ........................................................................................... 11-14
11.8 Subtending model.......................................................................................... 11-15
12 Statistics 12-1
12.1 Overview.......................................................................................................... 12-2
13 Inverse Multiplexing for ATM 13-1

13.1 General ............................................................................................................ 13-2
13.2 Interface arrangements.................................................................................... 13-3
14 Alarm management 14-1

14.1 Overview.......................................................................................................... 14-2
14.2 Alarm management ......................................................................................... 14-2
14.3 Programmable alarm filters.............................................................................. 14-5
15 Test features 15-1

15.1 Metallic Test Access ........................................................................................ 15-2
15.2 Single-ended line testing ................................................................................. 15-5
A. RADIUS Attributes A-1

App A.1 RADIUS Attributes ............................................................................................. A-2
App A.2 Vendor Specific RADIUS Attributes................................................................... A-3
Alcatel 7302 ISAM R2.5 July 2006 ix

Contents
Glossary
Index
x July 2006 Alcatel 7302 ISAM R2.5

1 System interface overview
1.1 General 1-2
1.2 Multi-ADSL 1-2
1.3 VDSL 1-6
1.4 Configurable impulse noise protection 1-9
1.5 Ethernet 1-11
1.6 SHDSL 1-13
Alcatel 7302 ISAM R2.5 July 2006 1-1

1.1 General
This chapter gives a general description of the system interfaces.

For a description of the 7302 ISAM or the 7330 ISAM FTTN high level system
architecture, refer to the:
7302 ISAM Product Information guide
7330 ISAM FTTN Product Information guide
1.2 Multi-ADSL
The Network Element (NE) supports multi-ADSL subscriber lines. This section
provides some explanation on the different supported ADSL flavours and ADSL
bonding.
Asymmetric Digital Subscriber Line (ADSL)

The ADSL system is used on existing metallic twisted-pairs (one per user) between
the Customer Premises Equipment (CPE) and a Central Office (CO) exchange.
A Frequency Division Multiplexing (FDM) technique allows the simultaneous use
of high-speed data services and the existing (lifeline) Plain Old Telephone Service
(POTS) or Integrated Services Digital Network (ISDN).
The advantages of ADSL are:
The existing cable network is used by the network operator (reducing costs).
The existing telephone service, including equipment, is retained by the customer.
Asymmetric nature of ADSL

The digital transmission capacity of the ADSL system is asymmetric in the sense that
the downstream and upstream bit rates are different:
The downstream bit rate can range from 32 kb/s up to 8 Mb/s. The bit rate
granularity is 32 kb/s.
The upstream bit rate can range from 32 kb/s to 1 Mb/s. The bit rate granularity
is 32 kb/s.
The chosen rate depends on the bi-directional services to be supported and the loop
characteristics.
This method allows high bandwidth services, for example, digital audio and video
(multimedia), Ethernet interconnection to the customer, and so on.
Bidirectional transport
With ADSL, the transport system provides bidirectional asymmetric communication
over a single or double twisted-pair without repeaters.
1-2 July 2006 Alcatel 7302 ISAM R2.5

ADSL services
The maximum physical bit rate is automatically determined during initialization of
the modem. Modem initialization is done using a predefined noise margin and within
the constraints of the transmit power spectral density. The service management
system then sets the line rate to the correct value. This is done according to the
customer service profile and maximizes the noise margin and/or minimizes the
transmission power. This allows various levels of service, for example, offering the
highest bit rates at a premium or ensuring a guaranteed bit rate. Bit rates can be
selected linearly, up to the maximum rate possible. Each individual user can have
different bit rates.
Operational modes
The following table lists the ADSL modes of operation that are supported by the
multi-ADSL boards
Table 1-1 ADSL modes of operation
Operation Mode Description
T1.413 Issue 2 ANSI standard (ADSL ansi)
DTS/TM-06006 ETSI standard (also called ETSI ISDN)
G.992.1 Annex A (Also known as G.DMT. Operation over POTS non-overlapped spectrum
G.992.1 Annex B Operation over ISDN non-overlapped spectrum
G.992.2 Annex A Also known as G.lite. Operation over POTS non-overlapped spectrum.
This standard is a medium bandwidth version of ADSL that allows Internet
access at up to 1.5 megabits downstream and up to 512 kilobits upstream.
ADSL2
A family of ADSL standards called ADSL2 adds features and functionality that
boost the performance, improve inter-operability, and support new applications,
services and deployment scenarios.
ADSL2 includes the following:
Better rate and reach
Improved modulation efficiency reduces framing overhead, achieves higher
coding gain, improves the initialization state machine, and provides enhanced
signal processing algorithms. ADSL2 increases downstream data rates to more
than 12 Mb/s, as compared to between 8 Mb/s and 10 Mb/s for original ADSL.
ADSL2 extends reach by approximately 183 m (600 ft).
Diagnostics
Real-time performance-monitoring capabilities provide information regarding
line quality and noise conditions at both ends of the line.
Fast startup
A fast start-up mode reduces initialization time from about 10 s to less than 3 s.
Packet-based services
Packet-based services such as Ethernet can be transported over ADSL2.

Note: The last two features are not supported in the Alcatel multi-ADSL cards
Operational modes
The following table lists the ADSL2 modes of operation that are supported by the
multi-ADSL boards
Table 1-2 ADSL2 modes of operation
G.992.3 Annex A Operation over POTS non-overlapped spectrum

G.992.3 Annex M Extended upstream operation (up to 3 Mb/s) over POTS non-overlapped
spectrum
ADSL2+
A number of applications, such as some video streams or combinations of video and
data streams, can benefit from higher downstream rates than are currently possible
with ADSL2. By increasing the ADSL downstream bandwidth, higher bit rates can
typically be provided on loops up to 2400 m or 8000 ft (on 26 AWG) through the use
of ADSL2+.
Operational modes
The following table lists the ADSL2+ modes of operation that are supported by the
multi-ADSL boards
Table 1-3 ADSL2+ modes of operation
G.992.5 Annex A Operation over POTS non-overlapped spectrum

G.992.5 Annex M Extended upstream operation (up to 3 Mb/s) over POTS non-overlapped
spectrum

Reach Extended ADSL2 (READSL2)

READSL2 (ADSL2 Annex L specification) proposes new Power Spectral Density
(PSD) masks that can result in a significant increase in ADSL reach.
Operational modes
The following table lists the READSL2 modes of operation that are supported by the
multi-ADSL boards
Table 1-4 READSL2 modes of operation
G.992.3 Annex L (WIDE) Operation over POTS non-overlapped spectrum,

Range-Extended Mode 1
G.992.3 Annex L (NARROW) Operation over POTS non-overlapped spectrum,

Range-Extended Mode 2
Multi-ADSL bonding
Multi-ADSL bonding allows traffic to be carried to and from a single logical
subscriber interface over multiple physical multi-ADSL lines. It offers the following
services:
increase the bandwidth to a subscriber for the same reach, for example, for adding
video to the service package
increase the loop length for a given required service bandwidth, for example, for
offering a same standard service package also to subscribers farther away from
the NE.
Multi-ADSL bonding supports the following main features:

compliance with the bonding standard ITU-T G.998.1 Asynchronous Transfer
Mode (ATM) - based Multi-Pair Bonding
pairs in a bonded group can operate in any of the enabled multi-ADSL modes
(ADSL, ADSL2, and so on)
continued support of multicast
the supported bit rate over a bonded group is the sum of the achieved bit rates on
each of the bonded pairs.
Note The bonded lines terminate on the same multi-ADSL

applique. There is no restriction on the number of bounding groups on
an applique.

1.3 VDSL
VDSL allows very high speed data transmission on a metallic twisted pair between
the operator network and the customer premise. This service is provisioned by using
the existing unshielded copper twisted pairs, without requiring repeaters. By using a
Frequency Division Multiplexing (FDM) technique, the existing POTS or BR ISDN
services can still be provided on the same wires. VDSL transceivers use Frequency
Division Duplexing (FDD) to separate upstream and downstream transmission.
VDSL1
However, VDSL provides subscribers with a higher bit rate than multi-ADSL and
can achieve speeds as high as 57 Mb/s downstream and 25 Mb/s upstream, compared
with 24 Mb/s downstream and 3 Mb/s upstream for multi-ADSL (annex M). The
maximum bit rates supported depend on deployment, noise environment, and
Ethernet system restrictions.
Operational modes
The following table lists the VDSL1 modes of operation that are supported by the
VDSL boards
Table 1-5 VDSL modes of operation
T1.424 ANSI standard (old trial use standard)(1)
TS 101 270-1/2 ETSI standard(1)
G.993.1 ITU-T standard
802.3ah IEEE standard (10PASS-TS or Ethernet First Mile (EFM) VDSL)
Notes
(1) Restriction: ANSI and ETSI modes cannot be enabled simultaneously. The ITU-T and IEEE modes
can be combined with any other mode.

VDSL2
The VDSL2 standard (G.993.2) is an enhancement to the ITU-T Recommendation
G.993.1 (VDSL1). It specifies DMT modulation and is based on ITU-T G.993.1
(VDSL1) and G.992.3 (ADSL2) Recommendations and uses also the G.994.1
handshake and initialization procedures.
VDSL2 Features
The main features of VDSL2 are:
VDSL2 is DMT only
VDSL2 offers packet transport (PTM) with 64/65B encapsulation:
also support of ATM and STM
64/65B framing is also referred to as Ethernet in First Mile (EFM)
no HDLC as in VDSL1
the definition of profiles supports a wide range of deployment scenario's:
deployment from the exchange (Fiber To The Exchange (FTTEx))
deployment from the cabinet (Fiber To The Cabinet (FTTCab))
deployment from the building (Fiber To the Building (FTTB))
VDSL2 extends the reach with regard to VDSL1.
Range is 2.5 km (0.4 mm) / 8 kft (26 AWG), compared to ~1.5 km (0.4 mm) /
4.5 kft (26 AWG) for VDSL1
VDSL2 supports higher bit rates than VDSL1.
Up to 100 Mb/ symmetrical. The attainable maximum data rate depends on the
used VDSL2 profile (100 Mb/s requires 30 MHz profile). Other profiles are better
suited for operation on longer loops with reduced maximum bit rate.
VDSL2 offers improved performance over VDSL1:
by addition of Trellis coding
Increased maximum allowable transmit power
VDSL2 features provide better support for triple play over VDSL
improved Impulse Noise Protection (INP)
virtual noise (optional)
VDSL2 has some ADSL2-like features:
similar: loop diagnostics
improved: PSD shaping
Improved management with regard to VDSL1

Operational modes
The following table lists the VDSL2 modes of operation that are supported by the
VDSL boards
Table 1-6 VDSL2 modes of operation
G.993.2 profile 8A ITU-T G.993.2 VDSL2 profile 8A
G.993.2 profile 8B ITU-T G.993.2 VDSL2 profile 8B
G.993.2 profile 8C ITU-T G.993.2 VDSL2 profile 8C
G.993.2 profile 8D ITU-T G.993.2 VDSL2 profile 8D
G.993.2 profile 12B ITU-T G.993.2 VDSL2 profile 12B

VDSL2 profile overview

VDSL2 profiles mainly define variants with different bandwidths and transmit
powers. The table below gives an overview of the different VDSL2 profiles.
Table 1-7 VDSL2 profile overview
VDSL2 profile
Parameter 8a 8b 8c 8d 12a 12b 17a 30a
Max. aggregate downstream 17.5 20.5 11.5 14.5 14.5 14.5 14.5 14.5
Tx power (dBm)
Max. aggregate upstream Tx 14.5 14.5 14.5 14.5 14.5 14.5 14.5 14.5
power (dBm)
US0 support M(1) M(1) M(1) M(1) M(1) O(1) O(1) O(1)
998 downstream upper 8.5 8.5 8.5 8.5 8.5 8.5 N/A N/A
frequency (MHz)
upstream upper 5.2 5.2 5.2 5.2 12 12 N/A N/A

frequency (MHz)
997 downstream upper 7.05 7.05 7.05 7.05 7.05 7.05 N/A N/A
frequency (MHz)
upstream upper 8.83 8.83 5.1 8.83 12 12 N/A N/A

frequency (MHz)
Notes
(1) M=Mandatory (required); O=Optional (not required)

1.4 Configurable impulse noise protection
Impulse Noise Protection (INP) is the ability to protect equipment against excessive
noise and vibrations, which cause signal degradation over xDSL lines. Configuring
INP provides the ability to configure the upstream and downstream minimum INP
parameters in the service profile. Minimum INP is specified in the G.992.3 (ADSL2)
and G.992.5 (ADSL2+) standards.
These standards include several provisions to reduce the number of errors that occur
due to impulse noise. The primary one is interleaving combined with forward error
correction (FEC) using Reed-Solomon (RS) error correcting codes.
Reed-Solomon
RS adds extra bits to the data packet when it is sent. When it is received, if the packet
is found to be corrupted, the decoder is able to use the extra bits to locate the error
and recover the original message.
Interleaving
Instead of transmitting the RS words directly on the line, a frame will be created of
the same size as the RS words and which is made up by multiple RS words by taking
only a portion of each of the original RS words. This has the advantage that when a
burst of errors occurs on the line and the original RS words are recreated on the
receiving side, the errors will be spread over multiple RS words.
This way, the errors within a single RS word can be corrected if the number of errors
are within the RS correction boundaries.
The main disadvantage of interleaving is the high delay. Constructing the blocs that
will finally be transmitted over the line takes time as you have to wait for a time
before you can actually start transmitting.
At the receiving side, it will also cost extra time to reconstruct the original RS word.
The first original RS word cannot be reconstructed before we have received all the
bytes of this first RS word.
Interleaving can be sped up by using different depths, that is, by taking bigger chunks
of the original RS words. This way, the first bloc for transmission can be constructed
much quicker. This has the disadvantage that errors will be spread over less RS
words on the receiving side with the possibility that they cannot be corrected.
INP calculation
The formula below can be used to calculate the INP.
Figure 1-1 INP formula
R SxD
INP = 0,5x(SxD)x = delay (ms)
N 4

where:
S = the number of Discrete Multi-Tone (DMT) symbols per RS word
D = the interleaving depth (number of combined RS words used)
N = the number of bytes per word (1..255 bytes)
R = the number of RS overhead bytes (0..16 bytes)
This INP formula expresses the length of protection in terms of DMT symbols
instead of in number of bytes. For example, an INP=1 DMT symbol, means that the
system will be able to correct a burst of errored bytes with a length corresponding to
the total number of bytes contained in 1 DMT symbol. The reason for expressing in
DMT symbols, lies in the fact that most impulse noises have lengths smaller than a
DMT symbol.
However, because of its potential high level, it will error potentially all bytes in the
specific DMT symbol. Because of the independence between DMT symbols, it will
not affect the next DMT symbol.
If the burst protection would have been expressed in bytes, different settings of
protection would have been required for changing datarates.
Conclusion
Configurable INP offers the operator direct control over:
the minimum INP of the xDSL line and, therefore, on the robustness of the line
for impulse noise
the maximum interleaving delay
Configuration
The configuration consists of:
characterizing the impulse noise on a line
setting the interleave depth to an optimal level for a particular region or even a
particular customer
The upstream and downstream minimum INP parameters can be configured in the
xDSL service profile (refer to the Operations and Maintenance Using CLI guide).
Practical
In practice, it has been noted that configuring INP=2 with a MaxDelay=8ms gives
good INP, reasonable low MaxDelay with high performance and reasonable
efficiency.
INP support
The configurable INP is supported on all multi-ADSL, VDSL and VDSL2 units.

1.5 Ethernet
The NE supports Fast Ethernet (FE) and Gigabit Ethernet (GE) uplinks through the
NT board on the network termination side of the NE, as well as for user and
subtending nodes. The 7330 ISAM FTTN ARAM-D NE supports additional optical
uplinks through the expander unit, as well as optical expansion links (downlinks).
Supported Ethernet Flavours

Table 1-8 describes the Ethernet flavours supported by the NE.
Table 1-8 Supported FE types
Name Type Description
100Base-TX Electrical 100 Mbps baseband Ethernet over two pairs of shielded
twisted pair or Category 4 twisted pair cable
1000Base-SX Optical 1000 Mbps baseband Ethernet over two multimode optical
fibers using shortwave laser optics (850 nm).
1000Base-LX Optical 1000 Mbps baseband Ethernet over two multimode or

single-mode optical fibers using longwave laser optics (1310
nm.
1000Base-EX Optical Duplex single mode fibers for longer wavelength (1310 nm)
1000Base-ZX Optical Same as 1000Base-EX but for extended distances (1550
nm)
1000Base-T Electrical 1000 Mbps baseband Ethernet over four pairs of Category 5
unshielded twisted pair cable.
1000Base-YX-CWDM Optical Multi-rate fiber for eight different wavelengths
1000Base-BX10-D Optical Bidirectional point-to-point Ethernet over single fiber

transmitting 1490 nm downstream and receiving 1310 nm
signals.
1000Base-BX10-U Optical Bidirectional point-to-point Ethernet over single fiber

transmitting 1310 nm upstream and receiving 1490 nm
signals.
Half and full duplex mode

Ethernet can operate in two modes:
Half duplex: In half duplex mode, a station can only send or receive at one time.
Full duplex: In full duplex mode, send and receive channels are separated on the
link so that a station can send and receive simultaneously.
The NE supports both modes and can adapt to either mode by way of
auto-negotiation or manual configuration.

Auto-negotiation
Auto-negotiation provides the capability for a device at one end of the link segment
to advertise its abilities to the device at the other end (its link partner), to detect
information defining the abilities of the link partner, and to determine if the two
devices are compatible. Auto-negotiation provides hands-free configuration of the
two attached devices.
Using auto-negotiation, the NE can determine the operational mode (full/half
duplex) and speed to be applied to the link.
Note 1 It is also possible to manually configure the transmission
mode and speed on the link.
Note 2 Auto-negotiation is supported for both optical and
electrical GE.
Advantages
Ethernet offers the following advantages:
high network reliability
general availability of management and troubleshooting tools
scalable to fit future needs
low cost both in purchase and support
easy migration from Ethernet or FE to GE
flexible internet working and network design

1.6 SHDSL
The Single-pair High-speed Digital Subscriber Line (SHDSL) technology is a

physical layer standard based on the ITU-T Recommendation G.991.2 (G.shdsl).
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 can be used for
extended reach. The use of signal regenerators for both the two-wire and multi-wire
operations is optional.
Multiple SHDSL circuits may be combined to support higher bandwidth using
Inverse Multiplexing for ATM (IMA) interface or the payload can be shared by
multiple circuits (using the M-pair mode). IMA and M-pair do not work
simultaneously over the same port/circuit. Generally, an SHDSL LT in the NE can
support ATM or IMA, or IEEE 802.3ah EFM in per port basis.
SHDSL transceivers are capable of supporting selected symmetric user data rates
ranging from 192 bit/s to 2312kbit/s, and optional up to 5696kbit/s, using Trellis
Coded Pulse Amplitude Modulation (TCPAM) line code. They are designed to be
spectrally compatible with other transmission technologies deployed in the access
network, including other DSL technologies.
SHDSL transceivers do not support the use of analogue splitting technology for
coexistence with either POTS or ISDN. However, POTS transport can be supported
by means of either VoDSL or channelized VoDSL.
Supported standards
The following table lists the standards that are supported by the SHDSL boards
Table 1-9 SHDSL standards
Standards Description
G.991.2 Annex A and Annex F Standards applicable for North America (region 1) (ANSI)
G.991.2 Annex B and Annex G Standards applicable for Europe (region 2) (ETSI)
Payload rates
The following payload rates are supported:
192 to 2304 kb/s in 64 kb/s steps for Annex A/B
192 to 5696 kb/s in 64 kb/s steps for Annex F/G


2 NT redundancy
2.1 Overview 2-2
2.2 Link-only protection 2-2
2.3 NT-only protection 2-4
2.4 Combined link and NT protection 2-4
2.5 Independent link and NT protection 2-6
2.6 NT protection and passive link protection 2-9
2.7 Subtending system protection 2-10

2 NT redundancy
2.1 Overview
Network Termination (NT) redundancy is the availability of an NT port to carry

additional traffic in the event of problems with one or more other NT ports or links,
or the installation of more than one NT unit so that the second NT unit can carry
traffic in case of problems with the first NT unit.
The NE supports NT redundancy in the form of link and equipment redundancy on
the external links when two NT units are installed. For link redundancy, you can
configure the NE to protect the physical links. For equipment redundancy, you can
configure the NE to reduce the time required to repair malfunctioning parts of the
NE. In cases where both link and equipment redundancy requirements are needed,
you can use the Automatic Protection Switching (APS)/Equipment Protection
Switching (EPS) combined configuration option. This solution involves a full
switchover of the links and equipment to the network. In cases where links and
equipment are decoupled, a single NT I/O unit is used.
Protection schemes that require a NT-IO are not supported on the ARAM-B since
this equipment practice does not support a NTIO card.
This chapter describes the following configuration options for NT redundancy:
link-only protection
NT-only protection
combined link and NT protection
independent link and NT protection
NT protection and passive link protection
subtending system protection
The NE supports line protection and EPS. If a second redundant NT unit is installed
in the shelf, EPS provides protection against internal failure of the active NT unit.
2.2 Link-only protection
All possible uplinks of the NE can be used in active/standby mode on one NT unit
installed in the NE. In case an active link fails, traffic will be fully switched to the
standby link; see Figure 2-1.

2 NT redundancy
Figure 2-1 Link protection with active/standby uplink
NT
PHY
Active
L2-L3 PHY
PHY
Standby
17854
A set of N (1<=N<=3) physical network interfaces that are used in load-sharing

mode (link aggregation) also support link protection. If one of the network interfaces
fails, the traffic is switched to the remaining network interfaces; see Figure 2-2.
Figure 2-2 Link protection with load-sharing uplinks
NT
PHY
L2-L3 PHY
PHY
17855
Note This link-only protection model does not protect equipment.

If the NT unit fails, all the links will be lost.
If an uplink for a single NT with multiple uplinks in a load-sharing group is lost, the
traffic is redistributed across the remaining links of the load-sharing group, by means
of the Link Aggregation Control Protocol (LACP).
If an active uplink for a single NT with dual uplinks in active/standby mode is lost,
the traffic is switched to the standby uplink, by means of the Rapid Spanning Tree
Protocol (RSTP).

2 NT redundancy
2.3 NT-only protection
NT-only protection is available with:

a single uplink with NT protection through the NT I/O
a single uplink with NT protection through a passive fiber splitter (7302 ISAM
only)
NT protection is available for two NT units with a single uplink connected through
an NT I/O to the active NT. In case of failure of the active NT, the NT I/O
automatically reconnects the single uplink to the appropriate switch fabric port of the
standby NT.
NT protection is available for two NT units with a single uplink connected through
a passive optical splitter to the active NT. The passive optical splitter interconnects
the single fiber with an optical interface directly on the NT units. The NT protection
switching is executed by a laser disable logic that is activated on the standby NT unit.
The laser disable logic prevents the standby NT from disturbing uplink transmission
from the active NT unit on the shared fiber. This configuration is not possible for
electrical uplink connections.
2.4 Combined link and NT protection
When using two NT units without the NT I/O, all links connected to the active NT
unit will be in the active state; see Figure 2-3. These links can either be individual
links or load-sharing groups. The standby NT unit has the same number and
configuration of links as the active NT unit.
In the event of link failure (the number of available links falls below the threshold
value of available links) or NT failure (active NT unit failure), all connections will
simultaneously switch over to the active NT unit.

2 NT redundancy
Figure 2-3 Combined link and NT protection with active/standby uplink interfaces
NT-A
PHY
L2-L3 PHY
Active
PHY
NT-B
PHY
L2-L3 PHY
PHY
Standby
17853
It is also possible to use the physical network interfaces on the active NT unit in
active/standby mode; see Figure 2-4. In this way the active NT unit has link
protection. In case the active NT unit fails, link protection and equipment protection
become coupled.

2 NT redundancy
Figure 2-4 Combined link and NT protection each with active/standby uplink interfaces
NT-A
PHY
Active
L2-L3 PHY
PHY
Standby
NT-B
PHY
L2-L3 PHY
PHY
17852
2.5 Independent link and NT protection
To perform an independent switchover of the NT protection and uplink protection

according to the location of the fault, a single NT I/O unit is required. This
configuration option is only supported on the 7330 ISAM FTTN ARAM-D and the
7302 ISAM. The alarm control and host expansion interface unit provides the NT I/O
functionality. Only the four links connected to the alarm control and host expansion
interface unit can work in this mode.
When only one network interface is physically connected to the two equipped NT
units by way of the alarm control and host expansion interface unit, and logically
connected to the active NT unit, only NT protection is supported; see Figure 2-5.

2 NT redundancy
Figure 2-5 Decoupled link and NT protection using the alarm control and host
expansion interface unit with single active uplink
NT-A
PHY
L2-L3 PHY
PHY
NTIO
Active
PHY
PHY
PHY
PHY
NT-B
PHY
L2-L3 PHY
PHY
17849
When two physical network interfaces are used in active/standby mode, each
connected physically to two equipped NT units by way of the alarm control and host
expansion interface unit, and logically connected to the active NT unit, both link and
NT protection are supported; see Figure 2-6.

2 NT redundancy
expansion interface unit and dual active/standby uplinks
NT-A
PHY
L2-L3 PHY
PHY
NTIO
Active
PHY
PHY
Standby
PHY
PHY
NT-B
PHY
L2-L3 PHY
PHY
17850
A set of N (1<=N<=3) physical network interfaces (load-sharing mode) used in

active/standby mode are connected physically to the two equipped NT units by way
of the alarm control and host expansion interface unit, and logically connected to the
active NT unit; see Figure 2-7. Both link and NT protection are supported.

2 NT redundancy
expansion interface unit and dual load-sharing links
NT-A
PHY
L2-L3 PHY
PHY
NTIO
Active
PHY
PHY
PHY
PHY
NT-B
PHY
L2-L3 PHY
PHY
Standby
17851
The system provides protection for dual NT units with a load-sharing link group that
are connected through an NT I/O to the active NT. In case of accumulated excessive
link group capacity loss, the active NT will switch over traffic to the standby NT.
Dual NT units, active and standby links or load-sharing link groups, connected
through an NT I/O to the active NT, with RSTP enabled.
The system provides protection for dual NT units with a load-sharing link group that
are connected through passive optical splitters to the active NT. The passive optical
splitters interconnect the corresponding fibers of the load-sharing group with optical
interfaces directly on the NT units.
2.6 NT protection and passive link protection
In order to have decoupled equipment and link protection for active/standby uplink
groups (load-sharing mode) without the alarm control and host expansion interface
unit, the N physical network interfaces must each be physically connected to the two
equipped NT units by way of a passive physical layer splitter and logically connected
to the active NT unit; see Figure 2-8.

2 NT redundancy
Figure 2-8 NT protection and passive link protection
NT-A
Active
PHY
L2-L3 PHY
PHY
NT-B
PHY
L2-L3 PHY Standby
PHY
17856
2.7 Subtending system protection
It is possible to cascade multiple single-shelf NE systems using standard Ethernet

subtending links. Collocated NE shelves can be connected together using electrical
intra-office Ethernet links to provide a consolidated optical Ethernet interface to the
network.
The NE supports the following cascading topologies:
daisy-chain topology; see Figure 2-9
star topology; see Figure 2-10
ring topology; see Figure 2-11
Up to three levels of cascading are supported. The last NE in the cascaded system
can be any DSLAM, such as:
a 7302 ISAM
a 7300 ASAM with a FENT
a 7325 Remote Unit
a 7330 ISAM FTTN

2 NT redundancy
Figure 2-9 Example of a NE daisy-chain topology
NT-A
PHY
L2-L3 PHY NTIO
PHY
PHY
PHY
PHY
PHY
NT-B
PHY
L2-L3 PHY
PHY NT-A
PHY
NT-A L2-L3 PHY NTIO Uplink
PHY
PHY PHY
L2-L3 PHY NTIO
PHY PHY
GE PHY
GE PHY
NT-B
GE
PHY
GE PHY
NT-B L2-L3
PHY
PHY
L2-L3 PHY
PHY
NT-A
PHY
L2-L3 PHY NTIO
PHY
PHY
PHY
PHY
PHY
NT-B
PHY
L2-L3 PHY
PHY
17977

2 NT redundancy
Figure 2-10 Example of a NE star topology
NT-A
PHY
L2-L3 PHY NTIO
PHY
PHY
PHY
PHY
PHY
NT-B
PHY
L2-L3 PHY
PHY NT-A
PHY
NT-A L2-L3 PHY NTIO Uplink
PHY
PHY PHY
L2-L3 PHY NTIO
PHY PHY
GE PHY
GE PHY
NT-B
GE
PHY
GE PHY
NT-B L2-L3
PHY
PHY
L2-L3 PHY
PHY
NT-A
PHY
L2-L3 PHY NTIO
PHY
PHY
PHY
PHY
PHY
NT-B
PHY
L2-L3 PHY
PHY
17970

2 NT redundancy
Figure 2-11 Example of a NE ring topology
NT-A
PHY
L2-L3 PHY NTIO
PHY
PHY
PHY
PHY
PHY
NT-B
PHY
L2-L3 PHY
PHY NT-A
PHY
NT-B L2-L3 PHY NTIO Uplink
PHY
PHY PHY
L2-L3 PHY NTIO
PHY PHY
GE PHY
GE PHY
NT-B
GE
PHY
GE PHY
NT-A L2-L3
PHY
PHY
L2-L3 PHY
PHY
NT-A
PHY
L2-L3 PHY NTIO
PHY
PHY
PHY
PHY
PHY
NT-B
PHY
L2-L3 PHY
PHY
17971

2 NT redundancy

3 Management functions
3.1 Single IP address 3-2
3.2 Cluster management (7302 ISAM only) 3-2
3.3 CPE remote management 3-4
3.4 License management 3-6

3.1 Single IP address
There is a single IP address to manage both the Intelligent Access termination,

Control and Management (IACM) and SHub subsystem. All direct management
access to the SHub subsystem is closed, which increases the security of the
management channels to the NE.
Note In case no single IP address is used, the SHub can be
configured directly via SNMP. As the SHub does not support
SNMPv3, this introduces a vulnerability in the system in case the
management interfaces on the NT are secured via SNMPv3 or SSH.
3.2 Cluster management (7302 ISAM only)
With massive deployment of xDSL, many more Digital Subscriber Line Access
Multiplexers (DSLAMs) are provisioned in the network. They are mostly managed
separately, which makes the management load heavy and complicated. To simplify
the management load 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 Internet Protocol (IP) addresses, which are limited, especially in China.
The objective of cluster management is to manage a group of DSLAMs through one
entry as a single DSLAM by one IP address.
Figure 3-1 shows a cluster management topology.
Figure 3-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 No.6
DSLAM No.3 No.4 No.5
No.11

Cluster management in the NE is implemented as follows:

Each node of a cluster still keeps its public IP address.
The Alcatel WorkStation (AWS) manages each node independently by way of its
public IP address, but offers the possibility to the operator to define "clusters" at
the AWS Graphical User Interface (GUI) level, and give commands that are valid
for the complete "cluster" (profile management, backup and restore, software
management, alarm management). AWS then executes the commands
sequentially to each DSLAM of the cluster.
AWS supports topology management of a cluster (defining command and backup
node, member nodes) and cluster topology collection.
AWS supports topology display, which is made possible by a topology collection
process in the 7302 ISAM. For this topology collection, the 7302 ISAM supports
the "neighbour discovery" and "topology collection" protocols as defined in the
China Communications Standards Organization (CCSA) cluster management
standard.
AWS defines for each cluster a command and a backup node. Both command and
backup node will do topology collection for the cluster. AWS retrieves the
collected cluster topology from the command node. If the command node fails,
AWS retrieves topology information from the backup node.
A neighbour-discovery protocol and a topology collection protocol are defined as
Ethernet messages with a specific Ethertype.
The neighbour-discovery protocol is supported in each node of the cluster. It
sends neighbour-discovery packets (with information of its own node) on each of
its up- and subtending links in a regular time-interval (default 60 s). Through
these packets, each 7302 ISAM 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 7302 ISAM (in this
case, the AWS is trapped by the 7302 ISAM if the topology is changed), or the
operator on AWS can start a manual topology collection request. The 7302 ISAM
sends topology request messages on all the links to its neighbours learned through
neighbour discovery. Each neighbour answers with a topology reply containing
info on its directly connected environment. Each neighbour also forwards the
original topology request on its other links, and the second level neighbours will
answer with topology response messages directly to the command node using the
command nodes MAC address.
With the information received in the topology response messages, the command
and backup 7302 ISAMs are able to construct tables giving the complete
topology of a cluster (including the MAC and IP address of each node).

3.3 CPE remote management
The function of Customer Premises Equipment (CPE) remote management includes

configuration, monitoring, maintenance and upgrade of the xDSL CPE.
Figure 3-2 shows the network reference model.
Figure 3-2 Network Reference Model
Network Management Entity
CPE-MM
RMI
User Management Entity
NE ADSL CPE
LMI
The CPE Management Machine (CPE-MM) is responsible for the management of

the CPE. The following interfaces are defined:
Line Management Interface (LMI)
This is the interface between the NE and the CPE. The LMI is defined by the
CCSA CPE remote management specification.
Remote Management Interface (RMI)
This is the interface between the CPE-MM and the NE. The specification of this
interface has to be defined by the customer. Alcatel offers a CPE-MM
implementation on its Residential Network Manager (RNM) platform.

CPE remote management features
Configuration management features

CPE remote management has the following configuration management features:
Permanent Virtual Connection (PVC) and encapsulation
configuration of the Virtual Path Identifier (VPI)/Virtual Channel Identifier (VCI)
value of the service PVC
configuration of the ATM Adaption Layer (AAL) parameters of the service PVC
configuration of the encapsulation parameters of the service PVC
IP layer configuration
configuration of the IP address, subnet and gateway of the Wide Area Network
(WAN) side of the CPE
enable/disable of the DHCP function of the WAN side of the CPE
enable/disable of the Network Address Translation (NAT) function of the WAN
side of the CPE
configuration of the IP address of the Domain Name Server (DNS) of the CPE
Management of configuration
auto-configuration
restoration of the CPE default parameters
batch configuration
on-line and off-line configuration
Diagnosis features
CPE remote management has the following diagnosis features:
CPE parameters
retrieval of CPE information
reset and restart of the CPE
Diagnosis testing
PPPoE testing
connectivity testing
bandwidth testing
Software upgrade features

The software/firmware of the CPE can be upgraded by way of File Transfer Protocol
(FTP).

3.4 License management
The NE supports licensing counters. Using 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.
The licensing counters can be retrieved by a manager for monitoring. The following
features are monitored in NE:
ADSL2+
READSL2
ADSL2/ADSL2+ Annex M
IGMP
IP Aware Bridge
PPPoA to PPPoE Relay
PPPoE Termination (7302 ISAM only)
802.1X
Other features are monitored by way of existing Management Information Bases

(MIBs), as 1+1 redundancy which is licensed but monitored using the Equipment
MIB.

4 Layer 2 forwarding
4.1 VLAN forwarding modes 4-2
4.2 Supported models in VLAN cross-connect mode 4-7
4.3 Protocol-aware cross-connect mode 4-12
4.4 VLAN frame tagging 4-15
4.5 Port/protocol-based VLAN in iBridge mode 4-16
4.6 IPoA cross-connect mode 4-17

4.1 VLAN forwarding modes
The internal forwarding of the NE is done on layer 2 information. Layer 2 for the NE
is Ethernet, which includes the concept of Virtual Local Area Networks (VLANs).
The standard for VLANs is Institute of Electrical and Electronics Engineers (IEEE)
802.1q.
Generally, VLANs can be seen as analogous to a group of end-stations, perhaps on
multiple physical LAN segments, that are not constrained by their physical location
and can communicate as if they were on a common Local Area Network (LAN).
Figure 4-1 shows an example of VLANs.
Figure 4-1 Example of VLAN
ne 9 VLAN A
bo tch
8
ck i 7
Ba
6
Sw 5
4
2
3
VLAN B
1
9
h 8
itc 7
Sw 6 VLAN C
5
4
3
2
1
The VLANs used by the NE are configured statically by the operator (or
automatically under 802.1x control) and the NE ports are associated by configuration
to these VLANs. This means that the NE ports are not automatically removed after
some time, but must be explicitly removed from a VLAN by the operator.
Two forwarding modes are supported. Each can be manually configured per VLAN.
intelligent bridging (iBridge) mode, also known as residential bridging mode
VLAN cross-connect mode

VLAN cross-connect mode

In VLAN cross-connect mode, one VLAN contains only one user port. Figure 4-2
shows the concept of VLAN cross-connect mode:
In the upstream direction, the incoming user port is sufficient for the NE to
identify the VLAN tag. This VLAN is the port-based default VLAN configured
for this user port. To identify the outgoing upstream port the MAC Destination
Address (DA) is required. If the MAC DA is not yet learned, the frame will be
flooded.
In the downstream direction, only the VLAN (without the MAC DA) is sufficient
for the NE to identify the outgoing user port.
For more information about MAC addresses, refer to the chapter Security.
Figure 4-2 VLAN Cross-connect mode
Usage
A particular VLAN ID can be configured only once:
on any of the user ports in the NE
over all NEs in the complete Ethernet network to which the NE is connected
VLAN stacking allows the user to use the same ID for multiple VLANs (see
section 4.2). But if VLAN stacking is not used, the VLAN cross-connect mode
should only be used in small networks, where the NE is directly connected to the IP
Edge router or Broadband Remote Access Server (BRAS) of a Network Service
Provider (NSP), or for business customers.

Properties
Because there is only one single user, a VLAN in cross-connect mode also has the
two basic properties that differentiate iBridging from standard bridging:
no user-to-user communication is possible in the NE
prevention of broadcast storms.
Supported models
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
Quality of Service (QoS)-aware VLAN cross-connect: VLAN + p-bits
cross-connect.
These models are described in section 4.2.
iBridge mode
The concept of 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.
Figure 4-3 shows the concept of the iBridge mode. The NE supports up to 128
iBridges.
Figure 4-3 iBridge mode

NSP 1
NSP IP backbone
EMAN
A NSP 1-VLAN
B
NSP1 NSP 2
C
NSP 2-VLAN NSP IP backbone
D NSP2
E NSP3
F NSP 3-VLAN
NSP 3
G
NSP IP backbone
iBridge VLANs support the snooping features DHCP Option 82 (refer to chapter
Layer 3 Protocols and IGMP (refer to chapter Multicast and IGMP).
The NE supports two VLAN classification modes in iBridge mode:
port-based VLAN
port/protocol based VLAN

For more information about these VLAN classification modes, refer to section
Port/protocol-based VLAN in iBridge mode.
Multiple user ports associated to a VLAN

In iBridge mode, multiple user ports can be associated to a single VLAN. In
Figure 4-3, the following user ports are connected to the different VLANs:
NSP 1-VLAN: user ports A, B and C
NSP 2-VLAN: user ports D and E
NSP 3-VLAN: user ports F and G
When a user generates a frame or a frame is received from the upstream Ethernet
switch, a MAC address lookup is done in the forwarding table identified by the
VLAN. Each NSP has its own forwarding table in the NE.
Network and user ports

The iBridge mode makes a distinction between network ports and user ports, in
contrast with standard bridging where all ports are treated equally. Frames received
from a user will always be sent towards the network and never to another user.
Prevention of broadcast problems

To prevent broadcast storms, the amount of broadcast traffic on each port can be
limited.
When standard bridging is used, a broadcast frame (ARP, PPPoE, DHCP) will be
sent to all ports in a particular VLAN. In iBridge mode, broadcast from the user only
goes to the network. Broadcast from the network is either passed to all ports or
blocked on the user ports. This behaviour can be configured per VLAN.
Also broadcast as a consequence of flooding, which happens in case of standard
bridging when the MAC DA is unknown or in case of multicast, is avoided in iBridge
mode.
MAC address learning

In iBridge mode, the MAC addresses are learned in a different way than in standard
bridging. A protection is built in to prevent the use of one specific MAC address by
multiple ports in one particular VLAN.
For more information about MAC address learning, refer to the chapter Security.

Frame types
In iBridge mode, only the following frame types are accepted from the user ports:
IP over Ethernet (IPoE) (IPv4)/ARP/Reverse Address Resolution Protocol
(RARP)
PPPoE (discovery & session)
IPoE (IPv4)/ARP/RARP/PPPoE (discovery & session)
all ethernet types
Extensible Authentication Protocol Over LAN (EAPOL)
EAPOL frames are dedicated packets that are never forwarded but are processed
by the NE.
Other frames, including multicast data frames, will be discarded.
NE/NSP IP router relationship

To support iBridge mode, two NEs (IP-DSLAMs) can not be within the same VLAN
if they are connected to the same Ethernet Metropolitan Area Network (EMAN)
network (same NSP IP router). So a VLAN must be unique between an NE and an
NSP IP router.
Figure 4-4 shows a single VLAN between NE 1, NE 2, and the NSP IP router:
The Ethernet switch will learn all user MAC addresses and if user A can obtain
the MAC address of user C, then user A can send traffic directly to user C without
the traffic going to the NSP IP router. This is direct user-to-user communication
and is not allowed in iBridge.
In such a configuration, an NE would receive all broadcast/flooded frames from
any NE in the VLAN. This causes potential performance problems and is not
allowed in iBridge mode.
Figure 4-4 VLAN with two NEs
NE 1
NE 2

4.2 Supported models in VLAN cross-connect mode
About VLAN stacking

VLAN-stacking introduces another VLAN-layer. One outer VLAN can bundle a
number of inner VLANs, similar to one LAN bundling a number of VLANs. This
way, one VLAN, called the Service-VLAN or S-VLAN, bundles a number of
smaller VLANs, called Customer-VLANs or C-VLANs. Traffic in this S-VLAN
may, on its turn, be bridged according to a forwarding context proprietary to the
S-VLAN. This is done in S-VLAN-aware bridges.
Figure 4-5 shows the protocol stack for S- and C-VLANs and the function of the
different bridge types. C-VLANs can be carried up to the end user (hence the C).
S-VLANs can be used to transparently convey traffic to specific large business
customers with their proprietary VLAN-organization, or to group a set of residential
users to a single service provider (hence the S).
Figure 4-5 S-VLAN- and C-VLAN-aware bridges

VLAN-unaware C-VLAN-aware S-VLAN-aware S-VLAN-aware C-VLAN-aware
terminal bridge bridge bridge terminal
C-VLAN
termination
anything S-VLAN S-VLAN anything
Bridging termination termination
Eth C-VLAN C-VLAN C-VLAN
Bridging Bridging
Eth Eth S-VLAN S-VLAN S-VLAN S-VLAN
Eth
Eth Eth Eth Eth
Basic VLAN cross-connect: C-VLAN cross-connect

C-VLAN cross-connect is the most straightforward VLAN cross-connect model,
where a single VLAN ID at the EMAN side is associated with a given PVC or
Ethernet over the First Mile (EFM) interface at the user side. Any kind of traffic
issued by the subscriber is forwarded transparently to the network using the selected
VLAN ID.
Figure 4-6 shows the C-VLAN cross-connect model.

Figure 4-6 C-VLAN cross-connect

C-VLAN to
PVC/EFM
crossconnects CPE(s)
NE
EMAN
PVC or EFM interface
CVLANs
Figure 4-7 shows the NE acting as a basic C-VLAN cross-connect bridge.
Figure 4-7 NE as a basic C-VLAN cross-connect bridge
C-VLAN cross-connect
EFM/Ethernet
Ethernet or
ATM/AAL5/Bridged_encaps/Ethernet
Network port Access port
C-VLAN tagged/
C-VLAN tagged untagged/priority
tagged
VLAN stacking for business users: S-VLAN cross-connect

In S-VLAN cross-connect mode, two levels of VLAN tags are used, supporting
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 PVC or
EFM 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.
Figure 4-8 S-VLAN cross-connect

S-VLAN to
PVC/EFM
CPE
EMAN NE cross-connect
S-VLAN PVC
C-VLANs

The NE acts as an S-VLAN-aware bridge, with the restriction that only one
subscriber interface can be attached; see Figure 4-9. 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 not have an S-VLAN tag. The
subscriber interfaces pre-configured S-VLAN ID will be assigned.
Figure 4-9 NE as a S-VLAN-aware bridge

S-VLAN cross-connect
EFM/Ethernet
Ethernet or
ATM/AAL5/Bridged_encaps/Ethernet
C-VLAN tagged/
S-VLAN tagged untagged/priority
tagged
VLAN stacking for residential users: S-VLAN/C-VLAN cross-connect

The basic VLAN cross-connect mode suffers from the fact that the number of VLAN
identifiers is limited to 4 K. Since the VLAN is an EMAN wide identifier, there is 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), theoretically reaching up to
16 M end users.
Figure 4-10 shows the NE in S-VLAN/C-VLAN cross-connect mode.
Figure 4-10 S-VLAN/C-VLAN cross-connect
C-VLAN to
PVC/EFM
EMAN NE cross-connects CPE(s)
S-VLAN PVCs
C-VLANs
The NE acts as a C-VLAN-aware bridge (Figure 4-11), with the restriction that only
one subscriber interface can be attached. Frames on the subscriber interface may be
C-VLAN tagged or untagged/priority tagged. In case of C-VLAN tagged frames, a
check will be performed on the received C-VLAN ID, while the subscriber
interfaces preconfigured S-VLAN will be assigned. In case of untagged/priority
tagged frames, the subscriber interfaces pre-configured C-VLAN and S-VLAN will
be assigned.

Figure 4-11 NE as a C-VLAN-aware bridge

C-VLAN cross-connect
S-VLAN termination EFM/Ethernet
or
Ethernet ATM/AAL5/Bridged_encaps/Ethernet
C-VLAN tagged/
S-VLAN tagged untagged/priority
tagged
QoS-aware VLAN cross-connect: VLAN + p-bits cross-connect

The QoS-aware VLAN cross-connect adds the possibility to support PVC-bundles
as subscriber interfaces.
Note The QoS-aware VLAN cross-connect mode only applies to

ATM-based access technologies such as ADSL. It does not apply to
EFM technology.
When transferring packets without cell interleaving, small real-time packets (for
example, voice) might suffer some high jitter due to the high serialization delay on
slow DSL links caused by transmitting long packets. These DSL links have an ATM
layer, which is a transport mechanism on top of DSL that allows cell interleaving
between PVCs. At the same time, you do not want to extend this local issue through
the complete network.
Consequently, for highly QoS sensitive traffic, one might require to set up several
PVCs and associate each PVC with a given traffic priority, identified by the priority
bits (p-bits) associated with the VLAN tag. One ends up with extending the VLAN
cross-connect concept by associating each PVC with one or two VLAN IDs and a
p-bits value.
In the downstream direction, the NE selects the PVC according to the p-bits value
(that is, the QoS classification will be based on the p-bits contained in the C-VLAN);
see Figure 4-12.
In the upstream direction, the NE assigns p-bits as a function of the PVC the frames
originate from (that is, in case the subsciber sends single-tagged frames and the
second tag (for the S-VLAN) is added, the p-bits received from the user are copied
into the S-VLAN p-bits. Thus, the original p-bits from the C-VLAN sent by the user
and stacked in NE do not change); see Figure 4-13.
Note The QoS-aware VLAN cross-connect mode can be applied

to all other VLAN cross-connect modes defined above, that is,
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 C-VLAN.

Figure 4-12 QoS-aware VLAN cross-connect downstream

VLAN to PVC
(S- or C-) cross-connects
EMAN VLAN-tagged NE CPE
frames
PVCs
Ingress
classification
based on p-bits
Figure 4-13 QoS-aware VLAN cross-connect upstream

PVC to VLAN
(S- or C-) cross-connects
EMAN VLAN-tagged NE CPE
frames
PVCs
Assign PVC
according to
traffic type

4.3 Protocol-aware cross-connect mode
A special cross-connect mode is the protocol-aware cross-connect mode. The

protocol-aware cross-connect model behaves like the formerly described
cross-connect models for the dataplane, but it also adds some protocol awareness
similar to the iBridge model, for protocols such as 802.1x, DHCP, IGMP, PPPoE.
Introduction
This mode provides a connectivity scheme compatible with a fully centralized
subscriber management, where each individual subscriber is connected to an IP Edge
(IP connectivity) or a BRAS (PPP connectivity) through a single bit-pipe. In this
configuration, the subscribers are sharing the same subnet for scalability reasons and
do not present their private network configuration to the network.
Figure 4-14 shows the IP network model using IP connectivity and Figure 4-15
shows the IP network model using PPP connectivity.
Figure 4-14 IP network model using IP connectivity

Edge EMAN ISAM CPE
VLAN-CC
Services VRF
IP subnet IP address VLAN
Figure 4-15 IP network model using PPP connectivity

Edge EMAN ISAM CPE
VLAN-CC
IP PPP
Services Routing Termina-
tion
IP subnet IP address
PPP session VLAN

Subscriber management
To protect the whole network, several functions, which are grouped under the term
subscriber management, must be assured by the access network. These functions
can be classified as follows:
subscriber identification
security (MAC address and/or IP address anti-spoofing, user-to-user traffic
control and so on)
service enforcement
service selection
service accounting
When considering subscriber management, two main types of network
configurations exist:
Centralized subscriber management
In this configuration, the NE is kept as simple and as transparent as possible, and
everything related to subscriber management is then performed centrally in the
network. The network model in this configuration is based on one bit-pipe,
realized by one (potentially stacked) VLAN, connecting the subscriber PVC to
the BRAS or the IP edge. The end user is then fully identified by its associated
VLAN.
Distributed subscriber management
In this configuration, subscriber management is performed in the NE relaxing the
requirements for the BRAS or the IP edges. These models are typically based on
some traffic aggregation at the NE level like Ethernet bridging and/or IP
forwarding. In this case, the BRAS or the IP edges do not have direct visibility on
the subscriber interface. herefore everything related to subscriber identification,
security, and so on, must be performed within the NE.
Features
The protocol-aware VLAN cross-connect mode has the following features:
xDSL interfaces types:
ATM:
- Bridged encapsulation carrying both PPPoE and IPoE traffic
- PPPoA with the required interworking to convert the traffic to PPPoE
- IPoA with the required interworking to convert the traffic to IPoE
- Encapsulation auto-detection
Ethernet:
- VDSL EFM
- VDSL2 EFM
Subscriber identification:
A single (C-VLAN) or a stacked (S-VLAN/C-VLAN) VLAN tag towards the
network is associated with either a PVC (in the case of ATM) or a DSL port (in the
case of EFM)
Optional addition of the PPPoE relay tag in the PPPoE control messages
Optional addition of the DHCP Option 82 in the DHCP messages

Security features:
Secured MAC learning, see section 8.2
No MAC address or IP address anti-spoofing since the scope of these addresses
remain limited within the protocol-aware cross-connect mode. The IP edge router or
the BRAS must keep the freedom of allocating them as they want. This control will
typically be performed centrally.
Service enforcement:
Policing per PVC (ATM) or DSL line (EFM)
Further detailed policing actions based on CoS and/or ACL results have to be
performed centrally where the service awareness is present.
Service selection:
performed centrally
Service accounting:
performed centrally
Local multicast handling:
driven by IGMP
The following restrictions apply to the protocol-aware VLAN cross-connect mode:
Router CPEs are not supported. This type of CPE is mainly associated with
business users who need to present their internal IP subnets towards the network
(for example, IP VPN). When considering residential users, the typical CPEs are
either based on a bridge or a router plus NAT (with either IP or PPP to the
network). In short, the residential cross-connect only supports single IP addresses
and does not support IP subnets (directly or not directly attached subnets) at the
subscriber interfaces.
Untagged frames at the user interface. This is especially important when
considering the following aspects:
Encapsulation auto-detection: tagged frames cannot be supported with an XoA
encapsulation. Consequently, they are not supported by the protocol-aware VLAN
cross-connect mode, to present a consistent behaviour independently of the user
interface.
Multicast traffic: the multicast traffic is received over a different VLAN than the
unicast traffic. Both are merged before leaving the NE towards the subscriber.
Making traffic untagged at this point makes this merging easier.

4.4 VLAN frame tagging
Frame types
Tagging of an Ethernet frame consists in adding a tag of four bytes that specifies the
VLAN ID and the priority (from 0 to 7). Table 4-1 shows the used frame types with
their properties.
Table 4-1 Frame types
Property Tagged frame Priority-tagged Untagged frame

frame
Carry the tag of four bytes Yes Yes No

Value of VLAN ID Non-zero value Zero NA
Indication priority bits QoS class QoS class NA
Figure 4-16 shows an untagged and a tagged Ethernet frame, in this case a
priority-tagged Ethernet frame.
Figure 4-16 Untagged and (priority-) tagged Ethernet frames

Untagged frame
Dest Src Length

Preamble SFD Data + Pad FCS
Addr Addr Type
7 1 6 6 2 461500 4
(priority-)tagged frame
MAC Client
Dest Src 802.1q VLAN
Preamble SFD Length Data + Pad FCS
Addr Addr Tag Tag Type
7 1 6 6 2 2 2 46...1500 4
Frame type usage

Frames coming from the upstream Ethernet network are mostly tagged with a VLAN
used in iBridge mode or C-VLAN (VLAN cross-connect mode). Frames coming
from the user side can be tagged or untagged.
Untagged frames can also be received from the network interface, for example, when
the NE is directly connected to an NSP IP router. In this special case, a port-based
default VLAN is also required on the network port.
When untagged frames or priority-tagged frames are received, the VLAN within
which the frame will be forwarded is the port- or port/protocol-based default VLAN
of the port. If the NE receives tagged frames, it will verify whether this VLAN is
allowed on this port.

4.5 Port/protocol-based VLAN in iBridge mode
If the port is a user port, then Permanent Virtual Connections (PVCs) are used. Each
DSL line supports up to 4 PVCs.
All untagged frames toward any port are tagged with the default VLAN ID and p-bit.
If the port is a network port, all priority-tagged frames toward this port are also
tagged with the default VLAN and p-bit. All 802.1q tagging modes are supported on
the network ports.
For more information about the handling of priority-tagged frames, refer to the
chapter Quality of Service.
Port-based VLAN classification

In port-based VLAN classification within a bridge, the VLAN ID associated with an
untagged or priority-tagged frame (that is, a frame with no tag header, or a frame with
a tag header that carries the null VLAN ID) is determined based on the port of arrival
of the frame into the bridge. This classification mechanism requires the association
of a specific Port VLAN Identifier (PVID), with each of the bridge ports. In this case,
the PVID for a given port provides the VLAN ID for untagged and priority-tagged
frames received through that port.
Port- and protocol-based VLAN classification

For bridges that implement port/protocol-based VLAN classification, the VLAN ID
associated with an untagged or priority-tagged frame is determined based on the port
of arrival of the frame into the bridge and on the protocol identifier of the frame. This
classification mechanism requires the association of multiple VLAN IDs with each
of the ports of the bridge; this is known as the VID Set for that port.
Each VID of a port of a bridge that supports port/protocol-based VLAN
classification is also associated with a protocol group identifier. A protocol group
identifier is not relevant in a bridge that supports only port-based VLAN
classification.
The contents of the VID Set for each port may be configured by management. The
VID Set is in addition to the PVID value described in Port-based VLAN
classification.

4.6 IPoA cross-connect mode
The IPoA cross-connect mode offers a solution for connecting users with
RFC-2684-routed encapsulation (IPoA) via the GE uplink with the same services as
in an ATM environment. For example, it offers no changes in IP configuration,
transparency for the involved (routing) protocols, QoS and so on.
Note The IPoA cross-connect mode is comparable with the
VLAN cross-connect mode, but with IPoA instead of IPoE at the CPE
side.
The IPoA cross-connect model implies a cross-connection between the PVC of a

subscriber whose encapsulation is IPoA with a VLAN at the EMAN side.
The following applies for the user subnet behind the customer CPE:
the CPE performs Network Address Translation(NAT), that is, the users behind
the CPE have a private subnet and the CPE translates the private user IP address
to the public CPE IP address
the users have IP addresses from the public range and, as a consequence, the
public user IP addresses become visible in the IP network.
In any case, the subnet configuration at the user side (behind the CPE) is transparent
to the ISAM. The ISAM only sees the IP address of the CPE and the IP address of
the edge router. (see figure 4-17).
Figure 4-17 IP network model for business IPoA cross-connect

Edge EMAN ISAM CPE
VRF
VLAN-CC
VRF Customer
Services VRF premises
VRF IP subnet
VRF
IP subnet IP address VLAN

IPoA cross-connect features

The following features are supported for the IPoA cross-connect mode:
The IP address of the CPE is static (no dynamic CPE IP address assignment via
DHCP).
The ISAM is transparent for routing protocols between CPE and PE.
Only /30 subnet is supported between the ISAM and the CPE.
A given CPE can be associated with up to 30 different subnets (multi-VPN). Each
of these subnets will then be served with a separate PVC and separate VLAN.
There is VLAN stacking on the GE uplink. Typically, the C-VLAN indicates the
CPE and the S-VLAN indicates the ISAM (or the paired NE-PE).
There is internal priorization based on Type of Service (ToS)-bits, both for the
upstream and the downstream direction.
Cross-connect from IPoA to IPoE (upstream)

The IP packet is extracted from ATM (IPoA) and encapsulated into Ethernet (IPoE),
as follows:
Unicast IP packets
The LIM MAC address is used as the source MAC address and the destination
MAC address is the MAC address of the edge router which is resolved from the
edge router IP address via ARP.
Broadcast/multicast IP packets
The LIM MAC address is used as the source MAC address and the destination
MAC address is derived from the broadcast/multicast destination IP address.
Cross-connect from IPoE to IPoA (downstream)

The IP packet is extracted from Ethernet (IPoE) and encapsulated into ATM (IPoA).
The CPE interface (PVC) is determined from the VLAN (or S-VLAN and C-VLAN
combination) since it is cross-connect mode.
The destination MAC address can either be the LIM MAC address (the NE responds
to an ARP request for the CPE IP address generated by the edge router) or a
broadcast/multicast MAC address.

5 Layer 2 protocol handling
5.1 Introduction 5-2
5.2 Link aggregation 5-3
5.3 RSTP 5-4
5.4 ARP 5-6
5.5 VBAS (7302 ISAM only) 5-7
5.6 DHCP 5-8
5.7 IGMP 5-10
5.8 802.1x support 5-11
5.9 PPPoE 5-12

5.1 Introduction
Layer 2 protocol handling can be divided into two parts of handling:

forwarding protocol handling
application protocol handling
Forwarding protocol handling

Table 5-1 shows the protocols of the forwarding protocol handling.
Table 5-1 Forwarding protocol handling
Protocol Described in Section
Link Aggregation 5.2
Rapid Spanning Tree Protocol 5.3
Application protocol handling

Table 5-2 shows the protocols of the application protocol handling.
Table 5-2 Application protocol handling
ARP 5.4
VBAS 5.5
DHCP 5.6
IGMP 5.7
802.1x 5.8
PPPoE Relay 5.9
PPPoA to PPPoE Relay 5.9

5.2 Link aggregation
Link aggregation or trunking is a method of combining physical network links into

a single logical link for increased bandwidth. Figure 5-1 shows an example of link
aggregation.
Figure 5-1 Link aggregation

IP Edge Router /
BRAS
Ethernet
Switch NSP IP backbone
NE m*FE/GE
ADSL
FE/GE
EMAN NSP IP backbone
n*FE/GE
NSP IP backbone
Link aggregation allows you to increase the capacity and availability of the
communications channel between devices (both switches and end stations) using
Ethernet technology. Two or more Ethernet connections are combined to increase the
bandwidth capability and to create resilient and redundant links. A set of multiple
parallel physical links between two devices is grouped together to form a single
logical link.
Link aggregation also provides load balancing where the processing and
communications activity is distributed across several links in a trunk, so that no
single link is overwhelmed.
Link Aggregation Control Protocol

The Link Aggregation Control Protocol (LACP) is part of the IEEE specification
802.3ad. This protocol allows a switch to negotiate an automatic bundle by sending
LACP packets to the peer.
When a set of links is configured to belong to the same link aggregate, LACP is used
to communicate over these links to the EMAN to assure that the links of one link
aggregate really connect to the same EMAN.
When an inconsistency is detected between the configured information and the
connectivity of a link, the involved link is not activated.
If a link fails, this is detected by LACP. It removes the link from the active set of the
link aggregate. When the link comes up again, LACP puts the link back in the active
set of the link aggregate.

Advantages
Using link aggregation on the uplink interfaces provides the following advantages:
Higher link capacity
For example, capacity is 200 Mb/s instead of 100 Mb/s when 2 FE links are
aggregated.
Link redundancy
If one link fails, the other link takes over. Throughput is decreased, but the
connection is not lost.
Link aggregation support

Up to 2 link aggregation groups are supported
Link aggregation is supported on:
network links
subtending links
Note Link aggregation is not supported on user links
5.3 RSTP
The NE can be configured with several network interfaces. They can be used to
connect the NE to multiple Ethernet switches.
For an Ethernet network to function properly, only one active path can exist between
two stations.
The Rapid Spanning Tree Protocol (RSTP) is a link management protocol that
provides path redundancy while preventing undesirable loops in the network.
Multiple active paths between stations cause loops in the network. If a loop exists in
the network topology, the potential exists for duplication of messages. When loops
occur, some switches see stations appear on both sides of the switch. This condition
confuses the forwarding algorithm and allows duplicate frames to be forwarded.
To provide path redundancy, RSTP defines a non-redundant tree topology within a
physical redundant network topology. RSTP forces certain redundant data paths into
a standby (blocked) state. After a network node or link has become unavailable,
RSTP will run again to define a new tree topology.
The RSTP operation is transparent to end stations, which are unaware whether they
are connected to a single LAN segment or a switched LAN of multiple segments.

RSTP in the 7302 ISAM

RSTP is supported on network links.
RSTP is not supported towards DSLAMs nor to users connected with an Ethernet
link.
RSTP can be disabled on some of the Ethernet interfaces of the 7302 ISAM. As a
consequence, RSTP is disabled on the network interface of the subtending
7302 ISAM.
Note The 7302 ISAM does support RSTP towards DSLAMs in a

ring; see Figure 5-2.
Figure 5-2 Ring architecture
Note RSTP is STP-compatible for support of older routers.
RSTP in the 7330 ISAM FTTN

The network element does not support RSTP toward users. RSTP can be disabled on
some of the Ethernet interfaces of the network element.
Note RSTP is STP-compatible for support of older routers.

5.4 ARP
The Address Resolution Protocol (ARP) is a protocol within TCP/IP that maps IP
addresses to Ethernet MAC addresses. TCP/IP requires ARP for use with Ethernet.
The NE has a limited ARP handling functionality, but it is sufficient to prevent
broadcast storms toward the users. This is achieved in the following ways.
In iBridge mode
When an ARP request is received from a PVC, the ARP request is broadcast to
the Ethernet network interface. This deviates from the standard Ethernet
broadcast because the ARP request is not broadcast to the VCs.
When an ARP request is received from an Ethernet network interface, the ARP
request is only broadcast in the VLAN when downstream broadcast is enabled in
the VLAN. Otherwise, the ARP request is dropped.
In cross-connect mode
ARP requests are forwarded transparently downstream or upstream like any other
data packet.
In both forwarding modes

ARP reply messages receive no special treatment compared to any other data packet.

5.5 VBAS (7302 ISAM only)
The Virtual Broadcast Access Server (VBAS) protocol is a Layer 2 protocol that
allows the external BRAS to query the NE for DSL link information so that the
BRAS can limit the number of Point-to-Point Protocol (PPP) sessions per DSL link.
VBAS allows the BRAS to obtain detailed information on the physical address of a
subscriber on the network element. The VBAS protocol goes through query and
response phases before the BRAS can obtain the physical address of any new
subscriber.
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 BRAS. This packet includes the physical port information of the new
subscriber.
All messages are encapsulated in standard Ethernet frames with a proprietary

Ethertype and the messages are all unicast messages. All VBAS packets carry a
destination identifier. If the packet is not destined for a specific system, it forwards
the packet to all subtending systems until it reaches its intended destination.
In normal operation, the network port toward the BRAS is tagged. This means that
the network port is able to process and respond to tagged VBAS frames.
If untagged packets need to be handled, the network port is explicitly set as untagged.
A PVID is also configured for the port. When the system receives a VBAS query,
subscriber information is retrieved from the VLAN configured as PVID.
VBAS handling in the 7302 ISAM

The VBAS handling in the 7302 ISAM is shown in Figure 5-3.
Figure 5-3 VBAS handling
When a VBAS packet is received, the port information based on the user MAC address
is added inside the VBAS packet and the VBAS packet is sent back to the BRAS.
BRAS
ISAM
EMAN
CPE
CPE Sends VBAS request with MAC DA address (the MAC address of
the user which is to be resolved) and waits for the response.
VBAS handling in a subtended 7302 ISAM

When a downstream VBAS packet is destined for a subtended 7302 ISAM, the hub
7302 ISAM will bridge the VBAS packet to the correct external Ethernet link. This
is because the MAC DA of the VBAS packet is equal to the MAC address of the
subtended 7302 ISAM.
5.6 DHCP
The 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. DHCP is defined in RFC 2131.
DHCP consists of two components:
a protocol for delivering host-specific configuration parameters from a DHCP
server to a host
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.
DHCP provides a framework for passing configuration information to hosts on a
Transfer Control Protocol (TCP)/IP network. DHCP adds the capability of automatic
allocation of reusable network addresses and additional configuration options.
DHCP relay
You can enable DHCP at layer 2 for VLANs configured in iBridge mode. For
VLANs configured in cross-connect mode, DHCP packets are forwarded
transparently. In layer 2, DHCP is used as an alternative to IP address allocation in
PPPoE.
Figure 5-4 shows the distributed DHCP relay implementation in NE.
Figure 5-4 Distributed DHCP relay implementation
US: Relay all broadcast packets to each DHCP server. Option82

from the LIM is kept in the packet.
DS: DHCP packet is sent to LIM as broadcast or unicast to the
user, depending on the broadcast flag.
LIM SHub Ethernet ER
US: simply IP routing.

CPE DS: simply IP routing.
LIM NT
CPE
US: Add Option82, and send packet as broadcast to

US/DS: DHCP broadcast SHub.
or unicast packet. DS: Remove Option82, and send on correct DSL line.

The IP edge router only sees unicast packets and performs IP routing. Therefore, it
needs a route toward the DHCP servers and a route toward the IP address of the
VLAN in the network element. The IP address is used as the gateway IP address in
the relayed DHCP packet and as the IP destination address of the downstream packet
sent by the DHCP server. This address is in the same subnet as the IP address of the
edge router on that VLAN. The network element resets the gateway address to zero
if the network element is functioning as the relay agent.
There are differences in DHCP when it is used in the upstream and downstream
directions.
Upstream
Option 82
In the upstream direction, the NE supports the insertion of DHCP option 82 as a
configurable option.
In the case where in the NE the insertion of option 82 is enabled, the NE adds
DHCP option 82 to the DHCP message in a way compliant with the standard.
In the case where in the NE the insertion of option 82 is disabled, the NE forwards
the DHCP messages if they are standard compliant.
Perform DHCP relay

If DHCP relay is not enabled, the NE - from the users view - does not modify DHCP
packets.
If DHCP relay is enabled, the packets are relayed by the NE toward the DHCP
servers as unicast packets.
The IP edge router only sees unicast packets and performs IP routing. Therefore, it
needs a route toward the DHCP servers and a route toward the IP address of the
VLAN in the NE. The latter address will be used as the gateway IP address (giaddr)
in the relayed DHCP packet and will be used as IP destination address of the
downstream packet sent by the DHCP server. This is an address in the same subnet
as the IP address of the edge router on that VLAN. Inside the NE, the giaddr is set to
zero again if the NE was the relay agent.
The following must be configured in the NE when the DHCP relay is enabled:
a list of DHCP servers per VLAN
when DHCP has been enabled for a VLAN, an IP address for that VLAN must
also be configured.
a static route so that an IP lookup can be done with the IP address of each DHCP
server to find the IP Next Hop (and thus the outgoing VLAN, which can be the
same as the originating VLAN).
All the static routes are kept in one routing table. Therefore, the IP addresses of
the DHCP servers and the IP addresses of the VLANs may not overlap. If this
were the case, it would be possible for two static routes to have the same IP next
hop. As a result, the NE would not know on which VLAN to send the relayed
DHCP packet.

Downstream
Option 82
In the downstream direction, the LIM can receive either a broadcast or unicast DHCP
message. This depends on the broadcast flag inside the DHCP message received
from the network if the DHCP relay agent in the 7302 ISAM is enabled. If option 82
was added in the upstream direction, it is stripped from the packet in the downstream
direction.
Perform DHCP relay

The DHCP message relayed by the NE to a downstream DHCP relay agent (giaddr
is non zero) is forwarded as unicast to the bridge port identified by the VLAN and
destination MAC address of the frame. If the destination MAC address contains a
MAC address not known in the database, the DHCP message is discarded.
DHCP relay with subtended NEs

For subtended NEs, DHCP relay can be achieved in two ways:
enable DHCP relay in the subtended NE and disable DHCP relay in the hub NE
disable DHCP relay in the subtended NE and enable DHCP relay in the hub NE
The disadvantage of the first method is that the subtended NE also needs an
IP address for that VLAN. This is not the case for the second method.
Option 82 is inserted by the subtended NE.
5.7 IGMP
For more information about IGMP, refer to chapter 10.2.

5.8 802.1x support
The 802.1x protocol complies with both the IEEE and CCSA specification. It is
mapped to the LIM, where the authentication state of the port is enforced; see Figure
5-5. This means that packets from unauthenticated users are dropped at the LIM.
802.1x on the LIM communicates with the NT by way of the internal VLAN to
perform the authentication. The NT uses a local database or contacts a RADIUS
server.
Figure 5-5 802.1x in the NE
Handles the 802.1x packets and communicates with the NT to perform

the authentication. This communication is done over the internal VLAN.
LIM SHUB Ethernet

ER
CPE
LIM NT
CPE
Performs authentication by means of contacting a RADIUS server or by

means of a local authentication database. The result is sent back to the LIM.
For an authenticated port, all user frames are forwarded as tagged frames. The VLAN
ID used to tag user IPoE frames can be either:
the VLAN ID determined by the RADIUS server
the VLAN ID configured in the user domain database of the NE (when no specific
VLAN is returned by the RADIUS server)
the VLAN ID configured by the operator on the user PVC (when no specific
VLAN is returned by the RADIUS server and no specific VLAN is configured in
the user domain database of NE)

5.9 PPPoE
Point-to-Point Protocol over Ethernet (PPPoE) is a specification used to connect

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 dialup
connections, with the Ethernet protocol, which supports multiple users in a LAN.
The PPP protocol information is encapsulated within an Ethernet frame.
PPPoE relay
In case of PPPoE relay, a relay session ID, based on the DSL link/ATM PVC, is
inserted in all the PPPoE messages in the discovery phase (that is, EtherType =
0x8863). All PPPoE messages contain MAC addresses of the user as source and the
PPPoE server as destination MAC addresses. The only exception is the PPPoE
Active Discovery Initiation (PADI), which is sent upstream with a MAC DA equal
to the broadcast MAC address. All PPPoE messages in the session phase are
forwarded without any processing.
Figure 5-6 PPPoE relay
PPPoE traffic

PPPoE traffic
CPE
LIM NT
CPE
US/DS: PPPoE session

setup frames US: add PPPoE relay session ID, and forward
DS: forward
Point-to-Point Protocol over ATM (PPPoA) to PPPoE relay

PPPoA is an important model for broadband access. PPP termination can be
supported in a distributed BRAS model (in the DSLAM) or in a centralized BRAS
model. The centralized BRAS model is the most prevalent model today. Opposed to
PPPoE, PPPoA has no natural MAC layer defined below the PPP session. As such,
in case of the Ethernet aggregation in the NE, the PPPoA session can only be
terminated on the NE or forwarded to another PPP termination point (the centralized
BRAS) using PPPoE type of encapsulation (called PPPoA to PPPoE relay).
In case of PPPoA to PPPoE relay, the PPP forwarder can be seen as a further
enhancement of the iBridge. It is still essentially a layer 2 forwarding model, but it
also uses information from the PPP layer in its forwarding decisions.
PPPoA packets on the DSL line are translated into PPPoE on the uplink as follows.
When a user initiates a PPPoA session, the NE first initiates a PPPoE session toward
the BRAS. Once the PPPoE session is established, the initial PPP request from the
user is forwarded within that PPPoE session. The remainder of the PPP negotiation
happens between the user terminal and the BRAS. When the PPP session is

terminated, the NE also terminates the corresponding PPPoE session. During the
session, every upstream PPP packet is encapsulated in PPPoE, whereby as source
MAC address, the MAC address of the NE is used, downstream the reverse operation
happens and the MAC layer is stripped off. From a BRAS perspective, the session
looks like any normal standard PPPoE session.
To give the Access Service Provider (ASP) the maximum information that can help
him to accept a PPPoE session establishment or to silently ignore the request, the NE
provides the server with line-related information as defined in DSL Forum
contribution 2004-071. This means it adds this information to the PADI message at
PPPoE session establishment. The NE provides this information through the vendor
specific tag. This option fulfills the same role as option 82 in DHCP. Figure 5-7
shows the PPPoA-PPPoE network topology.
Figure 5-7 PPPoA-PPPoE network topology

PPP ATM PPPoA - PPPoE PPPoE / PPP
termination termination relay termination
IP Edge
USB Local Loop ISP
USB Modem EMAN

Ethernet
IP Srv: Video
Bridge
I
IP
Routing
ISAM Srv: VoIP
Gateway
L2TP
PPPoE PPP-L2TP PPP

termination interworking termination


6.1 Network topology 6-2
6.2 Layer 3 forwarding modes 6-3
6.3 Authentication/authorization/accounting 6-5
6.4 Service provider selection 6-6
6.5 User IP address management 6-6

6.1 Network topology
This section focuses on the layer3 forwarding model to offer broadband services over
DSL. IP connectivity is established between terminals in the home environment and
content servers higher up in the network for High Speed Internet (HSI), Video
Broadcast, Video on Demand (VoD), VoIP service, and so on. IP packets are routed
(forwarding decision based on IP addresses) by the NE to the network or to the
individual DSL users.
Figure 6-1 shows the network topology.
Figure 6-1 Network topology

AAAproxy/server
AAA/DHCP
IP Edge
USB Local ISP
USB modem
PPPoE
Ethernet
Bridge IP Srv: Video
EMAN Network
IP
IP
Routing
Gateway ISAM
Srv: VoIP
The main elements to contribute to the service on the data plane level are:
CPE
DSLAM
Ethernet switches
edge nodes, such as edge routers or even BRAS as a service edge and the servers
such as HTTP servers
video servers
Voice servers
From a control perspective, RADIUS servers will help in user authentication, service
accounting and personalized on demand service settings. DHCP servers contribute
in IP address assignment. On the IP and the Ethernet control plane, different
protocols are used to aggregate links and to provide availability of the service or auto
configuration of the network.
Over the DSL link, the following protocol stacks are supported: PPPoE, IPoA (7302
ISAM only) and IPoE. PPPoA is another protocol stack supported to CPEs, but not
yet supported in combination with layer 3 forwarding. Both PPPoE and IPoE can be
supported on the same PVC. By way of a protocol-based filter (that is, ethertype),
traffic can be treated by a PPP-oriented access application or by an
IP/DHCP-oriented access application.

Service provider selection can be based on hard configuration by way of network

management or originated by the DSL user using PPPoE signaling based on
user-name@domain-name in the authentication part of the protocol. Since multiple
service providers need to be supported, multiple virtual routers need to be supported.
The IP service parameters used for going into service can be obtained by the end user
by way of IPCP in the case of PPP access, and by way of DHCP or configured in case
of IP/DHCP access. The resources should be used in an efficient way: for example,
optimization of the number of users that make use of the same subnet.
The IP forwarding table of the DSLAM can be populated with static routes or with
routes learned by way of routing protocols such as OSPF. By way of these protocols,
routes can be configured in upstream routers. Routing protocols will also contribute
to improve the availability of the service in case of a link failure or the failure of an
NE.
6.2 Layer 3 forwarding modes
The NE supports two variants of layer 3 forwarding:

IP 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.
IP-aware bridge
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.

IP routing
In the IP routing model, the NE behaves as a standard IP router toward the end users
and the network.
At the user side of the system (xDSL line), unnumbered IP interfaces are used, while
user subnets are configured on a user gateway interface. To achieve maximum
efficiency in the allocation of IP addresses, several users (on different DSL lines) can
share a same subnet. Toward the network, IP interfaces are numbered (meaning that
the NE IP addresses and subnets are configured).
Host routes toward the end user devices are either dynamically created in the NE, in
the case of dynamic DHCP or PPPoE sessions, or statically provisioned in the case
of static IP address assignment.
The end user subnets that are associated with the NE can be advertised to the
upstream routers by way of routing protocols. Conversely, network routes can be
advertised to the NE by way of these routing protocols.
End users that are attached to the same DSLAM can directly communicate with each
other at layer 3 (user-to-user traffic). In the case of users that share the same subnet,
this is achieved by providing a proxy ARP function towards those end users.
For security reasons, IP address anti-spoofing is performed, that is, comparing the
received source IP address with IP addresses that have been handed out over a given
PVC.
IP-aware bridge
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 is
situated in between and performs packet forwarding at layer 3.
In an IPoA/IPoE DHCP scenario, the upstream packet forwarding happens as
follows:
End user devices use ARP to contact the default gateway (really the IP edge)
The LIM learns the end user subnets by snooping DHCP messages, and based on
this knowledge, they perform a proxy ARP function and return the LIM MAC
address in the ARP reply.
The IP packet is sent to the LIM, and is forwarded at layer 3 into the correct
VLAN that leads to the IP edge router. The network routes that are needed in the
LIMs FIB must be configured by the operator.
In the downstream direction, the forwarding happens as follows:

The IP edge router sees the end user subnets as a directly attached networks.
When the IP edge uses ARP to contact an end user IP address, the relevant LIM
replies by way of a network-facing proxy ARP function.
When downstream packets arrive in the NE, they are forwarded at layer 3 into the
correct user PVC based on a host route that has been automatically created by the
system when the DHCP session was set up.

6.3 Authentication/authorization/accounting
The NE provides the possibility to authenticate the users to make sure that only those
users who have access rights can make use of the services offered by the service
providers
IPoE user interfaces

The following applies for IPoE user interfaces:
Users can be authenticated via 802.1x authentication protocol on the user
interface. The RADIUS protocol is used to authenticate the users via RADIUS
servers
The user interfaces are authorized for services by associating either with an
IP-aware bridge or with a router, corresponding to the service provider. RADIUS
authentication only verifies the access rights of the users.
IPoA user interfaces

The following applies for IPoA user interfaces:
No authentication mechanism is defined.
The user interfaces are by default considered as authenticated when configured.
IP-aware bridge or with a router, corresponding to the service provider.
PPPoE sessions
The following applies for PPPoE user interfaces:
Users are authenticated during the PPP protocol Link Control Protocol (LCP)
phase. The NE can either use the RADIUS protocol to authenticate the users by
way of RADIUS servers, or the users can be locally authenticated by using the
local user database in the NE.
IP-aware bridge or with a router, corresponding to the service provider which is
determined during the authentication phase.

6.4 Service provider selection
Service provider selection can be either static (by way of configuration) or dynamic
(by way of authentication).
Static
IPoE and IPoA user interfaces are statically assigned to either an IP-aware bridge or
a router, corresponding to the NSP. Users connected to the NE by way of the same
interface can only get access to the NSP network configured on that interface.
Dynamic
PPPoE user sessions are dynamically assigned to either an IP-aware bridge or a
router, corresponding to the NSP, determined during the authentication of the user
session, based on domain name and user name.
6.5 User IP address management
User IP address assignment can be either static (by way of configuration) or

dynamic.
Static IP address assignment: IPoE and IPoA user interfaces

IP addresses are statically assigned to the users. Static IP address assignment is only
supported for IPoE and IPoA user interfaces.
Dynamic IP address assignment: IPoE and IPoA user interfaces

DHCP servers dynamically allocate IP addresses to the users. A DHCP session
corresponds to a user who is connected by way of IPoE or IPoA interface to the NE
and makes use of DHCP protocol to get an IP address.
The NE needs to be aware of the IP address of the users to perform anti-spoofing in
the upstream direction, and to use IP-forwarding mode which is based on fixed match
look-up with the user IP address in the downstream direction.
Dynamic IP address assignment: PPPoE user interfaces

IP addresses are assigned during the authentication/authorization of the PPPoE
sessions. An IP address can be assigned either by the RADIUS servers or locally by
the NE from one of the locally configured IP address pools.

7.2 RIP 7-3
7.3 OSPF-2 7-4
7.4 ARP 7-7
7.5 PPPoE Termination 7-8
7.6 DHCP 7-11
7.7 IGMP 7-12

7.1 Introduction
Layer 3 Protocols can be divided into two parts:

routing protocols
user access protocols
Routing protocols
Table 7-1 shows the supported routing protocols:
Table 7-1 Routing protocols
RIP 7.2
OSPF-2 7.3
User access protocols

Table 7-2 shows the supported user access protocols:
Table 7-2 User access protocols
ARP 7.4
PPPoE 7.5
DHCP 7.6
IGMP 7.7

7.2 RIP
The Routing Information Protocol (RIP) is a distance vector protocol. It calculates

the shortest distance, and therefore the most desirable path, between source and
destination addresses, all based on the lowest hop count.
The network element supports:
RFC 1812 defined for IPv4 routers for handling IP packets that are forwarded and
destined to the system
RFC 2453 defined for RIPv2 protocol
RFC 1058 defined for RIPv1 protocol
RFC 2082 defined for RIPv2 MD5 authentication
RIPv1 compatibility
The NE is compatible with RIPv1 and RIPv2 versions of the RIP protocol. It supports
the configuration of the version of the RIP PDUs that are transmitted and received
by the RIP router in NE.
RIP authentication
The NE provides secure RIP update mechanisms using the password mechanism as
defined by the RFC. The RIP router accepts RIP updates only from peers whose
updates can be authenticated based on the configured authentication information.
The system accepts authentication based on simple text password and
MD5-encrypted authentication mechanisms as defined by the standards.
Advertise user reachability to network

The NE provides the ability to advertise the reachability to the users for the routers
that reside on the network side of the NE.
Statically configured user subnets are advertised to the network.
Route maps and route aggregation are supported when routes are advertised to the
network.
Individual user IP addresses (learned from RADIUS or DHCP server) are not
advertised.
Advertise network reachability to subscribers

The NE provides the ability to advertise the network reachability to the CPEs when
the CPEs are routing between different pipes, such as HSI over PPP and multimedia
over an IP interface. Typically, the default route will point to the PPPoE session. A
limited number of routes will point to the multimedia network. This information is
advertised by the NE to the CPEs by way of RIPv2 when RIPv2 is enabled at the
CPEs.
Note The RIP protocol runs in an advertise-only mode whereby

updates are sent to the CPE devices, but any updates from the CPE
devices are discarded and not processed.

7.3 OSPF-2
Open Shortest Path First (OSPF) is a dynamic routing protocol used to learn and
populate the forwarding database in the DSLAMs, CPE at the user side, and edge
devices at the network side. For example, a network element used as a default
gateway by users connected to the DSLAM acts as a next hop gateway to reach the
users from the routers on the network side. The route to the users through the network
element is learned by the edge routers using either the OSPF or RIP routing protocol
depending on the configuration of the Internet Service Provider (ISP) network.
The following scenario is an example where the NE is used as a default gateway by
users connected to the DSLAM. The NE in this case acts as a next hop gateway to
reach the users from the routers on the network side. The route to the users through
the NE is learned by the edge routers using the routing protocol OSPF or RIP based
on the configuration of the ISP network.
Toward the network multiple VLANs may be required (one per service).
In this case, each VLAN can be connected to multiple next-hops as well.
Figure 7-1 shows a scenario where the NE is connected to OSPF routers on the
network side and acts as a layer 3 gateway between the users and the ISP.
Figure 7-1 Typical scenario of OSPF routers connected to the NE

NE as default gateway for all users
Edge router
IPx1 in the routed model
User
NE OSPF
OSPF on
IPx2
User DSL/PVC Network
IPx3 OSPF
User
SHub-NT
IPx4
User
LT OSPF on OSPF
User
IPx5 DSL/PVC Edge router
IPx6
User

The network element complies with the following standards:

RFC 1812 defined for IPv4 routers for handling IP packets that are forwarded and
destined to the system
RFC 2328 defined for OSPF-2 protocol
RFC 3101 defined for OSPF to support the NSSA option.
The NSSA option is used by deployments to reduce the size of the LSA database
in the NSSA area and at the same time advertise the external LSA to the routers
that belong to this area, this option is commonly used in deployments that are
similar to network element
RFC 1765 for OSPF database overflow in case of conditions when the system
receives updates from the neighbors that exceeds the available database limit
RFC 2370 for OSPF opaque LSA option
Area support
The NE supports areas as defined in RFC 2328 for OSPF version 2 protocol. The
OSPF router on the NE is able to associate interfaces with the backbone area, a
normal area, a stub area, or an NSSA area.
OSPF-2 interfaces
The network element supports areas and interfaces as defined in RFC 2328 for the
OSPF-2 protocol. The router IP interfaces are configured as OSPF interfaces that
belong to a specific area number and type. When the router acts as an area border
router, there are multiple interfaces configured belonging to different areas. The
protocol, as defined by the standards, performs SPF on each area independently and
computes the intra- and inter-area routes and accordingly populates the forwarding
database.
OSPF is only supported on the network and subtending interfaces.
The subnets on the user side must be advertised for the edge routers to use network
element as the gateway to the users. This can be achieved by using route
redistribution and distributing interface routes into OSPF with route filters that are
applied on the distribution.
Load sharing
The NE supports load sharing as defined in RFC 2328 for OSPF version 2 protocol.
Multiple links are provisioned as OSPF interfaces that can provide the reachability
to a common network.
The NE provides the ability to share the traffic load by distributing the traffic over
these multiple links when they are learned through OSPF. This principle is defined
as Equal Cost Multi-Path (ECMP) routing in OSPF.

Border router
The NE provides the ability to act as a Border Router as defined in RFC 2328 for
OSPF version 2 protocol. The router IP interfaces are configured selectively as OSPF
interfaces, that belong to a specific area number and type. When the router acts as a
area border router, there are multiple interfaces configured belonging to different
areas. The protocol, as defined by the standards, performs SPF on each area
independently and compute the intra- and inter-area routes and accordingly populate
the forwarding database.
Advertise user reachability

The NE provides the ability to advertise the reachability of the users connected to the
NE to the network. Only statically configured user subnets are advertised to the
network. Individual user IP addresses (learned from RADIUS or the DHCP server)
are not advertised.
Alarms support
The NE provides the ability to report alarms when a new neighbour is discovered and
an adjacency is established using the OSPF protocol. An alarm is reported to indicate
a loss of adjacency. Events are reported to indicate the state in which each adjacency
is transitioning.

7.4 ARP
ARP is a protocol within TCP/IP that maps IP addresses to Ethernet MAC addresses.
TCP/IP requires ARP for use with Ethernet. The network element provides ARP
proxy on both the user and network interfaces.
ARP proxy on the user side

The NE provides ARP proxy (for the user subnets) on the IPoE user interfaces.
ARP requests received from users are treated as follows:
If the user is not learned on the incoming interface, discard the ARP message
(anti-spoofing).
If both source and target users are learned on the same interface, discard the ARP
message (users can communicate by way of the internal interface at the user side).
ARP reply is sent when one of the following conditions are fulfilled, otherwise
the ARP message is discarded (no ARP reply is sent back):
if target IP address is the gateway IP address
if both users are in the same subnet
ARP proxy on the network side

The NE provides ARP proxy (for the user subnets) on the network interfaces when
the IP aware bridge is enabled.
ARP requests received from a network interface are treated as follows:
If the source IP address of the ARP message is statically assigned to one of the
users, generate an alarm to the operator and send an ARP reply to the originator
of the ARP message (both source and target IP addresses are set to the IP address
of the user)
If the source IP address of the ARP message is dynamically assigned to one of the
users by way of PPPoE (local or RADIUS) or by way of DHCP:
If the network interface is trusted, preempt the user session and generate an
alarm to the operator.
If the network interface is not-trusted, generate an alarm to the operator and
send a reply to the originator of the ARP message (both source and target IP
addresses are set to the IP address of the user session). The session is not
preempted.
If the target IP address of the ARP message is assigned to one of the users, then
send an ARP reply.

7.5 PPPoE Termination
PPPoE is a specification used to connect 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 dialup connections, with the Ethernet protocol,
which supports multiple users in a LAN. The PPP protocol information is
encapsulated within an Ethernet frame.
In the case of Point-to-Point Protocol over Ethernet (PPPoE) termination in the NE,
the NE acts as PPPoE server. It handles all PPPoE, LCP, PAP, CHAP and IPCP
control messages. The PPPoE server is located in the LIM.
PPPoE is terminated in the LIM. In both upstream and downstream directions, all
PPPoE messages contain MAC addresses of the user and the PPPoE server (LIM) as
source and destination MAC addresses. For this to function properly, each LIM has
a separate MAC address and supports IP forwarding.
Local IP address management, local authentication, and RADIUS Client are located
and terminated at the NT.
User traffic is split per ISP. The NE supports Virtual Routing Forwarder (VRF) to
avoid private IP address collision between two ISPs. For each VRF, multiple VLANs
are reachable using VLAN aggregation.
Within a particular VLAN or on a particular VC, the LIM will either act as PPPoE
relay or PPPoE server. The PPPoE server function is shown in Figure 7-2.
Figure 7-2 PPPoE server

Terminate PPP/PPPoE session setup.
Communicates with the NT to perform the authentication.
This communication is done over the internal VLAN.
When session established, implement VRF function (IP forwarding traffic)

IPoE traffic
PPPoE traffic
CPE
LIM NT
CPE
Performs authentication by means of contacting a RADIUS server by

means of the local aythentication database. The result is sent back to the LIM.
PPPoE session setup

An average of 10 PPPoE/PPP messages in each direction are required to set up a
session. The average size of these messages is 60 bytes. IP address assignment can
be required from a RADIUS server or from a local IP address management system.
In this case, a single interface is required.

Note RADIUS client, local authentication and local IP address

management are present on the NT board.
The PPPoE session setup is shown in Figure 7-3.
Figure 7-3 PPPoE session setup

NT LIM
User
PADI
PPPoE discovery phase

[60]
[Host_unique, service_name]
PADO
[70]
[Host_unique, service_name, AC_name]
PADR
[60]
[Host_unique, service_name]
PADS
[66]
[PPPoE Session-id], [Host_unique, service_name, AC_name]
LCP Configure Request
[60]
[PPPoE Session-id] , [Magic number]
[60]
PPP LCP phase
[PPPoE Session-id] , [MRU, CHAP, Magic number]

LCP Configure Ack
[60]
[PPPoE Session-id] , [Magic number]
LCP Configure Nak
[60]
[PPPoE Session-id] , [PAP]
[60]
[PPPoE Session-id] , [MRU, PAP, Magic number]
LCP Configure Ack
[60]
[PPPoE Session-id] , [MRU, PAP, Magic number]
PAP Authenticate
Authentication phase
[60]
PPPoE session phase

[PPPoE Session-id] , [User-id, Password]
Access Request
internal Communication
Access Accept
internal Communication
Authenticate Ack
[60]
IPCP Configure Request

[60]
[PPPoE Session-id] , [IP address]
[60]
[PPPoE Session-id] , [IP address, DNS and NBNS server]
IPCP Configure Ack
[60] [PPPoE Session-id] , [IP address]
PPP IPCP phase
IPCP Configure Reject

[60]
[PPPoE Session-id] , [NBNS server reject]
[60]
[PPPoE Session-id] , [IP address, DNS server request]
[60] IPCP Configure Nak

[PPPoE Session-id] , [IP address, DNS server proposal]
[60]
[PPPoE Session-id] , [IP address, DNS server proposal]
IPCP Configure Ack
[60]
[Size of message] [PPPoE Session-id] , [IP address, DNS server acknowledgement]
Session setup messages are normally spread over time. In case of a restart of the NE,
all active users will try to re-establish their session. Therefore, a high burst of PPPoE
messages after a restart of the NE may be expected. After PPPoE discovery phase, a
unique session ID is allocated to this session, which is used in all further messages
exchanged within this session.
PPPoE data forwarding

Once the session has finished the Link Control Protocol (LCP), the authentication,
and the IP Control Protocol (IPCP) phase, data can be exchanged between the user
and the ISP.

PPPoE data packets are identified by way of the Ethertype (0x8864). Since PPP and
PPPoE are terminated in the NE, their headers are stripped in upstream direction. In
downstream direction, proper PPP and PPPoE headers are added. All PPPoE data
messages are sent upstream by the user with the LIM as destination MAC address.
To forward these data packets upstream, the NE looks at the IP destination address.
In this case, an IP forwarding table lookup is required.
At regular time intervals, both the user and the PPPoE server may send keep alive
(LCP echo request) messages. The PPPoE server sends these messages for all active
PPPoE sessions. The sending of these messages must be spread in time, to avoid a
burst of messages sent by the LIM.
The frequency at which these messages are sent can be configured. In most cases, the
user sends these echo request packets every 30 s. The keep-alive timer that is used
by the LIM does not have to be the same as the one used by the user.

7.6 DHCP
DHCP relay
DHCP at layer 3 is a user access protocol that enables DHCP servers to configure
internet hosts. The network element provides DHCP relay functionality in the
IP-aware bridge and router modes for both IPoE and IPoA user access interfaces.
DHCP relay functionality can be subdivided into two main components:
DHCP relay port
DHCP relay agent
The DHCP relay port on the network element performs the following:
upstream: add option 82 (if enabled)
downstream: remove option 82
The DHCP relay agent on the network element acts as the DHCP relay agent for
subscribers. In the upstream direction, broadcast DHCP messages received from
users are unicasted to the configured DHCP servers of the virtual router associated
with the user interface. In the downstream direction, unicast messages received from
the DHCP server are either unicasted or broadcasted (based on the broadcast flag) to
the correct user interfaces.
The DHCP relay agent function and the option-82 insertion can be individually
enabled/disabled per virtual router.
Option 82 handling
In layer 3, option 82 provides security when DHCP is used in public access networks.
In addition to enabling or disabling Option 82, you can configure the circuit ID to
identify the ingress PVC and the remote ID derived from the customer ID that is
configured on the ingress DSL line.
You can enable or disable the option 82 feature in upstream DHCP messages for each
DHCP relay agent. If enabled, option 82 parameters are inserted both for unicast and
broadcast DHCP messages.
The insertion of the circuit ID and the remote ID can also be enabled and disabled
separately. The remote ID is fully configurable for each DSL line or ATM PVC by
the operator (string with a length between 0 and 32 bytes). It is used to identify the
customer device at the remote end of the circuit.
By default, the circuit ID is auto-generated by the network element and contains
information used to identify the precise circuit (for example, DSL line and ATM
PVC) from which the DHCP message originates. With the network element, you can
enable or disable the circuit ID. You can insert the customer information that was
intended for the remote ID into the circuit ID. In this case, the remote ID is not sent.
If customer information is not configured on a given DSL line or PVC, the remote
ID (or configurable circuit ID) is sent with a NULL value for that DSL line/PVC.

7.7 IGMP
For more information about IGMP refer to chapter 10.2.

8 Security
8.1 IP address anti-spoofing 8-2
8.2 Secured MAC learning 8-2
8.3 Management channel security 8-4
8.4 Miscellaneous Security Features 8-9

8 Security
8.1 IP address anti-spoofing
IP address anti-spoofing is performed by the network processor on the LIMs in the

upstream IP-aware bridge mode. The NE provides IP anti-spoofing for:
User data packets: IP packets received from a user interface are discarded if
source IP address of the IP packet is not learned on the same user interface (by
way of configuration, by way of DHCP or by way of PPPoE).
ARP: If the user is not learned on the incoming interface, the ARP message is
discarded.
IGMP: IGMP messages from users that are not learned by the NE on the
incoming interface are discarded.
DHCP: IP anti-spoofing is also applied to the DHCP packets received from the
user interfaces before they are forwarded further upstream. DHCP packets are
discarded in the following cases:
DHCP packets with ciaddr/=0 while the user (ciaddr) was not learned by the NE on
the incoming interface.
DHCP packets with giaddr/=0 (relay agent at the user side) while the relay agent
(giaddr) was not learned on the incoming interface.
8.2 Secured MAC learning
When a frame is received with an unknown MAC Source Address (SA) or the MAC
SA is received on a different bridge port than previously learned, the NE will learn
this MAC address with the following restrictions:
If the MAC address is learned on a bridge port and the number of MAC addresses
already learned on that bridge port has reached a certain maximum, the MAC
address is not learned and the frame is dropped.
Note: The secured MAC learning mechanism can be disabled to allow, e.g. in
case of cross-connect mode, an unlimited number of MAC addresses.
If the MAC address is learned on a bridge port, and the same MAC address is
already learned on an Ethernet network interface in the same VLAN as the bridge
port, the MAC address is not learned and the frame is dropped (MAC address
duplication).
If the MAC address is learned on a bridge port, and the same MAC address was
already on another bridge port, and both bridge ports are in the same VLAN, the
new MAC address is not learned and the frame is dropped (MAC address
duplication).
If the MAC address is first learned on a bridge port, and then on an Ethernet
network interface, this movement is accepted and the MAC address is learned.
This means that the MAC address is removed on the bridge port (MAC address
movement).
Well-known MAC addresses (for example, multicast MAC addresses, MAC
addresses allocated for IEEE protocols, and so on) are not learned.

8 Security
Note These restrictions are valid in both iBridge mode and VLAN
cross-connect mode.
These principles apply also for subtending ports. In this context, a subtending port
behaves at the same level as a bridge port.
Only independent VLAN learning is supported. This means that a MAC address is
unique within a VLAN, but not across VLANs. If a port is connected to two VLANs,
the MAC address is learned twice.

8 Security
8.3 Management channel security
General
Both the IACM and SHub subsystem have their own management channels, but all
direct management access to the SHub subsystem is closed:
The software and database of the SHub subsystem are integrated in the software
and database of the IACM subsystem.
There is a single SNMP interface and IP address for both the IACM and the SHub
subsystem.
In order to make the ISAM securely managed, the operator must make sure that:
1 the ISAM works in single IP address mode
2 the secure variant of the used management channels are used. Unused
management channels must be closed.
Management channels
The following management channels on the IACM subsystem can be secured (refer
to Figure 8-1):
Simple Network Management Protocol (SNMP)
Can be secured by way of SNMPv3
Command Line Interface (CLI)
Can be secured by way of Secure Shell (SSH)
Transaction Language 1 (TL1)
Can be secured by way of SSH
Trivial File Transfer Protocol (TFTP)
Can be secured by way of Secured File Transfer Protocol (SFTP)
Figure 8-1 Secure and insecure management channels

Individual security control per management channel
RS232 serial interface

CLI TL1 SNMP File Transfer
CLI TL1 SNMP SNMP client server client server

Agent Agent v1/ 2 v3 TFTP SFTP
SNMP
Telnet SSH Telnet SSH 2361 161/ 162 69
server server server server
23 22 1123 1022 115
TCP TCP UDP UDP UDP TCP
Insecure Secure Secure Insecure Insecure Secure Insecure Secure
Note: TL1/TCP is only used in combination with SSH Mutually exclusive

8 Security
Simple Network Time Protocol (SNTP) does not have a secure variant. It is
configured to listen to a single SNTP server (the EMS). This configuration is done
by way of one of the above-listed management channels. Since these channels can
be secured by the operator, the SNTP configuration can be secured.
Apart from TFTP and SFTP, the system allows both the secure and insecure variant
to coexist so that the operator is able to contact the system in case the security setup
fails.
Encryption and authentication

Both SSH/SFTP and SNMPv3 support encryption and authentication. Table 8-1
shows the supported combinations.
Table 8-1 Supported SSH and SNMP Authentication and Encryption Schemes
Security Encryption Authentication Authentication Combinations

protocol algorithm algorithm mechanism
SSH/SFTP 3DES, blowfish, Hmac-sha-1, Username/password Nothing

AES, DES-56 hmac-sha-1-96 Username/public&Priva Encryption
te Key only
Authorization
only
Encryption
and
authorization
SNMPv3 DES-56 Hmac-sha-1, Username/password Nothing

hmac-md5 Note: Different Authorization
password per SNMP only
engine. Encryption
and
authorization
The username/password combinations of SSH and SNMPv3 can not be reused.
Security configuration
The configuration of the initial security parameters and usernames in the system is
done by way of CLI. Only the operator with security administrator rights has the
authorization to change the security configuration and to add or remove users.
Once the secure channel has been setup, the SNMPv3 parameters can also be
configured by way of the secured SNMPv3. For TL1 and CLI, the security
configuration remains a privilege of the security administrator (concept known in
both TL1 and CLI).
Default user name and password

Two command session interfaces (CLI and TL1) are available to the operator to
configure the system. The operator has access to both interfaces using the default
user name and password.
For security purposes, the default user name and password must be changed. The
system will prompt the operator to do this when he logs in for the first time.

8 Security
SNMPv3
The Simple Network Manager Protocol (SNMP) is used by element managers like
AWS or AMS to manage the 7302 ISAM or the 7330 ISAM FTTN.
Three versions of SNMP exist:
SNMP version 1 (SNMPv1) uses a community string (that is, a plain-text
password in the SNMP messages) to verify if a request may be executed or not.
This is very insecure.
SNMP version2 (SNMPv2) has the same syntax and security level as SNMPv1,
but has more commands, more error codes, different trap, and improved response
SNMP version 3 (SNMPv3) provides authentication, privacy and administration
for safe configuration and control operation. SNMPv3 also offers
transaction-by-transaction security configuration settings.
Note All three versions are supported in the NE.
SNMPv3 security mechanisms

The security mechanisms defined in SNMPv3 protect against threats as masquerade,
modification of information, message stream modification, and disclosure and
provide:
data origin authentication
data integrity checks
timeliness indicator
encryption
Security levels
SNMPv3 allows for three different security levels. Messages between agent and
manager can be:
1 unauthenticated and unencrypted
2 authenticated but unencrypted
3 both authenticated and encrypted

8 Security
Security implementation
SNMPv3 implements security by adding a security header to a standard SNMP PDU,
allowing entities to support non-SNMPv3-aware agents and managers; see Figure
8-2.
Figure 8-2 SNMP Message Format Evolution

Requests
SNMPv1
SNMPv1 PDU Get/ Set/
Get-Next
Add. version Commu- - PDU- ReqID Error Error
Var-bindings: name - value Trap different
nity Type Status Index
SNMPv2 SNMPv2 PDU

PDU-
Add. version Commu- ReqID ~ type ~ type Var-bindings: name - value Get/ Set/
nity Type
Get-Next/
Used for relay to
Backwards compatible for Get-Bulk/
ASAM or SHUB SNMPv1 requests, except trap Inform/
Report
SNMPv3 SNMPv3 PDU = SNMPv2 PDU Trap
Global Security Ctxt Ctxt PDU-
params params EngId Name Type ReqID ~ type ~ type Var-bindings: name - value
Global params: version, msgId, msgMaxSize, msgFlags, msgSecurityModel

Security params: AuthoritEngineId, AuthoritEngBoots, AuthoritEngTime, msgUserName, AuthParams, PrivParams
Security related capabilities

SNMPv3 defines two security-related capabilities:
1 User-based Security Model (USM)
The USM provides authentication and privacy (encryption) functions and
operates at the message level. In addition, it includes a key management
capability that provides for key localization and key updates. The USM is used
to authenticate entities, and provides encryption services to secure
communication between agents and managers. Each agent keeps track of the
authorized user allowable access via an internal table of user/secrets/access
entries. Both authentication and encryption utilize symmetric keys, which can be
generated from a password. Localization of the authentication and encryption
keys by hashing the generated key with the ID of each agent entity is strongly
recommended.
2 View-based Access Control Model (VACM)
The VACM verifies that a given user is allowed to access a particular MIB object
and perform particular functions (MIB views: read, write or notify access). The
VACM makes an access control decision on the basis of:
the principal asking for access
the security model and security level used for communicating the request
the context to which access is requested
the type of access requested (read, write, notify)
the actual object to which access is requested.

8 Security
Secure shell
Secure Shell (SSH) is a protocol that provides authentication, encryption, and data
integrity to secure network communications. On top of this protocol, SSH
implementations offer secure replacements for rsh, rlogin, rcp, ftp, and telnet, all of
which transmit data over the network as clear text. In addition, it offers secure
data-tunneling services for TCP/IP-based applications.
The NE uses the Interpeak SSH framework.
SSH protocol
The SSH 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). In case of TCP,
it always uses TCP port 22.
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.
SSH capabilities
The main capabilities of SSH are:
Secure command shell (ssh)
This secure version of the typical shell allows commands and applications to be
executed from the command-line.
Secure file transfer (SFTP)
This is a separate protocol layered over the SSH protocol to handle file transfers.
Supported services include file transfer in both directions, directory listings,
creation and removal of directories and files, and so on. It has the following
advantages over traditional (T)FTP:
SFTP encrypts both username/password and data.
SFTP uses the same port as the SSH server (no need to open an additional port).

8 Security
SSH architecture
SSH has a client-server architecture. The NE acts as the SSH server toward the
manager; see Figure 8-3.
Figure 8-3 SSH client-server architecture in the NE
SSH Appl. protocol

SSH CLI SSH CLI
client appl server appl
SSH transport
ssh client ssh server
authentic, conn.
DB of client
EMS pubKeys or pwds
ISAM
Server authentication
Secure link for CLI/TL1 SSH

SSH
client Server
ISAM pubkey
Client authentic
InterPeak
SFTP ISAM privkey
Secure link for SFTP
Server
SFTP supported algos
client
SFTP
SFTP client
File Client
uname/pwd
S
SFTP
Secure link for SW&DB Server Secure link for the transfer
from FileServer to ISAM
(SW&dDB)
SFTP Appl. protocol

SFTP server SFTP client
appl appl
SSH transport, authentic,
connection protocol
8.4 Miscellaneous Security Features
Some miscellaneous security features are listed below:

No user-to-user communication:
fixed for iBridge and IP-aware bridge
configurable for IP router
In iBridge mode: the downstream packets can be discarded. This is configurable
per VLAN
In iBridge, IP-aware bridge and IP router mode: downstream packets can only be
forwarded to the user port if the user MAC address has already been learnt via a
preliminary DHCP discovery message

8 Security

9 RADIUS
9.2 RADIUS Features 9-2
9.3 RADIUS server and proxy 9-3
9.4 Operator authentication via RADIUS 9-5
9.5 Encryption of authentication data 9-6

9 RADIUS
9.1 Introduction
Remote Authentication Dial-in User Service (RADIUS) is a standardized method of

information exchange between a device that provides network access to users
(RADIUS clients) and a device that contains authentication and profile information
for the users (RADIUS server). The NE supports RADIUS for both layer 2 and layer
3 forwarding.
Authentication via RADIUS provides the following advantages:
Password management is centralized so there are fewer password databases and
passwords to maintain.
It is easy to support strong authentication in a cost-effective way. The same
RADIUS server or a backend authentication server supports strong
authentication. In the case of local authentication, strong authentication may not
be feasible.
9.2 RADIUS Features
The following features are supported:

User authentication via an external RADIUS authentication server.
The RADIUS Authentication client:
encrypts all password fields in the messages.
supports multiple RADIUS Authentication servers.
A flexible authentication mechanism:
Support of Password Authentication Protocol (PAP) and Challenge-Handshake
Authentication Protocol (CHAP) authentication
Support of Extensible Authentication Protocol (EAP)
RADIUS authentication for CLI and TL1 users
User authentication via external RADIUS servers
Fall back to local authentication when no RADIUS server is available.
Fallback to a configurable default operator profile when the RADIUS server does
not support vendor specific attribute..

9 RADIUS
9.3 RADIUS server and proxy
Two applications on the LIM need authentication: 802.1x and PPP server.
These applications will use the internal communication to contact NT control (see
Figure 9-1). NT control will contact a RADIUS server outside the ISAM or it can use
a local authentication database (only for PPP). In the former case, NT control is
behaving as a RADIUS client.
Figure 9-1 RADIUS on LIM, NT, and SHub subsystem

Applications like 802.1x A RADIUS packet from NT control on the Internal OAM
and PPP server talk via VLAN is handled by the RADIUS proxy.
the internal OAM VLAN A RADIUS packet from NT control on the External OAM
to NT control to perform VLAN is bridged.
authentication
LIM Ethernet RADIUS

SHub ER
server
RADIUS
CPE NT
LIM
CPE control
When an application requests for authentication, NT control will

perform authentication using the local authentication database,
or it will use RADIUS.
In case of RADIUS, the external OAM VLAN is used to contact an
external RADIUS server, or the internal OAM VLAN is used
towards the SHub, which will perform RADIUSproxy.
The RADIUS client in NT control selects the RADIUS servers based on the domain
name. This domain name maps to a certain RADIUS server policy. In the RADIUS
server policy, the IP addresses of the RADIUS servers are found. To route the
RADIUS packets towards the RADIUS servers, an IP lookup has to be done. This
requires that also the VRF is configured in the RADIUS server policy and this VRF
must contain a route (e.g., a static route) towards the RADIUS server(s).
NT control can contact RADIUS servers over the internal OAM VLAN, and over the
external OAM VLAN.
If the internal OAM VLAN is used, then NT control addresses the RADIUS
proxy on the SHub, and this one contacts the RADIUS servers of the ISPs over .
If the external OAM VLAN is used, then NT control addresses the external
RADIUS server directly.
The RADIUS proxy IP forwards the RADIUS packet to the RADIUS server.
Therefore, the routes towards the RADIUS servers are configured in the VRF of
SHub. The RADIUS client passes the selected RADIUS server IP address and VRF
in a proprietary tag, defined in the RADIUS messages, to the RADIUS proxy. The
RADIUS proxy removes the proprietary tag and forwards the RADIUS message to
the RADIUS server specified in the proprietary tag.
In case of RADIUS server redundancy, the RADIUS client on NT control will take
care of that and the proxy is not aware of this redundancy.

9 RADIUS
The communication between NT control and the RADIUS proxy on the SHub goes
over the internal OAM VLAN. NT control will use a local IP address as IP SA, the
RADIUS proxy on the SHub will replace it by its own global IP address (configured
on the outgoing VLAN) as IP source address.
Note: this IP address is also used for DHCP relay.
When a packet is sent from the RADIUS server to the ISAM, then in case of the
external OAM VLAN, the IP and MAC destination address will be those of NT
control. Hence, the packet is bridged at the SHub.
If the packet is sent from the RADIUS server to the ISAM over another VLAN than
the external OAM VLAN, the IP and MAC destination address will be those of the
SHub. When the RADIUS proxy receives a packet from the network, it will be sent
to NT control over the internal OAM VLAN.

9 RADIUS
9.4 Operator authentication via RADIUS
CLI and TL1 operators can be authenticated either locally on each DSLAM or
remotely centralized at a RADIUS server. There is one restriction: if CLI or TL1 over
SSH with key authentication is used, the authentication has to be done locally as
RADIUS does not support keys.
This functionality is only supported for CLI and TL1. It does not apply for SNMP
operators as SNMP does not work with the concept of session. That would mean that,
for each SNMP request, communication with a RADIUS server would have to be
setup to authenticate the originator. In case of CLI and TL1, the authentication occurs
once for a complete session.
A centralized authentication server has a lot of benefits for the management of
operator accounts, but is a danger with regard to availability and security. It is
advisable to support redundant RADIUS servers (this is supported by the ISAM). In
addition, the ISAM will fallback to local authentication in case the communication
with the RADIUS server fails.
As an operator will either choose for local or centralized authentication, typically the
local database will only contain the administrator account in case RADIUS is used.
To prevent isolation, the operator can configure one default local operator profile
that applies when RADIUS is not reachable and the operator is not configured in the
local database.
Figure 9-2 Operator Authentication via RADIUS
EMS
CPE Ethernet
LIM SHub ER RADIUS
CPE server
RADIUS
NT
control
When a CLI or TL1 operator requests for authentication, NT control will perform
authentication using the local authentication database, or it will use RADIUS.
In case of RADIUS, the external OAM VLAN is used to contact an external
RADIUS server, or the internal OAM VLAN is used towards the SHub,
which will perform RADIUS proxy.

9 RADIUS
9.5 Encryption of authentication data
Passwords, RADIUS secrets and possible other authentication data are encrypted in
such a way in the system database that the plain form can not be derived from it
where this is not required for normal operation (for example, passwords for PAP
local authentication). In cases where it is necessary to retrieve the plain text form,
adequate encryption avoiding unauthorized retrieval is used. This applies for all
authentication on the management and user interfaces.

10 Multicast and IGMP
10.1 Overview 10-2
10.2 IGMP on the NE 10-6
10.3 Cross-VLAN and Intra-VLAN multicast 10-10
10.4 Multicast and IGMP parameters 10-12
10.5 Multicast on IPoA 10-16
10.6 Pay per view 10-16

10.1 Overview
Multicast is the transmission from a single device (such as an IPTV host) to a group
of recipients (such as xDSL subscribers). 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.
Actually, there are three versions of IGMP:
IGMP version 1 (IGMPv1) is described in RFC 1112
The network element:
supports IGMPv1 and IGMPv2 on the user interface.
When IGMPv3 is received from a user, the network element queries in IGMPv2.
At the network side, IGMPv1 is not supported. When a user uses IGMPv1, the
network element uses IGMPv2 toward the network. IGMPv1 is discarded by the
network element when it is received from the network.
supports fast IGMP zapping
enables user configurable limits to the number of multicast streams that can be
configured on an xDSL line.
You can configure the maximum number of multicast streams allowed on an
xDSL line to ensure that enough bandwidth is available for multicast services on
that line.
supports up to 1024 multicast streams
For information about commands handling IGMP, refer to the Operations and
Maintenance using CLI and the CLI Commands documents.

Multicast service description

The typical Multicast service model of the NE is shown in Figure 10-1.
Figure 10-1 IGMP and Multicast service

Multicast Stream
Multicast IP Network
Source
Multicast
IGMP
Stream
NE 1
Multicast Multicast Multicast

IGMP IGMP IGMP
Stream Stream Stream
End User1 End User2 NE 2
Multicast Multicast
IGMP IGMP
Stream Stream
End User3 NE 3
Multicast
IGMP
Stream
End User4
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
IGMP, which 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 and
further L2 encapsulated.
Multicast streams are preformatted in the correct IP multicast encapsulation and then
launched into the IP network. Typically, there is a multicast stream for each package
or group of services provided by the multicast source. Users are assigned to the
multicast group that corresponds to a particular multicast stream in order to receive
those services.
Table 10-1 lists the three types of IGMP messages related to the host-router
interaction.
Table 10-1 IGMP messages
Message Description
Membership query General membership query A query from the router asking hosts to respond
with all groups that they require. Used to learn
group members.
Group specific query A query from the router asking hosts if they are
listening to a specific group. Used to learn if a
particular group has any members.
(1 of 2)

Message Description
Membership report Used by hosts to join a multicast stream or to

respond to general or specific membership
queries.
Leave group message Used by hosts to inform the router that a specific
stream is no longer required.
(2 of 2)
Multicast streams are only sent to the network element when at least one user who is
a member of that multicast group is connected to the network element over the xDSL
link. If no group members are connected, the multicast stream is not routed toward
the network element.
The IGMP packets are intercepted to identify the outgoing ports (PVCs) for each
multicast group for which there is at least one receiver. In this way, multicast data
packets will only be routed to those users who have subscribed to that particular
multicast group.
The multicast MAC destination address and VLAN ID are used to forward the
multicast streams, not IGMP packets. Multicast streams can only be sent
downstream and are never tagged by the network element. Multicast streams are
received as tagged packets from the service provider, but untagged by the NE before
forwarding them to the end user.
Multicast streams can be configured statically or created dynamically at the network
side using IGMP. At the user side, only dynamic multicast streams are supported.
The NE may receive a particular multicast stream through dynamic or static
connections:
Dynamic connection
Multicast streams are sent to the NE only on request meaning that at least one
member of the related group is connecting to the NE (by DSL or by way of
subtending NE). This is typically done through the IGMP protocol.
If not, the multicast stream is not directed toward the NE. At the network side, the
NE supports only IGMPv2.
Static connection
The multicast stream is sent to the NE through a configured static connection. The
multicast stream is terminated on the SHub subsystem.
An end user joins a multicast group by means of the IGMP protocol. Only IGMPv2
is supported on the end user interface.
In the case where an IGMPv3 message is received from a end user, the NE forces the
end user to switch to IGMPv2 Host Compatibility mode by sending an IGMPv2
query.
In the case where an IGMPv1 message is received from an end user, the network
element uses IGMPv2 toward the network.
For each multicast group, IGMP packets are intercepted to identify the outgoing
ports (subtending NE and end user ports). In this way, multicast data packets are only
sent to those end users who have subscribed to that particular multicast group.

Inside the NE, the multicast forwarding (multicast streams) is based on the Multicast
MAC destination address together with the multicast service provider VLAN ID
(layer 2 interfaces) or the multicast IP destination address (layer 3 interfaces).
The NE does not allow an end user to behave as a source for multicast stream
forwarding. Multicast streams are only accepted in the downstream direction.
Multiple PVCs in one xDSL line

An xDSL line can have up to four PVCs. However, only one PVC can be enabled to
support the multicast service. The NE does not support multicast for a PPPoE
interface
Some examples of possible network models are shown in Figure 10-2.
Figure 10-2 Example network models
One PVC per DSL line

ISAM
CPE
Single PVC PPPoE or IPoE VLAN
RE
Multiple PVCs per DSL line

ISAM
CPE IPoE VLAN

IP RE
RE
PPPoE
PPPoE VLAN
CPE maps a port or an internal connection

(Voice terminal, Management channel) on a PVC
The working assumptions of the multiple PVC usage network model are:
downstream IP packets and PPPoE packets are identified to different PVCs by the
user CPE
no upstream PPPoE packets in the PVC that has been configured to be in IPoE
usage
no upstream IPoE packets in the PVC that has been configured to be in PPPoE
usage
each PVC in an ADSL line must have a separate default VLAN ID

10.2 IGMP on the NE
To reduce IGMP message communication to the network and to ensure faster

zapping responses, a distributed IGMP architecture is implemented in the network
element. The distributed IGMP architecture includes the following:
an IGMP proxy function, which is mapped to the interworking function
an enhanced IGMP snooping function, which is mapped to the aggregation
function
IGMP proxy
IGMP proxy is supported and used on the LIM of the network element. IGMP proxy
is supported on iBridge (RB VLANs), in the residential cross-connect forwarding
(C-VLAN) and on the IP aware bridge (IP interfaces). It is situated between two
IGMP networks and sends membership reports and leaves messages upstream as
required by the downstream users. IGMP proxy also replies to group specific and
general membership queries on behalf of downstream users. IGMP proxy sends
group-specific and general membership queries to downstream users to determine
which channels need to be sent to which ports. All messages sent by the proxy device
use the MAC and IP addresses of the device.
The network element functions as an IGMP proxy to the network, allowing end users
to announce their interest in multicast group memberships to the network. The main
functions of the IGMP proxy in the network element are:
responding to IGMP queries received from the network, with a single
membership report for each multicast stream to which end users have subscribed
sending IGMP queries at regular intervals to the end users; the transmission of
these IGMP queries is equally distributed in time over all the end user ports to
avoid overload situations
handling IGMP membership reports and leave requests received from the end
user; multicast replication trees are created on both the aggregation and the
interworking function
The IGMP proxy is mapped to the interworking function with the following
parameters:
support for IGMPv2 (IGMPv3-friendly behaviour)
IGMPv1 is partly supported at the end user side
ability to enable or disable IGMP on a port basis
support for IGMP Fast Leave with host tracking
content and rate-based admission control
a maximum of 256 simultaneously active multicast streams on the LIM
a maximum of 10 simultaneously active multicast streams per end user port.

multicast streams in the network element are either preconfigured or

nonconfigured:
Pre-configured multicast streams
The multicast streams are distributed in a dedicated VLAN (the VLAN of
the multicast service provider). The network element records the VLAN ID
assigned to the port in which join and leave messages are received and
forwards the IGMP packets to the network using the PVID of the multicast
service provider. The multicast stream is sent to the network element within
the PVID of the multicast service provider. This method of multicast
forwarding is called cross-VLAN multicast forwarding.
Pre-configured multicast streams are subject to CAC.
Properties of the preconfigured multicast groups, including dedicated
VLAN, multicast IP destination address, and bandwidth, are provisioned in
the system by way of the management plane. A maximum of 1024 multicast
groups can be configured by way of the management plane.
Non-configured multicast streams
End users are connected to the network element with the VLAN of their
corresponding NSP. The IGMP packets and multicast streams are forwarded
and carried in this VLAN. This method of multicast forwarding is called
intra-VLAN multicast forwarding.
support for multicast stream reserve period:
the multicast stream is reserved during well-defined time periods by the LIM, rather
than sending a leave message when there are no more membership requests
avoids frequent leaving and joining of a multicast stream toward the network
IGMP snooping
You can configure IGMP snooping, virtual LAN router port-related parameters, and
the virtual LAN filter for IGMP snooping for a particular VLAN.
The IGMP snooping function is mapped to the aggregation function with the
following parameters:
enhanced IGMP snooping, including the ability to avoid IGMP report avalanches
support for IGMPv2
support for static multicast streams
support for dynamic multicast streams
a maximum of 1024 simultaneously active multicast streams
support for fast leave

IGMP modes
Table 10-2 describes the IGMP proxy behaviour depending on the different
forwarding models.
Table 10-2 Supported IGMP modes
Mode Description
Residential IGMP proxy is supported for pre-configured multicast streams

Cross-Connect IGMP packets for non-configured streams are transparently
forwarding model forwarded (IGMP Proxy is not supported)
IP aware forwarding IGMP proxy is supported for pre-configured multicast streams
model (IPoE & IPoA) IGMP packets for non-configured streams are dropped
(non-configured streams are not supported)
iBridge forwarding IGMP proxy is supported for pre-configured multicast streams
model IGMP proxy is supported for non-configured multicast streams
PPPoE termination IGMP proxy is not supported
Cross-connect & IGMP packets are transparently forwarded (IGMP proxy is not supported)
PPPoE Relay
Figure 10-3 shows the supported IGMP modes in the network element.
Figure 10-3 Supported IGMP modes
Network NE User CPE
IGMP IGMP
IP IGMP in cross-connect IP
PPP PPP
PPPoE PPPoE
ETH ETH ETH ETH
Lower Lower Lower Lower
layers layers layers layers
IGMP IGMP
IP IGMP on top of PPPoE relay IP
PPP PPP
PPPoE PPPoE
ETH ETH ETH ETH
IGMP on the IPoA interface

IGMP IGMP IGMP IGMP
IP IP
IP IP
ETH ETH
IP over Ethernet iBridge

IGMP IGMP IGMP
IGMP
IP IP IP
IP
ETH ETH ETH
ETH
Lower Lower Lower
Lower
layers layers layers
layers

In cross-connect IGMP and IGMP over PPPoE relay modes, the IGMP packets are
forwarded transparently by the network element. In IGMP over IPoE mode, the
replication of the multicast streams is done by both the SHub subsystem and LIM. In
this case, IGMP is handled at the SHub subsystem and on all the LIMs. The LIM
functions as a router toward the users and as a host toward the network. The SHub
subsystem snoops the IGMP traffic between the LIMs and the network. Both router
and host functions on the LIM act independently of each other, queries sent to users
can be independent of receiving queries from the NT/SHub subsystem.
IGMP functions
There are two main functions performed by IGMP: handling of general IGMP
inquiries and IGMP zapping.
When the network interfaces of the network element receive a general IGMP query
from a network router, the IGMP proxy responds to the query and sends an IGMP
membership report message toward the network for each multicast group to which it
is subscribed.
IGMP zapping occurs when a user subscribes to a specific multicast stream, and then
unsubscribes from that multicast stream. When a user changes from one multicast
stream to another multicast stream, they unsubscribe from one stream, then subscribe
to another. A zap request is a combination of a leave message and two consecutive
report messages.
The network element implements an IGMP proxy to aggregate the IGMP reports
from users and limits the amount of IGMP messages at the network side. The
network element implements an integrated IGMP proxy.

10.3 Cross-VLAN and Intra-VLAN multicast
The network element supports the two multicast VLAN models, as described in
Table 10-3.
Table 10-3 VLAN models supported by multicast
Model Description
Cross-VLAN Multicast is delivered on a VLAN different from the one to which the user is
connected. All membership groups must be configured.
Intra-VLAN Multicast is delivered on the same VLAN as the one to which the user is
connected. Both configured and unconfigured groups are supported.
When the network element receives a join/leave request from the user, it performs a
query in the multicast source table with a key equal to the group IP address. There
are two ways the network element can resolve the routing request. The network
element performs:
cross-VLAN multicast routing if a matching entry in the multicast source table is
found
intra-VLAN multicast routing if a matching entry is not found
When a matching entry is found, the network element sets a tag in the join/leave
frame with the VLAN ID from the record. Further communication with the network
is performed with that VLAN ID. The multicast stream is then sent to the VLAN with
the replaced ID.
There is always a VLAN ID in the multicast source table. If the multicast group
requested by the user appears in the multicast source table, the VLAN ID in the tag
of the received IGMP packet is replaced by the VLAN ID found in the multicast
source table. If no corresponding entry was found in the multicast source table, the
IGMP packet is forwarded within the VLAN as it was tagged when it entered the
network element.
The network element performs intra-VLAN multicast routing if the multicast source
table query yields no matching result. The system records the VLAN ID in the
join/leave request from the default VLAN ID assigned to the port from which the
join/leave request originated (in case no VLAN ID is present). This VLAN is then
used for further communication with the network.
When the join/leave request comes from the cascading interface, this means that the
request was received at the SHub subsystem and that the central processor on the
network element LIM has already checked the multicast source table. The
cross-VLAN and intra-VLAN checking is done at the LIM.
For pre-configured multicast streams, a preventive traffic control is adopted in the
network element when handling an IGMP join request. A user can join the requested
multicast stream only when the allocated bandwidth for multicast is sufficient to
accommodate the new stream.
Cross-VLAN network model

Figure 10-4 shows the cross-VLAN network model.

Figure 10-4 Cross-VLAN multicast network model

One PVC per DSL line
ISAM
CPE
Single PVC IPoE VLAN
RE
Multicast VLAN
IGMP control
IGMP
Multiple PVCs per DSL line

ISAM
CPE
IP IPoE VLAN
RE
Multicast VLAN
PPPoE IGMP control
IGMP
CPE maps a port or an internal connection

(Voice terminal, Management channel) on a PVC
If the user subscribes to a multicast group that is configured in the multicast source
table, the default VLAN ID of the user and the VLAN ID of the multicast source do
not need to be the same. When a user subscribes to a group within the multicast
group, the network element sends a join request to that group with the VLAN tag of
the multicast source provider.
If the user subscribes to a multicast group that is not configured in the multicast
source table, intra-VLAN multicast routing is performed, which means that the
multicast service can only be provided within a VLAN.
Cross-VLAN multicast routing has several advantages:
Cross-VLAN multicast routing for well-known multicast service groups can save
downstream bandwidth. For example, when a well-known multicast service
stream is requested by users from different VLANs, only one copy is needed.
With intra-VLAN multicast routing, several copies of that stream need to be sent
to the network element.
On the user side, you can have only one IGMP channel and one IPoE VLAN.

10.4 Multicast and IGMP parameters
Multicast and IGMP parameters must be configured in order to support cross-VLAN

and intra-VLAN multicast routing. These parameters inform the system about the
multicast sources, provide traffic parameters for join control, and provide control
parameters for user access control and channel control.
The network element supports multicast and IGMP parameters for the interworking
function and the aggregation function.
The interworking function

The multicast and IGMP objects used to configure and manage the IGMP proxy
function are stored in the NE database and presented in the following MIB tables or
groups:
Multicast source table
General group multicast parameters
IGMP package table
IGMP channel table
IGMP module table
Module multicast source expansion table
IGMP system parameters group
Multicast capacity parameters group
Multicast source table

All known multicast groups are configured in the network element multicast source
table. The multicast source table defines:
the package to which a multicast source belongs
the service provider VLAN in which the multicast stream must be requested
the traffic descriptors of a particular multicast stream (peak and mean bit rate)
whether or not fast leave is supported
The multicast table is used to:

determine the cross-VLAN multicast route and VLAN ID of the multicast source
provide traffic parameters for traffic control
identify the package attribute
identify whether the source supports fast channel change
The IGMP proxy uses the information from the multicast source table to check
whether an end user has enough resources available to receive the stream.
The multicast source table can support up to 1024 multicast group entries. The
multicast source table is the same for all network elements in the same cascade.
User authentication is determined using information in both the multicast source
table and the IGMP channel table.

General group multicast parameters

In the IGMP proxy model, it is possible that some multicast sources are not
configured in the network element. The network element must ensure that the users
of these multicast sources can join multicast groups if enough resources are available
and if the user and multicast source are within the same VLAN. The general group
multicast parameters table is defined for all the multicast groups that are not in the
multicast source table.
The parameters from this table are used to configure the characteristics of the
non-configured multicast streams. The general group multicast parameters table
defines:
whether access to nonconfigured multicast streams is allowed
the average traffic descriptors for nonconfigured multicast streams (peak and
mean bit rate)
whether fast leave for a nonconfigured multicast streams is allowed or not
IGMP package table

Bundling of multicast streams into packages is performed using the IGMP package
table. 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. Typical video packages can include news, sports, and movies.
The IGMP package table is intended primarily for use by a network element
manager, such as an AWS, to support multiple sets of multicast packages. Within the
functional scope of the NE, the package table is supported only as a mnemonic label
to identify the different packages and the associated AWS templates.
IGMP channel table

The IGMP channel table consists of multicast parameters as well as statistics and
counters related to IGMP and multicast for an end user port.
These parameters allow:
enabling the IGMP proxy function on an end user port
configuring the maximum number of multicast streams that can be active on this
end user port
configuring the permission bitmap, that is, which multicast packages are allowed
to be accessed on this end user port
User authentication is determined using information from both the multicast source
table and the IGMP channel table.

You can configure the characteristics of an IGMP channel by specifying a unique

port index, a VCI, and a VPI for each channel:
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
IGMP module table

The IGMP module table consists of statistics and counters related to IGMP proxy
and multicast per LIM module.
Module multicast source expansion table

The module multicast source expansion table consists of statistic objects that
measure the popularity of a specific multicast source on a per LIM board, that is,
when and how much the multicast stream is being watched by the end users. This
table is only for those streams configured in the multicast source table.
IGMP system parameters group

The group contains the parameters, default values, and ranges of the IGMP system
objects that are derived from RFC 2236 for the NE playing the role of a querier and
a host. These parameters are used to maintain active memberships of connected
multicast streams and to process IGMP report, leave, and query messages.
Multicast capacity parameters group

The multicast capacity parameters group consists of system-level multicast capacity
parameters, which are used for the access control when an end user wants to join a
multicast stream.
The objects in this group limit the total numbers of preconfigured and unconfigured
multicast streams. The total number of multicast streams is limited because of
hardware limitations.
In addition, objects in this group define the time the NE will remain subscribed to a
multicast stream, even if there is no membership subscription anymore. This applies
for preconfigured and unconfigured multicast groups.

Aggregation function
The objects used to configure and manage the enhanced IGMP snooping function are
presented in the following MIB tables or groups:
IGS system group
IGS VLAN group
VLAN-based multicast forwarding table
VLAN-based router port table
VLAN-based filter table
IGS system group

The IGS system group contains system parameters to configure the enhanced IGMP
snooping function:
enable/disable the IGMP snooping function
configure the source IP address and mode used to forward IGMP packets to the
network
configure the interval after which a learned router/host port will be purged
configure the interval within which the next report packets for the same multicast
stream will not be forwarded to the network
configure the leave response timer on a per VLAN basis
IGS VLAN group

The objects used to configure and manage the VLAN specific related IGMP
snooping function are presented in the following MIB tables or groups:

The VLAN-based multicast forwarding table contains VLAN based multicast
forwarding information learned when a VLAN is in the system. It contains the
VLAN ID, the multicast group address, and the list of ports who have members for
the multicast stream.

The VLAN-based router port table contains the list of bridge ports through which a
multicast service provider, in a particular VLAN, is reachable. In case of static
multicast streams, this table also allows you to configure the query interval time for
a particular multicast stream.

The VLAN-based filter table allows to disable the IGMP snooping function on a
specific VLAN.

10.5 Multicast on IPoA
The network element supports IGMP multicast on IPoA user interfaces when IP
forwarding is enabled. To support multicast routing on IPoA, user IP addresses are
used instead of user MAC addresses to distinguish between the users.
IGMP multicast on IPoA has the following characteristics:
IP anti-spoofing support; IGMP messages from users that are not learned by the
network element on the incoming interface are discarded.
auto-detection of the encapsulation type
support for configured multicast streams (video) only.
Multicast on IPoA does not support intra-VLAN multicast routing.
Nonconfigured multicast streams (internet) are not supported, since the default
VLAN that is used to send IGMP messages to the network for unknown multicast
streams, cannot be configured on IPoA interfaces.
10.6 Pay per view
The NE supports Pay Per View (PPV) services:

PPV events are multicasted on PPV channels.
The customer is given access to a certain PPV channel by including the channel
in a multicast package and subscribing the customer to that package.
PPV channels are billed for each individual PPV event the customer consumes.
Call Detail Records (CDRs) are generated based on the actual viewing behaviour
of the customer.
The customer can be provided with previews-channel capabilities to certain

multicast groups, so as to encourage them to subscribe to these multicast groups with
full access rights.
The NE exercisse preview-channel access rights control on each DSL line
independently.
The access rights for each of the multicast streams to each of the DSL lines are
managed by the Subscriber Management System (SMS), which provides suitable
open standard interface(s) for the operator .
For a particular multicast stream, the following DSL line entitlements are offered :
Full-view
The end user can join the multicast channel at any time with unlimited view
duration.
Pre-view
The end user can join the multicast stream with a limited pre-view frequency and
view duration.
No-view
The end user cannot join the multicast stream, neither in pre-view nor in full-view
mode.

When the end user has preview rights for a given multicast group, the end user can
freely access the channel up to some predefined period. The frequency of subsequent
previews shall be limited per end user so as to avoid service theft.
A preview session is controlled by the following attributes:
The maximum duration for the preview session:
Per multicast channel: from 1 to 6000 s in multiples of 1 s.
The maximum number of preview sessions per reset period:
Per multicast channel: from 1 to 100 times.
The blackout period after each preview:
The time the end user must wait before he can watch a next preview session for
the same multicast stream.
Per multicast channel: from 1 to 7200 s in multiples of 1 s.
The reset period:
A pre-defined period of time in which the maximum number of preview sessions
is restricted.
Configurable system-wide: with a specific time on a day of the week (1 to 7), or,
a day of the month (1 to 31). For example, the operator can reset the counter at a
specific time, say 04:00, on all Mondays or, on every 1st, 11th, 21st of the month.
The preview recognition time:
The minimum time that an end user must watch a preview session before it is
considered as to be counted with regerd to the maximum number of preview
session threshold per reset period.
Configurable system-wide per system basis: from 1 to 120 s in multiples of 1 s.
The recognition time is used to determine that the preview session is valid. That
is, when the duration on the preview channel is shorter than the preview
recognition time, the preview counter is not increased and the blackout duration
timeout is not started.
The Call Data Record (CDR) recognition time:
The minimum time an end user must watch a preview session befor it is
considered for CDR generation. This attribute applies to full-view sessions too.
In order to support the operator with an overview of the multicast join and leave
activities on the DSL line (for example, for billing purposes, to distinguish between
popular and non-popular multicast streams and so on), the ISAM generates
autonomously CDR records whenever a DSL line initiates:
A subscription for a preview session
A subscription for a full-view session
A subsription outside its access rights
A subscription fro a preview session and the max number threshold has been
exceeded
A subscription for a preview session during the black-out period.

A CDR record reports:

the Multicast stream being subscribed
the entitlement of the multicast stream being subscribed
the start time
the view duration
the DSL line reference.
The generated CDR records are temporarely stored in a volatile memory buffer on
the LT board. At periodic time intervals, these memory buffers are retrieved by the
NT board which stores these CDR records in a compressed format in a file and
dedicated partition on the system disk. This partition may keep up to 8 hours of
generated CDR records.
An external management platform will periodically (typically 4 hours) request the
ISAM to transfer the compressed CDR files (by means of the TFTP protocol). This
external management platform is responsible to do any further correlation.

11 Quality of Service
11.2 Upstream QoS 11-3
11.3 Downstream QoS 11-4
11.4 Traffic classes 11-4
11.5 Queuing, scheduling, policing and BAC 11-5
11.6 QoS profiles 11-10
11.7 Policy framework 11-14
11.8 Subtending model 11-15

11.1 Introduction
In addition to delivering best-effort, high-speed Internet services, xDSL access

networks are evolving to multiservice access networks that must be capable of
supporting a whole range of services, such as:
conversational services (Voice over IP (VoIP), video telephony)
video services (Video on Demand (VoD), Broadcast TV)
transparent LAN services for business customers
data services for business customers
data services for residential customers
These services must be delivered with the appropriate level of QoS. In the case of
xDSL access networks with Ethernet aggregation, there are a number of network
elements, for example, BRAS, IP edge routers, 7302 ISAM, or CPE, that must each
give the correct priority treatment to the various application flows.
This is achieved by classifying these application flows at the ingress of the network
into a limited set of aggregate flows that are characterized by certain QoS markings.
The different network elements will then provide per-QoS class queuing and
scheduling for these aggregate flows.
The following section provides an overview of the role played by the network
element in end-to-end QoS.

11.2 Upstream QoS
From a high-level point of view, packets may be subject to the following traffic
engineering steps while traversing the NE in the upstream direction. On the
subscriber interfaces at ingress the following applies:
Traffic filtering by way of Access Control Lists (ACLs)
It is possible to filter out certain packet flows based on multi-field classification
at layer 3/4 or layer 2
DSCP or p-bit marking
A number of DSCP or p-bit marking possibilities exist:
The simplest one is to not perform any DSCP or p-bit marking at all. This implies
that QoS markings received from the end user are accepted as they arrive. This
possibility is useful in case of trusted end user devices (for example, in a business
context).
A variation on this theme is the enforcement of a DSCP or p-bit marking contract.
In this case, QoS markings received from the end user are taken into account, but
they are subject to a contract that specifies what DSCP or p-bit markings are allowed
and what QoS markings need to be re-marked. In essence, this functionality
provides support for correct marking in case of multi-QoS Service Access Points
(SAPs).
Default DSCP or p-bit marking. In this case, all packets on the interface will be
re-marked to the configured value.
In addition to the above, it is possible to use multifield classification into QoS
subflows, and (re-)mark packets that belong to the subflow.
Ingress policing
End users are subject to certain traffic contracts that specify how much traffic
they can send towards the network. To enforce these contracts, policers will be
installed. A policer may apply to an entire subscriber interface or to QoS subflows
within the subscriber interface. In this context, a QoS subflow (or subclass) is
defined as all the packets flowing through the interface that are bound by a
subcontract and desire a specific common treatment. Out-of-profile traffic can be
subject to packet drop, but also to color remarking.
After traffic engineering on the ingress interfaces of the LIMs, packets will be
forwarded in the context of a Virtual bridge, VR, or VLAN X-connection. Finally,
packets will be subject to per-QoS class queuing and scheduling at the egress
interfaces of the SHub subsystem.

11.3 Downstream QoS
In the downstream direction, frames ususally arrive in the NE with DSCP or P-bits
that are properly marked by service-aware edge devices (BRAS, edge-router,
application gateway, and so on). If this is not practical for some reason, the SHub can
align the P-bits to the DSCP found in the packet IP header.
No traffic engineering will be done at ingress on the network interfaces. The idea
here is that ingress policing and ACLs at the service provider level have already been
applied in a (access provider-owned) box deeper in the network.
After the forwarding decision, the following traffic engineering steps can be
performed on the subscriber interfaces at egress (intelligent line cards only):
Egress policing
End users are subject to certain traffic contracts that specify how much traffic
they can receive on their DSL connection. To enforce these contracts, policers
will be installed. A policer may apply to an entire subscriber interface or to a QoS
subflow (that is, priority flow) within the subscriber interface.
Classification of traffic into QoS classes based on P-bit markings
Per QoS class queuing and scheduling
In the downstream direction, separate QoS queues are provided per DSL line.
Buffer acceptance control can be done by way of Tail Drop or Random Early
Detect (RED).
11.4 Traffic classes
Four main traffic classes have been identified: Voice, Video, Controlled Load (CL)
and Best Effort (BE). These traffic classes together with their application and
recommended 802.1p value are listed in Table 11-1.
This approach segregates network control, voice and video-telephony into the
highest priority traffic class, broadcast video and video-on-demand into the second
traffic class, business customer data traffic into a third traffic class, and residential
customer data traffic into the fourth.
Table 11-1 Traffic classes, application, and recommended 802.1p value
Traffic class Application Recommended 802.1p value
Voice Voice 110

Video telephony (111)
(+ network control)
Video Broadcast video 100

Video-on-demand
Controlled load HSI for business access 011
Best effort HSI for residential access 000

11.5 Queuing, scheduling, policing and BAC
The scheduling model we seek to employ both on aggregates and on individual DSL
ports is presented in Figure 11-1. Voice gets absolute priority, then video, while CL
and BE (the two traffic classes relying mostly on TCP) will be protected from each
other by way of a bandwidth-sharing scheduler.
This model implies that both voice and video traffic are very well contained and only
trusted sources are allowed to use the high-priority traffic classes.
Figure 11-1 Reference scheduling hierarchy
Voice
Video SP
CL
WFQ
BE
QoS on the SHub subsystem

QoS on the SHub subsystem relies on the 802.1P-bits and is applicable on
aggregates.
In the NE, per-flow or per-session QoS is handled on the LIMs. Rate adaptation
towards a DSL port, rate limitation of user sessions and QoS at the DSL port
bottleneck, as well as the last active node on the multicast tree, are the responsibility
of the LIMs.
On all interfaces, four output buffers are enabled, because we have four traffic
classes. Buffer Acceptance Control (BAC) on the aggregation function is set to tail
drop.
Ingress policing can be done on a per-port, port.VLAN, port.VLAN.Dot1P and
port.VLAN.DSCP combination basis. All links connected with the interworking
function shall work at either line rate or at a preconfigured lower rate.
Upstream shaping is enabled per-Ethernet network interface basis. The shaping rate
granularity is 64 kb/s.
Traffic segregation into output buffers relies exclusively on the 802.1p-bits.
The NE will not generate pause frames, either internally nor upstream, but it will
correctly handle correctly pause frames coming from the network.
QoS on the LIMs

QoS on the layer2 based LIMs

Layer2 line cards have a different QoS architecture. Queuing is per PVC, and all
downstream unicast frames are using the same First In First Out (FIFO) queue. This
queue is scheduled with a priority that is inferred from the upstream P-bits attached
to the bridge port that was created on top of the VC.
Layer2 cards support 4 priority levels downstream. Upstream there is no bottleneck,
hence no queuing other than AAL5 reassembly.
Traffic within a VC can have different priorities:
unicast traffic priority is inferred from the port default upstream P-bits
broadcast traffic has the same priority as unicast traffic
multicast has priority 2 (second highest) if the multicast source is preconfigured
in the multicast source table, otherwise 0 (lowest)
Prioritization within a VC is strict priority. Also, across multiple VCs, fairness is

guaranteed only per datagram-priority and not per VC bandwidth.
Upstream PVCs are mono-QoS (that is, one P code point can be attached to them).
Each PVC will have an attribute that contains the default and unique VLAN ID and
the 802.1-bit value. The default 802.1-bit value can be specified by the operator by
way of the management interface.
The bit used for marking upstream frames is also used for downstream prioritisation
of unicast traffic (the priority level equals P-bits/2).
Traffic segregation into downstream queues is combined with the forwarding
decision: determining the outgoing port and PVC and determining the correct queue
with the appropriate priority is done in a single shot. For normal data traffic, this
relies on the VLAN ID (which is configured by the operator manually) and the MAC
DA (which is learned) and does not rely on the .1-bits.
QoS on the layer3-based LIMs

The logical architecture is presented in Figure 11-2:
Figure 11-2 Logical architecture layer3-based LIMs

downstream
Per-DSL line ATM
Input Logical Policing,
GE segmentation DSL
processing segregation Classification, PVC
aggregate or EFM per DSL line Queuing, forwarding
segmentation Scheduling decision
upstream
Segregation into
GE output buffers Per-DSL
Per-DSLline
li Input ATM DSL
aggregate (802.1P aggregates) Policing processing
processing reassembly
reassembly
or EFM reassembly

The input-processing entity stands for all protocol and forwarding-plane processing
functions. Each frame received from the network interface will have a handler or
meta-data that will contain all the fields needed by subsequent QoS-related
functions.
The next phase is the classification, policing and segregation process within a DSL
link; see Figure 11-3.
Session rate limitation is achieved by way of policing. Policing can be done per
terminated IP session, PPP session, 802.1x session, or per PVC with the following
subsets:
PVC
PVC.VLAN
Both upstream and downstream policing is possible with possibly asymmetrical
values. Granularity of policing rates is 8 kb/s.
PPP session policing is only applicable when the sessions are terminated on the NE.
If the NE is not in the terminating node, PPP sessions are not to be rate limited by the
NE.
IPoA sessions are unique per PVC, and identified by way of the configuration of the
PVC.
The NE handles policer conflicts in such way that, for each frame, the policer
installed on the highest layer of the interface hierarchy will be applicable. No frame
will be policed by more than one policer.
Figure 11-3 Per DSL-port scheduler

BAC
BAC voice
Traffic
Policing class
BAC video SP DSL
SP
entity switch BAC
BAC CL
Based on:
WFQ
Rule per SAP:
802.1P
BAC BE
PVC
PPP
Modes:
VLAN ID
802.1X Taildrop
IP interface RED
The policers available in the NE are single-token bucket.

The management interface allows:
the corresponding parameters per logical flow
the setting of the Weighted Fair Queueing (WFQ) weights
the BAC thresholds
the BAC type (Random Early Detection (RED)/ tail drop).

The weight, used for calculating average buffer sizes in RED, is not configurable.
RED-parameters to be set are: low buffer thresholds, high buffer threshold, max drop
probability. There are also profile-based BAC parameters that can be configured.
A WFQ scheduler ensures fair redistribution of the remaining bandwidth between
CL and BE traffic. BAC is either tail drop or RED per downstream queue.
Figure 11-4 shows the Ethernet-to-ATM QoS transition.
Figure 11-4 Ethernet-to-ATM QoS transition
Frame Domain Cell Domain
Segmentation
buffers
VOICE VC1
Add correct
VPI/VCI VC2
VIDEO 1 frame
SP fields
VC3
CL Rate limitation to
WFQ DSL bandwidth
DSL
BE
Ethernet (frame level)
scheduler
Scheduling is done solely on the Ethernet frame level, even for ATM-based DSL
flavors.
The queuing decision (within a DSL port) is independent from the forwarding
decision. There is no explicit fairness between different PPPoE or IPoE sessions
within a DSL link. Their peak rate is enforced independently by way of policing, and
then they share the same First In First Out (FIFO) per traffic class.
Marking is generally applicable upstream, although with the policy framework, it is
possible to modify downstream code points. Packets may arrive from user PVCs
tagged, untagged, or priority-tagged. There is a per-PVC remarking table from all
user-defined P-values to allowed ones. Untagged frames can be marked based on
PVC or VLAN defaults (statically configured) or can be marked as received from
RADIUS in the QoS session profile.
Downstream, frames are expected to arrive correctly marked for priority. If the video
feed interface is a dedicated Ethernet interface, a default P-value can be attached to
video frames. If, for various reasons, it is impractical to set the P-bits in the upstream
node, the NE allows to align the P-bits to the DSCP for IP packets incoming on the
SHub interfaces.
The NE allows also DSCP-marking for various subrscriber SAPs. DSCP-remarking
is also possible, just like P-bit remarking for tagged and priority-tagged frames.
Finally, a global DSCP-to-P-bit alignment table is provided to align DSCP-marked
traffic on selected interfaces to P-bits, as traffic segregation still relies on P-bits.
PPP-session marking for P-bits is possible based on the QoS session profile
attributes.

Connection Admission Control

The NE is an Ethernet device. Consequently, there is no Connection Admission
Control (CAC), neither in the sense of ATM nor in the sense of controlling
application session setup messages. QoS relies on the following assumptions and
helping mechanisms:
The high-priority traffic is well behaved. Downstream, only trusted sources are
allowed to use the high-priority traffic classes. It is assumed that packets arrive
with correctly set priority bits, and only operator-administered nodes (voice,
video portals, BRAS) originate these flows. On the layer3-based LIMs, the
high-priority traffic upstream is rate limited by way of policing.
Application session setups (say voice call initiation) are not detected. On the
layer3-based LIMs, it can be guaranteed by way of policing that the user can only
get one call-worth of bandwidth. Should the user initiate two calls, the NE cannot
block it in these phases, but the result will be two bad-quality voice calls as
policing will discard roughly 50% of the traffic.
Video streams both broadcast and video-on-demand are Constant Bit Rate
(CBR) encoded (or at least CBR shaped from the network).
The NE allows associating bandwidth parameters to known multicast video
streams. It allows, per DSL line, the setting of a maximum in kb/s for multicast.
Based on the bandwidth available for multicast, the NE executes a CAC for
known multicast sessions. A reserved amount can be set aside for voice and data.
What is left from the DSL total bandwidth is the budget for multicast CAC. This
functionality is available on all line card variants.
Per NE, the number of video-on-demand sessions can be limited from the
video-on-demand portal. This means a non-zero probability of blocking users
access to a subscribed service. This is typically not the case for broadcast video,
and often all streams are statically transmitted to the NE, regardless of whether
there are customers tuned in to certain channels.
Per DSL link, a designated amount of bandwidth can be saved for voice and data
from multicast video. VoD traffic is not included for the moment.

11.6 QoS profiles
The network element uses QoS profiles to perform ingress and egress traffic
policing, class queuing, and scheduling. QoS profiles can be created and then
assigned to QoS resources and SAPs. These are the types of QoS profiles:
CAC profile
Marker profile
Policer profile
Queue profile
Scheduler profile
Session profile
policy rule
layer2 filter
layer3 filter
policy action list
CAC profile
A CAC profile is primarily used to perform multicast video admission control for an
individual xDSL port in the downstream direction. The maximum downstream
bandwidth to be occupied by video can be further constrained by setting the
maximum multicast bandwidth parameter in the CAC profile. CAC profiles are
applicable on the LIMs, but not to interfaces on the SHub subsystem.
A CAC profile contains three configurable rate parameters:
the maximum allowed bandwidth for voice
the maximum allowed bandwidth for multicast video
the maximum reserved bandwidth for data traffic
The system derives the guaranteed line rate from the modem and calculates an
estimate of the available Ethernet bandwidth. In the profile, you can reserve a part of
the available downstream bandwidth for voice and data applications, and the
remaining part will be kept by the system as the available bandwidth for multicast
video. Only pre-configured multicast streams are considered for CAC. Unicast
video, regardless of whether or not it is premium content or generic internet
streaming video, is ignored by the CAC function.
A CAC profile can be associated with an xDSL interface, using the QoS DSL link
configuration command, see the Operations and Maintenance using CLI and the CLI
Commands documents for more information.

Marker profile
The marker profile is a building block of the QoS session profile. The marker profile
is used to convey upstream marking settings to the service access point.
The marker profile carries a flag for enabling DSCP to P-bits alignment of the SAP,
based on the global DSCP to P-bits alignment table of the layer3 cards. This allows
to specify the SAP default P-bits, the DSCP, or the DSCP contract table (depending
on the SAP type).
Six types of marker profiles exist:
single dot1p
DSCP contract
dot1p and DSCP
single DSCP
dot1p and DSCP contract
DSCP to dot1p alignment
See the Operations and Maintenance using CLI and the CLI Commands documents
for more information about marker profiles.
Policer profile
The network element uses policer profiles to enforce predetermined limits on
upstream and downstream subscriber traffic. These are single-token bucket policers
where the action upon the conformance result is either pass or discard. The layer3
LIMs support policing, both upstream and downstream . The SHub subsystem
supports ingress policing on externam interfaces, but it does not rely on policer
profiles.
Using a policer profile, you can set the committed information rate and the
committed burst size in 8 kb/s increments up to a maximum of 64 Mb/s for both
upstream and downstream policing. You need to create a separate policer profile for
each direction. When you create and configure a session profile, you have the option
to associate both an upstream and a downstream policer profile with that session
profile. Once configured and associated, policing is applied to all frames within the
session with which the policer profiles are associated. As such, rate enforcement is
performed uniformly for all subscriber lines that are associated with that session
profile.
Queue profile
The QoS queue profile is a BAC profile that contains admission control information
for frames arriving at the buffer from the services side of the network. Two types of
queues are supported on the LIMs: RED and tail drop.
A RED queue has three configurable parameters: the minimum number of frames to
queue before starting to discard, the maximum number of frames that will ever be
queued at one time, and the probability of a frame being discarded. Arriving frames
are queued until the minimum value is reached. Frames received after the minimum
is reached have the set discard probability chance of being discarded.

For tail drop queues, you only configure the queue size. Queue size is set as the
number of frames that can be stored in the queue. Arriving frames are queued as long
as the queue is not full. After the queue is full, all incoming frames are discarded until
the queue can transmit a frame over the xDSL line and space in the queue is made
available.
Note Increasing the total amount of queues used can result in

QoS-unaware discards. The default settings should allow for
maximum queueing over all ports without any frames being discarded
because other queues consume the total packet memory pool.
Scheduler profile
Each DSL port has four queues that are used to prioritize and buffer downstream
traffic. The highest priority queue is recommended for voice, followed by one for
video, next there is a controlled-load queue, and finally the BE queue.
The controlled-load and BE queues are prioritized based on a percentage using a
WFQ. The scheduler profile is used to change the default weight of the
controlled-load queue, which is set at 66%. The BE queue is auto-adjusted to yield a
sum of 100% and so no weight adjustments are required. You assign a scheduler
profile to a xDSL port to change the default weight of the controlled-load queue. You
can use scheduler profiles with the layer3 LIMs.
Session profile
The QoS session profile is the main building block for conveying user traffic,
contractual rights, and treatment of subscriber services through the network element.
This profile is a macro profile that has its own parameter settings, as well as
references to other profiles.
A QoS session profile is always a user logical interface. Please consult the CLI
Commands for the most recent list of supported SAP types.
A QoS session profile is composed of a logical flow type, a marker profile and two
policer profiles for up and downstream policing of the logical interface to which a
certain session profile is attached.

Figure 11-5 Composition of QoS session profile
QoS Session Profile
QoS Policer QoS Policer QoS Marker

QoS CCL Up QoS CCL Dn
Profile Up Profile Dn Profile Up
1..n 1..m
QoS Policy
Table
QoS Policer QoS Marker QoS L2 Filter QoS L3 Filter QoS Policy
Table Table Table Table ActionTable
The logical flow type parameter constrains the usage of a session profile to the
intended interface type. However, if the logical flow type is null (generic), the
session profile can be attached to any interface, provided that the settings inside the
profile can be configured on the target hardware. It is advised to always create
specific profiles for specific interface types to avoid wrong configurations.

11.7 Policy framework
A generic policy framework provides finer-grained control over subscriber traffic. It

provides for generic layer2/layer3 classifiers and associated policy rules, which can
be attached with a certain priority to subscriber Service Access Points (SAPs). One
pair of classifier (or policy condition) and policy action list form the basic building
block of a unidirectional policy. On each supported SAP, a QoS session profile can
be attached, which contains two lists of policies: one for upstream and one for
downstream. The policy precedence defines the order in which policy conditions (the
filters) are configured in hardware per SAP. The rule is that the first filter that a given
packet matches will cause its associated actions to be carried out and no further
filtering rules are verified for that frame.
Figure 11-6 shows the policy building blocks.
Figure 11-6 Policy building blocks
L2 Filter L3 Filter Policy Action

MAC Destination Address Address Type Default Disposition
MAC DA Prefix IP Destination Address Set DSCP
MAC Source Address IP DA Prefix Set P-bits
MAC SA Prefix IP Source Address Police
Ethertype IP SA Prefix Sharing
P-bits DSCP
CFI bit Protocol Type
VLAN ID Destination Port Range
Source Port Range
A set of nonconflicting actions can be grouped in a Policy Action list. This includes
a default disposition (permit/deny statement for ACL functionality), setting P-bit and
DSCP and policing. All packets identified by way of the associated filter can be rate
limited by way of a policer instance. Some subflow policies can share common
attributes, such as policing. The Sharing property of a policy action table enables
or disables policer sharing. Policer sharing will be used when the same policy action
list is referenced more than once on the same SAP in the same direction, and if the
Sharing attribute was set to enable.
Up to 16 policies can be defined for upstream traffic per SAP and up to 4 in the
downstream direction. This is in line with the typical requirements, as more security
policies are required in the ingress direction, while in the egress, mostly only traffic
class rate limitation applies.
There is a complex sanity check in place for avoiding conflicting policies, such as
filtering on MAC DA for IPoA traffic, and so on. In the downstream direction, code
point modifications are supported.

11.8 Subtending model
NEs can be connected in cascade, star, or ring topology, except when there is a ring
behind a Hub NE.
Cascading should not be done with interfaces that have smaller bandwidth than the
Hub NE. If the network scenario requires this, this may have severe QoS
consequences and basically constrain the services to voice plus best effort.
Cascading increases network delay.
Multicast streams should be configured statically, such that all multicast streams are
always sent to the last NE from the cascaded chain, otherwise zapping times will
increase.


12 Statistics
12.1 Overview 12-2

12 Statistics
12.1 Overview
Statistics are useful counters that you can retrieve to determine the health and
operation of elements in a network. You can retrieve the statistics for the 7302 ISAM
and the 7330 ISAM FTTN using CLI, TL1, or Element Management System (for
example, 5523 AWS or 5526 AMS). See the following documents for detailed
information and the commands for retrieving statistics:
Operations and Maintenance Using CLI
Operations and Maintenance Using the 5526 AMS
(7330 ISAM FTTN only)
CLI Commands
TL1 Commands and Messages

13 Inverse Multiplexing for ATM
13.1 General 13-2
13.2 Interface arrangements 13-3

13.1 General
Inverse Multiplexing for ATM (IMA) allows an ATM cell stream to be transported
on a number of lower-rate physical links (for example, several E1 span lines). This
is done by grouping these physical links into a single logical transport channel. The
bandwidth of this logical channel is approximately equal to the sum of the
transmission rates of the individual links in the IMA group.
Figure 13-1 IMA
IMA Group IMA Group

Physical link #0
PHY PHY
Physical link #1
PHY PHY
Single ATM Cell stream Original ATM Cell
from ATM layer stream to ATM layer
Physical link #2
PHY PHY
IMA Virtual Link
In the Tx direction, the ATM cells are distributed across the linke in a round robin
sequence.
In the Rx direction, the ATM cells are recombined into a single ATM stream.
Topology
Each Line Termination (LT) unit that has IMA capability can support the following
IMA group sizes:
1 link in native mode (so called "Native-PHY line"). Such a link is a link without
IMA sublayer. This allows to connect CPE equipment, that is non-IMA capable,
to be directly connected to the NE.
1 link using the IMA protocol
2 to 8 SHDSL links using the IMA protocol
Apart from this individual group limit, the number of links that are actually
combined in one or more IMA groups is only limited by the total links of the IMA
device, which is maximum 24 links.
There is one IMA subsystem per 24-ports SHDSL LT. The IMA subsystem is the
hardware unit providing IMA functionality.
On 48 ports SHDSL LTs, the IMA is implemented as two independent subsystems
of 24 lines. Crossover between the lower and upper groups of 24-line IMA
subsystems is not allowed.

13.2 Interface arrangements
Supported interface arrangements

The figure below shows the supported interface arrangements in the IMA LT
Figure 13-2 Supported interface arrangements
ISAM CPE
LT Native PHY
CPE
NT
LT CPE
SHDSL IMA
Incompatible interface arrangements

The figure below shows examples of incompatible arrangements between an IMA
LT and a CPE.
Figure 13-3 Incompatible interface arrangements

ISAM
IMA IMA
CPE
LT
CPE
Native IMA
LT CPE
NT
IMA Native
LT CPE
NC
IMA Native
LT CPE
Native CPE
IMA


14 Alarm management
14.1 Overview 14-2
14.2 Alarm management 14-2
14.3 Programmable alarm filters 14-5

14 Alarm management
14.1 Overview
This chapter describes alarm management and programmable TCA alarm filters for
the 7302 ISAM and the 7330 ISAM FTTN. Table 14-1 lists the information available
in this chapter.
Table 14-1 Alarm management contents
Contents Section
Alarm management description 14.2
Programmable alarm filters description 14.3
14.2 Alarm management
Alarm management enables you to manage alarm reporting for the NE. You can
manage the following alarm attributes and alarm reporting functions for all basic
system alarms, interface related alarms, derived alarms, and TCA alarm indications:
alarm identification and definition
alarm severity (intermediate, warning, minor, major, and critical)
alarm lists and logs
alarm filters
Alarm filters you configure at the NE affect how the NE reports its own alarms, as
well as alarms it receives from connected subtended NEs and from connected remote
expansion units. See 7302 ISAM | 7330 ISAM FTTN CLI Commands and the
7302 ISAM | 7330 ISAM FTTN TL1 Commands and Messages documents for alarm
management command definitions.
Alarm categories and identification

There are three categories of alarms.
non-interface related alarms
interface related alarms
derived alarms
Non-interface related alarms include alarms such as equipment failure alarms.
Interface related alarms involve ATM and xDSL interfaces. Derived alarms are
raised in the system when programmed temporal or spatial alarm filters are used. See
section 14.3 for more information about programmable alarm filters and derived
alarms.
Alarms use the same identification method that consists of two main parts: the alarm
type definition and the alarm number. The alarm type definition provides a general
definition of the type of alarm; for example, a SONET alarm. The alarm number
identifies a specific alarm within that type; for example, a path AIS alarm.

14 Alarm management
You can view alarm types and definitions as they are recorded in alarm lists and logs
using the TL1, CLI, 5526 AMS, or the 5528 WAM. See the
7302 ISAM | 7330 ISAM FTTN Operations and Maintenance Using CLI for a
complete listing of all alarms, along with their definitions. Alarm definitions are not
user configurable.
You can configure an identification attribute for alarms to identify if the alarm is
considered to be service affecting or non-service affecting. See
7302 ISAM|7330 ISAM FTTN CLI Commands and the
7302 ISAM|7330 ISAM FTTN TL1 Commands and Messages documents for alarm
management command definitions.
Alarm severity
Managed alarms are assigned a default minimum alarm severity level. There are five
alarm severity levels listed in ascending order of severity:
intermediate
warning
minor
major
critical
When an alarm level equals or exceeds its minimum severity level, that alarm is
forwarded to the alarm reporting and logging filters where it is reported and logged
as defined for that particular alarm. For TCA alarms, when the TCA feature is
enabled for an xDSL subscriber line, alarm indications are always sent to the alarm
reporting and logging filters. Whenever a minor, major, or critical alarm is received,
the corresponding alarm LED on the faceplate of the alarm control unit installed in
the shelf activates.
You can configure the minimum alarm severity of an alarm using the CLI. See
7302 ISAM | 7330 ISAM FTTN CLI Commands for alarm management command
definitions. It is also possible to disable alarm reporting for individual alarms.
Changing the minimum severity level for an alarm only affects new alarm events and
does not affect alarm indications that have already passed through the alarm
reporting and logging filters.
Alarm lists and logs

You can enable and disable alarm reporting, as well as set the alarm logging mode
for individual alarms. When enabled, alarm indications are always sent to the
appropriate alarm report and alarm log when the minimum alarm severity level for
the alarm is reached. Alarms are enabled by default. An exception is the TCA alarm
that you can enable for each xDSL subscriber line.
There are three types of alarm list:
current alarm list
snapshot alarm list
alarm severity delta logging list

14 Alarm management
The current alarm list and the snapshot alarm list display alarm activity when
initiated by the user. The alarm severity delta logging list is a log of alarm indications
that can be accessed at any time and contains a historic record of alarm events. Only
alarms that have their alarm mode enabled appear on these alarm lists.
Current and snapshot alarm lists

The current alarm list changes dynamically as alarms are detected and pass through
the alarm filters. If a stable view of the alarms is preferred, the snapshot alarm list
captures a momentary view of the current alarm condition at the time it is initiated
by the user. You can set the minimum severity level of the active alarms to be
retrieved and viewed in a snapshot alarm list for a maximum time period of up to 120
seconds. It is also possible to change the way alarms are displayed in the snapshot
list. The default is to list alarm indications according to severity level. You can
configure it so that alarm indications are ordered according to the time of occurrence.
Alarm severity delta logging list

A separate alarm severity delta logging list exists for each of the five alarm severity
levels. Each change in the alarm condition, such as a change of alarm state from
alarm on to alarm off, is logged. Alarm state changes are logged in order of
occurrence. Users can define the maximum size of each alarm severity delta logging
list, in addition to setting a maximum total sum of all logs kept by the system.
You can set the action taken when the alarm severity delta logging list reaches the
set maximum size. Alarm logging can be set to either continuously wrap entries,
where newer entries overwrite the oldest ones, or to halt alarm logging when the
logging list is full. For the latter method, alarm logging resumes only after the alarm
logging list is manually reset.
Resetting a logging list empties the contents of that list. This step is required before
reducing the size of a logging list and when restarting alarm logging if the alarm
logging method is set to halt when the logging list is full. A alarm severity delta
logging list can only be reduced in size if the new smaller size is less than the current
size of the logging list.
Alarm filters
There are three types of filters:
alarm logging filter
alarm reporting filter
programmable alarm filters
The alarm logging filter determines if the alarm indication should be processed and
recorded in one of the five alarm severity delta logging lists. The alarm reporting
filter determines if the alarm indication should be processed for a current view or
snapshot list. Programmable alarm filters enable you to customize how alarm
reporting occurs for specific diagnostic and monitoring scenarios.
Alarm filtering applies to non-interface related alarms, such as equipment failure
alarms, and interface related alarms that involve ATM and xDSL interfaces. It is
possible to enable and disable alarm filtering for individual alarms.

14 Alarm management
14.3 Programmable alarm filters
There are two types of programmable alarm filters: temporal alarm filters and spatial
alarm filters. You can define a maximum of 31 temporal alarm filters and 31 spatial
alarm filters. See the 7302 ISAM | 7330 ISAM FTTN TL1 Commands and Messages
documents for programmable alarm filter command definitions.
When you use programmable temporal or spatial alarm filters, the system raises a
derived alarm whenever the conditions of the alarm filter are met. The resulting
derived alarm has the same identification parameters as the alarm filter that
generated the derived alarm.
Temporal and spatial alarm filters

Using temporal alarm filters, you can limit the number of alarm state changes that
are reported for a particular alarm. For alarms that are frequently raised, you can
create a temporal alarm filter that will report only one alarm state change for a set
number of state changes that occur over a specified length of time. You can also
configure the threshold for the number of state changes and the time period of the
filtering window. Temporal alarm filters are severity based and only alarm
indications that equal or exceed the alarm severity level are counted.
A derived alarm is raised in the system when the number of alarm events reaches the
set threshold during the filtering window time period. Figure 14-1 shows how a
temporal alarm filter raises a derived alarm after the configured threshold is reached.
In this example, the threshold is set to three. When three alarm conditions occur
during the configured alarm filter time period, a derived alarm is raised.
Figure 14-1 Temporal alarm filter raising a derived alarm
Alarm
severity
15 15 15 15
minutes minutes minutes minutes
Set
level
Time
Alarm ON Alarm ON Alarm ON Alarm ON

Alarm OFF Alarm OFF Alarm OFF Alarm OFF
CONFIGURED ALARM FILTER TIME PERIOD
1 2 3
Derived Derived
alarm ON alarm OFF
18311

14 Alarm management
The derived alarm condition remains on until the end of the filtering window and is
cleared at the end of each filtering window time period.
Temporal alarm filters are useful for TCA alarms which can be raised frequently.
Using temporal alarm filters, you can filter out minor TCA alarm indications and
provide better visibility of major TCA alarm conditions.
Using spatial alarm filters, you can create a unique alarm condition such that when a
specified group of individual alarms are raised, a derived alarm is reported. This is
used to identify alarm conditions that are characterized by a certain set of alarm
conditions occurring simultaneously.
Identification of alarm filters and derived alarms consists of two main parts: a type
identifier and a number. Temporal and spatial alarm filters have a unique filter type
identifier. Derived alarms have a unique alarm type identifier. The number used in
the identification of derived alarms matches the number assigned to the alarm filter
that generates the derived alarm. Additionally, each derived alarm entry recorded in
alarm reporting and logging lists contains the identification of the affected
component. In the case of an interface related derived alarm, the identification of the
affected interface is provided.
The state change of a derived alarm must pass through the alarm reporting and
logging filters before being added to the alarm reporting lists and the alarm severity
delta logging list. A derived alarm that is generated from a temporal filter is
identified as an interface related alarm if the basic alarm being referenced by the
filter is also an interface related alarm. The derived alarms generated from spatial
alarm filters are always identified as non-interface related alarms.
Configuring programmable alarm filters and derived alarms

You can activate and deactivate alarm filters after they are created using TL1. When
you create a temporal or spatial alarm filter, the system automatically copies the
parameter settings of the basic alarm to which the alarm filter applies and uses those
as default settings for the derived alarm. The settings include:
severity level
reporting mode
logging mode
service affecting or non-service affecting
alarm category
You can change these settings for the derived alarm, but not if the alarm filter is
active. You must first deactivate the alarm filter.
After the filter is deactivated, you can configure the filtering threshold, filtering
window, and the alarm to which the filter applies. Once configured, you must
manually reactivate the alarm filter. See the 7302 ISAM | 7330 ISAM FTTN TL1
Commands and Messages documents for programmable alarm filter command
definitions.

14 Alarm management
Alarm reporting
Alarm reporting occurs differently, depending on whether or not alarm filters are
configured for the basic alarm. If no alarm filters are configured for the basic alarm,
then alarm state changes of the basic alarm are always reported to the appropriate
alarm reporting and logging lists when the alarm conditions are met.
If a temporal alarm filter is configured for a basic alarm, only state changes of the
derived alarm are recorded in the appropriate alarm reporting and logging lists during
the time period when the derived alarm is on. During the off period, state changes of
the basic alarm are recorded in the appropriate alarm reporting and logging lists.
With spatial alarm filters, both the derived alarm state changes and the basic alarm
state changes are recorded in the appropriate alarm reporting and logging lists.

14 Alarm management

15 Test features
15.1 Metallic Test Access 15-2
15.2 Single-ended line testing 15-5

15 Test features
15.1 Metallic Test Access
The 7302 ISAM and the 7330 ISAM FTTN ARAM-D host shelf provide Metallic
Test Access (MTA) to the xDSL lines.
During turn-up of a subscriber line, the operator can test the line to verify whether it
is suited to carry the promised xDSL service. After the service has been established,
the operator can also perform a variety of tests during routine or diagnostic tests.
Testing using MTA can be either single-ended or dual-ended.
Test access modes

The following test access modes are supported for each Test Access Port (TAP):
Released mode
All test connections are released and all TAP resources are freed.
Loop around mode
Is used to characterize the TAP so that its influence can be deducted from the
parameters measured during the split access mode.
Split access mode
Provides a breaking connection that allows the test system to test outwards
towards the line and to test inwards towards the LT equipment.
Note Only full MTA requires all the test access modes.
Figure 15-1 shows the test access modes.
Figure 15-1 Test access modes

Released Loop Around
Line Line
Facility pair Facility pair
RTU RTU
xTU-C xTU-C
Equipment pair Equipment pair
LPF LPF
DSLAM DSLAM
PSTN PSTN
Line
Facility pair
RTU
xTU-C
Equipment pair
LPF
DSLAM
PSTN
Split Access

15 Test features
The two following access modes are partial implementations of the split-access
mode and are called limited test access:
Limited outward access mode
toward the line. The Low Pass Filter (LPF) and the line to the Public Switched
Telephone Network (PSTN) remain connected to the line. This limits the number
of measurements that the test system is capable of.
Undisturbed outward access mode
toward the line. The LPF and the line to the PSTN are either not present or they
have been removed from the line. This ensures that the measurements are not
disturbed by the presence of the LPF or the DC battery voltage that is put on the
line.
Figure 15-2 shows the partial implementations of split-access mode.
Figure 15-2 Partial implementations of split-access mode

Limited Outward Acces Undisturbed Outward Access
Line Line
Facility pair Facility pair
RTU RTU
x-TU-C x-TU-C
Equipment pair LPF Equipment pair LPF
DSLAM DSLAM
PSTN PSTN
MTA support in the 7302 ISAM

Both full and limited test access scenarios are supported.
With the Metallic Test Access Unit (MTAU) function, these tests are possible. The
MTAU function is implemented by way of a test applique and LT appliques, which
are present in the splitter shelf. Using this function, a test head or Remote Test Unit
(RTU), can get metallic access to a line in the 7302 ISAM by way of a TAP, so that
it can perform the necessary tests.

15 Test features
MTA support in the 7330 ISAM FTTN

Both full and limited test access scenarios are supported in the ARAM-D shelf. The
ARAM-B, the ES and the SEM do not support MTA.
The ARAM-D shelf supports MTA through an MTAU function implemented by
the General Facilities Card (GFC) and alarm control and host expansion interface
unit combination in conjunction with the multi-ADSL and POTS splitter
appliques. All units must be present in their respective shelf for the MTAU
function to operate. Using this MTAU function, a test head or RTU can use a
single TAP on the GFC to get metallic access to any subscriber line connected to
the 7330 ISAM FTTN.
The ARAM-D shelf uses an RJ-45 MTA connector on the GFC as the TAP for
the test in and test out signals between the testhead and the shelf.
The ARAM-D shelf uses the alarm control and host expansion interface unit to
provide a relay-based matrix to connect the test in and test out signals with the
backplane for connection to the appropriate applique installed in the shelf.
The ARAM-D shelf supports MTA on the multi-ADSL and POTS splitter
appliques. The expansion shelf supports MTA on the multi-ADSL and POTS
splitter appliques. On-board relays are used to connect the test in and test out
signals to the appropriate connected subscriber line.
Test Access Control (TAC)

TAC is done with TL1 commands, which are sent by way of the TL1 agent of the
7302 ISAM or 7330 ISAM FTTN ARAM-D shelves in response to the testhead.

15 Test features
15.2 Single-ended line testing
Single-Ended Line Testing (SELT) can be performed from the CO without need for
support by the CPE or by a craftsperson at the customer premises. The SELT works
together with external data analysis software, such as the Alcatel 5530 Network
Analyzer (NA), to provide loop prequalification and maintenance of the network.
SELT is based on Frequency Domain Reflectometry (FDR). An excitation signal is
sent on the line and its echo response is analysed. Processing of the echo response is
done in the NA. The polarity and the position of the reflections indicate the loop
length, attenuation, presence of gauge wire changes and bridge taps of the line under
test.
The operator can check the presence of an interconnection to the Main Distribution
Frame (MDF). This feature can be of interest in situations where this interconnection
is being provisioned by a third party.
SELT has the following limitations:
SELT measurement is only possible on one DSL line at a time
Only one measurement at a time is possible
The NE does not check possible conflicts between the actual state and usage of
the DSL line that is being checked with SELT. The operator has to make sure that
a DSL line is available for testing, before starting the measurement on it.
SELT for multi-ADSL over POTS

The following measurements and tests are supported in SELT for ADSL over POTS:
uncalibrated echo
echo variance
proprietary BCM parameters (reflection reports)
Table 15-1 shows the different parameters that can be interpreted for ADSL over
POTS.
Table 15-1 Parameters for SELT
Performance Parameters Specifications
loop reach up to 4 km (2.5 mi) with 0.4 mm wire

up to 6 km (3.7 mi) with 0.5 mm wire
loop reach accuracy - short loops up to 500 m (1640 ft): < 30 %
loop reach accuracy - medium loops up to 500 m (1640 ft): < 20 %

loop reach accuracy - long loops up to 1.5 km (0.9 mi): < 10 %
loop topology mixed wire gauges (2 loop types): 0.4 mm and 0.5 mm or
24 AWG and 26 AWG are supported
loop topology termination (POTS, fax)

support of bridged taps from NA R4.1 onwards

15 Test features
SELT for VDSL (7330 ISAM FTTN only)

SELT measurements are also supported for the VDSL LT boards.

A. RADIUS Attributes
App A.1 RADIUS Attributes A-2
App A.2 Vendor Specific RADIUS Attributes A-3
Alcatel 7302 ISAM R2.5 July 2006 A-1

App A.1 RADIUS Attributes
NAS-Port
The system sets the NAS-port attribute as described below:
802.1x sessions:
The NAS-port attribute contains the ifIndex of underlying bridge port.
PPPoE sessions:
The NAS-port attribute contains the ifIndex of the PPPoE sessions.
NAS-Port-Id
The system sets the NAS-Port-Id attribute according to the following text format:
atm <rack>/<shelf>/<slot>/<DSL-Line>:<VPI>.<VCI>
The fields indicated between "<" and ">" is the information retrieved from the
management model:
Rack & shelf:
Rack and shelf number of the board that terminates the DSL line. Each item is
represented with 1 ASCII character.
Slot & DSL-line:
Slot number and port number of the board and of the DSL-line within the board,
each item is represented with 2 ASCII characters that correspond with the
decimal number.
For example, port 12 is represented with character "1" followed by character "2".
Port 5 is represented by character "0" followed by character "5".
VPI:
VPI represented with between 1 and 3 ASCII characters, using the number of
characters that is needed.
For example, VPI 12 is represented with character "1" followed by character "2".
VPI 5 is represented by character "5". VPI 0 is represented by character "0".
VCI:
VCI represented with between 1 and 5 ASCII characters, using the number of
characters that is needed.
For example, VCI 32 is represented with character "3" followed by character "2".
The fixed separators, including the blanks are characters that are inserted in
between the previous characters.
A-2 July 2006 Alcatel 7302 ISAM R2.5

App A.2 Vendor Specific RADIUS Attributes
General
Vendor ID 637 is used for ISAM.
The vendor specific attribute type has a length of two bytes long where the highest
byte is the project ID and the lowest byte is the project specific attribute ID.
The project ID 7 is assigned to ISAM project. This means that the vendor specific
attribute range from 1792 to 2047 will be used for ISAM.
VRF-Name
Vendor Type: 1792

Vendor Length: 4 < length < 35
Vendor Value: STRING
Packet: Access-Accept
VLAN-ID
Vendor Type: 1793

Vendor Length: 7
Vendor Value: INTEGER
QoS-Profile-Name
The QoS-Profile-Name is a character string of maximum 32 characters identifying
the QoS user profile configured in the system. The QoS user profile contains both
marker and policer information.
Note: This attribute cannot be specified together with QoS-Parms attribute.
Vendor Type: 1794

QoS-Parms
Note: This attribute cannot be specified together with QoS-Profile-Name attribute.
Vendor Type: 1795
Possible values are :

[marker up {.1p <value(0:7)>} ]
[policer up {cir <value> cbs <value>} ]
[policer down {cir <value> cbs <value>} ]
where:
cir: 4 bytes in kbit/s
cbs: 4 bytes in bytes
TL1 domain parameters

Table A-1 lists the VSAs and their default values for the TL1 domain.
Table App A-1 TL1 domain parameters
Domain VSA Value Default Value

Maintenance 1536 Integer (0..7) 4
Provisioning 1537 Integer (0..7) 4
Security 1538 Integer (0..7) 7

Test 1539 Integer (0..7) 0
The possible values for each domain are:

0: no privilege
1: privilege level 1

CLI domain parameters

Table A-2 lists the VSAs and their default values for the CLI domain.
Table App A-2 CLI domain parameters
Domain VSA Value Default Value
AAA 1801 Integer (0..3) 1
ATM 1802 Integer (0..3) 3

Alarm 1803 Integer (0..3) 3
DHCP 1804 Integer (0..3) 3
EQP 1805 Integer (0..3) 3
IGMP 1806 Integer (0..3) 3
CPEproxy 1807 Integer (0..3) 3
IP 1808 Integer (0..3) 3

PPPoE 1809 Integer (0..3) 3
QoS 1810 Integer (0..3) 3
SWMgt 1811 Integer (0..3) 3
Transport 1812 Integer (0..3) 3

VLAN 1813 Integer (0..3) 3
XDSL 1814 Integer (0..3) 3
Security 1815 Integer (0..3) 0
Cluster 1816 Integer (0..3) 3
The possible values for each domain are:

0: no privilege
1: read privileges
2: write privileges
3: read-write privileges
CLI profile parameters

Table A-2 lists the VSAs and their default values for the CLI profile.
Table App A-3 CLI profile parameters
Profile parameter VSA Value Default Value Length
Prompt 1817 String (< 19 characters) %n%d%c 18 bytes
Password timeout 1818 Integer (0..365 days) 0 -
Description 1819 String (< 31 characters) 30 bytes


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 R2.5 July 2006 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 card 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 July 2006 Alcatel 7302 ISAM R2.5

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.
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 card converts xDSL signals into ATM traffic. For a service
management application, if the service user is connected to the ATM
network through a DSLAM port, the network access is provisioned using a
DSLAM attachment type.
DSNC-A DSx Network Combiner
A general facilities card 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 card that supports connectivity between the NT unit, PSTN, and
multi-ADSL subscribers through the AVPC-A, HLPC-H, or HLPC-J
applique.

Glossary
EBLT-E Multi-ADSL Line Termination unit

A card that supports connectivity between the NT unit, PSTN, and
multi-ADSL subscribers through the AVPC-A, HLPC-H, or HLPC-J
applique.
EBLT-K Multi-ADSL Line Termination unit with system level bonding
A card with system level bonding capability that supports connectivity
between the NT unit, PSTN, and multi-ADSL subscribers through an
AVPC-A, HLPC-H, or HLPC-J applique.
ECI Equipment Catalog Item
An equipment catalog item is a six-digit numeric code that translates into the
bar code on the bar code label. ECI codes are also used as internal processing
codes.
ECMP Equal Cost Multi-Path routing
ECNT-A Combined Network Termination unit
An NT unit that provides Ethernet and/or Gigabit Ethernet optical and/or
electrical connectivity to a high-bandwidth IP services network.
EDSE-A Expansion Shelf Controller
An expansion shelf controller that provides some control functions for the
expansion shelf. The EDSE-A card also provides four Ethernet expansion
links for inter-shelf communications and for connecting the remote LT units
on the ES to the 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 card 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 Access termination, Control 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 card Ethernet switch (also known
as SHub)
LCP Link Control Protocol
A protocol that LCP establishes, configures, and tests data-link connections
for use by PPP.
LED Light Emitting Diode
A semiconductor diode that emits light when a current is passed through it.
LIM Line Interface Module
LMI Line Management Interface
LOS Loss of Signal
A condition at the receiver or a maintenance signal transmitted in the
physical overhead, indicating that the receiving equipment has lost the
received signal.
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 card for network termination.
NTA slot Network Termination slot A
The slot on the 7330 ISAM FTTN shelf for an NT unit. There are two slots
for NT units, marked as A and B.
NTB slot Network Termination slot B
The slot on the 7330 ISAM FTTN shelf for an NT unit. There are two slots
for NT units, marked as A and B.
NTP Non-Trouble Procedure
OAM Operation, Administration, and Maintenance
Broad categories of functions found in a communications network and/or the
business processes found in network service provider companies.
OBC On-Board Controller
OOS Out-of-service
The status of a primary rate link when it is out of service.
OS Operations System
Standalone software system that supports network-related operations
functions.
OSP Outside Plant
OSPF Open Shortest Path First
Dynamic routing protocol that responds quickly to network topology
changes. As a successor to RIP, it uses an algorithm that builds and
calculates the shortest path to all known destinations.
OSS Operations Support System
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 card
A general facilities card that provides power to the other units in the
ARAM-D shelf, including the fan unit. Two variants of the card are
available: one provides connectivity for six user-definable external alarm
inputs and the other provides connectivity for three user-definable external
alarm inputs and critical, major, and minor alarm outputs. Both variants
provide an ac failure input, MTA connectivity, and a connection for a craft
terminal.
QoS Quality of Service
Measure of the quality of a data communications link provided to a
subscriber.
RADIUS Remote Authentication Dial-in User Service
RADIUS is a standardized method of information exchange between a
device that provides network access to users (RADIUS client) and a device
that contains authentication and profile information for the users (RADIUS
server).
RAM Remote Access Multiplexer
RARP Reverse Address Resolution Protocol
RB VLAN Residential Bridging VLAN
RDI Remote Defect Indication
READSL2 Reach Extended ADSL2

Glossary
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
SAP Service Access Point

Glossary
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 card Ethernet
switch (also known as LANX).
SI Systme international dunits
SMF Single Mode Fiber
Optical fiber with a core diameter of less than 10 microns that is used for
high-bandwidth transmission over long distances.
SNMP Simple Network Management Protocol
Protocol used by network management to retrieve information about
connection status, configuration, and performance.
SNTP Simple Network Time Protocol
A method of synchronizing network nodes. An SNTP server can be used by
multiple nodes to synchronize themselves.
SONET Synchronous Optical Network
Transmission network that uses high-speed optical carriers.
SSCS service-specific convergence sublayer
SSH Secure Shell

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 Card

An applique that provides connectivity between POTS CO lines,
high-bandwidth IP services (through an LT unit), and 24 ADSL, VDSL, or
VDSL2 subscriber drop lines.
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 derived alarms, 14-2, 14-5

disable alarms, 14-3
7330 ISAM FTTN, 14-2 enable alarms, 14-3
802.1x major alarm LED, 14-3
support, 5-11 minor alarm LED, 14-3
NSE alarms, 14-2
A programmable alarm configuration, 14-6
programmable alarm filters, 14-5
ADSL
SE alarms, 14-2
about, 1-2
snapshot alarm list, 14-3
ADSL2
spatial alarm filters, 14-5, 14-5
about, 1-3
temporal alarm filters, 14-5, 14-5
ADSL2+
view alarms, 14-3
about, 1-4
ARP
alarm filters
layer 2, 5-6
logging filters, 14-4
layer 3, 7-7
programmable filters, 14-4
reporting filters, 14-4 C
alarm LEDs, 14-3
alarm management, 14-2 cluster
alarm delta logging, 14-3 management, 3-2
alarm filters, 14-4 cross-connect VLAN
alarm identification, 14-2 IGMP, 10-8
alarm lists, 14-3 current alarm list, 14-3
alarm logging, 14-3
alarm severity, 14-3
alarm types, 14-2
critical alarm LED, 14-3
current alarm list, 14-3
Alcatel 7302 ISAM R2.5 July 2006 IN-1

Index
D NT redundancy
D layer 3
forwarding, 6-3
derived alarms, 14-2, 14-5 protocol handling, 7-2
DHCP license
layer 2, 5-8 management, 3-6
layer 3, 7-11 logging alarms, 14-3
E M
ethernet management
FE, 1-11 cluster, 3-2
CPE remote, 3-4
F license, 3-6
user IP address, 6-6
FE
MTA
about, 1-11
in 7302 ISAM, 15-3
I in 7330 ISAM FTTN, 15-4
TAC, 15-4
iBridge mode test access modes, 15-2
about, 4-4 multi-ADSL
port and protocol based classification, 4-16 ADSL, 1-2
port based classification, 4-16 ADSL2, 1-3
IGMP ADSL2+, 1-4
about, 10-2 bonding, 1-5
functions, 10-9 INP, 1-9
modes, 10-8 READSL2, 1-5
parameters, 10-12 SELT, 15-5
PPV, 10-16 multicast
proxy, 10-6 about, 10-2
snooping, 10-7 IPoA, 10-16
INP parameters, 10-12
calculation, 1-9
IPoA N
cross-connect mode, 4-17
non-service affecting alarms, 14-2
IGMP, 10-8
NT redundancy
multicast, 10-16
about, 2-2
IPoE
combined link and equipment protection,
IGMP, 10-8
2-4
L equipment only protection, 2-4
independent link and equipment protection,
LACP 2-6
about, 5-3 link only protection, 2-2
layer 2 NT protection and passive link protection,
forwarding, 4-2 2-9
protocol handling, 5-2 subtending system protection, 2-10
IN-2 July 2006 Alcatel 7302 ISAM R2.5

Index
O VDSL
O R
OSPF-2 RADIUS
layer 3, 7-4 authentication, 9-2, 9-5
data encryption, 9-6
P server and proxy, 9-3
READSL
PPPoE about, 1-5
about, 5-12 remote CPE
IGMP, 10-8 management, 3-4
layer 3, 7-8 RIP
PPPoA to PPOE relay, 5-12 layer 3, 7-3
PPPoE relay, 5-12 RSTP
PPPoE relay in 7302 ISAM, 5-5
IGMP, 10-8 in 7330 ISAM FTTN, 5-5
programmable alarm filters, 14-5
configuration, 14-6 S
spatial alarm filters, 14-5
temporal alarm filters, 14-5 SELT
about, 15-5
Q multi-ADSL, 15-5
VDSL, 15-6
QoS service affecting alarms, 14-2
about, 11-2 snapshot alarm list, 14-3
CAC, 11-9 statistics
downstream, 11-4 about, 12-2, 13-2
on LIMs, 11-5
on SHub subsystem, 11-5 U
policy framework, 11-14
profiles, 11-10 user
subtending model, 11-15 accounting, 6-5
traffic classes, 11-4 authentication, 6-5
upstream, 11-3 authorization, 6-5
QoS profiles IP@ management, 6-6
CAC profile, 11-10 service provider selection, 6-6
marker profile, 11-11
policer profile, 11-11 V
queue profile, 11-11
scheduler profile, 11-12 VBAS
session profile, 11-12 query, 5-7
response, 5-7
VDSL
about, 1-6
INP, 1-9
SELT, 15-6
Alcatel 7302 ISAM R2.5 July 2006 IN-3

Index
VDSL2 VLAN frame
VDSL2
about, 1-6
VLAN cross-connect
about, 4-3
C-VLAN cross-connect, 4-7
protocol aware cross-connect, 4-12
S-VLAN cross-connect, 4-8
S-VLAN/C-VLAN cross-connect, 4-9
VLAN + P-bits cross-connect, 4-10
VLAN stacking, 4-7
VLAN forwarding
about, 4-2
cross-connect mode, 4-3
iBridge mode, 4-4
VLAN frame
frame type usage, 4-15
frame types, 4-15
IN-4 July 2006 Alcatel 7302 ISAM R2.5

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
2006 Alcatel. All rights reserved.
3HH-03573-AAAA-TQZZA Edition 01 Released

3hh 03573 Aaaa Tqzza 01 Isam r2 5 System Description

Uploaded by

Document Information

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

3hh 03573 Aaaa Tqzza 01 Isam r2 5 System Description

Uploaded by

Copyright:

Available Formats

Alcatel 7302 ISAM

INTELLIGENT SERVICES ACCESS MANAGER | RELEASE 2.5

3HH-03573-AAAA-TQZZA Edition 01 Released

Copyright 2006 Alcatel.

Alcatel 7302 ISAM R2.5 July 2006 iii

Table 1 7302 ISAM documentation set

Title Description Part number

CLI and TL1 documentation

iv July 2006 Alcatel 7302 ISAM R2.5

Danger Danger indicates that the described activity or situation

Warning Warning indicates that the described activity or situation

Caution Caution indicates that the described activity or situation

Note A note provides information that is, or may be, of special

Procedures with options or substeps

Procedure 1 Example of options in a procedure

a This is one option.

b This is another option.

2 You must perform this step.

Alcatel 7302 ISAM R2.5 July 2006 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 July 2006 Alcatel 7302 ISAM R2.5

1 System interface overview 1-1

3 Management functions 3-1

Alcatel 7302 ISAM R2.5 July 2006 vii

3.3 CPE remote management ................................................................................. 3-4

4 Layer 2 forwarding 4-1

5 Layer 2 protocol handling 5-1

6 Layer 3 forwarding 6-1

7 Layer 3 protocol handling 7-1

viii July 2006 Alcatel 7302 ISAM R2.5

10 Multicast and IGMP 10-1

11 Quality of Service 11-1

13 Inverse Multiplexing for ATM 13-1

14 Alarm management 14-1

15 Test features 15-1

A. RADIUS Attributes A-1

Alcatel 7302 ISAM R2.5 July 2006 ix

x July 2006 Alcatel 7302 ISAM R2.5

1.1 General 1-2

1.2 Multi-ADSL 1-2

1.3 VDSL 1-6

1.4 Configurable impulse noise protection 1-9

1.5 Ethernet 1-11

1.6 SHDSL 1-13

Alcatel 7302 ISAM R2.5 July 2006 1-1

This chapter gives a general description of the system interfaces.

Asymmetric Digital Subscriber Line (ADSL)

Asymmetric nature of ADSL

1-2 July 2006 Alcatel 7302 ISAM R2.5

Table 1-1 ADSL modes of operation

Operation Mode Description

T1.413 Issue 2 ANSI standard (ADSL ansi)

DTS/TM-06006 ETSI standard (also called ETSI ISDN)

G.992.1 Annex B Operation over ISDN non-overlapped spectrum

Alcatel 7302 ISAM R2.5 July 2006 1-3

Table 1-2 ADSL2 modes of operation

Operation Mode Description

G.992.3 Annex A Operation over POTS non-overlapped spectrum

G.992.3 Annex B Operation over ISDN non-overlapped spectrum

Table 1-3 ADSL2+ modes of operation