ISAM R4.2-System Description for 24Gbps NT

Alcatel-Lucent 7302INTELLIGENT SERVICES ACCESS MANAGER | RELEASE 4.2

Alcatel-Lucent 7330INTELLIGENT SERVICES ACCESS MANAGER FIBER TO THE NODE | RELEASE 4.2

S Y S T E M D E S C R I P T I O N F O R F D 2 4 G B P S N T3HH-08871-AAAA-TQZZA Edition 01 Released

Alcatel-Lucent 7356INTELLIGENT SERVICES ACCESS MANAGER FIBER TO THE BUILDING | RELEASE 4.2

Alcatel-Lucent ProprietaryThis document contains proprietary information of Alcatel-Lucent and is not to be disclosedor used except in accordance with applicable agreements.Copyright 2010 © Alcatel-Lucent. All rights reserved.

When printed by Alcatel-Lucent, this document is printed on recycled paper.

Alcatel-Lucent assumes no responsibility for the accuracy of the information presented, which is subject to change without notice.

Alcatel, Lucent and the Alcatel-Lucent logo are registered trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners.

Copyright 2010 Alcatel-Lucent.All rights reserved.

Disclaimers

Alcatel-Lucent products are intended for commercial uses. Without the appropriate network design engineering, they must not be sold, licensed or otherwise distributed for use in any hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life-support machines, or weapons systems, in which the failure of products could lead directly to death, personal injury, or severe physical or environmental damage. The customer hereby agrees that the use, sale, license or other distribution of the products for any such application without the prior written consent of Alcatel-Lucent, shall be at the customer's sole risk. The customer hereby agrees to defend and hold Alcatel-Lucent harmless from any claims for loss, cost, damage, expense or liability that may arise out of or in connection with the use, sale, license or other distribution of the products in such applications.

This document may contain information regarding the use and installation of non-Alcatel-Lucent products. Please note that this information is provided as a courtesy to assist you. While Alcatel-Lucent tries to ensure that this information accurately reflects information provided by the supplier, please refer to the materials provided with any non-Alcatel-Lucent product and contact the supplier for confirmation. Alcatel-Lucent assumes no responsibility or liability for incorrect or incomplete information provided about non-Alcatel-Lucent products.

However, this does not constitute a representation or warranty. The warranties provided for Alcatel-Lucent products, if any, are set forth in contractual documentation entered into by Alcatel-Lucent and its customers.

This document was originally written in English. If there is any conflict or inconsistency between the English version and any other version of a document, the English version shall prevail.

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 iii3HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

Preface

This preface provides general information about the documentation set for the 7302 Intelligent Services Access Manager (7302 ISAM), the 7330 Intelligent Services Access Manager Fiber to the Node (7330 ISAM FTTN) and the 7356 Intelligent Services Access Manager Fiber to the Building (7356 ISAM FTTB).

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, the 7330 ISAM FTTN or the 7356 ISAM FTTB.

Readers must be familiar with general telecommunications principles.

Acronyms and initialisms

The expansions and optional descriptions of most acronyms and initialisms appear in the glossary.

Assistance and ordering phone numbers

Alcatel-Lucent provides global technical support through regional call centers. Phone numbers for the regional call centers are available at the following URL: http://www.alcatel-lucent.com/myaccess.

Preface

iv November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

For ordering information, contact your Alcatel-Lucent sales representative.

Safety information

For safety information, see the Safety Manual for your product.

Documents

Refer to the Product Information document for your product to see a list of all the relevant customer documents and their part numbers for the current release.

Customer documentation is available for download from the Alcatel-Lucent Support Service website at http://www.alcatel-lucent.com/myaccess.

Product Naming

When the term “ISAM” is used alone, then the 7302 ISAM, the 7330 ISAM FTTN and the 7356 ISAM FTTB are meant. If a feature is valid for only one of the products, the applicability will be explicitly stated.

Special information

The following are examples of how special information is presented in this document.

Procedures with options or substepsWhen 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.

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.

Preface

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 v3HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

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.

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.

Release notes

Be sure to refer to the release notes (such as the Customer Release Notes or Emergency Fix Release Note) issued for software loads of your product before you install or use the product. The release notes provide important information about the software load.

Preface

vi November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

Contents

Preface iiiScope ............................................................................................... iiiAudience ............................................................................................... iiiAcronyms and initialisms ............................................................................. iiiAssistance and ordering phone numbers ........................................................... iiiSafety information..................................................................................... ivDocuments .............................................................................................. ivProduct Naming ........................................................................................ ivSpecial information.................................................................................... ivRelease notes............................................................................................v

1 — Introduction 1-11.1 General ................................................................................... 1-21.2 Supported User Interfaces ............................................................. 1-21.3 Document Structure .................................................................... 1-3

2 — System interface overview 2-12.1 General ................................................................................... 2-22.2 Overview ................................................................................. 2-22.3 Multi-ADSL................................................................................ 2-42.4 VDSL....................................................................................... 2-82.5 SHDSL .................................................................................... 2-102.6 Ethernet ................................................................................. 2-112.7 Inverse multiplexing for ATM......................................................... 2-122.8 ATM/PTM bonding...................................................................... 2-132.9 Overview of ISAM Voice interfaces .................................................. 2-132.10 Overview of ISAM support for remote management of third-party

equipment........................................................................ 2-14

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 vii3HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

Contents

3 — Failure protection and redundancy provisions in ISAM 3-13.1 Overview ................................................................................. 3-23.2 ISAM single shelf configurations ...................................................... 3-53.3 ISAM subtending system protection ................................................. 3-123.4 Failure protection at layer 3 ......................................................... 3-153.5 Network path connectivity protection.............................................. 3-15

4 — Management 4-14.1 Overview ................................................................................. 4-24.2 Management interfaces ................................................................ 4-34.3 Management interfaces security..................................................... 4-124.4 Management access models .......................................................... 4-144.5 Counters and statistics ................................................................ 4-174.6 Alarm management .................................................................... 4-174.7 Software and database management ............................................... 4-224.8 Equipment monitoring................................................................. 4-254.9 Access node control protocol ........................................................ 4-26

5 — Line testing features 5-15.1 Overview ................................................................................. 5-25.2 Metallic test access ..................................................................... 5-45.3 Single-Ended Line Testing ............................................................. 5-75.4 Dual-ended line testing ................................................................ 5-85.5 Metallic-Ended Line Testing ........................................................... 5-95.6 ATM F5 ................................................................................... 5-105.7 Link Related Ethernet OAM ........................................................... 5-105.8 Narrowband Line Testing ............................................................. 5-125.9 SFP diagnostics ......................................................................... 5-14

6 — Network timing reference support in ISAM 6-16.1 Introduction.............................................................................. 6-26.2 ISAM clock system and NTR extraction .............................................. 6-66.3 Downstream NTR clock distribution ................................................. 6-156.4 Applicable standards .................................................................. 6-16

7 — xDSL features 7-17.1 Overview ................................................................................. 7-27.2 Configurable impulse noise protection .............................................. 7-37.3 RFI Notching ............................................................................. 7-47.4 Low-power modes....................................................................... 7-47.5 Seamless rate adaptation .............................................................. 7-67.6 Upstream power back-off.............................................................. 7-77.7 Downstream power back-off .......................................................... 7-87.8 Impulse noise monitor................................................................. 7-107.9 Virtual noise ............................................................................ 7-107.10 Artificial noise .......................................................................... 7-117.11 Physical Layer Retransmission (RTX) ................................................ 7-127.12 Per-line configuration overrule ...................................................... 7-13

viii November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

Contents

8 — Integrated Voice service: ISAM Voice 8-18.1 Introduction.............................................................................. 8-38.2 Overall network topology .............................................................. 8-38.3 Product and market applicability.................................................... 8-118.4 Overall network support .............................................................. 8-148.5 VLAN / user-to-user communication applicability ................................ 8-148.6 Traffic types ............................................................................ 8-168.7 Traffic forwarding methods .......................................................... 8-178.8 Layer 2/layer 3 addressing topologies .............................................. 8-448.9 Protocol stacks ......................................................................... 8-778.10 Management interface ................................................................ 8-868.11 Permanent data storage .............................................................. 8-918.12 Management model .................................................................... 8-928.13 CDE profile management ........................................................... 8-1058.14 Service profile management ....................................................... 8-1058.15 Performance monitoring ............................................................ 8-1068.16 Reliability, Equipment / Connectivity / Overload Protection................. 8-1158.17 Quality of Service .................................................................... 8-1208.18 DHCP interworking ................................................................... 8-1218.19 DNS interworking..................................................................... 8-1228.20 Basic call handling and supplementary services................................. 8-1238.21 BITS Support .......................................................................... 8-1348.22 Narrowband Line Testing ........................................................... 8-1358.23 Termination local loop unbundling ................................................ 8-1358.24 Subscriber Line Showering .......................................................... 8-1368.25 Lawful Intercept...................................................................... 8-1368.26 Compliancy to standards............................................................ 8-1388.27 ISAM Voice migration ................................................................ 8-140

9 — Layer 2 forwarding 9-19.1 Introduction.............................................................................. 9-29.2 The concept of Virtual LAN (VLAN)................................................... 9-29.3 ISAM Internal Architecture............................................................. 9-89.4 Support for Jumbo frames ............................................................ 9-139.5 Subscriber access interface on the LT board ...................................... 9-139.6 iBridge mode............................................................................ 9-169.7 VLAN cross-connect mode ............................................................ 9-299.8 Protocol-aware cross-connect mode ................................................ 9-409.9 IPoA cross-connect mode ............................................................. 9-449.10 Secure forwarding in iBridge and VLAN cross-connect ........................... 9-469.11 Virtual MAC.............................................................................. 9-499.12 PPP Cross-connect mode.............................................................. 9-549.13 IP-aware bridge mode ................................................................. 9-57

10 — Protocol handling in a Layer 2 forwarding model 10-110.1 Introduction............................................................................. 10-210.2 Link aggregation........................................................................ 10-310.3 RSTP and MSTP ......................................................................... 10-510.4 Connectivity Fault Management ..................................................... 10-710.5 802.1x support........................................................................ 10-10

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 ix3HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

Contents

10.6 ARP ..................................................................................... 10-1110.7 VBAS.................................................................................... 10-1210.8 DHCP ................................................................................... 10-1310.9 IGMP.................................................................................... 10-1910.10 PPPoE .................................................................................. 10-1910.11 DHCPv6 ................................................................................ 10-24

11 — IP routing 11-111.1 Introduction............................................................................. 11-211.2 IP routing features ..................................................................... 11-211.3 IP routing model........................................................................ 11-511.4 Routing in case of subtended ISAMs ................................................. 11-7

12 — Protocol handling in a Layer 3 forwarding model 12-112.1 Introduction............................................................................. 12-212.2 IPv4 Routing Protocols................................................................. 12-212.3 ARP ....................................................................................... 12-312.4 DHCP relay agent....................................................................... 12-412.5 DHCP snooping.......................................................................... 12-7

13 — Multicast and IGMP 13-113.1 Overview ................................................................................ 13-213.2 Advanced capabilities ................................................................. 13-513.3 System decomposition............................................................... 13-1313.4 Multicast and forwarding models .................................................. 13-13

14 — Quality of Service 14-114.1 Introduction............................................................................. 14-214.2 Upstream QoS handling ............................................................... 14-214.3 Downstream QoS ....................................................................... 14-814.4 Hardware mapping of QoS functions .............................................. 14-1014.5 Configuration of QoS................................................................. 14-15

15 — Resource Management and Authentication 15-115.1 Introduction............................................................................. 15-215.2 RADIUS features ........................................................................ 15-215.3 802.1x authentication via RADIUS ................................................... 15-215.4 Operator authentication via RADIUS ................................................ 15-215.5 Encryption of authentication data .................................................. 15-315.6 Lawful interception.................................................................... 15-3

A. Cross-domain solutions A-1A.1 Overview ................................................................................. A-2A.2 Mobile backhaul ......................................................................... A-3A.3 E1/T1 Leased Line Replacement ....................................................A-10A.4 ISAM Backhaul (Rural DSL, Ultra-high Broadband) ................................A-14

x November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

Contents

A.5 Hospitality solution ....................................................................A-20A.6 Open Community Broadband for Smart Communities ............................A-26

B. RADIUS Attributes B-1B.1 RADIUS Attributes ....................................................................... B-2B.2 Vendor specific RADIUS attributes.................................................... B-2

Glossary

Index

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 xi3HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

Contents

xii November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 1-13HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

1 — Introduction

1.1 General 1-2

1.2 Supported User Interfaces 1-2

1.3 Document Structure 1-3

1 — Introduction

1-2 November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

1.1 General

This document provides the system description for the following products:

• 7302 Intelligent Services Access Manager (ISAM)• 7330 ISAM Fiber To The Node (FTTN)• 7356 and 7357 ISAM Fiber To The Building (FTTB)

For specific product details on each of these systems, see the:

• 7302 ISAM Product Information• 7330 ISAM FTTN Product Information

The ISAM is a frame-based Multi Service Access Platform, offering high-density copper and fibre connections for multimedia, high-speed internet access, voice and business services.

The position of the ISAM in the network is visualized in Figure 1-1, showing on the left side the different types of user interfaces that terminate on the Line Termination (LT) boards in the system.

The ISAM can be deployed with numerous interfaces and in different network environments.

1.2 Supported User Interfaces

The ISAM network architecture is shown in Figure 1-1.

Note — This document also covers the 7356/7357 ISAM FTTB.

1 — Introduction


Figure 1-1 ISAM Network Architecture

Depending on the type of LTs plugged into the system, three types of user interfaces are available:

• a number of different DSL interfaces (depending on the related DSL line board family),

• Ethernet interfaces• voice interfaces

The three types of user interfaces can be implemented simultaneously in one system.

More details on every of these interfaces is available in chapter “System interface overview”.

1.3 Document Structure

Following a general chapter about all of the system interfaces, this document is organized in a number of functional areas providing an end-to-end view of the different ISAM feature domains.

xDSL ISAM

FE/GE

FE/GE

IP Edge Router / BRAS

EMAN

EthernetSwitch NSP IP backbone

NSP IP backbone

NSP IP backbone

xDSLLT

EthLT

VoiceLT

xDSL

Ethernet

Voice NT

FE/GE

FE/GE

Ethernet

Voice

1 — Introduction



2 — System interface overview

2.1 General 2-2

2.2 Overview 2-2

2.3 Multi-ADSL 2-4

2.4 VDSL 2-8

2.5 SHDSL 2-10

2.6 Ethernet 2-11

2.7 Inverse multiplexing for ATM 2-12

2.8 ATM/PTM bonding 2-13

2.9 Overview of ISAM Voice interfaces 2-13

2.10 Overview of ISAM support for remote management of third-party equipment. 2-14



2.1 General

This chapter provides a general description of the system interfaces.

The ISAM can be deployed with numerous interfaces and in different network environments. The basic deployment uses it for providing High-Speed Internet (HSI), Video, and Voice over IP (VoIP) services to subscribers.

A specific use of the ISAM is to provide classic telephony services to subscribers being connected with classic Plain Old Telephone Service (POTS) or Integrated Services Digital Network (ISDN) lines, and to convert within the ISAM the corresponding signals to VoIP signaling and data packets. This specific use of the ISAM is known as ISAM Voice.

2.2 Overview

The following section provides an overview of the different relevant aspects for subscriber links.

Link transmission technology

In general, the subscriber links are terminated on the Line Termination (LT) boards. The ISAM supports LT boards with various transmission types:

• ADSL, ADSL2, ADSL2+, and READSL2 (ITU-T G.992)• VDSL1, VDSL2 (ITU-T G.993)• SHDSL (ITU-T 991.2, YD/T1185-2002, IEEE 802.3)• Ethernet (IEEE 802.3)

The Ethernet subscriber links can also be terminated on the Network Termination (NT) boards or the NT I/O boards.

The network links (ISAM uplinks), subtending links (to the subtended ISAM) or inter-shelf links (ISAM downlinks from the host shelf to remote shelves, Remote Expansion Modules (REMs) or Sealed Expansion Modules (SEMs)) are terminated by the Network Termination (NT) boards, by the NT I/O boards, or by an Ethernet LT board operating in Network-to-Network-Interfacing (NNI) modus:

• Ethernet (IEEE 802.3)

Figure 2-1 shows a diagram of approximate achievable downstream bit rates for the preceding DSL transmission types as a function of the line length for a 0.4 mm diameter (26 AWG) twisted pair.

Note — For ease of understanding, the ISAM Voice links are described separately, see section “Overview of ISAM Voice interfaces”.



Figure 2-1 DSL types: downstream bit rate as a function of line length

Transfer modes

The ISAM supports the following transfer modes for the preceding transmission types:

• Asynchronous Transfer Mode (ATM) is supported for all ADSL types and SHDSL.

• Packet Transfer Mode (PTM) with 64/65 octet encapsulation/Ethernet in the First Mile (EFM) is supported for SHDSL, VDSL1, VDSL2, and some ADSL2/2+ LT boards. This transfer mode uses 64/65 byte block coding of variable size frames or frame fragments at the transmission convergence sublayer in the modem. For VDSL1, HDLC will be used if VTU-R is not able to support 64/65 encapsulation.For PTM over ADSL2/2+, preemption is supported in the upstream direction and enabled by default (not configurable).

• IEEE 802.3 Ethernet frame transfer

Bonding

A number of methods exist to combine multiple physical links that apply the preceding transmission types and transfer modes to a single logical subscriber interface. This allows increasing either:

• the available service bandwidth for a subscriber• the distance across which a standard service bandwidth package can be offered,

in case of transmission types for which the achievable link bandwidth depends strongly on the length of the local loop

• a combination of the preceding two methods.

0

10

20

30

40

50

60

70

80

90

100

0 1 2 3 4 5 6 7

Lin e le n g th (km)

Do

wn

str

ea

m b

it ra

te (

Mb

/s)

VDSL2

VDSL

ADSL2+

ADSL2

ADSL



Bonding of multiple links is possible at different levels in the ISAM, where the traffic of DSL links is aggregated. The broader the scope of the bonding capability, the more flexibility an operator has to configure bonding groups.

The following bonding methods are defined within the standards:

• Inverse Multiplexing for ATM (IMA): ATM Forum Specification af-phy-0086.001

• ATM Bonding: ITU-T G.998.1• PTM Bonding: ITU-T G.998.2• M-pair operation for SHDSL: ITU-T G.991.2

2.3 Multi-ADSL

The ISAM supports multi-ADSL subscriber lines. This section describes the different supported ADSL types.

ADSL1

Asymmetric Digital Subscriber Line (ADSL) is used on existing metallic twisted pairs (one per subscriber) 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 Plain Old Telephone Service (POTS) or Integrated Services Digital Network (ISDN).

Other advantages of ADSL are:

• The existing 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 that the downstream and upstream bit rates are different:

• The downstream bit rate can range from 32 kb/s up to 8 Mb/s (or 15 Mb/s with the optional S=0.5). The bit rate granularity is 32 kb/s.

• The upstream bit rate can range from 32 kb/s to 1.5 Mb/s. The bit rate granularity is 32 kb/s.

The chosen rate depends on the bidirectional services to be supported and the loop characteristics.

This transmission type allows high-bandwidth services, for example, digital audio and video (multimedia), Ethernet interconnection to the customer, and so on.

Note — In practice, the maximum achievable upstream bit rate is typically below 1.5 Mb/s. For example, the maximum achievable upstream bit rate for Annex A is 1.2 Mb/s.



Bidirectional transport

With ADSL, the transport system provides bidirectional asymmetric communication over a single twisted pair without repeaters.

ADSL services

The multi-ADSL mode and maximum physical bit rate is automatically determined during initialization of the modem, based on line conditions and the line configuration. Modem initialization is done using a predefined noise margin and within the constraints of the transmit power spectral density. This allows various levels of service, for example, offering the highest bit rates at a premium or ensuring a guaranteed bit rate.

Operational modes

Table 2-1 lists the supported ADSL1 operational modes.

Table 2-1 ADSL operational modes

ADSL2

The ADSL2 family of ADSL standards adds features and functionality that boost the performance, improve interoperability, and support new applications, services, and deployment scenarios.

ADSL2 includes the following:

• Better rate and reach:Improved modulation efficiency, improved initialization state machine, enhanced signal processing algorithms, reduced framing overhead, and framing extension allowing higher coding gain.

• Loop diagnostics:Real-time performance-monitoring capabilities provide information regarding line quality and noise conditions at both ends of the line (see chapter “Line testing features”, section “Single-Ended Line Testing”). In addition, ADSL2 provides Carrier Loop diagnostics based on Dual-Ended Line Testing (DELT) (see chapter “Line testing features”, section “Dual-ended line testing”).

• Packet-based services:ADSL2 amendment 1 brings native transport of packets such as Ethernet

Operation Mode Description

T1.413 Issue 2 ANSI standard; operation over POTS non-overlapped spectrum

DTS/TM-06006 ETSI standard; operation over ISDN non-overlapped spectrum

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 Internetaccess at up to 1.5 Mb/s downstream and up to 512 kb/s upstream.



• Impulse Noise Protection (INP):See chapter “xDSL features”, section “Configurable impulse noise protection”.

• Physical Layer Retransmission (RTX):See chapter “xDSL features”, section “Physical Layer Retransmission (RTX)”.

• Bonding:ADSL2 also specifies IMA. However, this has been replaced by bonding support as per G.998.1; see section 2.8 “ATM/PTM bonding”.

• Low-power modes (L2/L3):See chapter “xDSL features”, section “Low-power modes”.

• Seamless Rate Adaptation (SRA):See chapter “xDSL features”, section “Seamless rate adaptation”.

• Carrier masking:The carrier mask allows the suppression of each individual carrier in the upstream and downstream direction.

• Mandatory receiver support of bit swapping:Bit swapping reallocates data and power (that is, margin) among the allocated subcarriers without modification of the higher layer features of the physical layer. After a bit swapping reconfiguration, the total data rate is unchanged and the data rate on each latency path is unchanged.

• Radio Frequency Interference (RFI) egress control and means for RFI ingress control:To minimize the impact of radio frequency interference from and with AM radio and radio amateurs, multi-ADSL provides RFI egress control and means for RFI ingress control.

Operational modes

Table 2-2 lists the supported ADSL2 operational modes.

Table 2-2 ADSL2 operational modes

A license counter keeps track of all the installed lines on which G.992.3 or G.992.5 Annex M is enabled.

A license counter keeps track of all the installed lines on which G.992.3 or G.992.5 Annex J is enabled.


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

G.992.3 Annex J All Digital Mode operation with non-overlapped spectrum and extended upstream band (spectrally compatible with ADSLx over ISDN)



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 doubling the ADSL frequency range up to 2.2 MHz, downstream bit rates of up to about 25 Mb/s can be provided.

Operational modes

Table 2-3 lists the supported ADSL2+ operational modes.

Table 2-3 ADSL2+ operational modes

A license counter keeps track of all the installed lines on which G.992.3 or G.992.5 Annex M is enabled.

A license counter keeps track of all the installed lines on which G.992.3 or G.992.5 Annex J is enabled.

Reach Extended ADSL2

Reach Extended ADSL2 (READSL2) is specified by ADSL2 Annex L, proposing new Power Spectral Density (PSD) masks that can result in a significant increase in ADSL reach.

Operational modes

Table 2-4 lists the READSL2 operational modes.

Table 2-4 READSL2 operational modes


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

G.992.5 Annex J All Digital Mode operation with non-overlapped spectrum and extended upstream band (spectrally compatible with ADSLx over ISDN)


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



2.4 VDSL

Very high bit rate Digital Subscriber Line (VDSL) allows very high speed data transmission on a metallic twisted pair between the operator network and the customer premises. 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 ISDN services can still be provided on the same wires. VDSL transceivers use Frequency Division Duplexing (FDD) to separate upstream and downstream transmission.

VDSL1

VDSL1 mode is not supported.

VDSL2

The VDSL2 standard (G.993.2) is an enhancement to VDSL1. VDSL2 specifies Discrete Multi-Tone (DMT) modulation and is reusing concepts of G.993.1 (VDSL1) and G.992.3 (ADSL2) recommendations, using also the G.994.1 handshake procedure.

VDSL2 features

The main features of VDSL2 are:

• VDSL2 offers Packet Transport Mode (PTM) with 64/65B encapsulation:• The definition of profiles supports a wide range of deployment scenarios:

• 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 supports higher bit rates than VDSL1; up to 100 Mb/ symmetrical.The attainable maximum data rate depends on the VDSL2 profile used. Support of 100 Mb/s requires the 30 MHz profile. Other profiles are better suited for operation on longer loops, but with reduced maximum bit rate.

• VDSL2 offers improved performance over VDSL1:• addition of Trellis coding• increased maximum allowable transmit power

• VDSL2 features provide better support for triple play over VDSL• improved Impulse Noise Protection (INP)• physical layer retransmission (RTX)• virtual noise (optional)

• VDSL2 has some ADSL2-like features:• similar: loop diagnostics• improved: PSD shaping• improved management with regard to VDSL1



VDSL2 Operational Modes

Table 2-5 lists the supported VDSL2 operational modes.

Table 2-5 VDSL2 operational modes

VDSL2 profile parameter overview

VDSL2 profiles mainly define variants with different bandwidths and transmit powers. Table 2-6 provides a VDSL2 profile parameter overview.

Table 2-6 VDSL2 profile parameter overview

Notes(1) US=upstream; DS=downstream(2) M=Mandatory; O=Optional; N=Not supported


G.993.2 profile 8A VDSL2 profile 8A

G.993.2 profile 8B VDSL2 profile 8B

G.993.2 profile 8C VDSL2 profile 8C

G.993.2 profile 8D VDSL2 profile 8D


G.993.2 profile 12B VDSL2 profile 12B


VDSL2 profile

Parameter 8A 8B 8C 8D 12A 12B 17A

Max. aggregate DS transmit power (dBm) 17.5 20.5 11.5 14.5 14.5 14.5 14.5

Max. aggregate US transmit power (dBm) 14.5 14.5 14.5 14.5 14.5 14.5 14.5

US0 support(2) M M M M M O O

Annex A (998)

DS upper frequency (MHz) 8.5 8.5 8.5 8.5 8.5 8.5 17.664

US upper frequency (MHz) 5.2 5.2 5.2 5.2 12 12 12

Annex B (997)

DS upper frequency (MHz) 7.05 7.05 7.05 7.05 7.05 7.05 N/A

US upper frequency (MHz) 8.83 8.83 5.1 8.83 12 12 N/A

Annex B (997E)

DS upper frequency (MHz) 7.05 7.05 7.05 7.05 7.05 7.05 14

US upper frequency (MHz) 8.832 8.832 5.1 8.832 12 12 17.664

Annex B (998E)



Annex B (998ADE)





2.5 SHDSL

The Symmetric High-speed Digital Subscriber Line (SHDSL) technology is a physical layer standard based on the ITU-T Recommendation G.991.2 (G.shdsl). The recommendation describes a versatile transmission method for data transport in the telecommunication access networks. SHDSL supports ATM, PTM, and EFM transport.

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 or bit rate. M-pair operation is supported for up to 4 pairs.

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 or circuit. Generally, an SHDSL LT in the system can support ATM or IMA, or ITU-T G.991.2 PTM, or IEEE 802.3ah EFM on a per-port basis.

SHDSL transceivers are capable of supporting selected symmetric user data rates ranging from 192 kb/s to 2312 kb/s, and optional up to 5696 kb/s, using Trellis Coded Pulse Amplitude Modulation (TCPAM) line code. For spectral compatibility with legacy services (including ADSLx), reach limitations can be imposed (typically by the national regulator) in function of the SHDSL bit rate.

SHDSL transceivers do not support the use of analogue splitting technology for coexistence with either POTS or ISDN.

Regional settings

Table 2-7 lists the supported regional settings.

Table 2-7 SHDSL regional settings

Payload ratesThe 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

Standards Description

G.991.2 Annex A/F Standards applicable for North America (region 1) (ANSI)

G.991.2 Annex B/G Standards applicable for Europe (region 2) (ETSI)



2.6 Ethernet

The ISAM supports the following Ethernet interfaces:

• Fast Ethernet (FE): supported on NT, NT I/O, and LT boards.• Gigabit Ethernet (GE): supported on NT, NT I/O, and LT boards.

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 network design

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 ISAM supports both modes and can adapt to either mode by way of auto-negotiation or manual configuration.

Hardware auto-negotiation

Hardware 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)• detect information defining the abilities of the link partner• determine if the two devices are compatible.

Auto-negotiation provides hands-free configuration of the two attached devices.

Using auto-negotiation, the ISAM can determine the operational mode (full or half duplex) and speed to be applied to the link.

Note 1 — The 7330 ISAM FTTN supports additional optical uplinks through the expander unit, as well as optical expansion links (downlinks).

Note 2 — For Ethernet features supported by the Ethernet Line Termination (LT) board, refer to the Unit Data Sheet (UDS) of the relevant board.



Software auto-negotiationSoftware auto-negotiation institutes a propriety protocol to negotiate a higher communication bandwidth between two auto-negotiation-capable boards (NT board on one side and LT board on the other side, both residing in the main shelf).

The operator can configure the highest possible bandwidth between two capable boards via the regular management channels. The software auto-negotiation protocol will, based on the configured values, bring the bandwidth between two auto-negotiation-capable boards to the configured maximum speed.

2.7 Inverse multiplexing for ATM

Inverse Multiplexing for ATM (IMA) is specified by ATM Forum Specification af-phy-0086.001.

IMA allows an ATM cell stream to be transported on a number of lower-rate physical links. 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 2-2 IMA

IMA requires that all bonded links operate at the same nominal rate. The original cells are not modified, and control (ICP) cells are inserted for OAM communication between the two ends.

• In the Tx direction, the ATM cells are distributed across the links in a round robin sequence.

• In the Rx direction, the ATM cells are recombined into a single ATM stream.

The IMA type of bonding is supported on SHDSL LT boards.

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.

IMA Group

PHY

PHY

PHY

IMA Group

PHY

PHY

PHY

Single ATM Cell streamfrom ATM layer

Physical link #0

Physical link #1

Physical link #2

IMA Virtual Link

Original ATM Cell stream to ATM layer



2.8 ATM/PTM bonding

ATM bonding

ATM bonding is specified by ITU-T G.998.1.

ATM bonding is applied to combine ATM-based transmission links with limited or reach-dependent bandwidth, which do not exhibit an identical transmission speed, specifically all types of ADSL. This technique does add sequence information to ATM cells, and thus allows resequencing, that is, delay variation due to speed variation across multiple physical links in one bonding group.

PTM bonding

PTM bonding is specified by ITU-T G.998.2.

PTM bonding applies to DSL links with or without identical transmission speed, because PTM implies the use of variable size PDUs, which make the use of IMA techniques impossible. PTM bonding is applied to combine EFM-based transmission links with limited or reach-dependent bandwidth, specifically VDSL2, SHDSL, and (possibly) ADSL2(+). This technique also adds sequence information to transmitted frames or frame fragments, and thus allows resequencing, that is, delay variation due to speed variations or PDU size variations, or both, across multiple physical links in one bonding group.

2.9 Overview of ISAM Voice interfaces

This section provides an overview of the different links of the ISAM Voice.

ISAM Voice supports LT boards with various types of Narrow Band (NB) subscriber links:

• Plain Old Telephone Service (POTS) link• Integrated Services Digital Network (ISDN) Basic Access (BA) link

ISAM Voice is connected to the network through Ethernet links as documented for the ISAM. See section “Ethernet”.

POTSThe POTS interface is the Z interface, that is, an analog subscriber line for connecting, for example, a POTS line. However, also other equipment such as faxes can be connected. The principles of this interface are as standardized in ITU-T Q.551 and Q.552.

The Z interface carries signals such as speech, voice band analog data, multi-frequency push button signals, and so on. In addition, the Z interface must provide for DC feeding of the subscriber set and ordinary functions such as DC signaling, ringing, metering, and so on, where appropriate.



The characteristics of this interface are as standardized in ITU-T Q.551 and Q.552. It is recognized that the characteristics of analog interfaces vary considerably from country to country and therefore the characteristics other than those defined in Recommendations Q.551 and Q.552 are not subject to ITU-T Recommendations. Within the ISAM, these are typically handled with the concept of a CDE profile.

ISDN BAThe ISDN BA interface corresponds to the U reference point of the Digital Transmission System.

The interface provides full-duplex and bit-independent transmission via two wires at a net bit rate of 144 kb/s. The net bit rate of 144 kb/s offers 1 D-channel of 16 kb/s and 2 B-channels of 64 kb/s.

The ISDN BA layer 1 specification is given in ITU-T I.430. Both 2B1Q and 4B3T encoding are applied through the use of different HW variants.

The D-channel signaling procedures are defined in the Q.920 and Q.930-Series, for the basis particularly in Q.921 and Q.931.

2.10 Overview of ISAM support for remote management of third-party equipment.

PurposeISAM supports dedicated interfaces for the remote management of co-located third-party equipment through Ethernet connections.

Examples are power supplies, timing supplies, Automatic Distribution Frames, environment monitoring and conditioning equipment.

Assumptions made on third-party equipment management trafficThe following assumptions are made about the third-party equipment management traffic:

• The equipment uses an Ethernet interface with untagged frames for remote management.

• The third-party equipment can be identified in the network through either:• a pre-configured IP address, for which a destination MAC address can be retrieved

through use of the ARP protocol.• a public MAC address.

• The third-party equipment traffic is conveyed in a dedicated VLAN. This VLAN is configurable by the operator

• The communication protocol used for remote managing of the third-party equipment allows detection of communication corruption or disruption.



Stand-alone ISAM with NT functions

Physical interface

In this case, the third-party equipment can be connected to a free Ethernet port of the NT function. This port has to be configured as a “direct user” port. The different ISAM NT board types either:

• provide a combo electrical 100/1000 Base-T and optical 1 GE interface as “direct user” port

• support the use of electrical 100/1000 Base-T SFPs in external port SFP cages.

Third-party management traffic handling and security

The applied NT port has to be configured for:

• VLAN-port tagging, with a dedicated third-party equipment management VLAN value

• VLAN cross-connect.

Remote LT equipment without NT functionsIn the case of ISAM REM and SEM equipment, the third-party equipment can be connected to:

• any REM/SEM equipment by means of a DSL modem with 10/100Base-T subscriber port connected to one of the REM/SEM ports. VLAN tagging/stripping and destination MAC address filtering are configured on the bridge port associated to the REM/SEM DSL line used for this purpose.

• FD-REM equipment by means of a 10/100Base-T electrical interface, provided on the REM control board NRCD-x.In this configuration, the average traffic load must not exceed 50 kb/s, or 50 packets/s.

Third-party management traffic handling and securityThe FD-REM external equipment management port has to be configured for VLAN-port tagging, with a dedicated third-party equipment management VLAN value.

VLAN cross-connect behavior is default and not configurable on this port.

For enhanced security in remote cabinets, it is possible to restrict allowed destination MAC addresses in upstream Ethernet traffic on this port to a white-list of 20 MAC address ranges. Each entry of this list consists of:

• an Original manufacturer Unique Identifier (OUI) value, covering the three Most Significant Bytes (MSB) of the public MAC address

• a start value and an end value of a single consecutive range of MAC addresses for the above OUI, covering at maximum the full three Least Significant Bytes (LSB) of the public MAC address.



The ISAM itself does not support detection of malfunctions on the FD-REM external equipment management port, and will not generate alarms related to usage of this port


3 — Failure protection and redundancy provisions in ISAM

3.1 Overview 3-2

3.2 ISAM single shelf configurations 3-5

3.3 ISAM subtending system protection 3-12

3.4 Failure protection at layer 3 3-15

3.5 Network path connectivity protection 3-15



3.1 Overview

When you provide protection for system functions and subsystems by use of redundancy, you improve the reliability of those parts of the ISAM, and hence the availability of the whole ISAM.

Redundancy aspectsRedundancy has different aspects, and each aspect has its advantages and disadvantages which must be taken into account. The following aspects are described:

• relation between essential and redundant resources• operational mode of the additional redundant resources• the scope of the protection - the impact of a failure• the average duration of an outage - time to repair• the number of simultaneous failures that have to be coped with

Relation between essential and redundant resources

• Bilateral:One redundant resource can back up only a single dedicated essential resource (notation 1:1 or 1+1).The advantage is that the redundant resource can be fully preconfigured, and that protection normally takes a minimal time. Also, the configuration data (static, or dynamic, or both) necessary for the redundant resource can be kept on the redundant resource itself.The disadvantage is that each essential resource has to be duplicated, which adds to the cost, the space requirements, and the power consumption.

• Dynamic:A redundant resource can replace any one resource out of a group of identical essential resources (notation N:1 or N+1, or N:M or N+M in general).Because each essential resource does not have to be duplicated, one or a few additional resources can protect a much larger group of identical essential resources.The disadvantage is that this scheme only is applicable when multiple identical essential resources are present in the ISAM. In many cases, the redundant resource cannot be fully preconfigured. The redundant resource can only be configured after the failing resource has been identified, which means the time for protection has to be increased by the configuration time. Also, an up-to-date copy of the configuration data (static, or dynamic, or both) for the multiple essential resources has to be kept in a place that is not affected by failure of the related resource. This requires either additional storage on the redundant resource, or a more complex data storage mechanism across all the protected resources.



Operational mode of the additional redundant resources

• Standby:One or more redundant resources are kept inactive or on standby while one or more essential resources perform all the required processing (notation 1:1, N:1,N:M in general).The advantages are that the ISAM architecture is relatively simple, and the configuration and initialization of the redundant resource(s) starts from a well-known state at the time of activation of the redundant resource(s) in case of a protection switchover. The standby state can apply on the data path, the control path and/or the management path (see “Redundancy provision” for more information and practical examples).The disadvantages are that the redundant resource does not contribute to the operation (performance) of the ISAM for 99.9% or more of the time, while requiring an additional, up to 100% investment in cost, space and power consumption. Also, in many cases the redundant resource cannot be monitored or tested for 100% of the functions that it has to perform, so a certain risk of dormant faults exists.

• Active and load sharing:All resources (reflected in the data path, control path and/or management path) are active or operational, normally in a load-sharing mode, but the number of resources in the ISAM exceeds the minimum needed to perform all the necessary processing by one, or more (notation 1+1, N+1, or N+M in general). Some resources can be implemented in load-sharing mode, while others are implemented in active/standby mode (see “Redundancy provision” for more information and practical examples).If one or more of the active resources fail, the remaining resources take over the whole processing load. Also, all the resources can be monitored in operational conditions, and dormant faults cannot occur.The advantage of this type of redundancy is that the ISAM performance increases while no faults occur, by virtue of the more-than-necessary active resources.The disadvantages are that the ISAM usually becomes more complex. A dispatching or processing load distribution function is necessary, which must be fair (that is, the load must be shared evenly over all the resources) and must be able to recognize resource failures in time and to respond to them. Also, this function must not constitute a (significant) single-point-of-failure in itself.

The scope of the protection - the impact of a failure

Usually, it is not economical to protect functions or sub-systems that affect only a limited number of subscribers, interfaces or a limited amount of traffic. An often applied principle is that central resources or aggregation resources (that is, resources whose availability determines the availability of the whole ISAM) are protected, while tributary resources are not protected. However, it depends on the specifics of each individual case whether this principle is economically viable, in either direction.



The average duration of an outage - time to repair

Redundancy of a resource nearly always should be optional. In many cases the need for providing redundancy or not for a given resource is determined by the average time to repair. A resource in a system may be reliable enough (that is, its Mean time Between Failure (MTBF) is high enough) to operate in a non-protected way. This is the case, for example, in an attended CO environment, where a stock of spare parts and skilled staff are available and where short detection and intervention times can be guaranteed. However, the same resource may require redundancy when deployed in an unattended outdoor cabinet, in order to meet the same availability as in the CO.

The number of simultaneous failures that have to be coped with

Individual Replaceable Items (RI) in modern, carrier-grade telecommunication equipment are already highly reliable, and provide an intrinsic availability of 99.99% or even 99.999%, within the boundaries of the specified environmental operating conditions. In order to achieve the generally required 99.9999% availability, coping with a single resource failure (that is, providing at most one redundant resource) is sufficient in all circumstances. The probability of dual simultaneous failures, affecting the same type of resource, is low enough, and does not have to be taken into account for protection.

Redundancy provisionThe ISAM basically provides redundancy as an option for essential central or aggregation functions and resources. These include:

• External link protection for:• network links• links with sub-tended ISAMs

• Equipment protection for the ISAM:• Data path: the Ethernet switch fabric• Control path: the Network Termination (NT) board processor• Management path: the NT board processor

The ISAM does not protect all the central functions or resources by default. Essential functions and resources reside on the NT board, which can be made redundant. In practice, a number of different configurations with single, redundant NT and single NT IO board are possible, each supporting a different amount or type of protection.

The ISAM can be configured in active/standby mode by means of an optional standby NT board. The standby NT board is synchronized with the active NT board. In order to speed-up the reconfiguration of the data plane after switchover and to facilitate the rebuilding of the control plane, the dynamic switch configuration (L1 and L2) is also synchronized between the active NT board and the standby NT board. The management plane is fully restored at the moment the new active NT board is initialized.



3.2 ISAM single shelf configurations

Single NTWhen using a single NT board only in the ISAM shelf, only redundancy for external (network or subtending) links is available, and hence only external link protection is possible. None of the central functions and resources are duplicated, except for the external Ethernet interfaces on the faceplate of the NT board itself. The actual number of these interfaces may vary with the NT type, but equals at least two. This implies that one or more external network or subtending links can be configured to protect other network or subtending links on the same NT board.

It must be clear that this link-only protection model does not protect equipment. If the NT board fails, connectivity on all the links will be lost. The supported mechanisms are described below.

External link protection: active/standby NT links

External NT links of the ISAM can be configured in active/standby mode on the single NT board of the ISAM. In case an active NT link fails, all traffic will be switched to the designated standby NT link as shown in Figure 3-1.

Figure 3-1 Link protection with active/standby external NT link

Link failure on the active NT link is detected by either:

• detection of “Loss of Signal” on the NT link• the (Rapid) Spanning Tree Protocol (RSTP) or Multiple Instances Spanning Tree

Protocol (MSTP). Normally, xSTP will allow only one network link to be active, while all other network links will be forced to standby, in order to avoid loops in the Ethernet network.

External link protection: Link aggregation

A set of N (1 ≤ N ≤ 8) physical NT interfaces can be configured in load-sharing mode (link aggregation) as shown in Figure 3-2. Apart from increasing the capacity of the resulting ISAM single network interface, this configuration also provides link protection.

NT

PHY

PHY

Active

Standby

LT1

LTn

µP



Figure 3-2 Link protection with load-sharing external NT links

If an external link for a single NT with multiple external links 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 failure detection capability of the Link Aggregation Control Protocol (LACP).

Single NT, with NTIOWhen extending the preceding configuration with an additional NTIO board in the ISAM shelf, only the number of external Ethernet interfaces is increased by the number available on the NTIO board faceplate. This number may vary with the NTIO board type.

Still none of the central functions and resources are duplicated beyond what is available on the NT + NTIO board itself. Again, one or more external network or subtending links can be configured to protect others on the same NT board, by either (R)STP, MSTP or by LACP.

Figure 3-3 Link protection with load-sharing external NT links

NT

PHY

PHY

LT1

LTn

µP

1

2

PHY

PHY

PHY

PHY

NTIO

PHY

PHY

NT

PHY

PHY

LT1

LTn

µP



Dual NT (active/standby), no NTIOWhen providing a second NT board in the same ISAM shelf, you can provide equipment protection for the NT board. The duplication provides redundancy for all the central functions and resources of the ISAM.

The ISAM supports active/standby NT equipment protection. Only one of the two NT boards (and all its functions and resources) can be active at a time. NT switchover is not revertive after the repair of a failed NT board. The protection capabilities exist:

Combined external link and NT equipment protection, common link set

Figure 3-4 illustrates the simplest configuration with a redundant NT pair, supporting an active/standby external link configuration. The active external link is connected to the active NT, while the standby external link is connected to the standby NT.

The operator can:

• configure a number of external link groups on the NT board• designate any external link of the NT board to be a member of one of the groups• configure a threshold for the minimum number of operational external links in

each group.

Figure 3-4 Combined link and NT protection with a shared set of active/standby external interfaces

Note — In practice, the redundancy is limited to the central functions and resources of the ISAM which are located on the NT board. The central functions and resources located on the NTIO board, for example, do not benefit of such equipment protection.

Active

Active

NT

PHY

PHY

LT1

LTn

µP

NT

PHY

PHY

LT1

LTn

µP



NT protection, that is, switchover of traffic from the active NT to the standby NT, and a related status change for both NT boards, is triggered by either of the following two events:

• unavailability of a network interface, which brings the number of operational network interfaces in any configured group below the configurable minimum.

• failure or removal of the NT board itself, detected by means of a dedicated protection interface between both NT boards.

This configuration implies that when the active external NT link fails, the only remedy is to trigger an NT switchover, by proper configuration of the original active link in a link group of 1, and a minimum threshold of 1.

Also, when the NT itself fails and an NT switchover is triggered, an external link switchover is imposed.

It must be noted that in all cases the standby NT board will not support traffic on its external links, and hence will not support xSTP processing while in standby mode.

Combined external link and NT equipment protection, separate link sets

Figure 3-5 shows a configuration with active and standby external links on the same NT board, in which a failure of the active external NT link does not have to lead to NT switchover. However, in case of NT board failure, its active external link cannot be kept operational, and traffic has to be switched to an additional standby link on the standby NT. This configuration is expensive in the number of required external standby links.

Figure 3-5 Combined link and NT protection with a separate set of active/standby network interfaces on each

NT

PHY

PHY

LT1

LTn

µP

NT

PHY

PHY

LT1

LTn

µP

Active

Standby

Standby

Standby



Combined external link and NT equipment protection, load aggregation link sets

Figure 3-6 shows a configuration with multiple external links that are grouped in a load aggregation group on the same NT board. Failure of the active external NT link does not have to lead to NT switchover, as long as the number of operational external links in the group does not drop below the configured minimum for the group.

Figure 3-6 Combined link and NT protection with network link and aggregation

In case of NT board failure, when this external link group cannot be kept operational, or in case the number of operational links on the active NT drops below the configured minimum, all traffic will be switched to a standby link group on the standby NT.

NT

PHY

PHY

LT1

LTn

µP

NT

PHY

PHY

LT1

LTn

µP

1

2

1

2



External link and NT equipment protection using passive optical splitters

Figure 3-7 and Figure 3-8 show redundant NT configurations that apply a passive optical splitter to interconnect a same external optical link to ports of both the active and standby NT board. These configurations are only possible for the 7302 ISAM shelves, and only for optical interfaces (not for electrical interfaces). The presence of the splitter consumes an extra 3 dB optical power of the optical link transmission budget. Use of such splitters enables the following:

• NT board equipment protection without external link protection (Figure 3-7 without standby external link)NT board equipment protection without external link protection is not possible in the preceding redundant NT configurations. Traffic can only be sent or received by the active one of the redundant NT pair, as the optical transmitters of the standby NT are physically disabled, to protect the optical signal sent out by the active NT on the shared fiber.

• Independent active/standby external link and NT board equipment protection A single pair of external links in active/standby mode can be used, as shown in Figure 3-7. It is possible to support external link protection without NT switchover, and NT board protection without external link switchover, that is, without making the peer ISAM switch traffic to the standby link.

• Independent load sharing external link group and NT board equipment protection: see Figure 3-8.

Figure 3-7 Independent active/standby external link and NT protection with optical splitters

NT

PHY

PHY

LT1

LTn

µP

NT

PHY

PHY

LT1

LTn

µP

Active

Standby



Figure 3-8 Independent load sharing external link and NT protection with optical splitters

Dual NT, with NTIOFigure 3-9 shows a redundant NT pair configuration with NTIO. The NTIO enables independent external link protection and NT board equipment protection, for external links connected to the NTIO. The NTIO replaces the passive optical splitter(s) in Figure 3-7 and Figure 3-8 with an active board. The NTIO eliminates the optical power budget reduction caused by the use of an optical splitter, and enables independent external link protection and NT board equipment protection, for electrical external links, if connected to the NTIO.

The external links on the NTIO can be configured in active/standby mode, or in load aggregation group mode, as already discussed above.

In a redundant NT pair configuration with NTIO, the external links on the faceplate of each NT, and the external links on the face plate of the common NTIO in practice cannot be combined as such in a same group, for example for constructing a bigger load aggregation group.

The reason is that in case of NT switchover, the NTIO external links will be reconnected automatically to the new active NT, while the same is not possible for external links plugged directly to the NT faceplate. It is possible to combine both types of external links in a same load aggregation group when an optical splitter is used for connecting the external links to the NT faceplate(s), as discussed for previous configurations.

NT

PHY

PHY

LT1

LTn

µP

NT

PHY

PHY

LT1

LTn

µP

1

2



It should be noted that the NTIO board is not duplicated, and, therefore, not protected. However, the probability of an NTIO failure that affects all of its external interfaces is low, so in case of a failure, outage for all of its external links will be limited to the actual duration of the board replacement.

Figure 3-9 Independent load sharing external link and NT protection with NT

3.3 ISAM subtending system protection

You can cascade multiple single-shelf ISAM systems using standard Ethernet subtending links. ISAM shelves can be connected together to provide a consolidated interface to the network.

In principle, all of the above protection techniques and configurations can be applied, for either network type links and subtending type links, or both. This depends on the required link capacity for each type, and on the interface capacity of the applied NT and NTIO board types. (R)STP, MSTP and LACP are supported on ISAM external interfaces for subtending.

The following topologies show some examples for cascading of ISAM equipment with protection:

• star topology; see Figure 3-10• daisy-chain topology; see Figure 3-11• ring topology: daisy chain with the last node connected to the first; see

Figure 3-12.

PHY

PHY

PHY

PHY

NTIO

PHY

PHY

Active

1

2

NT

PHY

PHY

LT1

LTn

µP

NT

PHY

PHY

LT1

LTn

µP



Up to three levels of cascading can be supported by the ISAM. It depends on the operator network requirements what the actual appropriate number can be in practice.

The last ISAM in the cascaded system can be any DSLAM, such as:

• a 7302 ISAM• a 7300 ASAM with a FENT or GENT• a 7325 Remote Unit• a 7330 ISAM FTTN

Figure 3-10 Example of an ISAM subtending star topology

SubtendinglinksNTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP

NTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP

NTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP

Networklinks

LAG

Subtendinglinks

LAG



Figure 3-11 Example of an ISAM subtending daisy chain topology

Figure 3-12 Example of an ISAM subtending ring topology

Networklinks

Subtendinglinks activeNTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP

NTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP

NTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP

NTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP

LAG

LAG

LAG

Networklinks

Subtendinglinks activeNTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP

NTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP

NTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP

NTIO

PHY

NT

PHY

PHY

PHY

PHY

PHYPHYPHY

NT

NT

PHY

PHY

μP

μP



3.4 Failure protection at layer 3

When the ISAM xHub is configured as a router in an layer 3 network, then connectivity protection can be achieved by enabling one or more of the following layer 3 features:

• Routing protocols: RIP, OSPF• ECMP (supported on static routes and OSPF routes)

An example is given below whereby the ISAM is used as a router in an layer 3 network and connected to more than one edge router on different subnets and physical ports. Layer 3 packets will be routed over the best route selected by OSPF.

Figure 3-13 Example of layer3-based protection

3.5 Network path connectivity protection

Network path connectivity protection technique consolidates the path connectivity between an ISAM and an upstream network device, typically the default gateway.

The feature supports both hub-only ISAMs and Hub with subtending ISAM topologies connected by means of either a layer 2 or a layer 3 aggregation network, to a redundant pair of layer 3 edge devices.

The network path connectivity protection applies to ISAM Voice access nodes that offer the Megaco service and the SIP-based integrated voice service (with the exception of the internally distributed SIP User Agent topology). It does not apply to ISAM access nodes offering data services.

A configured path connectivity protection group is composed of a minimum of two external network links or network Link Aggregation Groups (LAGs). One of these external network links or LAGs is the “active” link and carries the traffic exchanged between the ISAM and the L3 gateway. The other network link(s) is the “passive” link.

A periodic path connectivity check may reveal a potential connectivity disruption on the actual active network link or LAG. Upon the detection of such a connectivity disruption, the ISAM triggers a switchover from the active network link or LAG to (one of) the “passive” network link(s) or LAG(s)). Traffic that is exchanged between the ISAM and the layer 3 gateway is now switched to the new “active” network link or LAG.

µP

NT

PHY

PHY

LT 1

LT n

Edge router 1

Edge router 2

Subnet 2

Subnet 1

L3 switching andOSPF enabled



The path connectivity check relies on periodically initiating ICMP “echo request” packets to the target layer 3 device and listening for the ICMP “echo response” replies.

The ISAM decides that a connectivity disruption has occurred when either a “layer 1 down” event for the current network link is received or when there has been no reply to three consecutive ICMP “echo requests”.

In case a path connectivity protection group is composed of LAGs, the ISAM attempts to recover from a connectivity disruption by relying on the redundancy provided by the LAG concept, where possible. A switchover to another LAG in the path connectivity protection group is performed if the internal LAG redundancy cannot resolve the connectivity disruption.

Figure 3-14, Figure 3-15 and Figure 3-16 show the different types of network path connectivity protection topologies.

Figure 3-14 Network path connectivity protection - Network topology 1

L3 networkdevice

L2/L3switch

ISAM

VRRP

connectivityprotection

group

activeexternal

link

L3 networkdevice

L2/L3switch

passiveexternal

link





L3 networkdevice

L2switch

ISAM


group

activeexternal

link

L3 networkdevice

L2switch

passiveexternal

link

VRRP

L3 networkdevice

L2switch

ISAM


group

activeexternal

link

L3 networkdevice

L2switch

passiveexternal

link

VRRP

L2switch

L2switch

L2switch


4 — Management

4.1 Overview 4-2

4.2 Management interfaces 4-3

4.3 Management interfaces security 4-12

4.4 Management access models 4-14

4.5 Counters and statistics 4-17

4.6 Alarm management 4-17

4.7 Software and database management 4-22

4.8 Equipment monitoring 4-25

4.9 Access node control protocol 4-26

4 — Management


4.1 Overview

This chapter describes various management related topics of the ISAM. Table 4-1 below lists the information available in this chapter.

Table 4-1 Contents

The Alcatel-Lucent-recommended management architecture is shown in Figure 4-1.

Figure 4-1 ISAM management

In fact Alcatel-Lucent has an extensive management suite of products available (5520, 5529, 5530 range of Alcatel-Lucent products) to allow an efficient management of an ISAM network. Southbound, towards the ISAM, it takes care of all ISAM specifics and related protocols, while northbound it provides standard SOAP/XML interfaces for an easy and smooth integration with any other OSS applications, shielding from the DSLAM complexity.

Contents Section

Management interfaces 4.2

Management interfaces security 4.3

Management access models 4.4

Counters and statistics 4.5

Alarm management 4.6

Software and database management 4.7

Equipment monitoring 4.8

Access node control protocol 4.9

OSS

CLI

TL1

SNMP

xFTP

XMLSOAP

CLI

TL1

CLI

TL1

SNMP

xFTP

TL1 XMLSOAP

CLI

TL1

SNMP

xFTP

xFTP

xFTP5529IDM 5529

CT

RemoteCT

5530CT

5529OAD

5529APC

TL1GW

PBMT

5520 AMS

ISAMISAMLocal

CT

4 — Management


Of course a direct interaction with the ISAM itself, using CLI or TL1, remains possible, either directly connected to the ISAM or using a remote Craft terminal.

4.2 Management interfaces

The ISAM supports the following management interfaces:

• Simple Network Management Protocol (SNMP)• Command Line Interface (CLI)• Transaction Language 1 (TL1)• File Transfer Protocols: TFTP, SFTP, and FTP• Simple Network Time Protocol (SNTP)• Secure Shell (SSH)• System logging (Syslog)• Debug port for troubleshooting

These management interfaces are all supported “inband”. This means that the management interface is supported on top of an Ethernet / IP stack for which the Ethernet links are the Ethernet network links as mentioned in chapter “System interface overview”. If one such network link or uplink is dedicated only for management traffic, outband management can be realized as well.

Only the CLI and TL1 management interfaces can also be realized with a dedicated RS232 interface.

Note — When a firewall is in place between the network management stations and the ISAM network, it is required that the following UDP ports are opened on the firewall (for troubleshooting and migration reasons):

• UDP port 23 as destination port• UDP ports 928 – 939 (928 and 939 included) as source and

destination ports

Not opening these ports on the firewall may lead to a reduced or failed troubleshooting access, or a failure to perform an ISAM migration, or both.

4 — Management


Figure 4-2 ISAM management interfaces

SNMPThe Simple Network Manager Protocol (SNMP) is used by network management applications like the 5520 AMS, the 5529 Statistics and Data Collector, or the 5530 Network Analyser to manage the ISAM.

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.

SNMPv3

The security mechanisms defined in SNMPv3 protect against threats such as masquerade, modification of information, message stream modification, and disclosure and provide.

The SNMPv3 security mechanisms provide:

• data origin authentication• data integrity checks• timeliness indicator• encryption

Individual security control per management channel

2223

CLI

Telnetserver

Insecure

SSHserver

Secure

TCP

CLI Agent

161/162

SNMP

SNMPv1/v2

Insecure

SNMPv3

Secure

UDP

SNMP

File transfer

UDP TCP

InsecureSecure

Insecure

69 115 20

Mutually exclusive

SFTP

Client ServerServer

TFTP

Client

FTP

Client

10221023

TL1

Telnetserver

Insecure

SSHserver

Secure

TCP UDP

Insecure

TL1 Agent

13001

RS232serial interface

Note — SNMPv3 is supported by default. but also SNMPv2 and SNMPv1 messages can be processed.

4 — Management


SNMPv3 allows for three different security levels in that messages between agent and manager can be:

• unauthenticated and unencrypted• authenticated but unencrypted• both authenticated and encrypted

Two security-related capabilities are defined in SNMPv3:

1 User-based Security Model (USM):

The USM provides authentication and privacy (encryption) functions and operates at the message level. In addition, the USM 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 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 of 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 whether 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.

TL1The ISAM supports Transaction Language 1 (TL1) as management interface. This cross-vendor, cross-technology man-machine language is supported over UDP, telnet and SSH.

Please check the following documents for the full list and details of all the supported TL1 commands and events in the ISAM:

• 7302 ISAM | 7330 ISAM FTTN Operations and Maintenance Using TL1• 7302 ISAM | 7330 ISAM FTTN TL1 Commands and Messages Guide

The ISAM supports up to:

• five parallel TL1 sessions, when using TL1 over telnet or SHH• ten parallel sessions are possible when using UDP

In total, a maximum of ten TL1 parallel sessions are supported. When using TL1 scripts, it is recommended to strictly limit the number of active, parallel TL1 scripts to two. Anyway the TL1 response should be awaited before launching a new TL1 command to the ISAM.

4 — Management


The TL1 login banner is configurable.

CLIThe ISAM supports a Command Line Interface (CLI) as management interface. This interface is primarily intended as a man-machine interface for the ISAM and is supported over telnet, SHH, and using the serial interface (Craft).

Please check the following documents for the full list and details of all the supported CLI commands and events in the ISAM:

• 7302 ISAM | 7330 ISAM FTTN Operations and Maintenance using CLI• 7302 ISAM | 7330 ISAM FTTN CLI Command Guide

The ISAM supports up to ten parallel CLI sessions, be it over telnet or over SSH. There can only be 1 local Craft session.

xFTP

File Transfer Protocols

The ISAM supports 3 file transfer protocols: FTP, TFTP and SFTP.

TFTP is the simplest of the 3 file transfer protocols, but lacks reliability and security capabilities. It runs on top of UDP and does not require any username-password combination. There is also no encryption of data. The ISAM supports both a TFTP client and server. In server mode, the ISAM can handle up to 14 TFTP sessions.

FTP also lacks any encryption, but requires a username-password identification (“anonymous” access is not allowed) and runs on top of TCP/IP. The ISAM only supports an FTP client.

SFTP has been introduced as part of the SSH implementation. When the ISAM acts as a SFTP client towards an external SFTP server, the ISAM uses an operator-configured username & password. The security settings like encryption, hashing and signature protocols can be configured by the operator via CLI or SNMPv3. The ISAM supports both a SFTP client and server. In server mode, the ISAM supports one SFTP session at a time. Also, in SFTP server mode, the user authentication coincides with the SSH authentication, that is, the same username/password or username/key-pair combinations apply. This means that once the operator has been configured for CLI or TL1 with a username/password or for SSH with a username/key pair, the same username can be used for setting up an SFTP session with the ISAM.

External xFTP servers

External (software download, backup/restore…) xFTP servers can be configured in the ISAM. One and the same external server machine can be used as software download and backup/restore server, but they can be different machines as well. The servers might also be used in a redundant mode: if the first server cannot be reached, automatically the redundant one is tried. Multiple configurations are possible, depending on the situation and/or requirement of the customer.

4 — Management


Only one account (name, password) can be defined in the ISAM per external server:

• Even in case of multiple applications (software download, backup…) on one and the same server, only one account can be specified

• The account data is stored in encrypted format• The account data is not readable from any management interface, not even from

the SNMP manager.

xFTP Protocol selection

The xFTP protocol to be used for example for software download/backup/restore/… operations can be configured in the ISAM as a system-wide selection. That is, only one xFTP protocol can be selected at a time per ISAM. The selected xFTP protocol will be used for all applications requiring xFTP, independent of the used xFTP server or application.

Note however that as an FTP server is not supported in the ISAM (see section below), selecting FTP as protocol still allows to use the TFTP or SFTP server. When SFTP is selected as protocol though, the TFTP server will be disabled in the ISAM. Likewise, when selecting TFTP as protocol, the SFTP server will be disabled in the ISAM.

xNTPThe ISAM system time can be set in two ways:

• the system time can be retrieved from a time server using the Simple Network Time Protocol (SNTP)

• the system time can be set manually by the operator

SNTP Client

Typically, the ISAM system time is retrieved using SNTP. Although the ISAM only supports an SNTP client, the ISAM can cope both with SNTP servers and with NTP servers, using the SNTP protocol in both cases. Up to one (S)NTP server can be configured in the ISAM, specifying:

• The IP@ of the server• The port to be used• The polling rate

This data can be set using SNMP, CLI or TL1. Apart from defining the (S)NTP server, using SNTP must be explicitly enabled/disabled at operator request. The (S)NTP server will always provide the Coordinated Universal Time (UTC) time. No time zone or daylight savings settings are passed over the SNTP protocol.

Manual setting

The ISAM system time can also be set manually by the operator, using SNMP, CLI or TL1. Note however that if SNTP is enabled (see above), the set system time will be overwritten at the next SNTP poll by the UTC time.

4 — Management


Time zone offset

Using CLI or TL1 (not possible via SNMP), an operator can also specify a time zone offset in the ISAM, allowing the operator to mimic “local” time. This time zone offset:

• Is taken into account once the ISAM system time is set for the first time, be it via SNTP (at the first synchronization with the (S)NTP server), or manually (time set by the operator)

• As long as the ISAM system time has not been set, the system time will remain fixed to January 1, 1970

• Is independent of the fact whether SNTP is enabled or not, that is, it will also be applied when SNTP is disabled

• Has an allowed range of -780 to +780 minutes, with a default value of 0 minutes• Is stored persistently

The time zone offset is applied consistently for all applications in the ISAM, including SNMP, Syslog etc., i.e. the time applied by an application is always ISAM system time + time zone offset (note the default value being 0, even in case the operator did not specify any time zone offset value, the above statement still is correct).

Additional notes

• Daylight savings can not be specified nor are applied automatically in the ISAM.• ISAM management applications (5520 AMS, 5529 SDC, 5530 NA, …) typically

expect UTC timestamps from the managed nodes: the ISAM management application machine will typically apply a time zone and daylight savings correction on the timestamps received from the nodes, before displaying on the GUI, just like a with a PC. This also implies that if a time zone offset is set in the ISAM, different from 0, the timestamps on the GUI will be wrong as time corrections will be applied twice (once in the ISAM with the time zone offset and again on the management application itself). The ISAM management application typically will not take into account any time (zone) correction done in the node itself. Please check on the management applications for this aspect.

• The granularity of the ISAM time information, as provided by the ISAM applications exposing ISAM time information to external applications (Syslog, 5520 AMS, OSS, …), is seconds and has following format "yyyymmdd-hh:mm:ss".

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

SSH has a client-server architecture. The ISAM acts as the SSH server toward the manager; see Figure 4-3.

4 — Management


Figure 4-3 SSH and SFTP client-server architecture

System loggingSystem logging (SYSLOG) allows you to trace and audit system behavior related to operator and /or system activities. System log entries are issued by actions such as CLI and TL1 user logins, but also by alarms and video CDR records, for example.

With system logging, you can do the following:

• create up to 64 custom system logs that can be saved locally or to a remote server location

• create filters to determine which messages are sent to the system log files• monitor system logs

You can configure system logs using CLI, TL1 or an EMS.

File sets

The system logging works with file sets consisting of 2 log files. The operator can:

• Trigger the wrap-around from file1 to file2 in order to upload a stable file1.

• Assign a name to this file set• Specify the maximum size of the file set

SSH clientSSH server

SSH CLIclient appl

ssh client

SSH CLIserver appl

ssh server

SSH Appl. protocol

SSH transport

EMS NE

SSHClient

SFTPClient

authentication,connnection

Client authentication

Secure link for SFTP

SSHServer

SFTPServer

SFTPClient

InterPeak

- DB of client- Public keys or passwords

- NE public key- NE private key- Supported algorithms

- SFTP client- Username/password

Secure link forSW&DB

Secure link for the transferfrom FileServer to NE (SW&DB)

File

SFTP serverapplication

SFTP clientapplication

SFTP Appl. protocol

SSH transport, authentic,

connection protocol

SFTPServer

Server authentication

Secure link for CLI/TL1

Note — The ISAM will also automatically copy file 1 to file 2 when file 1 is full. Both actions (automatic by system / manual by operator) are performed independently of each other.

4 — Management


Configuring system logs

You can configure the following for each system log file:

• system log filename (local only), entered using up to eight alphanumeric characters followed by a dot separator and a three-alphanumeric character extension. Example: Alrmhigh.txt

• destination server type:• all active TL1 and CLI terminals (all-users)• all active CLI terminals (all-CLI)• all active TL1 terminals (all-TL1)• single active TL1 terminal (TL1-user)• local file (file:name:size)• remote host (udp:port:serv-ip-addr)

• destination server address, entered as an alphanumeric host name or in standard dot format (maximum value 255.255.255.255); where 0.0.0.0 is entered for local files

• enable or disable logging• delete a system log file

When a system log file is full, the ISAM will automatically copy the file (file1) to a backup file (file2) and start overwriting the oldest entries in file1 again.

You can also view system-wide information for system logs. This system-wide information includes the maximum message size allowed and statistics on the amount of combined disk space used by the local system logs. The combined maximum size of all locally saved system log files is 2 Mb.

System log filters

You can configure filters to define which messages get logged to which system log files, based on the message type; by default, all message types are logged to the system log files.

Table 4-2 lists the possible message type and log severity parameters. You can select which messages are sent to specific system log files using filters and can group multiple message types.

4 — Management


Table 4-2 Message type and log severity parameters

Operator access to the system logs

The operator access to the log file is determined by the allowed priority (access control). Different users have different access rights to the system log file, that is, some users only have read priority, while other users with higher priority have read and write (=delete) priority.

The local log files can only be retrieved via TFTP or SFTP. The removal of the files must be done via the management interface.

The operator can access the log file only after successful authentication. The authentication is done via the transfer protocol:

• no authentication for TFTP• user authentication for SFTP

System log files are to be deleted explicitly by operator command.

Viewing and monitoring system logs

The contents of a system log can be viewed either dynamically or statically.

Item Description Parameter

Message type Authentication actions AUTH

CLI commands CLI_CONFIG

TL1 commands TL1_CONFIG

CLI messages CLI_MSG

TL1 messages TL1_MSG

All message types ALL

Log severity Emergency EM

Alert AL

Critical CR

Error ER

Warning WN

Notice NO

Information IN

Debug DBG

Note — Besides these message types, the alarms and the errors encountered in the system are also logged in the system log files.

4 — Management


You can monitor remote system logs dynamically on your CLI or TL1 terminal. Setting the destination server type for the system log file to all active CLI or all active TL1 terminals sends all messages to the active terminals that have a management session with the ISAM. When you are finished monitoring the system log, deactivate system logging for that server.

You can view the static contents of a system log file that is saved to a remote server location using any text-based editor.

4.3 Management interfaces security

In order to make the ISAM securely managed, the operator must make sure that:

• A dedicated management access model is applied.• The secure variants of the used management channels are used.• A secure operator authentication method is used • Unused management interfaces are closed.• The debug port for troubleshooting is closed.

Management interfacesThe following management interfaces can be secured (refer to Figure 4-2):

• 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) and File Transfer Protocol (FTP):Can be secured by way of Secured File Transfer Protocol (SFTP)

Apart from xFTP, which is a system-wide, exclusive setting, the system allows both the secure and the insecure variant of a management interface to coexist, so that the operator is still able to contact the system in case the security setup would fail.

Simple Network Time Protocol (SNTP) does not have a secure variant. It is configured to listen to a single SNTP server (for example the Element Management System). This configuration is done via one of the management interfaces listed above. Since the operator can secure these interfaces, the SNTP configuration can be secured.

Encryption and authenticationSSH, SFTP and SNMPv3 support encryption and authentication. Table 4-3 shows the supported combinations.

4 — Management


Table 4-3 Supported SSH and SNMP Authentication and Encryption Schemes

Note(1) The username/password combinations of SSH and SNMPv3 can not be reused.

Security configurationThe configuration of the initial security parameters and user names in the system is only possible via 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 username and passwordTwo command session interfaces (CLI and TL1) are available to the operator to configure the system. To access these interfaces for the first time, the operator has to use the default username and password. However, for security purposes, the default username and password must be changed as soon as possible. For CLI the system prompts the operator to do this when he or she logs in for the first time.

Security protocol

Encryptionalgorithm

Authentication algorithm

Authentication mechanism

Combinations

SSH, SFTP 3DES, blowfish,

AES, DES-56

Hmac-sha-1, hmac-sha-1-96

Username/password(1)

Username/public and private Key

• Nothing• Encryption

only• Authorization

only• Encryption

and authorization

SNMPv3 DES-56 Hmac-sha-1, hmac-md5

Username/password(1)

Note: Different password per SNMP engine.

• Nothing• Authorization

only• Encryption

and authorization

4 — Management


4.4 Management access models

IntroductionIn most deployment models, the ISAM will use a specific management VLAN for management. Management access security in this case is guaranteed as follows:

• Any management access to the ISAM via a VLAN which is not the management VLAN is not possible. Such traffic will be dropped.

• There is a clear separation between management traffic and user traffic.• Management access is only possible via network ports. The aggregation and core

network should be designed in such a way that non-authorized users cannot get access to the management VLAN on the network port.

The management access policy will always be a combination of access checks on different layers:

• Layer 1: specific serial connector (for example, CRAFT cable)• Layer 2: a dedicated management VLAN.• Layer 3: specific IP ACLs (checks on traffic received via ingress ports)• Layer 4 - 7: authentication on protocol level

• Using SSH: user password or private public key• Using Telnet: user password• Using UDP: user password

The ISAM can support different management models to secure the access to the management plane depending on the system configuration:

• Management via a single management IP address and a specific management VLAN

• Management via the IP loopback address

Management via a single management IP addressA dedicated external management VLAN (4093) is used. The management IP address and management protocols are only accessible via the external management VLAN.

4 — Management


Figure 4-4 Management via a single management IP address

Access Control List (ACL)-based filtering on the ingress ports is possible. The filtering can be on source IP address/mask and destination port number/range. This allows to protect management against DOS attacks

Management via the IP loopback addressISAM management via loopback interface provides a management interfacing capability in an IP routing forwarding model. The IP loopback address is used as management IP address. This mode is required when the ISAM has to be managed via an IP address reachable through the NT router.

The advantage of such an interface is that the management IP address of the ISAM is decoupled from the IP subnet configured between the ISAM and the attached IP edge router.

This allows a network configuration where the aggregation network contains several IP edge routers all reusing the same IP subnet addresses towards the ISAMs they aggregate (see Figure 4-5) and minimizes router configuration. The forwarding tables of the edge routers are updated by a routing protocol such as RIP.

User traffic

NT

ISAM

LT

Phy

PhyLAG

Phy

VLAN 11

Externalmanagement

VLAN4093

Management traffic

iBridgeVLAN 23

ManagementIP stack

Management IP Address 10.177.0.122/17

IACM default-route 10.177.127.254ACL

4 — Management


Figure 4-5 Management loopback interface

Reusing the same IP subnet on all IP edge routers simplifies their configuration on the ISAM side. Of course it is required that the IP edge router does not advertise this shared IP subnet to the network.

In order to save addressing space, the loopback IP address is configured as a /32 subnet mask.

Figure 4-6 Management via the IP loopback address

IP

IP_A1/32 IP_B1;next-hop=IP_B2...

AMS FIBVRF

VRF

IP_A1

VRF

VRF

IP

ISAM1

EMAN

host routes installed via RIP

IP

Intermediate Subnet Callocated per IP edge,shared over multiple ISAMs

ISAM2

ISAM3

ISAM4

IP_A2

IP_A3

IP_A4

IP_B2

IP_B1

Edge2

RIP {IP_A1,IP_A2}(*)

RIP {IP_A3,IP_A4}(*)

Loopback interfacewith 32 IP addressesallocated for management

RIP {IP_A1}(*)

RIP {IP_A2}

RIP {IP_A3}

RIP {IP_A4}

IP_C2

IP_C3

IP_C3

(*) IP_Cx not advertised

IP_C1

IP_C1

IP_C2

IP_B3

IPEdge1

AMS

IP Edge 1 FIB

Subnet B IP_B1; dir attachedSubnet C IP_C1; dir attachedIP_A1/32 IP_C1;next-hop=IP_C2IP_A2/32 IP_C1;next-hop=IP_C3...

ISAM1 FIB (SHub)0.0.0.0/0 IP_C2;next-hop=IP_C1Subnet C IP_C2; dir attached

User traffic

NT

ISAM

LT

Phy

PhyLAG

Phy

VLAN 11

Management traffic

iBridgeVLAN 23

ManagementIP stack

LoopbackIP address /32

IACMdefault-route: network interface IP address

Internalmanagement

VLAN4093

Externalmanagement

VLAN600

VRF

Unnumbered interface

network interfaceIP address/18

4 — Management


The security in this case is based on:

• Layer 2 + Layer 3 combined:• A specific external management VLAN• ACL rules which limited the access to the management loopback IP address to this

external management VLAN• Optional ACL rules which limits the access to specific management stations

identified by IP address• Layer 4-7: specific authentication mechanisms on application level

4.5 Counters and statistics

Counters and statistics serve various purposes in the ISAM, like troubleshooting, network dimensioning and SLA adherence and are defined on both the network and subscriber side of the ISAM.

They can be retrieved from the ISAM using CLI, TL1, or an Element Management System (EMS). See the following documents for detailed information and the detailed command definitions for retrieving the ISAM counters and/or statistics using CLI or TL1:

• 7302 ISAM | 7330 ISAM FTTN Operations and Maintenance Using CLI for FD 24Gbps NT

• 7302 ISAM | 7330 ISAM FTTN TL1 Commands and Messages for FD 24Gbps NT

4.6 Alarm management

Alarm management enables you to manage alarm reporting for the ISAM. You can manage the following alarm attributes and alarm reporting functions for all basic system alarms, interface related alarms, derived alarms, and Threshold Crossing Alarm (TCA) alarm indications:

• alarm category and definition (fixed per release)• alarm severity (intermediate, warning, minor, major, and critical)• alarm is service affecting (yes, no)• alarm must be reported (yes, no)• alarm must be logged (yes, no)• alarm lists and logs severity thresholds, that is, the minimum severity of an alarm

in order to be logged or reported in the alarm snapshot and the alarm-changed trap)

• alarm filters: affect the way in which the ISAM reports its own alarms, as well as the alarms from connected remote expansion units.

See the 7302 ISAM | 7330 ISAM FTTN CLI Commands for FD 24Gbps NT and the 7302 ISAM | 7330 ISAM FTTN TL1 Commands and Messages for FD 24Gbps NT documents for alarm management command definitions.

4 — Management


Alarm categories and definition

There are four alarm categories:

• non-interface related alarms: these alarms include basic system alarms such as equipment failure alarms.

• interface related alarms: these alarms involve ATM and xDSL interfaces.• derived alarms: these alarms are raised in the system when programmed temporal

or spatial alarm filters are used (that is, alarms generated when the conditions set in an alarm filter are met). See section “Programmable alarm filters” for more information about programmable alarm filters and derived alarms.

• TCA alarms: these alarms are generated when a Performance Monitoring (PM) counter crosses a defined threshold value.

Alarms use the same definition method that consists of two main parts:

• the alarm type, which provides a general definition of the type of alarm; for example, an xDSL alarm.

• the alarm number, which identifies a specific alarm within that type; for example, a near-end LOS alarm

You can view alarm types and definitions as they are recorded in alarm lists and logs using the TL1, CLI or an EMS like the 5520 AMS. See the 7302 ISAM | 7330 ISAM FTTN Operation and Maintenance Using CLI for FD 24Gbps NT document for a complete listing of all alarms, along with their definitions. Alarm definitions are not user configurable.

Alarm severity

Managed alarms are assigned a default minimum alarm severity level. There are five alarm severity levels listed in ascending order of severity:

• indeterminate• warning• minor• major• critical

When the severity level of an alarm equals or exceeds the (system-wide) minimum severity level, that particular 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 is activated.

You can configure the (system-wide) minimum alarm severity level and the individual severity level of an alarm using the CLI or an EMS. See the 7302 ISAM | 7330 ISAM FTTN CLI Commands for FD 24Gbps NT for alarm management command definitions. Changing the 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.

4 — Management


Alarm lists and logs

You can set the alarm logging and reporting mode for individual alarms. When alarm logging and reporting are enabled, alarm indications are always sent to the appropriate alarm list and alarm log when the minimum alarm severity level for the alarm is reached. Alarm logging and reporting are enabled by default.

There are three types of alarm list:

• current alarm list• snapshot alarm list• alarm severity delta logging list

The current alarm list and the snapshot alarm list display only the currently active alarms. When the alarm reporting mode is enabled, alarm indications are sent to the current alarm list.

The alarm severity delta logging list is a log (one for each alarm severity) of alarm indications that can be accessed at any time and contains a historic record of alarm events (start and end of active alarm). Only alarms that have their alarm logging mode enabled appear on these alarm severity delta lists.

Current and snapshot alarm listsThe current alarm list changes dynamically as alarms are detected and pass through the alarm filters. Because the list changes dynamically, it is impossible to get a consistent view of the active alarm status. Therefore, if a stable view of the alarms is preferred, the snapshot alarm list captures a momentary view of the active alarm status at the time it is requested by the user. You can configure the minimum severity level of the active alarms in the snapshot list and you have access to the snapshot alarm list for a maximum time period of up to 120 seconds. The snapshot alarm list provides the active alarms ordered first by severity (high to low), and then on time-of-occurrence.

Alarm severity delta logging listA 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. You 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 to be taken when the alarm severity delta logging list reaches the configured maximum size:

• continuous wrap entries, where newer entries overwrite the oldest ones. An flag is set to indicate that there was a wrap-around

• halt alarm logging when the logging list is full. In this case, alarm logging resumes only after the alarm logging list is manually reset by the operator.

Resetting an alarm severity delta logging list empties the contents of that list. This step is required before reducing the size of a logging list and when resuming alarm logging after the logging has been halted as the logging list was full.

4 — Management


Alarm filters

There are three types of filters:

• alarm logging filter: determines if the alarm indication should be processed and recorded in one of the five alarm severity delta logging lists.

• 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 both non-interface related alarms, such as equipment failure alarms, and to interface related alarms, such as ATM and xDSL interfaces. It is possible to enable and disable alarm filtering for individual alarms.

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 for FD 24Gbps NT document for programmable alarm filter command definitions. The filters can also be configured using an EMS. There is no CLI support.

When you use programmable temporal or spatial alarm filters, the ISAM 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 configure the threshold for the number of state changes, and the time period of the filtering window. Since temporal alarm filters are severity based, only alarm indications that equal or exceed the alarm severity level are counted. In other words, it makes no sense to configure a temporal alarm filter on an alarm that has a severity below the global alarm severity level.

A derived alarm is raised in the ISAM when the number of alarm events reaches the set threshold during the filtering window time period. Figure 4-7 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.

4 — Management


Figure 4-7 Temporal alarm filter raising a derived alarm

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 that 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. Say, for example, that 100 objects in the system can experience the same alarm condition. A spatial alarm can be configured on top of the basic alarm. The spatial alarm is generated (that is, derived alarm ON condition) at the moment that a predefined number of these objects are in alarm (that is, basic alarm ON condition).

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 (current and snapshot alarm lists) and the alarm severity delta logging lists respectively. A derived alarm that is generated from a temporal filter is identified as an interface-related alarm if the basic alarm, 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.

Alarmseverity

Setlevel

Time

Alarm ON

Alarm OFF

15minutes

15minutes

15minutes

15minutes

1

Alarm ON

Alarm OFF

2

Alarm ON

Alarm OFF

3

Alarm ON

Alarm OFF

Derivedalarm ON

Derivedalarm OFF

CONFIGURED ALARM FILTER TIME PERIOD

4 — Management


Configuring programmable alarm filters and derived alarms

You can activate and deactivate alarm filters after they are created using TL1 and/or an EMS like the 5520 AMS. When you create a temporal or spatial alarm filter, the ISAM automatically copies the parameter settings of the basic alarm to which the alarm filter applies, and uses those parameter settings as default settings for the derived alarm. The settings include:

• alarm category• severity level• service affecting or non-service affecting• reporting mode• logging mode

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.

Alarm reporting

Alarm reporting of the basic and derived alarms 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.

4.7 Software and database management

Software and database management is all about controlling the software versions and databases on the system. On the ISAM a set of software and database management features are available, that are both powerful and efficient from an operational point of view.

OSWP and databasesThe ISAM is capable of hosting an active (operational) and a non-active (stand-by) Operational SoftWare Package (OSWP). Each package consists of a software version and a set of system databases. Only one of the 2 OSWP packages can be active in the ISAM, but the operator can switch between packages, making the one operational, and the other stand-by.

4 — Management


Each package also consists of a set of system databases, more in particular the SHub database, the IACM database and the xVPS databases (one physical database per xVPS pair). From an operational point of view, if not mentioned otherwise explicitly, the actions (backup, restore, migrate…) will be executed on the set as a whole, not on an individual database of the set.

Software upgrade and migrationOf course there are rules on compatibility between software and databases: a package can only become active, when the software version and the system databases in the package are compatible with one another. In this context, we make a distinction between:

• Software upgrade is the process to upgrade a network element to a higher software release not involving a migration of the system databases - there is no system database changeThis procedure is typically to be used when upgrading to a release in the same software stream, for example, from R3.6.01 to R3.6.03c

• Migration is the process to upgrade a network element to a higher software release requiring a migration of the system databasesThis procedure is normally to be used when upgrading to a release from a higher software stream, for example, from R3.6.01 to R4.0.02

A complete software upgrade/migration activity comprises of a sequence of actions:

1 The operator demands the system to download a new OSWP. This demand is the trigger for the system to initiate a file transfer session with the external file server specified by the operator. So it is not the operator who puts the software on the system disk.

2 The operator starts an off-line conversion of the DB from the source release to the destination release. It is the responsibility of the off-line migration tool to upload the complete DB, convert it to the destination release and the download it to the node again.

3 When the new OSWP is downloaded, the operator activates this new software and database set. The system will restart and come up with an upgraded software version. All persistent configuration data remains available.

4 Once the upgrade is successful, the operator can remove the former software and database package from the system in order to free space for the next upgrade.

Note that migrations and software upgrades do not have to be between consecutive software releases/streams: the necessary functionality has been provided to be able to 'skip' intermediate upgrade/migration steps. While no point for software upgrades, this is less evident for migrations.

Also, in case of a failure to upgrade, the ISAM will automatically switch back to the old software and database package and resume services.

4 — Management


Backup and restoreNext to a software upgrade and/or migration, DB management also requires the regular creation of backups in order to minimize the configuration loss in case of a system crash. This can be done either manually or automatically on a periodic basis. These ISAM backups can afterwards be restored on the ISAM if needed.

Basically there is a distinction between 2 kinds of backup files:

• dm_complete<something>.tarThis is a backup of the complete ISAM database, -including- all management data, like the IP address, the SNMP community strings and so on, required to make remote management of the ISAM possible

• dm<something>.tarThis is the same as the 'dm_complete.tar' kind of file, but -without- all management data

Typically only the 'dm.tar' kind of file is restored as otherwise the management data, required to have remote management of the ISAM, would be overwritten as well. The <something> can be any text suitable for a file name, and, in case of automatic backup enabled, this specifies the system IP address and the timestamp of creation.

The configuration data of the ISAM is autonomously saved to the ISAM database on the NT CF at different criteria:

• IACM: the database changes are cached in the system and autonomously saved to the CF

• Every 30 seconds, and/or• Whenever the cache of 5K is full (corresponds to 22 database updates), and/or• On request of an IACM application e.g. to safeguard some critical data (software

steered), and/or• As part of an ISAM database backup request

• xVPS: the database changes are autonomously saved to CF• Every 10 minutes if the xVPS configuration has changed indeed and the last xVPS

configuration change is at least 1 minute ago, and/or• As part of an ISAM database backup request

• SHub: the database changes are autonomously saved to CF• Every 10 minutes if the SHub configuration has changed indeed and the last SHUB

configuration change is at least 1 minute ago, and/or• As part of an ISAM database backup request

The SHub configuration data can be saved to NT CF (database) at operator request as well, e.g. at the end of a SHub configuration script. This is however not possible for the IACM data.

Active loadAnd last but not least, the release name of the current active ISAM software package (e.g. R3.6.01) can be consulted via SNMP, TL1 and CLI.

4 — Management


4.8 Equipment monitoring

NT CPU loadThe average NT CPU load can be monitored using CLI, TL1 and/or an Element Management System.

For SHub-based systems, both the IACM and SHub CPU loads are monitored.

The CPU load is expressed as a percentage, ranging from 0% (no load at all) to 100% (full load), and represents the average CPU load over the monitored period.

The monitoring is to be started and stopped explicitly at operator request. By default (at ISAM start-up), the monitoring is not active. Once started at operator request, the monitoring of the CPU load continues until the operator explicitly stops the monitoring.

NT memory usageThe actual NT memory usage can be polled using CLI, TL1 and/or an Element Management System.

For SHub-based systems, both the actual memory usage of the SHub and IACM is counted.

Both the absolute value (expressed in Mbytes) as well as the relative value (used percentage of the total available memory) is returned: always the actual values as of the moment of the request are returned.

Thermal sensor dataThermal sensor data can be retrieved from each board equipped with thermal sensors and running software (so, for example, not from a passive splitter board).

The data of all the thermal sensors on a particular board in an ISAM can be retrieved on-line at request of the operator. Per thermal sensor, the following data can be retrieved (all expressed in degrees Celsius):

• actual temperature• low threshold temperature for TCA (T0_low)• high threshold temperature for TCA (T0_high)• low threshold temperature for shutdown (T1_low)• high threshold temperature for shutdown (T1_high)

Only read access is provided for these parameters and none of the threshold temperature parameters can be changed by the operator. They are fine-tuned by Alcatel-Lucent in function of the actual board type and board variant.

The thermal sensor data as specified above can be retrieved via CLI, TL1 and/or using an Element Management System, and are always the actual values as measured at the moment of the request.

4 — Management


4.9 Access node control protocol

The purpose of the Access Node Control Protocol (ANCP) (also known as Layer 2 Control Protocol (L2CP)) is to allow a Broadband Network Gateway (BNG) to manage service related parameters of a DSLAM. The relevant standard is still under definition in IETF. In the ISAM a pre-standard is implemented.

In the draft ANCP standard some basic capabilities are defined, of which 2 are currently supported on the ISAM:

• Access Topology Discovery:Provides dynamic discovery of access topology by the BNG to provide tight QOS control in the access network (that is, the Ethernet Aggregation network up to and including the xDSL access loops). This can be done, for example, by shaping the traffic towards the user at the bitrate currently available in the xDSL line of the user.

• Layer 2 Operations and Maintenance:BNG controlled, on-demand xDSL access loop test capability.

In the ISAM up to 32 ANCP partitions can be configured, each partition grouping a number of xDSL subscriber lines (excluding SHDSL lines and bonding interfaces). One particular xDSL subscriber line can only belong to maximum 1 ANCP partition and each partition is managed by a dedicated set of BRASs via an ANCP session. The partitions are created and identified by the ISAM operator: the BNG/BRAS cannot set its own partition ID.

Up to 64 different ANCP sessions are supported, where for each ANCP partition, multiple sessions can be defined. But it is not allowed for one session to manage multiple partitions.

The BRAS and aggregation switches are directly attached to the ISAM via a L2 EMAN, through a dedicated VLAN, distinct from the VLAN used for ISAM management. The VLAN used for ANCP is hard coded to “6” and cannot be modified.

An alarm is raised whenever the ANCP connection between BRAS and ISAM is lost for some reason.


5 — Line testing features

5.1 Overview 5-2

5.2 Metallic test access 5-4

5.3 Single-Ended Line Testing 5-7

5.4 Dual-ended line testing 5-8

5.5 Metallic-Ended Line Testing 5-9

5.6 ATM F5 5-10

5.7 Link Related Ethernet OAM 5-10

5.8 Narrowband Line Testing 5-12

5.9 SFP diagnostics 5-14



5.1 Overview

This chapter describes the various line testing features within the ISAM and ISAM Voice.

All line testing capabilities provide a means to execute pro-active and/or re-active measurements to diagnose (potential) issues with the deployed equipment. As such they can:

• bring OPEX savings such as the ability to save on buying external test equipment, avoiding truck rolls

• increase customer satisfaction due to decreased service degradations or interrupts.

The line testing capabilities depend upon the type of interface. For an overview of the different types of interfaces (both for ISAM and ISAM Voice), see chapter “System interface overview”.

ISAM and ISAM Voice support testing for Ethernet network and subtending interfaces.

The ISAM supports various types of DSL interfaces (ATM or PTM mode) at the subscriber side, as well as Ethernet interfaces. The ISAM Voice supports POTS and ISDN lines at the subscriber side. The ISAM and ISAM Voice support line testing capabilities on all these types of interfaces.

But before considering the line test capabilities of these lines, we have to consider the nature of DSL versus POTS and ISDN.

DSL is a transmission technology that works in overlay with POTS or ISDN lines:

• “narrowband” is used for the POTS or ISDN signals• “broadband” is used for the DSL signal.

Both narrowband and broadband signals can be transported simultaneously on one physical line and a splitter technology is used to multiplex or split these signals. The part of the ISAM processing broadband is named the DSL line. The part of the ISAM Voice processing narrowband is named the POTS line or the ISDN line. Therefore, although a DSL line and a POTS or ISDN line are distinct lines from the perspective of the ISAM or the ISAM Voice, they can correspond to one physical line.

Therefore, some tests will test the DSL line (broadband), other tests will test the POTS or ISDN line (narrowband), but some tests will affect both.

The splitter technology can be integrated or can be outside of the ISAM or the ISAM Voice (refer to the 7302 ISAM Product Information or the 7330 ISAM FTTN Product Information). If integrated, this technology is supported by dedicated boards (appliques) that are managed from the ISAM. The splitter boards work in conjunction with the DSL LT boards. The physical lines, carrying both broadband and narrowband, are identified with the same identifier as the DSL line.

The overview of the line testing features:

• tests for the physical subscriber line:• Metallic Test Access (MTA)



• tests for a DSL line:• MTA• Single-Ended Line Test (SELT)• Dual-Ended Line Test (DELT)

• the DSL line can be of ATM or of PTM mode:• For DSL lines of ATM mode: ATM F5• For DSL lines of PTM mode: Link related Ethernet OAM

• tests for a POTS or ISDN line:• MTA• Narrowband Line testing

• tests for an Ethernet subscriber line:• Link related Ethernet OAM

• tests for an Ethernet network or subtending interface:• SFP diagnostics

Note that MTA appears on the list of test capabilities for the physical line, the DSL line, and for the POTS/ISDN line. This reflects that some MTA tests are for broadband, some for narrowband, some are outward toward the subscriber line, and some are inward to the MODEM/SLIC.

Figure 5-1 Position line testing capabilities for DSL - POTS/ISDN lines

RTU

DSL LT

Voice LT

DSL

line

POTS/ISDN

line

DSL applique

Relays

LPF

Subscriber line

Towards PSTN or ISAM Voice

Voice applique

Modem

SLIC Relays

(SELT, DELT)

(Narrowbandline testing)

(MTA)



5.2 Metallic test access

MTA provides a set of subscriber line tests both for narrowband and for broadband. MTA is performed on a line-by-line basis using TL1 or AMS.

MTA is a partially integrated test facility:

• MTA relies on a non-integrated Remote Test Unit (RTU) that is connected to the ISAM or ISAM Voice.

• MTA requires MTA-capable appliques terminating the subscriber line.

MTA can be used to set the relays so that the RTU gets outward access to, for example, the narrowband physical line, the broadband physical line, or the full physical line. MTA also allows setting the relays so the RTU gets inward access to test, for example, the narrowband towards the LT board terminating the POTS or ISDN line, or the broadband towards the LT board terminating the DSL line.

Note that it is possible to test the narrowband of a line from two different places:

• the narrowband line can be tested outward from the Voice applique, in which case it is managed as a test of the POTS line.Although the MTA technology applies in principle to POTS and ISDN, it must be noted that it is supported only for POTS.

• the narrowband line can be tested outward from the splitter board (DSL applique) that is associated with a DSL LT board, in which case it is managed as a test of the DSL line.In this way the MTA technology is supported for POTS and for ISDN lines.

It is also possible to equip collocated expansion shelves with MTA-capable appliques and to connect them to the host shelf with a cable, to support the same tests from the RTU connected to the host shelf.

Some tests can be executed during turn-up of a subscriber line, for example, 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: releases all test connections and frees all TAP resources.• Loop around mode: characterizes 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

testing outwards toward the line and testing inward towards the LT equipment.

Figure 5-2 shows the test access modes.

Figure 5-2 Test access modes

The two following access modes are partial implementations of the split-access mode and are called “limited test access”:

• Limited outward access mode: provides a breaking connection that allows testing outward 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: provides a breaking connection that allows testing outward 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 5-3 shows the partial implementations of split-access mode.

Note — Only full MTA requires all the test access modes.

Split access

Equipment pair

Facility pair

RTU

DSLAM

Line

PSTN

LPF

xTU-C

LPF

Released Loop around

Facility pair

Equipment pair

Facility pair

Equipment pair

RTU

DSLAM DSLAM

Line Line

PSTN PSTN

LPF

xTU-C xTU-CRTU



Figure 5-3 Partial implementations of split-access mode

MTA support in the 7302 ISAM

Full test access scenarios are supported, using the Metallic Test Access Unit (MTAU) function. The MTAU function is implemented using 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, to perform the necessary tests.

MTA support in the 7330 ISAM FTTN

Full test access scenarios are supported in the 7330 ISAM FTTN. The expansion nodes (expansion shelf and REM/SEM) do not support MTA.

• The 7330 ISAM FTTN shelf supports MTA through an MTAU function implemented by the test access board (or NTIO board with MTA function), 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 test access board to get metallic access to any subscriber line connected to the 7330 ISAM FTTN.

• The 7330 ISAM FTTN shelf uses an RJ-45 MTA connector on the test access board as the TAP for the test in and test out signals between the testhead and the shelf.

• The 7330 ISAM FTTN shelf uses these boards 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 7330 ISAM FTTN 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.

RTURTU

Limited outward access Undisturbed outward access

Facility pair Facility pair

Equipment pair Equipment pair

Line Line

LPF LPF

x-TU-C x-TU-C

PSTN PSTN

DSLAM DSLAM

Note 1 — The MTA test bus may be interconnected / daisy chained for up to 8 collocated FTTN host nodes using a maximum cable length of 10 m.

Note 2 — Since MTA is currently supported on host nodes only, the Test Operating System must insure that only one port in this daisy chain configuration is enabled at any one time



Test Access Control

Test Access Control (TAC) is done with TL1 commands, which are sent using the TL1 agent of the 7302 ISAM or 7330 ISAM FTTN shelves in response to the test head.

5.3 Single-Ended Line Testing

Single-Ended Line Testing (SELT) tests the DSL line from the DSL LT board. SELT does not require CPE to be connected to the peer side of the line.

SELT can be used as a base for a DSL service level agreement between provider and customer, and for fault detection, and monitoring of line degradation. SELT works together with external data analysis software, such as the Alcatel-Lucent 5530 Network Analyzer (5530 NA), to provide loop prequalification and maintenance of the network.

SELT can be performed from the DSL LT board without need for support by the CPE or for a craftsman to be present at the customer premises.

SELT is based on Frequency Domain Reflectometry (FDR). An excitation signal is sent on the line and its echo response is analyzed. Processing of the echo response is done in the 5530 NA. The polarity and position of the reflections indicate the loop length, attenuation, presence of a gauge wire change, and an open, short, or bridged tap and its distance from the DSL LT board of the line under test.

SELT provides a line test tool built inside the xDSL modem to measure the loop characteristics between the U-C and the U-R interface and allows for:

• detection and location of metallic faults (open/short).• detection, location and length of bridge taps.• noise measurement and detection of interferences.• measurement of the line attenuation.• estimation of the maximum achievable bit rate.• estimation of the line length.

The operator can check the presence and quality of, for example, a wire termination Main Distribution Frame (MDF) or SAI / DFI (Service Area / Feeder Distribution Interface). This feature can be of help in situations where this interconnection is being provisioned by a third party.

SELT support

SELT measurements are supported on the following boards:

• multi-ADSL LT boards• VDSL LT boards

Note — See the 5530 Network Analyzer User Guide for more information about SELT using the 5530 NA.



SELT measurements

The following SELT measurements and tests are supported:

• uncalibrated echo response• echo variance• noise

The ISAM allows up to 5 simultaneous SELT measurements per LT board.

5.4 Dual-ended line testing

Dual-Ended Line Testing (DELT) tests the DSL line from the DSL LT board. DELT requires a CPE to be connected to the peer side of the line.

This loop diagnostics function enables the immediate measurement of line conditions at both ends of the line without dispatching maintenance technicians to attach test equipment to the line. The resulting information helps to isolate the location (inside the premises, near the customer end of the line, or near the network end of the line) and the sources (cross-talk, radio frequency interference, and bridged tap) of impairments.

DELT support

DELT measurements are supported on the following boards:

• multi-ADSL LT boards• VDSL LT boards

DELT measurements

The following diagnostic measurement data are collected during a test using DELT:

• actual operational mode• operational mode capabilities (ATU-C/ATU-R)• SNR margin (US/DS)• loop attenuation (US/DS)• signal attenuation (US/DS)• aggregate output power (US/DS)• actual PSD (US/DS)• attainable bit rate (US/DS)• modem identification parameter: ATU-R ModemVendorID• carrier-related data: Hlog (US/DS), Hlin (US/DS), QLN PSD (US/DS), SNR

(US/DS)



5.5 Metallic-Ended Line Testing

Metallic-Ended Line Testing (MELT) tests the DSL line from the DSL LT board. MELT does not require the CPE to be connected to the peer side of the line.

MELT can be used as a base for fault detection and monitoring of line degradation.

MELT works together with external data analysis software, such as the Alcatel-Lucent 5530 Network Analyzer (5530 NA), to provide loop prequalification and maintenance of the network. Also basic management to start measurements and report results is provided through CLI.

MELT is performed from the DSL LT board without need for support by the CPE or for a craftsman to be present at the customer premises.

The MELT functionality is based on the technology for the narrowband POTS subscriber lines.

MELT provides a line test tool built inside the ISAM to measure the loop characteristics between the U-C and the U-R interface and allows for:

• detection and location of metallic faults (open/short/bad contacts)• detection of cable degradation (e.g. due to cable moisture)• detection of external voltages• line pair identification• detection of signature topologies

The MELT function also allows providing wetting current to dry DSL lines.

MELT supportMELT measurements are supported on the following boards:

• multi-ADSL LT boards• VDSL LT boards• SHDSL boards

MELT measurementsThe following MELT measurements and tests are supported:

• Foreign voltage (AC/DC): measures foreign voltage of a/Earth, b/Earth, and a/b• Capacitance: measures capacitance of a/Earth, b/Earth, and a/b• Insulating resistance: measures insulating resistance of a/Earth, b/Earth, and a/b• Termination detection: detects whether a termination circuit connects to the line• Pair identification tone generation

The ISAM allows up to one simultaneous MELT measurement per LT board.

Note — See the 5530 Network Analyzer User Guide for more information about MELT using the 5530 NA.



5.6 ATM F5

On ATM based DSL interfaces it is possible to use ATM F5 loopback. The following functionality, as is specified in ITU-T I.610, is supported:

• active: the operator asks for a loopback test• passive: the CPE triggers a loopback test and the ISAM responds

5.7 Link Related Ethernet OAM

Introduction

Link-Related Ethernet OAM (IEEE 802.3 clause 57 standard) enables network operators to monitor the health of the network and quickly determine the location of failing links or fault conditions. The feature allows remote side information to be retrieved for a link connected with a node for which SNMP may not be available as default.

The feature does not include functions such as station management, bandwidth allocation or provisioning functions, which are considered outside the scope of this standard.

Figure 5-4 shows a typical Link Related Ethernet OAM configuration.

Figure 5-4 Typical Link Related Ethernet OAM Configuration

General descriptionLink-Related Ethernet OAM information is conveyed in Slow Protocol frames called OAM Protocol Data Units (PDUs). Link-Related Ethernet OAM PDUs contain the appropriate control and status information used to monitor, test, and troubleshoot OAM-enabled links. Link-Related Ethernet OAM PDUs traverse a single link, and as such, are not forwarded by MAC clients (for example, bridges or switches).

7302 ISAMor

7330 FTTNCPE

IEEE802.3 clause 57(Link Ethernet OAM)



Link-Related Ethernet OAM provides a mechanism, called discovery, to detect the presence of an OAM sub layer at the remote DTE. During the Discovery process, the NE and the CPE exchange their respective configuration information and evaluate the remote information to determine compatibility. The decision for accepting remote configuration is based on the remote system OAM mode, version, maximum PDU size, Parser Action, Multiplexer Action, and functions supported information. If these parameters are accepted, the discovery will complete and-Link Related Ethernet OAM will be operational. Otherwise, the remote configuration is rejected and requires operator intervention to rectify the conflicting parameters.

Link-Related Ethernet OAM has provision to retrieve one or more MIB variables, also referred to as attributes, from the CPE. The operator can retrieve MAC layer counters and PME counters from the CPE after successful completion of discovery.

Link Related Ethernet OAM is supported on most of the EFM, EFM Bonding and Native Ethernet LT boards and some of the compatible CPEs.

Link-Related Ethernet OAM proceduresThe following subsections describe the different Link-Related OAM phases as defined in the standard IEEE 802.3-clause 57, and its support within the ISAM.

Discovery

The first phase of Link Related Ethernet OAM is discovery. This phase is started when the operator enables the Link Related Ethernet OAM feature.

Discovery has 3 main functions:

• provide a mechanism to detect the presence of an OAM sub layer• identify the devices in the network, along with OAM capabilities• setup of the OAM link

During this discovery procedure the ISAM always negotiates to become the active DTE. The ISAM never accepts to become the passive DTE. The ISAM never accepts the peer DTE to become active (the standard allows both sides to be active).

Link monitoring

The standard defines link monitoring tools for detecting and indicating link faults under a variety of circumstances. Both Event Notification and Variable Retrieve are part of link monitoring.

1 Link monitoring uses the Event Notification OAM PDU, and sends events to the peer OAM entity when the number of problems detected on the link crosses a threshold.

2 The manager can initiate a Variable Request to retrieve data about the link from the peer side. This capability allows emulating a non-intrusive loopback. It behaves like a “L2 ping” as each Variable Request shall be replied with a Variable Response.

The ISAM does not support Event notifications: it does not generate Event Notifications and ignores received Event Notifications.



The ISAM allows the manager to initiate a Variable Request to retrieve remote CPE data to know the current link status. It support to retrieve:

• Physical Medium Entity (PME) data• PME Aggregation Function (PAF) data

By forcing the peer side to be in passive mode, the ISAM does not support the peer side to retrieve data from the ISAM through Variable Requests / Responses.

Remote failure indication

A set of flags in the header of any OAM PDU allows an OAM entity to convey severe error conditions to its peer.

The ISAM does not report critical events to the peer side, and does not report the reception of critical events from the peer side to the operator.

Remote Loopback

Link-Related Ethernet OAM provides an optional data link layer frame-level loopback mode, which is controlled remotely. This means: one side forces the peer side to go in a loop mode and to send back the received frames.

The ISAM does not support a method to force a loop at the peer side. By nature by forcing the peer side to be in passive mode, the ISAM does not support to be forced in loop mode by the peer side.

5.8 Narrowband Line Testing

Narrowband Line Testing provides a set of tests for the narrowband on POTS subscriber lines, to tests the line from the SLIC on the Voice LT board. Narrowband line testing support is LT board hardware and software dependant.

Management of the narrowband line test feature for ISAM Voice is supported by the 5530 Network Analyzer. Also basic management to start measurements and report results is provided through CLI.

Narrowband line testing is supported for POTS LT boards operating in the H.248 and SIP environment.



The following test can be performed with the narrowband line testing feature:

• Electrical measurement tests:The purpose of these tests is the measurement of electrical parameters. These tests do not require customer assistance. Any or all of these tests can be invoked in the same test request for a given user port. Electrical measurement tests are:

• Foreign voltage (AC/DC): measures foreign voltage between wires.• Capacitance: measures capacitance between wires.• Insulating resistance: measures insulating resistance between wires.• Impedance: measures the impedance between wires.• Termination (M Socket detection): detects whether a phone, or just a resistance

connects the line.• Feeding voltage: measures voltage over wires in open circuit and verifies that the

voltage remains within thresholds.• Feeding current: connects a resistor, loading the wires and measuring the current in

limiting mode.• Noise level: detects abnormal noise level, for example, crosstalk

• Group test:This test consists of a combination of the predefined electrical measurements requested by the OS in previous electrical measurement tests. The test combines voltage, capacitance and insulating resistance measurements.

• AC foreign voltage: a/Earth, b/Earth, and a/b• DC foreign voltage: a/Earth, b/Earth, and a/b• capacitance: a/Earth, b/Earth, and a/b• insulation resistance: a/Earth, b/Earth, a/b, and b/a

• Dial tone test:This test checks the ability of the line circuit to detect an off-hook and to check the provision of the dial tone from the MGC. An off-hook condition is simulated in the ISAM. This off-hook must be detected by the line circuit and is further processed by call-handling software; the MGC then interprets it as a real off-hook and sends a dial tone.The time is measured and compared with a predefined threshold. Returned result is the delay-to-dial tone.

• Howler tone test:This test lets the user know that the handset is not on-hook and restores the user state from parking to idle after the handset goes on-hook. If the user does not go on-hook, the howler tone is stopped after a predefined timeout. The howler tone level and frequency depend on the specifications in different countries.

• Status monitor:This test lets the operator know the status of the indicated user.

• Status monitor:This test lets the operator know the status of the indicated user.

• Block Reading Mode:One extended new test mode (only for Foreign Voltage AC/DC, Capacitance, Insulation Resistance) for the basic electrical test types, it will return 20 reading results of one electrical test item in each session.



• Continuous Reading Mode:Another extended new test mode (only for Foreign Voltage AC/DC, Capacitance, Insulation Resistance) for the basic electrical test types, in one test session, operator can repeat test item after last test result is reported to it. This mode also accept only one electrical test item in each session.

5.9 SFP diagnostics

SFP diagnostics are used to terminate network, subtending, inter-shelf, or line board Ethernet interfaces. When isolating a data path problem, for example, fiber degradation, the operator can use the management interface to retrieve the instantaneous received optical power level and transmitted optical power level from an SFP.


6 — Network timing reference support in ISAM

6.1 Introduction 6-2

6.2 ISAM clock system and NTR extraction 6-6

6.3 Downstream NTR clock distribution 6-15

6.4 Applicable standards 6-16



6.1 Introduction

ScopeThis chapter describes the different clock systems and Network Timing Reference (NTR) capabilities of the ISAM. A specific ISAM board will not support all of these capabilities. To know which of these functions are supported on a specific ISAM board, refer to the Product Information document and/or the Unit Data Sheet (UDS) of that board.

Contrary to most of the other chapters in this system description, this section is not focused on only the 24Gbps NT family, or, only the 100Gbps/320Gbps NT family, since both families will be covered in this chapter. If an NTR function is supported or not is board-dependent, and less family-dependent.

Example: SyncE is supported on some board variants in the 100Gbps/320Gbps NT family. And while SyncE is not supported on most boards in the 24Gbps NT family, it is supported on NRNT-A (that is, the NT board for Standalone REM).

A summary of NTR capabilities of the most advanced board variants in each family is given in Figure 6-1 and Figure 6-2. In many cases, less advanced board variants with less or no NTR capabilities are available, and this for deployments where these features are not needed. The following section clarifies at a high level when such features are needed or not.

Applications as driver for specific clock or NTR requirementsThis section discusses high-end NTR capabilities on the ISAM such as BITS, SyncE, NTR on DSL, and so on. However, many applications such as High Speed Internet (HSI), Video, Packet Voice, Data Offload in Mobile Backhaul do not require such high-end clock system (see Table 6-1). So, for these applications the usual and less complex NTs and LTs are sufficient for network deployments.

Each access technology (ADSL, VDSL2, SHDSL, Ethernet, GPON) may have its specific clock requirements to guarantee synchronization and proper functioning between both ends (CO and end-user). However, in general, these clock requirements are taken care of in the design of line boards (LTs) for that specific access technology, and do not impose any restrictions on the specific NTs which can be used. Some exceptions exist (for example, voice over POTS line) and they will be covered in the section on that access technology. Clock requirements or restrictions related to a specific access technology, are in general not in the scope of this chapter.

Table 6-1 Specific clock requirements per application

Application(over DSL, Ethernet or GPON)

Required on NT Required on LT

High Speed Internet (HSI),

Video,

Packet Voice

External NTR source: not required

Local Clock Accuracy: low (32 or 50 ppm is sufficient)

All LTs are suited, i.e. no specific clock requirements on LT.

(1 of 2)



Voice via POTS line External NTR source: not required

Local Clock Accuracy: 4.6 ppm is required

All voice LTs are suited, i.e. no specific clock requirements on LT.

Long fax or modem calls via POTS line

External NTR source: SyncE In or BITS In

All voice LTs are suited, i.e. no specific clock requirements on LT.

NTR distribution from network node to network node (for example, to other DSLAMs)

• External NTR source: SyncE In or BITS In

• NTR Out: SyncE Out or BITS Out

NT or NTIO output can be used, and then no requirements on LT.

Alternatively, SyncE output on an Ethernet LT.

Mobile backhaul data offload External NTR source: not required


All LTs are suited, i.e. no specific clock requirements on LT.

Full mobile backhaul (with frequency synchronization)


• DSL LTs: NTR on VDSL2 or SHDSL (Note: NTR on ADSL is not supported on DSL-LTs)

• Ethernet LTs: SyncE out

• GPON LTs: no specific clock requirements on LT (Note: ONT with BITS out or SyncE out needed)

Full mobile backhaul with phase synchronization or ToD requirement

Not supported.

Note: Phase synchronization or ToD is only required for some mobile applications, and even then in most cases an alternative option exist which does not require these features.

Alternative solution: Provide Mobile Backhaul data offload only, with phase sync or ToD via a different channel (for example, GPS receiver)

Not supported.

Packet-based Business applications

External NTR source: not required


All LTs are suited, i.e. no specific requirements on LT.

Business applications with NTR requirements (for example, TDM leased lines)


• DSL LTs: NTR over SHDSL or VDSL2

• Ethernet LTs: SyncE out

• GPON LT: no specific clock requirements on LT

Application(over DSL, Ethernet or GPON)

Required on NT Required on LT

(2 of 2)



Only some applications such as Full Mobile Backhaul (with frequency synchronization) and some Business Applications (for example, TDM leased lines) will require NTR support (see Table 6-1). This then means that NT boards are required which either support BITS inputs or SyncE inputs, and LT boards supporting NTR over DSL in case of SHDSL or VDSL2, and SyncE out on Ethernet lines. For GPON LTs, there are no specific requirements, since the framing of GPON has inherent sufficient high clock quality (assuming the appropriate NT is used). But, an ONT needs to be selected with an NTR output (for example, SyncE on an Ethernet output port, or a BITS out).

For NTR in mobile applications, and especially in mobile backhaul, frequency synchronization has always been sufficient in the past, and phase synchronization or ToD was not required. With new mobile generations (for example, LTE) also the latter requirements may appear. However, in general, different options exist in the new mobile standards, and only some of these options (for example, TDD technology) require ToD, while mostly alternative options (for example, FDD) exist which do not require this. So, it depends very much on the selected technology which will be used in a mobile network of a particular operator, if phase synchronization or ToD will be possibly required there. And even if the latter is the case, the ISAM is then still capable to transport the mobile data, if the phase synchronization or ToD timing signal is transported in parallel via an alternative way (for example, via GPS).

To know which NT boards and LT boards in the ISAM portfolio support the specific NTR requirements for a certain application (according to for example, Table 6-1), one needs to consult the Product Information document and/or the UDS of that board.

The ISAM NTR features support a very wide range of applications. On the market still other clock solutions are available, which in most cases are just alternatives, that is, they just support the same applications in a different way. In some cases, they may be transparent to the ISAM, and could therefore also be used. Such an example is Adaptive Clock Recovery (ACR). ACR requires larger buffers and a better local oscillator in the end-receiver, and will therefore be more expensive. An investment in a bit more expensive ISAM NT board with SyncE or BITS support will then probably be better than having to deploy a more expensive receiver with ACR at every end-user. Secondly, the larger buffers needed for ACR increase the end-to-end delay, so echo-cancellation may be required for interactive services (for example, voice or video calls).

Overview of NTR support on ISAMTable 6-1 made clear that NTR is not required for all applications. However, in some cases it is required, and Figure 6-1 and Figure 6-2 give a high-level view on the supported options on NT boards and LT boards for the 24Gbps and 100Gbps/320Gbps NT family, respectively.



Figure 6-1 Overview of possible NTR support on some LTs and some NTs in the 24Gbps NT ISAM family

Figure 6-2 Overview of possible NTR support on some LT's and some NT's in the 100G/320G NT ISAM family

Note — To know which NT boards and which LT boards support the required synchronization functions, refer to the Product Information document and/or the Unit Data Sheet (UDS) of that board.

CT

RL

Voi

ce8 kHz

backplane POTS/ISDN

SEM/Distributed REM

DS

L LT8 kHz

backplane

NTR

DSL

NT

Outdoor ISAM

Hub ISAM

NT

BITS

G.703

7330 RA

Sync Eth

GE PHY

BITS

G.703 NT

Voi

ce

POTS/ISDN

NTR

DSL

Eth

Sync Eth

GE PHY

Voi

ce

POTS/ISDN

NTR

DSL

Eth

Sync Eth

GE PHY

NR

NT

-A

Voi

ce8 kHz

backplane POTS/ISDN

Standalone REM

DS

L LT8 kHz

backplane

NTR

DSL

Sync Eth

GE PHY

BITS

G.703

Optional PDH/SDH network

Optional GE network

CT

RL

Voi

ce8 kHz

backplane

DS

L LT8 kHz

backplane

CT

RL

Voi

ce8 kHz

backplane

8 kHz

backplane

NT

NT

BITS

G.703

7330 RA

Sync Eth

GE PHY

BITS

G.703 NT Sync Eth

GE PHYNT

Voi

ce

POTS/ISDNVoi

ce8 kHz

backplane

DS

LLT

NTR

DSL

8 kHz

backplane

8 kHz

backplane

Voi

ceV

oice8 kHz

backplane

8 kHz

backplane

Eth

Eth

8 kHz

backplane

NR

NT

-A

Voi

ce8 kHz

backplane

DS

L LT8 kHz

backplane

NR

NT

-A

Voi

ce8 kHz

backplane

8 kHz

backplane

Sync Eth

GE PHY

BITS

G.703



Optional GE network

Optional GE network

Sync Eth

GE PHY

Eth

DS

LLT

DS

LLT

DS

LLT

NT

IO

NT

IO

NT

Eth

NT

IO

DS

LLT

8 kHzbackplane

NTRDSL

8 kHzbackplane

8 kHzbackplane

8 kHzbackplane POTS/ISDN

GPON PHYGPON

Sync EthGE PHY

GP

ON

Voi

ce

NT

Eth

NT

IO

DS

LLT

8 kHzbackplane

NTRDSL

8 kHzbackplane

8 kHzbackplane

8 kHzbackplane POTS/ISDN

GPON PHYGPON

Sync EthGE PHY

GP

ON

Voi

ce

Sync EthGE PHY

CT

RL

Voi

ce

POTS/ISDN

DS

LLT

8 kHzbackplane

NTRDSL

8 kHzbackplane

NT

SEM/Distributed REM

Outdoor ISAM

Sync EthGE PHY

Hub ISAM

BITSG.703

Collocated ISAM shelves

NT

Optional GE network



Sync EthGE PHY

Sync EthGE PHY

Sync EthGE PHY

BITSG.703

Sync EthGE PHY

BIT

SG

.703

Syn

c E

thG

E P

HY

or



Although not shown in these figures, it is obvious that also deployments are possible with a mix of nodes from both figures. For example, a standalone REM connected via SyncE to an Ethernet output on an Hub ISAM with NT from the 100Gbps/320Gbps family.

6.2 ISAM clock system and NTR extraction

High level description of the external port selection for NTRFigure 6-3 gives a high level description on how the external port is selected that will be used for NTR extraction. This is valid for BITS and SyncE which both are linked to physical ports.

An ISAM hardware configuration has a number of external ports RJ45-a, RJ45-b, SFP-1,…, SFP-n, XFP-1,…, XFP-m available on NT-A, and possibly also on NT-B, and NTIO, in case the latter are also present. Not every port can be used for synchronization input. Hardware design of the specific ISAM boards determine which ports can be used for SyncE input (some Ethernet ports) or BITS input (some RJ45 ports), and this will be then a subset of the total number of external ports (see Figure 6-3).

Figure 6-3 Port selection for external NTR (SyncE and BITS)

The operator needs to configure which of these ports are valid inputs for NTR in his network deployment. Maximum 2 ports can be configured for this (T and U in Figure 6-3).

The ISAM clock subsystem will then dynamically select one of these 2 ports as NTR reference, according to the actual quality of the NTR signals on these ports, configured priority of these ports, and so on, according to the ITU Rec G.871 section 5.6 criteria and selection algorithm.

Externalports on NT-A,

(NT-B and NTIO)

Ports whichsupport

synchronisationinput (BITS or

SyncE)

HW designof specific

card

Clockdistributionon ISAM

backplaneto LTs

and thento access lines

Staticconfigur-ation on ISAM

ISAMclock

systemoperation

RJ45-a RJ45-b

SFP-1

……

SFP-n

XFP-1……

XFP-m

RJ45-aRJ45-bSFP-f

…SFP-gXFP-r

...XFP-s

Staticselection of 2 ports for NTR input

T

U

T

U

Dynamicselection of1 port for

NTR

Ref

eren

ce=

R



Possible External NTR sourcesThe ISAM supports the following external NTR clock sources:

• One BITS / SSU interface per NT faceplate:This interface supports a 2.048 MHz plain clock signal, an E1 framed signal, or a DS1 framed signal. For ETSI markets, the default expected input is an E1 framed signal. SSM is not supported on this interface.BITS has been a very common way of clock distribution in PDH/SDH networks for already a long time, and is therefore available in many COs. Even after migration from PDH/SDH networks to Metro Ethernet, it is still available in many cases for clock distribution. And because Synchronous Ethernet requires new specific hardware not yet available on first generations of Metro Ethernet networks, BITS is still an important option for providing NTR to ISAMs in COs.

• One or more Synchronous Ethernet interfaces on the NT or NTIO faceplates: This can be only supported on optical 1 GE, 2.5 GE and 10 GE interfaces, and not at other speeds (for example, 100 Mbps), nor on any electrical interface.SSM reception and processing can be enabled on these interfaces.Further network rationalization is the driver to move all functions to the Metro Ethernet, so the PDH/SDH network becomes completely obsolete. Consequently, over time, SyncE will become the more important solution for NTR. Since SyncE-support requires specific hardware, upgrades of some nodes in the Metro Ethernet network may be required.

Figure 6-1 and Figure 6-2 give a high-level view of the possible interfaces to external NTR sources for both the 24Gbps and the 100Gbps/320Gbps NT family, respectively. More detailed information on the actual capabilities of specific boards is available in the Product Information document and/or the UDS. Also there one can find which ports on these boards can be used as external NTR sources (and which ones not).

Single NT clock operationFigure 6-4 shows the NTR configuration with a single NT board, and with an NTIO board added as a possible option. The internal system NTR clock can be synchronized to any of the external NTR sources described in the previous subsection: BITS, SyncE.



Figure 6-4 ISAM configuration for NTR provisioning with single NT.

The 8 kHz NTR signal generated by the internal system NTR clock is distributed to the subscriber interface logic on the LT boards.

Up to two ports can be configured as valid external NTR input ports (see “High level description of the external port selection for NTR”). One will be the reference, and the other one is for protection (see “Clock protection: Overview”).

If all available external NTR clock sources fail, then this clock will switch to Hold-over mode, if locking to the external NTR clock source was completed at the time of failure.

In case no valid external NTR clock source is connected during system start-up, the internal NTR clock will remain in free-running mode, that is, it will adapt to the output frequency of its local oscillator.

Clock protection: OverviewWhen applications are running on equipment connected to ISAM which require NTR, it is important that this NTR signal is provided uninterrupted, and that protection is available against degradation or failure of selected external NTR sources. This is supported in the following ways:

• Switching to another redundant external NTR clock source, if available (see “Clock protection: External NTR source protection”).

• An internal NTR clock hold-over function (see Figure 6-5), which continues to apply the last known clock correction data to the internal NTR clock, in order to keep the NTR clock to dependent equipment as stable as possible during absence of external references.

• Switching to a second NT with identical NTR clock system when the active NT fails (see “Clock protection: NT redundancy”)

Active NTFront plate

1 GE EthernetSync Eth out

SFP

SFP

1 GE NTIO

SFP

XFP

10 GE NTIO

NTIO Front plate1 GE Sync Eth out

LT 1

LT 18

1 / 10 GESync Eth in

Sync Eth out

NTIO Front plate1 GE Sync Eth in

Sync Eth out

NTIO Front plate10 GE Sync Eth in

Sync Eth out

T4 : BITS/SSU1 out

T0 8 kHzNTR 1 to LT 1 -18

SFP

SFP

SFP+

P

LocOsc

NT

R clock source selection

NT

R clock generation

PHY

PHY

T3 : BITS /SSU 1 in

Single NTXFP

SFP

Sync Eth out

Sync Eth out



Figure 6-5 States and state transitions for the internal NTR clock

Clock protection: External NTR source protectionUp to two ports can be configured as valid external NTR input ports (see “High level description of the external port selection for NTR”). One port will be the reference, the other port is for protection. If the reference fails, then the other selected NTR input port will be used for clock synchronization.

NTR clock source failure is detected from:

• Loss of Signal• A signal frequency that falls outside the capture range of the internal system NTR

clock• Failure to receive SSM messages on an SSM enabled Synchronous Ethernet link

during more than 5 seconds• Reception of SSM messages with a QL value below the configured threshold

value.

Per external NTR source type, the following protection is supported:

• BITS input redundancy always requires 2 NT boards, since maximum one BITS input interface is available on NT boards. If the reference BITS input fails, then the BITS input on the other NT will be used as NTR, even if this other NT board is in standby mode. The ISAM is in general HW-ready to support this type of BITS input redundancy, but up to this release, SW support for this has been implemented on NANT-A only. BITS input redundancy is not supported on other NTs, but this will be planned in a future release.

• SyncE source redundancy is supported with all input ports either on one NT board, or on one NT board and NTIO board.

Furthermore, also any mix is supported when both inputs are on the same NT, or on one NT and NTIO. Example, BITS as the

- update holdover memory- lock clock to selected reference

Locked mode

Holdover mode

- freeze holdover memory- lock clock to holdover memory

Free-run mode

- rest holdover memory- free-run clock

Free-run mode

- rest holdover memory- free-run clock

AUTONOMOUS MODE

FORCED FREE-RUN MODE

Valid referenceavailable

No valid referencenor memory

available

No valid referencenor memory

available

Configure autonomous mode

Configure forcedfree-run mode



reference for NTR, while SyncE as NTR source protection.

However, such combinations are expected to be less common in the field, since either the long-existing BITS on the PDH/SDH network is used, or else this network has been completely outphased and the network has moved fully to metro Ethernet aggregation and uses SyncE.

Clock protection: NT redundancyAlso in ISAM configurations with NT redundancy, the NTR function should restore and this to the same quality, when an NT fails and the redundant NT takes over. This is supported when the next restrictions are taken into account:

• In case SSU / BITS is applied, a valid signal has to be provided to both NT board front plates. This will guarantee that the system NTR clock on the stand-by NT board can be synchronized to the network in case the active NT board HW fails or is removed. The BITS signal on the stand-by NT board cannot be configured independently, it will take the same configuration as the former active NT board BITS signal in case of NT board switch-over. This BITS signal cannot be monitored while the NT is in stand-by mode (Note: Although some NT's support active/active operation, this only refers to the data plane, since the control plane is still active/standby.)Note that this configuration does not support redundancy of BITS input (see previous subsection on external NTR sources), except for NANT-A.

• In case NT redundancy needs to be provided with SyncE for NTR, the SyncE input(s) should be connected to the NTIO board which has connections to both NTs. Note that in this way, also SyncE input redundancy can be supported.

Once the redundant NT has taken over from the failing NT and has arrived in a stable state, the NTR function will be compliant to the typical related standards. These standards also define the maximum allowed phase jump during a transient effect. Switch-over from a failing NT to a redundant NT is one of these transient effects, and ISAM does exceed in that case the maximum allowed phase jump. Since such NT switch-overs are exceptional, and since phase jumps may be filtered to some extent by end-user equipment, the impact on services is expected to be limited.

Future SW releases will improve the NTR functions of this subsection and relax the restrictions.

Detailed behavior of internal system NTR The operator can configure the following elements regarding NTR:

• The external NTR source(s) to be used:• BITS/SSU• Synchronous Ethernet interfaces

• Enabling and disabling of the reception of SSMs that carry a QL, on the one or two external NTR clock sources that have been configured as nominated for network synchronization purposes by the operator.The default setting is “DISABLE”. For the BITS/SSU interface, this setting cannot be changed



• The QL value applied for an external NTR clock source, in the algorithm that performs the selection of one external NTR clock source from up to two configured as nominated, and in case reception of SSM for that NTR clock source is disabled. The default setting for the value is equal to “QL-PRC” (code 0010b) for ETSI, and “QL-PRS” (code point 0000b) for ANSI.

• The target QL value that is applied as minimum threshold for eligibility of an external NTR clock source, in the algorithm that performs the selection of one external NTR clock source from up to two configured as nominated, and in case reception of SSM for that NTR clock source is enabled. The default setting for the value is equal to “QL- DNU” (code 1111b).

• The static relative priority to be applied for an external NTR clock source, in the algorithm that performs the selection of one external NTR clock source from up to two configured as nominated, in case the respective Quality Levels (QL) of the two sources are identical. The QL for each of both NTR clock sources can be either communicated via the Synchronization status Messages, or is fixed to a default value.

• Revertive or non-revertive operation of the external NTR clock signal selection. The default setting is “Revertive mode”

• Override of synchronization to any external NTR clock source, and forcing of free-running or hold-over mode for the internal NTR clock function.

• The target QL to be applied as minimum threshold for the internal system NTR clock, for generating an SSU / BITS out signal. The default setting for this target QL value is equal to “QL- DNU” (code 1111b).

The system performs the following autonomous NTR clock management functions

• Monitoring of the signal status (signal present, frequency within the capture range) and the QL of up to two external NTR clock sources that are configured by the operator as nominated.

• Selection of the external NTR clock source that fits best the selection criteria, from up to two sources configured as nominated. Selection happens as specified further.

• Disabling of the SSU / BITS output signal(s) in case the QL, which can be attributed to the internal system NTR clock, drops below the configured threshold.

The operator can retrieve the following information

• The status of BITS / SSU and / or Synchronous Ethernet interfaces nominated as external NTR source(s): “not available”, “available but not used”, “used”.

• The number of switch-over actions between nominated external NTR clock sources. In revertive mode, switch-over between nominated external NTR clock sources may happen without further alarm generation.



The operator can receive the following alarms

• Unavailability of any nominated external NTR clock source for reasons that include:

• Frequency out of range• Loss of Signal• Time-out for SSM reception, if enabled• Received SSM-QL below the target QL, default or configured

• Unavailability as described above of all nominated external NTR clock sources, with defaulting to hold-over mode for the internal NTR clock

• BITS output signal disabled • Internal system NTR clock QL drops below the output threshold QL, default or

configured.

The ISAM selects the most appropriate NTR clock source for synchronizing its output NTR signals to, and for protecting against failure of external NTR clock sources, as follows:

• In case two external NTR clock sources have been configured by the operator as nominated, and both are active, then selection of the external NTR clock source, to which the internal system NTR clock will synchronize, is subject to the following rules:

• The external NTR clock with highest Quality Level (QL), is selected as actual reference for the internal NTR clock. The QL of an external NTR clock source is communicated by means of SSM messages received on the interface related to the source. If SSM reception is not supported, or disabled on that interface, then a QL value configured by the operator, or a default QL value is applied, as described above.

• In case both external NTR clock sources exhibit the same QL, then their relative priority is determined by the external NTR clock source priority list as configured by the operator.

• After restoration or upgrading of an external NTR clock source, the selection depends on revertive or non-revertive mode setting, as configured by the operator.

• In case only one external NTR clock source has been configured by the operator as nominated, or in case only one is active, then the internal system NTR clock will switch to hold-over mode when this external NTR clock source fails, or is removed.In hold-over mode, the internal system NTR clock maintains application of the last stored correction values which describe the deviation of the own free-running oscillator signal relative to the external NTR clock source signal which was applied last.

NTR management



Configuration: external NTR clock source priority list

This command allows the operator to configure two NTR clock sources, with an operator assigned priority between them, as nominated references for the internal system NTR clock. Each of these two sources can be independently designated to be:

• The BITS interface on the faceplate of an NT board.• The 1GE /10GE interface on the faceplate of an NT board.• One of the two dedicated 1GE interfaces on the faceplate of a 1GE NTIO board.

The system factory default is “none”: no external clocks are selected. In this case the system automatically selects the internal free-run system NTR clock for downstream NTR timing.

Configuration: SSU/BITS input interface(s)

This command allows the operator to configure the BITS mode of the external clock source to E1, DS1, 2048Khz or auto-select. The BITS mode applies for the system, that is, any configured BITS clock source.

The system factory default is “auto-select”. In this case, the system automatically selects E1 for the system with the NT capabilities for clock device type of E1, or DS1 for clock device type of T1. This setting can be viewed in the clock status command. When the BITS mode is configured to “auto-select”, the actual BITS mode will display “E1” or “DS1” depending on the NT capabilities.

However, the system does not restrict the manual configuration of “DS1” or “E1” to a specific NT capability of the clock device type.

Configuration: Synchronous Ethernet input interface(s)

This command allows the operator to configure the Ethernet interface(s) which can provide(s) their extracted data clock as external NTR clock source. As mentioned above, 1 or 2 external NTR sources can be configured as clocks for synchronizing the internal system NTR clock to. Therefore, between 0 and 2 synchronous Ethernet links can be designated as external NTR clock sources.

The selected Ethernet interface(s) is (are) identified by means of:

• The board slot: NT-A, NT-B, NTIO slot, or none• The port type: SFP, XFP or none• The port number on the board: depends on SyncE port supported, or none

The system factory default is “none”.

Configuration: NTR Switching Mode

This command allows the operator to configure the external NTR selection mode to be either:

• Revertive:the system NTR clock always selects as reference the external NTR clock source with highest QL, or the one configured as preferred by the operator if the QLs of both nominated external NTR clock sources are equal, whenever this clock source is available.



• Non-revertive:the system NTR clock keeps the currently selected external NTR clock source as a reference, until it is no longer available for selection, for reasons listed above, or until it is disabled by the operator. This is the case even if another external NTR clock source, with better QL or higher preference as configured by the operator, has become available since the selection of the currently selected external NTR clock source.

The system factory default is “revertive”

Configuration: enabling of Synchronization Status Messaging (SSM)

This command allows the operator to enable or disable the support of Synchronous Status Message (SSM) for the configured NTR clock source(s).

At this time, this configuration is subject to the following restrictions in ISAM:

• SSM support for Synchronous Ethernet interfaces applies only to the reception of SSM frames on Synchronous Ethernet links at the network side.

• SSM frame transmission on Synchronous Ethernet links is not supported.• In particular, sending of SSM frames with “Do Not Use” (DNU) indication on the

transmission side of a Synchronous Ethernet link of which the incoming data clock is applied as external NTR source, is not yet supported. This limitation implies that the ISAM cannot be deployed in ring networks that rely on Synchronous Ethernet for NTR distribution.

• SSM support for BITS-A and BITS-B cannot be enabled yet.

The system factory default is “disable”

Configuration: forcing selection of the internal system NTR clock

This command allows the operator to force the transmitted downstream NTR clock to be synchronous to the internal system NTR clock, without synchronization to any external NTR clock source. The internal NTR clock can be in free-running, or in hold-over mode, when it had been synchronized previously to an external NTR clock source.

Status: nominated NTR clock status

This command allows the operator to query the status of the NTR clock source(s) configured for selection (“nominated”). The following items are shown:

• the NTR clock source: BITS-A, BITS-B, Sync Eth 1, Sync Eth 2, local• the Quality Level (QL) of the source: code points 0000b - 1111b (0 … 15)• the operator configured priority of the source: 1 … 3



• The operational status of the source: • REFERENCE: the clock source is selected as the reference clock.• VALID: the clock source is available for selection • FAILED: the clock source failed or is not available for selection• DO_NOT_USE: the clock must not be used as indicated by SSM (or timeout)• UNKNOWN: the clock status is unknown (startup, system fault) • FORCED: the clock is manually selected (only possible for the local NTR clock)• NO_SYNCE_CONFIG: the synchronization source is not bound to a physical port

for clock recovery.• NO_SYNCE_SUPPORT: the synchronization source is bound to a port that does

not support synchronization clock recovery.• ON_PEERNT_NOT_READY: the clock is configured on the faceplate of a peer NT

that is not ready to participate in clock management.• SYNCE_NOT_AVAILABLE: the synchronization source is not available because

the required equipment is not available.• MISSING: No SSM packets received for 5 seconds • INVALID: Incoming signal is valid on the hardware level, but the source is rejected

for quality reasons (below target QL)

6.3 Downstream NTR clock distribution

In the introduction of this chapter the drivers for NTR where explained, and include distribution of NTR to other network nodes, as well as distribution of NTR over access lines to the end-user or business user.

Figure 6-6 NTR distribution over access lines for different services

The typical options provided for delivering NTR to other network nodes are:

• BITS out on some NT boards• SyncE out on some Ethernet interfaces on some NT, NTIO and Ethernet LT

boards.This can be supported on optical Ethernet interfaces only, and not on electrical ones. Secondly, it can be supported at speeds of 1 Gbps, 2.5 Gbps and 10 Gbps, but not at for example, 100 Mbps.

ISAM

High-stabilityclock on NT

BITS interfaceon NT

NTR supporton LTs

Mobile backhaulingAccurate synchronizationof base stations

Leased linesCost-effective centralclock for synchronizationof all CPEs

VoiceHigh-stability clock forlong-lasting fax and modem calls

Network Timing Reference

Network Timing Reference

GPONNTR required forsynchronization-sensitiveservices (for example, Voice, DS1, E1)



The typical options provided for delivering NTR to access lines or end-users are:

• NTR on VDSL2 • NTR on ADSL/ADSL2/ADSL2+ is not supported• NTR on SHDSL• SyncE out on some Ethernet interfaces on some NT, NTIO and Ethernet LT

boards.This can be supported on optical Ethernet interfaces only, and not on electrical ones. Secondly, it can be supported at speeds of 1 Gbps, 2.5 Gbps and 10 Gbps, but not at for example, 100 Mbps.

• GPON

To know which specific NT, NTIO, or LT boards do support the above NTR distribution on their outgoing interfaces, refer to the Product Information document and/or the UDS. A high-level view of the capabilities of the 24Gbps and 100Gbps /320Gbos NT family is represented in Figure 6-1 and Figure 6-2, respectively.

6.4 Applicable standards

• Output NTR clock support on ADSL(2)(plus) lines: The NTR section in ITU Rec G.992.1 / G.992.3 / G.992.5 is not supported. NTR for ADSL is not supported.

• Output NTR clock support on SHDSL lines: ITU Rec G.991.2NTR for SHDSL is supported on selected ISAM SHDSL Line Termination board types.

• Output NTR clock support on VDSL2 lines: ITU Rec G.993.2NTR for VDSL is supported on selected ISAM VDSL Line Termination board types.

• Output NTR clock support on POTS lines: Not ApplicableAn analogue POTS interface does not provide a clock signal in downstream direction

• Output NTR clock support on Synchronous Ethernet lines: ITU Rec G.8261/Y.1361NTR by means of Synchronous Ethernet is supported on selected ISAM Ethernet Line Termination board types.

• Output NTR clock quality on ISAM NT:• Output NTR clock free running accuracy, hold-over frequency accuracy, Jitter and

wander generation, phase variation in case of interruptions on synchronization input signals:- ETSI SSU: ITU-T G.813 Option 1 (Note: As explained above, ISAM is not fullycompliant in case of transient behavior.)

- ETSI Synchronous Ethernet: ITU-T G.8262 Option 1• Output NTR clock jitter and wander transfer

- ETSI SSU: ITU-T G.813 Option 1- ETSI Synchronous Ethernet: ITU-T G.8262 Option 1



• Input external NTR clock source quality on ISAM NT• Input NTR signal clock pull-in & pull-out ranges:

- ETSI SSU: ITU-T G.813 Option 1- ETSI Synchronous Ethernet: ITU-T G.8262 Option 1

• Input NTR signal jitter and wander tolerance:- ETSI SSU: ITU-T G. 813 Option 1, G.823- ETSI Synchronous Ethernet: ITU-T G.8262 Option 1

• NTR management, including SSM: ITU-T G.781 Annex A• SSM transport

• BITS / SSU: ITU-T G.704 (1998)ISAM currently does not support SSM reception or generation on BITS / SSU interfaces.

• Synchronous Ethernet: IEEE 802.3 Organization Specific Slow Protocol (OSSP) Annex 43B (2005), ITU-T G.8264


7 — xDSL features

7.1 Overview 7-2

7.2 Configurable impulse noise protection 7-3

7.4 Low-power modes 7-4

7.5 Seamless rate adaptation 7-6

7.6 Upstream power back-off 7-7

7.7 Downstream power back-off 7-8

7.8 Impulse noise monitor 7-10

7.9 Virtual noise 7-10

7.10 Artificial noise 7-11

7.12 Per-line configuration overrule 7-13

7 — xDSL features


7.1 Overview

Table 7-1 lists the different features described in this chapter, indicating for which xDSL mode the feature is supported on xDSL LT boards.

Table 7-1 Supported xDSL features

Table 7-2 gives an overview of the supported VDSL2 profiles. Each profile defines normative values for a set of parameters, as defined by G.993.2.

Table 7-2 Supported VDSL2 profiles

Table 7-3 gives an overview of the supported VDSL2 bandplans. A bandplan is a partitioning of the frequency spectrum into non-overlapping frequency bands, each of which is allocated for either upstream or downstream transmission.

Feature ADSL ADSL2 ADSL2+ READSL2 VDSL2

Configurable impulse noise protection X X X X X

RFI Notching X X

Low-power modes X X X X X

L2 low-power mode X X X

L3 idle mode X X X X X

Seamless rate adaptation X X X X

Upstream power back-off X X X X

UPBO policing X

Equal RXPSD UPBO X

Equal FEXT UPBO X

Downstream power back-off X X X X X

Impulse noise monitor X

Virtual noise X

Artificial noise X X X X

Physical Layer Retransmission (RTX) X X X X

Per-line configuration overrule X X X X X

VDSL2 Profile xDSL LT

8a, 8b, 8c, 8d X

12a, 12b X

17a X

7 — xDSL features


Table 7-3 Supported VDSL2 bandplans

Notes(1) Region A = North America(2) Region B = Europe

7.2 Configurable impulse noise protection

Standards specify that a DSL link must comply with a Bit Error Ratio (BER) < 10-7, in the presence of a Signal-to-Noise Ratio (SNR) margin of 6 dB. For some types of service (for example IPTV, when using codecs with insufficient error concealing), subscriber comfort requires even higher line quality, that is, BER < 10-10 or better. DSL link modems are trained at initialization to achieve these quality levels in the presence of background noise.

Impulse Noise Protection (INP) is the ability to protect the transmission against impulse noises. These impulse noises differ from the stationary noise in the sense that they are transitory noises and that their power levels are high enough to be able to cause data errors on the xDSL lines. INP is important in the IPTV network. With the general evolution from pure High-Speed Internet (HSI) to triple play service offering, there is an increasing need for techniques that help to improve and assure the stability of the DSL line.

Configuring INP provides the ability to configure the upstream and downstream minimum INP parameters in the service profile.

The 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-SolomonReed-Solomon (RS) adds extra bytes to a group of data bytes when it is sent. These bytes are also known as the “RS word”. When data corruption is detected at reception, the RS decoder is able to use the extra bytes to locate the errors and to recover the original message. However, this only is effective up to a certain maximum number of errored bytes. In order to correct impulse noise errors, RS needs to be combined with interleaving.

VDSL2 Bandplan xDSL LT

Region A(1) 998 X

Region B(2) 998 X

Region B 998E X

Region B 998ADE X

Region B 997 X

Region B 997E X

7 — xDSL features


InterleavingInstead of transmitting the RS words directly on the line, the different RS words are first mixed and spread over time. This process is called “interleaving”. This has the advantage that when a burst of errors occurs on the line, it will hit bytes of different RS words. After reconstruction of the original RS words (by the de-interleaver), the errors will be spread over multiple RS words, such that each RS word is only affected by a small amount of errors and is therefore much easier to correct. The RS word can be corrected if its number of errors is within the RS correction boundaries.

The main disadvantage of interleaving is an extra “interleaving delay”. Constructing the blocks that will finally be transmitted over the line takes time, as the modems have to wait for a while before they can actually start transmitting. At the receiving side, it also costs extra time to reconstruct the original RS word. The first original RS word cannot be reconstructed before all of its bytes have been received.

Using smaller interleaving depths, that is, by taking bigger chunks of the original RS words, can lead to a lower interleaving delay. 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.

In the case that a high INP together with a low delay is required, extra RS bytes will have to be added to increase the RS correction capability. This however can lead to reduced bit rates.

It becomes clear from the above that when configuring the INP, a trade-off has to be made between:

• robustness of the line against impulse noise• interleaving delay• achievable bit rate

7.3 RFI Notching

Radio Frequency Interference (RFI) notching is used to alleviate signal interference in certain frequency bands. VDSL2 and ADSL2Plus provide the capability to reduce the Power Spectral Density (PSD) within certain frequency bands and thus notch the PSD in areas to reduce egress into certain services such as HAM radio. HAM radio is an Amateur Radio service enjoyed by radio enthusiasts. Shortwave radio can broadcast over long distances aided by relay signals.

7.4 Low-power modes

L2 low-power modeFirst-generation ADSL transceivers operate in full-power mode day and night, even when not in use. With several millions of deployed ADSL modems, a significant amount of electricity can be saved if the modems engage in a stand-by mode or sleep mode just like computers. This would also save power for ADSL transceivers operating in small remote units and Digital Loop Carrier (DLC) cabinets that operate under very strict heat dissipation requirements.

7 — xDSL features


To address these concerns, the ADSL2/ADSL2+ standards define two power management modes in addition to the full power mode (called “L0” power mode). These power management modes help reduce the overall power consumption while maintaining the ADSL “always-on” functionality for the subscriber. These modes include:

This mode enables statistical powers savings at the ADSL transceiver unit in the central office (ATU-C) by rapidly entering and exiting low power mode based on the subscriber traffic running over the ADSL connection.

By enabling the L2 low-power mode, the average power consumption and dissipation of a line is reduced because the modem reduces dynamically the downstream transmit Power Spectral Density (PSD) in case there is no subscriber data to transmit in the downstream direction. A low-rate connection is however always assured for minimum keep-alive data. The DSL line automatically returns to the full PSD/full data rate if subscriber data arrives, without loss of data.

The L2 entry and exit mechanisms and resulting data rate adaptations are accomplished without any service interruption or even a single bit error, and as such, are not noticed by the subscriber.

However, L2 low-power modes will lead to time varying crosstalk which might impact the stability of customers sharing the same binder.

Exit out of L2 mode into L0 mode can also be triggered from the CPE end, in case of significantly changed channel conditions.

L3 idle modeThis mode enables overall power savings at both the ATU-C and the remote ADSL transceiver unit (ATU-R) by entering into sleep/stand-by mode when the connection is not being used for extended periods of time (that is, subscriber asleep, modem asleep).

The L3 power mode is a total sleep mode where no traffic can be communicated over the ADSL connection. When the subscriber goes back on-line, the line has to be re-initialized to enter the L0 state again.

In case of L3 idle mode, the CPE decides whether or not to enter the L3 idle mode. It is also the responsibility of the CPE to trigger a re-initialization of the line once the subscriber gets on-line again.

The modem can enter the L3 state upon guided power removal (L3 Request exchange between xTU-R and xTU-C, also known as orderly shutdown), power loss or persistent link failures during Showtime (also known as disorderly shutdown).

During the L3 state, power savings at the XTU-C are realized independent of the used ADSLx or VDSL2 mode by putting certain Analog Front End (AFE) blocks and line drivers in power down mode. This power saving mechanism is also available in case no xTU-R is attached but the ports are in “listening mode” and configured in admin-up.

Figure 7-1 illustrates the L2/L3 power modes.

7 — xDSL features


Figure 7-1 L2/L3 power modes

7.5 Seamless rate adaptation

ITU-T G.997.1 defines 3 types of Rate Adaptation (RA) modes:

• RA Mode 1 (Operator Controlled):Bit rate is configured by operator, no rate adaptation

• RA Mode 2 (Rate adaptive at startup):At startup, the bit rate is selected between a configured minimum and a configured maximum. The actual bit rate remains fixed while the modem is in showtime.

• RA Mode 3 (Dynamic rate adaptive):The bit rate dynamically changes between a configured minimum and a configured maximum, even while the modem is in showtime.

The dynamic rate adaptive mode is also called “Seamless Rate Adaptation” (SRA). This feature is supported in all ADSL2x (ADSL2, ADSL2+, READSL2) modes of operation and in VDSL2 mode of operation.

SRA improves the stability of the line (that is, reduces the number of spontaneous retrains) by dynamically reducing the bit rate, without loss of data and without bit errors, in case of a slow decrease of the SNR to an SNR under a below a preset value. SRA can also assure that at any moment in time the line operates at the maximum achievable bit rate by dynamically increasing the bit rate, without loss of data and without bit errors, in case the SNR increases above a preset value.

SRA enables the modem to change the data rate of the connection while in operation without any service interruption. The modem detects changes in the channel conditions (for example, increase in noise level) and adapts the data rate to the new channel condition without a need to resynchronize the line.

SRA uses the online reconfiguration (OLR) procedures defined in the standards to seamlessly change the bit rate of the connection.

The upshift and downshift noise margin thresholds and time intervals for SRA are configurable.

Figure 7-2 illustrates SRA.

IDLE (L3)

Showtime

(L0)

“Low Power”Showtime (L2)“Low Power”

Showtime (L2)

Low traffic causes switch to L2

High traffic causesswitchback to L0

Initialization

Resynchronisation orL3 Power mode

Resynchronisation or

L3 Power mode

7 — xDSL features


Figure 7-2 Seamless Rate Adaptation

The upshift and downshift rate adaptation events due to SRA are counted in 15 minute and 24 hour Performance Monitoring (PM) intervals.

The following restrictions apply for SRA:

• SRA does not work well in interleaved mode, since SRA adaptations can violate the configured minimum impulse noise protection and maximum interleaving delay.

• large, sudden noise increases may still lead to bit errors or even re-initialization.

7.6 Upstream power back-off

Upstream Power Back-off (UPBO) is a remedy to the upstream far-end cross-talk (FEXT) problem, see Figure 7-3.

Figure 7-3 Far end cross-talk

It allows to reduce the upstream transmit PSD on short lines in order not to impact the upstream performance on longer lines unreasonably. Without UPBO, the nearby CPE would transmit at full power and would inject excessive FEXT in the upstream receiver of the long line.

Maximum Noise Margin

time interval has elapsed

Increasedata rate

Upshift Noise Margin

Downshift Noise Margin

Minimum Noise Margin

Target Noise Margin

0 dB Margin

Decreasedata rate

time interval has elapsed

Increase data rate if Upshift

Decrease data rate if Downshift

FEXT

weak Rx signal; strong FEXT signal from short loop

CPE

CPE

short loop

long loop

NE

7 — xDSL features


UPBO policing

The main purpose of VDSL2 UPBO policing is to avoid the usage of a CPE not complying with the UPBO configuration. When the CO modem detects such a non-compliant CPE, an alarm is raised and optionally the line is automatically shutdown. The expected behavior is configurable.

A line that has been automatically shut down because of policing can be triggered to re-initialize by toggling its administrative state (down/up).

Equal RXPSD UPBOThis is the form of UPBO first standardized in G.993.2. The goal of this UPBO is to equalize the upstream received signal PSD. The support of this form of UPBO is mandatory at both DSLAM and CPE.

Equal FEXT UPBO

The goal of this second form of UPBO is to equalize the level of FEXT VDSL2 self-crosstalk noise. This results in available upstream bitrates that are further optimized compared to the bitrates obtained with Equal RXPSD UPBO.

This form of UPBO is introduced because the equal RXPSD UPBO does not exactly equalize the impact of all lines to each other, but gives a different FEXT level impact proportional to the loop length, i.e. the short lines give a lower FEXT impact to long lines then vice versa. As a consequence, the equal RXPSD UPBO is actually implying too much power cutback on the short lines.

The Equal FEXT UPBO can be explained as first applying the equal RXPSD method but adding a loop-length-dependent delta FEXT factor, thereby equalizing the impact among the lines. This equalization is executed with respect to a reference FEXT level, characterized by a reference electrical length (kl0_ref). This parameter is configurable for each upstream band. Alternatively an automatic configuration mode is available: if the Equal FEXT parameters for all bands are all set to automatic, the modem uses a dedicated mechanism to automatically calculate good values for the Equal FEXT parameters, without manual configuration by the operator.

The equal FEXT UPBO method is standardized in G.993.2 Amendment 2, and is supported in the ISAM.

7.7 Downstream power back-off

With the introduction of remote cabinets, one can have deployment of DSL lines from different locations: some from the central office (CO), some from the remote terminals (RT). In case lines deployed from the CO and lines deployed from the RT share the same cable binder, a near-far crosstalk problem occurs.

The crosstalk from the near-end disturbers can be much higher than before, such that the signal from the far-end transmitter is completely degraded. Very often this results in a loss of the service on the line deployed from the CO.

7 — xDSL features


This near-far effect both occurs in upstream and in downstream direction. In upstream direction however, the typical services from the CO (ADSL2/2+) only use lower frequencies, where the coupling is much lower than on higher frequencies. That is why this problem mainly affects downstream communication (for the CO lines).

In order to give equal priority both to CO and RT, the RT applies downstream power reduction (also called Downstream Power Back-Off (DPBO)) on the frequencies that it has in common with the lines from the CO. As such, the lines from the CO can be protected, and also the RT can still have a decent bit rate on those overlapping frequencies. See Figure 7-4.

Figure 7-4 Crosstalk in mixed CO-RT deployment

Initially, it was only possible to configure downstream PSD shaping by configuration of a PSD Mask using a list of breakpoints, as part of the xDSL spectrum profile.

Although such a list of breakpoints allows for a high degree of flexibility, it lacks user friendliness. Within ITU-T, the so-called E-side Model for Downstream PSD Shaping has been defined, which provides several high-level parameters that are used to configure the PSD shape at the RT.

The E-side parameters are configurable via a special DPBO profile, which can be assigned either to an xDSL LT board or to an xDSL port.

Since DPBO PSD shapes can be configured in several ways, a number of priority rules apply:

• The DPBO profile parameters take precedence upon the downstream PSD shape configured via the xDSL spectrum profile.

• The DPBO profile parameters configured at LT board level apply, unless port-specific DPBO parameters are configured as well.

The DPBO profile parameters apply to ADSL1, ADSL2, ADSL2+ and VDSL2.

Shaped DPBO is not defined in the ADSL1 (G.992.1) and ADSL2 (G.992.3) standards. However, if ADSL1 or ADSL2 are deployed from a remote location (for example, from a remote VDSL2 LT board), the ADSL1 or ADSL2 downstream PSD needs to be shaped for ensuring spectral compatibility with CO deployed xDSL.

Remote TerminalRemote Terminal PS

DNTNTCOCO

RTRTCentral OfficeCentral Office

Remote TerminalRemote Terminal

frequency

PS

D

frequency

PS

D

Customer PremisesCustomer Premises

NTNT

frequency

PS

D

frequency

PS

D

frequency

PS

D

frequency

PS

D

7 — xDSL features


7.8 Impulse noise monitor

The Impulse Noise Monitor (INM) collects data characterizing the impulse noise on a particular line. This data can eventually be used to optimize the line configuration for triple play (for example, minimum INP and maximum delay).

An impulse noise measurement can be started or stopped on a particular line for the upstream direction, for the downstream direction, or for both. The upstream measurements are performed by the XTU-C (CO side) and the downstream measurements are performed by the XTU-R (CPE side), as illustrated in Figure 7-5.

The collected data is eventually represented as a set of impulse noise histograms, both for the 15 minute and 24 hour PM intervals:

• Impulse Noise Inter arrival time histogram• Impulse Noise Equivalent INP histogram

Figure 7-5 Impulse Noise Monitor in XTU-R and XTU-C

Impulse noise measurements can be performed without service interruption.

7.9 Virtual noise

By configuring virtual noise, it is possible to minimize the impact of time varying crosstalk on the stability of a DSL line. Virtual noise is an operator specified noise PSD, using a piecewise linear model with breakpoints and a special SNRM mode. It can be configured as a transmitter-referred noise PSD (TxRefVN, supported for downstream and upstream) or as a receiver-referred noise PSD (RxRefVN, supported for upstream only).

The transmitter-referred virtual noise PSD (TxRefVN) is converted by the receiver to a receiver virtual noise PSD. The receiver determines its bitloading based on the maximum of the received virtual noise and the received real noise. For a given transmit signal PSD, the definition of a transmit virtual noise PSD can also be seen as equivalent with setting a limit to the SNR that can be used by the receiver in the bitloading process.

In downstream, when protecting a fixed data rate for all lines against VDSL2 self FEXT crosstalk, the VN configuration is loop length independent. For more elaborate cases, the TxRefVN can be configured using a limited set of profiles (for example, to cover data rate with the loop length dependency, non FEXT noise, and so on).

Impulse NoiseSensor

INM AnomalyCounters

Indication ofSeverely

Degraded DataSymbols

anomaliesINM PMcounters

15min and 24h

INM PMcounters

15min and 24h

Impulse NoiseSensor

INM AnomalyCounters

xTU-R

xTU-CUS

DS

EOC

7 — xDSL features


Transmitter referred virtual noise can also be used with a single or a limited set of profiles in upstream if no UPBO is enabled.

When UPBO is enabled or in the presence of other noise (non FEXT), the TxRefVN becomes highly loop length dependent. To cope with this loop length dependency, the per line overrule mechanism can be used. For the case the operator does not wish to use a per line management, an alternative for upstream (where UPBO is applied) is to use the receiver referred virtual noise (RxRefVN) configuration option that can be configured with a unique VN profile setting independently of the loop length.

As indicated in Figure 7-6, during initialization, the DSLAM forwards the virtual noise downstream (DS) breakpoints to the CPE. The CPE calculates the DS virtual noise based on the DS loop attenuation and takes the maximum of this virtual noise and the actual received DS noise. The DSLAM does the same in upstream (US) direction, based on the received US noise, the US virtual noise and the US loop attenuation (in case of TxREFVN).

Transmitter-referred virtual noise is included in the VDSL2 standard (G.993.2) as an optional feature. The upstream receiver-referred virtual noise solution is not standardized but does not pose any interoperability issue.

Figure 7-6 Virtual noise concept

7.10 Artificial noise

Since ADSL is widely deployed, changing the standard to support virtual noise is not an effective solution. To overcome this limitation, for ADSL lines the ISAM has the ability to physically inject additional noise on the line, that is, artificial noise, as shown in Figure 7-7. This injection is executed during initialization as well as during showtime.

The artificial noise behaves similar as the transmitter referred virtual noise in the sense that it improves the stability and limits the SNR. The breakpoints also define the noise at the transmit side and this noise and the transmit signal are attenuated by the loop. The difference with virtual noise is that the CPE will see the power summation of the attenuated artificial noise and the normal receive noise. Artificial noise is only implemented in downstream, and it can be used on top of any ADSL flavor.

DSLAM

VDSL2

CPE

ReceivedNoise US

ReceivedNoise DS

VN BreakpointsDS/US

Loop attenuation

[Loopattenuation]

7 — xDSL features


Figure 7-7 Artificial noise concept

7.11 Physical Layer Retransmission (RTX)

The Bit Error Rate (BER) requirements for providing High Speed Internet (HSI) service are not too stringent. Transmission errors on the line are effectively hidden by retransmissions at the TCP-IP layer. With the evolution towards IPTV, much lower BER figures are required.

Impulse noise is the common cause for errors on the DSL line. Two types of impulse noise are defined:

• Single High Impulse Noise Environment (SHINE): impulse noise occurring at random time instants

• Repetitive Electrical Impulse Noise (REIN): periodic impulse noise, occurring at near equidistant time instants

Forward Error Correction (FEC) is the traditional error correction technique to deal with impulse noise, as defined in the ADSL, ADSL2(Plus) and VDSL2 standards. FEC is very well suited to protect against REIN, but due to the fixed overhead, FEC is not very efficient to protect against SHINE.

An alternative technique for impulse noise protection is to use retransmission. Because there is no fixed overhead, retransmission is best suited to protect against SHINE. Retransmission is available at the higher layers (TCP-IP retransmission for HSI, End-to-end retransmission for video), but is now also defined for the DSL physical layer.

ITU-T recommendation G.998.4 (G.inp) specifies techniques beyond those defined in the existing DSL recommendations to provide enhanced protection against impulse noise or to increase the efficiency of providing impulse noise protection. Both REIN and SHINE are handled efficiently on the DSL physical layer.

G.998.4 defines downstream retransmission both for VDSL2 mode and ADSL2(Plus) mode. Support of retransmission in upstream is optional and only defined for VDSL2 mode.

The concept of DSL physical layer retransmission is illustrated in Figure 7-8:

• The transmitter groups user data in Data Transfer Units (DTUs) and adds a Cyclic Redundancy Check (CRC) and sequence number.

• The receiver uses the CRC to detect errors and requests a retransmission of a DTU when in error.

DSLAM

ADSL

CPE

ReceivedNoise DS

Artificial noise DS

Loop+

7 — xDSL features


Figure 7-8 DSL physical layer retransmission concept

The configuration parameters for retransmission are defined within a separate RTX profile. The RTX profile is optional when configuring an xDSL port. If no RTX profile is assigned, retransmission will be disabled.

A specific set of Performance Monitoring (PM) parameters is defined, monitoring the quality of the line when retransmission is enabled.

7.12 Per-line configuration overrule

The configuration parameters for xDSL lines are provisioned by means of profiles. Typically, the same configuration profile is used on multiple lines that share similar line characteristics and offer the same type of service. If some deviation is required for the configuration of a particular line, then a completely new profile has to be assigned to this line.

The per-line configuration overrule feature allows to overrule part of the xDSL configuration parameters on a per-line basis, as shown in Figure 7-9.

Figure 7-9 Per-line configuration overrule

DSLAM

CPE

??

DTU

DTU

Parameter 1

Parameter 2

Parameter 3

Parameter N

……

Parameter 2

Parameter 1

Parameter 3

…

Parameter 2

Parameter N

Parameter N

XDSL Profiles

XDSL per-line overrule parameters

Actualconfiguration

merge

7 — xDSL features


This feature allows fine-tuning the configuration of individual lines, deviating from the overall settings configured via the profiles.

When using this feature, one should take care that the overruled parameter values do not result in an inconsistency with the parameters that are configured via the profiles.


8 — Integrated Voice service: ISAM Voice


8.2 Overall network topology 8-3

8.3 Product and market applicability 8-11

8.4 Overall network support 8-14

8.5 VLAN / user-to-user communication applicability 8-14

8.6 Traffic types 8-16

8.7 Traffic forwarding methods 8-17

8.8 Layer 2/layer 3 addressing topologies 8-44

8.9 Protocol stacks 8-77

8.10 Management interface 8-86

8.11 Permanent data storage 8-91

8.12 Management model 8-92

8.13 CDE profile management 8-105

8.14 Service profile management 8-105

8.15 Performance monitoring 8-106



8.16 Reliability, Equipment / Connectivity / Overload Protection 8-115

8.17 Quality of Service 8-120

8.18 DHCP interworking 8-121

8.19 DNS interworking 8-122

8.20 Basic call handling and supplementary services 8-123

8.21 BITS Support 8-134

8.22 Narrowband Line Testing 8-135

8.23 Termination local loop unbundling 8-135

8.24 Subscriber Line Showering 8-136

8.25 Lawful Intercept 8-136

8.26 Compliancy to standards 8-138

8.27 ISAM Voice migration 8-140



8.1 Introduction

A specific use of the ISAM is to provide classic telephony services to subscribers being connected with classic POTS/ISDN BRI lines, and to convert the corresponding signals to VoIP signaling/data packets. An ISAM supporting the integrated voice service is called ISAM Voice

The integrated voice service provides POTS or ISDN BRI service to subscribers over copper pairs together or without xDSL service.

The voice information is converted to VoIP in the ISAM Voice access node and forwarded to/from the service provider's Ethernet/IP network over optical fibers along with the HSI and IPTV services carried by the access node.

VoIP networks are subject to standardization. Within standardization there are two different approaches for the signaling:

• A set of standards driven by ITU-T, centered around ITU-T document H.248. In a nutshell: a network based on this standard uses RTP for the voice and Megaco for the signaling.

• A set of standards driven by IETF SIP. In a nutshell: a network based on this standard uses RTP for the voice and SIP for the signaling.VoIP SIP is supported by TISPAN compliant mode and non-IMS compliant mode.

ISAM Voice supports both signaling methods and can be deployed in the corresponding network topologies. However, ISAM Voice does not support both methods to run concurrently in the same access node.

8.2 Overall network topology

This section describes the overall network topology for:

• Megaco ISAM Voice situated in a Next Generation Voice Network (NVGN).• SIP ISAM Voice situated in a TISPAN-compliant NGN-IMS network.• SIP ISAM Voice situated in a non-IMS-compliant network.

Megaco ISAM Voice situated in a NGVN network

Megaco ISAM Voice supports Narrowband (NB) services and provides the connection to the NVGN for legacy Public Switching Telephone Network (PSTN) users via Voice over IP (VoIP). It plays the role of Media Gateway (MG), also called Access Media Gateway (AG).



Figure 8-1 Megaco ISAM Voice situated in a NGVN network

Megaco ISAM Voice connects legacy Narrow Band (NB) user interfaces, including Plain Old Telephone Services (POTS) and Integrated Services Digital Network (ISDN) BRI, to the NGVN.

Megaco ISAM Voice supports centralized configurations, where the NB user interfaces and MG are integrated in the same node, and distributed configurations, where the MG is located in a hub node and the NB user interfaces in remote nodes. The remote nodes can be subtended by the ISAM Voice acting as a MG, or located within the layer 2 aggregation or IP network.

A voice cluster is the aggregation of one Voice server pair, residing in the hub node, together with its voice associated ISAM nodes, that is, together with the ISAM nodes that contain Voice Line Termination (LT) boards that are managed by that particular Voice server pair. A voice cluster can support a maximum of 5K subscribers. These subscribers may be scattered over a maximum of 32 ISAM nodes and a maximum of 104 Voice LT boards.

A hub node may contain up to 8 Voice server pairs. In other words a hub node may host up to 8 different Voice Clusters.

The hub ISAM Voice, combined with the subtending/remote ISAM Voice, provides the view of a unique centralized MG. In subtending or remote configurations, the connection to the hub is via Fast or Gigabit Ethernet (optical or electrical). The Trunk MG links the NGVN with a legacy PSTN network.

The Softswitch is responsible for call control and charging, and communicates with the Media Gateways (Megaco ISAM Voice) via the Media Gateway Control (Megaco) protocol H.248.

SIGTRAN is used for ISDN BRI users, that is, Q921 is terminated in ISAM Voice and SIGTRAN is implemented to transfer Q931 messages between ISAM Voice and ASP.

IP Network

BAS

Servers

Softswitch

H.248 / SIGTRAN.

L2 AggregationNetwork

IPedge

PSTN

TGW

MG

POTS

SubtendingISAM Voice

POTS

ISDN

POTS

ISDN

POTS

ISDN

MGC ASPRTP

POTS/ISDN

Central OfficeISAM Voice POTS /

ISDN

POTS/ISDN

POTS/ISDN

RemoteISAM Voice

RemoteISAM Voice



SIP ISAM Voice situated in a TISPAN-compliant NGN-IMS network

SIP ISAM Voice supports Narrowband (NB) services and provides the connection to Next Generation Networks (NGN) for legacy PSTN users via Voice over IP (VoIP).

ISAM Voice plays the role as Voice Gateway (VGW) and communicates with the IMS core via the SIP protocol.

Figure 8-2 SIP ISAM Voice situated in a TISPAN compliant NGN-IMS network

ISAM Voice connects legacy Narrow Band (NB) user interfaces, the Plain Old Telephone Services (POTS), to the NGN/IMS.

Each of the nodes connected to the layer 2 aggregation or IP network has the SIP UA locally integrated on the Voice LT. The local SIP UA serves all NB user interfaces connected to a Voice LT.

The Call Session Control Function (CSCF) establishes, monitors, supports and releases multimedia sessions and manages the user's service interactions. The CSCF can act as Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) or Interrogating CSCF (I-CSCF):

• The P-CSCF is the first contact point for the ISAM Voice within the IM subsystem (IMS).

• The S-CSCF fulfils the role of registrar and handles the session states in the network.

• The I-CSCF is mainly the contact point within an operator's network for all IMS connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area.

IP Ne twork

SIP

L2 Ag g re g a tionNe twork

BAS

Servers

ER

PSTN

ISAM Voice

POTS

POTS

UA

ISAM Voice

UA

ISAM Voice

UA

ISAM Voice

UA

ERIMS Core

P_CSCF

I_CSCF

S_CSCF

AS

MRF

HSS

SBC

DNS Se rve r

DHCP Se rve r

Vo iceGa te wa y

RTP

Mgmt Pla tfo rm

SGF/ T-MGF

O th e r IPNetworks

IBCF/ IBGF

MGCF

x-CSCF/ BGCFPOTS

POTS

POTS

POTS

POTS

POTS

POTS

POTS

POTS

POTS



The Home Subscriber Server (HSS) is a master user database that supports the IMS network entities that handle calls. It contains the subscription-related information (user profiles), performs authentication and authorization of the user, and can provide information about the user's physical location.

Interconnection with legacy PSTN networks is guaranteed at the signaling level via the Signaling Gateway Function (SGF) (transport) and the Media Gateway Control Function (MGCF) (call/service control). Interconnection at the media level is provided by the Trunk Media Gateway Function (T-MGF).

Interconnection with other IP-based service subsystems (including other IMS subsystems) is performed via the Interconnection Breakout Control function (IBCF) at the signaling level and the Interconnection-Border Gateway Function (I-BGF) at the media level.

Very often, to support lawful intercept, Voice traffic is switched along the Legal Intercept gateway.

SIP ISAM Voice situated in a non-IMS-compliant networkSIP ISAM Voice supports the Narrowband (NB) services and provides the connection to an IMS-like New Generation Network (NGN) for legacy PSTN users via Voice over IP (VoIP).

ISAM Voice plays the role as Voice Gateway (VGW) and can interfaces with voice feature servers acting as back-to-back SIP Servers via the SIP protocol.

Figure 8-3 SIP ISAM Voice situated in a non-IMS-compliant network

ISAM Voice connects legacy Narrow Band (NB) user interfaces, the Plain Old Telephone Services (POTS), to a NGN/IMS network.

Each of the nodes connected to the IP network has the SIP UA locally integrated on the Voice LT. The local instance of the SIP User Agent (UA) serves all NB user interfaces connected to a Voice LT.

Back-to-backserver

Management Platform DHCP server

MediaGateway

IP

SIP

SNMP/CLI/TL1

RTP / RTCP

DHCP

ISAMVoice

POTS

POTS



The role of the SIP ISAM Voice is twofold:

• Access Gateway.• Access Gateway Controller (maintains AG states, manages AG features,

implements SIP UA).

Access network L2/L3 topologies

Megaco ISAM Voice

ISAM Voice access nodes belonging to a Voice cluster may be connected by layer 2, layer 3 or even a mixture of a layer 2 aggregation network and a layer 3 aggregation network.

Different Voice clusters may be connected by layer 2, layer 3 or even a mixture of a layer 2 aggregation network and a layer 3 aggregation networks.

The supported ISAM Voice Cluster topologies are shown in Figure 8-4, Figure 8-5, Figure 8-6, Figure 8-7, Figure 8-8 and Figure 8-9.

Figure 8-4 Megaco ISAM Voice: Voice Cluster topology A

VoiceLT 1

VoiceLT 2

VoiceLT 16

xVPSpair 1

xVPSpair 2

Voice LT shelf 8

Belongs to voice clustersupervised by xVPS pair 8

Voice LT shelf 2

Belongs to voice clustersupervised by xVPS pair2

Voice LT shelf 1


Main shelf

xVPSpair 8

VoiceLT 1

VoiceLT 1

VoiceLT 2

VoiceLT 2

VoiceLT 16

VoiceLT 16



Figure 8-5 Megaco ISAM Voice: Voice Cluster topology B

Figure 8-6 Megaco ISAM Voice: Voice Cluster topology C

VoiceLT 1

VoiceLT 2

VoiceLT 16

xVPSpair 1

xVPSpair 2

Voice LT shelf 2


Voice LT shelf 1


Main shelf

xVPSpair 3

VoiceLT 1

VoiceLT 1

VoiceLT 2

VoiceLT 2

VoiceLT 16

VoiceLT 16

Voice LT shelf 3


VoiceLT 1

VoiceLT 2

VoiceLT 16

xVPSpair 1

xVPSpair 2

Voice LT shelf 2


Voice LT shelf 1


Main shelf

xVPSpair 3

VoiceLT 1

VoiceLT 1

VoiceLT 2

VoiceLT 2

VoiceLT 16

VoiceLT 16

Voice LT shelf 3


VoiceLT 1

VoiceLT 2

VoiceLT 10

Voice LTs belongs to voice clustersupervised by xVPS pair 1



Figure 8-7 Megaco ISAM Voice: Voice Cluster topology D

Figure 8-8 Megaco ISAM Voice: Voice Cluster topology E

VoiceLT 1

VoiceLT 2

VoiceLT 16

xVPSpair 1

xVPSpair 2

Voice LT shelf 2


Voice LT shelf 1


Main shelf

xVPSpair 3

VoiceLT 1

VoiceLT 1

VoiceLT 2

VoiceLT 2

VoiceLT 16

VoiceLT 16

Voice LT shelf 3


VoiceLT 1

VoiceLT 2

VoiceLT 10

Voice LTs belong to different voice clusterssupervised by xVPS pair 1, 2 or 3

xVPSpair 1

xVPSpair 2

Voice LT shelf 8 (multiple)


Main shelf

xVPSpair 8

VoiceLT 1

VoiceLT 2

VoiceLT 16

VoiceLT 1

VoiceLT N

VoiceLT 16

Voice LTs inshelf 1 belong to voice

cluster supervised byxVPS pair 1

VoiceLT N+1



VoiceLT 1

VoiceLT M

VoiceLT 16



VoiceLT M+1





Figure 8-9 Megaco ISAM Voice: Voice Cluster topology F

SIP ISAM Voice

ISAM Voice access nodes may be connected by layer 2, layer 3 or even a mixture of a layer 2 aggregation network and a layer 3 aggregation network.

Figure 8-10 ISAM Voice access nodes connected to a layer 2 Aggregation Network

xVPSpair 1

xVPSpair 2

Main shelf

xVPSpair 3

VoiceLT 1

VoiceLT 2

VoiceLT 16

Voice LT shelf 3

Belongs to different voice clusterssupervised by xVPS pair 1, 2 or 3

VoiceLT 1

VoiceLT 2

VoiceLT 10

Voice LTs belong to different voice clusterssupervised by xVPS pair 1, 2 or 3

VoiceLT 1

VoiceLT N

VoiceLT 16



VoiceLT N+1



VoiceLT 1

VoiceLT M

VoiceLT 16



VoiceLT M+1



L2

Aggrega tion

Network

L3

Aggrega tion

Network

Iv = ISAM Voice

IvIv

Iv

Iv

Iv

IvIv



Figure 8-11 ISAM Voice access nodes connected to a layer 3 Aggregation Network

Figure 8-12 ISAM Voice access nodes connected to a layer 2/layer 3 Aggregation Network

8.3 Product and market applicability

SIPThe SIP-signaling-based integrated voice services are supported in:

• 7302 ISAM FD: POTS service supported. 18 LT slot positions can be planned with the Voice LT board.

• 7330 ISAM FTTN FD: POTS service supported. 10 LT slot positions can be planned with Voice LT.

L3

Aggrega tion

Network

IV= ISAM Voice

IvIv

Iv

Iv

Iv

IvIV

L2

Aggrega tion

Network

L3

Aggrega tion

Network

Iv = ISAM Voice

IvIv

Iv

Iv

Iv

IvIv



• 7356 SB-REM (FD) ETSI: POTS service supported. The Voice LT board can be planned for both the “master” (72-lines LT board only) and the “non-master” (48- and 72-lines LT board) slot position.

• ERAM-A (AGNT-A): POTS service supported. Maximum 24 LT slot positions can be planned with the Voice LT board.

IMSIn an IMS network topology, the SIP signaling POTS service and the H.248 (Megaco) signaling based ISDN BRI service can be mixed in the same 7302 / 7330 ISAM shelf.

In an IMS network topology, H.248 ISDN-BRI subscribers register to their Media Gateway Controller and are managed by the local Media Gateway (Voice Server) while SIP POTS subscribers register to their registrar and are managed by the local SIP User Agent.

Any VLAN topology for this mixed SIP/H.248 voice services is allowed, on the condition that not more than 2 VLANS (Public or Private) of type Voice-VLAN are configured per shelf.

• SIP centralised architecture: BOTH signaling and RTP/RTCP traffic MUST be carried by a VLAN of the type voice-VLAN.

• SIP distributed architecture: NEITHER signaling NOR RTP/RTCP traffic MUST be carried by a VLAN of the type voice-VLAN.

• H.248 architecture: XLES/RTP/RTCP traffic MUST be carried in a VLAN of the type voice-VLAN. SIGNALING traffic MAY NOT be carried in a VLAN of the type voice-VLAN.

Following VLAN topologies are supported:

• SIP POTS Centralised Architecture + H.248 ISDN-BRI:• SIP signaling traffic + (SIP related) RTP/RTCP traffic and H.248 signaling traffic +

(H.248 related) RTP/RTCP traffic, all traffic sharing the same VLAN (only one VLAN that carries all signaling and all RTP/RTCP traffic). VLAN ID (shared SIP signaling + H.248 signaling + SIP related RTP/RTCP + H.248 related RTP/RTCP).

• Distinct VLAN for SIP signaling traffic, distinct VLAN for H.248 signaling traffic, distinct VLAN shared by (SIP related) RTP/RTCP and (H.248 related) RTP/RTCP traffic.VLAN ID (SIP signaling) different from VLAN ID (H.248 signaling different from VLAN ID (Shared SIP related and H.248 related RTP/RTCP).

• Distinct VLAN shared by SIP signaling traffic and (SIP related) RTP/RTCP traffic. Distinct VLAN for H.248 signaling traffic. Distinct VLAN for (H.248 related) RTP/RTCP traffic.VLAN ID (Shared SIP traffic) different from VLAN ID (H.248 signaling) different from VLAN ID (H.248 related RTP/RTCP).

• Distinct VLAN shared by SIP signaling traffic + (SIP related) RTP/RTCP traffic.Distinct VLAN shared by H.248 signaling traffic + (H.248 related) RTP/RTCP traffic.VLAN ID (Shared SIP traffic) different from VLAN ID (Shared H.248 traffic).



• SIP POTS Distributed Architecture + H.248 ISDN BRI:• SIP signaling traffic + (SIP related) RTP/RTCP traffic and H.248 signaling traffic +

(H.248 related) RTP/RTCP traffic, all traffic sharing the same VLAN (only one VLAN that carries all signaling and all RTP/RTCP traffic).VLAN ID (shared SIP signaling + H.248 signaling + SIP related RTP/RTCP + H.248 related RTP/RTCP).

• Distinct VLAN for SIP signaling traffic, distinct VLAN for H.248 signaling traffic, distinct VLAN shared by (SIP related) RTP/RTCP and (H.248 related) RTP/RTCP traffic.VLAN ID (SIP signaling) different from VLAN ID (H.248 signaling different from VLAN ID (Shared SIP related and H.248 related RTP/RTCP).

• Distinct VLAN shared by SIP signaling traffic and (SIP related) RTP/RTCP traffic. Distinct VLAN for H.248 signaling traffic. Distinct VLAN for (H.248 related) RTP/RTCP traffic.VLAN ID (Shared SIP traffic) different from VLAN ID (H.248 signaling) different from VLAN ID (H.248 related RTP/RTCP).

• Distinct VLAN shared by SIP signaling traffic + (SIP related) RTP/RTCP traffic.Distinct VLAN shared by H.248 signaling traffic + (H.248 related) RTP/RTCP traffic.VLAN ID (Shared SIP traffic) different from VLAN ID (Shared H.248 traffic).

• Distinct VLAN for SIP signaling traffic. Distinct VLAN for (SIP related) RTP/RTCP traffic. Distinct VLAN for H.248 signaling traffic. Distinct VLAN for (H.248 related) RTP/RTCP traffic.VLAN ID (SIP signaling) different from VLAN ID (H.248 signaling) different from VLAN ID (SIP related RTP/RTCP) different from VLAN ID (H.248 related RTP/RTCP).

• IP Address/subnet reduction configuration by means of private VLAN.• IP Address/subnet reduction applies to the H.248 ISDN BRI service only• The Private VLAN must always be of type voice-VLAN.• Any VLAN topology for this mixed SIP/H.248 voice services is allowed, on the

condition that not more than 2 VLANS of type Voice-VLAN are configured per shelf.

External packet forwardingSee section “Megaco ISAM Voice: External Packet Forwarding (EPF)”.

• SIP POTS Centralised Architecture + H.248 ISDN-BRI: supported for POTS and ISDN-BRI terminations.

• SIP POTS Distributed Architecture + H.248 ISDN-BRI: supported for ISDN-BRI terminations only.

Other

• The mixed SIP signaling POTS and H.248 (Megaco) signaling based ISDN BRI service is supported for both, the switched as well as the routed voice model.

• H.248 clustering is supported (Hub/Subtending/Remote ISAM Voice node).• Integrated Line Test is supported for SIP signaling POTS terminations.



• MTA is supported for both SIP signaling POTS and H.248 ISDN BRI terminations.

• Basic call service and Supplementary services are supported for both SIP signaling POTS and H.248 ISDN BRI

8.4 Overall network support

• Megaco ISAM Voice situated in a Next Generation Voice Network (NGVN): supported

• SIP ISAM Voice situated in a TISPAN-compliant NGN-IMS network: supported• SIP ISAM Voice situated in a non-IMS-compliant network: supported

8.5 VLAN / user-to-user communication applicability

The integrated voice service requires that user-to-user communication is enabled for RTP/XLES traffic.

Two VLAN types are applicable to the deployment of the integrated Voice service:

• iBridge VLAN type• Voice VLAN type

The VLAN type that needs to be applied depends on the downstream signaling/voice traffic forwarding behavior being required at the SHub:

• Downstream forwarding behavior is L4 forwarding: only the Voice VLAN type can be used.

• Downstream forwarding behavior is L2 forwarding: both the Voice VLAN type and the iBridge VLAN type may be used.

If the iBridge VLAN type is used then L2/L3 user-to-user communication must be enabled for this VLAN.

If the Voice VLAN type is used, then L2/L3 user-to-user communication is autonomously enabled by the system. In addition, the configuration of an IP interface on top of this VLAN (at the SHub side) autonomously enables the L4 forwarding behavior in downstream direction at the ASAM port(s).

In practice, this means the following:

For H.248:

• NT is used as a switching device:• the signaling VLAN is of the iBridge VLAN type• the RTP/XLES VLAN is of the Voice VLAN type

• NT is used as a routing device (at the VRF user side):• the signaling VLAN is of the iBridge VLAN type• the RTP/XLES VLAN is of the Voice VLAN type



For SIP Distributed Architecture:

• NT is used as a switching device:• the signaling VLAN is of the iBridge VLAN type• the RTP VLAN is of the iBridge VLAN type

• NT is used as a routing device (at the VRF user side):• the signaling VLAN is of the iBridge VLAN type• the RTP VLAN is of the iBridge VLAN type

For SIP Centralized Architecture:

• NT is used as a switching device:• the signaling VLAN is of the Voice VLAN type• the RTP VLAN is of the Voice VLAN type

• NT is used as a routing device (at the VRF user side):• the signaling VLAN is of the Voice VLAN type• the RTP VLAN is of the Voice VLAN type



8.6 Traffic types

Megaco ISAM Voice

Four main traffic types can be distinguished:

• Management traffic (SNMP, CLI, TL1 (alarm display only)) exchanged between the external management platform and the Network termination (NT) and Voice server.

• Signaling traffic (Megaco, SIGTRAN) exchanged between the Media Gateway Controller (MGC)/Application Server Process (ASP) and the Voice server.

• Internal signaling traffic (XLES) exchanged between the Voice server and its underlying Voice LT boards hosted in either the hub, subtending or remote access nodes.

• Voice data traffic (RTP, RTCP, T.38, T.30, Voice Band data) exchanged between Voice terminations.

Management traffic is exchanged in the external communication VLAN and as such kept separated from the other traffic types. This is done for security reasons.

Voice data traffic and internal signaling traffic always share the same VLAN.

External signaling traffic may be exchanged in a dedicated signaling VLAN or may even share the same VLAN as the Voice data and Internal signaling traffic. The latter situation occurs when IP address/IP subnet optimization is preferred above signaling and voice data traffic isolation.

SIP ISAM Voice

Three main traffic types can be distinguished:

• Management traffic (SNMP, CLI, TL1) exchanged between the external management platform and the Network termination (NT).

• Signaling traffic (SIP) exchanged between the SIP Server and the SIP User Agent residing at the Voice LT.

• Voice data traffic (RTP, RTCP, T.38, T.30, Voice Band data) exchanged between voice terminations.

Management traffic is exchanged in the external communication VLAN and as such kept separated from the other traffic types. This is done for security reasons.

External signaling traffic may be exchanged in a dedicated signaling VLAN or may even share the same VLAN as the Voice data signaling traffic. The latter situation occurs when IP address/IP subnet optimization is preferred above signaling and voice data traffic isolation.



8.7 Traffic forwarding methods

The internal forwarding is frame based. Frame based forwarding is done either based on layer 2 (Ethernet), layer 3 (IP) or layer 4 (UDP/TCP) information carried in the frames.

The applied forwarding methods may be different for upstream and downstream traffic forwarding.

For layer 2 forwarding, see chapter “Layer 2 forwarding”. For layer 3 forwarding, see chapter “IP routing”.

The basic concept of layer 4 forwarding is explained in the following section.

Conceptual models

MEGACO switched model

Figure 8-13 shows the MEGACO ISAM Voice switched model.

Figure 8-13 Megaco ISAM Voice: switched model

• The network signaling VLAN terminates at the Voice server• The network RTP/RTCP (XLES) VLAN terminates at the voice LT board/Voice

server• The signaling VLAN is configured as type “Voice-VLAN” or “RB-VLAN”• The RTP/RTCP/XLES VLAN is configured as type “Voice-VLAN”• The source/destination IP address for H.248 signaling traffic is configured at the

Voice server• The source/destination IP address for XLES traffic is configured at the Voice

server• The source/destination IP address for RTP/RTCP traffic is configured at the

SHub and is shared by all the Voice LT boards• The SHub performs L4 forwarding for RTP/RTCP/XLES traffic destined to the

voice LT board• The SHub performs L2 forwarding for upstream/downstream signaling traffic

Voice LT

Voice server

NT

Voice VLAN

Signaling VLAN

Main ISAM Voice

IP addressXLES

IP addresssignalling

IP address voice

Fast path VRF



• The SHub performs L3 forwarding for upstream RTP/RTCP/XLES traffic.

MEGACO routed model

Figure 8-14 shows the MEGACO ISAM Voice routed model.

Figure 8-14 Megaco ISAM Voice: routed model

The conceptual architecture shows different VLANs carrying H.248 signaling and RTP/RTCP/XLES traffic at the network side than at the user side of the VRF.

The internal VLAN that carries RTP/RTCP/XLES traffic must be of type “voice-VLAN” as to perform L4 forwarding in downstream direction.

The internal VLAN that carries the signaling traffic may be of type “Voice-VLAN” or “RB-VLAN”.

• SHub VRF user side: a numbered IP interface is configured on top of the internal voice VLAN for the following reasons:

• This IP interface is used as the destination IP address for RTP/RTCP/XLES packets addressed to the voice LT board. For this purpose, the Voice subnet is advertised (as host subnet) to the upstream network.

• The SHub is considered as the first next hop for the RTP/XLES packets sent in the upstream direction by the Voice server.

• SHub VRF user side: A numbered IP interface is configured on top of the internal signaling VLAN. The SHub is seen as the first next hop for the H.248 signaling traffic that originates from the Media Gateway running at the Voice server.The signaling subnet is advertised (as host subnet) to the upstream network.

• SHub network side: A numbered IP interface is configured on top of the network-side signaling VLAN.

• SHub network side: A numbered IP interface is configured on top of the network-side TP/RTCP/XLES VLAN.

In the upstream direction, the selection of the network interface/VLAN will happen as the result of the IP DA look-up in the L3 forwarding table, and this for all the voice service related traffic (H.248 signaling, XLES, RTP and RTCP).

Voice LT

Voice server

NT

InternalVoiceVLAN

Internalsignaling

VLAN

Main ISAM Voice

IP addressXLES


Fast path VRF

IP addressVoice

IP addressUser 1

IP addressnetwork 1

IP addressnetwork 2

NetworkVLAN 1

NetworkVLAN 2



In the downstream direction, voice-service-related traffic (H.248 signaling, XLES, RTP and RTCP) may be received at any network interface/VLAN. The SHub must perform the further L3 forwarding to:

• the appropriate internal VLAN• and to the destined xVPS• and to the destined voice LT board (by L4 forwarding)

From a downstream forwarding perspective, seen from the edge router, the ISAM Voice access node is configured as the next-hop.

SIP ISAM Voice (centralized architecture): switched model

Figure 8-15 shows the SIP ISAM Voice (centralized architecture) switched model.

Figure 8-15 SIP ISAM Voice (centralized architecture): switched model

• The network signaling VLAN terminates at the voice LT board• The network RTP/RTCP VLAN terminates at the voice LT board• At the SHub, both VLANs are configured as type “Voice-VLAN”• The source/destination IP address for SIP signaling traffic is configured at the

SHub. It is shared by all the voice LT boards• The source/destination IP address for RTP/RTCP traffic is configured at the

SHub. It is shared by all the voice LT boards• The SHub performs L4 forwarding for SIP signaling/RTP/RTCP traffic destined

to the voice LT board• The SHub performs L3 forwarding for upstream SIP signaling/RTP/RTCP

traffic.

SIP ISAM Voice - centralized architecture: routed model

Figure 8-16 shows the SIP ISAM Voice (centralized architecture) routed model.

Voice LT

NT

Voice VLAN

Signaling VLAN

Main ISAM Voice


IP address voice

Fast path VRF



Figure 8-16 SIP ISAM Voice (centralized architecture): routed model

The conceptual architecture shows different VLANs carrying SIP signaling and RTP/RTCP traffic at the network and the user side of the VRF.

Both internal VLANs must be of type “Voice VLAN” as to perform L4 forwarding in downstream direction.

• SHub VRF user side: A numbered IP interface is configured on top of the internal voice VLAN. This IP address is used as destination IP address for RTP/RTCP packets addressed to the voice LT board. For this purpose, the Voice subnet is advertised (as host subnet) to the upstream network.

• SHub VRF user side: A numbered IP interface is configured on top of the internal signaling VLAN. This IP address is used as destination IP address for SIP signaling packets addressed to the voice LT board. For this purpose, the signaling subnet is advertised (as host subnet) to the upstream network.

• SHub VRF network side: A numbered IP interface is configured on top of the network voice VLAN

• SHub VRF network side: A numbered IP interface is configured on top of the network signaling VLAN.

In the upstream direction, the selection of the network interface/VLAN will happen as the result of the IP DA look-up in the L3 forwarding table. And this for all the voice service related traffic (SIP signaling, RTP and RTCP).

In the downstream direction, voice service related traffic (SIP signaling, RTP and RTCP) may be received at any network interface/VLAN. The SHub must perform the further L3 forwarding to the appropriate internal VLAN

- and to the destined voice LT board (by L4 forwarding)

- and to the destined voice LT board (by L4 forwarding)


SIP ISAM Voice - distributed architecture: switched model

Figure 8-17 shows the SIP ISAM Voice (distributed architecture) switched model.

Voice LT

NT

InternalVoiceVLAN

Internalsignaling

VLAN

Main ISAM VoiceFast path VRF

IP addressVoice

IP addresssignaling

IP addressnetwork 1

IP addressnetwork 2

NetworkVLAN 1

NetworkVLAN 2



Figure 8-17 SIP ISAM Voice (distributed architecture): switched model

• The network signaling VLAN terminates at the voice LT board• The network RTP/RTCP VLAN terminates at the voice LT board• At the SHub, both VLANs are configured as type “iBridge” or “Voice VLAN”• The source/destination IP address for SIP signaling traffic is configured at the

voice LT boards• The source/destination IP address for RTP/RTCP traffic is configured at the voice

LT boards• The SHub performs L2 forwarding for SIP signaling/RTP/RTCP traffic destined

to the voice LT board

SIP ISAM Voice - distributed architecture: routed model

Figure 8-18 shows the SIP ISAM Voice (distributed architecture) routed model.

Figure 8-18 SIP ISAM Voice (distributed architecture): routed model

The conceptual architecture shows different VLANs carrying SIP signaling and RTP/RTCP traffic at the network and the user side of the VRF.

At the VRF user side, internal VLANs are configured as type “iBridge” or “Voice VLAN”. Both the Voice subnet and the signaling subnet are advertised (as host subnet) to the upstream network.

Voice LTNT

Voice VLAN

Signaling VLAN

Main ISAM Voice


IP addressvoice

Fast path VRF

Voice LTNT

InternalVoiceVLAN

Internalsignaling

VLAN


IP addressUser 1

IP addressUser 2

IP addressnetwork 1

IP addressnetwork 2

NetworkVLAN 1

NetworkVLAN 2

IP addressVoice

IP addresssignaling



The SHub will be considered as the first next hop for the SIP signaling and for the RTP/RTCP traffic that originates from the voice LT board. For this reason, a numbered IP interface is configured on both the internal signaling VLAN and the internal RTP/RTCP VLAN at the VRF user side.

In the upstream direction, the selection of the network interface/VLAN will happen as the result of the IP DA look-up in the L3 forwarding table. And this for all the voice service related traffic (SIP signaling, RTP and RTCP).

In the downstream direction, voice-service-related traffic (SIP signaling, RTP and RTCP) may be received at any network interface/VLAN. The SHub must perform the further L3 forwarding to the appropriate internal VLAN and to the destined voice LT board.


Subtended topology: switched model

Figure 8-19 shows the MEGACO/SIP ISAM voice subtended topology for the switched model.

Figure 8-19 Subtended topology: switched model

The subtending ISAM Voice access node remains configured as a switching device. Only the main ISAM Voice access node fulfills the routing service.

Subtended topology: routed model

Figure 8-20 shows the MEGACO/SIP ISAM voice subtended topology for the routed model.

NT

Voice VLAN

Signaling VLAN


NT

Subtending ISAMFast path VRF



Figure 8-20 Subtended topology: routed model

The subtending ISAM Voice access node remains configured as a switching device. Only the main ISAM Voice access node fulfills the routing service.

Layer 4 forwarding

The layer 4 forwarding applies to downstream traffic only and is installed at the SHub on a per-VLAN basis. This forwarding method uses the contents of the destination port field in the transport protocol header of the packet to forward a packet to a voice LT. The configuration of an IP interface on top of a VLAN configured as Voice-VLAN automatically installs the layer 4 forwarding property.

Each voice LT gets assigned a fixed transport protocol port range. The SHub port that connects the voice LT inherits this port range mapping. The transport protocol port range for free usage (IANA) that is, 49153 - 65535 is divided in 24 equal portions and the lower part of each portion is mapped to the different SHub ports. The mapping algorithm is fixed to achieve the same range to SHub port mapping. Upon receipt of a downstream packet within a layer 4 forwarding capable VLAN and with the destination IP address configured on top of this VLAN, the destination port value of the transport protocol header included in the packet is compared against all defined transport protocol ranges. When a match is found, the corresponding SHub port mapping is read and the packet is forwarded to the voice LT that connects to this SHub port.

As described, the layer 4 forwarding uses the combination {VLAN + destination IP address + destination Transport Protocol port} to decide about the further downstream forwarding of an IP packet.

Layer 4 forwarding may be applied to external signaling, internal signaling and voice data traffic.

Layer 4 forwarding supports packet fragmentation at IP layer because unlike Voice traffic, SIP signaling traffic may be fragmented at the IP layer.

NT


IP addressUser 1

IP addressUser 2

IP addressnetwork 1

IP addressnetwork 2

NetworkVLAN 1

NetworkVLAN 2

NT


IP addresssub 1

IP addresssub 2



The transport protocol port range to SHub mapping is the same in every ISAM Voice node.

The described algorithm is schematically shown in Figure 8-21.

Figure 8-21 Layer 4 forwarding approach

Megaco ISAM Voice as switching device

Signaling traffic

Signaling traffic originates and terminates at the Voice server.

In the upstream direction, the Voice server determines the IP next hop for the destination IP address of the packet and forwards the IP packet appropriately. The local SHub and any potential intermediate SHub perform layer 2 forwarding.

In the downstream direction: The local SHub and any potential intermediate SHub perform layer 2 forwarding.

Layer 2 VLAN/MAC table

(Transport Prot port range1, port a )(Transport Prot portrange2, port a )

…(Transport Prot port rangeN, port a )

SHub

Match(VLAN ID +

ownMAC address/IP address)?

Layer 3 IP table

Layer 2/layer 3 forwarding

Layer 4 forwarding

ARP ARP

Ingress

Egress

Y

N

1

2

n



Figure 8-22 Megaco ISAM Voice (switched): signaling forwarding

XLES traffic

XLES traffic originates at the Voice server or at the Voice LT board and terminates respectively at the Voice LT board or the Voice server.

• XLES traffic originating at the Voice server and destined to the Voice LT board (see Figure 8-23):The destined Voice LT board is connected either to the local access node, to an access node subtending to the local access node, or to an access node connected via a layer 2 aggregation network with the local access node.The destination (Shub) IP address of the packet can directly be reached in the local subnet: the Voice server performs ARP for the destination (Shub) IP address and forwards the IP packet to this (Shub) IP address.The destined Voice LT board is reachable via a layer 3 aggregation network. The Voice server determines the IP next hop for the destination (Shub) IP address of the packet, performs ARP for the next hop IP address and forwards the IP packet appropriately.The (destined) SHub that connects the destined Voice LT performs layer 4 forwarding.Any potential intermediate Shub in between the Voice Server and the destined Shub performs layer 2 forwarding.

Main node

NT board

SHub VoiceIP address Voice LT

board

Voiceserver

Remote node

L2aggregation

network

MGC ASP

SoftSwitch

Voice LTboard

NT board

SHub VoiceIP address

L3 forwarding

L2 forwarding

Subtending node

NT board


board

Remote node

Voice LTboard

NT board


L3aggregation

network

SignalingIP address

XLESIP address

L4 forwarding

L4 forwarding

L4 forwarding



• XLES traffic originating at the Voice LT board and destined to the Voice server (see Figure 8-24):The Voice LT board forwards the XLES packet to the local SHub.

• The access node of the Voice LT board and the access node of the Voice server are the same or

• The Voice LT's access node subtends to the access node of the Voice server or• The Voice LT's access node is connected via a layer 2 aggregation network with the

access node of the Voice server:

The local SHub detects that the destination IP address of the packet can directly be reached via the local subnet. The local Shub performs ARP for the destination IP address and forwards the IP packet appropriately.The destined Voice Server is reachable via layer 3 aggregation network: The local SHub determines the IP next hop for the destination IP address of the packet, performs ARP the next hop IP address and forwards the IP packet appropriately.The SHub that connects the Voice server performs layer 2 forwarding. Any potential intermediate SHub in between the Voice LT's local Shub and the Voice Server L2 forwarding.

Figure 8-23 Megaco ISAM Voice (switched): XLES packet originating at the Voice server

Main node

NT board


board

Voiceserver

Remote node

L2aggregation

network

MGC ASP

SoftSwitch

Voice LTboard

NT board


L3 forwarding

L2 forwarding

Subtending node

NT board


board

Remote node

Voice LTboard

NT board


L3aggregation

network

SignalingIP address

XLESIP address

L4 forwarding

L4 forwarding

L4 forwarding



Figure 8-24 Megaco ISAM Voice (switched): XLES packet originating at the Voice LT board

Voice traffic

Voice traffic originates at the Voice LT board and is destined to a voice termination point either at the same Voice LT board, another Voice LT board in the same Voice cluster or outside the voice cluster.

In some cases the voice traffic is sent along the Voice server (as to support some supplementary services or an optimized IP addressing scheme).

Voice traffic is relayed to the SHub prior to the forwarding to the destined voice termination point. This relay is either done by the Voice LT board (voice traffic that may not pass the Voice server) or the Voice server (voice traffic that must pass the voice server).

Voice traffic not passing the Voice server:

• Voice traffic destined to an external termination point:• The voice LT board forwards the voice packet to the local SHub.• The local SHub determines the IP next hop for the voice traffic destination IP

address• The local SHub determines the IP next hop for the voice traffic destination IP

address• Any potential intermediate SHub between the local Shub and the next hop performs

layer 2 forwarding.• Voice traffic destined to a voice termination point at the same Voice LT board:

• The voice LT board forwards the voice packet to the local SHub.• The local SHub detects that the destination IP address of the packet is identical to

the own Voice IP address and treats the voice traffic locally.• The local SHub performs layer 4 forwarding to the Voice LT board from which the

packet originated.

Main node

NT board


board

Voiceserver

Remote node

L2aggregation

network

MGC ASP

SoftSwitch

Voice LTboard

NT board


L2 forwarding

Subtending node

NT board


board

Remote node

Voice LTboard

NT board


L3aggregation

network

SignalingIP address

XLESIP address

L3 forwarding

L3 forwarding

L3 forwarding



• Voice traffic destined to a voice termination point residing at a Voice LT board in the same access node:

• The voice LT board forwards the upstream voice packet to the local SHub.• The local SHub detects that the destination IP address of the packet is identical to

the own Voice IP address and treats the voice traffic locally.• The local SHub performs layer 4 forwarding to the Voice LT board to which the

destined voice termination point is connected.• Voice traffic destined to a voice termination point residing at a Voice LT in

another access node of the voice cluster:• The voice LT forwards the upstream voice packet to the local SHub.• One of the following takes place:

1. The destined Voice termination point is reachable via a layer 3 aggregation network:The local SHub determines the IP next hop for the destination IP address of the packet and forwards the IP packet appropriately.2. The destined Voice termination point reachable via a layer 2 aggregation network: The local SHub detects that the destination of the packet is reachable via the local subnet and forwards the IP packet appropriately.

• Any potential intermediate SHub between the local Shub and the destined SHub performs layer 2 forwarding.

• The SHub that connects the destined voice termination point (Voice LT board) performs layer 4 forwarding.

Voice traffic passing the Voice server:

• Voice traffic destined to the Voice server:• The voice LT forwards the voice packet to the local SHub.• One of the following takes place:

1. The destined Voice Server is reachable via layer 3 aggregation network:The local SHub determines the IP next hop for the Voice server, performs ARP for the next-hop IP address and forwards the voice traffic appropriately.2. The destined Voice Server is reachable via layer 2 aggregation network (in case the access node of the Voice LT board is either equal to the access node of the Voice server, or to an access node that subtends to the access node of the Voice server or to an access node connected via a layer 2 aggregation network with the access node of the Voice server): the local SHub detects that the Voice server is reachable within the local subnet. The local Shub performs ARP for the IP address of the Voice server and forwards the IP packet appropriately

• The SHub that connects the Voice server performs layer 2 forwarding.• Any potential intermediate SHub between the local Shub and the SHub that

connects the Voice server performs layer 2 forwarding.• Voice traffic relayed by the Voice server to a voice termination point connected

to a Voice LT board in the same access node:• The Voice server invokes the NAPT facility and forwards the packet along the local

SHub to itself (this is a basic forwarding condition to allow the support of External packet forwarding serving Lawful Intercept).

• The Voice server detects that the destination of the voice traffic is reachable via the local subnet and forwards the voice traffic to the IP address of the local SHub.

• The local SHub performs layer 4 forwarding to the Voice LT board that connects the Voice termination point.



• Voice traffic relayed by the Voice server to a voice termination point connected to a Voice LT board in another access node of the voice cluster:

• The destined Voice Termination point is reachable via layer 3 aggregation network. The Voice server determines the IP next hop for the destination of the voice traffic, performs ARP for the next hop IP address and forwards the voice traffic appropriately.

• The destined Voice Termination point is reachable via layer 2 aggregation network (in case the Voice Termination point is connected to an access node subtending to the local access node or an access node connected via a layer 2 aggregation network with the local access node):The Voice server invokes the NAPT facility and forwards the voice traffic along the local SHub to itself (this is a basic forwarding condition to allow the support of External packet forwarding serving Lawful Intercept).The Voice Server detects that the destination of the voice traffic is reachable via the local subnet, performs ARP for the destination IP address and forwards the voice traffic appropriately.

• The SHub that connects the Voice termination point (Voice LT board) performs layer 4 forwarding.

• Any potential intermediate SHub between the Voice server and the SHub connecting the destined voice termination performs layer 2 forwarding.

• Voice traffic relayed by the Voice server to an external voice termination point:• The Voice Server determines the IP next hop for the destination of the voice traffic,

performs ARP for the next hop IP address and forwards the voice traffic appropriately.

• Any potential intermediate SHub in between the Voice server and the next hop performs layer 2 forwarding.

Figure 8-25 Megaco ISAM Voice (switched): Voice packet originating at the Voice LT board

Main node

NT board


board

Voiceserver

Remote node

L2aggregation

network

MGC ASP

SoftSwitch

Voice LTboard

NT board


L2 forwarding

Subtending node

NT board


board

Remote node

Voice LTboard

NT board


L3aggregation

network

SignalingIP address

XLESIP address

L4 forwarding

L4 forwarding L3 forwarding

L3 forwarding



Figure 8-26 Megaco ISAM Voice (switched): Voice packet originating at the Voice server

OAM traffic

The management platform of the customer forwards the Voice OAM traffic to the public OAM IP address of the ISAM access node hosting the Voice server.

Voice OAM traffic is distinguishable by a Voice specific SNMP community string/context identifier from non-Voice OAM traffic and in addition distinguishable through the same SNMP community string/context identifier amongst the Voice server pairs (maximum 8) that may be hosted in the same ISAM access node.

Internally, the voice-specific OAM traffic is relayed to the Voice server.

Voice OAM responses generated by the Voice server are internally passed to the ISAM SNMP agent that forwards them to the management platform of the customer.

Any potential intermediate SHub performs layer 2 forwarding and this in both directions.

Refer also to chapter “Management interface functions”.

Megaco ISAM Voice as routing deviceThe following routing topologies are supported:

• Single ISAM-V access node topology:in this topology, only the main shelf is present. The main shelf behaves as a routing device.

• Subtending ISAM-V access node topology:in this topology, the main shelf and one or more subtending shelves are present. Only the main shelf behaves as routing device. The subtending shelves behave as switching device.

Main node

NT board


board

Voiceserver

Remote node

L2aggregation

network

MGC ASP

SoftSwitch

Voice LTboard

NT board


L3 forwarding

L2 forwarding

Subtending node

NT board


board

Remote node

Voice LTboard

NT board


L3aggregation

network

SignalingIP address

XLESIP address

L4 forwarding

L3 forwarding

L2 forwarding

L2 forwarding



Summarized: An ISAM-V access node that is directly connected to the upstream voice network can be configured as a routing device. An ISAM-V access node that is not directly connected to the upstream voice network must be configured as switching device.

Security considerations

The ISAM supports only a single fast path VRF. As a result, access nodes that are deployed in mixed mode (that is, narrowband services and broadband services are concurrently deployed by the same access node) must include protections that guarantee that data is kept secret against unwanted, unintended and malicious listeners and this for both the narrowband services and the broadband services.

This can be achieved as follows:

• At the network side of the VRF, the broadband data path is separated from the narrowband data path by configuring different VLANs for these different data paths (= different IP subnets).In this respect, path protection can be guaranteed by the routing protocols (different areas).

• At the user side of the VRF, ACLs need to be installed at the ports connection the LT boards to block broadband traffic from interfering with narrowband traffic and vice versa (that is, traffic received in the broadband path is not allowed to be destined to a narrowband user and, vice versa, traffic received in the narrowband path is not allowed to be destined to a broadband user).

• The ACLs will be built upon destination IP address/subnet and/or source IP address/subnet.

Signaling traffic

Signaling traffic originates and terminates at the Voice server.

In the upstream direction, the Voice server determines the IP next hop for the destination IP address of the packet, performs ARP for the next hop IP address and forwards the IP packet appropriately.

The local SHub is configured as the next hop for signaling packets originating at the Voice server.

The local SHub performs layer 3 forwarding in upstream and downstream direction.



Figure 8-27 Megaco ISAM Voice (routed): signaling forwarding

XLES traffic

XLES traffic originates at the Voice server or at the Voice LT board and terminates respectively at the Voice LT board or the Voice server.

• XLES traffic originating at the Voice server and destined to the Voice LT board:The destined Voice LT is connected to the local access node, to an access node subtending to the local access node or to an access node connected via a L3 aggregation network with the local access node.In the upstream direction, the Voice server determines the IP next hop for the destination IP address of the packet, performs ARP for the next hop IP address / destination IP address and forwards the IP packet appropriately.The local SHub is configured as the next hop for the XLES packets originating at the Voice server (in case the destined voice LT board connects to the local access node, the local SHub IP address is equal to the destination IP address).The (destined) SHub that connects the destined Voice LT board performs layer 3 followed by layer 4 forwarding.

• XLES traffic originating at the Voice LT board and destined to the Voice server:The Voice LT board relays the XLES packet to the local SHub.

• The access node of the Voice LT board and the access node of the Voice Server are the same:The local SHub detects that the destination IP address of the packet can directly be reached via the local subnet. The local Shub performs ARP for the destination IP address and forwards the IP packet appropriately.

• The access node of the Voice LT board subtends to the access node of the Voice Server:The local SHub determines the IP next hop for the destination IP address of the packet, performs ARP for the next hop IP address and forwards the IP packet appropriately.

• The access node of the Voice LT board is connected via a layer 3 aggregation network with the access node of the Voice Server:

Main node

NT board

SHub Voiceuser IPaddress

Voice LTboard

Voiceserver

MGC ASP

SoftSwitch

L3 forwarding

Subtending node

NT board


board

SignalingIP address

XLESIP address

Remote node

Voice LTboard

NT board

SHub networkIP address


Remote node

Voice LTboard

NT board



L3aggregation

network


SHub signalinguser IPaddress

L3 forwarding

SignalingSignaling



The local SHub determines the IP next hop for the destination IP address of the packet, performs ARP for the next hop IP address and forwards the IP packet appropriately.

The SHub that connects the Voice server performs layer 3 forwarding.

Figure 8-28 Megaco ISAM Voice - Routed: XLES packet originating at the Voice Server

Figure 8-29 Megaco ISAM Voice - Routed: XLES packet forwarding at the Voice LT board.

Voice traffic

Voice traffic originates at the Voice LT board and is destined to a voice termination at the same Voice LT board, a voice termination at another Voice LT board in the Voice cluster or a voice termination outside the voice cluster.

Main node

NT board


Voice LTboard

Voiceserver

MGC ASP

SoftSwitch

L3 forwarding

Subtending node

NT board


board

SignalingIP address

XLESIP address

Remote node

Voice LTboard

NT board



Remote node

Voice LTboard

NT board



L3aggregation

network



L3 forwarding

L4 forwarding

L4 forwarding

L4 forwarding

L3 forwarding

L3 forwarding

Main node

NT board


Voice LTboard

Voiceserver

MGC ASP

SoftSwitch

L3 forwarding

Subtending node

NT board


board

SignalingIP address

XLESIP address

Remote node

Voice LTboard

NT board



Remote node

Voice LTboard

NT board



L3aggregation

network



L3 forwarding

L3 forwarding

L3 forwarding



In some cases the voice traffic must be sent along the Voice server (as to support some supplementary services or an optimized IP addressing scheme).

From R3.7V onwards, in all cases, voice traffic is relayed to the SHub prior to the forwarding to the destined voice termination. This relay is either done by the Voice LT board (voice traffic that does not pass the Voice server) or the Voice server (voice traffic that passes the voice server).

A) Voice traffic not passing the Voice server.

• Voice traffic destined to a termination outside the voice cluster:• The voice LT board relays the upstream voice traffic to the local SHub.• The local SHub determines the IP next hop for the voice traffic destination.• The local Shub performs ARP for the next hop IP address and forwards the IP packet

appropriately.• Voice traffic destined to a voice termination connected to the same Voice LT

board in the local access node:• The Voice LT board relays the upstream voice traffic to the local SHub.• The local SHub detects that the destination of the voice traffic equals the local Voice

IP address and treats the voice traffic locally.• The local SHub performs layer 4 forwarding to the Voice LT voice from which the

voice traffic originated.• Voice traffic destined to a voice termination connected to a different Voice LT

board in the local access node:• The voice LT board relays the upstream voice traffic to the local SHub.• The local SHub detects that the destination of the voice traffic equals the local Voice

IP address and treats the voice traffic locally.• The local SHub performs layer 4 forwarding to the Voice LT board to which the

destined voice termination is connected.• Voice traffic destined to a voice termination connected to a Voice LT board in

another access node of the voice cluster:• The voice LT board relays the upstream voice traffic to the local SHub.• The local SHub determines the IP next hop for the destination of the voice traffic.

The local SHub performs ARP for the next hop IP address and forwards the voice traffic appropriately.

• The SHub that connects the destined voice termination (Voice LT board) performs layer 3 followed by layer 4 forwarding.

B) Voice traffic passing the Voice server.

• Voice traffic destined to the Voice server:• The voice LT board relays the upstream voice traffic to the local SHub.• The local SHub determines the IP next hop for the Voice server, performs ARP for

the next hop IP address and forwards the voice traffic appropriately.• In case the access node of the Voice LT board and the access node of the Voice

Server are the same, the local Shub performs ARP for the Voice server IP address and forwards the IP packet appropriately.



• Voice traffic relayed by the Voice server to a voice termination connected to a Voice LT board in the same access node:

• The Voice server invokes the NAPT facility and forwards the voice traffic along the local SHub to itself (this is a basic forwarding condition to allow the support of External packet forwarding serving Lawful Intercept).

• The Voice server detects that the destination of the voice traffic is reachable within the local subnet, performs ARP for the destination IP address and forwards the IP packet appropriately.

• The local SHub performs layer 4 forwarding to the Voice LT board that connects the Voice termination point.

• Voice traffic relayed by the Voice server to a voice termination connected to a Voice LT board in another access node of the voice cluster:

• The Voice Server determines the IP next hop for the destination of the voice traffic, performs ARP for the next hop IP address and forwards the voice traffic appropriately.

• The Voice termination is connected to an access node subtending to the local access node: The Voice server invokes the NAPT facility and forwards the voice traffic along the local SHub to itself (this is a basic forwarding condition to allow the support of External packet forwarding serving Lawful Intercept).The Voice Server detects that the destination of the voice traffic is reachable within the local subnet, performs ARP for the destination IP address and forwards the voice traffic appropriately.

• The SHub that connects the Voice termination (Voice LT board) performs layer 4 forwarding.

• Voice traffic relayed by the Voice server to a voice termination outside the voice cluster:

• The Voice Server determines the IP next hop for the destination of the voice traffic, performs ARP the next hop IP address and forwards the voice traffic appropriately.

Figure 8-30 Megaco ISAM Voice (routed): Voice packet originating at the LT board

Main node

NT board


Voice LTboard

Voiceserver

MGC ASP

SoftSwitch

Subtending node

NT board


board

SignalingIP address

XLESIP address

Remote node

Voice LTboard

NT board



Remote node

Voice LTboard

NT board



L3aggregation

network



L3 forwarding

L3 forwarding

L3 forwarding

SHub subtendedIP address

L4 forwarding

L3 forwarding

L3 forwardingL4 forwarding



Figure 8-31 Megaco ISAM Voice (routed): Voice packet originating at the Voice server

OAM traffic

The management platform of the customer forwards the Voice OAM traffic to the public OAM IP address of the ISAM access node hosting the Voice server.

Voice OAM traffic is distinguishable by a Voice specific SNMP community string/context identifier from non-Voice OAM traffic and in addition distinguishable through the same SNMP community string /context identifier amongst the Voice server pairs (maximum 8) that may be hosted in the same ISAM access node.

Internally, the voice specific OAM traffic is relayed to the Voice server.

Voice OAM responses generated by the Voice server are internally passed to the ISAM SNMP agent that forwards them to the customer's management platform.


SIP ISAM Voice as switching device

Signaling traffic

Signaling traffic originates at the Voice LT.

• Centralized SIP architecture = Single IP address:• In upstream direction: the Voice LT board forwards the signaling packet to the local

SHub. The Local SHub determines the IP next hop for the destination IP address of the packet, performs ARP for the next hop IP address and forwards the IP packet appropriately.

• In downstream direction: upon the receipt of a signaling packet, the local SHub performs layer 3 forwarding followed by layer 4 forwarding to the destined Voice LT board.

Main node

NT board


Voice LTboard

Voiceserver

MGC ASP

SoftSwitch

Subtending node

NT board


board

SignalingIP address

XLESIP address

Remote node

Voice LTboard

NT board



Remote node

Voice LTboard

NT board



L3aggregation

network



L3 forwarding

L4 forwarding

L3 forwarding

L3 forwarding

SHub subtended IP address

L3 forwarding



Figure 8-32 SIP ISAM Voice (switched, centralized): Signaling packet originating at the Voice LT/Upstream layer 3 forwarding at the SHub

Figure 8-33 SIP ISAM Voice (switched, centralized): Signaling packet destined to the Voice LT/Downstream layer 4 forwarding at the SHub

• Distributed SIP architecture = Multiple IP address:• In upstream direction: the Voice LT board determines the IP next hop for the

destination IP address of the packet and forwards the IP packet appropriately. Any potential intermediate SHub performs layer 2 forwarding.

• In downstream direction: upon the receipt of a signaling packet, the local SHub performs layer 2 forwarding to the destined Voice LT board.

Main node

Voice LTboard

Voiceserver

Remote node

L2aggregation

network

Voice LTboard

L3 forwarding

L2 forwarding

Subtending node

Voice LTboard

Remote node

Voice LTboard

L3aggregation

network

SignalingIP address

XLESIP address

IP

AS

MRF

S-CSCF

HSS IMSCore

I-CSCF

NT board


SHub signalingIP address

NT board



NT board



NT board



L3 forwarding

Main node

Voice LTboard

Remote node

L2aggregation

network

Voice LTboard

L2 forwarding

Subtending node

Voice LTboard

Remote node

Voice LTboard

L3aggregation

network

IP

AS

MRF

S-CSCF

HSS IMSCore

I-CSCF

NT board



NT board



NT board



NT board



L4 forwarding

L4 forwarding



Figure 8-34 SIP ISAM Voice (switched, distributed): Signaling packet originating at the Voice LT/Upstream layer 3 forwarding at the Voice LT

Figure 8-35 SIP ISAM Voice (switched, distributed): Signaling packet destined to the Voice LT/Downstream layer 2 forwarding at the SHub

Main node

Voice LTboard

Remote node

L2aggregation

network

Voice LTboard

L3 forwarding

L2 forwarding

Subtending node

Voice LTboard

Remote node

Voice LTboard

L3aggregation

network

IP

AS

MRF

S-CSCF

HSS IMSCore

I-CSCF

NT board

NT board NT board

NT board

L3 forwarding

SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

L2 forwarding

L2 forwarding

Main node

Voice LTboard

Remote node

L2aggregation

network

Voice LTboard

L2 forwarding

Subtending node

Voice LTboard

Remote node

Voice LTboard

L3aggregation

network

IP

AS

MRF

S-CSCF

HSS IMSCore

I-CSCF

NT board

NT board NT board

NT board

SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

L2 forwarding

L2 forwarding



Voice traffic

For both the centralized as well as the distributed architecture, the forwarding of the voice traffic in upstream as well as in downstream direction is identical as shown above for the signaling traffic.

• Voice traffic exchanged between a local and a remote voice termination:The forwarding behavior is identical to signaling traffic.

• Voice traffic exchanged between two voice termination connected to the same voice LT board:The forwarding behavior depends on the destination IP address been received from the IMS core, for example, all the voice traffic might be forced to be forwarded along a voice gateway.Should the IMS core have decided that the voice traffic may be switched internally in the access node then this voice traffic will be switched either internally on the Voice LT board or along the local Shub depending on the Voice LT board type being planned.

• Voice traffic exchanged between two voice termination connected to different voice LT boards in the same access node:The forwarding behavior depends on the destination IP address been received from the IMS core, for example, all the voice traffic might be forced to be forwarded along a voice gateway.

Anyhow, switching voice traffic between Voice Terminations, connected to the same Voice LT board, along the local SHub is only possible in the centralized SIP architecture, not in the distributed SIP architecture.

Centralized SIP architecture:


the own Voice IP address. As such the packet is treated locally.• The local SHub performs layer 4 forwarding to the Voice LT board to which the

destined voice termination point is connected (that is, the Voice LT board from which the voice packet originated).

Summarized, the SIP ISAM Voice forwards the voice traffic in accordance with the destination IP address dictated by the SIP signaling and the Voice LT board type.

The External Packet Forwarding facility serving Lawful Intercept is not supported, neither for the Distributed, nor for the Centralized SIP architecture.

OAM traffic

The management platform of the customer forwards the Voice OAM traffic to the management IP address of the ISAM access node hosting the Voice server.






SIP ISAM Voice as routing device

Security considerations

The ISAM supports only a single fast path VRF. As a result, access nodes that are deployed in mixed mode (that is, narrowband services and broadband services are concurrently deployed by the same access node) must include protections that guarantee that data is kept secret against unwanted, unintended and malicious listeners and this for both the narrowband services and the broadband services.

This can be achieved as follows:

• At the network side of the VRF, the broadband data path is separated from the narrowband data path by configuring different VLANs for these different data paths (= different IP subnets).In this respect, path protection can be guaranteed by the routing protocols (different areas).

• At the user side of the VRF, ACLs need to be installed at the ports connection the LT boards to block broadband traffic from interfering with narrowband traffic and vice versa (that is, traffic received in the broadband path is not allowed to be destined to a narrowband user and, vice versa, traffic received in the narrowband path is not allowed to be destined to a broadband user).

• The ACLs will be built upon destination IP address/subnet and/or source IP address/subnet.

Signaling traffic

Signaling traffic originates at the Voice LT.

• Centralized SIP architecture = Single IP address:• In upstream direction: the Voice LT board forwards the signaling packet to the local

SHub. The Local SHub determines the IP next hop for the destination IP address of the packet, performs ARP for the next hop IP address and forwards the IP packet appropriately.

• In downstream direction: upon the receipt of a signaling packet, the local SHub performs layer 3 forwarding followed by layer 4 forwarding to the destined Voice LT board.



Figure 8-36 SIP ISAM Voice (routed, centralized): Signaling packet originating at the Voice LT/Upstream layer 3 forwarding at the SHub

Figure 8-37 SIP ISAM Voice (routed, centralized): Signaling packet destined to the Voice LT/Downstream layer 4 forwarding at the SHub

• Distributed SIP architecture = Multiple IP address:• In upstream direction: the Voice LT board determines the IP next hop for the

destination IP address of the packet and forwards the IP packet appropriately. Any potential intermediate SHub performs layer 2 forwarding.

• In downstream direction: upon the receipt of a signaling packet, the local SHub performs layer 2 forwarding to the destined Voice LT board.

Main node

Voice LTboard

Remote node

Voice LTboard

L3 forwarding

Subtending node

Voice LTboard

Remote node

Voice LTboard

L3aggregation

network

IP

AS

MRF

S-CSCF

HSS IMSCore

I-CSCF

NT board

NT board NT board

NT board

L3 forwarding

SHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

SHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

SHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

SHub dignalingIP address


L3 forwarding

SHubsubtendingIP address

Main node

Voice LTboard

Remote node

Voice LTboard

L3 forwarding

Subtending node

Voice LTboard

Remote node

Voice LTboard

L3aggregation

network

IP

AS

MRF

S-CSCF

HSS IMSCore

I-CSCF

NT board

NT board NT board

NT boardSHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

SHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

SHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

SHub dignalingIP address


L3 forwarding


L4 forwarding



Figure 8-38 SIP ISAM Voice (routed, distributed): Signaling packet originating at the Voice LT/Upstream layer 3 forwarding at the Voice LT

Figure 8-39 SIP ISAM Voice (routed, distributed): Signaling packet destined to the Voice LT/Downstream layer 2 forwarding at the SHub

Main node

Voice LTboard

Remote node

Voice LTboard

L3 forwarding

Subtending node

Voice LTboard

Remote node

Voice LTboard

L3aggregation

network

IP

AS

MRF

S-CSCF

HSS IMSCore

I-CSCF

NT board

NT board NT board

NT board

L3 forwarding

SHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

SHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

SHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

L3 forwarding


SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

L2 forwarding

Main node

Voice LTboard

Remote node

Voice LTboard

L3 forwarding

Subtending node

Voice LTboard

Remote node

Voice LTboard

L3aggregation

network

IP

AS

MRF

S-CSCF

HSS IMSCore

I-CSCF

NT board

NT board NT board

NT boardSHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

SHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

SHub userSignaling

IP address

SHub userVoice

IP address

SHub netw.Signaling

IP address

SHub netw.Voice

IP address

L3 forwarding


SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

SignalingIP address

VoiceIP address

L2 forwarding



Voice traffic

For both the centralized as well as the distributed architecture, the forwarding of the voice traffic in upstream as well as in downstream direction is identical as shown above for the signaling traffic.

• Voice traffic exchanged between a local and a remote voice termination:The forwarding behavior is identical to signaling traffic.

• Voice traffic exchanged between two voice termination connected to the same voice LT board:The forwarding behavior depends on the destination IP address been received from the IMS core, for example, all the voice traffic might be forced to be forwarded along a voice gateway.Should the IMS core have decided that the voice traffic may be switched internally in the access node then this voice traffic will be switched either internally on the Voice LT board or along the local Shub depending on the Voice LT board type being planned.

• Voice traffic exchanged between two voice termination connected to different voice LT boards in the same access node:The forwarding behavior depends on the destination IP address been received from the IMS core, for example, all the voice traffic might be forced to be forwarded along a voice gateway.

Anyhow, switching voice traffic between Voice Terminations, connected to the same Voice LT board, along the local SHub is only possible in the centralized SIP architecture, not in the distributed SIP architecture.

Centralized SIP architecture:


the own Voice IP address. As such the packet is treated locally.• The local SHub performs layer 4 forwarding to the Voice LT board to which the

destined voice termination point is connected (that is, the Voice LT board from which the voice packet originated).

Summarized, the SIP ISAM Voice forwards the voice traffic in accordance with the destination IP address dictated by the SIP signaling and the Voice LT board type.

The External Packet Forwarding facility serving Lawful Intercept is not supported, neither for the Distributed, nor for the Centralized SIP architecture.

OAM traffic

The management platform of the customer forwards the Voice OAM traffic to the management IP address of the ISAM access node hosting the Voice server.






8.8 Layer 2/layer 3 addressing topologies

Megaco ISAM Voice as switching device

Three forwarding models can be distinguished for Megaco ISAM Voice:

• Basic layer 2/layer 3 addressing topology• IP subnet reduction• IP subnet and IP address reduction

The following is common to all three forwarding models:

• Equipment and platform management entity is hosted at the NT• Voice service Management entity is hosted at the Voice server• Media gateway is hosted at the Voice server• External communication VLAN carries the external management traffic• Public OAM IP interface is configured at the NT• External communication VLAN: see chapter “Management interface functions”• Public OAM IP address: see chapter “Management interface functions”

Basic layer 2/layer 3 addressing topology

The following applies for the basic layer 2/layer 3 addressing topology:

• A distinct VLAN is used for signaling and Voice/XLES traffic.• The public Voice IP interface is configured at the SHub.• The public signaling IP interface is configured at the Voice server.• The public XLES IP interface is configured at the Voice server.• Upstream packet forwarding:

• Signaling traffic: layer 3 forwarding at the Voice server and layer 2 forwarding at the SHub.

• Voice/XLES traffic: Voice/XLES packet internally relayed from the Voice LT to the SHub and layer 3 forwarding at the SHub.

• Downstream packet forwarding:• Signaling traffic is layer 2 forwarded at the SHub.• Voice/XLES traffic is layer 4 forwarded from the SHub to the Voice LT.

• Signaling VLAN:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the ISAM port(s) connecting the Voice server and the network port(s).The signaling VLAN terminates at the Voice server and carries the Megaco and SIGTRAN signaling traffic exchanged between the MGC (Call Server)/ ASP (Application Server Process) and the MG (ISAM Voice).



• Voice/XLES VLAN:The VLAN is of “Voice-VLAN” mode, configurable and allows layer 2 and layer 3 user-to-user communication.Ports associated with this VLAN are the ISAM port(s) connecting the Voice server, the ISAM port(s) connecting the Voice LT, subtending port(s), and network port(s).The VLAN terminates at both the Voice server and the Voice LT and carries:

• RTP traffic exchanged between end users.• RTCP traffic.• XLES traffic (internal signaling, control and management) exchanged between the

Voice server and the Voice LT.

The basic layer 2/layer 3 addressing topology is shown in the following figures:

• For a hub ISAM Voice, see Figure 8-40• For a subtending ISAM Voice, see Figure 8-41• For a remote ISAM Voice, see Figure 8-42

Figure 8-40 Basic layer 2/layer 3 addressing topology - hub ISAM Voice (switching)

IACM

NT

Voice Se rve r 1

Vo ice Se rve r N

Vo ice LT 1

Vo ice LT M

MG

MGExte rn a l OAM VLAN

SHub

SIGNALING VLAN

VOICE VLAN

In te rn a l OAM VLAN

Public O AM IP AddressPublic Signa ling IP AddressPublic Voice / XLES IP AddressPriva te O AM IP AddressPublic Voice IP Address



Figure 8-41 Basic layer 2/layer 3 addressing topology - subtending ISAM Voice (switching)

Figure 8-42 Basic layer 2/layer 3 addressing topology - remote ISAM Voice (switching)

Relying on the former layer 2 forwarding scheme, the layer 3 IP address scheme looks then as follows:

• Public signaling IP address:• Residing at the Voice server.• Single IP address shared by a redundant pair of Voice servers.• Configurable

• Public Voice IP address:• Single IP address per ISAM Voice access node.• Residing at the SHub.• Configurable

• Public XLES IP address:• Residing at the Voice server.• Shared by a redundant pair of Voice servers.• Configurable.

IACM

NT

Voice LT 1

Vo ice LT M

Exte rn a l OAM VLAN

SHub

VOICE VLAN

Public O AM IP Address

Public Voice IP Address

IACM

NT

Voice LT 1

Vo ice LT M


SHub

VOICE VLAN





IP subnet reduction

This model intends to reduce the number of IP subnets (that is, the total amount of reserved IP addresses), required for the voice service.

• A shared VLAN is used for signaling and Voice/XLES traffic.• The public Voice IP interface is configured at the SHub.• A shared public signaling/XLES IP interface is configured at the Voice server.• Upstream packet forwarding:


• Voice/XLES traffic: Voice/XLES packet internally relayed from Voice LT to SHub and layer 3 forwarding at the SHub.

• Downstream packet forwarding:• Signaling traffic is layer 2 forwarded at the SHub.• Voice/XLES traffic is layer 4 forwarded from the SHub to the Voice LT.

• Shared signaling/Voice/XLES VLAN:The VLAN is of “Voice-VLAN” mode, configurable and allows layer 2 and layer 3 user-to-user communication.Ports associated with this VLAN are the ASAM port(s) connecting the Voice server, the ISAM port(s) connecting the Voice LT, Subtending port(s) and the network port(s).The shared VLAN terminates at the Voice server and the Voice LT and carries:

• Megaco and SIGTRAN signaling traffic exchanged between the MGC (Call Server)/ ASP (Application Server Process) and the MG (ISAM Voice)

• RTP traffic exchanged between end users• RTCP traffic• XLES traffic (internal signaling, control and management) exchanged between the

Voice server and the Voice LT.

The basic layer 2/layer 3 addressing topology with IP subnet reduction is shown in the following figures:

• For a hub ISAM Voice, see Figure 8-43.• For a subtending ISAM Voice, see Figure 8-44.• For a remote ISAM Voice, see Figure 8-45.



Figure 8-43 IP subnet reduction - hub ISAM Voice (switching)

Figure 8-44 IP subnet reduction - subtending ISAM Voice (switching)

Figure 8-45 IP subnet reduction - remote ISAM Voice (switching)

Relying on the former layer 2 forwarding scheme, the layer 3 IP address scheme then looks as follows:

• Shared public signaling/XLES IP address:• Residing at the Voice server.• Single IP address shared by a redundant pair of Voice servers.• Configurable.

IACM

NT

Voice Se rve r 1

Vo ice Se rve r N

Vo ice LT 1

Vo ice LT M

MG

MGExte rn a l OAM VLAN

SHub

Shared SIGNALING/VOICE VLAN

In te rn a l OAM VLAN


Public shared Signaling/Voice/XLES IP Address

Priva te O AM IP Address


IACM

NT

Voice LT 1

Vo ice LT M


SHub


Public OAM IP Address


IACM

NT

Voice LT 1

Vo ice LT M


SHub






• Public Voice IP address:• Single IP address per ISAM Voice access node.• Residing at the SHub.• Configurable.

IP subnet and IP address reduction

This model further reduces the total amount of public IP addresses, required for the integrated voice service.

• A shared public VLAN is used for (case A) signaling/Voice/XLES or (case B) signaling/Voice traffic.

• A shared private VLAN is used for Voice/XLES traffic.• A shared public (case A) signaling/Voice/XLES or (case B) signaling/Voice IP

interface is configured at the Voice server.• A private voice IP interface is configured at the SHub.• A private XLES IP interface is configured at the Voice server. • Upstream packet forwarding in shared VLAN for signaling and Voice/XLES

traffic:• Signaling traffic: layer 3 forwarding at the Voice server and layer 2 forwarding at

the SHub.• Voice/XLES traffic for a hub ISAM Voice: layer 3 forwarding at the Voice server

and layer 2 forwarding at the SHub.• Voice/XLES traffic for a remote ISAM Voice (Figure 8-48 - CASE A):

Voice/XLES packet internally relayed from the Voice LT to the SHub and layer 3 forwarding at the SHub.

• Downstream packet forwarding in shared VLAN for signaling and Voice/XLES traffic:

• Signaling traffic: layer 2 forwarding at the SHub.• Voice/XLES traffic for a hub ISAM Voice: layer 2 forwarding at the SHub.• Voice/XLES traffic for a remote ISAM Voice (Figure 8-48 - CASE A): layer 4

forwarding from the SHub to the Voice LT.• Upstream packet forwarding in the private Voice VLAN:

Voice/XLES traffic: Voice/XLES packet internally relayed from Voice LT to the SHub and layer 3 forwarding at the SHub.

Note — For topologies that contain remote ISAM Voice access nodes, 2 options are possible:

• Case A: the remote ISAM Voice is associated with the public signaling/Voice/XLES VLAN. In this case a public voice IP interface is configured at the SHub of the remote ISAM Voice access node.

• Case B: the remote ISAM Voice is associated with the private Voice/XLES VLAN. In this case a private voice IP interface is configured at the SHub of the remote ISAM Voice access node.



• Case A: Shared public signaling/Voice/XLES VLAN:The VLAN is of “Residential Bridge” mode in the Hub ISAM Voice and of “Voice-VLAN” mode in the Remote ISAM Voice, and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice server in the Hub ISAM Voice, the ASAM port(s) connecting the voice LT boards in the remote ISAM Voice, and the network port(s).The shared VLAN terminates at the Voice server and at the Voice LT in the Remote ISAM Voice nodes. It carries:

• Megaco and SIGTRAN signaling traffic exchanged between the MGC (Call Server)/ ASP (Application Server Process) and the MG (ISAM Voice).

• RTP traffic originated from or destined to end users connected to a remote ISAM Voice node.

• RTP traffic originated from an external end user and destined to an end user connected to the hub node or subtending node.

• RTP traffic originated from an end user connected to the hub or Subtending node and destined to an external end user.

• RTCP traffic• XLES traffic (internal signaling, control and management) exchanged between the

Voice server and the Voice LT hosted in the remote ISAM Voice node.• Case B: Shared public signaling/Voice VLAN:

The VLAN is of “Residential Bridge” mode in the Hub ISAM Voice and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice server in the Hub ISAM Voice and the network port(s).The shared VLAN terminates at the Voice server. It carries:


• RTP traffic originated from an external end user and destined to an end user connected to the Hub node, Subtending node or Remote node.

• RTP traffic originated from an end user connected to the Hub, Subtending or Remote node and destined to an external end user.

• RTCP traffic.• Private Voice VLAN:

The VLAN is of “Voice-VLAN” mode, configurable and allows layer 2 and layer 3 user-to-user communication.Ports associated with this VLAN are the ISAM port(s) connecting the Voice server, the ISAM port(s) connecting the Voice LT and the subtending port(s).The private Voice VLAN terminates at the Voice server and the Voice LT and the SHub of the Hub, the Subtending (Case B) and/or Remote ISAM Voice node. It carries:

• RTP traffic originated or destined to end users connected to the hub and subtending ISAM Voice nodes.

• RTCP traffic.• XLES traffic (internal signaling, control and management) exchanged between the

Voice server and the Voice LT residing in the Hub, the Subtending (Case B) and/or the Remote ISAM Voice node.



The basic layer 2/layer 3 addressing topology with IP subnet reduction and IP address reduction is shown in the following figures:


Figure 8-46 IP subnet and IP reduction - hub ISAM Voice (switching)

Figure 8-47 IP subnet and IP reduction - subtending ISAM Voice (switching)

NT

Voice Server 1

Voice Server N

Voice LT 1

Voice LT M

MG

MGExternal OAM VLAN

Private VOICE/XLES VLAN

Shared SIGNALING/VOICE/XLES VLAN

Internal OAM VLAN

Public OAM IP AddressPrivate Voice IP AddressPublic shared Signaling/Voice /XLES IP AddressPrivate OAM IP AddressPrivate XLES IP Address

Fast-path VRF

IACM

SHub

NT

Vo ice LT 1

Vo ice LT M


Private VOICE/XLES VLAN

Public O AM IP AddressPrivate Voice IP Address



Figure 8-48 IP subnet and IP address reduction - remote ISAM Voice (switching)


• Shared public signaling/Voice/XLES IP address:• Residing at the Voice server.• Single IP address shared by a redundant pair of Voice servers.• Configurable.

• Public Voice IP address (for remote ISAM Voice node):• Single IP address per ISAM Voice access node.• Residing at the SHub.• Configurable.

• Private Voice IP address (for hub ISAM Voice node and subtending ISAM Voice node):

• Single IP address per ISAM Voice access node.• Residing at the SHub.• Configurable.

• Private XLES IP address (for hub ISAM Voice node):• Residing at the Voice server.• Shared by a redundant pair of Voice servers.• Configurable.

IACM

NT

Voice LT 1

Vo ice LT M


SHub

Shared SIGNALLING/VOICE VLAN

Public OAM IP AddressPublic Voice IP Address

Vo ice server N

IACM

NT

Voice LT 1

Vo ice LT M


SHub



Vo ice server N

CASE A

CASE B



Megaco ISAM Voice as routing device

Three forwarding models can be distinguished for Megaco ISAM Voice as routing device:

• Basic layer 2/layer 3 addressing topology• IP subnet reduction• IP subnet and IP address reduction

The following is common to all three forwarding models:

• Equipment and platform management entity is hosted at the NT• Voice service Management entity is hosted at the Voice server• Media gateway is hosted at the Voice server• External communication VLAN carries the external management traffic• Public OAM IP interface is configured at the NT• External communication VLAN: see chapter “Management interface functions”• Public OAM IP address: see chapter “Management interface functions”

Basic layer 3 addressing topology

The following applies for the basic layer 3 addressing topology:

• Distinct user side VLANs for signaling traffic and for Voice/XLES traffic are configured at the user side of the fast path VRF.

• Distinct network side VLANs for signaling traffic and for Voice/XLES traffic are configured at the network side of the fast path VRF.

• A distinct user side subtending VLAN for Voice/XLES traffic exchanged with the subtending ISAM Voice is configured at the user side of the fast path VRF.

• The public Voice IP interface is configured at the user side of the fast path VRF at the SHub.

• The public signaling IP interface is configured at the Voice server.• The public XLES IP interface is configured at the Voice server.• A user-side next hop IP interface is configured on top of the user side signaling

VLAN at the user side of the fast path VRF.• A network-side next hop IP interface is configured on top of both the

network-side signaling VLAN and the network-side Voice/XLES VLAN at the network side of the fast path VRF.

• A user-side next hop IP interface is configured on top of the user side subtending VLAN at the user side of the fats path VRF.

• Upstream packet forwarding:• Signaling traffic and XLES traffic originating at the Voice server: layer 3

forwarding at the Voice server and layer 3 forwarding at the SHub.• Voice traffic and XLES traffic originating at the Voice LT board: the Voice/XLES

packet is internally relayed from the Voice LT board to the SHub and layer 3 forwarding at the SHub.

• Voice traffic and XLES traffic originating at the subtending interface: layer 3 forwarding at the SHub.



• Downstream packet forwarding:• Signaling traffic and XLES traffic destined to the Voice server: layer 3 forwarded at

the SHub.• Voice traffic and XLES traffic destined to the Voice LT: layer 3 followed by layer

4 forwarded from the SHub to the Voice LT board.• Voice traffic and XLES traffic destined to the subtending interface: layer 3

forwarded at the SHub.• Signaling VLAN at the user side of the fast path VRF:

The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice server(s).The signaling VLAN terminates at the SHub/Voice server and carries the Megaco and SIGTRAN signaling traffic exchanged between the MGC (Call Server)/ ASP (Application Server Process) and the MG (ISAM Voice).

• Voice/XLES VLAN at the user side of the fast path VRF:The VLAN is of “Voice-VLAN” mode, configurable and allows layer 3 user-to-user communication.Ports associated with this VLAN are the ASAM port(s) connecting the Voice server and the ASAM port(s) connecting the Voice LT board.The VLAN terminates at the SHub and both, the Voice server and the Voice LT board and carries:

• RTP traffic exchanged between end users.• RTCP traffic.• XLES traffic (internal signaling, control and management) exchanged between the

Voice server and the Voice LT board).• Subtending Voice/XLES VLAN at the user side of the fast path VRF:

The VLAN is of “iBridge” mode and configurablePorts associated with this VLAN are the subtending port(s).The VLAN terminates at the SHub and the Voice LT board(s) connecting to the subtending ISAM Voice and carries:

• RTP traffic exchanged between end users• RTCP traffic• XLES traffic exchanged between the Voice server and the subtending Voice LT

board(s)

The basic layer 3 addressing topology is shown in the following figures:

• For a hub ISAM Voice, see Figure 8-49• For a subtending ISAM Voice, see Figure 8-50• For a remote ISAM Voice, see Figure 8-51



Figure 8-49 Basic layer 2/layer 3 addressing topology - hub ISAM Voice (routing)

Figure 8-50 Basic layer 2/layer 3 addressing topology - subtending ISAM Voice (routing)

NT

Voice Server 1

Voice Server N

Voice LT 1

Voice LT M

MG

MGExternal OAM VLAN

SIGNALING VLAN

VOICE VLAN

Internal OAM VLAN

Public OAM IP addressPublic Signaling IP addressPublic Voice /XLES IP addressPrivate OAM IP address

Fast-path VRFNetwork VLANNetwork VLAN

Network VLANNetwork VLAN

SubtendingVLAN

Public Voice IP addressNetwork IP addressUser IP addressSubtending IP address

NT

Voice LT 1

Voice LT M

External OAM VLAN

Subtending VLAN

Public OAM IP address

Public Voice IP address

Fast-path VRF



Figure 8-51 Basic layer 2/layer 3 addressing topology - remote ISAM Voice (routing)

The layer 3 IP address scheme looks then as follows:

• Public signaling IP address:• Residing at the Voice server.• Single IP address shared by a redundant pair of Voice servers.• Configurable

• Public Voice IP address:• Single IP address per ISAM Voice access node configured at the user side of the fast

path VRF.• Residing at the SHub.• Configurable

• Public XLES IP address:• Residing at the Voice server.• Shared by a redundant pair of Voice servers.• Configurable.

• Signaling path:• User-side next hop IP address configured at the user side of the fast path VRF

(SHub)• Network-side next hop IP address configured at the network side of the fast path

VRF (SHub)• Voice / XLES path:

Network-side next hop IP address configured at the network side of the fast path VRF (SHub)

• User-side next hop IP address configured at the user side of the fast path VRF (SHub) for the subtending link.

IP subnet reduction

This model intends to reduce the number of IP subnets (that is, the total amount of reserved IP addresses), required for the voice service.

• The same user-side VLAN is shared by signaling and Voice/XLES traffic and configured at the user side of the fast path VRF.

NT

Voice LT 1

Voice LT M

External OAM VLAN

VOICE VLAN




Network IP address



• The same network-side VLAN is shared by signaling and Voice/XLES traffic and configured at the network side of the fast path VRF.

• The public Voice IP interface is configured at the user side of the fast path VRF at the SHub.

• A shared public signaling/XLES IP interface is configured at the Voice server.• A distinct-user side subtending VLAN for Voice/XLES traffic exchanged with

the subtending ISAM Voice is configured at the user side of the fast path VRF.• A network-side next hop IP interface is configured on top of the network side

signaling/ Voice/XLES VLAN at the network side of the fast path VRF.• A user-side next hop IP interface is configured on top of the user-side subtending

VLAN at the user side of the fast path VRF.• Upstream packet forwarding:


• Voice/XLES traffic originating at the Voice LT: Voice/XLES packet internally relayed from Voice LT board to SHub and layer 3 forwarding at the SHub.

• Voice/XLES traffic originating at the subtending interface: layer 3 forwarding at the SHub.

• Downstream packet forwarding:• Signaling traffic and XLES traffic destined to the Voice server: layer 3 forwarded at

the SHub.• Voice traffic and XLES traffic destined to the Voice LT: layer 3 followed by layer

4 forwarded from the SHub to the Voice LT board.• Voice traffic and XLES traffic destined to the subtending interface: layer 3

forwarded at the SHub.• Shared signaling/Voice/XLES VLAN at the user side of the fast path VRF:

The VLAN is of “Voice-VLAN” mode, configurable and allows layer 3 user-to-user communication.Ports associated with this VLAN are the ASAM port(s) connecting the Voice server and the ISAM port(s) connecting the Voice LT.The shared VLAN terminates at the SHub/Voice server and the Voice LT board and carries:

• Megaco and SIGTRAN signaling traffic exchanged between the MGC (Call Server)/ ASP (Application Server Process) and the MG (ISAM Voice)

• RTP traffic exchanged between end users• RTCP traffic• XLES traffic (internal signaling, control and management) exchanged between the

Voice server and the Voice LT.• Subtending Voice/XLES VLAN at the user side of the fast path VRF:

The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the subtending port(s).The VLAN terminates at the SHub and the Voice LT board(s) connecting to the subtending ISAM Voice and carries:

• RTP traffic exchanged between end users• RTCP traffic• XLES traffic exchanged between the Voice server and the subtending Voice LT

board(s)



The basic layer 3 addressing topology with IP subnet reduction is shown in the following figures:


Figure 8-52 IP subnet reduction - hub ISAM Voice (routing)

Figure 8-53 IP subnet reduction - subtending ISAM Voice (routing)

NT

Voice Server 1

Voice Server N

Voice LT 1

Voice LT M

MG

MGExternal OAM VLAN


Internal OAM VLAN


Public shared Signaling/Voice/XLESIP Address

Private OAM IP Address



SubtendingVLAN

Network IP address

Subtending IP address

NT

Voice LT 1

Voice LT M

External OAM VLAN

VOICE VLANVOICE VLAN



Fast-path VRF



Figure 8-54 IP subnet reduction - remote ISAM Voice (routing)

The layer 3 IP address scheme then looks as follows:

• Shared public signaling/XLES IP address:• Residing at the Voice server.• Single IP address shared by a redundant pair of Voice servers.• Configurable.

• Public Voice IP address:• Single IP address per ISAM Voice access node at the user side of the fast path VRF

at the SHub.• Residing at the SHub.• Configurable.

• Signaling/Voice path:• Network-side next hop IP address configured at the network side of the fast path

VRF (SHub• User-side next hop IP address configured at the user side of the fast path VRF

(SHub) for the subtending link.

IP subnet and IP address reduction

This model further reduces the total amount of public IP addresses, required for the integrated voice service.

• A single public VLAN shared by signaling/Voice/XLES is configured at the user side of the fast path VRF

• A private VLAN for Voice/XLES traffic is configured at the user side of the fast path VRF (Applies to the HUB and subtending ISAM Voice only)

• A network side VLAN shared by signaling/Voice/XLES is configured at the network side of the fast path VRF.

• A single public IP interface shared by signaling/Voice/XLES IP interface is configured at the Voice server.

• A private voice IP interface is configured at the user side of the fast path VRF at the SHub.

• A private XLES IP interface is configured at the Voice server. • A distinct user side private subtending VLAN for Voice/XLES traffic exchanged

with the subtending ISAM Voice is configured at the user side of the fast path VRF.

• A network side Next hop IP interface is configured on top of the network side signaling/ Voice/XLES VLAN at the network side of the fast path VRF.

NT

Voice LT 1

Voice LT M

External OAM VLAN

VOICE VLAN




Network IP address



• A user side Next hop IP interface is configured on top of the user side signaling/Voice/XLES VLAN at the user side of the fast path VRF.

• A user side Next hop IP interface is configured on top of the user side subtending VLAN at the user side of the fats path VRF.

• Upstream packet forwarding in shared VLAN for signaling/Voice/XLES traffic:• Signaling traffic and XLES traffic + Voice traffic originating at the Voice server:

layer 3 forwarding at the Voice server and layer 3 forwarding at the SHub.• Voice traffic and XLES traffic originating at the Remote ISAM Voice: Voice/XLES

packet is internally relayed from the Voice LT board to the SHub and layer 3 forwarding at the SHub.

• Downstream packet forwarding in shared VLAN for signaling/Voice/XLES traffic

• Signaling traffic and XLES traffic + Voice traffic destined to the Voice server: layer 3 forwarding at the SHub.

• Voice traffic and XLES traffic destined to the Voice LT board (Remote ISAM Voice): layer 3 followed by layer 4 forwarding from the SHub to the Voice LT board.

• Upstream packet forwarding in the private Voice VLAN (HUB / Subtending ISAM Voice only):Voice traffic and XLES traffic originating at the voice LT board: Voice/XLES packet is internally relayed from Voice LT board to the SHub and layer 3 forwarding at the SHub.

• Downstream packet forwarding in the private Voice VLAN (HUB / Subtending ISAm Voice only):Voice traffic and XLES traffic destined to the voice LT: layer 3 followed by layer 4 forwarding from the SHub to the Voice LT board.

• Shared public signaling/Voice/XLES VLAN at the user side of the fast path VRF:The VLAN is of “Residential Bridge” mode in the Hub ISAM Voice and of “Voice-VLAN” mode in the remote ISAM Voice, and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice server in the Hub ISAM Voice and the ASAM port(s) connecting the voice LT board boards in the remote ISAM Voice.The shared VLAN terminates at the SHUB / Voice server and at the Voice LT board in the Remote ISAM Voice nodes. It carries:


• RTP traffic originated from or destined to end users connected to a remote ISAM Voice node.

• RTP traffic originated from an external end user and destined to an end user connected to the hub node or subtending node.

• RTP traffic originated from an end user connected to the hub or Subtending node and destined to an external end user.


Voice server and the Voice LT board hosted in the remote ISAM Voice node. • Private Voice VLAN:

The VLAN is of “Voice-VLAN” mode, configurable and allows layer 3 user-to-user communication.Ports associated with this VLAN are the ASAM port(s) connecting the Voice server and the ASAM port(s) connecting the Voice LT.



The private Voice VLAN terminates at the SHUB, Voice server and the Voice LT. It carries:

• RTP traffic originated or destined to end users connected to the Hub, Subtending (Case B:) and/or Remote ISAM Voice nodes.


Voice server and the Voice LT board residing in the Hub, the Subtending (Case B) and/or the Remote ISAM Voice node.

• Subtending Voice/XLES VLAN at the user side of the fast path VRF:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the subtending port(s).The VLAN terminates at the SHub and the Voice LT board(s) connecting to the subtending ISAM Voice and carries:

• RTP traffic exchanged between end users• RTCP traffic• XLES traffic exchanged between the Voice server and the subtending Voice LT(s)

The basic layer 2/layer 3 addressing topology with IP subnet reduction and IP address reduction is shown in the following figures:


Figure 8-55 IP subnet and IP reduction - hub ISAM Voice (routing)

NT

Voice Server 1

Voice Server N

Voice LT 1

Voice LT M

MG

MGExternal OAM VLAN

Private VOICE VLAN


Internal OAM VLAN

Public OAM IP AddressPrivate Voice IP AddressPublic shared Signaling/XLES IP AddressPrivate OAM IP Address

Private XLES IP Address


SubtendingVLAN

User IP addressSubtending IP address

Network IP address



Figure 8-56 IP subnet and IP reduction - subtending ISAM Voice (routing)

Figure 8-57 IP subnet and IP address reduction - remote ISAM Voice (routing)


• Shared public signaling/Voice/XLES IP address:• Residing at the Voice server.• Single IP address shared by a redundant pair of Voice servers.• Configurable.

• Public Voice IP address (for remote ISAM Voice node):• Single IP address per ISAM Voice access node configured at the user side of the fast

path VRF.• Residing at the SHub.• Configurable.

• Private Voice IP address (for hub ISAM Voice node and subtending ISAM Voice node):

• Single IP address per ISAM Voice access node configured at the user side of the fast path VRF.

• Residing at the SHub.• Configurable.

• Private XLES IP address (for hub ISAM Voice node):• Residing at the Voice server.• Shared by a redundant pair of Voice servers.• Configurable.

• Public Signaling / Voice path:

Fast-path VRF

NT

Voice LT 1

Voice LT M

External OAM VLAN

Private VOICE VLAN

Public OAM IP AddressPrivate Voice IP Address

Fast-path VRF

NT

Voice LT 1

Voice LT M

External OAM VLAN



Voice server N


Network IP address



Network-side next hop IP address configured at the network side of the fast path VRF (HUB and Remote SHub).User-side next hop IP address configured at the user side of the fast path VRF (HUB SHub).

• User-side next hop IP address configured at the user side of the fast path VRF (SHub) for the subtending link.

SIP ISAM Voice as switching device

Four addressing topologies are supported:

• Distributed IP address topology - shared signaling/Voice IP address.• Distributed IP address topology - distinct signaling/Voice IP address.• Centralized IP address topology - distinct signaling/Voice IP address.• Centralized IP address topology - shared signaling/Voice IP address.

The following is common to all four addressing models:

• Equipment, platform and integrated voice service management entity is hosted at the NT.

• A SIP UA instance is hosted at the Voice LT.• The external communication VLAN carries the external management traffic.• The public OAM IP interface is configured at the NT.• External communication VLAN: see chapter “Management interface functions”.• Public OAM IP address: see chapter “Management interface functions”.

Distributed IP address topology - shared signaling/Voice IP address

• A single VLAN shared by signaling traffic and by Voice traffic is configured at the SHub.

• A single source/destination IP interface shared by signaling traffic and by Voice traffic is configured at the voice LT board.

• Upstream packet forwarding:• Layer 3 forwarding of signaling/Voice packet at the Voice LT board.• Layer 2 forwarding of signaling/Voice packet at the SHub.• Layer 2 forwarding of signaling/Voice packet from subtending to network side.

• Downstream packet forwarding:• Layer 2 forwarding of signaling/Voice packet at the SHub.• Layer 2 forwarding of signaling/Voice packet from subtending to network side.



• Shared signaling/Voice VLAN:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the ISAM port(s) connecting the Voice LT and the network port(s).The shared signaling/Voice VLAN terminates at the Voice LT and carries:

• SIP signaling traffic exchanged between the SIP server and the SIP UA (ISAM Voice).

• RTP traffic exchanged between end-users.• RTCP traffic.

Figure 8-58 shows the layer 3 addressing topology for this model.

Figure 8-58 Distributed IP address topology (switching): shared signaling/voice IP address


• Signaling/Voice IP interface:• Configurable at the Voice LT.• Multiple IP address per ISAM Voice access node.

Distributed IP address topology - distinct signaling/Voice IP address

• Distinct VLANs are configured for signaling traffic and for Voice traffic at the SHub.

• Distinct IP interfaces for signaling traffic and for Voice traffic are configured at the Voice LT board.


• Downstream packet forwarding:• Layer 2 forwarding of signaling/Voice packet at the SHub.• Layer 2 forwarding of signaling/Voice packet from subtending to network side.

Fast-path VRF

NT

Voice LT 1

Voice LT K

Voice LT L

Voice LT X

SIP UA

OAM VLAN


OAM IP AddressShared signaling/Voice IP Address

SIP UA

SIP UA

SIP UA

Subtendingnode



• Signaling VLAN:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT, the network port(s) and the subtending port(s).The signaling VLAN terminates at the Voice LT board and carries the SIP signaling traffic exchanged between the SIP server and the SIP User Agent (ISAM Voice).

• Voice VLAN:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT, the network port(s) and the subtending port(s).The Voice VLAN terminates at the Voice LT and carries the RTP traffic exchanged between end users and RTCP traffic.

Figure 8-59 shows the layer 2/layer 3 addressing topology for this model.

Figure 8-59 Distributed IP address topology (switching): distinct signaling/voice IP address


• signaling IP interface:• Configurable at the Voice LT board.• Multiple IP address per ISAM Voice access node.

• Voice IP address:• Configurable at the Voice LT board.• Multiple IP address per ISAM Voice access node.

Fast-path VRF

NT

Voice LT 1

Voice LT K

Voice LT L

Voice LT X

SIP UA

External OAM VLAN

VOICE VLAN


Public Signaling IP Address

SIP UA

SIP UA

SIP UA

SIGNALING VLAN


Subtendingnode



Centralized IP topology - distinct signaling/Voice IP address

• Distinct VLANs are configured for signaling traffic and for Voice traffic at the SHub.

• Distinct source/destination IP interfaces for signaling traffic and for Voice traffic are configured at the Voice LT board.

• Upstream packet forwarding:• Signaling/Voice packet is internally relayed from Voice LT board to SHub• Layer 3 forwarding of signaling/Voice packet at the SHub.• Layer 2 forwarding of signaling/Voice packet from subtending to network side.

• Downstream packet forwarding:• Layer 4 forwarding of signaling/Voice packet from the SHub to the Voice LT board.• Layer 2 forwarding of signaling/Voice packet from network to subtending side.

• Signaling VLAN:The VLAN is of “Voice-VLAN” mode and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT, the network port(s) and the subtending port(s).The signaling VLAN terminates at the Voice LT board and carries the SIP signaling traffic exchanged between the SIP server and the SIP User Agent (ISAM Voice).

• Voice VLAN:The VLAN is of “Voice-VLAN” mode and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT, the network port(s) and the subtending port(s).The Voice VLAN terminates at the Voice LT and carries the RTP traffic exchanged between end users and RTCP traffic.


Figure 8-60 Centralized IP address topology (switching): distinct signaling/voice IP address

Fast-path VRF

NT

Voice LT 1

Voice LT K

Voice LT L

Voice LT X

SIP UA

External OAM VLAN

VOICE VLAN


Public Signaling IP Address

SIP UA

SIP UA

SIP UA

SIGNALING VLAN

Public Voice IP Address Subtendingnode




• Public signaling IP address:• Configurable at the SHub.• Shared by a redundant pair of NTs/SHubs.• Single IP address per ISAM Voice access node.

• Public Voice IP address:• Configurable at the SHub.• Shared by a redundant pair of NTs/SHubs.• Single IP address per ISAM Voice access node.

Centralized IP address topology - shared signaling/Voice IP address

• A single VLAN shared by signaling traffic and by Voice traffic is configured at the SHub.



• Downstream packet forwarding:• Layer 4 forwarding of signaling/Voice packet from the SHub to the Voice LT board.• Layer 2 forwarding of signaling/Voice packet from network to subtending side.

• Shared signaling/Voice VLAN:The VLAN is of “Voice-VLAN” mode and configurable.Ports associated with this VLAN are the ISAM port(s) connecting the Voice LT, the network port(s) and the subtending port(s).The signaling/Voice VLAN terminates at the Voice LT board and carries:






Figure 8-61 Centralized IP address topology (switching): shared signaling/voice IP address


• Shared signaling/Voice IP interface:• Configurable at the SHub.• Shared by a redundant pair of SHubs.• Single IP interface per ISAM Voice access node.

SIP ISAM Voice as routing device

Four addressing topologies are supported:

• Distributed IP address topology - shared signaling/Voice IP address.• Distributed IP address topology - distinct signaling/Voice IP address.• Centralized IP address topology - distinct signaling/Voice IP address.• Centralized IP address topology - shared signaling/Voice IP address.

The following is common to all four addressing models:

• Equipment, platform and integrated voice service management entity is hosted at the NT.

• A SIP UA instance is hosted at the Voice LT.• The external communication VLAN carries the external management traffic.• The public OAM IP interface is configured at the NT.• External communication VLAN: see chapter “Management interface functions”.• Public OAM IP address: see chapter “Management interface functions”.• Different VLANs at the network side and at the user side of the fast path VRF.

Fast-path VRF

NT

Voice LT 1

Voice LT K

Voice LT L

Voice LT X

SIP UA

External OAM VLAN

OAM IP Address

Shared Signaling/Voice IP Address

SIP UA

SIP UA

SIP UA


Subtendingnode



Distributed IP address topology - shared signaling/Voice IP address

• A single VLAN shared by signaling traffic and by Voice traffic is configured at the user side of the fast path VRF.

• A single VLAN shared by signaling traffic and by Voice traffic is configured at the network side of the fast path VRF.


• A single subtending VLAN shared by signaling traffic and by Voice traffic is configured at the user side of the fast path VRF.

• A next hop IP interface is configured on top of the signaling/voice VLAN at the user side of the fast path VRF.

• A next hop IP interface is configured on top of the signaling/voice VLAN at the network side of the fast path VRF.

• A next hop IP interface is configured on top of the subtending VLAN at the user side of the fast path VRF.


• Downstream packet forwarding:• Layer 3 forwarding of signaling/Voice packet at the SHub.• Layer 3 forwarding of signaling/Voice packet from network to subtending side.

• Signaling/Voice VLAN at the user side of the fast path VRF:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the ISAM port(s) connecting the Voice LT.The signaling/Voice VLAN terminates at the Voice LT and carries:



• Subtending signaling/Voice VLAN at the user side of the fast path VRF:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the subtending port(s).The user-side signaling/Voice VLAN terminates at the Voice LT(s) connected to the subtending ISAM Voice and carries:



Figure 8-62 shows the layer 3 addressing topology for this model.



Figure 8-62 Distributed IP address topology (routing): shared signaling/voice IP address


• Signaling/Voice IP interface:• Configurable at the Voice LT.• Multiple IP address per ISAM Voice access node.

• User-side signaling/voice VLAN: next-hop IP interface configured at the user side of the fast path VRF (SHub)

• Network-side signaling/voice VLAN: next-hop IP interface configured at the network side of the fast path VRF (SHub)

• User-side subtending signaling/voice VLAN: next-hop IP interface configured at the user side of the fast path VRF (SHub)

Distributed IP address topology - distinct signaling/Voice IP address

• Distinct VLANs are configured for signaling traffic and for Voice traffic at the user side of the fast path VRF.

• Distinct VLANs are configured for signaling traffic and for Voice traffic at the network side of the fast path VRF.

• Distinct IP interfaces for signaling traffic and for Voice traffic are configured at the Voice LT board.

• Distinct subtending VLANs for signaling traffic and for Voice traffic are configured at the user side of the fast path VRF.

• A next hop IP interface is configured on top of the signaling VLAN at the user side of the fast path VRF.

• A next hop IP interface is configured on top of the voice VLAN at the user side of the fast path VRF.

• A next hop IP interface is configured on top of the signaling VLAN at the network side of the fast path VRF.

• A next hop IP interface is configured on top of the voice VLAN at the network side of the fast path VRF.

• A next hop IP interface is configured on top of the subtending signaling VLAN at the user side of the fast path VRF.

Fast-path VRF

NT

Voice LT 1

Voice LT K

Voice LT L

Voice LT X

SIP UA

OAM VLAN



SIP UA

SIP UA

SIP UA

Subtendingnode


Network IP addressUser IP addressSubtending IP address




• A next hop IP interface is configured on top of the subtending voice VLAN at the user side of the fast path VRF.


• Downstream packet forwarding:• Layer 3 forwarding of signaling/Voice packet at the SHub.• Layer 3 forwarding of signaling/Voice packet from network to subtending side.

• Signaling VLAN at the user side of the fast path VRF:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT.The signaling VLAN terminates at the Voice LT board and carries the SIP signaling traffic exchanged between the SIP server and the SIP User Agent (ISAM Voice).

• Voice VLAN at the user side of the fast path VRF:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT.The Voice VLAN terminates at the Voice LT and carries the:

• RTP traffic exchanged between end users• RTCP traffic.

• Subtending VLAN for signaling and voice at the user side of the fast path VRF:These VLANs are of “iBridge” mode and configurable.Ports associated with this VLAN are the subtending port(s).The subtending signaling/Voice VLAN terminates at the Voice LT(s) connected to the subtending ISAM Voice and carries:

• SIP signaling traffic exchanged between the SIP server and the SIP User Agent (ISAM Voice).





Figure 8-63 Distributed IP address topology (routing): distinct signaling/voice IP address


• Signaling IP interface:• Configurable at the Voice LT board.• Multiple IP address per ISAM Voice access node.

• Voice IP address:• Configurable at the Voice LT board.• Multiple IP address per ISAM Voice access node.

• User-side signaling VLAN and user-side Voice VLAN: next-hop IP interface configured at the user side of the fast path VRF (SHub).

• Network-side signaling VLAN and network-side Voice VLAN: next-hop IP interface configured at the network side of the fast path VRF (SHub).

• User-side subtending signaling VLAN and user-side subtending voice VLAN: next-hop IP interface configured at the user side of the fast path VRF (SHub).

Centralized IP topology - distinct signaling/Voice IP address

• Distinct VLANs for signaling traffic and for Voice traffic at the user side of the fast path VRF.

• Distinct VLANs for signaling traffic and for Voice traffic at the network side of the fast path VRF.

• Distinct source/destination IP interfaces for signaling traffic and for Voice traffic at the user side of the VRF at the SHub.

• Distinct subtending VLANs for signaling traffic and for Voice traffic are configured at the user side of the fast path VRF.

Fast-path VRF

NT

Voice LT 1

Voice LT K

Voice LT L

Voice LT X

SIP UA

External OAM VLAN

VOICE VLAN

OAM IP Address

User IP Address

SIP UA

SIP UA

SIP UA

SIGNALING VLAN

User IP Address

Subtendingnode



Network IP Address

Subtending IP Address


Signalling IP Address

Voice IP Address



• A next hop IP interface is configured on top of the signaling VLAN at the network side of the fast path VRF.

• A next hop IP interface is configured on top of the voice VLAN at the network side of the fast path VRF.

• A next hop IP interface is configured on top of the subtending signaling VLAN at the user side of the fast path VRF.

• A next hop IP interface is configured on top of the subtending voice VLAN at the user side of the fast path VRF.


• Downstream packet forwarding:• Layer 3 followed by layer 4 forwarding of signaling/Voice packet from the SHub to

the Voice LT board.• Layer 3 forwarding of signaling/Voice packet from network to subtending side.

• Signaling VLAN:The VLAN is of “Voice-VLAN” mode and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT.The signaling VLAN terminates at the Voice LT board and carries the SIP signaling traffic exchanged between the SIP server and the SIP User Agent (ISAM Voice).

• Voice VLAN:The VLAN is of “Voice-VLAN” mode and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT.The Voice VLAN terminates at the Voice LT and carries:


• Subtending VLANs for signaling and Voice at the user side of the fast path VRF:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the subtending port(s).The Voice VLAN terminates at the Voice LT board connected to the subtending ISAM Voice and carries:

• SIP signaling traffic exchanged between the SIP server and the SIP UA (ISAM Voice)


Figure 8-64 shows the topology for this model.



Figure 8-64 Centralized IP address topology (routing): distinct signaling/voice IP address


• Signaling IP address:• Configurable at the SHub (user-side fast path VRF).• Shared by a redundant pair of SHubs.• Single IP address per ISAM Voice access node.

• Public Voice IP address:• Configurable at the SHub.• Shared by a redundant pair of NTs/SHubs.• Single IP address per ISAM Voice access node.

• Network-side signaling VLAN and network-side Voice VLAN: next-hop IP interface configured at the network side of the fast path VRF (SHub).

• User-side subtending signaling VLAN and user-side subtending voice VLAN: next-hop IP interface configured at the user side of the fast path VRF (SHub).

Centralized IP address topology - shared signaling/Voice IP address

• A single VLAN shared by signaling traffic and by Voice traffic is configured at the user side of the fast path VRF.

• A single VLAN shared by signaling traffic and by Voice traffic is configured at the network side of the fast path VRF.

• A single source/destination IP interface shared by signaling traffic and by Voice traffic is configured at the user side of the fast path VRF.

• A single subtending VLAN shared by signaling traffic and by Voice traffic is configured at the user side of the fast path VRF.

Fast-path VRF

NT

Voice LT 1

Voice LT K

Voice LT L

Voice LT X

SIP UA

External OAM VLAN

VOICE VLAN

OAM IP Address

Signaling IP Address

SIP UA

SIP UA

SIP UA

SIGNALING VLAN

Voice IP Address

Subtendingnode



Network IP Address





• A next hop IP interface is configured on top of the signaling/voice VLAN at the network side of the fast path VRF.

• A next hop IP interface is configured on top of the subtending VLAN at the user side of the fast path VRF.

• Upstream packet forwarding:• Signaling/Voice packet is internally relayed from Voice LT to SHub.• Layer 3 forwarding of signaling/Voice packet at the SHub.• Layer 3 forwarding of signaling/Voice packet from subtending to network side.

• Downstream packet forwarding:• Layer 3 followed by layer 4 forwarding of signaling/Voice packet from the SHub to

the Voice LT board.• Layer 3 forwarding of signaling/Voice packet from network to subtending side.

• Signaling/Voice VLAN at the user side of the fast path VRF:The VLAN is of “Voice-VLAN” mode and configurable.Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT.The signaling/Voice VLAN terminates at the Voice LT and carries:



• Subtending signaling/Voice VLAN at the user side of the fast path VRF:The VLAN is of “iBridge” mode and configurable.Ports associated with this VLAN are the subtending port(s).The subtending signaling/Voice VLAN terminates at the Voice LT(s) connected to the subtending ISAM Voice and carries:



Figure 8-65 shows the addressing topology for this model.



Figure 8-65 Centralized IP address topology (routing): shared signaling/voice IP address


• Shared signaling/Voice IP interface:• Configurable at the SHub (user side fast path VRF).• Shared by a redundant pair of NTs/SHubs.• Single IP interface per ISAM Voice access node.

• Network-side VLAN sharing signaling traffic and voice traffic: next-hop IP interface configured at the network side of the fast path VRF (SHub).

• User-side subtending VLAN sharing signaling traffic and voice traffic: next-hop IP interface configured at the user side of the fast path VRF (SHub).

Fast-path VRF

NT

Voice LT 1

Voice LT K

Voice LT L

Voice LT X

SIP UA

OAM VLAN



SIP UA

SIP UA

SIP UA

Subtendingnode


Network IP addressUser IP addressSubtending IP address




8.9 Protocol stacks

Megaco ISAM Voice as switching/routing device

Both POTS and ISDN BRI lines are supported.

Signaling protocol stack

H.248 and SIGTRAN signaling packets are exchanged between the MG (Voice server) and the MGC (Call Server). The XLES proprietary protocol is used to exchange internal signaling packets between the Voice server and the Voice LT boards residing in the hub, subtending or remote ISAM Voice access nodes.

H.248 and XLES signaling packets are encapsulated with UDP, IP and layer 2 frames. SIGTRAN signaling packets are encapsulated with SCTP, IP and layer 2 frames. The layer 2 frames are formatted according to Ethernet II format (that is, using the type field) and VLAN 802.1Q tagged including priority setting according to IEEE 802.1p.

H.248, SIGTRAN and XLES signaling packets include configured DSCP and .1P values.

Figure 8-66 shows the H.248 signaling protocol stack for a POTS termination connected directly to the hub ISAM Voice. The Z interface is terminated at the Voice LT. User events like hook off, hook on and so on are converted into XLES/LAPV5 packets which are sent to the Voice server. The Voice server in turn converts the internal proprietary XLES/LAPV5 protocol into Megaco messages sent to the MGC.

Figure 8-66 POTS signaling protocol stack - hub ISAM Voice (switching)

XLES

LapV5

UDP

IP

802.1Q

802.3

Voice LT Voice Server SHub EMAN Edge Router

L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf

XLES

LapV5

UDP

IP

802.1Q

802.3

H.248

UDP

IP

802.1Q

802.3

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

H.248

UDP

GenericPHY

IP



Figure 8-67 POTS signaling protocol stack - hub ISAM Voice (routing)

For POTS terminations connected to a remote or subtending ISAM Voice, the Z interface is terminated at the Voice LT residing at the remote or subtending ISAM Voice. Information transfer between the remote or subtending ISAM Voice and the hub ISAM Voice happens through the proprietary XLES/LAPV5 protocol that is terminated at the Voice server. The Voice server in turn converts the internal proprietary XLES/LAPV5 protocol into Megaco messages sent to the MGC.

Figure 8-68 POTS signaling protocol stack - subtending ISAM Voice (switching)

Figure 8-69 POTS signaling protocol stack - subtending ISAM Voice (routing)

Figure 8-70 POTS signaling protocol stack - remote ISAM Voice (switching)

XLES

LapV5

UDP

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf

XLES

LapV5

UDP

IP

802.1Q

802.3

H.248

UDP

IP

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

H.248

UDP

GenericPHY

IP

802.1Q

802.3

IP

Voice Server SHub EMAN Edge Router

L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

H.248

UDP

IP

802.1Q

802.3

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

H.248

UDP

GenericPHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

Voice LT SHub

Subtending ISAM Voice

Z Itf802.1Q

802.3

SHub

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

H.248

UDP

IP

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

H.248

UDP

GenericPHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

Voice LT SHub


Z Itf802.1Q

802.3

SHub

IP

802.1Q

802.3

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

H.248

UDP

IP

802.1Q

802.3

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

H.248

UDP

GenericPHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

Voice LT SHub

Remote ISAM Voice

Z Itf802.1Q

802.3

SHub

802.1Q

802.3

EMAN

802.1Q

802.3



Figure 8-71 POTS signaling protocol stack - remote ISAM Voice (routing)

For ISDN BRI terminations, the Voice server behaves as the signaling Gateway (SG). It communicates with the ASP through the SIGTRAN protocol. The D-channel layer 2 protocol (Q.921) is terminated at the Voice LT. The D-channel layer 3 protocol (Q.931) is fully transparent to the Voice server. Q.931 is encapsulated with SIGTRAN and fully transparently forwarded to the ASP.

The ISAM Voice still acts as the MG for the call control in calls involving B-channels.

Figure 8-72 ISDN BRI signaling protocol stack - hub ISAM Voice (switching)

Figure 8-73 ISDN BRI signaling protocol stack - hub ISAM Voice (routing)

For ISDN BRI Terminations connected to a remote or subtending ISAM Voice, the D-channel layer 2 protocol (Q.921) is terminated at the Voice LT residing at the remote or subtending ISAM Voice. Information transfer between the remote or subtending ISAM Voice and the hub ISAM Voice happens through the proprietary XLES/LAPV5 protocol that is terminated at the Voice server. The Voice server in turn converts the internal proprietary XLES/LAPV5 protocol into SIGTRAN messages sent to the ASP.


L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

H.248

UDP

IP

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

H.248

UDP

GenericPHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

Voice LT SHub

Remote ISAM Voice

Z Itf

SHubEMAN

802.1Q

802.3

IP

802.1Q

802.3

IP

802.1Q

802.3

IP

802.1Q

802.3

XLES

LapV5

UDP

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

GenericPHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

IUA

SCTP

IP

802.1Q

802.3

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

I410

Q921

I410

Q921

Q931 Q931

IUA

SCTP

IP

802.1Q

802.3

XLES

LapV5

UDP

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

GenericPHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

IUA

SCTP

IP

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

I410

Q921

I410

Q921

Q931 Q931

IUA

SCTP

IP

802.1Q

802.3

802.1Q

802.3

IP



Figure 8-74 ISDN BRI signaling protocol stack - subtending ISAM Voice (switching)

Figure 8-75 ISDN BRI signaling protocol stack - subtending ISAM Voice (routing)

Figure 8-76 ISDN BRI signaling protocol stack - remote ISAM Voice (switching)

Figure 8-77 ISDN BRI signaling protocol stack - remote ISAM Voice (routing)


L3

MGC

Hub ISAM Voice

Termination

GenericPHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

H.248

UDP

IP

802.1Q

802.3

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

XLES

LapV5

UDP

IP

802.1Q

802.3

Voice LT SHub


802.1Q

802.3

SHub

802.1Q

802.3

I410

Q921

Q931 Q931

IUA

SCTP

IP

802.1Q

802.3

I410

Q921


L3

MGC

Hub ISAM Voice

Termination

GenericPHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

H.248

UDP

IP

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

XLES

LapV5

UDP

IP

802.1Q

802.3

Voice LT SHub


802.1Q

802.3

SHub

I410

Q921

Q931 Q931

IUA

SCTP

IP

802.1Q

802.3

I410

Q921

IP

802.1Q

802.3

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

GenericPHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

H.248

UDP

IP

802.1Q

802.3

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

XLES

LapV5

UDP

IP

802.1Q

802.3

Voice LT SHub

Remote ISAM Voice

802.1Q

802.3

SHub

802.1Q

802.3

EMAN

802.1Q

802.3

I410

Q921

Q931 Q931

IUA

SCTP

IP

802.1Q

802.3

I410

Q921


L3

MGC

Hub ISAM Voice

Termination

GenericPHY

IP

XLES

LapV5

UDP

IP

802.1Q

802.3

H.248

UDP

IP

802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

XLES

LapV5

UDP

IP

802.1Q

802.3

Voice LT SHub

Remote ISAM Voice

SHubEMAN

802.1Q

802.3

I410

Q921

Q931 Q931

IUA

SCTP

IP

802.1Q

802.3

I410

Q921

IP

802.1Q

802.3

IP

802.1Q

802.3

IP

802.1Q

802.3



Voice protocol stack

Voice traffic, using Real-Time Protocol (RTP) providing the information needed to restore the original digital voice stream, is encapsulated in UDP/IP. The same encapsulation method is applied to Real-Time Control Protocol (RTCP), the control protocol associated to RTP.

The encapsulated voice traffic (RTP/RTCP) includes a configurable DSCP and .1P bit value. As a result the voice packets can use separate queues in the layer 2/layer 3 network to minimize delay and jitter.

Figure 8-78 Voice protocol stack - upstream (switching)

Figure 8-79 Voice protocol stack - upstream (routing)

Figure 8-80 Voice protocol stack - downstream (switching)

RTP

UDP

IP

802.1Q

802.3

Voice LT SHub EMAN Edge Router

L3

TGW

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

UDP

GenericPHY

IP

RTP

IP

802.1Q

802.3

RTP

UDP

IP

802.1Q

802.3


L3

TGW

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

UDP

GenericPHY

IP

RTP

IP

802.1Q

802.3

RTP

UDP

IP

802.1Q

802.3


L3

TGW

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

UDP

GenericPHY

IP

RTP

UDP

IP

802.1Q

802.3



Figure 8-81 Voice protocol stack - downstream (routing)

SIP ISAM Voice as switching/routing device

Only POTS lines are supported.

Signaling protocol stack

SIP signaling packets are exchanged between the Voice gateway and the SIP server.

All signaling packets are encapsulated with UDP, IP and layer 2 frames. The layer 2 frames are formatted according to Ethernet II format (that is, using the type field) and VLAN 802.1Q tagged including priority setting according to IEEE 802.1p.

SIP signaling packets will include configured DSCP and .1P values.

Figure 8-82, Figure 8-83, Figure 8-84, Figure 8-85, Figure 8-86 and Figure 8-87 show the SIP signaling protocol stack for a POTS termination for the different architectures. The Z interface is terminated at the Voice LT board. User events like hook off, hook on, and so on are converted into SIP messages sent to the SIP server.

Figure 8-82 POTS signaling protocol stack - distributed architecture (switching)

RTP

UDP

IP

802.1Q

802.3


L3

TGW

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

UDP

GenericPHY

IP

RTP

802.1Q

802.3

IP

UDP

IP

802.1Q

802.3


L3

TGW

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

802.1Q

802.3

IP

802.1Q

802.3

GenericPHY

IP

UDP

SIP

UDP

SIP

IP

802.1Q

802.3



Figure 8-83 POTS signaling protocol stack - distributed architecture (routing)

Figure 8-84 POTS signaling protocol stack - centralized architecture - upstream (switching)

Figure 8-85 POTS signaling protocol stack - centralized architecture - upstream (routing)

Figure 8-86 POTS signaling protocol stack - centralized architecture - downstream (switching)


L3

TGW

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

GenericPHY

IP

UDP

SIP

UDP

SIP

IP

802.1Q

802.3

802.1Q

802.3

IP


L3

TGW

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

GenericPHY

IP

UDP

SIP

UDP

SIP

IP

802.1Q

802.3

IP

802.1Q

802.3


L3

TGW

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

GenericPHY

IP

UDP

SIP

UDP

SIP

IP

802.1Q

802.3

802.1Q

802.3

IP


L3

TGW

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

GenericPHY

IP

UDP

SIP

UDP

SIP

IP

802.1Q

802.3

IP

802.1Q

802.3

UDP



Figure 8-87 POTS signaling protocol stack - centralized architecture - downstream (routing)

Voice protocol stack

Voice traffic, using RTP providing the information needed to restore the original digital voice stream, is encapsulated in UDP/IP. The same encapsulation method is applied to RTCP, the control protocol associated to RTP.

The encapsulated voice traffic (RTP/RTCP) includes a configurable DSCP and .1P bit value. As a result the voice packets can use separate queues in the layer 2/layer 3 network to minimize delay and jitter.

Figure 8-88 Voice protocol stack - distributed architecture (switching)

Figure 8-89 Voice protocol stack - distributed architecture (routing)


L3

TGW

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

GenericPHY

IP

UDP

SIP

UDP

SIP

IP

802.1Q

802.3

IP

802.1Q

802.3

UDP

IP

802.1Q

802.3

RTP

UDP

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

UDP

GenericPHY

IP

RTP

802.1Q

802.3

RTP

UDP

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

UDP

GenericPHY

IP

RTP

IP

802.1Q

802.3



Figure 8-90 Voice protocol stack - centralized architecture - upstream (switching)

Figure 8-91 Voice protocol stack - centralized architecture - upstream (routing)

Figure 8-92 Voice protocol stack - centralized architecture - downstream (switching)

Figure 8-93 Voice protocol stack - centralized architecture - downstream (routing)

RTP

UDP

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

UDP

GenericPHY

IP

RTP

IP

802.1Q

802.3

RTP

UDP

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

UDP

GenericPHY

IP

RTP

IP

802.1Q

802.3

RTP

UDP

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

UDP

GenericPHY

IP

RTP

IP

802.1Q

802.3

UDP

RTP

UDP

IP

802.1Q

802.3


L3

MGC

Hub ISAM Voice

Termination

Z ItfGeneric

PHY

IP

Z Itf802.1Q

802.3

IP

802.1Q

802.3

UDP

GenericPHY

IP

RTP

IP

802.1Q

802.3

UDP

IP

802.1Q

802.3



8.10 Management interface

General

Internally, the ISAM Voice supports three management entities:

• Intelligent Access termination, Control and Management (IACM) entity.• SHub management entity.• Voice server.

With the focus on the ISAM Voice, being an access node with integrated voice service, the following management responsibilities are assigned to the different management entities:

• In a Megaco ISAM Voice access node:• The IACM entity deals with equipment, platform and system control.• The SHub management entity deals with central switching control.• The Voice server deals with voice service control.

• In a SIP ISAM Voice access node:• The IACM entity deals with equipment, platform, system and voice service control.• The SHub management entity deals with the central switching control.

The ISAM Voice supports SNMPv3. A single public OAM IP address per access node is used to address all management entities (the IACM, the SHub and the Voice server management entity). The public OAM IP address resides at the NT and its value can immediately be configured through manual command input. Another valid configuration option is to let the OAM IP address be retrieved by means of the BOOTP protocol. The OAM IP address is shared by both NTs of the redundant pair.

Management of the ISAM is in-band, within a configurable external-OAM VLAN (default value is 4093).

The external communication VLAN terminates at the NT and carries the OAM traffic exchanged between the external management platform and the IACM management entity. The external communication VLAN is of iBridge mode and configurable (although by default allocated with VLAN ID 4093). Ports associated with this VLAN are the NT port(s), subtending port(s) and the network port(s).

The SHub and Voice server management entity can be addressed through the use of dedicated context names. The internal communication VLAN allows the NT to relay the specific management commands for SHub or Voice service to the SHub/Voice server.

Local management of the ISAM requires the operator to use the serial interface on the IACM. Via this interface he can manage all ISAM functionality, IACM, SHub, and Voice server, using CLI.

Note — The SHub has dedicated CLI commands.



The IACM part (including SIP) can be fully managed using TL1.

Figure 8-94 illustrates the management architecture.

Figure 8-94 Management architecture

The CLI agent on the IACM must support parsing for the complete CLI interface for support of auto-completion and the help function for the complete CLI functionality. The CLI agent will parse the complete command line with auto-completion. Once the line has been completed, the CLI agent will either execute the command itself or dispatch it to the SHub. Therefore the dispatcher will have to know the complete command tree of the SHub.

Note — The SHub can also be partly managed via the IACM TL1 that supports:

• Flow-through provisioning of VLANs and VLAN-ports on SHub• Alarm reporting and alarm report/threshold configuration on

SHub• Collection of PM statistics from SHub• Multicast control in SHub.

Note — Local and remote CT interface (serial interface) with command line interface is supported at the NT.

Local and remote CT interface is NOT supported at the Voice server.

SNMP

Mapper

Application code

TL1

SNMP

Mapper

Application code

IACM

SHub

ISAM

SNMP for ISAM SNMP for ShubTL1 for IACM

CLI

CLI for ISAM

1…8 Voice Server pairs

SNMP

Mapper

Application code

Voice Server

CLI forSAM VoiceMEGACO

SNMP forISAM VoiceMEGACO

SNMP forISAM Voice

SIP

TL1 for ISAM Voice

SIP

CLI for ISAM Voice

SIP

CLI for Shub



Megaco ISAM Voice

The SNMP agent that resides on the Voice server supports the management interface of the voice service. However, neither CLI nor SNMP commands can directly be addressed to the voice server. These commands must be addressed to the IACM CLI and SNMP agent.

For completeness, voice service alarms can be retrieved through the IACM TL1agent. However the usage of TL1 in the Megaco ISAM Voice is restricted to this single purpose only.

For the purpose of the relay function that is to be preformed by the IACM SNMP agent, each voice server owns a “voice server context name”. This context name is configurable in SNMP but fixed in CLI.

The Voice server context name corresponds to a private IP address assigned to each of the Voice servers. This IP address mapping is fixed and based on the physical slot ID of the voice server. It is an IP address from the private IP address range 127.0.0.11 to 127.0.0.26.

Relay of SNMP commands from the IACM SNMP agent to the Voice server happens in the internal Communication VLAN (4094).

SNMP commands, carrying a “voice server context name”, are addressed to the IACM SNMP agent which in turn relays the command to the destined Voice server based on the included context name.

CLI commands, carrying a “voice server identifier”, are addressed to the IACM CLI agent. The CLI agent translates the CLI command into the appropriate SNMP commands, which are relayed by the IACM SNMP agent to the destined Voice server SNMP Agent based on the included context name.

Batch configuration CLI command support for POTS subscriber management

In Megaco terminology, Voice subscribers are called “terminations”. A termination is a logical entity on a MG that sources and/or sinks media and/or control streams.

A termination is described by a number of characterizing properties, which are grouped in a set of descriptors that are included in commands. Terminations have unique identities, called “TerminationIDs” assigned by the MG at the time of their creation.

The ISAM Voice allows to make use of 2 different formats for the “terminationID”:

the flat-termination-id:

• Consists of a prefix and a termination ID, Format = 'prefix<tidXXXXX>'• Prefix: the prefix can be configured as uppercase or lower case character string

with a maximum length of 10 characters.



• <tidXXXXX>: • Maximum length of the termination ID = 5 numeric digits.• The configured format defines the MINIMUM length to be generated for the

termination ID (might require leading zeroes). However, it does not limit the maximum value of the termination ID itself.

• The termination ID can be defined as fixed length or variable length termination ID. Fixed length termination ID may imply the insertion of leading zeroes.

• Examples: AL0, AL1, AL54, AL004, AL0008, AL00055• Termination ID value range can start from value “0” or from value “1” (Value

range start value cannot be derived from the format definition; it is received through the provisioned termination id value.)

• POTS: a flat value in the range [0…32767] • ISDN BRI: a flat value in the range [0…8175]

the hierarchical-termination-id:

• Legacy mode: typical format: “Prefix/Dslam_Id/rack/shelf/slot/port(/channel)”Maximum length of the full hierarchical termination id string equals 72 bytes.

• The keywords must appear in a pre-defined order: Dslam_Id, rack, shelf, slot, port, channel.

• The delimiter is mandatory between the pre-defined keywords while optional between the prefix and the subsequent keyword.

• The delimiter character is fixed to “/”.• The delimiter character is copied to the generated termination ID.• Key-words: Dslam_Id (optional), rack (optional), shelf (mandatory), slot

(mandatory), port (mandatory) and channel (mandatory for ISDN-BRI only).- Dslam_id: integer (1..255).- Rack: char (1); value range '1' - '7'. - Shelf: char (2); value range ' 01' - '04'. - Slot: char (2); The applicable value range will depend on the configured Slot ID

numbering scheme. - Port: char(3); value range '001' - '072'. - Channel: char (2); value range '00' - '99'.

• All keywords, leading zeroes are to be included where needed.• Prefix: char (8), optional delimiter not included.



• Improved mode: typical format:“Prefix/Dslam_Id/rackXXXXX/shelfXXXXX/slotXXXXX/portXXXXX/channel”

• Maximum length of the full hierarchical termination id string equals 128 bytes.• Key-words: Dslam_Id (optional), rack (optional), shelf (mandatory), slot

(mandatory), port (mandatory) and channel (mandatory for ISDN-BRI only). • The sequence of the key-words as shown in the typical format string must be

respected.• A key-word can only occur once in the hierarchical termination id character string.• Key-word delimiter is optional.• “/” is defined as the default delimiter• Delimiter can be any valid character or character string not overlapping with the

start character (string) of any of the key-words.• The delimiter is copied to the generated termination ID.• Each key-word can be followed by a number of numeric digits with the maximum

number of digits = 5.• The number of digits and the value of the digits configured in the format string

define the MINIMUM number of digits to be generated (might require leading zeroes) and the value to start from, “0” or “1”.

• The value following the key-word can start from value “0” or from value “1”. Wildcard (*) is supported.

• The real value of the hierarchical termination id will autonomously be generated by the system based on the configured hierarchical termination id format string.

• Example:(1) ALshelf001/slot001port00000 whereby the shelf value range shall start from value “1” with max value 999, the slot value range shall start from value “1” with max value 999, while the port value range shall start from value “0” with max value 99999.(2) AL/Dslam_Id/shelf000slot000port00000 whereby the shelf value range shall start from value “0” with max value 999, the slot value range shall start from value “0” with max value 999, the port value range shall start from value “0” with max value 99999.

From a management interface perspective, should an operator decide to make use of the flat-termination-id format, then such flat termination id is to be configured for each of the terminations.

Otherwise, should the hierarchical-termination-id format be used then the hierarchical termination syntax is to be configured once and the system will autonomously create the appropriate hierarchical termination id for each of the terminations. However, in addition, also the flat termination id is to be configured for each of the terminations for internal ISAM Voice purposes only.

The management input for the flat termination ID can be given in 2 different ways:

• By entering a single “create” command per termination and dictating the value for the Flat Termination ID parameter per individual voice subscriber.

• By entering a batch “create” command for a series of voice subscribers (typically within the limits of a voice LT board). In this case, the operator doesn't specify a value for the Flat termination ID parameter. As a result the system will autonomously create the terminations for a voice LT board and assigns the value



of the Flat Termination ID, starting from one or previously successfully completed “create” command. and increment it by one for every subsequent termination being created.

Provisioning of MID field (H.248 packets)

ISAM Voice supports the provisioning of the Media Gateway IP Address, Media Gateway FQDN or Media Gateway Device Name to be used as Message identifier (MID) in H.248 signaling packets. Besides this, ISAM Voice supports the addition of the Port Number should either FQDN or IP address be used as MID.

The ISAM-Voice allows to provision the MID in accordance to the following provided options:

• “ipv4”: the media Gateway IP Address is used as the MG MID.• “ipv4-port”: the media Gateway IP Address together with the media Gateway

UDP Port is used as the MG mid.• “domain-name”: the media Gateway Fully Qualified Domain Name (FQDN) is

used as the MG MID.• “domain-name-port”: the media Gateway FQDN together with the media

Gateway UDP Port is used as the MG MID.• “device-name”: the media Gateway Name is used as the MG MID

The provisioning of the MG FQDN does only result in using this FQDN as MID in H.248 messages, it will for sure not be used as a trigger to perform DNS look-up for retrieving the media Gateway IP address. The latter IP address I still to be manually provisioned.

SIP-ISAM Voice

The Integrated Voice Service Management interface is fully supported by the SNMP and CLI agents that reside on the NT.

8.11 Permanent data storage

Megaco ISAM VoiceVoice permanent data is stored at the system disk. The system maintains a separate voice database for each of the Voice Servers.

The voice database is managed by the integrated voice service management entity hosted at the Voice Server. At regular time, each Voice Server uploads its voice database to the system disk.

SIP ISAM VoiceVoice permanent data is stored at the system disk. A single voice database is stored at the system disk. The voice database is managed by integrated voice service management entity hosted at the NT board.



8.12 Management model

Megaco ISAM VoiceFigure 8-95 shows the Megaco ISAM Voice conceptual management model.

Figure 8-95 Megaco ISAM Voice Conceptual Management Model

EquipmentBoard

EquipmentNode0..18 1

EquipmentTerminatio

n

1

0..n

POTSLine

ISDNLine

Voice Server

InternalSignalling

H248 VoiceDatabase1

11

0..32

0..10..1

1 1

POTSLT

ISDNLT

MediaGateway

Term IdSyntax

1 1

0..72 0..24 1

0..1

0..5000

1

MediaGateway

1

0..1

VoiceLT

Board

NT

1 1

1CDE profile

1..8

1POTSCDE profile

1

1ISDNCDE profile

1

1Voice ServerCDE profile

1..n1..n

1

1

1..n

VoiceServer

LTSession

LT testParam

LT LineId

LTLineIdExtReport

111

11

1..n

1..n

1..n



The Megaco ISAM Voice management model includes the following classes:

• The classes “NT”, “VoiceServer”, “VoiceLT” and “Board” reflect the Network Termination, respectively the Voice Server and Voice Line Termination HW being involved in the integrated voice service. These classes are not further elaborated in subsequent chapters.

• The classes “PotsLT” and “IsdnLT” are instantiations of the class “Voice LT”. The class “VoiceLT” will be further elaborated in subsequent chapters.

• The classes “PotsLine” and “IsdnLine” are instantiations of the class “EquipmentTermination”. The class “EquipmentTermination” will be elaborated in subsequent chapters.

Voice Cluster management

A Voice Cluster is the aggregation of the ISAM network elements and Voice LT boards controlled by a single Voice Server.

The class “EquipmentNode” includes the attributes and methods that allow defining and managing the ISAM network elements that are associated with the voice cluster controlled by a particular Voice Server.

The class “EquipmentBoard” includes the attributes and methods that allow defining and managing the voice LT boards that are associated with the voice cluster controlled by a particular Voice Server.

The methods that have been defined for both classes are “Creation”, “Destroy” and “Retrieve”.

Voice Network management

The class “MediaGateway” includes the attributes and methods that allow defining and managing:

• Media Gateway interface with primary and secondary Media Gateway Controller.

• Quality of Service properties of the signaling and voice flows.

The class “Signalinggateway” includes the attributes and methods that allow defining and managing the Signaling Gateway interface with primary and secondary Application Server Process.

The methods that have been defined for both classes are “Creation”, “Destroy”, “Modification” and “Retrieve”.

Note — For method “Modification” please refer to “In-service/out-of-service modification”.



Voice Subscriber management

The class “EquipmentTermination” includes the attributes and methods that allow defining and managing the POTS / ISDN subscribers associated with a Voice Server, including the ability to overrule the QOS properties of the voice flow defined in the class “MediaGateway”, should a particular subscriber require an exception.

The methods been defined for both classes are “Creation”, “Destroy”, “Modification” and “Retrieve”.

Voice Cluster Internal Signaling management

The class “InternalSignaling” includes the attributes and methods that allow defining and managing the internal signaling (XLES communication) properties of the voice cluster.

The methods been defined for this class are “Modification” and “Retrieve”.

Voice Database management

The class “VoiceDatabase” includes the attributes and methods that allow managing the Voice Database. In particular, it allows (by manual trigger) saving the actual configuration settings of the Voice Database at the Voice Server to the system disk.

The methods that have been defined for this class are “Modification” and “Retrieve”.

Termination ID Syntax management

The class “TermIdSyntax” includes the attributes and methods that allow defining and managing the termination ID syntax properties at the Voice Server.

Both, the flat termination-id format and the hierarchical termination-id format are allowed.

When selecting the flat termination-id format, the H.248 termination ID equals the termination ID created in class “EquipmentTermination”.

Otherwise, when selecting the hierarchical termination-id format, the H.248 termination ID is autonomously generated by the system based the hierarchical termination ID syntax. (The termination ID created in class “EquipmentTermination” is then for internal usage only.)






The Termination ID syntax is configured as a character string composed of a number of pre-defined keywords and operator defined characters.

For a more detailed description, see section “Megaco ISAM Voice”.

Both for POTS subscribers and for ISDN subscribers, the “Termination-id” must be unique network-wide.


Voice CDE Profile management

The class “CDEProfile” includes the attributes and methods that allow defining and managing the CDE profile for both the Voice Server and the voice LT.


Narrowband Line Testing management

The class “LtSession” includes the attributes and methods that allow defining and managing a narrowband line test session.

The class “LtLineId” includes the attributes and methods that allow defining and managing the subscriber lines involved in a narrowband line test session.

The class “LtTestParam” includes the attributes and methods that allow defining and managing the parameters being considered in the course of a narrowband line test session.

The class “ltReport” trap event during line test.

The class “LtLineIdExtReport” includes the attributes and methods that allow retrieving the results of the completed narrowband line test session.

The methods that have been defined for this class are “Modification” (first three classes only) and “Retrieve”.

In-service/out-of-service modification

The method “modification” includes 2 different functions: the “In-service-modification” and the “Out-of-service-modification”.






With the “in-service-modification” function, the system allows to modify the values of attributes of a previously created object whilst that object remains in service.

With the “Out-of-service-modification” function, the system allows to modify values of attributes of a previously created object on the condition that object has been put out-of-service.

An attribute is modifiable either by means of “in-service-modification” or by means of “out-of-service-modification” (these are mutual exclusive functions).

Usually, an “out-of-service-modification” function involves three steps to be executed:

• Putting the previously created object out-of-service by changing the administrative state of that object to “down”.

• Modify the value of one or multiple attributes of the object.• Putting the object in-service by changing the administrative state of that object to

“up”.

The first step usually causes de-registration of the voice subscribers associated with the object. The third step will then result in re-registration of the same voice subscribers. The latter step might also invoke a reset of the Voice Server.

Below a more detailed view is given on the applicability of the “in-service” and “out-of-service” modification for the different Voice classes:

• Class “EquipmentNode”: Neither “in-service-modification” nor “out-of-service-modification” apply.A modification of the attributes of a previously created object can only be done by destroying the existing object and a re-creation of the same object with different attribute values.All associated “EquipmentTermination” objects will immediately become de-registered.

• Class “EquipmentBoard”: Neither “in-service-modification” nor “out-of-service-modification” apply.A modification of the attributes of a previously created object can only be done by destroying the existing object and a re-creation of the same object with different attribute values.All associated “EquipmentTermination” objects will immediately become de-registered.

• Class “MediaGateway”: Both “in-service-modification” and “out-of-service-modification” apply.For the “out-of-service-modification”, the above described three-steps approach is to be followed.All associated “EquipmentTermination” objects will immediately become de-registered.

• Class “SignalingGateway”: Both “in-service-modification” and “out-of-service-modification” apply.For the “out-of-service-modification”, the above described three-steps approach is to be followed.All associated “EquipmentTermination” objects will immediately become de-registered.



• Class “EquipmentTermination”: Both “in-service-modification” and “out-of-service-modification” apply.For the “out-of-service-modification”, the above described three-steps approach is to be followed.The involved “EquipmentTermination” object will immediately become de-registered.

• Class “InternalSignaling”: Neither “in-service-modification” nor “out-of-service-modification” apply.All associated “EquipmentTermination” objects will immediately become de-registered.

• Class “VoiceDatabase”: “in-service-modification” applies.• Class “TermIdSyntax”: The “out-of-service-modification” applies.

The involved “EquipmentTermination” object will immediately become de-registered.

• Class “CDEProfile”: “in-service-modification” applies.• Class “LtSession”: “in-service-modification” applies.• Class “LtLineId”: “in-service-modification” applies.• Class “LtTestParam”: Only “in-service-modification” applies.• Class “LtLineIdExtReport”: Neither “in-service-modification” nor

“out-of-service-modification” apply.



SIP ISAM VoiceFigure 8-96 shows the SIP ISAM Voice conceptual management model.

Figure 8-96 SIP ISAM Voice Conceptual Management Model

Digit Map

Dial Plan

0…256

1

System Objects

LineId Syntax Profile

Sip Server

SIP Timers

System Stats

Line StatsCurrent 15m

Line StatsRecent 15m

Line StatsCurrent 1d

Line StatsRecent 1d

Call StatsRecent 15m

CPU stats

ResourceStats

Termination

POTSLine

POTSLT

1

0..1

n

1

VoiceLT

Board

NT

VSP0..n1

User Agent

User AgentAccess Point

1

0..1

1

1..18

1 1

96

1

3

0..n

1

1

1

NT

1

1

CDE profile

1

ThresholdCrossing Alarm

1

1Service profile

1

1..n1POTS

CDE profile 1

1..n

1..n0..n

SIP Voice Database

1

1

1.

NT

Line TestSession

1

0..8

1Number ofLt Sessions

1

1 1

11

11..n

Available LtSession ID

Line TestParameters

Line TestLine ID

1

Line TestReport

1..n



The SIP ISAM Voice management model includes the following classes:

• The classes “NT”, “VoiceLT” and “Board” reflect the Network Termination, respectively the Voice Server and Voice Line Termination HW being involved in the integrated voice service. These classes are not further elaborated in subsequent chapters.

• The class “PotsLT” is an instantiation of the class “Voice LT”. The class “VoiceLT” will be further elaborated in subsequent chapters.

• The class “PotsLine” is an instantiation of the class “SipTermination”. The class “SipTermination” will be elaborated in subsequent chapters.

• The class “POTS CDE Profile” is an instantiation of the class “CDE Profile”. The class “CDE Profile” will be elaborated in subsequent chapters.

Voice Network management

The class “SipSysObjects” includes the attributes and methods that allow defining and managing the properties of the Sip Session Timer facility. The methods that have been defined for this class are “Modification” and “Retrieve”.

The class “SipServer” includes the attributes and methods that allow defining and managing the set of SIP servers used by the SIP based integrated voice service. Actually, only one SIP server can be used for the SIP server roles “Proxy-server” and “Registrar”. The methods that have been defined for this class are “Creation”, “Destroy”, “Modification” and “Retrieve”.

The class “SipVsp” includes the attributes and methods that allow defining and managing the properties of the Voice Service provider. Actually only one Voice service provider is supported. This object is auto-created by the system. The methods that have been defined for this class are “Modification” and “Retrieve”.

The class “SIP Timers” includes the attributes and methods that allow defining and managing the timers applicable to the user Agent. The methods that have been defined for this calls are “Modification” and “Retrieve”.

The class “SipUserAgent” includes the attributes and methods that allow defining and managing:

• Access Gateway layer 3 addressing scheme.• Access Gateway interface with the Proxy/Registrar server.• Quality of Service properties of the signaling and voice flows.

The ISAM-Voice access node supports a single SIP User Agent as the properties of the “SipUserAgent” class are assumed to be associated with the Access provider, not the Voice Service provider. The methods that have been defined for this class are “Creation”, “Destroy”, “Modification” and “Retrieve”.

Note — Neither the modification of the SIP architecture mode (centralized, distributed) nor the modification of the configuration mode (manual, DHCP) is allowed. The modification of these properties is only allowed through a “destroy” and “creation” procedure. However a “User Agent” instance can only be destroyed on the condition that all the associated “termination” instances were destroyed before.



The class “SipUserAgentAccessPoint” includes the attributes and methods that allow defining and managing:

• The physical mapping properties for each of the SIP User Agent access points created in the ISAM Voice access node.

• The layer 3 properties of the addressing scheme defined in the “SipUserAgent” class.

Although from a logical perspective (and as formerly described), the ISAM Voice supports only one SIP User Agent, should the system be configured to behave as a distributed SIP model, then the system autonomously creates a SIP User Agent Access Point object per voice LT being planned. Otherwise, in case the system has been configured to behave as a centralized SIP model then the system autonomously creates a single SIP User Agent Access Point object (with as value the NT slot ID) that is shared by all voice LT boards. The methods that have been defined for this class are “Modification” and “Retrieve”.

The class “DialPlan” includes the attributes and methods that allow defining and managing the dial plan that applies to the voice subscribers. Actually, the same dial plan must be shared by all voice subscribers.The methods that have been defined for this class are “Creation”, “Destroy”, “Modification” and “Retrieve”.

The class “DigitMap” includes the attributes and methods that allow defining and managing the Digit Map that applies to the voice subscribers.The methods that have been defined for this class are “Creation”, “Destroy”, “Modification” and “Retrieve”.

Voice Subscriber management

The class “SipTermination” includes the attributes and methods that allow defining and managing POTS subscribers associated with the local SIP User Agent.

The methods that have been defined for this class are “Creation”, “Destroy”, “Modification” and “Retrieve”.

Note — For all classes: regarding the method “Modification”, see section “In-service/out-of-service modification”

Note — The SIP Digest Register Password is encrypted (not visible in display command).




Voice Performance Monitoring Management

The class “Threshold Crossing Alarm” includes the attributes and methods that allow defining and managing the threshold crossing alarms on a per subscriber line. The methods that have been defined for this class are “Modification” and “Retrieve”.

The class “Line Stats Current 15m” includes the attributes and methods that allow displaying the current 15-minutes register results of the per-subscriber-line performance monitoring. The method that has been defined for this class is “Retrieve”.

The class “Line Stats Recent 15m” includes the attributes and methods that allow displaying the recent 15-minutes registers results of the per-subscriber-line performance monitoring. The system defines a maximum of 96 15-minutes per-line recent registers per subscriber line. The method that has been defined for this class is “Retrieve”.

The class “Line Stats Current 1d” includes the attributes and methods that allow displaying the current 1-day register results of the per-subscriber-line performance monitoring. The method that has been defined for this class is “Retrieve”.

The class “Line Stats Recent 1d” includes the attributes and methods that allow displaying the recent 1-day registers results of the per-subscriber-line performance monitoring. The system defines a maximum of three 1-day recent registers per subscriber line. The method that has been defined for this class is “Retrieve”.

The class “Call Stats Recent 15m” includes the attributes and methods that allow displaying the recent 15-minutes registers results of the per-call & per-subscriber-line performance monitoring. The system defines a maximum of 96 per-call recent registers per subscriber line. The method that has been defined for this class is “Retrieve”.

The class “CPU Stats” includes the attributes and methods that allow displaying the actual CPU load figures per voice LT. The method that has been defined for this class is “Retrieve”.

The class “Resource Stats” includes the attributes and methods that allow displaying the actual memory resource allocation per voice LT. The method that has been defined for this class is “Retrieve”.

The class “System Stats” includes the attributes and methods that allow displaying the actual state of the subscriber line occupancy and service availability. The method that has been defined for this class is “Retrieve”.

SIP Voice Database management

The class “SIP Voice Database” includes the attributes and methods that allow managing the SIP Voice Database.

Termination ID Syntax management

The class “LineIdSyntaxProfile” includes the attributes and methods that allow defining and managing the termination ID syntax for POTS terminations.



The Termination ID syntax (“userInfo” part of the SIP URI) is configured as a character string composed of a number of pre-defined keywords and operator defined characters. The pre-defined keywords are separated by the operator defined characters.

The system supports pre-defined key-words for: Channel, Port, ShPrt, Slot, ShSlt, Shelf, Rack, ACCESS_NODE_ID. The difference here between Port/ShPrt, Slot/ShSlt is the former keywords express leading zero and the latter express non-leading zero.

The methods that have been defined for this class are “Creation”, “Destroy”, “Modification” and “Retrieve”.

CDE profile management

The class “CDEProfile” includes the attributes and methods that allow defining and managing the CDE profile for both the Voice Server and the voice LT.


SERVICE profile management

The class “Service Profile” includes the attributes and methods that allow defining and managing the Service profile for the voice LT. The methods that have been defined for this class are “Modification” and “Retrieve”.

Narrowband Line Testing management

The class “Line Test Session” includes the attributes and methods that allow defining and managing a narrowband line test session.

The class “Line Test Line ID” includes the attributes and methods that allow defining and managing the subscriber lines involved in a narrowband line test session.

The class “Line Test Parameters” includes the attributes and methods that allow defining and managing the parameters being considered in the course of a narrowband line test session.

The class “LtReport” traps event during line test.






The class “Line Test Report” includes the attributes and methods that allow retrieving the results of the completed narrowband line test session.

The methods that have been defined for this class are “Modification” (first three classes only) and “Retrieve”.

Overall management policies

Strict object creation priorities:

The management classes have been split in three main categories:

• Category 1: includes the management classes SipSysObjects, SipUserAgent, SipUserAgentAccessPoint, DialPlan, DigitMap, SipServer, LineIdSyntaxProfile.

• Category 2: includes the management class SipVsp.• Category 3: includes the management class Siptermination.

The overall management policy is such that the system requires that category N class objects must be created prior to category N+1 class objects.

In-service/out-of-service modification

The method “modification” includes 2 different functions: the “In-service-modification” and the “Out-of-service-modification”.

• With the “in-service-modification” function, the system allows to modify the values of attributes of a previously created object whilst that object remains in service.

• With the “Out-of-service-modification” function, the system allows to modify values of attributes of a previously created object on the condition that this object has been put out-of-service.

An attribute is modifiable either by means of the “in-service-modification” or by means of the out-of-service-modification” (these are mutual exclusive functions).

Usually, an “out-of-service-modification” function involves three steps to be executed:

1 Putting the previously created object out-of-service by changing the administrative state of that object to “down”.

Note — Regarding the method “Modification”, see section “In-service/out-of-service modification”

Note — The strict object creation policy does not apply to the “CDEProfile” class.



2 Modify the value of one or multiple attributes of the object.

3 Putting the object in-service by changing the administrative state of that object to “up”.

The first step usually causes de-registration of the voice subscribers associated with the object. The third step will then result in re-registration of the same voice subscribers.

The “down” operation of “SipVsp”, “SipUserAgent”, “SipUserAgentAccessPoint”, “SipServer”, “SipTermination” will be successful immediately no matter there is active call.

Below a more detailed view is given on the applicability of the “in-service” and “out-of-service” modification for the different Voice classes.

• Class “SipSysObjects”: “in-service-modification” applies.• Class “SipVSP”: Both “in-service-modification” and

“out-of-service-modification” apply. For the “out-of-service-modification”, the above described three-steps approach is to be followed. All the associated “SipTermination” objects will immediately become de-registered.

• Class “SipServer”: Both “in-service-modification” and “out-of-service-modification” apply.For the “out-of-service-modification”, the above described three-steps approach is to be followed.All associated “SipTermination” objects will immediately become de-registered.

• Class “DialPlan”: “In-service-modification” applies.• Class “DigitMap”: “In-service-modification” applies.• Class “User Agent”: Both “in-service-modification” and

“out-of-service-modification” apply.For the “out-of-service-modification”, the above described three-steps approach is to be followed.All associated “Termination” objects will immediately become de-registered.The following exception is noticed: switching from the manual configuration to the DHCP based configuration mode or vice versa can only be done by deleting the existing SipUserAgent object and re-creating this SipUserAgent object with the desired configuration mode. This implies that all existing SipTermination objects must be deleted prior to the deletion of the SipUserAgent object and that the same SIptermination objects need to be re-created once the new SipUserAgent object has been re-created.

• Class “SipUserAgentAccessPoint”: “out-of-service-modification” applies.For the “out-of-service-modification”, the above described three-steps approach is to be followed.All associated “SipTermination” objects will immediately become de-registered.(Centralized Sip model = All terminations; Distributed Sip model = All terminations of the involved Sip User Agent Access Point).

• Class “SipTermination”: “out-of-service-modification” applies.For the “out-of-service-modification”, the above described three-steps approach is to be followed.The involved “SipTermination” object will immediately become de-registered.



• Class “LineIdSyntaxProfile”: “In-service-modification” applies.All “SipTermination” objects will re-register.

• Class “Threshold Crossing Alarm”: “In-service-modification” applies

8.13 CDE profile management

Besides the regular management interface to configure the network and end user associated database parameters for the integrated voice service, the ISAM Voice node makes use of additional configuration data input under the format of a downloadable file. Allowing the integrated voice service to become fully operational requires the presence of CDE profiles at the Voice server (Megaco ISAM Voice only) and the Voice LT (both Megaco ISAM Voice and SIP ISAM Voice).

The content of CDE profiles is customer dependent. CDE profiles are produced off-line at the factory. The content is collected by means of a questionnaire that needs to be filled in by the customer. The contents is considered to be of static nature and concerns mainly the physical line characteristics of the NB user interface together with the Voice LT HW related configuration data and configuration data for the protocols that run at the end user side.

There is a dedicated CDE profile for the POTS Voice LT board, the ISDN BRI Voice LT board and the Voice server. The CDE profile for the POTS Voice LT board is voice-topology independent meaning that the same CDE profile can be used in either a MEGACO environment or a SIP environment.

The CDE profiles for the POTS/ISDN BRI Voice LT and Voice server are included in one CDE.tar file. This file must be downloaded and activated in the individual ISAM Voice access nodes, that is, the hub node, the subtending nodes and the remote nodes.

The CDE.tar file is delivered to the customer together with the SW package and all other associated files that are required to install an ISAM Voice in the access network.

The system itself takes care that a CDE profile is downloaded to the Voice server and/or the Voice LT board.

The system supports CDE profile upgrade. They are as well an integral part of the offline database migration during software upgrade.

8.14 Service profile management

SIP ISAM Voice has introduced the concept of “Service profile” to maximize flexibility on:

• IOT with multiple Application Servers, including the flexibility of a new IOT during a maintenance phase of a ISAM release

• re-using application SW: as such, application SW will be data driven, based on the selected options from the SIP service profile.

The service profile applies to the POTS SIP Voice LT board only and is provisional and downloadable via the CDE profile framework.



The content of the service profile is customer dependent. A service profile is produced off-line at the factory. The content is collected from the voice service requirements defined by the customer.

The service profile is appended to the CDE profile in the CDE profile file. As such it is downloaded together with the CDE profile in the individual ISAM Voice access nodes, that is, the hub node and the subtending nodes.

8.15 Performance monitoring

Megaco ISAM VoiceThe Megaco ISAM Voice supports the “nt” as well as the “rtp” package for the permanent and ephemeral terminations. These statistics are reported to the MGC after the call has finished in either the subtract or the audit reply.

Neither of these statistics are supported through the usual management interface.

Table 8-1 Statistics

Package Statistics Contained in CLI/SNMP Notes

subtract reply audit reply

nt dur Y Y - Provides the duration of time the termination has existed or been out of the NULL context.

os Y Y - Provides the number of octets sent from the termination or stream since the termination has existed or been out of the NULL Context. The octets represent the egress media flow excluding all transport overhead. At the termination level, it is equal to the sum of the egress flows over all streams.

or Y Y - Provides the number of octets received on the termination or stream since the termination has existed or been out of the NULL Context. The octets represent the ingress media flow excluding all transport overhead. At the termination level, it is equal to the sum of the ingress flows over all streams.

rtp ps Y Y - Provides the number of packets sent from the termination or stream since the termination has existed or been out of the NULL Context.

pr Y Y - Provides the number of packets received on the termination or stream since the termination has existed or been out of the NULL Context.

(1 of 2)



SIP ISAM VoiceThe SIP ISAM Voice supports

• The Per-Line statistics reflecting the measurements that have been done for calls made by a particular subscriber line during a 15-min time interval or a 1-day time interval.

• A set of per-line statistics is identified by the subscriber line identifier.• The per-call statistics reflecting the measurements been done for a particular call.

A set of per-call statistics, belonging to a particular call, is identified by the IMS Charging IDentifier (ICID) and the subscriber line identifier of the SIP termination that was involved in this particular call.

• Per-board resource utilization statistics.• Subscriber line utilization and service availability statistics.

For both the per-line statistics and the per-call statistics, the Performance History Storage Framework is used as the basic framework to collect performance measurements. This basic framework relies on historical interval counters that make use of storage registers to store the history of the PM counters. This is typically one register per 15 minutes or per 24 hours.

By applying the interval counters, should the duration of a call exceed the interval boundary, the per-call statistics for such a call will be collected and reported spread over multiple intervals. The post-processing (sum of all portions) of such per-call statistics portions is not supported by the ISAM Voice access node.

pl Y Y - Provides the current rate of packet loss on an RTP stream, as defined in RFC 3550. Packet loss is expressed as percentage value: number of packets lost in the interval between two reception reports, divided by the number of packets expected during that interval.

jit Y Y - Provides the current value of the inter-arrival jitter on an RTP stream as defined in RFC 3550. Jitter measures the variation in inter-arrival time for RTP data packets.

delay Y Y - Provides the current value of packet propagation delay expressed in timestamp units. This is the same as average latency.

Package Statistics Contained in CLI/SNMP Notes

subtract reply audit reply

(2 of 2)

Note — The use of some particular supplementary services may cause a dialog to become inactive for a while. This will also result in the generation of per-call statistics portions for the same call even within a single interval.



For the per-line statistics the SIP ISAM Voice supports:

• A current 15-minute register: a single register containing the PM counters for the PM measurements ongoing in the current 15-minute interval.

• A set of 96 15-minute recent registers: a set of 96 registers containing the PM counters of the 15-minute intervals preceding the current 15-minute interval.

• A current 1-day register: a single register containing the PM counters for the PM measurements ongoing in the current 1-day interval.

• A set of three 1-day recent registers: a set of three registers containing the PM counters of the 1-day intervals preceding the current 1-day interval.

For the per-call statistics the SIP ISAM Voice supports:

• A current 15-minute register: a single register containing the PM counters for the PM measurements ongoing in the current 15-minute interval.

• A set of 96 15-minute recent registers: a set of 96 registers containing the PM counters of the 15-minute intervals preceding the current 15-minute interval.

The start time and the end time of each interval (15 minutes / 1 day) are aligned with the quarter hours /24 hours of the wall clock.

The performance monitoring results can be retrieved by:

• The usual management interface (SNMP/CLI) (see Figure 8-97):• Row-by-row performance monitoring collection• Data analysis is to be done by OSS platform

• The Statistics Data Collector (SDC) (see Figure 8-98), which:• provides a feature-rich collection strategy (Fast MIB Upload)• provides a user-friendly report generation as performance monitoring data analysis

is done at the SDC• guides the MSAN to collect specific data via config. File (based on operator input)• retrieves performance monitoring results from the ISAM Voice via TFTP enhanced

with proprietary extensions



Figure 8-97 PM data collection by means of the usual management interface

Figure 8-98 PM data collection by means of SDC

LT

LT

LT

NT

Stats ag

ent

CLI terminal

AMSDSLAM

SNMP Get

Results

MSAN keeps collectingstatistics data from system

Collection strategy:Click to Get via SNMP

SNMP

LT

LT

LT

NT

Fast M

IB u

plo

ad

5529MSAN

TFTP-GET

TFTP-GET

SNMP/TFTP

EMSRetrieve list ofmanaged NEs

from EMS

Cfg.file

Cfg.file

Datafile

Controller

Filteralarm

Collection strategy- Statistics to be collected- File generation parameters- Collection interval- Automatic start or not

TFTP-PUT

1

2

4

5

6

FMU

FMU

FMU

3

Output



The SIP ISAM-V allows to retrieve the following performance monitoring results:

• For the per-line statistics:• The contents of the current 15-minute register• The contents of the 96 recent 15-minute registers• The contents of the current 1-day register• The contents of the three recent 1-day registers

• For the per-call statistics:• The contents of the 96 recent 15-minute registers.

Figure 8-99 Result post-processing

Per-line Performance Monitoring Counters

The following per-line performance monitoring counters are supported:

• Packets Sent.• Offers the number of RTP packets sent by a SIP termination during one or more calls

made in a single 15-min / 1-day interval• 32-bit counter• Autonomously enabled by the system upon the creation of the SIP termination.

• Octets Sent.• Offers the number of RTP payload octets sent by a SIP termination during one or

more calls made in a single 15-min / 1-day interval• 32-bit counter• Autonomously enabled by the system upon the creation of the SIP termination.

• Packets received.• Offers the number of RTP packets received by a SIP termination during one or more

calls made in a single 15-min / 1-day interval • 32-bit counter• Autonomously enabled by the system upon the creation of the SIP termination.

Dialog A “Elapse” time

Dialog A “active” time – portion 1 Dialog A “active” time – portion 2 Dialog A

Recent 15 min interval N-1 Recent 15 min interval N Recent 15 min interval N+1

Dialog APortion_1

PM record

Dialog APortion_3

PM record

Dialog APortion_4

PM record

Dialog APortion_2

PM record

1 PM record for dialog Ain this 15 min interval

2 PM records for dialog Ain this 15 min interval

1 PM record for dialog Ain this 15 min interval

Other NESDC

2. Generate PM record for dialog A including Dialog Reference. 1. Retrieve all PM portions for dialog A using Dialog Reference

1. Generate PM recordfor dialog A including

Dialog Reference

OSS Platform

2. Associate PM recordwith CDR record by using the

Dialog Reference

CDR

Dialog Ae.g. puton hold



• Octets received.• Offers the number of RTP payload octets received by a SIP termination during one

or more calls made in a single 15-min or 1-day interval. • 32-bit counter• Autonomously enabled by the system upon the creation of the SIP termination.

• Average Jitter Buffer Fill Level.• Offers the average jitter buffer fill level for one or more calls made by a SIP

termination during a single 15-min / 1-day interval. • 32-bit counter• Autonomously enabled by the system upon the creation of the SIP termination.

• Average Inter-Arrival Jitter.• Offers the average Inter-Arrival Jitter for one or more calls made by a SIP

termination in a single 15-min or 1-day interval.• 32-bit counter• Autonomously enabled by the system upon the creation of the SIP termination.

• Average Round Trip Delay.• Offers the average Round Trip Delay for one or more calls made by a SIP

termination during a single 15-min / 1-day interval • 32-bit counter• Autonomously enabled by the system upon the creation of the SIP termination.

• Total Packet Loss.• Offers the total (absolute) amount of packets lost for one or more calls made by a

SIP termination during a single 15-min / 1-day interval. • 32-bit counter• Autonomously enabled by the system upon the creation of the SIP termination.

Per-Call Performance Monitoring counters

The following per-call performance monitoring counters are supported:

• Packets Sent.• Offers the number of RTP packets sent by the SIP termination since:

- The call was established (call established in this 15-min interval)- The start of the 15-min interval (call established in a previous 15-min interval)And- The end of the call (call terminates in this 15-min interval)- The expiry of the 15-min interval (call crosses the border of this 15-min interval)

• 32-bit counter• Autonomously enabled by the system upon the configuration of the SIP termination.

• Octets Sent.• Offers the number of RTP payload octets sent by the SIP termination since:

- The call was established (call established in this 15-min interval)- The start of the 15-min interval (call established in a previous 15-min interval)And- The end of the call (call terminates in this 15-min interval)- The expiry of the 15-min interval (call crosses the border of this 15-min interval




• Packets Received.• Offers the number of RTP packets received by the SIP termination since:



• Octets received.• Offers the number of RTP payload octets received by the SIP termination since:



• Average Inter-Arrival Jitter.• Offers the average Inter-Arrival Jitter for an RTP data stream since:



• Peak Inter-Arrival Jitter.• Offers the peak Inter-Arrival Jitter for an RTP data stream since:



• Average Round Trip Delay.• Offers the average Round Trip Delay for an RTP data stream since:





• Peak Round Trip Delay.• Offers the Peak Round Trip Delay for an RTP data stream since:



• Total Packet Loss.• Offers the total amount of packets lost for an RTP data stream since:



• Total Packet Loss due to Jitter Buffer Overrun.• Offers the total amount of packets lost due to Jitter Buffer Overrun for an RTP data

stream since:- The call was established (call established in this 15-min interval)- The start of the 15-min interval (call established in a previous 15-min interval)And- The end of the call (call terminates in this 15-min interval)- The expiry of the 15-min interval (call crosses the border of this 15-min interval)

• 32-bit counter• Autonomously enabled by the system upon the configuration of the SIP termination

Per-Board Resource Utilization counters

• CPU load• Offers the CPU load for a particular Voice LT board as:

- a detailed value for the 180 most recent measurement points- an average value over the 180 most recent measurement points.

• Offered at board level and de-coupled from the Performance History Storage Framework.

• Enabled / Disabled on explicit operator request.• Memory Utilization

• Offers the memory utilization for a particular Voice LT board as:- an absolute value- as a percentage compared to the reserved amount of dynamic memory for that

Voice LT board.• Offered at board level and de-coupled from the performance History Storage

framework.• Autonomously enabled by the system upon the planning of the LT board.



Subscriber line Utilization and service availability statistics

The following counters are available:

• Number of non-configured lines:This counter offers the amount of planned/equipped subscriber lines for which no entry could be found in the Termination table.

• Planned subscriber lines are subscriber lines associated with planned Voice LT boards.

• Equipped subscriber lines are subscriber lines associated with equipped Voice LT boards.

• Number of operational configured lines:This counter offers the amount of subscriber lines configured in the SIP termination table for which the operational state equals “up”. Or in other words, the amount of subscriber lines that are registered with the IMS core and as such operational from an integrated voice service perspective.Only subscriber lines associated with equipped Voice LT boards can have an operational state which equals “up”.

• Number of non-operational configured lines:This counter offers the amount of subscriber lines configured in the SIP termination table for which the operational state equals “down”. Or in other words, the amount of subscriber lines that are configured in the SIP termination table but not registered with the IMS core and as such not operational from an integrated voice service perspective.Only subscriber lines associated with equipped Voice LT boards can have an operational state which equals “down”.

The following applies for these counters:

• they are 32-bit counters• they are offered at system level and de-coupled from the performance History

Storage framework.• they are autonomously enabled by the system upon system start-up and Voice LT

board planning.

Summarized: the sum of the lines of the planned Voice LT boards and the lines of the equipped Voice LT boards is equal to the sum of the non-configured lines, the operational configured lines, and the non-operational configured lines.]

Threshold Crossing Alarm Treatment

The SIP ISAM Voice supports TCA handling for the Jitter Buffer Fill level. The TCA can be enabled / disabled for each individual subscriber line.

Both the high and the low TCA threshold are configurable.



8.16 Reliability, Equipment / Connectivity / Overload Protection

Equipment Protection

NT redundancy

NT 1+1 redundancy applies to both Megaco ISAM Voice and SIP ISAM Voice.

For further details about NT redundancy, see chapter “Failure protection and redundancy provisions in ISAM”.

Megaco ISAM Voice: Voice Server redundancy

Voice server 1+1 redundancy applies to Megaco ISAM Voice only.

The Voice server may be installed as a 1+1 Redundancy pair. Both Voice servers of a 1+1 redundancy pair must be equipped in neighboring slot positions.

One Voice server is active while the other runs in standby mode. In case the active Voice server encounters a HW or SW problem, the standby Voice server takes over and becomes the active Voice server for the integrated voice service.

Upon switchover, the recovery time is less than 7 s for call signaling and less than 3 s for voice traffic.

Stable calls are not lost during the switchover. Non-stable calls that is, calls in the set-up phase may be lost due to a Voice server switchover. This applies to both, POTS and ISDN BRI calls.

Connectivity ProtectionBesides the support of Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP) or Multiple Spanning Tree Protocol (MSTP) and Link Aggregation Control Protocol (LACP) on the network links of the ISAM Voice node, some additional, more voice specific connectivity protection concepts are introduced.

Megaco ISAM Voice: dual homing

Megaco ISAM Voice allows the provisioning of a primary and a secondary Softswitch (IP address). This allows the ISAM Voice access node to make a switchover from the actual connected Softswitch to the alternative one in case the communication with the actual one would be broken.

The Megaco ISAM Voice supports the capability to preserve stable calls over a Softswitch switchover. However, whether stable calls are preserved or not depends on the capabilities of the Softswitch with which the ISAM Voice establishes the MGI, the customer requirements regarding the switch-over scenario to be followed and finally the total elapse time for making the switchover.



A connectivity failure with an MGC may be detected by three different occurrences:

• [A]: Upon no reply on a transaction request originating from the Voice server: Megaco ISAM Voice allows configuring the maximum number of retries (max 7) per transaction together with the transaction retry mode being either the transaction retry mode comprising a fixed (configurable) retry interval or the transaction retry mode comprising an increasing retry interval. The initial retry interval is configurable; the retry interval doubles for each subsequent retry.The decision that connectivity with the MGC is broken is taken the moment the maximum number of configured retries for a transaction request initiated by the voice server has been exceeded without receiving a reply from the MGC.

• Inactivity Timer package:This package contains an event that can be implemented by an MGC and by an MG. The purpose of the event is to allow the MG to detect periods of silence of messaging from the MGC. Once the period of silence exceeds a threshold, the MG assumes a connectivity failure with the MGC.

• [B]: Active Heartbeat approach:ISAM Voice takes the initiative to check the connectivity with the MGC at regular time interval. For this purpose it makes use of the “notify” package.Megaco ISAM Voice allows enabling/disabling the active heartbeat either in “learnt heartbeat interval” or in “configured heartbeat interval” mode.Mode = “configured heartbeat interval”: The interval by which the “notify” packages are sent from ISAM Voice to the MGC is configured in the ISAM Voice database.Mode = “learnt heartbeat interval”: ISAM Voice gets notified by the MGC (through the “Inactivity Timer” package) about the interval to be used for sending the “notify” packages to the MGC.The decision that the connectivity with the MGC has been broken is taken from the moment 7 subsequent “notify” packages were not replied by the MGC. The “notify” packages will not be sent in case the ISAM Voice receives at least one Megaco message from the MGC within the learnt/configured heartbeat interval.

• [C]: Passive Heartbeat approach:The MGC takes the initiative to check the connectivity with the MG (ISAM Voice) at regular time interval. For this purpose it makes use of the “audit” package.Megaco ISAM Voice allows enabling/disabling the passive heartbeat either in “learnt heartbeat interval” or in “configured heartbeat interval” mode.Mode = “configured heartbeat interval”: The interval at which the “audit” packages are sent from the MGC to the ISAM Voice is configured in the ISAM Voice database.Mode = “learnt heartbeat interval”: ISAM Voice learns the interval at which the “audit” packages are sent by the MGC to the ISAM voice. ISAM voice awaits three consecutive “audit” packages from the MGC to calculate the heartbeat interval.The decision that the connectivity with the MGC has been broken is taken from the moment 8 subsequent heartbeat intervals have been passed without receiving an “audit” package nor a regular Megaco package from the MGC.

Megaco Voice: Network Connectivity Protection

Also known as “Path Connectivity Check and Protection” (PCCP).

This protection technique aims at consolidating the connectivity between a Megaco ISAM Voice and a network device, mostly its default gateway.

For further details about Network Connectivity Protection, see chapter “Failure protection and redundancy provisions in ISAM”.



SIP ISAM Voice Fail-over

Failover is the capability to switch over automatically to a redundant or standby SIP server upon the failure or abnormal termination of the previously active SIP server.

Failover happens without human intervention and generally without warning.

SIP ISAM Voice supports a provisional FQDN for the outbound proxy and follows RFC3263 and RFC2782 for trying different proxy addresses until one is successful.

SIP ISAM Voice supports provisional primary and alternate proxy servers; Provisioned proxy addresses (primary or alternate) can be either an IP address or an FQDN. It is recommended to use FQDN. There are a number of alternatives for populating these addresses:

• Populate both a primary and an alternate address with IP addresses (IP1 and IP2)• Populate both a primary and an alternate address with FQDNs (FQDN1 and

FQDN2) • Populate just a primary address with an FQDN that resolves to multiple IP

addresses.

The FQDN is resolved through DNS server access. The SIP ISAM Voice does not currently support SRV parameters such as priority though A-record queries are supported. In this case, however, the DNS A-record query may include the complete list of primary and secondary IP addresses.

The SIP ISAM Voice currently assumes that the A-record list of intended primary and alternate servers remains in the desired order on the DNS, that is, it assumes that the list will not be permuted such as for load sharing purposes.

The SIP ISAM voice does not currently distinguish the primary from the alternate outbound proxies.

The SIP-UA first attempts to register with the first outbound proxy found in the IP address list. If registration via the current outbound proxy fails, the SIP-UA attempts to register via the next outbound proxy found in the IP address list.

If after all, registration would fail (as none of the outbound proxies do reply), the SIP-UA raises an alarm.

The maximum lifetime of the list of IP addresses received through a DNS A-query is controlled by a DNS purge timer which is currently fixed at a period of 20 minutes.

A new DNS A-query is also launched in case none of the SIP servers in the list do respond.

Note — When primary and alternate proxies are provisioned, the current SIP ISAM Voice will only consider the primary proxy. Failover to the alternate proxy when the primary proxy is not available is not autonomously triggered by the system; this switch requires manual (configuration) intervention. Consequently, for autonomous fail-over support, the third alternative must be used. that is, populate just a primary address with an FQDN that resolves to multiple IP addresses.



SIP ISAM Voice also allows enabling a heartbeat mechanism, based on the OPTION message, to verify the connectivity with a SIP server. In case there is no response to the OPTION request, the associated SIP server is marked as unreachable; stable calls that were associated with that SIP server are released and terminations associated with this SIP server are de-registered.

SIP ISAM Voice: SIP server fail-back

Fail-back, conversely, is the process of restoring a system/component/service in a state of failover back to its original state (before failure).

Based on the explanation given above, the fail-back would occur upon restoration of the first / primary server listed in the DNS A-query. While this primary server was unavailable, the secondary servers from the DNS A-query list were used.

Megaco ISAM Voice: MG (ISAM Voice Server) Overload ProtectionThe overload treatment introduced at the Voice server card aims at guaranteeing self-protection and robustness for the ISAM Voice.

The Voice Server overload protection is based on the SW Watch Dog concept.

The software watchdog monitors the system in verifying whether all defined SW tasks become scheduled in a reasonable time frame. When this is not the case anymore, the software watchdog will trigger a SW application-specified call-back function in which the existing CPU load problem is expected to become resolved (if possible). The action that is taken when a SW watchdog happens at a certain priority level depends on the SW application policy.

The goal of the SW watchdog is to detect tasks in the system that are too long in the READY state. A task in the READY state means that it wants to run, but cannot because there is one (or more) task(s) that constantly uses the CPU. This can be because the running task has a higher priority than the READY one or it has disabled its pre-emption.

The reason why the CPU consuming task doesn't give up the CPU can have several reasons:

• The process has a lot of work to do and runs at a high priority. For example a protocol stack is running in its own task and receives a lot of network traffic that it has to process.

• The process enters an endless loop.

The software watchdog is responsible for just detecting that there is a problem in the system, not to resolve the problem. The latter aspect is the responsibility of the clients of the software watchdog.

Several SW Watchdog levels were introduced at the Voice server, each of them monitoring the range of SW tasks that run with priorities higher than the SW Watchdog level. The lower the SW Watchdog level, the longer it may take before a SW watchdog time-out is triggered.



Watchdog approach

• Overload = Voice server card runs at 100% of its CPU capacity:• Received Megaco packets get a priority treatment• Received Line events (off-hook, on-hook, flash-hook, dialed digits…) could be

ignored,• Robustness Level 1 = reached when the Voice server remains running at 100% of

its CPU capacity during at least the next 40 s. The SW Watchdog task is started every 40 s and monitors the CPU capacity for another 40 s. As a result, the Voice server will get into robustness Level 1 mode 40 to 80 s after reaching the maximum CPU capacity.

• A Megaco “ADD” command being received from the MGC is replied with error 510 (Insufficient Resources).

• Any incoming “auditvalue” or “auditcapability” command is discarded (this includes the “heartbeat” audit).

• Robustness level 2 = reached when the Voice server runs in Level 1 mode and remains running at 100% of its CPU capacity during the next 160 s. The SW Watchdog task is started every 80 s and monitors the CPU capacity for another 80 s. As a result, the Voice server may get into robustness Level 2 mode at the earliest 160 s after having reached Level 1 mode.

• Any new Megaco command (Add, Modify, Subtract, Move, AuditValue, AuditCapabilities and ServiceChange) being received from the MGC is discarded by the Voice server.

• Intra voice subsystem polling intervals are enlarged (This also includes the intervals to establish / maintain the XLES connection with the voice LT boards).

• Commands been received from the MGC but not yet replied by the Voice server, are treated with long timer timeout; no “pending” will be sent for those transactions.

• Robustness level 3 = reached when the Voice server runs in Level 2 mode and remains running at 100% of its CPU capacity during the next 320 s. The SW Watchdog task is started every 160 s and monitors the CPU capacity for another 160 s. As a result, the Voice server may get into robustness Level 3 mode at the earliest 320 s after having reached Level 2 mode.The Voice server initiates a board reset.

Outgoing Megaco packets as well as outgoing internal signaling (XLES) packets remains treated as is the case when the Voice server runs in a non-overload situation

MG Control Overload package

An additional overload mechanism based on CPU load monitoring and in line with H.248.11 (MG Control Overload Package) is implemented (ocp).

This package protects an MG from processing overload that prevents the timely execution of Megaco transactions.

The MGC, supporting the MG Control Overload Package, adaptively throttles the rate with which it sets up calls using the ISAM Voice Server to maximize the effective throughput of the MG whilst bounding its response times.

It does this by throttling the rate at which transactions that set-up new calls or that new call legs are sent to the overloaded MG, so the rate of overload notifications which the MGC receives from the overloaded MG converges to a suitably low level.



To prevent a toggling between CPU-overload and end-of-CPU-overload, an (End of) Overload Persistency Time has been introduced.

The Overload Persistency Time is the time period the CPU load of the ISAM Voice Server must exceed the High-Water-Mark before it can enter the CPU overload state.

Similarly, the End of Overload Persistency Time is the time period the CPU load of the ISAM Voice Server must below the Low-Water-Mark before it leaves the CPU overload state.

The End of Overload Persistency Time is set larger than the Overload Persistency time as to ensure that the CPU load is for a sufficient long time below the Low-Water-Mark as not to cause quite immediately a new CPU overload situation.

• CPU load monitoring:• Monitors the overall CPU load of the Voice server by measuring the run time of the

IDLE task.• Informs registered SW applications in case of overload detection• Upon being notified of an overload situation, the SW Application takes action to

reduce the load.• CPU load monitoring parameters (not configurable):

High water (percentage): 95% (5% IDLE task)Low water (percentage): 93% (7% IDLE task)Overload persistency (time): 2000 ms End of overload persistency (time): 3000 msSample interval (time): 1000 ms (each sample period, the CPU load (as a function of the time given to the idle task) is measured)

• Upon the receipt of Overload-condition notification, the Voice server takes the following actions:

• If requested by MGC and after having received and replied to a Megaco “ADD” command, report the ocp/mg_overload event (irrespective of the events reporting settings being configured in the H.248 MIB.

• If not requested by the MGC, reports the ocp/mg_overload event if the MG-Overload event is enabled in the H.248 MIB (after having received and replied to a Megaco “ADD” command).

• Raise the MG-Overload alarm.• Upon the receipt of Overload-condition-Ended notification, the Voice server

takes the following actions:• Stop the reporting ocp/mg_overload event.• Clear the MG-Overload alarm

8.17 Quality of Service

For VoIP to be a realistic replacement for standard public switched telephone network (PSTN) telephony services, customers need to receive the same quality of voice transmission they receive with basic telephone services, meaning consistently high-quality voice transmissions. Like other real-time applications, VoIP is extremely sensitive with regard to bandwidth and delay. For VoIP transmissions to be intelligible to the receiver, voice packets should not be dropped, excessively delayed, or suffer varying delay (otherwise known as jitter).



VoIP can guarantee high-quality voice transmission only if the voice packets, for both the signaling and the voice channel, are given priority over other kinds of network traffic.

For VoIP to be deployed so that users receive an acceptable level of voice quality, VoIP traffic must be guaranteed certain compensating bandwidth, latency, and jitter requirements. QOS ensures that VoIP voice packets receive the preferential treatment they require.

P-bit marking (layer 2) and DSCP marking (layer 3) for signaling and voice (including fax and modem) traffic are supported.

The p-bit as well as the DSCP values are configurable for signaling and voice traffic

Megaco ISAM Voice

• Signaling traffic: The p-bit and DSCP values are configurable at Media Gateway level.

• Voice traffic (including fax and modem): The p-bit and DSCP values are configurable at Media Gateway and Termination level.

SIP ISAM Voice

• Signaling traffic: the p-bit and DSCP values are configurable at SIP UA level.• Voice traffic (including fax and modem): the p-bit and DSCP values are

configurable at SIP UA level.

8.18 DHCP interworking

Megaco ISAM VoiceDHCP interworking is not supported for Megaco ISAM Voice.

SIP ISAM VoiceThe distributed IP address architecture allows configuring the SIP UA parameter values by manual input (by means of the usual management interface (SNMP, CLI)) or for these values to be retrieved through a DHCP request.

The centralized IP address architecture only allows configuring those parameter values by manual input.

In case of retrieved through DHCP, options 1 (subnet mask), 3 (default route), 6 (DNS server IP address) and 120 (SIP option, to retrieve the SIP server IP address list or SIP domain names list) are used to retrieve all relevant information.



Management interface parameters for which the value can be retrieved through a DHCP request are:

• The source IP address and subnet mask of the SIP UA.• The default gateway IP address for signaling and Voice traffic.• The IP address of the DNS server.

8.19 DNS interworking

Megaco ISAM VoiceDNS interworking is not supported for Megaco ISAM Voice.

SIP ISAM VoiceThe usual Management interface (SNMP, CLI and TL1) allows configuring the SIP servers (Proxy Server, Registrar Server) by manual input or for these values to be retrieved through DNS access.

In the latter case, the DNS domain name must be specified to allow the system to make the correct DNS server binding.



8.20 Basic call handling and supplementary services

Megaco ISAM Voice

• Interfacing at subscriber's side according to the Z POTS interface.• DTMF/pulse digit detection/processing.• Caller identification services (FSK, DTMF, on/off hook).

• FSK/DTMF configurable per line• Signaling events processing• en-bloc dialing.• Voice activity detection, comfort noise, and packet loss concealment.• Configurable jitter buffer: adaptive or fixed size (per call).• G.168/G.165 echo cancellation with an echo tail length at 16ms• Tone generation: Ring tone, Dial Tone, Special (Information) Dial Tone, Ring

Back Tone, Congestion Tone, Busy Tone, and Howler tone.• Balanced ringing• Flexible Termination ID format including wildcard

• Flat termination ID format• Hierarchical termination ID format:

- Configurable Termination ID syntax- A character string composed of a number of pre-defined keywords.

• Configurable ephemeral termination id range.• Audit of ephemeral termination with support of the wildcard *. • Capability of configuring 2 dial plans in the CDE profile, each with a max size of

4 Kbytes including digit map patterns and digit map pattern separators. The digit patterns are consecutively stored with the 4 Kbytes buffer, separated by a digit pattern separator.

• Capability to store up to 512+51 dial plans (one dial plan/call; downloaded by the MGC), each with a max size of 4 Kbytes including digit map patterns and digit map pattern separators.

• T.38 Fax/Modem• Softswitch is responsible of voice/T.38 call control & charging.• Fax over IP according to ITU-T Rec. T.38• Between 2 Group 3 facsimile terminals.• UDP transportation • V21 flag detection• Byte based and frame based • FEC and redundancy • 2400 bps, 4800 bps, 7200 bps, 9600 bps, 12200 bps, 14400 bps.• Maximum Speed is 14400bps which depends on network situation.

• T30 Fax/Modem, requiring full control at the MGC. • Detected tones reported to MGC• Switch to VBD mode upon receipt of MGC command.



• Transparent modem/fax service (v.150 VBD mode)• Capability to detect fax/modem tones from network side or local side.• In-band tones compliant with RFC2833 (e.g., frequency, duration, volume,

modulation etc. shall be same).• “In-band tone detection” of fax/modem/text tones from remote side (voice band

codecs, commonly G.711, ADPCM like G.726, etc.), which serves both as a VBD stimulus and a coordination technique to guarantee autonomous behavior.

• In-band fax/modem tones trigger ISAM Voice to switch to VBD mode• For H.248only CNG/ANS tones and V.21 from local side will be reported to

MGC in case of T30/modem full control by MGC.• Support of the reception of event 52 in compliancy with RFC4734, allowing to

swap to VBD for Bell 103 / Bell 212 modems.• Support of the reception of event 28 in compliancy with RFC4734, allowing to

swap to VBD for V.8 bis modems.• Support of enhanced fax/modem in-band tone detection from local / IP side with

additional tones treated in compliancy with RFC4733 (when defined). Additional fax/modem tones support together with IP side in-band tone detection can be activated simultaneously without causing a density decrease. IP side in-band tone detection can be turned off via CDE Profile.

• Fax: V.21, V.17, V.27 ter, V.29, V.34• Modem (or textphone): V.18, V.21, V.22, V.22bis, V.23, V.32, V.32bis, V.32ext,

V.34, V.90, V.92, Baudot, Bell103, Bell 212A, V.25/V.8/V.8bis compliance.• Public Payphone (reverse polarity)

Line Polarity Reverse at answer. (H.248: driven by CDE profile input & MGC command input)

• 12 /16 Khz Metering (1 TR 110 - 1) for POTS lines connected to public coin boxes and payphones.

• Periodic Pulsing Only• Burst once then Periodic Pulsing• Periodic Bursts• Periodic bursts with Periodic Pulsing in between the bursts• Burst once at the begin of a call• Tariff changes during a call

• Configuration of Line impedance on a per subscriber port basis• Payload format 'audio/telephone_event' and associated dynamic payload type

number.• Delay before Reduce battery: Apply reduced power feed in case the analogue line

continues to remain Off-Hook without being associated to any connection. The ISAM Voice shall trigger timeout of cg/bt and xcg/roh signal and starts a timer in case the physical termination is in NULL Context or is the only termination in a non NULL context. Upon timer expiry, all active signals are disabled and the reduced battery line state is autonomously entered. The timer is disabled by 'On-Hook' event or 'stimal/stedsig=reduced battery' signal.

• Termination of the ISDN BRI U interface (ITU G.961).• Q921 protocol termination.• Q931 protocol relay via SIGTRAN.• CODECs:



• 48 lines POTS LT / 24 lines ISDN LT: G.711 A/u law (10ms, 20ms, 30ms), G.729AB (10ms, 20ms, 30ms, 40ms, 50 ms, 60ms), G.723.1 (5.3kbps, 6.3kbs, with 30ms), T.38, RFC2833

• 72 lines POTS LT: G.711 A/u (10ms, 20ms, 30ms), G.729 A/B (10ms, 20ms, 30ms, 40ms, 50ms, 60ms), G.723.1 (5.3 kb/s/30ms, 6.3 kb/s/30ms), T.38, RFC 2833;

• For G.711, DTMF or RFC2833 signaling is supported• For G.729, RF2833 signaling is supported

• ISDN: Test based formatted ISDN IUA Interface identifier.

SIP ISAM Voice

General properties (POTS)

• Interfacing at subscriber's side according to the Z POTS interface.• Caller Identification Services (FSK, DTMF, on/off hook).

• FSK/DTMF configurable per line• Signaling events processing.• Voice activity detection, comfort noise, and packet loss concealment.• Configurable jitter buffer: adaptive or fixed size (per call).• G.168 echo cancellation with an echo tail length at 16ms• en-bloc dialing• Overlap dialing

• Multiple-invite method• In-dialog (INFO method)

• Balanced ringing• Capability of configuring one dial plan through the usual management interface.

• The dial plan has a maximum size of 4 Kbytes including digit patterns and digit pattern separators.

• The dial plan needs to be configured by means of a maximum of 128 MIB table rows with a size of 32 bytes each.

• Each row may contain one or more digit patterns separated by a digit pattern separator.

• A digit pattern must not be split over 2 or more rows.• Constant payload type throughout session• CODECs:

• 48 lines POTS LT / 24 lines ISDN LT: G.711 A/u law (10ms, 20ms, 30ms), G.729AB (10ms, 20ms, 30ms, 40ms, 50ms, 60ms), T.38. RFC2833

• 72 lines POTS LT: G.711 A/u (10ms, 20ms, 30ms), G.729 A/B (10ms, 20ms, 30ms, 40ms, 50ms, 60ms), T.38, RFC 2833;

• For G.711, DTMF or RF2833 signaling is supported• For G.729, RF2833 signaling is supported

• Supported GR-506 requirements:• Detection of Dial-Pulse Signals from Analog Access Lines • Hits, Flash Signals, and Disconnect Signals • Detection of DTMF Signals from Analog Access Lines



• Call Process Signals• Audible ringing to calling line• Tone generation: Ring tone, Dial Tone, Special (Information) Dial Tone, Ring

Back Tone, Congestion Tone, Busy Tone, and Howler tone.• E2E Dynamic payload type negotiation (RFC3264) - dynamic payload value out

of the range 96...127.• T.38 Fax/Modem

• China telecom T.38 fax scenario in Softswitch is mandatory• Softswitch is responsible of voice/T.38 call control & charging.• Fax over IP according to ITU-T Rec. T.38• Between 2 Group 3 facsimile terminals.• UDP transportation • V21 flag detection• Byte based and frame based • FEC and redundancy • 2400 bps, 4800 bps, 7200 bps, 9600 bps, 12200 bps, 14400 bps.• Max. Speed is 14400bps which depends on network situation.

• Support of enhanced fax/modem in-band tone detection from local / IP side with additional tones treated in compliancy with RFC4733 (when defined). Additional fax/modem tones support together with IP side in-band tone detection can be activated simultaneously without causing a density decrease. IP side in-band tone detection can be turned off via CDE Profile.

• Simultaneous activation of Fax/modem tones support.• In-band tones compliant with RFC2833 (e.g., frequency, duration, volume,

modulation etc. shall be same).• “in-band tone detection” of fax/modem/text tones from remote side (voice band

codecs, commonly G.711, etc.), serving as both a VBD stimulus and a coordination technique, guarantees autonomous behavior.

• Fax: V.21, V.17, V.27 ter, V.29, V.34• Modem (or textphone): V.18, V.21, V.22, V.22bis, V.23, V.32, V.32bis, V.32ext,

V.34, V.90, V.92, Baudot, Bell103, Bell 212A, V.25/V.8/V.8bis compliance.• Flexible SIP URI provisioning:

Operator control on 'userinfo' part of SIP-URI• full operator control: The operator can configure a string per SIP Termination Point.

This configured string will be integrally copied into the 'userinfo' part of the SIP-URI where it will be completed with the '@' character.

• the MSAN itself generates a 'termination-id' string for the 'userinfo' part. This string shall be generated according a syntax that is under operator control. The string generated according the syntax will be completed with the '@' character.

Operator control on 'hostport' part of SIP-URI• hostname: port• IPv4address: port• Hostname• IPv4address

• Flexible Termination ID provisioning:• Configurable Termination ID syntax• A character string composed of a number of pre-defined keywords and operator

defined characters.



• Public Payphone (reverse polarity): Line Polarity Reverse at answer.• 12 /16 Khz Metering (1 TR 110 - 1) for POTS lines connected to public coin

boxes and payphones.• Periodic Pulsing Only• Burst once then Periodic Pulsing• Periodic Bursts• Periodic bursts with Periodic Pulsing in between the bursts• Burst once at the begin of a call• Tariff changes during a call

• Configuration of Line impedance on a per subscriber port basis• Service Subscriber Control for POTS subscribers:

• Subscriber Control with & without a PIN code.• PIN code is modifiable from the subscriber telephone set.

• Delay before Reduce battery: Apply reduced power feed in case the analogue line continues to remain Off-Hook without being associated to any connection.

• for 72-line POTS LT: complex tone support:• up to 12 multi tone cadences • each tone cadence can be 4 frequency tone

Supplementary Services

The ISAM Voice supports the following 3 models:

• Tightly Coupled Model.• More Advanced SIP EP Model (predecessor of Loosely Coupled Model).• Loosely Coupled Model.

Tightly Coupled Model

• On-hook and flash-hook are interpreted by the AS. • “Call Waiting”:

• Flash-hook only: Calling termination presses the flash-hook to switch between the current called termination and a third party.

• Flash-hook + dialed digit: Calling termination presses flash-hook and dials an additional digit to switch between the current called termination and a third party

• “Call Hold”:• Hard Hold:

- Only calling and called termination involved.- Allowing calling termination to Flash Hook once to put the called termination onhold, and to Flash Hook once again to resume the call with the hold termination.

• Call Hold Consultation:- Calling termination, called termination and third party involved.- Allowing calling termination to put an existing call on hold and to initiate a second call to a third party

• The following services are transparent for ISAM Voice:- CLIR- Call Forwarding Busy- Call Forwarding No reply- Call Forwarding unconditional



• “3-party Conference”:• Compliant to both TISPAN and non-TISPAN specification, noted that the

Y-function hosts in the MRF/MS, not in IAM Voice.• Following 2 methods are supported (depends on AS service application):

- Automatically bridged call by AS- User dialing decided conference call

• Non-TISPAN implementation only supports IOT with Broadworks FS.• “Explicit Call Transfer”:

• Compliant to both TISPAN and non-TISPAN specification.• The following 3 Explicit Call Transfer methods are supported:

- Consultative call transfer: for forwarding a call after the first person who wascalled spoke to the caller (for example, this is useful if a secretary is called andforwards the call afterwards to the responsible person).

- “3-Way Call transfer”: a termination can set up a three-way call and thendisconnect, allowing the remaining parties to continue the conversation.

- “Blind call transfer”: to transfer a call without talking to the called party.• Non-TISPAN implementation only supports IOT with Broadworks FS.

• “Malicious Call Identification”:• Permanent (transparent to ISAM-Voice): supported.• After call completion: supported.• During call (transparent to ISAM-Voice): supported

More Advanced SIP EP Model

• This model was introduced as the predecessor of the Loosely Coupled Model in order to meet the increased market demand from IMS Core and Application Server vendors.

• This model has been fully replaced by the Loosely Coupled Model.

Loosely Coupled Model

• On-hook and flash-hook events are analyzed in the AGCF/VGW (much like a simulation endpoint would operate).

• “Call Waiting”:Supported in compliancy with ETSI TS183043 C.9.1/C.16.1 Loose Coupling, 3GPP ES 23.228 chap5.11.1, ES 24.228 chap10.1, and China Mobile spec; Generates re-INVITE message when the supplementary service becomes activated due to pressing the hook-flash.

• “Call Hold”:Supported in compliancy with ETSI TS183043 C.9.1/C.16.1 Loose Coupling, 3GPP ES 23.228 chap5.11.1, ES 24.228 chap10.1, and China Mobile spec; Generates re-INVITE message when the supplementary service becomes activated due to pressing the hook-flash.

Note — In this case the Application Server cannot make any different between flash-hook for MCID or flash-hook for another supplementary service, for example, put call on hold.

As such, the Application Server does either support MCID or the rest of the supplementary service activated by flash-hook, but cannot support both simultaneously.



• “3-Party Conference”:Supported in compliancy with ETSI TS183 043 C.14.2 Loose Coupling option 1 and China Mobile spec. Support audio mixing on the 72 lines voice LT board.

• “Malicious Call Identification”:• Permanent (transparent to ISAM-Voice): supported.• After call is finished: supported.• During call: NOT supported

• “Call Transfer”:• Blind Transfer, Consultant Transfer, Call Proceeding.• Supported in compliancy with China Mobile spec and 3GPP ES 23.228 chap 5.11.5

Redirection, ES 24.228 chap 10.5. • Support “Refer” message to send the DTMF to the AS in compliancy with RFC

3515 REFER Method/Refer-to header and RFC 3892 Referred-By header.• Applying either the TISPAN or CMCC or 3GPP defined approach is configurable

through the SIP Service profile.• Support of the selected approach with or without SOC.• Support of TISPAN SIP UA-profile according to ETSI TS183 043 Annex A.• Support of SDP update of an early media stream.

Note — The SIP ISAM Voice is also able to interoperate with the BroadSoft BroadWorks Softswitch. Interoperability of the ISAM Voice with additional voice applications servers is also possible through commercial agreement.



Additional Supplementary Services

• “CLIP”:• Primary source for the Calling Line Identity is either the “From” header or the

“P-Asserted Identity” header (RFC3325). The primary source to be considered is configurable in ISAM Voice: PAI SIP URI user part, PAI SIP URI display name, PAI Tel URI, SIP URI user part, SIP URI display name, Tel URI.

• In case the end-user becomes identified to the CLIP service as “No subscription”, “Private” or “Unavailable”, part of the “From” header or from the “P-Asserted Identity” header will be set to a dedicated value by the IMS core network.ISAM Voice allows to configure whether either “Display Name” or “User Part” (PAI / From) or both do include this dedicated value.

• The dedicated value(s) for “No Subscription”, “Private” and “Unavailable” are configurable in ISAM Voice.

• Should a termination not be subscribed to the CLI service, then no CLI data transmission signalling sequence is applied.

• Should a termination be identified as “Private CLI”, then the calling Line identity parameter is omitted. Instead, “Reason for absence of calling line ID=private” is propagated.

• Should a termination be unavailable, then the calling Line identity parameter is omitted. Instead, “Reason for absence of calling line ID=unavailable” is propagated.

• Should both, a tel-uri as well as a sip-uri formatted P-Asserted Identity headers be present, then precedence is given to one of these headers in accordance with the precedence policy configured in ISAM Voice.

• In general, IMS networks do provide calling number information in the global number format identified by the leading “+” character (Ref. RFC3966). ISAM Voice converts the leading “+” into a configurable international-prefix before the CLI propagated in the CLIP FSK data message.

• ISAM Voice allows to configure whether the “Date and Time” parameter is to be included in the CLIP FSK data message. ISAM Voice is capable to display the date and time of the receipt of the INVITE request originated by the calling user based on the SIP Date header. ISAM Voice allows to configure whether the date and time shall be taken from the SIP Date Header or from the local ISAM Voice time reference.

• ISAM Voice allows to configure whether “Calling Party Name” and “Reason for absence of calling party name” is applicable or not. Should “Reason for absence of calling party name” be applicable and:- The termination is requesting private CLI, then the “Reason for absence of calling

party name” is set to “Private” - The termination calling party name information is unavailable (either no display name in header or using blank between double quotes), then the “Reason forabsence of calling party name” is set to “unavailable”.

• ISAM Voice allows to configure the primary source for the Calling Party Name i.e. from PAI SIP URI Display Name or from SIP URI Display Name.

• The Privacy header with value “id”, “user”, “header” is used for Calling Party Number/Name restriction. Number only, Name only, both Number and Name restriction are configurable by ISAM Voice.

• Privacy header with value “none” means that CLI is not forbidden by Privacy header. Whether CLI is presented or not still depends on the CLIP subscription status.



• Configurable “Number display format”:ISAM Voice support several number display formats:

• Countries requiring International and National number format:- international number format: <international access code> <country code> <national number>

- national number format:<national number> or<national access code> <national number>

• Countries requiring International, National and Area/Local number format:- international number format:<international access code> <country code> <national number>

- inter area number:<national access code> <national number>

- area/local number:<area/local number>

• ISAM Voice allows to distinguish the following number display modes:• display number restricted• display number• display number not available • no display (no subscription to CLIP)

• Release Control Procedure:ISAM Voice support the services:

• Called Subscriber Held (a.k.a re-answer), • Calling party hold by emergency operator, • Other calls to/from non-emergency operators for which to hold • Calling party hold for malicious calling indication in compliancy with the call flow

diagrams documented in NICC ND1021 (v.0.13.1), chapter E.2.7 & E.2.8 (support of INVITE 'no ring').

• Audible Message Waiting Indication:ISAM Voice supports the service “Audible Message Waiting Indication”, providing a stutter dial tone should a message be waiting.

• Fixed line SMS service:• ISAM Voice supports the “Fixed line SMS” service in compliancy with SIN413

“Fixed Line SMS”• As to be able to make use of this service, the termination needs to install an SMS

enabled terminal (SM-TE). • Once the call between the SM-TE and SM_SC has been successfully established,

either SM-TE or SM-SC will initiate the FSK data transmission in compliancy with ETSI EN 300 659 -2 (Off-hook data transmission).

• The TE-alerting signal (TAS) is used to signal that data-transmission shall be carried. Upon the receipt of the TAS (line side & IP side), the ISAM Voice switches to VBD mode.

• Only the Dual Tone TE-alerting signal can be used for off-hook data transmission, as is specified in EN 300 659 - 1 (On-hook data transmission).



Registration procedure

The registration of the SIP terminations is done:

• From a system perspective: by all SIP UAs in parallel.• From a SIP UA perspective: on individual SIP termination basis, in a sequential

way corresponding to the order that the SIP terminations become administratively enabled.

• From a voice LT board (system) recovery perspective: the SIP UA calculates the registration time for each individual SIP termination randomly within a fixed registration time frame ranging from [0…60] s.

Supplementary services

Supplementary services are widely used in traditional PSTN networks. When customers consider migrating from a TDM network to a NGN network, they expect feature parity to support legacy services.

Megaco: POTS service

The following is a list of representative POTS supplementary services that are available via the ISAM-Voice working in conjunction with different vendor MGC products.

• three-Party Conference (3PTY)• Abbreviated Address/Dialling (AA)• Add-on Conference (CONF)• Administrative Call Barring (ACB)/ Bad Payer• Alarm Call (AC)• Announcement Connection • Anonymous Call Rejection (ACR)• Call completion to Busy Subscriber (CCBS) / Ring Back• Calling Line Identification Presentation (CLIP)• Calling Line Identification Presentation Analog (CLIP-A)• Calling Line Identification Rejection (CLIR)• Call Forwarding Unconditional (CFU)• Call Forwarding on Busy (CFB)• Call Forwarding on No Reply (CFNR)• Call Forwarding to Fixed Announcement (CFFA)• Voice Mail• Call Forwarding to Voice Mail (CFVM)• Call Hold (HOLD)• Call Pick-UP (CPU)• Call Return (CR)• Call Waiting (CW)• CWID service• Call Waiting Originating• Coin box (CB)



• Connected Line Identification Restriction (COLR)• Distinctive Ringing• Do Not Disturb (DND)• Explicit Call transfer (ECT)• Fixed Destination Call (FDC) / Hotline• General Deactivation (GD)• Incoming Call Barring (ICB)• Inhibition of Incoming Forwarded Calls (IIFC)• Lawful Interception (LI)• Line Hunting (LH)• Malicious Call Identification (MCID)• Message Waiting Indication (MWI)• Numbering Plan and Dialed Digits• Outgoing Call Barring (OCB)• Outgoing Call Screening (OCS)• Special Dial Tone• Warm Line• Call Park• Last Call return

Megaco: ISDN service

The following is a list of representative ISDN BA supplementary services that are available via the ISAM-Voice working in conjunction with different vendor MGC products.

• three-Party Conference (3PTY)• Abbreviated Address/Dialling (AA)• Alarm Call (AC)• Call completion to Busy Subscriber (CCBS) / Ring Back• Change password• Calling Line Identification Presentation (CLIP)• Calling Line Identification Rejection (CLIR)• Calling Line Identification Rejection Override (CLIR-O)• Call Forwarding Unconditional (CFU)• Call Forwarding on Busy (CFB)• Call Forwarding on No Reply (CFNR)• Call Hold (HOLD)• Call Waiting (CW)• CWID service• Connected Line Identification Presentation (COLP)• Connected Line Identification Restriction (COLR)• Distinctive Dialing In (DDI)• Do Not Disturb (DND)• Fixed Destination Call (FDC) / Hotline• Incoming Call Barring (ICB)



• Inhibition of Incoming Forwarded Calls (IIFC)• Malicious Call Identification (MCID)• Outgoing Call Barring (OCB)• Sub Addressing (SUB)• Terminal Portability (TP)

SIP: POTS service

The following is a list of representative POTS supplementary services that are available via the ISAM-Voice working in conjunction with the ALU IMS R7 / 5420 CTS R5 products. More extensive treatment of the supplementary services supported is available in the associated ALU IMS documentation.

• three-Party Conference (3PTY)• Abbreviated Address/Dialling (AA)• Anonymous Call Rejection (ACR)• Call completion to Busy Subscriber (CCBS) / Ring Back• Calling Line Identification Presentation (CLIP)• Calling Line Identification Rejection (CLIR)• Call Forwarding Unconditional (CFU)• Call Forwarding on Busy (CFB)• Call Forwarding on No Reply (CFNR)• Voice Mail• Call Hold (HOLD)• Call Pick-UP (CPU)• Call Waiting (CW)• CWID service• Distinctive Ringing• Do Not Disturb (DND)• Explicit Call transfer (ECT)• Fixed Destination Call (FDC) / Hotline• Malicious Call Identification (MCID)• Outgoing Call Barring (OCB)• Selective Call Forwarding (SCF)• SIP Authentication Registration• Special Dial Tone• Music On Hold

8.21 BITS Support

An accurate synchronization is mandatory for the voice service, especially for voice-band-data services and ISDN services. The 24Gbps NT or the ERAM-A with BITS variant can be connecting by an external BITS clock or using its integrated BITS module (< 5ppm) to reach a decent quality voice quality. The NT boards without BITS module (50ppm) are not valid and are not permitted for voice application.



8.22 Narrowband Line Testing

Megaco ISAM VoiceFull MTA is supported for both POTS and ISDN BRI lines.

Integrated narrowband line testing is supported for POTS lines LT only.

For further details, see chapter “Line testing features”.

ISDN-BRI lines support ISDN BA loopback test with test pattern:

• Complete loopback with test pattern:• Loopback of full bit stream (B1 and B2 and D channel)

• Loopback at ISDN LT and NT/NT1:• Self test on layer 1 by the ISAM Voice: ISAM Voice generates a test pattern,

activates a loopback at the LT, and verifies and evaluates the received test pattern.• Test towards the NT/NT1: ISAM Voice generates a test pattern, activates a

loopback at the NT, and verifies and evaluates the received test pattern.

SIP ISAM VoiceFull MTA is supported for POTS lines

Integrated narrowband line testing is supported for POTS lines LT.

For further details, see chapter “Line testing features”.

8.23 Termination local loop unbundling

ISAM Voice with FD-Combo ETSI practice has been optimized for the combo service deployment (combined PSTN and xDSL services).

In such a situation it might be possible that subscribers desire to have the xDSL service provided by a different service provider than the integrated voice service.

This can be achieved through a correct configuration of the Local Loop Unbundling relay (configurable on a per subscriber basis).

The default setting of the LLU relay is that there is only a straight connection of the subscriber copper pair to the Voice LT.

Megaco ISAM VoiceLocal loop unbundling is supported.

SIP ISAM VoiceLocal loop unbundling is supported.



8.24 Subscriber Line Showering

In case the amount of on-hook and/or off-hook events for a particular subscriber line exceeds 20 events / minute, the subscriber line will be put in Line Showering state, meaning that all subsequent events still occurring on this subscriber line will be ignored by the system; the subscriber is not able anymore to make outgoing calls nor is the subscriber able to receive terminating calls.

Also from a narrowband line test perspective, when in showering state, the subscriber line is observed as being out-of-service.

Once the amount of on-hook and/or off-hook events decreases to less than 10 events per minute, the system will put the subscriber line back into normal operation state.

The upper and lower event thresholds are not configurable, neither in the CDE profile nor in the MIB.

8.25 Lawful Intercept

Overall Lawful Intercept strategyThe global Lawful Intercept (LI) solution complies with the international standardization definition of ETSI TISPAN WG7 and ES 201 671(ETSI TC LI). LI is considered to be fully transparent for ISAM Voice access node:

• Voice packet replication is assumed to be done by external equipment situated in the voice network.

• The control path is assumed to provide the IP address of the external equipment as the destination address of the bearer channel.

Megaco ISAM Voice: External Packet Forwarding (EPF)In order to support Lawful Intercept, voice traffic exchanged between 2 voice termination points must be intercepted by an interception point (CCIF & IRIIF) prior to receipt at the destination voice termination point.

In the feature described hereafter, the interception point is situated outside the ISAM Voice access node, further upstream in the customer's voice network.

Obviously, all voice traffic originating at an ISAM Voice access node and destined to either a termination point connected to the same ISAM Voice access node, or a termination point connected to an ISAM Voice access node that subtends to the originating ISAM Voice, or a termination point connected to a remote ISAM Voice access node, or a termination point that resides outside the ISAM Voice cluster, must be brought outside of the originating ISAM Voice access node as to allow this voice traffic to be tapped to the Lawful Intercept device.



To serve such Lawful intercept topology, Megaco ISAM Voice allows enabling the External Packet Forwarding facility. In addition, the EPF facility requires the IP address of the external device to which the voice traffic is to be forwarded as a configuration input. The external destination device must be directly connected to the ISAM Voice.

When EPF is enabled, all voice traffic that originates from a voice termination point A connected to the ISAM Voice and destined to a voice termination point B, either connected to the same ISAM Voice, or connected to an ISAM Voice that subtends to the former ISAM Voice, or connected to an ISAM Voice that together with the former ISAM Voice subtends to the same Hub ISAM Voice, or to an ISAM Voice connected by means of a layer 2/layer 3 aggregation network with the former ISAM Voice, is forwarded in upstream direction to the external device as being pointed to by the configured IP address prior to the downstream forwarding to the destined voice termination point.

The same forwarding principle as mentioned before, applies when either voice termination point A or voice termination point B becomes replaced by the Voice server due to the support of some supplementary services or the support of an optimized IP addressing scheme.

Figure 8-100 Megaco ISAM Voice: External Packet Forwarding enabled

Note — External packet Forwarding must not be enabled for H.248 L2/L3 addressing topologies with IP Subnet and/or IP Address reduction properties.

Main node

NT board


board

Voiceserver

Remote node

L2aggregation

network

MGC ASP

SoftSwitch

Voice LTboard

NT board


Subtending node

NT board


board

Remote node

Voice LTboard

NT board


L3aggregation

network

SignalingIP address

XLESIP address

Edge Router serves as "external device" from where the voice traffic

is tapped to the LI device



Figure 8-101 Megaco ISAM Voice: External Packet Forwarding disabled

8.26 Compliancy to standards

ISAM Voice is fully/partially compliant to the following standards (further details are provide in the related Protocol Information Compliancy Sheets (PICS documents)):

Megaco ISAM Voice

• RFC768, RFC791, RFC792, RFC826, RFC894, RFC919, RFC920, RFC950, RFC1157, RFC2327, RFC2960, RFC3057, RFC3389, RFC3550, RFC4734

• IEEE Std 802.3, IEEE Std 802.1Q, IEEE Std 802.1P• ITU-T Study Group 16: H248.1v2, H248.1v3 annex E, H248.1v3 annex F,

H248.2, H248.3, H248.8, H248.11, H248.14, H248.16, H248.23, H248.26, H248.27, H248.34, H248.45

• RFC2960, RFC4233• ITU-T Study Group II: Basic Call Progress Tones Generator with Directionality,

Expanded Call Progress Tones Generator Package, Basic Services Tones Generation Package.

• ITU-T Recommendation Q.921, ITU-T T.38 Recommendation Fax over IP, ITU-T recommendation V.23 (FSK), ITU-T recommendation Q.552: Transmission characteristics at a 2-wire analogue interface of digital exchanges

• ITU-T I.603 SERIES I: INTEGRATED SERVICES DIGITAL NETWORK (ISDN) Maintenance principles; Application of maintenance principles to ISDN basic accesses

Main node

NT board


board

Voiceserver

Remote node

L2aggregation

network

MGC ASP

SoftSwitch

Voice LTboard

NT board


Subtending node

NT board


board

Remote node

Voice LTboard

NT board


L3aggregation

network

SignalingIP address

XLESIP address



• Telcordia Bell 202 (FSK)• ETSI EN 300 659-1 V1.3.1 DTMF for on-hook data transmission• ETSI EN 300 659-1 V1.3.1, ETSI EN 300 659-2 V1.3.1, ETSI EN 300 659-3

V1.3.1: Subscriber line protocol over the local loop for display (and related) services.

• ETSI EMC 300 386 v1.3.1: Electromagnetic Compatibility Requirements• Telcordia recommendation GR-30 LSSR: “LSSR: Voice band Data Transmission

Interface (FSD 05-01-0100)”, 1998• Calling Line Identification service SIN 227, issue 3.2. British Telecom

specification, 2002

SIP ISAM VoiceRFC768, RFC791, RFC792, RFC950, RFC919, RFC920, RFC2131, RFC2327, RFC2833, RFC2976, RFC3261 (ETSI TS102 027-1), RFC3262, RFC3263, RFC3264, RFC3311, RFC3323, RFC3325, RFC3389, RFC3515, RFC3550, RFC3551, RFC3665, RFC3725, RFC 3842, RFC3891, RFC3892, RFC3959, RFC3960, RFC4028, RFC4780, RFC5009.



8.27 ISAM Voice migration

Off-line SW MigrationThe ISAM Voice uses the ISAM offline migration procedure, that is, the integrated voice service databases and related CDE profiles are considered to be an integral part of the ISAM offline database migration (next to the NT and SHub databases). This implies that at SW migration time:

• The integrated voice service databases and related CDE profiles are uploaded to the migration server offline migrated via the Push Button Migration Tool.

• The offline migrated integrated voice service database and associated CDE profiles are downloaded to the ISAM and activated together with the new SW package.

Megaco ISAM Voice

An “Upgrade/Migration cluster” is the aggregation of all ISAM Voice clusters served by a hub ISAM Voice node, this hub ISAM Voice node included.

In order for the integrated voice service to work correctly, the same SW package must be downloaded to all ISAM Voice nodes of an ISAM Voice cluster, that is, in particular with focus on the integrated voice service, the SW (maintenance) Release on the voice LT boards must be the same as the SW (maintenance) release on the Voice server and this for the complete ISAM Voice cluster.

The same applies within one ISAM Voice node. Only one SW (maintenance) Release can be active at an ISAM Voice node at the same time.

This implies that all Voice server pairs in the hub ISAM Voice node must run the same SW (maintenance) Release. As a consequence, for the integrated voice service to work, all ISAM Voice nodes within the same upgrade/migration cluster must be on the same SW (maintenance) release.

The above rules imply that for both a SW upgrade and a SW migration, the upgrade/offline migration procedure for the full upgrade/migration cluster must be completed in a single maintenance window.

Note — The following restriction applies:

All Voice servers equipped in a hub ISAM Voice node are supervised by one and the same Voice Service Provider.



Figure 8-102 Voice upgrade/migration cluster (centralized topology)

Figure 8-103 Voice upgrade/migration cluster (distributed topology)

Upgrade / Migration Cluster

Main ISAM Voice Node

VoiceServerPair 1

VoiceServerPair 2

VoiceServerPair 3

VoiceServerPair 4

VoiceServerPair 5

VoiceServerPair 6

VoiceServerPair 7

VoiceServerPair 8

VoiceCluster 1

VoiceCluster 2

VoiceCluster 3

VoiceCluster 4

VoiceCluster 5

VoiceCluster 6

VoiceCluster 7

VoiceCluster 8

Voice Upgrade / Migration Cluster concept in the context of a Centralised Voice Topology.

LTsNon-mainnode 1a

LTsNon-mainnode 1b

LTsNon-mainnode 1x

LTsNon-mainnode 2a

LTsNon-mainnode 2b

LTsNon-mainnode 2x

LTsNon-mainnode 3a

LTsNon-mainnode 3b

LTsNon-mainnode 3x

LTsNon-mainnode 4a

LTsNon-mainnode 4b

LTsNon-mainnode 4x

LTsNon-mainnode 5a

LTsNon-mainnode 5b

LTsNon-mainnode 5x

LTsNon-mainnode 6a

LTsNon-mainnode 6b

LTsNon-mainnode 6x

LTsNon-mainnode 7a

LTsNon-mainnode 7b

LTsNon-mainnode 7x

LTsNon-mainnode 8a

LTsNon-mainnode 8b

LTsNon-mainnode 8x

Upgrade /Migration Cluster 1Main ISAM

Voice Node 1

VoiceServer

Pair

VoiceCluster 1

LTsNon-mainnode 1a

LTsNon-mainnode 1b

LTsNon-mainnode 1x

Main ISAMVoice Node 2

VoiceServer

Pair

VoiceCluster 2

LTsNon-mainnode 2a

LTsNon-mainnode 2b

LTsNon-mainnode 2x


VoiceServer

Pair

VoiceCluster 3

LTsNon-mainnode 3a

LTsNon-mainnode 3b

LTsNon-mainnode 3x


VoiceServer

Pair

VoiceCluster 4

LTsNon-mainnode 4a

LTsNon-mainnode 4b

LTsNon-mainnode 4x


VoiceServer

Pair

VoiceCluster 5

LTsNon-mainnode 5a

LTsNon-mainnode 5b

LTsNon-mainnode 5x


VoiceServer

Pair

VoiceCluster 6

LTsNon-mainnode 6a

LTsNon-mainnode 6b

LTsNon-mainnode 6x


VoiceServer

Pair

VoiceCluster 7

LTsNon-mainnode 7a

LTsNon-mainnode 7b

LTsNon-mainnode 7x


VoiceServer

Pair

VoiceCluster 8

LTsNon-mainnode 8a

LTsNon-mainnode 8b

LTsNon-mainnode 8x

Upgrade /Migration Cluster 2







Voice Upgrade / Migration Cluster concept in the context of a Distributed Voice Topology.



Megaco ISAM Voice Backwards Compatibility in the Migration Scenario

Under the conditions and constraints as stipulated in the section below, ISAM Voice indeed strives for backwards compatibility between releases, starting from R4.0v onwards, in that any next voice release after R4.0v will take backwards compatibility into account. I.e. both the R4.0v maintenance releases and the R4.1v releases (main and maintenance) will take into account backwards compatible with R4.0v.

Disclaimer: Alcatel-Lucent, though remaining confident that this might be a rare case, is not in a position to guarantee backwards compatibility at all time, as, due to new feature introduction or problem resolution reasons, Alcatel-Lucent can be forced to break the backwards compatibility in a certain release, even under the conditions and constraints as stipulated below. In case of such happening, the customer will be informed by Alcatel-Lucent, clearly specifying the reasons why the backwards compatibility had to be broken and the related consequences for the customer. Also, Alcatel-Lucent will recover the backward compatibility on the earliest successive release possible.

Conditions and restrictions:

Backwards compatibility over ISAM Voice releases is considered:

• Between a main release and its maintenance releases (e.g. R4.0v and R4.0.02c), starting from R4.0v onwards

• Between 2 releases of 2 consecutive release streams (e.g. R4.0.03d and R4.1.02c), starting from R4.0v onwards

• From the xVPS pair to the voice boards, i.e. it is assumed the voice boards are always at a lower or equal release then the xVPS pair, but never at a higher release

This ISAM Voice backwards compatibility has the following restriction:

• New services, as part of the newly introduced release, might not work as long as there is more then one release active in the network.

ISAM Voice backwards compatibility is supported only at following conditions:

• At any time there are no more then 2 different releases in the network, being main or maintenance releases of consecutive release streams

• Having 2 releases in the network can last for at most 2 weeksFailing to do so will not only block any roll-out of new services in the customer's network, but will also make it impossible to guarantee tracking and fixing problems in the voice network

• Before an upgrade or migration is started to a next release, all ISAM Voice access nodes in the network must be at the same release (main or maintenance)

SIP ISAM Voice off-line SW migration

Since the scope of the Voice upgrade/migration cluster principle is restricted to a single ISAM access node, an upgrade/migration of a SIP ISAM Voice access node follows exactly the upgrade and offline migration procedure for an ISAM access node.



H.248 to SIP functional MigrationISAM Voice allows a voice access node / voice cluster being deployed in an H.248 based integrated voice service mode, to migrate to a SIP based integrated voice service deployment.

The following restrictions apply:

• It is not allowed that such a H.248 to SIP functional migration coincides with either a SW upgrade or a off-line SW migration or a Switching to Routing functional migration (see next chapter).

• The target migration SIP architecture is the centralized architecture.• A complete voice cluster is functionally migrated in one maintenance window.• Distinct VLANs for signaling and RTP traffic.• The same VLAN is used to carry RTP traffic in H.248 and SIP mode.• The same VLAN is used to carry signaling traffic in H.248 and SIP mode.• The same VLAN is used to carry OAM traffic in H.248 and SIP mode.

The main logical steps to be taken in the H.248 to SIP functional migration are:

1 Configure the SIP voice database

2 Check the ongoing calls and the emergency calls for graceful shutdown

3 Lock the H.248 MGI interface

4 Disconnect the Voice server at L2 from the voice LT boards

5 (re-)Configure the L2/L3 topology to run in SIP mode

6 Unplan the voice LT boards (configured with capability profile = H.248-profile)

7 Replan the voice LT boards with capability profile = SIP-profile

8 Reload the voice LT board with the SIP SW package

9 Perform a SIP voice database NT-LT audit

10 Register the SIP terminations

11 Verify the SIP-based voice service

12 Unplan the Voice server (the Voice server must be kept running till the verification has proven that the SIP-based voice service behaves correctly)

Switching to Routing functional MigrationISAM Voice allows a voice access node/voice cluster being deployed in a switched mode (NT behaving as switching device) to migrate to a routed mode (NT behaving as routing device).

The switching to routing functional migration applies to both an ISAM Voice access node deployed in H.248 mode and an ISAM Voice access node deployed in SIP mode.



The following restrictions apply:

• A functional migration from switching mode to routing mode may NOT coincide with:

• a SW upgrade• an off-line SW migration• a H.248 to SIP functional migration.

• ISAM Voice does not support the functional migration of a subtending access node. In other words, the subtending access node behaves at all times as a switched device.

• The same signaling VLAN ID remains used at the IACM part of the ISAM Voice before and after the migration from switching device to routing device.

• The same RTP VLAN ID remains used at the IACM part of the ISAM Voice before and after the migration from switching device to routing device.

• The same source / destination signaling IP address remains configured at the xVPS (H.248) / SHub (SIP).

• The same source / destination RTP IP address remains configured at the xVPS (H.248) / SHub (SIP and H.248).

The main logical steps to be taken in the switching to routing functional migration are:

1 Configure the routing protocol (OSPF / RIP)

2 Optionally, configure the static routes

3 (re-)Configure L2/L3 topology to run in route mode.

4 Reset the NT board pair.


9 — Layer 2 forwarding


9.2 The concept of Virtual LAN (VLAN) 9-2

9.3 ISAM Internal Architecture 9-8

9.4 Support for Jumbo frames 9-13

9.5 Subscriber access interface on the LT board 9-13

9.6 iBridge mode 9-16

9.7 VLAN cross-connect mode 9-29

9.8 Protocol-aware cross-connect mode 9-40

9.9 IPoA cross-connect mode 9-44

9.10 Secure forwarding in iBridge and VLAN cross-connect 9-46

9.11 Virtual MAC 9-49

9.12 PPP Cross-connect mode 9-54

9.13 IP-aware bridge mode 9-57



9.1 Introduction

This chapter focuses on L2 forwarding, consistent with the standards of the Electrical and Electronics Engineers (IEEE).

Concretely in the ISAM this involves the iBridge and VLAN cross-connect forwarding mode.

9.2 The concept of Virtual LAN (VLAN)

VLANs are standardized by the Institute of Electrical and Electronics Engineers (IEEE) in 802.1q (VLAN basic concept) and the 802.1ad/D6.0 (VLAN stacking).

VLAN tagging in IEEE 802.1q

Tagging of an Ethernet frame consists of adding a IEEE 802.1q tag of four bytes that specifies the VLAN ID and the priority (from 0 to 7) that indicate the QoS class. Table 9-1 shows the frame types used with their properties.

Table 9-1 Frame types

Figure 9-2 shows an untagged and a tagged/priority-tagged Ethernet frame.

Note 1 — Strictly speaking, only iBridge and Vlan cross-connect forwarding modes can be considered as L2 forwarding in term of IEEE context. For practical reasons however, this chapter will also cover two additional forwarding modes not really part of L2 forwarding family but still closely related: PPP cross-connect forwarding and IP-aware bridging.

Although PPP cross-connect mode has distinctive differences with iBridge and VLAN cross-connect, it has also similarities. For more information, see section 9.12.

In the IP-aware bridge mode, the ISAM can be an “IP-aware bridge” without being an IP next-hop. Subscribers connected to the ISAM are seen as being directly attached to the edge router IP interfaces. This mode is Alcatel-Lucent proprietary and is a kind of hybrid between layer 2 and layer 3 forwarding. For more information, see section 9.13.

Note 2 — The support of IP-aware bridging will be discontinued in the future. The use of IP-aware bridging is unadvised for new deployments.

Property Tagged frame Priority-tagged frame

Untagged frame

Carries 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 9-1 Untagged and tagged/priority-tagged Ethernet frames

VLAN Tagging as a means to support Virtual LAN (VLANThe use of VLAN Tagging on Ethernet frames has allowed the co-existence of a multiplicity of Virtual LANs (VLANs) which are logically isolated from each other although sharing the same physical infrastructure. Each VLAN is only aware of the Ethernet Frames tagged with the specific VLAN tag of this VLAN.

By using the frames VLAN tags as VLAN discriminator, end-stations and frame forwarders within a given VLAN have no contact with end-stations or frame forwarders operating in another VLAN even when they share the same physical infrastructure. Figure 9-2 shows an example of VLANs.

Figure 9-2 Example of VLAN

In general the VLAN is shared between a group of several end-stations, forming a meshed configuration. In some special cases, the VLAN is used in a strict point-to-point configuration between two end-stations. Within a VLAN, frame forwarding takes place at layer 2 (L2) by using Ethernet-related information.

The ISAM supports the VLAN concept applied to access networks.

preamble SFDdestaddr

srcaddr

lengthtype

data + pad FCS

7 1 6 6 2 46…1500 4

802.1qtag

VLANtag

MAC clientlengthtype

FCS

7 1 6 6 2 2 2 46...1500 4

(priority-)tagged frame

Untagged frame

preamble SFDdestaddr

srcaddr

data + pad

VLAN B

VLAN C

VLAN A

Backbone

Switch

Switch

1

87

65

43

2

91

87

65

43

2

9



Usage of VLANs in access networks

In the access network, each NSP operates in a dedicated VLAN. The role of the ISAM is to attach every subscriber to the NSP(s) of their choice, that is, to the corresponding VLAN(s).

Network side

Frames coming from the upstream Ethernet network are generally tagged, each tag being typical of a given NSP. The frame VLAN tag determines the VLAN the frame belongs to and the way the ISAM should forward it to the subscriber, via iBridge mode or VLAN cross-connect mode. Untagged frames can also be received from the network interface, for example when the ISAM is directly connected to an NSP IP router. In this case, a port-based default VLAN is required on the network interface.

Subscriber side

On an ADSL link carrying PVCs, the subscriber accesses different NSPs by using one PVC per NSP. On a PVC frames are typically untagged (in some rare network deployments, frames could also be priority tagged).

When the ISAM receives untagged frames or priority-tagged frames from the subscriber, a port default VLAN (or port-and-protocol-based default VLAN) determines the NSP VLAN on the network side to which the frame must be forwarded (more on this in section “Forwarding of untagged/priority-tagged frames received from the subscriber”).

Although not typical, tagged frames can also be used on PVCs to allow multiplexing several services on the same PVC.

When the ISAM receives tagged frames, the frame tag is used to determine the NSP VLAN to which the frame should be forwarded. User frames received with an unexpected tag are discarded. Figure 9-3 shows an example.

Figure 9-3 Example of PVCs used on ADSL links

ADSL link 1

PVC 0,32default VLAN 100

ADSL link 2

PVC 0,34VLAN 102

PVC 0,33default VLAN 101

PVC 0,34default VLAN 100VLAN 101, 102

NE



Figure 9-3 shows two ADSL links:

• ADSL link 1 with 3 PVCs:• PVC 0,32 accepts untagged packets, priority-tagged packets, and packets with

VLAN ID 100• PVC 0,33 accepts untagged packets, priority-tagged packets, and packets with

VLAN ID 101• PVC 0,34 accepts tagged packets, with VLAN ID 102

• ADSL link 2 with 1 PVC:• PVC 0,34 accepts untagged packets, priority-tagged packets, and tagged packets

with VLAN ID 100, 101 and 102

We have seen that for ATM-based DSL lines, one separate PVC per service (and per NSP) is deployed and the frames between the ISAM and CPE are typically untagged. Each PVC is related to a NSP VLAN in the aggregation network and vice versa. However, this is not possible for VDSL and point-to-point Ethernet accesses since this is based on EFM technology. Hence, tagged traffic on VDSL and point-to-point Ethernet subscriber access lines becomes the rule, with each VLAN identifying a given NSP.

Multi-VLAN tagged subscriber traffic over VDSL and point-to-point Ethernet subscriber access lines is actually the equivalent of multi-PVC over ATM-based DSL lines.

Point to multipoint configuration (1:N) and point to point configurations (1:1)

The ISAM allows two L2 access modes, respectively the 1:N and the 1:1 mode:

• In the 1:N mode, the ISAM allows the NSP network VLAN to be shared by a group of N subscribers. This is done by means of the iBridging forwarding mode (also called Residential Bridging)

• In the 1:1 mode, the ISAM allows the NSP network VLAN to be shared by only one subscriber. This is done by means of the VLAN cross-connect forwarding mode.

Generic forwarder model in ISAM

The ISAM uses a generic L2 forwarding model directly mapping to the VLAN concept. In this model, the ISAM associates to every NSP a dedicated L2 forwarder i.e. an iBridge or a VLAN cross-connect. Each L2 Forwarder operates in the context of a dedicated VLAN on the network side.

Further, the ISAM uses the following notions on the user side:

• Bridge port:a bridge port is a generic Ethernet interface on the user side. In practice, a bridge port can be an Ethernet PVC, an EFM link or a physical user Ethernet link. A bridge port can carry a mix of untagged, priority-tagged or tagged frames.

• VLAN port:a VLAN port is a generic Tagged Ethernet interface on the user side. In practice, a VLAN port results from the association of a VLAN ID and a bridge port. So a VLAN port is the ISAM entry point for user Ethernet traffic tagged with the



corresponding VLAN ID on the corresponding bridge port. Tagged frames received by the ISAM which cannot be related to a configured VLAN port are discarded.

• Port Default VLAN ID (PVID):A bridge port can be configured with a PVID. The PVID has only relevance for iBridging or VLAN cross-connect. It is the VLAN ID which untagged or priority-tagged traffic should inherit from this bridge port when subjected to iBridging or VLAN cross-connect. In that case, untagged frames are considered by the ISAM “as if” tagged by the user with the PVID. See more details in section “Forwarding of untagged/priority-tagged frames received from the subscriber”.

From a black box point of view, the operator needs to create an NSP Network VLAN. Then, attaching a subscriber to an NSP is done by associating a subscriber VLAN port to the NSP Network VLAN.

An interesting feature of this generic L2 forwarding model is that it does not impose that the VLAN port has the same VLAN ID as the NSP VLAN to which it is attached.

This allows the possibility of VLAN translation by which subscribers can access an NSP using frames tagged with another VLAN than the NSP VLAN. Obviously, de-coupling network VLAN from user VLAN allows more flexibility in terms of network deployment.

The need for VLAN translation becomes apparent when comparing with the familiar multi-PVC model in ATM-based aggregation networks.

In the multi-PVC model, each PVC must be given a VPI/VCI value on the access link. To facilitate provisioning, these VPI/VCI values are often chosen to be the same for all subscribers to a given service, for example 8/35 for HSI. These subscriber-side Virtual Channel Links (VCLs) are then cross-connected to VCLs at the network side with different VPI/VCI values.

In the multi-VLAN context, the same reasoning applies. Provisioning can be simplified by using the same C-VLAN IDs at the subscriber side for all subscribers. These subscriber-side C-VLANs indicate the service. For S+C-VLAN CCs, (see section “S+C-VLAN cross-connect: VLAN stacking for residential subscribers”) the network side C-VLAN IDs are typically used to identify the subscriber, with the S-VLAN identifying the service.

Hence a subscriber-side VLAN ID can have a local significance, which means that the user VLAN ID is just used to select a particular forwarding context. Then, the subscriber-side VLAN ID is stripped from the packet, the forwarding decision is made, and a new network-side VLAN ID is supplied with the packet when it is transmitted on the network interface.

As indicated in previous sections, although multi-VLAN originally came from the requirement to support multi-services above VDSL and point-to-point Ethernet subscriber access lines, some customers may want to use multi-VLAN on top of PVC for ADSL as well.

Doing so can be interesting to create a uniform network configuration, or to alleviate some possible CPE limitation.



To limit the configuration complexity of ADSL lines, the operator must however make a decision per ADSL line and segregate services either via PVCs or via VLANs. In the latter case, a single PVC will carry all the different VLANs.

Figure 9-4 shows an example of multi-VLAN and VLAN tag translation. In this example there are two VDSL access lines: EFM1 and EFM2. PVCs supporting multi-vlans are also shown. Note that this example applies to ADSL, VDSL and point-to-point Ethernet subscriber access lines.

Figure 9-4 Multi-VLAN and VLAN translation example

Note 1 — Multi-VLAN makes flexible wholesaling possible without impacting the CPE configuration. For example, starting from a set of predefined subscriber VLAN tags at the CPE side (say, the same values hard-coded in all CPEs), it is possible to re-tag the received packet with a new network VLAN tag, so that the traffic can be passed to the correct NSP for a specific service.

Note 2 — From R4.1 on, the restriction that one cannot attach two VLAN ports on the same bridge port to the same Layer 2 forwarding engine is removed.

VLAN_1

iBridge

MACFDB

VLANports

T

iBridge

Ethernet

Ethernet

Ethernet

Ethernet

Ethernet

Ethernet

Ethernet

Ethernet

Ethernet

VLAN_2

VLAN_3

VLAN_4

VLAN_5

PVC1_VLAN1

PVC2_VLAN1

EFM1_VLAN1

PVC1_VLAN2

PVC3_VLAN17

EFM2_VLAN2

EFM1_VLAN3

EFM2_VLAN34

EFM1_VLAN5

VLAN CC

VLAN CC

T

T

T

T

MACFDB

VLANports

NSP 1

NSP 2

NSP 3

NSP 4

NSP 5

EMAN ISAM

VLAN CC T

T

T

T



9.3 ISAM Internal Architecture

Layer 2 forwarding in ISAM is generally distributed over the LT boards and NT board in a two stage architecture. There may be also cases where only the NT board takes part in the Layer 2 forwarding - when users are directly connected to the NT board or when a subtending ISAM comes in the picture. This is shown in Figure 9-5.

Figure 9-5 Layer 2 Forwarding in ISAM

The basic strategy for the layer 2 forwarding data plane is that:

• When subscribers are connected to LT boards, the NT board forwards downstream frames to the proper LT board(s) and the LT board forwards downstream frames to the proper subscriber line/VLAN.

• It is the LT board that implements the difference between the VLAN cross-connect and iBridge mode. The NT board behavior is identical for iBridge and VLAN cross-connect.

• It is the LT board that takes care to translate user VLAN into network VLAN (optionally); the NT board does not perform VLAN translation.

Note — Figure 9-5 does not show the VLAN translation capability on the user side of the LT board.

NT

ISAM

LT

LT

Phy/LAG

Phy/LAG

L2 FwdrNSP A

L2 FwdrNSP A

L2 FwdrNSP B

L2 FwdrNSP A

L2 FwdrNSP B

L2 FwdrNSP B



• The NT board behaves as much as possible as a standard bridge. However, some restrictions may be required or desired for a consistent interworking with the specific LT boards forwarding modes, iBridge or VLAN cross-connect. User security and privacy may also require specific rules in the NT board, as further developed below.

• The NT board and the LT board behave as much as possible as two independent Layer 2 systems. For example, they both will learn and age independently on MAC addresses. Note that the ageing timer is independent in the NT board and the LT boards but for proper operation it should be configured identical. There is one ageing timer common for all LT boards.

Although the NT board is originally derived from a standard bridge, its behavior will typically be constrained to fit access network requirements such as for instance security and privacy. For that purpose the ISAM makes the distinction between ports facing users and ports facing the EMAN network side:

• Ports connected to subtending ISAMs, to LT boards or directly facing users instantiate the so-called “user side”. Such ports are considered untrusted.

• Ports connected to the EMAN or directly to service provider equipment (e.g. BRAS) instantiate the so-called “network side”. Such ports are considered trusted.

With the notion of User side and Network side, the NT has the capability to deviate from a normal standard bridge in particular in term of controlling traffic switching (or flooding) and controlling MAC address learning.

In typical network deployment, the NT board will be constrained such that

• Frames received from the network side can be passed:• back to the network side, possibly on the same physical interface but using another

VLAN (this is to support a ring). • to the user side (an LT board, a user, or a subtending ISAM).

• Frames received from the user side (an LT board, a user or a subtending ISAM) can only be passed to the network side.

Obviously, the NT board is VLAN aware. More specifically, every NT bridge instance operates within the context of a single distinct VLAN. Only tagged frames matching the VLAN of a bridge will be handled by that bridge. If the frame is multiple tagged, only the most exterior VLAN tag is used to determine whether the frame should be handled by a given bridge or not.

Another strategy employed to enable ISAM to participate in a maximum of network deployments scenarios is to subtend network elements (such as remote ISAM) directly from the LT, as shown in Figure 9-6.

Note 1 — The forwarding of broadcast frames or frames with unknown (unicast / multicast) destination MAC address will be based on these rules: flood to all allowed interfaces only.

Note 2 — The operator can enable communication from user side back to user side provided that both users are on different physical NT interfaces.



Figure 9-6 Subtended network elements

Such deployment scenario introduces the concept of User to Network Interface (UNI) and Network to Network Interface (NNI).

• A UNI is a reference point for all interactions between subscriber services and the ISAM.

• An NNI is a reference point for all interactions between a remote aggregator (business NTU, residential MDU, Ethernet switch, subtended ISAM, …) and the ISAM.

On the Hub-ISAM, the NNI subtending interfaces will support L2 forwarding dimensioning required to subtend an aggregation node (such as for example increased scaling for VLANs, multicast channels and MAC learning, …).

Detailed configuration models

iBridge configuration model

Figure 9-8 shows the iBridge configuration model.

NT

Subtended ISAM

LT

L2 FwderNSP A

L2 FwderNSP A

L2 FwderNSP B

L2 FwderNSP BNT

ISAM

LT

LT

L2 FwderNSP A

L2 FwderNSP A

L2 FwderNSP A

L2 FwderNSP B

L2 FwderNSP B

L2 FwderNSP B

UNI port

NNI port

UNI port



Figure 9-7 iBridge configuration model

To configure a bridge for a given VLAN in the NT, the operator needs to:

• Create the VLAN• Associate the proper network / LT / subtending / user interface to this VLAN.

VLAN cross-connect configuration model

The configuration of the NT board is the same as for the iBridge forwarding model, only the configuration of the LT board is different, as shown in Figure 9-8.

NT

ISAM

LT

LT

Phy/LAG

Phy/LAG

VLAN 19(= iBridge)

LT PortsNetwork Ports

RBVLAN 19

Network VLAN

RBVLAN 23

RBVLAN 19

RBVLAN 23

VLAN 23(= iBridge)



Figure 9-8 VLAN cross-connect configuration model

Note — The different types of VLAN cross-connect (C-VLAN, S+C-VLAN and S-VLAN) are explained further in this chapter.

NT

ISAM

LT

LT

C-VLAN CC

VLAN 19(=Bridge)

VLAN 13(=Bridge)

VLAN 17(=Bridge)

VLAN 11(=Bridge)

C11

VLAN CC

VLAN CC

S +C17 23

VLAN CC

S +C17 29

S13

VLAN CC

S+C-VLAN CC

S-VLAN CC

S+C-VLAN CC

C-, S+C- orS-VLAN CC

(No VLAN translationshown on user side)



9.4 Support for Jumbo frames

To take care of various encapsulation protocols overhead, Jumbo frames with 2048 bytes are supported in the data plane all over the ISAM, including all forwarding modes (iBridge, VLAN cross-connect, PPP cross-connect, VRF) and all Ethernet interface types. However, the final frame size will be constrained by the LT hardware limitation (the hardware of some LT boards cannot support more than 1580 bytes).

Figure 9-9 Support for Jumbo frames

9.5 Subscriber access interface on the LT board

The ISAM has the capability to receive user frames from ATM PVCs (ADSL), EFM (VDSL) or Ethernet Physical interfaces on the LT board.

Attaching subscribers to iBridges and VLAN cross-connect forwardersVLAN ports are always used to attach subscribers to iBridges and VLAN cross-connect, as shown in Figure 9-10.

This obviously applies to tagged Ethernet frames, but also to untagged Ethernet frames, via Port Default VLAN (PVID) and even to IPoA frames via the so-called Interworking Layer (IWL) located on the LT board. The IWL takes care to convert IPoA frames into IPoE frames; see section “Protocol-aware cross-connect mode” for more information.

Figure 9-10 shows the subscriber access interface model.

Edge

1 2 3, 4

3, 4

DA, SA

larger subscriber Ethernet payloadDSL linespecific

MPLS &other blue sky

Ethernet MAC

Ethernet MAC (with additional VLAN tags) larger subscriber Ethernet payload

Scope of jumbo frames: 1. To cope with more VLAN tags being added on network side2. To cope with additional encapsulating protocols, for example, MPLS on network side3. To cope with user having larger payload data4. NOT to cope with user having larger payload control

DA, SA, Qtags, Type/Length, FCS

DA, SA, Qtags, type/length, FCS



Figure 9-10 Subscriber access interface model for iBridges and VLAN cross-connect

Attaching subscribers to PPP cross-connect forwardersThe interfaces that can be used to attach subscribers to PPP cross-connect forwarders - that is, the interfaces on which PPP client ports can be configured - are shown in Figure 9-11.

Figure 9-11 Subscriber access interface model for PPP cross-connect forwarder

Frame Encapsulation on PVCsATM PVCs are configured on top of the ATM-based DSL links. A maximum of eight PVCs can be configured per DSL link. AAL5 is used to transport frames over ATM PVCs.

When a frame is received on an PVC, the ISAM will try to determine whether the AAL5 frame carries:

• an IPoA frame• a PPPoA frame• an Ethernet frame

For this, the ISAM inspects the encapsulation of each received AAL5 frame and compares it with the encapsulation allowed on the PVC receiving the frame.

IPoAFrames

PVC

ATM

ADSLx

PPPoE or IPoEFrames

VDSLx

EFMPVC

ATM

ADSLx

Bridge port

VLAN port

Eth Phy

Bridge port

VLAN port (from PVID)Of frame tag or PVID if untagged frame

Managedby IWL

PPPoA or untagged PPPoEFrames on PVC

PVC

ATM

ADSLx

Tagged PPPoEFrames

VDSLx

EFMPVC

ATM

ADSLx

Bridge port

VLAN port

Eth Phy VDSLx

EFM

Eth Phy

Untagged PPPoEFrames on EFM or Eth Phy



The ISAM supports the following ATM AAL5 encapsulation types:

• LLC/SNAP bridged (Ethernet)• VC Mux bridged (Ethernet)• LLC/SNAP routed (IPoA)• VC Mux routed (IPoA)• LLC/NLPid (PPPoA) • VC Mux PPP (PPPoA)

The operator can configure each PVC in such a way that either one of the following encapsulation modes is allowed:

• one single encapsulation type only is allowed on the PVC. This is called static encapsulation mode. Only the frames matching this encapsulation will be accepted.

• several encapsulation types are allowed on the PVC. In this case, the PVC works in auto-detect encapsulation mode: the ISAM adapts itself to the encapsulation selected by the CPE. If the encapsulation of the received frame matches one of the allowed encapsulations, the frame is accepted. Otherwise, the frame is discarded. This mode allows the subscriber to change his CPE without requiring the operator to reconfigure the ISAM.

Auto-detect encapsulation possibilities

It is not possible to have a universal auto-detect function accommodating any frame format without ambiguity. Hence, several auto-detect modes have been defined, each one with a limited number of allowed encapsulations. When an operator wants a PVC to work in auto-detect mode, he can configure the PVC with one of the following modes:

• Autodetect_IP allows auto-detection of the following frame encapsulations:• LLC-SNAP-Routed (then it is for IPoA) or• LLC-SNAP-Bridge (then it is for IPoE) or• VCMUX-Routed (then it is for IPoA)

Note: VCMUX-Bridge cannot be detected in this mode since it is ambiguous with VCMUX-Routed when the IP address starts with 00 (hex)

• Autodetect_PPP allows auto-detection of the following frame encapsulations:• LLC-NLPID-PPP (then is for PPPoA) or• VCMUX-PPP (then it is for PPPoA) or• LLC-SNAP-Bridge (then it is for PPPoE) or• VCMUX-Bridge (then it is for PPPoE)

• Autodetect_PPPoA allows auto-detection of the following frame encapsulations:• LLC-NLPID-PPP (then is for PPPoA) or• VCMUX-PPP (then is for PPPoA)



• Autodetect_IPoE_PPP allows auto-detection of the following frame encapsulations:

• LLC-NLPID-PPP (then is for PPPoA) or• VCMUX-PPP (then is for PPPoA) or• LLC-SNAP-Bridge (then it can be for PPPoE or IpoE) or• VCMUX-Bridge (then it can be for PPPoE or IpoE)

Note: LLC-SNAP-Routed and VCMUX-Routed (i.e. for IPoA) cannot be detected in this mode.

9.6 iBridge mode

In iBridge mode, each NSP is connected to the ISAM at the network side by a dedicated VLAN. The ISAM supports up to 128 iBridges for layer 2 boards and up to 768 iBridges for layer 3 boards.

Depending on the port configuration and LT board type, iBridges accept tagged and/or untagged traffic for forwarding. For untagged traffic, the ISAM makes use of a default VLAN configured per port to identify the NSP VLAN. More details about default VLANs are provided in section “Forwarding of untagged/priority-tagged frames received from the subscriber”.

iBridges allows to connection of several subscribers to the same network VLAN.

iBridges also allow the connection of several hub-ISAM NNI ports to the same network VLAN.

General considerations on iBridges

DHCP option 82

iBridge supports the DHCP snooping features for DHCP Option 82 handling. Likewise, iBridge supports DHCPv6 snooping for the insertion of DHCPv6 Option 18 and Option 37. For more information on DHCP, see chapter “Protocol handling in a Layer 2 forwarding model” and chapter “Protocol handling in a Layer 3 forwarding model”.

Note — The auto-detect feature is aimed to cope with occasional CPE reconfiguration: when the ISAM detects a valid change of encapsulation, it will clear data related to PPP or DHCP sessions related to this PVC, if any is present. Also, it is possible that a few frames are lost during the transition.

Note — DHCP option 82 is not supported on traffic received on hub-ISAM NNI ports. The remote aggregator access node (connected to the hub-ISAM) will perform such function if required.



Network and subscriber ports

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

This behavior is also true when the iBridge mode is used to forward traffic from hub-ISAM LT NNI ports. All the upstream traffic will be sent towards the network and never to another NNI port.

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, ICMPv6 or DHCPv6) will be sent to all ports in a particular VLAN. In iBridge mode, broadcast traffic from the subscriber only goes to the network. Broadcast traffic from the network is either passed to all ports or blocked on the subscriber ports. This behavior can be configured per VLAN.

Also broadcast as a consequence of flooding, which happens with standard bridging when the MAC destination address is unknown or with multicast, is avoided in iBridge mode.

In the context of hub-ISAM LT NNI ports, all the NNI upstream broadcast traffic is sent towards the network and never to another NNI port. Broadcast from the network is passed to all the NNI ports. This behavior is not configurable for NNI ports.

Frame types

In iBridge mode, only the following frame types are accepted from the subscriber ports:

• IP over Ethernet (IPoE) (IPv4)/ARP/Reverse Address Resolution Protocol (RARP)

• IPv6 over Ethernet (IPv6oE), including Neighbor Discovery and ICMPv6

• PPPoE (discovery and session)• PPPoE relay• IPoE (IPv4)/ARP/RARP/PPPoE (discovery and session)• IPoA (per enhanced iBridge) (for IPv4 only)• all Ethernet types• Extensible Authentication Protocol Over LAN (EAPOL):

EAPOL frames are dedicated packets that are never forwarded but are processed by the ISAM.

Other frames, including multicast data frames, will be discarded.

Note — Neighbor Discovery and ICMPv6 are identified by a Next Header value of 58 in the immediately preceding IPv6 header



In the context of hub-ISAM LT NNI ports, in iBridge mode, only the following frame types are accepted from the NNI ports:

• IP over Ethernet (IPoE) (IPv4)/ARP/Reverse Address Resolution Protocol (RARP)

• IPv6 over Ethernet (IPv6oE), including Neighbor Discovery and ICMPv6 (note: Neighbor Discovery and ICMPv6 are identified by a Next Header value of 58 in the immediately preceding IPv6 header

• PPPoE (discovery and session)• PPPoE relay• IPoE (IPv4)/ARP/RARP/PPPoE (discovery and session)• IPoA (per enhanced iBridge) (for IPv4 only)• all Ethernet types• Extensible Authentication Protocol Over LAN (EAPOL)

EAPOL frames are dedicated packets that are never forwarded, but are processed by the ISAM.

Other frames, including multicast data frames, will be will be sent towards the network and never to another NNI port.

iBridge Deployment

In iBridge mode, the operator will avoid putting two ISAMs within the same network VLAN on the same Ethernet Metropolitan Area Network (EMAN) to reach the same NSP IP router.

Sharing the same VLAN between two ISAMs would allow inter-ISAM user-to-user traffic to by-pass the NSP, which is undesirable. Figure 9-12 details this misconfiguration:

• The Ethernet switch will learn all subscriber MAC addresses. If subscriber A can obtain the MAC address of subscriber C, then subscriber A can send traffic directly to subscriber C without the traffic going to the NSP IP router. This is direct user-to-user communication and should be prevented in iBridge mode.

• In such a configuration, an ISAM would receive all broadcast/flooded frames from any ISAM in the VLAN. This causes potential performance problems and should not be allowed in iBridge mode.

Figure 9-12 VLAN with two ISAMs

ISAM 1

ISAM 2

Not allowedNot allowed

VLAN

EMAN

NSP

NSP IP backbone

A

B

C



Hub-ISAM LT NNI iBridge deployment example

The ISAM supports the ability to subtend network elements (such as remote ISAM) directly from the LT. This is done, in this time frame, by using the NNI port type on the GE Ethernet line board.

As shown in Figure 9-13, by using the iBridge mode on the NNI ports, the operator can leverage the Hub-ISAM access aggregation capabilities in order to aggregate traffic towards the EMAN network.

Figure 9-13 Hub-ISAM with iBridge

MAC learningIn the ISAM, each layer 2 forwarder has its own MAC learning process, independent from the other layer 2 forwarders. In other words, the text in the section below as to be understood “within the same network VLAN context”. 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.

Note — The Hub-ISAM can also perform local access and access aggregation, as shown in Figure 9-13.

S-ISAM 1A

B

UNI

UNI

S-ISAM 1C

D

UNI

UNI

E

F

UNI

UNI

NNI

NNI

NSP IPBackbone

EMAN

Hub-ISAM Remote Aggregator(subtended ISAM)



MAC address learning on the NT board

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 ISAM will learn this MAC address with the following restrictions:

• If the MAC address is learned from a subscriber port but the number of MAC addresses already learned on that port has reached a certain maximum, the MAC address is not learned and the frame is dropped.

• If the MAC address is learned from a subscriber port, but the same MAC address is already learned from the EMAN network, the MAC address is not learned and the frame is dropped (MAC address duplication).

• If the MAC address is learned from a subscriber port, but the same MAC address was already on another subscriber port, the new MAC address is not learned and the frame is dropped (MAC address duplication).

• If the MAC address is first learned on a subscriber port, and then learned from the EMAN network, this movement is accepted and the MAC address is learned. This means that the MAC address is removed from the subscriber port (MAC address movement, that is, the last learned MAC address takes priority).

• If the MAC address is first learned on a subtending, subscriber or internal LT port and then on another subtending, subscriber or internal LT port, then the MAC address is not learned on the second port (that is, no MAC address movement is performed)

• Well-known MAC addresses (for example, multicast MAC addresses, MAC addresses allocated for IEEE protocols, and so on) are not learned.

These principles apply also for subtending ports. In this context, a subtending port behaves at the same level as a subscriber port.

MAC address learning on the LT board

The ISAM LT boards provide a protection about the maximum number of MAC addresses that can be learned per port:

• On ATM-based interfaces, the limit is applied per PVC.• On PTM-based DSL interfaces, and Ethernet physical interfaces, the limit is

applied per interface.

Note — The secured MAC learning mechanism can be disabled to allow, for example, an unlimited number of MAC addresses in case of cross-connect mode.

Note — These restrictions are valid in both iBridge mode and VLAN cross-connect mode.



The way this protection is implemented depends on the LT board type:

• On layer 2+ LT boards and on layer 3 LT boards, this protection allows the operator to configure a maximum per port and this maximum is also committed.

• On layer 2 LT boards, this protection allows the operator to work with overbooking. The operator can configure a maximum per port and a committed number per port.

The committed number of MAC addresses per port is the number of entries reserved in the forwarding database for that port. This number of entries can be used by the subscriber connected to that port at all times, that is, independent of any activity of other subscribers.

However, if not all the available entries on an LT board have been assigned to a port, then the remaining entries are dynamically assigned to ports based on MAC address learning with the protection that the total number of entries per port cannot exceed the configured maximum number of MAC entries per port.

The ISAM LT boards also provide protection against duplicate MAC addresses in the VLAN context of the forwarder.

When a frame is received on a subscriber port with a source MAC address which was already learned on another port for this VLAN, this generates a duplicate MAC address alarm and:

• On layer 2 LT boards, the frame is discarded and the MAC address is not moved from the original port. Moreover the offending end-subscriber PVC gets locked. The subscriber port is unlocked again (and the duplicate MAC address alarm is cleared) after a time period equal to three times the MAC address aging time.

• On layer 3 and point-to-point Ethernet LT boards, the frame is discarded and the MAC address is not moved from the original port. The port carrying the offending frame remains fully operational for frames received with non-offending source MAC address. The alarm is cleared after a time period free of MAC address conflict.

• The Hub-ISAM LT NNI ports concept is currently supported on the GE Ethernet LT board only.

• As such, the MAC address learning and the associated duplicate MAC address alarming does apply to UNI and NNI ISAM LT ports with the same level of precedence between the two port types.

MAC aging time

A MAC address that was previously learned on a given iBridge is automatically removed from the MAC forwarding table of that iBridge when no traffic has been received from that MAC address during the MAC aging time.



MAC aging time configuration

It is important that the MAC ageing time is properly configured, otherwise data-plane connectivity may get lost between the network and the ISAM subscribers (due to the fact that traffic is not flooded to these subscribers when their MAC address is no longer present in the forwarding database):

• For PPPoE traffic, the MAC aging time can be kept small, because PPP has a built-in keep-alive mechanism.

• For DHCP-based service scenarios (IPv4 or IPv6), the MAC aging time must be taken in the same order of magnitude as the DHCP lease time (unless there is another time that can be used, for example, an ARP refresh interval, an application-layer keep-alive time, and so on).

The MAC aging time is configurable between 10 s and 1.000.000 s with a default value of 300 s.

A MAC aging time can be configured per iBridge forwarding instance as for some services the MAC aging time should be kept low, while for other services (for example, DHCP-based services) the MAC aging time should be increased.

VLAN tagging modes in the iBridge

Concepts

Section “Generic forwarder model in ISAM” has introduced the concepts of bridge ports and VLAN ports defined on the subscriber side and used by iBridges and VLAN cross-connects.

Forwarding of untagged/priority-tagged frames received from the subscriber

The subscriber bridge ports (that is, PVCs, EFM or Ethernet Physical link) are connected to the VLAN of the appropriate NSP by means of a default VLAN ID.

Figure 9-14 shows the concept of the iBridge mode for untagged subscriber traffic.

Note — On layer 2 LT boards, the MAC aging time is limited to a maximum of 1096 s by the hardware. In that case, the management interface allows the operator to configure a higher aging time, but the hardware caps this configured value to 1096 s.



Figure 9-14 iBridge mode - untagged subscriber traffic

Typical of an iBridge, several subscriber ports can be associated to a single VLAN. In Figure 9-14, the following subscriber ports are connected to the different VLANs:

• subscriber ports A, B and C connected to NSP 1-VLAN• subscriber ports D and E connected to NSP 2-VLAN• subscriber ports F and G connected to NSP 3-VLAN

There are two ways to determine a default VLAN ID (and P-bits) for untagged frames received on a bridge port:

• Port-based classification:For 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 uniquely determined by the bridge port through which the frame is received. This classification mechanism requires the operator to configure a specific PVID on each bridge port. In this case, the PVID provides the VLAN ID for untagged and priority-tagged frames received through that bridge port. The PVID is always associated with a VLAN port on the bridge port.

• Port- and Protocol- based classification:For bridges that implement port/protocol-based VLAN classification, the VLAN ID associated with an untagged or priority-tagged frame is determined by the bridge port through which the frame is received and the protocol type of the frame. This classification mechanism requires the operator to configure one Port-Protocol-VLAN ID per protocol type on each bridge port. Each Port-Protocol-VLAN ID is always associated with a specific VLAN port on the bridge port.When a PVID and Port-Protocol-VLAN ID(s) are both configured on a given bridge port, the ISAM always selects the Port-Protocol-VLAN ID if applicable. In practice, the ISAM operator can configure up to two port-Protocol-VLAN ID per bridge port:

• one for IP and related protocols (e.g. ARP) and • one for the PPP protocol

EMAN NSP IP backbone

NSP IP backbone

NSP IP backbone

NSP1

NSP2

NSP3

NSP 1-VLAN

NSP 2-VLAN

NSP 3-VLAN

A

B

C

D

E

F

GNSP 3

NSP 2

NSP 1



When a subscriber 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 ISAM.

The ISAM receives untagged or priority-tagged frames on a given bridge port, and forward these in the context of an iBridge. To achieve this, the operator creates a C-VLAN port on top of the bridge port, and couples it to the specified iBridge. Next, the operator installs a Port-default VLAN ID (PVID) (see Figure 9-15) or a Port-protocol-default VLAN (see Figure 9-16) that points to the VLAN port.

Figure 9-15 Forwarding untagged/priority-tagged frames in an iBridge (iBridge shown with only one subscriber)

Legend for traffic characterization:Ut,C1 means S-VLAN = untagged and C-VLAN = C1S1,X means S-VLAN = S1 and C-VLAN = do not care (tagged or untagged)Ut,Ut means no S-VLAN, no C-VLANLegend for VLAN port configuration:0,C1 means a C-VLAN portS1,0 means an S-VLAN port

Note — For more information about the handling of priority-tagged frames, see chapter “Quality of Service”.

Bridge port BP1

BP1:PVID = 0,C1

VLAN port (BP1/ 0,C1)Ut,Ut

User-side trafficConfigured VLANports

Network-sidetraffic

Ut,C1

Si,X (any i) orUt,Cj (j ≠ 1)

iBridge (C1)



Figure 9-16 Protocol-based VLAN selection (iBridge shown with only one subscriber)

Legend for traffic characterization:Ut,C1 means S-VLAN = untagged and C-VLAN = C1S1,X means S-VLAN = S1 and C-VLAN = do not care (tagged or untagged)Ut,Ut means no S-VLAN, no C-VLANLegend for VLAN port configuration:0,C1 means a C-VLAN portS1,0 means an S-VLAN port

Forwarding of C-VLAN tagged frames

The CPE accessing an NSP via iBridge mode send their traffic to the ISAM tagged with a NSP and, optionally, a service-specific VLAN ID. With the multi-VLAN and VLAN translation capability, a bridge port can access several NSPs simultaneously. Figure 9-17 shows the concept of the iBridge mode with tagged subscriber traffic.

Figure 9-17 iBridge mode - tagged subscriber traffic

Note — The behavior described in this section is also true when the iBridge mode is used to forward traffic from Hub-ISAM LT NNI ports.

Bridge port BP1

BP1: IPoE VID = 0,C1

VLAN port (BP1/ 0,C1)Ut,Ut


Network-sidetraffic

Ut,C1

Si,X (any i) orUt,Cj (j ≠ 1,2)

iBridge (C1)

iBridge (C2)Ut,C2

VLAN port (BP1/ 0,C2)PPPoE VID = 0,C2

EMAN NSP IP backbone

NSP IP backbone

NSP IP backbone

NSP1

NSP2

NSP3

NSP 1-VLAN

NSP 2-VLAN

NSP 3-VLANNSP 3

NSP 2

NSP 1

VDSL

Bridge port

VLAN-a VLAN-b

VLAN-c



In Figure 9-17 the VDSL subscriber is connected to 3 NSPs in iBridge mode. When a subscriber 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 network VLAN. This means that each NSP has its own forwarding table in the ISAM. This is indicated by the black boxes labeled with “NSPx”. The subscriber VLAN-a, VLAN-b and VLAN-c are translated in the ISAM to NSP 1-VLAN, NSP 2-VLAN and NSP 3-VLAN respectively at the subscriber-side boundary.

The ISAM receives C-VLAN-tagged frames on a given bridge port, and forwards these in the context of an iBridge. To achieve this, the operator creates a C-VLAN port on top of the bridge port, and couples it to the iBridge.

• When no VLAN translation is needed, the VLANs used in the network are extended all the way to the subscribers. In this case, the subscriber side VLAN IDs are said to have a network-wide scope; see Figure 9-18.

• In case of VLAN translation, the network-side and subscriber-side VLAN IDs are different. iBridging, in combination with VLAN translation, is typically used when a loose coupling is needed between the C-VLAN IDs used on the access link and the C-VLAN IDs used in the aggregation network; see Figure 9-19.

Figure 9-18 Subscriber-side VLAN-IDs with a network-wide scope (iBridge shown with only one subscriber)

Legend for traffic characterization:Ut,C1 means S-VLAN = untagged and C-VLAN = C1S1,X means S-VLAN = S1 and C-VLAN = do not care (tagged or untagged)Ut,Ut means no S-VLAN, no C-VLANLegend for VLAN port configuration:0,C1 means a C-VLAN port

Note — The behavior described in this section is also true when the iBridge mode is used to forward traffic from Hub-ISAM LT NNI ports.

Note — VLAN translation is not supported on Hub-ISAM LT NNI ports.

Bridge port BP1

BP1: no PVID

VLAN port (BP1/ 0,C1) Ut,C1


Network-sidetraffic

Ut,C1

Si,X (any i) orUt,Cj (j ≠ 1,2) orUt,Ut

iBridge (C1)

iBridge (C2)Ut,C2 VLAN port (BP1/ 0,C2)

Ut,C2



Figure 9-19 Support for VLAN translation (iBridge shown with only one subscriber)

Legend for traffic characterization:Ut,C1 means S-VLAN = untagged and C-VLAN = C1S1,X means S-VLAN = S1 and C-VLAN = do not care (tagged or untagged)Ut,Ut means no S-VLAN, no C-VLANLegend for VLAN port configuration:0,C1 means a C-VLAN port

VLAN tagging modes in the iBridge (Hub-ISAM LT NNI ports concept)Section “VLAN tagging modes in the iBridge” has explained the VLAN tagging modes in the iBridge for normal ISAM LT bridge ports, also known as UNI ports.

This section explains the VLAN tagging modes in the iBridge when used in context of the Hub-ISAM LT NNI ports.

Concept

Section “Generic forwarder model in ISAM” has introduced the concepts of bridge ports and VLAN ports defined on the subscriber side and used by iBridges and VLAN cross-connects. These concepts are also valid for iBridges defined on NNI ports.

As noted earlier, the Hub-ISAM LT NNI ports concept is currently supported on the GE Ethernet line card only.

There are two VLAN iBridge models supported on GE Ethernet LT board NNI ports:

• C-VLAN iBridge: basic VLAN bridge mode• S-VLAN iBridge: supporting mapped and tunnel VLAN bridge modes

Forwarding of untagged/priority-tagged/VLAN tagged frames in C-VLAN iBridge

Section “VLAN tagging modes in the iBridge” explains the forwarding behaviors of a C-VLAN iBridge configured on the GE Ethernet line card port type.

Bridge port BP1

BP1: no PVID

VLAN port (BP1/ 0,C3) Ut,C3


Network-sidetraffic

Ut,C1

Si,X (any i) orUt,Cj (j ≠ 3,4) orUt,Ut

iBridge (C1)

iBridge (C2)Ut,C2 VLAN port (BP1/ 0,C4)

Ut,C4

T

T



Forwarding of untagged/priority-tagged/VLAN tagged frames in S-VLAN iBridge

The forwarding behaviors described in section “VLAN tagging modes in the iBridge” are, for the most part, also pertinent for the operations of a S-VLAN iBridge configured on the GE Ethernet line card NNI port type.

The main difference being that an S-VLAN iBridge offers the ability of VLAN stacking (see “About VLAN stacking”)

When the Hub-ISAM GE Ethernet line card NNI port is configured with an S-VLAN iBridge, the ISAM Access Node is considered to be a VLAN aware bridge, where each N:1 SVLAN is a separate Virtual Bridge (VB) instance. Each VB performs independent source MAC address learning and frame forwarding process as described in 802.1D and 802.1Q.

The GE Ethernet line card S-iBridge forwarder, supported on the NNI port type, does support Mapped and Tunneled modes:

• In Tunnel Mode, the ISAM systematically adds a VLAN tag to frames originating from the NNI. This mode is enabled by configuring an S-VLAN PVID on the Bridge Port. It is to be noted that S-VLAN iBridge accepts indifferently untagged and single tagged frames.

• In Mapped Mode, the ISAM considers NNI traffic as if already inside a tunnel. In Mapped mode, the ISAM just extends the NNI tunnel further to the EMAN without adding any extra Vlan Tag. With Mapped mode, it is not possible to translate the NNI S-Vlan into a different network S-Vlan.

Both the Tunnel mode and the Mapped mode can coexist simultaneously in the ISAM. Whether a frame has to be handled in S-VLAN Tunnel or Mapped iBridge results from a comparison between the most external frame tag (if any) and the Bridge port PVID.

Thus the GE Ethernet LT board S-iBridge forwarding behaviors can be summarized as:

• When upstream traffic on a given NNI bridge port does not match a defined S-VLAN port attached to a given S-ibridge and no S-VLAN port default VLAN exist on that bridge port, then this traffic is dropped.

• When upstream traffic on a given NNI bridge port matches a defined S-VLAN port attached to a given S-ibridge and no S-VLAN port default VLAN exist on that bridge port, then this traffic is accepted into the VB instance for bridging functions. In this case, no new tag will be added on upstream egress. This mode of operation is referred as mapped mode.

• When an S-VLAN port default VLAN has been defined on an NNI bridge port, then all traffic is accepted into the VB instance for bridging functions and this traffic will be added an S-VLAN tag on upstream egress. This mode of operation is referred as tunnel mode.



9.7 VLAN cross-connect mode

ConceptThe VLAN cross-connect approach consists of building a connection-oriented model across the connectionless Ethernet access network, using VLANs. In VLAN cross-connect mode, one VLAN contains only one subscriber port. However, multiple VLANs (multi-VLAN feature) may be configured on a single subscriber port. Figures 9-20 shows the VLAN cross-connect mode.

Figure 9-20 VLAN cross-connect mode

Figure 9-21 shows the cross-connect network topology.

Figure 9-21 Cross-connect network topology

Note — Although Figure 9-20 is DSL copper access specific, the same concept applies for point-to-point Ethernet access solutions.

Subscriber A &Service a

VLAN

Subscriber A &Service b

VLAN

Subscriber B &Service c

VLAN

A

B

C

EMAN

NSP 1

NSP 2

NSP 3

NSP IP backbone

NSP IP backbone

NSP IP backbone

A

B

VLAN-a

bridge port

xDSL

VDSL

bridge port

VLAN-b

VLAN-c

Cross-connectlogical view

NSP

NSP

Bridge

Cross-connectphysical EMANtopology

User VLAN

User VLAN

Bridge

Bridge

Bridge

Network VLAN

Network VLAN



UsageA particular subscriber VLAN ID, without VLAN translation, can be configured only once:

• on any of the subscriber ports in the ISAM• over all the ISAMs in the complete Ethernet network to which the ISAM is

connected

When VLAN stacking is not used (see “About VLAN stacking”), the VLAN cross-connect mode should only be used:

• in small networks, where the ISAM is directly connected to the IP Edge router or Broadband Remote Access Server (BRAS) of a Network Service Provider (NSP), for business customers

• for a larger network in combination with VLAN translation.

Supported models in ISAMThere are several VLAN cross-connect models supported:

• C-VLAN cross-connect: basic VLAN cross-connect• S+C-VLAN cross-connect: VLAN stacking for residential subscribers (mapped

or tunnel mode)• S-VLAN cross-connect: VLAN stacking for business subscribers

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, in its turn, be bridged according to a forwarding context proprietary to the S-VLAN. This is done in S-VLAN-aware bridges.

Figure 9-22 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 subscriber (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 subscribers to a single service provider (hence the “S”).

Note — These VLAN cross-connect models are also supported on the Hub-ISAM LT NNI ports.



Figure 9-22 S-VLAN- and C-VLAN-aware bridges

C-VLAN cross-connect (basic 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 VLAN port at the subscriber side. In the ISAM, a bridge port is either an Ethernet PVC, an EFM link or a physical user Ethernet link. Any kind of traffic issued by the subscriber is forwarded transparently to the network using the selected VLAN ID.

As illustrated in Figure 9-24, similar to iBridging the C-VLAN cross-connect allows:

• user-VLAN to network-VLAN translation• handling of untagged traffic by means of PVID or Port-Protocol-VLAN ID

default VLANs.

Forwarding of untagged/priority-tagged frames in C-VLAN cross-connect

The ISAM receives untagged or priority-tagged frames on a given bridge port, and forwards these in the context of a C-VLAN cross-connect. To achieve this, the operator creates a C-VLAN port on top of the bridge port, and couples it to the C-VLAN cross-connect. Next, the operator configures on the bridge port a PVID or a Port-protocol-default VLAN that points to the VLAN port.

Forwarding of C-VLAN tagged frames in C-VLAN cross-connect

The ISAM receives C-VLAN-tagged frames on a bridge port, and forwards these in the context of a C-VLAN cross-connect. To achieve this, the operator creates a C-VLAN port on top of the bridge port, and couples it to the C-VLAN cross-connect.

When no VLAN translation is needed, the VLANs used in the network are extended all the way to the end subscribers. In this case, the end-subscriber side VLAN IDs are said to have a network-wide scope. For VLAN translation, the network-side and subscriber-side VLAN IDs are different.

VLAN translation is not supported on Hub-ISAM LT NNI ports.

Figure 9-23 shows the C-VLAN cross-connect model.

C-VLAN-awarebridge

VLAN-unawareterminal

S-VLAN-awarebridge

S-VLAN-awarebridge

C-VLAN-awareterminal

C-VLAN

S-VLANS-VLANtermination

terminationterminationanything anything

Bridging

Bridging Bridging

S-VLAN S-VLAN S-VLANS-VLAN

C-VLAN C-VLAN C-VLANEth

EthEth

EthEth

EthEthEth



Figure 9-23 C-VLAN cross-connect concept

Figure 9-24 shows a detailed example of C-VLAN cross-connects.

Figure 9-24 C-VLAN cross-connect detailed model

Legend:BrP10: bridge port 10{10, 0, 19}: C-VLAN port on bridge port 10 with User-C-VLAN ID = 19

S+C-VLAN cross-connect: VLAN stacking for residential subscribers

In the basic VLAN cross-connect mode, 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 4 K subscribers 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 4 M subscribers (the C-VLAN tag may not be identical to the S-VLAN tag, and vice versa).

An S+C-VLAN cross-connect can be seen as the generalization of a C-VLAN cross-connect. It has the same mode of operation and the same configuration model except that with an S+C-VLAN cross-connect, the user C-VLAN is always translated into a dual tag S+C Network VLAN.

Figure 9-25 shows the concept of the S+C-VLAN cross-connect mode.

NE EMAN CPE(s)

C-VLANs

C-VLAN portC-VLANcross-connect

T

T

T

Outer Tag: 17

BrP10(say, no PVID)

Traffic fromSubscriber

Outer Tag: 219

Outer Tag: 117

Anything else

Outer Tag: 19

Outer Tag: 17

Untagged (*)

Anything else

Trsl

Outer Tag: 19

Outer Tag: 17

Trsl

X

Trsl

Trsl

X

X

X

(*) Outer Tag: 19 is also accepted

Configured C-VlanPort:{BrP, S-VlanId, C-VlanId}

{10, 0,17}

{10, 0,19}

{11, 0,17}

{11, 0,19} (*)

Trsl

Trsl

X

Trsl

Trsl

X

X

X

BrP11PVID = (0,19)



Figure 9-25 S+C-VLAN cross-connect concept

Figure 9-26) shows a detailed example of S+C-VLAN cross-connects.

Figure 9-26 VLAN translation in case of the S+C-VLAN cross-connect

Legend:BrP10: bridge port 10{10, 0, 19}: C-VLAN port on bridge port 10 with User-C-VLAN ID = 19 (29, 119): (S, C) dual tag, with S being the outer tag with VLAN ID = 29

Special note about MAC address conflict prevention

Note 1 — In the ISAM, the S+C-VLAN cross-connect is always performing VLAN translation, even when the subscriber-side and network-side C-VLAN IDs are the same. For instance in Figure 9-26 the subscriber-side VLAN (0, 17) is translated into the network-side VLAN (23,17).

Note 2 — In the ISAM, the C-VLAN tag may not be identical to the S-VLAN tag.

Note 3 — S+C-VLAN cross-connect is also supported on the hub-ISAM LT NNI ports.

NEEMAN CPE(s)

C-VLAN to PVCcross-connectsC-VLANs C-VLAN port

S-VLAN

(23, 17)

(23, 117)

(29, 219)

(29, 119)

X

X

X

X

Trsl

Trsl

Trsl

Trsl

(23, 17)

(23, 117)

(29, 219)

(29, 119)

X

X

X

X

TrslTrsl

Trsl

TrslTrsl

TrslTrsl

Outer Tag: 17

BrP10(say, no PVID)

Traffic fromSubscriber

Anything else

Outer Tag: 19

Outer Tag: 17

Anything else

Configured C-VlanPort:{BrP, S-VlanId, C-VlanId}

{10, 0,17}

{10, 0,19}

{11, 0,17}

{11, 0,19}

BrP11(say, no PVID)

Outer Tag: 19



The purpose of S+C-VLAN cross-connect is to regroup different subscribers identified by their own C-VLAN in the same shared S-VLAN. Doing so improves the EMAN scalability by allowing the EMAN to collectively bridge all users' traffic in the same S-VLAN context.

Because the EMAN is only aware of the S-VLAN context when performing bridging, the ISAM must make sure that no two subscribers use the same source MAC address in upstream when put in the same S-VLAN.

While on the LT boards, each S+C VLAN cross-connect defines a distinct forwarding context, and hence there cannot be any MAC address conflict, this is not true on the NT board. The NT board acts as an S-VLAN bridge, unaware of the C-VLANs so traffic of multiple end-users that share the same S-VLAN ID is treated in the same forwarding context. If a given MAC address is first learned on an LT port and later on a second LT port, then no MAC movement occurs, but instead a “duplicate MAC address” alarm is raised by the NT board.

S-VLAN cross-connect: VLAN stacking for business subscribers

Like for the S+C-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

The difference however is that in the S-VLAN cross-connect mode, the EMAN and the ISAM are totally unaware of the C-VLANs. This contrasts with S+C VLAN cross-connects, for which the ISAM is aware of both the S-VLAN and the C-VLANs to identify individual S+C cross-connections.

In a S-VLAN cross-connect, the C-VLANs carried within the S-VLAN are passed transparently to the end subscriber. The S-VLAN cross-connect plays the role of a “transport pipe” between the subscriber and the remote site.

In this mode, the S-VLAN ID at the EMAN side is associated with an S-VLAN port at the subscriber side. The C-VLANs carried within the S-VLAN are passed transparently to the subscriber. This allows the subscriber to specify its own end-to-end connectivity, while remaining transparent for the EMAN.

Figure 9-27 shows the S-VLAN cross-connect model.

Figure 9-27 S-VLAN cross-connect model concept

The ISAM operator configures an S-VLAN cross-connect by configuring an S-VLAN port and associating it with an S-VLAN network VLAN.

NEEMAN

C-VLANs

S-VLANcross-connect S-VLAN port

S-VLAN C-VLANsATM PVC or EFMT



The S-VLAN cross-connect is available in two modes for realizing the “transparent pipe” transfer of subscriber traffic: the S-VLAN tunnel cross-connect and the S-VLAN mapped cross-connect.

• In tunnel mode, the ISAM systematically adds a VLAN tag to frames originating from the subscriber. This mode is enabled by configuring an S-VLAN PVID on the bridge port. S-VLAN tunnel cross-connect accepts indifferently untagged, single, dual or multi-tagged frames.

• In mapped mode, the ISAM considers subscriber traffic as if already inside a tunnel originated at subscriber side. In mapped mode, the ISAM just extends the subscriber tunnel further to the EMAN without adding any extra VLAN tag. With mapped mode, it is possible to translate the user S-VLAN into a different network S-VLAN.

Both the tunnel mode and the mapped mode can coexist simultaneously in the ISAM. Whether a frame has to be handled in S-VLAN tunnel cross-connect or S-VLAN mapped cross-connect results from a comparison between the most external frame tag (if any) and the bridge port PVID.

S-VLAN cross-connect is also supported on the hub-ISAM LT NNI ports.

Figure 9-28 and Figure 9-29 explain the principle by the means of detailed examples.

For VLAN cross-connect, only the most external VLAN tag is used to determine the type of VLAN cross-connect to be applied to the frame, independently whether additional tags would be present or not (subscriber frames with more than 2 VLAN tags are not shown in the figures).



Figure 9-28 Detailed example of ISAM Configuration with PVID = S-VLAN and resulting behavior

17

17,13

17,17

17,17,19

17,31,19

29

29,19

S-VLAN tunnel mode

S-VLAN mapped mode

23

23, 37

(17,0), PVID

(29, 0)

(0, 23)

Ut

13

17

17, 19

31, 19

29

29,19

23

23, 37

BridgePort

Ut Untagged frame

13 Frame with single tag = 13

17, 13 Frame with double tag = 17 (external tag) and 13

17, 31, 19 Frame with triple tag = 17 (external tag), 31 and 19

No frame output

Legend

(17, 0) S-VLAN VlanPort configured

(0, 23) C-VLAN VlanPort configured

X



Figure 9-29 Detailed example of ISAM Configuration with PVID different from S-VLAN and resulting behavior

MAC learningThe same MAC learning concepts apply as for iBridge; see section “MAC learning”

Transparent VLAN cross-connectThe ISAM supports transparent VLAN cross-connect for use in a business environment on all LT boards except layer 2 LT boards. A transparent VLAN cross-connect is a special mode of operation of the S-VLAN cross-connect, C-VLAN cross-connect or S+C-VLAN cross-connect. Transparent VLAN cross-connect is also supported on the hub-ISAM LT NNI ports.

A transparent VLAN has the following additional features compared with the usual VLAN cross-connect:

• L2CP frames are transparently forwarded (except pause frames).• MAC address learning is disabled in the NT board for better scalability.

29

29,19

S-VLAN mapped mode

S-VLAN mapped mode

23

23

23, 37

(17,0)

(29, 0)

(0, 23), PVID

29

29,19

BridgePort

Ut Untagged frame

13 Frame with single tag = 13

17 Frame with double tag = 17 (external tag) and 13

No frame output

Legend

(17, 0) S-VLAN VlanPort configured

(0, 23) C-VLAN VlanPort configured

17

17, 19

17

17, 19

Ut

23

23. 37

13

31, 19

X

X

X



L2CP frames are those frames with the following destination MAC addresses:

• 01-80-C2-00-00-00 through 01-80-C2-00-00-0F• 01-80-C2-00-00-10• 01-80-C2-00-00-20 through 01-80-C2-00-00-2F

L2CP protocols is a family of link-related protocols. It comprises the following protocols:

• Spanning Tree protocol• Rapid Spanning Tree protocol• Multiple Spanning Tree protocol• Pause (802.3x) protocol• Link Aggregation protocol• Marker protocol• Authentication (802.1x) protocol• LAN Bridge Management Group Block of protocols• Generic Attribute Registration Protocol (GARP) Block of protocols• and so on

Pause frames are those L2CP frames identified by:

• Destination MAC address = 01-80-C2-00-00-01• Ethernet type and op-code can be anything

The purpose of transparent VLAN cross-connect is to emulate a physical link, as illustrated in Figure 9-30.

Figure 9-30 Use of transparent VLAN cross-connect

Link aggregate

Br

Br

Br Br

LAG

L2CP:LACP

L2CP:LACP

L2CP: Sp. tree

L2CP: Sp. tree

Br

Br

Br

LAG

Br

Br

Br

LAG

x

x

x

x

x

x

LAG

Br

Br

Br

LAG LA

G

x

x

x

x

x

x

L2CP

L2CP

L2CP

VLAN1

VLAN2

VLAN3

EMAN

Assum p tion :EMAN tra n sp a re n t to ta g g e d L2CP traffic

Over Transparent VLAN-CC

Br

Br

Br

Br

Br

Br

Br

Br

Br

LAG



In the upstream direction, in a transparent VLAN cross-connect, untagged subscriber L2CP frames are considered as data traffic and are tagged by the default PVID configured on the PVC/EFM with the exception of:

• tagged pause frames, which are always discarded• untagged 802.1x frames, which are extracted to the LT OBC when 802.1x is

enabled, whether L2CP transparency is enabled or disabled on the LT board• untagged link-based Ethernet OAM, which is extracted to the OBC when

link-based Ethernet OAM is enabled, whether L2CP transparency is enabled or disabled on the LT board.

In the downstream direction, in a transparent VLAN cross-connect, tagged subscriber L2CP frames are considered as data traffic and are passed untagged to the subscriber. The handling of untagged downstream L2CP frames is not affected by the transparent VLAN cross-connect.

Because L2CP protocols are link related, the deployment model implies that only one transparent VLAN cross-connect is configured per PVC (or per EFM); see Figure 9-31. Having more than one cross-connect can lead to undesired effects in L2CP protocols.

Figure 9-31 One transparent VLAN cross-connect per PVC/EFM

Note — IEEE802.3ah OAM is currently not supported on hub-ISAM LT NNI ports.

CPE

x x

L2CP

PVID = VLAN1

CPE

x

x

L2CP

PVID= VLAN1x

x

x x

L2CP

VLAN1

EMAN

x

x

L2CP

VLAN1

EMANx

x

VLAN2

PVC/EFM

PVC/EFM

PVC/EFM PVC/EFM

PVC/ EFM CPE

CPECPE

CPE

CPE



9.8 Protocol-aware cross-connect mode

The protocol-aware cross-connect mode behaves like the formerly described cross-connect modes for the dataplane, but it also adds some protocol awareness similar to the iBridge mode, for protocols such as 802.1x, DHCP, IGMP, PPPoE, DHCPv6 and ICMPv6.

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.

VLAN cross-connect for business and residential subscribersThe VLAN cross-connect feature cross-connects a subscriber PVC (or DSL line in case of EFM, Ethernet link in case of point-to-point Ethernet) with a “private” VLAN at the EMAN side. Depending on the subscriber type, two VLAN cross-connect configurations are considered:

• Business cross-connect:This mode provides a connectivity scheme for business subscribers which is as transparent as possible and emulates a fully featured routed network. In this configuration, the IP subnets of the private subscribers are made visible to the network and the configuration data of those private subnets and the subnets further in the network are exchanged through routing protocols.Figure 9-32 shows the IP network model for business cross-connect.

Figure 9-32 IP network model for business cross-connect

• Residential cross-connect: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; see Figure 9-33) or a BRAS (PPP connectivity; see Figure 9-34) through a single bit pipe. In this configuration, the subscribers are sharing the same subnet for scalability reasons and (normally) do not present their private network configuration to the network.

VRF

VRF

VRF

VRF

NEEMANEdge CPE

VRFServices

IP subnet IP address VLAN

VVL

CustomerpremisesIP subnet



Figure 9-33 IP network model for residential cross-connect using IP connectivity

Figure 9-34 IP network model for residential cross-connect using PPP connectivity

Note — Figure 9-33 and Figure 9-34 apply for residential subscribers that are using bridged CPE or router CPEs with NAT. In those cases, only single IP address(es) are allocated to the subscriber, and no (directly or non-directly) attached subnets.

Though not typically associated with residential subscribers, router CPEs without NAT can be supported too. The data forwarding in the VLAN cross-connect model is fully based on the VLAN tag(s) and does not need to look at the IP addresses (that is, need to support an IP next-hop behavior in the downstream direction).

However, this possibility is rather heavy from an operational point of view: subscriber subnets need to be configured by the operator in the IP edge. If IP address anti-spoofing is switched on in the ISAM, the subscriber subnets must be configured there as well.

NE EMANEdge CPE

VLAN-CC

VRFServices

IP subnet IP address VLAN

NE EMANEdge CPE

VLAN-CCIP

RoutingServices

IP subnet IP address

PPPTermina-

tion

VLANPPP session



Business cross-connect features

In a business context, the VLAN cross-connect model is used to provide a transparent VPN service. Several variants exist:

• Layer 2 VPN: the subscriber sends C-VLAN tagged frames, which are wrapped at ingress of the ISAM into a S-VLAN pipe that is carried through the Ethernet aggregation network. In the ISAM, this model can be realized using the S-VLAN cross-connect.

• Layer 3 VPN: the subscriber router CPE (Customer Edge, CE) is connected to a Provider Edge (PE) located in the service provider network. In ATM-based DSL aggregation networks, a similar service is provided, often with IPoA encapsulation. The idea is that the Business cross-connect safeguards the parameters of the original service as it exists in the ATM environment: no changes in IP configuration, transparency for the (routing) protocols involved, same QoS offering, and so on. In the ISAM, this model can be realized using the C-VLAN cross-connect or S+C VLAN cross-connect.

The business version of the VLAN cross-connect mode supports the following features:

• point-to-point Ethernet interface types• supported on the hub-ISAM LT NNI ports• DSL interfaces types:

• ATM:- Bridged encapsulation carrying IPoE traffic- IPoA with the required interworking to convert the traffic to IPoE (for IPv4 only)- PPPoA encapsulation or encapsulation auto-detection is not expected in a business context

• Ethernet:- VDSL EFM- Ethernet LT ports

• Subscriber identification:A single or a stacked VLAN tag towards the network is associated to a single business subscriber. Various VLAN assignment schemes exist:

• S-VLAN cross-connect: The S-VLAN indicates the subscriber while the C-VLANs represent various subscriber-defined services.

• S+C-VLAN cross-connect: The C-VLAN indicates the subscriber, while the S-VLAN indicates the DSLAM (or the DSLAM-PE pair).

• IP addressing scheme for layer 3 VPNs:IP addresses are statically assigned to the CPE and PE. Since IP subnets are not shared between business subscribers, it is sufficient to use a /30 subnet between the CPE and the PE. The DSLAM must be transparent for routing protocols between CPE and PE. IP addresses used in the private domain (at the LAN side of the CPE) are not known to the operator, therefore, these should not be required in the DSLAM configuration.

• Security features:For bridged encapsulation: optional limitation of the number of MAC addresses per VLAN cross-connect.

• Service enforcement:Policing per subscriber interface (PVC (ATM), subscriber-side VLAN within a VDSL port/Ethernet LT port (EFM), and so on).



Residential cross-connect features

The VLAN cross-connect supports the following features in the context of residential subscribers:

• point-to-point Ethernet interface types• supported on the hub-ISAM LT NNI ports• DSL interfaces types:

• ATM:- Bridged encapsulation carrying both PPPoE and IPoE traffic- PPPoA with the required interworking to convert the traffic to PPPoE- Encapsulation auto-detection as the encapsulation of residential subscribers is generally unknown

• Ethernet:- VDSL EFM- LT ports

• Subscriber identification:• A single (C-VLAN) or a stacked (S+C-VLAN) VLAN tag towards the network is

associated to a single residential subscriber• Optional addition of the PPPoE relay tag (that is, the line ID parameter) in the

PPPoE control messages (this is not supported however on the hub-ISAM LT NNI ports)

• Optional addition of the DHCP Option 82 (that is, the line ID parameter) in the DHCP messages (this is not supported however on the hub-ISAM LT NNI ports)

• Optional addition of the DHCPv6 Option 18 and/or Option 37 (that is, the interface ID and the relay agent remote ID parameters) in the DHCPv6 messages

• Security features:• 802.1x authentication allowing to allow or disallow the traffic (PPPoE and IPoE)

through the pre-configured VLAN cross-connect in function of the connected CPEs (this is not supported however on the hub-ISAM LT NNI ports)

• Optional limitation of the number of MAC addresses per VLAN cross-connect• ACLs: though this should typically be done by the IP edge, it might happen that the

latter does not own enough processing capacity to support that feature• IP address anti-spoofing: this should ideally be done centrally in the network, but IP

address anti-spoofing might not always be available centrally and/or might suffer from some dimensioning/performance issues when used for a large amount of subscribers

• Service enforcement:• Policing per subscriber interface (PVC (ATM), subscriber-side VLAN within a

VDSL port/Eth LT port (EFM), and so on).• Further detailed policing actions based on CoS and/or ACL results should be

typically performed centrally where the service awareness is present.• QoS policy: in case a single PVC is used to carry multiple services and the CPE is

not generating priority tagged frames, segregating services is then only possible at IP level using the QoS policies offered by the ISAM QoS Policy framework. For instance, one can define IP sub-flows based on, for example, DSCP values, IP source or destination addresses or even UDP/TCP port addresses. Each of these sub-flows can then have its QoS parameters re-marked and/or can be policed. The same applies for VDSL ports that only carry untagged frames.

• Service selection: performed centrally• Service accounting: performed centrally• Local multicast handling: driven by IGMP



See also “Protocol handling in a Layer 2 forwarding model” for more information.

9.9 IPoA cross-connect mode

The IPoA cross-connect mode offers a solution for connecting subscribers 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. IPoA is only supported for IPv4.

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 subscriber subnet behind the customer CPE:

• the CPE performs Network Address Translation (NAT), that is, the subscribers behind the CPE have a private subnet and the CPE translates the private subscriber IP address to the public CPE IP address

• the subscribers have IP addresses from the public range and, as a consequence, the public subscriber IP addresses become visible in the IP network.

In any case, the subnet configuration at the subscriber 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 9-35 and Figure 9-36.

Figure 9-35 IP network model for business IPoA cross-connect

Note — The IPoA cross-connect mode is comparable with the VLAN cross-connect mode, but with IPoA instead of IPoE at the CPE side.

EdgeRouter

IP

IP

IP

IPoAIPoE

100.100.100.8 /30 Networkside

CPEside

100.100.100.9

= IP interface

100.100.100.10

100.100.100.13 100.100.100.14

100.100.100.17 100.100.100.18

100.100.100.12 /30

100.100.100.16 /30

CPE

CPE

CPE

NE



Figure 9-36 Ethernet network model for business IPoA cross-connect

IPoA cross-connect featuresThe 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 ISAM-PE).• There is internal prioritization based on Differentiated Services CodePoint

(DSCP) bits, both for the upstream and the downstream direction.• There is upstream p-bit marking.

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 and multicast IP packets:The LIM MAC address is used as the source MAC address and the destination MAC address is derived from the broadcast or 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 ISAM responds to an ARP request for the CPE IP address generated by the edge router), or a broadcast or multicast MAC address.

IPoE

IP

IP

IP

PVC11

EdgeRouter

CPE1C_VLAN1

S_VLAN

= L2 interface

IPoA

C_VLAN2

C_VLAN3

PVC12

PVC21

PVC22

PVC31

PVC32

CPE2

CPE3



9.10 Secure forwarding in iBridge and VLAN cross-connect

Secure forwarding is a feature applicable to iBridge and VLAN cross-connect forwarders. It increases the network security by making use of the IP characteristics of the traffic. It is applicable both for IPoA and IPoE user traffic. When enabled, secure forwarding provides the following features:

• IP session awareness:DHCP messages are snooped to dynamically learn IP session information.

• IP address anti-spoofing is activated both for dynamic IP sessions and statically configured IP addresses/subnets.Any IP packets whose IP source address does not match any of the following are discarded:

• any IP addresses allocated to the subscriber interface through DHCP• any static IP addresses• any IP subnets programmed by the operator

• ARP relay is performed both for dynamic IP sessions and statically configured IP addresses/subnets.Downstream broadcast ARP messages are forwarded to the correct subscriber port only. This provides some security against malicious subscribers doing a “theft of service”.

Secure forwarding relies on DHCP snooping (for more information on DHCP, see chapter “Protocol handling in a Layer 2 forwarding model” and chapter “Protocol handling in a Layer 3 forwarding model”.

The operator can enable or disable the secure forwarding feature per iBridge / VLAN cross-connect.

When secure forwarding is applied to iBridges, it is sometimes referred to as Enhanced iBridge forwarding.

Figure 9-37 Enhanced iBridge architecture

User

User

User

User

User

User

User

User

User

IP

Users can belong to a different public subnet.

ISAM

CPE

CPE

CPE

UserUser

UserUser

UserUser

CPE

CPE

CPE

UserUser

UserUser

UserUser

CPE

CPE

CPE

UserUser

UserUser

UserUser

IPnetwork

IP Subnet

Users can belong to adifferent public subnet

IP edge

LTLL

LTLL

LTLL

EMA

NT

DHCP snooping/Static config.

ARPRelay

iBridge


ARPRelay

iBridge


ARPRelay

iBridge

Bridge

VLAN



Secure forwarding is supported by all ISAM LT types: DSL and point-to-point Ethernet.

Secure forwarding is not supported on the hub-ISAM LT NNI ports.

IP session awarenessThe ISAM snoops DHCP messages to learn what IP addresses/subnets have been allocated to a subscriber port.

The ISAM keeps the IP session information (that is, IP address and associated subnet of the subscriber, lease time, default gateway IP address, DHCP server IP address, and so on) during the lifetime of the DHCP session.

The IP session information is used during ARP relay and to install IP anti-spoofing filters.

IP address anti-spoofingThe following applies for IP address anti-spoofing:

• IPv4 address anti-spoofing for dynamic IP addresses learned through DHCP.Any IP packets whose IP source address does not match any IP addresses allocated to the subscriber interface through DHCP are discarded.

• IPv4 address anti-spoofing for static IP addresses and/or IP subnets (IP prefix + length) configured by the operator.Any IP packets whose IP source address does not match any static IP addresses and/or any IP subnets programmed by the operator are discarded.Though the main scenario when considering IP awareness in the I-Bridge context is a configuration where IP addresses are dynamically allocated by a DHCP server, static IP addresses and/or subnets must also be supported to cover the following cases:

• migration from legacy network where CPEs are already configured with a static IP address

• DHCP servers that do not support Option 82• IP address anti-spoofing for control messages.

IP address anti-spoofing is applied to control messages like ARP, IGMP and DHCP.

ARP relayThe iBridge forwarding rules allow a basic ARP handling:

• Downstream ARP messagesWhen setting the broadcast flag for a given iBridge, downstream ARP requests are forwarded to all subscribers connected to the iBridge.

Note — For more information about DHCP, see Chapter “Protocol handling in a Layer 2 forwarding model” and Chapter “Protocol handling in a Layer 3 forwarding model”.



• Upstream ARP messagesARP requests originating from the subscriber are broadcast to all network bridge ports.

A more intelligent way of dealing with ARP messages is ARP relay.

ARP relay is composed of the following features:

• Broadcast ARP messages received from the network are forwarded to the single relevant subscriber bridge port.The ISAM does not broadcast ARP messages to all subscribers. Instead, the ISAM only forwards an ARP message to the subscriber interface whose IP address(es) and/or subnet(s) match the IP address targeted by the ARP message. This in order to reduce the load on the subscriber interfaces and avoid security flaws by broadcasting ARP messages to all subscribers in an uncontrolled way. It is then up to the subscriber to reply the ARP message (there is no ARP state machine in the ISAM).To simplify the downstream forwarding of ARP messages in the ISAM, the IP addresses that are statically configured or learned via DHCP on a subscriber port must be non-overlapping with any other IP addresses that exist on the same or any other subscriber port. This is guaranteed in the following way:

• Configuring a static IP address/subnet that overlaps with any other static one is prevented at the time of configuration.

• When a DHCP session is set up that contains overlapping IP address, the DHCP message exchange between the subscriber client and the DHCP server is completed as usual. However, the IP address/subnet is not learned on the subscriber port, so no data traffic will be possible with that IP address/subnet due to the IP anti-spoofing filter. In addition, an alarm is generated.

• Non-local ARP messages received from the subscribers are broadcast to all network bridge ports.ARP messages coming from a subscriber, provided they are not targeted to the same subscriber, are simply broadcast to all network interfaces, allowing the edge routers to reply with their own MAC address. To avoid bothering the network with ARP messages intended for hosts located on the local network of the subscriber, the ISAM discards any ARP messages, whose targeted IP address belong to the list of IP addresses and/or subnets defined for IP address anti-spoofing on that subscriber’s interface.Because iBridging in the ISAM does not allow user-to-user traffic, the edge router must support local ARP proxy and IP traffic hair-pinning (that is, traffic received on a given interface that must be forwarded to the same interface based on the routing table) if user-to-user traffic is needed.

IPoA support for secure forwardingBy similarity with IPoA VLAN cross-connect, secure forwarding is supported with IPoA encapsulation: IPoA upstream traffic is converted into IPoE traffic and vice-versa.

Note — ARP relay is not the same as the so-called “ARP-proxy” defined in the context of IP forwarding. Indeed, the ISAM will never answer with its own MAC address in the context of iBridging but will direct the message to the host in charge of answering.



9.11 Virtual MAC

Layer 2 forwarding models typically identify a subscriber device using a MAC address. However, since these devices are not directly controlled by the operator, their MAC address cannot be trusted. Various mechanisms have been put in place to deal with this, such as the duplicate MAC address control of the ISAM iBridge. However, this only partially solves the issue, because:

• MAC address uniqueness can only be guaranteed at the ISAM level and not across the whole access network

• The ISAM can detect a duplicate MAC address but cannot differentiate the well-meaning subscriber from the malicious one

The concept of virtual MAC (vMAC) offers a complete solution by replacing the MAC address of the subscriber with a MAC address defined by the operator (and therefore, fully controlled). Enabling vMAC allows improving layer 2 forwarding models in the following two areas:

• Security:Translating the MAC address of the subscriber by an operator-defined MAC address ensures, by definition, the uniqueness of the MAC address across the whole access network, automatically alleviating all issues related with duplicate MAC addresses.

• Scalability:By guaranteeing that a MAC address is unique across the whole access network, an operator can now choose to connect multiple DSLAMs to the edge router through the same network VLAN. By doing so, the operator increases the number of subscribers sharing the same subnet and, consequently, improves the pooling effect when allocating IP addresses.

Deployment scenario exampleOne possible deployment scenario for vMAC is shared network VLAN for IP address pooling.

Without enabling vMAC, the iBridge implementation only guarantees MAC address uniqueness at ISAM level, that is, not across the whole access network. In that case, you can only avoid duplicate MAC addresses by guaranteeing that the traffic from a DSLAM is not mixed with another DSLAM traffic in the EMAN, before entering the IP edge. In other words, avoiding duplicate MAC addresses is achieved by assigned a dedicated network VLAN per DSLAM; see Figure 9-38.

Caution — Although vMAC addresses are saved during an LT board reset, they are not saved if the LT board is powered down.

Note — vMAC is currently not supported on the hub-ISAM LT NNI ports.



Figure 9-38 iBridge

Activating vMAC support in iBridge removes the preceding constraint and allows sharing a same network VLAN across multiple DSLAMs. This network VLAN sharing improves the scalability of the access network regarding IP address allocation; see Figure 9-39.

Figure 9-39 iBridge with vMAC enabled

Sharing a network VLAN across multiple DSLAMs might lead to enabling user-to-user communication between subscribers connected to different DSLAMs through the Ethernet switches. This is typically not wanted by the access network operators and must be blocked by either the Ethernet switch (using the concept of split horizon at layer 2) or by the DSLAM itself.

vMAC featuresvMAC has the following features:

• vMAC support can be enabled or disabled per network VLAN• maximum number of vMAC per port is programmable• silent discard of packets received with a new subscriber MAC address when no

free vMAC is left• vMAC translation is not applied to multicast, broadcast and invalid MAC address

ISAMEMANEdge CPE

VRF Bridge

I-Bridge

IP subnet IP address

I-Bridge

ISAMEMANEdge CPE

VRF Bridge

vMACbridge

VLAN / IP subnet IP address

vMACbridge



• the DSLAM ID is programmable by the operator• DHCP algorithm• ARP algorithm• Ethernet OAM algorithm• user-to-user communication can optionally be blocked• vMAC address - MAC address translation table recovery

Enable/disable vMAC support per network VLAN

vMAC support can be enabled per network VLAN and this independently of the forwarding model.

vMAC can be used in conjunction with:

• C-VLAN cross-connect• S+C-VLAN cross-connect (vMAC is an S-VLAN level attribute)• iBridge

vMAC can also be used in conjunction with IP routing where the NT board acts as IP router and the LT board as iBridge.

vMAC support together with the IP routing model (and LT board acting as iBridge) is advised, so that any issues with duplicate MAC addresses are avoided. This is what you would expect with a black box IP router DSLAM (that is, the IP router should still work even if all subscribers were using the same MAC address).

vMAC support is characterized as follows:

• Upstream traffic:• Each time a new MAC address is received from the subscriber, a free vMAC is

associated with the MAC address of that subscriber.• The MAC source addresses of the Ethernet packets are overwritten with the vMAC

associated with the subscriber MAC address found into the MAC source address field.

• vMAC algorithms (ALGs) might be applied to control plane messages (ARP, DCHP, Link Related Ethernet OAM, and so on).

• Downstream traffic:• The MAC destination addresses of the Ethernet packets are overwritten with the

subscriber MAC address associated with the vMAC found in the MAC destination address field.

• vMAC ALGs might be applied to control plane messages (ARP, DCHP, Link Related Ethernet OAM, and so on).

Note — vMAC cannot be used in conjunction with S-VLAN cross-connect or layer 2-terminated VLAN.



When unused, vMAC are freed based on the standard MAC address aging process.

Maximum number of vMAC addresses per port is programmable

The maximum number of vMAC addresses that are allowed on a given subscriber port can be specified.

Silent discard

Packets received with a new subscriber MAC address when no free vMAC is left are silently discarded.

Any packet received from a subscriber, and whose MAC source address should be learned because it is still unknown, will be silently discarded if there is no free vMAC left for that subscriber.

vMAC translation is not applied to multicast, broadcast and invalid MAC address

A vMAC will only be assigned to a unicast and valid MAC address received from the subscriber. Any other valid MAC address is kept unchanged (multicast and broadcast).

DSL/Eth LT vMAC format

In the vMAC format, the DSLAM ID can be set by the operator, see Table 9-2.

To ensure uniqueness of the vMAC within the EMAN, vMAC cannot be enabled on any network VLAN until the DSLAM ID has been programmed by the operator. It is the responsibility of the operator to ensure that unique DSLAM IDs are assigned; otherwise duplicate vMAC addresses may be generated by different DSLAMs.

Table 9-2 vMAC format for data traffic forwarding

Note — All the dimensioning parameters related to the standard MAC address (for example, average number of MAC addresses per subscriber, maximum number of MAC addresses per subscriber, and so on) also apply when vMAC is enabled within a given network VLAN.

Note — This limit is programmed by setting the maximum number of MAC address per port (generic MAC address related feature).

MAC Address Configurable Description

Bit 47...45 No Rack ID (minus 1)

Bit 44 No vMAC signature field set to 0

Bit 43...42 No Reserved field for other applications, set to 0’s for the vMAC application

Bit 41 No U/L field set to 1 (local MAC address validity)

Bit 40 No I/G field set to 0 (unicast address)

(1 of 2)



DHCP algorithm

The chaddr field of the DHCP messages must be translated as follows:

• Upstream: the subscriber MAC address is replaced by the associated vMAC address

• Downstream: the vMAC address is replaced by the associated subscriber MAC address

ARP algorithm

The MAC address field present in the ARP message payload is updated in a similar way as for DHCP.

Ethernet OAM algorithm

The MAC address field present in the payload of Ethernet OAM messages exchanged with the subscribers is updated in a similar way as for the DHCP case.

User-to-user communication can optionally be blocked

If an operator wants to share a VLAN across multiple DSLAMs, but the Ethernet switches are unable to block user-to-user traffic, the operator can enable dedicated filters at ISAM level to discard subscriber traffic received from other DSLAMs. Those filters must be implemented so that they do not prevent using typical access network topologies (for example, star, ring, dual homing, and so on).

The filter is implemented per VLAN at LT board level so that the NT board still behaves as a normal bridge, in order to support all access network topologies (for example, ring).

The LT filter discards any Ethernet packet received from the NT board within the specified VLAN and whose MAC source address matches the non-DSLAM specific fields of the vMAC (i.e. DSLAM ID, rack/shelf/slot/Port/MAC IDs).

Bit 39...21 Yes DSLAM ID set by the operator [0…524287]

A unique DSLAM ID within an EMAN connected to the same IP edges

Bit 20...15 No Slot ID of the line board [0…63]

The logical position of the line card within the DSLAM.

Bit 14...6 No Port ID of the subscriber interface [0…511]

Bit 5...0 No MAC ID unique to each subscriber MAC address

Note — When vMAC is enabled, the DHCP lease time must be less than the MAC aging timer (on the ISAM or on the VLAN), or else the vMAC address for the subscriber will be forgotten before the DHCP session expires. In this case, when the subscriber attempts to renew the session, it is possible that the network is reached using a different vMAC address, causing it to be discarded.

MAC Address Configurable Description

(2 of 2)



vMAC address - MAC address translation table recovery

Enabling vMAC support makes the iBridge implementation state full. The ISAM recovers the stable states in case of LT software failure, LT board reset or LT software upgrade.

In this manner, a correct vMAC-address-to-IP-address mapping is maintained to avoid issues with:

• DCHP servers: for example, IP address lease renewal, where the subscriber is identified using the vMAC (that is, chaddr)

• IP routers implementing IP address anti-spoofing by coupling the vMAC and the IP address learned through DHCP snooping

9.12 PPP Cross-connect mode

PPP cross-connect is a forwarding mode in which the ISAM forwards traffic from PPP sessions from the user side through PPP sessions at the network side towards a BRAS and conversely, and this as long as the user PPP session is living. There is always a 1:1 relationship between the PPP session at user side and the PPP session at network side. This justifies the use of the term “cross-connect” which must be understood as “PPP session cross-connect”

By nature the PPP session is PPPoE at the network side. The network VLAN of a PPP cross-connect can be single tagged (like an iBridge or a C-VLAN cross-connect) or dual tagged (like a S+C-VLAN cross-connect).

It should be noted that PPP cross-connect does not require that the user encapsulation is Ethernet. It works as well with PPPoA as with PPPoE although the PPP session setup handling is different:

• In case of PPPoA, the ISAM is responsible for setting up and releasing the PPPoE session which will encapsulate the user PPP packets.

• In case of PPPoE, the PPPoE session is set up and released by the user himself and the ISAM just relays it to the network side.

For this to happen, the following must take place:

• The operator statically configures the PPP cross-connect forwarder, which network VLAN it uses and which users may use it. It is possible that multiple user sessions are multiplexed via PPPoE in one N:1 network VLAN, and it is possible that there is a 1:1 relationship between the user and the network VLAN.

• Each time a user initiates a PPP session, the ISAM goes though a dynamic PPP session marking phase: during this phase, the ISAM sets up information necessary to forward packets between user and network.

When the PPP session is terminated, the ISAM deletes the marked session information.



A property of PPP cross-connect is that the ISAM sends PPPoE packets to the network using its own MAC address as source address. Thus, for the network, the ISAM looks like the PPP client itself and actually performs user MAC address concentration.

The general model of a PPP cross-connect engine with MAC address concentration is quite intuitive. It is shown in Figure 9-40.

Figure 9-40 General PPP cross-connect engine

The VLAN which is attached to a PPP cross-connect Engine on the network side must be of iBridge or VLAN cross-connect type. Of course, when the VLAN is of type cross-connect, only one user is attached to the engine.

The type of interface on which a PPP Client Port can be configured must be one of the following:

• EFM interface for untagged PPPoE traffic• PVC for PPPoA and/or untagged PPPoE traffic• Ethernet interface for untagged PPPoE traffic• VLAN port interface for tagged PPPoE traffic

All the supported encapsulations for PVCs are shown in Figure 9-41.

Note — The possibility exists - for legacy purpose - to configure PPP cross-connect without MAC address concentration. In this mode, only PPPoA traffic is accepted by the PPP cross-connect, whereas PPPoE is automatically iBridged or VLAN cross-connected to the same network VLAN as the PPP cross-connect. When not specified, the term “PPP cross-connect” must always be understood as “PPP cross-connect with MAC address concentration”

Note — It is intentionally not possible to create a client port on a bridge port.

PPPCCEPPPoEServer

iBridge VLANor

CC VLANPPPCCE

PVC, EFM, VLANPort or GEPPP CC Client Port

PPPoEServer

PPPoA&

PPPoEIn case of PVC



Figure 9-41 Accepted ATM encapsulation for PPP cross-connect Forwarding with MAC address concentration

PPP cross-connect implementation

The object model of a PPP cross-connect depicted in Figure 9-40 is quite simple:

• a forwarding engine applying PPP cross-connect forwarding rules• one network VLAN• one or several client ports on top of PVCs, VLAN port interfaces, EFM interface

or Ethernet interface to attach users

Note — PPP cross-connect is not supported in hub-ISAM LT NNI ports.

Client Port

PPPCCE PPPoA

Client Port

PPPCCEUntaggedPPPoE

Client Port

PPPCCE TaggedPPPoE

asamAtmVclEncapsAutodetectdisabled(1),

asamAtmVclEncapsType llcSnapBridged(1) orvcMuxBridged(4)

VC

VCVlanPort

Client Port

PPPCCE

PPPoAor

UntaggedPPPoE

VC

asamAtmVclEncapsAutodetectdisabled(1) orautoDetectPPPoA(4)

asamAtmVclEncapsType llcNlpid(3) orvcMuxPppoa(6)

asamAtmVclEncapsAutodetectautoDetectPPP(3) orautoDetectIpoePpp (5)

asamAtmVclEncapsTypellcSnapBridged(1),llcNlpid(3),vcMuxBridged(4),vcMuxPPPoA(6)

VC

Client Port

PPPCCE

Client Port

PPPCCE

Client Port

PPPCCE

VC

VCBridgePortVLANPort

Client Port

PPPCCE

VC

VC



PPP Cross-connect inside the ISAMPPP cross-connect forwarding is implemented by a cooperation of functions in the LT board and NT board as shown in Figure 9-42.

Figure 9-42 PPP cross-connect inside the ISAM

9.13 IP-aware bridge mode

IP-aware bridge mode is a predecessor of the “secure forwarding in the iBridge”, also called enhanced iBridge feature. This mode is only supported for IPv4.

In the IP-aware bridge mode, the ISAM can be an “IP-aware bridge” without being an IP next-hop. Subscribers connected to the ISAM are seen as being directly attached to the edge router IP interfaces.

IP-aware bridgeThe end subscribers use the IP address of the edge router as their default gateway, while the IP edge router sees the end subscriber subnets as directly attached networks. The ISAM is situated in between the edge router and the networks and performs packet forwarding at layer 3.

LT

PPPCCE

PPPCCE

DSLAM

EMAN

NT

PPP CC Client Port

PPP CC Engine

PVC, EFM, VlanPort or EthPhy

L2 Fwd

L2 Fwd

Note — The IP-aware bridge is still supported by the ISAM, but its support will be removed over time. New deployments using IP-aware bridge are unadvised.



In an IPoA/IPoE DHCP scenario, the upstream packet forwarding happens as follows:

• End-subscriber devices use ARP to contact the default gateway (really the IP edge).

• The LIM learns the end subscriber subnets by snooping DHCP messages, and based on this knowledge, the LIM performs a proxy ARP function and returns 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 LIM FIB must be configured by the operator.

In the downstream direction, the forwarding happens as follows:

• The IP edge router sees the end-subscriber subnets as directly attached networks.• When the IP edge uses ARP to contact an end-subscriber IP address, the relevant

LIM replies by way of a network-facing proxy ARP function.• When downstream packets arrive in the ISAM, they are forwarded at layer 3 into

the correct subscriber PVC, based on a host route that was automatically created by the ISAM when the DHCP session was set up.

Figure 9-43 shows the IP-aware bridge functional model.

Figure 9-43 IP-aware bridge functional model

In IP-aware bridge mode, the VRFs on the LT boards have the FIBs and do the layer 3 forwarding. Two separated FIBs per VRF (upstream FIB and downstream FIB) prevent subscriber-to-subscriber communication. The SHub operates as a bridge. Between LT boards and SHub, one V-VLAN per VRF is required to indicate the VRF that IP packets belong to. The P-VLANs links the ISPs to the ISAM SHub.

In IP-aware bridge mode, the LT boards provide VLAN aggregation. A number of P-VLANs can be aggregated together to form an IP interface at the network side. VLAN aggregation is used in a network where subscribers with the same source IP address access different services offered by the same ISP.

Tra

ffic

man

agem

ent

(sha

ping

per

VLA

N)

Multicastforwarder

BTVMux

Option 82

Voice

Video

HSI

VRF IP

Unicast VLAN

BTV VLAN

BTV VLAN

Edge EMAN NE

IPoArelay

IP-awarebridge

Unicast VLAN

DHCPrelay

DSL

DSL

DSL

802.1x

Unicast VLAN

Unicast VLAN

DHCPrelay



Subscriber access interfacesFigure 9-44 shows the subscriber access interfaces.

Figure 9-44 Subscriber access interfaces

IPoEoA subscriber interfaces

An IPoEoA subscriber interface is a layer 2 interface created on a PVC, which is configured in RFC2684 LLCSNAP bridged or RFC2684 VC-MUX bridged encapsulation modes.

An IPoEoA interface is attached to a VR by configuring an unnumbered IP interface on top of it.

The VR is always determined via configuration.

Multiple subscriber sessions (or subscribers) can exist on the same IPoEoA interface. A session corresponds to all traffic originated from or destined to a host that is seen (IP address) by the ISAM in the customer environment.

IP addresses assigned to the subscribers on an IPoEoA interface have to be known by ISAM in order to support IP forwarding, ARP proxy, and IP anti-spoofing.

IPoA subscriber interfaces

An IPoA subscriber interface is a layer 2 interface created on a PVC which is configured in RFC2684 LLCSNAP routed or RFC2684 VC-MUX routed encapsulation modes.

An IPoA interface is attached to a VR by configuring an unnumbered IP interface on top of it.

The VR is always determined via configuration.

Multiple subscriber sessions (or subscribers) may exist on the same IPoA interface. A session corresponds to all traffic originated from or destined to a host that is seen (IP address) by the ISAM in the customer environment.

ATM

AAL5

RFC 2684

Ethernet

IP

PHY

Ethernet

IP

ADSLx

IPoEoA

ATM

AAL5

RFC 2684

IP

ADSLx

IPoA IPoE

User access Network interface

Virtual router

Ethernet

IP

VDSLx

IPoE

PTM



IP addresses assigned to the subscribers on an IPoA interface have to be known by the ISAM in order to support IP forwarding and IP anti-spoofing.

Authentication/authorization/accountingThe ISAM provides the possibility to authenticate the subscribers, to make sure that only those subscribers who have access rights can make use of the services offered by the service providers.

IPoE subscriber interfaces

The following applies for IPoE subscriber interfaces:

• The subscriber interfaces are authorized for services by associating with an IP-aware bridge corresponding to the service provider. RADIUS authentication only verifies the access rights of the subscribers.

IPoA subscriber interfaces

The following applies for IPoA subscriber interfaces:

• No authentication mechanism is defined.• The subscriber interfaces are by default considered as authenticated when

configured.• The subscriber interfaces are authorized for services by associating with an

IP-aware bridge, corresponding to the service provider.

Service provider selectionService provider selection is static (by way of configuration).

IPoE and IPoA subscriber interfaces are statically assigned to an IP-aware bridge, corresponding to the NSP. Subscribers connected to the ISAM by way of the same interface can only get access to the NSP network configured on that interface.

Subscriber IP address managementSubscriber IP address assignment can be either static (by way of configuration) or dynamic.

• Static IP address assignment: IPoE and IPoA subscriber interfacesIP addresses are statically assigned to the subscribers. Static IP address assignment is only supported for IPoE and IPoA subscriber interfaces.

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



IP-aware bridge scalabilityThe IP-aware bridge forwarding model supports sharing the same service provider VLAN over multiple ISAMs in the EMAN network. However, sharing the same VLAN for many subscribers would increase the number of broadcast storms (due to ARP and DHCP protocols) in the EMAN network, proportional to the number of subscribers (potentially tens of thousands). Large numbers of broadcast storms can lead to a scalability issue in both the ISAM control plane and the ISAM data plane (layer 2 FIB).

The broadcast storms would become even worse when the layer 2 switches in the EMAN (see the layer 2 switch in Figure 40) do not have the feature to prevent subscriber-port-to-subscriber-port communication (ports connected to the ISAMs). That is, any broadcast message issued by one of the ISAMs would be broadcast to the rest of the ISAMs.

Control plane scalability

Because the control plane of the ISAM handles the broadcast ARP and DHCP messages, the control plane would be overloaded with the ARP and DHCP broadcast storms.

The number of broadcast ARP messages that the ISAM control plane needs to handle on the network side (in downstream) would be increased enormously because:

• ARP requests issued by one of the ISAMs to resolve the edge router MAC address would be broadcast to the rest of the ISAMs via the layer 2 switches in between.

• Gratuitous ARP requests issued by one of the ISAMs to announce the subscriber IP address/MAC address relation would be broadcast to the rest of the ISAMs via the layer 2 switches in between.

• ARP requests issued by the edge router to resolve subscriber MAC address would be broadcast to all the ISAMs.

The number of broadcast DHCP messages that the ISAM control plane needs to handle on the network side (in downstream) would be increased enormously because:

• Broadcast DHCP messages (DHCP-DISCOVERY/REQUEST) issued by the subscribers would be broadcast to the rest of the ISAMs via the layer 2 switches in between.

• Broadcast DHCP messages (DHCP-OFFER/ACK) issued by the layer 3 DCHP relay agent located at the IP edge (assuming the broadcast flag is enabled) would be broadcast to all the ISAMs.

To avoid overloading the ISAM control plane with the broadcast storms, the ISAM implements an intelligent filtering mechanism in hardware. This mechanism discards (in the downstream direction) all the broadcast ARP and DHCP protocol messages which are not relevant for this ISAM (see ISAM-B in Figure 9-45).



Figure 9-45 Broadcast storms in the EMAN

DHCP protocol - LT control plane scalability

• The LT data plane discards all the client-initiated DHCP messages (DHCP op code = 1) received from the network because the client-initiated DHCP messages are NOT expected from network interfaces.

• The LT plane discards all the server-initiated DHCP messages when the chaddr is NOT the LT MAC address.

DHCP protocol - NT control plane scalability:

DHCP messages received from the network interfaces are processed by the NT control plane in case of “dynamic IP address allocation” mode for the management of the SHub. As this would require all the DHCP messages to be forwarded via the control plane, scalability cannot be guaranteed when the “dynamic IP address allocation” mode is enabled.

ARP protocol - LT control plane scalability:

The LT data plane discards all ARP requests received from the network interfaces if the ARP policy is not set to “trusted” or if the target subscriber is not known by the LT board (that is, not learned via DHCP snooping or via configuration).

EMAN

NTLT

LTNE-B

User

NE-AIP

networkIP edge

User

Control plane Data plane

DHCP-DISCOVERYDHCP-REQUEST

DHCP relayagent

DHCP-OFFERDHCP-ACK

Gratuitous ARPARP for next-Hop

ARP foruser

DHCP-DISCOVERYDHCP-REQUEST

DHCP-OFFERDHCP-ACK

Gratuitous ARPARP for next-Hop

ARP foruser

Upstream broadcast packets(generated by an NE) are reflectedback to other NEs



ARP protocol - NT control plane scalability:

• When IP forwarding is enabled in the SHub for a slow path VRF, the SHub control plane has to handle ARP messages destined for any of the VRF IP interfaces.

• A VRF (slow path) is required for any of the following cases:• IP forwarding of the RADIUS control packets when the ISAM acts as RADIUS

client for 802.1x subscriber authentication, or operator authentication• IP forwarding of the DHCP control packets when the ISAM acts as a layer 3 DHCP

relay agent• IP forwarding of the SHub management control packets when the SHub is managed

via a dedicated IP address• IP forwarding of the subscriber data/control packets when the ISAM acts as an IP

router• To achieve the control plane scalability, ARP filters are made “VLAN and IP

address” aware. Therefore, only those ARP requests destined for any of the SHub IP interfaces are extracted to the control plane. Because the number of filter resources in the SHub data plane is limited, a number of ARP filters are reserved (32 for ECNT-A and 128 for ECNT-C). The SHub ARP control plane scalability is then only guaranteed as long as the number of SHub X IP interfaces is within the reserved limit, otherwise scalability is not guaranteed.

Data plane scalability

In the ISAM, source MAC learning is by default enabled on the network ports of the NT. In the IP-aware bridge mode, the ISAM only needs to learn the edge router MAC addresses. However, as described in the preceding section, the fact that the layer 2 switches in the EMAN broadcast the ARP/DHCP broadcast messages (received from one of the ISAM ports) to the rest of the ISAM, would lead to every ISAM learning the MAC addresses of each other on the network ports.

In IP-aware bridge mode, the public MAC addresses of the LT boards are exposed to the EMAN, which means that the MAC address of each LT board would have to be learned.

This would cause a layer 2 FIB size scalability issue because the number of the ISAMs would be increased proportionally to the number of subscribers (potentially tens of thousands). This would become even worse (multiplied by the number of service provider VLANs of an IP-aware bridge) because the MAC learning is in the scope of a VLAN.

To overcome the layer 2 FIB size scalability issue, MAC learning is disabled on the ISAM network ports, provided there is a single network interface in the ISAM (that is, a single GE or a group of GEs with link aggregation). Therefore, it is not required to learn the MAC address at the network interface because there is only one. The traffic associated with unknown MAC addresses is simply flooded to the single network interface, assuring the correct network connectivity.


10 — Protocol handling in a Layer 2 forwarding model


10.2 Link aggregation 10-3

10.3 RSTP and MSTP 10-5

10.4 Connectivity Fault Management 10-7

10.5 802.1x support 10-10

10.6 ARP 10-11

10.7 VBAS 10-12

10.8 DHCP 10-13

10.9 IGMP 10-19

10.10 PPPoE 10-19

10.11 DHCPv6 10-24



10.1 Introduction

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

• Layer 2 Control Protocol handling:Layer 2 Control Protocols are protocols defined for use within the Layer 2 network. They are defined to influence the forwarding behavior within this Layer 2 network and/or to maintain and troubleshoot this Layer 2 network. This includes protocols that have an individual or group of interfaces as scope, and it includes protocols that have the end-to-end connectivity within this Layer 2 network as scope.

• Application protocol handling:These are protocols defined at a layer higher than Layer 2. They are used for communication between nodes connected to the Layer 2 network and/or nodes deeper in the IP (Layer 3) network. Some participation of the ISAM in the processing of these protocols allows these nodes, or more in general the total network, to give a better service.

Layer 2 Control Protocol handlingTable 10-1 shows the protocols of the Layer 2 control protocol handling.

Table 10-1 Layer 2 control protocol handling

Application protocol handlingTable 10-2 shows the protocols of the application protocol handling.

Table 10-2 Application protocol handling

Protocol Described in Section

Link Aggregation 10.2

Rapid Spanning Tree Protocol and Multiple Spanning Tree Protocol 10.3

Connectivity fault management 10.4

802.1x 10.5

Protocol Described in Section

ARP 10.6

VBAS 10.7

DHCP 10.8

IGMP 10.9

PPPoE 10.10

DHCPv6 10.11



10.2 Link aggregation

Link Aggregation allows one or more links to be aggregated together to form a Link Aggregation Group, such that a MAC client can treat the Link Aggregation Group as if it were a single link. Link aggregation is defined in IEEE 802.3-2005, clause 43. This specification specifies the establishment of Link Aggregation Groups, consisting of N parallel instances of full duplex point-to-point links operating at the same data rate.

This Link Aggregation Group provides increased bandwidth and/or increased availability. Link aggregation is defined with a load sharing mechanism that distributes the traffic over the active links of the Link Aggregation Group. When one of the physical links of the link Aggregation Group is not longer active, then the load sharing adapts and distributes the traffic over the remaining active links. If the total traffic exceeds the bandwidth of an active link, then normal QoS handling applies.

Figure 10-1 shows an example of link aggregation.

Figure 10-1 Link aggregation

Link Aggregation is defined for use between any type of Ethernet nodes (that is, both bridges and end stations). The binding of links into Link Aggregation Groups may be under manual control by an operator. In addition, automatic determination, configuration, binding, and monitoring may occur through the use of a Link Aggregation Control Protocol (LACP).

Link Aggregation Control Protocol

The Link Aggregation Control Protocol (LACP) is part of the IEEE 802.3-2005 clause 43. The LACP provides a standardized means for exchanging information between Partner Systems on a link to allow their Link Aggregation Control instances to reach agreement on the identity of the Link Aggregation Group to which the link belongs, move the link to that Link Aggregation Group, and enable its transmission and reception functions in an orderly manner.

NE

ADSL

FE/GE

m x FE/GE

n x FE/GE

IP Edge Router /BRAS

EMAN

EthernetBridge

NSP IP backbone

NSP IP backbone

NSP IP backbone

Link AggregationGroup 1

Link AggregationGroup 2



Also the use of LACP requires some operator control. Especially important is the configuration of actor-keys per physical link. This parameter identifies the Link Aggregation Group and is exchanged within the protocol to the peer side to assure that the links of one link aggregate really connect to the same node.

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.

Link aggregation supportLink aggregation is supported on:

• network links• subtending links• the GE Ethernet LT board UNI and NNI port types

Link Aggregation Groups are defined by configuring individual physical links with identical link aggregation parameters. Especially the parameter actor-key is important as the Link Aggregation Group is defined as the set of links with the same value for this parameter.

The use of the LACP protocol can be enabled or disabled.

Load balancing is supported and the load balancing criteria can be configured to use the source and/or destination MAC address, or to use the source and/or destination IP address.

Figure 10-2 shows link aggregation support.



Figure 10-2 Link aggregation support

10.3 RSTP and MSTP

The ISAM can be configured with several network interfaces. They can be used to connect the ISAM to multiple Ethernet Bridges, see Figure 10-3 as example, or directly to end stations such as, for example, a Router or a BRAS.

For an Ethernet network to function properly, only one active path can exist throughout an EMAN Network between two end stations. These paths are symmetrical, that is, they are used for both directions of communication.

Figure 10-3 Spanning Tree between NE and EMAN

Note — Link aggregation is not supported on subscriber links (with the exception of the GE Ethernet LT board UNI subscriber links) .

xHub LT

network links

LT links

s s

n n L

LTL

n n

.subtending links

LT links

L.A.G.

network links

xHub

L.A.G.

subtending links

PVCs (on top of xDSL links)

PVCs (on top of xDSL links)

n: link type is network linkL: link type is LT links: link type is subtending link

L.A.G.

L.A.G.

s s

NE

ADSL

FE/GE

m x FE/GE

n x FE/GE

IP Edge Router /BRAS

EMAN

EthernetBridge

NSP IP backbone

NSP IP backbone

NSP IP backbone: Link disabled by spanning tree protocol

Selected root of spanning



RSTP

The Rapid Spanning Tree Protocol (RSTP) as defined in IEEE 802.1D-2004, clause 17, is a Layer 2 Control Protocol that provides path redundancy while preventing undesirable loops in the network.

Providing path redundancy starts with having a physical redundant network topology.

Multiple active paths between end stations cause L2 loops in the network. If a loop exists in the network topology, the potential exists for duplication of messages. Therefore the task of RSTP is defining a single active path between each pair of end stations.

To realize this single active path, RSTP forces certain redundant data paths into a standby (blocked) state. The logical topology that is realized in this way is a single tree with a selected root end station and with the other end stations at leave positions. Ethernet Bridges are involved in selecting the active path and blocking the standby paths. After a network node or link has become unavailable, RSTP will run again to define a new tree topology.

MSTP

If the network contains more than one VLAN, the logical network configured by a single RSTP would work, but better use can be made of the available redundant links by using an alternate spanning tree for different (groups of) VLANs.

Multiple Spanning Tree Protocol (MSTP), which uses RSTP for rapid convergence, enables VLANs to be grouped into a spanning-tree instance. Each instance has a spanning-tree topology independent of other spanning-tree instances. This architecture provides multiple forwarding paths for data traffic, enables load balancing, and limits the number of spanning-tree instances required to support a large number of VLANs. MSTP is defined in IEEE 802.1Q clause 13.

Support of RSTP and MSTP

The ISAM can be configured to act as an Ethernet Bridge within a EMAN Network. Then RSTP and MSTP is supported on network links, on subtending links, and on subscriber links terminated on the NT board. The MSTP protocol is also supported on the GE Ethernet LT board NNI port type.

The ISAM can be configured to act as Router. This router functionality is provided on top of the Layer 2 Bridging functionality. All ISAM links are considered as being part of a single EMAN Network. In that case the ISAM acts as an end station connected to this EMAN Network. Then, as before, RSTP and MSTP is supported within this EMAN Network on network links, on subtending links, and on subscriber links terminated on the NT board.

Note — The GE Ethernet LT board NNI port type is used for access aggregation or business services access but not as an network uplink interface.



In some network topologies the use of RSTP or MSTP will not give benefit. This is the case when the single active path is already realized at physical level. An example is that the user equipment connected to LT boards (must) have already by construction a single physical interface and inherently this will form a single active path. Therefore and because of this RSTP and MSTP is not supported on these interfaces. Other examples are the use of a single link (aggregation group) between a hub and a subtending ISAM. Therefore RSTP and MSTP can be enabled or disabled per Ethernet interface of the ISAM. As an example, RSTP and MSTP shall be disabled on the network interface of the subtending ISAM in case it is disabled on the corresponding subtending interface in the Hub ISAM.

10.4 Connectivity Fault Management

This section describes Connectivity Fault Management (CFM) and identifies the level of support in the ISAM.

CFM elementsConnectivity Fault Management (CFM) is an Ethernet Operations and Maintenance (OAM) capability that allows service providers or network operators to verify and isolate connectivity faults and configuration problems at layer 2. CFM is specified in the standard IEEE 802.1ag.

To support CFM functionality, network operators must configure software entities called Maintenance Points (MPs) on selected bridge ports on the network. MPs are points where CFM messages are inserted, extracted, or monitored to verify connectivity within part or within the whole of the Layer 2 network.

MPs are organized into Maintenance Associations (MAs) and Maintenance Domains (MDs) on a network. Table 10-3 describes the CFM elements that must be configured on an Ethernet network.

Table 10-3 CFM elements

Note 1 — The 7302 ISAM does support RSTP and MSTP towards DSLAMs in a ring.

Note 2 — The 7302 ISAM and the 7330 ISAM FTTN also support STP (IEEE 802.1D-1998, clause 8) for inter-operability with older routers.

CFM element Description

MD An MD corresponds to the administrative OAM domain and is assigned a level from 1 to 8. A typical example is that an administrative OAM domain is defined per operator involved in the offering of a service with the Layer 2 network.

Associated to an MD are one or multiple MAs.

(1 of 2)



IEEE 802.1ag defines these generic CFM OAM procedures. DSLF TR-101 defines the usage of these procedures in a Layer 2 Access Network.

An access aggregation network typically has the following MD levels:

• Service provider domain from the edge router/BNG to the CPE• Carrier domain from the edge router/BNG or Ethernet switch to the user port on

the ISAM• Intra-carrier domain from the edge router/BNG or Ethernet switch to the network

port on the ISAM• Access link domain from the LT port on the ISAM to the CPE

Figure 10-4 shows CFM implemented on a typical access aggregation network.

When a customer contacts the service provider helpdesk because of lack of service, the service provider can run a test in the service provider domain from the BNG toward the CPE. If the fault is isolated to a specific section, the service provider can notify the owner of that section who can run tests at a lower level within his domain. This continues until the failing point is identified.

MA An MA is defined as an OAM maintenance entity per service instance per MD. The service instance could be a VLAN or a set of VLANs. The OAM maintenance entity scope is defined by a set of associated Maintenance end Points (MEP). The MEPs define a closed segment of the VLAN in the Layer 2 network. The segment matches the scope or involvement of a particular administrative OAM domain (operator) in that VLAN.

As such, MDs/MAs allow network operators to test the segment of a given VLAN that is within their own scope. E.g. it allows them to perform a test on all links and nodes of their own network and being used by the VLAN or service. Typically the set of operator segments are all at the same MD level and then the MDs/MAs can not overlap.

MDs/MAs also allow network operators to divide a network into separate hierarchical administrative OAM domains. An MD/MA at a higher level has no visibility inside an MD/MA at a lower level. Also at the higher level the same concepts apply: the scope is delimited by MEPs and the MDs/MAs at the same higher level can not overlap.

There may be one or more MA, that is, service instances, per MD. There may be multiple MAs for the same service instance (VLAN) if these are within different MDs and the lower level MDs/MAs are terminated with MEPs.

MP MPs are organized into MAs and MDs and are configured on ports within an MA (VLAN) defined within an MD level.

There are two types of MPs:

• Maintenance end points (MEPs)• Maintenance intermediate points (MIPs)

MEPs are points that identify the border of a maintenance entity. MEPs can initiate or terminate CFM messages.

MIPs are points inside the network segment that is defined as a maintenance entity. MIPs can respond to and allow the transit of CFM frames originated from another MP.

CFM element Description

(2 of 2)



Figure 10-4 CFM on the access aggregation network

CFM functionsThe CFM protocols define multiple functions that act as tools to test and isolate connectivity faults in the network.

The CFM link trace acts like an ICMP traceroute command. Multicast Link Trace Messages (LTMs) are sent from the originating MEP. Each MIP along the trace path inspects the message to determine whether the target MAC address of the LTM is known. If the MIP knows the MAC address, the MIP forwards the LTM to the next MIP, and a response in the form of a Link Trace Reply (LTR) message is sent back to the originating MEP. A MIP that does not know the target MAC address does not send back an LTR. When the target MP responds with a successful LTR message, the link trace test is successfully completed.

A CFM loopback acts like an ICMP ping command. Multicast or unicast loopback messages (LBMs) are sent from the originating MEP. In the case of a unicast LBM, the MAC address of the destination MP is inserted. When the target MP receives the LBM with the matching MAC address, it sends back a loopback response (LBR) to the originating MP. When the originating MP receives the LBR, the loopback is complete. In the case of a multicast LBM, each MEP within the targeted MA in the MD level that receives the LBM request will reply with an LBR.

A connectivity check (CC) is a message multicast to all MEPs in the same MA at fixed intervals. When a peer MEP does not receive a specified number of CCM reply messages in a given time, a fault is raised.

CFM support in the ISAMThe ISAM supports the configuration of MDs, MAs and MEPs. MIPs are created by the ISAM based on the parameter setting of the MA.

The service instance managed by an MA covers a single VLAN.

DSLAM

Ethernetaccessnetwork

Regionalnetwork

BNG

RG

CPE

MEPMIP

Ethernetswitch

MD level 7

MD level 1

MD level 5

ME Service provider

ME carrier

ME Intra-carrier

Access link ME

Scope of accessnetwork operator

Scope of serviceprovider operator

MD level 3



The ISAM supports MIPs and network facing MEPs at UNI ports (which includes UNI ports supported by the GE Ethernet LT board). The ISAM also support MIPs at the GE Ethernet LT board NNI ports. Within these MPs the ISAM responds to LBMs and to LTMs coming from the network. The ISAM responds to LBM coming from the user (see DSLF TR-101).

The ISAM supports network facing MEPs on the LT board at its GE interface towards the NT board. Within these MEPs the ISAM responds to LBMs and to LTMs.

For information about CFM MAC addresses and performing CFM fault detection and isolation, see TNG 120 in the Operations and Maintenance Using CLI for FD 24Gbps NT document.

10.5 802.1x support

The 802.1X protocol complies with both the IEEE 802.1X and the CCSA specification. Its purpose is to control the access of users to the Layer 2 Access Network. Each 802.1X-enabled user port (including the GE Ethernet LT board UNI user ports) is by default in a closed status and successful authentication is needed to open the port.

This functionality is mapped to the LT board, where the authentication state of the port is enforced; see Figure 10-5. Packets from unauthenticated subscribers are dropped at the LT board. 802.1X on the LT board communicates with the NT board by way of the internal communication to perform the authentication. The NT board uses a local database or contacts a RADIUS Server to execute the authentication request.

• For an un-authenticated port, all subscriber frames are discarded.• For an authenticated port, all subscriber frames are processed based on the Layer

2 configuration

Note — The GE Ethernet LT board NNI ports do not support 802.1x



Figure 10-5 802.1x in the ISAM

10.6 ARP

The IETF RFC 826 defined Address Resolution Protocol (ARP) is a protocol defined within the context of using IP over Ethernet. An IP node uses the ARP protocol to obtain the Ethernet MAC address of another IP node identified by a known IP address and connected to the same Layer 2 network.

The ISAM has a limited ARP handling functionality, but it is sufficient to prevent broadcast storms toward the subscribers. This is achieved in the following ways:

• in iBridge mode:• When an ARP request is received from a user port, 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 other user ports. This behavior is also true for the GE Ethernet LT board NNI ports.

• 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 case of the GE Ethernet LT board NNI ports, the ARP request is only broadcast in the VLAN (not configurable).

• in VLAN 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.

Performs authenticationby means of contactinga RADIUS server. The result is sent backto the LT.

LIMCPE

LIM EREthernet

Handles the 802.1x protocol, communicates with the systemcontroller to perform the authentication, controls the port state.

xHub

NTControl

802.1x



• in secure-forwarding-enabled iBridge/VLAN cross-connect mode:An ARP relay function exists to forward the downstream ARP request messages to the right user only. This is achieved by forwarding downstream ARP request messages to the user port that owns the IP address that is to be resolved via the ARP request.In the upstream direction this ARP relay will perform IP address anti-spoofing, that is, it will discard ARP request messages when the sender IP address is not owned by a user behind the same user port, and it will discard ARP messages addressed to other users behind the same user port. Valid ARP requests will be forwarded to the network.

• in IP-aware bridge mode:An ARP proxy function exists that will reply to upstream and downstream ARP request messages with its own MAC.

10.7 VBAS

The Virtual Broadcast Access Server (VBAS) protocol is defined directly on top of the Ethernet Layer and allows the external BRAS to query the ISAM 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 ISAM to gather physical port information corresponding to the MAC address of the new subscriber.

• VBAS response:Upon receiving the request packet, the ISAM sends a VBAS response packet to the BRAS. This packet includes the physical port information of the new subscriber.

All messages are 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 floods 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.

Note 1 — The ARP-Relay function learns the IP addresses from the end-users either via DHCP snooping or via static configuration.

Note 2 — The GE Ethernet LT board NNI ports do not support secure forwarding

Note — VBAS is only supported on the 7302 ISAM.



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 ISAM receives a VBAS query, subscriber information is retrieved from the VLAN configured as PVID.

VBAS handling in the 7302 ISAMFigure 10-6 shows the VBAS handling in the 7302 ISAM.

Figure 10-6 VBAS handling

VBAS handling in a subtended 7302 ISAMWhen 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 Destination Address (DA) of the VBAS packet is equal to the MAC address of the subtended 7302 ISAM.

10.8 DHCP

The Dynamic Host Configuration Protocol (DHCP) is a client-server protocol that enables DHCP Servers to configure internet hosts. The DHCP protocol is defined on top of UDP/IP. DHCP simplifies the configuration of a host since no IP addresses, subnet masks, default gateways, domain names, or DNSs must be locally configured within the host. Instead, 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, it reduces the number of IP addresses to be used, and it simplifies maintenance. DHCP is defined in IETF RFC 2131.

A problem to solve when using this technology is that the DHCP Client must be able to communicate to the DHCP Server. This is achieved by the DHCP Client starting the communication with a broadcast message. The DHCP Server will receive this message in case the Server is connected to the same Layer 2 network as the Client. IETF RFC 2131 and RFC 3046 define a DHCP Relay Agent for when this is not the case. Then a DHCP Relay Agent connected to the Layer 2 network of the Client will convert the broadcast message to a unicast message and send it to a Server further in the IP network. In doing so, the DHCP Relay Agent can add 'option 82' information. That information can be used by the DHCP Server to identify the subscriber, and when mirrored back in reply messages it helps the DHCP Relay Agent to forward the replies to the correct Client. In its definition this DHCP Relay Agent is a function within a router for which it can be referred to as a 'Layer 3' DHCP Relay Agent.

BRASCPE

CPE

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.

Sends VBAS request with MAC DA address (the MAC address of the user which is to be resolved) and waits for the response.

NE

EMAN



DSLF TR-101 defines a “Layer 2” DHCP Relay Agent, that is, a Relay Agent functionality in the middle of the Layer 2 Access Network. The Layer 2 DHCP Relay Agent is assigned to be a responsibility of the DSLAM. It shall add option 82 information (which allows the Server to identify the subscriber) but leaves the broadcast message a broadcast message. Converting the broadcast message to a unicast message is not needed when the DHCP Server is connected directly to the Layer 2 Access Network, or is the responsibility for a real DHCP Relay Agent at the edge of the Layer 2 Access Network.

The ISAM provides Layer 2 DHCP Relay Agent functionality when it is configured for Layer 2 forwarding and a full (Layer 3) DHCP relay when it acts as an IP Router.

Layer 2 DHCP Relay AgentThe ISAM provides Layer 2 DHCP Relay Agent functionality for IPoE and IPoA subscriber access interfaces for all of the Layer 2 forwarding modes that provide IPoE and/or IPoA:

• the iBridge• the IP-aware bridge• the protocol-aware cross-connect (that is, C-VLAN cross-connect and

S/C-VLAN cross-connect)• the iBridge and cross-connect with IPoA to IPoE interworking function

This Layer 2 DHCP Relay Agent is supported for the L2 forwarding modes above, irrespective of secure forwarding being enabled or not.

The Layer 2 DHCP Relay Agent functions can be split in three parts:

• Relaying DHCP messages to and from network and subscriber interfaces• Option 82 handling• Client hardware address (chaddr in the DHCP message) concentration

Relaying DHCP messages to and from network and subscriber interfaces

Relaying DHCP messages in iBridge and VLAN cross-connect

The Layer 2 DHCP Relay Agent for the iBridge and for the protocol-aware cross-connect forwarding modes is distributed over the LT boards.

Note — The layer 2 DHCP Relay Agent is only supported on the GE Ethernet LT board UNI ports.



Figure 10-7 Layer 2 DHCP relay implementation)

The DHCP client can send broadcast or unicast DHCP messages. These will be forwarded in the upstream direction:

• If the insertion of option 82 is enabled, the ISAM verifies the DHCP message and adds option 82 to a valid DHCP message as described further on.

• If the insertion of option 82 is disabled, the ISAM still verifies the DHCP message as described further but does not add an option 82.

But with or without option 82 insertion, the broadcast message remains a broadcast message, the unicast message remains a unicast message. For more information on the handling and configuration of DHCP Option 82; see section “Option 82 handling”.

In the downstream direction the DHCP Relay within the Edge Router (or the DHCP server in case it is directly connected to the Layer 2 Access Network) sends broadcast or a unicast DHCP messages. This depends on the broadcast flag inside the DHCP message sent from the DHCP Client. In all cases the Layer 2 DHCP Relay Agent will forward the DHCP message to the correct user only. For a unicast DHCP message the user is identified from the MAC address in the Ethernet header, for broadcast DHCP messages the user is identified from the payload of the DHCP messages, for example, chaddr. In any case the option 82 is removed before forwarding the DHCP message.

Relaying DHCP messages in IP-aware bridge

The Layer 2 DHCP Relay Agent for the IP-aware bridge forwarding mode is very similar to the Layer 2 DHCP Relay Agent for iBridge. Its implementation is also distributed over the LTs. The possibilities for option 82 insertion are also the same.

Some differences exist in the forwarding behavior.

LT NT

xHub

CPE

LT EREthernet

DHCP client

IPnetwork

DHCPserver

DHCP relay

US: Bridge to the network interfaces (unicast packet forward based on FDB, broadcast packet: flood to all the network interfaces that participate in the VLANDS: Bridge to the LTs/subtending interfaces (unicast packet: forward based on FDB, broadcast: flood to all network interfaces that participate in the VLAN

US: adds option 82 and sends packet to xHubDS: remove option 82 and send on to correct user port

US/DS: DHCP boadcast or unicast packet



Upstream relay (from subscriber to network) - broadcast/unicast DHCP message:

• A broadcast DHCP message is further broadcast into one specific VLAN associated with the VRF (of an IP-aware bridge). This specific broadcast VLAN is configurable per VRF. In case no broadcast VLAN is configured, then the DHCP message is flooded into all VLANs associated to the VRF.

• When chaddr concentration is enabled: the subscriber chaddr is replaced by the LT board MAC address, and the user XID (transaction ID) is replaced by an LT-board-wide unique XID.

Downstream relay (from network to subscriber) - broadcast/unicast DHCP message:

• In the DHCP session set-up phase and if chaddr concentration is not enabled: the DHCP message is forwarded to the subscriber interface that is selected based on the chaddr.

• In the DHCP session set-up phase and if chaddr concentration is enabled: the DHCP message is forwarded to the subscriber interface that is selected based on XID. Both the subscriber chaddr and the subscriber XID are restored before sending the DHCP message to the subscriber.

More information on the client hardware address concentration function is provided in section “Client hardware address concentration”.

Relaying DHCP messages in the iBridge and cross-connect mode with IPoA to IPoE interworking function

The Layer 2 DHCP Relay Agent for the iBridge and cross-connect mode with IPoA to IPoE interworking function is very similar to the Layer 2 DHCP Relay Agent when the IPoA to IPoE interworking function is absent. Its implementation is also distributed over the LT boards. The possibilities for option 82 insertion are also the same.

But here, IPoA packets from and to the user do not have an Ethernet header. As such, the chaddr in the upstream DHCP messages is normally not a MAC address. The ISAM will insert itself an identifier in the chaddr of upstream messages. This field being returned by the DHCP Server allows the ISAM to identify the correct user. The ISAM will restore the original chaddr before sending the DHCP message to the user.

Option 82 handling

IETF RFC 3046 defines a “Relay Agent Information option” and assigns it the code 82. In this way the option is often referred to as “option 82". Option 82 provides security when DHCP is used in public access networks. It provides the DHCP Server with trusted information on who is requesting an IP address.

But to make it really a trustable identifier the ISAM shall also discard upstream messages with an option 82 already added by the user. Therefore the ISAM also makes some validity checks on upstream DHCP messages.

In the upstream direction, the insertion of DHCP option 82 is configurable. If enabled, option 82 parameters are inserted both for unicast and broadcast DHCP messages. If disabled the ISAM obviously does not add option 82. The validity checks are however executed also when option 82 insertion is disabled.



IETF RFC 3046 defines option 82 as containing two sub-options: the circuit-id being sub-option 1 and the remote-id being sub-option 2.

In addition to enabling or disabling option 82 insertion, it is possible to control the insertion and contents of the sub-options:

• the circuit ID: this can be configured with one of the following values:• do not add this sub-option into option 82• add the customer ID into the circuit-id sub-option• generate a physical line ID and add this into the circuit-id sub-option

• the remote ID: this can be configured with one of the following values:• do not add this sub-option into option 82• add the customer ID into the remote-id sub-option• generate a physical line ID and add this into the remote-id sub-option

Insertion of the circuit ID and/or remote ID can be enabled or disabled per VLAN in iBridge or VLAN cross-connect mode, and per VRF in IP-aware Bridge mode.

Customer ID

The Customer ID is fully configurable for each DSL line, ATM PVC, Ethernet interface or VLAN port by the operator (string with a length between 0 and 64 bytes).

In case the Customer ID is configured for one user at various levels, e.g. at ATM PVC and at DSL line level, then the most fine grained level will be used. For example, the Customer ID configured for an ATM PVC will take precedence over the customer ID configured at the DSL line.

Physical line ID

By default, the Physical line ID is auto-generated by the ISAM and contains information used to identify the precise circuit from which the DHCP message originates (for example, DSL line, ATM PVC, Ethernet interface or VLANport).

The Physical line ID syntax is configurable. The Physical line ID syntax is a concatenation of keywords, separators, and free text strings:

• for ATM-based DSL interfaces, the default value is “Access_Node_ID atm Rack/Frame/Slot/Port:VPI.VCI”

• for EFM-based DSL and for Ethernet interfaces, the default value is “Access_Node_ID eth Rack/Frame/Slot/Port”

You can use the following predefined keywords:

• Access_Node_ID: identifies the ISAM. The ISAM will insert the identifier that is configured as “System ID”

• Rack: rack number in the access node for the position of the line termination

Note — The values for the circuit ID and the remote ID are not allowed to be identical.



• Frame: shelf number in the rack. The variable is called 'Frame' to be inline with TR-101.

• Slot: slot number in the shelf.• Port: port number on the LT. On DSL or point-to-point LTs, the “port” stands for

an end-user DSL/fiber interface• VPI: VPI on user interface in case of ATM over DSL• VCI: VCI on user interface in case of ATM over DSL• Q-VID: VLAN ID on user interface (when applicable)• NVID: refers to the C-VLAN ID at the network-side, which may be different

from the user-side “Q-VID”

Bandwidth information

DSLF TR-101 defines additional sub-options on top of those defined in IETF RFC 3046. Amongst others it specifies a set of sub-options to pass DSL line bandwidth characteristics.

You can also enable or disable the insertion of the line rate characteristics per VLAN/VRF (per VLAN in iBridge or VLAN-cross-connect mode, per VRF in IP-aware Bridge mode).

When enabled, the ISAM inserts actual line rate data.

Client hardware address concentration

Client hardware address (chaddr) concentration is only supported for IP-aware bridge forwarding mode.

In IP-aware bridge, the ISAM performs MAC concentration (in the upstream direction, the source MAC address of the subscriber IP packets is replaced by the LT board MAC address) for MAC scalability in the EMAN network. Chaddr concentration means replacing the chaddr in the DHCP message by the LT board MAC address.

This is required to solve the following issues when several ISAMs, or several LT boards in the same ISAM, or both, share the same service provider VLAN in the EMAN network:

• Flooding in the downstream direction when the layer 3 DHCP relay agent is not enabled in the ISAM: As the chaddr is not learned by the Layer 2 Bridges in EMAN, any unicast DHCP messages destined for the chaddr would have to be flooded. Replacing the subscriber chaddr by the LT board MAC address avoids this flooding as the LT MAC address will always been learned in the EMAN.

Note — <ShSlt> and <ShPrt> keywords can also be used instead of respectively <slot> and <port>. The keywords <ShSlt> and <ShPrt> can be used to specify the slot and port number without leading zero. This gives an alternative for the <Slot> and <Port> keywords as defined above and provides full flexibility as to the wanted/required syntax.



• IP-aware bridge security:Due to the fact that downstream DHCP messages would always be flooded to all ISAMs (or LT boards in the same ISAM), the chaddr would have to be unique at the network level in order to have a secure DHCP handling. Replacing the chaddr by the LT board MAC address allows the chaddr to be unique only within the scope of a single ISAM or LT board.

• IP-aware bridge scalability: refer to chapter “Layer 2 forwarding”, section “IP-aware bridge scalability”.

Chaddr concentration is configurable per VRF of an IP aware bridge. When enabled, DHCP servers should use Option 82 (and, optionally, Option 61) to apply user specific IP address policies (if any) as chaddr does not refer to the user anymore.

(Layer 3) DHCP Relay AgentThis is further described in chapter “Protocol handling in a Layer 3 forwarding model”, section “DHCP relay agent”.

DHCP snoopingIf secure forwarding in Enhanced iBridge respectively in VLAN cross-connect is configured, DHCP messages are snooped in order to learn the IP address associated with the end user.

More information on DHCP snooping can be found in chapter “Protocol handling in a Layer 3 forwarding model”.

10.9 IGMP

For more information about IGMP, see chapter “Multicast and IGMP”.

10.10 PPPoE

Point-to-Point Protocol over Ethernet (PPPoE) is a network protocol for encapsulating Point-to-Point Protocol (PPP) frames inside Ethernet frames. PPP is the commonly used protocol in dialup connections. PPPoE allows to connect one or multiple PPP Client computer subscribers through an Ethernet LAN to a PPP Server. PPPoE is defined in IETF RFC 2516.

PPPoE relay

In many cases the Layer 2 (Ethernet) Access network extends Ethernet into the home network. A CPE in the home network terminates the DSL link or Ethernet interface that provides the connectivity with the Access Network. One possibility is that the CPE is a router. Then this router CPE will be the single PPP Client establishing PPPoE sessions. Another possibility is that a bridge CPE transparently bridges the request coming from a device deeper in the home network. Something in between can be that a CPE multiplexes PPPoE sessions coming from multiple devices deeper in the home network.



All these cases have in common that PPPoE frames are sent from the user equipment, through the ISAM, to a BRAS more centrally in the network. DSLF TR-101 specifies that in such case the DSLAM has to add some subscriber information to the upstream discovery messages, i.e. to the PADI, PADR and upstream PADT packets.

So for PPPoE relay, the ISAM inserts a PPPoE Relay tag in all the upstream PPPoE messages in the discovery phase (that is, frames with EtherType = 0x8863). This information insertion is the only intervention of the ISAM on PPPoE frames in the upstream direction. This means that all PPPoE messages forwarded to the BRAS will still contain the MAC address of the subscriber as source MAC address (MAC SA) and the broadcast MAC (PADI) or the MAC address of the PPPoE Server (PADR, PADT) as destination MAC address (MAC DA).

The ISAM does not make an intervention in the downstream direction.

All PPPoE messages in the session phase are forwarded without any processing.

Figure 10-8 PPPoE relay

PPPoE relay tag

The “PPPoE Relay tag” is in fact a confusing name. It refers to the “PPPoE vendor specific tag” that can be inserted by the ISAM in order to provide access loop identification data towards the PPPoE Server (typically a BRAS).

The access loop identification conveyed by the PPPoE vendor specific tag is similar as conveyed by DHCP option 82. Its format is defined in BBF TR-101. As for DHCP option 82, the tag contains the identification of the access loop on which the PADI, PADR, or PADT packet was received in the ISAM and possibly some line rate information about this loop.

The insertion of the PPPoE vendor specific tag and the sub-options to be added are configurable per VLAN.

Note — PPPoE Relay is only supported on the GE Ethernet LT board UNI port type.

US/DS: PPPoE session setup frames

US: add PPPoE relay session ID, and forwardDS: forward

PPPoE traffic

PPPoE traffic

LIM NT

xHub

CPE

LIM

CPE

EREthernet



PPPoA to PPPoE interworkingIn some cases the Layer 2 (Ethernet) Access network does not extend Ethernet into the home network. In some situations the home network is connected to the Access Network with a traditional PPP over ATM over DSL interface. Because the remainder of the Access Network is using Ethernet at the physical layer, it becomes the responsibility of the ISAM to provide an interworking function between both technologies. This interworking function is also specified in BBF TR-101.

Figure 10-9 Network topology

In case of PPPoA to PPPoE interworking, the PPP forwarder is a further enhancement of the iBridge. The PPP forwarder 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:

1 When a subscriber initiates a PPPoA session, the ISAM first initiates a PPPoE session toward the BRAS. The involved PAD-x messages are sent with a VLAN tag with priority 7.

2 Once the PPPoE session is established, the initial PPP (LCP) request from the subscriber is forwarded within that PPPoE session.

3 The remainder of the PPP negotiation happens between the subscriber terminal and the BRAS.

The initial PPP request packet and all further packets sent within the established PPPoE session are sent with a VLAN tag with the priority configured for the PPP client port.

During the session, every upstream PPP packet is encapsulated in PPPoE, where the MAC address of the ISAM is used as MAC source address. Downstream, the reverse operation takes place and the MAC layer is stripped. From a BRAS perspective, the session looks like any normal standard PPPoE session.

I

ATMtermination

PPPoA - PPPoE Interworking

USB

Ethernet

IP

Local Loop

USB Modem

Bridge

Routing Gateway NE

PPP-L2TPinterworking

L2TP

EMAN

IP

IP Edge

ISP

Srv: Video

Srv: VoIP



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 ISAM provides the PPPoE Server with access loop identification and line rate information just as for PPPoE Relay. The difference is that here these messages are generated by the ISAM.

Beside all these similarities there is still something special:

The ISAM can inform the PPPoE Server that the PPPoE session being established is an “interworked session, that is, a session established on behalf of a user. This could be useful for the BRAS, for example, to use a different a approach for limiting the number of sessions per client. This information is provided through the insertion of the BBF-IWF-tag sub-option in the PPPoE vendor specific tag. This sub-option is defined in BBF TR-101.

Adding this sub-option can be enabled or disabled per PPP cross-connect Engine.

A second special thing relates to the Maxim Transmit Unit (MTU). In this scenario the PPP Client is a PPPoA user and it assumes it can send PPP packets of 1500 bytes. To encapsulate these frames in Ethernet, the interworking function shall add 8 bytes of PPPoE header and as such the frame does not longer fit in a standard Ethernet frame with a maximum payload of 1500 bytes. The normal procedure then requires the PPP Client and the PPP Server to negotiate about the MTU. To facilitate the convergence of this negotiation, the ISAM supports Ethernet frames that are 8 bytes longer then standard Ethernet. This facility is signaled in the PADI message to the PPPoE Server by adding the PPP-Maximum-Payload tag. This tag is defined in IETF RFC 4638.

Adding this tag can be enabled or disabled per PPP cross-connect Engine.

Also for the release phase the ISAM can not restrict to passively forwarding frames. When the PPP session is terminated, the ISAM also terminates the corresponding PPPoE session. The involved PAD-T message is sent with a VLAN tag with priority 7.

Normally, when a DSL line has gone out of service, the PPPoE session will only time-out in the BRAS after a certain time (typically 3 minutes). This delay is considered too long, for example, by service providers that offer a PPP-based HSI service with time-based billing.

Therefore, the ISAM removes an interworked PPPoE session and sends a PPPoE PAD-T message to the BRAS upon a loss-of-connectivity to the subscriber (this can be indicated by loss of DSL synchronization on the associated subscriber line).

PPPoE relay with MAC address concentrationIn theory, if the CPE terminates the PPPoE protocol, there should not be any issue to install an end-to-end connectivity between such a CPE and a BRAS located into the Ethernet network. PPPoE frames contain enough routing information (that is, MAC addresses) to reach the BRAS across the EMAN using standard bridging.

Note — PPPoA to PPPoE interworking is not supported on the GE Ethernet LT board.



However, many legacy Ethernet switches cannot cope with the large number of MAC addresses required to route PPPoE frames to the large number of DSL subscribers connected to the EMAN through the ISAMs (at least 1 MAC address per DSL subscriber).

This scalability issue is solved by the PPPoE relay with MAC address concentration feature: the ISAM replaces the large number of MAC addresses, issued by the subscribers, with the ISAM MAC address(es). The EMAN now only needs to cope with a few MAC addresses per connected ISAM instead of ten of thousands of MAC addresses for all connected subscribers.

Next to solving the scalability issue, the PPPoE relay with MAC address concentration also increases the security within the network. The MAC address of the subscriber does not enter the EMAN anymore. This address is replaced by the own MAC address(es) of the ISAM and, consequently, all issues related to duplicate subscriber MAC addresses are solved. The subscriber MAC address has only a local meaning (that is, local to the PVC) and, consequently, even if all the subscribers would present the same MAC address to the ISAM, they could still be connected to the BRAS without any problem.

Spoofing the MAC address of another subscriber will not allow to grab its traffic because the subscriber MAC address is not used by the EMAN nor by the ISAM to route the traffic.

MAC address concentration can be enabled or disabled per PPP cross-connect Engine.

If enabled the ISAM behaves very much like in the PPPoA to PPPoE interworking scenario with the difference that the interworking applies to multiple PPPoE sessions coming from users instead of to PPPoA sessions.

Note — PPPoE relay with MAC address concentration is not supported on the GE Ethernet LT board NNI port type.



10.11 DHCPv6

Lightweight DHCPv6 Relay AgentThe ISAM can be configured to act as a Lightweight DHCPv6 Relay Agent (LDRA). In this configuration, the Edge Router deeper in the network will act as a DHCPv6 Relay Agent.

The DHCPv6 packet headers will be created in accordance with draft-ietf-dhc-dhcpv6-ldra. The DHCPv6 packet received from the user is copied in the Relay-Message option of the relayed DHCPv6 packet.

The Access Node is able to encode the access loop identification in the Interface-ID Option (option 18, defined in RFC 3315) to the DHCPv6 Relay-forward messages sent to the BNG.

The encoding must uniquely identify the Access Node and the access loop logical port on the Access Node on which the DHCPv6 message was received. The Interface-ID contains a locally administered ASCII string generated by the Access Node, representing the corresponding access loop logical port.

The actual syntax of the access loop identification in the Interface-ID can take the same values as the ones supported for the DHCP option 82 sub-option 1:

• No Circuit ID (empty)• Syntax defined in TR-101 section 3.9.3, i.e. physical line ID using a default or a

configured syntax at system level• Customer-ID• Physical line ID in CCSA format

This allows the operator to migrate to IPv6 in a VLAN cross-connect model, without losing access line information.

The Access Node is also able to add the Relay Agent Remote-ID Option (option 37, defined in RFC 4649) to the DHCPv6 Relay-forward messages sent to the BNG. This is used in order to further refine the access loop logical port identification.

The Relay Agent Remote-ID contains an operator-configured string of 63 characters maximum that (at least) uniquely identifies the user on the associated access loop on the Access Node on which the DHCPv6 Solicit message was received.

The actual syntax of the user identification in the Relay Agent Remote-ID can take the same values as the ones supported for the DHCP option 82 sub-option 2:

• No Remote ID (empty)• Customer-ID• Physical line ID (using a default or a configured syntax at system level)

In the ISAM implementation the LDRA is enabled when either option 18 insertion or option 37 insertion is enabled, and LDRA is disabled when both option 18 insertion and option 37 insertion are disabled. The operator can enable/disable the insertion of option 37 into upstream DHCPv6 messages for each lightweight DHCPv6 Relay Agent instance.



DHCPv6 trusted/untrusted port configurationThe interface (VLAN) where the LDRA is enabled, can be configured as trusted or untrusted interface.

When the interface is configured as trusted, then the LDRA accepts DHCPv6 Relay-Forward messages from user side with options 18 and/or 37 already inserted. The ISAM will relay these Relay-Forward messages in accordance with draft-ietf-dhc-dhcpv6-ldra. In that case hop count is incremented in the upstream and is decremented in the downstream.

When the interface is configured as untrusted, then Relay-Forward messages from user side with options 18 and/or 37 already inserted will be discarded and not relayed.

DHCPv6 Relay AgentSee chapter “Protocol handling in a Layer 3 forwarding model”, section “DHCPv6 Relay Agent”.

DHCPv6 snoopingSee chapter “Protocol handling in a Layer 3 forwarding model”.


11 — IP routing


11.2 IP routing features 11-2

11.3 IP routing model 11-5

11.4 Routing in case of subtended ISAMs 11-7

11 — IP routing


11.1 Introduction

The IP routing model of the ISAM is a typical router implementation with increased security and scalability, allowing to use cheaper devices (that is, simple Ethernet switches) in the aggregation network. It can be characterized as follows:

• Packets are forwarded based on the IP Destination Address (DA) with the ISAM acting as a next hop.

• IP connectivity towards the end user can be established statically by the operator or learned dynamically by inspecting the DHCP messages exchanged between the subscriber and the DHCP server during the IP session establishment.

• IP connectivity towards the network and the subtending nodes can be established statically by the operator or dynamically by routing protocols.

• Service Level Agreement (SLA) enforcement can be achieved by means of policing and ACL, and this at various granularity levels.

• Improved security:• Subscriber MAC addresses are never propagated to the network• User-to-user communication can optionally be blocked• ARP messages do not cross the ISAM leading to not broadcasting ARP messages to

all subscribers• IP address anti-spoofing and ACL

• Improved scalability• The ISAM presents a single MAC address towards the network• The broadcast message load generated by the subscribers towards the network is

reduced by either handling them locally (for example, ARP) or by converting them into unicast messages (for example, L3 DHCP relay).

11.2 IP routing features

Packet forwarding based on the IP addressesImplementing a forwarding based on IP addresses allows to:

• terminate the Ethernet segment at the subscriber side and consequently, avoid the need to propagate the MAC address of the subscriber to the network solving at the same time many security and scalability issues.

• forward packets based on addresses assigned by the operator, enforcing a high security level.

• introduce IP awareness in the DSLAM, which facilitates support of enhanced features such as IP address anti-spoofing, ACLs and so on.

11 — IP routing


Next hop behaviorThe ISAM is seen as a next hop by the network and the subscribers, which allows increased scalability. Indeed, the IP edge router does not have to know each subscriber individually (which results in a reduced ARP table size) and ARP messages issued by the subscribers are terminated by the ISAM, reducing the control plane load at the IP edge.

Subscriber interface - Encapsulation types

• The IP routing model supports all types of subscriber interface IPoX encapsulations, which can be connected to an iBridge on the LT:

• ATM subscriber interface (IPoE over ATM and IP over ATM)• EFM/Ethernet subscriber interface (IPoE)

• IPoE subscriber interface:• User interface can be authenticated through 802.1/RADIUS protocols before

connecting to a router in ISAM.• vMAC can be enabled when subscribers do not have unique MAC address

• PPPoE and PPPoA subscriber interface encapsulations are not supported by IP routing.

802.1x/RADIUS authenticationSubscriber interfaces (IPoE over ATM or EFM/Ethernet) can be authenticated through 802.1/RADIUS protocols before connecting to a router in ISAM.

Subscriber interface - UnnumberedIn order to make the subscriber addressing scalable, subscriber interfaces (on the DSL lines) are considered as unnumbered IP interfaces attached to the IP router i.e. there is no need to allocate an IP address (note that this is only from the logical point of view and no need to explicitly configure unnumbered IP interface on the subscriber lines). This allows to share a subnet across many subscribers and, consequently, to increase the scalability and ease of operations.

DHCPv4 relay agentDHCP messages from the subscribers are forwarded through a layer 3 DHCP relay instance. This allows to:

• Convert broadcast messages into unicast messages towards a set of predefined DHCP servers to reduce the broadcast traffic load in the network.

• Add option 82 to uniquely identify the requesting subscriber by inserting the identification of his DSL line into the DHCP messages.

11 — IP routing


Subscriber routes - Dynamically learned through DHCP snoopingFor a router in general, interfaces are usually configured statically (by the operator), and the routes are learned dynamically via routing protocols. This is not typical for the subscriber side in ISAM because the devices of the subscriber do not typically support routing protocols and secondly the amount of subscribers to be configured in a DSLAM is high. The better method for ISAM is to learn the IP addresses by snooping DHCP messages.

The ISAM can automatically manage the forwarding parameters associated with the subscriber's interfaces by snooping the DHCP messages exchanged with these subscribers (populate the snooped subscriber's IP address, remove that IP address once the snooped IP address lease time is elapsed). This basically reduces the operator's cost of operation since the connectivity establishment is performed dynamically at IP session set-up time without any involvement of the operator.

Note however that an operator may still configure subscribers statically if desired (for example, business users). Static configuration is required whenever a subnet needs to be assigned to a subscriber, while ISAM only supports dynamic subscriber's IP address allocation for an individual IP address.

Network routes - Dynamically learned through routing protocolNetwork routes can be learned dynamically through routing protocols, hence reducing the cost of operation: connectivity to the network is automatically established by means of routing protocols, i.e. OSPF, IS-IS, RIP or BGP. Additionally, routing protocols can also be used to increase the network reliability by advertising alternative routes whenever a failure occurs in the network (for example, dual homing from the ISAM to two different routers).

The operator can also configure static routes to the network if desired.

Routes advertised to network and subscribersIPv4 network routes can be advertised to the subscribers using RIP.

IPv4 subscriber routes (individual or aggregated routes) can be advertised to the network using RIP or other routing protocols. This reduces the provisioning workload at the network side, at the CPE side, or both.

User-to-user communicationUser-to-user communication can be enabled or disabled at the VRF level. When disabled, user-to-user traffic will be discarded. When enabled, local ARP proxy also needs to be enabled on the user gateway IP interface.

IPv4 option processingISAM supports the processing of following IP options:

• Router alert• Time stamp• Record route

11 — IP routing


ISAM does not process source route option, that is, IP packets including source route options are forwarded transparently.

TTL=0 forwardingStandard IP routers are expected to discard packets received with TTL=0 and not intended for one of the router interface IP address. However, some specific network configurations require the ISAM to forward such packets.

TTL=0 forwarding is disabled by default. This option is configurable.

MTUThe L2 MTU size is fixed to 2048 and not configurable.

Implementation notes:

• The ISAM does not perform IP packet fragmentation for forwarded packets (packets generated by the ISAM itself are subject to fragmentation)

• Packets received with a length larger than the MTU are discarded.

ECMPUp to 4 Equal Cost Multi Path (ECMP) next-hops are supported per route.

Directed broadcastISAM does not support forwarding of the broadcast IP packets directed to the directly connected subscriber subnets (where subnet is all zeros or all ones). Directed broadcast IP packets are discarded by ISAM.

ICMP redirectISAM does not support ICMP redirect.

11.3 IP routing model

The IP routing model of the ISAM consists of iBridge forwarders (with secure forwarding enabled) on the LT boards connected to a standard IP forwarder on the NT board.

Figure 11-1 shows the IP routing model based on iBridge.

11 — IP routing


Figure 11-1 IP routing model based on iBridge

iBridge forwarders on the LT boards offer the following security features:

• IP address anti-spoofing (data-plane)• ARP relay: ARP messages from the NT board are forwarded to the targeted

subscribers, not broadcasted to everyone• layer 2 DHCP relay (adding option-82)• DHCP snooping: the subscriber IP address is learned through DHCP, which

allows to configure the ARP relay and IP address anti-spoofing• 802.1x/RADIUS authentication

IP router on the NT board offers the following functions:

• IP forwarding (data-plane), only one Virtual Forwarding and Routing (VRF) instance is supported

• ARP to network and to subscribers on the LT boards• User-to-user communication at layer 3 (including local ARP proxy)• IP option processing• Programmable TTL=0 forwarding• Layer 3 DHCP relay• Routing protocols (OSPF, RIP)

An internal VLAN is established between the LT boards and the NT board acting as an IP router. There is typically one v-VLAN per VRF instance. Multiple v-VLANs for a single VRF can be considered whenever a given VRF is forwarding multiple services and the services are associated with either a different PVC or a different VLAN at the subscriber interface.

Note — The ISAM supports only one VRF (IP routing) instance.

ISAM

V-VLAN per VRF

C

C

C

UserUser

UserUser

UserUser

C

C

C

UserUser

UserUser

UserUser

C

C

C

UserUser

UserUser

UserUser

Routingprotocols

NTARP

E

E

E

E

E

E

E

E

E

LT

DHCP snooping/Sta tic config.

ARPrelay

LT

LT

I-bridge

I-bridge

I-bridge

VRF IP Ed g eIP Ed g e

EMAN IP Ne twork

User ga teway IP interface on the V-VLAN

DHCP RelayAgent

Users can belong to adifferent public subnet.



ARPrelay

ARPrelay

11 — IP routing


The user gateway interface is the IP interface, which is facing the subscribers, and which is created on top of the V-VLAN. The subnet of the subscriber gateway interface is shared among the subscribers connected to the iBridge instance identified by the V-VLAN on the LT boards. The IP address of the subscriber gateway interface is used as the gateway IP address for the subscribers directly attached to the subnet of the subscriber gateway interface.

Multi-netting is also supported for the subscriber gateway interface to allow multiple subscriber subnets.

It is also possible to implement IP routing based on the IP- aware bridge forwarding model on LT boards; see chapter “Layer 2 forwarding”, section “IP-aware bridge mode”.

Figure 11-2 shows the IP routing model based on IP-aware bridge.

Figure 11-2 IP routing model based on IP-aware bridge

11.4 Routing in case of subtended ISAMs

When grooming traffic from multiple subtended ISAMs into a Hub ISAM, the ISAM supports two approaches:

• Subtended nodes operating as Layer 2 devices (Preferred)• Subtended nodes operating as L3 devices

Subtended nodes operating as Layer 2 devices (Preferred)In this node, IP routing and L3 DHCP relay are kept centralized on the Hub ISAM (H-ISAM) so that remote nodes - subtended ISAM or S-ISAM - can be kept as simple as possible (both from an hardware implementation and from a provisioning points of view). This allows centralizing routing protocols and subnet management at the H-ISAM while keeping the S-ISAMs untouched, that is, any addition of a new pool of IP addresses will only impact the H-ISAM.

The potential drawbacks of this configuration are related to H-ISAM scalability:

• larger Forwarding Database and ARP tables• higher processing load.

ISAM

V-VLAN per VRF

C

C

C

CP

CP

CP

UserSubscriber

C

C

C

Routingprotocols

SHubARP

E

E

E

E

E

E

E

E

E

LT

DHCP snooping/static config.

ARPrelay

LT

LT

IP-aware bridge

IP-aware bridge

IP-aware bridge

VRF IP EdgeIP edge

EMAN IPnetwork

IP interfaceon the V-VLAN

DHCP relayagent



ARPrelay

ARPrelay

UserSubscriber

UserSubscriber

UserSubscriber

UserSubscriber

UserSubscriber

UserSubscriber

UserSubscriber

UserSubscriber

11 — IP routing


This configuration is shown in Figure 11-3. In the hub ISAM, the router function is configured while in the subtended ISAMs layer 2 forwarding is in place.

Figure 11-3 ISAM sub-network configuration for video traffic (e.g VDSL)

EiB: Enhanced -Bridge

Subtended nodes operating as L3 devicesAll nodes operate as IP routers, allowing the operator to define a similar configuration for all nodes. The approach leads to inefficient IP subnet usage.

The subtending ISAM forwards upstream traffic to the hub ISAM via the default route announced from the hub ISAM.

NTLT

Aggregation Network

L2

RR

DHCP RelayDHCP Relay

Seen by the operator as one big virtual router

REiB

BEiB

Hub ISAM

Sub ISAM

NTLT

One single IP subnet over all Hub + Sub ISAMs

Identical LT configuration in Hub and Sub ISAMs

RGONT

EiB: Enhanced iBridge

11 — IP routing


Figure 11-4 Subtended ISAM operating as a L3 device

Aggregation Network

L3

L3

L3

IGP

IGP

IGP

11 — IP routing





12.2 IPv4 Routing Protocols 12-2

12.3 ARP 12-3

12.4 DHCP relay agent 12-4

12.5 DHCP snooping 12-7



12.1 Introduction

This section addresses layer 3 protocols in the scope of a layer 3 forwarded model as described in chapter “IP routing”.

Layer 3 protocols can be divided into two parts:

• routing protocols: see section “IPv4 Routing Protocols”• user access protocols:

• ARP: see section “ARP”• DHCP Relay: see section “DHCP relay agent”• DHCP: see section “DHCP snooping”

12.2 IPv4 Routing Protocols

IntroductionThe supported routing protocols are:

• RIP• OSPF-v2

These routing protocols are supported on network interfaces and interfaces towards a subtended ISAM. In addition, the RIP protocol can be supported on subscriber interfaces to advertise the routes towards the routers at the network side of the ISAM. The ISAM does not accept any route advertisement from the subscribers for security reasons.

The ISAM will report alarms to inform the Manager about lack of resources, major issues and state transitions in the Protocol.

RIPThe 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 ISAM 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 ISAM 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 the ISAM.

OSPF-v2Open Shortest Path First (OSPF) is a dynamic routing protocol used to learn and populate the forwarding database in the DSLAMs and the edge devices at the network side.

The ISAM 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 Not-So-Stubby Area (NSSA) option.

The NSSA option is used by deployments to reduce the size of the LSA database. There is no external route imported into an NSSA area from other OSPF areas. In an NSSA, external routes learned by OSPF routers in the NSSA area are advertised within the NSSA area and are translated by ABRs into external route advertisements for distribution into other areas of the OSPF domain.

• 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 ISAM supports areas, as defined in RFC 2328, for OSPF-2 protocol. The OSPF router on the ISAM can associate interfaces with the backbone area, a normal area, a stub area, or an NSSA area.

12.3 ARP

The IETF RFC 826 defined Address Resolution Protocol (ARP) is a protocol defined within the context of using IP over Ethernet. An IP node uses the ARP protocol to obtain the Ethernet MAC address of another IP node identified by a known IP address and connected to the same Layer 2 network.

This section describes ARP handling in ISAM in case of an IP routing model.

Note — For more information on ARP relay; see section “ARP relay”.



ARP handling on the subscriber side

• ARP request from users, for another user in the same subnet:The ISAM acts as an ARP proxy for local user subnet IP addresses.When the ISAM receives an ARP request for another user in the same subnet, the ISAM sends an ARP response. However the request will be discarded for these exception cases:

• IP address anti-spoofing verification reveals that the user is not known: the source IP address is not known to belong to the incoming interface

• both users are connected to the same user interface: subscribers should communicate by way of the internal interface at the subscriber side.

• ARP request from users, for user gateway IP address;When the ISAM receives an ARP request for the user gateway IP address, the ISAM will send an ARP response when the IP anti-spoofing verification is successful.

• ARP initiated by the ISAM to resolve a user MAC:An ARP request for a user IP address is not broadcast to all users attached to the same gateway IP interface. It is relayed to the user interface where the target user is learned.ARP responses from the user are validated with respect to IP address anti-spoofing.

ARP protocol tracing can be enabled on a few subscriber interfaces. The system can provide the list of messages exchanged with the subscriber to the ISAM syslog utility that will determine the destination of the traces (i.e. CLI screen, remote server, local file)

ARP handling on the network sideStandard ARP Handling applies at the network side:

• for ARP requests received from the network. • for ARP requests ISAM sends to the network.

12.4 DHCP relay agent

DHCP is a subscriber access protocol that enables DHCP servers to configure internet hosts. The ISAM provides DHCP relay agent functionality for IPoE/IPoA subscriber access interfaces in the IP routing mode.

The DHCP relay agent functionality is composed of two main components:

• layer 2 DHCP relay agent• layer 3 DHCP relay agent

Layer 2 DHCP relay agentThe functionality is equal to the functionality of the DHCP Relay Agent as described in chapter “Protocol handling in a Layer 2 forwarding model”.



DHCP protocol tracing can be enabled on a few subscriber interfaces. The system can provide the following to the ISAM syslog utility that will determine the destination of the traces (i.e. CLI screen, remote server, local file):

• the stable states and/or exceptional events related with DHCP handling• the list of messages exchanged with the subscriber

Layer 3 DHCP relay agent

Basic functionality

The ISAM can act as layer 3 DHCP relay agent for the subscribers in the following forwarding modes:

• IP routing• IP-aware bridge• iBridge

The layer 3 DHCP relay agent is responsible to relay DHCP messages between the subscribers and DHCP servers as follows:

• Upstream:Broadcast DHCP messages received from the subscribers are unicasted to the configured DHCP servers of the VR (of an IP router or an IP-aware bridge) associated with the subscribers interface.

• Downstream:Unicast DHCP messages received from the DHCP servers are either unicasted or broadcasted (based on the broadcast flag) to the correct subscriber interfaces.

Subscribers connected to the same interface may get IP addresses in the same subnet or from different subnets. User-to-user communication between those subscribers would be via the ISAM (in the IP routing mode) and via the IP edge router (in the IP-aware bridge and iBridge mode), even though there is a direct connectivity between them.

Note — The functionality is also provided in case of iBridge and IP-aware bridge forwarding mode, though such configuration is not recommended and is planned to be phased out.

Note — The L3 DHCP relay agent only relays broadcast packets to the configured servers. The L3 DHCP Relay agent never forwards or relays unicast DHCP packets from subscribers to servers.

Note 1 — The layer 2 DHCP relay agent is located at the LT board and the layer 3 DHCP relay agent is located at the SHub.

Note 2 — When the chaddr concentration is enabled, Option 82 should be configured. This feature is only available for IP-aware bridge.



Multiple DHCP relay instances per VRF

Multiple instances of a layer 3 DHCP relay per VRF are supported in case of the IP routing model. The DHCP Relay Agents are located on the NT.

When multiple services are offered via the same VRF while each service uses a dedicated IP address range managed by different set of DHCP servers, the operator can enable multiple layer 3 DHCP relay instance per router, and dedicate the usage of each instance to one service. This approach avoids overloading DHCP servers (with a given service) with DHCP messages that are not relevant for that service.

A layer 3 DHCP relay instance is characterized by:

• VRF ID• Relay agent IP address• List of DHCP servers to be addressed

When receiving a DHCP message from a user and which must be handled by a layer 3 DHCP relay agent, the incoming IP interface (VLAN where the DHCP message came in) is used to select one of the relay agent instances configured within the VRF of the incoming IP interface.

Thus, the ISAM will only relay the DHCP message to those DHCP servers which are associated with the selected DHCP relay instance.

This is shown in Figure 12-1.

Figure 12-1 Multiple DHCP relay instances per VRF

LT

NT

LT

v-VL

AN B

IP a,b

User

User

ISP DHCPserver

User

User

User

User

IP c,d

User

giaddr=any VRF IP address

v-VLAN A

: is an IP interface

Notation:

IP y

User

User

IP x

User

User

User

User

User

IPa1

IPb1

IPc1

IPa2

IPb2

IPc2

IPd1

L2 DHCPRelay A

L2-enhancedforwarder A

L2 DHCPRelay B

L2-enhancedforwarder B

L2 DHCPRelay A

L2-enhancedforwarder A

L2 DHCPRelay B

L2-enhancedforwarder B

Subs 3Subs 3

Subs 4Subs 4

Subs 1Subs 1

Subs 2Subs 2

Option 82 insertion,session snooping

DHCPserver

L3 DHCPRelay Agent A

L3 DHCPRelay Agent B



12.5 DHCP snooping

In the IP routing, IP-aware bridging and iBridge model, the ISAM maintains the relation between the subscriber IP addresses and the corresponding subscriber interfaces by snooping the DHCP messages. The DHCP snooping is distributed and performed by every LT board. There is no NT board involvement.

The LT board snoops the following information:

• the subscriber IP address:required for IP anti-spoofing in the upstream direction (that is, an IP packet received with a source IP address which is not learned from the incoming subscriber interface is discarded).

• IP address lease:The ISAM also monitors the IP address lease. The relation between the subscriber IP address and the subscriber interface is removed when the lease time is expired. In case the lease is infinite, the subscriber IP address can only be removed by a manual operator action (by locking the subscriber interface or powering-off the corresponding LT board).

As the NT board is not using data retrieved from the DHCP snooping (that is, no dataplane configuration), DHCP sessions are by definition preserved against:

• an NT board reset or switchover due to a software or a hardware failure• an NT board reset due to software upgrade

The DHCP sessions are stored in the reset-safe memory of the LT and NT boards and are preserved against:

• an LT board reset due to recoverable or unrecoverable software failure leading or not to the power-on reset

• an LT board reset due to software upgrade• an LT board reset due to hardware failure• an LT board replacement

In cases where the DHCP sessions could not be preserved (exceptional case of combined NT and LT failures, for example, during complete ISAM power down), the subscribers will have to re-establish DHCP sessions in order to recover the IP connectivity.


13 — Multicast and IGMP

13.1 Overview 13-2

13.2 Advanced capabilities 13-5

13.3 System decomposition 13-13

13.4 Multicast and forwarding models 13-13



13.1 Overview

Multicast is the simultaneous transmission from a single device (such as a video head end) to a group of recipients (such as video Set Top Boxes) using the most efficient strategy to deliver the data over each link of the network only once.

The ISAM supports IP Multicast based on VLAN bridging (layer 2) technology.

Internet Group Management Protocol (IGMP) is the control protocol for multicast in a layer 2 network. It is used between the recipients (hosts) and multicast routers to join and leave a group.

By default, bridges flood multicast frames as well as IGMP packets between the multicast router and the hosts. The resulting bandwidth waste is unacceptable on relatively low bandwidth interfaces like xDSL. Bridges can optimize the bandwidth usage by snooping the IGMP control packets exchanged between hosts and multicast router. Efficient multicast trees are constructed from the learned information. The ISAM supports IGMP proxy, which serves as an alternative variant for IGMP snooping.

Figure 13-1 IGMP enabled bridges

Note — IGMP is specified in IETF RFC 2236 (IGMPv2) and RFC 3376 (IGMPv3).

Note — IGMP snooping is specified in IETF RFC 4541.

IP network

EdgeRouter

Bridge

BridgedVLAN

Host

Member group A

Member group A

Member group B

IGMP

data

LAN

VideoHeadend

Member group A

Member group B



Data planeIP Multicasting uses IP datagrams with a multicast destination IP address, which is a class D address in the range “224.0.0.0” through “239.255.255.255”.

In the layer 2 network between the hosts and the edge router, the IP datagrams are encapsulated in Ethernet frames with a multicast destination MAC address that is derived from the multicast destination IP address. Hosts should not only accept frames with a destination MAC address matching their own MAC address, but also frames with a multicast destination MAC address of the groups of which they are a member.

Bridges maintain multicast forwarding tables, also known as multicast Forwarding Data Base (FDB), representing the replication trees.

The ISAM maintains a multicast forwarding table per VLAN. The entries are known as multicast trees in the management plane. Multicast trees are indexed with the multicast IP address, rather than with the multicast MAC address. This makes it easy to correlate the data plane with the control plane (IGMP) which is based on IP addresses.

In Figure 13-2, the multicast forwarder is shown as segregated from the unicast forwarder for the same VLAN. Multicasting is only supported in VLANs that have IGMP enabled, so-called multicast VLANs.

Figure 13-2 Multicast data plane

IGMP can only be enabled on network VLANs whose unicast forwarder is an iBridge, but not a cross-connect VLAN.

If IGMP is not enabled, then the forwarder is either transparent for or discards IGMP packets and multicast frames. Refer to Table 13-1.

Note — Remark that multiple (32) IP addresses map to the same multicast IEEE 802 MAC address.

Note — The use of IP addresses does not eliminate the issue of many-to-1 mapping from IP addresses to MAC addresses, since there are still components in ISAM that forward based on the MAC address.

240.0.10.1

Port P2DSL interfaceGE interface

224.0.10.2

VLAN PortUnicast forwardingiBridge

Port P1

Multicast Fwd Table

VLAN Multicast IP address Egress ports

15

15

240.010.1

240.010.2

{ P1 }

{ P1, P2 }

Multicast forwarding



Control planeThe ISAM supports an IGMP Proxy. Compared to an IGMP Snooper, an IGMP Proxy maintains independent “Router” state machines towards the hosts and “Host” state machines towards the routers. this offers some advantages, such as spreading the load of queries towards subscribers.

The IGMP Proxy updates the mFIB tables dynamically, based on the control plane events (join requests, leave requests).

Figure 13-3 IGMP control plane

IGMP version 2 as well as IGMP version 3 are supported.

Multicast services are configured on subscriber ports by creating an IGMP channel on top of the subscriber port. This enables IGMP proxy on the subscriber port.

By enabling IGMP on a network VLAN, that is, making it a multicast VLAN, IGMP snooping is enabled on all network ports and subtending ports that are in that VLAN.

When IGMP is encapsulated over PPP, it is handled transparently

Note — IGMP Proxy is defined in IETF RFC 4605.

VLAN port

Multicast Fwd

R HIGMPProxy

upda te

join 240.0.10.1

join 240.0.10.2

join 240.0.10.1



13.2 Advanced capabilities

The regular multicast mechanisms are suited to provide a very basic video service. More advanced capabilities are available. Most of these capabilities require the configuration of the list of IP addresses of the multicast channels that can be joined by the ISAM subscribers. This is known as the list of preconfigured multicast channels, or “premium” video channels.

Join requests received from the subscribers are identified as targeting a preconfigured multicast channel by comparing the join (multicast IP address, source IP address) against the list of preconfigured multicast channels identified as follows:

• Cross-VLAN multicast (see subsection “Cross-VLAN multicasting”): (multicast IP address, source IP address)

Some of the advanced capabilities also apply to non-configured “best-effort” video channels, that is, to IP addresses that are not configured in the ISAM.

Static infeedThe availability and join latency of popular multicast channels can be improved by feeding them statically up to the ISAM. The channel is semi-permanently streamed in the aggregation network up to the ISAM uplink, whether hosts joined the channel or not. There is no need for the edge router to react on IGMP requests to join this channel.

Statically fed channels towards subtending nodes are configured in the ISAM by configuring static multicast branches, as opposed to the dynamic multicast branches created through IGMP signaling. By doing so, the root of the replication tree becomes static. It is also possible to configure a list of static egress ports (branches) on subtending ports or on network ports, so the channel is also statically fed up to the next node.

Figure 13-4 Static infeed

Note — Statically fed channels still support dynamic branches, controlled through IGMP signaling.

EdgeRouter

Aggregation networkISAMSubtending ISAM

Branch Rootstatic

dynamicIGMP

No IGMPnecessary

No IGMPnecessary



Cross-VLAN multicastingMulticasting in an iBridge is normally contained within the same VLAN. As a consequence multicast-enabled subscriber ports would need to be VLAN ports within the multicast VLAN.

With cross-VLAN multicasting ALL the subscriber ports that are multicast-enabled can receive multicast traffic from ALL the multicast VLANs. This makes it possible to:

• mix multicast and other services at the subscriber ports, yet segregate these services in the aggregation network in different VLANs.

• offer multicast services on subscriber ports of different iBridges, yet share the multicast channels in a common VLAN. Cross-VLAN thus reduces the number of copies of the same multicast channel.

• offer multicast services on subscriber ports that employ other forwarding modes, such as VLAN cross-connects or IP-aware bridges. Without cross-VLAN, multicast traffic would be discarded or would be transparent, implying no efficient replication.

• organize multicast channels in multiple multicast VLANs, without limiting the access possibilities of the subscriber.

Figure 13-5 Cross-VLAN multicast - forwarding view

In cross-VLAN multicasting, when the subscriber joins a channel, the ISAM finds the multicast VLAN from the preconfigured multicast channel. If the requested multicast IP address, possibly extended with source IP address - see “Source Specific Multicasting”, is not in the list of multicast channels, then the join is handled in the scope of the subscriber VLAN. In case the subscriber VLAN forwarder is an iBridge (that is, multicasting is supported), the join is proxied as a “best-effort” video service. Else, the join is transparently forwarded or is discarded, see Table 13-1.

240.0.10.2

(network-side)SAP

VLAN

VLAN

VLAN

VLAN port

VLAN port

Multicastforwarding

Unicast forwarding(iBridge)

Unicast forwarding(VLAN-CC)

(network-side)SAP

(network-side)SAP



Figure 13-6 Cross-VLAN multicast - network view

Source Specific MulticastingThe multicast IP address range is unique. In a wholesale environment, different multicast service operators would need to make agreements to use non-overlapping subranges.

Source Specific Multicasting (SSM) makes it possible for multicast service operators to use overlapping multicast IP address ranges because SSM-mode multicast channels are identified by the combination of the multicast IP address and a source IP address, which refers to the multicast service provider. When configured in IGMPv3, subscribers can join to SSM-mode channels and the ISAM can distinguish the requests by means of the source IP address, even if the multicast IP address is the same.

Even though subscribers can join based on the combination of multicast IP address and source IP address, the multicast forwarding table of the ISAM (and possibly also in the aggregation network) does not support the source IP address. That is, the data plane is SSM-unaware. For this reason, the same multicast IP address can only be reused in combination with a different VLAN. When receiving a join for an SSM-mode channel, the ISAM finds that VLAN in the list of preconfigured multicast channels.

SSM channels must therefore be preconfigured as multicast channels.

ISAM Aggregation network

STB

BTV + VOD

Fwd

Fwd

BTV VLAN 15

VOD VLAN 16

Edgerouter

Multicastchannel list

MulticastIP address

VLAN

1515

240.0.10.1240.0.10.2

Note — The method to use SSM in the control plane but not in the data plane of L2 networks is specified in DSLF TR-101.



Figure 13-7 Source Specific Multicasting

Fast leaveIn the normal leave procedure of IGMP, when a host leaves a multicast channel, the router queries the port for any other hosts that must still receive the multicast channel. It typically takes more than 1 second before the router can decide there is no more interest in the multicast channel and that the Multicast Fwd table is updated to stop replication on that port.

Zapping behavior is such that the host which left the multicast channel does not wait until the multicast channel is stopped and immediately joins another multicast channel. During a short time, both the old and the new multicast channel are therefore present on the subscriber port. For xDSL lines, which bandwidth is often tailored to accommodate a limited number of multicast channels, the extra bandwidth from the old channel may lead to frame loss.

With fast leave, the ISAM keeps track of all the hosts that joined a certain multicast channel and immediately knows when the last host on the subscriber port has left the multicast channel. If that is the case, then the ISAM immediately updates the Multicast Fwd table to stop replication on that port.

Fast leave can be enabled per multicast channel.

ISAMAggregation network

STB

Fwd

Fwd

BTV VLAN 15

VOD VLAN 36

Edgerouter

MulticastFws table

MulticastIP address

VLAN

1536

240.0.10.1240.0.10.1

Multicastchannel list

MulticastIP address

VLAN

1536

240.0.10.1240.0.10.1

SourceIP address140.20.20.1144.30.30.1

VideoHead End

140.20.20.1

144.30.30.1

(240.0.10.1,144.30.30.1)

(240.0.10.1,140.20.20.1)

Note — The situation of multiple hosts on a user port can occur in case of a bridged CPE and multiple STBs.



Figure 13-8 Fast leave on subscriber ports

Resource admission control on the subscriber portVideo services can tolerate only very minimal frame loss, therefore an oversubscription of video bandwidth should be avoided. Also, it may not be acceptable that lower-priority services, such as HSI, are completely blocked by video traffic. In this respect, the ISAM supports 2 mechanisms to control the resources on the subscriber ports. If any of the checks fail, then join messages are rejected.

• Control the number of multicast channels per subscriber port:This mechanism, which is primarily intended for access control, can be used as a simple multicast-only RAC assuming that all multicast channels have more or less the same bandwidth.The maximum number of multicast channels is configured per IGMP channel.

• Control the downstream bandwidth per physical (xDSL) lineThis mechanism takes into account the actual bandwidth of each multicast channel, as configured per multicast channel. It is integrated in a multi-service RAC.A maximum video bandwidth can be configured in the CAC profile, refer to chapter “Quality of Service”, section “CAC profile”.

Resource admission control on the uplinkVideo services can tolerate only very minimal frame loss, therefore an oversubscription of video bandwidth should be avoided. Also, it may not be acceptable that lower priority services, such as HSI, are completely blocked by video traffic. In case traffic engineering techniques are insufficient, ISAM supports 2 mechanisms to control the resources on the network ports. If any of the checks fail, then join messages are rejected.

240.0.0.1

Leave 240.0.0.1

Query 240.0.0.1

Join 240.0.0.2240.0.0.2

Query 240.0.0.1

240.0.0.1

240.0.0.1

Leave 240.0.0.1

Join 240.0.0.2240.0.0.2

240.0.0.1

STB

CPE

ISAMSTB

CPE

ISAM

Bandwidth Bandwidth

Time Time>

1 s

Normal leave Fast leave



Both mechanisms apply to the aggregation of network ports.

• Control the number of multicast channels on the ISAMThis mechanism can be used as a simple multicast-only RAC assuming that all multicast channels have more or less the same bandwidth.The maximum number of multicast channels is configured per system.

• Control the downstream multicast bandwidth on the ISAMThis mechanism takes into account the actual bandwidth of each multicast channel, as configured per multicast channel. It is still a multicast-only RAC.The maximum video bandwidth is configured per system.

Both mechanisms can also apply per bundle. A bundle is a set of multicast channels. In a wholesale environment, each multicast service provider can hold its own bundle. Assigning resources per bundle is a way to achieve fairness between the different multicast service providers. The bundle is configured indirectly by configuring per multicast channel whether the multicast channel belongs to a bundle, and if so, configure the bundle name.

• Control the number of multicast channels per multicast bundleThis mechanism can be used as a simple multicast-only RAC assuming that all multicast channels have more or less the same bandwidth.The maximum number of multicast channels is configured per multicast bundle.

• Control the downstream multicast bandwidth per multicast bundleThis mechanism takes into account the actual bandwidth of each multicast channel, as configured per multicast channel. It is still a multicast-only RAC.The maximum video bandwidth is configured per multicast bundle.

Access controlAccess control limits subscribers access to multicast services.

The ISAM can restrict the access to a predefined set of multicast channels and disallow joining any other multicast channels, like some kind of ACL. For this purpose multicast packages are configured, containing a set of preconfigured multicast channels. The set of multicast packages that are allowed to be viewed is then configured per IGMP channel.

Packages can also be used to give limited preview access to multicast channels. The set of multicast packages that are allowed to be previewed is then configured per IGMP channel. With preview access, subscribers can view the multicast channel during a short time period.

Call Detailed RecordsThe ISAM can generate Call Detailed Records (CDRs). The CDRs log the actual viewing behavior of the individual subscribers. CDRs for example report the identity of the subscriber port, the multicast channel joined, the start time and view duration. They are sent in real time to a server using TFTP or syslog protocol. The server can use the information to bill the subscribers on a Pay-Per-View basis.

CDR generation can be enabled and configured in the IGMP system.



Static router portsThe IGMP Proxy dynamically learns the router port as the network port from which it received the queries, that is, behind which the multicast router resides. Join messages and leave messages are sent on that learned router port. There can be only one dynamic router port.

In some network topologies there is a need for multiple router ports. Configuring network-side Service Access Points (SAP) as multicast router (MR) offers this capability.

For example, a network topology may have two multicast routers directly attached to the ISAM. In that case, only one multicast router will assume the role of the querier, the other multicast router serves as backup. To be fully prepared to take over in the event of a failure of the querier router, the non-querier router must also be aware of the multicast channels that need to be injected in the aggregation network. By configuring both network ports as (multicast) router port, all the join messages and the leave messages are sent to both routers.

Figure 13-9 Example of static router port

IGMP forkingAn Edge Router implementing hierarchical scheduling, shapes downstream traffic according to the actual user line rate, minus the bandwidth taken by multicast channels streamed on this user line. Such Edge Router needs to be aware of that bandwidth.

An IGMP Proxy enhanced with IGMP forking copies every upstream IGMP packet towards the Edge Router into the same vlan on which it has been received. The forked packets contain the original source MAC and IP address from the STB. By monitoring all the IGMP traffic on the user line, the Edge Router can thus calculate the bandwidth taken by multicast channels on this user line.

IGMP Forking can be enabled in the IGMP system or on the IGMP channel.

ISAM

STB

non-Querier

Querier

MR SAP

Join 240.0.0.1Join 240.0.0.1

Join 240.0.0.1

Query



Figure 13-10 Example of IGMP forking

To be effective in avoiding overload issues, the operator should make sure that these forked IGMP packets are not snooped/proxied in the ISAM or elsewhere in the aggregation network. In particular, the operator should:

• choose a BTV VLAN different from any unicast forwarding VLAN in which forked packets are inserted

• not deploy non-configured (best effort) multicast service in any unicast vlan in which forked packets are inserted

• not deploy L2 LT boards in the ISAM (because such cards apply IGMP proxy on ALL the network VLANs, even on unicast VLANs that may carry forked IGMP traffic)

• enable IGMP snooping on maximum 5 VLANs in the SHub (if more, then the SHub will snoop ALL the VLANs). Remark that, by default, VLANs in the SHub are created with IGMP snooping enabled.

Warning — IGMP forking generates many IGMP packets.

EdgeRouter

Aggregation networkISAM

STB

BTV+HSI+Voice

Fwd

Proxy

Join( Proxied Join )

Forked Join

BTV VLAN 15

HSI+Voice VLAN 16Fwd



13.3 System decomposition

Multicast services impact both the LT boards and the SHub.

The LT board implements a multicast forwarder and IGMP proxy. Advanced features like cross-VLAN multicasting, fast leave, most of SSM, RAC on the user line, access control and CDRs are implemented in the LT board.

The SHub implements a multicast forwarder and IGMP snooper. The snooper operates completely in the scope of a VLAN, that is, there is no cross-VLAN support in the SHub. Advanced features like static infeed, RAC on the uplink and static router ports are implemented in the SHub.

Figure 13-11 shows the system decomposition for multicast and how the management concepts map on the system components. Although some concepts can be configured both on the LT boards and on the SHub, this is not always necessary. Refer to the 7302 ISAM | 7330 ISAM FTTN Operations and Maintenance using CLI for FD 24Gbps NT.

Figure 13-11 System decomposition for multicast

13.4 Multicast and forwarding models

This section focuses on the case where the ISAM participates in the multicast data and control plane. Depending on the forwarding model and on the configuration (multicast enabled or not, joined channel in the list of multicast channels or not), the ISAM does or does not participate. If the ISAM does not participate, the ISAM may discard or transparently pass the multicast data and control frames. Table 13-1 provides a summary of the handling of IGMP packets and multicast frames in forwarders.

STB

Multicast VLANsMulticast channels

IGMP channelsMulticast packages

Multicast VLANsMulticast channelsMulticast bundles

Router portsMulticast trees

IGMP Proxy

mcast fwd

IGMP SnooperSHub

Aggregationnetwork

LIM

LIM

mcast fwd

mcast fwd

MulticastVLAN

Unicast VLAN

IGMP Proxy



Table 13-1 Handling of IGMP packets and multicast frames in forwarders

Forwarder to which the user is linked for unicast traffic

IGMP channel not created

IGMP channel created, requested multicast channel not in list

IGMP channel created, requested multicast channel in list

VLAN Cross-Connect IGMP and mcast transparent

IGMP and mcast transparent

IGMP proxy and mcast replication

iBridge (IPoE) IGMP and mcast discarded



iBridge (PPPoE) IGMP and mcast transparent

Not supported Not supported

IP aware bridge IGMP and mcast discarded

IGMP and mcast discarded


PPP cross-connect IGMP and mcast transparent

Not supported Not supported

IP router IGMP and mcast discarded

IGMP and mcast discarded



14 — Quality of Service


14.2 Upstream QoS handling 14-2

14.3 Downstream QoS 14-8

14.4 Hardware mapping of QoS functions 14-10

14.5 Configuration of QoS 14-15



14.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, 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 ISAM in end-to-end QoS.

14.2 Upstream QoS handling

This section deals with subscriber- or ISAM-originated traffic that is transmitted on the network link.

OverviewFigure 14-1 shows the standard QoS model which includes a configurable system-wide p-bit-to-traffic-class mapping, four queues and a fixed scheduling scheme.

A GE Ethernet LT board allows a flexible number of queues (either four or eight) and uses either the system-wide p-bit-to-traffic-class mapping or a mapping that is configurable per forwarder.



Figure 14-1 Qos Overview - Standard model

ClassificationThe purpose of classification is to identify flows or streams of traffic which need a different treatment, that is, which require a different quality of service.

Figure 14-2 QoS: classification for Standard model

For the standard model, four main traffic classes have been identified: Voice, Video, Controlled Load (CL) and Best Effort (BE). These traffic classes are listed in Table 14-1, together with their application and recommended 802.1p value.

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 14-1 Classes, application, and recommended 802.1p value

SP

WRRWFQ

GE/FE Voice

Video

CL

BE

classification

111110

101100

011010

001

000

.1p

p-bit marking

ISAM queues

mapping to queuespriority scheduling

mapping ofDSCP

to P-bits

TC3

TC2

TC1

TC0

Traffic classes

mapping to traffic classes

Traffic class Application Recommended 802.1p value

Voice • Voice• Video telephony• + network control)

110

(111)

Video • Broadcast video• Video-on-demand

100

(1 of 2)

classification

1. Voice

2. Video (VoD, BTV)

3. Controlled load (home working)

4. Best effort (HSI)



It is also possible to use an eight traffic class model.

• For LT boards that support only four queues, the eight traffic classes are mapped to four queues, according to a fixed scheme. See “Mapping and queueing” for details.

• For LT boards that support eight queues, each traffic class is mapped to its own queue.

Classification is based on layer 2/layer 3/layer 4 parameters

When the outcome of classification is “discard”, we're dealing with Traffic filtering by means of Access Control Lists (ACLs). In this way, it is possible to filter out certain packet flows based on multi-field classification at layer 3/4 or layer 2.

Control plane and management plane traffic is separately classified based on protocol type.

MarkingMarking is defining the value of:

• layer 2: p-bits - part of the VLAN-tag• layer 3: DSCP - part of the IP packet header

Figure 14-3 QoS: marking

Controlled load HSI for business access 011

Best effort HSI for residential access 000

Note — The classification can already be done by the CPE (priority tagged frames or tagged frames), but the ISAM can be configured to overrule the marking done by the CPE.

Traffic class Application Recommended 802.1p value

(2 of 2)

classification

111110

101100

011010

001

000

.1p

p-bit marking



In upstream direction, there are four possibilities:

• Trusted Subscriber Interface:• No remarking of DSCP or p-bit; QoS markings received by the user are accepted as

they are. This possibility is useful in case of trusted subscribers (for example, in a business context).

• DSCP or p-bit contract enforcement/remarking. In this case, QoS markings received from the subscriber 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).

• Non-trusted Subscriber Interface:• Default DSCP or p-bit marking per subscriber interface. In this case, all the packets

on the interface will be re-marked to the configured value.• DSCP or p-bit marking per QoS subflow using layer 2/layer 3/layer 4 filters (based

on multi-field classification into QoS subflows).

In addition to above policies it is also possible to align the p-bits, that is, p-bits are derived from the DSCP codepoint. There is a single system-wide p-bit alignment table for upstream.

The p-bit marking of protocol frames is left untouched. If the frame was received untagged (or is originated by the ISAM) a fixed p-bit (7) marking is applied.

PolicingSubscribers are subject to certain traffic contracts that specify how much traffic they can send towards the network. Policers are installed to enforce these contracts.

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 the aggregate of packets flowing through the interface that are bound by a subcontract and require a specific common treatment.

Two types of policer are supported:

• single token bucket policer• two-rate three-color policer (supported only on GE Ethernet LT board)

The characteristics of these two types are explained in “Policer profile”.

Figure 14-4 QoS: policing

classification

111110

101100

011010

001

000

.1p

p-bit marking

P

P

P

P



Figure 14-5 illustrates the policing feature implementation for a single token bucket policer.

Figure 14-5 Policing implementation framework

Mapping and queueingMapping to queues is the action of assigning a frame to the appropriate queue based on the p-bit determined during classification (see above). Queue sizes and scheduling mechanisms can then be tuned to fit optimally to the traffic class at hand.

Traffic is classified into either four or eight traffic classes. At any congestion point in the system, ISAM supports either four or eight queues to distinguish four or eight different traffic classes.

Figure 14-6 shows the different QoS queues the different QoS queues for the standard QoS model, employing 4 traffic classes and 4 queues. The configurable mapping of p-bits to traffic class is system-wide. The mapping of traffic class to queue is a non-configurable one-to-one mapping.

Figure 14-6 QoS queues for standard model

Per-SAP policingSubflow policing

QoS Session Profile

QoS PolicerProfile UP

QoS PolicerProfile DOWN

QoS PolicerProfile DOWN

QoS PolicyList DOWN

L2 filterL3 filter

Policy-action=Policer-Profile

CIRCBS

L2 filtersDST MAC address + prefix lengthSRC MAC address + prefix length

EthertypeP-Bit

User-side VLAN IDCFI

L3+ filtersDST IP address + prefix lengthSRC IP address + prefix length

Min/max DST port IDMin/max SRC port ID

ProtocolDSCP value

Voice

Video

CL

BE

classification

111110

101100

011010

001

000

.1p

p-bit marking

ISAM queues

mapping toqueues

mapping ofDSCP

to P-bits

TC3

TC2

TC1

TC0

Traffic classes




When eight traffic classes are used, the traffic classes are mapped either to four queues or to eight queues. Again this mapping is non-configurable. The mapping of eight traffic classes to eight queues is a one-to-one mapping. The mapping of eight traffic classes to four queues is as shown in Table 14-2.

Table 14-2 Mapping of eight traffic classes to four queues

For UNI ports on a GE Ethernet LT board, it is allowed to configure the p-bit to traffic class mapping per forwarder. If configured, this mapping takes precedence over the system-wide mapping.

It is also optionally possible to define a mapping of p-bits to color marking. There are two types of color marking available:

• Drop Precedence (DP) color marking (either green or yellow) • Policer color marking (green, yellow, or red)

The DP color marking is used as input to color-aware BAC. See “Queue configuration and queue profile” for description of color-aware BAC. The policer color marking is used as input to color-aware policing. (Note that the output of the policing will also be used as input to color-aware BAC.)

In the upstream direction, only a GE Ethernet LT board supports color-aware BAC and color-aware policing. Note that the color-aware BAC is a fixed configuration.

Scheduling and shaping

Standard scheduling model

Traffic Class Queue

7 3

6 3

5 2

4 2

3 1

2 1

1 0

0 0



Figure 14-7 QoS: scheduling

The standard scheduling model is presented in Figure 14-8.

Figure 14-8 Reference scheduling hierarchy

The priority scheduling is as follows:

1 Voice traffic is scheduled first (strict priority)

2 Video traffic is scheduled next (strict priority)

3 CL and BE packets compete for bandwidth in a fair manner (Weighted Fair Queuing or Deficit Round Robin). The bandwidth ratio is determined by the weight of CL respectively BE.

Scheduling is work-conserving, that is, lower QoS classes can occupy bandwidth that is not actually consumed by higher QoS classes.

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.

Shaping on network ports

ISAM supports port-level shaping of traffic on the network ports.

14.3 Downstream QoS

This section deals with traffic received from the network link and transmitted on the subscriber link or locally terminated on the ISAM.

mapping to queues classificationp-bit markingpriority scheduling

SP

WRRWFQ

GE/FE Voice

Video

CL

BE

111110

101100

011010

001

000

.1pISAM queues

mapping ofDSCP

to P-bits

TC3

TC2

TC1

TC0

Traffic classes


Voice

Video

CL

BE

SP

WFQ



Downstream traffic is subject to similar QoS actions as upstream traffic. This section will focus on the differences between downstream and upstream QoS handling.

ClassificationSame capabilities as for upstream QoS handling (see “Classification”).

MarkingIn the downstream direction, frames usually arrive in the ISAM with DSCP or p-bits properly marked by service-aware edge devices (such as BRAS, edge router, application gateway, and so on). If this is not practical for some reason, the p-bits can be aligned to the DSCP found in the packet IP header.

Further, multi-field based marking is supported in downstream; SAP-based marking is only supported in upstream.

Same capabilities for marking of protocol frames as for upstream QoS handling (see “Marking”).

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

However, after the forwarding decision egress policing may apply. Subscribers are subject to certain traffic contracts that specify how much traffic they can receive on their DSL connection. Policers are installed to enforce these contracts. A policer may apply to an entire subscriber interface or to a QoS subflow within the subscriber interface.

As for upstream, it is possible to configure either single token bucket policers or two-rate three-color policers.

Mapping and queuingIn the downstream direction, separate QoS queues (one per traffic class) are provided per DSL line. Frames are mapped to the appropriate queue based on the p-bit determined during classification.

Optionally, it is possible (as for the upstream case) to define a mapping of p-bits to color marking. There are two types of color marking available:

• Drop Precedence (DP) color marking (either green or yellow) • Policer color marking (green, yellow, or red)

The use of the color marking is similar to the upstream case.

Buffer Acceptance Control (BAC) can be done by means of Tail Drop or Random Early Detect (RED). The Tail Drop or RED can optionally be color-aware.



Scheduling and ShapingIn the downstream direction, for the DSL lines, the same capabilities apply as for upstream scheduling (see “Scheduling and shaping”).

The scope of shaping is different though. In the downstream direction shaping applies to the per-subscriber queues.

A GE Ethernet LT board supports the following scheduling and shaping capabilities:

• Scheduling of queues at the port level. The scheduling can be strict priority or WFQ and is configurable per queue (applies to both UNI and NNI ports)

• Scheduling of ports at the board level with configurable port weights (applies to UNI ports only)

• Shaping at both the queue level and the port level (applies to both UNI and NNI ports)

Connection Admission ControlThe ISAM allows associating bandwidth parameters to known multicast video streams. Per subscriber line, a maximum bandwidth (in kb/s) can be configured for (downstream) multicast. In addition a portion of the link bandwidth can be reserved for voice and data. Based on the bandwidth available for multicast, the ISAM executes a CAC for known multicast sessions(*).

ISAM also supports CAC for multicast on the uplink.

14.4 Hardware mapping of QoS functions

QoS on the NT boardsThe QoS functions of the NT are fully implemented at the switch port/service level. In the ISAM, per-flow or per-session QoS is handled on the LT boards, for example, QoS at the DSL port bottleneck and rate limitation of user sessions.

The following QoS features are supported in the SHub switch hardware:

• Classifying packets• Metering packet flows• DSCP-to-p-bit alignment (IPv4 only)• Mapping packets to a queue• Buffer acceptance and scheduling at egress port side• Per port egress rate limitation• Uplink CAC

Note — (*) Video on Demand (VoD) traffic is not taken into account.



Downstream, frames are expected to arrive with correct priority markings. If the video feed interface is a dedicated Ethernet interface, a default p-bit value can be attached to video frames. If, for various reasons, it is impractical to set the p-bits in the upstream node, the SHub allows to align the p-bits to the DSCP for IP packets incoming on the external interfaces.

The NT supports Connection Admission Control on the uplink for multicast traffic; the bandwidth of known multicast streams is checked against net available bandwidth on the uplink. Consequently, a multicast join request for a multicast stream that was not yet present on the uplink will only be honored if the check is successful.

QoS on the LT boards

QoS on layer 3/layer2+ LT boards

Figure 14-9 shows the logical architecture for QoS on layer 3/layer 2+ LT boards. This includes all the ISAM LT boards except the layer 2 LT boards.

Figure 14-9 Logical architecture for QoS on layer 3 LT boards

The input-processing entity stands for all the 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 14-10.

Session rate limitation is achieved by way of policing. Policing can be done at different subscriber SAPs: bridge port, VLAN port, IP interface, or PPP CC client port.

Both upstream and downstream policing is possible with possibly asymmetrical values.

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

Inputprocessing

Per-DSL li DSL

upstream

GEaggregate

Inputprocessing

Segregation intooutput buffers

(802.1P aggregates)

Per-DSL linePolicing

ATM or EFMreassembly

Inputprocessing

Logicalsegregationper DSL line

Per-DSL linePolicing,

Classification,Queuing,

Scheduling

ATM or EFMsegmentation

PVCforwardingdecision

DSL

downstream

GEaggregate



Figure 14-10 Per DSL-port scheduler

Traffic class mapping on the LT boards is governed by a system wide p-bit-to-queue mapping table.

BAC is either Tail Drop or RED per downstream queue (optionally DP-aware).

A WFQ scheduler ensures fair redistribution of the remaining bandwidth between CL and BE traffic. Some boards also support shaping per downstream queue.

Figure 14-11 shows the Ethernet-to-ATM QoS transition.

Figure 14-11 Ethernet-to-ATM QoS transition

Scheduling is done solely on the Ethernet frame level, even for ATM-based DSL transmission types.

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 p-bit and DSCP values. Packets may arrive from user ports tagged, untagged, or priority-tagged. At the bridge port and VLAN port level, the ISAM supports a remarking table which maps all user-defined P-values to allowed values. Untagged frames can be marked based on subscriber SAP defaults (statically configured).

Note — The traffic class mapping on the NT boards is governed by another system wide table.

SP SP

WFQWFQ

Policingentity

DSL

Rule per SAP:

• PVC• PPP• VLAN ID• 802.1X• IP interface

Based on:• 802.1P

Modes:

• Taildrop• RED

Trafficclassswitch

voiceCBAC

videoBAC

CLBAC

BEBAC

SPSP

WFQWFQCL

BE

Frame Domain

VOICE

VIDEO

Ethernet (frame level)scheduler

Cell Domain

Segmentationbuffers

Rate limitation toDSL bandwidth

1 frameAdd correct

VPI/VCIfields

VC1

VC2

VC3

DSL



The ISAM allows also DSCP-marking for various subscriber SAPs. DSCP-to-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. Note that these marking capabilities related to DSCP are available only for IPv4 packets, not IPv6 packets.

PPP-session marking for p-bits is possible based on the QoS session profile attributes.

QoS on the layer2 LT boards

Layer 2 LT boards have a different QoS architecture. Queuing is per PVC, and all the 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.

Layer 2 LT boards support 4 priority levels downstream. Upstream there is no bottleneck, hence no queuing other than AAL5 reassembly is required.

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 means of the management interface.

The bit used for marking upstream frames is also used for downstream prioritization 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 802.1-bits.

Session rate limitation is achieved by way of policing. Policing can be done per PVC.

Note — Only fixed p-bit value marking is supported; no DSCP marking, nor dot1p-alignment.



QoS on a GE Ethernet LT board

A GE Ethernet LT board supports both UNI and NNI ports. The NNI port is typically employed to connect a subtending system (such as another ISAM) or a business customer. Therefore it is expected that NNI ports will have simplified upstream QoS requirements, since many QoS functions will have already been performed. In the case of a GE Ethernet LT board, the QoS capabilities of both UNI and NNI ports are summarized in Table 14-3.

Table 14-3 QoS capabilities of UNI ports and NNI ports

Link Aggregation on a GE Ethernet LT board

Feature UNI NNI

P-bit-based classification Y Y

Port default p-bit (untagged frames) Y Y

VLAN-based priority (untagged frames) Y Y

P-bit regeneration profile Y Y (on bridge port only)

DSCP-based classification Y (on bridge port only) N

DSCP-to-p-bit alignment Y (on bridge port only) N

L2/L3 filters Y (on bridge port only) N

Subflow policing and marking Y (on bridge port only) N

3-color marking Y Y (upstream only, on bridge port only)

P-bit to eight traffic class mapping Y (system wide or per forwarder)

Y (system wide)

3-color WRED Y Y

3-color tail drop Y Y

Eight queues per port Y Y

Downstream configurable SP/WRR scheduling of queues at port level

Y Y

Downstream configurable port weights for scheduling at port level

Y N

Port shaping Y Y

Queue shaping Y Y



The GE Ethernet LT board supports link aggregation of up to eight ports per link aggregation group (LAG). The ports may be either all UNI ports or all NNI pots, and all ports in the LAG must be on the same LT board and must be all operating at the same link speed. There are some special considerations related to the QoS for the LAG:

• Downstream queues, queue profiles and scheduler node profiles are all configured on the LAG port and the configuration is applied identically to each physical port in the LAG.

• A downstream queue shaper applies across all ports of the LAG, for the queues of a specific traffic class. In the case of a UNI LAG, the aggregate of the traffic across all queues is shaped. In the case of an NNI LAG, if the shaper rate is R and the number of links is N, then each queue is shaped to a rate of R/N.

• A downstream port shaper applies across all ports of the LAG. In the case of a UNI LAG, the aggregate of the traffic across all ports is shaped. In the case of an NNI LAG, if the shaper rate is R and the number of links is N, then each port is shaped to a rate of R/N.

• As usual, a session profile is attached to a bridge port or a VLAN port. Since the bridge port or VLAN port is associated with the entire LAG (not just one physical port) then the session profile applies to all physical ports in the LAG. This is also true for the marker profile, policers and filters that belong to the session profile.

• p-bit marking/remarking configured on the bridge port or a VLAN port of a LAG is applicable to all physical ports of the LAG.

• CAC checks are made using the aggregate bandwidth of the LAG, not the bandwidth of the individual physical ports.

• QoS counters apply to the LAG, not to the individual physical ports of the LAG.

14.5 Configuration of QoS

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

IACM partThe following QoS profiles are supported on the LTs (IACM part):

• CAC profile• Queue profile• Session profile• Marker profile• Policer profile• Policy profile• Layer 2 filter• Layer 3 filter• Policy action profile



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.

A CAC profile contains three configurable rate parameters:

• the minimum reserved bandwidth for voice• the maximum allowed bandwidth for multicast video• the minimum reserved bandwidth for data traffic

The ISAM derives the guaranteed line rate from the modem and calculates an estimate of the available Ethernet bandwidth. In the profile, a part of the available downstream bandwidth can be reserved 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 7302 ISAM | 7330 ISAM FTTN CLI Commands for FD 24Gbps NT and the 7302 ISAM | 7330 ISAM FTTN Operations and Maintenance Using CLI for FD 24Gbps NT documents for more information.

Queue configuration and queue profile

For the Layer 3 LT boards, in the downstream direction, the queue weight is configured for the Controlled Load (CL) queue and the Best Effort (BE) queue. The default weight of the CL queue is 66 and the default weight of the BE queue is 34.

A queue profile is associated with each queue. The 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 basic BAC types are supported in downstream: RED and tail drop. However, their color-aware variants are also available on some LT boards:

• Two color tail drop• Two color RED• Three color tail drop (GE Ethernet LT board only)• Three color RED (GE Ethernet LT board only)

A RED queue has three configurable parameters:

• MinThreshold: the average queue filling level for which frame discard will start to occur (threshold expressed in number of packets)

• MaxThreshold: the average queue filling level for which frame discard will start be 100% (threshold expressed in number of packets)

• DropProbability: the probability of frame discard for average queue filling levels just below the maximum threshold.



Figure 14-12 RED configuration parameters

Arriving frames are accepted as long as the average queue filling level remains below the minimum threshold. Frames received at the moment the minimum threshold is exceeded will be dropped with a probability as indicated by the RED curve.

For tail drop queues, only a max queue size has to be configured. 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.

In the case of color-aware BAC, a separate curve must be configured for each color. That means, in the case of color-aware RED, that MinThreshold, MaxThreshold and DropProbability are configured separately for each color. In the case of color-aware tail drop, only MaxThreshold needs to be configured for each color.

Shaper profile

ISAM uses shaper profiles to capture shaper configuration parameters. For a DSL line, a shaper profile contains the following configuration parameters:

• Type: only single-token bucket shapers are currently supported.• Committed Information Rate (CIR): in 16 kb/s increments up to a maximum of

128 Mb/s (up to a maximum of 1Gb/s on a GE Ethernet LT board). • Committed Burst Size (CBS): in byte increments up to a maximum of 256Kbyte.

A DSL shaper profile may be associated with a downstream queue. For a GE Ethernet LT board, a shaper may also be associated with a port (either UNI or NNI).

Note — The weight, used for calculating average buffer sizes in RED, is not configurable.

Note 1 — BAC configuration for upstream queues on LT is fixed.

Note 2 — L3 LTs support buffer oversubscription.

Weighted averageFilling level

Minimumthreshold

Maximumthreshold

Drop probability

Discardprobability



Scheduler node profile

The GE Ethernet board uses the scheduler node profile. It provides the flexibility needed for flexible, hierarchical scheduling and shaping. The scheduler node profile does not specify weight or priority for its associated queues. Instead, the queues themselves have weight and priority parameters. Also the scheduler node profile can have a variable number of associated queues (either four or eight). The scheduler node profile includes the following parameters.

• Weight and priority:used to schedule at the next level scheduler. For example, if the scheduler node is at the UNI level, its output will be next scheduled at the board level (GE Ethernet LT).

• Shaper profile:used when the output of the scheduler node requires shaping.

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 SAP. Please consult the 7302 ISAM | 7330 ISAM FTTN CLI Commands for FD 24Gbps NT document 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 14-13 Composition of QoS session profile

The logical flow type is a mandatory parameter but is ignored from R4.0 onwards, that is, the logical flow type is always considered null (generic). Hence, the QoS Session profile can be attached to any interface, provided that the settings inside the profile can be configured on the target hardware. Unsupported fields/actions are silently ignored at run-time.

QoS Session profiles are assigned statically, as specified by the operator.

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 (SAP).

QoS Session Profile

QoS PolicerProfile Up

Logical FlowType

QoS PolicerProfile Down

QoS MarkerProfile Up

QoS PolicyList Up

QoS PolicyList Down



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 layer 3 boards. This further 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:

• d1p: fixed value imposed for p-bit• dscp-contract: DSCP code-point translated• d1p-dscp: fixed value imposed both for p-bit and DSCP code-point• dscp: fixed value imposed for DSCP code-point• d1p-dscp-contract: fixed value imposed for p-bit, while DSCP code-point

translated• d1p-alignment: p-bit value derived from DSCP code-point

See the 7302 ISAM | 7330 ISAM FTTN CLI Commands for FD 24Gbps NT and the 7302 ISAM | 7330 ISAM FTTN Operations and Maintenance Using CLI for FD 24Gbps NT documents for more information about marker profiles.

Policer profile

The ISAM uses policer profiles to enforce predetermined limits on upstream and downstream subscriber traffic. Single-token bucket policers are supported where the action upon the conformance result is either pass or discard. The layer 3 LT boards support policing, both upstream and downstream.

A single-token bucket policer profile contains following policer parameters can be set:

• Committed Information Rate (CIR) in 16 kb/s increments up to a maximum of 128 Mb/s for both upstream and downstream policing.

• Committed Burst Size (CBS) in byte increments up to a maximum of 256 Kbyte.

The GE Ethernet LT board also supports the two-rate Three Color Marker (trTCM). This is a type of policer that marks each packet with a color - green, yellow, or red. The trTCM contains some additional parameters:

• Excess information rate (EIR)• Excess Burst Size (EBS)• Color mode: either color-aware or color-blind• Yellow action: forward or discard the yellow packets• Red action: forward or discard the red packets• Coupling flag: enabled or disabled.

The trTCM is intended to be used in conjunction with the color-aware BAC types described in “Queue configuration and queue profile”. The color-aware mode makes use of the Drop Precedence marking described in “Mapping and queuing”. The Drop Precedence marking is either in-profile (green) or out-of-profile (yellow). The coupling flag is defined in the MEF 10.1 and only is applicable for color-aware mode.



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

In addition to this fast path policer, there is also a slow path policer that limits the number of (upstream) control frames that are excepted to the on-board processor for each subscriber line. This mechanism has been put in place to protect this shared resource against DoS attacks from malicious users.

The slow path policer is also a single token bucket policer with Committed Information Rate expressed in terms of packets per second and Committed Burst Size expressed in terms of number of packets. This policer type is not subject to profiling.

Policy framework

A generic policy framework provides finer-grained control over subscriber traffic. It provides for generic layer2 or 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 14-14 shows the policy building blocks.

Figure 14-14 Policy building blocks

L3 FilterIP Destination Address

IP DA Prefix

IP Source Address

IP SA Prefix

DSCP

Protocol Type

Destination Port Range

Source Port Range

L2 FilterMAC Destination Address

MAC Source Address

MAC SA Prefix

Ethertype

P-bits

CFI bit

VLAN ID

MAC DA Prefix

Default Disposition

Set DSCP

Set P-bits

Police

Sharing

Policy Action



A set of non-conflicting 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 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”.

The ISAM LT boards support more policies in the upstream direction than 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.

Counters and Threshold Crossing Alarms

QoS counters and related alarms serve the purpose of debugging the network for traffic problems. SLA-based accounting is served by SAP-counters and as such queue counters should only be enabled when debugging or testing the network. Enabling the queue counters may reduce the maximum throughput of the system.

QoS counters are designed to provide evidence of traffic issues in case there are problems. The queue counters are a basic building block which can be used by a network operator to learn whether queue overflows occur in a certain traffic class, and if so how often.

In a normal troubleshooting scenario the operator would enable or reset queue counters and start up the services to observe whether the queue drop and pass counters are incrementing. Queue drop counters provide evidence of buffer overflows, which needs to be avoided in high-priority traffic classes transporting non-responsive flows. Queue pass counters provide evidence of ongoing traffic, which is a basic feedback whether there is connectivity or not and if traffic falls into the right queues.

Alarms are useful to observe events that occur rarely. QoS alarms have been defined to detect in part traffic misbehaviors and in part system performance issues. While queue counters can be used for device-under-study testing, alarms are useful to detect conditions that occur rarely and would cost too much to be tracked by OAM engineers.

The counters and threshold crossing alarms (TCAs) can be divided in two categories: line/ queue based and line-card based.



Figure 14-15 QoS Counters and TCAs on layer 3 Boards

The following line/queue based counters and alarms are supported:

• number of packets passed (per queue/line)• number of packets dropped (per queue/line)• number of bytes passed (per queue/line)• number of bytes dropped (per queue/line)• threshold crossing alarm for dropped packets (per queue)• queue load meter per queue (sync rate vs. bytes passed in this queue)• total load meter per line (sync-rate vs. bytes passed per line)• threshold crossing alarm for the load inflicted by traffic in one queue on the parent

physical interface (taking into account sync rate and encapsulation format)

The queue/line loads and counters are calculated on a 15-minute basis. No long history is kept; only the current and previous 15-minute counters are retrievable.

The total buffer pool is divided in two regions: a common region and a region saved for high-priority traffic (that is, voice or video packets). The preliminary buffer pool threshold can be specified in terms of percentage of total buffer pool, above which only high-priority traffic is permitted into the buffer pool (both upstream and downstream).

MasterTx

Tx

OBC

Memory Pool

High priority

threshold

Downstream

OBC counters:Dropped OBC frames USDropped OBC frames DS

Aggregate buffer counters:Dropped frames USDropped frames DSDropped low prio frames

Line Counters:Passed Bytes/FramesDroppedd Bytes/FramesLoad

System Bus Counters(per Traffic Class):Passed Bytes/FramesLoad

Queue Counters:Passed Bytes/FramesDropped Bytes/FramesLoad

SP

WFQ

SP

WFQTx

OBC TCAs:Dropped OBC frames USDropped OBC frames DS

Aggregate buffer TCAs:Dropped frames USDropped frames DSDropped low prio frames

Queue TCAs:Dropped FramesLoad

System Bus TCA):Load



Figure 14-16 Buffer pool regions on IXP boards

For upstream and downstream (which share the same pool on L3 cards) there are dedicated threshold crossing alarms that can be triggered when more than a programmable number of OBC, resp. non-OBC packets are dropped. Packet loss in the total buffer pools may occur when:

• the egress queue sizes have been enlarged to a large extent, and many egress ports on multiple queues suffer large backlogs

• when exceptionally high loads with smallest packet sizes persist over a long duration (basically several hundreds of packets at gigabit speeds with less than 100 bytes each)

OBC-directed packets (that is, control packets) are also tracked for packet loss and associated threshold crossing alarms can be activated. The queues towards the OBC may overflow when:

• there are large bursts of control frames in the downstream direction• there are large and correlated bursts on many ingress lines in the upstream

direction

Due to the fact that each subscriber line has a programmable packet policer for control traffic it is inconceivable that the OBC-directed queues should overflow as a result of just one subscriber line.

The following line-card level counters and alarms are supported:

• number of packets passed (per Traffic Class)• number of bytes passed (per Traffic Class)• total system bus load meter (per Traffic Class)• threshold crossing alarm for system bus total load• aggregate buffer overflow events for upstream resp. downstream traffic• aggregate buffer overflow events for upstream resp. downstream OBC directed

traffic• partial buffer overflow events for low priority traffic (i.e. Controlled Load and

Best Effort)

Total Physical Packetmemory

Max usage of a queuefrom the total pool (noguaranteed minimum

on L3 boards)

Area that canbe saved forhigh priority

traffic viaconfiguring

partial bufferoverflowthreshold

(configurable in% of total pool)

Area for both low andhigh priority traffic



• threshold crossing alarm for dropped upstream resp. dropped downstream traffic due to aggregate buffer overflow

• threshold crossing alarm for dropped upstream resp. dropped downstream OBC directed traffic due to aggregate buffer overflow

• threshold crossing alarm for dropped low priority traffic due to partial buffer overflow

The system maintains 32 15-minute counter sets and one previous and current 1-day counter set related to aggregate buffer overflow (aggregate upstream, aggregate downstream, aggregate upstream OBC, aggregate downstream OBC and partial buffer pool overflow).

Fan-out load per traffic class is useful to trigger operator attention to unusually high load conditions per LT board. In case the system bus gets overloaded (via normal but rare or abnormal load conditions) this information can be used to take action in terms of limiting the number of subscribers provisioned per LT board or finding problems with multicast sources. The system automatically calculates fan-out loads (i.e. the load that goes down the system bus after multicast replication has occurred) vs. the actual system bus bandwidth (as this varies with hardware versions).

For fan-out load the system keeps 96 15-minute counters sets (load, pass bytes/frames per Traffic Class) and one previous and current 1-day counter set (pass bytes/frames) in addition to rolling counters. The 15-minute history counters are useful for tracking system load evolutions over the day. Since the load is calculated per traffic class, not only per LT board, this information can be used to track the system load and bandwidth usage for the multicast video service (as this could not possibly be tracked deeper in the network).

SHub part

P-bit-to-queue mapping

The SHub has its own dedicated p-bit-to-queue mapping.

DSCP-to-P-bit alignment

On the SHub there is a single DSCP-to-p-bits alignment table that can be enabled per SHub external interface for incoming traffic. It applies to all incoming (IPv4 only) traffic for all VLANs.

CAC profile

A Resource Admission Control mechanism is supported on the uplink as well. See chapter “Multicast and IGMP” for more detailed information.

Queue profile

Queue settings are hard-coded (that is, not operator configurable).



Scheduler profile

The following scheduling parameters can be configured on external interfaces:

• port level rate shaping• relative weight of Controlled Load, respectively Best Effort traffic

Scheduling parameters can be configured per member of a Link Aggregation Group and is replicated to other members.

Supported range of shaping rates is [64Kbps - 10Gbps] in steps of 64 Kbps. Supported range of WRR weights is [1-15].

Scheduling on internal interfaces is not configurable at all.

Flow profile

A flow definition is used to describe the scope of a policer instance. A flow definition can be instantiated on multiple ports, but only once per port. On different ports it can be paired with different policers.

Following flow types are supported:

• Port• VLAN • VLAN.P• VLAN.DSCP (for IPv4 only)

Meter profile

The operator can create (62) policer prototypes. A policer prototype contains rate and burst tolerance information, and can be used on multiple ingress ports and on multiple flows. Following ranges are supported for the respective policer parameters:

• information rate: [1Kbps - 10Gbps] units of 64Kbps• burst tolerance: [3Kbytes - 512Kbytes] 8 discrete values


15 — Resource Management and Authentication


15.2 RADIUS features 15-2

15.3 802.1x authentication via RADIUS 15-2

15.4 Operator authentication via RADIUS 15-2

15.5 Encryption of authentication data 15-3

15.6 Lawful interception 15-3



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

• support of strong authentication in a cost-effective way. The same RADIUS server or a back-end authentication server supports strong authentication. In the case of local authentication, strong authentication may not be feasible.

15.2 RADIUS features

The following features are supported:

• User authentication via an external RADIUS authentication server.• A 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)

• Fallback to a configurable default operator profile when the RADIUS server does not support vendor specific attribute.

15.3 802.1x authentication via RADIUS

RADIUS support provides the ability to authenticate 802.1x sessions at an external database (residing at the RADIUS server). Apart from authentication, RADIUS can also be used to provide accounting for 802.1x sessions. In addition, when authenticating the subscriber, RADIUS can return configuration parameters to the ISAM, which enables the dynamic provisioning of certain subscriber aspects. These aspects include dynamic mapping to a service provider (service selection), QoS, and ACL. RADIUS not only provides secure authentication and accounting, but also facilitates subscriber provisioning.

15.4 Operator authentication via RADIUS

CLI and TL1 operators can be authenticated either locally on each DSLAM or remotely via a central RADIUS server.

There is one restriction: if CLI or TL1 over SSH with key authentication is used, then the authentication has to be done locally. RADIUS does not support keys.



This functionality is only supported for CLI and TL1. The authentication occurs once for a complete session. Operator authentication is not supported for SNMP operators as SNMP does not work with the concept of session. Communication with a RADIUS server would have to be set up for each SNMP request, in order to authenticate the originator.

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.

Typically, the local database only contains the administrator account in case RADIUS is used. To prevent isolation, one default local operator profile can be configured, which applies when RADIUS is not reachable and when the operator is not configured in the local database.

15.5 Encryption of authentication data

Passwords, RADIUS secrets, and other authentication data are encrypted in such a way in the system database that the plain form cannot be derived from the system database when 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 (MD5) is used to avoid unauthorized retrieval. This applies for authentication on all the management interfaces and on all the user interfaces.

15.6 Lawful interception

Lawful Interception (LI) is done by Law Enforcement Agencies (LEA) of governments in order to combat crime and other anti-constitutional activities.

The ISAM family performs the role of Content of Communication Interception Function (CCIF) by mirroring the data to be intercepted. The target to be intercepted is identified by an external Lawful Intercept Administration Function (LIAF) by means of interfacing with the RADIUS and/or the DHCP servers.

The LIAF then triggers the ISAM to intercept the associated target based on identifiers received from RADIUS and/or DHCP servers.

Once the data is mirrored (duplicated) in the ISAM, the same data is forwarded to an external Lawful Interception Mediation Function (LIMF), which in turn securely transmits the data towards the LEA.

Due to the sensitive nature of Lawful Interception, the administration of Lawful Interception is restricted to authenticated operators only. Non-authenticated operators are not able to administer the Lawful Interception function in the ISAM. Lawful Interception administration on the ISAM can be done either via CLI or by SNMPv3 by exclusively authenticated operators.

Note — No accounting is performed for authenticated CLI/TL1 operator sessions.



In order to securely transmit the content of communication data, all intercepted (mirrored) packets are encapsulated before forwarding to the LIMF.

The upstream / downstream traffic to the user is not impacted by enabling lawful interception on the user. The intercepted traffic is forwarded to the LIMF by means of tunneling techniques. It is possible to set the priority of the intercepted packets.

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 A-13HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

A. Cross-domain solutions

A.1 Overview A-2

A.2 Mobile backhaul A-3

A.3 E1/T1 Leased Line Replacement A-10

A.4 ISAM Backhaul (Rural DSL, Ultra-high Broadband) A-14

A.5 Hospitality solution A-20

A.6 Open Community Broadband for Smart Communities A-26


A-2 November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

A.1 Overview

This section describes a description of various applications for which the ISAM provides an effective solution.

Mobile BackhaulFixed operators and converged fixed/mobile operators can benefit from leveraging cost-optimized residential broadband access infrastructure for backhauling traffic from mobile base stations. The ISAM access node, in cooperation with dedicated cell site devices is fulfills the requirements for backhaul of 2G/3G and LTE base stations in terms of bandwidth, TDM/ATM/ETH service delivery, high availability, QoS and base station synchronization; for data as well as for mission critical voice services, and this for the range of DSL, GPON and point-to-point fibre access technologies.

E1/T1 Leased Line ReplacementLegacy E1/T1 leased line services can be converged over the modern IP DSLAM. This allows to decommission legacy line systems or ATM DSLAMs. The ISAM access node, in combination with a pseudowire capable device at the business premises fulfills the requirements for leased line replacement in terms of bit error rate, delay, availability and synchronization.

ISAM Backhaul (Rural DSL, Ultra-high Broadband)The ISAM (remote or CO) relies on the availability of Gigabit Ethernet fiber to provide uplink network connectivity. In some cases this fiber is not available. This is typically the case in rural areas or emerging and developing countries. But this also true for industrialized countries having fiber-dark-spots. For both cases a solution can be proposed allowing broadband deployment with ISAM in all areas. For rural areas and industrialized areas different bandwidth requirements apply and hence different architectural solution can be proposed.

Hospitality solutionTo remain competitive in their market segment many hoteliers are looking to increase the overall guest experience in their hotel. The ISAM can provide triple-play and enhanced media applications in the hotel guest room, conference rooms, lobby, and so on, by leveraging on the existing copper wiring (Cat3). The existing Cat3 wiring, currently used for Voice (PABX), can be enabled with xDSL without rewiring or other labor cost.

Open Community Broadband for Smart CommunitiesThe aim of the Open Community Broadband solution is to offer a very flexible wholesaling framework allowing sharing of access and aggregation infrastructure by multiple service providers allowing end-users to pick-and-play in flexible and on-demand way.



A.2 Mobile backhaul

1.2.1 ScopeThis section describes solutions for backhaul of 2G/3G and LTE mobile base stations over ISAM 7302/7330/7356.

Mobile backhaul over (bonded) ADSL2+, over (bonded) SHDSL, over (bonded) VDSL2, over point-to-point Ethernet (FE/GE) is included, covering solutions for data off-load as well as full backhaul of voice and data.

Apart from the ISAM 7302/7330/7356 node, the solution also proposes the cell site devices (residential DSL CPE, dedicated DSL CPE for business/mobile backhaul, 7705 SAR-F/7705 SAR-M) for which the solution is validated.

Apart from this, an end-to-end mobile backhaul solution also requires an aggregation network and a gateway device that interfaces to the mobile gateways. These are not specified here. Please refer to the ALU Mobile Backhaul Blueprint Solutions for a description of ALU end-to-end mobile backhaul solutions.

IntroductionMobile backhaul (mobile backhaul) is about transporting traffic between mobile base stations (2G BTS, 3G NodeB, LTE eNodeB) and a centralized mobile gateway (2G BSC, 3G RNC, LTE S-GW).

Mobile backhaul comes from a legacy of 2G base stations, carrying low volumes of traffic (voice and low BW data) and backhauled over a TDM (PDH/SDH) network, with first mile access to the TDM network typically over 1 or 2 copper (or microwave) E1/T1. The TDM network inherently provided synchronization as well as resilience and QoS for mission critical services.

With the growth of data services in 3G and LTE, traffic volumes are increasing rapidly and exponentially and mobile operators need more bandwidth fast. On the other hand, mobile ARPU is more or less flat and consequently there is pressure on the cost per bit, also for backhaul. The legacy TDM backhaul infrastructure cannot scale in a cost effective way.

The following evolutions are happening:

• transition from copper (and TDM microwave) to fibre (and packet microwave) in mobile backhaul access, at a pace allowed by investment levels

• transition from TDM transport to packet transport (carrier Ethernet, IP/MPLS)• convergence of residential/business/mobile backhaul over a common transport

infrastructure (the High Leverage Network)

In this context there is a clear incentive for fixed access operators to leverage residential broadband assets (existing or new rollouts) for mobile backhaul.



Using broadband access technologies for mobile backhaul allows to reuse existing outside plant (copper, GPON feeder fibre). Moreover, broadband access technologies (DSL, GPON, point-to-point Ethernet) are existing, cost optimized platforms and will enable significantly reduced port cost per mobile base station/mobile site.

Technical challengesThe following technical challenges arise when leveraging broadband access infrastructure for mobile backhaul:

Bandwidth

Mobile backhaul bandwidth requirements have evolved from 1-2 E1/T1 (2-4Mbps) for a 2G site to more than 250Mbps for a full blown multi-provider, multi-generation 2G/3G/LTE site.

With respect to this bandwidth evolution, the different broadband access technologies can be positioned as follows:

• (bonded) ADSL2+ and (bonded) SHDSL can be positioned as short-to-mid term tactical solutions for 3G bandwidth relief. E.g. 4 pair bonded g.SHDSL.bis can support symmetrical bandwidth up to 22.8 Mbps. ADSL2+ deployment will in practise be limited to data off-load, while SHDSL can and will typically be used in full off-load scenarios (*). For SHDSL, ATM IMA and EFM bonding are preferred for reasons of resiliency (if one pair goes down, the group will not be impacted). Of the two, EFM bonding is superior with respect to bandwidth efficiency, provisioning and flexibility in data rates for the different pairs.

• With bandwidths of e.g. ~ 400/100 Mbps downstream/upstream at 500m, 250/50 Mbps downstream/upstream at 1000m for 8-pair bonded VDSL2, bonded VDSL2 is a strategic, rather than a tactical solution for evolution to and including LTE. VDSL2 could be deployed in off-load scenarios but definitely have full backhaul as the final goal (*).

• GPON and point-to-point fibre are full-blown solutions capable of supporting all scenarios to LTE. Again, GPON and point-to-point fibre could be deployed in off-load scenarios but definitely have full backhaul as the final goal (*).

Access node features: Physical layer interfaces, DSL bonding.

TDM/ATM/Ethernet service delivery

2G base stations have TDMoE1 interfaces. 3G base stations can come in any of 3 flavors: all ATM IMAoE1, hybrid ATM IMAoE1 (for voice) and Ethernet (for data), all Ethernet. LTE base stations have all Ethernet interfaces. Typically, 2G/3G/LTE base stations will be collocated on a single site and will be backhauled over a common access link.

Note — (*): See the section on QoS and High availability for distinction between data off-load and full backhaul.



Transport of TDM and ATM services over a packet network (potentially along with Ethernet service) requires the use of pseudo wires (PWE3 TDM/ATM/Ethernet pseudo wires for IP/MPLS, MEF-8 TDM pseudowire for Carrier Ethernet). Pseudo wires are typically set up between by a dedicated cell site gateway (CSG) device at the cell site and a peer device at the mobile controller site.

Access node features: Transparent for the access node.

Synchronization

Base stations with legacy E1 interfaces need frequency synchronization for the purpose of TDM transport (i.e. to avoid frame slips).

All base stations also need frequency synchronization for the purpose of providing an accurate wireless carrier frequency.

In addition, TDD (time division duplex) base stations need phase synchronization for the TDD mechanism to operate. FDD (frequency division duplex) systems may also need phase synchronization for specific advanced wireless features like MBMS and network MIMO, but deployment of these must be considered longer term and is of no immediate concern.

Base stations can be synchronized in multiple ways:

• using a synchronized E1/T1 from a TDM network (frequency synchronization only)This is the synchronization method in the legacy TDM network. It is also the synchronization method in a data off-load approach, where synchronization (and voice) remain to be transported by the TDM network, but data is off-loaded to the packet network.

• using an on-site GPS (frequency and phase synchronization)This is the synchronization mechanism in CDMA and will most likely be the first synchronization mechanism in TDD and FDD deployments requiring phase sync.

• using synchronization from the packet networkThese synchronization methods classify in 2 flavours:

• Physical layer mechanismsThese provide end-to-end synchronization on the physical layer. Several physical layer synchronization mechanisms are standardized: NTR for DSL, GPON PHY for GPON, SyncE for Ethernet.

• Packet layer mechanismsThese include NTP, 1588v2 point-to-point, ACR, DCR. Of these, 1588v2 is the more forward looking with evolution to provide phase synchronization as well as frequency sync.

In contrast to packet layer mechanisms, physical layer mechanisms are inherently deterministic and insensitive to network traffic load conditions and QoS design.

It is recommended to use physical layer synchronization mechanisms whenever available. I.e. BITS or SyncE into the ISAM in CO and physical layer synchronization (NTR, GPON PHY, SyncE) from there to the business site. If no BITS or SyncE is available in CO, we recommend 1588v2 termination in a client in the CO and to go with physical layer synchronization from there. This can be by means of an external client that feeds into the BITS of ISAM.



Access node features: NT with BITS/SyncE in, DSL NTR/GPON PHY/SyncE on the last mile.

QoS and High Availability for mission critical traffic

Today, mobile operators have mission critical voice services running over a TDM backhaul network, with stringent guarantees for loss, delay, jitter and availability provided by the PDH/SDH network.

By no means should these guarantees be impacted when moving to a packet based backhaul.

A conservative approach is to move into a data off-load scenario as a first step: voice and synchronization remain on the TDM network, whereas high volume data traffic (with less stringent QoS requirements) is off-loaded to the packet network.

In the full backhaul scenario, the mobile backhaul solution needs to provide QoS and High Availability inherently.

• The ISAM access node, being already engineered for triple play services is well positioned to provide differentiated QoS for mobile voice and data traffic streams of varying nature, also in competition with residential and business traffic in the same node.

• In terms of High Availability, prime concerns are focused on the network links and - elements that aggregate a (large) number of base stations and less so on the first mile. For these links/nodes, High Availability is taken care of by either IP/MPLS mechanisms (possibly initiated from an IP/MPLS capable cell side device) or carrier Ethernet mechanisms, or a mixture thereof. Dual homing of the access node to the aggregation network is essential for protecting the second mile (with LAG or mSTP) and the first aggregation node (with multi-chassis LAG or mSTP).DSL bonding inherently provides a level of resiliency for a first mile over bonded DSL.

Figure A-1 High availability: points of failure

L2 aggregationAN

ISAM dual uplinks with LAG,multi-chassis LAG, mSTP

IP/MPLS or CarrierEthernet repair mechanisms

ISAM NTredundancy

CSG

Base station

TDMATMETH

AGG

AGG

GTW

ControllerGTW

GPON feeder redundancyinherent redundancy in DSL bonding



Access node features: QoS (as for triple play), NT redundancy, dual homed ISAM uplinks (with LAG, multi-chassis LAG or mSTP), transparent for IP/MPLS based redundancy (handled in the cell site gateway and/or in the IP/MPLS core), GPON feeder redundancy, inherent redundancy in DSL bonding (for ATM IMA and EFM).

Demarcation

End-to-end OAM features and SLA monitoring (including the first mile) are typically handled by the cell site gateway device, either by IP/MPLS mechanisms or by carrier Ethernet mechanisms. 802.1ag and Y.1731 can be used between the cell site device and the gateway device for end-to-end checks of connectivity, loss and delay, either on a continuous basis or on-demand. Optionally, 802.1ag MEPs and MIPs can be placed in ISAM for further troubleshooting and fault isolation.

Access node features: Transparent for end-to-end IP/MPLS OAM and 802.1ag/Y.1731 OAM. Optional 802.1ag MIP/MEPs in the access node for troubleshooting.

Solution descriptionFigure A-2 shows the different access options for mobile backhaul over ISAM and the associated cell site gateway portfolio.

Figure A-2 Mobile backhaul cell site device portfolio

Low-end residential type DSL CPEs (ADSL2+, 7130 Cellpipe VDSL2) are low-cost solutions for data off-load of 3G base station Ethernet interfaces (for base stations with hybrid ATM/Ethernet interfaces).

Dedicated 3rd party SHDSL CPEs for business/mobile backhaul can be positioned as mid-range solutions for full backhaul of TDM, ATM and Ethernet services over (bonded) SHDSL.

7705 SAR-F (fiber uplink) and 7705 SAR-M (with modular uplink of fiber, 4p bonded SHDSL + 2p bonded ADSL2+ (combo) are high-end solutions for off-load and full backhaul of TDM, ATM and Ethernet services. 7705 SAR-F and 7705 SAR-M are IP/MPLS based.

Figure A-3 shows the logical end-to-end topologies for mobile backhaul between multiple mobile base stations and a centralized mobile controller.

1-2p adsl2+

1-4p shdsl

1-4p shdsl + 1-2p xdsl

2p vdsl2

point-to-point Ethernet (FE|GE)

7302/7330 ISAM

ADSL2+ CPE (o)

3 party SHDSL CPE

CellPipe 5Ve.A4010 (o)SAR-M combo

SAR-M/SAR-F (o) offload only

rd



Figure A-3 Mobile backhaul end-to-end-topologies (logical)

The solution components are:

• A cell site gateway (CSG) that performs media adaptation between the base station interfaces (TDMoE1, ATM IMAoE1, Ethernet) and the first mile physical layer (DSL, GPON, point-to-point FE/GE) and initiates pseudo wires when applicable. In addition, it can perform synchronization and demarcation functions when applicable. On the network side, the cell site gateway can be either IP/MPLS based (TDM/ATM/Ethernet PWE3 pseudo wires) or Ethernet based (raw Ethernet + TDM MEF8 pseudo wires).

• The access node (AN) is typically operated in L2 transparent vlan cross-connect mode for mobile backhaul, with each cell site gateway or service cross-connected to the first aggregation node.The access node is typically shared with residential and possibly other business users.

• The aggregation network can be carrier Ethernet based or IP/MPLS based. In the latter case IP/MPLS from the cell site gateway is typically tunneled in a L2 IP/MPLS service. A flat IP/MPLS model is also possible in principle, but requires hybrid (access/MPLS) interfaces on the first aggregation node.

• A controller side Gateway Device (GTW), peering with the cell site gateway on the pseudowire level and interfacing to the mobile controller(s) over TDM STM-x, ATM STM-x or Ethernet interfaces.

Access nodes can be dual homed to redundant aggregation nodes and mobile controllers can be dual homed to redundant gateway devices for High Availability purposes.

CSG

Base station

TDMETH

Controller

AN AGG GTWL2 tunnel (IP/MPLS)

MEF8 PW (TDM) + raw Ethernet

Mixed

CSG

Base station

TDMETH

Controller

AN AGG GTWCarrier Ethernet

MEF8 PW (TDM) + raw Ethernet

Carrier Eth

CSG

Base station

TDMATMETH

Controller

AN AGG GTWL2 tunnel (IP/MPLS)

PWE3 IP/MPLS pseudowire (TDM/ATM/ETH)

IP/MPLS

TDMETH

TDMETH

TDMATMETH



Figure A-4 shows the physical layer synchronization architecture of ISAM.

Figure A-4 ISAM physical layer synchronization architecture (DSL and point-to-point)

Physical layer synchronization can be fed into ISAM either via BITS or via SyncE from the network through synchronization-capable dedicated NT variants. In case no BITS or SyncE is available in the Central Office, an external device can be collocated that terminates 1588v2 (or eventually ACR) and feeds into the ISAM via the BITS interface.

Synchronization can then be propagated over the first mile to a synchronization-capable cell site gateway through a physical layer mechanism: SHDSL NTR. 7356 deployments also support physical layer synchronization from CO to the cabinet through SyncE.

Finally, the cell site gateway provides synchronization to the base station either through a synchronized E1 or through a SyncE interface.

The physical layer synchronization entails frequency synchronization only.

7302/7330 ISAM

SHDSLLT

8 kHzbackplane

NT

BITS G.703 SHDSL.bis PHY NTR

GigESyncE B

ase station interface

3 party CPE7705SAR-M

rd

E1

FE/GE (SAR-M)

FE/GE unsynchronized (3 party CPE)rd

Optical GE SyncEto 7354 REM



A.3 E1/T1 Leased Line Replacement

ScopeThis section describes solutions for emulation of (E1/T1) leased line services with access over ISAM over SHDSL, using 3rd party SHDSL CPEs (single or multiple E1/T1 interface).

In principle, E1/T1 leased lines can also be emulated over point-to-point ethernet access, with a dedicated fibre CPE.

IntroductionOperators may benefit from consolidation of legacy (E1/T1) leased line services on broadband access equipment rolled out for residential (and business) services.

This may allow them to e.g. decommission dedicated line systems for (E1/T1) leased line access. It may also be an element in an ongoing decommissioning (partial of full) of the legacy TDM network in favour of a packet switched network.

Technical Challenges

Leased line emulation

TDM pseudowire technology is used for emulation of (E1/T1) leased line services over a Packet Switched Network (PSN). Structured and unstructured E1/T1 can be transported using RFC 4553 SAToP (Structure Agnostic TDM over Packet) and RFC 5086 CESoPSN (Circuit Emulation Service over PSN) encapsulations respectively. The TDM pseudowire can be transported over Ethernet (MEF8), over MPLS, or over MPLS/GRE.

In this solution, TDM pseudo wires are set up between a dedicated device on the customer premises (3rd party SHDSL CPE) and a peer device (either a peer CPE on another customer site or a centralized device interfacing to the core TDM network, usually over STM1/STM4).

Symmetrical bandwidth

Physical layer bandwidth requirements for transporting an E1/T1 will depend on the encapsulation type (Ethernet, MPLS) and the TDM payload size in the pseudowire, but will amount to more than 2 Mbps symmetrical per E1/T1. In practise, for copper access this (together with delay and synchronization requirements) rules out ADSL2+ in favour of SHDSL. Bonded SHDL links, as well as SHDSL repeaters can be used to increase the reach of SHDSL segments for leased line replacement. ATM IMA and EFM bonding are preferred for SHDSL for reasons of resiliency (if one pair goes down, the group will not be impacted). Of the two, EFM bonding is superior with respect to bandwidth efficiency, provisioning simplicity and flexibility in data rates for the different pairs.



Key Performance Indicators (KPIs) for loss and delay

The legacy TDM network guarantees stringent requirements for loss and delay for TDM traffic. These cannot be impacted by moving to an emulated service over a packet switched network under load (in competition with residential and other business services).

The ISAM access node, being already engineered for triple play services (including loss sensitive video and delay/jitter sensitive voice) is well positioned to provide low loss/low delay guarantees.

SHDSL is a low latency technology that complies to delay requirements for leased line.

Tuning of the payload size and de-jitter buffer size of the pseudowire allows to meet delay and loss requirements under background network packet delay variation (PDV).

Synchronization

Both ends of an E1/T1 leased line connection need to be synchronized to avoid frame slips in the TDM transport (i.e. wander needs to comply to the ITU-T G.823 traffic mask).

This solution assumes a network clock is imposed upon the customer TDM equipment.

For leased line emulation, the clock reference has to be distributed through the packet network. As discussed in the mobile backhaul section, this can be done via physical layer mechanisms (SHDSL NTR, GPON PHY, SyncE) or via packet layer mechanisms (NTP, 1588v2 PTP, ACR, DCR).

It is recommended to use physical layer synchronization mechanisms whenever available. I.e. BITS or SyncE into the ISAM in CO and physical layer synchronization (NTR, GPON PHY, SyncE) from there to the business site. If no BITS or SyncE is available in CO, we recommend 1588v2 termination in a client in the CO and to go with physical layer synchronization from there. This can be an external client device that feeds into the BITS of ISAM.

Access node features: NT with BITS/SyncE in, SHDSL NTR on the last mile.

High Availability

In terms of High Availability, prime concerns are focused on the network links and network elements that aggregate a (large) number of customers and less so on the first mile. For these links/nodes, High Availability is taken care of by either IP/MPLS mechanisms (possibly initiated from an IP/MPLS capable business CPE) or Carrier Ethernet mechanisms, or a mixture thereof. Dual homing of the access node to the aggregation network is essential for protecting the second mile (with LAG or mSTP) and the first aggregation node (with multi-chassis LAG or mSTP).

DSL bonding inherently provides a level of resiliency for a first mile over bonded DSL.

Access node features: NT redundancy, dual homed ISAM uplinks (with multi-chassis LAG or mSTP), transparent for IP/MPLS based redundancy (handled in business CPE), inherent redundancy in DSL bonding (ATM IMA and EFM).



Solution descriptionFigure A-5 shows the access components for a leased line replacement solution over (bonded) SHDSL.

Figure A-5 Access components for E1/T1 leased line replacement

3rd party SHDSL business CPEs provide circuit emulation for a single or multiple E1/T1 (possibly in conjunction with Ethernet access) over SHDSL (single pair g.SHDSL at max 2.3Mbps Mbps up to 4 pair EFM bonded g.SHDSL.bis at max 22.8 Mbps). The pseudowire encapsulation is IP/MPLS with static MPLS labels. SAToP and CESoPSN encapsulations are supported.

Figure A-6 shows the logical end-to-end topologies for leased line emulation between 2 business customer sites.

Figure A-6 End-to-end topologies for E1/T1 leased line emulation

Two connectivity models can be envisaged and will possibly be deployed in parallel:

• A business CPE connected back-to-back over an end-to-end pseudowire to a peer business CPE, without crossing a SDH/PDH segment.

• A business CPE connected over a pseudowire to a core SDH/PDH network (typically groomed over an STM1/STM4 interface). The pseudowire could cover the access segment only (with the pseudowire terminated and dropped on TDM equipment in the CO). Alternatively it could span the full metro Ethernet aggregation network (TDM equipment in a centralized PoP location).

1-4p shdsl

7302/7330 ISAM

3 party SHDSL CPErd

1-4 * E1/T1 (+ Eth)

CustomerTDM equipment

TDM pseudowire (MEF-8 or IP/MPLS)

CPE/B-0404G

ONTAN

CPE/B-0404G

ONTAN


Aggregation

(ETH, IP/MPLS)

E1 E1


TDM pseudowire (MEF-8 or IP/MPLS)

CPE/B-0404G

ONTAN

CESGTW


Aggregation(*)

(ETH, IP/MPLS)

E1ADM

SDH E1

(*): optionally, AN could also directly connect to CES GTW in CO



The solution components are:

• A business CPE that performs media adaptation to the access technology (SHDSL) and initiates/terminates the TDM pseudo wire(s). It will also perform synchronization functions.

• The access node (AN) is typically operated in L2 transparent vlan cross-connect mode for leased line emulation, with each business CPE cross-connected to the first aggregation node.The access node is typically shared with residential and possibly other business and mobile backhaul users.

• The aggregation network can be carrier Ethernet based or IP/MPLS based. In the latter case IP/MPLS from the cell site gateway is typically tunneled in a L2 IP/MPLS service. A flat IP/MPLS model is also possible in principle, but requires hybrid (access/MPLS) interfaces on the first aggregation node. See the section on mobile backhaul for more details on the aggregation options.

• A CES gateway device (CES GTW) (not present in the back-2-back scenario), peering with the TDM core network.

Access nodes can be dual homed to the aggregation network and SDH equipment can be dual homed to redundant gateway devices for High Availability purposes.

In this solution, the customer TDM equipment is timed by the network clock. In the second connectivity model, this is also the clock of the core TDM network. As per the ALU synchronization strategy, an end-to-end physical layer synchronization is preferred. This means that physical layer synchronization is fed into ISAM either via BITS or via SyncE from the network through synchronization capable dedicated NT variants.

In case no BITS or SyncE is available in the central office, an external device can be collocated that terminates 1588v2 (or eventually ACR) and feeds into the ISAM via the BITS interface.

Synchronization can then be propagated over the first mile to the business CPE over SHDSL NTR.

Finally, the business CPE provides a synchronized E1/T1 to the customer TDM equipment.



A.4 ISAM Backhaul (Rural DSL, Ultra-high Broadband)

IntroductionThe absence of fiber may not be blocking for remote ISAM deployments. Also in fiber-poor areas, ISAMs for DSL broadband access can be deployed. Taking the approach of backhauling the fiber-link (point-to-point Gigabit Ethernet) by an alternative transport technology leaves no further constraints deploying the ISAM in rural areas or other markets where the exclusive use (dark-fiber) of fiber is not possible to connect the ISAM.

Depending on the market, available regional or national infrastructure or customer requirements, we can distinguish possible domains:

• Rural areas (Broadband for all)• Early/fast deployments in emerging markets reusing legacy (incumbent) network• Reuse of high-capacity national infrastructure• Complementing fiber based FTTN deployment

Solution descriptionThe base of the solution is finding the best way for backhauling the Gigabit Ethernet fiber link. The choice of the backhaul transport technology is depending on the backhaul distance, the available infrastructure to leverage upon, regulations (e.g. in the case of wireless backhaul options) and required throughput.

The backhaul is accomplished by using a converter which converts the optical Gigabit Ethernet transport layer into an other Ethernet based transport layer (illustrated by Figure A-7). The new transport layer consists of a physical layer depending on the available infrastructure and a data-layer supporting the transport of Ethernet frames. Depending on the different physical layers different framing options apply: EFM (G.SHDSL), GFP (Generic Framing Procedure ITU-T G.7041), HDLC (High-level Data Link Control ISO-13239, ML-PPP (Multi-Link Point-to-Point Protocol RFC-1990), …



Figure A-7 ISAM fiber backhaul

A converter will be required at the Central Office location and at the Remote/Cabinet location. These converters can be point-to-point, where one Ethernet link corresponds to one link in the transport network or they can be point-to-multipoint where Ethernet frames are bridged between one Gigabit Ethernet link on the ISAM side and multiple transport links on the backhaul network side (e.g. ML-PPP).

Bandwidth

In many cases the backhaul transport network can not offer the full 1 Gbps connection which is supported on the ISAM product family. This is typically not an issue for rural areas where the number of remote subscribers to be served are limited per rural site with a limited total amount of bandwidth need, or for emerging markets where connectivity with a rather limited bandwidth is the primary requirement. An assessment must be made on a case-by-case base to see whether the network capacity is sufficient in the backhaul transport network for the target end-user services (Voice, High Speed Internet, …). Possibly multiple links need to be bundled to increase the bandwidth.

In industrialized countries with subscriber dense areas and high bandwidth per user (e.g. 20 Mbit/s), where typically fiber is being used for FTTN deployments, higher capacities are required for the backhaul link. The backhaul approach is taken for those locations which can not be served by fiber (fiber black spots) to obtain 100% user coverage with ISAM based broadband access.

7302 ISAM CO

7330 ISAM CO

7330 ISAM RA

7330 ISAM FTTN

7356 ISAM REM

7357 ISAMSEM

Remote / Cabinet LocationCentral Office / Aggregation

Location

AggregationNetwork

ISP 1

ISP 2

Corporationsand Residences

7354/7324 ISAM RU

Ethernet

OpticalDistribution

Network

ODF

Active OpticalNetwork

Backhaul option

TransportNetwork

Co

nverter

Co

nverter

7302 ISAM CO

7330 ISAM CO

7330 ISAM RA

Central Office / AggregationLocation

AggregationNetwork

ISP 1

ISP 2

Ethernet

7330 ISAM FTTN

7356 ISAM REM

7357 ISAMSEM

Remote / Cabinet Location

Corporationsand Residences

7354/7324 ISAM RU



Transparency

The backhaul connection between the remote ISAM and CO ISAM must provide a transparent Ethernet service. The bridging function between the network port of the ISAM (uplink and/or subtended link) and the backhaul transport network can be done by an external converter. The converters and backhaul transport network must ensure that, both the remote ISAM and the CO node, are able to extract the original frames sent by the other side, in the same order as they were sent, i.e. no frame-reordering or fragmentation.

Service differentiation

ISAM deployments in a backhaul scenario, and especially in those cases with limited backhaul capacity like rural areas, must support proper queuing and scheduling mechanisms to provide service differentiation in both up- and downstream direction. Voice must get strict priority over other services like Video and High-Speed Internet, and management connectivity must be ensured at all times.

Congestion is likely to occur on the backhaul link between the remote ISAM and the CO node due to the limited available bandwidth on this link. The buffer-acceptance, queuing and scheduling in the upstream direction on the remote ISAM and in the downstream direction on the CO node are particularly important.

Next to the queuing and scheduling mechanisms, proper service classification must be done on the backhaul link. At least the p-bits in the VLAN-tag should be configurable as a means to map VLAN-tagged traffic in the appropriate queues.

To overcome congestion and eventually packet drop (high priority traffic) on the backhaul link we can use the buffer mechanism of the ISAM, in both upstream and downstream direction. Using the interface rate-limiting capabilities of the ISAM network ports, uplink at the remote ISAM and subtended link at the CO node, service differentiation can be done based on the available bandwidth on the backhaul link. The port rate-limiting allows traffic scheduling (queue handling) to be done at a speed (bit rate) matching the available bandwidth in the backhaul transport network. The dimensioning of the rate-limited on ISAM network ports will depend on the encapsulation overhead added by framing mechanism implemented on the backhaul transport equipment (i.e. converters) and the Ethernet frame sizes used by the data services. When forwarding the Ethernet frames over the transport link, headers and trailers are added to the Ethernet frame. This results in a lower Ethernet packet throughput than natively supported by the backhaul link. The overhead, headers and trailers added, depends on the encapsulation method used. Figure A-9 shows an example of the header/trailer bytes added by the GFP and HDLC encapsulation method.



Figure A-8 Encapsulation overhead GFP versus HDLC

As a result the port rate-limit will be set to a rate according the supported packet bit-rate and not to bit-rate natively (on the wire) supported by the transport network, which can be a lot lower, depending the Ethernet frame sizes. See below an example based on GFP-F on E1 to illustrate this.

Table A-1 GFP Encapsulation overhead calculation

In a second step packet buffers and schedulers of the converters can be used to deal with service differentiation when sudden bandwidth drop occurs on the backhaul link (e.g. link failure). The priority scheduler in the converter will ensure high priority traffic (e.g. voice) gets precedence over other concurrent traffic in case of congestion. This is illustrated in Figure A-9.

Framed E1 (31 Timeslots) = 1984 kbit/sGFP-F Overhead = 12 bytes

Ethernet frame size(bytes)

Max throughput(kbit/s)

Overhead(%)

Rate limiter ISAM(x 64 kbit/s)

64 1670 15,83 26

128 1813 8,62 28

256 1895 4,49 29

512 1938 2,32 30

1024 1961 1,16 30

1500 1968 0,81 30

GFP Encapsulation HDLC Encapsulation



Figure A-9 ISAM backhaul with point-to-multipoint converter

In case of point-to-point converters (see Figure A-10), the ISAM ensures the service differentiation. Flushing the queues will be done at the rate of the available bit-rate on the link giving precedence to the frames in the highest priority queue.

Figure A-10 ISAM backhaul with point-to-point converter

Resiliency

To limit the impact of single failures, the backhaul solution should provide the necessary resiliency at all levels of the architecture. Depending on the backhaul transport network different resiliency mechanisms apply: ML-PPP, EFM bonding, SDH VCAT (Virtual Concatenation), APS (Automatic Protection Switching), …. On top packet based link-aggregation can be done using LACP (LAG) or path redundancy using RSTP.

Bonding or aggregation functions do not only allow a level of resiliency put also offer the means to provide more aggregated bandwidth on the backhaul link.

Converter

SP

VoIP

NW Ctrl

HSI

DS

L Link Policies

Protocol basedVLAN tag. + Pbit

LT

NT

NT

DSL1

DSL48

GE

GE

WRR

SP

VoIP

HSI

NW Ctrl

SP

VoIP

NW Ctrl

HSI

shaping

FE/GE

Converter

WRR

SP

VoIP

HSI

NW Ctrl

NT

shaping

FE/GE

WRR

SP

VoIP

HSI

NW Ctrl

E1

E1

...GE

Mgmt IP

DOWN

UP

Remote / Cabinet Location Central Office / AggregationLocation Backhaul option

PDH (nxE1)

VoIP : Strict Priority 1

NW Ctrl : Strict Priority 2

HSI : Best Effort

ML-PPP

DS

L Link Policies

VoIP : Strict Priority 1

NW Ctrl : Strict Priority 2

HSI : Best Effort

Central Office / AggregationLocation Backhaul option

PDH (nxE1)

Remote / Cabinet Location

GE

GE

GE

GE

GE

GE

GE

GE

GE

NT NT

NT

LTProtocol based

VLAN tag. + Pbit

UP

DOWN

DSL1

DSL48

GE

GE

WRR

SP

VoIP

HSI

NW Ctrl

shaping

WRR

SP

VoIP

HSI

NW Ctrl

shaping

WRR

SP

VoIP

HSI

NW Ctrl

shaping

WRR

SP

VoIP

HSI

NW Ctrl

shaping

LAG

E1

E1

E1

E1

E1

E1

E1

E1

LAG

WRR

SP

VoIP

HSI

NW Ctrl

shaping

WRR

SP

VoIP

HSI

NW Ctrl

shaping

WRR

SP

VoIP

HSI

NW Ctrl

shaping

WRR

SP

VoIP

HSI

NW Ctrl

shaping

WRR

SP

VoIP

HSI

NW Ctrl

Mgmt IP



As shown in Figure A-9 the LAG function of the ISAM is being used to aggregate 4x E1 based backhaul links into one pipe. Figure A-10 shows an example where the bonding of the backhaul link is done in the transport network using ML-PPP (typically 16xE1).

The end-to-end path resiliency will only work when “fault-propagation” is supported by the converters and any other intermediate node. Any link-failure causing a service outage in the path must be propagated in the forward and backward direction towards the connected ISAM. The CO ISAM will take proper measures when the link-failure (operational down) is detected: an alternative route might be chosen based on the implemented resiliency function (e.g. LAG) and a port-down alarm (LOS) is presented to the management system. In a none redundant backhaul scenario the alert should indicates that the remote site is no longer reachable.

Ethernet bridging converter options

Alcatel-Lucent offers a wide range of products supporting different transport network options combined with the required Ethernet interfaces and Ethernet bridging functionality.

Given the rich Alcatel-Lucent portfolio supporting any transport option, the ISAM can be deployed in any environment:

• Reusing available incumbent transport infrastructure which lowers the CAPEX investment for the remote DSLAM deployment

• Leveraging on equipment already used by the Telecom provider to have limited OPEX impact: no new logistical processes required, reuse of in-house skills, unified management …

• Fast go-to-market with Broadband access by providing early connectivity prior to fiber roll-out. No DSLAM replacement is required after upgrading the network infrastructure later on.

Figure A-11 provides a high-level overview of possible ISAM configurations and converters to provide the backhaul connectivity.



Figure A-11 ISAM backhaul options

A.5 Hospitality solution

IntroductionMany hotels and retirement home are wired with Category3 cable which was very popular in 1990's. The Cat3 twisted pair is mainly used to provide hotel and public telephony services for the hotel guests, in the room and in public areas, and the hotel staff.

With the emergence of broadband internet access, WiFi (shared) hotspots were made available where the hotel guest can connect to. In many cases the internet hotspot belongs to an ISP. The user connects to the internet via the user registration portal of the ISP after paying a connection fee (pre-paid) via a credit-card.

Figure A-12 Standard offering for voice and internet access in hotel guest rooms



In order to remain competitive, to increase revenue opportunities and to enrich the guest experience, hotels need to upgrade their IT infrastructure to offer high-speed and secure internet access, voice and multi-media applications and need to get into the value chain.

Via similar ways a Telecom operator offers Triple play services to residential subscribers via xDSL and IP DSLAM, the hotelier can offer IP based triple play services to the hotel guest with xDSL provided by an IP DSLAM.

By reusing the existing Cat3 wiring for xDSL the hotelier can achieve this over the existing infrastructure, without to costly cabling costs. So no “rip & replace” but fully leverage on the existing infrastructure providing triple play-services. The choice between ADSL2+ or VDSL2 depends on the length of the copper-wire and the required data throughput.

Figure A-13 Enhanced multi-media experience in hotel guest rooms with xDSL

Solution description

High level architecture hospitality solution

The ISAM is installed in the existing telecom closet/room near the existing terminal blocks or distribution frame.

From here DSL connectivity is provided to each room to offer voice (VoIP), video (IP TV), high speed internet and other data services (multi-media, gaming, …) using a single copper pair.

A modem (e.g. ALU 7130 CellPipe gateway) distributes the services within the hotel room by providing connectivity to STBs, VoIP or POTS phones, laptop PCs, (personal) multimedia devices and in-room control (wake-up call, mini-bar, …).

Gigabit Ethernet interfaces from the ISAM provide connectivity to the supporting network for the different data services, billing servers/firewalls and management systems.



Not all hotels or retirement homes are the same. They differ not only in size, in terms of number of guest rooms, but also in building architecture. Depending on the building and infrastructure architecture different product solutions can be offered:

• Small to medium size hotels consisting out of one building, having a single, centralized equipment room where all the terminal blocks are residing. In such a case a CO ISAM or a standalone FTTN node is used to terminate the copper pairs from all the guest rooms on one central location; see Figure A-14.

• Medium to large size hotels with multiple equipment rooms (e.g. on each floor) in one building are addressed using the distributed ISAM solution. In such a case a 7356 ISAM REM chassis can be installed at the different terminal blocks. An aggregation node aggregates the distributed nodes via GigE optical connections and provides a single uplink to the network; see Figure A-15.

• A variant to the previous deployment scenario is with larger properties where the hotel guest's rooms are distributed over different buildings or multiple, collocated, remote sites (e.g. campus). The same ISAM solution applies as in the previous case; see Figure A-16.

Figure A-14 IP DSLAM Deployment scenario for hospitality, centralized



Figure A-15 IP DSLAM Deployment scenario for hospitality, distributed (single building)

Figure A-16 IP DSLAM Deployment scenario for hospitality, distribute (multiple sites)



DSL and POTS in hospitality solutions

Proven xDSL technology is used on the existing copper pair towards the guest rooms for the IP/Ethernet based services. This copper pair is used traditionally to provide telephony (POTS) services.

Figure A-17 ISAM in hospitality: triple-play high-level network topology

Two options apply:

• The existing telephony/POTS can coexist on the same pair as the DSL services.Voice and DSL use a different frequency band (POTS uses narrowband, DSL broadband) on the copper wire. Splitters are used to separate the POTS from DSL.The DSL terminates on the DSL LT of the ISAM and POTS is further relayed to the voice switching system of the hotel. If desired the splitter function can be provided by the ISAM using a dedicated POTS splitter board or a DSL LT board with integrated splitter technology.The same splitter technology is required on the modem side. The POTS splitter is usually supplied via wall socket with a connector for both the POTS/analogue phone and the modem (see Figure A-17, “room 1”).

• The copper pair is used for DSL only (naked or dry-loop DSL) and the existing telephony/POTS is replaced by a Voice-over-IP service. In this case the IP telephony service is delivered to the guest room over the DSL connection.This scenario does not require any splitter technology. The analogy voice is packetized into a VoIP (RTP) stream via the DSL gateway in the guest room or a VoIP phone set is being used (see Figure A-17, “room 2 and 3"). In both cases the VoIP is handled as any other data stream on DSL. A higher quality of service treatment is applied to the voice, than the concurrent data streams (Internet, IPTV, …) on the same DSL line.

Broadband bandwidth requirements

The total bandwidth required is determined by the services offered to the hotel guest.



To a large extent the bandwidth requirements are defined by the IPTV service offering. IPTV is recognized as a high value added service for the hotelier. Especially with the emergence of HD TV an attractive offering for the hotel guests can be made. The capacity required for IPTV is determined by:

• High Definition (HD) or Standard Definition (SD) TV or both (e.g. SD broadcast TV combined with HD Video-on-Demand)

• Encoding used: MPEG2, MPEG4• Number of TVs in the room or suite.

Internet access is no longer a nice-to-have service but has become a necessity. On top, with the use of internet for social networking, file sharing, video-conferencing, business, and so on, internet is also no longer seen as a best-effort service. Also high-speed internet access comes with a minimum of bandwidth guarantees and quality of service.

IP Telephony is probably the least bandwidth consuming service but requires the highest quality of services and needs to be prioritized accordingly.

Other services are on-line gaming (might be part of Internet service), in-room control, hotel camera views (e.g. bar, swinging-pool, …), …

Figure A-18 Hotel Room Bandwidth requirement

All the data-streams described in Figure A-18 can run over a single DSL copper pair. In the ISAM and the DSL gateway in the room the proper quality of service provisioning is done for each of the services. Policing and rate-limiting might apply depending on the guest profile and service package subscribed to.

The available DSL bandwidth on the copper pair depends on the DSL technology used:

• ADSL2+ with a theoretical maximum downstream bandwidth of 25 Mb/s.• Supports longer loops than VDSL2• Typically 15-20 Mb/s• Artificial Noise can be applied to increase stability of the line

SD TV MPEG2 Channel: 2 - 5 Mb/s

HSI: 1 - 5 Mb/s

HD TV MPEG4 Channel: 5 - 10 Mb/s

Online gaming: 4 - 8 Mb/S

SD TV MPEG4 Channel: 1.5 - 2 Mb/s

In control room: 0.5 Mb/s

VoIP: 160 Kb/s



• VDSL2 (17a profile) has a theoretical maximum downstream bandwidth of 100 MB/s

• Due to the use of higher frequencies on the copper pair the distance is limited• Typically 25-40 Mb/s• Virtual Noise increases stability

Other factors influencing the actual copper and therefore the bandwidth are:

• Cable type: Gauge, twisted-pair, shielding, …• Distance: loop length limits, especially for VDSL2• Bridged Taps: copper pairs that are interconnected together are causing reduced

DSL performance• Environment Interference: airco's, elevator engines, …• Interference by cross-talk: caused by other services on adjacent pairs.

Global or individual DSL line settings can be applied on the ISAM to minimize the impact of the different factors described above by configuring DSL profiles accordingly. DSL profiles can be DSL line specific or uniform across a line card and/or ISAM chassis.

A.6 Open Community Broadband for Smart Communities

IntroductionEnd-user's expectations on access to Broadband connectivity are becoming nearly as widespread as for the classic commodities (water, gas, electricity, telephony). Not just private end-users but also businesses and local authorities need broadband access. However the geographical coverage by the classic operators is not total, and not all greenfield opportunities are covered. Backed by government incentives, more and more local authorities are considering the deployment of a community-wide access network to fill the gaps and ensure digital attractiveness of their locality (for social and economic reasons). This is the Smart community concept, whereby there is a variety of levels for the “community”: building site, campus or estate, city district, and complete city. One important aspect for attractiveness is the openness to multiple service providers, promoting service competition rather than access competition. The applications include but go beyond the classic triple play, also encompassing business services and specific services for public authorities like municipalities.

The aim of the Open Community Broadband solution is to offer a way for those new entrants to build out, deploy and manage such a single access and aggregation infrastructure at their local level, which can then be opened to and shared by multiple third party service providers, from which the end-users can select a mix of applications. In other words to offer a very flexible wholesaling framework.

The OCB solution as such comprises the passive infrastructure, the active infrastructure, the management sub-system, and the professional services for guidance of the local authority to roll out the infrastructure. OCB is part of the wider context of Smart Communities, developed by Strategic Industries. The scope is greenfield deployments, encompassing FTTH networks (point-point Ethernet, GPON) and other flavours of FTTx depending on the case-by-case needs.



The converged ISAM can play a prominent and competitive role in the OCB solution, by offering a variety of access technologies (point-point optical, GPON access, FTTx) in a single platform with the necessary mechanisms to create and manage the connectivities in an open context. Other advantages of the ISAM are port density, the modular approach (extend-as-you-grow with LTs), and high temperature range.

OCB context

Wholesaling

Three layers can be identified in the delivery of broadband access. The first is the passive infrastructure (ducts, cables, fibres, splitters). The active infrastructure consists of all network equipment, and uses the passive infrastructure for giving connectivity between the end-users and the applications. Finally the service layer uses the active and passive infrastructure to deliver the applications.

In traditional networks the approach is a vertically integrated one; the different incumbent operators integrate all layers, competing with each other on access infrastructure and less on the services offered.

It is possible to introduce wholesaling to this situation, splitting the responsibilities over multiple roles, to varying degrees, as illustrated in Figure A-19. In the passive wholesale case, a single passive network is shared and made accessible to multiple vertical service providers. In the active wholesale case, a single vertical infrastructure provider offers connectivity to multiple retail service providers (RSPs). Finally in the most separated case, a single passive provider gives access to its infrastructure to the active network operated by a single network operator which connects towards multiple service providers. Note that even here a single player can combine the roles of active infrastructure owner and service provider (by offering its own services), but the important point is that it remains open to third party retail service providers.

Figure A-19 OCB: roles and wholesaling levels

The focus of OCB lies on the full separation case.



Roles and responsibilities

As shown in Figure A-20, in the fully separated case there are distinct responsibilities at each level.

Figure A-20 OCB: roles and responsibilities

Solution description: Active architecture

Requirements

The OCB network must carry residential (triple play + RF video), business (L2 VPN, L3 VPN, Business Internet Access) and public applications (VPN, e-care, …) with the corresponding levels of security, availability and QoS differentiation. It can hence be based on existing converged network architectures for residential and business applications (public applications can be mostly considered as business services). There are some new requirements though with respect to existing environments, namely the level of wholesaling and the need for an integrated management approach:

• each end-user is able to select applications from multiple service providers simultaneously

• the network operator can sell white label services to third-party service providers who can then include this service next to their own into their commercial bundle towards the end-user

• the network operator must have the management tools to operate the network, the users and their selection of services in the most integrated possible way. A certain level of dynamism is introduced by allowing end-users to select the services per service provider via a self-provisioning portal.

• The network operator needs to provide the ability for Retails Service Providers (RSP) to offer competitive and differentiating service offerings. The OCB network as to support a very granular configuration of bandwidth and QoS per RSP per end-user.



Architecture: Ethernet open access

The Customer Premises Network (CPN) can either consist of a CPE followed by one RGW per RSP (delivered by the RSP), or of a CPE followed by a single RGW (delivered by the network operator). In both cases there is one IP address allocated per RSP. Note that in the first case each RGW falls under responsibility of its corresponding RSP, and that in the second case the RGW is managed by the network operator.

The access & edge network is characterized by the following features;

• Generic:In general the connectivity is similar to the broadband networks for residential and business applications. As a single user can now connect to different service providers simultaneously, the service provider separation on the first-mile is done by means of VLAN tagging by the CPE (port-based). Traffic is further separated in the network at L2 by means of VLANs (separate broadcast domains) and at MPLS level by means of VPLS or VLL instances. There is also a separate VLAN and VPLS instance for the CPE management (e.g. TR-069), which is fully terminated by the network provider. At the edge of the network operator, there is a L2 hand-off to the different service providers. In other words there is no routing within the network operator domain.A new feature introduced in OCB is the self-provisioning portal, offering the possibility for end-users to dynamically check their service subscriptions and select specific services from the service providers they have subscribed to. The portal is best positioned at the network operator, to consolidate the view of the end-user on all its services (see paragraph on management subsystem).

• Specifically for residential services:All requirements of classic triple-play deployments apply, in terms of L2 and L3 security, QoS handling, connectivity capabilities, IGMP handling, DHCP proxying, and so on…. However a couple of features are additionally required in the specific context of OCB:

• the support of multiple service providers (with potentially overlapping multicast addressing schemes) in the network, possibly also multiple multicast IPTV services per subscriber. This must be taken into account in the multicast replication points and in the CDRs (Charging Detailed Record) for viewing statistics.

• the QoS, access control and resource control policies in the network also have to be applicable at per-service subscriber level.

• Specifically for business/public services:There are no specific OCB requirements on the architecture other than the simultaneous co-existence of multiple VPNs offered by multiple service providers. Note that for business services there is a separation per service instance in the access and aggregation network.The Ethernet open access is the most straightforward deployment model in terms of node complexity and involvement burden of the network operator (IP auto-configuration and service configuration can be left to the service providers). Note however that it implies a mapping of CPN (Customer Premises Network) terminals on service providers.



Figure A-21 L2 access architecture for OCB (residential user showned with 1 RGW per RSP)

Solution description: Management subsystemThe management subsystem covers the set of applications in charge of managing the telecommunication infrastructure, the end users, the services and the service providers.

A solution for the OSS/BSS/CRM (Customer Relation Management)/EMS of the network operator plays an important role in the OCB context. It must support the traditional roles of subscriber provisioning and management, service provisioning and management, statistics gathering, alarm management, and customer care in the wholesale context to multiple service providers per end-user. Additionally in the case of OCB a self-provisioning portal would allow the end-user to select and monitor its services. Note that in OCB the network provider is a new entrant, meaning that it doesn't have experience or legacy systems to rely upon. Hence the importance of an affordable and comprehensive solution.

This can be fulfilled by a combination of the classic EMS platforms (AMS for ISAM and SAM for ESS and SR) with an integrated management platform, which acts as OSS/BSS/CRM by interacting with end-users, network operator and service provider:

• customer self-provisioning portal (restricted access by end-user): users monitor their profile and select their services

• service provider portal (restricted access by service providers): service providers monitor and manage their subscribers

• technical portal (restricted access by network operator): network operator sets the per-subscriber service policies, keeps usage statistics, by directly interacting with the corresponding network elements

• customer care portal (restricted access by service providers): allows the service providers to manage the customer trouble tickets

The dedicated EMS platforms take care of the initial user provisioning and consolidated alarm management.

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 B-13HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

B. RADIUS Attributes

B.1 RADIUS Attributes B-2

B.2 Vendor specific RADIUS attributes B-2


B-2 November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

B.1 RADIUS Attributes

NAS-PortThe 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-IdThe 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.

B.2 Vendor specific RADIUS attributes



GeneralVendor ID 637 is used for 7302 ISAM.

The “Vendor type” field has a length of two bytes where the highest byte is the project ID and the lowest byte is the project specific attribute ID.

The “Vendor length” field has a length of one byte.

The project ID 7 is assigned to 7302 ISAM project. This means that the vendor specific attribute range from 1792 to 2047 will be used for the 7302 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• Packet: Access-Accept

QoS-Profile-NameThe 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.


QoS-ParmsNote: This attribute cannot be specified together with QoS-Profile-Name attribute.




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 parametersTable B-1 lists the VSAs and their default values for the TL1 domain.

Table B-1 TL1 domain parameters

The possible values for each domain are:

• 0: no privilege• 1: privilege level 1• 2: privilege level 2• 3: privilege level 3• 4: privilege level 4• 5: privilege level 5• 6: privilege level 6• 7: privilege level 7

CLI domain parametersTable B-2 lists the VSAs and their default values for the CLI domain.

Table B-2 CLI 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


AAA 1801 Integer (0..3) 1

ATM 1802 Integer (0..3) 3

Alarm 1803 Integer (0..3) 3

(1 of 2)



The possible values for each domain are:

• 0: no privilege• 1: read privileges• 2: write privileges• 3: read-write privileges

CLI profile parametersTable B-2 lists the VSAs and their default values for the CLI profile.

Table B-3 CLI profile parameters

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


(2 of 2)

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

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 GL-13HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

Glossary

Numbers

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.

10GBase-LR An IEEE 802.3ae standard for 10 Gigabit Ethernet. 10GBase-LR carries data at 10 Gb/s to a maximum distance of 6.2 mi (10 km) over single-mode fiber.

100Base-LX An IEEE 802.3 LAN transmission standard for 100 Mb/s Fast Ethernet using Long Wavelength (LX) laser transmitters over MMF for distances up to 1.25 mi (2 km). The 7302 ISAM and 7330 ISAM FTTN support an SMF implementation of 100Base-LX for distances up to 9.3 mi (15 km).

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 An IEEE 802.3 LAN transmission standard for bidirectional point-to-point 1000 Mb/s Gigabit Ethernet over SMF for distances of up to 6.2 mi (10 km). Always used in pairs, wavelength division multiplexing is performed in the SFP module to split the optical signal into two light paths. The 1000Base-BX10-D (downstream) SFP module transmits a 1490 nm signal and receives a 1310 nm signal. The 1000Base-BX10-U (upstream) SFP module transmits a 1310 nm signal and receives a 1490 nm signal.

1000Base-EX A nonstandard implementation of the 1000Base-LX transmission standard with an extended reach up to 24.9 mi (40 km).

Glossary

GL-2 November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

1000Base-LX 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 6.2 mi (10 km).

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 A nonstandard implementation of the 1000Base-LX transmission standard operating at 1550 nm for distances up to 49.7 mi (80 km).

23 inch preconfigured rack

A 23 inch, 7 foot equipment rack with one or two ARAM-D shelves preinstalled. The rack can be extended to 9 ft or 11.5 ft in height.

3DES Triple DES

A mode of the DES encryption algorithm that encrypts data three times instead of once. Three 64-bit keys are used for an overall key length of 192 bits; the first encryption is encrypted with a second key, and the resulting cipher text is encrypted with a third key.

5520 AMS The Alcatel-Lucent UNIX-based, client-server architecture controller for various NE systems.

5526 AMS The Alcatel-Lucent 5526 Access Management System

A UNIX-based, client-server architecture controller for 7330 ISAM FTTN systems.

7300 ASAM The Alcatel-Lucent 7300 Advanced Services Access Manager

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

7301 ASAM The Alcatel-Lucent 7301 Advanced Services Access Manager

A high-bandwidth, multimedia-ready DSLAM that provides DSL-based high-speed data transmission between a residential subscriber host and an ATM network.

7302 ISAM The Alcatel-Lucent 7302 Intelligent Services Access Manager

A DSLAM 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 The Alcatel-Lucent 7330 Intelligent Services Access Manager Fiber to the Node

A standalone DSLAM 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.

Glossary


A

AAL ATM Adaptation Layer

A 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

An easily accessible switch on the equipment that allows audible alarms to be extinguished without affecting the visual alarms. The audible alarms can be toggled as enabled or disabled.

ACU Alarm Control Unit

A plug-in unit or built-in subsystem that collects shelf alarms and provides an alarm interface to the CO alarm system.

ADSL Asymmetric DSL

A variant of DSL with asymmetric upstream and downstream data rates. ADSL provides more bandwidth for downstream traffic (server to client) than for upstream (client to server). There are several types of ADSL including ADSL, ADSL2, READSL. All these types are collectively referred to as multi-ADSL.

AES Advanced Encryption Standard

A symmetric 128-bit block data encryption algorithm.

AGG Node Aggregation Node

AIS Alarm Indication Signal

ALP-148 cabinet An Alcatel-Lucent Low Profile single 48-inch remote terminal cabinet

ALP-248 cabinet An Alcatel-Lucent Low Profile dual 48-inch remote terminal cabinet

ALP-448P An Alcatel-Lucent Low Profile quadruple 48-inch remote terminal cabinet

AMP Champ A common name for a 25-pair connector used on the 7330 ISAM FTTN to connect POTS CO lines and subscriber drop lines.

Glossary


AMSL Above Mean Sea Level

ANCP Access Node Control Protocol

ANSI American National Standards Institute

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

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.

AS Autonomous System

ASCII American Standard Code for Information Interchange

A coding method used to convert letters, numbers, punctuation, and control codes into digital form.

ASP Access Service Provider

ATI Alarms, Test Access, and Interfaces

ATM Asynchronous Transfer Mode

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

ATP Aggregate Transmit Power

ATU-C ADSL Transceiver Unit – Central Office

ATU-R ADSL Transceiver Unit – Remote

AWG American Wire Gauge

A standard measuring gauge for non-ferrous conductors.

B

BAC Buffer Acceptance Control

BE Best Effort

Glossary


BER Bit Error Rate

A 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 clock that supplies a composite clock timing reference to all other clocks in a building over BITS clock cables.

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 locking connector for slim coaxial cables, such as those used for Ethernet.

BNG Broadband Network Gateway

BOOTP Bootstrap Protocol

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

An ISDN interface consisting of two 64 kb/s B-channels and one 16 kb/s D-channel for a total of 144 kb/s.

C

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

CDC Carrier Data Collection

Glossary


CDE Customer Dependant Engineering

The CDE file on a card contains country-specific information.

CEV Controlled Environmental Vault

A temperature- and humidity-controlled underground vault that houses the 7330 ISAM FTTN system at a remote location.

CFM Cubic Feet per Minute

or

Connectivity Fault Management

CFM is an Ethernet OAM capability for testing network connectivity at Layer 2. CFM allows service providers or network operators to verify and isolate link and node faults on a bridged network. CFM is specified in the standard IEEE 802.1ag.

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

A 10-character code used to identify telecommunications equipment. The 10-character structure, outlined in the Telcordia specification, specifies the basic product type, features, source document, and associated drawings and versions. A CLEI code is unique to a specific piece of equipment.

CLI Command Line Interface

A workstation access method interface that uses CLI commands to communicate to any network element in the 7330 ISAM FTTN network.

CMOS Complementary Metal Oxide Semiconductor

CMP Communications Plenum Cable

CO Central Office

A telephone switching center that connects subscribers within a telephone network.

CODEC Coder decoder

COLO Collocation

CPCS Common Part Convergence Sublayer

The portion of the convergence sublayer of an AAL that remains the same regardless of traffic.

Glossary


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

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.

Craft terminal A workstation that has element management system software installed on it. The workstation can be an ASCII terminal or a PC or laptop computer equipped with terminal emulator software. The craft terminal typically uses CLI or TL1 for managing network elements, either remotely over a network connection or locally over a local connection.

CT See Craft terminal

C-VLAN Customer VLAN

CWDM Coarse Wavelength Division Multiplexing

D

DA Destination Address

DB-9 A 9-pin D-shell connector used for the craft port on the 7330 ISAM FTTN.

DBPO Downstream Power Back-Off

DELT Dual Ended Line Testing

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

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

DMT Discrete Multitone

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 modem technology that enables high-speed 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.

DSLAM Digital Subscriber Line Access Multiplexer

A network device that converts xDSL signals into ATM traffic. For a service management application, if the service user is connected to the ATM network through a DSLAM port, the network access is provisioned using a DSLAM attachment type.

DSP Digital Service Provider

E

EAR Ethernet Access Router

EAPOL Extensible Authentication Protocol Over LAN

ECI Equipment Catalog Item

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

Glossary


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. For EIA-spaced equipment racks, 1 RU equals 1.75 in. (4.45 cm).

EMAN Ethernet Metropolitan Area Network

EMC Electromagnetic Compatibility

EMI Electromagnetic Immunity

EMS Element Management System

A system that manages the components of a network.

EOC Embedded Operations Channel

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.

ES Expansion Shelf

An expansion shelf using the same shelf as the 7330 ISAM FTTN host shelf (ARAM-D shelf), but with some different units installed to provide additional subscriber line connections for the host shelf.

ESD Electrostatic Discharge

Ethernet A data link layer protocol for interconnecting computer equipment into CSMA/CD LANs, jointly developed by Xerox, Digital Equipment Corporation, and Intel. This standard forms the basis for IEEE 802.3.

The Ethernet protocol specifies how data is placed on, and retrieved from, a common transmission medium. It is used as the underlying transport vehicle by several upper-level protocols, including TCP/IP and UDP/IP.

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.

Glossary


F

FDD Frequency Division Duplexing

FDM Frequency Division Multiplexing

A form of multiplexing in which several independent signals are allocated separate frequency bands for transmission over a common channel.

FE Fast Ethernet

FEC Forward Error Correction

FEMF Foreign Electro-Motive Force

FENT Fast Ethernet Network Termination

FEXT Far-end XTalk (crosstalk)

FIB Forwarding Information Base

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

FTTN Fiber to the node

See 7330 ISAM FTTN.

G

GE Gigabit Ethernet

Ethernet interface running at 1000 Mb/s.

GFC General Facilities Card

GUI Graphical User Interface

A user screen that includes menus, tables, or icons to query or change data; usually distinguished from a command line interface.

H

HSI High Speed Internet

Glossary


I

IACM Intelligent Access Termination, Control and Management

iBridge Intelligent Bridging mode, also known as residential bridging mode

ICMP Internet Control Message Protocol

ICS Item Change Status

A code that identifies the change status of an Alcatel-Lucent unit or component.

IDEA International Data Encryption Algorithm

A symmetric-key encryption method that uses a 128-bit key and the block cipher method, which breaks text into 64-bit blocks and then encrypts them.

IEEE Institute of Electrical and Electronics Engineers

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

An 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

A protocol used between hosts and multicast routers on a single physical network to establish hosts’ membership in particular multicast groups. Version 2 of IGMP is described in RFC 2236.

IGS IGMP System on the SHub

IMA Inverse Multiplexing for ATM

INP Impulse Noise Protection

INP provides forward error correction techniques to protect user traffic from excessive noise, which can result in data loss.

IP Internet Protocol

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

Glossary


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

See 7302 ISAM or 7330 ISAM FTTN.

ISDN Integrated Services Digital Network

ISP Internet Service Provider

ITSC Integrated Test and Sealing Current

A feature that includes narrowband line testing functionality as well as sealing current for subscriber lines connected to the equipment.

ITU International Telecommunications Union

A standards organization that develops international telecommunications recommendations.

IXL Index List

J

JFET Junction Field Effect Transistor

L

L2 Layer 2

L3 Layer 3

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.

LAG Link Aggregation Group

A LAG increases the bandwidth available between two network elements by grouping ports into one logical link. The aggregation of multiple physical links allows for load sharing and offers seamless redundancy. If one of the links fails, traffic is redistributed over the remaining links.

Glossary


LAN Local Area Network

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

LC Lucent Connector

A small optical fiber connector.

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

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

A message of the OSPF routing protocol that informs about network topology changes.

LSDB Link State Database

A database 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


M

MA Maintenance Association

MAC Media Access Control

The IEEE sublayer in a LAN that controls access to the shared medium by LAN attached devices.

MAIP Maintenance Access Interface Port

or

Multipurpose Alarm Interface Panel

A panel, located in the electronics compartment of a 52-type cabinet that provides fused dc power to the 7330 ISAM FTTN shelf and cabinet fans, as well as cabinet and power alarm outputs.

MAU Media Attachment Unit

MD Maintenance Domain

MD5 Message Digest algorithm 5

A security algorithm that takes an input message of arbitrary length and produces as an output a 128-bit message digest of the input. MD5 is intended for digital signature applications, where a large file must be compressed securely before being encrypted.

MDF Main Distribution Frame

MDI Medium-Dependent Interface

A type of Ethernet port for use with twisted-pair wiring.

MDIX Medium-Dependent Interface Crossover

The crossover version of MDI that 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.

ME Maintenance Entity

Megaco Media Gateway Controller

MEP Maintenance Endpoint

MEPID Maintenance Endpoint Identifier

MHF MIP Half Function

MIB Management Information Base

MIP Maintenance Intermediate Point

Glossary


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

MP Maintenance Point

M-pair Multi-pair

MSTP Multiple Spanning Tree Protocol

An extension of RSTP that allows different spanning trees to co-exist on the same Ethernet switched network.

MTA Metallic Test Access

MTAU Metallic Test Access Unit

MTBF Mean Time Between Failures

Multi-ADSL A general term that refers to more than one type of ADSL (for example, ADSL, ADSL2, and READSL).

N

NACP Network Access Control Protocol

NAT Network Address Translation

NE Network Element

NEBS Network Equipment Building Standards

Performance, quality, environmental, and safety standards set by Telcordia for telecommunications equipment.

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.

NNI Network to Network Interface

NSA Non-Service Affecting

NSP Network Service Provider

NT Network Termination

A plug-in unit that provides a link to a broadband network, such as ATM or IP. The 7330 ISAM FTTN uses the ECNT-A or ECNT-C card for network termination.

Glossary


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

NTR Network Timing Reference

O

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

OLR OnLine Reconfiguration

ONC Open Network Computing

OOS Out-of-service

The status of a primary rate link when it is out of service.

OS Operations System

A standalone software system that supports network-related operations functions.

OSP Outside Plant

OSPF Open Shortest Path First

A 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

P

PADI PPPoE Active Discovery Initiation

PBO Power Back-Off

Glossary


PC Personal computer

A PC can be used as a craft terminal.

PDF Power Distribution Frame

PDU Protocol Data Unit

PM Performance Monitoring

POTS Plain Old Telephone Service

A term for narrowband, voice-only telephone service.

PPP Point-to-Point Protocol

A protocol that allows a computer to use TCP/IP with a standard telephone line and a high-speed modem to establish a link between two terminal installations.

PPPoA Point-to-Point Protocol over ATM

PPPoE Point-to-Point Protocol over Ethernet

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

A telephone network based on normal telephone signaling and ordinary switched long distance telephone circuits.

PTC Positive Temperature Coefficient

A type of thermal resistor used for current limiting in circuitry.

PSU Power Supply Unit

PTM Packet Transfer Mode

A DSL framing mode that allows DSL equipment to transport packet-based (for example, Ethernet or IP packets) rather than ATM-based data. PTM involves 64/65 byte block coding of variable size frames or frame fragments at the transmission convergence sublayer in the modem. PTM is defined in the G.992.3 (ADSL2) and G.992.5 (ADSL2+) standards.

PVC Permanent Virtual Connection

PVID Port VLAN Identifier

Glossary


Q

QoS Quality of Service

A measure of the quality of a data communications link provided to a subscriber.

R

RADIUS Remote Authentication Dial-in User Service

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

RAL Restricted Access Location

RAM Remote Access Multiplexer

RARP Reverse Address Resolution Protocol

RB VLAN Residential Bridging VLAN

RDI Remote Defect Indication

READSL2 Reach Extended ADSL2

RED Random Early Detection

REN Ringer Equivalence Number

RFC Request for Comments

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.

RFT Remote Feeding Telecommunication

RG Residential Gateway

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 A single-line jack for digital transmission over ordinary phone wire, either untwisted or twisted. It is the interface for Ethernet standards 10Base-T and 100Base-T.

Glossary


RMI Remote Management Interface

RNM Residential Network Manager

rpm revolutions per minute

RS Reed-Solomon

RSTP Rapid Spanning Tree Protocol

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

RT Remote Terminal

RTL Routine Task List

RTP Real-time Transport Protocol

RTU Remote Test Unit

RU Rack Unit

A unit of vertical space in a standard 19 inch or 23 inch equipment rack. For EIA-spaced racks, 1 RU equals 1.75 in. (4.45 cm). For WECO-spaced racks, 1 RU equals 2 in. (5.08 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.

S

SA Service Affecting

or

Source Address

SAI Service Area Interface

SAP Service Access Point

SC Standard Connector

A small optical fiber connector.

SDU Service Data Unit

A unit of information from an upper-layer protocol that defines a service request to a lower-layer protocol.

Glossary


SELT Single-Ended Line Testing

SELV Safety Extra Low Voltage

SEM Sealed Expansion Module

A remote expansion unit for the 7330 ISAM FTTN. The SEM is a single LT unit in a flood resistant, environmentally hardened enclosure designed for remote outside deployment in hard-to-reach or low-density locations.

SFP Small Form-factor Pluggable

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

SHDSL Symmetric High-speed Digital Subscriber Line

SHub Service Hub

7330 ISAM FTTN and 7302 ISAM Network Termination card Ethernet switch (also known as LANX).

SI Système international d’unités

SIP Session Initiation Protocol

SLIC Subscriber Line Interface Circuit

SMF Single Mode Fiber

An optical fiber with a core diameter of less than 10 μm that is used for high-bandwidth transmission over long distances.

SNMP Simple Network Management Protocol

A protocol used by network management to retrieve information about connection status, configuration, and performance.

SNR Signal-to-Noise Ratio

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

A transmission network that uses high-speed optical carriers.

SRA Seamless Rate Adaptation

SSCS Service-specific convergence sublayer

SSH Secure Shell

SSM Source-specific multicast

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.

STU-C SHDSL Transceiver Unit – Central Office

STU-R SHDSL Transceiver Unit – Remote

S-VLAN Stacked VLAN

SWDB SoftWare DataBase

SWP SoftWare Package

T

TAC Test Access Control

TAP Test Access Port

or

Trouble Analysis Procedure

TAU Test Access Unit

TBC Time base correction

TCA Threshold Crossing Alarm

TCP Transmission Control Protocol

A protocol for establishing a duplex connection between end systems for the reliable delivery of data.

TCPAM Trellis Coded Pulse Amplitude Modulation

TCP/IP Transmission Control Protocol/Internet Protocol

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.

Glossary


TNG Training Document

TNV Telecom Network Voltage

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.

TRU Top Rack Unit

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.

U

UA User Agent

UDP/IP User Datagram Protocol/Internet Protocol

A transport layer, connectionless mode protocol, providing a datagram mode of communication for delivery to a remote or local user. UDP is part of the TCP/IP suite.

UDS Unit Data Sheet

UPBO Upstream Power Back-Off

UPS Uninterruptible Power Supply

URI Universal Resource Identifier

USM User-based Security Model

V

VACM View-based Access Control Model

VBAS Virtual Broadcast Access Server

VC Virtual Channel

A single communications connection identified by an office equipment number, VPI, and VCI.

VCC Virtual Channel Connection

VCI Virtual Channel Identifier

An identifier in an ATM cell that distinguishes the data of one VC from the data of another VC.

Glossary


VCL Virtual Channel Link

VC/VP/VR Virtual Channel/Virtual Path/Virtual Router

VDSL Very High Bit Rate DSL

A variant of DSL that provides 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.

VID VLAN Identifier

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 Video on Demand

VoIP Voice over IP

VP Virtual Path

A single communications connection identified by an office equipment number and a VPI.

VPI Virtual Path Identifier

An identifier in an ATM cell that distinguishes the data of one VP from the data of another VP.

VP/VC Virtual Path/Virtual Channel

VRF Virtual Routing Forwarder

A logical or virtual routing function with associated routing table that can be instantiated in a router capable of supporting IP VPN services.

VTU-C VDSL Transceiver Unit – Remote

VTU-R VDSL Transceiver Unit – Central Office

W

WAN Wide Area Network

WECO Western Electric Company

For WECO-spaced racks, 1 RU equals 2 in. (5.08 cm).

WFQ Weighted Fair Queue

WRED Weighted Random Early Detection

WRR Weighted Round Robin

Glossary


X

xDSL A general term that is used to refer to more than one type of DSL (for example, ADSL, ADSL2, READSL, SHDSL, VDSL, VDSL2).

xTU-C xDSL Transceiver Unit – Central Office

xTU-R xDSL Transceiver Unit – Remote

XFP 10 Gigabit Small Form Factor Pluggable

An XFP optical module is a hot-swappable, protocol-independent optical transceiver, typically operating at 850nm, 1310nm or 1550nm, for 10 Gb/s SONET/SDH, Fiber Channel, Gigabit Ethernet, 10 Gigabit Ethernet and other applications. XFP was developed by the XFP Multi Source Agreement Group.

XoA encapsulation A general term used to refer to an unspecified type of encapsulation over ATM.

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 IN-13HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

Index

Numbers

802.1xsupport, 10-10

A

Access node control protocolabout, 4-26

ADSLabout, 2-4

ADSL1about, 2-4

ADSL2about, 2-5, 2-5

ADSL2+about, 2-7, 2-7

alarm filterslogging filters, 4-20programmable filters, 4-20reporting filters, 4-20

alarm LEDs, 4-18alarm management, 4-17

alarm delta logging, 4-19alarm filters, 4-20alarm identification, 4-18alarm lists, 4-19alarm logging, 4-19alarm severity, 4-18

alarm types, 4-18critical alarm LED, 4-18current alarm list, 4-19derived alarms, 4-18, 4-20disable alarms, 4-19enable alarms, 4-19major alarm LED, 4-18minor alarm LED, 4-18NSE alarms, 4-18programmable alarm configuration, 4-22programmable alarm filters, 4-20SE alarms, 4-18snapshot alarm list, 4-19spatial alarm filters, 4-20, 4-20temporal alarm filters, 4-20, 4-20view alarms, 4-19

ARPlayer 2, 10-11layer 3, 12-3

Artificial noiseabout, 7-11

B

Bonding, 2-3about, 2-3ATM, 2-13ATM bonding, 2-13

Index

IN-2 November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

EFM, 2-13PTM bonding, 2-13

C

C-VLAN cross-connect, 9-31Configuration overrule

about, 7-13current alarm list, 4-19

D

DELTabout, 5-8

derived alarms, 4-18, 4-20DHCP

layer 2, 10-13layer 3, 12-4

DPBO, 7-8

E

EFMOAMgeneral description, 5-10

Ethernetabout, 2-11, 2-11

ethernetauto-negotiation, 2-11modes, 2-11

I

iBridge, 9-16iBridge mode features, 9-16IEEE 802.1q tagging, 9-2IGMP

forwarding models, 13-13Impulse noise sensor

about, 7-10IPoA cross-connect, 9-44ISAM Voice

call handlingMEGACO, 8-123SIP, 8-125

forwardingLayer 4, 8-23MEGACO, 8-24SIP, 8-36, 8-40

L2/L3 addressingMEGACO, 8-44, 8-53SIP, 8-63, 8-68

managementgeneral, 8-86MEGACO, 8-88SIP, 8-91

market applicability, 8-11MEGACO

network topology, 8-3product applicability, 8-11protocol stacks

MEGACO, 8-77SIP, 8-82

SIPnetwork topology, 8-5

supplementary services, 8-132traffic types

MEGACO, 8-16SIP, 8-16

L

LACPabout, 10-3

layer 2protocol handling, 10-2user access interface, 9-13

layer 2 forwardingIPoA cross-connect, 9-44

layer 2 forwarding modeiBridge, 9-16VLAN cross-connect, 9-29

layer 3forwarding, 11-2protocol handling, 12-2

Line InstabilityTest features, 5-12

Link transmission technology, 2-2logging alarms, 4-19

Bonding (continued) — logging alarms

Index

Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2 November 2010 IN-33HH-08871-AAAA-TQZZA Edition 01 Released System Description for FD 24Gbps NT

Low power modesL2 low-power mode, 7-4L3 idle power mode, 7-4

low power modesabout, 7-4

M

MSTPabout, 10-6

MTAin 7302 ISAM, 5-6in 7330 ISAM FTTN, 5-6TAC, 5-7test access modes, 5-5

multi-ADSLADSL, 2-4ADSL2, 2-5ADSL2+, 2-7READSL2, 2-7SELT, 5-7, 5-8

multi-VLAN, 9-5multicast

forwarding models, 13-13

N

non-service affecting alarms, 4-18NT redundancy

about, 3-2link only protection, 3-5

O

Operational modesADSL1, 2-5ADSL2, 2-6ADSL2+, 2-7READSL, 2-7

P

performance statistics, 4-17PPPoE

about, 10-19PPPoE relay, 10-19

programmable alarm filters, 4-20configuration, 4-22spatial alarm filters, 4-20temporal alarm filters, 4-20

protocol aware cross-connect, 9-40Protocol Tracing

about, 5-14PSD shaping

about, 7-8

Q

QoSabout, 14-2downstream, 14-8policy framework, 14-20profiles, 14-15traffic classes, 14-10

QoS profilesCAC profile, 14-16marker profile, 14-18policer profile, 14-19queue profile, 14-16session profile, 14-18

R

RADIUSabout, 6-2, 15-2authentication, 15-2encryption, 15-3features, 15-2proxy, 15-2server, 15-2

READSLabout, 2-7

READSL2about, 2-7

RSTPabout, 10-6in 7302 ISAM, 10-6

S

S-VLAN cross-connect, 9-34S-VLAN/C-VLAN cross-connect, 9-32

Low power modes — S-VLAN/C-VLAN cross-connect

Index

IN-4 November 2010 Alcatel-Lucent 7302 ISAM R4.2 | 7330 ISAM FTTN | 7356 ISAM FTTB R4.2System Description for FD 24Gbps NT Edition 01 Released 3HH-08871-AAAA-TQZZA

Seamless rate adaptationmodes, 7-6

SELTabout, 5-7multi-ADSL, 5-7, 5-8VDSL, 5-8, 5-8

service affecting alarms, 4-18SHDSL

about, 2-10, 2-10, 2-10supported standards, 2-10

snapshot alarm list, 4-19SRA

about, 7-6statistics

performance statistics, 4-17system logs

configuring, 4-10filters, 4-10message types, 4-10monitoring, 4-11severity level, 4-10

T

TestLine Instability, 5-12

Transfer modes, 2-3

U

UPBOequal FEXT, 7-8policing, 7-8

user access interfacelayer 2, 9-13

V

VDSLabout, 2-8SELT, 5-8, 5-8

VDSL1about, 2-8, 2-8

VDSL2about, 2-8, 2-8operational modes, 2-9

profile overview, 2-9profiles, 2-9

Virtual noiseabout, 7-10

VLAN cross-connect, 9-29C-VLAN cross-connect, 9-31protocol aware cross-connect, 9-40S-VLAN cross-connect, 9-34S-VLAN/C-VLAN cross-connect, 9-32VLAN stacking, 9-30

VLAN forwarding, 9-2VLAN frame

frame type usage, 9-4multi-VLAN, 9-5tagging, 9-2VLAN translation, 9-5

VLAN translation, 9-5

X

xDSLINP, 7-3

Seamless rate adaptation — xDSL

Customer documentation and product support

Customer documentationhttp://www.alcatel-lucent.com/myaccessProduct manuals and documentation updates are available at alcatel-lucent.com. If you are a new user and require access to this service, please contact your Alcatel-Lucent sales representative.

Technical Supporthttp://www.alcatel-lucent.com/support

Documentation [email protected]

http://www.alcatel-lucent.com/myaccess

http://www.alcatel-lucent.com/support

mailto:[email protected]

ISAM R4.2-System Description for 24Gbps NT

Documents

Transcript of ISAM R4.2-System Description for 24Gbps NT