Alcatel-Lucent 7302
INTELLIGENT SERVICES ACCESS MANAGER
Alcatel-Lucent 7330
INTELLIGENT SERVICES ACCESS MANAGER FIBER TO THE NODE
Alcatel-Lucent 7360
INTELLIGENT SERVICES ACCESS MANAGER FX SYSTEM DESCRIPTION FOR FD 100/320GBPS NT AND FX NT RELEASE 4.6.02
3H H - 11651- BAAA- T QZZA Edition 03 Released
Alcatel-Lucent Proprietary This document contains proprietary information of Alcatel-Lucent and is not to be disclosed or used except in accordance with applicable agreements. Copyright 2013 © Alcatel-Lucent. All rights reserved.
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 2013 Alcatel-Lucent. All rights reserved. Disclaimers
Alcatel-Lucent products are intended for commercial uses. Without the appropriate network design engineering, they must not be sold, licensed or otherwise distributed for use in any hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life-support machines, or weapons systems, in which the failure of products could lead directly to death, personal injury, or severe physical or environmental damage. The customer hereby agrees that the use, sale, license or other distribution of the products for any such application without the prior written consent of Alcatel-Lucent, shall be at the customer's sole risk. The customer hereby agrees to defend and hold Alcatel-Lucent harmless from any claims for loss, cost, damage, expense or liability that may arise out of or in connection with the use, sale, license or other distribution of the products in such applications. This document may contain information regarding the use and installation of non-Alcatel-Lucent products. Please note that this information is provided as a courtesy to assist you. While Alcatel-Lucent tries to ensure that this information accurately reflects information provided by the supplier, please refer to the materials provided with any non-Alcatel-Lucent product and contact the supplier for confirmation. Alcatel-Lucent assumes no responsibility or liability for incorrect or incomplete information provided about non-Alcatel-Lucent products. However, this does not constitute a representation or warranty. The warranties provided for Alcatel-Lucent products, if any, are set forth in contractual documentation entered into by Alcatel-Lucent and its customers. This document was originally written in English. If there is any conflict or inconsistency between the English version and any other version of a document, the English version shall prevail.
When printed by Alcatel-Lucent, this document is printed on recycled paper.
Preface
This preface provides general information about the documentation set for the 7302 Intelligent Services Access Manager (7302 ISAM), the 7330 Intelligent Services Access Manager Fiber to the Node (7330 ISAM FTTN) and the 7360 ISAM FX.
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 7360 ISAM FX.
Required knowledge The reader must be familiar with general telecommunications principles.
Acronyms and initialisms The expansions and optional descriptions of most acronyms and initialisms appear in the glossary, which is included in the System Description document.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
iii
Preface
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. 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, both the 7302 ISAM, the 7330 ISAM FTTN and the 7360 ISAM FX 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. 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.
iv
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Preface
Procedures with options or substeps When there are options in a procedure, they are identified by letters. When there are required substeps in a procedure, they are identified by roman numerals.
Procedure 1 Example of options in a procedure At step 1, you can choose option a or b. At step 2, you must do what the step indicates. 1
2
This step offers two options. You must choose one of the following: a
This is one option.
b
This is another option.
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
2
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.
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
v
Preface
vi
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Contents
Preface
iii
Scope ................................................................................................................... iii Audience ................................................................................................................... iii Required knowledge..................................................................................................... iii Acronyms and initialisms............................................................................................... iii Assistance and ordering phone numbers ........................................................................ iv Safety information........................................................................................................ iv Documents .................................................................................................................. iv Product Naming ........................................................................................................... iv Special information....................................................................................................... iv Release notes ............................................................................................................... v
1—
Introduction 1.1 1.2 1.3 1.4
2—
1-1
General...................................................................................................... 1-2 Supported User Interfaces........................................................................... 1-2 Integrated DSL, Voice, Point-to-point Ethernet, GPON, EPON, 10G EPON and DPoE system ............................................................................... 1-4 Document Structure.................................................................................... 1-4
System interface overview 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9
2-1
General...................................................................................................... 2-3 Overview ................................................................................................... 2-3 Multi-ADSL ................................................................................................. 2-5 VDSL ......................................................................................................... 2-9 SHDSL ..................................................................................................... 2-11 Ethernet................................................................................................... 2-13 GPON ...................................................................................................... 2-15 EPON....................................................................................................... 2-16 10G EPON ................................................................................................ 2-19
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
vii
Contents
2.10 2.11 2.12 2.13 2.14 2.15 2.16
3—
Failure protection and redundancy provisions in ISAM 3.1 3.2 3.3 3.4 3.5
4—
6—
Overview ................................................................................................... 4-2 Management interfaces ............................................................................... 4-3 Management interfaces security................................................................. 4-13 Management access models ...................................................................... 4-15 Counters and statistics .............................................................................. 4-18 Alarm management .................................................................................. 4-19 Software and database management ......................................................... 4-26 Equipment monitoring............................................................................... 4-30 Access node control protocol ..................................................................... 4-31
5-1
Overview ................................................................................................... 5-2 Metallic test access ..................................................................................... 5-4 Single-Ended Line Testing ........................................................................... 5-7 Dual-ended line testing ............................................................................... 5-8 Metallic-Ended Line Testing ......................................................................... 5-9 ATM F5 .................................................................................................... 5-11 Link Related Ethernet OAM........................................................................ 5-12 Narrowband Line Testing .......................................................................... 5-14 SFP diagnostics ........................................................................................ 5-17 Embedded OTDR ...................................................................................... 5-18
Network timing reference support in ISAM 6.1 6.2 6.3 6.4
viii
4-1
Line testing features 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10
3-1
Overview ................................................................................................... 3-2 ISAM single shelf configurations .................................................................. 3-5 ISAM subtending system protection ........................................................... 3-11 Failure protection at layer 3....................................................................... 3-13 Subscriber interface redundancy ................................................................ 3-14
Management 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9
5—
DPoE ....................................................................................................... 2-23 Inverse multiplexing for ATM ..................................................................... 2-24 ATM/PTM bonding .................................................................................... 2-24 Overview of ISAM Voice interfaces ............................................................. 2-25 E1 TDM Interface ..................................................................................... 2-26 Overview of ONU Based UNI and Service Interfaces .................................... 2-26 Overview of ISAM support for remote management of third-party equipment. ...................................................................................... 2-28
6-1
Introduction ............................................................................................... 6-2 ISAM clock system and NTR extraction......................................................... 6-6 Downstream NTR clock distribution............................................................ 6-16 Applicable standards ................................................................................. 6-17
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Contents
7—
xDSL features 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14
8—
Overview ................................................................................................... 7-2 Configurable impulse noise protection .......................................................... 7-3 RFI Notching .............................................................................................. 7-4 Low-power modes ...................................................................................... 7-4 Seamless rate adaptation ............................................................................ 7-6 Upstream power back-off ............................................................................ 7-7 Downstream power back-off........................................................................ 7-9 Impulse noise monitor .............................................................................. 7-10 Virtual noise ............................................................................................. 7-10 Physical Layer Retransmission (RTX) .......................................................... 7-12 Per-line configuration overrule ................................................................... 7-13 Configurable US/ DS memory split ............................................................. 7-14 Vectoring ................................................................................................. 7-14 Fall-back configuration for vectoring .......................................................... 7-17
GPON Network Architecture 8.1 8.2 8.3 8.4 8.5 8.6
9—
7-1
8-1
Introduction: GPON Network ....................................................................... 8-2 Alcatel-Lucent GPON Network Architecture ................................................... 8-2 GPON Implementation of ISAM .................................................................... 8-3 V-OLT GPON Functions ............................................................................. 8-12 Protection ................................................................................................ 8-12 ONU Functions ......................................................................................... 8-12
ISAM Support for the GPON ONU 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10
9-1
Introduction ............................................................................................... 9-2 ONU Product Identification .......................................................................... 9-5 Ethernet features........................................................................................ 9-7 xDSL features............................................................................................. 9-7 Wi-Fi.......................................................................................................... 9-7 DS1/E1 Features......................................................................................... 9-7 Video Overlay........................................................................................... 9-10 Home Phoneline Network (HPNA) .............................................................. 9-11 Power over Ethernet ................................................................................. 9-12 Ethernet loopback detection ...................................................................... 9-12
10 — EPON Network Architecture 10.1 10.2 10.3 10.4
10-1
Overview ................................................................................................. 10-2 EPON network .......................................................................................... 10-2 EPON implementation of ISAM................................................................... 10-9 EPON system capacity............................................................................. 10-29
11 — ISAM Support for the EPON ONU 11.1 11.2 11.3 11.4
11-1
Overview ................................................................................................. 11-2 EPON ONU ............................................................................................... 11-2 Supported features and services ................................................................ 11-5 Security ................................................................................................... 11-8
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
ix
Contents
12 — ISAM Voice Network Architecture 12.1 12.2 12.3 12.4 12.5 12.6 12.7 12.8 12.9 12.10 12.11 12.12 12.13 12.14 12.15 12.16 12.17 12.18 12.19 12.20
Introduction ............................................................................................. 12-3 Overall network topology .......................................................................... 12-3 Access network L2/L3 topologies ............................................................... 12-8 Product Definition and Dimensioning ........................................................ 12-13 Traffic types and forwarding.................................................................... 12-14 Layer 2/layer 3 addressing topologies ...................................................... 12-44 Protocol stacks ....................................................................................... 12-75 Voice service and MPLS Pseudo-wire ........................................................ 12-84 Management interface ............................................................................ 12-84 Permanent data storage .......................................................................... 12-87 Management model ................................................................................ 12-88 Reliability, Equipment / Connectivity / Overload Protection ........................ 12-96 Quality of Service ..................................................................................12-110 DNS interworking ..................................................................................12-110 BITS Support.........................................................................................12-112 Narrowband Line Testing .......................................................................12-112 Termination local loop unbundling ..........................................................12-112 Alarm Treatment ...................................................................................12-113 Lawful Intercept ....................................................................................12-115 ISAM Voice migration.............................................................................12-120
13 — DPoE Network Architecture 13.1 13.2 13.3 13.4
x
14-1
Introduction ............................................................................................. 14-2 Coverage ................................................................................................. 14-2 MEGACO Feature Portfolio ......................................................................... 14-3 SIP Feature Portfolio ................................................................................. 14-9 Validating Origin of SIP request ............................................................... 14-28 Voice Service related defined alarms ........................................................ 14-29 Compliancy to standards ......................................................................... 14-31
15 — Layer 2 forwarding 15.1 15.2 15.3 15.4 15.5 15.6 15.7 15.8 15.9 15.10
13-1
Introduction ............................................................................................. 13-2 Overview ................................................................................................. 13-2 Alcatel-Lucent DPoE network architecture................................................... 13-3 DPoE implementation of ISAM ................................................................... 13-6
14 — Integrated Narrowband Support 14.1 14.2 14.3 14.4 14.5 14.6 14.7
12-1
15-1
Introduction ............................................................................................. 15-2 The concept of Virtual LAN (VLAN)............................................................. 15-2 The ISAM is an Access Device.................................................................... 15-4 ISAM Internal Architecture ...................................................................... 15-17 Subscriber interface stack on the LT board ............................................... 15-26 iBridges ................................................................................................. 15-29 VLAN cross-connect mode ....................................................................... 15-49 Protocol-aware cross-connect mode ......................................................... 15-56 IPoA cross-connect mode ........................................................................ 15-61 Secure forwarding in iBridge and VLAN cross-connect ............................... 15-63
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Contents
15.11 15.12
Virtual MAC ............................................................................................ 15-67 PPP cross-connect mode ......................................................................... 15-74
16 — Protocol handling in a Layer 2 forwarding model 16.1 16.2 16.3 16.4 16.5 16.6 16.7 16.8 16.9 16.10 16.11 16.12 16.13
Introduction ............................................................................................. 16-2 Link aggregation....................................................................................... 16-3 RSTP and MSTP........................................................................................ 16-8 Connectivity Fault Management ............................................................... 16-13 802.1x support ....................................................................................... 16-17 BCMP..................................................................................................... 16-18 ARP ....................................................................................................... 16-19 DHCP..................................................................................................... 16-20 IGMP ..................................................................................................... 16-26 PPPoE.................................................................................................... 16-26 DHCPv6 ................................................................................................. 16-31 ICMPv6 .................................................................................................. 16-33 LLDP...................................................................................................... 16-33
17 — IP routing 17.1 17.2 17.3 17.4
17-1
Introduction ............................................................................................. 17-2 IP routing features.................................................................................... 17-2 IP routing model....................................................................................... 17-6 Routing in case of subtended ISAMs ........................................................ 17-10
18 — Protocol handling in a Layer 3 forwarding model 18.1 18.2 18.3 18.4 18.5 18.6 18.7 18.8 18.9 18.10
19-1
Overview ................................................................................................. 19-2 Advanced capabilities................................................................................ 19-5 System decomposition ............................................................................ 19-15 Multicast and forwarding models.............................................................. 19-19
20 — Quality of Service 20.1 20.2 20.3
18-1
Introduction ............................................................................................. 18-2 IPv4 Routing Protocols .............................................................................. 18-2 ARP ......................................................................................................... 18-2 DHCP relay agent ..................................................................................... 18-3 DHCP snooping ........................................................................................ 18-5 IPv6 routing protocols............................................................................... 18-6 Neighbour Discovery (ICMPv6) .................................................................. 18-7 DHCPv6 Relay Agent................................................................................. 18-7 DHCPv6 Snooping..................................................................................... 18-8 Bidirectional Forwarding Detection ............................................................. 18-9
19 — Multicast and IGMP 19.1 19.2 19.3 19.4
16-1
20-1
Introduction ............................................................................................. 20-2 Upstream QoS handling ............................................................................ 20-2 Downstream QoS.................................................................................... 20-13
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
xi
Contents
20.4 20.5
Hardware mapping of QoS functions ........................................................ 20-15 Configuration of QoS............................................................................... 20-31
21 — Resource management and authentication 21.1 21.2 21.3 21.4 21.5 21.6
Introduction ............................................................................................. 21-2 RADIUS features....................................................................................... 21-2 802.1x authentication via RADIUS.............................................................. 21-2 Operator authentication via RADIUS........................................................... 21-3 Encryption of authentication data............................................................... 21-3 Lawful Interception................................................................................... 21-3
22 — MPLS 22.1 22.2 22.3 22.4 22.5 22.6 22.7 22.8 22.9 22.10 22.11
22-1 Introduction ............................................................................................. 22-2 Label Switched Path.................................................................................. 22-2 Label Distribution Protocol......................................................................... 22-3 Resource Reservation Protocol................................................................... 22-5 Pseudo-wires and T-LDP ........................................................................... 22-6 L2 VPN services ........................................................................................ 22-7 QoS ......................................................................................................... 22-9 Redundancy and resilience ........................................................................ 22-9 Support for MPLS rings ........................................................................... 22-10 Support for MPLS flow label..................................................................... 22-11 Supporting integrated voice services over MPLS ........................................ 22-12
23 — ATM Pseudowire emulation 23.1 23.2 23.3 23.4 23.5 23.6
A.
xii
24-1
Introduction ............................................................................................. 24-2 Solution description .................................................................................. 24-2 Benefits ................................................................................................... 24-4 Support in ISAM ....................................................................................... 24-4
Cross-domain solutions A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8
23-1
Introduction ............................................................................................. 23-2 Solution description .................................................................................. 23-2 Cell concatenation .................................................................................... 23-3 QoS ......................................................................................................... 23-4 Known restrictions .................................................................................... 23-4 Support on the ISAM ................................................................................ 23-4
24 — Application Intelligence Platform 24.1 24.2 24.3 24.4
21-1
A-1
Overview ...................................................................................................A-2 Mobile backhaul..........................................................................................A-3 E1/T1 Leased Line Replacement (SHDSL/PON) ........................................... A-11 E1/PRA Interfaces on ISAM ....................................................................... A-15 Ethernet Business Access over ISAM .......................................................... A-21 ISAM Backhaul (Rural DSL, Ultra-high Broadband) ...................................... A-27 Hospitality solution ................................................................................... A-33 Open Community Broadband for Smart Communities .................................. A-39 November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Contents
B.
RADIUS Attributes B.1 B.2
B-1
RADIUS Attributes ......................................................................................B-2 Vendor specific RADIUS attributes ...............................................................B-2
Glossary
Index
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
xiii
Contents
xiv
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
1 — Introduction
1.1 General
1-2
1.2 Supported User Interfaces
1-2
1.3 Integrated DSL, Voice, Point-to-point Ethernet, GPON, EPON, 10G EPON and DPoE system 1-4 1.4 Document Structure
1-4
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
1-1
1 — Introduction
1.1
General This document provides the system description for the following products:
• 7302 Intelligent Services Access Manager (ISAM) equipped with an FD 100 or 320Gbps NT
• 7330 ISAM Fiber To The Node (FTTN) equipped with an FD 100 or 320Gbps NT • 7360 Intelligent Services Access Manager (ISAM) FX For specific product details on each of these systems, see the:
• 7302 ISAM Product Information • 7330 ISAM FTTN Product Information • 7360 ISAM FX 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. Note — The ISAM OLT (EPON) described is qualified for MII market only.
1.2
Supported User Interfaces Depending on the system and the Network Termination (NT) used in that system, the list of supported user interfaces will be different. The ISAM network architecture is shown in Figure 1-1.
1-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
1 — Introduction Figure 1-1 ISAM Network Architecture IP Edge Router / BRAS Ethernet Switch
NSP IP backbone
ISAM xDSL FE/GE
Ethernet
EMAN
Voice
NSP IP backbone
FE/GE
DS1/E1 Video Wi-Fi
NSP IP backbone
ISAM ISAM shelf xDSL LT
xDSL
FE/GE/10GE
Eth LT
DS1/E1 Ethernet
Voice LT
Voice
NT
FE/GE/10GE
Video
ONT/ OMCI ONU GPON
Wi-Fi
ONT/ ONU
OAM (10G) EPON
GPON LT
(10G) EPON LT ISAM OLT
Depending on the type of LT boards 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 In case a GPON (Gigabit Passive Optical Network) LT LT is used, depending on the type of ONU connected, the same 3 types of user interfaces are available. In addition, also RF video overlay, Wi-Fi, and DS1/E1 interfaces can be available via the Optical Network Units (ONU). In case an EPON (Ethernet Passive Optical Network)), or a 10G EPON (10Gigabit Ethernet Passive Optical Network) LT is used, depending on the type of ONU connected, the xDSL interface, Ethernet and Voice interface can be available via the Optical Network Units (ONU). DOCSIS Provisioning of EPON (DPoE) implements the DOCSIS operations, administration, maintenance, and provisioning functionality on existing EPON equipment to allow for existing DOCSIS Operations Support System Infrastructure (OSSI).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
1-3
1 — Introduction
Every type of ONU has a number of user interfaces of a certain type, so they have to be chosen in function of the required interfaces and functionality. Although it is clear that the ONUs are physical boxes outside the ISAM shelves, often located at customer premises, they belong to the ISAM system architecture and are also managed from the ISAM. It is worthwhile to emphasize the physical and conceptual place of the GPON, EPON, and 10G EPON functionality in the ISAM because it extends the system boundaries up to 128 (ONUs) over a fiber plant that can reach tens of kilometers from the GPON, and 10G EPON LTs and up to 64 (ONUs) over a fiber plant that reach tens of kilometers from the EPON LTs. More details on every of these interfaces are available in chapter “System interface overview”.
1.3
Integrated DSL, Voice, Point-to-point Ethernet, GPON, EPON, 10G EPON and DPoE system A combination of all of above mentioned user interfaces and functionality can be supported simultaneously in one single ISAM system, as shown in Figure 1-1. By deploying xDSL, Voice, point-to-point Ethernet, GPON, EPON, 10G EPON and DPoE LTs together in a single shelf, a single system can support all these types of interfaces. Therefore we can talk about an 'integrated system'. The management models for DPoE and traditional EPON are very different however they share the same EPON LT card using the following management modes:
• EPON: default mode, managed using traditional 1G EPON model • DPoE: managed using traditional 1G EPON model compliant with DPoE specified OAM • DOCSIS: managed using DOCSIS model The ISAM system can on the other hand also be used as a DSL-only, Voice-only, point-to-point Ethernet-only, GPON-only, EPON-only, or 10G EPON-only system in function of the available network strategy decided on by the operator. Even though the ISAM LTs and ONUs may have similar interface types (Ethernet, xDSL and voice) they are treated separately and in a number of cases managed through different commands and procedures. However, for any higher layer functionality, such as Layer2 and Layer3 forwarding protocols, ISAM provides a common management model and common implementation
1.4
Document Structure Following a general chapter about the system interfaces in the next chapter, this document is organized in a number of functional areas providing an end-to-end view of the various ISAM feature domains.
1-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
1 — Introduction
All chapters related to the higher layers in this document cover the ISAM as an integrated system (see chapter “System interface overview”) because of the common management model and implementation between xDSL, Voice, point-to-point Ethernet, GPON, EPON, 10G EPON and DPoE architecture. The GPON, EPON, 10G EPON and DPoE architecture is covered in a dedicated chapter followed by a chapter that provides an overview of all ONU types and their respective physical user interfaces.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
1-5
1 — Introduction
1-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
2.1 General
2-3
2.2 Overview
2-3
2.3 Multi-ADSL 2.4 VDSL
2-5
2-9
2.5 SHDSL
2-11
2.6 Ethernet
2-13
2.7 GPON
2-15
2.8 EPON
2-16
2.9 10G EPON 2.10 DPoE
2-19
2-23
2.11 Inverse multiplexing for ATM 2.12 ATM/PTM bonding
2-24
2-24
2.13 Overview of ISAM Voice interfaces 2.14 E1 TDM Interface
2-25
2-26
2.15 Overview of ONU Based UNI and Service Interfaces
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-26
2-1
2 — System interface overview
2.16 Overview of ISAM support for remote management of third-party equipment. 2-28
2-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
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. In a basic deployment, the ISAM is used to provide 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. In case a Passive Optical Network (PON) is used as physical access technology, the GPON LT, EPON LT or 10G EPON LT connects via fiber interfaces to the PON and physically terminate into the Optical Network Units (ONUs) that provide the user interfaces for all services. ONUs are access devices that are located at the user/customer premises. Several types of ONU exist, more details are described in a dedicated section further in this document It should be clear that, due to the positioning of the ONU, this device provides the actual user interfaces and is, together with the GPON LT, fully ISAM-internal. In the case of EPON, and 10G EPON, the EPON interface cannot be considered as fully ISAM-internal because of the white-box management model designed for better compatibility with other vendors. Note — Throughout this document, the terminology as defined in Rec. ITU-T G.984.1 (03/2008) will be adopted for EPON, 10G EPON and GPON. The Optical Network Unit (ONU) is the generic term denoting a device that terminates any one of the distributed (leaf) endpoints of an Optical Distribution Network, implements a PON protocol, and adapts PON PDUs to subscriber service interfaces. In some contexts, an ONU implies a multiple-subscriber device. The Optical Network Termination (ONT) is a single subscriber device and is a special case of an ONU.
2.2
Overview The following section provides an overview of the different relevant aspects for subscriber links. Note 1 — For ease of understanding, the ISAM Voice links are
described separately, see section “Overview of ISAM Voice interfaces”. Note 2 — For a clear delineation, Optical Network Unit (ONU)-based
user-facing interfaces (UNIs) are also discussed separately, see section “Overview of ONU Based UNI and Service Interfaces”.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-3
2 — System interface overview
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) VDSL2 (ITU-T G.993) SHDSL (ITU-T 991.2, YD/T1185-2002), IEEE 802.3 Ethernet (IEEE 802.3) 10G EPON (IEEE 802.3av)
The Ethernet subscriber links can also be terminated on the Network Termination (NT) boards or the NT I/O boards. In addition, Gigabit-capable Passive Optical Network (GPON) and Ethernet Passive Optical Network (EPON) line boards provide ISAM OLT interfaces to ONU to deliver high quality voice, video, and data services to both single-family, multi-dwelling residential and business subscribers. The ISAM OLT implementation is based on ITU-T and IEEE specifications, see sections “GPON” and “EPON”. 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 (7356 ISAM FTTB REMs) or Sealed Expansion Modules (7357 ISAM FTTB 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 modus. 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. Figure 2-1 DSL types: downstream bit rate as a function of line length 100 90 80
VDSL2
Do wn s tre a m b it ra te (Mb /s)
70 60 50
VDSL
40 30
ADSL2+
20
ADSL2 10
ADSL 0 0
1
2
3
4
5
6
7
Lin e le n g th (km)
2-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
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, 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 PTM over ADSL2/2+, preemption is supported in the upstream direction and enabled by default (not configurable). • IEEE 802.3 Ethernet frame transfer • Time Division Multiplex Mode (TDM) is supported for 10G EPON • Wavelength Division Multiplex Mode (WDM) is supported for 10G EPON
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. 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-5
2 — System interface overview
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. 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. 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. 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.
2-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview Table 2-1 ADSL operational modes 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 Internet access at up to 1.5 Mb/s downstream and up to 512 kb/s upstream.
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 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 “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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-7
2 — System interface overview
• 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 Operation Mode
Description
G.992.3 Annex A
Operation over POTS non-overlapped spectrum
G.992.3 Annex B
Operation over ISDN non-overlapped spectrum
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)
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.
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 Operation Mode
Description
G.992.5 Annex A
Operation over POTS non-overlapped spectrum
(1 of 2)
2-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
Operation Mode
Description
G.992.5 Annex B
Operation over ISDN 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)
(2 of 2)
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
2.4
Operation Mode
Description
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
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-9
2 — System interface overview
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
2-10
Operation Mode
Description
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 12A
VDSL2 profile 12A
G.993.2 profile 12B
VDSL2 profile 12B
G.993.2 profile 17A
VDSL2 profile 17A
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
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 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)
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
14
Annex B (998ADE)
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
Notes (1) US=upstream; DS=downstream (2) M=Mandatory; O=Optional; N=Not supported
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 four pairs. The use of signal regenerators for both the two-wire and multi-wire operations is optional.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-11
2 — System interface overview
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 support Cross-Talk Cancellation (CTC). 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 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)
Payload rates The following payload rates are supported:
• 192 to 2304 kb/s in 64 kb/s steps for Annex A/B • 192 to 5696 kb/s in 64 kb/s steps for Annex F/G
2-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
2.6
Ethernet The ISAM supports the following Ethernet interfaces:
• Fast Ethernet (FE): supported on NT boards, NT I/O boards, and LT boards. • Gigabit Ethernet (GE): supported on NT boards, NT I/O boards, and LT boards. • 10 Gigabit Ethernet (10GE): supported on NT boards, NT I/O boards and LT boards. 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. 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 NTs supports both modes and can adapt to either mode by way of auto-negotiation or manual configuration. The ISAM Ethernet LTs only support the full duplex mode.
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), to detect information defining the abilities of the link partner, and to determine if the two devices are compatible. Auto-negotiation provides hands-free configuration of the two attached devices.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-13
2 — System interface overview
Using auto-negotiation, the ISAM can determine the operational mode (full or half duplex) and the speed (only for electrical interfaces) to be applied to the link. Note 1 — It is also possible to manually configure the transmission
mode and speed on the link. Note 2 — Auto-negotiation is supported for both optical and electrical
GE. Auto-negotiation is supported as follows in ISAM: For ISAM NTs: full support For Ethernet LT:
• NELT-A: Not supported • NELT-B: • Optical GE: Supported in “advertising mode” only, i.e. the interface will
•
communicate its settings (default or fixed by the operator) to the peer but will not change them as a result of the negotiation, i.e. it is up to the peer to line up its configuration to the advertised settings. Electrical GE: the interface will automatically advertise support for 1000 and 100 Mb/s speeds and will adapt its speed in function of the peer capabilities. Other parameters are only advertised and not negotiated.
Fiber speed auto-sensing Dual speed optical SFPs support both 100 Mb/s and 1 Gb/s modes of operations. When using dual speed SFPs, it is sometimes operationally easier to leave the ISAM automatically select the link speed in function of the CPE capabilities. Though speed selection by means of auto-negotiation is standardized for electrical interfaces, it is not the case for optical interfaces. In order to overcome this situation, the ISAM supports a proprietary extension allowing the operator to enable the so-called “fiber speed auto-sensing”. Once enabled, the ISAM will automatically detect the operating speed of the CPE and adapts its own line rate. Note 1 — Whenever supported by the CPE (only standardized for
Gigabit Ethernet optical lines), the fiber speed auto-sensing process will use auto-negotiation, allowing for faster convergence (1 Gb/s line only). Note 2 — When 100 Mb/s and 1 Gb/s rates are both supported by the
ISAM and the CPE, the highest available rate (that is, 1 Gb/s) is always selected. See the ISAM Product Information manual for supported dual speed optical SFP modules per board type.
Software Auto-negotiation Software auto-negotiation institutes a propriety protocol to negotiate a higher communication bandwidth between two capable boards (NT board on one side and LT board on the other side). These two boards do not necessarily have to reside in the same shelf.
2-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
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 capable boards to the configured maximum speed. In case of 7356/7357 ISAM REM/SEM equipment, auto-negotiation will check the end-to-end configuration based on a capability matrix of 1Gb/s / 2.5Gb/s components (for example, SFP+/XFP capabilities, NTIO, controller board), and configure a 2.5Gb/s link speed end-to-end if all the components support 2.5Gb/s.
2.7
GPON The GPON interface is an optical interface that provides the ability to transport data between the Optical Line Termination (OLT) and the Optical Network Units (ONUs). Each GPON interface is shared by up to 128 ONUs. Some ONUs are used to connect individual residential or business subscribers: the Single Family Unit (SFU); others connect more residential or business subscribers: the Multi-Dwelling Unit (MDU) and Multi-Tenant Unit (MTU). The GPON interfaces must be considered as internal (user) interfaces while the ONU/ONT service interfaces are the actual (external) user interfaces in this specific case. GPON interfaces can also be configured as subtending interfaces, similar to subtending interfaces as offered on NT and NT I/O ports. See L2 Forwarding section for additional details All the ISAM implementations of ONU and OLT are based on the following GPON ITU-T standards:
• • • • • • •
G.984.1 (GPON Service requirements) G.984.2 (GPON PMD layer) G.984.2 (GPON PMD layer) amendment 1 G.984.3 (GPON TC Layer) G.984.3 (GPON TC Layer) amendments 1 and 2 G.984.4 (GPON OMCI) G.984.4 (GPON OMCI) amendments 1 and 2
Encapsulation Data sent over the GPON interface is encapsulated in the GEM header, where GEM stands for GPON Encapsulation Method. The GEM header includes a “GEM port” ID which uniquely identifies a traffic flow or group of traffic flows for a specific UNI. GEM port IDs are not exposed to the operator, but are assigned, for example, when a VLAN port is created on a UNI. In the ONU, a GEM port ID is associated with a specific traffic queue towards the PON. Thus the GEM port can be conceptualized as identifying a specific traffic class within a UNI.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-15
2 — System interface overview
Dynamic Bandwidth Assignment In GPON, upstream traffic from all of the ONUs on a PON is managed by the OLT using DBA (Dynamic Bandwidth Assignment). A number of “traffic containers” or T-CONTs are defined, each with individual upstream bandwidth attributes. Each T-CONT is associated with a specific ONU and aggregates the traffic for one or more GEM ports on that ONU. ONUs cannot transmit upstream data for a T-CONT without permission from the OLT. The OLT issues a “grant” to the ONU to give it permission to transmit data for a specific T-CONT. This way the OLT can control the upstream transmission for all T-CONTs and ensure that all BW requirements are honored.
Delay tolerance For the upstream GPON transmission, the ISAM system provides a configurable Delay Tolerance parameter to realize optimal latency and delay variation characteristics on the GPON link.
Forward Error Correction Forward Error Correction (FEC) is used by the GPON transport layer, which involves transmitting the data in an encoded format. The encoding introduces redundancy, which allows the decoder to detect and correct transmission errors. For further details, see chapter “GPON Network Architecture”.
OMCI ONT Management and Control Interface (OMCI) is the ITU-T G984.4 based open interface definition that provides the management model for provisioning and surveillance related functions between OLT and ONU.
2.8
EPON The EPON interface is an optical interface that provides the ability to transport data between the Optical Line Termination (OLT) and the Optical Network Unit (ONUs). Each EPON interface is shared by up to 64 ONUs. Some ONUs are used to connect individual residential or business subscribers - the Single Family Unit (SFU) or Single Business Unit (SBU). Other ONTs connect multiple residential or business subscribers - the Multi-Dwelling Unit (MDU) and Multi-Tenant Unit (MTU). As already stated in section “General”, both the EPON interfaces and the ONU service interface are the actual (external) user interface. All ISAM implementations of ONU and EPON OLT are based on the following EPON standards:
• IEEE 802.3ah-2004 (Amendment: Media access control parameters, physical layers and management parameters for subscriber access networks)
• IEEE 802.3-2005 (Carrier sense multiple access with collision detection access method and physical layer specifications) • China Telecom EPON Specification V2.1/V3.0
2-16
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
• ITU-T G.652 (Characteristics of a single-mode optical fiber and cable) • CCSA EPON regulation amendment for PX20+ sublayer requirement • YD/T 1475-2006 The access technical requirements-EPON Downstream Traffic Transmission In the downstream direction, Ethernet packets transmitted by the OLT pass through a 1×N passive splitter or cascade of splitters and reach each ONU. The value of N is typically between 4 and 64 (limited by the available optical power budget). This behavior is similar to a shared-medium network. Because Ethernet is broadcasting by nature, in the downstream direction (from network to user) it fits perfectly with the EPON architecture. Packets are broadcast by the OLT and are selectively extracted by their destination ONU; see Figure 2-2. Figure 2-2 EPON Downstream Transmission
Upstream Traffic Transmission In the upstream direction (from users to network), due to the directional properties of a passive optical combiner, data packets from any ONU will reach only the OLT, and not other ONUs. In this sense, in the upstream direction, the behavior of a PON is similar to that of a point-to-point architecture. However, unlike a true point-to-point network, all ONUs belong to a single collision domain: data packets from different ONUs transmitted simultaneously still may collide. Therefore, in the upstream direction, EPON needs to employ some arbitration mechanism to avoid data collisions and fairly share the channel capacity among ONUs.
Dynamic Bandwidth Assignment In EPON, the upstream traffic from all the ONUs on a PON is managed by the OLT using Dynamic Bandwidth Allocation (DBA). The upstream traffic is allocated per Logical Link IDentifier (LLID) by the OLT. Each LLID aggregates the traffic for one or more service interfaces on that ONU. ONUs cannot transmit upstream data without permission from the OLT.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-17
2 — System interface overview
The bandwidth assignment mechanism relies on grant and request messages, or GATE and REPORT, in IEEE 802.3ah terminology. Both GATE and REPORT messages are MAC control frames, which are identified by a predefined type value of 88-08.
• A GATE message is sent from the OLT to an individual ONU and is used to assign a transmission timeslot to this ONU. A timeslot is identified by a pair of values {startTime, length}. • A REPORT message is a feedback mechanism used by an ONU to convey its local conditions (such as buffer occupancy) to the OLT to help the OLT make intelligent allocation decisions. As specified in China Telecom EPON Specification V2.1/V3.0, the number of Queue Set and the threshold of each Queue can be configured by the OLT. The LLID is one of the key points in EPON technology, it derives from preserving the existing Ethernet MAC operation defined in the IEEE 802.3 standard, the Logical Topology Emulation (LTE) function should reside below the MAC sublayer. Operation of this function relies on the tagging of Ethernet frames with tags unique for each ONU. These tags are called LLIDs and are placed in the preamble at the beginning of each frame; see Figure 2-3. To guarantee uniqueness of the LLIDs, each ONU is assigned one or more tags by the OLT during the initial registration (auto-discovery) phase. Figure 2-3 Frame Preamble Format in EPON
Forward Error Correction Forward Error Correction (FEC) is used by the EPON MAC layer, which involves transmitting the data in an encoded format. The encoding introduces redundancy, which allows the decoder to detect and correct transmission errors. For further details, see chapter “EPON Network Architecture”.
Churning Encryption The churning encryption is to improve the security of the downstream data because the downstream traffic can easily be intercepted by malicious users. The triple churning can be enabled/disabled per LLID on ISAM, and each LLID has the unique churning key, which is generated by the request of the OLT. In the downstream direction, the EPON OLT supports the triple churning function as defined by China Telecom EPON Specification V2.1. 2-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
OAM Operation, Administration and Management (OAM) is specified in the IEEE 802.3-2005 which provides network operators the ability to monitor the health of the network and quickly determine the location of failing links or fault conditions. This OAM described in this IEEE 802.3-2005 focuses on the data link layer. Several extended OAMs have been implemented on ISAM to improve the management capability of the whole EPON network, especially EPON ONU (for example, configuration management, fault management, performance management, security management and so on).
2.9
10G EPON The 10G EPON interface is an optical interface that provides the ability to transport data between the Optical Line Termination (OLT) and the Optical Network Unit (ONUs). Each 10G EPON interface is shared by up to 128 ONUs. Some ONUs are used to connect individual residential or business subscribers - the Single Family Unit (SFU) or Single Business Unit (SBU). Other ONTs connect multiple residential or business subscribers - the Multi-Dwelling Unit (MDU) and Multi-Tenant Unit (MTU). As already stated in section “General”, both the 10G EPON interfaces and the ONU service interface are the actual (external) user interface. All ISAM implementations of ONU and 10G EPON OLT are based on the following EPON standards:
• IEEE 802.3ah-2004 (Amendment: Media access control parameters, physical layers and management parameters for subscriber access networks)
• IEEE 802.3-2005 (Carrier sense multiple access with collision detection access • • • • • •
method and physical layer specifications) IEEE 802.3av-2009 (Co-existence and simultaneous operation of 1 Gbs and 10 Gbs and physical layer specifications IEEE 802.3av-2009 (PMD, RS, PCS, PMA, and MPCP Sub-Layer Requirements China Telecom EPON Specification V2.1 ITU-T G.652 and G.657 (Characteristics of a single-mode optical fiber and cable) CCSA EPON regulation amendment for PX20+, PR20, PRX20, PR30, and PRX30 sublayer requirement YD/T 1475-2006 The access technical requirements-EPON
The 10G EPON system is a single-fiber two-way system that supports two co-existing configurations:
• symmetric operation with line rates of 10 Gb/s upstream and downstream • support for TDMA and WDM with line rates of 1/1, 10/1, and 10/10 Gb/s upstream/downstream coexistence
• asymmetric operation with line rates of 1 Gb/s upstream, and 10 Gb/s downstream
• support for TDMA and WDM with line rates of 1/1 and 10/1 Gb/s upstream/downstream coexistence
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-19
2 — System interface overview
Downstream Traffic Transmission In the downstream direction, 10G EPON supports the coexistence of both 10 Gb/s and 1Gb/s signals in a WDM manner. Ethernet packets transmitted by the OLT pass through a 1×N passive splitter or cascade of splitters and reach each ONU. The value of N is typically between 4 and 64 (limited by the available optical power budget). This behavior is similar to a shared-medium network. Because Ethernet is broadcasting by nature, in the downstream direction (from network to user) it fits perfectly with the 10G EPON architecture. Packets are broadcast by the OLT in continuous mode and are selectively extracted by their destination ONU; see Figure 2-4. Figure 2-4 10G EPON Downstream Transmission Downstream 10 Gb/s, 1577 nm 1 Gb/s, 1490 nm
10G-10G ONU
RF Video, 1555 nm 10G-1G ONU
OLT Upstream 1 Gb/s, 1310nm
1 Gb/s, 1310nm
10 Gb/s, 1270nm
1G-1G ONU
Upstream Traffic Transmission In the upstream direction, 10G EPON system supports the coexistence of both 10 Gb/s and 1 Gb/s signals in a TDMA manner (from users to network), due to the directional properties of a passive optical combiner, data packets from any ONU will reach only the OLT, and not other ONUs. In this sense, in the upstream direction, the behavior of a PON is similar to that of a point-to-point architecture. However, unlike a true point-to-point network, all ONUs belong to a single collision domain: data packets from different ONUs transmitted simultaneously still may collide. Therefore, in the upstream direction, 10G EPON needs to employ some arbitration mechanism to avoid data collisions and fairly share the channel capacity among ONUs. Multiple ONUs will take turns transmitting upstream in burst mode. See Figure 2-4
Dynamic Bandwidth Assignment In 10G EPON, the upstream traffic from all the ONUs on a PON is managed by the OLT using Dynamic Bandwidth Allocation (DBA). The upstream traffic is allocated per Logical Link IDentifier (LLID) by the OLT. Each LLID aggregates the traffic for one or more service interfaces on that ONU. ONUs cannot transmit upstream data without permission from the OLT.
2-20
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
The bandwidth assignment mechanism relies on grant and request messages, or GATE and REPORT, in IEEE 802.3ah terminology. Both GATE and REPORT messages are MAC control frames, which are identified by a predefined type value of 88-08.
• A GATE message is sent from the OLT to an individual ONU and is used to assign a transmission timeslot to this ONU. A timeslot is identified by a pair of values {startTime, length}. • A REPORT message is a feedback mechanism used by an ONU to convey its local conditions (such as buffer occupancy) to the OLT to help the OLT make intelligent allocation decisions. As specified in China Telecom EPON Specification V2.1/V3.0, the number of Queue Set and the threshold of each Queue can be configured by the OLT. The LLID is one of the key points in 10G EPON technology, it derives from preserving the existing Ethernet MAC operation defined in the IEEE 802.3 standard, the Logical Topology Emulation (LTE) function should reside below the MAC sublayer. Operation of this function relies on the tagging of Ethernet frames with tags unique for each ONU. These tags are called LLIDs and are placed in the preamble at the beginning of each frame. To guarantee uniqueness of the LLIDs, each ONU is assigned one or more tags by the OLT during the initial registration (auto-discovery) phase.
Forward Error Correction Forward Error Correction (FEC) is used by the EPON MAC layer, which involves transmitting the data in an encoded format. The encoding introduces redundancy, which allows the decoder to detect and correct transmission errors. In the 10G EPON system, the FEC is configurable and can be enabled forcibly for both the upstream and downstream direction of 10/10 Gb/s data rate per PON, and downstream of 1/10 Gb/s data rate per PON. The FEC is configurable for both the upstream and downstream direction of 1/1 Gb/s data rate per PON, and upstream of 1/10 Gb/s data rate per PON. For further details, see chapter “EPON Network Architecture”.
Churning Encryption The churning encryption is to improve the security of the downstream data because the downstream traffic can easily be intercepted by malicious users. The triple churning can be enabled/disabled per LLID on ISAM, and each LLID has the unique churning key, which is generated by the request of the OLT as defined by CCSA for 10G EPON.
OAM Operation, Administration and Management (OAM) is specified in the IEEE 802.3-2005 which provides network operators the ability to monitor the health of the network and quickly determine the location of failing links or fault conditions. This OAM described in this IEEE 802.3-2005 focuses on the data link layer.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-21
2 — System interface overview
Several extended OAMs have been implemented on ISAM to improve the management capability of the whole 10G EPON network, especially EPON ONU (for example, configuration management, fault management, performance management, security management and so on).
2-22
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
2.10
DPoE DOCSIS provisioning of EPON is a set of Cable Television Laboratory specifications that implement the DOCSIS service layer interface on existing Ethernet PON (EPON or 10G EPON) Media Access Control (MAC) and Physical layer (PHY) standards accessed using a management interface. DOCSIS operations, administration, maintenance, and provisioning functionality is implemented on existing EPON equipment to re-use existing DOCSIS Operations Support System Infrastructure (OSSI) causing the EPON OLT to act like a DOCSIS Cable Modem Termination Systems (CMTS) platform. The DPoE system supports the same IP (HSD) service capabilities as a CMTS, and also Metro Ethernet Forum (MEF) services for the delivery of Ethernet services. Note — Currently, only symmetric 1G EPON is supported.
The Alcatel-Lucent DPoE implementation of ISAM is based on the following standards:
• Cablelabs DPoE 1.0 specifications • Architecture specification: DPoE-SP-ARCH v1.0-101-110225 • OAM Extensions specification: DPoE-SP-OAM v1.0-105-130328 • Physical Layer specification: DPoE-SP-PHY v1.0-103-130328 • Security and Certificate specification: DPoE-SP-SEC v1.0-103-130328 • IP Network Element requirements: DPoE-SP-IPNE v1.0-105-130328 • MAC and Upper Layer Protocols requirements: DPoE-SP-MULPI v1.0-105-130328
• Metro Ethernet Forum specification: DPoE-SP-MEF v1.0-103-120830 • Operations and Support System Interface specification: DPoE-SP-OSSI v1.0-104-130328
• Data-Over-Cable Service Interface 3.0 specifications • MAC and Upper Layer Protocols Interface specification: CM-SP-MULPI v3.0-I 17-111117
• Layer 2 Virtual Private Networks: CM-SP-L2VPN-109-100611 • Operations Support System Interface specification: CM-SP-OSSI v3.0-120-121113 • Cablelabs DHCP Options registry: CL-SP-CANN-DHCP-Reg-109-120809 • IEEE 803.ah-2004 (Amendment: Media access control parameters, physical layers and management parameters for subscriber access networks) • IEEE 802.3-2005 (Carrier sense multiple access with collision detection access method and physical layer specifications) • IEEE 802.1ad-2005 standards for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks Amendment 4: Provider Bridges, May 2006
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-23
2 — System interface overview
2.11
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-5 IMA IMA Group
IMA Group PHY
Physical link #0
PHY
Physical link #1 PHY
PHY
Single ATM Cell stream from ATM layer
Original ATM Cell stream to ATM layer Physical link #2 PHY
PHY
IMA Virtual Link
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.
2.12
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. Up to 2 transmission links can be combined in one bonding group with ADSL ATM bonding.
2-24
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
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 ADSL2(+). This technique adds sequence information to transmitted frames or frame fragments, and thus allows resequencing, that is, delay variation due to speed variations or to PDU size variations, or both, across multiple physical links in one bonding group. Up to 8 transmission links can be combined in one bonding group with VDSL2 or ADSL2(+) PTM bonding.
2.13
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”.
POTS The 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 BA The 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-25
2 — System interface overview
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.14
E1 TDM Interface The ISAM supports E1 interfaces by means of a dedicated E1 TDM pseudo-wire SFP. The E1-TDM SFP can be inserted in a standard GE SFP cage of the ISAM's NT, NT I/O or LT board. Per need basis any Gigabit Ethernet SFP port can be converted into a TDM port and back. See the Product Information document for your system for supported SFP modules per board type. By performing Circuit Emulation Services (CES) encapsulating, the E1 TDM traffic is transported in Ethernet Layer2 packets across the ISAM and Ethernet based network. Allowing interoperability with other CES interworking devices the E1-TDM SFP is using the Metro Ethernet Forum standard (MEF-8) payload format and pseudo-wire (PW) technology. The E1-TDM SFP is a dual-channel SFP allowing terminating up to two E1 TDM lines, with a data-rate of 2,048 Mbps per E1. The CES interworking function of the E1-TDM SFP initiates and terminates a dedicated pseudo-wire per E1 tributary. The E1-TDM SFP supports structure agnostic E1 operation modes only. The line-interface supports framed-E1 for Loss Of Framing detection and CRC-4 checks. DS0 grooming or fractional E1 is not supported. Different line impedances (75Ω, 120Ω) are software selectable. The receiver sensitivity can be configured depending on the required distances (Long Haul, Short Haul). The interface type is RJ45. Using Synchronous Ethernet between the host board and the SFP, a high accurate clocking reference is provided to meet the wander requirements for TDM traffic.
2.15
Overview of ONU Based UNI and Service Interfaces The Alcatel-Lucent ONU products are access devices that use GPON technology to extend a fiber optic cable from a GPON LT in the ISAM to a subscriber residence or business location. There is a variety of ONU applications including single-family residences, multi-dwelling residences such as an apartment building, and small office home office applications. Next to a GPON uplink towards the GPON LTs, the Alcatel-Lucent ONU products can provide the following end-user interfaces:
• Ethernet UNIs (IEEE 802.3) • xDSL UNIs (ITU-T G.993.2 VDSL2) • DS1/E1 UNIs (Structured and Unstructured) in CES encapsulation with MEF-8 compliant packetization format • Voice interworking function from analog POTS lines to the VoIP/Ethernet layer (SIP) • RF Video for Overlay Service 2-26
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
Ethernet UNIs The Ethernet interfaces on the ONUs support the following primary features:
• IEEE 802.3 Physical Layer • IEEE 802.1Q, 802.1x port-based authentication, and 802.1p (QoS classification per Ethernet port support) • Layer 3 DSCP to 802.1p mapping to allow L3 Class of Service (CoS) over the Layer 2 network • Full or half duplex operations • Auto-negotiation or manual setting of speed and operation mode
VDSL UNIs The VDSL service is provided using unshielded copper twisted pairs and without requiring repeaters. By using a Frequency Division Multiplexing technique, the existing POTS or BR ISDN services can still be provided on the same wires. VDSL transceivers use Frequency Division Duplexing (FDD) to separate upstream and downstream transmission. Additional details are provided in chapter “xDSL features”.
DS1/E1 UNIs in CES Encapsulation TDM traffic based on structured and unstructured DS1 / E1 interfaces of ONUs are transported using Circuit Emulation Services (CES) encapsulation in Ethernet layer-2 over the GPON using the Metro Ethernet Forum standard MEF-8 payload structure and pseudo-wire (PW) technology, primarily for Business Services. Additional details are provided in chapter “ISAM Support for the GPON ONU”.
POTS UNIs in VoIP The ONUs support the voice interworking function from the analog POTS lines to the VoIP/Ethernet using SIP. SIP implementation is based on RFC 3261 which contains the primary methods or signaling messages. Additional RFCs are defined that expand on this base to provide more complete functionality so that a complete set of call features that phone users are accustomed to can be supported. The connection model uses SDP in conformance with RFC 2327. The media stream or bearer channel is based on its own protocol, RTP, which is defined in RFC3550 and RFC 3551. Additional details are provided in chapter “ISAM Support for the GPON ONU”.
RF Video The ONU provides RF video service through the video overlay function. The function operates downstream in the 1550 nm optical band. Signals sent over the overlay network are presented to the subscriber as RF signals from a video F-type connector in the ONU.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-27
2 — System interface overview
This service is an alternative to IGMP-based in-band video provided over HSI services supported on Ethernet and VDSL2 UNIs. Additional details are provided in chapter “ISAM Support for the GPON ONU”.
2.16
Overview of ISAM support for remote management of third-party equipment.
Purpose ISAM 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 traffic The 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.
2-28
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
2 — System interface overview
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 functions In 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. With the introduction of the NRCD-C control board, the allowed average traffic load is increased to 10Mbps of mixed size packets.
Third-party management traffic handling and security The 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
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
2-29
2 — System interface overview
2-30
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
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.4 Failure protection at layer 3
3-13
3.5 Subscriber interface redundancy
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
3-11
3-14
November 2013
3-1
3 — Failure protection and redundancy provisions in ISAM
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 aspects Redundancy 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 static and/or dynamic configuration data for the multiple essential resources has to be kept in a location which 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: 3-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
3 — Failure protection and redundancy provisions in ISAM
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 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
3-3
3 — Failure protection and redundancy provisions in ISAM
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 low enough) to operate in a non-protected way. For example, in an attended CO environment, where a spare parts stock 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 provision The 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. An ISAM can be configured in loadsharing mode by means of an optional second FD 100/320GbpsNT board or FX NT board. In this case the faceplate ports on both NT boards can be configured to carry traffic (that is, active-active data plane). The NTIO boards that are currently available will switch traffic to and from a single NT board (that is, the “active” NT board) only. Because of this, loadsharing over the ports connected to the NTIO board is not possible. Also, since the currently available LSM boards are only capable of sending/receiving traffic to/from a single NT board (that is, the “active” NT board) no loadsharing is possible between the NT board and the LSMs. This means that all traffic to/from the LSMs will pass through the “active” NT board.
3-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
3 — Failure protection and redundancy provisions in ISAM
The control plane is managed on the active NT board but the control plane is fully synchronized between the two NT boards. The control plane is fully synchronized for a selected number of protocols:
• L1: port state configuration synchronization and port state changes are forwarded and handled by the active control plane
• L2: MAC learning, LACP and IGMP snooping • L3: • Base Router, only static configuration: static routes, IP interfaces and ARP • some other protocols: QoS, ACLs and security, that is, filters. For a number of protocols such as SyncE and a number of Layer3 protocols (OSPF, ISIS, RIP, BGP, L3 DHCP Relay Agent) no hitless control plane switchover is supported. After switchover these protocols will be established from scratch as if on a simplex system. Also, MPLS, as an exception, is only supported in a simplex configuration and not in a duplex configuration. After switchover, the data plane and the control plane (for the supported protocols) are immediately recovered. The management plane recovery is artificially delayed and is restored at the moment the new active NT board is fully initialized.
3.2
ISAM single shelf configurations
Single NT When using a single NT board 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
3-5
3 — Failure protection and redundancy provisions in ISAM Figure 3-1 Link protection with active/standby external NT link LT1
NT Active PHY µP
Standby
PHY
LTn
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. Figure 3-2 Link protection with load-sharing external NT links LT1
NT µP
PHY
1
PHY
2
LTn
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).
3-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
3 — Failure protection and redundancy provisions in ISAM
Single NT, with NTIO When 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 LT1
NT PHY µP
PHY
NTIO PHY PHY LTn
PHY PHY PHY PHY
Dual NT (loadsharing), no NTIO The FD 100/320Gbps NT/ FX NT system supports loadsharing of the data and control layer. The dataplane is physically loadshared (only on the network side, though, loadsharing towards the LTs is not yet supported) and the control plane is fully synchronized between the two NT boards. This means that the external links on the faceplate of both NT boards can be used to connect to the network and that every one of these links is active at the same time. The FD 100/320Gbps NT/ FX NT system supports an active/standby NT equipment protection at the same time (that is, only one of the two NT boards can be active at a time). After switchover, the control plane on the new active NT board will get full control over the synchronized control plane. The dataplane via the faceplate ports is possibly impacted by the reset of the previous active NT board. An LAG over the faceplate ports of the two NT boards is a good protection in this case. NT switchover is not revertive after the repair of a failed NT board. The following protection capabilities exist: NT equipment protection with distributed external links
Figure 3-4 illustrates the usual configuration with a redundant NT pair, supporting a loadshared external link configuration. The active external links are connected to the active NT board and the standby NT board.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
3-7
3 — Failure protection and redundancy provisions in ISAM
The operator can:
• configure a number of external link groups on the NT board (active and/or standby) • 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 NT equipment protection with distributed external links LT1
NT PHY µP
Active
PHY
LTn LT1
NT PHY µP
Active
PHY
LTn
NT protection, that is, switchover of control and management traffic from the active NT board to the standby NT board, and a related status change for both NT boards, is only triggered by the failure or removal of the NT board itself, detected by means of a dedicated protection interface between both NT boards. This means that a failure of the active NT board or the standby NT board will have an impact on the data traffic over the external links that can be active on both NT boards (this can be protected by configuration of a LAG protection group over the faceplate ports of the two NT boards, though, see “NT equipment protection with distributed external links”), but also that a failure of the external faceplate links will have no influence on the switchover between the active NT board and the standby NT board. NT equipment protection with distributed external links (load aggregation)
Figure 3-5 shows a configuration with multiple external links that are grouped in a load aggregation group over the two NT boards. 3-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
3 — Failure protection and redundancy provisions in ISAM Figure 3-5 NT equipment protection with distributed external links (load aggregation) LT1
NT µP
PHY
1
PHY
2
LTn LT1
NT µP
PHY
3
PHY
4
LTn
NT protection, that is, switchover of control and management traffic from the active NT board to the standby NT board, and a related status change for both NT boards, is only triggered by the failure or removal of the NT board itself, detected by means of a dedicated protection interface between both NT boards. This means that a failure of the active NT board or the standby NT board will have an impact on the data traffic over the external links that can be active on both NT boards (protected by the LAG), but also that a failure of the external faceplate links will have no influence on the switchover between the active NT board and the standby NT board.
Dual NT, with NTIO Figure 3-6 shows a redundant NT pair configuration with NTIO board. The NTIO board enables independent external link protection and NT board equipment protection, for external links connected to the NTIO board. The NTIO board replaces the passive optical splitter(s) with an active board. The NTIO board 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 board. The external links on the NTIO board can be configured in active/standby mode, or in load aggregation group mode, as already discussed above.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
3-9
3 — Failure protection and redundancy provisions in ISAM
There is also no different behavior for the FD 100/320Gbps NT board / FX NT board system (see “NT equipment protection with distributed external links”) since the external links via the NTIO board are shared over the active NT board and the standby NT board and only the active NT board will be able to use these links. This means that FD 100/320Gbps NT system uplinks and FX NT system uplinks are only data-path loadshared for the faceplate ports. The uplinks connected to the current NTIOs are not loadshared, but physically flipped (SAS controlled) towards the active NT. In a redundant NT pair configuration with NTIO board, the external links on the faceplate of each NT board, and the external links on the face plate of the common NTIO board 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 board switchover, the external links of the NTIO board will be reconnected automatically to the new active NT board, while the same is not possible for external links plugged directly to the NT board 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 board faceplate(s), as discussed for previous configurations. 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-6 Independent load sharing external link and NT protection with NT LT1
NT PHY µP
PHY NTIO PHY
Active
PHY
LTn LT1
µP
PHY
1
PHY
2
NT
PHY
PHY
PHY
PHY
LTn
3-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
3 — Failure protection and redundancy provisions in ISAM
LT Loadsharing In a redundant NT configuration, the backplane links from the LT to the two NTs are able to loadshare the upstream and downstream traffic. In downstream the load sharing NTs should be capable of splitting the traffic across the backplane links towards the LT and in upstream direction the loadsharing LT should be capable of distributing the traffic towards the NT, thus doubling the backplane capacity.
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-7 • daisy-chain topology; see Figure 3-8 • ring topology: daisy chain with the last node connected to the first; see Figure 3-9. 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 a 7360 ISAM FX
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
3-11
3 — Failure protection and redundancy provisions in ISAM Figure 3-7 Example of an ISAM subtending star topology μP
NT
PHY PHY
Subtending links
LAG
NTIO PHY PHY
μP
NT
PHY PHY
N PHY PHY T
PHY PHY
μP
NT
PHY PHY
NTIO PHY PHY
μP
NT
PHY PHY
N PHY PHY T
Network links
PHY PHY
μP
NT
PHY PHY
LAG
NTIO PHY PHY
μP
NT
Subtending links
PHY PHY
N PHY PHY T
PHY PHY
Figure 3-8 Example of an ISAM subtending daisy chain topology μP
NT
PHY PHY
Subtending links active
NTIO PHY PHY
μP
NT
PHY
N PHY PHY T
LAG
PHY PHY PHY
μP
NT
PHY PHY
μP
NT
LAG
NTIO
PHY PHY
PHY
PHY
PHY
μP
NT
PHY
PHY
N PHY PHY T
μP
PHY PHY PHY
μP
NTIO
NT
PHY
N PHY PHY T
PHY PHY PHY
NT
Network links PHY PHY
NTIO PHY PHY
μP
NT
PHY
N PHY PHY T
LAG
PHY PHY PHY
3-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
3 — Failure protection and redundancy provisions in ISAM Figure 3-9 Example of an ISAM subtending ring topology NT
μP
PHY PHY
Subtending links active
NTIO PHY PHY
NT
μP
PHY
N PHY PHY T
PHY PHY PHY
μP
μP
NT
NT
PHY PHY
μP
NT
NTIO
NTIO
PHY
PHY
PHY
PHY
PHY
μP
PHY
N PHY PHY T
PHY PHY
NT
PHY
PHY
N PHY PHY T
PHY
μP
PHY
Network links
PHY PHY
NT
PHY PHY
NTIO PHY PHY
μP
NT
PHY
N PHY PHY T
PHY PHY PHY
3.4
Failure protection at layer 3 When the ISAM 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 a 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-10 Example of layer3-based protection LT 1
NT µP
Subnet 1
PHY
Edge router 1
PHY
Edge router 2 Subnet 2
L3 switching and OSPF enabled
LT n
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
3-13
3 — Failure protection and redundancy provisions in ISAM
3.5
Subscriber interface redundancy The ISAM provides subscriber interface redundancy for important subscriber interface which can be:
• lines that are connected with business users or small access Nodes (PON/LAN ONU/ONT)
• lines that representing high-capacity access points (Point to point fiber, GPON/EPON)
PON Link Protection Note — The PON Link Protection feature is only supported on the 7360 ISAM FX (with FANT-F) in this release.
Large bundles of feeders in a cable or duct increase the risk of intolerable repair times in case of a breach or an accident. The increasing number of split ratios and deployment of business critical services highlight the importance of implementing PON protection schemes. ITU-T specification G984.1 describes multiple PON protection schemes. ISAM GPON line cards implement Type-B PON protections defined in this standard which addresses route diversity to the first splitter in a 1:1 arrangement. The PON links of the ISAM can be configured in protection pairs on the PON boards across the shelf. In case an active PON link fails, all traffic is switched to the associated protection without service loss; see Figure 3-11. Figure 3-11 Type-B PON Link Protection ONU #1 PON LT
N:2 optical splitter OLT PON LT (1) PON LT (0)
ONU #N PON LT
3-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
3 — Failure protection and redundancy provisions in ISAM
From the topology point of view, the Type-B PON protection arrangement can be achieved by connecting two fibers from the ISAM PON interfaces to the a first level N:2 optical splitter. Link failure on the active link is detected by either:
• detection of “Loss of Signal” on the PON link • loss of frame • Excessive errors on the active PON-using a settable threshold crossing limit on the errors. In the current ISAM implementation, only inter-card protection among the cards of the same type is supported (that is, PON links belonging to the same board can not be paired into protection groups). In addition the current implementation does not provide coverage for IPv6/DHCPv6, 802.1x/RADIUS, and CFM/OAM or network-side router (Layer-3) functions. Before configuring two PONs in a protection pair on NGLT-C/FGLT-A, please make sure the number of downstream queues per UNI/ONT is configured with the same value on the two PONs (see also section “Downstream QoS”). The Type-B protection feature is not supported with NANT-D or NANT-E. A license counter keeps track of the number of configured Protection Groups.
Ethernet link protection Ethernet interfaces hosted by the Ethernet LT can be used to connect critical resources like business users, mobile base station, or subtended DSLAMs where link protection is often required. The redundancy options offered by NELT-B are as follows:
• LAG: Up to eight links can be grouped into a LAG, provided the following conditions are fulfilled:
• they share the same interface type (UNI, HC-UNI or NNI) • they share the same fixed line rate (FE, GE) • all the links members of the LAG are hosted by the same LT (intra-card LAG) and they all belong to either the port range 1…18 or the port range 19…36
Dynamic (with LACP) and static (without LACP) LAG variants can be configured. Load sharing is based on MAC and/or IP addresses (configuration options).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
3-15
3 — Failure protection and redundancy provisions in ISAM
• RSTP/MSTP: Any link (including a logical link corresponding to a LAG) can be associated with an xSTP instance provided they share the same interface type (NNI) and are located onto the same LT board (intra-card xSTP). The following additional constraints apply:
• xSTP is only supported with the iBridge model (not with VLAN cross-connect) • xSTP on the Ethernet LT assumes the LT interface to be root bridge and must be configured accordingly by the operator.
NT and LT xSTP instances are split, that is the NT links and the LT links are not part of the same protection domain. A link event failure at the LT side is not signaled by the NT towards the network and inversely meaning that cross-LT or cross-ISAM link protection schemes are not supported Table 3-1 Overview of link protection options in function of the NELT-B interface type
3-16
Supported link protection option
LAG
xSTP
UNI
Y
N
Hi-Cap UNI
N
N
NNI
Y
Y
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
4.1 Overview
4-2
4.2 Management interfaces
4-3
4.3 Management interfaces security 4.4 Management access models 4.5 Counters and statistics 4.6 Alarm management
4-13
4-15
4-18
4-19
4.7 Software and database management 4.8 Equipment monitoring
4-26
4-30
4.9 Access node control protocol
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
4-31
November 2013
4-1
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 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
The Alcatel-Lucent-recommended management architecture is shown in Figure 4-1. Figure 4-1 ISAM management OSS
SOAP XML
TL1 GW
5529 SDC
5530 NA
TL1 xFTP
5529 IDM
5529 OAD
5529 APC PBMT
5520 AMS xFTP SNMP
SNMP
Remote CT
SOAP XML
TL1 xFTP
CLI
xFTP
TL1 CLI
CLI SNMP TL1 xFTP Local CT
TL1 CLI
ISAM
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. 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
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
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. Figure 4-2 Secure and insecure management interfaces
Individual security control per management channel
CLI
RS232 serial interface
CLI Agent
File transfer
TL1
SNMP
TL1 Agent
SNMP SNMP v1/v2 v3
Client
Server
TFTP
Client
Server
SFTP
Client FTP
SNMP Telnet server
SSH server
23
22
TCP
Telnet server 1023
161/162 13001 69
1022
TCP
Secure Insecure
SSH server
UDP
UDP
Secure Insecure
UDP
Secure Insecure
Insecure
115
20
TCP
Secure Insecure
Insecure
Mutually exclusive
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-3
4 — Management
SNMP The 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. Note — SNMPv3 is supported by default. but also SNMPv2 and SNMPv1 messages can be processed.
SNMPv3
The security mechanisms defined in SNMPv3 protect against threats such as masquerade, modification of information, message stream modification, and disclosure. The SNMPv3 security mechanisms provide:
• • • •
data origin authentication data integrity checks timeliness indicator encryption
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
4-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
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.
TL1 The 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:
• Operations and Maintenance Using TL1 for FD 100/320Gbps NT and FX NT • TL1 Commands and Messages Guide for FD 100/320Gbps NT and FX NT In total, maximum ten TL1 parallel sessions are supported. The following restrictions and conditions apply depending on the type of session:
• • • •
two sessions are reserved for CRAFT/Serial access up to five parallel TL1 sessions over Telnet (TCP) can be used up to five parallel TL1 sessions over SSH (TCP) can be used a maximum of six UDP session are supported.
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. An alarm is raised whenever a TL1 user logs in (successful or not), indicating the IP address, account name and timestamp of the login trial. Severity, reporting and so on of this alarm can be configured as with any other alarm. If the login was not successful, the corresponding alarm needs to be cleared manually by the operator. To avoid an overflow of failed login alarms (for example, due to a malicious user), a new failed login alarm will only be generated either when 3 minutes have passed since the last failed login alarm or when 90 failed logins occurred, whichever comes first.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-5
4 — Management
The TL1 login banner is configurable. Note — The ISAM will refuse any TL1/UDP connection with a source port < 12 to protect the ISAM against malicious attacks.
CLI The 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:
• Operations and Maintenance using CLI for FD 100/320Gbps NT and FX NT • CLI Command Guide for FD 100/320Gbps NT and FX NT The ISAM supports up to ten parallel CLI sessions, be it over telnet or over SSH. There can only be 1 local Craft session. An alarm is raised whenever a CLI user logs in (successful or not), indicating the IP address, account name and timestamp of the login trial. Severity, reporting and so on of this alarm can be configured as with any other alarm. If the login was not successful, the corresponding alarm needs to be cleared manually by the operator. To avoid an overflow of failed login alarms (for example, due to a malicious user), a new failed login alarm will only be generated either when 3 minutes have passed since the last failed login alarm or when 90 failed logins occurred, whichever comes first.
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 an SFTP client towards an external SFTP server, the ISAM uses an operator-configured username and password. The security settings like encryption, hashing and signature protocols can be configured by the operator via CLI or SNMPv3. The ISAM supports both an SFTP client and server. In server mode, the ISAM supports two SFTP sessions simultaneously. Also, in SFTP server mode, the
4-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
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. 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. In case of SFTP, only one account can be specified. This account will be used towards all external xFTP servers. In case of FTP, up to 8 external servers/accounts can be specified, each with their own account. In case of TFTP, no account is required, so also none (0) can be specified. 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.
xNTP The ISAM system time can be set in three ways:
• the system time can be retrieved using the SNTP protocol to retrieve the time from a (S)NTP time server
• the system time can be retrieved using the NTP protocol to retrieve the time from (S)NTP time servers • the system time can be set manually by the operator
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-7
4 — Management
This is a system wide setting in the ISAM. While SNTP and NTP is mutually exclusive (that is, either SNTP or NTP can be enabled, but not both at the same time), the ISAM system time can always be set manually by the operator, even if SNTP or NTP is enabled. SNTP Client
Typically, the ISAM system time is retrieved using the Simple Network Time Protocol (SNTP); the ISAM can cope with both SNTP and NTP servers, in both cases using the SNTP protocol. On a per ISAM level, also the polling rate can be specified, applicable for all specified (S)NTP servers. Apart from defining the (S)NTP servers, first of all SNTP must be set as the system-wide option for the ISAM. The (S)NTP server will always provide the UTC (Coordinated Universal Time): no time zone or daylight savings settings are passed over the SNTP protocol. The (S)NTP server can be configured in the ISAM by specifying:
• The IP address of the server • The port to be used Up to three (S)NTP servers can be configured in the ISAM, specifying:
• The IP address of the server • The port to be used • The relative priority among the three possible servers The relative priority defines which server will be polled first to get the time. If none of the time servers can be reached, even after three retries, an alarm is raised. NTP Client
Alternatively the ISAM can also retrieve its system time using the NTP protocol (NTPv3), with up to 5 NTP servers used. Also in this case the NTP servers can be pre-configured, but no priority is to be specified as this is irrelevant in case of the NTP protocol. Note the xNTP servers need to be configured separately for the SNTP and the NTP protocol: the servers defined for the SNTP protocol will not be used by the NTP protocol and vice versa. The following can be specified per NTP server:
• The IP address of the server • The port to be used (default = 123) On a per-ISAM level, also the polling rate can be specified, applicable for all specified NTP servers. If none of the servers can be reached, even after three retries, an alarm will be raised. Also when selecting NTP to set the system time, the server will always provide the UTC time.
4-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
Manual setting
The ISAM system time can also be set manually by the operator. However, if SNTP or NTP is enabled (see above), the set system time will be overwritten at the next xNTP poll by the UTC time. Note — As all the management time stamping (such as alarms, syslog messages, PM, …) is based on the ISAM system time, Alcatel-Lucent highly recommends to use either SNTP or NTP instead and discourages any manual time setting in the operational network. Time zone offset
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), via NTP (when time is set using the NTP protocol) 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
• The ISAM system time (taking into account the time zone offset) is also stored in prozone and restored after a reset of the ISAM. If the time cannot be restored from prozone, the ISAM system time is set fixed to January 1, 1970 again, until the time is set, either manually or by using xNTP.
• Is independent of the fact whether xNTP is enabled or not, that is, it will also be applied when SNTP and/or NTP are 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 and so on, that is 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). SNTP Server towards ONT/MDU
The ISAM can also act as SNTP server towards the ONTs/MDUs. This means the ONT/MDU can retrieve its system time directly from the ISAM by using SNTP. The ISAM acts on behalf of the SNTP server in the network. The SNTP server addresses are learned by the ONT/MDU using DHCP option 42. 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 Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-9
4 — Management
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”.
SSH Secure Shell (SSH) is a protocol that provides authentication, encryption, and data integrity to secure network communications. On top of this protocol, SSH implementations offer secure replacements for rsh, rlogin, rcp, ftp, and telnet, all of which transmit data over the network as clear text. In addition, it offers secure data-tunneling services for TCP/IP-based applications. SSH has a client-server architecture. The ISAM can act both as an SSH server or an SSH client; see Figure 4-3. Figure 4-3 SSH client-server architecture in the NE SSH Appl. protocol
SSH CLI client appl
SSH CLI server appl
SSH transport ssh client
EMS SSH Client
ssh server
authentication, connnection
- DB of client - Public keys or passwords
NE
Server authentication Secure link for CLI/TL1
SSH Server
- NE public key - NE private key - Supported algorithms
Client authentication SFTP Client
Secure link for SFTP
File
Secure link for SW&DB
SFTP Server
SFTP server application
SSH server
InterPeak
SFTP Server
SFTP Client
- SFTP client - Username/password
Secure link for the transfer from FileServer to NE (SW&DB)
SFTP Appl. protocol SSH transport, authentic, connection protocol
SFTP client application
SSH client
System logging System 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:
4-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
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. Locally stored syslog files can be transferred to an external server using xFTP. File sets
The system logging works with file sets consisting of two log files. The operator can:
• Trigger the wrap-around from file1 to file2 in order to upload a stable file1. Note — The ISAM will also automatically copy file1 to file2 when file1 is full. Both actions (automatic by system / manual by operator) are performed independently of each other.
• Assign a name to this file set • Specify the maximum size of the file set 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-11
4 — Management
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. Table 4-2 Message type and log severity parameters 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
Emergency
EM
Alert
AL
Critical
CR
Error
ER
Warning
WN
Notice
NO
Information
IN
Debug
DBG
Log severity
Note — Besides these message types, the alarms and the errors encountered in the system are also logged in the system log files.
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 be retrieved via xFTP to upload to an external server. In this case the operator can access the log file only after successful xFTP authentication. System log files are to be deleted explicitly by operator command.
4-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
Viewing and monitoring system logs
The contents of a system log can be viewed either dynamically or statically. 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 interfaces The 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 authentication SSH, SFTP and SNMPv3 support encryption and authentication. Table 4-3 shows the supported combinations.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-13
4 — Management Table 4-3 Supported SSH and SNMP Authentication and Encryption Schemes Security protocol
Encryption algorithm
Authenticatio n algorithm
Authentication mechanism
Combinations
SSH, SFTP
3DES, blowfish,
Hmac-sha-1, hmac-sha-1-96
Username/password(1)
• • •
AES, DES-56
Username/public and private key
• SNMPv3
DES-56
Hmac-sha-1, hmac-md5
Username/password(1)
Note: Different
password per SNMP engine.
• •
Nothing Encryption only Authorization only Encryption and authorization Authorization only Encryption and authorization
Note (1)
The username/password combinations of SSH and SNMPv3 cannot be reused.
Security configuration The 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 password Two 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. For security purposes, the default username and password must be changed as soon as possible. The system prompts the operator to do this when he or she logs in for the first time.
Trace and Debug interface The ISAM also supports a Trace&Debug (T&D) interface for troubleshooting purposes. his interface gives access to low level ISAM functionality and is intended to be used by trained Alcatel-Lucent personnel only. Alcatel-Lucent highly recommends to disable this interface at any time during normal network operations. Moreover, as an alternative management interface, the ISAM T&D interface is also vulnerable to security issues. This can be avoided as much as possible by disabling this interface whenever it is not used. The T&D interface can be enabled or disabled using the configure system security ssh access command: please refer to the CLI Command Guide for FD 100/320Gbps NT and FX NT for all details.
4-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
4.4
Management access models
Introduction In 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 v-VPLS • a dedicated management pseudo-wire tunnel over an MPLS network. • Layer 3: specific IP ACLs (checks for all traffic destined for the CPU (CPU filters)) • 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 model via a Layer 3 SAP • Management model via an IP interface directly connected to a network port Management via Layer 3 SAP (IES SAP) Two different models are possible: 1
All the management plane packets are passing via a dedicated external Management VLAN (v-VPLS)
2
There is no explicit external management v-VPLS (VLAN).
All the management plane packets are passing via a dedicated external Management VLAN (v-VPLS)
A dedicated external management v-VPLS (VLAN) isolates the management plane traffic from the user plane traffic in the access network.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-15
4 — Management
All the user plane traffic is passing via another v-VPLS and not via the external management v-VPLS. Figure 4-4 Management via a Layer 3 SAP - external management VLAN (v-VPLS) Management traffic User traffic
Regular Ports
v-VPLS SAPs
Phy
IHub v-VPLS
IES SAP
IHub IES
Ext. mgnt. v-VPLS VLAN 4093
IES Phy LAG Phy
v-VPLS VLAN 23
iBridge VLAN 23
v-VPLS VLAN 11
(No VLAN translation shown on user side)
CPU filter
OBC NT
LT
ISAM
In this case, the security is based on:
• No layer 2 checks • Layer 3 checks: By using CPU filters, the operator will only allow management traffic from the VPLS service of the management VLAN (external management v-VPLS). Optional: in combination with checks on the source IP address of the management stations • Layer 4-7: specific authentication mechanisms on application level There is no explicit external management v-VPLS (VLAN)
On the access network the user and management traffic is not separated.
4-16
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management Figure 4-5 Management via a Layer 3 SAP - No external management v-VPLS User and Management traffic
Regular Ports
v-VPLS SAPs
IHub v-VPLS
IHub IES
IES SAP
Phy
v-VPLS VLAN 11
IES
v-VPLS VLAN 23
iBridge VLAN 23
Phy LAG Phy
(No VLAN translation shown on user side)
CPU filter
OBC NT
LT
ISAM
In this case, the security is based on:
• No layer 2 checks • Layer 3 checks: by using CPU filters, the operator will only allow management traffic from the source IP address of the management stations. • Layer 4-7: specific authentication mechanisms on application level
Management via an IP interface directly connected to a network port On a network port it is possible to configure an IP interface with a corresponding encaps-value (VLAN). All IP packets which are destined for the interface IP address are lifted to the OBC. However, all IP packets which have access to the Base Router can also access the OBC by using the IP address of the interface as destination IP address. If no special protection mechanisms are activated, all packets which have access to the base router can access the OBC. If a v-VPLS is connected to the base router via a L3 SAP, all user traffic which is passing via the v-VPLS, can access the OBC. This is possible by using the IP address of the IP interface (connected to the network port) or via the IP address of the L3 SAP. All packets which have access to the OBC can access the management protocols.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-17
4 — Management Figure 4-6 Management via an IP interface directly connected to a network port Management traffic User traffic
Network Port
L3 SAP
IP interface
Phy
v-VPLS VLAN 23
IES
iBridge VLAN 23
Phy Access Port
v-VPLS VLAN 11
(No VLAN translation shown on user side)
CPU filter
OBC NT
LT
ISAM
In this case, the security is based on:
• No layer 2 checks • Layer 3 checks: by using CPU filters, the operator will only allow management traffic from the source IP address of the management stations (and also the allowed protocols). • 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:
• Operations and Maintenance Using CLI for FD 100/320Gbps NT and FX NT • TL1 Commands and Messages for FD 100/320Gbps NT and FX NT
4-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
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 Alarms (TCA) indications:
• • • • • •
alarm category and definition (fixed per release) alarm severity (ignore, 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 CLI Commands for FD 100/320Gbps NT and FX NT and the TL1 Commands and Messages for FD 100/320Gbps NT and FX NT documents for alarm management command definitions.
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 temporal and spacial alarm filters and the derived alarms. • TCA alarms: these alarms are generated when a Performance Monitoring (PM) counter or actual value of a parameter crosses a defined threshold value (Threshold Crossing Alert). 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
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-19
4 — Management
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 Operation and Maintenance Using CLI for FD 100/320Gbps NT and FX NT and Operation and Maintenance Using TL1 for FD 100/320Gbps NT and FX NT document for a complete listing of all alarms, along with their definitions. Alarm definitions are not user configurable. Note — It is not possible yet to retrieve the GPON alarms via CLI.
This limitation will be removed in a future ISAM release.
Alarm severity For each individual alarm the operator can configure:
• whether spontaneous reporting should take place or not and • the severity level of the alarm. There are six alarm severity levels listed in ascending order of severity:
• • • • • •
ignore indeterminate warning minor major critical
In addition to the individual alarm reporting control above, the operator has the capability to select which alarm severity he wants to see spontaneously reported. This is useful to avoid being overwhelmed by a flood of non-important alarms. There are five levels available for the minimum severity which alarms must have to be reported, listed in ascending order of severity:
• • • • •
indeterminate warning minor major critical
For additional flexibility this minimum reporting severity level is separately configurable for:
• non-interface related alarms, (cfr. CLI: “configure alarm...”); • interface related alarms, per interface type like xDSL, Ethernet, Gpn,... (cfr. CLI: “configure interface...”) 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.
4-20
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
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 as well. You can configure the (system-wide) minimum alarm severity level and the individual severity level of an alarm using CLI, TL1 or an Element Management System. See the 7302 ISAM | 7330 ISAM FTTN CLI Commands and 7302 ISAM | 7330 ISAM FTTN Operations and Maintenance Using TL1 documents 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. Note that when the severity level of an alarm is set to ignore (lowest level), these alarms are completely ignored by the system and no processing will happen whatsoever - the ISAM will behave as if this alarm just does not exist.
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, unless otherwise specified. 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. Note — There is no alarm severity delta log for the ignore severity.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-21
4 — Management
Current and snapshot alarm lists The 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 list A separate alarm severity delta logging list exists for five alarm severity levels, there is no alarm severity delta log for the ignore severity. 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, with a total capacity of 100 entries per alarm severity delta logging list. 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. A 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.
Alarm clearing Most alarms are cleared autonomously. Both the alarm-on and alarm-off situation are detected and reported. The alarm-off will result in the automatic clearing of the alarm-on from the current alarm list. However, some alarms cannot be cleared automatically and require operator intervention to clear the alarm: OSWP-Download-failure is an example of such an alarm. Also a group of IHub alarms will not be cleared automatically. In order to clear these alarms, explicit operator intervention is needed using CLI and/or an Element Management System. The list of alarms that need clearing through operator intervention is specified in the alarm description document as specified before.
4-22
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
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 TL1 Commands and Messages for FD 100/320Gbps NT and FX 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 temporal alarm is raised in the ISAM when:
• the number of alarm events reaches the set threshold during the filtering window time period, OR
• the alarm event remains active for at least the filtering window time (even if the set threshold is not met) Figure 4-7 shows how a temporal alarm filter raises a derived alarm after the configured threshold is reached (in this case set to 3). In the first case only 2 alarm events occur during the filtering window time T, so no derived alarm is raised. In the other cases, 3 alarm events occur in the window T, and a derived alarm is raised.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-23
4 — Management Figure 4-7 Temporal alarm by quantity Only 2 events in time T: no temporal alarm is raised
Alarm event
Threshold = 3
T
T
T
Temporal alarm Temporal alarm is cleared when the alarm event is cleared
Figure 4-8 shows how a temporal alarm filter raises a derived alarm when the alarm event is active for at least the filtering window time T. In the first case the alarm event is cleared before T, so no derived alarm is generated; in the second case an alarm event remains active for more then T, in which case the derived alarm is raised. Figure 4-8 Temporal alarm by time Event is cleared again before time T expires: no temporal alarm is raised
Alarm event
T
T
Threshold = 3
Temporal alarm Temporal alarm is cleared when the alarm event is cleared
So the temporal alarm is always raised when the condition is met, and cleared whenever the alarm event, triggering the alarm filter condition, is cleared, independent of the filtering window time. See also Figure 4-7 and Figure 4-8. A temporal alarm filter becomes active whenever the alarm event is raised on an ISAM object (for example, on a port, ONT, …), i.e. at that moment timer T is started (see figures above) and the number of occurrences is counted. Each such filter can be activated (by the alarm event) on at most 50 different objects at a time. A filter becomes inactive again for a certain object whenever the condition is cleared (and so no derived alarm is generated, or the derived alarm is cleared). Temporal alarm filters are useful for, for example, 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. 4-24
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
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. 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. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-25
4 — Management
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.
External alarms profiles The ISAM equipment practices provide an external alarm interface to which up to 5 external alarms can be connected, be it in a CO or cabinet environment. Upon alarm condition detection, the ISAM will raise an external alarm, also known as 'customizable alarm' and/or 'environmental alarm', and are configured and handled in the ISAM like any other, internal ISAM alarm (severity, logging, filtering, …). For these external alarms, also an external alarms profile can be defined, reflecting a configuration of external alarms parameters that correspond to a certain environment where the ISAM is located (outdoor cabinet, CO, basement cabinet, …). Using these external alarms profiles, we avoid the need to specify these parameters for each ISAM separately. The external alarms profile can be assigned either to the NT, or to the remote LT (in case of a REM). Note this profile is only applicable for the external alarms.
4.7
Software and database management Software and database management is all about controlling the OSWP (Operation SoftWare Package) 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. A Push-Button Migration tool (PBMT) is delivered together with the ISAM software. This tool provides all the required functionality to migrate and/or upgrade an ISAM to a new software load, automating all the different steps of the software upgrade and migration process. The PBMT is expected to run on the same machine as the 5520 AMS, as the PBMT needs certain specific files for its proper execution. The PBMT is supported on both a Sparc and x86 platform (Solaris OS), delivered as one installation package. At run tim, the correct libraries and executables will be selected. Support is only provided for migrations to the target release (that is, the release for which the PBMT is delivered).
OSWP and databases The 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-26
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
Each package also consists of a set of system databases, more in particular the IHub 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. What, in case of GPON deployment, is not part of these packages however is the ONT software. All ONT software files are stored in a dedicated 1G partition on the compact flash (CF) of the NT. All ONT data, managed via the ISAM, is part of the IACM database: the ONT can have its own database as well, this however not being managed by/via the ISAM. The OLT software and database is part of the OSWP as described above. The link between the ONT type and/or a specific ONT instance and its (specific) ONT software is (persistently) stored in the ISAM MIB - the partition on the NT CF is only a storage for the ONT software files. Management of these software files (downloading to the ISAM, deleting, …) is done via an external manager, be it the 5520 AMS, the PBMT (Push-Button Migration Tool) or using CLI and/or TL1.
Software upgrade and migration Of 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 OSWP 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 change This 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 databases This 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 consists 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
In case of GPON, new ONT software is placed on the NT CF by the 5520 AMS, PBMT and/or using CLI or TL1, potentially together with a clean-up of older software files.
3
The operator starts an off-line conversion of the database from the source release to the destination release. It is the responsibility of the off-line migration tool to upload the complete database, convert it to the destination release and to download it to the node again. In case of new ONT software, the description of the to-be-used software version on the ONT, is updated in the database as well, as part of the off-line migration.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-27
4 — Management
4
In case of GPON, the ONT software is pre-downloaded to the ONTs at operator demand. The software is downloaded to the ONT via the OMCI channel, but is not activated yet on the ONT - also the ONT can have an active and a standby software load in parallel
5
When the new OSWP is downloaded, and, in case of GPON, the new ONT software is pre-downloaded to the ONTs, the operator activates this new OSWP. The system will restart and come up with an upgraded software version. All persistent configuration data remains available. Due to the new ONT software description in the ISAM database, the OLT will trigger the ONTs to restart with the new ONT software.
6
Once the upgrade is successful, the operator can remove the former OSWP from the system in order to free space for the next upgrade.
Some remarks:
• The ONT software is pre-downloaded to the ONTs using the OMCI channel, prior to the activation of the new OSWP. • The ONT software activation is triggered by the OLT, also using the OMCI channel. • OLT and ONT software activation are not coupled: OLT and ONT software can be upgraded independently if required. 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 OSWP and resume services. This also implies that the ONT will also re-start with the old, previous software, as the ONT software activation is triggered by the OLT, following the configuration settings done before. If the ONT itself fails to start with the new software load, the ONT will also re-start autonomously with the previous, old software load. The OLT software will NOT be restarted in that case. This implies that the ONT will not be able to support the services and features of the correct, new load, but, as the ONT becomes active again, a new load can be downloaded and the restart of the ONT retried. Note — Due to the introduction of a new version of the IPD stack (SROS ed.08) in R4.3.01, a R4.3.01 (or higher) ISAM database is NOT backwards compatible with a R4.3 ISAM database!
The necessary functionality has been added to make sure the R4.3 OSWP, with related (R4.3) database, can still be activated again, even after a successful R4.3.01 upgrade. The changes done with R4.3.01 will of course be lost as the R4.3 OSWP can -not- work with a R4.3.01 (or higher) version of the database. R4.3.01 (or higher) can work with any R4.3.x database; in case R4.3.01 (or higher) starts with a R4.3 version of the ISAM database, the R4.3 database will be upgraded first.
4-28
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
Backup and restore Next to a software upgrade and/or migration, database 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. These ISAM backups can afterwards be restored on the ISAM if needed. For IHub-based NT boards, only one type of backup can be taken, always containing all the ISAM configuration data and all the ISAM OAM data for remote management (such as the IP address, next-hop and so on). Note that in case of automatic backup enabled, the TFTP protocol cannot be used, as the TFTP protocols implies the file name to be known already up front at the server side. Given the format of the generated backup file name, this is however not possible. Alternatively SFTP or FTP can be used. 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 60 seconds, and/or • Whenever the cache of 5K is full (corresponds to 22 database updates), and/or • On request of an IACM application, for example 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 • IHub: the database changes are autonomously saved to CF • Every 10 minutes if the IHub configuration change, and/or • As part of an ISAM database backup request The IHub configuration data can be saved to NT CF (database) at operator request as well, for example, at the end of a IHub configuration script. This is however not possible for the IACM data. Note — Due to the introduction of a new version of the IPD stack (SROS ed.08) in R4.3.01, a R4.3.01 (or higher) ISAM database is NOT backwards compatible with a R4.3 ISAM database!
This implies that R4.3 can only work with a R4.3 version of the ISAM database and it is NOT possible to start R4.3 with a R4.3.01 (or higher) version of the database. R4.3.01 (or higher) can work with any R4.3.x version of the ISAM database; in case a R4.3 version of the database is detected, it will be upgraded to a higher version first. Practically this implies that R4.3 backups can also work with R4.3.01 or higher, but R4.3.01 (or higher) backups cannot work with R4.3.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-29
4 — Management
Active load The release name of the current active ISAM software package (for example, R3.6.01) can be consulted via EMS, TL1 and CLI.
Voice service management The behavior of POTS voice services on ONTs can be controlled by downloading a service configuration in XML format onto the ONT. This XML file can be sent to the ONT via the in-band communication channel, used to provide data service. In some cases, operators may require that the XML is downloaded to the ONT via the Management VLAN, in order to provide a higher level of security. This approach includes the following steps: 1
The Element Manager generates the ONT service configuration in XML format and makes it available on an FTP server reachable by the ISAM
2
The ISAM NT downloads the XML file from the FTP server
3
The XML file is sent to ONT using an internal OMCI channel
This approach is supported on Alcatel-Lucent Single Family Unit (SFU) and Multi-Dwelling Unit (MDU) ONTs that do not use TR-069 for voice provisioning.
4.8
Equipment monitoring
NT CPU load The average NT CPU load can be monitored using CLI, TL1 and/or an Element Management System. For IHub-based systems, only the IACM CPU load can be consulted this way: the IHub CPU load can be measured using an IHub dedicated mechanism (see the IHub configuration guides for more specifics). 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 usage The actual NT memory usage can be polled using CLI, TL1 and/or an Element Management System.
4-30
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
4 — Management
For IHub-based systems, only the actual memory usage of the IACM is counted: the memory usage of the IHub can be measured using an IHub dedicated mechanism (see the IHub configuration guides for more specifics). Moreover, in the IHub not all memory is allocated up front during the initialisation phase, but is rather dynamically allocated whenever there is a need: an out-of-memory alarm is generated when the IHub gets into memory problems. 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 data Thermal sensor data can be retrieved from each board equipped with thermal sensors and running software (so, for example, not from a passive splitter board). 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.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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
4-31
4 — Management
In the ISAM up to 62 ANCP partitions can be configured, each partition grouping a number of xDSL subscriber lines (excluding VDSL bonding interfaces; ANCP on SHDSL lines is only supported on NSLT-B). 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. The partition ID can be signaled to the BNG/BRAS in the ANCP packet header. Up to 62 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 ANCP protocol only runs in the context of the base router. 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 ANCP VLAN ID is fully configurable by the operator, and even multiple ANCP VLANs can be defined (the ANCP messages going to multiple VLANs). When using an MPLS-based access network, ANCP sessions can be established over an Ethernet Pseudowire (PW) (see Chapter “MPLS” for more details). The ANCP traffic can either be sent in a dedicated PW, or in the same PW used for data traffic. In the case of a shared PW, different VLAN IDs need to be used in order to make a distinction between the ANCP traffic and data traffic. An alarm is raised whenever the ANCP connection between BRAS and ISAM is lost for some reason.
4-32
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
5 — Line testing features
5.1 Overview
5-2
5.2 Metallic test access
5-4
5.3 Single-Ended Line Testing 5.4 Dual-ended line testing
5-7 5-8
5.5 Metallic-Ended Line Testing 5.6 ATM F5
5-9
5-11
5.7 Link Related Ethernet OAM 5.8 Narrowband Line Testing 5.9 SFP diagnostics 5.10 Embedded OTDR
5-12 5-14
5-17 5-18
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
5-1
5 — Line testing features
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 supports line testing for:
• • • • •
Ethernet network and subtending interfaces DSL interfaces (ATM or PTM mode) at the subscriber side Active Ethernet interfaces POTS and ISDN lines at the subscriber side xPON 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, or is integrated within the DSL board. 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.
5-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
5 — Line testing features
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) • Metallic-Ended Line Testing (MELT) • 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 • SFP diagnostics • tests for an Ethernet network or subtending interface: • SFP diagnostics • tests for an xPON interface: • SFP diagnostics • Embedded OTDR Note — 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 towards the subscriber line, and some are inward towards the MODEM/SLIC. Figure 5-1 Position line testing capabilities for DSL - POTS/ISDN lines
DSL applique RTU
(MTA)
Relays
DSL LT
Subscriber line
(SELT, DELT)
Modem
DSL line
LPF Towards PSTN or ISAM Voice
Voice LT SLIC (Narrowband line testing)
POTS/ISDN
Relays
line
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
Voice applique
November 2013
5-3
5 — Line testing features
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.
5-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
5 — Line testing features
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 outward towards the line and testing inward towards the LT equipment. Note — Only full MTA requires all the test access modes.
Figure 5-2 shows the test access modes. Figure 5-2 Test access modes Released
Loop around Line
Line Facility pair
Facility pair
RTU
RTU
xTU-C Equipment pair DSLAM
xTU-C Equipment pair
LPF
DSLAM
PSTN
LPF PSTN
Line Facility pair RTU
xTU-C Equipment pair DSLAM
LPF PSTN
Split access
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 towards 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 towards 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
5-5
5 — Line testing features Figure 5-3 Partial implementations of split-access mode
Limited outward access
Undisturbed outward access Line
Line Facility pair
Facility pair
RTU
RTU
xTU-C
xTU-C Equipment pair
LPF DSLAM
Equipment pair DSLAM
PSTN
LPF PSTN
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. 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 ensure that only one port in this daisy chain configuration is enabled at any one time
5-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
5 — Line testing features
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 pre-qualification and maintenance of the network. Note — See the 5530 Network Analyzer User Guide for more information about SELT using the 5530 NA.
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
5-7
5 — Line testing features
SELT support SELT measurements are supported on the following boards:
• multi-ADSL LT boards • VDSL LT boards • VDSL2 LT boards These boards can be located in the main subrack or in remote subracks (FD-REM, VSEM-D, …).
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:
• • • • • • 5-8
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) November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
5 — Line testing features
• • • •
5.5
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)
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 pre-qualification and maintenance of the network. Also basic management, to start measurements and report results, is provided through CLI. Note — See the 5530 Network Analyzer User Guide for more information about MELT using the 5530 NA.
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 (for example, due to cable moisture) detection of external voltages line pair identification detection of signature topologies
MELT support MELT measurements are supported on the following boards:
• multi-ADSL LT boards • VDSL LT boards • SHDSL boards The list of xDSL LT boards for which MELT testing is supported can be found in the Product Information manual.
MELT measurements ISAM limits to execute only one MELT session at a time at an LT board. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
5-9
5 — Line testing features
The following MELT tests are supported:
• Foreign AC voltage: Measures foreign AC voltage of a/Earth, b/Earth, and a/b. Result values:
• Measured AC Voltage of a/Earth, b/Earth, and a/b. • Measured AC voltage frequency of a/Earth, b/Earth, and a/b. • Foreign DC voltage: Measures foreign DC voltage of a/Earth, b/Earth, and a/b. Result values:
• Measured DC Voltage of a/Earth, b/Earth, and a/b • Capacitance: Measures capacitance of a/Earth, b/Earth, and a/b Result values:
• Measured capacitance of a/Earth, b/Earth, and a/b • Measurement AC voltage used for determining the capacitance of a/Earth, b/Earth, • •
and a/b Measurement AC voltage frequency used for determining the capacitance of a/Earth, b/Earth, and a/b On-board capacitance used for correcting the measured capacitance value of a/Earth, b/Earth, and a/b
• Insulating resistance: Measures insulating resistance of a/Earth, b/Earth, a/b and b/a. Result values:
• Measured resistance of a/Earth, b/Earth, a/b and b/a • Measurement DC voltage used for determining the resistance of a/Earth, b/Earth, a/b and b/a.
• Measurement DC current used for determining the resistance of a/Earth, b/Earth, a/b and b/a.
• • • • • • • • •
Termination detection: detects whether a termination circuit connects to the line Cable Pair identification (search tone generation) Hazardous voltage (DC>120V or AC>50V). Galvanic Signature Detection (For ADSL/VDSL; not for SHDSL). End Device Capacitance Detection. PPA Detection (ppa / ppa-invers / ppa-not-detected / analysis-not-available) ROH Detection (For ADSL/VDSL, not for SHDSL) Conductance (a/Earth, b/Earth and a/b). Susceptibility (a/Earth, b/Earth and a/b).
Enhanced MELT Test result reporting offering the following information:
• The time stamp the MELT test has finished • The remaining time the search tone will be played (Cable pair Identification) • Validity flag indicating whether the result of a MELT test: • was not taken or the result is not reliable • was taken and the result is reliable. • Textual clarification of the returned MELT test result status.
5-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
5 — Line testing features
The MELT Group test capability supports the following execution modes:
• Legacy MELT Group test including • Foreign DC Voltage • Insulating Resistance • Capacitance • Capacitance Of Signature • Resistance of Ringer and only providing the MELT test results.
• MELT Group test with extended reporting including • Foreign DC Voltage • Insulating Resistance • Capacitance • Capacitance Of Signature • Resistance of Ringer and providing the MELT test result values together with the conditions (Used AC/DC voltage, frequency, calibration capacitance) under which the tests were executed • MELT Collective Group test including
• • • • • • • • • • • •
Foreign AC Voltage Foreign DC Voltage Insulating Resistance Capacitance Capacitance Of Signature Resistance of Ringer Conductance Susceptibility PPA Detection Galvanic Signature Detection End Device Capacitance Detection ROH-Detection
and providing the MELT test result values together with the conditions (Used AC/DC voltage, frequency, calibration capacitance) under which the tests were executed Further on, the capability is offered to request:
• The Chipset Vendor Identity / HW version / FW version • During MELT session execution, an overview of the busy ports and busy reason (awaiting execution, execution on-going, playing search tone, test finished).
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 Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
5-11
5 — Line testing features
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 7302 ISAM or 7330 FTTN CPE IEEE802.3 clause 57 (Link Ethernet OAM)
General description Link-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). 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 ISAM 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 function 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. The ISAM supports some Link-related Ethernet OAM functions on its Ethernet and EFM user interfaces, that is, on interfaces terminated on LT boards.
5-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
5 — Line testing features
Link-Related Ethernet OAM procedures The following sections describe the different Link-Related OAM procedures, 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 cross 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 supports 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
5-13
5 — Line testing features
The ISAM reports reception of following critical events from peer:
• Dying Gasp • Critical Event • Link Fault 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 Ethernet line card supports a method to invoke remote loopback at the peer end. The looped back traffic can be monitored using performance counters at the Ethernet physical layer of the line card. ISAM does not support generation of test traffic towards the peer and relies on network traffic (or an upstream device) to be used during loopback. As an active DTE, ISAM ignores any remote loopback request received from the peer. GPON / DSL LT boards do not support invocation of remote loopback at the peer end.
5.8
Narrowband Line Testing Narrowband Line Testing provides a set of tests for the narrowband on POTS/ISDN subscriber lines, to tests the line from the SLIC on the Voice LT board. Narrowband line testing support is LT board hardware and software dependent. 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 and 5520 AMS. Narrowband line testing is supported for:
• POTS/ISDN LT boards operating in the H.248 environment • POTS LT boards operating in the SIP environment.
5-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
5 — Line testing features
Line testing support on POTS The following test can be performed with the narrowband line testing feature (on POTS (H.248 and SIP):
• 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 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, a/battery, b/battery, and a/b.
• Impedance: measures the impedance of a/Earth, b/Earth, and a/b. • 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: for NPOT-A a resistor, loading the wires, is connected and the • •
current in limiting mode is measured. For NPOT-B and NPOT-C, the system will measure the real feeding current on the subscriber line. Noise level: detects abnormal noise level, for example, crosstalk Longitudinal current (Supported on NPOT-B and NPOT-C, SIP only)
• 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
• Detection of electronic ringers. Two types of electronic ringers can be detected (Supported on NPOT-B and NPOT-C, SIP only). • Termination (M-Socket) detection) Detects if the line is connected by an M-socket (470k ohm resistance in series with a diode) or a resistance. • 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. 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. For H.248 the MGC then interprets it as a real off-hook and sends a dial tone. For SIP, ISAMV will generate a dial tone upon receiving the off-hook event. The time is measured and compared with a predefined threshold. Returned result is the delay-to-dial tone.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
5-15
5 — Line testing features
• 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 time-out. 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. • Talking tests are supported on ISAM, but not on NA5530. The following tests are supported:
• • • • • •
Talking with Subscriber Subscriber Private Meter Pulses Resistance of user's loop (AB) Line Reverse Ring Subscriber with Auto Ring Trip DP/DTMF Signal
• 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, the operator can repeat the test item after the last test result is reported to it. This mode also accepts only one electrical test item in each session.
Line testing support on ISDN ISDN line test is only supported in H.248 environment. The following tests can be performed with the narrowband line testing feature on ISDN (H.248):
• 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
•
5-16
Self test on layer 1 by the ISAM-V: ISAM-V generates a test pattern and activates a loopback at the LT + verification and evaluation of received test pattern. Test towards the NT/NT1: ISAM-V generates a test pattern and activates a loopback at the NT + Verification and evaluation of received test pattern Only when the transmitted and received patterns are exactly the same, the test is considered as passed. The test pattern is hard-coded (NOT configurable). Precondition for executing ISDN BA loop back test: The ISDN BA loop back test will be rejected in case the ISDN B channel would be busy. Otherwise the ISDN BA loop back test (including loopback test to the NT board and loopback test to the LT board) will be accepted and executed (on condition that the ISDN user port has been provisioned).
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
5 — Line testing features
• ISDN electric line tests: • Foreign voltage (AC/DC): measures foreign voltage of a/Earth, b/Earth, and a/b • Resistance: measures insulating resistance of a/Earth, b/Earth, a/b and b/a • Capacitance: measures capacitance of a/Earth, b/Earth, and a/b • Precondition for executing ISDN electric tests: The tests should be supported in any port status except for line busy.
Extended Test modes The following extended test modes can be performed:
• Block Reading Mode: One extended new test mode (only for Foreign Voltage AC/DC, Capacitance, Insulation Resistance) for the basic POTS 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 POTS electrical test types, in one test session, the operator can repeat the test item after the last test result is reported to it. This mode also accepts only one electrical test item in each session. Note — Both extended test modes are not supported on ISDN.
Enhanced NBLT result reporting (SIP based VoIP service only) The NBLT result reporting offers the following additional information:
• The time stamp the NBLT test has finished • The remaining time the search tone will be played (Cable pair Identification) • Textual clarification of the returned NBLT test result status. Further on, the capability is offered to request during NBLT session execution, an overview of the busy ports and busy reason (awaiting execution, execution on-going, playing search tone, test finished).
5.9
SFP diagnostics SFPs are used to terminate network, subtending, inter-shelf, line board Ethernet interfaces or xPON. The ISAM supports the digital diagnostics function in line with SFF-8472. 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. This diagnostics functionality is available on all SFP, SFP+ and XFP interfaces of the ISAM system.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
5-17
5 — Line testing features
5.10
Embedded OTDR Optical time-domain reflectometry (OTDR) is an opto-electronic measurement technology used to characterize an optical fiber plant. Classical OTDR uses external measuring equipment which injects a series of optical pulses into the tested fiber. From the same end of the fiber the equipment then extracts light that is scattered (Rayleigh backscatter) or reflected back from points along the fiber. OTDR may be used for estimating the fiber length and the overall attenuation, including splice and mated-connector losses. OTDR is also commonly used for fault finding on installed systems. Figure 5-5 shows the main advantages of the embedded OTDR solution.
• the easy deployment • the integrated management • the OTDR measurements are possible without the requirement for expensive external test equipment
• the measurement capability is always available and is non-service affecting • the measurements do not require an operator to be on-site Figure 5-5 Embedded OTDR main advantages GPON OLT
Fibre coupler (signal attenuated) Splitter
F1 Optical switch
Filter at ONT to block OTDR signal
F2
ONT λ OTDR
Analysis tool
OTDR 1310
1490
1625 nm
GPON OLT Splitter
F1 F2
Embedded OTDR SFP
Network analyzer
1310
ONT
1490 Also used as λ OTDR
The ISAM supports SFPs for GPON and EPON interfaces that have an embedded OTDR capability, allowing OTDR measurements without the requirement for expensive external test equipment. Therefore, the measurement capability is always available, is non-service affecting and does not require an operator to be on-site. The 5530 NA-Fiber provides the necessary support to interpret the results of the OTDR measurements.
5-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
6 — Network timing reference support in ISAM
6.1 Introduction
6-2
6.2 ISAM clock system and NTR extraction 6.3 Downstream NTR clock distribution 6.4 Applicable standards
6-6 6-16
6-17
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
6-1
6 — Network timing reference support in ISAM
6.1
Introduction
Scope This 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. This section focuses on both the 24G NT family and the 100G/320G NT + FX NT family. Whether or not an NTR function is supported is board dependent rather than family dependent. This is the rationale to cover both families. Example: SyncE is supported on some board variants in the 100Gbps/320Gbps NT family, but is not supported on the cheaper ones. And while SyncE is not supported on most boards in the 24Gbps NT family, it is supported on the NRNT-A board (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 fewer or no NTR capabilities are available. These can be used for deployments where these capabilities are not needed. The next section will clarify this at a high level.
Applications as driver for specific clock or NTR requirements This 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). For these applications the usual and less complex NTs and LTs are sufficient for network deployments. Each access technology (ADSL, VDSL2, SHDSL, Ethernet, GPON and EPON) 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 PON)(1)
Required on NT
Required on LT
High Speed Internet (HSI),
External NTR source: not required
Video,
Local Clock Accuracy: low (32 or 50 ppm is sufficient)
All LTs are suited, that is, no specific clock requirements on LT.
Packet Voice (1 of 2)
6-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
6 — Network timing reference support in ISAM
Application (over DSL, Ethernet or PON)(1) Voice via POTS line
Required on NT
Required on LT
External NTR source: not required
All voice LTs are suited, that is, no specific clock requirements on LT.
Local Clock Accuracy: 4.6 ppm is required Long fax or modem calls via POTS line
External NTR source: SyncE In or BITS In
All voice LTs are suited, that is, 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.
External NTR source: not required
All LTs are suited, that is, no specific clock requirements on LT.
Mobile backhaul data offload
•
Local Clock Accuracy: low (32 or 50 ppm is sufficient) Full mobile backhaul (with frequency synchronization)
External NTR source: SyncE In or BITS In
Alternatively, SyncE output on an Ethernet LT.
•
• •
Full mobile backhaul with phase synchronization or ToD requirement
DSL LTs: NTR on VDSL2 or SHDSL (Note: NTR on ADSL is not supported on DSL-LTs) Ethernet LTs: SyncE out PON LTs: no specific clock requirements on LT (Note: ONT with BITS out or SyncE out needed)
Not supported.
Not supported. Note: Phase synchronization or ToD is only required for some mobile applications, and even then in most cases an alternative option exists 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/ GNSS receiver)
Packet-based Business applications
External NTR source: not required
Business applications with NTR requirements (for example, TDM leased lines)
External NTR source: SyncE In or BITS In
Local Clock Accuracy: low (32 or 50 ppm is sufficient)
All LTs are suited, that is, no specific requirements on LT.
• • •
DSL LTs: NTR over SHDSL or VDSL2 Ethernet LTs: SyncE out PON LT: no specific clock requirements on LT
(2 of 2) Note (1)
DSL is a generic term in this chapter referring to ADSL, ADSL2, ADSL2+, VDSL2 and SHDSL. PON is a generic term in this chapter referring to both GPON and EPON
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
6-3
6 — Network timing reference support in ISAM
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 PON LTs, there are no specific requirements, since the framing of PON 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). 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. It depends very much on the selected technology which will be used in a mobile network, if phase synchronization or ToD will be possibly required there. 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/ GNSS). 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), please 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 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. 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 somewhat 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 and may therefore require echo-cancellation for interactive services (for example, voice or video calls).
Overview of NTR support on ISAM Table 6-1 made clear that NTR is not required for all applications. However, in some cases it is required. Figure 6-1 and Figure 6-2 give a high-level view on the supported options on NT boards and LT boards for the FD 24Gbps family and the FD 100/320Gbps NT and FX NT family, respectively.
6-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
6 — Network timing reference support in ISAM
Sync Eth
8 kHz 8 kHz
GE PHY
NRNT -A
Optional GE network
8 kHz 8 kHz
DSL
backplane backplane
DSL
POTS/ISDN
NTR DSL
POTS/ISDN
SEM/Distributed REM
8 kHz
Eth
POTS/ISDN
backplane
NT
Hub ISAM
Sync Eth
NT
DSLLT Voice DSL LT
CTRL
Eth
NTR
8 kHz backplane
DSL LT
backplane
backplane backplane
NTIO
8 kHz
8 kHz 8 kHz
GE PHY
DSL LT
NT
Sync Eth GE PHY NTR DSL
GE PHY Voice
NTIO
8 kHz backplane
Sync Eth
Voice
8 kHz
G.703
8 kHz 8 kHz backplane backplane
NTR
GE PHY backplane
BITS
backplane backplane
Standalone REM
Sync Eth
BITS G.703
DSL Voice DSL LT LT
Figure 6-1 Overview of possible NTR support on some LTs and some NTs in the FD 24Gbps NT ISAM family
8 kHz
7330 RA
backplane
Optional PDH/SDH network
POTS/ISDN
BITS G.703 Outdoor ISAM
Optional PDH/SDH network
Collocated ISAM shelves
GPON
8 kHz backplane
Eth
NT
Optional GE network
GPON PHY GPON Sync Eth GE PHY
8 kHz backplane 8 kHz backplane
8 kHz backplane
NT NT
BITS or Sync Eth G.703 GE PHY
Sync Eth GE PHY
Sync Eth GE PHY
DSL LT
POTS/ISDN
Sync Eth GE PHY
POTS/ISDN
SEM/Distributed REM Sync Eth GE PHY
Hub ISAM
8 kHz backplane
NTR DSL
Voice
8 kHz backplane
NTR DSL
DSL LT
8 kHz backplane
DSL LT
NTIO
NT
Sync Eth GE PHY
8 kHz backplane
Voice
Eth
Sync Eth GE PHY
CTRL
8 kHz backplane
8 kHz backplane
BITS G.703
NTIO
GPON
GPON PHY GPON
Voice
Figure 6-2 Overview of possible NTR support on some LTs and some NTs in the FD 100/320Gbps NT ISAM family
BITS G.703
NTR DSL
POTS/ISDN Sync Eth GE PHY
Outdoor ISAM
The FX NT supports in addition also IEEE1588 as NTR source as indicated in Figure 6-3.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
6-5
6 — Network timing reference support in ISAM
Sync Eth GE PHY
Optional GE network IEEE1588 GE
IEEE1588 GE
GPON
Sync Eth GE PHY
8 kHz backplane
GPON PHY GPON
8 kHz backplane
GPON
Hub ISAM
Sync Eth GE PHY
GPON PHY GPON
8 kHz backplane
GPON PHY GPON Sync Eth GE PHY Sync Eth GE PHY
8 kHz backplane
NT
BITS or Sync Eth GE PHY G.703
GE PHY Sync Eth GE PHY
GPON
8 kHz backplane
IEEE1588 GE
GPON PHY GPON
Eth
8 kHz backplane
GPON PHY GPON
NT
NTIO
NT
Sync Eth GE PHY
GPON PHY GPON
NTIO
8 kHz backplane
GPON GPON GPON
8 kHz backplane
BITS G.703
Eth
Figure 6-3 NTR options for FX NT ISAM family
NT
Optional PDH/SDH network
BITS G.703 Outdoor ISAM
Collocated ISAM shelves
Note — For an overview of which NT boards and which LT boards support the required synchronization functions, refer to the Product Information document of your system and/or the Unit Data Sheet (UDS) of that board.
Although not shown in these figures, also deployments with a mix of nodes are possible from both figures. For example, a standalone REM connected via SyncE to an Ethernet output on an Hub ISAM with NT from the FD 100/320Gbps NT and FX NT family. Note — The distributed REM requires a fiber connection per LT board for the data transport. However, only the fiber to LT1 transports the NTR signal, which is then distributed in the REM to both LT boards. Hence, when that fiber link is broken, the NTR features described in this chapter are not fully supported anymore for all lines in that distributed REM.
6.2
ISAM clock system and NTR extraction
High level description of the external port selection for NTR Figure 6-4 gives a high level description on how the external port is selected that will be used for NTR extraction. This is valid for BITS, SyncE and IEEE1588 which are linked to physical ports.
6-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
6 — Network timing reference support in ISAM
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 then form a subset of the total number of external ports (see Figure 6-4). Figure 6-4 Port selection for external NTR (SyncE and BITS) Ports which support synchronisation input (BITS, SyncE or IEEE1588)
RJ45-a RJ45-b SFP-1 … … SFP-n XFP-1 … … XFP-m
HW design of specific card
RJ45-a RJ45-b SFP-f … SFP-g XFP-r ... XFP-s
Static configuration on ISAM
Static selection of 2 ports for NTR input
T U
ISAM clock system operation
Dynamic selection of 1 port for NTR
R ef e renc e =R
External ports on NT-A, (NT-B and NTIO)
Clock distribution on ISAM backplane to LTs and then to access lines
Note: RJ45-a is the connector for BITS-A on NT-A RJ45-b is the connector for BITS-B on NT-B
The operator needs to configure which of these ports are valid inputs for NTR in his network deployment. Maximum two ports can be configured for this (T and U in Figure 6-4). The ISAM clock subsystem will then dynamically select one of these two 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.
Possible External NTR sources The 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. 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
6-7
6 — Network timing reference support in ISAM
• 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 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. • One or more PTP (also known as IEEE1588v2) clock sources: This is a packet-based clock synchronization method using Ethernet packets. Next to support for frequency synchronization this protocol also provides support for time synchronization over a packet network. ISAM currently only supports frequency synchronization. Figure 6-1, Figure 6-2 and Figure 6-3 give a high-level view of the possible interfaces to external NTR sources for the FD 24Gbps NT family, the FD 100/320Gbps NT family and the FX NT family, respectively. More detailed information on the actual capabilities of specific boards is available in the Product Information document for your product 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 operation Figure 6-5 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 and IEEE1588. Figure 6-5 ISAM configuration for NTR provisioning with single NT. SFP
NT Front plate 1 GE Ethernet Sync Eth out
LT 1 Sync Eth out
µP
SFP
NT Front plate 1 / 10 GE Sync Eth in
SFP+ SFP
NTIO Front plate 1 GE Sync Eth out SFP SFP
Sync Eth out
PHY
PTP IEEE 1588
1 GE NTIO T3 : BITS /SSU 1 in NTIO Front plate 10 GE Sync Eth in Sync Eth out
XFP
S E L
TC/ OC XO
NTR clock generation
SFP
LT 18
PHY
NTR clock source selection
NTIO Front plate 1 GE Sync Eth in Sync Eth out
T4 : BITS/SSU 1 out T0 8 kHz NTR 1 to LT 1 -18
XFP
10 GE NTIO
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. 6-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
6 — Network timing reference support in ISAM
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: Overview When 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-6), 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”) Figure 6-6 States and state transitions for the internal NTR clock
AUTONOMOUS MODE Holdover mode - freeze holdover memory - lock clock to holdover memory No valid reference nor memory available
Free-run mode - rest holdover memory - free-run clock Valid reference available
Locked mode
Configure autonomous mode
No valid reference nor memory available
FORCED FREE-RUN MODE
- update holdover memory - lock clock to selected reference
Free-run mode Configure forced free-run mode
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
- rest holdover memory - free-run clock
November 2013
6-9
6 — Network timing reference support in ISAM
Clock protection: External NTR source protection 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 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. • Not locked on PTP packet stream (IEEE1588) 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 hardware-ready to support this type of BITS input redundancy, but up to this release, software support for this has been implemented on NANT-A and NANT-D 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. • IEEE1588: the PTP circuitry on the NT can perform the Best Master Algorithm on three different, configured PTP Masters, but it can track only one of these actively. Therefore, actively tracking two redundant Grand Masters will require a redundant NT pair. Resilience with respect to L2 connectivity can be guaranteed via the usual means like LAG. The clockClass field in the PTP messages is not used by the ISAM. Any mix of BITS and SyncE is supported when both inputs are on the same NT, or on one NT and NTIO. For example, BITS as the reference for NTR, while SyncE as NTR source protection. Note 1 — IEEE1588 cannot be mixed with BITS or SyncE. Note 2 — The reception of PTP frames on an NTIO port is not
supported on IEEE1588. 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 or IEEE1588.
6-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
6 — Network timing reference support in ISAM
Clock protection: NT redundancy Also 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. The following restrictions have to be 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 hardware fails or is removed. The BITS signal on the NT in stand-by mode can be monitored • 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. In this way, also SyncE input redundancy can be supported. • In case IEEE1588 is applied, both the active and the standby NT can actively track one PTP Grand Master out of the maximum three devices configured per NT. Full clock redundancy is also supported in PTP mode. 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.
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 • IEEE1588 • 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 and IEEE1588 interface, this setting cannot be changed (that is, the QL is to be configured statically by the operator). • 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).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
6-11
6 — Network timing reference support in ISAM
• 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, Synchronous Ethernet and/ or IEEE1588 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 Not locked on PTP packet stream (IEEE1588)
• Unavailability of all nominated external NTR clock sources for the reasons mentioned above, 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.
6-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
6 — Network timing reference support in ISAM
In the default NTR switching mode (revertive mode), the ISAM selects the most appropriate NTR clock source for synchronizing its output NTR signals, 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 IEEE1588 interface receiving PTP messages from Master(s) over any external interface.
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
6-13
6 — Network timing reference support in ISAM
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 to 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 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 too. 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: IEEE1588
The following needs to be configured for IEEE1588:
• The IEEE1588 interface as well as the external interface on which PTP messages will be received have to be attached to a L2 forwarder. • Host IP address of the IEEE1588 slave and gateway IP address + mask • Host IP address and priority of acceptable Master(s) from which PTP messages will be received and used as external NTR clock source. • IEEE1588 protocol specific parameters (PTP Domain and mode) 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.
6-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
6 — Network timing reference support in ISAM
• 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)
Synchronization Status Messages (SSM) are required to allow the downstream element that requires synchronization to know the quality of the upstream clock. Typically, it allows a downstream element which has the choice between different upstream clocks to select the one with the best quality, or the one which meets the minimum required quality. Even when there is only one upstream clock available, such as, for example, in the case of a mobile base station connected to a DSL line, SSM has value. If SSM indicates that the quality of the upstream clock degrades below the quality of the local clock of the base station, the latter can switch to the local clock for synchronization. More information about SSM can be found in G.781 with extensions for Synchronous Ethernet in G.8264. Several commands exist to enable or disable the support of the Synchronization Status Message (SSM):
• enable or disable the handling of received SSM messages on ports configured as NTR clock source(s). • enable or disable transmitting SSM messages per port, and this for the following cases:
• Synchronous Ethernet output ports on NT cards, NTIO cards and NELT-B • VDSL2 ports and SHDSL ports on some LT cards (only SSM transmission and not SSM reception). And then it is only supported in EFM mode and not ATM mode.
The system factory default is “disable”. SSM is not supported for BITS-A, BITS-B and IEEE1588. 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 was synchronized previously to an external NTR clock source.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
6-15
6 — Network timing reference support in ISAM
Status: nominated NTR clock status
This command allows the operator to query the status of the NTR clock source(s). The following command results are listed:
• the NTR clock source: BITS-A (on NT-A), BITS-B (on NT-B), Sync Eth 1 (from NT or NTIO), Sync Eth 2 (from NT or NTIO), IEEE1588-A (on NT-A), IEEE1588-B (on NT-B), 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:
• • • • • • • • • • • •
6.3
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 time-out). UNKNOWN: the clock status is unknown (start-up, system fault). FORCED: the clock is manually selected. NO_SYNCE_CONFIG: the synchronization source is not bound to a physical port. NO_SYNCE_SUPPORT: the syncE is bound to a port that does not support syncE clock extraction. 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 syncE 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).
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-7 NTR distribution over access lines for different services Mobile backhauling Accurate synchronization of base stations
ISAM Network Timing Reference
High-stability clock on NT BITS interface on NT NTR support on LTs
6-16
November 2013
Network Timing Reference
Leased lines Cost-effective central clock for synchronization of all CPEs Voice High-stability clock for long-lasting fax and modem calls
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
6 — Network timing reference support in ISAM
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. In the normal default case, the BITS out on the NT board is filtered by the SETG function (see Annex 7 in G.8262/G8264) in order to achieve compliance to G.813 option 1 for BITS out. But alternative configurations of the ISAM clock system are possible as suggested in Annex7 in G.8262/G8264, allowing that the SyncE input(s) are passed through unfiltered to the BITS output. Typically the unfiltered BITS output will then be connected to an SSU device. 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 • EPON 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 FD NT family, the 100Gbps /320Gbps FD NT family and the FX NT family is represented in Figure 6-1, Figure 6-2 and Figure 6-3 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.2 NTR for SHDSL is supported on selected ISAM SHDSL Line Termination board types. • Output NTR clock support on VDSL2 lines: ITU Rec G.993.2 NTR for VDSL is supported on selected ISAM VDSL Line Termination board types. • Output NTR clock support on POTS lines: Not Applicable An analogue POTS interface does not provide a clock signal in downstream direction
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
6-17
6 — Network timing reference support in ISAM
• Output NTR clock support on Synchronous Ethernet lines: ITU Rec G.8261/Y.1361 NTR 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 fully compliant 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 - ETSI/ANSI PTP: ITU-T G.8261 (note: PDVs indirectly specified by means of network topologies and traffic models)
• NTR management, including SSM: ITU-T G.781 781 Option 1 to a large extent • SSM transport • BITS / SSU: ITU-T G.704 (1998) •
6-18
ISAM 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
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
7 — xDSL features
7.1 Overview
7-2
7.2 Configurable impulse noise protection 7.3 RFI Notching
7-4
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 Impulse noise monitor 7.9 Virtual noise
7-9
7-10
7-10
7.10 Physical Layer Retransmission (RTX) 7.11 Per-line configuration overrule
7-12
7-13
7.12 Configurable US/ DS memory split 7.13 Vectoring
7-3
7-14
7-14
7.14 Fall-back configuration for vectoring
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
7-17
November 2013
7-1
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 and ONUs. Table 7-1 Supported xDSL features Feature
xDSL LT
Configurable impulse noise protection
xDSL ONU
ADSL
ADSL2
ADSL2+
READSL2
VDSL2
VDSL2
X
X
X
X
X
X
X
X
RFI Notching
X
Low-power modes
X
X
X
X
X
X
X
X
X
X
X
Seamless rate adaptation
X
X
X
X
Upstream power back-off
X
X
X
X
L2 low-power mode L3 idle mode
X
X
UPBO policing
X
Equal RXPSD UPBO
X
Equal FEXT UPBO
X
Downstream power back-off
X
X
Virtual noise
X
Per-line configuration overrule
X
X
X
Impulse noise monitor
Physical Layer Retransmission (RTX)
X
X
X
X
X
X
X
X
X
Configurable US/ DS memory split
X
Vectoring
X
Fall-back configuration for vectoring
X
X
X
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 VDSL2 Profile
xDSL LT
8a, 8b, 8c, 8d
X
12a, 12b
X
17a
X
30a
7-2
November 2013
xDSL ONU
X X
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
7 — xDSL features
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. Table 7-3 Supported VDSL2 bandplans VDSL2 Bandplan
xDSL LT
xDSL ONU
Region A(1) 998
X
X
Region B(2) 998
X
Region B 998E
X
X
Region B 998ADE
X
X
Region B 997
X
Region B 997E
X
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 modems can be trained at initialization to achieve these quality levels in the presence of stationary 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-Solomon Reed-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. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
7-3
7 — xDSL features
Interleaving Instead 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 mode First-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-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
7 — xDSL features
To address these concerns, the ADSL2/ADSL2+ standards define L2 low-power mode in addition to the full power mode (called “L0” power mode). This power management mode helps reduce the overall power consumption while maintaining the ADSL “always-on” functionality for the subscriber. 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 downstream 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. In the L2 mode, only the downstream data rate is lowered. The data rate of the upstream remains unchanged. This because in ADSLx the downstream transmitter constitutes a much larger consumer of power than the upstream transmitter. 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. With the support of the enhanced L2 defined in ITU-T G.992.3 (2009) Amendment 4, it is now possible to use:
• Extended range of Lp values in the L2 low power mode: This allows to support higher bit rates in low power mode, thus limiting the delay incurred by delay-sensitive services, or to support higher bit rate services while maintaining high levels of power saving. • Extended range for the Gi gain scaling in L2 low power mode: This provides finer control of power reduction via Gi scaling, leading to better power savings than previously possible with flat power reduction only.
L3 idle mode This mode enables overall power savings at both the XTU-C and the remote xDSL transceiver unit (XTU-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 xDSL connection. When the subscriber goes back on-line, the line has to be re-initialized to enter the L0 state 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).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
7-5
7 — xDSL features
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. Figure 7-1 L2/L3 power modes Initialization
Showtime
Low traffic causes switch to L2
(L0)
Resynchronisation or L3 Power mode
Resynchronisation or
IDLE (L3)
7.5
L3 Power mode
High traffic causes switchback to L0
“Low Power” “Low Power” Showtime (L2) Showtime (L2)
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 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. The upshift and downshift noise margin thresholds and time intervals for SRA are fully configurable. Figure 7-2 illustrates SRA.
7-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
7 — xDSL features Figure 7-2 Seamless Rate Adaptation Maximum Noise Margin Increase data rate if Upshift time interval has elapsed Upshift Noise Margin
Increase data rate
Target Noise Margin Downshift Noise Margin Decrease data rate if Downshift time interval has elapsed
Decrease data rate
Minimum Noise Margin
0 dB Margin
The upshift and downshift rate adaptation events due to SRA are counted in 15-minute and 24-hour Performance Monitoring (PM) intervals. SRA can encounter upshift and downshift limitations on lines activated with interleaving:
• ADSL2(+): The SRA protocol can only change parameter L (number of bits per DMT symbol). SRA downshifts are limited by the configured maximum interleaving delay as SRA downshift results in an increase of the delay. SRA upshifts are limited by the configured minimum impulse noise protection as SRA upshift results in a decrease of the impulse noise protection. • VDSL2: The SRA protocol can change both parameter L (number of bits per DMT symbol) and parameter D (interleaving depth). This allows to keep the delay and impulse noise protection constant after a rate adaptation. When all allocated interleaving memory is used, upshift rate adaptations are still limited by the configured minimum impulse noise protection.
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
7-7
7 — xDSL features Figure 7-3 Far end cross-talk
NE short loop
FEXT
CPE
long loop
CPE
weak Rx signal; strong FEXT signal from short loop
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.
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 UPBO This 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. 7-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
7 — xDSL features
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. 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.
Remote Terminal
PSD
Figure 7-4 Crosstalk in mixed CO-RT deployment
Customer Premises frequency
Central Office
CO
Remote Terminal
PSD
PSD
NT
PSD
NT
RT
frequency
frequency
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
7-9
7 — xDSL features
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 ADSL2+ and VDSL2.
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 US
xTU-C Impulse Noise Sensor
Indication of xTU-R Severely Degraded Data DS Symbols EOC Impulse Noise anomalies INM Anomaly
Sensor
Counters
INM Anomaly Counters
INM PM counters 15min and 24h
INM PM counters 15min and 24h
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).
7-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
7 — xDSL features
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). 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. In 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. Figure 7-6 Virtual noise concept Loop attenuation
VN Breakpoints DS/US VDSL2
[Loop attenuation]
CPE
DSLAM
Received Noise US
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
Received Noise DS
November 2013
7-11
7 — xDSL features
7.10
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-7:
• 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. Figure 7-7 DSL physical layer retransmission concept
?? DTU
CPE
DTU DSLAM
7-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
7 — xDSL features
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.11
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 a small 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-8. Figure 7-8 Per-line configuration overrule
XDSL Profiles
Parameter 1
Actual configuration
Parameter 2
…
Parameter 3
…
Parameter 1
Parameter N
Parameter 2
merge
Parameter 3
…
XDSL per-line overrule parameters
Parameter N
Parameter 2 Parameter N
This 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
7-13
7 — xDSL features
For bonded XDSL lines, the data rate, impulse noise protection and delay configuration of the individual lines are derived from the bonding profile parameters. A subset of the per-line configuration overrule parameters related to data rate, impulse noise protection or delay will also be taken into account for bonded lines:
• Maximum data rate • Minimum Impulse Noise Protection
7.12
Configurable US/ DS memory split The aggregate interleaver or G.inp (G.998.4) memory supported for the different VDSL2 profiles is defined by the VDSL2 standard (G.993.2). This aggregate memory has to be split in the upstream and downstream direction, making a trade-off between upstream and downstream data rate. By default, a vendor discretionary algorithm is used to determine the memory split between upstream and downstream. The configurable US/DS memory split feature gives the operator manual control of the memory split. The percentage of memory allocated to the downstream direction can be configured in steps of 1 percent. The remaining memory is automatically allocated to the upstream direction. By manually configuring the VDSL2 memory split, the operator has full control and can make a better trade-off between upstream and downstream performance in case the automatic algorithm does not provide the expected results.
7.13
Vectoring VDSL2 vectoring takes full advantage of existing copper binders by making conditions in the field as close to ideal as possible. Vectoring is not a method for raising the theoretical maximum transport speeds. Instead, this noise-cancellation technology addresses the gap between the theoretical maximum rate and the speeds that service providers can deliver in typical field conditions. In most deployments, telephone lines that carry VDSL2 signals are part of cables (sometimes partitioned in smaller cable bundles) that contain 10 to a few hundred lines positioned very closely together. This close proximity results in crosstalk, and the higher the number of lines in a cable (bundle), the more crosstalk is generated. Crosstalk is the main reason why lines in the field perform significantly lower than their theoretical maximum. Vectoring enables each line to perform as if it is alone, that is, without crosstalk. In a dynamic process, vectoring continually measures and cancels this “crosstalk”, so all lines can operate at much higher capacity, as shown in Figure 7-9.
7-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
7 — xDSL features Figure 7-9 Typical vectoring gains 120
Optimal VDSL2 performance 100
Mbps
80
Near-optimal field performance with vectoring
60
40
20
Reduced field performance due to crosstalk
0 100
200
300
400
500
600
700
800
900
1000
1100
1200
Although most of the processing and necessary intelligence for vectoring resides in the Digital Subscriber Line Access Multiplexer (DSLAM), minimal support is needed at the Customer Premises Equipment (CPE) for the efficient estimation of the crosstalk from the line into the neighboring lines and vice versa. This additional functionality at the CPE side is defined by the International Telecommunication Union (ITU) vectoring standard, G.993.5 (G.vector). In order to achieve the full vectoring gain, all VDSL2 lines in the cable need to participate in the crosstalk estimation. Otherwise, the crosstalk from some lines will remain un-cancelled, reducing bit rates on vectored lines. The ultimate situation is where all VDSL2 lines operate in G.vector mode. Most of the existing VDSL2 CPEs in the field can be software upgraded to support vectoring, or to be at least “vectoring-friendly”. The latter has been defined by the ITU in Annexes X and Y of the VDSL2 standard (G.993.2) and allows the crosstalk from the legacy line into the neighboring vectored lines to still be measured. Annex X defines requirements for downstream friendliness such that the crosstalk from the legacy line into the neighboring vectored lines can be estimated and cancelled in downstream direction only. Annex Y defines requirements for full friendliness, allowing estimation of crosstalk from the legacy line into the neighboring vectored lines in up- and downstream direction. In principle, “friendly” customers do not benefit from vectoring gains but their equipment no longer impairs vectoring for subscribers who are paying for this enhancement. For legacy VDSL2 CPEs that cannot be upgraded to support vectoring or vector-friendliness, the “Zero-Touch Vectoring” feature can optionally be enabled to cancel the crosstalk from such legacy line into the neighboring vectored lines (in downstream direction only).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
7-15
7 — xDSL features
Depending on the deployment scale (that is, the considered VDSL2 lines in the cable binder) two vectoring types can be distinguished:
• Board Level Vectoring (BLV): • Vectoring on one LT board (for example, 48 lines) and consequently only suited for deployment scenario with deep fiber penetration where small remotes are installed.
• Only the crosstalk between the lines on the same board can be cancelled. • System Level Vectoring (SLV): • Vectoring over multiple LT boards and consequently suited for deployment scenarios where bigger cabinets are installed.
• Crosstalk between lines on different LTs can be cancelled The main additional functional blocks for a vectoring system (compared to a non-vectoring VDSL2 system) are the following:
• Vectoring Control Entity (VCE): The VCE will control the Vectoring state machine and will use the incoming error samples to do the calculation of the crosstalk coefficients. The VCE is located on the LT board for BLV, whereas it is on the Vector Processing board for SLV. • Pre-/Post-coder The Pre-/Post-coder will perform the actual crosstalk cancellation by manipulating the outgoing/incoming signals from the different DSPs. To configure vectoring on the ISAM you will need to create two new profiles: the vectoring profile and the VCE profile. The VCE profile is assigned to the board containing the VCE (LT board for BLV and Vector Processing board for SLV) while the vectoring profile is assigned to the lines. In case of SLV, the Vector Processing board is communicating with the LT boards by means of dedicated front cabling. There are two modes of operation: 1
Auto-discovery mode disabled on VP and LT boards (default mode): When auto-discovery is disabled, the connection between the VP links and LT boards has to be configured. This is a precondition for being able to assign a vectoring profile to an LT port. Failures of the VP-LT cable are reported on the corresponding VP link.
2
Auto-discovery mode enabled on VP and LT boards: When auto-discovery is enabled, there is no need anymore to configure the connection between the VP links and LT boards. Once auto-discovery is enabled on the LT, vectoring profiles can be assigned to the LT ports. Failures of the VP-LT cable are reported on the corresponding LT.
Vectoring operation requires synchronization between the LT and the VP card. When installing the VP-LT cable, this synchronization will automatically be executed in case at least one LT port has been configured in vectored mode. In case all LT ports are still configured in non-vectored mode, the synchronization will be postponed until a vectoring profile gets assigned to at least one port of this LT. The VP-LT synchronization results in a resynchronization of all DSL lines of this LT.
7-16
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
7 — xDSL features
A System Level Vectoring group can be composed of VP and SLV LT boards located in different ISAM shelves, managed as separate network elements. This type of setup is called Cross-DSLAM Level Vectoring (XDLV) and is shown in Figure 7-10. Because of the limited VP-LT cable length, the equipment still has to be collocated. Figure 7-10 Cross-DSLAM Level Vectoring
ISAM 1 VP NT
LT LT VP-LT cables ISAM 2 LT
NT LT
Constraints:
• XDLV is only possible when auto-discovery mode is enabled. Without auto-discovery, the VP and the LT boards have to be managed by the same ISAM. • XDLV requires compatible SW releases for the VP and LT boards. In case a SW incompatibility is detected, a VP/LT mismatch alarm will be raised. By default, the XDSL LT ports with a vectoring profile will not synchronize anymore, but the system can be configured to autonomously switch such lines to a fall-back VDSL2 configuration with limited spectrum usage.
7.14
Fall-back configuration for vectoring The vectoring profile specifies the type of CPE allowed on a line:
• • • •
G.Vector CPE G.Vector friendly CPE for downstream direction (G.993.2 Annex X) Full G.Vector friendly CPE (G.993.2 Annex Y) Legacy VDSL2 CPE
If the type of connected CPE does not match any of the allowed types, then by default the line will not initialize in order not to disturb the other lines of the vectoring group. As an alternative, the system can be configured to autonomously switch the line to a fall-back VDSL2 configuration with limited spectrum usage in case a CPE capability mismatch is detected. When the mismatch disappears, the line will autonomously switch back to the normal configuration.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
7-17
7 — xDSL features
In case of communication problems between the LT and the VP board in case of SLV, the lines configured with a vectoring profile will by default not initialize anymore in order not to disturb the other lines of the vectoring group. As an alternative, the system can be configured to autonomously switch the lines to a fall-back VDSL2 configuration with limited spectrum usage in case of detection of VP/LT communication problems. When the communication recovers, the lines will autonomously switch back to the normal configuration. The definition of the fall-back configuration as well as the enabling of the fall-back mechanism can be specified at XDSL LT board level:
• For BLV, the feature can optionally be enabled for the detection of a CPE capability mismatch.
• For SLV, the feature can optionally be enabled for the detection of VP/LT communication problems. If enabled, the feature can additionally be enabled for detection of a CPE capability mismatch.
7-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
8 — GPON Network Architecture
8.1 Introduction: GPON Network
8-2
8.2 Alcatel-Lucent GPON Network Architecture 8.3 GPON Implementation of ISAM 8.4 V-OLT GPON Functions 8.5 Protection
8-2
8-3
8-12
8-12
8.6 ONU Functions
8-12
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
8-1
8 — GPON Network Architecture
8.1
Introduction: GPON Network An Optical Distribution Network (ODN) based on Gigabit Passive Optical Network (GPON) technology consists of two main parts that may be implemented by network equipment that can be categorized as follows:
• Optical Line Termination (OLT): This unit provides central processing, switching, and control functions. This equipment is located at the network side of the Optical Distribution Network • Optical Network Unit (ONU): This unit is located at the subscriber premises as distributed end-points of the ODN. This equipment implements the GPON protocol and adapts GPON Protocol Data Units to subscriber service interfaces. Note — There is a specific case for ONU equipment that is generally referred to as Optical Network Termination (ONT). This specific term is generally used to designate a single-user subscriber premise equipment.
8.2
Alcatel-Lucent GPON Network Architecture In the Alcatel-Lucent GPON network architecture, the OLT function is provided via three distinct equipment types:
• Packet - Optical Line Termination (P-OLT) unit which corresponds to the ISAM with its NT and GPON LTs. • Video - Optical Line Termination (V-OLT) unit which distributes Radio Frequency (RF) overlay video signals across the GPON if the network provider chooses this method for providing Video Services. (This optional equipment is provided by a third-party supplier and hence outside of the scope of ISAM) • Wavelength Division Multiplexer which is only needed in case of V-OLT presence in the network, and which is used to mix and separate the RF Video signal into/from the optical fiber going towards ONUs. (This optional equipment is also outside of the scope of ISAM) Alcatel-Lucent also provides a wide variety of ONU equipment which works seamlessly together with the ISAM (P-OLT) products to form a fiber access network capable of delivering high quality voice, video, and data services to both single-family or multi-dwelling residential subscribers and business subscribers. This model is shown in Figure 8-1.
8-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
8 — GPON Network Architecture Figure 8-1 ISAM GPON Network Architecture Network
Central office or remote terminal
Fiber distribution
Passive outside plan
ONTs
End user
Optical link length 1
Optional RF router V-OLT/EDFA
RF Video provider network
Ethernet
1,550 nm
IPTV
MDU WDM
Internet
Edge switch router
1,490 nm 1,550 nm
2.4 Gb/s
1,310 nm
1.2 Gb/s
ISAM
PSTN
Voice gateway EMS/NMS Class 5 switch
Softswitch
1 The maximum optical link length depends on the specific equipment and deployment conditions
Standards The Alcatel-Lucent GPON network is developed based on the following ITU-T standards:
• • • • • • •
8.3
G.984.1 (GPON Service requirements) G.984.2 (GPON PMD layer) G.984.2 (GPON PMD layer) amendment 1 G.984.3 (GPON TC Layer) G.984.3 (GPON TC Layer) amendment 1 and 2 G.984.4 (GPON OMCI) G.984.4 (GPON OMCI) amendments 1 and 2
GPON Implementation of ISAM ISAM provides the core processing, switching, and control functions and interacts in the upstream direction with the Ethernet switch and voice gateway using the NT cards. The ISAM shelves with their NT and GPON LT boards comprise the conceptual P-OLT system from the GPON Network point of view.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
8-3
8 — GPON Network Architecture
The Alcatel-Lucent ONU products are edge devices that use GPON technology to extend a fiber optic cable from a P-OLT shelf to a subscriber residence, including single-family residences, multi-dwelling residences such as an apartment building, and small office / home office applications. There are two types of GPON LT boards in ISAM with different GPON capacities:
• 2.4Gb/s Downstream / 1.2Gb/s Upstream • 10Gb/s Downstream / 2.5Gb/s Upstream Transmission Convergence Layer - Multiplexing Architecture ITU-T GPON recommendations provide two multiplexing mechanisms: ATM base and GEM base. ISAM only supports GEM multiplexing. The ATM partition is not supported. Figure 8-2 GPON Functional Blocks PLOAM
OMCI
TC Adaptation sub-layer OMCI adapter
VPI/VCI filter
Port-ID filter
ATM TC adapter
GEM TC adapter
GTC Framing sub-layer
PLOAM partition
Alloc-ID filter
Alloc-ID filter
Embedded OAM
ATM partition
GEM partition
Frame header
- BW Granting - Key Switching - DBA
Multiplexing based on frame location
• In downstream direction, the GEM frames are carried in the GEM partition, and arrive at all the ONUs. The ONU framing sublayer extracts the frames, and the GEM TC adapter filters the GEM fragment based on their 12-bit port ID. Only frames with the appropriate port IDs are allowed through to the GEM client function at the ONU. • In upstream direction, the GEM traffic is carried over one or more Transmission Containers (T-CONTs). The OLT receives the transmission associated with the T-CONT, and the frames are forwarded to the GEM TC adapter, and then to the GEM client function at the OLT.
8-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
8 — GPON Network Architecture
One ONU can be served by one or several T-CONTs, but a given T-CONT can only be used by a single ONU. Also, a given T-CONT can transport traffic from several GEM ports, but traffic from a given GEM port can only be carried by a single T-CONT. ISAM GPON-LTs support 2.048 GEM clients (also called GEM ports) and 1.024 T-CONTs per GPON interface. Both GEM ports and T-CONTs are internal GPON protocol constructs/abstractions that are not directly exposed to the operator for convenience and ease of management.
Transmission Convergence Layer - GPON Media Access Control The Transmission Convergence layer in ISAM provides media access control for upstream traffic. Figure 8-3 PON media access control concept Downstream
Frame header (PCBd)
Payload for downstream
US BW Map
Alloc ID
Start
End
Alloc ID
Start
End
Alloc ID
Start
End
1
100
300
2
400
500
3
520
600
Upstream
T-CONT1 (ONU1) Slot 100
T-CONT2 (ONU2) Slot 300
Slot 400
T-CONT3 (ONU3)
Slot Slot 500 520
Slot 600
In the basic concept, downstream frames indicate permitted locations for upstream traffic and upstream frames synchronized with downstream frames as outlined in Figure 8-3. The ISAM sends pointers in the frame header Physical Control Block downstream (PCBd). The pointers indicate the time at which each ONU must begin and end its upstream transmission. In this way, only one ONU can access the GPON at any time, and there is no contention in normal operation. The pointers are 2 bytes long and given in units of bytes, allowing the OLT to control the GPON at an effective static bandwidth granularity of 64 kb/s. The size of the GTC frame is 125 µs. The downstream payload contains GEM packets that are uniquely destined to some specific T-CONT/ONUs. The ONUs examine the GEM header and only process the GEM packets which port IDs match its own.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
8-5
8 — GPON Network Architecture
Transmission Convergence Layer - Upstream and Downstream Frames Figure 8-4 shows the PON downstream frame format. Figure 8-4 PON Downstream Frame format
PCBd n
Payload n
TP-Frame = 125 µS
PCBd n+1
PCBd n+2
Payload n+1
"Pure" ATM cells Section
TDM & Data Fragments over GEM Section
N x 53 bytes
Figure 8-5 shows the PON upstream frame format. Figure 8-5 PON Upstream Frame Format Upstream Frame
PLOu
PLOAMu PLSu
DBRu X
Payload X
DBRu Y
PLOu DBRu
Payload Y
Z
ONT A
Payload Z
ONT B
Transmission Convergence Layer - GEM Encapsulation of Ethernet Packets Ethernet packets are encapsulated by ISAM and ONUs into GEM as shown in Figure 8-6. Each packet is mapped into the GEM frame. The Preamble and SFD bytes are not included in the GEM frame. Figure 8-6 Ethernet encapsulation over GEM Ethernet Packet
GEM Frame PLI
12
Inter Packet Gap
7
Preamble
PTI
1
SFD
CRC
6
DA
Port-ID
6
SA
2
Length/Type
5 Bytes
GEM Payload
MAC client Data 4 1
8-6
November 2013
FCS EOF
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
8 — GPON Network Architecture
Each produced GEM fragment is transmitted contiguously. A fragment cannot straddle a frame boundary. Therefore, the fragmentation process must be aware of the amount of time remaining in the current partition or payload, and must fragment its user data frames appropriately. Figure 8-7 shows different possibilities of user frames fragmentation. Figure 8-7 Fragmentation Examples Case 1
Case 2
User Frame
GEM PTI: 001
Full Frame
Case 3
User Frame
GEM PTI: 001
#1
GEM PTI: 001
User Frame
#2
GEM PTI: 001
#1
GEM PTI: 001
#2
GEM PTI: 001
#3
Dynamic Bandwidth Assignment Dynamic Bandwidth Assignment (DBA) is the process by which ONUs and their associated T-CONTs dynamically request upstream bandwidth. ISAM processes the implicit bandwidth requests from ONU via idle cell monitoring and reassigns upstream bandwidth accordingly. In the idle cell monitoring implementation, ISAM bandwidth reassignment is applied to the distribution of the non-guaranteed or un-assured portion of the service traffic in order not to disturb the guaranteed traffic contracts. T-CONTs are used for the management of upstream bandwidth allocation in the GPON section of the Transmission Convergence layer. As such, T-CONTs are primarily used to improve the upstream bandwidth use on the GPON.
Forward Error Correction Forward Error Correction (FEC) is used by the transport layer of ISAM and it is based on transmitting the data in an encoded format. The encoding allows the decoder to detect and correct the transmission errors. For example, for input BER of 10-4, the BER at the FEC decoder's output may drop to 10-15. By using the FEC technique, data transmission with low error rates can be achieved, and retransmissions are avoided. FEC results in an increased link budget. Therefore, higher bit rate and longer distance from the ISAM to the ONUs can be supported. Alternatively, by using this process a higher number of splits per single GPON tree can be achieved over an equivalent distance. The FEC encoding and decoding of ISAM is based on Reed-Solomon (block based FEC). Reed-Solomon (RS) is a block-based code, which takes a data block of constant size and adds extra “redundant” bits at the end, thus creating a code word. Using those extra bits, the FEC decoder processes the data stream, discovers errors, corrects errors, and recovers the original data. Reed-Solomon code is specified in CMTT recommendation CCIR 723.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
8-7
8 — GPON Network Architecture
When using a block-based FEC, original data is preserved. Therefore, by ignoring the parity bits, even if the other side does not support FEC, the original data can be processed. However, block-based FEC error correction is not efficient for very high BER levels (for example, for 10-3 BER, a decoding error will be generated).
Delay Tolerance For the upstream GPON transmission, ISAM provides a configurable Delay Tolerance parameter to realize optimal latency and delay variation characteristics on the GPON link.
Security ISAM uses Advanced Encryption Standard (AES) for security. Internally AES is enabled/disabled by ISAM for individual port IDs in conformance with the GPON protocol standards. However, management model granularity is provided on a per-ONU basis. Advanced Encryption Standard is a block cipher that operates on 16 byte (128 bit) blocks of data. It accepts 128, 192, and 256 bit keys. This algorithm is described in documents published by the National Institute of Standards and Technology (NIST) in the USA. There are several modes of operation for this standard. However, only the “Counter” (CTR) mode is used by ISAM. In this mode, the cipher generates a stream of 16-byte pseudorandom cipher blocks which are exclusive-ORed with the input clear-text to produce the output of cipher-text. The cipher-text is exclusive-ORed with the same pseudorandom cipher blocks to regenerate the clear-text. The key length is fixed at 128 bits.
ONU Ranging and Discovery When ISAM is ranging new ONUs, working ONUs must temporarily stop transmissions. This is done by opening a ranging window to discover new ONUs. Two activation/ranging methods supported by ISAM
• Configured-S/N: The serial number of the ONU is registered in advance at the OLT and used for authentication of the matching ONT. • Discovered-S/N: The serial number of the ONU is not registered at the OLT. It requires an automatic detection mechanism of the serial number of the ONU based on the operator-assigned ONU Registration ID that is provisioned locally at the ONU and at the ISAM for a match. In case a new ONU is detected, an ONU ID is assigned and the ONU is activated.
• Operator-assigned ONU Registration ID can take two forms: a simple Subscriber •
8-8
Location IDentifier (SLID) or a LOgical IDentifier (LOID, which consists of a logical subscriber location designation and an associated password). The use of SLID vs. LOID based authentication is provisionable on a per-PON basis.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
8 — GPON Network Architecture
Concurrent Use of Activation/Ranging Methods: ISAM also allows a special per-PON configuration in order to support ONUs conforming to either Configured-S/N or LOID-based Discovered-S/N authentication methods to be mixed on the same PON. In this case LOID-based Discovered-S/N has precedence over Configured-S/N mode in processing each ONT. SLID/LOID-Serial_Number Bundling and Anti Snooping Function: SLID or LOID (G.988) association with a S/N may to be locked after a user defined time period (for example, 4h/24h) following the first ranging of the ONT with a certain Serial Number. This will allow for changing of ONT during installation. In this case, after the defined period of time, the installed ONT hence its Serial Number shall be considered as final per operator's intentions and the SLID/LOID association to this Serial Number shall be frozen. After this defined transition period any detected mismatch results in an alarm. The function of bundling or un-bundling between SLID/LOID with SN is configurable per ONT. There are three triggers for initiating the activation of an ONU:
• The network operator enables the activation process to start when it is known that a new ONU has been connected. • The OLT automatically initiates the activation process, when one or more of the previously working ONUs are 'missing', to see if those ONUs can return to service. The frequency of polling is programmable. • The OLT periodically initiates the activation process, testing to see if any new ONUs have been connected. The frequency of polling is programmable.
ONU Activation The activation process is performed under the control of ISAM. The activation procedure is performed by the exchange of upstream and downstream flags and Physical Layer Operations Administration and Maintenance (PLOAM) standard messages defined for GPON, as follows: 1
ONU receives the requested GPON operating parameters from ISAM.
2
ONU adjusts it parameters accordingly.
3
ISAM discovers the Serial Number of a new connected ONU.
4
ISAM assigns an ONU-ID to the ONU.
5
ISAM measures the round-trip delay of the ONU transmission.
6
ISAM notifies the ONU of the equalization delay.
7
ONU adjusts the transmission phase to the notified value.
In the normal operating state, all the transmissions can be used for monitoring the phase of the arriving transmission. Based on the monitoring transmission phase information, the equalization delay can be updated.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
8-9
8 — GPON Network Architecture
ISAM broadcasts the Serial-Number requests to all ONUs in the Serial-Number state. Consequently, more than one Serial-Number transmission can simultaneously arrive at the OLT causing a collision. The Random Delay Method is used to resolve this problem. Based on the Random Delay Method, each Serial-Number transmission is delayed by a random number of delay units generated by each ONU. The delay units are 32 bytes long for all bit rates. The random delay must be an integral number of delay units. Following each response to a Serial-Number request, the ONU generates a new random number, thus collisions are easily and efficiently prevented.
OMCI The ONT Management and Control Interface (OMCI) is the ITU-T G984.4-based open interface definition that provides the management model for provisioning and surveillance related functions between ISAM and ONUs.
Transmission Convergence Layer Performance Monitoring ISAM provides on-demand counters to monitor GPON TC layer traffic and performance. The related counters are collected internally on a GEM-port basis from both ends of the GPON section, and are presented to the operator on a per-ONU and per-UNI basis. In addition, the same set of counters is also supported for the shared Multicast GEM port of the PON.
Rogue ONT Detection and Defense Mechanism The Rogue ONT Diagnostic feature of the ISAM provides a means of monitoring ONT behavior on the PON and identifying rogue ONT(s) through the problematic symptoms of other ONTs on the optical network. Alarm notifications are generated upon detection of Rogue ONTs. There are four Rogue ONT detection methods:
• The on-demand ON/OFF test which is a service-affecting test whether or not a rogue ONT is detected. • The on-demand pattern test which is a non-service affecting test unless a rogue ONT is present on the PON. • The background pattern test which is run in background mode on the ONTs at regular intervals or on a given ONT when it ranges. This test is disabled by default. • The background ON/OFF test which is triggered by PON LOS to run a test on each ONT. On Demand ON/OFF Test
This test is also called the manual stuck laser test or the manual on/off test. This test is service affecting as all ONTs on the PON are disabled during the test. The Disable Serial Number PLOAM message is used for testing. This PLOAM is sent to each ONT in turn. G984.3 states that on receiving this message the ONT should go to Emergency Stop State and disable the TX optics.
8-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
8 — GPON Network Architecture
A broadcast option has been added to the Disable Serial Number PLOAM message to allow the disabling of ONTs which have been added to the PON but are not yet provisioned at the time of the test. This enhancement is not defined in G984.3. On-Demand Pattern Test
An ONT which is exhibiting rogue behavior by transmitting outside its assigned time slot should impact other ONTs on the PON. The on-demand pattern test uses the Diagnostic PLOAM message to trigger a test mode on an individual ONT while monitoring for adverse impacts on the other ONTs. The impacts may include a change in alarms or an ONT moving to INACT state. The pattern test enabled on one ONT generally does not have an impact on other subscribers unless the ONT being tested is rogue. However, in case of RF overlay, and depending on specific channel line up frequencies, a small amount of transitory interference might be observed on the video signal. If a rogue ONT is found, other subscribers would be impacted for a few seconds on the first check. This test is implemented via an ONT Diagnostic Vendor Specific PLOAM message not detailed in G984.3. Background Pattern Tests
The background pattern test utilizes the same algorithm as the on-demand Pattern Test and is disabled by default. When enabled, the diagnostics will trigger a test under two conditions:
• An ONT ranges • The background timer expires. Execution of the background test is by default scheduled at an interval of 12 hours. This interval can be configured. Background On/Off Test
This test is also called the background stuck laser test or Background On/Off test. The test algorithm is the same as the manual on/off test. The test is disabled by default and is service affecting. The trigger for this test is a PON LOS event where the RX laser is detected to be on, corresponding to an ONT continuously transmitting irrespective of its allowed window Automatic RF Service Shutdown
ISAM supports the management capability to provision the automatic RF Video service shutdown function. This capability consists in provisioning a configurable setting for ONTs supporting the underlying function to use in order to determine the period of time to assure continued video service for, in case of communication loss between the OLT and the ONT. RF video service in such ONTs is only restored after a successful re-range with the OLT.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
8-11
8 — GPON Network Architecture
8.4
V-OLT GPON Functions V-OLT is an optional network equipment that is used to distribute Radio Frequency (RF) video signal from service providers to the ONUs. This equipment is not part of ISAM. The following description of the V-OLT function is provided for informational purposes. Note however that occasionally, when fiber and equipment in the GPON network are shared, a so-called Raman Effect can occur where signals cross over from downstream digital signals in the lower spectrum and cause visible lines on overlaid broadcast RF video signals. The effect is usually more prominent in the low end video channels that are in the 1550 to 1560 nm range. The ISAM GPON LTs provide a Raman crosstalk reduction feature that can be enabled if distortion, caused by downstream digital data signals on the GPON network, is visible on the lower spectrum video channels.
Radio Frequency Video Signal Distribution The V-OLT uses Erbium Doped Fiber Amplifiers (EDFA). The distribution requires a Wavelength Division Multiplexer (WDM) to be overlaid into the fiber path. The distribution of the optical video signal is described as follows:
• The V-OLT receives an incoming wavelength optical signal with embedded video channels through a fiber path from the cable TV head-end equipment. • The V-OLT amplifies and splits the optical signal into multiple optical feeds to the video coupler. • The video coupler merges the video signal over the fiber paths. • The fiber paths carry the optical signals between the P-OLT and the ONUs.
RF Video Services The V-OLT supports the full cable television (CATV) spectrum from 47 MHz to 862 MHz. Access to video services may require a Set-Top Box (STB) between the video output of the ONU equipment and other Customer Premises Equipment (CPE). The V-OLT requires a separate Element Management System (EMS) to control video output signals from the V-OLT equipment.
8.5
Protection ISAM supports Type-B protection per ITU-T specification G984.1. Refer to section “Subscriber interface redundancy” in chapter “Failure protection and redundancy provisions in ISAM” for further information.
8.6
ONU Functions ONU functions are described in chapter “ISAM Support for the GPON ONU”.
8-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
9 — ISAM Support for the GPON ONU
9.1 Introduction
9-2
9.2 ONU Product Identification 9.3 Ethernet features 9.4 xDSL features 9.5 Wi-Fi
9-5
9-7
9-7
9-7
9.6 DS1/E1 Features 9.7 Video Overlay
9-7 9-10
9.8 Home Phoneline Network (HPNA) 9.9 Power over Ethernet
9-11
9-12
9.10 Ethernet loopback detection
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
9-12
November 2013
9-1
9 — ISAM Support for the GPON ONU
9.1
Introduction The Optical Network Unit (ONU) in conjunction with the ISAM OLT products work seamlessly together to form a fiber access network capable of delivering high quality voice, video, and data services to both single-family or multi-dwelling residential subscribers and business subscribers This chapter describes the ONU support in ISAM. Figure 9-1 ISAM GPON Network Architecture Network
Central office or remote terminal
Fiber distribution
Passive outside plan
ONTs
End user
Optical link length 1
Optional RF router V-OLT/EDFA
RF Video provider network
Ethernet
1,550 nm
IPTV
MDU WDM
Internet
Edge switch router
1,490 nm 1,550 nm
2.4 Gb/s
1,310 nm
1.2 Gb/s
ISAM
PSTN
Voice gateway EMS/NMS Class 5 switch
Softswitch
1 The maximum optical link length depends on the specific equipment and deployment conditions
P-OLTs and V-OLTs The P-OLT and V-OLT reside in the central office (CO) or controlled environment vault (CEV) and provide interfaces between the network and the Gigabit-capable Passive Optical Network (GPON).
9-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
9 — ISAM Support for the GPON ONU
GPON ONUs The Alcatel-Lucent GPON ONU products are subscriber/customer co-located edge devices that use GPON technology to extend a fiber optic cable from a P-OLT shelf at a CO to a subscriber residence, including single-family residences (SFU), multi-dwelling residences (MDU) such as an apartment building, and small office home office applications. The ONUs terminate the GPON physical and transmission convergence layer and provide the specific service interworking function required at the subscriber residence (for example, High Speed Interface, POTS, DS1 CES and so on). The Alcatel-Lucent GPON ONU products provide the following functions and services:
• network demarcation for all services • voice interworking function from the analog POTS lines to the VoIP/Ethernet • • • • • •
layers interworking functions between the GEM and Ethernet layers interworking functions between the PON optical overlay and the RF video interface CES encapsulation of DS1/E1 using the MEF-8 packetization format for transport across the layer 2 Ethernet PON mux and demux functions to the PON optical to electrical conversion located at subscriber residence
All Alcatel-Lucent GPON ONUs were developed using the following GPON ITU-T standards:
• • • • • • • • •
G.984.1 (GPON Service requirements) G.984.2 (GPON PMD layer) G.984.2 (GPON PMD layer) amendment 1 G.984.3 (GPON TC Layer) G.984.3 (GPON TC Layer) amendment 1 and 2 G.984.4 (GPON OMCI) G.984.4 (GPON OMCI) amendments 1 and 2 G.988 (OMCI) OIG Implementers Guide Note — As already stated in chapter “GPON Network Architecture”, the term ONT (Optical Network Termination) is an implementation of the more general used term ONU (Optical Network Unit). This document uses the general term for all Optical Network devices
Indoor ONU The indoor ONU terminates services at the subscriber premises and is used for subscribers living in single-family residences. The indoor ONU is suitable for installation on a desktop or for attaching to an interior wall.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
9-3
9 — ISAM Support for the GPON ONU
Outdoor ONU The outdoor ONU terminates services at the subscriber premises and is suitable for single residences and Small Office Home Office (SOHO) applications. The single residence and SOHO outdoor ONUs have environmentally-hardened enclosures that can be installed outside the subscriber premises.
MDU outdoor ONU The MDU ONU terminates GPON layer services and is suitable for multi-dwelling unit (MDU) applications. The MDU ONU supportsVDSL2 interfaces and Ethernet interfaces that are terminated at the customer's premise.
Business ONUs All business ONUs are suitable for small business applications and provide voice, data and IP video, and optional RF video services to subscribers and support CES DS1 or E1 connections at the business premises.
9-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
9 — ISAM Support for the GPON ONU
9.2
ONU Product Identification Table 9-1 provides the identification information for the ONU product series. Table 9-1 ONU Product Series Identification Series
Description
I-series
Indoor ONUs
O-series
Outdoor ONUs
M-series
Modular ONUs
S-series
Service plug-ins for modular ONUs
B-series
Business ONUs
In a product series, each ONU model can be further identified by a designation that defines the characteristics of the particular model, such as the number of voice, data, and video interfaces. Table 9-2 provides the designation for the different models of indoor and outdoor ONUs. Table 9-2 General ONU Mnemonic Designation Position in mnemonic
Description
Beginning character
Indicates the series to which the product belongs
First digit after the dash
Refers to the number of POTS interfaces
Second digit after the dash
Refers to the number of data interfaces
Third digit after the dash
Refers to the number of video/MoCA interfaces
Character after the third digit
Refers to the type of data service supported. The codes for the supported types are:
• • • • • Ending character
E for 10/100BASE-T Ethernet G for 10/100/1000BASE-T Ethernet (Gigabit Ethernet) V for VDSL M for MoCA and 10/100/1000BASE-T Ethernet (Gigabit Ethernet) W for Wi-Fi
Refers to the variant
Table 9-3 provides the designation for the different MDU models. Table 9-3 MDU Mnemonic Designation Position in mnemonic
Description
Beginning character
Indicates the series to which the product belongs
First digit after the dash
Refers to the number of POTS interfaces
(1 of 2)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
9-5
9 — ISAM Support for the GPON ONU
Position in mnemonic
Description
Second digit after the dash
Refers to the number of data interfaces
Third digit after the dash
Refers to the number of VDSL interfaces
Character after the third digit
Refers to the type of data service supported. The codes for the supported types are:
• • • Ending character
E for 10/100BASE-T Ethernet G for 10/100/1000BASE-T Ethernet (Gigabit Ethernet) V for VDSL
Refers to the variant
(2 of 2)
Table 9-4 provides the designation for the business ONUs. Table 9-4 Business ONU Mnemonic Designation Position in mnemonic
Description
Beginning character
Indicates the series to which the product belongs
First digit after the dash
Refers to the number of POTS interfaces
Second digit after the dash
Refers to the number of data interfaces
Third digit after the dash
Refers to the number of video interfaces
Fourth digit after the dash
Refers to the number of DS1/E1 interfaces
Ending character
Refers to the variant
General ONU Features GPON ONUs support the following main GPON features:
• GEM mode support for efficient IP/Ethernet service traffic transport • 2.488 Gb/s line rate downstream and 1.244 Gb/s line rate upstream • Class B+ optics with 28 dB optical link loss (without FEC) • Rx optical sensitivity of -27 dB (without FEC) • Class C+ optics with 32 dB optical link loss (with FEC) • Rx optical sensitivity of -30 dB (without FEC) • integrated diplexer for ONUs supporting POTS and data • integrated triplexer for ONUs supporting POTS, data, and RF video • 1490 nm wavelength downstream, 1310 nm wavelength upstream, and optional 1550 nm downstream for RF video overlay
• single mode fiber and use SC/APC optical port • G.984.3-compliant Dynamic Bandwidth Allocation (DBA) • G.984.3-compliant Advanced Encryption System (AES) with operator enable/disable per port-ID level
9-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
9 — ISAM Support for the GPON ONU
• G.984.3-compliant Forward Error Correction (FEC) for longer reach upstream and downstream
• G.988-compliant ME extension for PoE management with operator enable/disable per Ethernet interface to allow control of the output power level on each PoE port
9.3
Ethernet features The Ethernet interfaces on the ONUs support the following primary features:
• Ethernet ports are IEEE 802.3 Compliant • IEEE 802.1Q, 802.1x port-based authentication, and 802.1p (QoS classification per Ethernet port support Layer 3 DSCP to 802.1p mapping to allow L3 CoS over the Layer 2 network supports full or half duplex operations supports auto-negotiation or manual setting by operator supports the PoE control ME to monitor and configure the output power level in the PSE (MDU ONU) which includes alarms if the ONU is unable to supply PoE demand • Supports loopback detection capability
• • • •
Refer to chapter “Layer 2 forwarding” for details on the supported Ethernet L2 forwarding features.
9.4
xDSL features Refer to chapter “xDSL features” for an overview of the supported xDSL features.
9.5
Wi-Fi The ONU supports IEEE 802.11b, 802.11g, 802.11n Wi-Fi certification.
9.6
DS1/E1 Features Only one CES encapsulation mode can be configured per ONT. i.e. If a given DS1 port on an ONT is configured in MEF8 CES mode, SAToP CES cannot be configured on a different DS1 port on the same ONT
MEF8 CES Overview The ISAM performs Circuit Emulation Services (CES) encapsulation on DS1 and E1 TDM traffic for transport as Ethernet layer 2 over the GPON using the Metro Ethernet Forum standard MEF-8 payload structure and pseudo-wire (PW) technology. CES and the DS1 or E1 ports may be provisioned on the business ONU using a CLI, a TL1 or an AMS management session with the P-OLT. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
9-7
9 — ISAM Support for the GPON ONU
The business ONU supports DS1 and E1 service connections at the subscriber premises. The following TDM link types are supported:
• structured (fractional) DS1 or E1 • unstructured DS1 or E1 At the subscriber premises, the business ONU terminates DS1 or E1 links from the subscriber. The TDM traffic is adapted and packetized using MEF-8 pseudo-wire technology before being transported across the GPON. MEF-8 is the payload option that is used. The MEF-8 packets are multiplexed with the Ethernet layer 2 data traffic at the business ONU GPON port. When the MEF-8 packets are received at the ISAM P-OLT that is installed at the CO, the P-OLT forwards the packets to the destination PSTN, typically via a G6 voice gateway that is connected to the IP network. Figure 9-2 CES DS1 or E1 Traffic between the ONU and PSTN over the GPON via the P-OLT
EMS
DS1 or E1
Class 5 PSTN switch
GE
L2 Ethernet cloud
GE
GPON
P-OLT
Voice gateway (G6)
DS1 or E1 Business ONT
DHCP server
In the downstream direction, DS1 or E1 traffic from the PSTN is sent to the G6 voice gateway, which performs Ethernet layer 2 encapsulation using the MEF-8 payload format and sends the traffic out to the Ethernet network to the ISAM P-OLT. The LT board installed in the ISAM P-OLT forwards the packets to the business ONU over the GPON. At the subscriber premises, the business ONU de-encapsulates the packets and forwards the DS1 or E1 payload to the DS1 or E1 port, which is terminating the DS1 or E1 lines at the subscriber premises.
MEF8 Structured and unstructured DS1 and E1 services handling for CES Structured DS1 or E1 services emulate fractional services where the 1.544 Mb/s DS1, or 2.048 Mb/s E1, bandwidth is subdivided into DS0 64 kb/s channels. Framing is used to group together multiple DS0s when the service is structured or fractional. Unstructured services treat the full bandwidth of a DS1 or E1 link like one large channel, ignoring any framing.
9-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
9 — ISAM Support for the GPON ONU
CES encapsulation is a method of carrying TDM traffic in an Ethernet frame so that there is minimal loss of quality. The ISAM performs CES on the TDM traffic received at the ONU DS1 or E1 port using the MEF-8 payload structure for transport as Ethernet layer 2 packets over pseudo-wires (PW). The TDM payload within the MEF-8 packet, whether it is structured or unstructured, is treated as a bitstream. The MEF-8 packets are multiplexed along with other Ethernet layer 2 data packets at the ONU before being transported across the GPON. In unstructured mode, the payload size is fixed at eight DS0 frames per MEF-8 packet. For DS1, the payload length is fixed at 192 bytes per frame. For E1, the payload length is fixed at 256 bytes per frame. In structured mode, the payload length is determined from the encapsulation delay setting.
SATOP CES The ISAM performs Circuit Emulation Services (CES) encapsulation on DS1 TDM traffic for transport as Ethernet layer 2 over GPON using the Structure Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) via UDP pseudo-wire (PW) demultiplexing. CES via SAToP and the DS1 ports may be provisioned on the business ONU using a CLI, TL1 or an AMS management session with the P-OLT. The business ONU supports DS1 service connections at the subscriber premises. SAToP is an emulation of unstructured TDM circuits only. At the subscriber premises, the business ONU provides an Interworking function (IWF) which segments and encapsulates TDM into SAToP packets and that in the reverse direction decapsulates SAToP packets and reconstitutes the TDM service. The TDM traffic is adapted and packetized using SAToP pseudo-wire technology over Ethernet Layer 2 before being transported across the GPON. When the SAToP packets are received at the ISAM P-OLT that is installed at the CO, the P-OLT forwards the packets to the destination PSTN. The payload size is fixed. For DS1, the payload length is fixed at 192 bytes per frame.
CES clocking and synchronization The same clocking reference at both ends of the DS1 or E1 link is required to meet the wander requirements of TDM traffic. The business ONU can use one of two clocking sources for CES:
• a derived GPON clock at 16.384 MHz • a 6.384 MHz local oscillator. When the system clock for CES is derived from the GPON, the upstream P-OLT locks to the BIT clock and supplies the ONT with an Ethernet clock that is traceable to a network timing reference. The supplied Ethernet clock is used for differential clock recovery and for timing the upstream pseudo-wire CES packet streams in the absence of a valid TDM recovery clock. The local oscillator is only used if adaptive mode is selected.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
9-9
9 — ISAM Support for the GPON ONU
The downstream TDM streams may be timed from one of two clocking sources:
• a 16.384 MHz adaptive clock received from the CES packet stream. • a differential clock recovered from the CES packet stream via the GPON. When the clock is received from the GPON, the GPON must be configured to send RTP packets. In adaptive timing, a local, free-running 25 MHz clock is used. The generated bit rate is determined by the long-term average data rate. The attached DS1/E1 equipment must be loop-timed. In differential timing, a 16.384 MHz reference clock is synchronized to the PON. Both ends of the DS1/E1 CES PW must use the same reference clock frequency and be synchronized to a common source. RTP is used to transport the transmitted bit rate information. The DS1 or E1 equipment that is attached to the terminating CES PW devices must be loop-timed. In loop timing, the received clock rate is used for the transmitted clock rate. The DS1/E1 equipment that is attached must be source-timed, not loop-timed. Timestamps within the CES packets are used for carrying timing information across the network. Timestamp values are generated in differential format when the interface is operating in differential timing reference mode. Otherwise, the timestamp values represent absolute time. An RTP header can be added to each CES packet for timing purposes and determine whether or not to include the 4 byte control word immediately preceding the RTP header. Configure RTP header parameters using a CLI, a TL1 or an AMS management session with the P-OLT
9.7
Video Overlay The ISAM can provide RF video service through the video overlay function. The function operates downstream in the 1550 nm optical band. Signals sent over the overlay network are presented to the subscriber as RF signals from a video F-type connector in the ONU. The RF video service in the downstream 1550 nm optical band supports most available cable television (CATV) services, including standard analog broadcast channels, as well as standard and high definition digital broadcast channels. In the upstream direction, the 1310 nm return channel is carried over an HSI service. For access to these services, a set-top box may be required between the video output of the ONU equipment and the customer's television set. Within the ONU functional blocks, the RF subsystem is an RF amplifier that produces the required RF output for the subscriber video equipment. The RF subsystem monitors the levels of optical and RF signals in support of the performance management functions. The RF video service is optional and independent of the SoC functions.
9-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
9 — ISAM Support for the GPON ONU Figure 9-3 Video overlay service in ISAM Video head end
Analog channels Digital channels
Core transport
Central office
Fiber (PON) Distribution
Broadcast video
ONT
Home network
1550 nm (downstream RF video) Video RF mux
Video optical transmitter
A
Coax
EDFA
1310 nm (upstream) B
Private network Power
Major Alarm
Processor
Minor Alarm
WDM IP Network
VoD server
VoD
Ethernet Router
Coax
ISAM Ethernet
C
Coax
1490 nm (downstream data)
A Analog broadcast No STB needed B Digital broadcast STB needed C Broadcast and VoD STB needed
9.8
Home Phoneline Network (HPNA) HPNA is a subscriber interface that is preferred by some service providers. The technology allows the service provider to deploy high bandwidth services (> 10 Mb/s) without the need to install CAT5 wiring in older homes that were not wired for broadband services. Two options exist to match the possible subscriber's wiring:
• HPNA over twisted pair • HPNA over COAX. HPNA is an integrated protocol stack handling PHY, Data Link, Convergence and Management Layers. The HPNA protocol provides a synchronous, collision-free media access method. A master device on the network control access to the network and periodically registers devices on the network. Devices compatible with version 3.1 of the HPNA standards are backwards compatible with previous versions of HPNA. HPNA over Twisted Pair provides relatively broadband services over CAT3 or better wiring. This HPNA physical layer is compatible with POTS, V.90 and various other protocols. HPNA over COAX provides relatively broadband services over COAX wiring. This HPNA physical layer is compatible with VDSL, VDSL2 and Cable-TV signals. ISAM provides support of HPNA 3.1 over COAX. HPNA 3.1 complies with the following specification:
• certified as HPNA 3.1 compliant by a NRTL • HomePNA 3.1b Certification Specification version 0.5WD (Jan/2010) • HomePNA Plugfest Certification Guidelines Rev2 (Oct/2008). Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
9-11
9 — ISAM Support for the GPON ONU
• G.9954 “Home networking transceivers - Enhanced physical, media access, and link layer specifications”
• The throughput: • Bi-directional throughput over the HPNA port shall be at least 38 Mbps in each direction for 1514 byte packets.
• Unidirectional throughput over the HPNA port shall be at least 96Mbps.
9.9
Power over Ethernet Power over Ethernet (PoE) technology describes a system to pass electrical power safely, along with data, on Ethernet cabling. Power is supplied in common mode over two or more of the differential pairs of wires found in the Ethernet cables and comes from a power supply within a PoE-enabled networking device such as an Ethernet switch or can be injected into a cable run with a midspan power supply. The IEEE standard for PoE requires Category 5 cable or higher for high power levels, but can operate with category 3 cable for low power levels. The IEEE 802.3af-2003 PoE standard provides up to 15.4 W of DC power (minimum 44 V DC and 350 mA) to each device. The IEEE 802.3at PoE standard also known as PoE+ or PoE plus, provides up to 25.5 W of power. PoE is presently deployed in applications where USB is unsuitable and where AC power would be inconvenient, expensive or infeasible to supply. Foe example, PoE is especially useful for powering IP telephones, wireless LAN access points, cameras with pan tilt and zoom (PTZ), remote Ethernet switches, embedded computers, thin clients and LCDs which is approximately 100 m of cable. PoE has several advantages, including:
• Cheaper cabling • A true gigabit connection to every device is possible • Global organizations can deploy PoE everywhere without concern for any local variance in AC power standards, outlets, plugs, or reliability. The PoE interface of the ISAM complies with IEEE 802.3at, and is backwards compatible with IEEE802.3 af.
• PoE supported through FE ports
9.10
Ethernet loopback detection The GPON ONU supports the loopback detection in the same Ethernet port or different Ethernet ports. The GPON OLT allows you to enable or disable the function per ONT. When a loopback is detected on the ONU side, the ONU will trigger an alarm and send it to the OLT. The OLT reports the alarm messages to the AMS. The alarm will be cleared by the ONU when the loopback issue is resolved.
9-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
9 — ISAM Support for the GPON ONU
The OLT can be configured to enable or disable the action of shutting down the port where the loopback exists. Depending on the configuration, the ONU or the OLT will shutdown the port.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
9-13
9 — ISAM Support for the GPON ONU
9-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture
10.1 Overview
10-2
10.2 EPON network
10-2
10.3 EPON implementation of ISAM 10.4 EPON system capacity
10-9
10-29
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-1
10 — EPON Network Architecture
10.1
Overview The 7360 ISAM FX is an optical fiber distribution network that delivers voice, data, and video services to residential and business subscribers using the Ethernet passive optical network (EPON) technology, the Gigabit passive optical network (GPON) or Point-to-point Ethernet technology. This chapter provides information about the EPON optical distribution network.
10.2
EPON network As with the GPON network, the 7360 ISAM FX EPON optical distribution network extends optical access across the “last mile” of the communications network to the subscriber, using fiber optic cabling to provide services from the network to residential or business subscribers.
EPON network elements The 7360 ISAM FX EPON optical distribution network consists of the following network elements:
• • • •
EPON OLT EPON 10G EPON EPON ONU
Figure 10-1 shows the EPON network elements deployed in a network topology.
10-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture Figure 10-1 EPON network topology
PC EPON ONU Video Server
STB
TV PC
LAN
EMAN Splitter
EMS
STB
RGW
EPON OLT
PSTN
Phone Voice Gateway
EPON ONU
Wireless access
Mobile device
EPON OLT
The optical line termination unit is the equipment located at the network side of the optical distribution network. The OLT performs a network-to-EPON and an EPON-to-network interface function to support the transmission of services and traffic between the network and the EPON ONU. The P-OLT resides at the central office of the service provider. The EPON OLT provides uplinks to the EMAN and access interfaces for subscribers, and serves two main functions:
• performs conversion between the electrical signals used by the service provider equipment and the fiber optic signals used by the passive optical network
• coordinates the multiplexing between the conversion devices (ONUs) on the other end of the optical network The EPON OLT supports ONU data configuration preservation using OAM channels to improve service recovery time on end-to-end solutions when the ONU or the OLT power switches off and on. The EPON OLT supports forwarding of IPv6 UC and MC traffic in the iBridge VLAN at the data plane.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-3
10 — EPON Network Architecture
The EPON OLT supports downstream broadcast flooding. When the secure forwarding mode is disabled in the RB VLAN, the OLT ensures that received ARP packets are forwarded correctly in both the upstream and downstream directions so that there is no need for operator involvement. In the case where RB VLAN flooding is enabled and CVLAN translation is required at the same time, CVLAN translation for flooding packets will not be completed by the OLT resulting in incorrect downstream forwarding behavior. Therefore, CVLAN translation in RB VLAN flooding is not supported. Lightweight DHCPv6 Relay Agent (LDRA), including Option 18 for Circuit ID and Option 37 for Remote ID, is supported by the EPON OLT in all forwarding models except CC VLAN and S RB VLAN for IPv6 subscriber identification. IPv6 addresses are copied transparently and are not modified or stored. For Option 18, relay agents identify the interface where the client message is received. For Option 37, relay agents that terminate switched or permanent circuits identify the remote hosts. ISAM allows insertion for one or both options to enable LDRA and when both options are disabled, LDRA is disabled. The EPON OLT supports DHCP Relay Agent Information Object (DHCP Option 82). This is an optional parameter that the relay agent adds to the DHCP request messages to identify the circuit to which a user is connected. In the upstream direction, the EPON OLT adds a relay-tag containing user-port information to the upstream PPPoE discovery packets, depending on the configuration. In the downstream direction, the EPON OLT does not process the PPPoE proprietary tags therefore it is recommended to follow TR-101 standard. The EPON OLT is DHCP Option 82 compliant with MII standards. For DHCP and PPPoE Option 82 supports customer ID format for the Remote ID sub-option and physical line ID format for the Circuit ID sub-option, in compliance with the definition of EPON specification v. 2.1 and CCSA “Technical requirements for access network subscriber access loop (port) identification in broadband access networks.” Serial number inclusion of Option 82 is supported by the EPON OLT. You can specify the type of system identifier added to the header of a DHCP Option 82 message or PPPoE: system, MAC address, or logical ID. The EPON system supports rogue ONU discovery and closure which means automatic identification of faults or error conditions using alarms and statistics can be used to inform operators of any problems or to have automatic action taken to disable a rogue ONU and avoid any disruption in the PON. Configuration and retrieval of RSSI thresholds and alarms on optical modules for specific EPON uplink ports on the LT, NT, and NTIO boards is supported and allows the operator to report the operating conditions of the optics module on the ONU and on the PON. Optical Time-Domain Reflectometry (OTDR) is supported for SFPs and XFPs on EPON interfaces that have an embedded OTDR capability which allows measurements to be obtained without the requirement for external equipment and without the requirement of an operator on-site.
10-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture
The EPON ONU supports the loopback detection in the same Ethernet port or different Ethernet ports. The EPON OLT allows you to enable or disable the function per Ethernet port. When a loopback is detected on the ONU side, the ONU will trigger an alarm and send it to the OLT. The OLT reports the alarm messages to the EMS. The alarm will be cleared by the ONU when the loopback issue is resolved. The OLT can b configured to enable or disable the action of shutting down the port where the loopback exists. Depending on the configuration, the ONU or the OLT will shutdown the port. The EPON OLT supports on-board controller (OBC) defense on 1G, 10G EPON LT cards and the NT card in the upstream direction only. Operators can specify the threshold value for each ONU. The following three control level rate limits are supported:
• PON • LLID • VP Note — The VP control level is currently not supported.
Two types of rate limits exist in each control level. Each protocol type for each control level and the summation of all protocol types have an independent rate limit threshold value. All alarms are independent with two alarms supported for each level rate limit. A total of six threshold values can be set for the following:
• • • • • •
PON + protocol PON + summation of all protocols LLID + protocol LLID + summation of all protocols VP + protocol VP + summation of all protocols
The OBC defense features can monitor packets for the following protocols:
• • • • • • • • •
ARP DHCP PPPoE IGMP ND DHCPv6 ICMPv6 MLD cfm
In the Alcatel-Lucent EPON network architecture, the EPON OLT function consists of the ISAM NT and the EPON functional LT.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-5
10 — EPON Network Architecture
EPON
All services and traffic are transported between the OLT and an ONU over the EPON. The EPON brings optical fiber cabling and signals to the subscriber. The optical fiber network connecting the EPON OLT and the EPON ONU is a passive optical network (PON) with no active or powered elements. The EPON employs a point-to-multipoint topology. A single strand of fiber extends from the OLT at the central office to a passive optical splitter. The PON supports up to 64 splits or ONU. The EPON network uses the following wavelengths of light between the P-OLT and the ONUs across the EPON:
• 1310 nm transmit in the upstream • 1490 nm receive in the downstream 10G EPON
All services and traffic are transported between the OLT and an ONU over the 10G EPON. The 10G EPON brings optical fiber cabling and signals to the subscriber. The optical fiber network connecting the EPON OLT and the EPON ONU is a passive optical network (PON) with no active or powered elements. The 10G EPON employs a point-to-multipoint topology. A single strand of fiber extends from the OLT at the central office to a passive optical splitter. The PON supports up to 128 ONUs on a PON. A Neighbor Discovery (ND) proxy is supported on the NT board. IPv6 anti-spoofing is supported for 10G EPON providing the capability of anti-spoofing towards any received IPv6 traffic from the subscriber side based on DHCPv6 snooping. The 10G EPON network uses the following wavelengths of light between the P-OLT and the ONUs across the EPON:
• • • •
1310 nm burst transmit in the 1 Gb/s upstream 1490 nm a continuous receive in the 1 Gb/s downstream 1270 nm a burst transmit in the 10 Gb/s upstream 1577 nm continuous receive in the 10 Gb/s downstream
In the CATV service, 1550 nm wavelength is used. Figure 10-2 shows the wavelength and spectral width of the 10G EPON system.
10-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture Figure 10-2 Wavelength and Spectral Width of the 10G EPON system 10G upstream 1270 +- 10nm
10G downstream 1577 -2/+3nm 1G upstream 1310 +- 50nm
1260 1280
Narrow 1310 nm laser
1G downstream 1490 +- 10nm
1360
1480 1500
RF video
1550 1575 1600 1560 1580
Wavelength, nm
EPON ONU
The optical network unit is a conversion device that is located at the subscriber premises as distributed end-points of the optical distribution network. The ONU performs an EPON-to-subscriber and a subscriber-to-EPON interface function to support the distribution of network services and traffic from the OLT to the subscribers, and the transmission of subscriber traffic to the OLT. The EPON ONU implements the EPON protocol and adapts EPON Protocol Data Units to subscriber service interfaces. See chapter “ISAM Support for the EPON ONU” for more information about the EPON ONU. The EPON ONU supports PB encapsulation mode in the upstream and downstream directions, and PB transport mode in the upstream and downstream directions. When the EPON LT card is set to DPoE mode, the card supports TPID translation and functionality. Operators can configure one ONU using the following TPID values:
• • • •
0x8100 0x88a8 0x9100 0x9200
The configured values used for DPoE OAM support are dependent on the type of service and hardware being used. See Customer Release Notes for DPoE limitations. See your Alcatel-Lucent representative for more information. The EPON OLT enables the following behavior: 1
In the upstream direction, the LT card will translate the ONU TPID to 0x8100 and send the traffic to the NT card with TPID 0x8100. The IHub can translate the TPID 0x8100 to the network TPID and send the traffic to the network side. The network TPID will be the port default TPID that is configured on the network port or the service level TPID that is configured on the V-VPLS.
2
In the downstream direction, the IHUB translates the network TPID to 0x8100. The LT translates TPID 0x8100 to the ONU TPID that is configured on the ONU side.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-7
10 — EPON Network Architecture
Standards The EPON and 10G EPON networks are developed based on the following standards:
• IEEE 802.3ah-2004 (Amendment: Media access control parameters, physical • • • • • • • • •
layers and management parameters for subscriber access networks) IEEE 802.3-2005 (Carrier sense multiple access with collision detection access method and physical layer specifications) EPON access device technical specification of CTC R2.1 ITU-T G.652 and G.657(Characteristics of a single-mode optical fibre and cable) CCSA EPON regulation amendment for PX20+, PR20, PRX20, PR30, and PRX30 sublayer requirement YD/T 1475-2006 access technical requirements - EPON EPON physical ID format for LDRA Option 18 and Option 37 specification of CTC R3.0 technical requirements for Broadband access network: subscriber access loop (port) identification IEEE 802.3av-2009 (Co-existence and simultaneous operation of 1 Gb/s and 10 Gb/s and physical layer specifications IEEE 802.3av-2009 (PMD, RS, PCS, PMA, and MPCP Sub-Layer Requirements CTC EPON Specification V2.1/V3.0
The IEEE 802.3ah series of standards define how traffic is packetized and transported over the EPON. As per the IEEE 802.3ah protocol, each EPON optical fiber connection from the P-OLT supports:
• line rates of 1.25 Gb/s upstream • line rates of 1.25 Gb/s downstream The IEEE 802.3av series of standards define how traffic is packetized and transported over the EPON, 10G EPON, or both. As per the IEEE 802.3av protocol, each EPON optical fiber connection from the P-OLT supports:
• symmetric operation with line rates of 10 Gb/s upstream and downstream • support for TDM and WDM with line rates of 1/1, and 10/10 Gb/s upstream/downstream coexistence
• asymmetric operation with line rates of 1 Gb/s upstream, and 10 Gb/s downstream
• support for TDM and WDM with line rates of 1/1 and 10/1 Gb/s upstream/downstream coexistence
The 10G EPON OLT supports the coexistence of 10G EPON and 1G EPON ONUs on the same PON. In the downstream direction, the OLT transmits both 10 Gb/s and 1Gb/s signals in a WDM manner. In the upstream direction, the OLT receives both 10Gb/s and 1Gb/s signals in a TDMA manner. See Figure 10-3. In the case where the ONU uses a DFB laser in the upstream direction and the actual variance from the center wavelength of 1310nm is ± 8 nm then the card can support an external WDM implementation. The upstream 1G EPON receiver would be on another card. This allows sharing a fiber with 10G and 1G EPON without having to reprovision the existing 1G EPON customers to a new port or having the 1G customers effect the bandwidth available in the upstream of the 10G services.
10-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture Figure 10-3 Coexistence of 10/10G EPON, 10/1G EPON, and 1G EPON ONUs Downstream 10 Gb/s, 1577 nm 1 Gb/s, 1490 nm
10G-10G ONU
RF Video, 1555 nm 10G-1G ONU
OLT Upstream 1 Gb/s, 1310nm
10.3
1 Gb/s, 1310nm
10 Gb/s, 1270nm
1G-1G ONU
EPON implementation of ISAM ISAM provides the core processing, switching, and control functions. The ISAM shelves with their NT card and the EPON LT card comprise the conceptual OLT system from an EPON network point of view.
• In the upstream direction, ISAM interacts with the Ethernet switch and voice gateway using the NT cards. • In the downstream direction, ISAM distributes network traffic to the subscribers via the LT cards that terminate to the ONUs. The Alcatel-Lucent ONU products are edge devices that use EPON technology to extend a fiber optic cable from an OLT shelf to a subscriber residence, including single-family residences, multi-dwelling units, such as apartment buildings, small office or medium business offices or home office applications. See chapter “ISAM Support for the EPON ONU” for more information about the EPON ONU.
EPON physical layer Ethernet for subscriber access networks combine a minimal set of extensions to the IEEE 802.3 Media Access Control (MAC) and MAC control sublayers with a family of physical layers. The physical layers include optical fiber and voice-grade copper cable Physical Medium Dependent (PMDs) sublayers not only for point-to-point (P2P) connections in subscriber access networks, but also for a point-to-multi-point (P2MP) network topology with passive optical splitters. To support P2MP topology, IEEE 802.3ah extensions to the MAC control sublayers and reconciliation sublayers as well as to optical fiber PMDs. In addition, a mechanism for network operations, administration, and maintenance is included to facilitate network operations and troubleshooting. The hierarchy of the Ethernet PHY layer is as follows:
• Data Link Layer (layer 2) • PHY Layer (layer 1)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-9
10 — EPON Network Architecture
where the Data Link Layer (layer 2) consists of:
• LLC (Logical Link Control sublayer) • MAC (Media Access Control sublayer) • RS (Reconciliation Sublayer). This sublayer processes PHY Local/Remote Fault messages and handles DDR conversion
and the PHY Layer (layer 1) consists of:
• PCS (Physical Coding Sublayer). This sublayer performs auto-negotiation and coding such as 8b/10b encoding for EPON and 64b/66b encoding for 10G EPON. • PMA (Physical Medium Attachment Sublayer). This sublayer performs PMA framing, octet synchronization/detection, and x7 + x6 + 1 scrambling/de-scrambling. • PMD (Physical Medium Dependent sublayer). This sublayer consists of a transceiver for the physical medium. Figure 10-4 shows the reference model for the P2MP topology over EPON. Figure 10-4 Reference model for P2MP topology over EPON OSI REFERENCE MODEL LAYERS
LAN CSMA/CD LAYERS
LAN CSMA/CD LAYERS
HIGER LAYERS APPLICATION PRESENTATION SESSION TRANSPORT NETWORK
LLC-LOGICAL LINK CONTROL OR OTHER MAC CLIENT
OAM (OPTIONAL)
OAM (OPTIONAL)
MPMC-MULTI-POINT MAC CONTROL
MPMC-MULTI-POINT MAC CONTROL
MAC-MEDIA ACCESS CONTROL
MAC-MEDIA ACCESS CONTROL
RECONCILIATION
DATA LINK PHYSICAL
HIGER LAYERS
LLC-LOGICAL LINK CONTROL OR OTHER MAC CLIENT
RECONCILIATION OLT
ONU(s) GMI
GMI PCS PMA
PCS PMA
PHY
PMD
PHY
PMD
MDI
MDI PASSIVE OPTICAL NETWORK MEDIUM
GMII MDI OAM OLT
= GIGABIT MEDIA INDEPENDENT INTERFACE = MEDIUM DEPENDENT INTERFACE = OPERATIONS, ADMINISTRATION, AND MAINTENANCE = OPTICAL LINE TERMINAL
ONU = OPTICALNETWORK UNIT PCS = PHYSICAL CODING SUBLAYER PHY = PHYSICAL LAYER DEVICE PMA = PHYSICAL MEDIUM ATTACHMENT PMD = PHYSICAL MEDIUM DEPENDENT 21767
Figure 10-5 shows the reference model for the P2MP topology over 10G/10G EPON. 10-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture Figure 10-5 Architecture model for P2MP topology over 10G/10G EPON OSI REFERENCE MODEL LAYERS
LAN DSMACO LAYERS
Higher Layers APPLICATION PRESENTATION SESSION TRANSPORT NETWORK DATA LINK PHYSICAL
MAC CLIENT MAC CLIENT OAM (optional) OAM (optional) MULTIPOINT MAC CONTROL (MPCP) (Clause 77) MAC MEDIA MAC MEDIA ACCESS CONTROL ACCESS CONTROL RECONSILIATION (Clause 75)
OLT
XGMII
PHY
POS (Clause 76) FEC (Clause 76) PMA (Clause 76) PR-type PMD (clause 75) MDII Fiber
OSI REFERENCE MODEL LAYERS
LAN DSMACO LAYERS
Optical distributor comments
PON medium Fiber
Fiber
Higher Layers APPLICATION PRESENTATION SESSION TRANSPORT NETWORK DATA LINK PHYSICAL
MAC CLIENT OAM (optional) MULTIPOINT MAC CONTROL (MPCP) (Clause 77) MAC MEDIA ACCESS CONTROL RECONSILIATION (Clause 76)
ONU
XGMII
PHY
POS (Clause 76) FEC (Clause 76) PMA (Clause 76) PR-type PMD (clause 75) MDII
XGMII = MDI = OAM = OLT = ONU =
10 GIGABIT MEDIA INDEPENDANT INTERFACE MEDIA INDEPENDANT INTERFACE OPERATIONS, ADMINISTRATION & MAINTENANCE OPTICAL TERMINAL OPTICAL NETWORK UNIT
PCS = PHY = PMA = PMD =
PHYSICAL CODING SUBLAYER PHYSICAL LAYER DEVICE PHYSICAL MEDIUM ATTACHMENT PHYSICAL MEDIUM DEPENDENT 23417
Figure 10-6 shows the reference model for the P2MP topology over 10G/1G EPON
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-11
10 — EPON Network Architecture Figure 10-6 Architecture model for P2MP topology over 10G/1G EPON OSI REFERENCE MODEL LAYERS
LAN DSMACO LAYERS
Higher Layers APPLICATION PRESENTATION SESSION TRANSPORT NETWORK DATA LINK PHYSICAL
MAC CLIENT MAC CLIENT OAM (optional) OAM (optional) MULTIPOINT MAC CONTROL (MPCP) (Clause 77) MAC MEDIA MAC MEDIA ACCESS CONTROL ACCESS CONTROL RECONSILIATION (Clause 75)
OLT
XGMII
PHY
GMII
POS (Clause 76) FEC (Clause 76) PMA (Clause 76) PR-type PMD (clause 75) MDII Fiber
OSI REFERENCE MODEL LAYERS
LAN DSMACO LAYERS
Optical distributor comments
PON medium Fiber
Fiber
Higher Layers APPLICATION PRESENTATION SESSION TRANSPORT NETWORK DATA LINK PHYSICAL
MAC CLIENT OAM (optional) MULTIPOINT MAC CONTROL (MPCP) (Clause 77) MAC MEDIA ACCESS CONTROL RECONSILIATION (Clause 76) XGMII
PHY
ONU GMII
POS (Clause 76) FEC (Clause 76) PMA (Clause 76) PR-type PMD (clause 75) MDII
GMII
XGMII = GMII = MDI = OAM = OLT =
10 GIGABIT MEDIA INDEPENDANT INTERFACE GIGABIT MEDIA INDEPENDANT INTERFACE MEDIA INDEPENDANT INTERFACE OPERATIONS, ADMINISTRATION & MAINTENANCE OPTICAL TERMINAL
ONU = PCS = PHY = PMA = PMD =
OPTICAL NETWORK UNIT PHYSICAL CODING LAYER PHYSICAL LAYER DEVICE PHYSICAL MEDIUM ATTACHMENT PHYSICAL MEDIUM DEPENDENT 23417
Physical medium dependent (PMD) PMD Sublayer for EPON
The EPON PMD sublayer consists of the 1000Base-PX20+ transceiver for the physical medium, and is compliant with the IEEE 802.3-2005 1000Base-PX20 and CCSA EPON regulation amendment for 1000Base-PX20+ sublayer requirement. In addition to 1000Base-PX20 PMD, the 1000Base-PX20+ also provides P2MP 1000BASE connection over PON up to 20 km with a typical split ratio of 1:32, or 10 km with 1:64 split ratio. The objective of 1000Base-PX20+ is to provides P2MP 1000Base service over a single-mode fiber with BER better than or equal to 10-12 at PHY service interface. Table 10-1 defines the 1000BASE-PX20 PMD. 10-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture Table 10-1 1000BASE-PX20+ PMD definition Description
1000Base-PX20+-U
Fiber type
1000Base-PX20+_ D
B1.1, B1.3 SMF
—
1
—
Number of fiber Nominal transmit wavelength Direction
Unit
1310
1490
nm
Upstream
Downstream
—
Minimum range
.5 m to 20 km
Optical power budget
30
— 29.5
dB
Maximum channel insertion loss
28
dB
Minimum channel insertion loss
10
dB
A 1000Base-PX20+ link uses a 1000Base-PX20+-U PDM at one end and a 1000Base-PX20+-D PMD at the other. However a 1000Base-PX20+-D PMD is interoperable with a 1000Base-PX20-U PMD to support upgrade possibilities of 1:32 to 1:64 split ratio. A 1000Base-PX20+ link does allow 1000Base-PX20+-D PMD to interoperate with 1000Base-PX10-U PMD to increase the maximum access range from 10 km to 20 km. PMD sublayer for 10G EPON
A 1000Base-PX30/1000Base-PRX30 link is used to support upgrade possibilities of 1:32 to 1:128 split ratio. A 1000Base-PX30/1000Base-PRX30 link allows interoperability to increase the maximum access range from 10 km to 20 km. Table 10-2 describes the illustrative channel insertion loss and penalties for PR10, PR20 and PR30 (symmetric-rate, 10 Gb/s power budget classes). Table 10-2 Channel insertion loss and penalties for PR10, PR20, and PR30 Description
PR10
PR20
US
DS
Fiber type
PR30
US
DS
US
DS
IEC 60793-2 B1.1, B1.3 SMF ITU-T G.652, G.657 SMF
Measurement wavelength for fiber
1270 nm
Nominal distance Available power budget
1577 nm
1270 nm
10 km 23 dB
1577 nm
1270 nm
20 km 21.5 dB
27 dB
1577 nm
20 km
25.5 dB
32 dB
30.5 dB
Channel insertion loss (max)
20 dB
24 dB
29 dB
Channel insertion loss (min)
5 dB
10 dB
15 dB
Allocation for penalties
3 dB
2.5 dB
3 dB
Optical return loss of ODN (min)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
1.5 dB
3 dB
1.5 dB
20 dB
November 2013
10-13
10 — EPON Network Architecture
Table 10-3 describes the illustrative channel insertion loss and penalties for PRX10, PRX20, and PRX30 (asymmetric-rate, 10 Gb/s downstream, 1 Gb/s upstream power budget classes). Table 10-3 Channel insertion loss and penalties for PRX10, PRX20, and PRX30 Description
PRX10
PRX20
US
DS
Fiber type
PRX30
US
DS
US
DS
IEC 60793-2 B1.1, B1.3 SMF ITU-T G.652, G.657 SMF
Measurement wavelength for fiber
1310 nm
Nominal distance
1577 nm
1310 nm
10 km
Available power budget
23 dB
1577 nm
1310 nm
20 km 21.5 dB
26 dB
1577 nm
20 km
25.5 dB
30.4 dB
30.5 dB
Channel insertion loss (max)
20 dB
24 dB
29 dB
Channel insertion loss (min)
5 dB
10 dB
15 dB
Allocation for penalties
3 dB
2.5 dB
Optical return loss of ODN (min)
2 dB
1.5 dB
1.4 dB
1.5 dB
20 dB
Physical medium attachment, physical coding, and reconciliation sublayers The PMA, PCS, and RS sub-layers in ISAM are compliant with Clause 65 of IEEE 802.3-2005 for EPON and IEEE802.3av for 10G EPON.
• The PMA sublayer performs PMA framing, octet synchronization/detection, and x7 + x6 + 1 scrambling/de-scrambling. • The PCS sublayer helps to define the physical layer specifications, such as speed and duplex modes, for networking protocols like Fast Ethernet, Gigabit Ethernet and 10-GE. It performs auto-negotiation and coding such as 8b/10b encoding. • The RS sublayer processes PHY local/remote fault messages and handles DDR conversion. The transmit function of the extended RS replaces some of the octets of the preamble, as transmitted by the MAC.
Multipoint MAC control protocol The EPON network allows only one ONU to transmit in the upstream direction at a time. The MPCP located at the OLT times the transmissions of multiple ONUs. MPCP reports traffic congestions, which optimizes the allocation of bandwidth across the PON. The MPCP comprises the following processing functions:
• discovery processing This function manages the discovery process of an ONU and compensates for round trip time.
10-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture
• report processing This function manages the generation and collection of report messages through which bandwidth requests are sent upstream from the ONU to the OLT. • gate processing This function manages the generation and collection of gate messages, through which multiplexing of multiple transmitters is achieved. In the discovery phase, each registered ONU is designated a unique LLID. The OLT supports 64 LLIDs for each PON interface over EPON. For 10G EPON, the OLT supports 128 LLIDs for each PON interface.
Dynamic bandwidth allocation Dynamic bandwidth allocation (DBA) is the process by which an ONU requests upstream bandwidth and whereby the OLT re-assigns bandwidth accordingly to improve upstream bandwidth utilization and to guarantee service equality. To process the bandwidth requests from the ONUs, ISAM monitors the queue status of all LLIDs and reassigns upstream bandwidth accordingly. ISAM supports the following bandwidth types:
• fixed bandwidth. The upstream bandwidth is reserved for the ONU so that the OLT always sends a constant grant to the ONU even without an upstream request. This bandwidth is not included in DBA scheduling. • assured bandwidth. The OLT sends the corresponding grant according to the MPCP report message from the ONU. If the upstream request is less than the grant assigned by the OLT, the surplus bandwidth can be used by other ONUs through DBA. • best-effort bandwidth. The ONU can use the surplus bandwidth on the PON if there are no bandwidth requests from services that have higher priority. ISAM EPON supports a minimum DBA bandwidth granularity of 64 kb/s and ±5% DBA precision.
Forward error correction Forward error correction (FEC) corrects transmission errors on the PON by inserting redundant information into the bit stream to recover errors. The ISAM transport layer between the ONU and the OLT uses a block-based FEC to transmit the data in an encoded format. The encoding introduces redundancy that allows the decoder to detect and correct the transmission errors. For example, for input BER of 10-4, the BER at the FEC decoder's output may drop to 10-15. By using the FEC technique, data transmission with low error rates can be achieved, and retransmissions are avoided. FEC results in an increased link budget. Therefore, higher bit rate and a longer distance from the ISAM to the ONUs can be supported. Alternatively, a higher number of splits per single PON tree can be achieved over an equivalent distance.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-15
10 — EPON Network Architecture
ISAM uses Reed-Solomon FEC to correct transmission errors on the PON. Reed-Solomon FEC is a block-based code that inserts bits at the end of a data block of a specific size to create a code word. Using the extra bits, the FEC decoder processes the data stream, discovers errors, corrects error, and recovers the original data. Reed-Solomon code is specified in CMTT recommendation CCIR 723. When a system uses a block-based FEC, the original data is preserved. Therefore, by ignoring the parity bits, the original data can be processed, even if the other side does not support FEC. However, block-based FEC error correction is not efficient for very high BER levels (for example, for 10-3 BER, a decoding error will be generated). In ISAM over EPON, FEC can be enabled or disabled in the downstream direction on a per-PON basis, or in the upstream direction on a per-ONU basis. For 10G EPON, FEC can be enabled forcibly in both the upstream and downstream directions of 10/10 Gb/s data rate per PON, and in the downstream direction of 10/1 Gb/s data rate per PON. The FEC function of the P-OLT is configurable for upstream of 10/1 Gb/s data rate per PON.
OTDR functionality Optical Time Domain Reflectometry (OTDR) is used to detect faults and degradations on optical links. OTDR-capable EPON SFPs for 1G only can be deployed in the ISAM. The configuration of the OTDR function in the ISAM and the analysis of the OTDR measurements are done by the 5530 Network Analyzer Fiber. The PON port on the LT card can support an SFP with an integrated OTDR function. The OTDR function provides a means to continuously monitor an optical path to measure the length of the fiber, and the physical location of any fiber breaks or degradations. The operator can enable, on a per-PON basis, a background process on the LT card to collect the OTDR data from the SFP. Raw measurements are collected every 225 s and up to a maximum of two-hours worth of data per enabled PON. After the two-hour period expires, the background process overwrites the raw measurements from the first hour. Using an EMS or SNMP interface, an operator can retrieve the following OTDR data for analysis and troubleshooting purposes:
• raw measurements for current or previous hour • summed measurements for up to 25 previous hours • calibration measurements Security ISAM supports the following security features:
• Triple churning • Advanced Encryption Standard (AES)
10-16
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture
• Authentication • Other security features to avoid unlawful attacks and interceptions Note — DPoE supports AES in Cipher Feed Back (CFB) mode, and CTC supports triple churning.
Triple churning
The ISAM uses broadcasting mode in the downstream. To ensure security of data from the OLT to the ONU, the ISAM EPON supports the triple churning function that is defined in the China Telcom EPON equipment technical requirement specifications. In general, the OLT requests a churning key (new_key_request) from the ONU, and the ONU responds with a 3-byte churning key (new_churning_key) for 1G EPON and 9-byte churning key for 10 G EPON that the OLT uses to generate a scramble key. The OLT then uses the scramble key to scramble all frames, including OAM frames, before sending to the ONU. The triple churning can be enabled or disabled on a per-LLID basis, and each LLID can have its own churning key. Advanced Encryption Standard (AES)
The ISAM supports AES security features for DPoE links for operation and maintenance. Specifications are compliant with IEEE 802.1 ae and provides protection of all frames from malicious attacks at an EPON link in both the upstream and downstream directions. The EPON OLT and ONU provide link security for up to 64 ONUs using a 128 bits Galois/Counter Mode Advanced Encryption Standard (GCM-AES) authenticated encryption to provide user data confidentiality, frame data integrity, and data origin authenticity to subscribers at a maximum 2 Gbps for the EPON system using Counter-AES (CTR-AES).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-17
10 — EPON Network Architecture
Authentication
ISAM only allows ONUs that pass authentication to access the EPON network. ISAM supports three ONU authentication modes as specified in the CTC EPON equipment technical requirements specifications R2.1. The PON can be configured for one of the following authentication modes:
• physical ID (MAC-based) authentication. Only ONUs with a physical identifier that passes authentication as per IEEE 802.3-2005 can register at the PON. This authentication is performed during the ONU discovery phase. In EPON deployments, the physical identifier is the MAC address of the ONU. • Logical ID authentication. Only ONUs with a logical identifier that passes authentication can register at the PON. In release 4.2.30, the logical ID can either be the ONU ID, a password, or the combination of ONU ID and password. It is recommended that the latter be implemented through extended OAM. This authentication is performed after the ONU discovery phase. When the authentication fails, the OLT will un-register the ONU even though the ONU has passed the discovery phase. • mix-based authentication. In this mode, the ISAM authenticates the ONU based on the physical ID or the logical ID. If the physical ID authentication fails, ISAM then checks the logical ID before registering the ONU. This mode is applicable for legacy deployments where the authentication mode migrated from physical to logical. Note — To avoid registration storms due to authentication failures, ISAM requires that an ONU waits at least 60 s before attempting to re-register.
Other security features
In addition to authentication, ISAM also provides the following security features to avoid unlawful attacks and interceptions:
• filtering • anti-spoofing • CPU overloading protection ONU ID method ISAM allows for configuration of the ONU ID method that can be used at both the system and ONT levels for planning and security purposes. The ONT level ONU ID method takes higher priority than the system level ONU ID method. The operator can configure whether the OLT will provide the MAC address or the LOGICAL ID as the ONU ID in DHCP option 82 or PPPoE relay tag. DHCP option82 is compliant with the MII standard. When the MAC address is used for ONU authentication, the service configuration is retained to simplify and improve the process of ONU replacement.
10-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture
ONU ranging Ranging is the process by which the propagation delay between the OLT and the ONU is measured. The OLT performs the round trip delay computation using the timestamp in the MPCP messages from the ONU. The OLT and the ONU have 32-bit counters that increment every 16 ns. These counters provide a local time stamp. When either device transmits an MPCPDU, it records its counter value into the timestamp field. To set the timestamp value, the time of transmission of the first octet of the MPCPDU frame from the MAC control to the MAC is used as the reference time. When the ONU receives MPCPDUs, the ONU sets its counter according to the value in the timestamp field in the received MPCPDU. When the OLT receives MPCPDUs, the OLT uses the received timestamp value to calculate or verify a Round Trip Time (RTT) between the OLT and the ONU. The RTT is equal to the difference between the time value and the value in the timestamp field. The MAC client then uses the calculated RTT for ranging.
ONU discovery and activation Discovery is the process by which offline or newly-connected ONUs are provided access to the PON. The OLT drives the process. On a periodic basis, the OLT makes available Discovery Time Windows. At these times, the offline ONUs can make themselves known to the OLT. The OLT broadcasts a discovery gate message to advertise a discovery period. The message includes the starting time and length of the discovery window. After the ONU receives this message, offline ONUs wait until the period begins to send a Register Request message to the OLT. Discovery windows are the only times when multiple ONUs can simultaneously access the PON. Therefore, transmission overlaps may occur. To minimize overlapping transmissions, online ONUs temporarily stop transmitting to the PON, and offline ONUs wait a random period of time that is less than the length of the discovery time window before sending their Register Request message. After the OLT receives a valid Register Request message from an ONU, the following events occur. 1
The OLT registers the ONU, assigns a port identifier (LLID) to the ONU, and relates the MAC address of the ONU to the LLID.
2
The OLT sends the LLID and the required synchronization time to the ONU.
3
The OLT echoes the maximum number of pending grants.
4
The OLT schedules the ONU to the PON.
5
The OLT sends a standard gate message to the ONU.
6
The ONU acknowledges the registration by sending a Register ACK.
The discovery process is complete when the OLT receives the Register ACK from the ONU. The ONU is registered and the OLT and the ONU can exchange normal messages.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-19
10 — EPON Network Architecture
The OLT monitors report messages that are received from online ONUs for transmission requests. In return, the OLT sends gate messages to the ONUs to report their allocated DBA grants. To maintain the watchdog timer at the ONU, the OLT periodically generates DBA grants when empty gate messages are sent.
Operations, administration, and maintenance The ISAM supports the following OAM functions for DPoE, TK, and CTC service modes:
• standard OAM functions specified in clause 57 of IEEE802.3-2005 • the managed object class, and attribute and action in clause 30 of IEEE802.3-2005
• extended DPoE OAM functions compliant with DPoE Specification OAM V1.0, section 9.3 to support the following:
• • • • • • • • • • • • •
ACL CCL enable/disable port - MAC enable status S1 Interface port auto-negotiation ONU bridging aging time optical monitoring OAM frame rate UNI statistics counter ONU bridge mode dynamic MAC table, dynamic learning mode, and MAC learning MAX allowed dying gasp LOS alarm C-VLAN TPID S-VLAN TPID
• extended TK OAM functions compliant with DPoE Specification OAM V1.0, section 9.3 to support the following:
• • • • • • • • • • • •
10-20
ACL CCL S1 Interface port auto-negotiation ONU bridging aging time optical monitoring OAM frame rate UNI statistics counter multicast mode fast leave ONU bridge mode dynamic MAC table, dynamic learning mode, and MAC learning MAX allowed dying gasp LOS alarm
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture
• extended OAM functions compliant with CTC requirements to manage remote EPON ONU. The extended OAM includes the following functions:
• • • • • • • • • • • • • • • • • • • • • • • • • • • •
extended OAM discovery and capability notification ONU basic information and ability notification FEC configuration triple churning mechanism DBA configuration subscriber port management VLAN management multicast configuration QoS management, such as traffic classification and remarking ONU reset and software upgrade ONU authentication based on logical identifier or MAC address ONU alarm rogue ONU discovery and closure embedded OTDR functionality RSSI support on SFPs for EPON port voice service configuration option to configure ONU ID method at both system and ONT level DHCP option 82 compliant with MII standard Lightweight DHCPv6 Relay Agent (LDRA) compliant including option 18 and option 37 China NBI support ONU configuration data preservation option to configure ONU Ethernet port mode and speed forwarding of IPv6 UC/MC traffic in the iBridge VLAN at the data plane improved process to retain ONU service configuration for ONU replacement CTC V2.1/V3.0 for 10G EPON requirements proprietary OAM support for downstream queueing and scheduling per SFU BCMP protocol support Ethernet port loopback detection
ISAM supports a maximum of 2000 bytes of standard and extended OAM PDU. Typically, ISAM manages the SFU/SBU through OAM. However, ISAM uses a hybrid way to manage the MDU/MTU because neither standard nor extended OAM are sufficient to configure complex services, such as voice services on the ONU with VoIP functionality. As per WT-142 recommendation, the 802.3ah OAM and extended OAM support the configuration and management of PON and ONU interfaces, for which they were designed. Other management protocols, such as SNMP or TR-069, complement OAM in layer 3 and above to support the configuration and management of subscriber services. Note — The operator can configure the system to use the same management VLAN for the OLT and for the ONU.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-21
10 — EPON Network Architecture
Performance monitoring and troubleshooting The ISAM provides tools for the operator to measure and monitor the performance of the EPON system, and to troubleshoot problems. The tools include:
• Performance counters • Reports • Alarms The EPON OLT provides NBI support for monitoring the following optics:
• configurable upper and lower alarm thresholds • raised alarm for upper or lower threshold crossings • cleared alarm option if either the upper or lower clearing threshold is crossed Performance counters
ISAM provides on-demand counters to monitor EPON layer traffic and performance on the OLT and the ONU sides, and the traffic on the UNI in 15-min or 1-day intervals. These counters enable service providers to:
• • • • •
set a baseline for performance get a high-level view of the activity at a specific point in the network detect problems when they occur diagnose the cause of problems plan for development and growth
DPoE statistics and counters are compliant with OAM V1.0 specifications and supported on an ONU PON MAC and UNI port level. Counters on the logical link and queue level are not supported. Table 10-4 describes the performance counters by performance monitoring type. Types include:
• OLTPON monitoring type • ONTPON monitoring type • ONTENET monitoring type Table 10-4 PM counters Performance monitoring counter
Location
Direction
Description
Transmit
A count of octets
OLTPON monitoring type OCTS
Near end
Receive FRAME
Near end
Transmit
A count of frames
Receive (1 of 5)
10-22
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture
Performance monitoring counter
Location
FSTSEG
Near end
Direction
Description
Transmit
A count of 64 octet frames
Receive SECSEG
Near end
Transmit
A count of 65 to 127 octet frames
Receive THIRDSEG
Near end
Transmit
A count of 128 to 255 octet frames
Receive FORTHSEG
Near end
Transmit
A count of 256 to 511 octet frames
Receive FIFTHSEG
Near end
Transmit
A count of 511 to 1023 octet frames
Receive SIXSEG
Near end
Transmit
A count of 1024 to 1518 octet frames
Receive LASTSEG
Near end
Transmit
A count of 1519 or more octet frames
Receive UCFRAMES
Near end
Transmit
A count of unicast frames
Receive MCFRAMES
Near end
Transmit
A count of multicast frames
Receive BRDFRAME
Near end
Transmit
A count of broadcast frames
Receive DRPDFRMS
Near end
Transmit
A count of dropped frames
Receive ERRFRAMES
Near end
Transmit
A count of error frames
Receive CRCERR
Near end
Transmit
A count of CRC error frames
Receive UNDFRAMES
Near end
Transmit
A count of underrun frames
Receive OVRFRAMES
Near end
Transmit
A count of overrun frames
Receive DROPEVENTR
Near end
Transmit
A count of dropped events
Receive FRAGMENTS
Near end
Transmit
A count of fragments
Receive JABBERFRAMES
Near end
Transmit
A count of jabber frames
Receive STATUSCHANGE
Near end
Transmit
A count of status changes
Receive ONTPON monitoring type (2 of 5)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-23
10 — EPON Network Architecture
Performance monitoring counter
Location
Direction
Description
OCTS
Far end
Transmit
A count of octets
Receive FRAME
Far end
Transmit
A count of frames
Receive FSTSEG
Far end
Transmit
A count of 64 octet frames
Receive SECSEG
Far end
Transmit
A count of 65 to 127 octet frames
Receive THIRDSEG
Far end
Transmit
A count of 128 to 255 octet frames
Receive FORTHSEG
Far end
Transmit
A count of 256 to 511 octet frames
Receive FIFTHSEG
Far end
Transmit
A count of 511 to 1023 octet frames
Receive SIXSEG
Far end
Transmit
A count of 1024 to 1518 octet frames
Receive LASTSEG
Far end
Transmit
A count of 1519+ octet frames
Receive UCFRAMES
Near end
Transmit
A count of unicast frames
Receive MCFRAMES
Near end
Transmit
A count of multicast frames
Receive BRDFRAME
Near end
Transmit
A count of broadcast frames
Receive DRPDFRMS
Near end
Transmit
A count of dropped frames
Receive ERRFRAMES
Near end
Transmit
A count of error frames
Receive CRCERR
Near end
Transmit
A count of CRC error frames
Receive UNDFRAMES
Near end
Transmit
A count of underrun frames
Receive OVRFRAMES
Near end
Transmit
A count of overrun frames
Receive DROPEVENTR
Near end
Transmit
A count of dropped events
Receive FRAGMENTS
Near end
Transmit
A count of fragments
Receive JABBERFRAMES
Near end
Transmit
A count of jabber frames
Receive (3 of 5)
10-24
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture
Performance monitoring counter
Location
Direction
Description
STATUSCHANGE
Near end
Transmit
A count of status changes
Receive ONTENET monitoring type OCTS
N/A
Transmit
A count of octets
Receive FRAME
N/A
Transmit
A count of frames
Receive FSTSEG
N/A
Transmit
A count of 64 octet frames
Receive SECSEG
N/A
Transmit
A count of 65 to 127 octet frames
Receive THIRDSEG
N/A
Transmit
A count of 128 to 255 octet frames
Receive FORTHSEG
N/A
Transmit
A count of 256 to 511 octet frames
Receive FIFTHSEG
N/A
Transmit
A count of 511 to 1023 octet frames
Receive SIXSEG
N/A
Transmit
A count of 1024 to 1518 octet frames
Receive LASTSEG
N/A
Transmit
A count of 1519+ octet frames
Receive BRDFRAME
N/A
Transmit
A count of broadcast frames
Receive CRCERR
N/A
Transmit
A count of CRC error frames
Receive PAUSEFRAME
N/A
Transmit
A count of pause frames
Receive UCFRAMES
NA
Transmit
A count of unicast frames
Receive MCFRAMES
NA
Transmit
A count of multicast frames
Receive DRPFRMS
NA
Transmit
A count of dropped frames
Receive ERRFRAMES
NA
Transmit
A count of error frames
Receive UNDFRAMES
NA
Transmit
A count of underrun frames.
Receive OVRFRAMES
NA
Transmit
A count of overrun frames.
Receive (4 of 5)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-25
10 — EPON Network Architecture
Performance monitoring counter
Location
Direction
Description
STATUSCHANGE
NA
Transmit
A count of status change
Receive DROPEVENTR
Near end
Transmit
A count of dropped events
Receive FRAGMENTS
Near end
Transmit
A count of fragments
Receive JABBERFRAMES
Near end
Transmit
A count of jabber frames
Receive (5 of 5)
Reports
ISAM provides reporting facilities for the operator to monitor and diagnose the optical link. The operator can report optical measurements between the P-OLT and a specific ONU, or between the P-OLT and all ONUs under a specific PON.
• The reporting facility allows the operator to view the following OLT and ONU optical signal levels:
• • • •
ONU receive optical signal level at 1490 nm ONU transmit optical signal level at 1310 nm OLT receive optical signal level at 1310 nm OLT transmit optical signal level at 1490 nm
• The RSSI capabilities of the optics module allow the operator to report the following operating conditions of the optics module on the ONU and on the PON:
• • • •
laser bias current supply voltage operating temperature Rx and Tx power levels
• For each operating condition, operators can configure and retrieve four RSSI thresholds for warnings and alarms on optic modules for EPON uplink ports on the LT, NT, and NTIO boards for monitoring and troubleshooting purposes. The related alarms and warnings are triggered or cleared according to the real-time status of optical modules on PON ports. The following thresholds are supported:
• • • •
alarm high alarm low warning high warning low
Table 10-5 describes the RSSI profile support on SFPs / XFPs per board type.
10-26
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture Table 10-5 RSSI thresholds for supported SFPs / XFPs per board type Board Type
Mnemonic
8-port EPON LT
FPLT-A
Supported SFPs/XFPs
Limit of Thresholds per RSSI Profile
EPON PX20+
20
EPON PX20+ OTDR 4-port 10G EPON LT NT / NTIO
FPXT-A
PRX30 /PR30 XFP
32 28
FANT-F
GE-BX10-D
FNIO-B
1000Base-T
NANT-A
10GE-R
ECNT-A
1000Base - PX20-U
ECNT-C
Thresholds, alarms, and warnings can be configured and monitored to retrieve information in each profile, for example, one threshold profile can be associated with a specific EPON uplink port on the LT, NT and NTIO boards. Improved alarm reporting is supported when optic fiber interruptions occur. When the EPON ramose fiber interruption occurs, the alarm REPORTTIMEOUT will be displayed. When the EPON trunk fiber interruption occurs, the alarm EPONLOS will be displayed. Alarms
ISAM supports configurable high and low threshold values for certain ONU alarm conditions at a specific PON interface or ONU interface on the PON. An alarm is raised if the condition exceeds the specified threshold value in a time period. Not all alarm conditions have TCA support. Table 10-6 identifies TCA-supported ONU alarm conditions by interface location. Locations include:
• PON interface • ONU interface • OLT interface Table 10-6 TCA-supported ONU alarm conditions Alarm
Description
PON interface RXPWLO
Receive optical signal too low alarm
RXPWHI
Receive optical signal too high alarm
TXPWHIALM
Transmit optical power too high
TXPWLOALM
Transmit optical power too low
TXBIASHIALM
Transmit bias too high
TXBIASLOALM
Transmit bias too low
(1 of 3)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-27
10 — EPON Network Architecture
Alarm
Description
VOLHIALM
Voltage too high
VOLLOALM
Voltage too low
TEMPEHIALM
Temperature too high
TEMPLOALM
Temperature too low
TXPWHIWARN
Transmit optical power too high
TXBIASHIWARN
Transmit bias too high
TXBIASLOWARN
Transmit bias too low
VOLHIWARN
Voltage too high
VOLLOWARN
Voltage too low
TEMPEHIWARN
Temperature too high
TEMPELOWWARN
Temperature too low
EXTTXPWHIALM
XFP transmit optical power too high
EXTTXPWLOALM
XFP transmit optical power too low
EXTTXBIASHIALM
XFP transmit bias too high
EXTTXBIASLOALM
XFP transmit bias too low
EXTTXPWHIWARN
XFP transmit optical power too high
EXTTXPWLOWARN
XFP transmit optical power too low
EXTTXBIASHIWARN
XFP transmit bias too high
EXTTXBIASLOWARN
XFP transmit bias too low
ONU interface TEMPLOW
Temperature too low alarm
TEMPHIGH
Temperature too high alarm
TEMPELOWARN
Temperature too low warning alarm
TEMPEHIWARN
Temperature too high warning alarm
VOLLO
Voltage too low alarm
VOLHI
Voltage too high alarm
VOLLOWARN
Voltage too low warning
VOLHIWARN
Voltage too high warning
TXBIASLO
Transmit bias too low alarm
TXBIASHI
Transmit bias too high alarm
TXBIASLOWARN
Transmit bias too low warning
TXBIASHIWARN
Transmit bias too high warning
TXPWLO
Transmit optical signal too low alarm
TXPWHI
Transmit optical signal too high alarm
TXPWLOWARN
Transmit optical signal too low warning
TXPWHIWARN
Transmit optical signal too high warning
RXPWLO
Receive optical signal too low alarm
(2 of 3)
10-28
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
10 — EPON Network Architecture
Alarm
Description
RXPWHI
Receive optical signal too high alarm
RXPWLOWARN
Receive optical signal too low warning
RXPWHIWARN
Receive optical signal too high warning
OLT interface OLTRXPWLO
Receive power from ONU at OLT side too high
OLTRXPWHI
Receive power from ONUT at OLT side too low
OLTRXPWLOWARN
Receive power low warning at OLT PON side
OLTRXPWHIWARN
Receive power high warning at OLT PON side
(3 of 3)
10.4
EPON system capacity Table 10-7 lists the capacity of the 7360 ISAM FX EPON system. Table 10-7 7360 ISAM FX EPON system capacity Item
Capacity
Maximum number of ONUs per PON
64
Maximum number of ONUs per EPON LT card
512
Maximum number of ONUs per system
8192
Maximum number of LLIDs per ONU
8
Maximum number of UNIs per PON
512
Maximum number of UNIs per LT card
4096
Maximum number of UNIs per system
26214
Table 10-8 lists the capacity of the 7360 ISAM FX 10G EPON system. Table 10-8 7360 ISAM FX 10G EPON system capacity Item
Capacity
Maximum number of ONUs per PON
128
Maximum number of ONUs per EPON LT card
512
Maximum number of ONUs per system
8192
Maximum number of LLIDs per ONU
8
Maximum number of UNIs per PON
1024
Maximum number of UNIs per LT card
4096
Maximum number of UNIs per system
26214
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
10-29
10 — EPON Network Architecture
10-30
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
11 — ISAM Support for the EPON ONU
11.1 Overview 11.2 EPON ONU
11-2 11-2
11.3 Supported features and services 11.4 Security
11-5
11-8
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
11-1
11 — ISAM Support for the EPON ONU
11.1
Overview The EPON ONU is a media converter that works with the OLT to form a seamless fiber access network that is capable of delivering high quality voice, video, and data services to single-family subscribers, multi-dwelling residential subscribers, and business subscribers. Figure 11-1 shows the EPON ONU in an EPON network topology. Figure 11-1 EPON network topology
PC
EPON ONU Video Server
STB
TV PC
EMAN
LAN
EMS
Splitter OLT
STB
RGW xPON ONU
PSTN
Phone Voice Gateway
Wireless access
Mobile device
This chapter describes the support that ISAM provides to the EPON ONU. Note — The terminology as defined in Rec. ITU-T G.984.1 (03/2008) is adopted in this chapter. The ONU (Optical Network Unit) is the generic term denoting a device that terminates any one of the distributed (leaf) endpoints of an Optical Distribution Network, implements a PON protocol, and adapts PON PDUs to subscriber service interfaces. In some cONUexts, an ONU implies a multiple-subscriber device. The ONU (Optical Network Termination) is a single subscriber device and is a special case of an ONU.
11.2
EPON ONU The EPON ONU is an edge device that uses EPON technology to extend a fiber optic cable from an EPON-OLT shelf at a central office to a subscriber residence, including single-family residences, multi-dwelling units (MDUs), such as apartment buildings and small office or home office applications. The ONU terminates the EPON physical and transmission convergence layer and provides the specific service interworking function that is required at the subscriber residence.
11-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
11 — ISAM Support for the EPON ONU
The EPON ONU products provide the following functions and services:
• network demarcation for all services • voice interworking function from the analog POTS lines to the VoIP/Ethernet layers
• CES encapsulation of DS1/E1 using the MEF-8 packetization format for transport across the layer 2 Ethernet PON • mux and demux functions to the PON • optical-to-electrical conversion All Alcatel-Lucent ONUs were developed using the following EPON IEEE standards:
• • • • • • •
IEEE 802.3-2005 Clause 60 (PMD) IEEE 802.3-2005 Clause 64.(MAC cONUrol) IEEE 802.3-2005 Clause 65 (RS layer) IEEE802.3-2005 Clause 57 (OAM) IEEE802.3av-2009 (10G EPON) YD/T 1475-2006 (OAM) China Telecom EPON equipment technical requirement specification V2.1/V3.0
Alcatel-Lucent provides a wide variety of ONU equipment including business units, indoor units, outdoor units, and modular and service plug-in units.
EPON ONU product series ONUs are available in various models. They can be used interchangeably on the EPON network so that network providers can mix ONU models to meet the needs of the subscribers to deliver services to single-family residences, multi-dwelling units, such as apartment buildings, and small office or home office applications. The product series of ONUs include the following:
• indoor ONU The indoor ONU terminates services at the subscriber premises, and is suitable for subscribers living in a single-family residence. The indoor ONU can be mounted to an interior wall, or installed on a desktop. The indoor ONU can provide voice, data, and IP video services. • outdoor ONU The outdoor ONU terminates services at the subscriber premises and is suitable for single residences and small office home office (SOHO) applications. The single residence and SOHO outdoor ONUs have environmentally hardened enclosures that you can install outside the subscriber premises. • MDU The multi-dwelling unit is suitable for multi-dwelling unit applications. The MDU supports ADLS2/ADLS2+/VDSL2 and Ethernet interfaces, which terminate at the customer premises. • business ONU Business ONUs are suitable for small business applications. The business ONU provides voice, data, IP video, and optionally RF video services to subscribers, and support CES DS1 or E1 connections at the business premises. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
11-3
11 — ISAM Support for the EPON ONU
EPON ONU product identification Table 11-1 identifies the EPON ONU product series. Table 11-1 EPON ONU product series identification Series
Product
SFU
Indoor ONUs
EONU
Outdoor ONUs Business ONUs
MDU
Modular ONUs
In a product series, each ONU model can be further identified by a mnemonic designation that defines the characteristics of the particular model, such as the voice, data, and video interfaces. Figure 11-2 shows an example of a mnemonic designation for an outdoor ONU. Figure 11-2 EPON ONU mnemonic designation example EONU16160-E
EONU
16
16
0
E Product vendor code Number of E1 ports
Number of POTS ports Number of FE ports EPON ONU 21768
Table 11-2 describes the general EPON ONU mnemonic designation. Table 11-2 General EPON ONU mnemonic designation Position in mnemonic
Description
Beginning characters
Series that the product belongs to
First pair of digits
Number of FE interfaces
Second pair of digits
Number of POTS interfaces
Fifth digit
Number of E1 interfaces
Character after the dash
Product ODM vendor code. The codes are:
• • • •
11-4
November 2013
space, A, or B for T&W C or D for Zyxel E or F for Dare H or I for Alpha
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
11 — ISAM Support for the EPON ONU
EPON ONU features The ONUs support the following EPON features:
• For 1G EPON systems: • efficient IP/Ethernet service traffic transport • 1 Gb/s line rate downstream and 1 Gb/s line rate upstream • PX20 optics with 28 dB optical link loss • PX20+ optics with 32 dB optical link loss • PX30 optics • integrated diplexer for ONUs supporting POTS and data • 1310 nm wavelength upstream • 1490 nm wavelength downstream • single-mode fiber and use 2x5 SFF SC/APC optical port • PON reach capacity of 20 km • configuration data preservation • option to configure ONU Ethernet port mode and speed • FEC functions • Rogue ONU discovery and closure • proprietary OAM support for downstream queueing and scheduling • Ethernet port loopback detection • DPoE link OAM support • For 10G EPON system: • support of efficient IP/Ethernet service traffic transport • 10Gb/s line rate downstream and 10Gb/s line rate upstream • 10Gb/s line rate downstream and 1Gb/s line rate upstream • PRX30 optics for 10G/1G EPON • PR30 optics for 10G/10G EPON • integrated diplexer for ONUs supporting POTS and data • 1270 nm wavelength upstream • 1577 nm wavelength downstream, • single mode fiber and use 2x5 SFF SC/APC optical port • PON reach capacity of 20 km • configuration data preservation • option to configure Ethernet port mode and speed • FEC functions for 10G EPON • rogue ONU discovery and closure
11.3
Supported features and services This section describes the following features and services that are supported for the EPON ONU:
• • • • •
xDSL Wi-Fi POTS Ethernet Forward Error Correction
• Rogue ONU Discovery and Closure • Proprietary OAM support for downstream queuing and scheduling • Ethernet port loopback detection
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
11-5
11 — ISAM Support for the EPON ONU
xDSL See chapter 7, “xDSL features”, for information about the supported xDSL features.
Wi-Fi The EPON ONU supports the following Wi-Fi certification standards from the IEEE: 802.11b, 802.11g, and 802.11n.
POTS The EPON ONU supports the voice interworking function from the analog POTS lines to VoIP/Ethernet. The ONU is based on a business chipset and a switch that provides layer 2 switching with filtering functions. In the upstream direction, the ONU assigns traffic to the LLID. In the downstream direction, the ONU performs layer 2 bridging.
• The POTS analog interfaces are part of the ONU on the subscriber side. • The VoIP signaling and bearer channels are terminated on the ONU on the OLT side. ISAM supports different modes of operation for VoIP services on the EPON ONU. These modes of operation include:
• SIP • H.248 softswitch (Megaco) SIP
SIP protocol complies with the IETF RFC 3261 and China Telecom SIP network gateway cONUrol protocol specification. SIP service configuration
Table 11-3 describes the possible sources of configuration information for SIP, which is different for the POTS service with the GPON ONU. In the case of the EPON ONU, the CT defines ways to configure VoIP services that support signaling protocols, such as H.248 softswitch and SIP. Table 11-3 Sources of SIP configuration data Source
Description
IEEE 802.3 OAM and CT extended OAM
Extended OAM is used to:
• • •
conduct service and protocol provisioning configure the overall VoIP service and individual POTS lines from the OLT provide a limited set of provisioning options for SIP
(1 of 2)
11-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
11 — ISAM Support for the EPON ONU
Source
Description
TR-069
ACS uses TR-069 for remote management of the EPON ONU. OAM allows for the remote management of layer 2 and lower functions of ONU, and the configuration of the management IP address and of the FTP IP address. The configuration profile is downloaded using TR-069.
(2 of 2)
Ethernet The Ethernet interfaces on the ONU support the following primary features:
• Ethernet port compliance with IEEE 802.3 • IEEE 802.3av compliance for 10G EPON • IEEE 802.1Q, 802.1x port-based authentication, and 802.1p (QoS classification per Ethernet port) • layer 3 DSCP to 802.1p mapping to allow layer 3 CoS over the layer 2 network • full or half duplex operations • auto-negotiation or manual setting by an operator See Chapter “Layer 2 forwarding” for the supported Ethernet L2 forwarding features. See Chapter “ISAM Support for the GPON ONU” for more information.
Forward Error Correction The EPON ONU supports the following FEC functions for the 10G EPON system:
• configurable upstream and downstream for 1G ONU • configurable upstream for 10G/1G ONU • always enabled for 10G/10G ONU Rogue ONU Discovery and Closure The EPON system will automatically identify faults or error conditions using alarms and statistics to inform operators of any problems or by using automatic action to disable a rogue ONU to avoid disruption in the PON. Conditions on one ONU may affect other ONUs using the same PON and cause disruption, so the system can help operators troubleshoot and manage rogue ONUs. The following faults or error conditions are automatically identified by the EPON system:
• PON unusable due to ONU laser light stuck in ON position • ONU de-registers due to duplicate ONU serial numbers which prevents correct ranging • ONU misinterprets the bandwidth map • ONU transmits the incorrect time slot allocation • ONU fails to transmit to correct time slot allocation
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
11-7
11 — ISAM Support for the EPON ONU
• ONU transmits incorrect signal timing which can disrupt other ONUs • ONU transmits signals too low or too high which can cause bit rate errors or ranging failure
Proprietary OAM support for downstream queuing and scheduling Hierarchical downstream scheduling and rate limiting is supported for downstream traffic management per ONU LLID and per service. For 1G EPON configurations, implementation is on the ONU side where OLT provisioning using Alcatel-Lucent proprietary OAM specifications can interoperate with the ONU. For 10G EPON configurations, implementation is on the OLT side, with no dependencies or interoperation with the ONU is required.
Ethernet port loopback detection The EPON ONU supports the loopback detection in the same Ethernet port or different Ethernet ports, The EPON OLT allows you to enable or disable the function per Ethernet port. When a loopback is detected on the ONU side, the ONU will trigger an alarm and send it to the OLT. The OLT reports the alarm messages to the EMS. The alarm will be cleared by the ONU when the loopback issue is resolved. The OLT can be configured to enable or disable the action of shutting down the port where the loopback exists. Depending on the configuration, the ONU or the OLT will shutdown the port.
11.4
Security To ensure security at the network and ONU level, the EPON ONU supports the following security mechanisms:
• Triple churning • ONU authentication at the PON See also chapter “EPON Network Architecture”, for more information about triple churning and authentication of the EPON ONU,
Triple churning The ISAM uses broadcasting mode in the downstream, which can allow hostile users to intercept other user messages. To improve the protection of the data from the OLT to the ONU, ISAM supports triple churning in the downstream as defined in the China Telecom EPON equipment technical requirement specifications. In general, the OLT requests a churning key (new_key_request) from the ONU, and the ONU responds with a 3-byte churning key (new_churning_key) for 1G EPON and a 9-byte churning key for 10G EPON that the OLT uses to generate a scramble key to scramble all data and OAM frames before sending these frames to the ONU. Triple churning can be enabled or disabled on a per-LLID basis, and each LLID can have its own churning key. The procedures to change and synchronize the churning key use the OAMPDU mode based on the organization-specific Extension. 11-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
11 — ISAM Support for the EPON ONU
ONU ID method ISAM allows for configuration of the ONU ID method that can be used at both the system and ONU levels for planning and security purposes. The ONT level ONU ID method takes higher priority than the system level ONU ID method. The operator can configure whether the OLT will provide the MAC address or the LOGICAL ID as the ONU ID in DHCP option 82 or PPPoE relay tag. When the MAC address is used for ONU authentication, the service configuration is retained to simplify and improve the process of ONU replacement.
ONU authentication on the PON The following authentication modes are supported for the EPON ONU.
• physical ID (MAC-based) authentication. In EPON deployments, the physical ID refers to the MAC address of the ONU. This authentication mode requires that the OLT has the ability to verify the MAC address of the ONU as per IEEE 802.3-2005. • logical ID authentication. In release 2.4.30, the logical ID can either be the ONU ID, a password, or the combination of ONU ID and password. It is recommended that the latter be implemented through extended OAM as proposed by China Telecom. • mixed-based authentication. This mode allows the OLT to authenticate an ONU using the physical ID or the logical ID. If the physical ID authentication fails, the OLT then checks the logical ID. This mode creates two additional ways to authenticate an ONU: MAC address plus ONU ID and MAC address plus password. Table 11-4 lists the possible identifiers for each authentication mode. Table 11-4 Authentication modes Authentication mode
MAC address
Logical iD ONU ID
Physical ID mode
Password
✓
Logical ID mode
✓ ✓ ✓
Mixed mode
✓
✓
✓ ✓
✓
✓ ✓
✓
Regardless of the authentication mode of the corresponding PON, the operator must specify either the physical identifier or the logical identifier of the ONU when configuring the ONU. The system ensures the uniqueness of the identifier on the PON based on the authentication mode of the PON. The password does not need to be unique if used in combination with a MAC address or ONU ID. However, the password must be unique if authentication is based on a password alone. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
11-9
11 — ISAM Support for the EPON ONU
The operator can change the authentication mode of a PON interface if the ONU MAC address is not statically provisioned. However, all ONU MAC addresses under the modified PON interface will be removed and all ONUs under the PON interface will deregister. Note — Conflicting passwords may occur if the authentication mode is changed from ONU ID plus password to password only. If a conflict is detected, the system will reject the request to change the authentication mode of the PON.
In the logical ID authentication mode, the operator does not need to preprovision an EPON ONU with its logical ID. However, because of a limitation with the EPON MAC chipset, the operator must preprovision an EPON ONU with its MAC address so that the MPCP process can be completed. If an unknown ONU MAC address is discovered, the MAC address is added to the white list of acceptable EPON MAC addresses. In this case, the MPCP process is completed when the ONU tries to reregister. However, the logical ID authentication starts regardless of whether the ONU MAC address is preprovisioned. If the authentication is successful, the SLA is enabled immediately and services start running. If the authentication fails, the ONU MAC address is removed from the white list. In logical ID authentication mode, the ONU can be authenticated either locally on the OLT or remotely at a centralized RADIUS server. Note — Release 4.2.30 of the EPON system does not support centralized remote authentication through a RADIUS server.
11-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
12.1 Introduction
12-3
12.2 Overall network topology
12-3
12.3 Access network L2/L3 topologies
12-8
12.4 Product Definition and Dimensioning 12.5 Traffic types and forwarding
12-14
12.6 Layer 2/layer 3 addressing topologies 12.7 Protocol stacks
12-13
12-44
12-75
12.8 Voice service and MPLS Pseudo-wire 12.9 Management interface
12-84
12.10 Permanent data storage 12.11 Management model
12-84
12-87
12-88
12.12 Reliability, Equipment / Connectivity / Overload Protection 12-96 12.13 Quality of Service
12-110
12.14 DNS interworking
12-110
12.15 BITS Support
12-112
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-1
12 — ISAM Voice Network Architecture
12.16 Narrowband Line Testing
12-112
12.17 Termination local loop unbundling 12.18 Alarm Treatment
12-113
12.19 Lawful Intercept
12-115
12.20 ISAM Voice migration
12-2
November 2013
12-112
12-120
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
12.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.
12.2
Overall network topology This section describes the overall network topology for:
• Megaco ISAM Voice situated in a Next Generation Voice Network (NGVN). • SIP ISAM Voice situated in a TISPAN-compliant NGN-IMS network. Megaco ISAM Voice in a NGVN network Megaco ISAM Voice supports Narrowband (NB) services and provides the connection to the NGVN 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).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-3
12 — ISAM Voice Network Architecture Figure 12-1 Megaco ISAM Voice situated in a NGVN network Subtending ISAM Voice
Softswitch
MGC
PSTN RTP
TGW
ASP
P O T S
Central Office ISAM Voice
Servers
I S D N POTS / ISDN
IP Network H.248 / SIGTRAN .
L2 Aggregation Network
IP edge
BAS
M G
P O T S
POTS/ ISDN
Remote ISAM Voice
P O T S
P O T S
I S D N
I S D N
POTS/ ISDN
POTS/ ISDN
Remote ISAM Voice
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 an 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.
12-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
SIP ISAM Voice in a TISPAN-compliant NGN-IMS network SIP ISAM Voice is a ETSI TISPAN PES compliant VGW. The ALU IMS PES Solution is a PSTN Emulation IMS subsystem specifically tailored to allow TDM equipment replacement, while keeping legacy terminals unchanged. It is based on TISPAN IMS-PES functional Architecture and provides
• • • •
Access for legacy POTS-line towards an IMS network through Access gateways A PSTN Service emulation in the IMS domain Interconnection with PSTN networks Interconnection with peer IP networks
The SIP based ISAM Voice gateway (VGW)
• • • • • •
Terminates the z-interface (z Reference point) Directly connects to the IMS-core (P_CSCF) Associates POTS lines with an IMS user identity REGISTERS each user at the IMS-core. Media conversion Voice-band => RTP packets Interacts with the AS based on the tightly coupled model Figure 12-2 The TISPAN IMS-PES functional architecture
Application Servers
Ut Ut
Network Attachment Subsystem e2
Sh
UPSF
Charging Functions Rf/Ro
Dh
ISC/Ma Cx
Dx
Iw
SLF
Ib
P3
IWF
IMS-based PES
e2
AGCF
Mx
M w Mw
I/S-CSCF
BGCF
MGCF
Ie
SGF
PSTN/ISDN
Gq'
Gq'
Mg
MRFC
Gq' Mp
Mn
Resource and Admission Control Subsystem
Other IP Networks
P-CSCF
Ic
Mk
Mj
Mx
Gm
IBCF
Mx Mi
Mr
Mw
Ut
Rf/Ro
PSTN/ISDN Emulation logic
P1
SIP/Gm
Rf/Ro
Other types of service logic
VGW MRFP
Z
Z
MG
T-MGF
IP Transport (Access and Core)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
I-BGF
November 2013
12-5
12 — ISAM Voice Network Architecture Figure 12-3 The Alcatel-Lucent TISPAN IMS-PES Solution 5020 MGC - 8 5020 MGC - 12 5020MGC - 10
5420 CTS
ISUP
SS7 MGCF
PSTN
5450 ISC
Feature Server
SIP
Session Control
8650 SDM
HSS
SIP
MGW
H.248
7510 MGW 7515 MGW 7520 MGW
IP Network
Voice
7302 ISAM
VGW
7342 ISAM OLT
SIP
7302/ 7330 ISAM
IP Access
3rd party VGW
7330 ISAM FTTN
TDM Access
SIP
SIP
SIP ONT
ONT RG
RG
Figure 12-4 The SIP based Voice Network Architecture DHCP Se r ve r
Mgmt Pla tfo r m
PSTN
DN S Se r ve r
SG F/ T-MG F S_CSCF
AS
MG CF
ISAM Voice
I_CSCF
P_CSCF
P O T S
RTP
P U O A T S POTS
ISAM Voice
HSS
SIP
MRF
x- CSCF/ BG CF
IMS Co r e
SBC
ER
IP N e two r k Vo ice G a te wa y
P O T S
P U O A T S POTS
L2 Ag g r e g a tio n N e two r k
IBCF/ IBGF
ISAM Voice
ER
O th e r IP Networks
Se rve rs
BAS
P O T S
ISAM Voice
P O T S
P U O T A S POTS
P O U T A S POTS
ISAM Voice connects legacy Narrow Band (NB) user interfaces, the Plain Old Telephone Services (POTS), to the NGN/IMS. 12-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
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 instance of the 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. 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 Intermediate 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 in a non-IMS-compliant network SIP 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 interface with voice feature servers acting as back-to-back SIP Servers via the SIP protocol.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-7
12 — ISAM Voice Network Architecture Figure 12-5 SIP ISAM Voice in a non-IMS-compliant network Management Platform
DHCP server
ISAM Voice
DHCP
SNMP/ CLI/TL1
P O T S
IP
POTS
SIP RTP / RTCP Media Gateway
SIP server
ISAM Voice connects legacy Narrow Band (NB) user interfaces, the Plain Old Telephone Services (POTS), to a non-IMS compliant 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. The role of the SIP ISAM Voice is twofold:
• Access Gateway. • Access Gateway Controller (maintains AG states, manages AG features, implements SIP UA).
12.3
Access network L2/L3 topologies Megaco ISAM Voice ISAM Voice access nodes being part of 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 network. The supported ISAM Voice Cluster topologies are shown in Figure 12-6, Figure 12-7, Figure 12-8, Figure 12-9, Figure 12-10 and Figure 12-11.
12-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-6 Megaco ISAM Voice: Voice Cluster topology A
xVPS pair 1
xVPS pair 2
xVPS pair 8
Main shelf
Voice LT 1
Voice LT 2
Voice LT 1
Voice LT 2
Voice LT 1
Voice LT 2
Voice LT shelf 1 Belongs to voice cluster supervised by xVPS pair 1
Voice LT shelf 2 Belongs to voice cluster supervised by xVPS pair2
Voice LT shelf 8 Belongs to voice cluster supervised by xVPS pair 8
Voice LT 16
Voice LT 16
Voice LT 16
Figure 12-7 Megaco ISAM Voice: Voice Cluster topology B
xVPS pair 1
xVPS pair 2
xVPS pair 3
Main shelf
Voice LT 1
Voice LT 2
Voice LT 1
Voice LT 2
Voice LT 1
Voice LT 2
Voice LT shelf 1 Belongs to voice cluster supervised by xVPS pair 1
Voice LT shelf 2 Belongs to voice cluster supervised by xVPS pair 2
Voice LT shelf 3 Belongs to voice cluster supervised by xVPS pair 3
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
Voice LT 16
Voice LT 16
Voice LT 16
12-9
12 — ISAM Voice Network Architecture Figure 12-8 Megaco ISAM Voice: Voice Cluster topology C
xVPS pair 1
xVPS pair 2
xVPS pair 3
Voice LT 1
Voice LT 2
Voice LT 1
Voice LT 2
Voice LT 1
Voice LT 2
Voice LT 10
Voice LTs belongs to voice cluster supervised by xVPS pair 1
Main shelf
Voice LT 1
Voice LT 2
Voice LT shelf 1 Belongs to voice cluster supervised by xVPS pair 1
Voice LT shelf 2 Belongs to voice cluster supervised by xVPS pair 2
Voice LT shelf 3 Belongs to voice cluster supervised by xVPS pair 3
Voice LT 16
Voice LT 16
Voice LT 16
Figure 12-9 Megaco ISAM Voice: Voice Cluster topology D
xVPS pair 1
xVPS pair 2 Main shelf
12-10
Voice LT 1
Voice LT 2
Voice LT 1
Voice LT 2
Voice LT 1
Voice LT 2
November 2013
xVPS pair 3
Voice LT 1
Voice LT 2
Voice LT 10
Voice LTs belong to different voice clusters supervised by xVPS pair 1, 2 or 3
Voice LT shelf 1 Belongs to voice cluster supervised by xVPS pair 1
Voice LT shelf 2 Belongs to voice cluster supervised by xVPS pair 2
Voice LT shelf 3 Belongs to voice cluster supervised by xVPS pair 3
Voice LT 16
Voice LT 16
Voice LT 16
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-10 Megaco ISAM Voice: Voice Cluster topology E
xVPS pair 1
xVPS pair 2
xVPS pair 8
Main shelf
Voice LT 1
Voice LT 1
Voice LTs in shelf 1 belong to voice cluster supervised by xVPS pair 1
Voice LTs in shelf 2 belong to voice cluster supervised by xVPS pair 2
Voice LT 1
Voice LT N
Voice LT N+1
Voice LT M
Voice LT M+1
Voice LTs in shelf 1 belong to voice cluster supervised by xVPS pair 2
Voice LTs in shelf 2 belong to voice cluster supervised by xVPS pair 1
Voice LT shelf 8 (multiple)
Voice LT 2
Belongs to voice cluster supervised by xVPS pair 8
Voice LT 16
Voice LT 16
Voice LT 16
Figure 12-11 Megaco ISAM Voice: Voice Cluster topology F
xVPS pair 1
xVPS pair 2
xVPS pair 3
Voice LT 1
Voice LT 1
Voice LTs in shelf 1 belong to voice cluster supervised by xVPS pair 1
Voice LTs in shelf 2 belong to voice cluster supervised by xVPS pair 2
Voice LT 1
Voice LT 2
Voice LT 10
Voice LTs belong to different voice clusters supervised by xVPS pair 1, 2 or 3
Main shelf
Voice LT 1
Voice LT 2
Voice LT N
Voice LT N+1
Voice LT M
Voice LT M+1
Voice LTs in shelf 1 belong to voice cluster supervised by xVPS pair 3
Voice LTs in shelf 2 belong to voice cluster supervised by xVPS pair 3
Voice LT shelf 3 Belongs to different voice clusters supervised by xVPS pair 1, 2 or 3
Voice LT 16
Voice LT 16
Voice LT 16
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-11
12 — ISAM Voice Network Architecture
The ISAM Voice access node can behave as a router. Figure 12-12 ISAM Voice access nodes connected to a layer 2 Aggregation Network
Iv
Iv Iv L2
L3 Aggrega tion Network
Iv
Aggrega tion Network
Iv Iv = ISAM Voice
Iv
Iv
Figure 12-13 ISAM Voice access nodes connected to a layer 3 Aggregation Network
Iv
Iv Iv L3
Iv
Aggrega tion Network
Iv IV= ISAM Voice
12-12
November 2013
Iv
IV
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-14 ISAM Voice access nodes connected to a layer 2/layer 3 Aggregation Network
Iv
Iv Iv L2
L3
Iv
Aggrega tion Network
Aggrega tion Network
Iv Iv = ISAM Voice
12.4
Iv
Iv
Product Definition and Dimensioning Megaco The H.248 (Megaco) signaling based integrated voice service is supported for the following products:
• 7302 ISAM: • POTS and ISDN BRI services supported. • Maximum 18 Voice LT slot positions (with single NT). • 7330 ISAM FTTN: • POTS and ISDN BRI services supported. • Maximum 10 Voice LT slot positions (with single NT). • 7356 ISAM FTTB SB-REM: • Only POTS service supported. • Maximum 2 Voice LT slot positions. SIP The SIP-signaling-based integrated voice services are supported in:
• 7302 ISAM: POTS service supported. Maximum 18 Voice LT slot positions (with single NT). • 7330 ISAM FTTN: POTS service supported. Maximum 10 Voice LT slot positions (with single NT).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-13
12 — ISAM Voice Network Architecture
• 7356 ISAM FTTB SB-REM: • POTS service supported. • Maximum 2 Voice LT slot positions. • Voice LT can be planned for both the “master” (72-lines LT board only) and the “non-master” (48- and 72-lines LT board) slot position.
IMS In 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
• • • • • •
12.5
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. 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 Narrow band Line Test is supported for SIP signaling POTS terminations (full NBLT set) and H.248 ISDN BRI terminations (limited NBLT set). 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.
Traffic types and forwarding Traffic Types Megaco ISAM Voice
Four traffic types can be distinguished:
• Management traffic (SNMP, CLI, TL1 (alarm display only)) exchanged between the OSS 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, Voice Band data). Management traffic is exchanged in the external communication VLAN and as such kept separate from the other traffic types. This is done for security reasons. 12-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
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 traffic types can be distinguished:
• Management traffic (SNMP, CLI, TL1 (alarm display only)) 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, Voice Band data). Management traffic is exchanged in the external communication VLAN and as such kept separate 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.
Traffic forwarding The internal forwarding is frame based and done at either layer 2 (Ethernet), layer 3 (IP) or layer 4 (UDP/TCP) obeying the 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
Figure 12-15 shows the MEGACO ISAM Voice switched model.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-15
12 — ISAM Voice Network Architecture Figure 12-15 Megaco ISAM Voice: switched model Main ISAM Voice Fast path VRF IP address voice
Voice LT
Voice VLAN
Signaling VLAN
IP address XLES
Voice server
NT
IP address signalling
• The network signaling VLAN terminates at the Voice server • The network RTP/RTCP (XLES) VLAN terminates at the voice LT board/Voice • • • • • •
server 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 IHub and is shared by all the Voice LT boards The IHub performs L4 forwarding for RTP/RTCP/XLES traffic destined to the voice LT board The IHub performs L2 forwarding for upstream/downstream signaling traffic The IHub performs L3 forwarding for upstream RTP/RTCP/XLES traffic.
Figure 12-16 shows the MEGACO ISAM Voice routed model. Figure 12-16 Megaco ISAM Voice: routed model Main ISAM Voice Fast path VRF
Voice LT
IP address Voice
Internal Voice VLAN
IP address User 1
IP address network 1 IP address network 2
Network VLAN 1
Network VLAN 2
IP address XLES
Voice server IP address signalling
Internal signaling VLAN
NT
The conceptual architecture shows different VLANs carrying H.248 signaling and RTP/RTCP/XLES traffic at the network side than at the user side (VLAN) of the VRF.
12-16
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
The internal VLAN that carries RTP/RTCP/XLES traffic performs L4 forwarding in downstream direction. At the IHub:
• 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 IHub is considered as the first next hop for the RTP/XLES packets sent in the upstream direction by the xVPS
• VRF user side: A numbered IP interface is configured on top of the internal signaling VLAN. The IHub is seen as the first next hop for the H.248 signaling traffic that originates from the Media Gateway running at the xVPS board. The signaling subnet is advertised (as host subnet) to the upstream network. • Network side: A numbered IP interface is configured on top of the network-side signaling VLAN. • 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). In the downstream direction, voice-service-related traffic (H.248 signaling, XLES, RTP and RTCP) may be received at any network interface/VLAN. The IHub 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. Figure 12-17 shows the SIP ISAM Voice (centralized architecture) switched model.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-17
12 — ISAM Voice Network Architecture Figure 12-17 SIP ISAM Voice (centralized architecture): switched model Main ISAM Voice Fast path VRF
Voice v-VPLS
Voice LT
IP address voice
Signaling v-VPLS
IP address signalling
Network v-VPLS 1 /VLAN 1 Network v-VPLS 2 /VLAN 2
NT
• The network signaling VLAN terminates at the voice LT board • The network RTP/RTCP VLAN terminates at the voice LT board • The source/destination IP address for SIP signaling traffic is configured at the IHub. It is shared by all the voice LT boards
• The source/destination IP address for RTP/RTCP traffic is configured at the IHub. It is shared by all the voice LT boards • The IHub performs L4 forwarding for SIP signaling/RTP/RTCP traffic destined to the voice LT board • The IHub performs L3 forwarding for upstream SIP signaling/RTP/RTCP traffic. Figure 12-18 shows the SIP ISAM Voice (centralized architecture) routed model. Figure 12-18 SIP ISAM Voice (centralized architecture): routed model Main ISAM Voice Fast path VRF
Voice LT
Internal Voice v-VPLS
IP address Voice IP address signaling
Internal signaling v-VPLS
IP address network 1 IP address network 2
Network v-VPLS 1 /VLAN 1
Network v-VPLS 2 /VLAN 2
NT
The conceptual architecture shows different VLANs carrying SIP signaling and RTP/RTCP traffic at the network and the user side (VLAN) of the VRF. Both internal VLANs perform L4 forwarding in downstream direction.
12-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
At the IHub:
• IHub 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. • IHub 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. • IHub VRF network side: A numbered IP interface is configured on top of the network voice VLAN. • IHub 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 IHub must perform the further L3 forwarding to the appropriate internal VLAN 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. Figure 12-19 shows the SIP ISAM Voice (distributed architecture) switched model. Figure 12-19 SIP ISAM Voice (distributed architecture): switched model Main ISAM Voice Network v-VPLS 1 /VLAN 1
Fast path VRF IP address voice IP address signalling
Voice v-VPLS
Network v-VPLS 2 /VLAN 2
Signaling v-VPLS
Voice LT NT
• The network signaling VLAN terminates at the voice LT board • The network RTP/RTCP VLAN terminates at the voice LT board • The source/destination IP address for SIP signaling traffic is configured at the voice LT board. Each voice LT board owns a different signaling IP address.
• The source/destination IP address for RTP/RTCP traffic is configured at the voice LT board. Each voice LT board owns a different RTP/RTCP IP address.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-19
12 — ISAM Voice Network Architecture
• The IHub performs L2 forwarding for SIP signaling/RTP/RTCP traffic destined to the voice LT board
• The IHub performs L2 forwarding for upstream SIP signaling/RTP/RTCP traffic. Figure 12-20 shows the SIP ISAM Voice (distributed architecture) routed model. Figure 12-20 SIP ISAM Voice (distributed architecture): routed model Main ISAM Voice Fast path VRF IP address Voice
IP address signaling
Internal Voice v-VPLS
IP address user 1 IP address user 2
Internal signaling v-VPLS
IP address network 1 IP address network 2
Network v-VPLS 1 /VLAN 1
Network v-VPLS 2 /VLAN 2
Voice LT NT
The conceptual architecture shows different VLANs carrying SIP signaling and RTP/RTCP traffic at the network and the user side (VLAN) of the VRF. At the IHub:
• VRF user side: A numbered IP interface is configured on top of the internal voice VLAN. Note — The IP address configured at the voice LT board 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.
• VRF user side: A numbered IP interface is configured on top of the internal signaling VLAN. Note — The IP address configured at the voice LT board 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.
• VRF network side: A numbered IP interface is configured on top of the network voice VLAN.
• VRF network side: A numbered IP interface is configured on top of the network signaling VLAN. The IHub 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 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 voice service related traffic (SIP signaling, RTP and RTCP). 12-20
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
In downstream direction, voice service related traffic (SIP signaling, RTP and RTCP) may be received at any network interface/VLAN. The IHub must perform the further L3 forwarding to the appropriate internal VLAN and to the destined voice LT board. From a downstream forwarding perspective, seen from the edge router, the ISAM Voice access node is configured as the next-hop. Figure 12-21 shows the MEGACO/SIP ISAM voice subtended topology for the switched model. Figure 12-21 MEGACO/SIP ISAM Voice - Subtended topology: Switched mode Main ISAM Voice Fast path VRF
NT
Subtending ISAM Fast path VRF
NT
Figure 12-22 shows the MEGACO/SIP ISAM voice subtended topology for the routed model.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-21
12 — ISAM Voice Network Architecture Figure 12-22 Megaco/SIP ISAM Voice - Subtended topology: Routed mode Main ISAM Voice Fast path VRF IP address User 1 IP address User 2
NT
IP address sub 1
IP address network 1 IP address network 2
IP address sub 2
Main ISAM Voice Fast path VRF
NT
The subtending ISAM Voice access node remains configured as a switching device. Only the main ISAM Voice access node fulfills the routing service. The conceptual traffic forwarding models depicted above for the IHub based system without Remote Expansion Module also apply to the IHub based system with Remote Expansion Module. (The physical position of the voice LT board, locally connected in the host access node or remotely connected by means of a REM, is transparent to the operational behavior of the VoIP service)
• Megaco ISAM Voice Service: • Remote Expansion Module may host 1 or 2 voice LT boards: Voice LT board can be planned for both the “master” (72-line LT board only) and the “non-Master” (48-line and 72-line LT board) slot position. Remote Expansion Module cannot host the Voice Server.
• • SIP ISAM Voice Service: • Remote Expansion Module may host 1 or 2 voice LT boards: Voice LT board can be planned for both the “master” (72-line LT board only) and the “non-Master” (48-line and 72-line LT board) slot position. Layer 4 forwarding
The layer 4 forwarding applies to downstream traffic only and is installed at the IHub 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 board.
12-22
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
The layer 4 forwarding property is installed in case the following conditions are fulfilled: 1
The number of VLAN to be created depends on the operating mode of the IHub NT:
• IHub NT as switching device: A single VLAN is created including the ASAM ports and the Network ports.
• IHub NT as routing device: One user VLAN and one or multiple network VLAN are created. The user VLAN includes the ASAM ports. The network VLAN includes the network ports.
2
A VPRN service, identified by the VFR ID, is created (for both cases, the IHub NT behaving as switching device and the IHub NT behaving as routing device).
3
An IP interface and an IP address are created as part of the VPRN service.
4
The IP interface is bound to the (user) VLAN.
5
The VLAN has at least one Voice LT board connected.
The layer 4 forwarding capability is installed on a per-port basis. Planning or unplanning a voice LT board results in adding/removing the layer 4 forwarding capability to/from the VLAN for the corresponding ASAM port. Each voice LT board gets assigned a fixed transport protocol port range. The IHub port that connects the voice LT board inherits this port range mapping. The transport protocol port range for free usage (IANA), that is, 49153 - 65535, is divided in 32 equal portions and the lower part of each portion is mapped to the different IHub ports. The mapping of the transport protocol portions to the IHub ports is fixed and the same in every ISAM Voice access node. Upon the receipt of a downstream packet within a layer 4 forwarding capable VLAN and with the destination IP address bound to 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 IHub port mapping is looked up and the packet is forwarded to the voice LT board that connects to this IHub port. As described, the layer 4 forwarding uses the combination {VRF-ID + destination IP address + destination Transport Protocol port} to decide about the further downstream forwarding of an IP packet. Layer 4 forwarding is applied to both 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. The described algorithm is schematically shown in Figure 12-23.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-23
12 — ISAM Voice Network Architecture Figure 12-23 Layer 4 forwarding approach IHub
Match (VRF ID + own IP address)?
Ingress
(Transport Prot port range1, port a1 ) (Transport Prot port range2, port a2 ) … (Transport Prot port rangeN, port an )
Y
N
Layer 4 forwarding
Egress
Layer 3 IP table Layer 2 VLAN/MAC table
Layer 2/layer 3 forwarding
User-to-user communication
The integrated voice service requires that user-to-user communication is enabled for RTP and XLES traffic (Megaco based integrated voice service only). There are no specific VLAN types defined neither for the voice, nor for the non-voice services. The system autonomously decides whether a VLAN is intended to be used by the voice service by checking the board type associated with the ASAM port(s) being a member of the VLAN. As such, a voice service IP address is each IP address which is configured on top of a VLAN (/= OAM) which has at least one voice LT board type as port member. The configuration of an IP interface on top of a VLAN (at the IHub side) which has at least one voice LT board as port member, autonomously enables the L4 forwarding behaviour in downstream direction at the ASAM port(s). User-to-user needs to be explicitly enabled. 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, performs ARP the next hop IP address and forwards the IP packet appropriately. The local IHub and any potential intermediate IHub perform layer 2 forwarding. In the downstream direction: The local IHub and any potential intermediate IHub perform layer 2 forwarding.
12-24
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-24 Megaco ISAM Voice - Switched: Signaling forwarding L4 forwarding L3 forwarding
Remote node NT board
Main node NT board
L2 forwarding
Signaling IP address Voice
server XLES IP address Voice LT board
IHub Voice IP address
IHub Voice IP address
L2 aggregation network
Voice LT board
L4 forwarding
Remote node
Subtending node
NT board
Voice LT board
NT board
L3 aggregation network
IHub Voice IP address
IHub Voice IP address
Voice LT board
L4 forwarding
ASP
MGC
SoftSwitch
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 12-25): 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 (IHub) IP address of the packet can directly be reached in the local subnet: the Voice server performs ARP for the destination (IHub) IP address and forwards the IP packet to this (IHub) 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 (IHub) IP address of the packet, performs ARP for the next hop IP address and forwards the IP packet appropriately. The (destined) IHub that connects the destined Voice LT performs layer 4 forwarding. Any potential intermediate IHub in between the Voice Server and the destined IHub performs layer 2 forwarding.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-25
12 — ISAM Voice Network Architecture
• XLES traffic originating at the Voice LT board and destined to the Voice server (see Figure 12-26): The Voice LT board forwards the XLES packet to the local IHub.
• The access node of the Voice LT board and the access node of the Voice server are the same or
• The access node of the Voice LT board subtends to the access node of the Voice server or
• The access node of the Voice LT board is connected via a layer 2 aggregation network with the access node of the Voice server
The local IHub detects that the destination IP address of the packet can directly be reached via the local subnet. The local IHub 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 IHub 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 IHub that connects the Voice server performs layer 2 forwarding. Any potential intermediate IHub in between the Voice LT's local IHub and the Voice Server L2 forwarding. Figure 12-25 Megaco ISAM Voice - Switched: XLES packet originating at the Voice server L4 forwarding L3 forwarding
Remote node NT board
Main node NT board
L2 forwarding
Signaling IP address Voice
server XLES IP address Voice LT board
IHub Voice IP address
IHub Voice IP address
L2 aggregation network
Voice LT board
L4 forwarding
Remote node
Subtending node
NT board
Voice LT board
NT board
L3 aggregation network
IHub Voice IP address
IHub Voice IP address
Voice LT board
L4 forwarding
ASP
MGC
SoftSwitch
12-26
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-26 Megaco ISAM Voice - Switched: XLES packet originating at the Voice LT board L3 forwarding
Main node
Remote node NT board
NT board
L2 forwarding
Signaling IP address Voice
server XLES IP address Voice LT board
IHub Voice IP address
IHub Voice IP address
L2 aggregation network
Voice LT board
L3 forwarding
Remote node
Subtending node
NT board
Voice LT board
NT board
L3 aggregation network
IHub Voice IP address
IHub Voice IP address
Voice LT board
L3 forwarding
ASP
MGC
SoftSwitch
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 (to support some supplementary services or an optimized IP addressing scheme). Voice traffic is relayed to the IHub 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). A. Voice traffic not passing the Voice server:
• Voice traffic destined to an external termination point: • The voice LT board forwards the voice traffic to the local IHub. • The local IHub determines the IP next hop for the voice traffic destination IP address.
• The local IHub performs ARP for the next hop IP address and forwards the IP packet appropriately.
• Any potential intermediate IHub between the local IHub and the next hop performs layer 2 forwarding.
• Voice traffic destined to a voice termination point at the same Voice LT board in the local access node:
• The voice LT board forwards the upstream voice traffic to the local IHub. • The local IHub detects that the destination IP address of the voice traffic is identical to the own Voice IP address and treats the voice traffic locally.
• The local IHub performs layer 4 forwarding to the Voice LT board from which the voice traffic originated.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-27
12 — ISAM Voice Network Architecture
• Voice traffic destined to a voice termination point residing at a different Voice LT board in the local access node:
• The voice LT board forwards the upstream voice traffic to the local IHub. • The local IHub detects that the destination IP address of the voice traffic is identical •
to the own Voice IP address and treats the voice traffic locally. The local IHub 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 traffic to the local IHub. • One of the following takes place: 1. The destined Voice termination point is reachable via a layer 3 aggregation network: The local IHub determines the IP next hop for the destination IP address of the voice traffic. The local IHub performs ARP the next hop IP address and forwards the voice traffic appropriately.
• •
2. The destined Voice termination point reachable via a layer 2 aggregation network: The local IHub detects that the destination of the voice traffic is reachable via the local subnet. The local IHub performs ARP the destination IP address and forwards the voice traffic appropriately. Any potential intermediate IHub between the local IHub and the destined IHub performs layer 2 forwarding. The IHub that connects the destined voice termination point (Voice LT board) performs layer 4 forwarding.
B. Voice traffic passing the Voice server:
• Voice traffic destined to the Voice server: • The voice LT forwards the upstream voice packet to the local IHub. • If the destined Voice Server is reachable via layer 3 aggregation network: •
• •
12-28
The local IHub determines the IP next hop for the Voice server, performs ARP for the next-hop IP address and forwards the voice traffic appropriately. If 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 IHub detects that the Voice server is reachable within the local subnet. The local IHub performs ARP for the IP address of the Voice server and forwards the IP packet appropriately The IHub that connects the Voice server performs layer 2 forwarding. Any potential intermediate IHub between the local IHub and the IHub that connects the Voice server performs layer 2 forwarding.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
• 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 • •
IHub 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 IHub. The local IHub 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 IHub 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 IHub that connects the Voice termination point (Voice LT board) performs layer 4 forwarding. Any potential intermediate IHub between the Voice server and the IHub connecting the destined voice termination performs layer 2 forwarding.
• Voice traffic relayed by the Voice server to a voice termination point outside 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. Any potential intermediate IHub in between the Voice server and the next hop performs layer 2 forwarding.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-29
12 — ISAM Voice Network Architecture Figure 12-27 Megaco ISAM Voice - Switched: Voice packet originating at the Voice LT board L4 forwarding
Main node
Remote node NT board
Signaling IP address Voice
NT board
L2 forwarding
server XLES IP address Voice LT board
IHub Voice IP address
IHub Voice IP address
L2 aggregation network
Voice LT board
L3 forwarding
Remote node
Subtending node
NT board
Voice LT board
NT board
L3 aggregation network
IHub Voice IP address
IHub Voice IP address
Voice LT board
L3 forwarding
L4 forwarding
ASP
MGC
SoftSwitch
Figure 12-28 Megaco ISAM Voice - Switched: Voice packet originating at the Voice server L4 forwarding L3 forwarding
Remote node NT board
Main node NT board
L2 forwarding
Signaling IP address Voice
server XLES IP address Voice LT board
IHub Voice IP address
IHub Voice IP address
L2 aggregation network
L2 forwarding
Remote node
Subtending node
NT board
Voice LT board
Voice LT board
L2 forwarding
NT board
L3 aggregation network
IHub Voice IP address
IHub Voice IP address
Voice LT board
L3 forwarding
ASP
MGC
SoftSwitch
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.
12-30
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
Any potential intermediate IHub performs layer 2 forwarding and this in both directions. Refer also to chapter “Management”. Megaco ISAM Voice as routing device
The 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. 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 IHUB has the capability of defining different VRFs for narrowband and Broadband traffic. As a result, for access nodes that are deployed in mixed mode (that is, meaning that narrowband and broadband services are concurrently deployed by the same access node) shall assign different VRFs to narrowband and broadband services to guarantee that data is kept secret against unwanted, unintended and malicious listeners. 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 IHub is configured as the next hop for signaling packets originating at the Voice server. The local IHub performs layer 3 forwarding in upstream and downstream direction.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-31
12 — ISAM Voice Network Architecture Figure 12-29 Megaco ISAM Voice - Routed: signaling forwarding L3 forwarding
Remote node
Main node NT board
L3 forwarding
NT board
Voice LT board
Signaling IP address Voice
IHub signaling user IP address
IHub network IP address IHub network IP address
IHub Voice user IP address
server XLES IP address Voice LT board
L3 aggregation network
IHub Voice user IP address
Remote node
Subtending node
NT board
NT board
IHub network IP address
Voice LT board
IHub Voice IP address
IHub Voice user IP address
Voice LT board
Signaling
ASP
MGC
SoftSwitch
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 board is connected:
• to the local access node, or • 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 IHub 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 IHub IP address is equal to the destination IP address). The (destined) IHub that connects the destined Voice LT board performs layer 3 followed by layer 4 forwarding.
12-32
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
• 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 IHub. The access node of the Voice LT board and the access node of the Voice Server are the same: the local IHub detects that the destination IP address of the packet can directly be reached via the local subnet. The local IHub 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 IHub 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: The local IHub 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 IHub that connects the Voice server performs layer 3 forwarding. Figure 12-30 Megaco ISAM Voice - Routed: XLES packet originating at the Voice Server L4 forwarding L3 forwarding
Remote node NT board IHub network IP address
Voice LT board
Main node NT board
L3 forwarding
IHub network IP address
IHub Voice user IP address
Signaling IP address Voice
IHub signaling user IP address
L3 forwarding
server XLES IP address Voice LT board
L3 aggregation network
IHub Voice user IP address
Remote node
L4 forwarding
Subtending node
NT board
NT board
IHub network IP address
Voice LT board
IHub Voice IP address
IHub Voice user IP address
Voice LT board
L4 forwarding L3 forwarding ASP
MGC
SoftSwitch
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-33
12 — ISAM Voice Network Architecture Figure 12-31 Megaco ISAM Voice - Routed: XLES packet forwarding at the Voice LT board. L3 forwarding L3 forwarding
Remote node
Main node NT board
L3 forwarding
NT board IHub network IP address
Voice LT board
Signaling IP address Voice
IHub signaling user IP address IHub network IP address
IHub Voice user IP address
server XLES IP address Voice LT board
L3 aggregation network
IHub Voice user IP address
Remote node
Subtending node
NT board
NT board
IHub network IP address
Voice LT board
IHub Voice IP address
IHub Voice user IP address
Voice LT board
L3 forwarding
ASP
MGC
SoftSwitch
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. In some cases the voice traffic must be sent along the Voice server (to support some supplementary services or an optimized IP addressing scheme). In all cases, voice traffic is relayed to the IHub 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 IHub. • The local IHub determines the IP next hop for the voice traffic destination. • The local IHub 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 IHub. • The local IHub detects that the destination of the voice traffic equals the local Voice •
12-34
IP address and treats the voice traffic locally. The local IHub performs layer 4 forwarding to the Voice LT board from which the voice traffic originated.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
• 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 IHub. • The local IHub detects that the destination of the voice traffic equals the local Voice •
IP address and treats the voice traffic locally. The local IHub 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 IHub. • The local IHub determines the IP next hop for the destination of the voice traffic. •
The local IHub performs ARP for the next hop IP address and forwards the voice traffic appropriately. The IHub 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 IHub. • The local IHub 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 IHub 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 IHub 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 IHub 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 IHub 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 IHub that connects the Voice termination (Voice LT board) performs layer 4 forwarding.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-35
12 — ISAM Voice Network Architecture
• 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 12-32 Megaco ISAM Voice - Routed: Voice packet originating at the LT board L4 forwarding L3 forwarding
Remote node
Main node NT board
L3 forwarding
NT board IHub network IP address
Voice LT board
Signaling IP address Voice
IHub signaling user IP address IHub network IP address
IHub Voice user IP address
L3 aggregation network
server XLES IP address Voice LT board IHub Voice user IP address
IHub subtended IP address
Remote node
L3 forwarding
Subtending node
NT board
NT board
IHub network IP address
Voice LT board
L4 forwarding
IHub Voice IP address
IHub Voice user IP address
L3 forwarding
Voice LT board
L3 forwarding
ASP
MGC
SoftSwitch
Figure 12-33 Megaco ISAM Voice - Routed: Voice packet originating at the Voice server L4 forwarding
Main node
Remote node NT board IHub network IP address
Voice LT board
NT board
L3 forwarding
IHub network IP address
IHub Voice user IP address
Signaling IP address Voice
IHub signaling user IP address
L3 forwarding
L3 aggregation network
Voice LT board IHub Voice user IP address
IHub subtended IP address
Remote node
server XLES IP address
L3 forwarding
Subtending node
NT board
NT board
IHub network IP address
Voice LT board
IHub Voice IP address
IHub Voice user IP address
Voice LT board
L3 forwarding
ASP
MGC
SoftSwitch
OAM traffic
12-36
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
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 eight) 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. Refer also to chapter “Management”. SIP ISAM Voice as switching device
Signaling traffic Signaling traffic originates at the Voice LT board.
• Centralized SIP architecture = single IP address: • In upstream direction: the Voice LT board forwards the signaling packet to the local
•
IHub. The Local IHub 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 IHub performs layer 3 forwarding followed by layer 4 forwarding to the destined Voice LT board.
Figure 12-34 SIP ISAM Voice - Switched - Centralized: Signaling packet originating at the Voice LT/Upstream layer 3 forwarding at the IHub L3 forwarding
Remote node NT board
Main node NT board
L2 forwarding
IHub Voice IP address
IHub Voice IP address
Voice LT board
IHub signaling IP address
IHub signaling IP address
L2 aggregation network
Remote node
Subtending node
NT board
NT board
L3 aggregation network
IHub Voice IP address
Voice LT board
Voice LT board
IHub Voice IP address
IHub signaling IP address
IHub signaling IP address
Voice LT board
L3 forwarding
S-CSCF I-CSCF AS
IP HSS MRF
IMS Core
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-37
12 — ISAM Voice Network Architecture Figure 12-35 SIP ISAM Voice - Switched - Centralized: Signaling packet destined to the Voice LT/Downstream layer 4 forwarding at the IHub Main node
L4 forwarding
Remote node NT board
NT board
L2 forwarding
IHub Voice IP address
IHub Voice IP address
Voice LT board
IHub signaling IP address
IHub signaling IP address
L2 aggregation network
Remote node
Subtending node
NT board
NT board
L3 aggregation network
IHub Voice IP address
Voice LT board
Voice LT board
IHub Voice IP address
IHub signaling IP address
IHub signaling IP address
Voice LT board L4 forwarding
S-CSCF I-CSCF AS
IP HSS
IMS Core
MRF
• Distributed SIP architecture = Multiple IP address: • In the 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 IHub performs layer 2 forwarding. In the downstream direction: upon the receipt of a signaling packet, the local IHub performs layer 2 forwarding to the destined Voice LT board.
Figure 12-36 SIP ISAM Voice - Switched - Distributed: Signaling packet originating at the Voice LT/Upstream layer 3 forwarding at the Voice LT L3 forwarding
Remote node Voice LT board
NT board
Main node NT board
L2 forwarding
Signaling IP address
Voice LT board Signaling IP address
Voice IP address
Voice IP address
L2 aggregation network
Remote node Voice LT board
Subtending node
NT board
NT board
L3 aggregation network
Signaling IP address
Voice LT board Signaling IP address
Voice IP address
Voice IP address
L3 forwarding
S-CSCF I-CSCF AS
L2 forwarding
IP HSS MRF
12-38
November 2013
IMS Core
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-37 SIP ISAM Voice - Switched - Distributed: Signaling packet destined to the Voice LT/Downstream layer 2 forwarding at the IHub Main node
Main node Voice LT board
NT board
Signaling IP address
Signaling IP address Voice IP address
Voice IP address
L2 aggregation network
Main node Voice LT board
Voice LT board
NT board
L2 forwarding
Subtending node
NT board
L3 aggregation network
Signaling IP address
Voice LT board
NT board
Signaling IP address
Voice IP address
Voice IP address
L2 forwarding
S-CSCF I-CSCF AS
IP HSS MRF
IMS Core
Voice traffic Voice traffic originates at the Voice LT board. 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 terminations connected to the same voice LT board: The forwarding behavior depends on the destination IP address 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 IHub depending on the Voice LT board type being planned. • Voice traffic exchanged between two voice terminations connected to different voice LT boards in the same access node: The forwarding behavior depends on the destination IP address 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 IHub is only possible in the centralized SIP architecture, not in the distributed SIP architecture.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-39
12 — ISAM Voice Network Architecture
Centralized SIP architecture:
• The voice LT board forwards the voice packet to the local IHub. • The local IHub detects that the destination IP address of the packet is identical to the own Voice IP address and treats the packet locally.
• The local IHub 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. 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 IHub performs layer 2 forwarding and this in both directions. Refer also to chapter “Management”. SIP ISAM Voice as routing device
Security considerations The IHub can define different VRFs for narrowband and broadband traffic. As a result, for access nodes that are deployed in mixed mode, meaning that narrowband and broadband services are concurrently deployed by the same access node, different VRFs must be assigned to narrowband services and to broadband services to guarantee that data is kept secret against unwanted, unintended and malicious listeners. Signaling traffic Signaling traffic originates at the Voice LT board.
• Centralized SIP architecture = single IP address: • In upstream direction: the Voice LT board forwards the signaling packet to the local
•
12-40
IHub. The Local IHub 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 IHub performs layer 3 forwarding followed by layer 4 forwarding to the destined Voice LT board.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-38 SIP ISAM Voice - Routed - Centralized: Signaling packet originating at the Voice LT/Upstream layer 3 forwarding at the IHub L3 forwarding
Remote node
Main node
L3 forwarding IHub user Signaling IP address
Voice LT board
NT board
IHub user Voice IP address
IHub netw. Signaling IP address
IHub netw. Signaling IP address
NT board
IHub user Signaling IP address
IHub netw. Voice IP address
IHub netw. Voice IP address
L3 aggregation network
IHub subtending IP address
Remote node
IHub user Voice IP address
Voice LT board
Subtending node
NT board IHub user Signaling IP address
NT board
IHub netw. Signaling IP address
IHub dignaling IP address
Voice LT board
Voice LT board
IHub Voice IP address
IHub netw. Voice IP address
IHub user Voice IP address
L3 forwarding
S-CSCF I-CSCF AS
IP HSS
IMS Core
MRF
Figure 12-39 SIP ISAM Voice - Routed - Centralized: Signaling packet destined to the Voice LT/Downstream layer 4 forwarding at the IHub L3 forwarding
Remote node
Main node
L3 forwarding IHub user Signaling IP address
Voice LT board
NT board
IHub user Voice IP address
IHub netw. Signaling IP address
IHub netw. Signaling IP address
L3 aggregation network
IHub subtending IP address
Remote node
IHub user Signaling IP address
Voice LT board IHub user Voice IP address
IHub user Signaling IP address
IHub netw. Voice IP address
IHub netw. Voice IP address
NT board
NT board
IHub user Voice IP address
Voice LT board
Subtending node NT board
IHub netw. Signaling IP address
IHub dignaling IP address IHub Voice IP address
IHub netw. Voice IP address
Voice LT board
L4 forwarding
S-CSCF I-CSCF AS
IP HSS MRF
IMS Core
• Distributed SIP architecture = Multiple IP address: • In the 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.
• In the downstream direction: upon the receipt of a signaling packet, the local IHub performs layer 3 forwarding to the destined Voice LT board.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-41
12 — ISAM Voice Network Architecture Figure 12-40 SIP ISAM Voice - Routed - Distributed: Signaling packet originating at the Voice LT/Upstream layer 3 forwarding at the Voice LT L3 forwarding
Main node
Main node
L3 forwarding
Voice LT board
NT board
Signaling IP address
IHub netw. Signaling IP address
IHub netw. Signaling IP address
IHub user Signaling IP address
Voice IP address
IHub user Voice IP address
NT board
Signaling IP address
Signaling IP address
IHub netw. Voice IP address
IHub netw. Voice IP address
L3 aggregation network
Voice IP address
IHub user Voice IP address
IHub subtending IP address
Mainnode Voice LT board
Voice LT board
IHub user Signaling IP address
Subtending node
NT board IHub user Signaling IP address
Voice IP address
Voice LT board
NT board
IHub netw. Signaling IP address
Signaling IP address
Voice IP address
IHub netw. Voice IP address
IHub user Voice IP address
L3 forwarding
S-CSCF I-CSCF
L2 forwarding
AS
IP HSS
IMS Core
MRF
Figure 12-41 SIP ISAM Voice - Routed - Distributed: Signaling packet destined to the Voice LT/Downstream layer 2 forwarding at the IHub L3 forwarding
Main node
Main node
L3 forwarding
Voice LT board Signaling IP address
Voice IP address
NT board
IHub netw. Signaling IP address
IHub netw. Signaling IP address
IHub user Signaling IP address IHub user Voice IP address
IHub netw. Voice IP address
Signaling IP address
NT board IHub user Signaling IP address
Voice IP address IHub user Voice IP address
IHub user Signaling IP address
IHub netw. Voice IP address
L3 aggregation network
IHub subtending IP address
Main node Voice LT board
NT board
IHub user Voice IP address
Voice LT board Signaling IP address
Voice IP address
Subtending node NT board
IHub netw. Signaling IP address
Voice LT board Signaling IP address
Voice IP address
IHub netw. Voice IP address
S-CSCF
L2 forwarding
I-CSCF AS
IP HSS MRF
IMS Core
Voice traffic Voice traffic originates at the Voice LT board.
12-42
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
For both the centralized 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 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 IHub depending on the Voice LT board type being planned. • Voice traffic exchanged between two voice terminations connected to different voice LT boards in the same access node: The forwarding behavior depends on the destination IP address received from the IMS core, for example, all the voice traffic might be forced to be forwarded along a voice gateway. Switching voice traffic between Voice Terminations, connected to the same Voice LT board along the local IHub is only possible in the Centralized SIP architecture, not in the Distributed SIP architecture. Centralized SIP architecture:
• The Voice LT board forwards the voice packet to the local IHub. • The local IHub detects that the destination IP address of the packet is identical to the own Voice IP address and treats the packet locally.
• The local IHub 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. 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. Refer also to chapter “Management”.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-43
12 — ISAM Voice Network Architecture
12.6
Layer 2/layer 3 addressing topologies Megaco ISAM Voice as switching device Three addressing topologies are supported for Megaco ISAM Voice:
• Basic layer 2/layer 3 addressing topology • IP subnet reduction topology • IP subnet and IP address reduction topology The following is common to all three topologies:
• • • • • • •
Equipment and platform management entity is hosted at the NT Integrated 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” Public OAM IP address: see chapter “Management”
Basic layer 2/layer 3 addressing topology
The following applies for the basic layer 2/layer 3 addressing topology:
• • • • •
A distinct VLAN is configured for signaling and Voice/XLES traffic. The public Voice IP interface is configured at the IHub. 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 and XLES traffic originating at the Voice server: layer 3 forwarding at the Voice server and layer 2 forwarding at the IHub.
• Voice/XLES traffic originating at the Voice LT board: Voice/XLES packet internally relayed from the Voice LT to the IHub and layer 3 forwarding at the IHub.
• Downstream packet forwarding: • Signaling traffic and XLES traffic destined to the Voice server is layer 2 forwarded •
at the IHub. Voice/XLES traffic destined to the voice LT is layer 4 forwarded from the IHub to the Voice LT.
• Signaling VLAN: Configurable. Ports associated with this VLAN are the ASAM 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).
12-44
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
• Voice/XLES VLAN: Configurable. Ports associated with this VLAN are the ASAM port(s) connecting the Voice server, the ASAM 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 12-42 • For a subtending ISAM Voice, see Figure 12-43 • For a remote ISAM Voice, see Figure 12-44 Figure 12-42 Switching - Basic layer 2/layer 3 addressing topology - HUB ISAM Voice MG In te r n a l O AM VLAN Vo ice Se r ve r 1
Exte r n a l O AM VLAN
MG IACM Vo ice Se r ve r N
SIG N ALIN G VLAN
Vo ice LT 1
IHub NT
VO ICE VLAN Public O AM IP Address Public Signa ling IP Address Public Voice / XLES IP Address Priva te O AM IP Address Public Voice IP Address
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
Vo ice LT M
November 2013
12-45
12 — ISAM Voice Network Architecture Figure 12-43 Switching - Basic layer 2/layer 3 addressing topology - Subtending ISAM Voice
Exte r n a l O AM VLAN
IACM
Vo ice LT 1
IHub NT
VO ICE VLAN
Public O AM IP Address Vo ice LT M
Public Voice IP Address
Figure 12-44 Switching - Basic layer 2/layer 3 addressing topology - Remote ISAM Voice
Exte r n a l O AM VLAN
IACM
Vo ice LT 1
IHub NT
VO ICE VLAN
Public O AM IP Address Public Voice IP Address
Vo ice LT M
Relying on the former layer 2 forwarding scheme, the layer 3 IP address scheme looks 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 IHub. • Configurable • Public XLES IP address: • Residing at the Voice server. • Shared by a redundant pair of Voice servers. • Configurable.
12-46
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
IP subnet reduction topology
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 single, shared VLAN is configured for signaling and Voice/XLES traffic. The public Voice IP interface is configured at the IHub. A single, shared signaling/XLES IP interface is configured at the Voice server. Upstream packet forwarding:
• Signaling traffic and XLES traffic originating at the Voice server: layer 3 forwarding at the Voice server and layer 2 forwarding at the IHub.
• Voice/XLES traffic originating at the Voice LT: Voice/XLES packet internally relayed from Voice LT to IHub and layer 3 forwarding at the IHub.
• Downstream packet forwarding: • Signaling traffic and XLES traffic destined to the Voice server is layer 2 forwarded •
at the IHub. Voice/XLES traffic destined to the Voice LT is layer 4 forwarded from the IHub to the Voice LT.
• Shared signaling/Voice/XLES VLAN: Configurable. Ports associated with this VLAN are the ASAM port(s) connecting the Voice server, the ASAM 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 12-45. • For a subtending ISAM Voice, see Figure 12-46. • For a remote ISAM Voice, see Figure 12-47.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-47
12 — ISAM Voice Network Architecture Figure 12-45 Switching - IP subnet reduction topology - HUB ISAM Voice MG In te r n a l O AM VLAN Vo ice Se r ve r 1
Exte r n a l O AM VLAN
MG IACM Vo ice Se r ve r N
Shared SIG N ALIN G/VOICE VLAN
Vo ice LT 1
IHub NT
Public O AM IP Address Public Voice IP Address Public shared Signaling/Voice/XLES IP Address Priva te O AM IP Address
Vo ice LT M
Figure 12-46 Switching - IP subnet reduction topology - Subtending ISAM Voice Exte r n a l O AM VLAN
IACM
Shared SIG N ALIN G/VOICE VLAN
Vo ice LT 1
IHub NT
Public OAM IP Address Public Voice IP Address Vo ice LT M
Figure 12-47 Switching - IP subnet reduction topology - Remote ISAM Voice
Ext e r n a l O AM VLAN
IACM
Shared SIG N ALIN G/VOICE VLAN
Vo ice LT 1
IHub NT
Pub lic OAM IP Ad d re ss Pub lic Vo ice IP Ad d re ss Vo ice LT M
Relying on the former layer 2 forwarding scheme, the layer 3 IP address scheme 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.
12-48
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
• Public Voice IP address: • Single IP address per ISAM Voice access node. • Residing at the IHub. • Configurable. IP subnet and IP address reduction
This model further reduces the total amount of public IP addresses, required for the integrated voice service. 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 IHub 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 IHub of the remote ISAM Voice access node.
• A single, shared public VLAN is used for (case A) signaling/Voice/XLES or • • • • •
(case B) signaling/Voice traffic. A single, 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 IHub. 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 originating at the Voice server: layer 3 forwarding at the Voice server and layer 2 forwarding at the IHub.
• Voice/XLES traffic originating at the Voice server: layer 3 forwarding at the Voice server and layer 2 forwarding at the IHub.
• Voice/XLES traffic originating at the remote ISAM Voice (Figure 12-50 - CASE A): Voice/XLES packet internally relayed from the Voice LT to the IHub and layer 3 forwarding at the IHub.
• Downstream packet forwarding in shared VLAN for signaling and Voice/XLES traffic:
• Signaling traffic destined to the Voice server: layer 2 forwarding at the IHub. • Voice/XLES traffic destined to the Voice server: layer 2 forwarding at the IHub. • Voice/XLES destined to the Voice LT in Remote ISAM-V (Figure 12-50 - CASE A): layer 4 forwarding from the IHub 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 IHub and layer 3 forwarding at the IHub.
• Downstream packet forwarding in the private Voice VLAN: • Voice/XLES traffic: layer 4 forwarding from the xHub to the Voice LT.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-49
12 — ISAM Voice Network Architecture
• Case A: Shared public signaling/Voice/XLES VLAN: 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: 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:
• Megaco and SIGTRAN signaling traffic exchanged between the MGC (Call Server)/ ASP (Application Server Process) and the MG (ISAM Voice).
• 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: Configurable. Ports associated with this VLAN are the ASAM port(s) connecting the Voice server, the ASAM 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 IHub 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 and/ or remote 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:
• For a hub ISAM Voice, see Figure 12-48. • For a subtending ISAM Voice, see Figure 12-49. • For a remote ISAM Voice, see Figure 12-50. 12-50
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-48 Switching - IP subnet and IP address reduction topology - HUB ISAM Voice MG In te r n a l O AM VLAN Vo ice Se r ve r 1
Exte r n a l O AM VLAN
MG IACM Vo ice Se r ve r N
Private VOICE/XLES VLAN
Vo ice LT 1
IHub NT
Shared SIGNALING/VO ICE VLAN Public O AM IP Address Private Voice IP Address Public shared Signaling/Voice / XLES IP Address Priva te O AM IP Address Private XLES IP Address
Vo ice LT M
Figure 12-49 Switching - IP subnet an IP address reduction topology - Subtending ISAM Voice Vo ice LT M Public O AM IP Address Private Voice IP Address NT IHub
Vo ice LT 1
Private VOICE/XLES VLAN IACM
Exte r n a l O AM VLAN
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-51
12 — ISAM Voice Network Architecture Figure 12-50 Switching - IP subnet and IP address reduction topology - Remote ISAM Voice CASE A
Exte r n a l O AM VLAN
IACM Vo ice server N
Shared SIGNALLING/VO ICE VLAN
Vo ice LT 1
IHub NT
Public OAM IP Address Public Voice IP Address Vo ice LT M
CASE B Exte r n a l O AM VLAN
IACM Vo ice server N
Shared SIGNALLING/VO ICE VLAN
Vo ice LT 1
IHub NT
Public OAM IP Address Public Voice IP Address Vo ice LT M
Relying on the former layer 2 forwarding scheme, the layer 3 IP address scheme looks as follows:
• 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 IHub. • 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 IHub. • Configurable. • Private XLES IP address (for hub ISAM Voice node): • Residing at the Voice server. • Shared by a redundant pair of Voice servers. • Configurable.
12-52
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
Megaco ISAM Voice as routing device Three addressing topologies are supported for Megaco ISAM Voice as routing device:
• Basic layer 3 addressing topology • IP subnet reduction topology • IP subnet and IP address reduction topology The following is common to all three topologies:
• • • •
Equipment and platform management entity is hosted at the NT Integrated 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 (see chapter “Management”) • Public OAM IP interface is configured at the NT (see chapter “Management”) 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 IHub. 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 fast 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 IHub.
• 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 IHub and layer 3 forwarding at the IHub. Voice traffic and XLES traffic originating at the subtending interface: layer 3 forwarding at the IHub.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-53
12 — ISAM Voice Network Architecture
• Downstream packet forwarding: • Signaling traffic and XLES traffic destined to the Voice server: layer 3 forwarded at the IHub.
• Voice traffic and XLES traffic destined to the Voice LT: layer 3 followed by layer 4 forwarded from the IHub to the Voice LT board.
• Voice traffic and XLES traffic destined to the subtending interface: layer 3 forwarded at the IHub.
• Signaling VLAN at the user side of the fast path VRF: Configurable. Ports associated with this VLAN are the ASAM port(s) connecting the Voice server(s). The signaling VLAN terminates at the IHub/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: Configurable. 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 IHub 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: Configurable. Ports associated with this VLAN are the subtending port(s). The VLAN terminates at the IHub 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 12-51 • For a subtending ISAM Voice, see Figure 12-52 • For a remote ISAM Voice, see Figure 12-53
12-54
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-51 Routing - Basic layer 3 addressing topology - HUB ISAM Voice MG Internal OAM VLAN Voice Server 1
External OAM VLAN
MG
SIGNALING VLAN Network VLAN
Voice Server N
Fast-path VRF
Voice LT 1
Network VLAN NT
Subtending VLAN Public OAM IP address Public Signaling IP address Public Voice /XLES IP address Private OAM IP address
Voice LT M
VOICE VLAN
Public Voice IP address Network IP address User IP address Subtending IP address
Figure 12-52 Routing - Basic layer 3 addressing topology - Subtending ISAM Voice
External OAM VLAN
Fast-path VRF Voice LT 1 NT
Subtending VLAN
Public OAM IP address Public Voice IP address
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
Voice LT M
November 2013
12-55
12 — ISAM Voice Network Architecture Figure 12-53 Routing - Basic layer 3 addressing topology - Remote ISAM Voice
External OAM VLAN
Fast-path VRF
Network VLAN
Voice LT 1 NT
VOICE VLAN Public OAM IP Address Public Voice IP Address Network IP address
Voice LT M
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 IHub. 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 (IHub) • Network-side next hop IP address configured at the network side of the fast path VRF (IHub)
• Voice / XLES path: Network-side next hop IP address configured at the network side of the fast path VRF (IHub) • User-side next hop IP address configured at the user side of the fast path VRF (IHub) for the subtending link. IP subnet reduction topology
This model intends to reduce the number of IP subnets (that is, the total amount of reserved IP addresses), required for the integrated 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. • The same network-side VLAN is shared by signaling and Voice/XLES traffic and configured at the network side of the fast path VRF. 12-56
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
• The public Voice IP interface is configured at the user side of the fast path VRF at the IHub.
• 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:
• Signaling traffic and XLES traffic originating at the Voice server: layer 3 forwarding at the Voice server and layer 3 forwarding at the IHub.
• Voice/XLES traffic originating at the Voice LT: Voice/XLES packet internally relayed from Voice LT board to IHub and layer 3 forwarding at the IHub.
• Voice/XLES traffic originating at the subtending interface: layer 3 forwarding at the IHub.
• Downstream packet forwarding: • Signaling traffic and XLES traffic destined to the Voice server: layer 3 forwarded at the IHub.
• Voice traffic and XLES traffic destined to the Voice LT: layer 3 followed by layer 4 forwarded from the IHub to the Voice LT board.
• Voice traffic and XLES traffic destined to the subtending interface: layer 3 forwarded at the IHub.
• Shared signaling/Voice/XLES VLAN at the user side of the fast path VRF: Configurable. 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 IHub/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: Configurable. Ports associated with this VLAN are the subtending port(s). The VLAN terminates at the IHub 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)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-57
12 — ISAM Voice Network Architecture
The basic layer 3 addressing topology with IP subnet reduction is shown in the following figures:
• For a hub ISAM Voice, see Figure 12-54. • For a subtending ISAM Voice, see Figure 12-55. • For a remote ISAM Voice, see Figure 12-56. Figure 12-54 Routing - IP subnet reduction topology - HUB ISAM Voice MG Internal OAM VLAN Voice Server 1
External OAM VLAN
MG
Shared SIGNALING /VOICE VLAN
Voice Server N
Fast-path VRF
Network VLAN
Voice LT 1 NT
Subtending VLAN Public OAM IP Address Public Voice IP Address Public shared Signaling/Voice/XLES IP Address
Private OAM IP Address Network IP address Subtending IP address
Voice LT M
Figure 12-55 Routing - IP subnet reduction topology - Subtending ISAM Voice External OAM VLAN
VOICE VLAN Fast-path VRF Voice LT 1 NT
Public OAM IP Address Public Voice IP Address Voice LT M
12-58
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-56 Routing - IP subnet reduction topology - Remote ISAM Voice External OAM VLAN
Network VLAN
Fast-path VRF Voice LT 1 NT
VOICE VLAN Public OAM IP Address Public Voice IP Address Network IP address
Voice LT M
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 IHub.
• Residing at the IHub. • Configurable. • Signaling/Voice path: • Network-side next hop IP address configured at the network side of the fast path VRF (IHub
• User-side next hop IP address configured at the user side of the fast path VRF (IHub) for the subtending link. IP subnet and IP address reduction topology
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 IHub. 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-59
12 — ISAM Voice Network Architecture
• 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 fast 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 IHub.
• Voice traffic and XLES traffic originating at the Remote ISAM Voice: Voice/XLES packet is internally relayed from the Voice LT board to the IHub and layer 3 forwarding at the IHub.
• 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 IHub. Voice traffic and XLES traffic destined to the Voice LT board (Remote ISAM Voice): layer 3 followed by layer 4 forwarding from the IHub 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 IHub and layer 3 forwarding at the IHub. • 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 IHub to the Voice LT board. • Shared public signaling/Voice/XLES VLAN at the user side of the fast path VRF: 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 boards in the remote ISAM Voice. The shared VLAN terminates at the IHub / Voice server and at the Voice LT board in the Remote ISAM Voice nodes. It carries:
• Megaco and SIGTRAN signaling traffic exchanged between the MGC (Call • • • • •
12-60
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 board hosted in the remote ISAM Voice node.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
• Private Voice VLAN: Configurable. 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 IHub, 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.
• RTCP traffic. • XLES traffic (internal signaling, control and management) exchanged between the 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: Configurable. Ports associated with this VLAN are the subtending port(s). The VLAN terminates at the IHub 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 3 addressing topology with IP subnet reduction and IP address reduction is shown in the following figures:
• For a hub ISAM Voice, see Figure 12-57. • For a subtending ISAM Voice, see Figure 12-58. • For a remote ISAM Voice, see Figure 12-59. Figure 12-57 Routing - IP subnet and IP address reduction topology - HUB ISAM Voice MG Internal OAM VLAN Shared SIGNALING/VOICE VLAN
Voice Server 1
External OAM VLAN
MG
Private VOICE VLAN Network VLAN
Voice Server N
Fast-path VRF
Voice LT 1
NT
Subtending VLAN Public OAM IP Address Private Voice IP Address Public shared Signaling/XLES IP Address Private OAM IP Address
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
Voice LT M
Private XLES IP Address Network IP address User IP address Subtending IP address
November 2013
12-61
12 — ISAM Voice Network Architecture Figure 12-58 Routing - IP subnet an IP address reduction topology - Subtending ISAM Voice External OAM VLAN
Private VOICE VLAN Fast-path VRF
Voice LT 1 NT
Public OAM IP Address Private Voice IP Address Voice LT M
Figure 12-59 Routing - IP subnet and IP address reduction topology - Remote ISAM Voice External OAM VLAN Shared SIGNALLING /VOICE VLAN Voice server N
Network VLAN
Fast-path VRF Voice LT 1 NT
Public OAM IP Address Public Voice IP Address Network IP address Voice LT M
The layer 3 IP address scheme then looks as follows:
• 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 IHub. 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 IHub. Configurable.
• Private XLES IP address (for hub ISAM Voice node): • Residing at the Voice server. • Shared by a redundant pair of Voice servers. • Configurable.
12-62
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
• Public Signaling / Voice path: Network-side next hop IP address configured at the network side of the fast path VRF (HUB and Remote IHub). User-side next hop IP address configured at the user side of the fast path VRF (HUB IHub). • User-side next hop IP address configured at the user side of the fast path VRF (IHub) for the subtending link.
SIP ISAM Voice as switching device The following addressing topologies are supported:
• • • •
Distributed IP address architecture - shared signaling/Voice IP interface Distributed IP address architecture - distinct signaling/Voice IP interface Centralized IP address architecture - distinct signaling/Voice IP interface Centralized IP address architecture - shared signaling/Voice IP interface
The following is common to all four addressing topologies:
• Equipment, platform and integrated voice service management entity is hosted at the NT.
• A SIP UA instance is hosted at each Voice LT board. • The external communication VLAN carries the external management traffic (see chapter “Management”).
• The public OAM IP interface is configured at the NT (see chapter “Management”). Distributed IP address topology - shared signaling/Voice IP interface
• A single VLAN shared by signaling and Voice traffic is configured at the IHub. • A single source/destination IP interface shared by signaling and Voice traffic is configured at the voice LT • Upstream packet forwarding:
• Layer 3 forwarding of signaling/Voice packet at the Voice LT. • Layer 2 forwarding of signaling/Voice packet at the IHub. • Layer 2 forwarding of signaling/Voice packet from subtending to network side. • Downstream packet forwarding: • Layer 2 forwarding of signaling/Voice packet at the IHub. • Layer 2 forwarding of signaling/Voice packet from network to subtending side. • Shared signaling/Voice VLAN: 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 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-63
12 — ISAM Voice Network Architecture
Figure 12-60 shows the addressing topology for this model. Figure 12-60 Distributed IP address topology - Switching - Shared signaling/voice IP interface SIP UA
Voice LT 1
OAM VLAN
SIP UA
Voice LT K
Shared SIGNALING/VOICE VLAN
SIP UA
Fast-path VRF
Voice LT L
NT
SIP UA
OAM IP Address Shared signaling/Voice IP Address Voice LT X Subtending node
Relying on the former layer 2 forwarding scheme, the layer 3 IP address scheme then looks as follows:
• signaling/Voice IP interface: • Configurable at the Voice LT. • Multiple IP interfaces per ISAM Voice access node. Distributed IP address topology - distinct signaling/Voice IP interface
• Distinct VLANs for signaling and Voice traffic are configured at the IHub. • Distinct IP interfaces for signaling and Voice traffic are configured at the Voice LT. • Upstream packet forwarding:
• Layer 3 forwarding of signaling/Voice packet at the Voice LT. • Layer 2 forwarding of signaling/Voice packet at the IHub. • Layer 2 forwarding of signaling/voice packet from subtending to network side • Downstream packet forwarding: • Layer 2 forwarding of signaling/Voice packet at the IHub. • Layer 2 forwarding of signaling/Voice packet from network to subtending side. • Signaling VLAN: 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 and carries the SIP signaling traffic exchanged between the SIP server and the SIP User Agent (ISAM Voice). • Voice VLAN: 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.
12-64
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
Figure 12-61 shows the addressing topology for this model. Figure 12-61 Distributed IP address topology - Switching - Distinct signaling/voice IP interface SIP UA
External OAM VLAN
Voice LT 1
SIP UA
SIGNALING VLAN Voice LT K
Fast-path VRF
SIP UA
Voice LT L
VOICE VLAN NT
SIP UA
Public OAM IP Address Public Signaling IP Address Public Voice IP Address
Voice LT X Subtending node
Relying on the former layer 2 forwarding scheme, the layer 3 IP address scheme then looks as follows:
• Signaling IP interface: • Configurable at the Voice LT. • Multiple IP interfaces per ISAM Voice access node. • Voice IP address: • Configurable at the Voice LT. • Multiple IP interfaces per ISAM Voice access node. Centralized IP address topology - distinct signaling/Voice IP interface
• Distinct VLANs for signaling traffic and for Voice traffic are configured at the IHub • Distinct IP interfaces for signaling traffic and for Voice traffic are configured at the IHub • Upstream packet forwarding:
• Signaling/Voice packet internally relayed from the Voice LT board to the IHub • Layer 3 forwarding of signaling/Voice packet at the IHub. • Layer 2 forwarding of signaling/Voice packet from subtending to network side • Downstream packet forwarding: • Layer 4 forwarding of signaling/Voice packet from the IHub to the Voice LT board. • Layer 2 forwarding of signaling/Voice packet from network to subtending side.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-65
12 — ISAM Voice Network Architecture
• Signaling VLAN: The VLAN is configurable. Ports associated with this VLAN/ V_VPLS 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 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 board and carries the RTP traffic exchanged between end users and RTCP traffic. Figure 12-62 shows the addressing topology for this model. Figure 12-62 Centralized IP address topology - Switching - Distinct signaling/voice IP interface SIP UA
Voice LT 1
External OAM VLAN SIP UA
Voice LT K
SIGNALING VLAN
SIP UA
Fast-path VRF
Voice LT L
VOICE VLAN
SIP UA NT
Voice LT X
Public OAM IP Address Public Signaling IP Address Public Voice IP Address
Subtending node
Relying on the former layer 2 forwarding scheme, the layer 3 IP address scheme then looks as follows:
• Signaling IP address: • Configurable at the IHub. • Shared by a redundant pair of IHubs. • Single IP interface per ISAM Voice access node. • Voice IP interface: • Configurable at the IHub. • Shared by a redundant pair of IHubs. • Single IP address per ISAM Voice access node.
12-66
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
Centralized IP address topology - shared signaling/Voice IP interface
• A single VLAN shared by signaling traffic and by Voice traffic is configured at the IHub • A single IP interface shared by signaling traffic and by Voice traffic is configured at the IHub • Upstream packet forwarding:
• Signaling/Voice packet internally relayed from the Voice LT board to the IHub • Layer 3 forwarding of signaling/Voice packet at the IHub. • Layer 2 forwarding of signaling/Voice packet from subtending to network side • Downstream packet forwarding: • Layer 4 forwarding of signaling/Voice packet from the IHub to the Voice LT board. • Layer 2 forwarding of signaling/Voice packet from network to subtending side • Shared signaling/Voice VLAN: The VLAN is 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/Voice VLAN terminates at the Voice LT and carries the SIP signaling traffic exchanged between the SIP server and the SIP User Agent (ISAM Voice) together with the RTP traffic exchanged between end users and the RTCP traffic. Figure 12-63 shows the addressing topology for this model. Figure 12-63 Centralized IP address topology - Switching - Shared signaling/voice IP interface SIP UA
Voice LT 1
External OAM VLAN
SIP UA
Shared SIGNALING/VOICE VLAN Voice LT K
Fast-path VRF
SIP UA
NT
Voice LT L
OAM IP Address Shared Signaling/Voice IP Address
SIP UA
Subtending node
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
Voice LT X
November 2013
12-67
12 — ISAM Voice Network Architecture
Relying on the former layer 2 forwarding scheme, the layer 3 IP address scheme then looks as follows:
• Shared public signaling/Voice IP interface: • Configurable at the IHub. • Shared by a redundant pair of IHubs. • Single IP interface per ISAM Voice access node. SIP ISAM Voice as routing device The following addressing topologies are supported:
• • • •
Distributed IP address architecture - shared signaling/Voice IP interface Distributed IP address architecture - distinct signaling/Voice IP interface Centralized IP address architecture - distinct signaling/Voice IP interface Centralized IP address architecture - shared signaling/Voice IP interface
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 each Voice LT board. The external communication VLAN carries the external management traffic (see chapter “Management”). The public OAM IP interface is configured at the NT (see chapter “Management”). Different VLANs at the network side and at the user side of the fast path VRF.
Distributed IP address topology - shared signaling/Voice IP interface
• A single VLAN shared by signaling and Voice traffic is configured at the user • • • • • • •
side of the fast path VRF. A single VLAN shared by signaling and voice traffic is configured at the network side of the fast path VRF. A single IP interface shared by signaling/voice traffic is configured at the Voice LT. A single subtending VLAN shared by signaling and 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. Upstream packet forwarding:
• Layer 3 forwarding of signaling/Voice packet at the Voice LT. • Layer 3 forwarding of signaling/Voice packet at the IHub. • Layer 3 forwarding of signaling/Voice packet from subtending to network side
12-68
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
• Downstream packet forwarding: • Layer 3 forwarding of signaling/Voice packet at the IHub. • Layer 3 forwarding of signaling/voice packet from network to subtending side. • Signaling/Voice VLAN at the user side of the fast path VRF: 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:
• SIP signaling traffic exchanged between the SIP server and the SIP UA (ISAM Voice).
• RTP traffic exchanged between end users. • RTCP traffic. • Subtending signaling/Voice VLAN at the user side of the fast path VRF: Configurable. Ports associated with this VLAN are the subtending port(s). The user side 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 UA (ISAM Voice).
• RTP traffic exchanged between end users. • RTCP traffic. Figure 12-64 shows the routing model. Figure 12-64 Distributed IP address (routing) - shared signaling/voice IP interface SIP UA
Shared SIGNALING/VOICE user v-VPLS
Vo ice LT 1
Exte r n a l O AM v-VPLS SIP UA IACM Vo ice LT K
SIP UA
Vo ice LT L
IHub NT
Network v-VPLS SIP UA Public O AM IP Address Shared Signaling/Voice IP Address at user v-VPLS Network IP Address at network v-VPLS User IP address Subtending IP address
Vo ice LT X subtending node
The layer 3 IP address scheme then looks as follows:
• Signaling/Voice IP interface: • Configurable at the Voice LT. • Multiple IP interfaces per ISAM Voice access node.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-69
12 — ISAM Voice Network Architecture
• User side signaling/voice VLAN: Next hop IP interface configured at the user side of the fast path VRF (IHub)
• Network side signaling/voice VLAN: Next hop IP interface configured at the network side of the fast path VRF (IHub) • User side subtending signaling/voice VLAN: Next hop IP interface configured at the user side of the fast path VRF (IHub) Distributed IP address topology - distinct signaling/Voice IP interface
• Distinct VLANs for signaling and Voice traffic are configured at the user side of • • • • • • • • • •
the fast path VRF. Distinct VLANs for signaling and voice traffic are configured at the network side of the fast path VRF. Distinct IP interfaces are configured at the Voice LT. Distinct subtending VLANs for signaling and Voice traffic are configured at the user side of the fast path VRF A Next Hop IP interface is configured on top of signaling VLAN at the user side of the fast path VRF A Next Hop IP interface is configured on top of 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. A Next Hop IP interface is configured on top of the subtending voice VLAN at the user side of the fast path VRF. Upstream packet forwarding:
• Layer 3 forwarding of signaling/Voice packet at the Voice LT. • Layer 3 forwarding of signaling/Voice packet at the IHub. • Layer 3 forwarding of signaling/voice packet from subtending to network side. • Downstream packet forwarding: • Layer 3 forwarding of signaling/Voice packet at the IHub. • Layer 3 forwarding of signaling/Voice packet from network to subtending side • Signaling VLAN at the user side of the fast path VRF: Configurable. Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT. The signaling VLAN terminates at the Voice LT and carries:
• SIP signaling traffic exchanged between the SIP server and the SIP UA (ISAM Voice).
• Voice VLAN at the user side of the fast path VRF: 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:
• RTP traffic exchanged between end users. • RTCP traffic.
12-70
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
• Subtending VLAN for signaling and Voice at the user side of the fast path VRF: Configurable. Ports associated with these VLANs 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 UA (ISAM Voice).
• RTP traffic exchanged between end users. • RTCP traffic. Figure 12-65 shows the routing model. Figure 12-65 Distributed IP address topology - Routing - Distinct signaling/voice IP interface SIGNALING user v-VPLS
SIP UA
VO ICE user v-VPLS Vo ice LT 1
Exte r n a l O AM v-VPLS SIP UA IACM Vo ice LT K
SIP UA
Network v-VPLS
Vo ice LT L
IHu b NT
SIP UA
Public O AM IP Address Signaling IP Address at user v-VPLS Voice IP Address at user v-VPLS Public Voice IP Address at network v-VPLS User IP address Subtending IP address
Vo ice LT X
subtending node
The layer 3 IP address scheme then looks as follows:
• Signaling IP interface: • Configurable at the Voice LT. • Multiple IP interfaces per ISAM Voice access node. • Public Voice IP interface: • Configurable at the Voice LT. • Multiple IP interfaces per ISAM Voice access node. • User side signaling and user side voice VLAN: Next hop IP interface configured at the user side of the fast path VRF (IHub). • Network side signaling and network side voice VLAN: Next hop IP interface configured at the network side of the fast path VRF (IHub). • User side subtending signaling and user side subtending voice VLAN: Next hop IP interface configured at the user side of the fast path VRF (IHub).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-71
12 — ISAM Voice Network Architecture
Centralized IP address topology- distinct signaling/Voice IP interface
• Distinct VLANs for signaling traffic and for Voice traffic are configured at the • • • • • • • •
user side of the fast path VRF. Distinct VLANs for signaling traffic and for Voice traffic are configured at the network side of the fast path VRF. Distinct IP interfaces are configured at the user side of the VRF at the IHub. 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 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. Upstream packet forwarding:
• Signaling/Voice packet is internally relayed from Voice LT board to IHub • Layer 3 forwarding of signaling/Voice packet at the IHub. • 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 IHub to the Voice LT board.
• Layer 3 forwarding of signaling/Voice packet from network to subtending side. • User-side signaling VLAN of the fast path VRF: The VLAN is configurable. Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT. The user-side signaling VLAN terminates at the voice LT and carries the SIP signaling traffic exchanged between the SIP server and the SIP User Agent (ISAM Voice). • User-side voice VLAN of the fast path VRF: The VLAN is 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:
• RTP traffic exchanged between end users • RTCP traffic. • User-side subtending VLANs for signaling and Voice of the fast path VRF: The VLAN is 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 UA (ISAM • •
Voice) RTP traffic exchanged between end users RTCP traffic.
Figure 12-66 shows the routing model.
12-72
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-66 Centralized IP address topology - Routing - Distinct signaling/voice IP interface SIP UA
Vo ice LT 1
Exte r n a l O AM v-VPLS SIP UA IACM Vo ice LT K
SIGNALING user v-VPLS
SIP UA
Network v-VPLS
Vo ice LT L
IHu b NT
VO ICE user v-VPLS
Public O AM IP Address Public Signaling IP Address at user v-VPLS Public Voice IP Address at user v-VPLS
SIP UA
Vo ice LT X
Public Voice IP Address at network v-VPLS
The layer 3 IP address scheme then looks as follows:
• Signaling IP address: • Configurable at the IHub (user side fast path VRF). • Shared by a redundant pair of IHubs. • Single IP address per ISAM Voice access node. • Voice IP address: • Configurable at the IHub (user side fast path VRF). • Shared by a redundant pair of IHubs. • 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 (IHub).
• 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 (IHub). Centralized IP address topology- shared signaling/Voice IP interface
• 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 IP interface is configured at the user side of the VRF at the IHub. 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 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-73
12 — ISAM Voice Network Architecture
• Upstream packet forwarding: • Signaling/Voice packet is internally relayed from Voice LT to IHub. • Layer 3 forwarding of signaling/Voice packet at the IHub. • 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 IHub 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 configurable. Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT. The signaling/Voice VLAN terminates at the Voice LT carries:
• SIP signaling traffic exchanged between the SIP server and the SIP UA (ISAM Voice).
• RTP traffic exchanged between end-users. • RTCP traffic. • Subtending signaling/Voice VLAN at the user side of the fast path VRF: The VLAN is 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 UA (ISAM Voice).
• RTP traffic exchanged between end-users. • RTCP traffic. Figure 12-67 shows the routing model. Figure 12-67 Centralized IP address topology - Routing - Shared signaling/voice IP interface SIP UA
Vo ice LT 1
Exte r n a l O AM v-VPLS SIP UA IACM Vo ice LT K
Shared SIGNALING/VOICE user v-VPLS
SIP UA
Vo ice LT L
IHub NT
Network v-VPLS SIP UA
Public O AM IP Address Public Signaling/Voice IP Address at user v-VPLS
Vo ice LT X
Public IP Address at network v-VPLS
12-74
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
The layer 3 IP address scheme then looks as follows:
• Signaling IP interface: • Configurable at the IHub (user side fast path VRF). • Shared by a redundant pair of IHubs. • 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 (IHub). • User-side subtending VLAN sharing signaling traffic and voice traffic: next-hop IP interface configured at the user side of the fast path VRF (IHub).
12.7
Protocol stacks Megaco ISAM Voice Signaling Protocol Stack (Switching / Routing Both POTS and ISDN BRI lines are supported. 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 12-68 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 12-68 POTS signaling protocol stack - HUB ISAM Voice - Switching model Hub ISAM Voice
XLES
XLES
LapV5
LapV5
UDP
UDP
UDP
IP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
802.3
IHub
EMAN
H.248
H.248
Z Itf
Termination
UDP IP
Z Itf
Voice LT
Voice Server
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
IP Generic PHY
Edge Router
November 2013
L3
IP Generic PHY
MGC
12-75
12 — ISAM Voice Network Architecture Figure 12-69 POTS signaling protocol stack - HUB ISAM Voice - Routing model Hub ISAM Voice
XLES
XLES
LapV5
LapV5
UDP
UDP
UDP
IP
IP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
802.3
IHub
EMAN
H.248
H.248
UDP
Termination
Voice Server
Voice LT
IP Generic PHY
Generic PHY
Z Itf
Z Itf
L3
IP
IP
Edge Router
MGC
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 12-70 POTS signaling protocol stack - Subtending ISAM Voice - Switching model Subtending ISAM Voice
Hub ISAM Voice
XLES
XLES
LapV5
LapV5
UDP
UDP
UDP
IP
IP
IP
H.248
H.248
Z Itf
Termination
UDP IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
802.3
802.3
802.3
IHub
IHub
Voice Server
IHub
EMAN
Z Itf
Voice LT
IP
L3
IP Generic PHY
Generic PHY
Edge Router
MGC
Figure 12-71 POTS signaling protocol stack Subtending ISAM Voice - Routing model Subtending ISAM Voice
Hub ISAM Voice
XLES
XLES
LapV5
LapV5
H.248
H.248
UDP IP
Z Itf
Termination
12-76
UDP
UDP
IP
IP
IP
IP
UDP IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
802.3
802.3
802.3
IHub
IHub
Voice Server
IHub
EMAN
Z Itf
Voice LT
November 2013
IP Generic PHY
Edge Router
L3
IP Generic PHY
MGC
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-72 POTS signaling protocol stack - Remote ISAM Voice - Switching model Remote ISAM Voice
Hub ISAM Voice
XLES
XLES
LapV5
LapV5
UDP
UDP
UDP
IP
IP
IP
802.1Q
802.1Q
802.1Q 802.3
H.248
H.248
802.1Q Z Itf
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
IHub
EMAN
Z Itf 802.3
Termination
802.1Q
UDP
Voice LT
802.3
802.3
802.3
802.3
IHub
EMAN
IHub
Voice Server
L3
IP
IP
IP Generic PHY
Generic PHY
Edge Router
MGC
Figure 12-73 POTS signaling protocol stack - Remote ISAM Voice - Routing model Remote ISAM Voice
Hub ISAM Voice
XLES
XLES
LapV5
LapV5
H.248
H.248
UDP
Z Itf
Termination
UDP
UDP
IP
IP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
802.3
802.3
802.3
IHub
EMAN
IHub
EMAN
IP
IP
802.1Q
802.1Q
802.3
UDP IP
Z Itf
Voice LT
IHub
Voice Server
L3
IP
IP Generic PHY
Generic PHY
Edge Router
MGC
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 12-74 ISDN BRI signaling protocol stack - HUB ISAM Voice - Switching model Hub ISAM Voice
Q931
Q931 XLES
XLES
LapV5
LapV5
UDP
UDP
SCTP
IP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
802.3
IHub
EMAN
IUA Q921
I410
Termination
Q921
I410
Voice LT
Voice Server
IUA
SCTP IP
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
IP Generic PHY
Edge Router
November 2013
L3
IP 802.1Q 802.3
MGC
12-77
12 — ISAM Voice Network Architecture Figure 12-75 ISDN BRI signaling protocol stack - HUB ISAM Voice - Routing model Hub ISAM Voice
Q931
Q931 XLES
XLES
LapV5
LapV5
UDP
UDP
SCTP
IP
IP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
802.3
IHub
EMAN
IUA Q921
Q921
I410
I410
Termination
IUA
SCTP
Voice Server
Voice LT
L3
IP
IP
IP 802.1Q
Generic PHY
802.3
Edge Router
MGC
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. Figure 12-76 ISDN BRI signaling protocol stack - Subtending ISAM Voice Switching model Subtending ISAM Voice
Hub ISAM Voice
Q931
Q921
I410
Termination
Q931
Q921
I410
XLES
XLES
LapV5
LapV5
UDP
UDP
SCTP
IP
IP
IP
IUA
IUA
L3 IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
802.3
802.3
802.3
IHub
IHub
Voice Server
IHub
EMAN
Voice LT
SCTP IP
IP
802.1Q
Generic PHY
802.3
Edge Router
MGC
Figure 12-77 ISDN BRI signaling protocol stack - Subtending ISAM Voice - Routing model Subtending ISAM Voice
Hub ISAM Voice
Q931
Q921
Q931
Q921
XLES
XLES
LapV5
LapV5
UDP IP
I410
Termination
12-78
I410
IUA
IUA
L3
UDP
SCTP
IP
IP
IP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
802.3
802.3
802.3
IHub
IHub
Voice Server
IHub
EMAN
Voice LT
November 2013
IP Generic PHY
Edge Router
SCTP IP 802.1Q 802.3
MGC
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-78 ISDN BRI signaling protocol stack - Remote ISAM Voice - Switching model Remote ISAM Voice
Hub ISAM Voice
Q931
Q931 XLES
XLES
LapV5
LapV5
UDP
UDP
SCTP
IP
IP
IP
IUA
IUA Q921
I410
Termination
Q921
I410
L3 IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
802.3
802.3
802.3
802.3
IHub
EMAN
IHub
Voice Server
IHub
EMAN
Voice LT
SCTP IP
IP
802.1Q
Generic PHY
802.3
Edge Router
MGC
Figure 12-79 ISDN BRI signaling protocol stack - Remote ISAM Voice - Routing model Remote ISAM Voice
Hub ISAM Voice
Q931
Q931 XLES
XLES
LapV5
LapV5
IUA
IUA Q921
Q921
UDP
I410
I410
IP
IP
802.1Q
802.1Q
802.3
Termination
Voice LT
802.3
IHub
802.1Q 802.3
EMAN
UDP
SCTP
IP
IP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
IHub
Voice Server
L3
802.3
IHub
IP 802.1Q
802.1Q
802.3
802.3
EMAN
IP Generic PHY
Edge Router
SCTP IP 802.1Q 802.3
MGC
SIP ISAM Voice Signaling Protocol Stack (Switching / Routing) Only POTS lines are supported. 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 12-80, Figure 12-81, Figure 12-82, Figure 12-83, Figure 12-84, and Figure 12-85 show the SIP signaling protocol stack for a POTS termination. The Z interface is terminated at the Voice LT. User events like hook off, hook on, and so on are converted into SIP messages sent to the SIP server.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-79
12 — ISAM Voice Network Architecture Figure 12-80 POTS signaling protocol stack - Distributed Architecture - Switching model Hub ISAM Voice
SIP
SIP
UDP
UDP
IP
Z Itf
Termination
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
IHub
EMAN
Z Itf
Voice LT
IP
L3
IP Generic PHY
Generic PHY
Edge Router
TGW
Figure 12-81 POTS signaling protocol stack - Distributed Architecture - Routing model Hub ISAM Voice
SIP
SIP
UDP
Z Itf
Termination
UDP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
IHub
EMAN
IP
Z Itf
Voice LT
IP
L3
IP Generic PHY
Generic PHY
Edge Router
MGC
Figure 12-82 POTS signaling protocol stack - Centralized Architecture - Upstream - Switching model Hub ISAM Voice
SIP
SIP
UDP
Z Itf
Termination
UDP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
IHub
EMAN
IP
Z Itf
Voice LT
IP
L3
IP Generic PHY
Generic PHY
Edge Router
MGC
Figure 12-83 POTS signaling protocol stack - Centralized Architecture - Upstream - Routing model Hub ISAM Voice
SIP
SIP
UDP
Z Itf
Termination
12-80
November 2013
UDP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
IHub
EMAN
IP
Z Itf
Voice LT
IP Generic PHY
Edge Router
L3
IP Generic PHY
MGC
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-84 POTS signaling protocol stack - Centralized Architecture Downstream - Switching model Hub ISAM Voice
SIP
SIP
UDP
UDP
IP
IP
UDP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
Termination
IHub
EMAN
Voice LT
IP Generic PHY
Generic PHY
Z Itf
Z Itf
L3
IP
IP
Edge Router
MGC
Figure 12-85 POTS signaling protocol stack - Centralized Architecture Downstream - Routing model Hub ISAM Voice
SIP
Z Itf
Termination
SIP
UDP
UDP
IP
IP
IP
UDP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
IHub
EMAN
IP Generic PHY
Generic PHY
Z Itf
Voice LT
L3
IP
IP
Edge Router
MGC
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 12-86 MEGACO POTS Voice protocol stack - Upstream - Switching model Hub ISAM Voice
RTP
RTP
UDP
UDP
IP
Z Itf
Termination
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
IHub
EMAN
Z Itf
Voice LT
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
IP
L3
Generic PHY
Edge Router
November 2013
IP Generic PHY
MGC
12-81
12 — ISAM Voice Network Architecture Figure 12-87 MEGACO Voice protocol stack - Upstream - Routing model Hub ISAM Voice
RTP
RTP
UDP
UDP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
Termination
IHub
EMAN
Voice LT
IP Generic PHY
Generic PHY
Z Itf
Z Itf
L3
IP
IP
Edge Router
MGC
Figure 12-88 MEGACO POTS Voice protocol stack - Downstream - Switching model Hub ISAM Voice
RTP
RTP
UDP
UDP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
Termination
IHub
EMAN
Voice LT
IP Generic PHY
Generic PHY
Z Itf
Z Itf
L3
IP
IP
Edge Router
MGC
Figure 12-89 MEGACO Voice protocol stack - Downstream - Routing model Hub ISAM Voice
RTP
Z Itf
Termination
RTP
UDP
UDP
IP
IP
IP
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
UDP
802.1Q
802.1Q
802.3
802.3
Z Itf
IHub
Voice LT
EMAN
L3
IP
IP
IP Generic PHY
Generic PHY
Edge Router
TGW
Figure 12-90 SIP POTS Voice protocol stack - Distributed Architecture - Switching model Hub ISAM Voice
RTP
RTP
UDP
UDP
IP 802.1Q Z Itf
802.1Q
802.1Q
802.3
802.3
802.3
IHub
EMAN
802.1Q
Z Itf 802.3
Termination
12-82
IP
November 2013
Voice LT
IP Generic PHY
Edge Router
L3
IP Generic PHY
MGC
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-91 SIP POTS Voice protocol stack - Distributed Architecture - Routing model Hub ISAM Voice
RTP
RTP
UDP
UDP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
Termination
IHub
EMAN
Voice LT
IP Generic PHY
Generic PHY
Z Itf
Z Itf
L3
IP
IP
Edge Router
MGC
Figure 12-92 SIP POTS Voice protocol stack - Centralized Architecture - Upstream - Switching model Hub ISAM Voice
Z Itf
Termination
RTP
RTP
UDP
UDP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
IHub
EMAN
IP
Z Itf
Voice LT
IP
L3
IP Generic PHY
Generic PHY
Edge Router
MGC
Figure 12-93 SIP Voice protocol stack - Centralized Architecture - Upstream Routing model Hub ISAM Voice
Z Itf
Termination
RTP
RTP
UDP
UDP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
IHub
EMAN
IP
Z Itf
Voice LT
IP
L3
IP Generic PHY
Generic PHY
Edge Router
MGC
Figure 12-94 SIP Voice protocol stack - Centralized Architecture - Downstream Switching model Hub ISAM Voice
RTP
Z Itf
Termination
RTP
UDP
UDP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
UDP IP
Z Itf
Voice LT
IHub
EMAN
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
IP Generic PHY
Edge Router
November 2013
L3
IP Generic PHY
MGC
12-83
12 — ISAM Voice Network Architecture Figure 12-95 SIP Voice protocol stack - Centralised Architecture - Downstream Routing model Hub ISAM Voice
RTP UDP
Z Itf
Termination
12.8
RTP UDP
UDP
IP
IP
IP
802.1Q
802.1Q
802.1Q
802.1Q
802.1Q
802.3
802.3
802.3
802.3
802.3
Z Itf
Voice LT
IHub
IP
IP
EMAN
Generic PHY
Edge Router
L3
IP Generic PHY
MGC
Voice service and MPLS Pseudo-wire See chapter “MPLS” for more information.
12.9
Management interface MEGACO ISAM Voice The provisioning of the Megaco ISAM Voice service parameters is done via the a CLI / SNMP(MIB) interface together with a CDE profile to be downloaded from a file server. Configuration by means of DHCP is not supported. CLI / SNMP Interface
The SNMPV3 agent hosted at the Voice Server serves as the management interface for the integrated VoIP service. However, neither CLI nor SNMP commands can directly be addressed to the Voice Server. In general, the Integrated VoIP service cannot be managed via TL1. Although, as an exception, VoIP service alarms can be retrieved via TL1. All CLI or SNMP commands to manage the integrated VoIP service are addressed to the public OAM IP address of the access node and are subsequently relayed to the correct Voice Server by means of the “voice server context name” present in the management command. A Voice server context name is mapped to a private IP address, out of the range 127.0.0.11 to 127.0.0.26. The private IP address is assigned to a Voice Server. This IP address to Voice Server mapping is fixed and based on the physical slot position of the Voice Server. SNMP commands, carrying a “voice server context name”, are addressed to the NT SNMP agent which in turn relays the command to the destined Voice Server. CLI commands, carrying a “voice server identifier”, are addressed to the NT CLI agent, where it becomes translated into the appropriate SNMP command and forwarded to the NT SNMP agent The NT SNMP agent in turn relays the SNMP command to the destined Voice Server. 12-84
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
Batch configuration CLI command support for subscriber management
A subscriber is a logical entity managed by the MG that sources and/or sinks media and/or control streams. Subscriber have unique identities, called “TerminationIDs” assigned by the MG at the time of their creation. The ISAM Voice allows to make use of 3 different formats for the “TerminationID”:
• The FLAT termination ID: Typical Format: 'prefix' • The LEGACY HIERARCHICAL termination ID: Typical format: “Prefix/Dslam_Id/rack/shelf/slot/port(/channel” • The IMPROVED HIERARCHICAL termination ID: Typical format: “Prefix/Dslam_Id/rackXXXXX/shelfXXXXX/slotXXXXX/ portXXXXX/channel” In case the customer decides to make use of the FLAT termination ID format, then such termination id is to be configured for each of the terminations. The FLAT termination ID can be provisioned in two different ways:
• By initiating a single “create” command per termination and provisioning the value for the Flat Termination ID. • By initiating a batch “create” command for a series of terminations (typically within the limits of a voice LT board). In this case, the operator doesn't provision a value for the Flat termination ID parameter. The system autonomously creates the terminations for a voice LT board and assigns autonomously the value of the Flat Termination ID, starting from 1 or previously successfully completed “create” command. and increment it by 1 for every subsequent termination being created. If the customer decides to make use of the HIERARCHICAL termination ID format, then the desired pattern is to be configured once and the system will autonomously create the appropriate hierarchical termination id for each of the terminations. It must be noted, that in this case also the flat termination ID is to be configured for each of the terminations as this is still internally used by ISAM Voice.
SIP ISAM Voice The provisioning of the SIP ISAM Voice service parameters is done via the a CLI / SNMP(MIB) interface together with the SIP Service Profile and CDE profile to be downloaded from a file server and optionally DHCP. CLI / SNMP Interface
The Integrated VoIP Service Management interface is fully supported by the SNMP and CLI agents that reside at the NT. All CLI or SNMP commands to manage the integrated VoIP service are addressed to the public OAM IP address of the access node. The integrated VoIP service cannot be managed by means of TL1. Although, as an exception, VoIP service alarms can be retrieved via TL1.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-85
12 — ISAM Voice Network Architecture
DHCP
The SIP Distributed model allows part of the configuration data to be retrieved through a DHCP request. Following DHCP options are supported: Table 12-1 Supported DHCP options Option
Name
1
Subnet-Mask
3
Router
6
Domain Name Server
50
DHCP Requested Address
51
DHCP Lease Time
53
DHCP Message Type
55
DHCP Parameter Request List
57
DHCP Maximum Message Size
58
DHCP Renewal Time
59
DHCP Rebinding Time
60
DHCP Class Identifier
61
DHCP Client Identifier
81
Client FQDN
82
Client ID(1)
90
Authentication
120
SIP Servers
124
Vendor-Identifying Vendor Class
Note (1)
The insertion of Option 82 by the DHCP client at the voice LT board can be enabled/disabled through configuration. Only the sub-option “Remote-ID” is supported. The content of the “Remote-ID” is configurable. The default value equals the Physical LT Board-ID i.e. rack/shelf/slot.
DHCP is not supported for the SIP centralized model.
CDE Profile Besides the usual management interface to configure the network and end user associated database parameters for the integrated voice service, ISAM Voice makes use of additional configuration input under the format of a downloadable file. Allowing the integrated voice service to become fully operational requires the presence of the CDE profile at the Voice server (Megaco ISAM Voice only) and the Voice LT (both Megaco and SIP ISAM Voice).
12-86
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
The content of CDE profile is customer dependent. A CDE profile is produced off-line at the factory. The content is collected by means of a questionnaire, filled in by the customer. The content is considered to be of static nature and concerns mainly the physical subscriber line, the Z-interface, the tone pattern, the protocols that run at the end user side and LT board HW characteristics. There is a dedicated CDE profile for the POTS Voice LT, the ISDN BRI Voice LT and the Voice server. The latter 2 profiles do only apply to the Megaco ISAM Voice). The CDE profile for the POTS Voice LT is voice topology independent meaning that the same CDE profile can be used in either a Megaco or a SIP environment. The CDE profiles for the POTS/ISDN BRI Voice LT and Voice server are included in a CDE.tar file. This file must be downloaded and activated in the individual ISAM Voice access nodes (SIP ISAM Voice). For the Megaco ISAM Voice, 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 (Megaco ISAM Voice only) and /or Voice LT. The system supports CDE profile upgrade. They are as well an integral part of the offline database migration during software upgrade.
SIP Service Profile SIP ISAM Voice has introduced the concept of “Service profile” to achieve a maximum on flexibility for (1) IOT w/ multiple Application Servers, including the flexibility of a new IOT during a Maintenance phase of a ISAM release and (2) on re-using application SW; as such, application SW shall be data driven, based on the selected options out of the SIP service profile. The SERVICE profile applies to the POTS SIP Voice LT 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.
12.10
Permanent data storage Megaco ISAM Voice The VoIP service provisioned data is archived by the VoIP database(s) stored on the system disk of the NT. The system maintains a separate voice database for each of the Voice Servers. Up to eight VoIP database(s) may be present on the system disk of the NT.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-87
12 — ISAM Voice Network Architecture
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 Voice The VoIP provisioned data is archived by the VoIP database stored on the system disk of the NT. The VoIP database is managed by integrated voice service management entity hosted at the NT board.
12.11
Management model Megaco ISAM Voice Figure 12-96 shows the Megaco ISAM Voice conceptual management model.
12-88
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-96 Megaco ISAM Voice Conceptual Management Model H.248 Protocol and Network Management Model
Read-only Read-Write
Equipment Board
Base Class File Input
1..24
1
0..32
0..72
1 0..5000
H.248 Termination 1
1 1
1
Voice Server
XLES 1
1 0..1
0..1 1..N
Equipment Node
1
POTS Line 0..72 1 POTS LT Board
0..1
1 1..N
ISDN Line
1
Media Gateway
0..24
1
1
0..1
ISDN LT Board
Signaling Gateway
1..2
Line Id Syntax Profile
Voice LT Board 1
1
ISDN CDE Profile
POTS CDE Profile
LT Board
Voice Server CDE Profile
1
NT Board
CDE Profile
VoIP NarrowBand Line Test Management Model Line Test Parameters
1..1024
Voice Server
Session 1
1
1
1
1 1
1..72
Available Session
Line Identity 1 1..N Session Report
VoIP Database Model Voice Server
VoIP Database 1
1
• The classes “SYSTEM”, “NT”, “LT Board” and “Voice Server” reflect the Access Node, the Network Termination, the Line Termination and Voice server hardware being involved in the integrated voice service. These classes are not further elaborated in subsequent sections. • The class “Voice LT Board” is an instantiation of the class “LT Board”. This class is not further elaborated in subsequent sections.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-89
12 — ISAM Voice Network Architecture
• The classes “POTS LT Board” and “ISDN LT Board” are instantiations of the class “Voice LT Board”. This class is not further elaborated in subsequent sections. • The classes “POTS Line” and “ISDN Line” are instantiations of the class “H.248 Termination”. The class “H.248 Termination” is elaborated in subsequent sections. • The classes “POTS CDE Profile”, “ISDN CDE Profile” and “Voice Server CDE” are instantiations of the class “CDE Profile”. The class “POTS CDE Profile” is elaborated in subsequent sections. H.248 Protocol and Network Management Model.
This management model offers the capability to provision the Voice Cluster, the Media and Signaling gateway as well as the network related H.248 protocol parameters. A Voice Cluster is the aggregation of the ISAM Voice network elements controlled by a single Voice Server (pair). The entire Voice Cluster is provisioned by means of the following 2 classes:
• The class “EquipmentNode” includes the attributes and methods that allow the provisioning of the ISAM Voice access nodes that belong to the voice cluster.
• The class “EquipmentBoard” includes the attributes and methods that allow the provisioning of the Voice LT boards that belong to each of the access nodes in the voice cluster. The class “Media Gateway” includes the attributes and methods that allow the provisioning of the H.248 protocol, L2 and L3 network connection and the network redundancy parameters as well as the quality of service characteristics for the signaling as well as the voice stream. The class “H.248 Termination” includes the attributes and methods that allow the provisioning of the individual POTS or ISDN termination characteristics. The class “XLES” includes the attributes and methods that allow the provisioning of the internal Voice cluster signaling characteristics. The class “Signaling Gateway” includes the attributes and methods that allow the provisioning of the L3/L4 and network redundancy characteristics of the Assignment Source Point (ASP). The Class “Line Id Syntax Profile” includes the attributes and methods that allow the provisioning of the POTS and / or ISDN termination ID format. The classes “POTS CDE Profile”, “ISDN CDE Profile” and “Voice Server CDE Profile” include the attributes and methods that allow the provisioning of the physical subscriber line, the Z-interface, the tone pattern, the protocols that run at the end user side and LT board hardware characteristics. VoIP Database Model
The class “VoIP Database” includes the attributes and methods that allow managing the SIP Voice Database.
12-90
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
VoIP Narrowband Line Test Management Model
The class “Available Session” includes the attributes and methods to schedule a new narrowband line test session. The class “Session” includes the attributes and methods that allow the provisioning of the narrowband line test session characteristics. The class “Line Identity” includes the attributes and methods that allow the provisioning of the subscriber lines involved in the narrowband line test session. The class “Line Test Parameters” includes the attributes and methods that allow the provisioning of the parameters to be considered in the course of a narrowband line test session. The class “Session Report” includes the attributes and methods that allow retrieving the results of the completed narrowband line test session.
SIP ISAM Voice The following figures show the SIP ISAM Voice conceptual management models. Figure 12-97 SIP ISAM Voice - Statistics and Counters Management Model
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-91
12 — ISAM Voice Network Architecture Figure 12-98 SIP Protocol and Network Management model VSP
Dial Plan 1
1
0..N
1
1 1..256
SIP Termination 0..1
1
1
1 Digit Map
POTS Line
SIP Timers
N
SIP Server
1..N 1..N
NAPTR Resource Record
1..N
SRV Resource Record
1..N
A Resource Record
DNS Server 0..6
Session Timer 0..1 Line Id Syntax Profile
User Agent Access Point
1
1 POTS LT Board
MIB Readiness ONLY 1
0..1 LT Board
1..18
Transport Protocols
Voice LT Board
1
1..2 1
User Agent Registration
1
Network Redundancy
NT
1
1
MIB Readiness ONLY
DHCP Authentication
Figure 12-99 VoIP services management model
VSP 1
1
0..N
SIP Termination 0..1
1
1 POTS Line N 1 POTS CDE Profile
1
1 1
CDE Profile
1
SIP Service Profile
1
1..N
1..N
POTS LT Board
Voice LT Board
LT Board
NT
12-92
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-100 VoIP Narrowband Line Test model and VoIP database model
VoIP NarrowBand Line Test Model
Line Test Parameters
1..1024
Session
NT
1..16
1
1
1
1
1..16
1..72
Available Session
Line Identity 1
1..N Session Report
VoIP Database Model
NT
VoIP Database 1
1
• The classes “SYSTEM”, “NT”, “LT Board” reflect the Access Node, the
• • • •
Network Termination, and the Line Termination hardware being involved in the integrated voice service. These classes are not further elaborated in subsequent sections. The class “Voice LT Board” is an instantiation of the class “LT Board”. This class is not further elaborated in subsequent sections. The class “POTS LT Board” is an instantiation of the class “Voice LT Board”. This class is not further elaborated in subsequent sections. The class “POTS Line” is an instantiation of the class “SIP Termination”. The class “SIP Termination is elaborated in subsequent sections. The class “POTS CDE Profile” is an instantiation of the class “CDE Profile”. The class “POTS CDE Profile” is elaborated in subsequent sections.
Statistics and Counters Management Model
This management model offers the capability to provision the TCA thresholds as well as to retrieve the SIP termination availability, the SIP termination voice and board resource occupancy statistics and counters. The class “TCA Threshold” includes the attributes and methods that allow the provisioning of the threshold crossing alarms on a per SIP termination. The class “Per-Line Stats Current 15 min” includes the attributes and methods that allow retrieving the per-line measured values during the current 15-minutes interval. The class “Per-Line Stats History 15 min” includes the attributes and methods that allow retrieving the per-line measured values for the past 96 15-min intervals. The class “Per-Line Stats Current 1 day” includes the attributes and methods that allow retrieving the per-line measured values during the current 1-day interval. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-93
12 — ISAM Voice Network Architecture
The class “Per-Line Stats History 1 day” includes the attributes and methods that allow retrieving the per-line measured values for the past three 1-day intervals. The class “Per-Board Stats Current 15 min” includes the attributes and methods that allow retrieving the per-board measured values during the current 15-minutes interval. The class “Per-Board Stats History 15 min” includes the attributes and methods that allow retrieving the per-board measured values for the past 96 15-min intervals. The class “Per-Board Stats Current 1 day” includes the attributes and methods that allow retrieving the per-board measured values during the current 1-day interval. The class “Per-Board Stats History 1 day” includes the attributes and methods that allow retrieving the per-board measured values for the past 3 1-day intervals. The class “Per-Call Stats History 15 min” includes the attributes and methods that allow retrieving the per-call measured values for the past 96 15-minutes intervals. The class “CPU Load” includes the attributes and methods that allow retrieving the CPU occupancy during the past 180 s time period at the Line termination / Network termination board. The class “Memory Resource Occupation” includes the attributes and methods that allow retrieving the actual dynamic memory resource allocation at the Line termination / Network termination board. The class “Subscriber Line Availability”: includes the attributes and methods that allow retrieving the actual service state of the subscriber lines. The class “Per-Line Performance Monitoring Info” includes the attributes and methods that allow retrieving the validity of the measured data during the several intervals. The class “Per-Board Performance Monitoring Info” includes the attributes and methods that allow retrieving the validity of the measured data during the several intervals. The class “Stats Configuration” includes the attributes and methods that allow to:
• enable/disable performance monitoring overall • identify an “incoming call” / “outgoing call” during performance monitoring. SIP Protocol and Network Management Model
This management model offers the capability to provision the access gateway as well as the network related SIP protocol parameters. The class “VSP” includes the attributes and methods that allow the provisioning of the Voice Service Provider properties. The class “SIP Timers” includes the attributes and methods that allow the provisioning of the SIP protocol timers. The class “Dial Plan” includes the attributes and methods that allow the provisioning of the dial plan that applies to the network of the Voice Service Provider.
12-94
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
The class “Digit Map” includes the attributes and methods that allow the provisioning of the Digit Map that applies to the network of the Voice Service Provider. The class “SIP Server” includes the attributes and methods that allow the provisioning of the (list of) SIP server(s) being installed in the network of the Voice Service Provider. The class “DNS Server” includes the attributes and methods that allow the provisioning of the (list of) DNS server(s) being installed in the network of the Voice Service Provider. The class “Session Timer” includes the attributes and methods that allow the provisioning of the Session Timer extension of the SIP protocol. The class “Line Id Syntax Profile” includes the attributes and methods that allow the provisioning of the POTS termination ID format. The class “Transport Protocols” includes the attributes and methods that allow the provisioning of the transport protocols the SIP User Agent must listen to for incoming SIP requests. The class “Registration” includes the attributes and methods that allow the provisioning of the SIP Register Method behavior in the network of the Voice Service Provider. The class “Network Redundancy” includes the attributes and methods that allow the provisioning of the Voice Service Provider's network redundancy characteristics together with the expected SIP User Agent redundancy behavior. The classes “User Agent” and “User Agent Access Point” includes the attributes and methods that allow the provisioning of the L2 and L3 network connection together with the quality of service characteristics for the signaling as well as the voice stream. The class “Termination” includes the attributes and methods that allow the provisioning of the individual SIP termination characteristics. VoIP Services Management Model
This management model offers the capability to provision the physical subscriber line interface, the Z-interface, the tone pattern, the Basic call and Supplementary Services related parameters. The provisioning of these parameters happens by means of a couple of profiles being downloaded by the access node. The customer cannot manually update these profiles. The class “SIP Service Profile” includes the attributes and methods that allow the provisioning of the Basic call and Supplementary service characteristics. The class “POTS CDE Profile” includes the attributes and methods that allow the provisioning of the physical subscriber line, the Z-interface, the tone pattern, the protocols that run at the end-user side and LT board hardware characteristics. VoIP Database Model
The class “VoIP Database” includes the attributes and methods that allow managing the SIP Voice Database. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-95
12 — ISAM Voice Network Architecture
VoIP Narrowband Line Test Management Model
The class “Available Session” includes the attributes and methods to schedule a new narrowband line test session. The class “Session” includes the attributes and methods that allow the provisioning of the narrowband line test session characteristics. The class “Line Identity” includes the attributes and methods that allow the provisioning of the subscriber lines involved in the narrowband line test session. The class “Line Test Parameters” includes the attributes and methods that allow the provisioning of the parameters to be considered in the course of a narrowband line test session. The class “Session Report” includes the attributes and methods that allow retrieving the results of the completed narrowband line test session.
12.12
Reliability, Equipment / Connectivity / Overload Protection Equipment Protection NT redundancy
For further details about NT redundancy, see chapter “Failure protection and redundancy provisions in ISAM”. Megaco ISAM Voice: Voice Server redundancy
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 hardware or a software 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 Protection Besides 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.
12-96
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
Megaco ISAM Voice: Geo-Redundancy
GEO-Redundancy implies the provisioning of a primary, secondary and optionally tertiary Softswitch / Application Server Process (ASP) with each of these Softswitches / Application Server Process being provisioned with a different IP address, and allowing, in case of a failure of the primary control association, to make a switch-over to the secondary or tertiary Softswitch / ASP preserving of stable calls. It is to be noted that the possibility to preserve stable calls during a switch-over depends on the capabilities supported by the Softswitch. The system autonomously notifies the operator about control association changes via SYSLOG notifications. A SYSLOG notification is sent upon:
• The control association being lost due to: • Timer expiry • Heartbeat expiry • The control association being administratively locked by the operator. • The control association being disconnected due to a handoff, forced, graceful service change method initiated by MG / MGC or disconnect service change method initiated by the MG. • The control association being established with the MGC A failure of the current control association may be detected as described hereafter:
• Upon no reply received on a transaction request initiated by the Voice server: Megaco ISAM Voice allows to provision the maximum number of retries per transaction together with the retry mode. The latter being either the fixed retry interval mode or the increasing retry interval mode. In the latter case, the retry interval doubles for each subsequent retry. • Through the support of the Inactivity Timer package: The purpose of this package 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 control connection failure with that MGC.
• Active Heartbeat mode:
•
The MG checks the connectivity with the MGC at regular time interval by means of the “notify” package. The following modes are supported: - Configured heartbeat interval: The interval by which the “notify” packages are initiated by the MG is provisioned. - Learnt heartbeat interval: The interval by which the “notify” packages are initiated by the MG is learnt from the “Inactivity Timer” package notification of the MGC. The system decides upon a failure of the current control association from the moment 7 subsequent “notify” packages were not replied by the MGC. A “Notify” package is sent on the condition that no other Megaco message is received from the MGC within the learnt/configured heartbeat interval. Passive Heartbeat mode: The MGC checks the connectivity with the MG at regular time interval by means of the “audit” package. The following modes are supported: - Configured heartbeat interval: The interval by which the “audit” packages are initiated by the MGC is provisioned. - Learnt heartbeat interval: The interval by which the “audit” packages are initiated by the MGC is dynamically learnt by the MG. The MG awaits 3 consecutive “audit” packages from the MGC to calculate the heartbeat interval.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-97
12 — ISAM Voice Network Architecture
The system decides upon a failure of the current control association from the moment 8 subsequent heartbeat intervals have passed without receiving neither an “audit” nor a regular Megaco package from the MGC. Megaco ISAM Voice: Network Local-Redundancy
Network Local-Redundancy implies the provisioning, at ISAM Voice side, of:
• either a single Softswitch and a single Application Server Process (ASP). At the network side, both instances of the Softswitch together with both instances of the ASP share the same IP address; see Figure 12-101. • or a single Softswitch and two ASP instances. At the network side, both instances of the Softswitch share the same IP address while each instance of the ASP owns a different IP address which is different form the IP address shared by the Softswitch instances; see Figure 12-102. Figure 12-101 Single Softswitch and single ASP MGC1 Active
ISAM Voice
so
s la
cia
tro
n
8 .24
IP address of MGI IP address of SGI
n
tio
MG/SG co
tion ssocia
H ol a contr SCTP
IP@_1
ASP1 Active IP@_1
H.248 contr ol ass SC ociati TP on co ntr ol as so cia tio n
MGC2 Standby IP@_1
ASP2 Standby IP@_1
Figure 12-102 Single Softswitch and two ASPs MGC1 Active
ISAM Voice on
MG/SG
oc
nt
rol
8 .24
IP address of MGI IP address of SGI
co
s as
i iat
tion ssocia
H ol a contr SCTP
H.248 contr ol ass SC ociati TP on co ntr ol as so cia tio n
IP@_1
ASP1 Active IP@_2
MGC2 Standby IP@_1
ASP2 Standby IP@_3
12-98
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
A Softswitch switch-over is fully transparent to the MG, however it cannot be guaranteed that the same applies to the ASP switch-over. In the latter case, usually the following scenario is followed:
• Upon ASP/SCTP switch-over, the new active SCTP instance initiates an SCTP INIT to the MG.
• Upon the receipt of such SCTP-INIT, the MG starts the recovery timer T(r), does
• • • •
not remove any termination context and starts queuing Q.931 messages for terminations involved in a stable ISDN call (Q.931 messages from terminations involved in calls that have not reached the stable phase are NOT queued). In compliancy to RFC4233, the recovery timer T(r) can be configured to a value in the range 1 - 5 s in the ISAM Voice CDE profile The MG is able to buffer Q.931 messages for up to 564 stable ISDN calls with the restriction that only the most recent Q.931 data message is queued. Upon the receipt of “ASP active” notification, prior to T(r) expiry, all the buffered Q.931 messages are sent to the active ASP. The MG gradually forwards the messages to the new active ASP as to avoid ASP overload. Should the recovery timer expire prior to the receipt of an ASP active notification, then ISAM Voice turns the signaling gateway status to operational down, drops the queued Q.931 messages, removes all ISDN termination contexts and sends Service Change “904” for all ISDN terminations Note — The buffer for queueing SCN messages is not synchronised to the standby Voice Server.
Megaco ISAM Voice: ESA-Redundancy
An ESA Softswitch is to be understood as an MGC that supports a minimum feature set, such that the basic and the emergency call can remain supported in situations of a simultaneous failure of all usual MGCs (primary and secondary). In that respect, it is assumed that the ESA Softswitch functionality is limited to:
• Basic POTS calls (ISDN calls and supplementary services are not supported during ESA mode activation).
• Establishing calls between user ports controlled by the MG(s) that has (have) a control association with the ESA SoftSwitch. • Emergency call. Based on the above, ESA-Redundancy requires the provisioning of at least 2 MGCs with the strict condition that the ESA softswitch must be provisioned as the lowest priority MGC. The provisioning of both, Primary + ESA softswitch and Primary + Secondary + ESA Softswitch is allowed. In case of a failure of the Primary (Primary + ESA) or both simultaneously, Primary and Secondary (Primary + Secondary + ESA) MGC, ISAM-V will make a switch-over to the MGC with the lowest priority potentially allowing for the preservation of stable calls. The possibility to preserve stable calls during a switch-over depends on the capabilities supported by the MGC.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-99
12 — ISAM Voice Network Architecture
The ISAM-V, from a perception of being an MG, does not have any notion about the capabilities of a SoftSwitch being configured as primary, secondary or tertiary MGC. The ISAM-V treats all configured MGCs equally. The ISAM-V assumes that:
• The ESA SoftSwitch accepts “on-hook” notifications for calls that were established in the course of the control association being established between the MG and the Primary / Secondary MGC but finished in the course of the control association being established between the MG and the ESA SoftSwitch. • The ESA SoftSwitch is responsible to “subtract” the contexts for calls that were established in the course of the control association being established between the MG and the Primary / Secondary MGC but finished in the course of the control association being established between the MG and the ESA SoftSwitch. • The ESA SoftSwitch is responsible for the alive monitoring of Primary (and Secondary) MGC when ESA mode being active.
• While the ESA SoftSwitch has an active control relationship with the MG, it will •
continuously monitor both the primary and the secondary MGC by repeating to send a ServiceChange message with method = “FailOver SVC Forced”. Should a reply “ERROR 403 syntax Error” be received from either the Primary or the Secondary MGC, the ESA SoftSwitch will immediately send a ServiceChange message with Method = “HandOff” and [Primary/Secondary MGC] address to the ISAM Voice MG. The capability of the ESA Softswitch to poll only one MGC or multiple MGCs does not have any impact on the ISAM-V in its capacity as MG. This may only influence the time period after which the usual voice service can be resumed.
Control association failure detection and switch-over from Primary/secondary MGC to ESA MGC is identical as described for the GEO-Redundancy. SIP ISAM Voice: SIP Server Redundancy and SIP Server Fail-Over / Fail-Back
SIP Server Redundancy entails the grouping of individual SIP servers that as a group can support the ability for a SIP User Agent in the access node to recover and resume service in spite of a failure of one or multiple of the individual SIP servers. Figure 12-103 SIP Server redundancy L2 / L3 Network
Primary Site
I-CSCF
HSS
ISAM-V
Site connection
P-CSCF 1_1
ISAM-V
12-100
November 2013
S-CSCF
First Hop SIP Server Redundancy
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
The ISAM Voice SIP User Agent supports the interworking with a group of “first hop SIP servers” that form a SIP server redundancy group and whereby all SIP servers get assigned a different priority. The SIP server with the highest priority acts as the primary SIP server, while the rest of the SIP servers act as secondary SIP servers. A “first hop SIP Server” is to be understood as the SIP Server being selected by the SIP User Agent to send the initial REGISTER/INVITE requests. Such SIP server redundancy group consist of a primary and one or multiple secondary SIP servers. A SIP server redundancy group can be provisioned by means of:
• A Domain Name whereby the IP address of the individual SIP servers must be resolved through the Domain Name Service NAPTR, SRV and A resource record look-up, • A list of Fully Qualified Domain Names whereby the IP address of the individual SIP servers must then be resolved through the Domain Name Service A resource record look-up, • A list of IP addresses of the individual SIP Servers. The SIP User Agent triggers autonomously a SIP server Fail-over upon the failure of the actually selected first hop SIP server. A failure is to be understood as a situation where a reply is no longer received for an out-of-dialog SIP request or the receipt of an unsuccessful response code to an out-of-dialog SIP request. In the course of a SIP Server Fail-Over, the SIP terminations that are currently registered via the failing SIP server are moved to another SIP server within the same redundancy group. The SIP server Fail-over trigger default conditions can be customized by means of SIP Service Profile provisioning. Once the failed primary SIP server is back in service, the SIP User Agent triggers autonomously a SIP server Fail-back. In the course of a SIP server Fail-back, the SIP terminations that are currently registered via a secondary SIP server are moved to the primary SIP server within the same redundancy group. The SIP server fail-back is performed gracefully meaning that the SIP User agent triggers a fail-back for a SIP termination from the moment it has the on-hook state. Neither ongoing dialogs nor ongoing transactions are interrupted. Neither for the SIP server Fail-over nor for the SIP server fail-back ongoing dialogs and transactions are transferred to the selected fail-over / fail-back SIP server, and this neither at the signaling plane (SIP) nor at the media plane (RTP). Foreground Service Health Monitoring
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-101
12 — ISAM Voice Network Architecture
Foreground Service Health Monitoring helps the SIP User Agent to rapidly detect whether the currently selected first hop SIP server can still be addressed for new SIP requests. Foreground Service Health Monitoring makes use of either the SIP REGISTER or the SIP OPTIONS Method.
• In case the SIP register method applies, one termination out of the group of terminations re-registers with a configurable high frequent interval (typically 90 s) while the rest of the terminations re-register with the usual frequency. The group of terminations must have the following in common (SIP Termination Group):
• These SIP terminations get the same service route returned upon successful registration
• These SIP terminations addressed the same First Hop SIP server for their initial registration.
• In case the SIP options method applies, the SIP User agent will periodically send (period typically equals 90 s) a SIP options request to the active SIP first hop server. Passive Heartbeat As opposed to Foreground Service Health Monitoring, the main purpose of the Passive Heartbeat is to help the SIP first hop server to rapidly detect whether a SIP user Agent can still be addressed for new SIP requests. When Passive Heartbeat is enabled, the SIP User Agent must reply to the SIP OPTIONS request that is periodically sent by the SIP first hop server. The Passive Heartbeat interval configured at and used by the SIP first hop server can also provisioned at the access node side. By watching the regular receipt of a SIP OPTIONS request from the SIP first hop server, the SIP User Agent is able to detect whether the SIP first hop server is still up and running. Note — The Passive Heartbeat and Foreground Service Health Monitoring methods are mutually exclusive.
Background Service Health Monitoring Background Service Health Monitoring applies to all First Hop SIP Servers being a fail-over candidate SIP server. The SIP user Agent transmits periodically (configurable period) an out-of-dialog OPTIONS message to determine the health status of the fail-over candidate First Hop SIP Server. Having this information in advance helps to reduce the elapse time to perform fail-over and subsequently the establishment of new call sessions. Background Service Health Monitoring makes use of the OPTIONS method. Fail-Over Hysteresis Threshold In order to allow the SIP User Agent to distinguish accidental from persistent error conditions and as such to prevent connection toggling between first hop SIP servers within a redundancy group, a Fail-over Hysteresis Threshold can be configured. 12-102
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
A SIP Server Fail-over is triggered from the moment the amount of error conditions has exceeded the Fail-Over Hysteresis Threshold. Stable Operation Observation Period Stable operation observation intends to observe the stability of the SIP server once this SIP server has resumed service after having failed. Should an observed SIP server remain uninterrupted in-service from the start till the expiry of the (configurable) stable operation observation period, then this SIP server is declared stable and ready to be a fail-over / fail-back candidate SIP server. The stable-operation observation starts from the moment a failed SIP server has resumed operation, detected by the SIP User Agent via the background service health monitoring. Deliberate Update For reason of maintenance activities, a SIP server may be temporarily put out of service. To avoid service interruption, the ISAM-V allows to announce such upcoming activity by an update of the list of SIP servers being part of a redundancy group (DNS zone file, SIP server table). In case such update is recognized by the SIP User Agent and the removed SIP server is a SIP server via which SIP terminations are registered, then the SIP User Agent will trigger a Fail-over to the highest priority SIP Server still present in the list. A Deliberate Update is performed gracefully meaning that the SIP User agent triggers a fail-over for a SIP termination from the moment it has the on-hook state. Neither ongoing dialogs nor ongoing transactions are interrupted. SIP ISAM Voice: GEO Redundancy and GEO Fail-Over / Fail-Back
Geographic redundancy entails the physical distribution of individual SIP servers or SIP server redundancy groups that can support the ability for a SIP User Agent in the access node to recover and resume service in spite of a failure or a catastrophe at a particular physical location.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-103
12 — ISAM Voice Network Architecture Figure 12-104 SIP GEO redundancy L2 / L3 Network
GEO Primary Site
I-CSCF
HSS
ISAM-V
GEO primary site connection
GEO back-up site connection
P-CSCF 1_1
S-CSCF
GEO Back-up Site ISAM-V
GEO redundancy
GEO Back-up Site
I-CSCF
HSS
ISAM-V
GEO primary site connection P-CSCF 1_1
S-CSCF
GEO back-up site connection
GEO Primary Site ISAM-V
The ISAM Voice SIP User Agent supports the interworking with a first hop Geo-redundant SIP server topology. A Geo-redundant SIP server topology can be provisioned by means of:
• The Domain Names of the geo primary and geo back-up site whereby the IP address of the individual SIP servers of these sites must be resolved through the Domain Name Service NAPTR, SRV and A resource record look-up, • A list of Fully Qualified Domain Names for both the geo primary and the geo back-up site whereby the IP address of the individual SIP servers must then be resolved through the Domain Name Service A resource record look-up, • A list of IP addresses of the individual SIP Servers for both the geo primary and the geo back-up site. The SIP User Agent triggers a Geo Fail-Over / Geo Fail-Back upon explicit request of the operator. See the related documents for detailed information and the detailed command definitions for initiating such Geo Fail-Over / Geo Fail-back (ISAM Operations and Maintenance Guide Using CLI). The ISAM-V supports manually triggered GRACEFUL GEO Fail-over / Fail-Back, meaning that a SIP termination is individually moved to the GEO Back-Up / Primary site on the condition that the SIP termination has the call state “on-hook”. For any other call state, the system will defer the GEO Fail-Over for this SIP termination till the call state has become “on-hook”.
12-104
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
The ISAM-V supports manually triggered FORCED GEO Fail-over / Fail-Back, meaning that all ongoing dialogs and transactions are immediately aborted and that all SIP terminations become immediately moved to the GEO Back-up / Primary site (The system does not await the “on-hook” call state of the SIP termination to perform the GEO Fail-over / Fail-Back). Neither in the graceful, nor in the forced GEO Fail-over / Fail-back, ongoing dialogs and transactions are transferred, and this neither at the signaling plane (SIP) nor at the media plane (RTP). SIP ISAM Voice: ESA Redundancy and ESA Fail-Over / Fail-Back
Emergency StandAlone redundancy is considered to be a restrictive redundancy mode of the GEO redundancy. The ESA Primary side has an identical SIP server topology as if it was a Geo Primary side. However, the Back-up side only hosts a single ESA SIP server that locally maintains the subscriber database, consistent with the ESA Primary site IMS provisioning, and that supports a minimum call handling feature set:
• The Basic Call Service. • Special lines can be directly connected to Emergency Offices for Emergency Call • The Billing system is not available Figure 12-105 SIP ESA redundancy L2 / L3 Network
ESAPrimary Site
I-CSCF
HSS
ISAM-V
ESA Primary Site connection
P-CSCF 1_1
S-CSCF
First Hop SIP Server Redundancy
ISAM-V
ESA redundancy
ESA Back-up Site connection
ESA SIP server
The ISAM-V triggers an autonomous ESA Fail-Over at the moment that the connectivity with the ESA Primary Site has completely been lost (none of the First Hop SIP servers at the ESA primary sites are still addressable). A SIP termination is individually moved to the ESA Back-Up site on the condition that the SIP termination is not involved in a stable call. For any other call state, the system will defer the ESA Fail-Over for this SIP termination till the call state has become “on-hook”.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-105
12 — ISAM Voice Network Architecture
The ISAM-V does not support the DNS location service for the ESA Back-up site. The ISAM-V triggers an autonomous ESA Fail-Back at the moment that at least one of the SIP servers located at the ESA Primary Site can again be addressed. A SIP termination is individually moved to the ESA Primary site on the condition that the SIP termination has the call state “on-hook”. For any other call state, the system will defer the ESA Fail-Back for this SIP termination till the call state has become “on-hook”. The ISAM-V does not transfer neither ongoing dialogs nor ongoing transactions to the ESA Primary / Back-up site, and this neither at the signaling plane (SIP) nor at the media plane (RTP). SIP ISAM Voice: NT switch-over interaction with SIP server Redundancy
The Voice LT board monitors the receipt of the Uplink Switch-over notification from the NT. Upon the receipt of this signal, meaning that an NT switch-over was triggered, the LT board starts a 3 minutes “restoration-blocked” timer. While this timer is running, the complete Geo and SIP server Fail-over / Fail-back handling becomes blocked meaning that neither a SIP server Fail-over, nor a SIP server Fail-back, Geo Fail-Over or Geo Fail-back can be triggered and this neither autonomously nor manually. The ISAM-V does not block any out-of-dialog request, any in-dialog request, foreground health service monitoring, background health service health monitoring, DNS look-up request during the period that the “restoration-blocked” timer is running.
Overload Protection Megaco ISAM Voice: MG (ISAM Voice Server) Overload Protection
The overload protection, based on software Watchdog monitoring, as supported by the Voice server aims at guaranteeing self-protection and robustness for the ISAM Voice. Software Watchdog Monitoring The Software Watchdog monitors the system in verifying whether all defined software tasks become scheduled in a reasonable time frame. Should this not be the case anymore, the software Watchdog will trigger a software application-defined call-back function in trying to resolve the actual CPU overload problem. The actions taken by the several software applications depend on these software application policies. The responsibility of the software Watchdog is to detect that there is a problem in the system, not to resolve the problem. The latter aspect is the responsibility of the clients that subscribed to the software Watchdog warnings.
12-106
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
An overload situation is reached when the Voice server runs at 100% of its CPU capacity. In such a situation, the received Megaco packets get a priority treatment; Received Line events (off-hook, on-hook, flash-hook, dialed digits…) run the risk to be ignored. This depends on the robustness level being applicable at that moment:
• Robustness Level 1: reached when the Voice Server remains running at 100% of its CPU capacity during the next 40 seconds.
• 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 too).
• 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 seconds.
• 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 seconds.
• The Voice server initiates a board reset. Outgoing Megaco packets as well as outgoing internal signaling (XLES) packets remain 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 while 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 be below the Low-Water-Mark before it leaves the CPU overload state.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-107
12 — ISAM Voice Network Architecture
The End of Overload Persistency Time is set larger than the Overload Persistency time to ensure that the CPU load is for a sufficient long time below the Low-Water-Mark as not to immediately cause 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 software applications in case of overload detection • Upon being notified of an overload situation, the software 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 ms • Sample 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 SIP ISAM Voice: SIP Overload Handling
Transactions are the main building blocks of the SIP protocol; Each dialog is composed out of a number of independent message exchanges called transactions. A SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and a final response. Limiting the total number of simultaneous active transactions at the LT board level has proven to be an effective way to safeguard the system. By introducing a Maximum Transaction Limit (MaxTx), the LT board becomes protected against consuming all the available system resources when high loads of incoming SIP traffic need to be processed. The MaxTx value is an internal system dimensioning parameter set by ALU in accordance with the engineered capacity of the system. However, if MaxTx Limit is reached, the system does not simply react by gently rejecting all new, incoming, out-of-dialog SIP requests by sending a 503 “Service Unavailable” response including a Retry-After header.
12-108
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
Instead, the following rules were incorporated as a local prioritization policy when applying the MaxTx Limit:
• Requests for ongoing sessions have priority over requests that setup a new session.
• Response messages are not be targeted by overload protection. • Requests that relieve stress from the system are not targeted by overload protection mechanisms
• Outgoing calls/requests are not subjected to MaxTx The following incoming SIP requests are considered “priority” requests:
• • • •
Session refreshes (in-dialog INVITE requests with Session-Expires header) in-dialog requests such as BYE, PRACK, UPDATE and INFO CANCEL requests out-of-dialog OPTIONS requests (typically used for heartbeat/polling)
Figure 12-106 shows the system behavior. Figure 12-106 SIP overload handling Nbr of transactions in use
Zone 3 Total Tx Limit
margin
Zone 2 MaxTx limit
Zone 1
time
• Zone 1: Incoming traffic stays below Max Tx Limit: All incoming SIP requests are accepted • Zone 2: Incoming traffic rises above MaxTx but below Total Tx Limit: All low-priority SIP requests are rejected with a 503 Service Unavailable response; High priority requests are still handled • Zone 3: Incoming traffic reaches Total Tx Limit: No more SIP transactions available in the system; All incoming SIP requests are rejected with a 503 Service Unavailable response
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-109
12 — ISAM Voice Network Architecture
12.13
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.
12.14
DNS interworking Megaco ISAM Voice DNS interworking is not supported for Megaco ISAM Voice.
SIP ISAM Voice The usual Management interface (SNMP, CLI) allows configuring the SIP servers by manual input or for these values to be retrieved through DNS access. In the latter case, either the Domain Name or the Fully Qualified Domain Name (FQDN) must be specified to allow the system to resolve the related IP address by making use of the Domain Name Service.
12-110
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
To resolve Domain names and/or Fully Qualified Domain Names, the ISAM Voice supports the NAPTR, SRV and/or A resource record look-up to recursive Domain Name Servers. ISAM Voice supports DNS server redundancy with configurable DNS server selection mode:
• dns_redun_primary: Multiple DNS servers can be provisioned whereby the DNS Server being provisioned with the highest priority is addressed as the primary DNS server. Any new DNS look-up request gets always sent to the highest priority DNS server irrespective of whether the previous DNS look-up request got replied by the highest priority DNS server or not. Should no reply be received from the primary DNS Server, then the DNS look-up is repeated to the DNS server with the next higher priority in the list. This repeat cycle may be continued till a reply is received from a particular DNS server in the list or the end of the list is reached. Should all Domain Name servers once been queried but without success and the DNS Maximum Number of Retransmissions parameter has been provisioned with a value different from zero, then the ISAM Voice shall again retransmit the DNS look-up to the Name Servers in the list, starting again with the highest priority DNS server. Should still no reply be received from none of the DNS servers in the list, then the re-initiation of the DNS look-up over the complete list will be repeated for as many times as provisioned in the afore mentioned parameter. Upon the maximum number of Retransmissions been handled, an alarm is raised notifying the customer that none of the DNS servers do reply. • dns-redun-successful: Multiple DNS servers can be provisioned, The very first DNS look-up is addressed to the DNS Server being provisioned with the highest priority. Any new DNS look-up request gets sent to the DNS server that successfully replied to the previous DNS look-up request. This DNS server remains addressed for as long as a reply gets received from this DNS server during the initial retransmission interval. However, when no response is received in the initial retransmission interval then the query is repeated to the DNS server with the next higher priority in the list. When no response is received after all provisioned DNS servers have been tried, the above procedure continues for another two retries with an exponentially increasing time-interval. If three DNS servers were configured, and the primary DNS server fails, while the query to the second DNS server gets successfully replied, then the following DNS query will start from the seconds DNS server. But if now the second DNS server also fails, the query will be repeated to the third DNS server. The overall retrying sequence in this loop shall be 2, 3, 1 before giving up. If all three DNS servers fail after three times retransmission, the next loop query shall be trying from the primary DNS server and the trying sequence is 1, 2, 3. To support the Domain Name Service for GEO redundant network topologies, the ISAM Voice allows to provision a separate list of DNS servers for the Geo Primary and the Geo Back-up site. The ISAM Voice caches the retrieved NAPTR, SRV and A resource records for a period equals Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-111
12 — ISAM Voice Network Architecture
{MIN {DNS Purge Time; MIN of [NAPTR,SRV,A] TTL values for a particular DN}} whereby the provisionable DNS Purge Timer allows to limit the TTL value, should some of the resource records own an excessively long TTL value. In order to reduce the call set-up elapse time and/or to reduce the burden on the network, where possible, the DNS Resolver limits the number of DNS queries to a strict minimum. This is achieved by supporting the “additional section” in the DNS server reply.
12.15
BITS Support An accurate synchronization is mandatory for the voice service, especially for voice-band-data services and ISDN services. The NT can be connecting by an external BITS clock or using its integrated BITS module (< 5ppm) to reach a decent voice quality. The NTs without BITS module (50ppm) are not valid and not permitted for voice application.
12.16
Narrowband Line Testing Megaco ISAM Voice See chapter “Line testing features”.
SIP ISAM Voice See chapter “Line testing features”.
12.17
Termination local loop unbundling ISAM Voice with Combo 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 Voice Local loop unbundling is supported.
SIP ISAM Voice Local loop unbundling is supported.
12-112
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
12.18
Alarm Treatment Alarm Definition Megaco Based ISAM Voice
Alarms are defined to warn the customer about:
• • • • • • • • • • • • • • • • • •
A loss of the Control Association with the Media Gateway Controller. A loss of the Control Association with the ASP. A loss of the XLES connection between the Voice server and voice LT board. A mismatch between the planned and the actually equipped voice LT board type. A H.248 subscriber been configured at the ISAM Voice is not known by the Media Gateway Controller. The current threshold of the physical POTS port being exceeded. The temperature threshold of the physical POTS port being exceeded. A L1 activation failure at an ISDN lines. The current threshold of the physical ISDN port being exceeded. (One of the 2 wires is grounded). Line showering. The Voice Server having lost all persistent data after board reset. The Voice Server database storage area at the board being occupied for at least 90%. The Voice Server not being able to activate the most recent downloaded database. Media gateway overload. A Voice Database corruption. An invalid CDE file. The CDE file being missing. A CDE file activation failure due to hash key mismatch.
SIP Based ISAM Voice
Alarms are defined to warn the customer about:
• The Digit Map that is not usable. • A lack of resources that prohibits the Voice LT board from establishing additional • • • • • • • •
calls. The DHCP server that is not reachable. A SIP first hop server that is not reachable. The register server that is not reachable. A SIP subscriber been configured at the ISAM Voice not known by the IMS core network. The current threshold of the physical POTS port being exceeded. (One of the 2 wires is grounded). The temperature threshold of the physical POTS port being exceeded. A SIP Registration request failure due to a domain name being unresolvable. A SIP Registration request failure due to an authentication failure.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-113
12 — ISAM Voice Network Architecture
• • • • • • • • • • • • • • • • •
A SIP Registration request failure due to a transaction timeout. A SIP Registration request failure due to a non-successful response. A SIP Invite request failure due to a domain name being unresolvable. A SIP Invite request failure due to an authentication failure. A SIP Invite request failure due to a transaction timeout. A SIP Invite request failure due to a non-successful response. A SIP Subscribe request failure due to a non-successful response. Jitter Buffer Fill Level TCA threshold being exceeded. A DNS look-up failure. Not any DNS server being configured. None of the SIP first hop servers do still reply. Not any SIP first hop server being configured. A mismatch between the transport protocol(s) actually supported by ISAM Voice and the transport protocol(s) to be used to access a SIP first hop. A Voice Database corruption. An invalid CDE file. The CDE file being missing. A CDE file activation failure due to hash key mismatch.
Subscriber Line Showering Megaco Based ISAM Voice
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, this service change is notified to the Media Gateway Controller and an alarm is raised. This means 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 / 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. SIP Based ISAM Voice
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. No alarm is raised; The system continues to handle the subscriber line being put in showering state as if it was not put in this state.
12-114
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
12.19
Lawful Intercept Overall Lawful Intercept strategy The 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 two voice termination points must be intercepted by an interception point (CCIF and 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 voice network of the customer. 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. Local ISAM Voice RTP traffic switching:
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-115
12 — ISAM Voice Network Architecture
To allow the support of the External Packet Forwarding facility, the RTP traffic will always be switched along the IHub, even if the two voice terminations among which the RTP traffic is to be exchanged are connected to the same voice LT board. Restrictions: 1
The External Packet Forwarding facility is supported on all equipment practices.
2
The External Packet Forwarding facility is supported on the HUB, Subtending and Remote ISAM Voice access nodes.
3
The External Packet Forwarding facility is supported on VLANS of type “Voice-VLAN” and “Residential Bridge”/v-VPLS.
4
The External Packet Forwarding facility supports L2 aggregated network links through static L2 aggregation group configuration.
5
The External Packet Forwarding facility supports L2 aggregated network links through LACP.
6
The External Packet Forwarding facility supports xSTP.
7
The External Packet Forwarding facility is supported for POTS only.
8
The External Packet Forwarding facility is supported in case the ISAM Voice Access node connects directly or by means of (an) intermediate ISAM Voice access node(s) to the external EPF device by means of a L2 switching network.
9
Supporting (enabling) the External Packet Forwarding facility is mutual exclusive to the support (configuration) of the private IP addressing topology (IP Address and IP Subnet reduction topology).
10 The External Packet Forwarding facility shall only be enabled for the VLAN that carries the RTP traffic (might be a vlan sharing both RTP and signaling traffic). 11 The External EPF device must allow to disable the ICMP Redirect facility.
12-116
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture Figure 12-107 Megaco ISAM Voice - Switched device - External Packet Forwarding enabled Main node
Remote node NT board
NT board
Signaling IP address Voice
server XLES IP address Voice LT board
IHub Voice IP address
IHub Voice IP address
Remote node
Subtending node
NT board
Voice LT board
Voice LT board
L2 aggregation network
NT board
L3 aggregation network
IHub Voice IP address
IHub Voice IP address
ASP
MGC
Voice LT board
Edge Router serves as "external device" from where the voice traffic is tapped to the LI device
SoftSwitch
Figure 12-108 Megaco ISAM Voice - Switched device - External Packet Forwarding disabled Main node
Remote node NT board
NT board
Signaling IP address Voice
server XLES IP address Voice LT board
IHub Voice IP address
IHub Voice IP address
L2 aggregation network
Remote node
Subtending node
NT board
Voice LT board
Voice LT board
NT board
L3 aggregation network
IHub Voice IP address
IHub Voice IP address
Voice LT board
ASP
MGC
SoftSwitch
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-117
12 — ISAM Voice Network Architecture
SIP 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 and 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 voice network of the customer. 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 that resides outside the ISAM Voice, must be brought outside of the originating ISAM Voice access node to allow this voice traffic to be tapped to the Lawful Intercept device. To serve such Lawful intercept topology, SIP 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, 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. Local ISAM Voice RTP traffic switching: To allow the support of the External Packet Forwarding facility, the RTP traffic will always be switched along the IHub, even if the 2 voice terminations among which the RTP traffic is to be exchanged are connected to the same voice LT board. This RTP switching model applies to the SIP Centralised Model only. (SIP Distributed model: when RTP traffic is to be exchanged among 2 voice terminations connected to the same voice LT board, the RTP traffic is switched internally at the voice LT board.) Restrictions:
12-118
1
The External Packet Forwarding facility is supported on all equipment practices.
2
The External Packet Forwarding facility is supported on the HUB, Subtending and Remote ISAM Voice access nodes.
3
The External Packet Forwarding facility is supported on VLANS of type “Voice-VLAN” and “Residential Bridge”/v-VPLS.
4
The External Packet Forwarding facility supports L2 aggregated network links through static L2 aggregation group configuration.
5
The External Packet Forwarding facility supports L2 aggregated network links through LACP.
6
The External Packet Forwarding facility supports xSTP.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
7
The External Packet Forwarding facility is supported for POTS only.
8
The External Packet Forwarding facility is supported in case the ISAM Voice Access node connects directly or by means of (an) intermediate ISAM Voice access node(s) to the external EPF device by means of a L2 switching network.
9
Supporting (enabling) the External Packet Forwarding facility is mutual exclusive to the support (configuration) of the private IP addressing topology (IP Address & IP Subnet reduction topology).
10 The External Packet Forwarding facility shall only be enabled for the VLAN that carries the RTP traffic (might be a vlan sharing both RTP and signaling traffic). 11 The External EPF device must allow to disable the ICMP Redirect facility. Figure 12-109 SIP ISAM Voice - Switched device - External Packet Forwarding enabled Main node
Remote node
Voice LT board
NT board
NT board
IHub Voice IP address
IHub Voice IP address
L2 aggregation network
Remote node
Subtending node
NT board
Voice LT board
Voice LT board
NT board
L3 aggregation network
IHub Voice IP address
IHub Voice IP address
ASP
MGC
Voice LT board
Edge Router serves as "external device" from where the voice traffic is tapped to the LI device
SoftSwitch
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-119
12 — ISAM Voice Network Architecture Figure 12-110 SIP ISAM Voice - Switched device - External Packet Forwarding disabled Main node
Remote node
Voice LT board
NT board
NT board
IHub Voice IP address
IHub Voice IP address
L2 aggregation network
Remote node
Subtending node
NT board
Voice LT board
Voice LT board
NT board
L3 aggregation network
IHub Voice IP address
IHub Voice IP address
Voice LT board
ASP
MGC
SoftSwitch
12.20
ISAM Voice migration Off-line Software Migration The 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 IHub databases). This implies that at software 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 software package. Megaco ISAM Voice off-line software migration
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. 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.
12-120
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
In order for the integrated voice service to work correctly, the same software 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 software (maintenance) release on the voice LT boards must be the same as the software (maintenance) release on the Voice server and this for the complete ISAM Voice cluster. The same applies within one ISAM Voice node. Only one software (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 software (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 software (maintenance) release. The above rules imply that for both a software upgrade and a software migration, the upgrade/offline migration procedure for the full upgrade/migration cluster must be completed in a single maintenance window. Figure 12-111 Voice upgrade/migration cluster (centralized topology) Voice Upgrade / Migration Cluster concept in the context of a Centralised Voice Topology.
Upgrade / Migration Cluster Main ISAM Voice Node Voice Server Pair 1
Voice Server Pair 2
Voice Server Pair 3
Voice Server Pair 4
Voice Server Pair 5
Voice Server Pair 6
Voice Server Pair 7
LTs Non-main node 1a
LTs Non-main node 2a
LTs Non-main node 3a
LTs Non-main node 4a
LTs Non-main node 5a
LTs Non-main node 6a
LTs Non-main node 7a
LTs Non-main node 8a
LTs Non-main node 1b
LTs Non-main node 2b
LTs Non-main node 3b
LTs Non-main node 4b
LTs Non-main node 5b
LTs Non-main node 6b
LTs Non-main node 7b
LTs Non-main node 8b
LTs Non-main node 1x
LTs Non-main node 2x
LTs Non-main node 3x
LTs Non-main node 4x
LTs Non-main node 5x
LTs Non-main node 6x
LTs Non-main node 7x
LTs Non-main node 8x
Voice Cluster 1
Voice Cluster 2
Voice Cluster 3
Voice Cluster 4
Voice Cluster 5
Voice Cluster 6
Voice Cluster 7
Voice Cluster 8
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
Voice Server Pair 8
12-121
12 — ISAM Voice Network Architecture Figure 12-112 Voice upgrade/migration cluster (distributed topology) Voice Upgrade / Migration Cluster concept in the context of a Distributed Voice Topology.
Upgrade / Migration Cluster 1
Upgrade / Migration Cluster 2
Upgrade / Migration Cluster 3
Main ISAM Voice Node 1
Main ISAM Voice Node 2
Main ISAM Voice Node 3
Upgrade / Migration Cluster 4 Main ISAM Voice Node 4
Upgrade / Migration Cluster 5 Main ISAM Voice Node 5
Upgrade / Migration Cluster 6 Main ISAM Voice Node 6
Upgrade / Migration Cluster 7 Main ISAM Voice Node 7
Upgrade / Migration Cluster 8 Main ISAM Voice Node 8
Voice Server Pair
Voice Server Pair
Voice Server Pair
Voice Server Pair
Voice Server Pair
Voice Server Pair
Voice Server Pair
Voice Server Pair
LTs Non -main node 1a
LTs Non -main node 2a
LTs Non -main node 3a
LTs Non -main node 4a
LTs Non -main node 5a
LTs Non -main node 6a
LTs Non -main node 7a
LTs Non -main node 8a
LTs Non -main node 1b
LTs Non -main node 2b
LTs Non -main node 3b
LTs Non -main node 4b
LTs Non -main node 5b
LTs Non -main node 6b
LTs Non -main node 7b
LTs Non -main node 8b
LTs Non -main node 1x
LTs Non -main node 2x
LTs Non -main node 3x
LTs Non -main node 4x
LTs Non -main node 5x
LTs Non -main node 6x
LTs Non -main node 7x
LTs Non -main node 8x
Voice Cluster 1
Voice Cluster 2
Voice Cluster 3
Voice Cluster 4
Voice Cluster 5
Voice Cluster 6
Voice Cluster 7
Voice Cluster 8
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. That is, both the R4.0v maintenance releases and the R4.1v releases (main and maintenance) will take into account backwards compatibility 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 (for example, R4.0v and R4.0.02c), starting from R4.0v onwards • Between 2 releases of 2 consecutive release streams (for example, R4.0.03d and R4.1.02c), starting from R4.0v onwards • From the xVPS pair to the voice boards, that is, it is assumed the voice boards are always at a lower or equal release then the xVPS pair, but never at a higher release 12-122
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
12 — ISAM Voice Network Architecture
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 weeks Failing to do so will not only block any roll-out of new services in the network of the customer, 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 software 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 Migration ISAM 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 software upgrade or an off-line software 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
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
12-123
12 — ISAM Voice Network Architecture
8
Reload the voice LT board with the SIP software 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 Migration ISAM Voice allows a voice access node being deployed in a switched mode, to migrate to a routed mode. The switching to routing functional migration applies to an ISAM Voice access node deployed in SIP mode. The following restrictions apply:
• It is not allowed that such a Switching to Routing functional migration coincides with either a software upgrade or an off-line software migration.
• ISAM Voice does not support the functional migration of a subtending access • • • •
node. In other words, the subtending access node remains at all times behaving as switched devices. The same Signaling VLAN ID remains used at the IACM part of the ISAM Voice before and after the migration from “switching” 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” to “routing” device. The same source / destination Signaling IP address remains configured at the IHub. The same source / destination RTP IP address remains configured at the IHub.
The main logical steps to be taken in the switching to routing functional migration are:
12-124
1
Configure the routing protocol (OSPF / RIP)
2
Optional: Configure the static routes
3
(re-)Configure L2/L3 topology to run in route mode.
4
Reset the NT pair.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
13 — DPoE Network Architecture
13.1 Introduction 13.2 Overview
13-2 13-2
13.3 Alcatel-Lucent DPoE network architecture 13.4 DPoE implementation of ISAM
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
13-3
13-6
November 2013
13-1
13 — DPoE Network Architecture
13.1
Introduction This chapter provides a general description of the Alcatel-Lucent DPoE network architecture used for ISAM in North America.
13.2
Overview DOCSIS Provisioning of Ethernet Passive Optical Network, named as DPoE, is a set of Cable Television Laboratory specifications that implement the DOCSIS service layer interface on existing Ethernet PON (EPON or 10G-EPON) Media Access Control (MAC) and Physical layer (PHY) standards. The advantage of DPoE is to preserve and leverage the DOCSIS back-office investments for MSOs migrating access network technology from Hybrid Fiber Cable (HFC) to Fiber to the Home (FTTH) or Fiber to the Premises (FTTP). This feature implements the DOCSIS Operations, Administration, Maintenance, and Provisioning (OAMP) functionality on existing EPON equipment in order to re-use existing DOCSIS Operations Support System Infrastructure (OSSI). The EPON OLT will act like a DOCSIS Cable Modem Termination Systems (CMTS) platform, while the EPON OLT and EPON ONT will work together like virtual Cable Modem (vCM). The DPoE system refers to all the elements that provide the DPoE function with the operator's network facilities. It includes the EPON OLT function, DOCSIS service function, forwarding and routing functions, management function, and so on. In addition to offering the same IP service capabilities as a CMTS, the DPoE system supports Metro Ethernet Forum (MEF) services for the delivery of Ethernet services for FTTP business customers. Figure 13-1 shows the DPoE network reference architecture.
13-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
13 — DPoE Network Architecture Figure 13-1 DPoE Network reference architecture DOCSIS Network IPv4/v6 CPE
SNMP server
CM IPv4/v6 CPE
Syslog server DHCPv4/v6 server
CMTS
TFTP server
IPv4/v6 CPE CM
SNTP server
IPv4/v6 CPE
OSS Infrastructure
HFC
Customer Premise Network
DPoE Network DPoE System SNMP server
DPoE ONT
vCM
Syslog server DHCPv4/v6 server
OSS Infrastructure
IPv4/v6 CPE
CMTS
TFTP server SNTP server
IPv4/v6 CPE
DPoE ONT
vCM
PON
IPv4/v6 CPE IPv4/v6 CPE Customer Premise Network 23659
In comparison with a traditional EPON deployment model, major differentiations for DPoE are as follows:
• Each DPoE ONT shall be assigned a unique IP address and managed as a separate management element, just like a virtual Cable Modem (vCM) residing on the EPON OLT, as the DPoE specifications were designed to support an existing market of ONUs that do not contain an IP stack. • The DPoE ONT relevant configuration is maintained by OSSI instead of the DPoE system. Once the DPoE ONT completes each registration, the DPoE system needs to download the configuration profile from an external TFTP server on behalf of the ONT before provisioning the DPoE system and DPoE ONT based on the parsing information. • The DPoE system provides management capabilities on behalf of the ONU for all IP-based management functions. When the DPoE system receives management requests for a vCM, it converts those requests into the appropriate DPoE OAM and relays them to the DPoE ONU as needed.
13.3
Alcatel-Lucent DPoE network architecture The Alcatel-Lucent DPoE network architecture almost matches the reference model defined in the DPoE architecture specification. The DPoE system role is taken by the FANT-F and FPLT-A cards on the 7360 FX platform. Only symmetric 1G EPON is currently supported.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
13-3
13 — DPoE Network Architecture
Figure 13-2 shows the ISAM DPoE network architecture. Figure 13-2 ISAM DPoE network architecture DPoE-SP-IPNEv1.0 SSH/Telnet TACACS* RADIUS HTTP NTP FTP/SFTP TFTP RSH SNMP
External eSAFE SNMP
DOCSIS 3.0 Equivalent IP Service eSAFE SNMP eSAFE EVCs
External eSAFE EVCs
DPoE Standalone ONU IEEE 802.1 Switch WiFi eDVA DPoE-SP-OAMv1.0 EPON OAM + EPON OAM Extensions
DPoE-SP-OSSIv1.0 OSSI SNMP
eRouter WiFi sDVA
DPoE-SP-PHYv1.0 ODN
OSS
DEMARC ONU
DPoE System
IP/Transport R Network R
DEMARC
R OLT
R/X DPoE Bridge ONU
DEMARC DEMARC
ONU DPoE-SP-IPNEv1.0
IEEE 802.1 Switch
Routing ARP IS-IS OSPF MP-BGP
IEEE 802.3 (EPON) DPoE-SP-MEFv1.0
FANT-F
FPLT-A
SFU
SFP-ONU
MEF EVCs 23660
As shown in Figure 13-2, the term DPoE standalone ONU refers to the DPoE ONU that provides the full functionality of all of the DPoE specifications without the need of an external device. In ISAM DPoE network architecture, it always refers to an SFU with one or two Ethernet interfaces. The embedded DOCSIS facilities such as WiFi, eVDA and eRouter, are not currently supported.
13-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
13 — DPoE Network Architecture
The term DPoE bridge ONU refers to another type of DPoE ONU that does not implement the full functionality defined in DPoE specification without assistance from an external device. In general, this type of DPoE ONU must have at least one subscriber interface that passes traffic transparently without any VLAN manipulation at all. In ISAM DPoE network architecture, the term DPoE bridge ONU always refers to the SFP-ONU. The term DEMARC (Demarcation Device) refers to the device that is owned and operated by the operator that provides the demarcation (sometimes called the UNI interface) to the customer. Sometimes this device is referred to as a CPE in DSL or Broadband Forum. Although the DPoE network does not cover this device, it is sometimes required by a bridge ONU to provide MEF services.
Standards The Alcatel-Lucent DPoE network is developed based on the following standards:
• Cablelabs DPoE 1.0 specifications: • architecture specification: DPoE-SP-ARCH v1.0-I01-110225 • OAM extensions specification: DPoE-SP-OAM v1.0-I05-130328 • physical layer specification: DPoE-SP-PHY v1.0-I03-130328 • security and certificate specification: DPoE-SP-SEC v1.0-I03-130328 • IP network element requirements: DPoE-SP-IPNE v1.0-I05-130328 • MAC and upper layer protocols requirements: DPoE-SP-MULPI v1.0-I05-130328 • metro ethernet forum specification: DPoE-SP-MEF v1.0-I03-120830 • operations and support system interface specification: DPoE-SP-OSSI v1.0-I04-130328
• Data-over-cable service interface 3.0 specifications: • MAC and upper layer protocols interface specification: CM-SP-MULPI v3.0-I17-111117
• layer 2 virtual private networks: CM-SP-L2VPN-I09-100611 • operations support system interface specification: CM-SP-OSSI v3.0-I20-121113 • CableLabs' DHCP options registry: CL-SP-CANN-DHCP Reg-I09-120809 • IEEE 802.3ah-2004 (Amendment: media access control parameters, physical layers and management parameters for subscriber access networks)
• IEEE 802.3-2005 (Carrier sense multiple access with collision detection access method and physical layer specifications) • IEEE 802.1ad-2005 (Amendment 4: provider bridges, May 2006 standard for local and metropolitan area networks virtual bridged local area networks)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
13-5
13 — DPoE Network Architecture
13.4
DPoE implementation of ISAM As a convergence platform, the 7360 ISAM FX supports mixed deployment for several kinds of access technologies such as xDSL, Ethernet, Voice, GPON, traditional 1G EPON, 10G EPON, and now DPoE. The management model for the DPoE and traditional 1G-EPON is totally different though they share same 1G EPON line card (FPLT-A). Currently, these two management models are segregated per slot which means that they are mutually exclusive for one given FPLT-A card during deployment. A third management mode for the FPLT-A card currently supports business services in the MSO market. This mode uses a similar management model as with traditional 1G EPON, but utilizes the DPoE specified OAM requirements instead of those for traditional 1G EPON to interoperate with existing DPoE ONUs owned by other vendors. The management modes for the FPLT-A card are determined during card planning using different configuration profile names, as follows:
• EPON: default mode, managed using the traditional 1G EPON management model • DPoE: managed using the traditional 1G EPON management model with DPoE specified OAM • DOCSIS: managed using the DOCSIS management model
Management interface The Command Line Interface (CLI) is the most popular management interface used for existing DOCSIS systems. The ISAM DPoE system provides the CLI required to manage CMTS over a serial port terminal or IP using Telnet or SSH2. Though not required from the vCM view, the CLI is still mandatory for monitoring the vCM registration process and working states from a CMTS perspective. The SNMP protocol is the primary communication protocol for management of existing DOCSIS services. The ISAM DPoE system not only provides an SNMP agent to access the DPoE system MIBs, but also provides an SNMP agent to access the vCM MIBs on behalf of each attached ONU. Each vCM appears as a separate management entity to external management applications and responds to management requests using the IP connection, which is established during the DPoE ONU registration. Unlike the current behavior of ISAM, most of the time the SNMP access to the vCM is used to query the working status and configuration of the vCM instead of for provisioning. Provisioning is accomplished using the vCM configuration file on an external TFTP server. Operators may control the vCM directly by setting the vCM MIB, for example, such as restarting vCM, setting event report thresholds, and so on. As mentioned in the IPNE specification, the DOCSIS specifications do not describe the configuration of the CMTS, and so then DPoE specifications follow same principle. The CMTS MIB specified in the DOCSIS and the DPoE specifications are allowed as well as the vendor proprietary MIB for CMTS provisioning as a supplementation. The Alcatel-Lucent proprietary MIB is managed by the Alcatel-Lucent management system (AMS), which is not currently integrated with the CMTS OSSI of MSOs.
13-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
13 — DPoE Network Architecture
Figure 13-3 shows the ISAM DPoE management model. Figure 13-3 ISAM DPoE management model ALU proprietary MIB
AMS NOT integrated yet CMTS OSS
DPoE SYSTEM CLI Agent CMTS
CMTS MIB defined by DPoE OSSI specification
SNMP Agent manage vCM
vCM
vCM
SNMP Agent
SNMP Agent
SNMP Agent
mapping CM OSS
mapping
mapping
vCM MIB defined by DPoE specification DPoE ONT CM OSS
CM OSS
DPoE ONT DPoE ONT 23661
Service model The ISAM DPoE system supports the following two typical service modes that are defined in the DPoE specification v1.0:
• MEF service mode • IP (HSD) service mode Metro Ethernet Forum (MEF) The ISAM only supports E-line MEF service, which looks like a transparent bit pipe across a DPoE ONU and ISAM. Just like traditional EPON, a user to user communication between two MEF UNIs is not allowed in ISAM. The DPoE specification defines the following two types of encapsulation modes for MEF service:
• 802.1ad provider bridging • 802.1ah provider backbone bridging (not currently supported) Figure 13-4 shows the ISAM DPoE MEF forwarding model.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
13-7
13 — DPoE Network Architecture Figure 13-4 ISAM DPoE MEF forwarding model EVC FANT-F
FPLT-A
DPoE ONU 1
encapsulation mode
transport mode DPoE ONU 2
DEMARC
EVC Legend: MEF UNI MEF INNI 23662
In the case of the user interface acting as a MEF UNI (named as 'encapsulation mode' in DPoE MEF specification), the DPoE ONU encapsulates the customer upstream frames based on classification with one S-VLAN, which is designated by the vCM configuration file. In the downstream direction, the DPoE ONU does the opposite and strips the S-VLAN before forwarding the frames to the customer. Since there is no ability to encapsulate and de-encapsulate, the user interface on a bridged ONU will not work as a MEF UNI forever. In the case of the MEF UNI role taken by DEMARC (named as the 'transport mode' in the DPoE MEF specification), the DPoE ONU only passes customer frames transparently without any VLAN operation in both upstream and downstream directions. Here the user interface on the ONU looks like a MEF INNI. The encapsulation mode of a user interface is determined by the DOCSIS L2 VPN TLV in the vCM configuration file. The TLV also guides how to handle L2CP frames within a given EVC. Once the option to transmit L2CP is enabled, all of the L2CP frames will be mapped into an EVC just like another frames beside PAUSE, which will be discarded silently. The MEF service parameters such as classification criteria, bandwidth allocation, scheduling mechanism, and so on, are provided in the vCM configuration file. They are provisioned almost automatically by the DPoE system except for the network interfaces. Since the TLV is not defined in the DPoE specification to specify which network interface to forward MEF services to, as in the case of multiple network interfaces existing in the DPoE system, the operator must specify the correct network interface. Figure 13-5 shows the ISAM DPoE MEF service realization.
13-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
13 — DPoE Network Architecture Figure 13-5 ISAM DPoE MEF service realization
FANT-F
FPLT-A LLID
TC
FANT-F V-VPLS
provision manually
DPoE ONU
FPLT-A S-VLAN
SF SF
TC
DPoE ONU LLID
TC
provision automatically according to TLVs in CM configuration file
Legend: MEF UNI MEF INNI 23663
In terms of DPoE, each MEF service is classified to a separated service flow (SF) in each direction. Both service flows are further mapped to a unique LLID over a PON interface. Currently, the DPoE ONU only supports 8 LLIDs at maximum. This means that only 8 MEF services are allowed for a bridged ONU even if the DEMARC is equipped with more than 8 user interfaces.
IP service The DOCSIS IP services are delivered “over the top” of virtual Ethernet services. The Ethernet tags used for an IP(HSD) service can not be exposed to service customer interfaces. In other words, the encapsulation for IP(HSD) forwarding is performed in the DPoE ONU after the customer interface is in the ingress direction, and vice-versa for de-encapsulation. In the general terms of L2 forwarding, the customer interface provisioned for IP(HSD) works using the untagged mode, it receives only untagged frames in the upstream direction, and transmits untagged frames in downstream direction. Since there is no ability to encapsulate and de-encapsulate, the bridged ONU does not support IP(HSD). Therefore the IP(HSD) service is only relevant to the standalone ONU in practice. The IP(HSD) forwarding model uses MEF EVCs from a “soft” UNI interface which are connected to the IP router interface (the default router). The IP(HSD) EVCs are implemented with PB [802.1ad] model, where the service interface is assigned a unique S-VLAN ID and C-VLAN ID pair by the DPoE system instead of the vCM configuration file. Each S-VLAN carries a set of C-VLANs with their respective EVCs and terminates at a forwarding interface that is facing the IP router interface. In this way, each S-VLAN belongs to only one IP subnet, which is called an IP serving group (IP-SG), in DPoE terms. Figure 13-6 shows the ISAM DPoE IP (HSD) forwarding model.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
13-9
13 — DPoE Network Architecture Figure 13-6 ISAM DPoE IP (HSD) forwarding model EVC
DHCP relay IP-SG 3
IP-SG 1
IES/ VPRN DHCP relay
IP-SG 2
FPLT-A DPoE ONU 1 S1+C1
untag
DPoE ONU 2 S1+C2
untag
DPoE ONU 3 S2+C1
untag
DPoE ONU 4 S2+C2
untag
Legend: MEF UNI MEF INNI IP Interface 23664
In the DPoE specification, each IP-SG may consist of more than one S-VLAN. Unlike a MEF service, the S-VLAN for an IP(HSD) service is assigned by the DPoE system instead of the vCM configuration file. In general, the DPoE system reserves a list of S-VLANs for each IP-SG, which is bound to one PON, or to more than one PON interface (or bundle). As the DPoE ONU registration completes, the DPoE system selects from the S-VLAN list of IP-SGs, from the PON, or the bundle of the connecting ONU, and then allocates an arbitrary C-VLAN within that S-VLAN. The DPoE ONU encapsulates in the upstream direction with an S-VLAN and C-VLAN pair, and removes both of them in downstream direction. Since there is no ability of inserting an S-VLAN and C-VLAN for some existing DPoE ONUs, the ISAM DPoE system currently requires this type of ONU to pass through an untagged IP service over a PON interface in both directions. As a result, the DPoE system has to insert and remove the S-VLAN and C-VLAN on its own. This behavior is not compatible with the DPoE specification, and will be corrected in a future release once the standard DPoE ONU completed. Figure 13-7 shows the ISAM DPoE IP (HSD) management entities.
13-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
13 — DPoE Network Architecture Figure 13-7 ISAM DPoE IP (HSD) management entities
ISAM does not support binding IP-SG with PON directly in order to simplify provisioning. Here not fully line up with DPoE specification actually
IPSubnet 1 belong to 0..1 1 IP-SG 1 belong to 0..1 BUNDLE 1 include 0..n PON
has
0..1
include
1
DHCP relay agent
1..n
S-VLAN 1 include 1..n C-VLAN
Designed by operator
Allocated by DPoE system automatically
23665
Apart from the MEF service, the IP(HSD) service needs more pre-configuration in the DPoE system. Besides the EVC S-VLAN, it is also the responsibility of operators to provide information about the IP forwarding interface, routing, DHCP relay agent, and so on, before a DPoE ONU registration. Figure 13-8 shows the ISAM DPoE IP (HSD) service realization. Figure 13-8 ISAM DPoE IP (HSD) service realization
FANT-F
FPLT-A
IES/VPRN
TC
FANT-F
FPLT-A
IES/VPRN provision manually Legend:
VPLS
DPoE ONU LLID
SF SF
TC
DPoE ONU
S+C-VLAN LLID
TC
Besides S-VLAN and CVLAN, other parameters required for EVC are provision automatically according to TLVs in CM configuration file
MEF UNI MEF INNI IP Interface 23666
As the first point of entry of a subscriber to the network and the only point with physical connectivity, some security features need to be enforced by the DPoE system. Each IP-SG facing a user interface has a DHCP relay agent with option 82 insertion. Each relay agent listens to the DHCP client messages being broadcast on the subnet from the CPE behind an IP service interface, and relays them to a configured DHCP server, which may reside on a different network or subnet from
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
13-11
13 — DPoE Network Architecture
the CPEs. The DPoE system also supports subscriber identification insertion using the DHCP option 82, not only for security reasons, but also for advanced QoS reasons. For example, the access loop sync rate and inter-leaving delay is important information to be reported by the access node. The Broadband Network Gateway (BNG) will use it to enable policy decisions and advanced QoS functionalities. Currently, the ISAM router component does not support a SAP on top of an S-VLAN and C-VLAN pair so that the forwarding interface in FIB will only include a single VLAN, which will result in incorrect forwarding behavior in the downstream direction. This is why a residential bridge (VPLS) is introduced to terminate the EVC of an IP(HSD) service. As a broadcast domain however, the residential bridge may bring security issues particularly for an ARP request. Therefore, DHCP snooping and ARP relays are provided by the ISAM DPoE system. DHCP snooping functionality is provided in order to learn the subscriber's IP address on a particular user port. The ARP relay transmits the ARP request in the downstream direction to a particular user port based directly on the snooping table lookup result instead of broadcasting over a PON. In the upstream direction, the ISAM DPoE will also provide an IP anti-spoofing feature, but it is not currently supported. The ISAM DPoE system supports most standard routing protocols for an IP (HSD) service such as RIP, OSPF, BGP, IS-IS, and so on, which are inherited from the converged platform.
Multicast service The ISAM DPoE system does not support multicast service since it is not required by the DPoE specification v1.0.
ONU initialization As with a traditional EPON, the ISAM DPoE ONU is not allowed to transmit until it is discovered, ranged, registered, and granted for access by the DPoE system. The ISAM DPoE system will not configure a DPoE ONU or enable services until the authentication and encryption procedures have been completed successfully. Every time a DPoE ONU is powered on, it is required to go through almost the same initialization process as specified in the 802.3ah standard for 1G EPON, besides the authentication method. The ISAM DPoE system uses the X.509 certificate based authentication functionally, which is equivalent to the DOCSIS specification. The certificate is transported using EAP-TLS, as defined in [RFC 5216], over the EAPOL framework defined in [802.1x]. Once the DPoE ONU is authenticated, the DPoE system is to obtain an IP address, on behalf of the ONU, from an external DHCP server. Upon successful establishment of IP connectivity, the DPoE system obtains the vCM configuration file from the external TFTP server. Once the configuration file is validated, the DPoE system initiates the registration and service provisioning process.
Software management The ISAM DPoE software management is comprised of the following two parts:
• DPoE system • DPoE ONU firmware
13-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
13 — DPoE Network Architecture
As part of the converged platform, the DPoE system follows same process to manage its software. The ISAM DPoE system stores two software images in persistent storage, which does not fully comply with the DPoE specification which requires storing the active software that is currently running and at least two other versions of this software. The mechanism to roll-back or move back to the DPoE system software for the previous version and download new versions for software upgrades does however fully line up with existing ISAM behavior. Apart from traditional EPON, the DPoE ONU utilizes a completely different software upgrade approach, which it inherits from the DOCSIS network. Once the DPoE ONU firmware name given by the TLV9 in the vCM configuration file (which is downloaded from the TFTP server during DPoE ONU registration) is different from the currently active one, the DPoE system will start the ONU firmware upgrade. The dedicated TLV21 in the vCM configuration file indicates where to fetch the DPoE ONU firmware. If this information is not provided explicitly in the vCM configuration file, the DPoE system will download the new firmware from the TFTP server where the vCM configuration file resides on behalf of the DPoE ONU. Once the new firmware download is verified and complete, the DPoE system will transfer it to the corresponding DPoE ONU and then activate it by restarting the ONU.
Configuration management The ISAM stores the DPoE system related configuration periodically, or by the explicit control of the operator, and recovers it after a system initialization. Like traditional EPON, the ISAM DPoE can backup and restore the DPoE system configuration to or from an Alcatel-Lucent management workstation instead of a DOCSIS OSSI. The ISAM does not store the vCM configuration file related data. According to the responsibility split in the service realization diagrams of the service model section, those parameters configured by an operator manually still need to be synchronized into the persistent storage, and restored vice versa. Unlike a traditional EPON, the DPoE ONU does not support dynamic configuration change. Even for a minor modification in the vCM configuration file for a DPoE ONU, it will not take effect in the DPoE system in real time unless the ONU is restarted by the back office system. The ISAM DPoE system supports online migration only.
Event management The ISAM DPoE supports the DPoE relevant events defined in the DOCSIS OSSI v3.0 specification for trouble-shooting purposes. Both the CMTS and the vCM can generate events. Specifically, they can generate the same event under some circumstances such as a permanent authorization failure.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
13-13
13 — DPoE Network Architecture
Each event has a corresponding level and a reporting mode. The ISAM DPoE supports the following reporting modes:
• SNMP trap: a CMTS and a vCM may have a separate trap server. The trap server for a CMTS is assigned by an operator using CLI or SNMP, while the server for a vCM is provided in the vCM configuration file. They may have a separate event reporting controller that decides which level's events are to be generated. • Syslog: a CMTS and a vCM may have a separate syslog server. The syslog server for a CMTS is assigned by an operator using CLI or SNMP, while the server for a vCM is provided in the DHCP option 7 while establishing an IP connection, or set by SNMP aimed at this vCM. • Non-volatile local log: exists even after resetting a CMTS or a vCM • Volatile local log: disappears after resetting a CMTS or a vCM
System redundancy Currently, the ISAM DPoE system only supports equipment level redundancy, and never synchronizes a DPoE ONU registration running time status to the standby system. As an NT switch-over happens, the DPoE system must restart all the registered DPoE ONUs and make them re-register again.
System security The ISAM DPoE supports subscriber data privacy including DPoE ONU authentication and key exchanges required to ensure data path encryption for subscriber data. Different from traditional EPON which uses triple churning to encrypt downstream, the only cipher used by DPoE is AES-128. Not like DOCISIS which private/public key cryptography taken from X.509 certificate is used for securely exchange keys, the DPoE system uses either DPoE OAM for 1G-EPON or MKA defined in 802.1x for 10G-EPON to exchange keys. The ISAM DPoE system also protects the provider's network against theft of service, and denial of service (DoS). Secure provisioning is an important aspect to protect the DPoE system and ONU against attack and prevent DoS. This includes:
• mandatory encryption for the downstream direction per LLID with optional encryption for the upstream direction
• mandatory encryption of all control messages excluding those for PON discovery • • • •
13-14
and initial authentication used to establish encryption secure download of DPoE firmware and vCM configuration profiles limitation of MAC address learning capacity per DPoE ONU interface broadcast traffic suppression for IP(HSD) such as ARP MAC addresses bound to specific DPoE ONU interfaces. This is implemented by an Access Control List (ACL) using a TLV60 designated in a vCM configuration file.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
14.1 Introduction 14.2 Coverage
14-2 14-2
14.3 MEGACO Feature Portfolio 14.4 SIP Feature Portfolio
14-3
14-9
14.5 Validating Origin of SIP request
14-28
14.6 Voice Service related defined alarms 14.7 Compliancy to standards
14-29
14-31
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-1
14 — Integrated Narrowband Support
14.1
Introduction The integrated VoIP service provides classic telephony services to subscribers being connected with classic POTS/ISDN BRI lines, and to convert the corresponding signals to VoIP signaling/data packets. 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 device. 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. The integrated VoIP Service supports both signaling methods and can be deployed in the corresponding network topologies. Note 1 — Voice over Broadband (VoBB) is not in the scope of this
chapter Note 2 — The “ISAM Voice Network Architecture” chapter describes the behavior and characteristics of the POTS/ ISDN ports associated with the Alcatel-Lucent access devices offering the integrated voice service.
14.2
Coverage The following chapters summarizes the VoIP service features supported by the different Alcatel-Lucent Voice access products: 7302 ISAM-V, 7353 2U-MDU, RGW and ONT. It is the aim to offer the customer a common feature set and common voice end-user experience at all Alcatel-Lucent access products offering the integrated VoIP service. Nevertheless, slight differences in product roadmaps and product's feature prioritization might result in deviations from the listed feature set and external behavior. Please contact the responsible Alcatel-Lucent Copper /Fiber Product Units for further details.
14-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
14.3
MEGACO Feature Portfolio Registration The Voice Server acting as Media Gateway (MG) announces its existence to the Media Gateway Controller by means of a registration (Service Change) command. This registration instantiates a control association between MG and Media Gateway Controller (MGC). The Voice Server notifies the MGC that a termination or group of terminations is about to be taken out of service or has just been returned to service. A situation where such notification is to be done simultaneously for multiple terminations might create an overload situation at the MGC. To guarantee that all terminations are “registered” at the MGC with the correct state, the Voice Server invokes the termination-state-notify recovery procedure that verifies the termination state at periodic time interval and that initiates “state change” retries when necessary.
Basic Call • Analogue Z interface. • Line feeding • Symmetrical programmable ringing • Metering tone insertion • Polarity reversal • Programmable line impedance with echo cancellation. • Overvoltage protection • Integrated Narrowband Line Test facility • Digit collection by detecting either DTMF tones or pulse dialing. • FSK/DTMF (provisionable per subscriber 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). • Echo cancellation: • Voice, low speed voice band data, fax (per subscriber line) • In compliancy to G.168 • High-speed data transmission: with echo tail length up to 16ms • Silence suppression: • Detection of silence descriptors in the bearer channel • Voice Activity Detection • Transmission of comfort noise to (near-end) customer interface when silence suppression is activated at the far end packet voice transmitter
• 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 Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-3
14 — Integrated Narrowband Support
• Configurable ephemeral termination ID range. • Audit of ephemeral termination with support of the wildcard *. • 2 dial plans / digit maps provisionable in the CDE profile. (max size of each dial plan / digit map = 4 kB).
• S (Short Timer), T (Start Timer) and L (Long Timer) • Capability to store up to 512 (basic call)+51 (emergency call) dial plans (1 dial plan/call; downloaded by the MGC). (maximum size dial plan = 4 kB).
• T.38 Fax • Softswitch is responsible of voice/T.38 call control and charging. • Fax over IP according in compliancy to ITU-T Rec. T.38 • Between 2 Group 3 facsimile terminals. • UDP transport. • 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 depending on network situation. • ISDN: Support of T.38 MGC Transitioning method. (T.38 Autonomous transitioning method is NOT supported.)
• T30 Fax/Modem, requiring full control at the MGC: • Detected tones reported to MGC • Switch to VBD mode upon receipt of MGC command. • ISDN: T.38 FAXoIP: T.38 MGC Transitioning method • • • • • • • •
• • •
14-4
(T.38 Autonomous Transitioning method is NOT supported) Transparent modem/fax service (v.150 VBD mode). Capability to detect fax/modem tones from network side or local side. In-band tones in compliancy to RFC 2833. “In-band tone detection” of fax/modem/text tones from remote side (voice band codecs, commonly G.711, etc.), which serves as both a VBD stimulus and a coordination technique to guarantee autonomous behavior. In-band fax/modem tones trigger integrated VoIP service to switch to VBD mode. For H.248, only tone detected from local side will be reported to MGC in case of T30/modem full control by MGC. Support of the reception of all RFC4734 NTE events, allowing to swap to VBD. 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 however by causing some density decrease (Density of 48-lines voice LT board becomes 40 instead of 48). IP-side in-band tone detection can be turned off via CDE Profile. Fax: V.21, V.17, V.27ter, V.29, V.34 Modem (or text phone): 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. Support of reverse polarity as a (configurable) pulse type as well as 12k/16kHz metering pulses in the amet package.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
• Public Pay phone (reverse polarity) • Line Polarity Reverse at answer. (H.248: driven by CDE profile input and MGC command input)
• 12 /16 Khz Metering (1 TR 110 - 1) for POTS lines connected to public coin boxes and pay phones.
• • • • • •
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
• Payload format 'audio/telephone_event' and associated dynamic payload type number. • Reduce power feed in case the subscriber line is detected to be in Off-Hook state for a longer time period without being involved in a call; provisionable delay to enter reduced power feed state. • Termination of the ISDN BRI U interface (ITU G.961).
• 2B1Q encoding • 4B3T encoding • Q921 protocol termination. • Q931 protocol relay via SIGTRAN. • CODECs: • G.711 A/u law (10ms, 20ms, 30ms), G.729AB (10ms, 20ms, 30ms, 40ms, 50ms, 60 ms), G.723.1 (20ms 30ms), T.38, RFC2833
• Packet loss concealment capability for G.711 • End-to-End codec negotiation at call set-up. In case codec information is absent, the system shall use the default codec settings: G.711 with 20ms packetization interval.
• RTCP: • SR, RR, SDES and BYE supported • The deterministic calculated interval Td is set to 5 s. • No support for RTP session membership • ISDN: Test based formatted ISDN IUA Interface identifier. • Jitter Buffer monitoring on a per subscriber line. • Support of following packages H248.2, H248.3, H248.8, H248.11, H248.14, H248.16, H248.23, H248.26, H248.27, H248.34, H248.45. For further details about full or partial compliancy with these standards, please contact the Alcatel-Lucent Product Unit. • Configurable DSCP & 802.1p bit value for signalling and voice traffic • ISDN: support to show the state of power source 1 and power source 2 received from NT1 (to know whether an ISDN user port is locally powered on NT or remotely powered).
Supplementary services Supplementary services are widely used in a traditional PSTN network. Customers considering to evolve/migrate from a TDM network to a NGN IP-based network, expect feature parity with the TDM network. Therefore, the support of supplementary services is mandatory.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-5
14 — Integrated Narrowband Support
The H.248 protocol specifies a master/slave architecture for decomposed gateways. In the master/slave architecture, MGC is the master server and MGs are the slave clients that behave as simple switches. The integrated VoIP service acts as a voice access gateway. A supplementary service will be provisioned by the operator at the MGC or registered to the MGC through a registration procedure by subscriber's operation. Such service registration and withdrawing operation will be transparent to the integrated VoIP service. The integrated VoIP service replies to the H.248 requests of the MGC and allocates resources for a subscriber liner when a supplementary service gets invoked for this subscriber. Table 14-1 Overview of the supported supplementary services No
Supplementary Service
POTS
ISDN
Multiparty Services
Call Waiting (CW)
✓
✓
Call Hold (HOLD): Hold For Enquiry / Stockbroker
✓
✓
3-Party Conference (3PTY)
✓
✓
Explicit Call Transfer (ECT)
✓
Add-on Conference (CONF)
✓
Abbreviated Address / Dialling (AA)
✓
Administrative Call Barring (ACB)/ Bad Payer
✓
Alarm Call (transparent)
✓
Announcement connection via MS
✓
Anonymous Call Rejection (ACR)
✓
Call Completion to Busy Subscriber (CCBS) / Ring Back (transparent)
✓
Call Completion on no Reply (CCNR)
✓
Calling Line Identification Services
Calling Line Identification Presentation (CLIP)
✓
✓
Calling Line Identification Restriction (CLIR): Permanent / On a per call basis
✓
✓
CWID service
✓
Calling Line Identification Rejection Override (CLIR-O)
✓
✓
Malicious Call Identification (MCID)
✓
✓
Call Forwarding Unconditional (CFU) (transparent)
✓
✓
Call Forwarding Busy (CFB) (transparent)
✓
✓
Call Forwarding No Reply (CFNR) (transparent)
✓
✓
Call Forwarding to Fixed Announcement (CFFA)
✓
Call Forwarding to Voice Mail (transparent)
✓
Call Diversion Services
Call Pick-Up (CPU)
✓
Call Return (CR)
✓
Coin Box (CB)
✓
Connected Line Identification Presentation (COLP)
✓
✓
✓
✓
✓
(1 of 2)
14-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
No
Supplementary Service
Connected Line Identification Restriction (COLR)
POTS
ISDN
✓
✓
Connected Line Identification Restriction Override (COLR-O) Distinctive Ringing Fixed Destination Call (FDC)
✓ ✓
HotLine
✓
✓
WarmLine
✓
✓
General Deactivation (GD)
✓
Call Barring Services
Incoming Call Barring (ICB) (transparent)
✓
✓
Outgoing Call Barring (OCB) (transparent)
✓
✓
Do Not Disturb (DND) (transparent)
✓
✓
Inhibition of Incoming Forwarded Calls (IIFC) [a.k.a. Incoming Calls Barring for diverted calls]
✓
✓
Line Hunting (LH) (transparent)
✓
Message Waiting Indication (MWI): with special dial tone connection, no VMWI
✓
Outgoing Call Screening (OCS)
✓
Special Dial Tone
✓
Call Park
✓
Last Call Return
✓
Emergency Call
✓
Multiple Subscriber Number (MSN)
✓
Sub Addressing (SUB)
✓
Terminal Portability (TP)
✓
Direct Dialling In (DDI)
✓
Change Password
✓
VoiceMail
✓
VMWI: VMWI via H248.3 ind package
✓
(2 of 2)
Interoperability of the integrated VoIP service access device with a 3rd party Voice application Server can be supported through commercial agreement. Please contact the ISAM PU for the supported supplementary services list.
Performance monitoring The statistics are autonomously enabled by the system. They are reported to the MGC in either the subtract or the audit reply, once the call has finished. These statistics are not supported through the usual management interface. The Megaco integrated VoIP service supports the “nt” as well as the “rtp” package for the permanent and ephemeral terminations.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-7
14 — Integrated Narrowband Support Table 14-2 Performance monitoring Package
Statistics
Contained in substract reply
Contained in audit reply
CLI/SNMP
Notes
nt
dur
✓
✓
-
Provides the duration of time the termination has existed or been out of the NULL context.
os
✓
✓
-
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
✓
✓
-
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.
ps
✓
✓
-
Provides the number of packets sent from the termination or stream since the termination has existed or been out of the NULL Context.
pr
✓
✓
-
Provides the number of packets received on the termination or stream since the termination has existed or been out of the NULL Context.
pl
✓
✓
-
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
✓
✓
-
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
✓
✓
-
Provides the current value of packet propagation delay expressed in timestamp units. This is the same as average latency.
rtp
14-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
14.4
SIP Feature Portfolio Registration From a system perspective, the registration of SIP terminations is done by all SIP UAs in parallel. From a SIP UA perspective, as a general rule, SIP terminations are registered on an individual basis and in the order that the SIP terminations become administratively enabled.
• SIP Registration method in compliancy to RFC3261 (including de-registration and re-registration)
• Header fields: Call ID, CSeq, From tag, Path, Service-Route, Random contact • Response codes: 200/404/413/480/486/500/503/401/407/423. • “reg” event package in compliancy with RFC3680. (Event header present in SUBSCRIBE and NOTIFY requests.) • Subscription upon successful registration • Subscribe / Notify dialog complies to RFC 3265. Anti-avalanche register procedure as to avoid stressing the register server.
• • MD5 digest encryption of registration password. Basic Call General
• Analogue Z interface. • Line feeding • Symmetrical programmable ringing • Metering tone insertion • Polarity reversal • Programmable line impedance with echo cancellation. • Overvoltage protection • Integrated Narrowband Line Test facility • Configurable end-of-dialling indicator: *, #, * and # • Tone generation: Ring tone, Dial Tone, Special (Information) Dial Tone, Ring Back Tone, Congestion Tone, Busy Tone, and Howler tone. • Echo cancellation:
• • • • •
Voice (per subscriber line): configurable as enabled/disabled low speed voice band data (per subscriber line) fax (per subscriber line) In compliancy to G.168 High speed data transmission: with echo tail length up to 16ms.
• Silence suppression: • Detection of silence descriptors in the bearer channel • Voice Activity Detection • Transmission of comfort noise to (near-end) customer interface when silence suppression is activated at the far end packet voice transmitter
• Voice activity detection, comfort noise, and packet loss concealment. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-9
14 — Integrated Narrowband Support
• FSK / DTMF (Provisionable per subscriber line). • Formatting SIP signaling messages in compliancy to RFC3261 (including escaped characters in SIP URI). • SIP BYE method (receiving, sending) in compliancy to RFC3261 to terminate call. • SIP CANCEL method in compliancy to RFC3261 to cancel outgoing call.
• Response codes: 481 / 487 • Release timer: Call gets released upon release timer expiry and no final response received.
• SIP CANCEL method in compliancy to RFC3261 to cancel incoming call. • Outgoing call rejected by remote endpoint: • Response codes: 400, 403, 404, 406, 408, 415, 480, 486, 487, 488, 500, 501, 503, • • • •
504, 600, 604, 606. Upon receipt of 486 / 600: play busy tone. Upon receipt of 480: play congestion tone. Upon receipt others: Play fast busy tone / reorder tone Retry-after header received in error 500, 404, 413, 480, 486, 600, 603: retry call set-up upon retry-after timer expiry.
• Incoming call rejection: Lack of DSP resource, CODEC not supported, Line busy, Termination not known, not supported media type in SDP offer body, Termination with administrative state = down. Response codes: 400, 404, 420, 480, 481, 486, 488, 500
• • • • • • • • • • • • • • • • •
Line busy: 486. Not supported media type in SDP offer: 488 (warning header included). Termination not known: 404. Termination with administrative state = down: 480.
Timer A, B, C and F in compliancy to RFC3261 Authentication challenges in compliancy to RFC3261 and RFC 2617. Line Polarity Reverse for incoming as well as for outgoing call. SIP OPTIONS method in compliancy to RFC3261 (Tightly and Loosely couple mode) Support for receipt of In-dialog INFO or OPTIONS method originating at network side to confirm connectivity with integrated voice service during an ongoing call. Support for receipt of in-dialog UPDATE or OPTIONS method originating at network side for session and audit refresh. Support for local or remote ring-back tone depending on P-Early-Media header settings (Tightly and Loosely coupled mode). Support for Reliability of Provisional Responses in compliancy to RFC 3262. Support for TEL URI scheme in compliancy to RFC 3961. Support of “isub-encoding” parameter in compliancy to RFC 4715. Support of TEL URI to SIP URI conversion in compliancy to RFC 3261. Support for 300 / 302 response code to new INVITE. Provisionable Dial Plan / Digit Map (Maximum size = 4 kBs)
• Maximum Digit Map match mode (Inter-digit timer expiry mode) • Minimum Digit Map match mode
14-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
• CODECs: • G.711 A/u law (10ms, 20ms, 30ms), G.729AB (10ms, 20ms, 30ms, 40ms, 50ms, 60ms), G.723.1 (20ms 30ms), T.38, RFC2833
• Packet loss concealment capability for G.711 • End-to-End codec negotiation at call set-up. In case codec information is absent, the system shall use the default codec settings: G.711 with 20ms packetization interval. G.722 (for ONT only!)
• • RTCP: • SR, RR, SDES and BYE supported • The deterministic calculated interval Td is set to 5 s. • No support for RTP session membership • Support of PreConditions in compliancy to RFC 4032: • Enable/disable SIP Preconditions. • Backwards compatibility (remote party not supporting SIP Preconditions). • Segmented QoS precondition - basic call origination:
•
• •
• Resource reservation before sending initial INVITE. • Indicate the support of SIP preconditions in the Supported header of the INVITE. • Prevent media stream from flowing until the SIP preconditions are met. Segmented QoS precondition - basic call termination: • Resource reservation before returning SDP answer. • Hold ringing the callee until the preconditions are met. • Hold call waiting tone and/or CLIP for incoming call until the required SIP preconditions are met. • Prevent media stream from flowing until SIP preconditions are met. Segmented QoS precondition - supplementary services: • Hold ringing, call waiting tone and/or CLIP for incoming call until the required SIP preconditions are met. Segmented QoS precondition - early dialog: • Only when the SIP preconditions are met, the system decides whether to present the received early media to the user.
• Reduce power feed in case the subscriber line is detected to be in Off-Hook state • • • • • •
for a longer time period without being involved in a call; provisionable delay to enter reduced power feed state. Flexible SIP URI provisioning. Flexible Termination ID provisioning. Jitter Buffer monitoring on a per subscriber line. Configurable DSCP & 802.1p bit value for signalling and voice traffic. Domain Name Service (DNS) support. Dynamic Host Configuration Protocol (DHCP) support.
Outgoing call
SIP Invite method in compliancy to RFC3261
• Header fields: Accept header; Supported header (100rel, timer, in-dialog); Allow header (“INVITE”, “ACK”, “CANCEL”, “BYE”, “UPDATE”, “PRACK”, “INFO”, “NOTIFY”, “OPTIONS”); User-Agent header; Date header; • P-Preferred-Id; P-Early-Media; Route header. • Media resource negotiation
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-11
14 — Integrated Narrowband Support
• Response codes: 180/181/182/183. • “Forking” • Response with/without SDP • Response with same/different to-tag • Alert timer: started upon the receipt of 18x. Call gets released upon alert timer expiry and no non-100 response received.
• Ability to handle the 180 ringing response including “Alert-info”. • Ability to handle the 183 response including “Required: in-dialog”. • Response code: 200OK. • Response with/without SDP • SDP body: • Offer/Answer approach:
•
• Outgoing INVITE always with initial SDP offer. • Early dialog, most recent SDP offer in response overrules previously received SDP offer. Non conformity with RFC3261. • Multiple active early dialogs: • dialog confirmed by 200 response without SDP: last received SDP applies. • dialog confirmed by 200 with SDP: this last received SDP applies. SDP content: • Session description: v=; o=; s=; c=*; a=*; • Time description: t=. • Media description: m=; a=* • Attribute: • sendonly/recvonly/sendrecv/inactive • ptime (not sent in offer). • Rtpmap • Fmtp
• Date header included in the INVITE message as GMT (Tightly and Loosely coupled mode) Incoming Call
• History-Info / Diversion header present in incoming INVITE copied in 18x response. • Incoming INVITE with/without SDP. • Optional header fields incoming INVITE: History-Info, Allow, Supported, Accept, Content-Length, Content-Type, Allow-Events, Record-Route, User-Agent, Session- Expires, Min-SE, Privacy, P-Asserted-identity, and so on. Also, it should be noted that many headers can be received but will be ignored. • Optional header fields outgoing 180 Ringing: History-Info, Allow, Supported, Accept, Content-Length, Content-Type, Allow-Events, Record-Route, User-Agent, Require. Media
• Dynamic payload type kept unchanged during a session. • Support of Early-Dialog Handling. SDP handling in 18x with different/same to-tag. • Generation of audible ringing upon receipt of 180-Ringing response. • Media update upon receipt of RE-INVITE or UPDATE methods with new SDP. • RFC 2833 (Tightly and Loosely coupled mode) 14-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
• Digit collection by detection of DTMF tones / Pulse dialing (Tightly and Loosely coupled mode)
• Dynamic payload negotiation is compliant with RFC 2833 / RFC 3264. Session refresh
• Session Timer in compliancy to RFC 4028 • Response code: 422 • Support for receipt of RE-INVITE and UPDATE methods for session refresh • UPDATE method is used for session refresh initiated by Integrated Voice Service. Overlap dialing
• Overlap Dialing: Multiple-Invite method in compliancy with RFC 3578. • Response code: 484. • Overlap Dialing: In-Dialog method (INFO method) Support of “second dialling”:
• Notifying softswitch about capability to support “in-dialog” mode by including “in-dialog” in Supported header of outgoing INVITE method.
• Establish Early dialog upon the receipt of 183 response with Require header including “In-dialog”. (No ring-back tone played).
• Play/stop dial tone upon receipt of 180 response including specific “Alert Info” • Collected digits are sent by means of INFO method. Metering
• • • • •
12/16 Khz metering. Support of metering parameters in XML body in compliancy to ETSI TS 183 047. Periodic / Burst pulsing Burst pulsing in compliancy to ETSI TS 0373_96 part 6. Supported modes:
• • • • •
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.
• Support of tariff type changes during a call. • Changing from the current tariff type to a new tariff type • Rate change within a tariff type • Support of “Free Charge” POTS metering mode. • Support of Metring types: “Override” & “Period of Day”. • Support of enable/disable reverse polarity prior to sending of metring pulse. Fax and modem
• Fax over IP in compliancy to ITU-T Rec. T.38 • FEC and redundancy • 2400 bps, 4800 bps, 7200 bps, 9600 bps, 12200 bps, 14400 bps. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-13
14 — Integrated Narrowband Support
• Incoming/Outgoing Fax with G.711 VBD or T.38. • sending/receiving 491 response • Incoming fax fallback from T.38 to VBD Fax call. • Outgoing fax fallback from T.38 to VBD fax call. • Sending 488 to fallback to VBD when lack of T.38 resources. • Fax call termination upon the receipt of 415 response • Receipt of NTE event 52 “swapping to VBD” in compliancy to RFC 4734. • Voice Band data modem and fax modem operation in compliance with GR-909 s. 5.2.1.5, R5-14by using:
• Fax/Modem Pass-through • Fax/Modem Relay. • Detection of T.30 CNG tone to identify a fax call. • Detection of the 2100 Hz (with periodic phase reversals) echo canceller disabling • • • • • • • • • • •
tone (ANS or ANSam tone) to identify a data modem call or a V.34-modulated fax call; in compliancy to GR-909 s. 5.2.1.5.3, R5-17. Disable voice band echo cancellers upon detection of a 2100 Hz tone (with periodic phase reversals); in compliancy to GR-909 s. 5.2.1.3, R5-10. CNG detection upon the receipt of a 1100 Hz tone [0.5 s. ON; 3 s. OFF] in compliancy to T.30. Detection of voice, fax, or data modem call types in accordance with the matrix (GR-909 s. 5.2.1.5.4, R5-18) shown in Table 14-3. Support for automatic upspeed to G.711 when Fax and Data Modem tones are detected. Detection of 2225 Hz Bell 103 modem tone, used with security panels and other very low bit rate devices, with automatic upspeed to G.711. Detection of 2300 Hz tone causing automatic disabling RFC 2833 DTMF transport if it was active during the call. In the transition from voice to T.38, the ability to re-use the audio media stream and UDP port for the T.38 image media stream. In the transition from T.38 to voice, The same UDP port used with the T.38 image media shall be used with the SDP offer for the audio. Transition to T.38 upon detection of V.21 flags received at the POTS port. Fax: V.21, V.17, V.27ter, V.29, V.34 compliance. Modem (or text phone): 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. Table 14-3 Detection matrix Tone detected at near-end
14-14
Tone detected from far-end None
DNG
2100 Hz with Phase rev
None
Voice
Fax
Data
CNG
Fax
-
Data
210 Hz with Phase Rev
Data
Data
-
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
Supplementary services The TISPAN PES emulates the PSTN services to subscribers with full transparency regarding the “look and feel” of the services. Subscribers can continue to use their legacy terminals connected to the IMS network via gateways. TISPAN PES defines two models on how the Voice Gateway interacts with the Application Server with respect to SIP call manipulation for supplementary services. In the tightly coupled model, the VGW remains mostly ignorant to the call control logic of the supplementary service. It simply acts under the direction of the AS and will report any event to the AS who will manipulate the call leg(s). Supplementary service logic is mostly centralized in the AS. In the loosely coupled model, service logic is pushed into the VGW. The VGW will autonomously interpret user events and will autonomously manipulate the call legs accordingly. The Integrated VoIP service supports both models. Although both models cannot run in parallel. General
Table 14-4 lists the representative supplementary services that work in conjunction with the Alcatel-Lucent IMS solution. More extensive treatment of the supplementary services supported is available in the associated Alcatel-Lucent IMS documentation. Table 14-4 Overview of the supported supplementary services No
Supplementary Service
POTS
Multiparty Services
Call Waiting (CW): activation / deactivation / explicit or implicit subscription
✓
Call Hold (HOLD): activation / deactivation / explicit or implicit subscription
✓
3-Party Conference (3PTY): activation / deactivation / explicit or implicit subscription
✓
Explicit Call Transfer (ECT): activation / deactivation / explicit or implicit subscription
✓
Call Completion to Busy Subscriber (CCBS) / Ring Back (transparent)
✓
Calling Line Identification Services
Calling Line Identification Presentation (CLIP)
✓
Calling Line Identification Restriction (CLIR): Permanent / On a per call basis
✓
CWID service
✓
Malicious Call Identification (MCID): Permanent / After call ended
✓
(1 of 2)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-15
14 — Integrated Narrowband Support
No
Supplementary Service
POTS
Call Diversion Services
Call Forwarding Unconditional (CFU)
✓
Call Forwarding Busy (CFB)
✓
Call Forwarding No Reply (CFNR)
✓
Call Forwarding to Voice Mail
✓
Selective Call Forwarding (SCF)
✓
Special dial tone in case diversion service activated
✓
Special dial tone in case Message waiting service activated and new waiting messages at VMS for the user's account.
✓
SIP based Integrated VoIP access device supports the TS183 043 standardized solution (Annex A) for dial tone management based on unsolicited NOTIFY SIP messages using the ua-profile XML body
✓
Notification Services
Distinctive Ringing
✓
Call Barring Services
Selective Call Baring Services
Fixed Destination Call (FDC
Outgoing Call Barring (OCB): Administrative / User Controlled
✓
Incoming call barring (ICB): Administrative / User Controlled
✓
Do Not Disturb (DND)
✓
Bad Payer
✓
Selective call rejection
✓
Selective call acceptance
✓
Anonymous Call Rejection (ACR)
✓
HotLine
✓
WarmLine: activation / deactivation / explicit or implicit subscription (interrogation via service code).
✓
(2 of 2)
Interoperability of the SIP based Integrated VoIP access device with a 3rd party Voice Application Server can be supported through commercial agreement. Please contact the ISAM PU for the supported supplementary services list. Tightly Coupled Model
• “Call Waiting”: • Flash-hook only: Calling termination presses the flash-hook to switch between the •
14-16
current called termination and a 3rd party. Flash-hook + SOC (Switch Order Command): Calling termination presses flash-hook and dials an additional digit to switch between the current called termination and a 3rd party
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
• “Call Hold”: • Hard Hold:
•
•
• Only calling and called termination involved. • Allowing calling termination to Flash Hook once to put the called termination on hold, and to Flash Hook once again to resume the call with the hold termination. Call Hold Consultation: • Calling termination, called termination and 3rd party involved. • Allowing calling termination to put an existing call on hold and to initiate a second call to a 3rd party ANSI: Full Consultive Call Hold support via feature code.
• “3-party Conference”: • Automatically bridged call by AS • User dialing decided conference call • “Explicit Call Transfer”: • Consultative call transfer: for forwarding a call after the first person who was called •
spoke to the caller. (e.g. This is useful if a secretary is called and forwards the call afterwards to the responsible person). 3-Way Call transfer: With 3-Way Call Transfer, a termination can set up a 3-way call and then disconnect, allowing the remaining parties to continue the conversation. Blind call transfer: to transfer a call without talking to the called party.
• • “Malicious Call Identification”: • Permanent (transparent to Integrated VoIP service access device). • After call completion. • During call (transparent to Integrated VoIP service access device).
Note — In this case the Application Server cannot make any different between flash-hook for MCID or flash-hook for other supplementary service e.g. 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. Loosely Coupled Model
• “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. The user is notified by a CW-tone that a 2nd incoming call arrived. The user can either decide to ignore the call waiting tone or accept the waiting call. Two variants are supported: • Simplified CW with Flash-hook only: Calling termination presses the flash-hook to accept the waiting call and hold the current call. Continuously switching between both parties by subsequent flash-hook events. To reject the waiting call, the user just ignores the CW-tone. • CW with Flash-hook + SOC (Switch Order Command): Calling termination presses flash-hook and dials an additional digit to either indicate:
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-17
14 — Integrated Narrowband Support
• •
• Accept waiting call with release of current call • Accept waiting call with hold of current call • Reject waiting call • Toggle between two calls • Merge two calls into a 3-way-call conference Cancel Call Waiting (CCW) controlled by 485 (confirmation tone played) / 489 (no confirmation tone played) in response to INVITE sent after subscriber dialled CCW access code Cancel Call Waiting (CCW) in compliancy with GR-572-CORE - LSSGR: Cancel Call Waiting, FSD 01-02-1204: • Use of configurable feature code for subscriber requests. • The “S” modifier without an “R” modifier must be present in the Dial Plan.
• “Call Hold”: • Complies with ETSI TS183043 C.9.1/C.16.1 Loose Coupling, 3GPP ES 23.228
•
chap 5.11.1, ES 24.228 chap10.1, and China Mobile specification. Generate re-INVITE message when the supplementary service becomes activated due to pressing the hook-flash. The user can hold the initial call and initiate an enquiry call to a 3rd party by making a hook-flash event and dial the 3-party number. Once the enquiry call is established the user can switch between two calls by making a subsequent hook-flash event. Following flavours are supported: • Simplified Call hold with HF-only: the user can continuously switch between two calls by making a Hook-flash event • Call Hold with Hook-flash + SOC: user makes a hook-flash event and gets dial tone. User dials a 1 digit SOC to either: • Release held call and continue with current active call • Go back to held call with release of current active call • Switch continuously between both calls • Join both calls into a 3-way-call conference ANSI: Full Consultive Call Hold support via feature code.
• • “3 Party Conference”: • Compliant to both TISPAN and NON-TISPAN specification, noted that the
•
•
• •
14-18
Y-function hosts in the MRF/MS, not in SIP based Integrated VoIP access device. Although, the 72 lines Voice LT board is also able to do audio mixing. (NON-TISPAN implementation only supports IOT with Broadworks FS.) Supported with the media-stream mixing being done at the IMS core MRF, in compliancy with 3GPP specification TS24.147 subclauses 5.3.1.3.2 “Conference creation with a conference factory URI”, 5.3.1.3.3 “Three-way session creation”, 5.3.1.5.3 “User invites other user to conference by sending a REFER request to the conference focus” and 5.3.1.6.1 “Conference participant leaving a conference”. Supported in compliancy with ETSI TS183 043 C.14.2 Loose Coupling option 1 (with local RTP-stream mixing at the SIP based Integrated VoIP access device) and option 3 (with RTP-stream mixing at the MRF of the core under control of the core application server). The user can hold the initial call and initiate an inquiry call to a 3th party by making a hook-flash event and dial the 3-party number. Once the enquiry call is established the user can join both calls into 3-way conference by a subsequent Hook-flash event. Support of “Isfocus” parameter in compliancy with GR-577-CORE - LSSGR: Three-Way Calling, FSD 01-02-1301, with contact header of the form “username3wc@host” where username is the configured username of the line / user part of address_of_record appended with the string “3wc”.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
• “Explicit Call Transfer”: • Compliant to both TISPAN and NON-TISPAN specification. (NON-TISPAN implementation only supports IOT with Broadworks FS.)
• Supported in compliancy with 3GPP ES 23.228 chap 5.11.6 Session Transfer and ES 24.228 chap 10.5.
• Support REFER message to send the DTMF to the AS according to RFC 3515 “REFER Method/Refer-to header” and RFC 3892 “Referred-By header”.
• Consultative call transfer: for forwarding a call after the first person who was called • •
spoke to the caller. (e.g. This is useful if a secretary is called and forwards the call afterwards to the responsible person). 3 Way Call transfer: With 3-Way Call Transfer, a termination can set up a 3-way call and then disconnect, allowing the remaining parties to continue the conversation. Blind call transfer: to transfer a call without talking to the called party. For example, in case *23 is the blind call transfer service code, the digit map shall include “*23S” as prefix of those patterns to be dialed as transfer target of blind call transfer service. Those patterns are used for blind call transfer only. For example, pattern 11xxx is used for basic call, and *23S11xxx is used for blind call transfer.
• “Malicious Call Identification” • Permanent (transparent to SIP based Integrated VoIP access device). • After call is finished (Not supported during a call). • “Emergency Call” • Support Emergency number dialing (e.g. 911)
•
• By adding priority headers in the INVITE message subsequent to dialing. • Priority: “emergency” in compliancy with RFC 3261 • “Resource-Priority: emrg.0” in compliancy with draft-ietf-sip-resource-priority-10 • The dial plan contains a specific method of identifying when an emergency number has been dialed (the “E” modifier). • Allow an emergency number to be dialed whenever digit collection is performed Support Emergency Call E911 for a standard 2-party call with • call feature blocking • provisionable forced hold option.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-19
14 — Integrated Narrowband Support
Additional Info
• “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 SIP based Integrated VoIP access device. 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. SIP-based Integrated VoIP access device 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 SIP based Integrated VoIP access device. 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 header be present, then precedence is given to one of these headers in accordance with the precedence policy configured in SIP based Integrated VoIP access device. In general, IMS networks do provide calling number information in the global number format identified by the leading “+” character (Ref. RFC3966). SIP based Integrated VoIP access device is able to convert the leading “+” into a configurable international-prefix before the CLI propagated in the CLIP FSK data message. SIP-based Integrated VoIP access device allows to configure whether the “Date and Time” parameter is to be included in the CLIP FSK data message. SIP based Integrated VoIP access device allows to configure whether the date and time shall be taken from the SIP INVITE Date Header or from the local SIP based Integrated VoIP access device time reference. 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 SIP based Integrated VoIP access device. 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.
• Audible and Visual Message Waiting Indication: • SIP-based Integrated VoIP access device supports the NOTIFY messages with
•
14-20
Messages-Waiting parameter in the application/simple-message-summary body. If the message waiting indicator state is ON, then Stutter Tone (Message Waiting Indicator Tone) will be output during call origination (replacing normal Dial Tone). Visual Indication FSK will be output to the telephone set.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
• Fixed line SMS service. • SIP-based Integrated VoIP access device 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 SIP based Integrated VoIP access device 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).
Release Control
• • • •
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').
SMS
• Fixed Line SMS service. • FSK Data transmission in compliancy to ETSI EN 300 659 - 2. • TE-altering signal (TAS) used to signal the data transmission and to force the receiver to switch to VBD mode. PANI Header
• Format = P-Access-Network-Info: ADSL; dsl-location=”quoted string” • Used by IMS core to identify the originating access device of a SIP request. Performance Monitoring
The statistics can be retrieved using CLI or an Element Management System (EMS / SDC). See the related documents for detailed information and the detailed command definitions for retrieving the VoIP service counters and/or statistics. (Operations and Maintenance Guide Using CLI, 5529 Statistics and Data Collector Installation and User Guide). The SIP based integrated VoIP service supports different performance monitoring methods. Access products may support all or a subset of these methods. Please contact the ISAM PU for further details. The different performance monitoring methods are explained hereafter. History Interval Framework.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-21
14 — Integrated Narrowband Support
One of the methods supported by the SIP-based integrated VoIP service for the collection and reporting of statistics and counters is the History Interval Framework. This basic framework relies on current and historical intervals to store the history of the statistics and counters. This is typically one interval per 15 minutes or 24 hours. The start and end time of each interval (15 minutes / 24 hours) are aligned with the quarter hours / 24 hours of the wall clock. Should the duration of a call session exceed the interval boundary, then the statistics and counters for such call session will be collected and reported spread over multiple intervals. The post-processing i.e the concatenation / sum-up of all portions for such statistics and counters, in order to calculate the results for the full call, is not supported by the Integrated Voice Service access device; It is to be done by an external expert system (e.g. SDC). Figure 14-1 SIP ISAM Voice Performance Monitoring Result Post-Processing OSS Platform 1. Generate PM record for dialog A including Dialog Reference
2. Associate PM record with CDR record by using the Dialog Reference
Other NE
CDR SDC 2. Generate PM record for dialog A including Dialog Reference. 1. Retrieve all PM portions for dialog A using Dialog Reference Dialog A “Elapse” time Dialog A “active” time – portion 1
Dialog A
Dialog A Portion_1 PM record Recent 15 min interval N-1
1 PM record for dialog A in this 15 min interval
Dialog A “active” time – portion 2
Dialog A Dialog A e.g. put Portion_2 on hold PM record
Dialog A Portion_3 PM record
Recent 15 min interval N
2 PM records for dialog A in this 15 min interval
Dialog A Portion_4 PM record Recent 15 min interval N+1
1 PM record for dialog A in this 15 min interval
The SIP based Integrated VoIP Service supports voice related per-line, per-board and per call statistics / counters. For the per-line statistics and counters, the current 15 min / 24 hours interval together with a set of 96 x 15 min and 3 x 24 hours history intervals is supported. For the per-call statistics and counters, a set of 96 x 15 min history intervals is supported (The current 15 min interval is not supported). For the per-board statistics and counters, the current 15 min / 24 hours interval together with a set of 96 x 15 min and 3 x 24 hours history intervals is supported. The SIP based Integrated VoIP Service supports TCA handling. The TCA can be enabled / disabled for each individual subscriber line. Both the high and the low TCA threshold are configurable. Statistics can be explicitly enabled / disabled by means of the regular management channel. The system does not allow to enable/disable a particular performance monitoring category. Either PM is enabled for all categories (per-Line, per-Board, per-Call) or PM is disabled for all categories (per-Line, per-Board, per-Call).
14-22
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support Table 14-5 Overview of Per-line Statistics and Counters Statistics
Description
Packets Sent
The number of RTP packets sent by a SIP termination during a single
Packets Received
The number of RTP packets received by a SIP termination during a single interval
Octets Sent
The number of octets sent by a SIP termination during a single interval
Octets Received
The number of octets received by a SIP termination during a single interval
Average Inter-Arrival Jitter
The average Inter-Arrival Jitter for (an) RTP data stream(s) of a SIP termination in a single interval.
Peak Inter-Arrival Jitter
The peak Inter-Arrival Jitter measured for (an) RTP data stream(s) exchanged by a SIP termination during a single interval.
Average Round Trip Delay
The average Round Trip Delay for (an) RTP data stream(s) of a SIP termination during a single interval
Peak Round Trip Delay
The peak Round Trip Delay measured for (an) RTP data stream(s) exchanged by a SIP termination during a single interval
Average Jitter Buffer Fill level
The average jitter buffer fill level for a SIP termination during a single interval
Average Jitter Buffer Fill level G711a
The average jitter buffer fill level measured during the receipt of (an) RTP stream(s), encoded with G711_a by a SIP termination during a single interval
Average Jitter Buffer Fill level G711u
The average jitter buffer fill level measured during the receipt of (an) RTP stream(s), encoded with G711_u by a SIP termination during a single interval
Average Jitter Buffer Fill level G723
The average jitter buffer fill level measured during the receipt of (an) RTP stream(s), encoded with G723 by a SIP termination during a single interval
Average Jitter Buffer Fill level G729
The average jitter buffer fill level measured during the receipt of (an) RTP stream(s), encoded with G729 by a SIP termination during a single interval
Total Packet Loss
The total (absolute) amount of packets lost for a SIP termination during a single interval.
Successful (Re-) Register requests
The number of (re-)registration requests which are successfully replied in this interval i.e. a response = 200 OK with expire header time = 0 or expire header 0 has been returned by the Registrar.
Failed (Re-) Register requests
The number of (re-)registration requests which failed in this interval i.e a response 200 OK was returned by the SIP First Hop server / Registrar or that SIP transaction timed-out.
Active Registrations
The number of registrations being active at a subscriber port at the start of the interval. In the current implementation, only 1 registration can be active at a subscriber port at a time. An active registration is counted when a registration request has been successfully completed in the past (200 OK received to register request with “expire header” time 0) and the register expiration interval hasn't expired.
(1 of 2)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-23
14 — Integrated Narrowband Support
Statistics
Description
Outgoing Calls Answered
The number of outgoing call attempts in this interval for which an initial INVITE request is sent AND for which a response is received. The system allows to provision what kind of response must be received as to be counted as a successful outgoing call attempt. The system offers the following options:
• • Incoming Calls Answered
Any response be received (irrespective of whether this is a successful or unsuccessful response). A successful response be received (180 or 200 response only).
The number of incoming call attempts in this interval for which a SIP response is sent being the result of the off-hook event been detected. The system allows to provision the kind of response that will be considered as to be counted as a successful incoming call attempt. The system offers the following options:
• •
Any response be sent. 180 response be sent.
(2 of 2)
Table 14-6 Overview of Per-call Statistics and Counters
14-24
Statistics
Description
Packets Sent
The number of RTP packets sent by a SIP termination since the call is established/ the start of the interval and the end of the call/ the expiry of the interval
Packet Received
The number of RTP packets received by a SIP termination since the call is established/ the start of the interval and the end of the call/ the expiry of the interval
Octets Sent
The number of octets sent by a SIP termination since the call is established / the start of the interval and the end of the call/ the expiry of the interval
Octets Received
The number of octets received by a SIP termination since the call is established/ the start of the interval and the end of the call/ the expiry of the interval
Average Inter-Arrival Jitter
The average Inter-Arrival Jitter for the RTP data stream since the call is established/ the start of the interval and the end of the call/ the expiry of the interval.
Peak Inter-Arrival Jitter
The peak Inter-Arrival Jitter for the RTP data stream since the call is established/ the start of the interval and the end of the call/ the expiry of the interval.
Average Round Trip Delay
The average Round Trip Delay for the RTP data stream since the call is established/ the start of the interval and the end of the call/ the expiry of the interval.
Peak Round Trip delay
The peak Round Trip Delay for the RTP data stream since the call is established/ the start of the interval and the end of the call/ the expiry of the interval.
Total Packet Loss
The total (absolute) amount of packets lost for the RTP data stream since the call is established/ the start of the interval and the end of the call/ the expiry of the interval.
Total Packet Loss due to Jitter Buffer Overrun
The total (absolute) amount of packets lost due to Jitter Buffer Overrun for the RTP data stream since the call is established/ the start of the interval and the end of the call/ the expiry of the interval.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support Table 14-7 Overview of the Per-Board statistics and counters Statistics
Description
Packets Sent
The number of RTP packets sent by all SIP terminations of an LT board during a single interval
Packets Received
The number of RTP packets received by all SIP terminations of an LT board during a single interval
Octets Sent
The number of octets sent by all SIP terminations of an LT board during a single interval
Octets Received
The number of octets received by all SIP terminations of an LT board during a single interval
Average Inter-Arrival Jitter
The average Inter-Arrival Jitter for (an) RTP data stream(s) exchanged by an LT board during a single interval.
Peak Inter-Arrival Jitter
The peak Inter-Arrival Jitter measured for (an) RTP data stream(s) exchanged by an LT board during a single interval.
Average Jitter Buffer Fill level
The average jitter buffer fill level for an LT board during a single interval
Average Round Trip Delay
The average Round Trip Delay for (an) RTP data stream(s) exchanged by an LT board during a single interval
Peak Round Trip Delay
The peak Round Trip Delay measured for (an) RTP data stream(s) exchanged by an LT board during a single interval
Total Packet Loss
The total (absolute) amount of packets lost by an LT board during a single interval.
Average Jitter Buffer Fill level
The average jitter buffer fill level measured during the receipt of (an) RTP stream(s), encoded with G711_a for an LT board during a single interval
Average Jitter Buffer Fill level G711u
The average jitter buffer fill level measured during the receipt of (an) RTP stream(s), encoded with G711_u for an LT board during a single interval
Average Jitter Buffer Fill level G723
The average jitter buffer fill level measured during the receipt of (an) RTP stream(s), encoded with G723 for an LT board during a single interval
Average Jitter Buffer Fill level G729
The average jitter buffer fill level measured during the receipt of (an) RTP stream(s), encoded with G729 for an LT board during a single interval
Spare POTS Ports
Total amount of POTS ports, which are not configured in the SIP termination Table, but present at the LT board. The value is taken at the beginning of the respective interval
Active POTS Ports
Total amount of available configured (configured and not administratively blocked) POTS ports (independent of line status and registration) at the LT board. The value is taken at the beginning of the respective interval
Inactive POTS Ports
Total amount of not-available configured (configured and administratively blocked) POTS ports (independent of line status and registration) at the LT board. The value is taken at the beginning of the respective interval.
Average CPU Load
Average CPU load measured at an LT board during a single interval
Average Memory Utilization
Average amount of semi and dynamic memory being used at an LT board / NT board) during a single interval. Expressed as a percentage.
Average Free Memory
Average amount of free semi and dynamic memory measured at an LT board / NT board during a single interval. Expressed in MB.
(1 of 2)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-25
14 — Integrated Narrowband Support
Statistics
Description
Average Memory Used
Average amount of semi and dynamic memory being used at an LT board / NT board) during a single interval. Expressed in MB.
Total Memory
The total amount of semi and dynamic memory available at an LT board / NT board. Expressed in MB
Successful (Re-) Register requests
The number of (re-)registration requests which are successfully replied in this interval i.e. a response = 200 OK with expire header time = 0 or expire header 0 has been returned by the Registrar.
Failed (Re-) Register requests
The number of (re-)registration requests which failed in this interval i.e a response 200 OK was returned by the SIP First Hop server / Registrar or that SIP transaction timed-out.
Active Registrations
The number of registrations being active at a subscriber port at the start of the interval. In the current implementation, only 1 registration can be active at a subscriber port at a time. An active registration is counted when a registration request has been successfully completed in the past (200 OK received to register request with “expire header” time 0) and the register expiration interval hasn't expired.
Outgoing Calls Answered
The number of outgoing call attempts in this interval for which an initial INVITE request is sent AND for which a response is received. The system allows to provision what kind of response must be received as to be counted as a successful outgoing call attempt. The system offers the following options:
• • Incoming Calls Answered
Any response be received (irrespective of whether this is a successful or unsuccessful response). A successful response be received (180 or 200 response only).
The number of incoming call attempts in this interval for which a SIP response is sent being the result of the off-hook event been detected. The system allows to provision the kind of response that will be considered as to be counted as a successful incoming call attempt. The system offers the following options:
• •
Any response be sent. 180 response be sent.
(2 of 2)
Data Set Framework. Another method supported by the SIP based integrated VoIP service for the collection and reporting of statistics and counters is the Data Set framework. This Data Set framework supports collection of per-call statistics for each individual POTS port. This information is retained at the Line termination board and be retrievable via the usual management interface. The per-call statistics consist of up to 32 sets data collected on a call by call basis, using information from SIP call control and RTP bearer channel information from the DSP. A new data set is initiated whenever the POTS line exits the idle on-hook state. Bearer channel data is updated in the active data set when a bearer channel is closed. If multiple bearer channels are established during the course of a single call (e.g. if call waiting occurred) then only the data from the last disconnected bearer channel will be retained in the data set. The data set is closed when the POTS lines returns to an idle state. The oldest data set entry becomes overwritten when no free entry is found.
14-26
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
The call history data (the 32 sets of data) shall be cleared when a POTS line is deleted (i.e. un-provisioned). Table 14-8 Overview of the Data Set Statistics and Counters Statistics
Description
Time and Date
Time and Date when the new call was initiated.
Duration
The duration of the call.
Called party number
DN of called party.
Calling party number
DN of calling party.
Packets sent
Number of RTP packets sent.
Packets received
Number of packets received.
Packets not received
Number of RTP packets that were not received (which can be determined from missing sequence numbers).
Packets discarded
Number of RTP packets discarded due to errors.
Jitter Buffer over-run
Number of jitter buffer over-runs (number of RTP packets discarded because the jitter buffer was full).
Jitter Buffer under-run
Number of jitter buffer under-runs (number of RTP packets that were not processed to provide PCM voice because the jitter buffer was empty).
Average Jitter
The average jitter measured during the receipt of the RTP stream.
Average Jitter buffer depth
Average jitter buffer depth while the bearer channel was active.
Peak Jitter
The peak jitter measured during the receipt of the RTP stream.
RTCP participation
Whether or not the far end participated in RTCP.
Average Round Trip Delay
If the far end did participate in RTCP: Average round trip delay while the bearer channel was active.
Peak Round Trip Delay
If the far end did participate in RTCP: Peak round trip delay while the bearer channel was active.
RTCP-XR
Whether or not the far end participated in RTCP-XR.
Average Mean Opinion Score
If the far end did participate in RTCP-XR: Average Mean Opinion Score (MOS).
Short-Lived Framework The short-lived method supported for the System-wide resource utilization related statistics / counters and System-wide Subscriber Line Utilization and service availability statistics / counters makes use of operational counters. Table 14-9 Overview of the System-wide Resource Utilization Statistics and Counters Statistics
Description
Average CPU Load
The average CPU load for a particular LT board (180 s)
Detailed CPU load
Detailed list of the CPU load measured with a 1 s interval over a total period of 180 s
(1 of 2)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-27
14 — Integrated Narrowband Support
Statistics
Description
Absolute Memory Utilization
The absolute value of the total amount of memory resources utilized by a particular LT board.
Percentage of Memory Utilization
The percentage of memory resource utilization compared to the available dynamic memory resources for a particular LT board
(2 of 2)
Table 14-10 Overview of the System-wide Resource Utilization Statistics and Counters
14.5
Statistics
Description
Non-Configured Lines
The amount of planned/equipped subscriber lines for which no entry could be found in the SIP Termination Table.
Operational Configured Lines
The amount of subscriber lines configured in the SIP Termination Table and for which the operational state equals “up”.
Non-Operational Configured Lines
The amount of subscriber lines configured in the SIP Termination Table and for which the operational state equals “down”.
Validating Origin of SIP request The system allows to check the origin of a received SIP request (Invite, Options, Notify) message. Following origin check options are supported: 1
A SIP request gets accepted irrespective of the origin of the request (SIP request is accepted from any SIP first hop server)
2
A SIP request gets accepted on the condition that it originates from the SIP first hop server that has been selected as the SIP first hop server currently to be addressed (Active SIP server) for outgoing SIP requests.A SIP request received from SIP first hop server other than the ACTIVE SIP server is rejected with response code “403”.
3
A SIP request gets accepted on the condition that it originates from one of the SIP first hop servers that are maintained in the locally created SIP first hop server White List. This “White List” includes all configured (IP@, FQDN, DN) and administratively enabled SIP first hop servers (primary + secondary) in the SIP Server Table (SIP MIB). A SIP request received from SIP first hop server other than the SIP first hop servers appearing in the White List is rejected with response code “403”.
The system allows to check the origin of a received SIP response message. A SIP response message gets dropped if it does not originate from the Active SIP server / a SIP first hop server appearing in the White List.
14-28
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
14.6
Voice Service related defined alarms The alarms below listed may be supported by all or only a subset of the integrated voice service access products. Please contact the ISAM PU for further details.
Generic • Clock Loss Alarm: A condition meaning that either the NT-A clock or the NT-B clock or both NT clock signals are lost.
• Invalid Voice Server Database: A condition meaning a corruption of the Voice Server database. • Invalid CDE Profile: A condition meaning a corruption of the CDE Profile. • Missing CDE Profile: A condition meaning that the voice LT board requests a CDE file that cannot be found at the NT. • CDE Profile Hash Error: A condition meaning that the Activation of a new CDE Profile has failed because of wrong CDE Profile Hash Key.
MEGACO • Media Gateway Controller Unreachable: A condition meaning that the control • • • • • • • • • • • • •
association with the MGC has been lost. Signaling Gateway Controller Unreachable: A condition meaning that the control association with the Signaling Gateway Controller has been lost. LT Card Unreachable: A condition meaning that the Server card has lost the connection with the LT card. LT Card Mismatch: A condition meaning that the planned LT board type is different from the equipped LT board type. Unknown Megaco Subscriber: A condition meaning that the Megaco subscriber doesn't exist at the Media Gateway Controller. Port Ground Key: A condition meaning that the current threshold of the physical port has been exceeded (The tip is connected to AC source; The ring is connected to the AC source). Port High Temperature: A condition meaning that the temperature threshold of the physical port has been exceeded; the port has been shutdown. Line Showering: A condition meaning that the number of on-hook and off-hook occurrences for a particular subscriber lines has exceeded the threshold. L1 active failure: A condition meaning that the activation of the link layer of the ISDN subscriber has failed. Over Current: A condition meaning that the line current of the physical ISDN port has exceeded the current threshold. Voice Server Persistent Data Loss: A condition meaning that the Voice Server has lost all persistent data after been reset. Voice Server Flash Disk Full: A condition meaning that amount of free space at the flash disk of the Voice Server is less than 10%. Voice Server implicit DB Rollback: A condition meaning that the Voice Server is not able to use the most recent downloaded data base contents. MG Overload: A condition meaning that the Voice Server is in overload.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-29
14 — Integrated Narrowband Support
SIP • Bad Digitmap: A condition meaning that the provisioned digit map is unusable. • No DNS server reply: A condition meaning that none of the provisioned DNS servers do reply.
• No DNS server configured: A condition meaning that DNS server provisioning is • • • • • • • • • • • • • • • • • • • •
14-30
missing. No SIP server reply: A condition meaning that none of the provisioned SIP servers do reply. No SIP server configured: A condition meaning that SIP sever provisioning is missing. No SIP Registrar reply: A condition meaning that none of the provisioned SIP registrars do reply. Transport Protocol mismatch: A condition meaning that a mismatch exists between the transport protocol(s) supported by the SIP UA and the transport protocol(s) to be used to access a SIP server. DNS Look-up failure: A condition meaning that DNS look-up failed. DHCP Server unreachable: A condition meaning that DHCP server is unreachable. Port Ground Key: A condition meaning that the current threshold of the physical port has been exceeded (The tip is connected to AC source; The ring is connected to the AC source). Port High Temperature: A condition meaning that the temperature threshold of the physical port has been exceeded; the port has been shutdown. Unknown SIP Subscriber: A condition meaning that the SIP subscriber doesn't exist in the SIP Application Server. Mismatch: A condition meaning that the ONT did not accept the OMCI configuration requests for the provisioned POTS service RTCP Stream error: A condition meaning that the POTS Realtime Transport Control Protocol packet stream was lost during an active voice call. Voice Configuration File Error: A condition meaning that the voice configuration file contains an error. SIP Registration failure - Resolve domain name: A condition meaning that the SIP registration failed, because of resolve domain name failure. SIP Registration failure - Authentication: A condition meaning that the SIP registration failed, because of authentication failure. SIP Registration failure - Time-out: A condition meaning that the SIP registration failed, because of message time-out. SIP Registration failure - SIP Server error response: A condition meaning that the SIP registration failed, because of error response from SIP server. SIP INVITE failure - Resolve domain name: A condition meaning that the SIP invite failed, because of resolve domain name failure. SIP INVITE failure - Authentication: A condition meaning that the SIP invite failed, because of authentication failure. SIP INVITE failure - Time-out: A condition meaning that the SIP invite failed, because of message time-out. SIP INVITE failure - SIP Server error response: A condition meaning that the SIP invite failed, because of error response from SIP server.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
14 — Integrated Narrowband Support
• SIP SUBSCRIBE failure - SIP Server Error response: A condition meaning that the SIP subscribe failed, because of error response from SIP server.
• SIP SUBSCRIBE failure - Resolve domain name: A condition meaning that the • • • • • • •
14.7
SIP subscribe failed, because of resolve domain name failure. SIP SUBSCRIBE failure - Authentication: A condition meaning that the SIP subscribe failed, because of authentication failure. SIP SUBSCRIBE failure - refresh Time-out: A condition meaning that the SIP subscribe refresh failed, because of message time-out. SIP SUBSCRIBE failure - initial Time-out: A condition meaning that the initial SIP subscribe failed, because of message time-out. Emergency Call ongoing: A condition meaning that an Emergency call is ongoing. SIP Message Timeout Threshold crossed (TCA): A condition meaning that the number of SIP Message timeouts threshold has crossed for the POTS line. RTP Bearer Packet Loss Threshold crossed (TCA): A condition meaning that the number of RTP bearer packets loss on a POTS line has been crossed. Jitter Threshold crossed (TCA): A condition meaning that the RTP Jitter Threshold has been crossed on a POTS line.
Compliancy to standards ISAM Voice is fully/partially compliant to the following standards (further details are provided in the related Protocol Information Compliancy Sheets (PICS documents)):
Megaco • RFC768, RFC791, RFC792, RFC826, RFC894, RFC919, RFC920, RFC950, • • • • • • • • • •
RFC1157, RFC2327, RFC2960, RFC3057, RFC3389, RFC3550, RFC4233, RFC4734 IEEE Std 802.3, IEEE Std 802.1Q, IEEE Std 802.1P ITU-T Study Group 16: H248.1v2, 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 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 Recommendation Q.1950: Bearer independent call bearer control protocol, ITU-T Recommendation V.152: Procedures for supporting voice-band data over IP networks ITU-T I.603 SERIES I: INTEGRATED SERVICES DIGITAL NETWORK (ISDN) Maintenance principles; Application of maintenance principles to ISDN basic accesses Telcordia Bell 202 (FSK) ETSI EN 300 659-1 V1.3.1 DTMF for on-hook data transmission
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
14-31
14 — Integrated Narrowband Support
• 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 ETSI ES 283 002: H.248 Profile 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 • RFC768, RFC791, RFC792, RFC950, RFC919, RFC920, RFC2131, RFC2327,
• • • • • • • • • • • • • • • • • •
14-32
RFC2833, RFC2976, RFC3261 (ETSI TS102 027-1), RFC3262, RFC3263, RFC3264, RFC3265, RFC3311,RFC3321, RFC3323, RFC3325, RFC3326, RFC3389, RFC3515, RFC3550, RFC3551, RFC3665, RFC3680, RFC3725, RFC 3842, RFC3891, RFC3892, RFC3959, RFC3960, RFC4028, RFC4244, RFC4780, RFC5009, RFC5366, RFC5806 Draft-kaplan-sip-session-id-02: A Session Identifier for the Session Initiation Protocol (SIP) Draft-ietf-sipping-sip-offer/answer: SIP (Session Initiation Protocol) Usage of the Offer/Answer Model ITU-T Recommendation V.152: Procedures for supporting voice-band data over IP networks 3GPP ETSI TS 23.167: IP Multimedia Subsystem (IMS) emergency sessions 3GPP ETSI TS 23.228: IP Multimedia Subsystem (IMS) 3GPP ETSI TS 24.228: Signalling flows for the IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) 3GPP ETSI TS 24.229: IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) 3GPP ETSI TS 24.406: Message Waiting Indication (MWI) 3GPP ETSI TS 24.407: Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR) 3GPP ETSI TS 24.408: Terminating Identification Presentation (TIP) and Terminating Identification Restriction (TIR) 3GPP ETSI TS 24.410: Communication HOLD (HOLD) 3GPP ETSI TS 24.447: Advice Of Charge (AOC) 3GPP ETSI TS 24.504: Communication Diversion (CDIV) 3GPP ETSI TS 24.505: Conference (CONF) 3GPP ETSI TS 24.529: Explicit Communication Transfer (ECT) 3GPP ETSI TS 24.615: Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem 3GPP ETSI TS 183.043: IMS-based PSTN/ISDN Emulation 3GPP ETSI TS 183.047: NGN IMS Supplementary Services; Advice Of Charge (AOC)
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
15.1 Introduction
15-2
15.2 The concept of Virtual LAN (VLAN) 15.3 The ISAM is an Access Device
15-2
15-4
15.4 ISAM Internal Architecture
15-17
15.5 Subscriber interface stack on the LT board 15.6 iBridges
15-26
15-29
15.7 VLAN cross-connect mode
15-49
15.8 Protocol-aware cross-connect mode 15.9 IPoA cross-connect mode
15-56
15-61
15.10 Secure forwarding in iBridge and VLAN cross-connect 15.11 Virtual MAC
15-63
15-67
15.12 PPP cross-connect mode
15-74
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-1
15 — Layer 2 forwarding
15.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 and E-PIPE forwarding mode. Note — 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 an additional forwarding mode not really part of L2 forwarding family but still closely related: PPP cross-connect forwarding. Although PPP cross-connect mode has distinctive differences with iBridge and VLAN cross-connect, it has also similarities. See section “PPP cross-connect mode”.
15.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 15-1 shows the frame types used with their properties. Table 15-1 Frame types 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 15-1 shows an untagged and a tagged/priority-tagged Ethernet frame. Figure 15-1 Untagged and tagged/priority-tagged Ethernet frames
Untagged frame preamble
SFD
dest addr
src addr
length type
data + pad
FCS
7
1
6
6
2
46…1500
4
(priority-)tagged frame
15-2
preamble
SFD
dest addr
7
1
6
November 2013
src addr 6
802.1q tag 2
VLAN tag 2
MAC client length type
data + pad
2
46...1500
FCS 4
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
VLAN Tagging as a Means to support Virtual LAN (VLAN) The 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 15-2 shows an example of VLANs. Figure 15-2 Example of VLAN
c Ba
kb
on
e tch
i Sw 3
7 5
8
9
VLAN A
6
4
VLAN B
2 1 8
tch
i Sw 1
2
3
4
5
9
7
VLAN C
6
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-3
15 — Layer 2 forwarding
15.3
The ISAM is an Access Device The ISAM is a DSLAM type access device i.e. a device which supports the VLAN concept applied to access networks. Its basic function is to interconnect subscribers with Network Service Providers (NSP) over a public Ethernet Metropolitan Area Network (EMAN) network. Depending on the business model of the Access provider, an NSP may offer one or several Services, for instance HSI, VoIP, TV,... which subscribers want to enjoy. Consequently, the ISAM is an asymmetrical machine:
• In all practical deployments, the number of subscribers is quite larger than the number of service providers.
• By definition, the ISAM makes the distinction between interfaces facing users and interfaces facing the EMAN network side:
• Interfaces which are directly facing subscribers or which are connected to •
subtending ISAMs instantiate the so-called “User Side”. Such interfaces are generally considered untrusted, especially when facing individual subscribers. Interfaces connected to the EMAN or directly to service provider equipment (for example, BRAS) instantiate the so-called “Network Side”. Such interfaces are considered trusted. Figure 15-3 ISAM as an Access Device
NNIs
UNIs
EMAN Forwarder Instances
ISAM
Network Side
User Side
One will also note that in case of subtending ISAM, the access functionality is spread over the Hub and Subtending ISAMs. Much of the subscriber related functionality will obviously be performed in the subtending ISAM, alleviating the hub ISAM requirements to that respect. For what concerns frame forwarding, the Hub ISAM will just perform a simpler aggregation of subtending traffic. To reflect the difference in the handling of subscriber traffic vs. subtended traffic, one has introduced the notion of UNI (User Network Interface) for the links connected to individual subscribers and NNI for links connected to subtending ISAMs. Note 1 — Throughout this document and generally in all ISAM
documentation User and Subscriber are synonyms and are indifferently used. Note 2 — Even if features on UNI and NNI sometimes differ, L2
Forwarding concepts apply similarly to UNI and NNI. 15-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
Because of this asymmetry, the functions on the subscriber side are generally different from those on the network side, in particular considering privacy and security aspects. Beyond the obvious capability of terminating of DSL and PON circuits, much of the added value of the ISAM compared with utility Ethernet switches resides in its unique capability to exploit and preserve the difference between user side and network side, in particular around L2 forwarding.
Generic L2 Forwarder In a L2 access network, each NSP Service is offered on a particular network VLAN over the EMAN. The role of the ISAM is to attach every subscriber to the NSP Service(s) of their choice, that is, to the VLAN corresponding to this NSP Service in the EMAN. For that purpose, the ISAM uses a generic L2 forwarder model. In this model the ISAM associates to every NSP Service a dedicated L2 forwarder, operating within the context of this network VLAN and to which uplink(s) and subscriber(s) can be attached by means of forwarder interfaces. The basic generic L2 forwarder is shown in Figure 15-4. Figure 15-4 The generic L2 forwarder L2 Forwarder
Forwarder Identifier
(Network Vlan for the NSP Service)
NSP Server
Network VLAN for this NSP Service
Forwarding data structures
Forwarder Interfaces
E.g. FDB, PortTable, etc…
Generic L2 Forwarder EMAN
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-5
15 — Layer 2 forwarding
It makes use of the following data structures which form its operational context:
• Forwarder Identifier: This is reflecting the fact that the ISAM typically hosts several instances of L2 forwarders, one per NSP Service. Each L2 forwarder instance operates within the context of a dedicated network VLAN used to identify the forwarder. Depending on the network deployment strategy, this VLAN can be identified by one of the following:
• a single VLAN tag (say C-VLAN): this can be for instance when an NSP only provides one service, say HSI. The forwarder is then a single tag forwarder.
• a dual tag (say S+C-VLAN): this can be for instance when the S VLAN tag identifies a multiservice-NSP and the C VLAN tag identifies a given service offered by this NSP (alternate VLAN tag usage are possible as well, e.g. where the C VLAN tag identifies the individual subscriber rather than a service). The forwarder is then a dual tag forwarder (sometimes also called a stacked forwarder).
Some L2 Forwarding properties can generally be configured at L2 forwarder level (e.g. vMAC, downstream broadcast traffic enable, secure forwarding, etc.… see further) • Forwarder Interfaces: Forwarder Interfaces are the access points of the forwarder to the external world, typically the subscribers and the NSPs. It is through these Interfaces that the forwarder receives or transmits frames. Some L2 Forwarding properties can generally be configured on an individual interface basis (e.g. VLAN Translation,… see further) • Forwarding Data Structures: This is the means by which the forwarder knows to which egress forwarder interface a frame should be directed to. This data structure typically consists in an FDB (Forwarding DataBase) containing the associations between MAC address and the VLAN ports on which they were learned (or statically configured). It should be emphasized that consistent with the concept of VLAN isolation seen in section “VLAN Tagging as a Means to support Virtual LAN (VLAN)”, each L2 forwarder has its own private context. For instance, a L2 forwarder interface cannot belong to two L2 forwarders and each L2 forwarder has its own private FDB. Note — IEEE leaves the possibility open to have a shared FDB between several L2 forwarders. This sometimes is unavoidable due to hardware limitations but is typically not desirable in an access network because of the restrictions it brings.
Usage of VLANs in an “1:1” and “1:N” Access Network Deployment According to DSL Forum TR-101, an NSP VLAN can be used in 1:N or 1:1 deployment mode:
• In the 1:N mode, the NSP network VLAN is shared by a group of N subscribers. In the ISAM this deployment is supported by a L2 forwarder specialized as an iBridge. • In the 1:1 mode, the NSP network VLAN is used by only one subscriber. In the ISAM this deployment is supported by a L2 forwarder specialized as a VLAN cross-connect. 15-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
The iBridge is derived from the standard self-learning IEEE 802.1q-Bridge which makes use of destination MAC addresses lookup to discriminate subscribers from each other. A standard bridge however is not suitable for residential DSL access because it lacks a number of essential security and privacy features. Adding those features turns a standard bridge into an iBridge (also known as Intelligent Bridge). Note — In CLI and MIB and in some documentation the term Residential Bridge (RB) is sometimes used as an equivalent for iBridge.
Since the ISAM has the notion of user side and network side, it 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. On the other side, due to its very 1:1 nature a VLAN cross-connect does not rely on MAC address lookup to identify a given subscriber, the network VLAN ID is sufficient. Note however that in case of several uplinks, an FDB is still needed for the VLAN cross-connect to find out the right uplink. So actually, a VLAN cross-connect usually exhibits a bridge behavior on the network side. Although privacy is not as a concern as for iBridges VLAN cross-connects are also aware of user side versus network side for other access related features (e.g. DHCP Opt82). A typical VLAN cross-connect is shown in Figure 15-5. Figure 15-5 A VLAN cross-connect
NSP Server
Network VLAN for this NSP Service (17)
User Vlan (19)
FDB
VLAN Cross-Connect (17) EMAN
Because they are both affiliated to the same L2 Generic forwarder iBridges and VLAN cross-connect follow the same configuration model despite their differences. Moreover most of L2 access related features apply to both of them as well (e.g. VLAN translation, DHCP Opt 82, …). This will be further detailed in later sections.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-7
15 — Layer 2 forwarding
Dual-tag L2 Forwarders This section will elaborate a bit on dual-tag L2 forwarder mentioned in section “Generic L2 Forwarder”. These forwarders has the special feature that subscriber upstream frames get their single-tag outer VLAN replaced by the dual-tag VLAN of the forwarder before being forwarded to the network. Conversely dual-tagged network frames matching the forwarder dual-tag identifier will have their dual-tag outer VLAN replaced by the genuine single-tag subscriber VLAN before being passed to the subscriber. Figure 15-6 illustrates a dual-tag cross-connect (also called S+C cross-connect) Figure 15-6 Dual-Tag S+C-VLAN cross-connect
NSP Server
Dual-tag Network VLAN for this NSP Service (100,19)
FDB
User VLAN (19)
VLAN Cross-Connect (100,19) EMAN
Multi-service Configurations on the Access Link In general subscribers enjoy multiservice offering i.e. each subscriber needs to get access to different NSPs simultaneously. Consider for instance a residential end-user that is subscribed to a triple-play service offering. This end-user must be capable of accessing HSI, Video (VoD and Broadcast TV) and VoIP services over his DSL line/access link. As we told previously the role of the ISAM is to forward subscriber traffic to the right NSP VLAN on the EMAN though the corresponding L2 forwarder. The following basic question then arises: how will multi-service traffic that is originating from a residential end-user be discriminated and forwarded to the correct service-VLAN at the network side, through the correct iBridge or VLAN CC instance? Several possibilities exist upon operator's deployment preference:
• The multi-PVC model: For DSL interfaces in ATM mode it is possible to provide a separate PVC per service. Each PVC is then coupled to a L2 or L3 forwarder that gives access to the service VLAN of interest. The multi-PVC model assumes that user frames are untagged. A multiple PVC solution is often encountered with access providers that have evolved from ATM to Ethernet aggregation networks, while keeping their CPE configuration unchanged. A multiple PVC solution is also used when upstream QoS guarantees must be given for delay-sensitive applications (such as VoIP) on low-bandwidth DSL links 15-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
• Reducing the number of PVCs: protocol-based forwarding context selection In many cases, access providers want to minimize the number of PVCs used on a DSL interface to reduce operational complexity. The protocol-based model assumes that user frames are untagged. A popular scheme is the following:
• Provision a single PVC per end-user with bridged encapsulation • Deliver the HSI service through a PPPoE session that is set-up between the CPE and
• •
a central BRAS. The ISAM is capable of segregating the end-user's PPPoE traffic from the rest by applying an Ether-type filter, and will forward this PPPoE traffic in a L2 forwarder that is coupled to the “HSI” VLAN. This procedure is known as protocol-based VLAN selection Deliver IPoE-based multimedia services using another L2 or L3 forwarder, which is coupled to the “Multimedia” VLAN. The IPoE traffic is separated from the rest via Ether-type filtering as well If for some reason it is appropriate to carry multicast streams in a separate “Multicast” VLAN this can be done as well. IGMP packets sent by the end-user to join a given multicast stream are intercepted by the ISAM to perform its IGMP proxy function. For each configured multicast stream the operator can specify what network VLAN this stream originates from. This feature is referred to as cross-VLAN multicast.
• PTM/Ethernet subscriber interfaces: protocol-based forwarding context selection Protocol-based VLAN selection, being an Eth-type based segregation technique can equally be applied on PTM or Ethernet subscriber interfaces (VDSL, SHDSL or ADSLx in PTM mode, subscriber interfaces on the Eth LT). Again protocol-based VLAN selection assumes that end-user frames are sent untagged. While the use of just untagged frames on an PTM/Ethernet interface is in itself quite simple and straightforward, it also limits the number of different NSPs that can be reached by a given end-user to two (or more when cross-VLAN multicast is used). Some access providers want more control over the forwarding context selection, which they can achieve if they start using single-tagged frames on the access link. • PTM/Ethernet subscriber interfaces: the multi-VLAN model The “multi-VLAN model” refers to an architecture whereby on the access link tagged frames are used, with multiple VLAN-ids that indicate the services of interest. This is similar to the multi-PVC model on ATM-based DSL lines. Traffic tagged with different VLAN-ids is to be handled differently in the ISAM, i.e. to be forwarded via separate forwarders. An important driver for going to the multi-VLAN model on PTM/Ethernet subscriber interfaces is service wholesaling. In case of VDSL or fiber there is more bandwidth compared to the ADSL case, so it makes sense to subdivide the available BW and wholesale part of it to 3rd party service providers. In the aggregation network each 3rd party wholesale provider is given a separate VLAN, and the multi-VLAN scheme provides a flexible way of mapping end-user traffic onto these wholesale provider VLANs. The multi-VLAN model implies that VLAN-ids are present both on the subscriber-side and the network-side. Two sub-cases can be identified here:
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-9
15 — Layer 2 forwarding
• A subscriber-side VLAN-id can have network-wide significance, which means that the frame is forwarded at L2 while leaving the VLAN-id unaltered
• A subscriber-side VLAN-id can have a local significance, which means that the VLAN-id is just used to select a particular forwarder. Once this is done, the subscriber-side VLAN-id is stripped off from the packet, the forwarding decision is made and a new network-side VLAN-id is stamped onto the packet when it is transmitted on the network interface. From an end-to-end perspective this mechanism amounts to performing a VLAN translation
The multi-VLAN model offers the equivalent of the multi-PVC model in ATM, and that implies that also multicast handling is equivalent to what is offered in a multi-PVC environment. Two variants can be considered:
• The basic model, equivalent to the multi-PVC model: in this case multicast services
•
can only be offered on 1 VLAN on the user-to-network interface (UNI). The ISAM can treat 1 VLAN on the UNI as “the VLAN for IGMP”. IGMP messages coming from this VLAN are handled in the IGMP proxy, and this allows to support all the IGMP/multicast related features of ISAM identically as in case of ATM The advanced model, offering multicast services on more than 1 VLAN on the UNI. This is the equivalent of “IGMP/multicast on multiple PVCs”.
Since the ISAM supports cross-VLAN multicast, the VLAN ID on the UNI can be different from the VLAN of the multicast stream used on the uplink. • The multi-VLAN model on top of a single ATM PVC While the multi-VLAN model is most natural in case of PTM/Eth interfaces, it can be applied as well on top of a single ATM PVC. A first possible reason to choose for this model is to achieve a uniform configuration for VDSL and ADSLx access. For instance on a given VDSL LT it is possible to connect both ADSL(2+) and VDSL subscribers depending on the individual end-user's service subscription. Above the physical layer, the end-user configuration can be kept the same if multi-VLANs are used on top of a “bridge port” which is either stacked on top of a bridged encapsulated PVC or on top of the VDSL port. Another reason for using a multi-VLAN model on top of a single ATM PVC may have to do with CPE limitations: some cheaper ADSL(2+) CPEs support at most one active ATM PVC. The ISAM can support these various deployment models by means of the generic L2 concepts detailed in the next section.
The VLAN port: Supporting Concept for Multiservice Access In the previous section we have seen different possibilities for supporting multi-services on the subscriber's line. It should be noted that once the L2 service forwarder is identified, the frame forwarding process itself does not depend on the way the service was multiplexed on the subscriber's line, by means or multi-PVC, multi-VLAN or both. To reflect this, the concepts of VLAN port and bridge port have been introduced in the ISAM, which form a common denominator for all the different service multiplexing methods.
15-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
More specifically, VLAN ports, bridge ports and some additional objects are defined as follows:
• bridge port: a bridge port is a generic Ethernet interface. In practice, a bridge port can be a PVC carrying Ethernet, an EFM link or a physical user Ethernet link. A bridge port can carry a mix of untagged, priority-tagged or tagged frames. Note — Despite the name, in ISAM, a bridge port is not related to a specific iBridge! A better name for bridge port would have been virtual Ethernet port!
• VLAN port: a VLAN port is a generic tagged Ethernet interface on a bridge port, more specifically it is only related to the frames tagged with a specific VLAN ID on this bridge port. In the ingress direction, a VLAN port can be best seen as picking-up frames with a specific VLAN tag received from the bridge port. For all practical purposes, a VLAN port is the ISAM implementation of the L2 Forwarder Interface introduced in section “Generic L2 Forwarder”. Tagged frames received by the ISAM which cannot be related to any configured VLAN port are discarded. Note — The ISAM allows to configure the TPID (802.1q tags) used on each network interface, from a set of four possible values per ISAM.
• 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. • Port Protocol Default VLAN ID (ProtocolVID): A bridge port can be configured with a Protocol VLAN ID. A ProtocolVID has the same purpose as a PVID except that it takes into account the Ethertype of the packet. In practice, the ISAM operator can configure up to three port-Protocol-VLAN IDs per bridge port:
• One ID per PPP • One ID for IPv4 and related protocols (for example, ARP) • One ID for the IPv6 When a PPP (respectively IPv4, IPv6) protocol VLAN ID is configured on a bridge port, all untagged or priority-tagged PPP (respectively IPv4, IPv6) frames will be considered as if tagged with this VLAN ID. Like the PVID, the ProtocolVID has only relevance for iBridging or VLAN cross-connect. When a PVID and Port-Protocol-VLAN ID(s) are both configured on a given bridge port and an untagged frame is received, the ISAM always selects the ProtocolVID if the protocol type matches.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-11
15 — Layer 2 forwarding
• PVID tagging flag: This is a parameter that can be configured at bridge port level, for the GPON LT. It indicates whether the ONT or the OLT should perform the operation of adding the PVID for the untagged and priority-tagged traffic. By default this is done by the ONT. Note that PVID handling at the LT has certain restrictions:
• protocol-based PVID is not supported; • it does not support S-tunnel iBridge and S-tunnel cross-connect; • certain p-bit marking/remarking options are also not supported (for example there is no support for DSCP to p-bit alignment).
So in summary, a L2 forwarder interacts with the external world, i.e. subscribers and EMAN by means of VLAN ports, whatever line technology is used (PVC, EFM, Ethernet, and so on) and whatever L2 forwarder type, iBridge or VLAN cross-connect. In Figure 15-7 below, one VLAN port is created for each service on a given subscriber's line. Figure 15-7 L2 multiservice by means of VLAN ports
VlanPort L2 Fwd1 NSP1
BridgePort
VLAN 1
NSP2
VLAN 2
L2 Fwd2
EFM
VLAN 3
NSP3
EMAN L2 Fwd3
Figure 15-8 illustrates some examples on how VLAN ports and bridge ports help to make abstraction of the line transport technology and frame encapsulation.
15-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding Figure 15-8 VLAN ports hiding the line transport technology
VlanPort
BridgePort
PVC
Phy Line
PVID
Untag_Serv1
PVID
Untag_Serv2
PVID
Untag_Serv3
IP-VID
Untag_Serv1 (IP) Untag_Serv2 (PPP) Untag_Serv3 (other)
PPP-VID PVID
Tag_Serv1 Tag_Serv2 Tag_Serv3
IP-VID
EFM Tag_Serv1 Untag_Serv2 (PPP) Untag_Serv3 (other)
PVID
An interesting feature of this generic L2 forwarding model is VLAN translation by which subscribers can access an NSP using frames tagged with another VLAN than the NSP VLAN. Obviously, de-coupling user VLAN from network VLAN allows more flexibility in terms of network deployment: VLAN ID values may be locally assigned at the user side CPE without being constrained with the VLAN ID values used within the EMAN. In particular, this makes flexible wholesaling possible without local CPE (re)configuration. Assume for instance a deployment where all subscribers have a CPE hard coded with a given VLAN ID for HSI service. Assume also that the access provider wants to offer subscribers the choice between competing NSPa and NSPb for HSI service, on a subscription basis. VLAN translation allows the access provider to do that without reconfiguring CPE VLANs: selecting the right NSP per subscriber will be done in the ISAM by translating each subscriber VLAN to the proper NSP VLAN.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-13
15 — Layer 2 forwarding
The configuration of S+C-VLAN cross-connects, (see section “S+C-VLAN cross-connect: VLAN stacking for residential subscribers”) uses an extreme case of VLAN translation: a user single-tag VLAN ID say “CLocal” is translated into a network dual-tag VLAN ID say “SNetwork+CNetwork”. As an example, CLocal could be the same for all users hard coded in their CPE, while CNetwork could carry the identity of each subscriber and SNetwork would carry the identity of the NSP. Note that with VLAN translation capabilities on the user side, there is no point to support VLAN translation on the network side. As indicated in previous sections, although multi-VLAN originally came from the requirement to support multi-services above VDSL, P2P ETH and GPON/EPON 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.
Configuration Scenario Example for Multiservice Deployment So to summarize the previous sections, the L2 processing of a frame in the ISAM can be, roughly speaking, partitioned in three stages for both the upstream and downstream direction:
• User/subscriber side processing • L2 forwarding itself and • Network side processing
15-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
This partitioning is handy to deal with the ISAM functional asymmetry emphasized at the beginning of section “The ISAM is an Access Device”
• Subscriber side processing: This involves the functions related to VLAN ports on the user side. Depending on configuration:
• support of various underlying user frame encapsulation types, e.g. Ethernet PVCs, Ethernet VDSL EFM, Ethernet Phy, IPoA PVC, PPPoA PVC,...
• support of various VLAN tagging mode: untagged, priority tagged, single tagged or multiple tagged
• User VLAN tag manipulations: preserve/translate user VLAN IDs, add (upstream)
• •
or remove (downstream) an extra VLAN tag to a specific user frame. Note: these VLAN translations are not supported on the GE Ethernet LT NNI interfaces. IPoA to IPoE conversion (see further). find out which forwarder instance a received upstream frame has to be submitted to. This takes place by matching the frame VLAN tag(s) to a VLAN port configured on the bridge port on which the frame has been received.
Of course, the ISAM performs additional functions on the user side but they are considered outside the scope of this Chapter because not related or only indirectly related to L2 Forwarding:
• subscriber management related functions like Opt 82, PPP relay tag, QOS, Filters,… • redundancy mechanisms like Link Aggregation, Spanning tree,... • L2 Forwarding: The role of the L2 forwarder is essentially to decide on which outgoing forwarder interface(s) an ingress frame has to be sent out. Naturally the iBridge and VLAN CC use different mechanism to forward frames. • Network side processing: This involves the functions related to VLAN ports on network side:
• The ISAM only supports Ethernet frames on the network side: they can be single• •
or multiple-tagged (untagged and priority tagged frames are normally never deployed). Finding-out which L2 forwarder instance a received downstream stream frame has to be submitted to. Note that no VLAN translation is supported on the network side
Of course, the ISAM performs additional functions on the network side but they are considered outside the scope of this FD because not related or only indirectly related to L2 Forwarding:
• Termination/Relaying of various subscriber or network related protocols (GMP, DHCP, PPPoE, Routing protocols, OAM, Link aggregation, Spanning Tree …) • QoS-related functions To conclude, here is a typical scenario for an operator to establish the connectivity between subscribers and NSP Servers:
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-15
15 — Layer 2 forwarding
for each NSP, create an iBridge or VLAN cross-connect L2 Forwarder associated to the VLAN of the NSP:
• attach network uplinks to the L2 Forwarder(s) (see further for details) • create a bridge port on every user PVC/EFM (a Bridgeport is shared by all services) • attach subscribers to L2 Forwarder(s) by creating on each subscriber's bridge port a VLAN port corresponding to each L2 Forwarder. If necessary, the operator has the possibility to create a VLAN port translating a user VLAN ID into the L2 Forwarder VLAN ID. • If untagged frames are expected on a bridge port the operator can configure a PVID or ProtocolVlanId on this bridge port referring to the VLAN port to be used when the frame is received. Figure 15-9 shows an example of multi-VLAN access with VLAN 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, P2P ETH and GPON/EPON subscriber access lines. Figure 15-9 Multi-VLAN and VLAN translation example BrPort
VlanPorts
VlanPorts Tr
GE1-VLAN1
NSP1
MAC FDB
Tr
iBridge
Tr
Tr GE1-VLAN2
NSP2
MAC FDB
iBridge
Tr Tr
PVC1 PVC2-VLAN1 EFM1-VLAN1
PVC3-VLAN17
GE1-VLAN4
GE1-VLAN5
NSP5
EMAN
PVC3
DSL Phy
DSL Phy
EFM1-VLAN2 EFM1
GE1-VLAN3
NSP4
PVC2
PVC2-VLAN2
Eth Phy NSP3
BrPorts
PVC1-VLAN1
Vlan CC
Tr
EFM1-VLAN3
Vlan CC
Tr
EFM2-VLAN34
Vlan CC
Tr
EFM2-VLAN5
EFM2
DSL Phy
DSL Phy
ISAM
Use of MPLS encapsulation in the ISAM generic forwarding model The MPLS technique is an interesting alternative to connecting the ISAM to the NSP. With MPLS, the ISAM reaches a given NSP via an MPLS pseudo-wire rather than via a network VLAN dedicated to the NSP. Actually the introduction of MPLS does not change the generic forwarding model presented above, it just adds another network encapsulation possibility. For more details on MPLS see chapter “MPLS”. The use of MPLS on the network side is illustrated in Figure 15-10.
15-16
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding Figure 15-10 MPLS as network encapsulation technique
T
MPLS_PW1 NSP 1
VLAN ports
MAC FDB
T T
iBridge
T
MPLS_PW2 NSP 2
MPLS_PW3 NSP 3
MPLS_PW4 NSP 4
MPLS_PW5 NSP 5
VLAN MAC ports FDB iBridge
T
VLAN CC
T
VLAN CC
T
VLAN CC
T
MPLS network (overlayed on EMAN)
15.4
T
Ethernet Ethernet Ethernet
Ethernet
PVC1_VLAN1 PVC2_VLAN1 EFM1_VLAN1 PVC1_VLAN2
Ethernet
PVC3_VLAN17
Ethernet
EFM2_VLAN2
Ethernet
Ethernet
Ethernet
EFM1_VLAN3
EFM2_VLAN34
EFM1_VLAN5
ISAM
ISAM Internal Architecture
L2 forwarding on the NT board and the LT boards 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 15-13. Note — Figure 15-13 does not show the VLAN translation capability on the user side of the LT board.
The distributed Layer 2 forwarding in ISAM also applies to GPON access solutions. In this case, the GPON OLT - ONT sub-system is acting as a single ISAM LT entity. This is shown in Figure 15-11.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-17
15 — Layer 2 forwarding Figure 15-11 Distributed Layer 2 Forwarding in ISAM (GPON OLT-ONT)
VDSL LT
NT xDSL GLT-ONT Eth OLT
ONT
CES POTS
The distributed Layer 2 forwarding in ISAM also applies to EPON access solutions. In this case, the EPON OLT - ONT sub-system is acting as a single ISAM LT entity. This is depicted in the Figure 15-12. Figure 15-12 Distributed Layer 2 Forwarding in ISAM (EPON OLT-ONT)
xDSL Eth
ISAM LT
POTS
xDSL GPON LT-ONT Eth NT
OLT
ONT
CES POTS
Black-box mode
EPON OLT
EPON ONT
xDSL Eth POTS
White-box mode
15-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding Figure 15-13 Layer 2 Forwarding in ISAM
L2 Fwdr NSP A
L2 Fwdr NSP B L2 Fwdr NSP A
Phy
LT
L2 Fwdr NSP A
Phy L2 Fwdr NSP B
L2 Fwdr NSP B
NT LT ISAM
The basic strategy for the layer 2 forwarding data plane is that:
• When subscribers are connected to LT boards (directly or via the ONT), 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 (directly or via the ONT). • It is the LT board that implements the difference between the VLAN cross-connect, the iBridge mode and the stacked iBridge mode. The NT board behavior is identical for the iBridge and VLAN cross-connect. Note — When MPLS pseudo-wires are used on the network side, the NT board can be optimized to directly support cross-connect forwarding (called E-PIPE service) next to the regular iBridging (VPLS service)
• The LT board translates user VLAN into network VLAN (optionally). In case of GPON access, there are two alternative modes for VLAN translation:
• ‘Remote' translation: the ONT translates user VLAN into network VLAN • ‘Local' translation: the GPON LT translates user VLAN into network VLAN The configuration of remote or local translation mode is possible at the ONT level. The default mode is remote translation, that is, VLAN translation performed at the ONT. Note — When a VPLS is used (for example, to support MPLS pseudo-wires on the network side), the NT board is also able to translate user VLANs.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-19
15 — Layer 2 forwarding
• The NT board behaves as much as possible as a standard bridge (except when it performs E-PIPE forwarding). 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. • In some cases, the operator only wants to accept single-tagged Ethernet frames from end-users. This is possible by combining VLAN handling on the LT board with additional filtering on the NT board. The LT board can be configured to use a forwarding model that adds a second tag to the incoming customer traffic (for example, S/C VLAN cross-connect). By attaching the VLAN to an SAP on a VPLS, the NT board can be configured to only accept Ethernet frames having 2 C-VLANs (using Ethertype 0x8100). If the user sends untagged traffic, it will arrive at the NT board as a single-tagged frame and will be discarded. • The NT board and the LT board (in case of GPON, OLT and ONT) 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 (for example, BRAS) instantiate the so-called “network side”. Such ports are considered trusted. With the notion of User side and Network side, the NT board 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 (with pseudo-wire or direct VLAN encapsulation) can be passed:
• back to the network side possibly on the same physical interface but using another pseudo-wire or direct VLAN encapsulation (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.
15-20
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
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 thereby allowing inter-LT traffic forwarding. Up to 10 VLAN per NT can support communication from user side back to user side. Note 3 — The operator can enable communication from user side
back to the same user side (that is, the same LT board) for the VLAN supporting communication from user side back to user side. This system level provisioning command allows intra-LT traffic forwarding. When this voice services feature is used, the operator must also invoke secure-forwarding on the LT (see “Secure forwarding in iBridge and VLAN cross-connect”). Obviously, when the network VLAN is directly mapped to an NSP, 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. When a frame is received from a pseudo-wire, it is the inner VC label that defines the NT bridge instance. 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 15-14. Figure 15-14 Subtended network elements UNI port L2 Fwder NSP A
L2 Fwder NSP B L2 Fwder NSP A
UNI port
LT
L2 Fwder NSP A L2 Fwder NSP B
L2 Fwder NSP A
L2 Fwder NSP B
NT
L2 Fwder NSP A
L2 Fwder NSP B
L2 Fwder NSP B
LT
LT
NT
ISAM
Subtended ISAM
NNI port
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-21
15 — Layer 2 forwarding
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. Note — On the Ethernet LT, two variants of the UNI interface exist:
the so-called UNI and the High Capacity UNI (HC-UNI). The HC-UNI provides higher throughput at the price of a reduced feature set. Differences are detailed into the Product Information document.
• 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 with Direct Network VLAN Encapsulation
When the network VLAN is directly mapped to a given NSP, the NT makes use of a special type of VPLS, the VLAN-VPLS (v-VPLS). The v-VPLS emulates the behavior of a VLAN bridge. The main difference with a usual VPLS is that all Service Access Points (SAPs) of a v-VPLS must be defined with the same VLAN ID, that is, the NSP VLAN. Also, a v-VPLS is not able to support MPLS pseudo-wires. Figure 15-15 iBridge with direct network VLAN encapsulation
Regular Ports
RB VLAN 19
v-VPLS on v-VPLS Residential network VLAN SAPs Ports
RB VLAN 23 v-VPLS VLAN 19
Phy
LT
RB VLAN 19
Phy v-VPLS VLAN 23
RB VLAN 23
NT_IHUB LT ISAM_IHUB
15-22
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
To configure a bridge for a given VLAN in the NT, the operator needs to:
• Create a v-VPLS operating in this VLAN • Configure SAPs on this v-VPLS for each appropriate Regular or Residential port VLAN Cross-connect Configuration Model with Direct Network VLAN Encapsulation
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 15-16. Figure 15-16 VLAN Cross-connect with direct network VLAN encapsulation
C 11
v-VPLS VLAN 11
v-VPLS VLAN 17
VLAN CC
S17 +C23 VLAN CC
C-VLAN CC
S+C-VLAN CC
LT (No VLAN translation shown on user side)
v-VPLS VLAN 13
S17 +C29 VLAN CC
S 13
v-VPLS VLAN 19
VLAN CC
S+C-VLAN CC
S-VLAN CC
LT NT C-, S+C- or S-VLAN CC
ISAM
Note — The different types of VLAN cross-connect (C-VLAN, S+C-VLAN and S-VLAN) are explained further in this chapter.
iBridge or VLAN Cross-connect Configuration Model with MPLS Pseudo-wire Encapsulation
When the MPLS pseudo-wire encapsulation is used on the network side, the NT board needs to make use of a general VPLS. Figure 15-17 shows the case of a wholesale access provider.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-23
15 — Layer 2 forwarding Figure 15-17 iBridging using with MPLS pseudo-wires towards the NSP
Network ports
VPLS
VPLS SAPs
RB VLAN 19
Residential access ports
RB VLAN 23 Phy
NSP_a
PW
VPLS NSP_a
LT
MPLS tunnel NSP_b
RB VLAN 19
Phy
VPLS NSP_b
Wholesale provider access point
RB VLAN 23
NT Mapping of MPLS tunnel on physical network port is not shown
LT ISAM
Generally speaking, similar to the direct Network VLAN encapsulation, the iBridge configuration model is applicable as well to the case of VLAN cross-connect except for the LT configuration. The case of C-VLAN can however be optimized as shown in section “VLAN Cross-connect Configuration Model with MPLS Pseudo-wire Encapsulation and E-PIPE”. Note — It is not possible to combine an MPLS pseudowire with
another VLAN bridged or IP routed service on the same physical port.
VLAN Cross-connect Configuration Model with MPLS Pseudo-wire Encapsulation and E-PIPE
An alternative configuration model is possible for the C-VLAN and S-VLAN cross-connect modes as shown in Figure 15-18. These cases make use of the E-PIPE forwarder in the NT board.
15-24
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding Figure 15-18 C- and S-VLAN cross-connect with MPLS pseudo-wires and E-PIPE
Network ports
Phy
NSP_a
EPIPE
PW
EPIPE SAPs
Residential access ports
C-VLAN CC VLAN 19
LT
EPIPE NSP_a
MPLS tunnel NSP_b
Phy
EPIPE NSP_b
Wholesale provider access point
S-VLAN CC VLAN 23
NT Mapping of MPLS tunnel on physical network port is not shown
LT ISAM
Full Bridge Emulation for Business Customer
This is a special case of VPLS usage where an unrestricted L2 connectivity is provided between business customers and with the network. Network access can be realized by means of a pseudo-wire or by means of a direct Network VLAN encapsulation. In this mode, both the user side and the network side are considered equally trusted. In particular, there is no restriction for MAC address relearning in contrary to the iBridge forwarding based on v-VPLS (see for instance section “MAC address learning on the NT board”). Figure 15-19 Full Bridge emulation (direct Network VLAN encapsulation shown) LT 1 NT
VLAN 1
VLAN-CC DSL
VPLS
VLAN x
LT n
VLAN-CC
VLAN 2
VLAN-CC
VLAN 3
DSL
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-25
15 — Layer 2 forwarding
15.5
Subscriber interface stack on the LT board The ISAM can receive user frames from ATM PVCs (ADSL), EFM (VDSL), ONT UNI or Ethernet Physical interfaces on the LT board.
Frame Encapsulation on PVCs ATM 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 a 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. 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 single encapsulation only is allowed on the PVC. This is called static encapsulation mode. Only the frames matching this encapsulation will be accepted. • several encapsulations 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.
15-26
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
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 (that is, for IPoA) cannot be detected in this mode. 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.
Attaching subscribers to iBridges and VLAN cross-connect forwarders VLAN ports are always used to attach subscribers to iBridges and VLAN cross-connect, as shown in Figure 15-20. 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 15-20 shows the subscriber access interface model. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-27
15 — Layer 2 forwarding Figure 15-20 Subscriber access interface model for iBridges and VLAN cross-connect
Of frame tag or PVID if untagged frame
VLAN port Bridge port PVC
EFM
ATM ADSLx VDSLx Eth Phy
VLAN port (from PVID)
Managed by IWL
Bridge port UNI
PVC
ONT
ATM
PON
ADSLx
PPPoE or IPoE Frames
IPoA Frames
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). This requirement is to allow some room to add protocol overhead to upstream user frames, in function of the forwarder used. Note — The requirements for large MTU do not make a distinction between the network and the user side. Of course, frames from the user side which are for instance encapsulated with MPLS should be smaller than the allowed maximum. Figure 15-21 Support for Jumbo frames
3, 4 DSL line specific
Ethernet MAC
larger subscriber Ethernet payload
DA, SA, SA Qtags, Type/Length, FCS
Edge
1 Ethernet MAC (with additional VLAN tags)
2 MPLS & other blue sky
3, 4 larger subscriber Ethernet payload
DA, SA, Qtags, type/length, FCS
Scope of jumbo frames: 1. To cope with more VLAN tags being added on network side 2. To cope with additional encapsulating protocols, for example, MPLS on network side 3. To cope with user having larger payload data 4. NOT to cope with user having larger payload control
15-28
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
15.6
iBridges For the sake of clarity, this section only considers the case of network VLAN encapsulation directly mapped to NSP. This discussion can however be generalized to the cases where MPLS pseudo-wire encapsulation is used instead. In alignment with customer-evolving deployment models, the ISAM platform also supports a stacked VLAN iBridge mode in addition to the original single tagged network VLAN. The ISAM with a stacked VLAN iBridge mode can perform bridging operations and can also add/remove a VLAN header to the customer upstream / downstream traffic. This allows support of different broadband access solutions. Examples of use cases for stacked VLAN iBridge mode:
• The outer-tag (S-TAG) represents the NSP, while the inner-tag (C-TAG) represents the NSP-Service; or
• The outer-tag (S-TAG) represents the AN PON port, while the inner-tag (C-TAG) represents an NSP-Service for a specific user; or • The outer-tag (S-TAG) represents the AN PON port, while the inner-tag (C-TAG) represents the end-customer ONT. A stacked VLAN iBridge is considered to be a VLAN aware bridge, where each N:1 VLAN (S-Bridge) is a separate Virtual Bridge (VB) instance. Each VB performs independent source MAC address learning and frame forwarding processing. The ISAM with a stacked VLAN iBridge offers two modes of operations:
• S+C iBridge; and • S-iBridge The S+C iBridge mode allows C-VLAN tag operations, such as C-VLAN translation, in addition to adding/removing an S-VLAN header. This forwarding mode requires the operator to configure a VLAN port for each C-VLAN. The S-iBridge mode supports two sub-modes of operation:
• S-Tunnel iBridge mode • S-VLAN mapped mode. The S-Tunnel iBridge mode allows the operator to minimize provisioning by creating a tunnel VLAN port on a specific bridge port. On this bridge port all tagged / untagged customer frames which match the tunnel VLAN port are encapsulated by an S-VLAN header.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-29
15 — Layer 2 forwarding
The S-VLAN mapped mode is used on Hub-ISAM NNI ports. See “VLAN tagging modes in the iBridge (Hub-ISAM LT NNI ports concept)” for further details. Note 1 — The GPON line board allows the same S-VLAN ID to be
shared between an S-iBridge and S+C iBridge or S+C cross-connect. The EPON line board also supports sharing between an S-iBridge and S+C iBridge. For other interfaces, S-VLAN ID cannot be shared between S+C iBridge and S- iBridge. Note 2 — The S-tunnel iBridge mode is currently supported on
GPON and EPON access solutions. It is also supported on the NNI ports of the GE Ethernet line board. Note 3 — The S-VLAN mapped mode is supported on the NNI ports
of both the GPON line board and the GE Ethernet line board.
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 — DHCP option 82 is not supported on traffic received on hub-ISAM NNI ports for the GE Ethernet line board. The remote aggregator access node (connected to the hub-ISAM) will perform such function if required. Note however that DHCP option 82 is supported for NNI ports on the GPON line board. Network side and subscriber side
The iBridge and stacked iBridge mode make 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. Note 1 — The ability to allow subscriber-to -subscriber traffic is
configurable on the NT. Note 2 — For GPON and EPON access, it is not recommended to
configure subscriber-to-subscriber traffic switching in conjunction with allowing downstream network broadcast (see “Prevention of broadcast problems”). This behavior is also true when the iBridge mode is used to forward traffic from Hub-ISAM LT NNI ports: All upstream traffic will be sent towards the network and never to another NNI port.
15-30
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
Prevention of broadcast problems
To prevent broadcast storms, the amount of broadcast traffic on each port can be controlled. 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. Note 1 — This behavior is also true for stacked iBridge modes. Note 2 — For GPON access, when configured to do so, the broadcast
frames from the network will be broadcasted to all users. There are two modes available for sending the broadcast:
• Mode 1. The broadcast packet is transmitted on via a dedicated transport channel, the so-called “incidental multicast GEM port”. This normally does not require replication of the packet. However, in the case that VLAN translation is performed by the LT, it will be necessary to replicate the packet for each unique user-side C-VLAN. • Mode 2. The broadcast packet is replicated for each member port of the VLAN, with each copy of the packet being transmitted on a dedicated GEM port belonging to a member port. A configurable option exists at the forwarder level to select between these two modes, with use of the incidental multicast GEM port being the default. In both modes, the broadcast traffic is placed on the dedicated incidental broadcast/multicast queue on the PON. It is possible to configure a shaper on this queue so that incidental broadcast/multicast traffic can be rate limited. Note 3 — For EPON access, upstream broadcast will be forwarded
both in iBridge and cross-connection mode. Downstream broadcast will only be forwarded in cross-connection mode. This means that in iBridge mode the downstream broadcast is blocked. Also broadcast as a consequence of flooding, which happens with standard bridging when the MAC DA is unknown is typically not done towards the subscriber side. Note — With EPON access, the operator can configure on a per network VLAN basis flooding of unknown MAC destination addresses.
In context of Hub-ISAM LT NNI ports, all NNI upstream broadcast traffic will be sent towards the network and never to another NNI port. Broadcast from the network is passed to all NNI ports. This behavior is not configurable for NNI ports. Downstream unicast traffic is also passed to all NNI ports when the MAC DA is unknown. Again, this behavior is not configurable.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-31
15 — Layer 2 forwarding
Multicast Protocols forwarding control
In context of GPON access solutions, to take full advantage of the point to multi-point topology of the GPON network, the iBridge mode does support multicast forwarding optimization. Configured on a per VLAN basis, multicast traffic (from the network to the subscriber port and from the subscriber port to the network) is either passed to all ports or blocked on the subscriber ports, depending on the type of multicast traffic. (Here we discuss the 'incidental' multicast traffic, for example related to certain protocols, rather than the multicast video traffic which is typically controlled via IGMP.) When configured to do so, the multicast frames from the network will be broadcasted to all users. As for the handling of broadcast packets (see “Prevention of broadcast problems”), there are the two modes available: using the incidental multicast GEM port, or using the dedicated GEM port of each member port in the VLAN. As for the broadcast traffic, the multicast traffic is placed on the dedicated incidental broadcast/multicast queue on the PON, and there exists the option to shape this queue. The following different multicast protocols forwarding controls are possible:
• • • •
Allow, upstream and downstream, IPv4 multicast traffic on user ports Allow, upstream and downstream, IPv6 multicast traffic on user ports Allow, upstream and downstream, Ethernet multicast traffic on user ports Allow, upstream and downstream, Protocols specific multicast traffic on user ports Note — For stacked iBridge forwarding modes, all multicast protocol forwarding controls are based on the S-VLAN iBridge. Therefore, in case of an S+C iBridge mode, all C-VLAN vlan ports will have a unique common behavior inherited from the parent S-VLAN ibridge.
IPv4 multicast traffic control
This feature allows upstream multicast IPv4 traffic, and flood downstream IPv4 multicast traffic. The frames that are affected are in the following MAC address range: Dest MAC: 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF, insofar there is no IGMP managed tree, see chapter “Multicast and IGMP”. Note — Protocol Specific Multicast traffic control offers a more granular control for some specific multicast frames. See “Protocol Specific Multicast traffic control”
This control is ignored for NNI ports, in which case the behavior depends on whether there is any multicast VLAN configured on the NNI port. If no multicast VLAN is configured, then IPv4 multicast traffic will be forwarded. If a multicast VLAN is configured, then IPv4 multicast traffic will be forwarded according to the multicast tree structure (i.e. if the corresponding multicast stream has been joined on the NNI port). Note however that group addresses in the range 224.0.0.0/24 will always be forwarded.
15-32
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
IPv6 multicast traffic control
This feature allows upstream multicast IPv6 traffic, and flood downstream IPv6 multicast traffic. The frames that are affected are in the following MAC address range: dest MAC: 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF. This control is ignored for NNI ports where IPv6 multicast traffic is always forwarded. Ethernet multicast traffic control
This feature results in flooding downstream Ethernet multicast traffic. The frames that are affected are frames with the lowest significant bit set to 1. Example of these frames are L2 IS-IS frames. Note — This feature will not affect Broadcast, L2 Control Protocol, IPv4 Multicast and IPv6 Multicast frames.
This control is ignored for NNI ports where Ethernet multicast traffic is always forwarded. Protocol Specific Multicast traffic control
This feature allows upstream protocol specific multicast traffic, and flood downstream protocol specific multicast traffic. The following specific Multicast protocols supported are:
• NTP multicast protocol frames using the IPv4 multicast frame format • RIP multicast protocol frames using IPv4 multicast frame format. Note — When the Protocols Specific Multicast control is not enabled,
the forwarding behaviors of all IPv4 Protocol multicast frames are controlled as per “IPv4 multicast traffic control”. This control is ignored for NNI ports where protocol specific multicast traffic is always forwarded. Upstream Frame types accepted by iBridges
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 Note — Neighbor Discovery and ICMPv6 are identified by a Next Header value of 58 in the immediately preceding IPv6 header
• PPPoE (discovery and session) Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-33
15 — Layer 2 forwarding
• • • • •
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 upstream frames, including multicast data frames, will be discarded (see section “Protocol Specific Multicast traffic control” on multicast traffic control). 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) • PPPoE • all Ethernet types Other frames, including multicast data frames, 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 15-22 details this scenario:
• 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.
15-34
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding Figure 15-22 VLAN with two ISAMs ISAM 1
A
EMAN B
VLAN NSP NSP IP backbone
Not allowed
C
ISAM 2
An operator may still choose to deploy such a configuration for VLAN scalability reasons. In these scenario's care must be taken to prevent undesirable user-to-user traffic by:
• enabling split horizon functionality in aggregation network, or • enable vMAC on ISAMs and use vMAC filters at the ISAM to discard ingress network traffic with vMAC source addresses. Hub-ISAM LT NNI iBridge deployment example
As described in “L2 forwarding on the NT board and the LT boards”, 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 or the GPON line board. As shown in Figure 15-23, 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-35
15 — Layer 2 forwarding Figure 15-23 Hub-ISAM with iBridge UNI
UNI
NNI
NSP IP Backbone
E F
S-ISAM 1
EMAN
UNI
UNI
NNI
S-ISAM 1
UNI
UNI
Hub-ISAM
A B
C D
Remote Aggregator (subtended ISAM)
Note — The Hub-ISAM can also perform local access and access aggregation, as shown in Figure 15-23.
MAC learning In 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 has 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. 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 residential (user) port but the number of MAC addresses already learned on that service has reached a certain maximum, the MAC address is not learned and the frame is dropped. Note — The MAC learning mechanism can be disabled to allow, for example, an unlimited number of MAC addresses in case of cross-connect mode.
• If the MAC address is learned from a residential 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 residential port, but the same MAC address was already on another residential port, the new MAC address is not learned and the frame is dropped (MAC address duplication).
15-36
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
• If the MAC address is first learned on a residential 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 residential port (MAC address movement, that is, the last learned MAC address takes priority). • If the MAC address is first learned on a subtending, user or internal LT port and then on another subtending, residential 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 residential (user) 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 and ONT UNI, the limit is applied per interface. The way this protection is implemented depends on the LT board type:
• On layer 2+, point-to-point Ethernet and EPON/ ONT LT boards, this protection allows the operator to configure a maximum per port and this maximum is also committed. On NNI interfaces, the maximum number of MAC addresses is not committed. • On layer 2, layer 3 and GPON/ONT 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. • Additionally, for the GPON ONT, it is possible to configure a limit per VLAN port. In this case, the limit on the ONT UNI is also applied. That means a MAC address will only be learned if the limit has not been exceeded on the VLAN port AND the limit has not been exceeded on the UNI. 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. Note that, for GPON, the committed number of MAC addresses can only be configured at the UNI level, not at the VLAN port level. 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-37
15 — Layer 2 forwarding
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, point-to-point Ethernet, EPON/ ONT and GPON/ONT 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 port concept is currently supported on the GE Ethernet LT •
board and the GPON line board. 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.
The GPON LT also supports enabling of MAC movement within the same LT. Enabling or disabling of MAC movement can be configured per iBridge, with the default being 'disabled'. The feature is useful to allow a wireless device to move from one UNI to another within a Wi-Fi 'hot spot'. MAC movement is not permitted between LTs. Movement is only permitted for dynamically learned MAC addresses, statically configured MAC addresses are not permitted to move. When MAC movement is performed, the MAC address is deleted from the old port and relearned on the new port. In this case no duplicate MAC alarm is raised. Note — MAC addresses are never learned for VLAN cross-connects configured on HC-UNI ports and NNI ports of the Ethernet LT, and this independently of the MAC learning mode defined at the interface level. This allows for:
• maximum scalability for business user and/or subtending applications
• combining bridging and VLAN cross-connects on the same interface, while keeping the VLAN cross-connect fully transparent for MAC addresses MAC aging time
A MAC address that was previously learned on a given L2 forwarder is automatically removed from the MAC forwarding table of that L2 forwarder when no traffic has been received from that MAC address during the MAC aging time.
15-38
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
It is important that the MAC aging 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 with secure forwarding and ARP relay enabled, 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. 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.
A MAC aging time can be configured per L2 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-39
15 — Layer 2 forwarding
VLAN tagging modes in the iBridge Forwarding of untagged/priority-tagged frames received from the subscriber Figure 15-24 Forwarding untagged/priority-tagged frames in an iBridge (iBridge shown with only one subscriber) Network-side traffic
Configured VLAN ports
User-side traffic Bridge port BP1
Ut,C1
VLAN port (BP1/ 0,C1) Ut,Ut
iBridge (C1)
BP1:PVID = 0,C1 Si,X (any i) or Ut,Cj (j ≠ 1)
Legend for traffic characterization: Ut,C1 means S-VLAN = untagged and C-VLAN = C1 S1,X means S-VLAN = S1 and C-VLAN = do not care (tagged or untagged) Ut,Ut means no S-VLAN, no C-VLAN Legend for VLAN port configuration: 0,C1 means a C-VLAN port S1,0 means an S-VLAN port
15-40
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding Figure 15-25 Protocol-based VLAN selection (iBridge shown with only one subscriber) Network-side traffic
Configured VLAN ports
User-side traffic Bridge port BP1
Ut,C1
VLAN port (BP1/ 0,C1) Ut,Ut
iBridge (C1)
BP1: IPoE VID = 0,C1 PPPoE VID = 0,C2
Ut,C2 iBridge (C2)
VLAN port (BP1/ 0,C2)
Si,X (any i) or Ut,Cj (j ≠ 1,2)
Legend for traffic characterization: Ut,C1 means S-VLAN = untagged and C-VLAN = C1 S1,X means S-VLAN = S1 and C-VLAN = do not care (tagged or untagged) Ut,Ut means no S-VLAN, no C-VLAN Legend for VLAN port configuration: 0,C1 means a C-VLAN port S1,0 means an S-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.
Forwarding of C-VLAN tagged frames
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 15-26. 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-41
15 — Layer 2 forwarding
• 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 15-27. Note — VLAN translation is not supported on Hub-ISAM LT NNI ports.
Figure 15-26 Subscriber-side VLAN-IDs with a network-wide scope (iBridge shown with only one subscriber) Network-side traffic
Configured VLAN ports
User-side traffic Bridge port BP1
Ut,C1
iBridge (C1)
Ut,C2 iBridge (C2)
VLAN port (BP1/ 0,C1)
Ut,C1
VLAN port (BP1/ 0,C2) Ut,C2 BP1: no PVID Si,X (any i) or Ut,Cj (j ≠ 1,2) or Ut,Ut
Legend for traffic characterization: Ut,C1 means S-VLAN = untagged and C-VLAN = C1 S1,X means S-VLAN = S1 and C-VLAN = do not care (tagged or untagged) Ut,Ut means no S-VLAN, no C-VLAN Legend for VLAN port configuration: 0,C1 means a C-VLAN port
15-42
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding Figure 15-27 Support for VLAN translation (iBridge shown with only one subscriber) Network-side traffic
Configured VLAN ports
User-side traffic Bridge port BP1
Ut,C1
iBridge (C1)
T
iBridge (C2)
T
Ut,C2
VLAN port (BP1/ 0,C3)
Ut,C3
VLAN port (BP1/ 0,C4) Ut,C4 BP1: no PVID Si,X (any i) or Ut,Cj (j ≠ 3,4) or Ut,Ut
Legend for traffic characterization: Ut,C1 means S-VLAN = untagged and C-VLAN = C1 S1,X means S-VLAN = S1 and C-VLAN = do not care (tagged or untagged) Ut,Ut means no S-VLAN, no C-VLAN Legend for VLAN port configuration: 0,C1 means a C-VLAN port
Note — In case of GPON access, there are two alternative modes for VLAN translation: ONT based translation and LT based translation, as explained in “L2 forwarding on the NT board and the LT boards”.
VLAN tagging modes in the stacked iBridge modes Section “VLAN tagging modes in the iBridge” explained VLAN tagging modes in the iBridge for normal ISAM LT bridge ports. This section focuses on VLAN tagging modes in the stacked iBridge mode. Concepts
The concepts of Bridge Ports and VLAN ports defined on the subscriber side and used by iBridges and VLAN cross-connects are also valid for stacked iBridge modes. Two stacked iBridge modes are currently supported:
• S+C iBridge • S-iBridge The S+C iBridge mode allows C-VLAN tag operations, such as C-VLAN translation, in addition to adding/removing an S-VLAN header. This forwarding mode requires the operator to configure a VLAN Port for each C-VLAN.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-43
15 — Layer 2 forwarding
The S-iBridge mode supports two sub-modes of operation:
• S-Tunnel iBridge mode • S-VLAN mapped mode. The S-Tunnel iBridge mode allows the operator to minimize provisioning by creating a tunnel VLAN port on a specific bridge port. On this bridge port all tagged/ untagged customer frames which match the tunnel VLAN port are encapsulated by an S-VLAN header. The S-VLAN mapped mode is used on Hub-ISAM NNI ports. See “VLAN tagging modes in the iBridge (Hub-ISAM LT NNI ports concept)” for further details. Forwarding of untagged/priority-tagged/VLAN tagged frames in S+C iBridge
The forwarding behaviors described in Section “VLAN tagging modes in the iBridge” are mostly also pertinent for the operations of an S+C iBridge forwarding model. Therefore, the S+C iBridge supports forwarding of untagged / priority-tagged and VLAN-tagged customer frames.
• Forwarding of untagged / priority-tagged customer frames requires the configuration of the PVID. • Forwarding of tagged customer frames requires the configuration of a VLAN port. The main difference is that an S+C iBridge offers the ability of VLAN stacking (see section “C-VLAN cross-connect (basic VLAN cross-connect)”). An S+C iBridge is considered to be an S-VLAN aware bridge on PON LTs, where each N:1 VLAN (S-Bridge) is a separate Virtual Bridge (VB) instance. Each VB performs independent source MAC address learning and frame forwarding processing. In case of DSL and Ethernet (UNI) S+C iBridge is S+C VLAN aware, where each N:1 VLAN (S+C) is a separate Virtual Bridge (VB) instance with independent source MAC address leaning and frame forwarding processing. This forwarding mode resembles the ISAM S+C VLAN cross-connect forwarding model. The main difference is that in the S+C iBridge mode, the C-VLAN ID can be shared across multiple UNIs. This is not the case for the S+C cross-connect mode, whereby a C-VLAN ID is restricted to a single UNI.
15-44
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
The S+C iBridge mode supports both protocol-unaware and protocol-aware modes of operations. For example, DHCP option 82 insertion, PPPoE Intermediate Agent and secure forwarding (ARP Relay, DHCP Snooping, IP anti-spoofing) are supported for protocol-aware S+C iBridge operations. Note 1 — The S+C iBridge mode is supported on GPON and EPON
access solutions. Note 2 — Protocol awareness is supported for customer untagged and
single-tagged frames. Protocol unaware is supported for customer untagged, single/dual/multi -tagged frames. In context of GPON and EPON access solutions, some restrictions may apply on the ONT for the ability to support dual and multi-tagged frames. Note 3 — A given S-VLAN ID can only be shared between S+C
iBridge and S-iBridge for GPON and EPON access. Other interfaces do not support sharing. Note 4 — For EPON LT boards, a given S-VLAN ID cannot be
shared between S+C iBridge and S+C cross-connect. However, it is possible to have an S+C Bridge and an S-Tunnel cross-connect on the same bridge port, as long as the S-VLAN ID is not the same. Note 5 — DSL LT boards support stacked iBridge mode for unicast
traffic only. Note 6 — Multicasting traffic by means of an IGMP proxy is not
supported by stacked iBridges, a standard iBridge must be used instead. Note 7 — The following restrictions apply to Ethernet LTs:
• UNI: Stacked iBridge is supported for unicast traffic only • HC-UNI: Stacked iBridge is not supported • NNI: Only the (S,*) variant of the stacked iBridge is supported, that is, multi-tagged frames are bridged in function of their outer VLAN, see further Note 8 — On DSL LT boards, stacked iBridge does not support PPP
MAC address concentration, IPoA, PPPoX Relay and VRRP Proxy On DSL LT boards, secure-forwarding, broadcast control and aging time are individually controlled at the S+C level while other configurations are inherited from the S level. Forwarding of untagged/priority-tagged/VLAN tagged frames in S-iBridge
The forwarding behaviors described in section “VLAN tagging modes in the iBridge” are mostly pertinent for the operations of an S-iBridge. The main difference is that an S-VLAN iBridge offers the ability of VLAN stacking. The S-iBridge can be configured either in the S-tunnel iBridge mode or in the S-VLAN mapped mode. The S-tunnel iBridge is described in more detail in the following paragraphs. The S-VLAN mapped mode is supported only for the NNI ports of the GPON and GE Ethernet line boards. Further details of the S-VLAN mapped mode can be found in “VLAN tagging modes in the iBridge (Hub-ISAM LT NNI ports concept)”. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-45
15 — Layer 2 forwarding
The S-Tunnel iBridge supports forwarding of untagged / priority-tagged and VLAN-tagged customer frames via the configuration of a tunnel VLAN port. The S-tunnel iBridge also supports the ability to forward dual and multi-tagged customer frames via the configuration of a tunnel VLAN port. For GPON and EPON access solutions some restrictions may apply on the ONT for the ability to support dual and multi-tagged frames. An S-Tunnel iBridge is considered to be an S-VLAN aware bridge, where each N:1 VLAN (S-Bridge) is a separate Virtual Bridge (VB) instance. Each VB performs independent source MAC address learning and frame forwarding processing. This forwarding mode resembles the ISAM S-Tunnel VLAN cross-connect forwarding model. The main differences are that in the S-Tunnel iBridge mode, a tunnel VLAN port can exist across multiple UNIs. This is not the case for the S-Tunnel cross-connect mode, where a tunnel VLAN port is restricted to a single UNI. The S-Tunnel iBridge is mainly protocol unaware. Therefore, secure forwarding (ARP Relay, DHCP Snooping, IP anti-spoofing) is not supported. Nonetheless, the following subscriber identification features are supported on GPON LT NNIs:
• DHCP option 82 insertion for untagged and single-tagged customer Ethernet frames • PPPoE Intermediate Agent for untagged and single-tagged customer Ethernet frames Note — The S-Tunnel iBridge mode is only supported on GPON, EPON and Ethernet LT NNI access solutions.
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. Concepts
The concepts of bridge ports and VLAN ports defined on the subscriber side and used by iBridges and VLAN cross-connects 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 board and on the GPON line board. For the GPON line board, the NNI interface supports connection to the 7353 MDU.
15-46
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
There are three VLAN iBridge models supported on NNI ports:
• C-VLAN iBridge: Basic VLAN bridge mode (as defined in “VLAN tagging modes in the iBridge”) • S+C iBridge: As described in “VLAN tagging modes in the stacked iBridge modes”, but only supported on GPON line board • S-VLAN iBridge: Supporting Mapped and Tunnel VLAN bridge modes (Tunnel mode is described in “VLAN tagging modes in the stacked iBridge modes” and a description of Mapped mode follows). For GPON NNI ports, the concept of transparent mode versus non-transparent mode is introduced. Transparent mode provides a simplified interface between the OLT and the ONT that connects to the subtending system. It is currently supported for the 7353 MDU and can be summarized as follows:
• All packets will be transparently forwarded without VLAN translation, EtherType filtering, P-bit marking, and so on. • The GEM ports are allocated according to P-bit only. • The maximum number of VLAN ports per NNI port is 512. In contrast, the non-transparent mode re-uses the UNI interface between OLT and ONT. Therefore packet manipulations are possible but the number of VLAN ports per NNI is restricted to 8. Note that, in transparent mode, the P-bit to traffic class mapping used is the system level mapping, rather than the per forwarder mapping normally used for GPON. 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 board port type. Forwarding of untagged/priority-tagged/VLAN tagged frames in S+C iBridge
The S+C iBridge on NNI port is only supported for the GPON line board. Section “VLAN tagging modes in the stacked iBridge modes” explains the forwarding behaviors of the S+C iBridge. 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 an S-VLAN iBridge configured on the GE Ethernet line board NNI port type. The main difference is that an S-VLAN iBridge offers the ability of VLAN stacking (see “VLAN tagging modes in the stacked iBridge modes”)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-47
15 — Layer 2 forwarding
When the Hub-ISAM 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 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 co-exist 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 NNI port S-iBridge forwarding behaviors can be summarized as follows:
• 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 exists 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 called 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 called tunnel mode.
15-48
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
15.7
VLAN cross-connect mode
VLAN cross-connect usage Because it associates only one subscriber to one network VLAN, VLAN cross-connect forwarding is generally not well adapted to residential deployments where many subscribers need to be connected taking into account that a VLAN tag can only identify up to 4 K different VLANs. Hence the VLAN cross-connect mode should preferably be used for business applications or 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). Dual-tag VLAN cross-connect (see further) alleviates the scalability issue, but still requires intensive configuration action in the ISAM which generally makes VLAN cross-connect less attractive for residential mass deployment. Note — For the sake of clarity, this section only considers the case of direct VLAN encapsulation on the EMAN. This discussion can however be generalized to the cases where MPLS pseudo-wire encapsulation is used in the EMAN instead.
Supported models in ISAM There are several VLAN cross-connect models supported:
• C-VLAN cross-connect: basic VLAN cross-connect • S+C-VLAN cross-connect: more scalable and hierarchical grouping possible (e.g. the Headquarter of a given company identified by the S-VLAN in touch with several subsidiaries each one identified by a specific C-VLAN tag) • Tunnel -VLAN cross-connect: transports the traffic of a given subscriber with total unawareness of subscriber tagging (or untagging). Note — These VLAN cross-connect models are also supported on the Hub-ISAM LT NNI ports.
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 C-VLAN port at the subscriber side. In the ISAM, a bridge port is either an Ethernet PVC, an EFM link, an ONT UNI 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-49
15 — Layer 2 forwarding
As illustrated in Figure 15-28, 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 C-VLAN tagged frames in C-VLAN cross-connect The operator creates a C-VLAN port on top of the bridge port, and couples it to the C-VLAN cross-connect. When the ISAM receives C-VLAN-tagged frames on a bridge port it forwards them in the context of a 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. VLAN translation allows that the network-side and subscriber-side VLAN IDs are different. Forwarding of untagged/priority-tagged frames in C-VLAN cross-connect In addition to the configuration above, the operator configures on the Bridge Port a PVID or a Port-protocol-default VLAN that points to the VLAN port. When The ISAM receives untagged or priority-tagged frames on a given Bridge Port it adds a Vlan tag to the frame corresponding to the PVID and forwards the frames in the context of the C-VLAN CC. Note that in GPON, a Bridgeport is configured on an ONT UNI. In case of GPON access, there are two alternative modes for VLAN translation: ONT based translation and LT based translation; see “L2 forwarding on the NT board and the LT boards”. Note — For the GE Ethernet line board, VLAN translation is not supported on Hub-ISAM LT NNI ports. For GPON NNI ports, VLAN translation is not supported in the ONT, if transparent mode is configured. See “Concepts” for an explanation of transparent mode. However, note that VLAN translation in the OLT is still supported for the transparent mode.
Figure 15-28 shows the concept of the C-VLAN cross-connect mode. Figure 15-28 C-VLAN cross-connect concept
NetVlan (11)
11, *, Data
CC: 1-1
NetVlan (21)
21, *, Data
CC: 1-1
VlanId (11) PVID Tr
VlanId (11)
11, *, Data Ut, Data 11, *, Data
Only VlanPorts are shown
15-50
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
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. 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 15-29 shows the concept of the S+C-VLAN cross-connect mode. Figure 15-29 S+C-VLAN cross-connect concept
31, 12, *, Data NetVlan (31,12)
CC: 1-1 +- VlanId (12)
12, *, Data Ut, Data
31, 17, *, Data NetVlan (31,17)
CC: 1-1 +- VlanId (17)
17, *, Data
31, 23, *, Data NetVlan (31,23)
CC: 1-1 +-
Tr
VlanId (13)
13, *, Data
31, 21 *, Data NetVlan (31,21)
CC: 1-1 +-
Tr
VlanId (11)
11, *, Data
41, 27, *, Data NetVlan (41,27)
CC: 1-1 +-
Tr
VlanId (17)
17, *, Data
41, 39, *, Data NetVlan (41,39)
CC: 1-1 +-
Tr
VlanId (19)
19, *, Data
PVID
31, *, Data
EMAN (Outer Tag switches)
41, *, Data
Only VlanPorts are shown
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 15-29 the subscriber-side VLAN (0, 12) is translated into the network-side VLAN (31,12). Note 2 — In case of GPON access, there are two alternative modes for
VLAN translation: ONT based translation and LT based translation; see “L2 forwarding on the NT board and the LT boards” Special note about MAC address conflict prevention 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. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-51
15 — Layer 2 forwarding
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 learned on a 1st LT port and later on a 2nd LT port, then no MAC movement occurs, but instead a “duplicate MAC address” alarm is raised by the NT board. Tunnel-VLAN cross-connect: VLAN stacking for business subscribers
Like for the S+C-VLAN cross-connect, in a Tunnel-VLAN cross-connect, two levels of VLAN tags are used, supporting hierarchical VLAN tagging:
• the inner tag (when present) is the customer VLAN: C-VLAN • the outer tag is the service provider VLAN: S-VLAN The difference however is that in the Tunnel-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. Hence, in a Tunnel-Vlan Cross-connect, the ISAM systematically adds a VLAN tag to frames originating from the subscriber. In downstream, the ISAM systematically removes the outer tag before passing back the frame to the subscriber. In a Tunnel-VLAN cross-connect, the C-VLANs carried within the S-VLAN are passed transparently to the end-subscriber. The Tunnel-VLAN cross-connect plays the role of a “transport pipe” between the subscriber and the remote site, with the S-VLAN being the envelope of the tunnel. Tunnel-VLAN cross-connect allows the end-subscriber to specify a private end-to-end connectivity with no need to involve the access provider in his VLAN tagging strategy. It is to be noted that S-VLAN Tunnel cross-connect accepts indifferently untagged, single-tagged, dual-tagged or multi-tagged frames. To configure a Tunnel cross-connect for DSL, Ethernet or GPON subscribers, the operator needs to configure the ISAM with the following:
• configure a network S-VLAN with mode cross-connect • configure an S-VLAN port on the bridge port of the subscriber using the tunnel • use this S-VLAN port as PVID To configure a Tunnel cross-connect for EPON subscribers, the operator needs to configure the ISAM with the following:
• configure a network S-VLAN with mode cross-connect • configure a local scope “Star” C-VLAN port (0,*) on the bridge port of the subscriber using the tunnel and associates this C-VLAN port to the network S-VLAN 15-52
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
Figure 15-30 shows the S-VLAN cross-connect model (DSL, Ethernet or GPON case shown). Figure 15-30 S-VLAN cross-connect model concept
NetVlan 51
51, *, Data
CC: 1-1 +- VlanId (51,0)
*/Ut, Data
PVID
Only VlanPorts are shown
It should be noted that a Tunnel-VLAN cross-connect can coexist with C-VLAN and S+C-VLAN cross-connects on the same bridge port. When this is the case, upstream user traffic is preferably sent to the C- or S+C-VLAN cross-connect if the user VLAN matches the corresponding VLAN ports. The rest of the upstream traffic is sent by default through the Tunnel-VLAN cross-connect. Figure 15-31 illustrates this case. Figure 15-31 Tunnel-VLAN, C-VLAN and S+C-VLAN cross-connects on same bridge port
NetVlan 11
11, *, Data
CC: 1-1
VlanId (11)
NetVlan 31,23
31, 23, *, Data
CC: 1-1 +-
Tr
NetVlan 51
51, *, Data
CC: 1-1 +- VlanId (51,0)
VlanId (13)
11, *, Data
13, *, Data
*/Ut, Data
PVID
Only VlanPorts are shown “*, Data “ here means any frame except with outertag = 11 or 13
MAC learning and VLAN port handling The same MAC learning concepts and VLAN port handling as for iBridge apply to VLAN CC; see section “iBridges”. Although VLAN cross-connects do not rely on MAC address to forward frames to subscribers, VLAN cross-connects also perform MAC address learning in a similar way as for iBridges as a DOS protection means (enforcing the port limit and avoid rogue users stealing network MAC addresses). When DOS protection is not of primary concern however, MAC address learning can be disabled within a VLAN cross-connect allowing an unrestricted number of source MAC addresses to flow through the vlan cross-connect.
Transparent VLAN cross-connect The ISAM supports transparent VLAN cross-connect for use in a business environment on all LT boards except layer 2 LT boards. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-53
15 — Layer 2 forwarding
A transparent VLAN cross-connect is a special mode of operation of the C-VLAN cross-connect, the S+C-VLAN cross-connect or the Tunnel-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. 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 Note — The ECNT-A can only partly support fully transparent
VLAN-cross-connect. It can only recognize those L2CP frames which have the following MAC addresses:
• 01-80-C2-00-00-00 • 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 15-32.
15-54
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding Figure 15-32 Use of transparent VLAN cross-connect
L2CP: Sp. tree Br Br
Br L2CP: Sp. tree Link aggregate
L2CP:LACP
Br Br LAG LAG
Br Br
LAG
Br Br
L2CP:LACP
Br
Over Transparent VLAN-CC
x
Br Br
x x
L2CP x
VLAN2
L2CP
VLAN3
L2CP
x x
Br Br Br Br LAG LAG
Br Br
LAG LAG
Br Br
VLAN1
Br Br
EMAN Assu m p tio n : EMAN tr a n sp a r e n t to ta g g e d L2 CP traffic
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/ONT UNI 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 Note — For GPON access, the IEEE802.1x frames are always terminated on the ONT UNI. This means that if no PVID has been configured on the ONT UNI bridge port, then the IEEE802.1x frames will be discarded. If a PVID has been configured and associated with a forwarding context, IEEE802.1x frames will be forwarded to the OLT using the PVID VLAN ID. Once at the OLT if IEEE802.1x is:
• Disabled, then these frames will be dropped. • Enabled, then these frames will be extracted to the LT OBC. • 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. Note — IEEE802.3ah OAM is currently not supported on ONT UNI ports and on Hub-ISAM LT NNI port.
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-55
15 — Layer 2 forwarding
Because L2CP protocols are link related, the deployment model implies that only one transparent VLAN cross-connect is configured per PVC (or per EFM/ONT UNI); see Figure 15-33. Having more than one cross-connect can lead to undesired effects in L2CP protocols. Figure 15-33 One transparent VLAN cross-connect per PVC/EFM L2CP CPE
PVC/EFM
x
VLAN1
x
PVC/EFM
x
CPE
PVID = VLAN1
EMAN
CPE
PVC/EFM
L2CP VLAN1 x PVC/ EFM
CPE
x VLAN2 CPE
PVC/EFM
x
PVID= VLAN1
EMAN
15.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. Note — For EPON access, no protocol-aware cross-connect mode is supported.
15-56
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
VLAN cross-connect for business and residential subscribers The VLAN cross-connect feature is aimed at cross-connecting a subscriber PVC (or DSL line in case of EFM, Ethernet link in case of point-to-point Ethernet or ONT UNI) 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 15-34 shows the IP network model for business cross-connect. Figure 15-34 IP network model for business cross-connect
Edge
EMAN
NE
CPE VRF
VL VRF Services
VRF VRF VRF
IP subnet
IP address
VLAN
Customer premises IP subnet
• 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 15-35) or a BRAS (PPP connectivity; see Figure 15-36) 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-57
15 — Layer 2 forwarding Figure 15-35 IP network model for residential cross-connect using IP connectivity
Edge
EMAN
NE
CPE
VLAN-CC VRF
Services
IP subnet
IP address
VLAN
Figure 15-36 IP network model for residential cross-connect using PPP connectivity
Edge
EMAN
NE
CPE
VLAN-CC Services
PPP IP Routing Termination
IP subnet
IP address
PPP session
VLAN
Note — Figure 15-35 and Figure 15-36 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.
15-58
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
Business cross-connect features
In a business context, the VLAN cross-connect model is used to provide a transparent VPN service which supports the following features:
• point-to-point Ethernet and ONT UNI interface types • Supported on the Hub-ISAM LT NNI ports. • DSL interfaces types: • ATM:
•
• Bridged encapsulation carrying IPoE or PPPoE traffic • IPoA with the required interworking to convert the traffic to IPoE • PPPoA encapsulation or encapsulation auto-detection is not expected in a business context VDSL EFM • IPoE or PPPoE traffic
• 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).
• Tunnel-VLAN cross-connect: The S-VLAN indicates the end subscriber, while the C-VLANs represent various subscriber-defined services.
• Security features: For bridged encapsulation: optional limitation of the number of MAC addresses per VLAN cross-connect. • Service enforcement: Policing per end-subscriber VLAN port or bridge port Residential cross-connect features
The VLAN cross-connect supports the following features in the context of residential subscribers:
• point-to-point Ethernet and ONT UNI 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 VDSL EFM • IPoE or PPPoE traffic
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-59
15 — Layer 2 forwarding
• 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
• 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
• These subscriber identification options are transparent on the NNI ports of the GE Ethernet line board. The NNI ports of the GPON line board will add the OLT part of the line ID in these options, based on the syntax configuration.
• 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 end-subscriber VLAN port • 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.
15-60
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
15.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. Note — The IPoA cross-connect mode is comparable with the VLAN cross-connect mode, but with IPoA instead of IPoE at the CPE side.
The IPoA cross-connect model implies a cross-connection between the PVC of a subscriber whose encapsulation is IPoA with a VLAN at the EMAN side. The following applies for the 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 15-37 and Figure 15-38. Figure 15-37 IP network model for business IPoA cross-connect NE 100.100.100.9
100.100.100.8 /30 Network side
IP
CPE CPE side
100.100.100.10 CPE
Edge Router
100.100.100.13
100.100.100.12 /30
IP
100.100.100.14
100.100.100.17
100.100.100.16 /30
IP
100.100.100.18
CPE
= IP interface
IPoE
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
IPoA
November 2013
15-61
15 — Layer 2 forwarding Figure 15-38 Ethernet network model for business IPoA cross-connect IPoE
IPoA
IP
C_VLAN1
PVC11
CPE1 PVC12
Edge Router
C_VLAN2
S_VLAN
C_VLAN3
IP
PVC21 PVC22
IP
CPE2
PVC31 PVC32
CPE3
= L2 interface
IPoA cross-connect features The following features are supported for the IPoA cross-connect mode:
• The IP address of the CPE is static (no dynamic CPE IP address assignment via • • • • • •
DHCP). The ISAM is transparent for routing protocols between CPE and PE. Only /30 subnet is supported between the ISAM and the CPE. A given CPE can be associated with up to 30 different subnets (multi-VPN). Each of these subnets will then be served with a separate PVC and separate VLAN. There is VLAN stacking on the GE uplink. Typically, the C-VLAN indicates the CPE and the S-VLAN indicates the ISAM (or the paired 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 LT 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 LT 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 LT 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. 15-62
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
15.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 (IPv4 only) and IPoE (Ipv4 or IPv6) 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 In case of IPv6, the ISAM discards any IPv6 packets whose IPv6 source address does not match any IPv6 addresses or prefixes that are either statically configured or dynamically to the user interface. The ISAM will only check the first 64 bits of the 128-bit IPv6 address. This is sufficient because the last 64 bits of the IPv6 address hold the “Interface Identifier”; the Interface ID is typically based on the interface MAC address and therefore not of relevance to the IPv6 anti-spoofing function. • 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. For EPON access, the operator will have the ability to explicitly configure per L2 forwarder the IP address anti-spoofing feature, when:
• secure forwarding is enabled, ARP relay, DHCP snooping and IP static configuration will work for IP session set up. On DSL/GPON/ETH, as stated above, this would activate also the IP anti-spoofing functionalities. • IP address anti-spoofing is enabled and MaxNbrOfIpaddress is not equal to 0, then LT will further check srcIP of US packets. • Secure forwarding is disabled, All US/DS of ARP requests/replies will immediately be dropped. Due to no protocol-aware VLAN cross-connect supported on the EPON access, the ARP and DHCP packets will be always transparent in VLAN cross-connect. When secure forwarding is applied to iBridges, it is sometimes referred to as Enhanced iBridge forwarding. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-63
15 — Layer 2 forwarding Figure 15-39 Enhanced iBridge architecture IS AM Us Useer r
CPE
Us Useer r
CPE
Us Useer r
CPE
Us Useer r
CPE
Us Useer r
CPE
Us Useer r
CPE
Us Useer r
CPE
Us Useer r
CPE
Us Useer r
CPE
L LT DHCP s nooping/ S tatic config.
ARP Relay
VLAN
iBridge
L LT DHCP s nooping/ S tatic config.
IP Subnet
NT ARP Relay
iBridge
EMA Bridge
IP edge
IP IP network
L LT DHCP s nooping/ S tatic config.
ARP Relay
iBridge
Us ers can belong to a different public s ubnet ubnet.
• Secure forwarding of IPv4 traffic is supported by all ISAM LT boards: DSL, • • • •
point-to-point Ethernet (UNI), 10G/EPON and GPON LTs. Secure forwarding of IPv6 traffic is supported by all ISAM LT boards: DSL, point-to-point Ethernet (UNI), 10G/EPON and GPON LTs. Secure forwarding is supported for S+C iBridge on both GPON and EPON access solutions. However, secure forwarding cannot be enabled on an S+C cross-connect VLAN when associated to the VLAN ports of a GPON LT. Secure forwarding is supported for untagged and single-tagged customer frames in S-Tunnel iBridge on both GPON and EPON access solutions. Secure forwarding is not supported on the hub-ISAM LT NNI ports and the point-to-point Ethernet HC-UNI ports.
IP session awareness The ISAM snoops DHCP messages to learn what IP addresses/subnets have been allocated to a subscriber port. 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”.
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.
15-64
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
IP address anti-spoofing The 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. Though the main scenario when considering IP awareness in the iBridge VLAN cross-connect 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 • IPv6 address anti-spoofing for dynamic IPv6 addresses learned through DHCPv6. The ISAM discards any IPv6 packets whose IPv6 source address does not match any IPv6 addresses or prefixes allocated to the user interface. The ISAM will only check the first 64 bits of the 128-bit IPv6 address. • IPv6 address anti-spoofing for static IP addresses and/or IP subnets (IP prefix + length) configured by the operator. Any IPv6 packets whose IPv6 source address does not match any static IPv6 addresses and/or prefixes programmed by the operator are discarded. The ISAM will only check the first 64 bits of the 128-bit IPv6 address. Note — IPv6 address anti-spoofing for dynamic IP addresses and/or IP subnets is not currently supported by EPON LT cards. IPv6 address anti-spoofing for static IP addresses and/or IP subnets is not currently supported by 10G EPON LT cards.
• IP address anti-spoofing for control messages. IP address anti-spoofing is applied to control messages like ARP, IGMP, and DHCP.
ARP relay The iBridge forwarding rules allow a basic ARP handling:
• Downstream ARP messages When setting the broadcast flag for a given iBridge, downstream ARP requests are forwarded to all subscribers connected to the iBridge. • Upstream ARP messages ARP requests originating from the subscriber are broadcast to all network bridge ports. A more intelligent way of dealing with ARP messages is ARP relay. 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-65
15 — Layer 2 forwarding
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.
ICMPv6 The details of ICMPv6 protocol handling are captured in chapter “Protocol handling in a Layer 2 forwarding model”.
IPoA support for secure forwarding By similarity with IPoA VLAN cross-connect, secure forwarding is supported with IPoA encapsulation: IPoA upstream traffic is converted into IPoE traffic and vice-versa.
15-66
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
15.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. Caution — Although vMAC addresses are saved during an LT board reset, they are not saved if the LT board is powered down.
Note 1 — vMAC is currently not supported on EPON LT access
solutions. Note 2 — vMAC is currently not supported on the Hub-ISAM LT
NNI ports and the point-to-point Ethernet HC-UNI ports. Note 3 — vMAC is supported with S+C iBridge and S-Tunnel
iBridge on GPON access solutions on UNI ports only.
Deployment scenario example One possible deployment scenario for vMAC is shared network VLAN for IP address pooling.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-67
15 — Layer 2 forwarding
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 the traffic from another DSLAM 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 15-40. Figure 15-40 iBridge
Edge
EMAN
ISAM
CPE
I-Bridge
Bridge
VRF
I-Bridge
IP subnet
IP address
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 15-41. Figure 15-41 iBridge with vMAC enabled
Edge
EMAN
ISAM
CPE
vMAC bridge Bridge
VRF
vMAC bridge
VLAN / IP subnet
IP address
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.
15-68
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
vMAC features vMAC 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 the DSLAM ID is programmable by the operator handling in DHCP Application Layer Gateway (ALG) handling in ARP ALG handling in ICMPv6 ALG handling in Ethernet OAM ALG user-to-user communication can optionally be blocked vMAC address - MAC address translation table recovery application or not of vMAC to DHCP Option61 user MAC address
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 stacked iBridge Note 1 — vMAC cannot be used in conjunction with Tunnel-VLAN
cross-connect. Note 2 — vMAC is controlled at S Level for an S+C 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).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-69
15 — Layer 2 forwarding
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 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. Multicast and broadcast destination addresses have a special format and are not impacted by the vMAC ALG (when allowed to get through). vMAC ALGs might be applied to control plane messages (ARP, DCHP, Link Related Ethernet OAM, and so on).
When unused, vMAC are freed based on the standard MAC address aging process. 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. 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. Note — This limit is programmed by setting the maximum number of MAC address per port (generic MAC address related feature).
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.
15-70
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
DSL/Eth vMAC format
In the vMAC format, the DSLAM ID can be set by the operator, see Table 15-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 15-2 vMAC format for data traffic forwarding MAC Address
Configurable
Description
Bit 47...45
No
Rack ID (minus 1)
Bit 44
No
ISAM xDSL vMAC 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)
Bit 39...21
Yes
DSLAM ID set by the operator [1…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 board 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
xPON vMAC format
In the vMAC format, the DSLAM ID can be set by the operator, see Table 15-3. 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 15-3 vMAC format for data traffic forwarding MAC Address
Configurable
Description
Bit 47...45
Yes
0 in case of GPON
Bit 44
No
vMAC xPON MAC set to 1
Bit 43
No
vMAC (0) / CFM MAC (1)
Bit 42
No
For vMAC always 0 / for CFM MAC (future; PON Identifier: OLT / ONT)
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)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-71
15 — Layer 2 forwarding
MAC Address Bit 39...27
Configurable Yes
Description GPON vMAC format DSLAM ID [1…8K] A unique DSLAM ID within an EMAN connected to the same IP edges
Bit 26...22
No
Slot ID of the line board [0…31] The logical position of the line board within the DSLAM.
Bit 21...18
No
Bit 17...8
No
PON Port ID [0…15] Port ID (UNI) of the subscriber interface [0…1023] Logical port ID picked by the system.
Bit 7
No
Reserved
Bit 6...0
No
MAC ID unique to each subscriber MAC address
(2 of 2)
DHCP ALG
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 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. ARP ALG
The MAC address field present in the ARP message payload is updated in a similar way as for DHCP. ICMPv6 ALG
The MAC address field present in the ICMPv6 Neighbor Discovery message payload is translated as follows:
• Upstream Neighbor Solicitation (NS): translate the MAC address carried in the “source link-layer address” option. This option contains the MAC address of the routed modem (or PC behind a bridged modem), hence it must be translated to the vMAC address; • Upstream Neighbor Advertisement (NA): translates the MAC address carried in the “target link-layer address”; • Upstream Router Solicitation: translate the MAC address carried in the “source link-layer address” option.
15-72
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
Ethernet OAM ALG
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 (that is, DSLAM ID, rack/shelf/slot/Port/MAC IDs). 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
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-73
15 — Layer 2 forwarding
15.12
PPP cross-connect mode This chapter covers the so-called “PPP cross-connect forwarding mode”. Although it shares many concepts with iBridges and VLAN CC L2 forwarders, this mode is quite different. 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”. Like iBridges and VLAN CC, a PPP cross-connect is defined in the context of a network VLAN ID. A PPP CC forwarder (often called PPP CC Engine) interacts with the user side world through PPP CC client port interfaces. 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 an 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. Note — It is possible - 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”. 15-74
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding
The general model of a PPP cross-connect engine with MAC address concentration is quite intuitive. It is shown in Figure 15-42. Figure 15-42 General PPP cross-connect engine
PPP CC Client Port iBridge VLAN or CC VLAN
PPPoE PPPoE Server Server
PVC, EFM, VLANPort or GE
PPPCCE PPPCCE PPPoA & PPPoE
In case of PVC
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 the user side 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 Note — It is not intended to create a client port on a bridge port.
The interfaces stack for PPP client ports is shown in Figure 15-43. Figure 15-43 Subscriber access interface stack for PPP client ports PPP client port
PPP client port
PPP client port
PVC
EFM
PPP client port
VLAN port Bridge port PVC
EFM
ATM
ATM
ADSLx VDSLx Eth Phy
ADSLx
Tagged PPPoE Frames
PPPoA or untagged PPPoE Frames on PVC
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
VDSLx
Eth Phy
Untagged PPPoE Frames on EFM or Eth Phy
November 2013
15-75
15 — Layer 2 forwarding
All the supported encapsulations for PVCs are shown in Figure 15-44. Figure 15-44 Accepted ATM encapsulation for PPP cross-connect Forwarding with MAC address concentration asamAtmVclEncapsAutodetect Client Client Port Port PPPCCE PPPCCE
PPPoA
disabled(1) or autoDetectPPPoA(4)
asamAtmVclEncapsType
VC VC
llcNlpid(3) or vcMuxPppoa(6)
Client Client Port Port PPPCCE PPPCCE VC VC
Untagged PPPoE
asamAtmVclEncapsAutodetect disabled(1),
asamAtmVclEncapsType Client Client Port Port PPPCCE PPPCCE VlanPortBridgePort VC VLANPort VC
Tagged PPPoE
llcSnapBridged(1) or vcMuxBridged(4)
asamAtmVclEncapsAutodetect Client Port Port Client
PPPCCE PPPCCE VC VC
PPPoA or Untagged PPPoE
autoDetectPPP(3) or autoDetectIpoePpp (5)
asamAtmVclEncapsType llcSnapBridged(1), llcNlpid(3), vcMuxBridged(4), vcMuxPPPoA(6)
PPP cross-connect implementation The object model of a PPP cross-connect depicted in Figure 15-42 is quite simple:
• a PPP cross-connect 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 1 — PPP cross-connect is not supported in hub-ISAM LT NNI
ports and the point-to-point Ethernet LT HC-UNI ports. Note 2 — PPP cross-connect is not supported in GPON access
solutions.
PPP Cross-connect inside the ISAM PPP cross-connect forwarding is implemented by a cooperation of functions in the LT board and NT board as shown in Figure 15-45.
15-76
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
15 — Layer 2 forwarding Figure 15-45 PPP cross-connect inside the ISAM PVC, EFM, VlanPort or EthPhy PPP CC Client Port PPP CC Engine
PPPCCE
L2 Fwd
PPPCCE EMAN
L2 Fwd LT NT DSLAM
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
15-77
15 — Layer 2 forwarding
15-78
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
16.1 Introduction
16-2
16.2 Link aggregation 16.3 RSTP and MSTP
16-3 16-8
16.4 Connectivity Fault Management 16.5 802.1x support 16.6 BCMP 16.7 ARP
16-19 16-20
16.9 IGMP
16-26
16.10 PPPoE 16.11 DHCPv6
16.13 LLDP
16-17
16-18
16.8 DHCP
16.12 ICMPv6
16-13
16-26 16-31 16-33 16-33
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-1
16 — Protocol handling in a Layer 2 forwarding model
16.1
Introduction Layer 2 protocol handling can be divided into two parts:
• 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. Participation of the ISAM - being the boundary node of the service provider network - in processing these protocols, enables the general network or nodes deeper in the network to provide better services to subscribers. Note — MPLS-related protocols are handled in chapter “MPLS”.
Layer 2 Control Protocol handling Table 16-1 shows the protocols of the Layer 2 control protocol handling. Table 16-1 Layer 2 control protocol handling Protocol
Described in Section
Link Aggregation
16.2
Rapid Spanning Tree Protocol and Multiple Spanning Tree Protocol
16.3
Connectivity fault management
16.4
802.1x
16.5
Application protocol handling Table 16-2 shows the protocols of the application protocol handling.
16-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model Table 16-2 Application protocol handling Protocol
Described in Section
Broadband Access Network Cluster Management Protocol (BCMP)
16.6
ARP
16.7
DHCP
16.8
IGMP
16.9
PPPoE
16.10
DHCPv6
16.11
ICMPv6
16.12
These protocols play an important role in the way subscribers establish connectivity and/or access broadband services. The ISAM supports a set of protocol processing features in order to maintain network security and allow customer identification and troubleshooting. These are defined in the next sections. The use of these control protocols can lead to security issues when malicious users try to perform a (Distributed) Denial of Service attack towards the systems handling the user-generated control traffic (for example, a BRAS, an Edge Router or a DHCP server). In order to protect these systems, the ISAM can be configured to perform upstream policing for the following protocols: ARP, DHCP, DHCPv6, IGMP, ICMPv6, PPPoE and Connectivity Fault Management. The policing rate and maximum burst size can be configured separately for each of the mentioned protocols.
16.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 no 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 16-1 shows an example of link aggregation.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-3
16 — Protocol handling in a Layer 2 forwarding model Figure 16-1 Link aggregation IP Edge Router / BRAS Link Aggregation Group 1
Ethernet Bridge
NSP IP backbone
NE ADSL m x FE/GE n x FE/GE
FE/GE
EMAN
NSP IP backbone
Link Aggregation Group 2 NSP IP backbone
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). If enabled by the operator, the cost of the Link Aggregation Group, as used by OSPF for making routing decisions, is based on the available aggregated operational bandwidth.
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. 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.
16-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
Link aggregation support Link aggregation is supported on:
• network links • subtending links • The GE Ethernet LT board UNI, HC-UNI and NNI port types (note that all link members of the LAG must be hosted by the same GE Ethernet LT board) The ISAM NT interacts with the network side by means of SAPs and/or MPLS Pseudowires:
• SAPs facing the network side are configured on regular access ports, not on network ports. • MPLS Pseudo Wires are always facing the network side and are exclusively configured on genuine network ports. The ISAM NT exclusively interacts with the subscriber side (that is, LT boards, directly attached subscribers or subtending ISAMs) by means of SAPs:
• SAPs facing the subscriber side are configured on residential access ports. LAG is currently supported only on regular access ports and those residential access ports used for subtending. 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 16-2 shows link aggregation support.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-5
16 — Protocol handling in a Layer 2 forwarding model Figure 16-2 Link aggregation support
Network side
SDPs
Subscriber side
SDP bindings
LAG
EMAN
LAG
EMAN
LT LT
NT Residential access port Regular access port Network port SAP
Note — Link aggregation is not supported on subscriber links (with the exception of the GE Ethernet LT board subscriber links).
Active / Standby Subgroup in Link Aggregation Access Nodes connected to Upstream Network Equipment (Bridges, Routers and Servers) need to protect against various kinds of upstream failures:
• Protection against Uplink level failures • Protection against Upstream NE circuit pack failures • Protection against Upstream NE failure Link Aggregation subgroups are configured by combining physical links of a Link Aggregation Group in a subgroup. The subgroups are supported for static and dynamic (LACP enabled) Link Aggregation Groups. The subgroups are given a preference value and a threshold. On this basis, the subgroup will act as an active subgroup or as a standby subgroup. The subgroup with the highest preference will always be selected as the active subgroup. When the threshold on the active subgroup reaches a pre-defined threshold, the subgroup with the next highest preference will be selected as active. It is essential that the IP address and MAC address of the links on the two upstream network elements be configured identically towards the Access Node. 16-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
Multiple links of a Link Aggregation Group from redundant control cards and / or NTIO cards can be combined to form the Link Aggregation Subgroup. Figure 16-3 Active / standby subgroup for aggregation Active Subgroup
APS Logic
Standby Subgroup
Upstream NE 1
L A G
EMAN
Upstream NE 2
Static LAG Subgroups
In case of static subgroups the link state of standby subgroups are not known (physical link state is down). As a result, static subgroups only support non-revertive behavior. After initialization or changing LAG operation status (shutdown / no shutdown), the most preferred subgroup will be made active based on the preference value. In non-revertive mode of static LAG the current active subgroup will continue to carry traffic as long as the threshold is not reached. Once the threshold is reached, a switchover is initiated by bringing down links of current active subgroup. This is followed by designating the standby subgroup as active and the links of the newly active subgroup are enabled. In case the number of links, coming up during the switchover, is less than the threshold, the newly designated active subgroup continues to be active. This condition is cleared if the operator forces a manual switchover to a subgroup or the number of links in the newly active subgroup exceeds the threshold. If during switchover no ports / links are active on the standby side for a pre-configured time, then the switchover is aborted. Dynamic LAG subgroups
LACP-based LAG subgroups support both revertive and non-revertive behavior. In revertive behavior the most preferred subgroup remains the active subgroup as long as the number of active links exceeds the threshold value. In case the threshold value is reached the traffic will switch over to the standby subgroup and will be restored to the active subgroup once the number of active links exceeds the threshold value.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-7
16 — Protocol handling in a Layer 2 forwarding model
In non-revertive mode, once the switchover from active to standby subgroup takes place, the traffic continues on this newly active subgroup irrespective of the number of active links exceeding the threshold value on the most preferred subgroup. Only when the threshold value of this newly active subgroup drops below the threshold the traffic will switch to the most preferred subgroup.
16.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 16-4 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 16-4 Spanning Tree between NE and EMAN IP Edge Router / BRAS Ethernet Bridge NE
NSP IP backbone
m x FE/GE
ADSL
EMAN
FE/GE
NSP IP backbone
n x FE/GE
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.
16-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
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 nodes 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 an EMAN Network. Then RSTP and MSTP are 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 are supported within this EMAN Network on network links, on subtending links, and on subscriber links terminated on the NT board. The GE Ethernet LT board NNI port type, used for access aggregation or business services access (but not as a network uplink interface) also supports RSTP/MSTP. The following restrictions apply:
• All interfaces must be of the same type (NNI) and located onto the same GE Ethernet LT board • RSTP/MSTP is only supported with the iBridge model (no VLAN-CC) • RSTP/MSTP on the Ethernet LT assumes the LT interface to be root bridge and must be configured accordingly by the operator • NT and LT xSTP instances are split, that is, the NT and LT links are not part of the same protection domain. A link event failure at the LT side is not signaled by the NT towards the network and inversely meaning that cross-LT or cross-ISAM link protection schemes are not supported. In some network topologies the use of RSTP or MSTP will not provide any 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 are not supported on these
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-9
16 — Protocol handling in a Layer 2 forwarding model
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. Note 1 — The 7302 ISAM supports RSTP and MSTP towards
DSLAMs in a ring. Note 2 — The 7302 ISAM and the 7330 ISAM FTTN supports STP
(IEEE 802.1D-1998, clause 8) for inter-operability with older routers. Note 3 — The terminology of network links, subtending links, and
subscriber links is not used on the management interface of the ISAM. The operator configures a link as “regular” to make it behaving as a network link and configures it as “residential” to make it behaving as subtending or subscriber link. Note 4 — RSTP and MSTP shall only be supported in the m-VPLS.
Only a single m-VPLS can be configured. RSTP and MSTP do not run concurrently on the system. Note 5 — No Spanning Tree protocol is supported on MPLS Pseudo
Wires (on Network links).
Ethernet Ring Protection Switching (ERPS) Several ISAM nodes can be connected to each other in a ring topology in some networks. In an Ethernet Ring, each Ethernet ring node is connected to adjacent Ethernet ring nodes participating in the same Ethernet ring, using two independent links. The G.8032 ERPS standard defines the mechanisms and protocols to achieve a fast, highly reliable and stable protection in case any link or node of an Ethernet ring fails. This mechanism ensures that L2 forwarding loops are never formed as forwarding loops would fatally affect network operation and service availability. xSTP protocols are not needed when ERPS is used and are disabled on the ring ports. For ring protection G.8032 specifies a protocol known as the R-APS protocol that runs between the nodes of a ring. The R-APS protocol messages are carried in a dedicated VLAN known as the ERP VLAN and is based on the Y.1731 Ethernet OAM CCM message.
16-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model Figure 16-5 Ethernet Ring Topology
B
A
C
F
RPL Link E
Data VLANs
D
ERP VLAN
RPL owner
Two modes of protection switching have been defined in G.8032: revertive mode and non-revertive mode. In the revertive mode after the condition(s) causing a switch-over has (have been) cleared, the traffic path on the ring is restored to the normal working state, that is, blocked on the RPL. Note that switching back to the normal state causes an additional traffic interruption. In the non-revertive operation, the traffic channel continues to use the RPL, if it has not failed, after a switch condition has cleared. The operator has to block the RPL link manually in order to restore the ring to the normal state. Figure 16-6 Normal state of Ethernet Ring Protection
A
B C
F E
D RPL owner
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-11
16 — Protocol handling in a Layer 2 forwarding model Figure 16-7 Path Failure and R-APS message flow to RPL Owner Node
A
B
C
F
R-APS
R-APS
E
D RPL owner
Each time a link failure occurs that affects reachability, the nodes that detect the failure initiate R-APS messages on either side of the ring. The nodes that initiate R-APS (Signal Fail abbreviated as SF) also flush their FDBs on the ring links. Every node that receives the R-APS (SF) message also flushes the FDB. The RPL owner unblocks the RPL link when it receives the R-APS message and initiates its own R-APS messages in either direction. Every node that receives the R-APS messages from the RPL owner once again flushes the FDB. The nodes that are connected to the failed link periodically transmit the R-APS messages as long as the Signal Fail condition persists. Figure 16-8 Reconfiguration to protected path
A
B C
F E
D RPL owner
Support of ERPS in ISAM In the ISAM ERPS is supported on 1G and 10G uplink ports of ISAM FX shelves with NANT-E and FANT-F NT cards. Note that these uplink ports can be on any of the active/standby NT cards. The port mode shall be “access” only. ERPS is supported on uplinks that are NTIO ports as well. ERPS is supported on a single ring instance per pair of ports. It is expected that ISAM will be just a node on the ERPS ring and the RPL owner on the ring will be a 7x50 from IPD or some other router. 16-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
ERPS in ISAM is supported for VPLS and v-VPLS services. CCM messages are sent every 100 ms. The maximum number of Ethernet Rings in an ISAM FX shelf with FANT-F NT boards is six. Each ring has to be on a separate pair of ports (there are eight ports in a duplex ISAM shelf and four NTIO ports and hence a maximum of six Ethernet Rings). A simplex system with a single NT card supports a maximum of two Ethernet Rings.
Limitations of ERPS in ISAM • Each pair of ports supports a single instance of ERPS only. • RPL owner function is not supported. • RPL neighbor function is not supported. • The failure protection occurs within one second; 50 millisecond switchover is not guaranteed. • Sub-rings and ladder topologies are not supported. • ERPS is supported on LAG ports of ISAM, but with limited functionality:
• In a ring of ISAMs, link failures should still result in Automatic Laser Shutdown and the other ports in the LAG should take over immediately
• Facility MEP is not supported. CCM messages can still be sent, but will only be sent
•
16.4
in a round robin on each link in the LAG. In case there is a failure on a few links of the LAG, the failure wont be detected by the CCM messages unless and until CCM messages fail on all the links of the LAG. A LAG failure will be indicated if the number of active ports in the LAG goes below a configurable threshold. Only if the LAG failure condition exists, ERPS will be triggered (and not in case of a few individual ports of the LAG failing). In case the entire LAG goes down (could be due to the LAG configuration), then the failure needs to be detected through LACP messages and switch-over performed.
Connectivity Fault Management This section describes Connectivity Fault Management (CFM) and identifies the level of support in the ISAM.
CFM elements Connectivity 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 16-3 describes the CFM elements that must be configured on an Ethernet network.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-13
16 — Protocol handling in a Layer 2 forwarding model Table 16-3 CFM elements 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.
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. For example, 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 cannot 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 cannot 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 MD/MA (VLAN). 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.
IEEE 802.1ag defines these generic CFM OAM procedures. Broadband Forum 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 user port on the ISAM to the CPE Figure 16-9 shows CFM implemented on a typical access aggregation network.
16-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
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. Figure 16-9 CFM on the access aggregation network MD Service provider
MD level 7
MD carrier
MD level 5 MD level 3
MD Intra-carrier
Access link MD
MD level 1
CPE RG
MEP MIP
Ethernet access network DSLAM
Scope of access network operator
Regional network Ethernet switch
BNG
Scope of service provider operator
CFM functions The CFM protocols define multiple functions that act as tools to test and isolate connectivity faults in the network. The CFM link trace acts as an ICMP traceroute command. Multicast Link Trace Messages (LTMs) are sent from the originating MEP and are addressed to another MEP of the MA. 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 MEP, and a response in the form of a Link Trace Reply (LTR) message is sent back to the originating MEP. An 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 as 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-15
16 — Protocol handling in a Layer 2 forwarding model
CFM support in the ISAM The 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. 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 supports MIPs at the GE Ethernet LT board NNI and HC-UNI ports. Within these MPs the ISAM responds to LBMs and to LTMs coming from the network and generation of LTM and unicast LBMs towards the network.The ISAM responds to LBM coming from the user (see Broadband Forum TR-101). On the MEPs at UNI ports and network-facing MEPs, the ISAM supports generation and reception of CCM messages from the network. For CCM messages, the ISAM supports fault detection and notification as per 802.1ag. On the MEPs at UNI port and network-facing MEPs on the line boards ISAM supports responder functionality for Synthetic Loss Measurement (SLM). These MEPs support reception of Synthetic Loss Measurement Frames and Generation of Synthetic Loss Reply (SLR). 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 DSL and GPON access solutions, the ISAM supports the following on the NT board:
• configuration of MIPs and DOWN MEPs on network facing v-VPLS SAPs and • • • • •
VPLS SDPs configuration of UP MEP on LT SAPs on the NT board support for generation of LTM and unicast LBM messages from MEPs configured on the NT board support for receiving and responding to LTM and unicast/multicast LBM messages received from the NT board and the user support for generation of unicast LBM messages from NT support for generation and processing of CCM Messages on Down MEPs on network facing v-VPLS SAPs and VPLS SDPs
For GPON access solutions, the ISAM (acting as an OLT) supports the ability to configure MD, MA, MEP and MIP on ONT UNI ports (via OMCI ME):
• single VLAN-aware MAs can be configured on the ONT UNI ports (for MIP- and network-facing MEP operations).
• a single VLAN-unaware MA can be configured on the ONT (for UNI-facing MEP operations). • MIPs and network facing MEPs can be configured at ONT UNI ports. • maintenance points on LT or NT are NOT supported.
16-16
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
Refer to the ONT user documentation for a more complete description of ONT-specific CFM support. Note 1 — In the GPON access solution, CFM is only supported on the
C and S+C cross connect forwarding model (used via ONT Ethernet UNI). For voice services via ONT RJ-11 and ETH UNI, the ISAM GPON access solution support CFM on iBridge VLAN. Note 2 — The ISAM does not support CFM on the EPON LT board
in this release.
16.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. Packets from unauthenticated subscribers are dropped at the LT until an 802.1x session is set-up after authentication by an external RADIUS server, see Figure 16-10.
• 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 and the EPON LT board UNI ports do not support 802.1x
Figure 16-10 802.1x in the ISAM
LT
IHub
LT
NT Control
802.1x
CPE
Ethernet
ER
Performs authentication by means of contacting a RADIUS server. The result is sent back to the LT.
Handles the 802.1x protocol, communicates with the system controller to perform the authentication, controls the port state.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-17
16 — Protocol handling in a Layer 2 forwarding model
16.6
BCMP The Broadband Access Network Cluster Management Protocol is a protocol defined within the context of using cable access for IP-based networks. The BCMP protocol is used by the BCMP client to retrieve management related configuration (such as management VLAN, management IP, SNMP community name and so on) from BCMP server. The BCMP client is usually collocated with the EPON over Coax (EOC) Head-end, and utilized by the EOC Head-end to get above configuration data during initialization. Once the EOC Head-end gets the configuration, it can be managed by the network management system. The BCMP protocol can be enabled or disabled by the operator to allow the EPON OLT to act as the BCMP proxy for resolution of BCMP packets which are sent from the BCMP client and the BCMP server, and further to relay the BCMP packets between the BCMP client and the BCMP server. For BCMP protocol handling on the LT board:
• in upstream: BCMP receives the L2 packets, extracts the L2 information and then sends it to the NT board
• in downstream: BCMP receives L2 information from the NT board, constructs a L2 response packet for forwarding through the host message interface For BCMP protocol handling on the NT board:
• in upstream: BCMP receives the L2 information from the LT board, constructs L3 packets to maintain the BCMP forwarding table, and relays upstream packets towards the configured BCMP server • in downstream: BCMP receives the L3 response from the BCMP server, looks up the BCMP forward table, constructs the L2 information and relays it to the corresponding LT board • The BCMP proxy uses the same IP address as the one used for OLT management and OAM Figure 16-11 shows an overview of the BCMP protocol.
16-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model Figure 16-11 BCMP Protocol Overview BCMP Server
NT-BCMP Proxy OLT
HS
LT
LT
LT
LT
Pon...Pon
Pon...Pon
ODN
ODN
ONU
ONU
BCMP Client
BCMP Client
EOC
EOC
NT-BCMP Proxy
EOC
CDN
CDN
EOC
The user data stream can be forwarded through the EPON OLT using the S+C RB mode. However, to forward the SNMP packet transparently through the OLT, configuration of a specific management VLAN for the SNMP packet is required.
16.7
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 provides ARP handling functionality sufficient to prevent broadcast storms toward the subscribers. This is achieved in the following ways:
• 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). For EPON LT boards, all ARP requests will be dropped (not configurable) when an ARP request is received from an Ethernet network interface.
•
For GPON access solutions, the above description is also applicable to stacked iBridge mode. ARP reply messages receive no special treatment compared to any other data packet.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-19
16 — Protocol handling in a Layer 2 forwarding model
• VLAN cross-connect mode ARP requests are forwarded transparently downstream and policed upstream using the control protocol packet policer. • 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 checks the binding of a specific customer, learned via DHCP snooping. An ARP packet is only accepted if the MAC source address and the IP source address in the ARP payload correspond to a specific customer having established IP connectivity on that port. Valid ARP requests will be forwarded to the network. In case of static IP address configuration, the ARP relay performs a similar check for the sender IP address. The packet is accepted if this address is configured on that port. The ISAM supports counters that track the number of ARP packets that have been dropped per VLAN port because they contain spoofed information in the ARP payload. 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 and HC-UNI ports do not
support secure forwarding. Note 3 — For DSL LTs and GE Ethernet LT board UNIs, the above
description also applies to S+C iBridge forwarding mode. Note 4 — For EPON LT boards in VLAN cross-connect mode, secure
forwarding cannot be enabled. Therefore, the ARP request and reply will always be transparent. Note 5 — For GPON and EPON LT boards, the above description
also applies to S+C iBridge forwarding. Note 6 — For GPON LTs in S+C cross-connect mode, secure
forwarding cannot be enabled
16.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.
16-20
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
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. Broadband Forum 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 Agent The 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 access:
• the iBridge, • 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 The Layer 2 DHCP relay agent is supported for the L2 forwarding modes above, irrespective of whether secure forwarding is enabled or not. The Layer 2 DHCP Relay Agent functions can be split in parts:
• Relaying DHCP messages to and from network and subscriber interfaces • Option 82 handling Note 1 — The layer 2 DHCP Relay Agent is only supported on the GE
Ethernet LT board UNI and HC-UNI ports. Note 2 — For EPON access, DHCP Relay Agent is not supported on
cross-connect mode since there is no protocol-aware cross-connect. Relaying DHCP messages to and from network and subscriber interfaces
Relaying DHCP messages in iBridge and VLAN cross-connect
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-21
16 — Protocol handling in a Layer 2 forwarding model
The Layer 2 DHCP Relay Agent for the iBridge and for the protocol-aware cross-connect forwarding modes is distributed over the LT boards. Figure 16-12 Layer 2 DHCP relay implementation) US: Bridge to the network interfaces (unicast packet forward based on FDB, broadcast packet: flood to all the network interfaces that participate in the VLAN DS: Bridge to the LTs/subtending interfaces (unicast packet: forward based on FDB, broadcast: flood to all network interfaces that participate in the VLAN
LT
IHub
DHCP relay
Ethernet
ER
IP network
DHCP client
LT
NT
CPE
DHCP server US/DS: DHCP boadcast or unicast packet
US: adds option 82 and sends packet to xHub DS: remove option 82 and send on to correct user port
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. 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 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. 16-22
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
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 inserts 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 restores 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 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 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 Note — The values for the circuit ID and the remote ID are not allowed to be identical.
Insertion of the circuit ID and/or remote ID can be enabled or disabled per VLAN in iBridge or VLAN cross-connect mode. For EPON SFU, option 82 info will be filled by the OLT. Any option 82 from the SFU is untrusted, the OLT will discard such a DHCP packet with option 82 from the SFU, For EPON MDU, option 82 info will be filled by both the MDU and the OLT. The option handling mode should be consistent between the OLT and the MDU, or the OLT will discard this kind of packet. The OLT will discard such a DHCP packet without option from the MDU unless option 82 is configured as 'notAdd' case.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-23
16 — Protocol handling in a Layer 2 forwarding model
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, for example, at ATM PVC and at DSL line level, then the most fine grained level will be used. In the example the Customer ID configured for an ATM PVC will take precedence over the customer ID configured at the DSL line. It is possible to configure a system-level Customer ID. When doing so, the system has the following behavior:
• If the customer ID at the interface level (vlan.port, UNI) is set to the default value “available”, then the customer ID configured at system-level will be used for that interface. This can be useful in case an operator wants to use the same Customer ID on all UNIs, without having to configure it on each individual UNI. • In case a specific user value is configured for a UNI or vlan.port, it takes precedence over the system-level customer ID setting. 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” • for Ethernet[/DSL] based user interfaces that are served via a GPON LT, the default value is “Access_Node_ID eth Rack/Frame/Slot/Port/ONU/OnuSlt/UNI” • for Ethernet[/DSL] based user interfaces that are served via an EPON LT, the default value is “Access_Node_ID eth Rack/Frame/Slot/Port/ONU EP”. For SFU, the default value is “Access_Node_ID eth Rack/Frame/Slot/Port/ONU OnuSlt/OnuPort:atm|eth/Port_XPI.Port_XCI EP” for MDU. 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 • Frame: shelf number in the rack. The variable is called “Frame” to be in line with TR-101
• Slot: slot number in the shelf. • Port: port number on the LT board. On DSL/Point-to-Point LTs the “Port” stands for an end-user DSL/fiber interface, while on the GPON LT the “Port” stands for an entire PON
16-24
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
• LzPrt: Same as “Port” but with a different syntax: it uses 3 ASCII characters that • • • • • • • • • • • •
correspond to the port number with leading zeros (for example: '001', '002', '015', '064') ONU (for GPON LT only): denotes the ONT/MDU identifier on the PON LzOnu (for GPON LT only): denotes the ONT/MDU identifier on the PON, with 3 digits and leading zeroes (for example, ONU 1 denoted as 001, ONU 10 denoted as 010 and ONU 100 denoted as 100). OnuSlt (for GPON LT only): slot number on the ONT/MDU UNI (for GPON LT only): UNI within the ONU-Slot 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” U-VID: VLAN ID on user interface in case of tagged frames and nothing inserted as VLAN id in case of untagged frames. The special character / delimiter in front of this keyword in case of untagged frames is not inserted. DUVID: same as U-VID, but in this case the special character / delimiter in front of this keyword in case of untagged frames is inserted. LzQVID: VLAN ID on user interface with 4 digits and leading zeroes (for example, VLAN ID 1 denoted as 0001, VLAN ID 10 denoted as 0010, VLAN ID 100 denoted as 0100 and VLAN ID 1000 denoted as 1000). I-VID: Refers to the second or inner VLAN-id in dual-tagged Ethernet frames. Note — and keywords can also be used instead of respectively and . The keywords and can be used to specify the slot and port number without leading zero. This gives an alternative for the and keywords as defined above and provides full flexibility as to the wanted/required syntax.
Bandwidth information
Broadband Forum TR-101 defines additional sub-options on top of those defined in IETF RFC 3046. Among others it specifies a set of sub-options to pass DSL line bandwidth characteristics. The insertion of the line rate characteristics per VLAN in iBridge or VLAN cross-connect mode can also be enabled or disabled. The ISAM can be configured to either add only the actual line rate information in DHCP option 82, or to add the full set of access line parameters defined in TR-101. For example, this includes the minimum, maximum, attainable and actual line rates and interleaving delays. This functionality is supported on the DSL and Ethernet LT boards, but not on the GPON LT boards.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-25
16 — Protocol handling in a Layer 2 forwarding model
The EPON LT board does not add the line rate information in DHCP option 82. However, the option may be added by the MDU ONT. In this case, the OLT will transparently forward the associated information. Note — This functionality is not supported in this release for the GPON LT.
(Layer 3) DHCP Relay Agent This is further described in chapter “Protocol handling in a Layer 3 forwarding model”, section “Layer 3 DHCP relay agent”.
DHCP snooping If 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. Due to no protocol aware cross-connect supported on the EPON access, DHCP messages are not snooped and will always be transparent in VLAN cross-connect. More information on DHCP snooping can be found in chapter “Protocol handling in a Layer 3 forwarding model”.
16.9
IGMP For more information about IGMP, see chapter “Multicast and IGMP”.
16.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.
16-26
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
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. Broadband Forum TR-101 specifies that in such case the DSLAM has to add some subscriber information to the upstream discovery messages, that is, 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. Note — PPPoE Relay is only supported on the GE Ethernet LT board
UNI port type.
Figure 16-13 PPPoE relay PPPoE traffic
LT
IHub
LT
NT
Ethernet
ER
PPPoE traffic
CPE CPE US/DS: PPPoE session setup frames
US: add PPPoE relay session ID, and forward DS: forward
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 the 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. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-27
16 — Protocol handling in a Layer 2 forwarding model
The ISAM can be configured to either add only the actual line rate information in PPPoE discovery messages, or to add the full set of access line parameters defined in TR-101, such as the minimum, maximum, attainable and actual line rates and interleaving delays. This functionality is supported for the DSL and Ethernet LT boards. The functionality of adding the full set of access line parameters is not supported on the GPON LTs, but GPON can add the actual line rate information. The EPON LT board does not add the line rate information in the PPPoE discovery message. However, the information may be added in the PPPoE message by the MDU ONT. In this case, the OLT will transparently forward the associated information.
PPPoA to PPPoE interworking In 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 16-14 Network topology PPPoA - PPPoE Interworking ATM termination IP Edge USB
ISP
Local Loop EMAN
USB Modem Ethernet
IP
Bridge
Srv: Video
I IP Routing Gateway
Srv: VoIP
NE L2TP PPP-L2TP interworking
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
16-28
When a subscriber initiates a PPPoA session, the ISAM first initiates a PPPoE session towards the BRAS. The involved PAD-x messages are sent with a VLAN tag with priority 7.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
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. 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 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 no 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 than 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 cannot 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-29
16 — Protocol handling in a Layer 2 forwarding model
Therefore, the ISAM removes state for 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). Note — PPPoA to PPPoE interworking is not supported on the GPON and EPON LT, nor on the GE Ethernet LT board. It is also not supported on DSL LTs in Stacked iBridge model.
PPPoE relay with MAC address concentration In 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. However, some legacy Ethernet switches cannot cope with the large number of MAC addresses required to route PPPoE frames to the large number of DSL or GPON subscribers connected to the EMAN through the ISAMs (at least one MAC address per 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 tens 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 1 — PPPoE relay with MAC address concentration is not
supported on the EPON LT, nor on the GE Ethernet LT board HC-UNI and NNI port types. Note 2 — PPPoE relay with MAC address concentration is not
supported on DSL LTs for Stacked iBridge model.
16-30
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
16.11
DHCPv6
Lightweight DHCPv6 Relay Agent The 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, that is, 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)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-31
16 — Protocol handling in a Layer 2 forwarding model
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. Note — The lightweight DHCPv6 relay agent is not supported on the
GE Ethernet LT board NNI port type.
Bandwidth information The Lightweight DHCPv6 Relay Agent supports the insertion of the “Vendor-specific Information” Option (option 17) as defined in RFC 3315 in order to add information about access loop characteristics. This is similar to the DHCP behavior specified for IPv4 (see section “Bandwidth information”). The ISAM can be configured to add the full set of access line parameters in DHCPv6 option 17, as defined in TR-101. This includes among others the minimum, maximum, attainable and actual line rates and interleaving delays. This functionality is supported for the DSL LT boards (except the 72-port ADSL2+ LT board) and Ethernet LT boards (except the NNI port type). The functionality is not supported on the GPON and EPON LT boards.
DHCPv6 trusted/untrusted port configuration The 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 the user side will be discarded and not relayed.
DHCPv6 Relay Agent See chapter “Protocol handling in a Layer 3 forwarding model”, section “DHCPv6 Relay Agent”.
DHCPv6 snooping See chapter “Protocol handling in a Layer 3 forwarding model”. Note 1 — DHCPv6 snooping is not supported by the GE Ethernet LT
board HC-UNI and NNI port types. Note 2 — DHCPv6 is not supported for EPON access, but is supported for 10G EPON access.
16-32
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
16 — Protocol handling in a Layer 2 forwarding model
16.12
ICMPv6 ICMPv6 includes Neighbor Discovery (ND) messages as well as Multicast Listener Discovery (MLD) messages. In general, upstream and downstream ICMPv6 messages are handled transparently without specific processing. This means that downstream multicast ICMPv6 messages are typically flooded by default. The filtering of ICMPv6 unicast and multicast ICMPv6 packets in an iBridge or VLAN cross-connect forwarder can be enabled or disabled. This allows fine tuning of the ICMPv6 message handling for security purposes. When enabled, the following ND and MLD messages must be discarded:
• • • •
Downstream Router Solicitation (RS) Upstream Router Advertisement Upstream Redirect Upstream MLD Multicast Listener Queries
When using MAC address translation or virtual MAC addresses, the MAC address field present in the ICMPv6 Neighbor Discovery message payload must be translated. See section “Virtual MAC” for more information on virtual MAC addresses.
16.13
LLDP ISAM supports advertising using Link Layer Discovery Protocol (LLDP) (IEEE 802.1AB 2009) on its uplink ports, this allows upstream node to discover ISAM as part of network topology. LLDP Implementation on ISAM can be configured on a per uplink port basis to advertise to following destinations:
• 'nearest bridge' MAC Address (01-80-C2-00-00-0E) • 'nearest non-Two Port MAC Relay bridge' MAC Address (01-80-C2-00-00-03) • 'nearest customer bridge' MAC Address (01-80-C2-00-00-00) Following TLVs are supported:
• • • • • • •
Chassis ID Port ID Time To Live Port Description System Name System Description Management Address
Each uplink port on ISAM can be configured to advertise different TLVs to different destination MAC address. A maximum of 3 LLDP sessions i.e. one per destination MAC address can be configured.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
16-33
16 — Protocol handling in a Layer 2 forwarding model
ISAM shall process any untagged LLDP PDUs received on network/access ports if corresponding LLDP destination MAC bridge is enabled on that port. Any tagged LLDP PDUs are forwarded in the context of the service associated. LLDP packets are not blocked due to xSTP or LACP port states.
16-34
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
17 — IP routing
17.1 Introduction
17-2
17.2 IP routing features 17.3 IP routing model
17-2 17-6
17.4 Routing in case of subtended ISAMs
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
17-10
November 2013
17-1
17 — IP routing
17.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 Access Control List (ACL), and this at various granularity levels. Improved security:
• Subscriber MAC addresses are never propagated to the network • 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).
17.2
IP routing features In the next sections, unless stated differently, the description applies to both IPv4 and IPv6.
Packet forwarding based on the IP addresses Implementing 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.
Next hop behavior The 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 or reduced IPv6 Neighbor Cache size) and ARP messages issued by the subscribers are terminated by the ISAM, reducing the control plane load at the IP edge. 17-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
17 — IP routing
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 authentication Subscriber interfaces (IPoE over ATM or EFM/Ethernet) can be authenticated through 802.1/RADIUS protocols before connecting to a router in ISAM.
Subscriber interface - Unnumbered In order to make the subscriber addressing scalable, subscriber interfaces (on the DSL lines or ONT UNIs) are considered as unnumbered IP interfaces attached to the IP router. That is, 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 agent DHCP 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 or ONT UNI into the DHCP messages.
DHCPv6 relay agent When performing IPv6 forwarding/routing, the ISAM supports a DHCPv6 Relay Agent according to RFC 3315. This allows to:
• Convert IPv6 multicast messages into unicast messages towards a set of predefined DHCPv6 servers to reduce the IPv6 multicast traffic load in the network. • Add option 18 and/or option 37 to uniquely identify the requesting subscriber by inserting the identification of his DSL line or ONT UNI into the DHCPv6 messages.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
17-3
17 — IP routing
More details on the DHCPv6 processing can be found in chapter “Protocol handling in a Layer 2 forwarding model” and chapter “Protocol handling in a Layer 3 forwarding model”.
Subscriber routes - Dynamically learned through DHCP snooping For 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 interfaces of the subscribers by snooping the DHCP messages exchanged with these subscribers (populate the snooped IP address of the subscriber, 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. However, 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. In the case of IPv6, DHCPv6 snooping is performed to learn the subscriber routes:
• When DHCPv6 is used for Prefix Delegation, the IPv6 forwarding table is populated with the delegated prefix, indicating this is a non directly attached subnet. These are so-called “DHCPv6 managed routes”. The ISAM maintains the relation between the delegated IPv6 prefixes, its lease time and the corresponding subscriber-facing interfaces. • In case of stateful DHCPv6 address assignment, managed (DHCPv6) entries are created in the Neighbor Cache for the /128 IPv6 addresses that are assigned to the IPv6 hosts. The ISAM maintains the relation between the IPv6 address, its lease time and the corresponding MAC address.
Network routes - Dynamically learned through routing protocol Network routes can be learned dynamically through routing protocols, hence reducing the cost of operation. Connectivity to the network is automatically established by means of IP routing protocols. 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 subscribers IPv4 network routes can be advertised to the subscribers using RIP. IPv6 network routes cannot be advertised to the subscribers.
17-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
17 — IP routing
IPv4 subscriber routes (individual or aggregated routes) can be advertised to the network using RIP, and other routing protocols. This reduces the provisioning work at the network and/or CPE side. IPv6 subscriber routes (individual or aggregated routes) can be advertised to the network using OSPFv3 and BGP-4.
User-to-user communication User-to-user communication is always enabled via the IP router. ISAM provides local ARP proxy or local Neighbor Discovery proxy for all directly connected subscriber subnets (which need to be explicitly enabled when user-to-user communication is required). Note that user-to-user communication can still be prevented by means of ACLs.
IPv4 option processing ISAM supports the processing of following IPv4 options:
• Router alert • Time stamp • Record route ISAM does not process source route option, that is, IP packets including source route options are forwarded transparently.
MTU The L2 MTU size is fixed to 2048 and not configurable. The L3 MTU size can be configured per interface. The default value is 2030, but if required a lower value can be configured. 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. ECMP Up to 4 Equal Cost Multi Path (ECMP) next-hops are supported per route.
Directed broadcast ISAM 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 Redirect ISAM does not support ICMP Redirect. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
17-5
17 — IP routing
ICMPv6 redirect The ISAM does not support ICMPv6 Redirect.
17.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 router on the NT board.
Public IP routing instance Base router is the default IP router instance that is connected to the public IP network domain and manages the topology of the public domain. The base router is connected to the public IP network via the network facing ports of ISAM. Network facing ports can be configured in two exclusive modes: network or access.
• On a port of mode network, an IP interface can be directly created. • On ports of mode access, an IP interface cannot be directly created. It needs to be done in two steps:
• Associate the access port(s) for a particular encapsulation value with a v-VPLS • Create an IP interface on top of this v-VPLS by using the Internet Enhanced Service (IES) and a virtual port.
Subscribers can also access the services offered via the public IP network domain. In this case, Internet Enhance Service (IES) needs to be explicitly created and needs to be enabled on the subscriber access interfaces. The IES service provides a way to attach subscribers to the base router since the base router cannot have IP interfaces directly on the subscriber interfaces. These concepts are illustrated in Figure 17-1 and Figure 17-2. Even if it is not required to provide public network access to subscribers, still IES service needs to be explicitly configured to attach the base router to the public domain since plain base router IP interface configuration on the physical network ports is not supported (that is, physical port mode: network is not supported by ISAM).
17-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
17 — IP routing Figure 17-1 IPv4 routing - Base router with IES service ISAM / OLT
iBridge VLAN with secure forwarding enabled
User IP address part of the user gateway interface subnet
IPoE user interface 802.1x authentication can be enabled (tagged or untagged)
NT Base Router
GPON LT
ONT
DHCP Relay Agent
Proxy
iBridge VLAN
RG
User gateway Local ARP Interface
IP interface facing network
Routing Protocols
SAP IES Service
……
IPoA - IPoE interworking
IPoE user interface (DSL/PVC/VLAN or DSL/VLAN)
vMAC can be enabled
LT
CPE
EMAN
v-VPLS
LT ports (facing users)
v-VPLS
IPoA user interface (DSL/PVC)
Virtual port
User gateway v-VPLS
IP edge
Network v-VPLS
IP network
L2 switch
iBridge VLAN
IPoA/IPoE
CPE
User gateway VLAN (VLAN attached to user gateway interface)
Physical port facing network
CPE iBridge VLAN with secure forwarding enabled User IP address part of the IPoE user interface user gateway interface (DSL/PVC or DSL), subnet untagged
802.1x authentication can be enabled
Figure 17-2 IPv6 routing - Base router with IES service ISAM
Not applicable for IPv6
NT
Bridged, routed or routed unnumbered
Base Router
LT CPE
User gateway Local ARP Interface iBridge VLAN
IPoA/IPoE
CPE
Proxy
DHCP Relay Agent
Routing Protocols
IP interface facing network
SAP IES Service
CPE
……
CPE CPE
LT
EMAN
v-VPLS
IPoA - IPoE interworking vMAC can not applicable be enabled
Virtual port
User gateway v-VPLS
Network v-VPLS
IP IP edge network
L2 switch
IPoA/IPoE
iBridge VLAN
IPoE user interface (DSL/PVC/VLAN or DSL/VLAN)
LT ports (facing users)
v-VPLS
IPoA user interface (DSL/PVC)
User gateway VLAN (VLAN attached to user gateway interface)
Physical port facing network
CPE iBridge VLAN with secure forwarding enabled User IP address part of the IPoE user interface user gateway interface (DSL/PVC or DSL), subnet untagged
802.1x authentication can be enabled
IP routing with IES service is achieved by enabling “Base router”, “IES service” and “iBridge” components in ISAM.
• Base router: • IP interfaces facing the network (on ports of mode network) need to be configured • Routing protocols can be enabled on the IP interfaces which are defined directly on
• •
the ports of mode network or which have been created as part of the IES service in order to dynamically learn network routers and/or advertise the subscriber routes to the network (refer to chapter “Protocol handling in a Layer 3 forwarding model”). Supported IPv4 routing protocols: BGP, IS-IS, OSPF, RIP Supported IPv6 routing protocols: BGP, OSPF
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
17-7
17 — IP routing
• IES service: • IP interfaces facing the network (on ports of mode access) need to be configured in the IES service.
• In the context of the IES service: a User gateway IP interface (containing the subnet •
• •
of the subscriber) needs to be configured on top of the user gateway v-VPLS, on behalf of the iBridge VLAN). The subnet of the subscriber gateway IP interface is shared among the subscribers connected to the iBridge 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. DHCP relay agent can be enabled on the user gateway IP interface in order to allow subscribers to retrieve their IP addresses dynamically from DHCP servers (refer to chapter “Protocol handling in a Layer 3 forwarding model”). Local ARP proxy or local Neighbor Discovery proxy needs to be enabled on the user gateway interface in order to enable user-to-user communication (refer to chapter “Protocol handling in a Layer 3 forwarding model”).
• iBridge: • iBridge VLAN needs to be enabled on those subscriber interfaces which need to get access to the IES services.
• Secure forwarding needs to be configured for the iBridge VLAN: Secure forwarding
• • • • •
enables IP anti-spoofing (in upstream, that is, packets received from users) and dynamic learning of the IP addresses assigned to subscribers via DHCP snooping (refer to chapter “Layer 2 forwarding” and chapter “Protocol handling in a Layer 2 forwarding model”). Adding DHCP Option-82 can be enabled for the iBridge VLAN (refer to chapter “Protocol handling in a Layer 2 forwarding model”). Adding DHCPv6 Option 18 and/or option 37 can be enabled for the iBridge VLAN (refer to chapter “Protocol handling in a Layer 2 forwarding model”). 802.1x/RADIUS authentication can be enabled for IPoE subscriber interfaces (refer to chapter “Protocol handling in a Layer 2 forwarding model”). vMAC shall be enabled when IPoE subscribers do not have unique MAC address IPoA/IPoE interworking needs to be configured on those IPoA subscriber interfaces which need to get access to the IES services. Note that IPoA is supported for IPv4 only.
Private IP routing instance The Virtual Private Routed Network (VPRN) service allows creating a private IP routing instance de-coupled/isolated from the public IP network domain. Each VRPN service gets it's own private routing/forwarding instance. ISAM supports multiple VPRN services. The VPRNs are isolated from one another, likewise the VPRNs are isolated from the Base Router with its IES services. VPRN IP interfaces can only be created on user-facing ports or on network-facing ports of mode access.
17-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
17 — IP routing Figure 17-3 IPv4 routing - VPRN service ISAM / OLT
User IP address part of the user gateway interface subnet
NT
IPoE user interface 802.1x authentication can be enabled (tagged or untagged)
VPRN Service
GPON LT
User gateway Local ARP Interface
ONT
DHCP Relay Agent
Proxy
iBridge VLAN
RG
Multiple VPRN instances
IP interface facing network
Routing Protocols
SAP
……
IPoA - IPoE interworking
vMAC can be enabled
LT
CPE
EMAN
v-VPLS
IPoE user interface (DSL/PVC/VLAN or DSL/VLAN)
LT ports (facing users)
v-VPLS
IPoA user interface (DSL/PVC)
Virtual port
User gateway v-VPLS
IP edge
Network v-VPLS
IP network
L2 switch
iBridge VLAN
IPoA/IPoE
CPE
User gateway VLAN (VLAN attached to user gateway interface)
Physical port facing network
CPE iBridge VLAN with secure forwarding enabled User IP address part of the IPoE user interface user gateway interface (DSL/PVC or DSL), subnet untagged
802.1x authentication can be enabled
Figure 17-4 IPv6 routing - VPRN service ISAM
Not applicable for IPv6
Multiple VPRN instances
NT
Bridged, routed or routed unnumbered
VPRN Service
LT CPE
User gateway Local ARP Interface iBridge VLAN
IPoA/IPoE
CPE
Proxy
DHCP Relay Agent
Routing Protocols
IP interface facing network
SAP
CPE
……
CPE CPE
LT
v-VPLS
EMAN Virtual port
User gateway v-VPLS
Network v-VPLS
IP IP edge network
L2 switch
IPoA/IPoE
iBridge VLAN
IPoE user interface (DSL/PVC/VLAN or DSL/VLAN)
LT ports (facing users) IPoA - IPoE interworking vMAC can not applicable be enabled
v-VPLS
IPoA user interface (DSL/PVC)
User gateway VLAN (VLAN attached to user gateway interface)
Physical port facing network
CPE iBridge VLAN with secure forwarding enabled User IP address part of the IPoE user interface user gateway interface (DSL/PVC or DSL), subnet untagged
802.1x authentication can be enabled
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
17-9
17 — IP routing
A private IP routing instance is achieved by enabling “VPRN service” and “iBridge” components in ISAM.
• VPRN service: • A VPRN service needs to be created. • IP interfaces facing the network need to be configured, network facing ports should • •
• • • • •
be defined as mode access. In the context of the VPRN service: a user gateway IP interface (containing the subnet of the subscriber) needs to be configured on top of the user gateway v-VPLS, on behalf of the iBridge VLAN. The subnet of the subscriber gateway IP interface is shared among the subscribers connected to the iBridge 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. DHCPv4 or DHCPv6 relay agent can be enabled on the user gateway IP interface in order to allow subscribers to retrieve their IP addresses dynamically from DHCP servers (refer to chapter “Protocol handling in a Layer 3 forwarding model”). Local ARP proxy or local Neighbor Discovery proxy needs to be enabled on the user gateway interface in order to enable user-to-user communication (refer to chapter “Protocol handling in a Layer 3 forwarding model”). Routing protocols can be enabled in order to dynamically learn network routers and/or advertise the subscriber routes to the network (refer to chapter “Protocol handling in a Layer 3 forwarding model”). Supported IPv4 routing protocols: BGP, OSPF, RIP Supported IPv6 routing protocols: BGP
• iBridge: • The same as in section “Public IP routing instance”.
17.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 a hardware implementation and from a provisioning point 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.
17-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
17 — IP routing
This configuration is shown in Figure 17-5. In the H-ISAM, the router function is configured while in the S-ISAMs layer 2 forwarding is in place. Figure 17-5 ISAM sub-network configuration for video traffic (e.g VDSL) Seen by the operator as one big virtual router RG
ONT
R
Aggregation Network
DHCP Relay
L2
One single IP subnet over all Hub + Sub ISAMs
Hub ISAM
LT
NT
EiB
B
LT
NT
EiB
R
Identical LT configuration in Hub and Sub ISAMs
Sub ISAM EiB: Enhanced iBridge
EiB: Enhanced -Bridge
Subtended nodes operating as L3 devices All 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 S-ISAM does forward upstream traffic to the H-ISAM as per the default route announced from the H-ISAM. Figure 17-6 provides a network view. The assumption is that RIP is used to distribute routes towards the subscribers. The red dots indicate where an IP interface is configured.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
17-11
17 — IP routing Figure 17-6 Subtended ISAM operating as a L3 device
IGP
L3 IGP
L3
Aggregation Network
IGP
L3
17-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
18 — Protocol handling in a Layer 3 forwarding model
18.1 Introduction
18-2
18.2 IPv4 Routing Protocols 18.3 ARP
18-2
18-2
18.4 DHCP relay agent 18.5 DHCP snooping
18-3 18-5
18.6 IPv6 routing protocols
18-6
18.7 Neighbour Discovery (ICMPv6) 18.8 DHCPv6 Relay Agent 18.9 DHCPv6 Snooping
18-7
18-7 18-8
18.10 Bidirectional Forwarding Detection
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
18-9
November 2013
18-1
18 — Protocol handling in a Layer 3 forwarding model
18.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” and “IPv6 routing protocols”
• user access protocols: • ARP: see section “ARP” • DHCP Relay: see section “DHCP relay agent” • DHCP: see section “DHCP snooping” • Neighbour Discovery (ICMPv6): refer to section “Neighbour Discovery (ICMPv6)” • DHCPv6 Relay: refer to section “DHCPv6 Relay Agent” • DHCPv6 Snooping: refer to section “DHCPv6 Snooping”
18.2
IPv4 Routing Protocols The following IPv4 routing protocols are supported:
• on network interfaces: RIP, OSPF, IS-IS, and BGP (both i-BGP and e-BGP). • on interfaces towards a subtended ISAM, directly connected to the NT card (that is, not supported on the GE Ethernet card NNI port type): RIP and OSPF • on subscriber interfaces: RIP 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. Note — These routing protocols are extensively described in the FD 100Gbps and 320Gbps NT Router Configuration and Protocol Guide.
The ISAM will report alarms to inform the Manager about lack of resources, major issues and state transitions in the protocol.
18.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”.
18-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
18 — Protocol handling in a Layer 3 forwarding model
ARP handling on the user 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 the following exceptions:
• 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 the 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 (that is, CLI screen, remote server, local file).
ARP handling on the network side Standard ARP Handling applies at the network side:
• for ARP requests received from the network. • for ARP requests ISAM sends to the network.
18.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 agent The functionality is equal to the functionality of the DHCP Relay Agent as described in chapter “Protocol handling in a Layer 2 forwarding model”.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
18-3
18 — Protocol handling in a Layer 3 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 (that is, 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 The ISAM can act as layer 3 DHCP relay agent for the subscribers when configured in router mode. The layer 3 DHCP relay agent is responsible to relay DHCP messages between the subscribers and the DHCP servers as follows:
• Upstream: Broadcast DHCP messages received from the subscribers are unicast to the a list of configured DHCP servers. This list is configured per incoming IP interface associated with the subscribers of a VPRN or IES (base router). 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.
• Downstream: Unicast DHCP messages received from the DHCP servers are either unicast or broadcast (based on the broadcast flag) to the correct subscriber interfaces (using services of the L2 DHCP Relay Agent). 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. Note — The layer 2 DHCP relay agent is located at the LT board and the layer 3 DHCP relay agent is located at the NT board.
Layer 3 DHCP relay in routed mode is configurable per IP interface of a VPRN or an IES (base router). When layer 3 DHCP relay is enabled on a particular IP interface one can configure:
• a list of up to eight DHCP servers • the Gi address to be used: by default the primary address of the IP interface is used, to overrule the default behavior the operator can specify any other primary/secondary IP address of the concerned router instance • whether or not to use the Gi-address as the source IP address As an IP interface will be associated with a VLAN, the L3 DHCP relay agent instance will be different for services that use another VLAN or another PVC.
18-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
18 — Protocol handling in a Layer 3 forwarding model Figure 18-1 L3 DHCP Relay NT
LT 1 VLAN 1 LT x LT16
VPRN / IES VLAN 2
: IP interface
18.5
Per IP interface at user side: - primary IP address - [secondary IP address(es)] - L3 DHCP relay data: -list of DHCP servers -[gi address] -[source IP Address]
DHCP snooping In the IP routing model, the iBridge model and the VLAN cross-connect models (assuming secured forwarding is enabled for the last two models), 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. 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). Usually, the NT board does not need to perform DHCP snooping except for the following two cases:
• The Lawful Intercept functionality is enabled on the system. In this case, the NT board snoops DHCP messages in order to establish filters in the data plane for specific customer traffic. More details can be found in chapter “Resource management and authentication”. • IPv6 routing is enabled on the system. In this case, the NT board snoops DHCPv6 messages to learn the IPv6 prefixes assigned to the subscribers attached to the ISAM and to dynamically populate the IPv6 routing table (FIB).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
18-5
18 — Protocol handling in a Layer 3 forwarding model
In all cases, the DHCP sessions are preserved against:
• an NT board reset due to a software or a hardware failure • an NT board reset due to software upgrade The ISAM supports counter that track the number of packets that have been dropped per line because they contain a spoofed IPv4 source address. These counters can be made available to an external management system for troubleshooting. The DHCP sessions are stored in the reset-safe memory of the LT and the 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, a complete ISAM power down), the subscribers will have to re-establish DHCP sessions in order to recover the IP connectivity.
18.6
IPv6 routing protocols The following IPv6 routing protocols are supported:
• OSPFv3 and BGP-4 (both i-BGP and e-BGP). Note — These Routing Protocols are extensively described in the FD 100Gbps and 320Gbps NT IHub Router Configuration and Protocols Guide.
OSPFv3 All features that relate to OSPFv2 in the context of an IPv4 routed network remain applicable to OSPFv3. OSPFv3 for distribution of IPv6 routes is supported in the Base Router only.
BGP-4 All BGP features used for IPv4 remain applicable to IPv6. In addition, the following RFCs are supported:
• RFC 4760 - Multiprotocol Extensions for BGP-4 • RFC 2545 - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing BGP-4 is supported in the Base Router as well as in VPRNs.
18-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
18 — Protocol handling in a Layer 3 forwarding model
18.7
Neighbour Discovery (ICMPv6) Proxy ND Proxy Neighbor Discovery (ND) is similar to local proxy ARP. This feature is useful in a residential bridging environment where end users are not allowed to communicate to each other directly, even when they would belong to the same globally routable IPv6 subnet. Proxy ND can be enabled per IPv6 interface of a VPRN or IES (base router), and when enabled, the router will behave as follows:
• Respond to all neighbor solicitation messages received on the interface for IPv6 addresses in the subnet(s) with system MAC address as Link-layer address. • Forward traffic between hosts in the subnet(s) of the interface. • Drop traffic between hosts if the link-layer address information for the IPv6 destination has not been learned.
Dynamic Neighbor Cache population based on Neighbour Discovery Upon receiving a Neighbour Solicitation message from the host or Residential Gateway, the ISAM adds an entry to the Neighbor Cache for the IPv6 (link-local) address and corresponding MAC address (provided no entry exists yet). The entry is put as STALE. Next, the ISAM performs a reachability check by sending a unicast Neighbour Solliciation to the host / Residential Gateway. When successful, the entry in the Neighbour Cache is updated to state REACHABLE.
18.8
DHCPv6 Relay Agent Lightweight DHCPv6 Relay Agent The functionality is equal to the functionality of the Lightweight DHCPv6 Relay Agent as described in chapter “Protocol handling in a Layer 2 forwarding model”.]
DHCPv6 Relay Agent When performing IPv6 forwarding/routing, the ISAM supports a DHCPv6 Relay Agent according to RFC 3315. The operator can enable multiple instances of a DHCPv6 Relay Agent per VRF (that is, per IPv6 interface), each instance being characterized by:
• A global unicast IPv6 address (which will be used as the value of the link-address field in the DHCPv6 messages sent on that interface) • A list of up to 4 DHCPv6 servers to be addressed The ISAM relays DHCPv6 messages to all configured DHCPv6 servers. It is up to the user to accept one of these servers (ISAM forwards DHCPv6 replies from multiple DHCPv6 servers to the same user).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
18-7
18 — Protocol handling in a Layer 3 forwarding model
This could be useful for operators that combine multiple services within a single VRF, while using a dedicated DHCPv6 server per service. In that case, the ISAM must be able to forward DHCPv6 messages associated with a given service to the relevant DHCPv6 server and send those messages with a dedicated link-address field value per service. Next to the LDRA behavior, the DHCPv6 Relay Agent on the NT board can optionally insert a second “Interface-ID” (option 18) or “Relay Agent Remote-ID” (option 37). This may be used in case the DHCPv6 server and/or the Residential Gateway are not handling DHCPv6 options that could help discriminating the requested service (for example, the User Class Option (option 15) or the Vendor Class Option (option 16)). The DHCPv6 server will use the Interface-ID in order to select the IPv6 address pool to use for assigning the requested service related IPv6 address.
18.9
DHCPv6 Snooping The LT board snoops the following information from the DHCPv6 packets:
• the user IPv6 address or prefix: The ISAM discards any IPv6 packets whose IPv6 source address does not match any IPv6 addresses or prefixes allocated to the user interface. The ISAM will only check the first 64 bits of the 128-bit IPv6 address. This is sufficient because the last 64 bits of the IPv6 address hold the “Interface Identifier”; the Interface ID is typically based on the interface MAC address and therefore not of relevance to the IPv6 anti-spoofing function. • IPv6 address or prefix lease: The ISAM also monitors the IPv6 address or prefix lease. The relation between the subscriber IPv6 address or prefix and the subscriber interface is removed when the lease time is expired. In case of IPv6 forwarding, DHCPv6 snooping is also performed at the NT board.
• When DHCPv6 is used for Prefix Delegation, the IPv6 forwarding table is populated with the delegated prefix, indicating this is a non directly attached subnet. These are so-called “DHCPv6 managed routes”. The ISAM maintains the relation between the delegated IPv6 prefixes, its lease time and the corresponding subscriber-facing interfaces. • In case of stateful DHCPv6 address assignment, managed (DHCPv6) entries are created in the Neighbor Cache for the /128 IPv6 addresses that are assigned to the IPv6 hosts. The ISAM maintains the relation between the IPv6 address, its lease time and the corresponding MAC address.
18-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
18 — Protocol handling in a Layer 3 forwarding model
18.10
Bidirectional Forwarding Detection To protect key applications, a network is usually designed with redundant backup links. Devices need to quickly detect communication failures and restore communication through backup links as soon as possible. On some links, such as Packet over SONET (POS) links, devices detect link failures by sending hardware detection signals. However, some other links, such as Ethernet links, provide no hardware detection mechanism. In order to detect network failures, devices can use the failure detection mechanisms that are built into signaling protocols (for example, routing protocols), based on the use of hello messages. These messages typically use low message rates, resulting in failure detection times of more than one second. This is too slow for some applications. Some routing protocols, such as OSPF and IS-IS, provide a fast hello mechanism for failure detection. Such a mechanism still has a failure detection rate of at least one second and is protocol-dependent. Bidirectional Forwarding Detection (BFD) provides a general-purpose, standard, medium and protocol-independent fast failure detection mechanism. It has the following benefits:
• Detecting failures on any bidirectional forwarding paths, such as direct physical link, virtual link, tunnel, MPLS Pseudowire, multi-hop path, and unidirectional link, between network devices. • Providing consistent fast fault detection time for upper-layer applications. • Providing a configurable failure detection time which can be sub-second to speed up network convergence, short application interruptions, and enhance network reliability. The ISAM supports BFD for fast failure detection with the following protocols:
• • • • • • • •
Static routing (for example, configured routes) OSPF IS-IS BGP PIM-SSM MPLS Pseudowires (T-LDP) RSVP-TE Ethernet Link Aggregation Group (LAG)
BFD can operate either over a single IP hop, or over multiple hops, for example, across different routing areas. The latter is the case, for example, when protecting a BGP session running between two routers that are not directly attached. The ISAM can configure the message rate for each BFD session. Multiple BFD sessions can be supported in parallel (for example, one BFD session per IP interface, terminated on the directly attached peer). The BFD message rate can be configured according to the required detection speed: high message rates provide for faster failure detection. It is an operator decision to select the balance between the number of BFD sessions and the message rate.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
18-9
18 — Protocol handling in a Layer 3 forwarding model
The configuration of the BFD polling interval should take into account the time required for the packet to reach the destination. For instance, when using multi-hop BFD, the polling interval may be set higher than one second to avoid the BFD session from timing out before the packets reach the destination. When using multi-hop BFD over an Ethernet LAG, one should take care that the failure detection time is set greater than the LAG failure detection time of one second. Otherwise, the BFD session would time out too soon, which would defeat the purpose of using an LAG.
18-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
19 — Multicast and IGMP
19.1 Overview
19-2
19.2 Advanced capabilities
19-5
19.3 System decomposition
19-15
19.4 Multicast and forwarding models
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
19-19
November 2013
19-1
19 — Multicast and IGMP
19.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. Note — IGMP is specified in IETF RFC 2236 (IGMPv2) and RFC 3376 (IGMPv3).
By default, bridges flood multicast frames as well as IGMP packets between the multicast router and the hosts. This not only creates a security issues when end users can see each other's IGMP messages, but also 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. Note — IGMP snooping is specified in IETF RFC 4541.
Figure 19-1 IGMP enabled bridges Member group A
Host Video Head end
Member group A Edge Router
LAN
IP network
Bridge
Member group A Member group B
Bridged VLAN data IGMP Member group B
Data plane IP 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”. 19-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
19 — Multicast and IGMP
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. Note — Remark that multiple (32) IP addresses map to the same multicast IEEE 802 MAC address.
Besides a forwarding database for unicast traffic, 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. 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.
In Figure 19-2, the multicast forwarder is shown as segregated from the unicast forwarder for the same VLAN. Multicasting, as opposed to flooding, is only supported in VLANs that have IGMP enabled, so-called multicast VLANs. Figure 19-2 Multicast data plane Port P2
DSL interfa ce
Unicast forwarding iBridge
VLAN Port
Multicast forwarding
GE interface
224.0.10.2
Port P1 240.0.10.1
Multicast Fwd Ta ble VLAN Multicast IP address
Egress ports
15
240.010.1
{ P1 }
15
240.010.2
{ P1, P2 }
IGMP can only be enabled on network VLANs whose unicast forwarder is an iBridge, but not a cross-connect VLAN. IGMP can also be enabled on a network VLAN terminated in an IP interface. But then, for multicast traffic, this network VLAN must have user-side ports besides network-side ports, see Figure 19-2.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
19-3
19 — Multicast and IGMP Figure 19-3 Common network VLAN for L3 unicast and multicast
ISAM Edge Router
IHub
LT CPE
VLAN B
VRF Edge Router
VLAN A
L3 unicast data traffic (IP routed...) multicast data traffic L2 unicast data traffic (bridged...)
Note — IGMP can also be enabled in L2 VPN (VPLS) whose unicast forwarder is an iBridge.
If IGMP is not enabled, then the forwarder is either transparent for or discards IGMP packets and multicast frames. Refer to Table 19-1.
Control plane The 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). Note — IGMP Proxy is defined in IETF RFC 4605.
Figure 19-4 IGMP control plane
R
IGMP Proxy
H upda te
join 240.0.10.1 join 240.0.10.2
Multica st Fwd
join 240.0.10.1 VLAN port
19-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
19 — Multicast and IGMP
By default, IGMP version 2 as well as IGMP version 3 are supported. The system can be configured to only accept IGMPv3 and drop incoming IGMPv2 messages. IGMPv1 messages will always be dropped. 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 the network ports and the subtending ports that are in that VLAN. When IGMP is encapsulated over PPP, it is handled transparently
19.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 channel identified as follows:
• cross-VLAN multicast: (multicast IP address, source IP address) (see section “Cross-VLAN multicasting”)
• fixed multicast VLAN per IGMP channel: (multicast IP address, source IP address, multicast VLAN) (see section “Fixed multicast VLAN per IGMP channel” 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. Provisioning multicast channels can be simplified by manipulating “ranges of channels”. A range of channels is characterized by a set of channels sharing the same characteristics (source IP address, multicast VLAN (optional), bandwidth parameters, …) and whose multicast IP address belongs to a given range. Such a “channel range” can be manipulated as one management object by the operator.
Static infeed The 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
19-5
19 — Multicast and IGMP
To take full advantage of statically-fed channels towards the ISAM, no specific configuration in ISAM is needed, since ISAM continuously dynamically learns from which port(s) a multicast channel is fed. These ports need not be the same as the port having the Querier. The root of the replication tree can be static, but ISAM does not take this into account. Statically fed channels towards subtending nodes or to individually selected PON UNIs are configured in the ISAM by configuring static multicast branches, as opposed to the dynamic multicast branches created through IGMP signaling. Note — Statically fed channels still support dynamic branches,
controlled through IGMP signaling.
Figure 19-5 Static infeed Subtending ISAM
ISAM
Aggregation network
No IGMP necessary
Edge Router No IGMP necessary
IGMP
static Branch
Root
dynamic
Cross-VLAN multicasting Multicasting 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 than iBridge, such as VLAN cross-connects. 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.
19-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
19 — Multicast and IGMP Figure 19-6 Cross-VLAN multicast - forwarding view 240.0.10.2
Multicast forwarding
VLAN (network-side) SAP
Unicast forwarding (iBridge)
VLAN port
VLAN (network-side) SAP
Unicast forwarding (VLAN-CC) VLAN port
VLAN (network-side) SAP
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 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. Otherwise, the join is transparently forwarded or is discarded, see Table 19-1. Figure 19-7 Cross-VLAN multicast - network view ISAM
Aggregation network
STB
Edge router Fwd
BTV VLAN 15
Fwd
VOD VLAN 16
BTV + VOD
Multicast channel list
Multicast IP address 240.0.10.1 240.0.10.2
VLAN 15 15
Source Specific Multicasting The multicast IP address range is unique. In a wholesale environment, different multicast service operators would need to make agreements to use non-overlapping subranges.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
19-7
19 — Multicast and IGMP
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 re-used in combination with a different VLAN. When receiving a join for an SSM-mode channel, the ISAM finds the associated VLAN in the list of preconfigured multicast channels. SSM channels must therefore be preconfigured as multicast channels. Next to preconfigured SSM channels, GPON access also supports unconfigured SSM channels with following restrictions:
• The system does not support that a subscriber joins simultaneously multiple multicast channels with the same group address but different source addresses • The source address is not controlled, leading to a potential security risk Note 1 — The method to use SSM in the control plane but not in the
data plane of L2 networks is specified in BBF TR-101. Note 2 — For GPON access IGMPv3-SSM is supported for selected
ONTs only. Figure 19-8 Source Specific Multicasting ISAM
Aggregation network
Video Head End
STB Fwd Fwd
(240.0.10.1,140.20.20.1)
Edge router
BTV VLAN 15
140.20.20.1
(240.0.10.1,144.30.30.1) VOD VLAN 36
144.30.30.1 Multicast channel list
Multicast Fws table
Multicast IP address 240.0.10.1 240.0.10.1
19-8
November 2013
VLAN 15 36
Multicast IP address 240.0.10.1 240.0.10.1
Source VLAN IP address 140.20.20.1 15 144.30.30.1 36
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
19 — Multicast and IGMP
Fixed multicast VLAN per IGMP channel Using a fixed multicast VLAN per IGMP channel offers an alternative to SSM-based IPTV wholesale with the following characteristics:
• ASM-based deployment (IGMPv2 or IGMPv3 ASM) with overlapping group address ranges across Video Service Providers: This approach simplifies multicast address management within the access network. Indeed, there is no need anymore for Video Service Providers to agree upon non-overlapping multicast address sub-ranges when using IGMPv2 or IGMPv3-ASM. • SSM-based deployment with overlapping source addresses across Video Service Providers: An example of such a configuration is a network where multiple Video Service Providers distribute IPTV services from the same Video Content Provider generating video traffic over IP, including its source IP address. Each Video Service Provider wants to keep control on its own offering, leading to overlapping IP source addresses in the network. In order to support overlapping “Group Address” or “Source Address” across Video Service Providers, the ISAM allows to assign a dedicated Video Service Provider (that is, Multicast VLAN) per subscriber (that is, IGMP channel) so that the (S,G) processing is instantiated per Video Service Provider, allowing full freedom. This feature changes the algorithm for determining the multicast VLAN, as it was explained in “Cross-VLAN multicasting”. With “fixed multicast VLAN per IGMP channel”, the multicast VLAN, both for preconfigured and non-configured multicast channels, is determined by the multicast VLAN configured per IGMP channel. From R4.3.01 on: This feature changes the algorithm for determining the multicast VLAN, as it was explained in “Cross-VLAN multicasting”. With “fixed multicast VLAN per IGMP channel”, the multicast VLAN for preconfigured multicast channels, is determined by the per-IGMP channel configured multicast VLAN. The VLAN for non-configured multicast channels remains the unicast VLAN as it is the case for the cross-VLAN multicast model. Figure 19-9 Fixed Multicast VLAN per IGMP channel Access/ Aggregation network
NNI
SP own (unique) Mcast groups
Mcast content provider (for example, Free-To-Air TV) Fwd BTV + VOD
Fwd
BTV S-VLAN 15
SP #2
BTV S-VLAN 16
Unicast (VOD, HSI, ...) Fwd S-VLAN (+ C-VLANs)
SP #1
SP own (unique) Mcast groups
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
Example: (S,G)=(140.20.20.1,240.0.10.1) stream will be requested by end-users over both BTV VLANs 15 and 16
November 2013
19-9
19 — Multicast and IGMP
The “fixed Multicast VLAN per IGMP channel” mode is defined at system level and cannot be used simultaneously with other modes where multiple Video Service Providers can be selected by the subscribers by means of either the “Group Address” (ASM) or the “Source Address” (SSM). Note — For GPON access, the “fixed Multicast VLAN per IGMP channel” is supported when ONT-to-OLT signaling is enabled or when the ONT supports the provisioning of “multicast ACLs” through ONT Management Control Interface (OMCI) (see section “System decomposition”).
Fast leave In 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. Note — The situation of multiple hosts on a user port can occur in
case of a bridged CPE and multiple STBs.
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.
19-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
19 — Multicast and IGMP Figure 19-10 Fast leave on subscriber ports Normal leave
Fast leave ISAM
ISAM
STB
STB
CPE
CPE
Bandwidth
Bandwidth
240.0.0.1
Leave 240.0.0.1
Leave 240.0.0.1
Query 240.0.0.1
240.0.0.1
Join 240.0.0.2 240.0.0.2
Join 240.0.0.2 240.0.0.2
>1s
240.0.0.1
Query 240.0.0.1 240.0.0.1
Time
Time
Resource admission control on the subscriber port Video 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) line This 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”. Note 1 — For GPON access, RAC on the subscriber port is supported
when ONT-to-OLT signaling is enabled or when the ONT supports the provisioning of “multicast ACLs” through OMCI; see section “System decomposition”. Note 2 — For EPON access, RAC is supported on PON level, but not supported on UNI level.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
19-11
19 — Multicast and IGMP
Resource admission control on the uplink An ISAM with an FD 100/320Gbps NT or an FX NT has no configuration for resource admission control on the uplink. It is assumed that resource admission control, and in particular bandwidth control, is done by the edge router, for example, by using IGMP forking.
Access control Access 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. Note — For GPON access, access control is supported when ONT-to-OLT signaling is enabled or when the ONT supports the provisioning of “multicast ACLs” through OMCI.; see section “System decomposition”.
Call Detailed Records The 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 ports The 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) respectively SDP binding 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-side SAP as multicast router (MR), all the join messages and the leave messages are sent to both routers.
19-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
19 — Multicast and IGMP Figure 19-11 Example of static router port ISAM STB
non-Querier
Join 240.0.0.1
0.1
Join 240.0.
Join 240.0.0.
1
Query
Querier MR SAP
IGMP forking An 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. Figure 19-12 Example of IGMP forking
ISAM Proxy
STB
Aggregation network ( Proxied Join )
Edge Router
Join
Fwd
BTV VLAN 15 Forked Join
BTV+HSI+Voice
Fwd
HSI+Voice VLAN 16
Warning — IGMP forking generates many IGMP packets.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
19-13
19 — Multicast and IGMP
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)
PIM-SSM The ISAM implements the PIM Source Specific Multicast (PIM-SSM) variant of PIM-SM (PIM Sparse Mode) because it is better suited for the one-to-many topology typically used for IPTV deployments. ISAM supports PIM-SSM on network interfaces according to RFC 4601 with the following remarks:
• Due to the location of the ISAM in the network, the PIM-SSM roles supported by the ISAM are limited to “Designated Router” (DR) and “Last Hop Router” (LHR). • PIM-SSM is only supported for the base router (that is, not supported for VPRNs) • ECMP based load sharing is supported • Ring configurations are supported by configuring the ISAM as “Intermediate Router”, using a different VLAN on each leg of the ring (PIM snooping not supported) As LHR, the ISAM is responsible for converting IGMP messages received from the subscribers into PIM-SSM ones. In order to support subscribers generating “Any Source Multicast” (ASM) messages (that is, IGMPv2 or IGMPv3-SSM), the ISAM provides an “SSM translation function” that will convert ASM messages into SSM ones by adding an IP source address selected in function of the “Group Address”, provided the “Group Address” belongs to the ASM range as indicated in Figure 19-13. Figure 19-13 SSM Translate Overview SSM txl
SSM
November 2013
ASM
Group IP Address
19-14
Provider S1
Provider A1
IPSA1
Provider A2
IPSA2
Provider A3
IPSA3
Provider S2
Provider S3
N.A.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
19 — Multicast and IGMP
19.3
System decomposition Multicast services impact both the LT boards and the NT board. The LT board implements a multicast forwarder and IGMP proxy. The LT forwards multicast streams from internal LT-NT ports to user ports. 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. For GPON-based access, the OLT performs the same functions as a DSL LT, but in this case the multicast forwarder replicates multicast packets to the various OLT ports, that is the various PON interfaces. The PON technology itself, due to its point-to-multipoint nature, ensures that all ONTs coupled to the PON receive all multicast streams that were forwarded onto the PON. The ONT also acts as a multicast forwarder, which replicates multicast streams to the correct ONT ports (UNIs). There are two basic models for configuring the ONT multicast forwarding table: 1
The ONT is transparent for IGMP messages. IGMP messages are handled on the OLT in the IGMP proxy, and once an IGMP JOIN is accepted, possibly after performing a RAC check on the subscriber port or an Access Control check, the ONT is instructed to create multicast branches to the right UNIs via an Alcatel-Lucent-proprietary ONT-to-OLT signaling
2
For R4.3: The ONT performs IGMP snooping in order to learn what multicast branches it needs to create towards the UNIs. In this model no RAC checks are done on the subscriber port on the ONT, nor Access Control checks. Then the IGMP messages are sent to the OLT where they are processed in the IGMP proxy.
3
From R4.3.01 on: The ONT performs IGMP snooping in order to learn what multicast branches it needs to create towards the UNIs. Depending on the ONT Management Control Interface (OMCI) capabilities supported by the ONT, two sub-modes can be considered:
• RAC/Access rights management by OMCI not supported:
•
In this mode, no RAC checks on the subscriber port are done on the ONT, neither Access Control checks. Next the IGMP messages are further sent to the OLT where they are processed in the IGMP proxy. RAC/Access right management by OMCI supported: In this mode, the OLT delegates some part of the RAC and access rights control to the ONT by provisioning through OMCI a set of rules (“multicast ACLs”) specifying: The list of allowed channels The bandwidth associated to the channel The default behaviour for unconfigured channels Once those rules are provisioned on the ONT, the ONT snooper can directly apply those rules to check if an IGMP join can be granted or not. If granted, the IGMP join is passed to the OLT for further processing (and it might happen that RAC / access right controls at OLT level leads to decide not to grant the join). This approach is a fully standard and therefore interoperable approach for managing multicast services on ONTs. Note that the “channel preview” cannot be provisioned through OMCI standards and consequently, the feature cannot be used together with that ONT management model.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
19-15
19 — Multicast and IGMP
OMCI-based access rights and CAC control Figure 19-14 shows the multicast provisioning modes at the ONT. Figure 19-14 Modes of multicast provisioning at the ONT Multicast provisioning by means of the proprietary OLT-ONT signalling channel 2
1
Join
Join
Proxy
3 Proprietary Join
Multicast provisioning through OMCI 1 OMCI
Proxy
Snooper 2
3 Join
Join
Proxy
Snooper
Multicast provisioning by means of the proprietary OLT-ONT signalling channel: 1
No snooper at the ONT: the Join is passed transparently to the OLT
2
The OLT performs CAC. If Ok, a multicast branch is created towards the PON and the Join is propagated to the network (if needed)
3
Proprietary Join sent by the OLT to the ONT to provision the required multicast branch
Multicast provisioning through OMCI:
19-16
1
The OLT provisions the ACL through the OMCI (at ONT start-up or reconfiguration)
2
The snooper at the ONT performs UNI CAC. If Ok, a multicast branch is configured at ONT level and the Join is propagated to the OLT (if needed)
3
Proxy at the OLT performs additional CAC. If Ok, a multicast branch is created towards the PON and the Join is propagated to the network (if needed)
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
19 — Multicast and IGMP
System decomposition The IHub implements a multicast forwarder and an IGMP proxy snooper. The IHub IGMP proxy snooper operates completely in the scope of a VLAN and VPLS, that is, there is no cross-VLAN support in the IHub. To make that the IHub does IGMP proxy, as opposed to snooping, Service Access Points (SAPs) on LT-side ports must be configured as SQ SAPs (Send Query SAP). To support redundant Queriers in the network, for example, in a ring structure, Service Access Points (SAPs) respectively Service Distribution Point bindings to VPLS (SDP bindings) on network ports must be configured as Multicast Router (MR) port, so that Reports and Leaves are forwarded to both upstream Queriers (or multicast edge routers) in order to keep them in synchronization. General Queries are also forwarded to all ports so that ISAM participates in the Querier Election process transparently. MR SAPs behave as IGMP hosts towards the network. They can be configured statically, or can be learned by receiving a General Query from the network. SQ SAPs behave as IGMP router towards the LT boards. Figure 19-15, Figure 19-16 and Figure 19-17 show the system decomposition for multicast and how the management concepts map on the system components. Figure 19-15 System decomposition for multicast LT IGMP Proxy
STB Unicast VLAN
mcast fwd
Multicast VLAN
IHub IGMP Snooper mcast fwd
LT IGMP Proxy
Aggregation network
mcast fwd
Multicast VLANs Multicast channels IGMP channels Multicast packages
Multicast VLANs Multicast channels Multicast bundles Router ports Multicast trees
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
19-17
19 — Multicast and IGMP Figure 19-16 System decomposition for multicast (GPON with ONT-to-OLT signaling) ONT-to-OLT signalling
STB Unicast VLAN
ONT LT
mcast fwd
IGMP Proxy
ONT
mcast fwd
Multicast VLAN
IHub IGMP Snooper
Aggregation network
mcast fwd
LT IGMP Proxy mcast fwd
Multicast VLANs Multicast channels Multicast bundles Router ports Multicast trees
Multicast VLANs Multicast channels IGMP channels Multicast packages
Figure 19-17 System decomposition for multicast (GPON with IGMP snooping on the ONT) STB
ONT Unicast VLAN
IGMP snooping
LT
mcast fwd
IGMP Proxy
ONT
mcast fwd
Multicast VLAN
IHub IGMP Snooper
Aggregation network
mcast fwd
LT IGMP Proxy mcast fwd
Multicast VLANs Multicast channels Multicast bundles Router ports Multicast trees
Multicast VLANs Multicast channels IGMP channels Multicast packages
Figure 19-18 System decomposition for multicast (EPON with IGMP snooping on the ONT) STB
ONT Unicast VLAN
IGMP snooping
LT
mcast fwd
IGMP Proxy
ONT
mcast fwd
Multicast VLAN LT
IHub IGMP Snooper mcast fwd
IGMP Proxy
Aggregation network
mcast fwd
Multicast VLANs Multicast channels IGMP channels Multicast packages
19-18
November 2013
Multicast VLANs Multicast channels Multicast bundles Router ports Multicast trees
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
19 — Multicast and IGMP
The behavior of EPON with IGMP snooping on the ONT is similar as for GPON: the ONT acts as IGMP snooper in order to learn what multicast branches it needs to create towards the UNIs. Figure 19-19 System decomposition for multicast (EPON with IGMP controllable mode on the ONT) STB
ONT Unicast VLAN
IGMP controllable
mcast fwd
EPON OAM channel
LT IGMP Proxy
ONT
mcast fwd
Multicast VLAN
IHub IGMP Snooper mcast fwd
LT IGMP Proxy
Aggregation network
mcast fwd
Multicast VLANs Multicast channels Multicast bundles Router ports Multicast trees
Multicast VLANs Multicast channels IGMP channels Multicast packages
Note 1 — When the ONT works in “IGMP-controllable” mode which is defined by China Telecom EPON technical spec V2.1, the ONT maintains a multicast forwarding table according to the OLT via China Telecom extended OAM messages. Note 2 — The ONT IGMP mode (IGMP snooping and IGMP
controllable) is configured by the OLT via China Telecom extended OAM message.
19.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 19-1 provides a summary of the handling of IGMP packets and multicast frames in forwarders. Table 19-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
IGMP proxy and mcast replication
IGMP proxy and mcast replication
(1 of 2)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
19-19
19 — Multicast and IGMP
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
iBridge (PPPoE)
IGMP and mcast transparent
Not supported
Not supported
PPP cross-connect
IGMP and mcast transparent
Not supported
Not supported
(2 of 2)
19-20
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
20.1 Introduction
20-2
20.2 Upstream QoS handling 20.3 Downstream QoS
20-2
20-13
20.4 Hardware mapping of QoS functions 20.5 Configuration of QoS
20-15
20-31
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-1
20 — Quality of Service
20.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. Network performance objectives for the different service types are documented in the ITU-T Recommendation Y.1541 (Network performance objectives for IP-based services). 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.
20.2
Upstream QoS handling This section deals with subscriber- or ISAM-originated traffic that is transmitted on the network link.
Overview Figure 20-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. Some LT board types support an eight-queue model, as explained in the following notes. If an LT board type is not explicitly mentioned in the following, then it only supports the standard QoS model. The GE Ethernet LT board always supports 8 queues.
20-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
WRR WFQ
Video
WRR WFQ
CL
Mapping to queues
Scheduling
BE
TC7
111
TC6
110
TC5
101
TC4
100
TC3
011
TC2
010
TC1
001
TC0
000
Classification
GE/FE
.1p
p-bit marking
Voice
Traffic Classes
Mapping to Traffic Classes
ISAM queues
Mapping of DSCP to P-bits
Figure 20-1 Qos Overview - Standard Model
Figure 20-2 illustrates a flexible QoS model which allows:
• a flexible mapping of p-bits to traffic class, configurable per forwarder • a flexible number of queues (either four or eight) • a flexible scheduling of the queues, where each queue has a configurable priority and weight The flexible model can be configured for GPON subscribers. Both the standard model and the flexible model are described in more detail in the following sub-sections. The flexible model is also used for the EPON board, where the model is further extended to configure the mapping of p-bits to traffic class at the VLAN port level. Figure 20-2 QoS Overview - Flexible Model
GigE/FE
SP+WFQ Scheduler
.1p
ISAM queues
Traffic classes
Queue7
TC 7
Queue6
TC 6
Queue5
TC 5
Queue4
TC 4
Queue3
TC 3
001
Queue2
TC 2
000
Queue1
TC 1
Queue0
TC 0
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
110 101
001 000
VoIP VLAN 1
HSI #1 VLAN 2 HSI #2 VLAN 3
20-3
20 — Quality of Service
Classification The 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 20-3 QoS: classification 1. Voice 2. Video (VoD, BTV) 3. Controlled load (home working) 4. Best effort (HSI)
classification
For the Standard Model of Figure 20-1, four main traffic classes have been identified: Voice, Video, Controlled Load (CL) and Best Effort (BE). These traffic classes are listed in Table 20-1, together with their application and recommended 802.1p value. For LT boards that only support 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 8 queues, each traffic class is mapped to its own queue. This approach segregates network control, voice and video-telephony into the highest priority queue, broadcast video and video-on-demand into the second queue, business customer data traffic into a third queue, and residential customer data traffic into the fourth. Table 20-1 Classes, application, and recommended 802.1p value Traffic class
Application
Recommended 802.1p value
Voice
• • • • •
Voice Video telephony + network control)
110
Broadcast video Video-on-demand
100
Video
(111)
Controlled load
HSI for business access
011
Best effort
HSI for residential access
000
Classification is based on layer 2/layer 3/layer 4 parameters 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.
20-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
When the outcome of classification is “discard”, we are 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.
Marking Marking is defining the value of:
• layer 2: p-bits - part of the VLAN-tag • layer 3: DSCP - part of the IP packet header Figure 20-4 QoS: marking .1p
111 110
101 100
011 010 001
000
p-bit marking
classification
In upstream direction, there are four possibilities:
• Trusted Subscriber Interface: • No re-marking 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/re-marking. 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 the above policies it is also possible to align the p-bits, i.e. p-bits are derived from the DSCP codepoint, or IPv6 Traffic Class field. The upstream mapping of DSCP codepoint to p-bit value can be achieved in two ways:
• Using a system-wide p-bit alignment table, or • Associating a p-bit alignment profile with a subscriber
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-5
20 — Quality of Service
The second option is only available for GPON subscribers, but has the advantage that different mappings can be used for different groups of subscribers. This is useful, for example, if the ISAM is used in a wholesale environment where different mappings are needed for different service providers. For stacked VLANs, there are some additional points to note related to p-bit marking
• In case of S+C VLAN cross-connect or S+C VLAN RB, both S- and C-VLAN p-bits are set to the same value.
• In case of S-VLAN CC tunnel or S-VLAN RB tunnel, the C-VLAN p-bit is never modified. The S-VLAN p-bit is set according to the preceding explanation. The default behavior for tagged frames is to copy the C-VLAN p-bit, if no other marking is specified. Some limitations apply to tunnel VLANs for GPON subscribers:
• For S-VLAN tunnel, the S-VLAN p-bit is set to the VLAN port default p-bit when it is enabled (that is, VLAN port marking policy = 'regenerated p-bit'). When the VLAN port default p-bit is not enabled, then the p-bit is copied from the C-VLAN p-bit (tagged frames) or is set to the bridge port default p-bit (untagged frames). Note that other methods of marking the S-VLAN p-bit are not supported for GPON S-VLAN (for example, deriving the p-bit from the DSCP codepoint). • For S-VLAN RB tunnel, the p-bit contract enforcement/re-marking is not supported on most ONT types. The p-bit marking of protocol frames is handled in a different way to data plane traffic. The handling differs according to the protocol. Handling of protocol frames for non-GPON subscribers:
• IGMP frames sent by the ISAM are always marked with highest priority, that is, p-bits=7.
• DHCP frames: • When traffic is received with p-bits marked at user side, the marking is left •
unchanged. When unmarked traffic is received, the default p-bit marking for the given VLAN is applied.
• PPP control frames (for example, PADI/PADO) are marked with fixed p-bits=7. The CDE option exists to configure in the same way as done for DHCP:
• When traffic is received with p-bits marked at user side, the marking is left unchanged.
• When unmarked traffic is received, the default p-bit marking for the given VLAN is applied.
• ARP frames are tagged always with highest priority (p-bit=7) Handling of protocol frames for GPON subscribers:
20-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
The VLAN port, on which a protocol frame is forwarded, may not have p-bit 7 configured. Some additional accommodation must be made to ensure that the protocol frames are correctly forwarded.
• For IGMP frames generated by the LT board, the p-bit used is the highest p-bit configured for the VLAN. This is true for both upstream and downstream packets. • For ARP and DHCP, the p-bit marking follows the same rules as used for the data plane traffic. • PPP control frames are marked with fixed p-bit=7. There is also a CDE option to configure in the same way as done for DHCP. The p-bit marking follows the same rules as used for the data plane traffic.
Policing Subscribers 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 and GPON LT board) The characteristics of these two types are explained in “Policer profile”. Figure 20-5 QoS: policing .1p
P 111 P
110
101 P
100
011 010
P
001
000
p-bit marking
classification
Figure 20-6 illustrates the policing feature implementation for a single token bucket policer.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-7
20 — Quality of Service Figure 20-6 Policing implementation framework QoS Session Profile
QoS Policer Profile UP
QoS Policer Profile DOWN
QoS Policer Profile DOWN
QoS Policy List DOWN
L2 filter L3 filter Policy-action= Policer-Profile
CIR CBS Per-SAP policing
Subflow policing
L2 filters
L3+ filters
DST MAC address + prefix length SRC MAC address + prefix length Ethertype P-Bit User-side VLAN ID CFI
DST IP address + prefix length SRC IP address + prefix length Min/max DST port ID Min/max SRC port ID Protocol DSCP value
Mapping and queueing Mapping 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 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 delay precedences. Figure 20-7 shows the different QoS queues for the standard QoS model, employing four traffic classes and four queues. The configurable mapping of p-bits to traffic class is system-wide. The mapping of traffic class to queue is non-configurable on the LT boards and on the FD 100Gbps NT, but is configurable on the FD 320Gbps NT and the FX NT.
20-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
CL
111
TC6
110
TC5
101
TC4
100
TC3
011
TC2
010
TC1
001
TC0
000
Mapping to queues
BE
TC7
Classification
Video
.1p
p-bit marking
Voice
Traffic Classes
Mapping to Traffic Classes
ISAM queues
Mapping of DSCP to P-bits
Figure 20-7 QoS queues for standard model
The eight traffic classes are mapped either to four queues or to eight queues. The selection of which mapping to use is hardware dependent, depending on how many hardware queues are supported by a specific LT board type. Again this mapping is non-configurable on the LT boards and on the FD 100Gbps NT, but is configurable on the FD 320Gbps NT and the FX NT. The non-configurable mappings (used on the LT boards and the FD 100Gbps NT) are as shown in Table 20-2. Details of the default mappings used on the FD 320Gbps NT and the FX NT can be found in Table 20-6 and Table 20-7. Table 20-2 Mapping of Traffic Classes into Queues Traffic Class
4-Queue Mapping
8-Queue Mapping
7
3
7
6
3
6
5
2
5
4
2
4
3
1
3
2
1
2
1
0
1
0
0
0
For UNI ports on a GE Ethernet LT board, it is advised to align the p-bit to traffic class mapping per forwarder, for use in the downstream direction, to the system-wide mapping. This alignment must be done explicitly because the mapping per forwarder is not explicitly defaulted to the system-wide mapping when not programmed. This explicit alignment is not needed when the system-wide mapping is kept identical to the default configuration. Refer to “QoS on a GE Ethernet LT board” for further details. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-9
20 — Quality of Service
The GPON LT board also uses a configurable per forwarder p-bit to traffic class mapping. However, for the GPON LT board, the per forwarder mapping is required, since the system-wide mapping is not used. The EPON LT board uses a configurable per VLAN port p-bit to traffic class mapping. However, per VLAN port mapping is required for the EPON LT board because the system-wide mapping and forwarder mapping are not used. It is also optionally possible to define a mapping of p-bits to color marking. There are two types of color marking available:
• Policer color marking (green, yellow, or red)): based on received p-bit value, applicable to the GE Ethernet LT board
• Per forwarder color marking (green, yellow, red): based on re-marked p-bit value, applicable to the GPON LT board. An option exists to mark the color based on the DEI bit in the packet, rather than the p-bits • Drop Precedence (DP) color marking (either green or yellow), based on re-marked p-bit value, applicable to other LT board types The 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 — (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. Both the GE Ethernet LT board and the GPON LT board support color-aware policing. Note — The GPON LT board has an MDU option to police at the MDU rather than at the LT board, in which case only single token bucket policing is supported.
20-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
Scheduling and shaping Standard Scheduling Model
WRR WFQ
Video CL
WRR WFQ
Mapping to queues
Scheduling
BE
TC7
111
TC6
110
TC5
101
TC4
100
TC3
011
TC2
010
TC1
001
TC0
000
Classification
GE/FE
.1p
p-bit marking
Voice
Traffic Classes
Mapping to Traffic Classes
ISAM queues
Mapping of DSCP to P-bits
Figure 20-8 QoS: scheduling
The standard scheduling model is presented in Figure 20-9. Figure 20-9 Reference scheduling hierarchy for standard model
Voice SP
Video CL WFQ BE
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-11
20 — Quality of Service
Flexible Scheduling Model
In the flexible scheduling model, each queue can be provisioned with a priority and a weight. The scheduler uses these settings as follows: 1
Queues with a higher priority are scheduled ahead of queues with a lower priority.
2
Queues with the same priority are scheduled according to their relative weights.
The flexible scheduling model is applicable to GPON and in future will be applied to other LT boards using eight queues. The FD 320Gbps NT and the FX NT also support the flexible scheduling model; see “Egress scheduler and rate limiter” for details. PON Scheduling and Shaping
Since the GPON interface is shared by up to 128 ONTs, the GPON LT board manages the transmission upstream over the PON, including both scheduling and shaping functions. The reader is referred to section “QoS on the GPON LT boards and the ONTs”, which describes the QoS of the GPON LT board and ONT in more detail. As the EPON interface is shared by up to 64 ONTs, the EPON LT board manages the transmission upstream over the PON. This includes both scheduling and shaping function. Section “QoS on an EPON LT board and an EPON ONT” describes the QoS of EPON LT board and ONT in more detail. Shaping on network ports
ISAM supports port-level shaping of traffic on the network ports.
Connection Admission Control For GPON LT, PON level CAC is supported. Upstream, each T-CONT can be created with a guaranteed bandwidth (either CIR or AIR). ISAM executes a CAC to ensure that the total guaranteed bandwidth is not exceeding the physical bandwidth of the PON. For the EPON LT, PON level CAC is supported, each LLID can be created with a guaranteed bandwidth (AIR). ISAM executes a CAC to ensure that the total guaranteed bandwidth is not exceeding the physical bandwidth of the PON.
20-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
MPLS VPLS/EPIPE L2 VPN services allow to pass Ethernet frames from a user in a transparent manner over an MPLS network using pseudo-wires (PWs). The LSRs in the MPLS network use the EXP bits of the outer label to define the QoS handling. Therefore the ISAM offers the possibility to configure the setting of these EXP bits. Two models are supported:
• Fixed EXP value per service provider • EXP value derived from the forwarding class Note — The EXP bits of the outer label (transport) and the inner label
(service) are set identical. In case the MPLS packets are sent tagged, the p-bit of the added DLC header will be set equal to the EXP value.
Figure 20-10 PW data packet DLH + p-bit
20.3
OuterLabel + EXP
Inner Label + EXP
DMAC
SMAC
[VLAN]
[p-bit]
Payload
Downstream QoS This section deals with traffic received from the network link and transmitted on the subscriber link or locally terminated on the ISAM. Downstream traffic is subject to similar QoS actions as upstream traffic. This section will focus on the differences between downstream and upstream QoS handling.
Classification Same capabilities as for upstream QoS handling (see “Classification”) with the following addition for MPLS PW packets: For packets entering a VPLS/EPIPE via a PW the classification can be based on the EXP value of the inner service label or the p-bit of the encapsulated Ethernet frame.
Marking In 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. For GPON subscribers, if a priority contract profile is used to map the p-bits in the upstream direction, then the inverse mapping is applied in the downstream direction. For example, if p-bit 1 is mapped to p-bit 2 upstream, then p-bit 2 is mapped to p-bit 1 downstream. For GPON subscribers, there is also a CDE option that, when enabled, will result in downstream p-bit being unchanged, so that the inverse mapping will not be applied.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-13
20 — Quality of Service
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”) with the following addition for MPLS PW packets: When a PW is defined of type ether, then a VLAN and p-bits need to be added. These p-bits are then derived from the forwarding class defined by the classification logic.
Policing No traffic engineering will be done at ingress on the network interfaces. The idea here is that ingress policing and ACLs at the service provider level have already been applied in a (access provider-owned) box deeper in the network. 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 queuing In the downstream direction, separate QoS queues are provided per DSL line or per GPON UNI. 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 three types of color marking available:
• Policer color marking (green, yellow, or red), based on received p-bit value, applicable to the GE Ethernet LT board.
• Per forwarder color marking (green, yellow, red), based on re-marked p-bit value, applicable to the GPON LT board. There is also an option to mark the color based on the DEI bit in the packet, rather than the p-bits. • Drop Precedence (DP) color marking (either green or yellow), based on re-marked p-bit value, applicable to other LT board types. The use of the color marking is similar to the upstream case. For GPON LT, downstream queues can also be configured per ONT, instead of per UNI. For EPON LT, downstream queues are configured per LLID (logical link). 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 Shaping In the downstream direction, for the DSL lines, there are the same scheduling capabilities as in upstream for the Standard Model (see “Scheduling and shaping”). 20-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
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, HC-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, HC-UNI and NNI ports) Additionally, the GPON LT board provides hierarchical scheduling and shaping. The reader is referred to section “QoS on the GPON LT boards and the ONTs”, which describes the QoS of the GPON LT board and ONT in more detail. EPON LT boards also provide hierarchical scheduling and shaping. The reader is referred to Section “QoS on an EPON LT board and an EPON ONT”which describes the QoS of the EPON LT board and ONT in more detail.
Connection Admission Control The 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(*). For GPON LT, PON level CAC is also supported. Downstream, a maximum multicast bandwidth is configurable on the PON. ISAM executes a CAC when a multicast stream is joined to ensure that the maximum bandwidth is not exceeded. For GPON LT there is also a CAC check for downstream Committed Information Rate on queues. This CAC is enabled when auto-scheduling is enabled. (See “QoS on the GPON LT boards and the ONTs” for a description of auto-scheduling.) The CAC involves checking that the sum of CIRs of all queues on the PON is less than or equal to (total bandwidth on the PON minus maximum multicast bandwidth). For EPON LT boards, PON level CAC is also supported. In downstream, a maximum multicast bandwidth is configurable on the PON. ISAM executes a CAC when a multicast stream is joined to ensure that the maximum bandwidth is not exceeded. ISAM also supports CAC for multicast on the uplink. Note —
20.4
(*)
Video on Demand (VoD) traffic is not taken into account.
Hardware mapping of QoS functions
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-15
20 — Quality of Service
QoS on the NT boards The 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 QoS flow of a packet in IHub is shown in Figure 20-11. Figure 20-11 QoS flow in IHub Fixed egress port queue policy
Ingress QoS policy
Service lookup at packet reception
Map packet to flow class
Apply per service egress rate limit
Switch to egress port
Map flow class to queue
Buffer acceptance & scheduling
Port egress rate limiter
The following QoS features are supported in the IHub switch hardware:
• Mapping packets to a flow class based on DSCP, PREC, p-bits or LSP EXP • • • • •
(MPLS) Per service egress or ingress rate limitation Mapping of flow classes to egress queues Mapping of flow classes to LSP EXP value (MPLS) Buffer acceptance and scheduling at egress port side Per-port egress rate limitation Note — The IHub does not generate pause frames, neither downstream nor upstream, but the switch correctly handles pause frames coming from the network.
The IHub does not support the following QoS features:
• DSCP-to-p-bit alignment • Uplink CAC On top of the above, the operator will be able to create:
• profiles to specify the QoS parameters of control packets which are self-generated by the IHUB. The NE manager will be able to specify per service a QoS profile for self-generated control traffic. • profiles to specify the QoS parameters of packets ingressing the base router via network facing ports.
QoS on the LT boards QoS on layer 3/layer2+ LT boards
Figure 20-12 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. 20-16
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service Figure 20-12 Logical architecture for QoS on layer 3 LT boards downstream GE aggregate
Input processing
Per-DSL line Policing, Classification, Queuing, Scheduling
Logical segregation per DSL line
ATM or EFM segmentation DSL PVC forwarding decision
upstream Segregation into GE output buffers aggregate (802.1P aggregates)
Per-DSL Per-DSLline li Policing
Input processing processing
ATM or EFM reassembly
DSL
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 20-13. 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. Figure 20-13 Per DSL-port scheduler
Policing entity Rule per SAP: • PVC • PPP • VLAN ID • 802.1X • IP interface
BACC
voice
Traffic class switch
BAC
video
BAC
CL
Based on: • 802.1P
BAC
BE
SP SP
DSL
WFQ WFQ Modes: • Taildrop • RED
Traffic class mapping on the LT boards is governed by a system wide p-bit-to-queue mapping table. Note — The traffic class mapping on the NT boards is governed by another system wide table.
BAC is either Tail Drop or RED per downstream queue (optionally DP-aware).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-17
20 — Quality of Service
A WFQ scheduler ensures fair redistribution of the remaining bandwidth between CL and BE traffic. Some boards also support shaping per downstream queue. Figure 20-14 shows the Ethernet-to-ATM QoS transition. Figure 20-14 Ethernet-to-ATM QoS transition Frame Domain
Cell Domain Segmentation buffers
VOICE VIDEO
SP SP
1 frame
VC1 Add correct VPI/VCI fields
VC2 VC3
CL
WFQ WFQ
Rate limitation to DSL bandwidth
DSL
BE Ethernet (frame level) scheduler
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 re-marking table which maps all user-defined P-values to allowed values. Untagged frames can be marked based on subscriber SAP defaults (statically configured). The ISAM allows also DSCP-marking for various subscriber SAPs. DSCP-to-DSCP re-marking is also possible, just like p-bit re-marking for tagged and priority-tagged frames. Finally, a global DSCP-to-p-bit alignment table is provided to align DSCP-marked traffic on selected interfaces to p-bits, as traffic segregation still relies on p-bits. PPP-session marking for p-bits is possible based on the QoS session profile attributes. 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 four priority levels downstream. Upstream there is no bottleneck, hence no queuing other than AAL5 reassembly is required.
20-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
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). Note — Only fixed p-bit value marking is supported; no DSCP marking, nor dot1p-alignment.
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. QoS on the GPON LT boards and the ONTs
This section describes the QoS aspects of both the GPON LT boards and the ONTs, noting which functions are performed by the LT board and which are performed by the ONT. Capabilities specific to the GPON implementation are highlighted, as well as any deviations from the DSL capabilities. In the discussion of the GPON QoS, it is important to understand the high-level implementation of the GPON QoS management model. In accordance with TR-156 and the ITU-T G.984 series, the NGLT and ONT should be considered as one “virtual” entity from a management point of view. See Figure 20-15.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-19
20 — Quality of Service Figure 20-15 GPON LT and ONT combined into a single management entity
Network
NE
xDSL LT
xDSL
NT
Eth LT
Eth
GPON LT
ONT ONU
DSL ETH CES POTS
Classification and marking Upstream classification and marking for GPON subscribers is performed by the ONT, with the exception of some types of stacked VLANs, where the OLT is involved for the p-bit marking of the outer VLAN. Marking is only applied to p-bits (not DSCP). A number of options are available.
• Packets can be marked based on subscriber SAP defaults, or protocol default (IPoE or PPPoE).
• If a packet is already tagged, the p-bits can be re-marked using one of 32 priority contract profiles that map the received p-bit to a new value. See “Priority contract profile” for details. • Untagged IPoE packets can be marked at the ONT using the global DSCP to p-bit alignment table, when the DSCP is trusted. This is supported for IPv4 packets and, for the majority of ONT types, also IPv6 packets. As mentioned in “Marking”, the DSCP to p-bit alignment can be derived either from a system level table or by associating one of a number of profiles to the UNI on the ONT. • Packets can also be marked at the OLT. The GPON LT can be configured to perform upstream DSCP to p-bit alignment for untagged and tagged IPv4 and IPv6 traffic. Both encapsulation in PPPoE and in plain Ethernet are supported. The DSCP to p-bit alignment on the GPON LT must be based on the system level DSCP to p-bit alignment table. Marking as a policy action is not supported (that is, p-bits cannot be set as a filter action). Policing
20-20
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
As for DSL subscribers, policing is possible for GPON subscribers, both in the upstream and downstream directions. Downstream policing is always performed by the LT board; upstream policing can also be performed by the LT board, except VLAN port policing for MDU subscribers, which is performed by the MDU itself. Note that a GPON policer can be attached to a VLAN port or to a bridge port. As for DSL subscribers, a GPON policer can also be attached to a filter. Upstream scheduling and shaping Inherent to the GPON network architecture, upstream transmission introduces an additional challenge as multiple ONTs share a common medium: transmissions could collide if they were transmitted at random times. For this, a TDMA-based Dynamic Bandwidth Allocation (DBA) mechanism has been implemented at the GPON LT board control plane as part of the of the Transmission Convergence (TC) layer. This layer thus manages the upstream bandwidth efficiency, and provides support for differentiated services. Therefore, the actual mapping of the traffic into queues and possible scheduling of the queues within a certain traffic subflow should be understood with reference to the underlying TC layer parameters. Two key entities used in the TC layer are the Traffic Container (T-CONT) and the port ID of the GPON Encapsulation Method, or GEM port id, as it is known. The T-CONT can be thought of as a bandwidth pipe. At the egress of the UNI interfaces towards the PON link, rate shaping is activated on the T-CONT level and triggered by the DBA mechanism. The DBA will issue grants to ensure that the rate allocated to a T-CONT will not exceed its provisioned traffic contract (reflected by CIR, AIR and EIR). For example, for a fixed bandwidth T-CONT (Type 1), the rate is limited to the CIR; for a best effort bandwidth T-CONT (Type 4), the rate is limited to the EIR. The Alcatel-Lucent GPON solution supports all T-CONT types, from 1 to 5. Figure 20-16 T-CONT bandwidth parameters and DBA mechanism EIR Best-Effort Bandwidth
Additional Bandwidth AIR Guaranteed Bandwidth
CIR
DBA
Non-Assured Bandwidth Assured Bandwidth Fixed Bandwidth
Statically reserved
Data sent over the PON is encapsulated in the GEM header. The GEM header includes the GEM port id which uniquely identifies a traffic flow or group of traffic flows for a specific UNI. In the ONT, a GEM port is associated with a specific traffic queue towards the PON. By default, GEM ports are allocated for each VLAN port, with a separate GEM port allocated for each traffic class used (defined by the p-bit to traffic class mapping, see “Ingress QoS profile (p-bit to traffic class mapping)”). There is also an option, configurable at the UNI level, to share the same GEM ports for all VLAN ports on the UNI. When this option is used, the p-bit to traffic class mapping used for the VLAN ports must be ‘non-conflicting’. For example, it is not possible to have p-bit 1 map to TC1 for one VLAN port and have p-bit 1 map to TC2 for a second VLAN port. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-21
20 — Quality of Service
The main features of the upstream scheduling and shaping are as follows.
• Each UNI on a PON is allocated either four or eight queues. (The number is
•
•
•
• • •
•
configurable per ONT.) These queues are located on the ONT. Each queue is configured with priority and weight parameters. A T-CONT is also associated with each queue. There is also an option to share the queues between all UNIs on an ONT. An option exists to configure the upstream ONT queues on the VLAN port level, rather than on a UNI or ONT level. In this case, T-CONTs are also allocated at the VLAN port level. This has he benefit that bandwidth parameters can be configured individually for each VLAN port. The characteristics of the T-CONT are configured in a bandwidth profile and include rate parameters CIR, AIR, EIR. Grants are issued by the GPON LT to the ONTs on the PON, to ensure for each T-CONT, the committed rate and (on average) the assured rate. Also, for each T-CONT, the traffic is shaped to the maximum of CIR, AIR and EIR. Queues are scheduled using strict priority or WFQ algorithms, within the T-CONT, according to the configured priorities and weights. It is also possible to configure a mixture of strict priority and WFQ. The WFQ queues should all be configured with the same priority. Note that more than one WRR group in a mixed SP+WRR scheduling mode is not supported. When more than one WRR group is config-ured in a mixed SP+WRR mode, the OLT will use the configured weights to support a pure WRR mode. In other words, the configured priorities will be ignored by the OLT and only the weights will be used. The 'bandwidth profile sharing' attribute allows a T-CONT to be shared by multiple queues within a UNI and also across multiple UNIs within the same ONT. However, a T-CONT cannot be shared between ONTs. When queues are configured at the VLAN port level, bandwidth profile sharing can be set to 'vlan-port-sharing' which will result in a single T-CONT for each VLAN port, shared by all queues for the VLAN port. When the upstream traffic is forwarded from the LT to the NT, a simple, non-configurable queuing mechanism is used. Traffic enters a single queue per uplink and is classified as critical, high or low priority. Critical priority is reserved for internal LT-to-NT communications and other traffic is classified as high or low priority based on p-bits. The queue fill level has two thresholds: when the queue fills to the lower threshold, low priority traffic is dropped; when the queue fills to the higher threshold, low and high priority traffic is dropped. For some ONT types, there is the option to perform shaping of upstream traffic for individual queues, before the traffic reaches the T-CONT. In this way, when a T-CONT serves multiple queues, a hierarchical shaping is achieved by shaping at the queue level and also at the T-CONT level. This option is supported for queues both at the UNI level and at the VLAN port level. It is configured by associating a shaper profile to the upstream queue.
Figure 20-17 illustrates the mapping of traffic to queues and the TC layer parameters, as well as bandwidth profile sharing.
20-22
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service Figure 20-17 Upstream traffic mapping to queues and TC layer parameters BW profile -> T-CONT
Different priorities: SP Identical priorities: WFQ
BW profile sharing ENABLED
GEM T-CONT
SP WFQ GEM
T-CONT
Pbit-to-queue mapping
Pbitx . . . Pbitz
GEM BW profile sharing DISABLED
Downstream scheduling and shaping The GPON LT board provides a hierarchical downstream scheduling and shaping as depicted in Figure 20-18. The main features are as follows:
• A fixed number of downstream queues can be assigned to each UNI/ONT of a PON. The fixed number is either 4 or 8 on NGLT-A, this parameter can be configured independently on each PON. On NGLT-C/FGLT-A, it is configured per pair of neighboring PONs: that is, if the operator modifies the parameter on PON-1, the same value is also configured on PON-2 automatically (and so on for the other pairs: PON-3and PON-4, PON-5 and PON-6, and so on). Each queue can be configured by the operator with a weight and priority, which are used to control the scheduling of the queues at the UNI/ONT level. Note — Before changing the number of downstream queues per UNI/ONT parameter of a PON on NGLT-C/FGLT-A, please be aware of the following restrictions:
• make sure there is no UNI/ONT already created on the neighboring PON.
• make sure the neighboring PON is not already protected by another PON (see “PON Link Protection” in chapter “Failure protection and redundancy provisions in ISAM”.
• A scheduler node profile is assigned to each UNI on the PON, unless “queue sharing” is used. Each scheduler can be configured by the operator with a weight, which is used to control the scheduling of the UNIs at the ONT level. Up to 32 UNIs can be included in the same ONT scheduler. • A scheduler node profile can be assigned to an ONT. The scheduler can be configured by the operator with a weight, which is used to control the scheduling of the ONT at the PON level. The ONT scheduler node is required if “queue sharing” is used; otherwise, it is optional. • A shaper profile can be configured at queue level, at UNI level, and at ONT level. Note that this shaping is applied to unicast traffic only. Multicast traffic is queued separately, and is therefore shaped separately (see Figure 20-18). However, there is a configurable option to include the multicast traffic in the UNI level shaping. When this option is enabled, as a multicast stream is joined (via IGMP protocol), then its bandwidth is subtracted from the configured bandwidth
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-23
20 — Quality of Service
of the shaper on the corresponding UNI. Since the configured multicast bandwidth is used, note that the actual (dynamic) use of bandwidth by the multicast stream is not taken into account. Note — Including the multicast traffic in the UNI level shaping is not possible when auto-shaping is used.
When shaping is performed at multiple levels (for example, queue level and UNI level) it is advised to set the rate at the lower level to a lower value than the rate at the higher level. For example, in the case that queue and UNI level shaping are configured, the queue rate should be configured to a lower value than the UNI rate. Not following this rule can lead to unexpected behavior because the operation of the two shapers is not synchronized. • The auto-scheduling option allows the weight of the queues to be calculated automatically, rather than using configured or default values. The weight of a queue is calculated based on the CIR of the queue. The value is selected so that the queue will be guaranteed sufficient service to allow its CIR to be honored. Note that the CIR is a parameter of the shaper profile associated with a queue. Also, when auto-scheduling is enabled, the weight of the next scheduler level is calculated automatically. Again, the value is selected to guarantee sufficient service to allow the CIRs of all queues to be honored. Auto-scheduling option can be enabled on a per-PON basis. When it is enabled, it is mandatory to configure CIR for each queue, since the CIRs of the queues are used to derive the weights. The automatically calculated weights can be displayed by the operator and are stored separately from configured weights. Auto-scheduling entails a downstream CAC to ensure that configured CIRs can be honored. See “Connection Admission Control” Note — The CIR of a queue can only be guaranteed if either:
• all queues (attached to the same scheduler node) are scheduled in weighted mode; or
• any queues (attached to the same scheduler node) scheduled as strict priority are rate limited to their configured CIR (that is, EIR = CIR). It is the responsibility of the operator to ensure that the scheduling is configured correctly when CIRs are used.
• Auto-shaping. This option allows the EIR of a shaper attached to a scheduler node to be automatically calculated. The option is applicable in two cases:
• when queues are scheduled at the UNI level, the EIR of the UNI is automatically calculated;
• when queues are scheduled at the ONT level, the EIR of the ONT is automatically calculated.
The EIR value is calculated based on the configured CIRs/EIRs of the queues on the UNI/ONT. EIR of UNI/ONT = max (sum of CIRs of queues, maximum EIR of queues). The auto-shaping option can be enabled or disabled per shaper profile.
20-24
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
• PON level queues for the following: • OMCI queue (which is also used for trace and debug packets) • Multicast streams - a scheduler block consisting of two queues scheduled SP, with • •
higher priority for configured multicast streams and lower priority for unconfigured multicast streams Incidental multicasts/broadcasts VoIP traffic. A forwarder (VLAN) may be configured so that its traffic is sent to the voice queue. Use of this queue has the advantage that latency is minimized
The OMCI, VoIP, and incidental multicasts/broadcasts queues are scheduled as strict priority, with OMCI as the highest priority and VoIP as the second highest. The multicast streams scheduler block is also scheduled as strict priority in conjunction with a rate limiting to the configured maximum multicast bandwidth. Figure 20-18 Downstream scheduling and shaping on the GPON LT OMCI
OMCI
R
SP
R
SP
R
WFQ
R
SP
Voice
Voice Hig h Pr io r ity Low Priority
Multicast streams
R
SP
R
SP
broadcasts and Bincidental multicasts
TC w
Unicast traffic for one UNI distributed to 4 or 8 queues
TC x TC y TC z
R R R
GPON INTERFACE
R R R
TC w
Unicast traffic for one UNI distributed to 4 or 8 queues
TC x TC y TC z
WFQ
R R R R R
UNI level scheduler ONT level scheduler
PON level scheduler
The GPON LT board supports both tail drop and color-aware RED buffer admission control. The GPON ONT only supports tail drop For many ONT types, the downstream queues on the ONT are not configurable. The exact implementation varies by ONT type. The number of queues used can be eight (for example, Freescale ONT), four, or two (for example, Broadcom ONT). Generally, traffic is assigned to the queues based on p-bit marking, and traffic with higher p-bit values is scheduled ahead of traffic with lower p-bit values. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-25
20 — Quality of Service
Some ONT types support configuration of priority and weight for the downstream queues. To distinguish these queues from the downstream queues on the LT, they are referred to as “remote queues”. Per UNI, either four or eight remote queues may be configured with priority and weight. Scheduling is performed in accordance with the configured priorities and weights. QoS on a GE Ethernet LT board
A GE Ethernet LT board supports UNI, HC-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 20-3. Table 20-3 QoS capabilities of UNI ports and NNI ports Feature P-bit-handling
P-bit-based classification P-bit to traffic class mapping
UNI
NNI
HC-UNI
Y
Y
Y
System or
System
System
VLAN(1)
DSCP-handling
Subflow
Policing
Queueing
Shaping
Port default p-bit (untagged frames)
Y
Y
Y
VLAN-based priority (tagged frames)
Y
Y
Y
P-bit regeneration profile
Y
Y
Y
DSCP-to-p-bit alignment
BP
BP
BP
DSCP-to-DSCP contract table
N
N
N
L2/L3 filters
BP, VP
BP(2), VP(2)
BP(2), VP(2)
Subflow policing and marking
BP, VP
BP(2), VP(2)
BP(2), VP(2)
DSCP range support for L3 filters
Y
Y
Y
SAP based policing
BP, VP
BP, VP(2)
BP, VP(2)
trTCM (Two Rate Three Colour Metering) – Colour aware and blind variants
Y
Y(2)
Y(2)
WRED (# of colours)
3C
3C
3C
Weighted tail drop (# of colours)
3C
3C
3C
Downstream programmable weights between WFQ queues
Y
Y
Y
Downstream configurable SP/WRR queue scheduler at port level
Y
Y
Y
Downstream programmable weights between ports (scheduling at board level)
Y
NA
NA
Port shaping
Y
Y
Y
Queue shaping
Y
Y
Y
Legend: BP: supported at Bridge Port level VP: supported at VLAN port level
20-26
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service Notes (1) VLAN-based p-bit to queue mapping is only supported in the downstream direction. System level mapping is recommended (2) Upstream only
The following limitations apply to the NNI and HC-UNI ports:
• • • •
downstream L2/L3 filters are not supported downstream policers are not supported on VLAN port level downstream trTCM is not supported L2 filter with MAC address is not supported Caution — Caution regarding p-bit to traffic class mapping
Usually, it is expected that both system-level and VLAN-level mappings will be configured identically. There are cases where a different mapping could be used at the VLAN level. For example where it is desired to have a 'queue per VLAN' model (for example, to allow per-VLAN shaping downstream) all p-bits for a VLAN are mapped to a single traffic class which then is mapped to a specific queue. Link Aggregation on a GE Ethernet LT board The GE Ethernet LT board supports link aggregation of up to eight ports per link aggregation group (LAG). The ports must be:
• of the same type (UNI, HC-UNI or NNI) • on the same LT board • 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 active links is N, then each port is shaped to a rate of R/N. A policer associated with an LAG will be applied to traffic for all active links in the LAG. 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/re-marking configured on the bridge port or a VLAN port of an LAG is applicable to all physical ports of the LAG.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-27
20 — Quality of Service
• 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. QoS on an EPON LT board and an EPON ONT
This section describes the QoS aspects of both the EPON LT boards and the ONTs, noting which functions are performed by the LT board and which are performed by the ONT. Capabilities specific to the EPON implementation are highlighted, as well as any deviations from the DSL capabilities. In the discussion of the EPON QoS, it is important to understand the high-level implementation of the EPON QoS management model. To accommodate various traffic types and rates, the EPON LT has a number of scheduling mechanisms as illustrated in Figure 20-19. The paragraphs below describe the different scheduling mechanisms. Figure 20-19 Upstream QoS Handling EPON LT
ONU
LLID
Rate limitation
PON
Rate limitation
Classifier
LLID
SP/WRR
DBA Scheduler
EPON LT SP/WRR
Ether Port
Fixed, Guaranteed, Best Effort bandwidth
Ether Port
Ether Port
Grants
Upstream QoS handling
EPON LT
PON
LLID
Rate limitation
LLID
SP
WRR/SP
EPON LT Rate limitation per Service
Ether Port
ONU
Ether Port
Downstream QoS handling
Classification and marking
20-28
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
Upstream classification and marking for EPON subscribers is performed by the MDU. For SFU cases, the upstream classification and marking for EPON subscribers is performed by the EPON OLT. Marking is only applied to p-bits (not DSCP). Below options are available:
• Packets can be marked based on subscriber port, or protocol default (IPoE or PPPoE). • If a packet is already tagged, the p-bits can be re-marked using one of ten fixed mapping tables that map the received p-bit to a new value. Marking as a policy action is supported. Note — EPON LT boards and ONTs do not re-mark p-bits in the downstream direction.
Policing No policing is supported in EPON upstream and downstream per LLID. Upstream scheduling and shaping In EPON LT boards, the hardware has two forwarding devices, an aggregation switch and EPON MAC chipset. Since it is non-blocking in upstream, the aggregation switch will not do QoS control in the upstream direction. EPON MAC contains a grant engine or DBA scheduler for each PON. This grant engine allocates bandwidth to the specific LLIDs. Three types of bandwidth allocation are supported in EPON MAC for each LLID:
• Fixed bandwidth: the fixed bandwidth allocated to an LLID cannot be shared with other LLIDs even when there is no traffic within this LLID. • Guaranteed bandwidth: the guaranteed bandwidth allocated to an LLID can be shared with other LLIDs if the guaranteed bandwidth is not fully occupied by the traffic within this LLID. The traffic within this LLID has the highest priority to get guaranteed bandwidth by SP scheduling. • Best effort bandwidth EPON MAC DBA scheduler will assure fixed and guaranteed bandwidth first for all LLIDs after CAC checking within the PON interface. If the spare bandwidth is still available for this PON interface, EPON MAC DBA will allocate best effort bandwidth for all LLIDs according to the DBA report from each ONU. Downstream scheduling and shaping In the aggregation switch of EPON LT boards, there are eight queues per GE PORT towards EPON MAC and programmable SP, WRR or SP + WRR are supported among downstream queues. Traffic mapping to queue can be based on COS or p-bit. In EPON MAC, downstream queues are supported in each PON interface. Each downstream queue has a different SLA level and each SLA level is assigned a priority.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-29
20 — Quality of Service
The EPON LT board provides a hierarchical downstream scheduling and shaping as depicted in Figure 20-20. The main features are as follows.
• A fixed number of downstream queues can be assigned to each UNI/ONT of a PON. The fixed number is either four or eight. Each queue can be configured by the operator with a weight and priority, which are used to control the scheduling of the queues at the UNI/ONT level. • A shaper profile can be configured at queue level. Figure 20-20 Downstream QoS handling in EPON LT boards 1 LLID (1 ONT)
RR
PON Level
SLA level 1 P-bit P1
TC SLA level 2
-Q
P4
SLA level 3
Strict priority In EPON, 8 SLA levels are supported per LLID. But in order to ensure the CIR for each SLA level, EPON put the data in CIR in an SLA level and put data larger than CIR and less than EIR to another SLA level (SLA level +4). So it can ensure all CIR with different SLA levels. So in EPON, only 4 queue levels can be used by the operator.
Shaping profile SLA level 4 1 LLID (1 ONT)
The Q-SLA level mapping is manageable via EPON MIB
Upstream ONT Quality of Service In ONU, upstream rate limitation per UNI is supported. Then traffic from all UNI ports within the ONU will be aggregated and classified to 4 queues. The traffic classification is based on below information:
• • • • • • • • •
VLAN ID Ethertype CoS VLAN ID +CoS VLAN ID + Ethertype SA/DA IP DSCP IP protocol type TCP/UDP port
A priority will be provisioned for each queue. The upstream scheduler in ONU can treat an individual queue in a strict priority or a weighted round robin fashion. In ONU, all traffic from four queues will be associated with one LLID. It is important to understand that the EPON LT board granting engine operates on LLID and not on queue, UNI or VLAN Priorities. Downstream ONT Quality of Service 20-30
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
In the downstream direction, the ONT can receive more data than its egress ports can support. A substantial amount of data buffering must be provided to absorb any data bursts until they can be transported out of the NE. Therefore, ONU/ONT must support an SP scheduling mechanism in the downstream direction. The rate limitation per UNI is also required to be supported in ONU.
20.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. QoS profiles supported on the LTs (IACM part):
• • • • • • • • • • • • • • • •
CAC profile Ingress QoS profile (p-bit to traffic class mapping) Queue profile Shaper profile Bandwidth profile (used for GPON T-CONT) Bandwidth profile (used for EPON LLID) Scheduler node profile Priority contract profile (p-bit regeneration profile) Session profile Marker profile Policer profile Policy profile Layer 2 filter Layer 3 filter Policy action profile DSCP to p-bit alignment profile
QoS profiles supported on the NTs (IHub part):
• • • •
Service Ingress access profile Service Ingress network profile Service Egress network profile Base router network policy
IACM part 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-31
20 — Quality of Service
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 line rate from the physical interfaces and calculates an estimate of the available Ethernet bandwidth using configurable overhead factors. The line rate taken into account may be the guaranteed sync rate or the actual line rate in case of xDSL, based on a global configuration. In the profile, a part of the available downstream bandwidth can be reserved for voice and data applications. 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 is ignored by the CAC function, even if it concerns premium content or generic internet streaming video. A CAC profile can be associated with a subscriber interface, using the relevant QoS configuration command, see the 7360 /7302 ISAM | 7330 ISAM FTTN CLI Commands and the 7360 /7302 ISAM | 7330 ISAM FTTN Operations and Maintenance using CLI documents for more information. Ingress QoS profile (p-bit to traffic class mapping)
The ingress QoS profile is used to map traffic to the correct traffic class. A profile is associated with each forwarder (VLAN) or per VLAN port. The configurable profile specifies, for each p-bit value, the traffic class to which it is mapped. Up to eight traffic classes can be specified. The ingress QoS profile is currently only supported for GE Ethernet LT board (UNI ports only, downstream direction), GPON LT boards and GPON ONT, EPON LT boards and EPON ONT. For other LT board types, and UNI in the upstream direction, and NNI and HC-UNI ports of the GE Ethernet LT boards, there is a single configurable system-wide mapping table that maps p-bits to traffic class. For the GE Ethernet LT board:
• NNI ports use the system-wide mapping table • UNI ports use the system-wide mapping table if no ingress QoS profile has been configured. For the GPON LT board, the ingress QoS profile also defines how p-bits are mapped to color. The color marking is used for color-aware policing and color-aware RED. There is also an option to use the DEI bit in the packet to mark color, rather than using the p-bits. 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. For GPON LT boards, since flexible scheduling is supported, it is possible to configure all queue weights and priorities. 20-32
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
For GPON ONT, some ONT types support configuration of priority and weight for the downstream queues. To distinguish these queues from the downstream queues on the LT, they are referred to as “remote queues”. For EPON LT boards, the flexible scheduling is supported and it is possible to configure all queue weights and priority. However, the queue weights are ignored, since only round robin is supported for same priority queue. 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. There are a number of default BAC profiles which can be used, but which can not be modified nor deleted. 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 discards for average queue filling levels just below the maximum threshold. Figure 20-21 RED configuration parameters Drop probability
Discard probability
Minimum threshold
Maximum threshold
Weighted average Filling level
Note — The weight, used for calculating average buffer sizes in RED, is not configurable.
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. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-33
20 — Quality of Service
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 subscriber 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. The following two figures illustrate the three color WRED and the three color tail drop, respectively. Figure 20-22 Three color WRED Drop probability
100%
Averaged queue filling level red min
red max/ yellow min
yellow max/ green min
green max
Figure 20-23 Three color tail drop Drop probability
100%
Actual queue filling level red max
20-34
November 2013
yellow max
green max
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
Queue buffers on GPON LT boards form a shared pool. Therefore, the guaranteed minimum queue size and the maximum queue size are configurable for both tail drop and color-aware RED queues. In the case of prolonged congestion on the PON, the shared pool can come close to empty since many packets will be queued. In this scenario, the BAC policy will be temporarily modified to ensure that the pool remaining is sufficient to satisfy the guaranteed minimum of all queues. In this temporary congestion state, all queues operate in a simple tail drop fashion by using the guaranteed minimum queue size as the drop threshold. The normal BAC policy is temporarily suspended until there are more buffers available. For some GPON ONT types, it is possible to configure the maximum queue size for the upstream queues on the ONT. A queue profile is used for that purpose. Due to a hardware limitation in the ONT types that support this feature, currently all upstream queues on the ONT must use the same maximum queue size. Therefore, all queues on an ONT should be configured with the same queue profile. In the EPON LT board, only tail drop queues are supported. Note 1 — BAC configuration for upstream queues on LT board is
fixed. Note 2 — L3 LT boards support buffer oversubscription. 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. • Committed Burst Size (CBS): in byte increments up to a maximum of 256Mbyte (this parameter is not used by shapers on GPON LT). 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 (UNI, HC-UNI or NNI). For GPON subscribers, a shaper profile contains the following configuration parameters:
• Type: only single-token bucket shapers are currently supported • Excess Information Rate (EIR): used on the GPON LT board to rate limit a queue, a UNI level scheduler or ONT level scheduler.
• Committed Information Rate (CIR): When the auto-scheduling option is enabled on the PON, the shaper profile specifies a CIR value for the downstream queue. The CIR is used to automatically configure the queue weight. Additionally, when the auto-shaping option is enabled on a UNI or ONT, the CIR of the associated queues may be used to calculate the rate limit on a UNI or ONT. See “QoS on the GPON LT boards and the ONTs” for a description of auto-scheduling and auto-shaping. • A GPON shaper profile may be associated with a downstream queue, UNI level scheduler, or ONT level scheduler. A GPON shaper may be associated with an upstream queue on an ONT. Note that shaping in the upstream direction is also Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-35
20 — Quality of Service
configured at the T-CONT level using the bandwidth profile rather than the shaper profile. Thus hierarchical shaping is possible in both downstream direction (queue/UNI/ONT) and upstream direction (queue/T-CONT). For EPON subscribers, a shaper profile contains the following configuration parameters:
• • • •
Type: only single-token two rate bucket shapers are supported. Committed Information Rate (CIR) Excess Information Rate (EIR) Committed Burst Size (CBS)
Shaping profile is used at both LLID and VLAN port level. Bandwidth profile
ISAM uses bandwidth profiles to capture the upstream scheduling and shaping requirements of a T-CONT, as described in section “QoS on the GPON LT boards and the ONTs”. The following parameters can be configured:
• • • •
Committed Information Rate (CIR). Assured Information Rate (AIR). Excess Information Rate (EIR) Delay tolerance.
The T-CONT type is determined by the CIR, AIR and EIR configuration; see Table 20-4). Table 20-4 Mapping CIR, AIR and EIR to T-CONT type Delay Sensitive
Assignment Type
Applicable T-CONT types Type 1
Type 2
Type 3
Type 4
Type 5
CIR
Yes
Provisioned
CIR
0
0
0
CIR
AIR
No
Provisioned
AIR = CIR
AIR
AIR
0
AIR ≥ CIR
EIR
No
Provisioned
EIR = AIR
EIR = AIR
EIR > AIR
EIR
EIR ≥ AIR
ISAM uses bandwidth profiles to capture the upstream scheduling and shaping requirements of LLID, as described in section “QoS on an EPON LT board and an EPON ONT”. The Assured Information Rate (AIR) parameter can be configured per LLID. Priority contract profile
A priority contract profile may be associated with a bridge port or a VLAN port. For non-GPON subscribers one of ten profiles can be selected. Refer to the CLI command guide for details. These ten profiles are not configurable. For GPON subscribers, there are 22 additional configurable profiles available. Each profile consists of the mapping of each p-bit to a different p-bit (or the same p-bit).
20-36
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
Scheduler node profile
The GE Ethernet board and the GPON LT board use 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 board) or at ONT level (GPON LT board). • 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. See Figure 20-24 A QoS session profile is always instantiated at a user logical interface or Service Access Point (SAP). See the CLI Commands for FD 100/320Gbps NT and FX 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 20-24 Composition of QoS session profile QoS Session Profile
Logical Flow Type
QoS Policer Profile Up
QoS Policer Profile Down
QoS Marker Profile Up
QoS Policy List Up
QoS Policy List Down
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-37
20 — Quality of Service
The scope of a QoS Session profile is always a user logical interface or Service Access Point (SAP). The following are examples of such “logical interface” types supported:
• PVC: all frames on a PVC • 802.1x session: all frames on a bridge port that was opened via a 802.1x • • • • • • •
authentication PVC.VLAN: all frames on a bridge port with the same VLAN ID IPoE VLAN CC: all IPoE frames in a VLAN CC interface PPPoE iBridge: all PPPoE frames in iBridge interface GPON UNI: all frames on a UNI of an ONT GPON VLAN port: all frames on a UNI with the same VLAN ID EPON LLINK: all frames on an ONU EPON VLAN port: all frames on an ONU with the same VLAN ID
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). The marker profile carries a flag for enabling DSCP to p-bit alignment of the SAP, based on the global DSCP to p-bit alignment table, or alternatively in case of GPON subscribers, based on the associated DSCP to p-bit alignment profile. It further allows specification of the SAP default p-bits, the DSCP, or the DSCP contract table (depending on the SAP type). The marker profile can also be used to re-mark the p-bit based on trTCM packet color. Seven types of marker profiles exist:
• • • • •
20-38
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
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
• d1p-alignment: p-bit value derived from DSCP code-point. This mapping to p-bit markings applies to the IPv4 DSCP value as well as to the IPv6 Traffic Class field. A configurable system level mapping is used. In addition, for GPON subscribers, it is possible to use a DSCP to p-bit alignment profile, as described in “DSCP to p-bit alignment profile”. When used for GPON, the alignment can be done in two different ways: At the ONT: this functionality is only applicable to untagged IPoE frames. The IPv4 and IPv6 alignments are configured separately, as explained in the following notes:
• For IPv4 alignment, a port default VLAN must first be configured, e.g. VLAN1. The •
alignment must then be configured in the marker profile associated with the VLAN port for VLAN1. For IPv6 alignment, an IPv6oE protocol default VLAN must first be configured, e.g. VLAN2. The alignment must then be configured in the marker profile associated with the VLAN port for VLAN2.
The VLANs used for IPv4 and IPv6 may be the same (VLAN1 equals VLAN2) or different (VLAN1 does not equal VLAN2). At the OLT: this functionality applies across all ONTs. The GPON LT can be configured to perform upstream DSCP to p-bit alignment for untagged and tagged IPv4 and IPv6 traffic. Both encapsulation in PPPoE and in plain Ethernet are supported. The DSCP to p-bit alignment on the GPON LT must be based on the system level DSCP to p-bit alignment table. • d1p-re-mark: mapping of p-bit to another p-bit is to be used in conjunction with the trTCM. (The profile is attached to the policer as a color-specific action. This allows re-marking p-bits as a function of the color determined by the policer.) This option is only supported by the GPON LT board. All types of marker profile are supported in the upstream direction. The marker profile is not supported in downstream direction. Only the following types of marker profile are supported for IPv6 packets:
• a fixed value imposed for p-bit • d1p-alignment See the CLI Commands for FD 100/320Gbps NT and FX NT and the Operations and Maintenance Using CLI for FD 100/320Gbps NT and FX 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-39
20 — Quality of Service
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. Note 1 — For GPON LT boards, CIR is in 64 kb/s increments up to 1 Gb/s. Note 2 — Policing is not supported in the EPON board.
• Committed Burst Size (CBS) up to a maximum of 128 Mbyte. Note that the maximum is dependent on the LT type:
• • • •
•
L3 LT based on Intel or CATE: 256 KB NELT-A: 2 MB L3 DSL LT based on CATAN: 64 MB NELT-B: • UNI downstream: 64 MB • UNI upstream: 128 MB • NC-UNI upstream/downstream: 128 MB • NNI upstream/downstream: 128 MB GPON LT: 128 MB
The GE Ethernet LT board and the GPON LT board also support the two-rate Three Color Marker (trTCM). This is a type of policer that marks each packet with a color - green, yellow, or red. Note — The GPON LT board has an MDU option to police at the MDU rather than the LT board. In this case only single token bucket policing is supported.
The trTCM contains some additional parameters:
• • • •
Excess information rate (EIR) Excess Burst Size (EBS) Color mode: either color-aware or color-blind For the GE Ethernet LT board:
• Green action: forward • Yellow action: forward, discard • Red action: forward, discard • For the GPON LT board: • Green action: forward, or forward and re-mark the green packets. Re-marking can either re-mark the p-bit or set the DEI based on the color.
• Yellow action: forward, discard, or forward and re-mark the yellow packets • Red action: forward, discard, or forward and re-mark the red packets • Coupling flag: enabled or disabled. • For GPON LT board, per color, a marker profile of type “dot1p re-mark” can be associated. This allows re-marking of p-bit as a function of the color output of the policer
20-40
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
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 color marking described in “Mapping and queueing”. The color marking can be green, yellow or red. 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. For GPON, ONTs also police the upstream DHCP, ARP and IGMP packets. DHCP and ARP packets are each limited to 10 per second. If an IGMP channel is configured, then IGMP packets are rate limited to the same CIR as the slow path policer (described above). Policy framework
A generic policy framework provides finer-grained control over subscriber traffic. It provides for generic layer 2 or layer 3 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. Two types of L3 filters are supported: filters applicable to IPv4 traffic and filters applicable to IPv6 traffic. The type of traffic is explicitly mentioned in the L3 filter definition with default applicable to IPv4 traffic. For the sake of simplicity, IPv4 terminology is used for the different fields in an IPv4 filter and an IPv6 filter. As such DSCP refers to DSCP in IPv4 and traffic class in IPV6. The protocol field refers to protocol field in IPv4 and the next header field in IPv6. Figure 20-25 shows the policy building blocks.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-41
20 — Quality of Service Figure 20-25 Policy building blocks
L2 Filter
L3 Filter
Policy Action
MAC Destination Address
Address Type
Default Disposition
MAC DA Prefix
IP Destination Address
Set DSCP
MAC Source Address
IP DA Prefix
Set P-bits
MAC SA Prefix
IP Source Address
Police
Ethertype
IP SA Prefix
Sharing
P-bits
DSCP
CFI bit
Protocol Type
VLAN ID
Destination Port Range Source Port Range
Note — P-bits and DSCP relate to the re-marked values when used as a policy match condition. For example, a policy match condition specifies p-bit value two. When a packet is received with p-bit value two, but is subsequently re-marked to p-bit value three, it would not match the policy. However, for the GE Ethernet LT board, the received p-bit is used.
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, 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, p-bit/DSCP code point modifications can only be realized by means of a policy action. Some restrictions apply to IPv6 packets:
• Layer 3 filters are not supported for IPv6 packets. This implies that corresponding policy actions are not possible for such packets, unless applied via a Layer 2 filter.
• It is not possible to set the DSCP field in an IPv6 packet as a Layer 2 filter action.
20-42
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
For the GPON LT board, filter policies are applied to protocol packets lifted to the CPU, as well as data packets. For the non-GPON LT boards, filter policies are not applied to the protocol packets lifted to the CPU. For example, suppose that a policy is defined to discard upstream broadcast packets. For a DSL subscriber with PPPoE service, this policy would not discard a PPPoE PADI packet. However, for a GPON subscriber, this policy would discard a PPPoE PADI packet. To avoid discarding the PADI packet, an additional policy must be added in the case of the GPON subscriber, with higher precedence than the discard policy. This policy should match on the Ethertype of the PADI and specify action as 'allow packet'. DSCP to p-bit alignment profile
For GPON subscribers, it is possible to configure DSCP to p-bit alignment profiles. Each profile defines an explicit mapping of each DSCP codepoint to a p-bit value. The profile may be linked to an upstream marker profile. 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-43
20 — Quality of Service Figure 20-26 QoS Counters and TCAs on layer 3 Boards Queue Counters: Passed Bytes/Frames Dropped Bytes/Frames Load
OBC counters: Dropped OBC frames US Dropped OBC frames DS
OBC OBC TCAs: Dropped OBC frames US Dropped OBC frames DS
Queue TCAs: Dropped Frames Load
Tx SP WFQ
Master Tx
Memory Pool Downstream
System Bus Counters (per Traffic Class): Passed Bytes/Frames Load
System Bus TCA): Load
SP WFQ Aggregate buffer counters: Dropped frames US Dropped frames DS Dropped low prio frames Aggregate buffer TCAs: Dropped frames US Dropped frames DS Dropped low prio frames
Tx
High priority threshold
Line Counters: Passed Bytes/Frames Droppedd Bytes/Frames Load
For the GPON LT board, downstream queue based counters are enabled/disabled on a per UNI basis, being disabled by default. The counters can be enabled on up to 32 UNIs per PON. Packets passed/dropped, and bytes passed/dropped are counted. Load per queue is not calculated. There is also a, per queue, threshold crossing alarm for dropped packets. For EPON LT boards, queue counters are not supported. For the non-GPON LT 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). 20-44
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service Figure 20-27 Buffer pool regions on IXP boards Max usage of a queue from the total pool (no guaranteed minimum on L3 boards)
Total Physical Packet memory
Area that can be saved for high priority traffic via configuring partial buffer overflow threshold (configurable in % of total pool)
Area for both low and high priority traffic
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. For the GPON LT board, the following line-card level counters are supported:
• • • •
high-priority packets to the OBC, dropped packets and bytes, low-priority packets to the OBC, dropped packets and bytes, high-priority packets towards the NT-LT link, dropped packets and bytes, low-priority packets towards the NT-LT link, dropped packets and bytes.
For the non-GPON LT boards, the following line-card level counters and alarms are supported:
• number of packets passed (per Traffic Class) • number of bytes passed (per Traffic Class) Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-45
20 — Quality of Service
• • • • • • • •
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 (that is, Controlled Load and Best Effort) 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
For EPON boards, line-card level counters are not supported. 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 (that is, 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).
IHub part
Service ingress access policy
Ingress access policies can be assigned to layer 2 services V-VPLS/VPLS/EPIPE and to layer 3 services VPRN/IES. This effectively means that Ingress access policies mappings can be defined and applied per service provider. Ingress access policy profiles describe the mapping of packets received from SAPs to a forwarding class and in/out profile color:
• The forwarding class is used to identify the egress queue in which the packet will be queued.
• The profile color will be used for queue acceptance in the egress queue (WRED: see later) 20-46
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
The mapping of packets to forwarding class and color can be based on combinations of customer QoS markings, including IEEE 802.1p bits, DSCP (IPv4 or IPv6), and TOS precedence codepoints (IPv4 or IPv6). Each service is associated at creation time to a default ingress access policy. Note — Untagged packets will be assigned a default p-bit codepoint.
This codepoint is also configurable in the policy.
In case ingress access policies are configured for a v-VPLS and this v-VPLS is associated with a VPRN/IES service, then the VPRN/IES service ingress access policy takes precedence. Service ingress network policy
Ingress network policies can be assigned to the following L2 services: VPLS/ EPIPE. This effectively means that Ingress network policies mappings can be defined and applied per service provider. Ingress network policy profiles describe the mapping of packets received from MPLS PW (that is, SDP binding) to a forwarding class and in/out profile color:
• The forwarding class is used to identify the egress queue in which the packet will be queued.
• The profile color will be used for queue acceptance in the egress queue (WRED: see later) The mapping of packets to forwarding class and color is based on service label EXP value or based on the IEEE 802.1p bits of the encapsulated Ethernet packet. Each service is associated at creation time a default ingress network policy. Note — Using the inner p-bit is only meaningful when the encapsulated Ethernet packet is tagged. This is not guaranteed when the PW VC-type is ether.
Service egress network policy
Egress network policies can be assigned to the following L2 services: VPLS/EPIPE. This effectively means that egress access policies mappings can be defined and applied per service provider. Egress access policy profiles describe how the EXP value and the outer p-bit of packets sent out of a MPLS PW (SDP binding) are generated based on a forwarding class and in/out profile color.
• The outer EXP value and/or outer p-bit will be used by subsequent LSRs. • The inner EXP value is set identical to the outer EXP value, and can be used by eLER as described in section “Service ingress network policy”
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-47
20 — Quality of Service
Each service is associated at creation time a default egress access policy. Note — Mapping in the policy all forwarding classes to the same EXP value allows to have a particular EXP per service provider.
Per-service egress rate limit
The IHub allows applying an egress rate limit: 1
Per service for all received traffic, associated to a V-VPLS/VPLS/EPIPE or VPRN/IES service, which is egressing on network ports, or
2
Per class of service (CoS) within a specific service, again for all received traffic, associated to a V-VPLS service, which is egressing on network ports.
In case a packet matches an egress rate limit for both a V-VPLS and a VPRN/IES service, the VPRN/IES rate limit shall always have priority over the per V-VPLS rate limit (so the latter will not be applied). For the type (2) rate limiter, the CoS is identified by a p-bit or by multiple p-bits. Both type (1) and type (2) rate limiting can co-exist on the same service. However, traffic that matches a type (2) rate limiter will not be included in the type (1) rate limiter, since only a single rate limiter can be applied to a packet. The metering is based on two rate, three color marking. Lower priority packets will be dropped first. The packets will be marked green (in profile) or yellow (out of profile) using a configurable system-wide mapping of p-bit to color. The metering will then update the color (green can change to green, yellow, or red; yellow can change to yellow or red). The per-service rate limiter function will include an action to drop the red packets. It is possible to re-mark the p-bit after policing has occurred, based on the color determined by the policer. There is a configurable system-wide mapping for each (p-bit, color) combination. Each network port can be configured to enable or disable this re-marking. Note — See sections “Service ingress access policy” and “Service
ingress network policy” for details on interaction of per-service egress rate limiting with service ingress access/network policies. Both per-service egress rate limiting and service ingress access/network policies provide a means to color mark packets. If no rate limiting is applied to a packet, then the applicable service ingress access/network policy determines the color marking. However, if perservice egress rate limiting is applied to a packet, then the color determined by it overrides the color determined by the service ingress access/network policy, except for the following case:
• Rate limiter has determined that a packet is green (in profile), but the applicable service access/network policy determines that the packet is yellow (out of profile). The resulting color is yellow (out of profile).
20-48
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
When the NT redundancy scheme is configured as “active/active”, then separate rate limiting is required in both NT boards. In this case, the configured rate limit is split 50 percent to each NT board according to the configuration via the CLI command configure qos-servicerouter active-nt-loadshare. Normally, this should be set to 50%-50% for the two NT boards. Note — In the active/active configuration, the rate limiting function
will not work for subtending interface on the NT, for example, if a subtending ISAM is connected directly to the NT.
Per-service ingress rate limit
The FD 320Gbps NT and the FX NT allow applying an ingress rate limit per service for all received traffic associated to a v-VPLS/VPLS or VPRN/IES service, which is ingressing on network ports. Note — This feature is not supported on EPIPE, VPLS used for MPLS, or VPLS with multiple VLANs associated to it. It is also not supported on the FD 100Gbps NT.
As for the per service egress rate limiting, the ingress rate limiting uses metering based on two rate, three color marking. See “Per-service egress rate limit” for details. Base router network policy
Network policy is assigned to the base router. Base router network policy profiles describe the mapping of packets received on network IP interfaces (of this base router) to a forwarding class and in/out profile color:
• The forwarding class is used to identify the egress queue in which the packet will be queued.
• The profile color will be used for queue acceptance in the egress queue (WRED: see later) The mapping of packets to forwarding class and color can be based on combinations of network QoS markings, DSCP (IPv4 or IPv6), and TOS precedence codepoints (IPv4 or IPv6). Note 1 — Untagged packets will be assigned a default p-bit
codepoint. This codepoint is also configurable in the policy. Note 2 — This policy is similar as the service access ingress policy
associated with a VPRN/IES service. Note 3 — The policy is applicable for all network interfaces. Forwarding class to egress queue mapping
For the FD 100Gbps NT, the mapping of the forwarding classes to egress queues is fixed and does not need configuration. The mapping table is shown in Table 20-5.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-49
20 — Quality of Service Table 20-5 Forwarding class to egress queue mapping (FD 100Gbps NT) Flow Class Name
FC Numbers
Egress Queue
Best Effort (BE)
0, 1
0
Controlled Load (CL)
2, 3
1
Video
4, 5
2
Voice
6, 7
3
For the FD 320Gbps NT and the FX NT, it is possible to configure:
• the number of unicast queues as either 4 or 8 • the FC to queue mapping. Since there are separate queues for unicast traffic and multicast traffic, for each traffic class, both the unicast queue and the multicast queue can be specified. The default mappings are shown in the following two tables. Note that the default for 8 queues is selected to correspond to the default queue prioritization. Refer to “Egress scheduler and rate limiter” for details of the default queue prioritization. Table 20-6 Default FC to egress queue mapping (4 queue - FD 320Gbps and FX NTs) Flow Class Name
FC Numbers
Egress UC Queue
Egress MC Queue
Best Effort (BE)
0, 1
0
0
Controlled Load (CL)
2, 3
1
1
Video
4, 5
2
2
Voice
6, 7
3
3
Table 20-7 Default FC to egress queue mapping (4 queue - FD 320Gbps and FX NTs)
20-50
Flow Class Name
FC Numbers
Egress UC Queue
Egress MC Queue
be
0
0
0
l2
1
4
0
af
2
1
1
l1
3
5
1
h2
4
2
2
ef
5
6
2
h1
6
3
3
nc
7
7
3
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service
Buffer and queue acceptance
Buffer and queue acceptance features Weighted Random Early Discard (WRED). The configuration of the buffer dimensioning and the buffer acceptance parameters is fixed and does not need configuration. The WRED supports two colors: in-profile (green) and out-of-profile (yellow) packets. For each of these profiles, a start average queue filling level, a maximum average queue filling level and a maximum drop probability applies, as shown in Figure 20-28, which is applicable for TCP traffic. Figure 20-28 Buffer and queue acceptance (TCP Traffic) Drop Probability
100% In profile max. probability = Out profile max. probability
50%
Average queue filling level
50% Out profile av. start
70%
90%
Out profile av. maximum
In profile av. start
In profile av. maximum
The following applies for the packets:
• Green packets: the packet drop rate starts at 70% average queue filling level and increases linearly from 0 to 50% packet drop rate at 90% average queue filling level. When the average queue filling level goes beyond 90%, all packets are dropped. Below 70% average queue filling level, there is no WRED drop. • Yellow packets: the packet drop rate starts at 50% average queue filling level and increases linearly from 0 to 50% packet drop rate at 70% queue filling level. When the average queue filling level goes beyond 70%, all packets are dropped. Below 50% average queue filling level, there is no WRED drop. For non-TCP traffic, the handling as shown in Figure 20-29 applies.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-51
20 — Quality of Service Figure 20-29 Buffer and queue acceptance (non-TCP traffic) Drop Probability
100%
Average queue filling level
70%
90%
In profile av. maximum
Out profile av. maximum
Egress scheduler and rate limiter
For the FD 100Gbps NT, the Egress queue schedulers are fixed and do not need configuration. The scheduler topology is a combination of strict priority (SP) served queues and Weighted Round Robin (WRR) served queues, as shown in Figure 20-30. Figure 20-30 IHub egress port scheduler topology
Voice SP
Video
Port rate limiter
CL WRR BE
For the FD 320Gbps NT and FX NT, it is possible to configure the queue priorities and weights. Weighted queues are treated as the lowest priority. There are default configurations for both 4 queue and 8 queue modes, as shown in Figure 20-31 and Figure 20-32. Note that there are separate queues for unicast and multicast traffic. Each multicast queue is always scheduled in a round robin fashion with the corresponding unicast queue. For example, multicast queue 3 and unicast queue 3 are scheduled together as a round robin group. In the 4 queue default, the unicast/multicast queue 3 are scheduled at highest priority, then the unicast/multicast queue 2, and finally unicast/multicast queue 1 and queue 0, in a 2:1 weighted fashion.
20-52
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service Figure 20-31 IHub egress port scheduler topology (default 4 queue FD 320Gbps and FX NT)
UC Q0 RR MC Q0
W=1
W=2
UC Q1
WRR
RR MC Q1
SP SP
UC Q2 RR
SP
MC Q2 SP UC Q3 RR MC Q3
Figure 20-32 IHub egress port scheduler topology (default 8 queue FD 320Gbps and FX NT)
UC Q0 RR MC Q0
SP
UC Q4
SP
UC Q1 RR
SP
MC Q1 SP UC Q5
SP SP
UC Q2 RR MC Q2
SP
UC Q6
SP SP
UC Q3 RR MC Q3 UC Q7
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-53
20 — Quality of Service
In the 8-queue mode, there are 8 unicast queues but still only 4 multicast queues (queues 0, 1, 2 and 3). As for the 4-queue case, each multicast queue is always scheduled in a round robin fashion with the corresponding unicast queue. The 4 extra unicast queues are numbered queue 4, 5, 6 and 7. In the 8-queue default, all queues are scheduled in strict priority (except for the round robin grouping for each pair of unicast/multicast queues). In terms of queue priorities, the 4 extra queues are interleaved with the 4 paired queues. At first sight, this order of prioritization looks strange as it means queue 7 is scheduled first priority, then queue 3, then queue 6, then queue 2, and so on (as shown in Figure 20-32). One would expect instead queue 7, then queue 6, then queue 5, and so on. However, such an order of prioritization would imply that 4 unicast queues would be scheduled at a higher priority than any multicast queue. The interleaving of the extra unicast queues avoids this problem. For each port, connected to the network or connected to a subtending ISAM, a port rate limiter function may be applied. The port rate limiter parameters are:
• Port egress rate • Burst size QoS parameters of packets generated by the control plane
IHub supports the creation of policies for packets generated by the control plane. Each policy defines the following QoS parameters for packets generated by the control plane:
• p-bit codepoint • DSCP codepoint • EXP value Each service is associated to a default policy for packets generated by the control plane. It is allowed to change this association, so that a service is associated with a customized policy, instead of the default policy. The QoS parameters will be added when the control packet is sent out on an external interface and will apply to all protocols associated to the service. Note — The policy does not apply to packets relayed by the control
plane.
20-54
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
20 — Quality of Service Figure 20-33 QoS in IHub upstream for services Service Egress Rate Limiting - CIR, PIR, CBS, PBS
Ingress QoS Policy (applies to all SAPs) Set FC based on DSCP, PREC,P-bits
Egress QoS policy (applies to all SDP bindings) Set EXP based on FC
VPLS/EPIPE/VPRN/IES
VPLS/EPIPE Application
Egress Port Rate Limiter - maximum rate
Self-Generated Traffic Policy
Access port Residential
Network port FC1 Access port regular
FC2 FC8 Port
SERVICE
SAP
ISAM
SDP binding Egress Port Queue Policy
FC Queue Map Policy
Egress Queue Slope Policy WRED
System wide defined mapping of FCx to egress COS queue
Defines Characteristics of each egress COS queue: - CBS, MBS, CIR, PIR Per-port definition of scheduling over egress queues: SP,WRR,..
Figure 20-34 QoS in IHub downstream for services Ingress QoS policy (applis to all SDP bindings) Set FC based on EXP, inner p-bit
Ingress QoS Policy (applies to all SAPs) Set FC based on DSCP, PREC,p-bit
VPLS/EPIPE/VPRN/IES
VPLS/EPIPE
Egress Port Rate Limiter - CIR, PIR, CBS, PBS
Application Access port regular
Self-Generated Traffic Policy
1 4 1 4 1
Network port
Access port Residential
4
FC1 FC2 FC8
SERVICE ISAM
FC Queue Map Policy
ISAM wide
Defines characteristics of each egress COS queue: - CBS, MBS, CIR, PIR System-wide definition of scheduling over egress queues: SP,WRR,..
Egress Port Queue Policy Egress Queue Slope Policy WRED
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
20-55
20 — Quality of Service Figure 20-35 QoS in IHub for base router
Network QoS Policy (applies to all network IP interfaces) Ingress: set FC based on DSCP, PREC, p-bit Egress: empty
Egress Port Rate Limiter
Application Self-Generated Traffic Policy
Network port
FCx
Base router
Egress Queue Slope Policy WRED
November 2013
IP interface
Egress Port Queue Policy FC Queue Map Policy
Defines characteristics of each [1..4] queue
20-56
Port
ISAM
ISAM wide
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
21 — Resource management and authentication
21.1 Introduction
21-2
21.2 RADIUS features
21-2
21.3 802.1x authentication via RADIUS 21.4 Operator authentication via RADIUS 21.5 Encryption of authentication data 21.6 Lawful Interception
21-2 21-3 21-3
21-3
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
21-1
21 — Resource management and authentication
21.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. The ISAM supports RADIUS authentication via base router and VPRN services.
21.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.
21.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.
21-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
21 — Resource management and authentication
21.4
Operator authentication via RADIUS CLI and TL1 operators can be authenticated either locally on each DSLAM or remotely via a central RADIUS server. In case of remote authentication via RADIUS, besides the username and password, also the terminal IP address from where the operator is initiating the Telnet session or the SSH session with the ISAM, is sent to the RADIUS server. This will allow the RADIUS server to also use the IP address of the operator during authentication. The IP address is always sent. It is up to the RADIUS server to check the IP address or not during authentication. If the operator is connected thought a CRAFT (serial) terminal there is no operator IP address hence no attribute with IP address in the Access Request is sent to the RADIUS server. There is one restriction: if CLI or TL1 over SSH with key authentication is used, 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. Note — No accounting is performed for authenticated CLI/TL1 operator sessions.
21.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.
21.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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
21-3
21 — Resource management and authentication
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 ISAM the same 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 would not be 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. 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 shall be possible to set the priority of the intercepted packets.
21-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
22 — MPLS
22.1 Introduction
22-2
22.2 Label Switched Path
22-2
22.3 Label Distribution Protocol
22-3
22.4 Resource Reservation Protocol 22.5 Pseudo-wires and T-LDP 22.6 L2 VPN services 22.7 QoS
22-5
22-6
22-7
22-9
22.8 Redundancy and resilience 22.9 Support for MPLS rings
22-9
22-10
22.10 Support for MPLS flow label
22-11
22.11 Supporting integrated voice services over MPLS
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
22-12
22-1
22 — MPLS
22.1
Introduction Multi-protocol Label Switching (MPLS) is a label switching technology that provides the ability to set up connection-oriented paths over a connectionless IP network. MPLS sets up a specific path for a sequence of packets. The packets are identified by a label inserted into each packet. MPLS is used in the ISAM as a building block to support L2 VPN services like Virtual Leased Line (VLL) and Virtual Private Lan Service (VPLS). In this case, the ISAM is acting as Label Edge Router (LER) and the distribution/reception of MPLS transport labels is based on Label Distribution Protocol (LDP). MPLS can also be used in the ISAM to support deploying an MPLS ring. In that case, the ISAM is acting as a Label Switch Router (LSR) and the distribution/reception of the MPLS transport labels is based on the Resource Reservation Protocol (RSVP-TE). In both cases, the ISAM originates and terminates pseudo-wires (PWs) to support VLL/VPLS services. The distribution/reception of service labels to identify these pseudo-wires is based on Targeted LDP (T-LDP).
22.2
Label Switched Path The MPLS traffic is originated/terminated on the uplinks of the NT/NTIO board. It needs explicit configuration to define which uplinks can be configured as supporting MPLS (that is, by setting the port mode of the link to network). The MPLS traffic can be sent tagged or untagged. This depends on the configuration of the network IP interface that is selected as the next best hop when sending the packet. For traffic arriving on an access port which needs to be sent towards the aggregation network, the system is acting as an ingress Label Edge Router (iLER). In the other direction, the system is acting as an egress Label Edge Router (eLER). In order to support deploying an MPLS ring, the Access Nodes also supports MPLS LSR functionality. This is used to switch the MPLS LSP traffic to the next node in the ring, without having to terminate MPLS connections on each node.
22-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
22 — MPLS Figure 22-1 Label switched path POP
SWAP
SWAP
PUSH
eLER
iLER LSR
LSR
Label Switched Path
DATA
LABEL DATA
LABEL DATA
LABEL DATA
DATA
As MPLS is introduced as a vehicle to support L2 VPN services, one can state that MPLS data traffic will mostly carry two labels:
• the first label is the transport label (received via LDP or statically configured) • the second label is a service demultiplexer as described in PWE3 (received via T-LDP or statically configured). Label switched paths (LSPs) are either configured statically or are setup via LDP or RSVP-TE. Transit LSPs can only be established using RSVP-TE. In other words, the ISAM cannot use LDP when acting as an LSR. For troubleshooting of LSPs, the system will respond to LSP ping messages and traceroute messages received from remote peers.
22.3
Label Distribution Protocol The Label Distribution Protocol (LDP) is used by the ISAM as an MPLS label distribution protocol. LDP is enabled on the IP interfaces defined on top of the network-facing ports (and which have been enabled to support MPLS). These IP interfaces have to be created part of the base router as described in chapter “IP routing”.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
22-3
22 — MPLS
The system has the following LDP characteristics:
• LDP can operate in either Downstream Unsolicited (DoU) mode or Downstream on Demand (DoD) mode.
• When using DoU, an LER/LSR is allowed to distribute label bindings to a peering
•
• •
• •
•
• •
•
22-4
LER/LSR (for example, ISAM) that has not explicitly requested these label bindings. Hence, the ISAM will receive all label bindings for reachable far-end IP addresses of the PE nodes. When using DoD, the ISAM will explicitly send label request messages to its directly connected peers, in order to obtain label bindings for the far-end IP addresses of PE nodes (provided that the peer is the next hop to reach the far-end IP address, and that the next hop is the IGP shortest path). The ISAM will send a label request message whenever an SDP is created. This greatly reduces the amount of label bindings that need to be stored on the ISAM.
The use of DoU or DoD mode is configurable on system level. Note that DoD is not supported for T-LDP, according to the PWE3 standards. By default the ISAM only advertises the label binding(s) for its system IP address (/32). The ISAM uses the “liberal label retention” mode, that is, the ISAM stores the bindings between a label and an FEC which are received from LERs/LSRs which are not its next hop for that FEC. The liberal label retention mode allows for quicker adaptation to routing changes. The Label Information Base (LIB) is the database where all received label bindings are stored. The ISAM uses a per-platform label space, that is, the labels that are advertised are identical on all the MPLS network links. LDP can be enabled or disabled per network interface. The LDP protocol parameters can be configured globally and can be overruled per IP interface. By default, the system IP address is used as transport address to establish the LDP TCP session. The ISAM supports dynamically signaled LSPs in combination with the following IP routing protocols: static routing, OSPF, IS-IS and RIP. In addition, MPLS LSPs can be statically configured or dynamically signaled on top of an Ethernet Link Aggregation Group (LAG). The ISAM does not require other LSRs to support “Penultimate Hop Popping”. The ISAM will NOT advertise NULL labels. The ISAM supports LDP message reception, requesting to use the explicit NULL label towards the directly attached LER. This allows the ISAM to be interoperable with peering LERs that require MPLS packet reception having an MPLS tunnel label of value 0. The ISAM supports LDP message reception, requesting to use the implicit NULL label towards the directly attached LER for the purpose of Penultimate Hop Popping (PHP). This allows the ISAM to be fully interoperable with peering LERs that require MPLS packet reception having no MPLS tunnel label.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
22 — MPLS Figure 22-2 Label distribution LDP session ISAM
LSR
LIB
RIB
LSR LDP session LDP DoU Routing protocol
• When receiving a Label Mapping message from an LSR for a Prefix or Host Address FEC Element (for example, the system IP address of another access node) the ISAM can use the label for forwarding even when its routing table (RIB) does not contain an entry that exactly matches the FEC Element. The ISAM supports so-called aggregated prefix matching, meaning that it is sufficient for the routing table to contain a longest matching prefix entry for the corresponding FEC Element. Population of the ISAM routing table (RIB) can be done manually but due to the large number of host addresses it is preferred to have a routing protocol activated (OSPF, RIP,…) on the ISAM node. The RIB is the database where all received or configured routes are stored. • When there are multiple LSPs that contain a Host Address FEC element (for example the system IP address of another access node) which is identical to the destination address of the packet, then the packet is mapped to one of those LSPs. The choice of LSP is made based on the IGP next-hop for that host address. In case there are multiple equal-cost IGP next-hops available (that is, several equal-cost tunnel LSPs that allow to reach the same Provider Edge node) then the ISAM will select one of those LSPs. This selection is performed on a per-service base in order to allow load balancing of upstream traffic
22.4
Resource Reservation Protocol RSVP-TE support is mainly introduced to allow deploying the ISAMs in an MPLS ring. It allow establishing LSPs that will be switched through the ISAM which acts as an LSR. See section “Support for MPLS rings” for the basic description. The following table summarizes the main features supported in relation to RSVP-TE
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
22-5
22 — MPLS Table 22-1 RSVP-TE main features Features
Description
RSVP-TE base protocol
Base RSVP-TE protocol support
RSVP-TE parameters
• • • •
RSVP-TE LSP without Constrained-based Shortest Path First (CSPF)
The LSP is setup using the best path as advertised with a routing protocol (for example, OSPF or IS-IS)
RSVP-TE LSP with Constrained-based Shortest Path First (CSPF)
Traffic engineering and LSP CSPF constraints can be used to control the LSP setup
RSVP-TE Primary and secondary
The LSP can be setup using path constraints (for example, hop-limit)
RSVP-TE reservation styles Message pacing Refresh reduction Refresh time
Parameter support for primary and secondary paths RSVP-TE BFD
BFD support for RSVP interface to speed up failure detection
RSVP Authentication
Protects against spoofed RSVP-TE packets
Note — The RSVP-TE, the MPLS Fast Reroute (FRR) and the MPLS LSR functionality can also be applied to non-ring networks. However, the ISAM currently only supports one-to-one backup tunnels (that is, detour LSPs). This means that in large networks, the number of LSPs may become large. Care should be taken to keep the total number of LSPs under control.
22.5
Pseudo-wires and T-LDP By using PWs the ISAM offers an emulated L2 service over an MPLS tunnel, that is, it acts as a Provider Edge (PE) device or a Multi-Tenant Unit Switch (MTU-s) (RFC4762) offering Pseudo Wire Emulation Edge to Edge (PWE3) services. The ISAM supports both spoke PW and hub PW. The ISAM uses T-LDP by default to set up PWs (although static provisioning of service labels is also supported).
22-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
22 — MPLS Figure 22-3 T-LDP and PW PE/MTU-s T-LDP session (exchange service labels)
DATA LT1
PE
LSR AC1
LDP session
LDP session
AC2 AC3
DATA LTn
DATA
ISAM
Service 1 Service 2
DATA
LABEL LABEL DATA
LABEL LABEL DATA
DATA
DATA
LABEL LABEL DATA
LABEL LABEL DATA
DATA
Second label identifying service
The T-LDP session is set up between the ISAM (using the configured system IP address) and each configured far-end IP address that terminates service tunnels. To define which LSP is used for a particular service tunnel, the ISAM uses the concept of Service Delivery Points (SDPs). An SDP identifies the IP address of the end of the tunnel and the LSP to reach that endpoint. The LSP can be either static or dynamic (when LDP is enabled on it). An SDP binding is created by associating a service instance (VLL, VPLS) with an SDP (this is in fact nothing else than a pseudo-wire. When using T-LDP, the ISAM has the following T-LDP characteristics:
• • • •
FEC128 is used for reception and distribution of service labels the configured VC-TYPE of the SDP binding is passed: ether or VLAN indication of whether a control word will be used indication of the maximum MTU size (which is configurable per service)
For troubleshooting of a PW, the system will react on Virtual Channel Connectivity Verification (VCCV) messages. The ISAM supports two types of pseudo-wires: mesh or spoke. A spoke is used for H-VPLS or to connect an ISAM in a redundant manner.
22.6
L2 VPN services The MPLS service configuration on the IHUB system can be summarized in next steps: 1
Creation of a service instance (VLL or a VPLS)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
22-7
22 — MPLS
2
Creation of SAPs within the service instance: SAPs represent user traffic entering the NT board from a connected LT board/user port. A SAP is identified via an LT board/user port number and an encapsulation value.
3
Creation of an SDP binding within the service instance The SDP binding represents a PW and is created by associating the service with an SDP. Figure 22-4 LT-NT mapping DSL
LT VLAN cross-connect (Tunnel)
NT Tunnel VLAN
PW 1
VLL1
LSP 1
SDP 1
DSL VLAN cross-connect (Mapped)
iBridge
Mapped VLAN
VLL2
VLAN B
VPLS1
VLAN B iBridge
PW 2 SDP 2
PW 3
LSP 2
SDP 3 VPLS2
PW 4 LSP 3 PW 5
SAP SDP binding
VLL Tunneling approach The LT board unconditionally adds a “tunnel VLAN” when sending traffic to the NT board. The pair is used to determine the VLL instance in the NT board. Before encapsulating the L2 frame in the associated PW, the tunnel VLAN can be removed by configuring the PW of type ether. This mechanism achieves full transparency of customer traffic. Specifically, it supports receiving dual-tagged frames and sending them on a VLL towards the aggregation network.
VLL Mapping approach The LT board maintains the VLAN(s) in the frames received from a customer. The pair is used to determine the VLL instance in the NT board. Before encapsulating the L2 frame in the associated PW, the outer VLAN can be removed by configuring the PW of type ether.
22-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
22 — MPLS
VPLS iBridge approach The LT multiplexes incoming untagged traffic or single-tagged traffic of several residential subscribers in an (enhanced) iBridge instance. At the user-side, frames may arrive untagged or priority tagged, in which case a Port-default-VLAN (PVID) selection or a protocol-based VLAN selection is used to select the appropriate iBridge. Frames are sent to the NT board using a single VLAN tag. This VLAN ID is used to map traffic to the corresponding VPLS instance on the NT board. Before encapsulating the L2 frame in the associated PW, the outer VLAN can be removed by configuring the PW of type ether.
22.7
QoS QoS details can be found in chapter “Quality of Service”. In a nutshell, two types of PW-related policies can be configured:
• Service egress network policy: allows to define the setting of the EXP and the outer p-bits based on the forwarding class • Service ingress network policy: allows to derive the forwarding class from the EXP or the inner p-bit. These policies are associated with a VLL instance or a VPLS instance. In addition to offering QoS to LSPs that are initiated or terminated, the ISAM can provide QoS to transit LSPs (when the ISAM acts as an LSR). To do this, separate policies have to be configured that map the traffic with a specific MPLS exp-bit value to a given Traffic Class and provide the appropriate QoS. Before sending the traffic to the egress interface, a Traffic Class to MPLS exp-bit mapping is performed, using a fixed mapping table. This two-step process allows remarking the MPLS exp-bit values of transit LSPs.
22.8
Redundancy and resilience The ISAM supports ECMP for IP (non-MPLS) routed packets. In case there are multiple equal-cost paths to the same peer PE, that is, there are multiple equal-cost LSPs to reach the PE, a single LSP will be selected out of that set for sending MPLS traffic. This selection is done per SDP binding, that is, per PW. In this way, traffic from different services sent on different PWs can still be sent over different LSPs towards the PE. This enables service-based load balancing of upstream traffic.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
22-9
22 — MPLS
The following failures can be protected:
• Failure of an Access Node uplink: this is achieved by relying on MPLS protection using active/standby LSPs and the use of MPLS Fast Reroute (when the ISAM acts as an LSR). • Failure of the Aggregation Node connected to the Access Node: this is also achieved by relying on MPLS protection using active/standby LSPs. • Failure of a PE node that terminates the PWs that are initiated on the Access Node. This can be covered by means of active/standby PWs in a VPLS configuration. When the primary peer PE fails, packets will be sent to the secondary peer PE using the standby PW. The current system allows MPLS support in a duplex configuration, that is, with two NT boards. This is supported in combination with static routing or dynamic routing via OSPF. Control traffic (that is, LDP), L2 VPN data traffic and IP traffic can be received/transmitted on the links of both NT boards.
22.9
Support for MPLS rings Traditionally, rings have been used in order to protect against a link or node failure, by allowing traffic to use the other half of the ring as a backup path. This approach has been used for a long time, using a variety of different technologies (for example, SDH/SONET, Ethernet Spanning Tree / Multiple Spanning Tree). Rings of Ethernet Access Nodes could use RSTP / MSTP in order to recover from a link or node failure. Unfortunately the xSTP algorithm is not designed for ring networks and will give a poor switchover performance due to slow re-convergence. To overcome this limitation, MPLS can be used to establish connections over the ring of Access Nodes. By using RSVP-TE, an operator can pre-provision one or more backup paths, the so-called “detour LSPs”, that provide protection in case of a failure. Next, whenever an Access Node detects a local failure, it can use MPLS Fast-ReRoute (MPLS FRR) to send traffic over the detour LSPs. This provides a very fast local failure detection process, much faster than with xSTP. The basic principle is shown in Figure 22-5.
22-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
22 — MPLS Figure 22-5 MPLS switchover principles
eLER
eLER
iLER
iLER
Optimized path Local switchover Step 1: wrapping
Step 2: Make-Before-Break (MBB)
- Using detour LSPs to guide traffic around the link failure
- Re-optimize path to avoid traffic loops
- Very fast, local protection
- Improves bandwidth usage and QoS
In Step 1, Fast ReRoute is used to recover from the failure. Once this has been done, the node that detected the failure will inform the ingress LER (usually by means of RSVP-TE Path Error messages). This is the trigger for the ingress LER to calculate a new optimal path and reconfigure the network to use a different LSP. This process is called “Make-Before-Break”, referring to the principle of first establishing the new path and afterwards performing the switchover to this path. By doing so, the outage in the second step can be minimized or even completely avoided.
22.10
Support for MPLS flow label In some cases an operator wants to have the flexibility to identify different sub-flows within one Ethernet Pseudo Wire. This is possible by means of an “MPLS Flow Label”, as defined in IETF draft-ietf-pwe3-fat-pw. The MPLS Flow Label (also referred to as “Hash Label” or “Entropy Label”) allows LSR nodes in a network to load balance labeled packets in a more granular fashion than would otherwise be possible by only hashing on the standard label stack. Instead, by taking the MPLS Flow Label into account in the hashing algorithm, load balancing within a Pseudowire becomes possible. This also removes the need to have an LSR inspect the payload below the label stack to check for an IPv4 or IPv6 header. The ISAM can insert an MPLS Flow at the bottom of the label stack in packets forwarded over an LSP. The value of the label is the result of the hashing of the packet headers. The ISAM hashing routine assigns the same label to all packets within the same conversation. This ensures that when an LSR load balances the packets over multiple ECMP paths or multiple paths over a LAG network, packet ordering is kept within a conversation. The MPLS flow label insertion/removal can be configured per SDP binding. To support insertion / removal of the MPLS flow label, the NANT-D CB NT board variant is required.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
22-11
22 — MPLS
In addition to the NANT-D CB board variant, flow label insertion/removal is also supported on the NCNC-H. This NTIO board can be freely combined with any of the existing NANT-D or NANT-E NT boards.
22.11
Supporting integrated voice services over MPLS The ISAM Voice (ISAM-V) allows the conversion of a legacy voice service (for example, POTS) into a VoIP service (H.248 or SIP-based), thereby moving to an integrated packet-based network. In current deployment scenarios, the ISAM-V connects to the packet-based aggregation network by means of an Ethernet interface. When migrating to an MPLS-based access network, operators need to be able to support legacy voice services over the same MPLS-based access network. This can be done by:
• Subtending: The ISAM-V shelf is subtended to a hub ISAM which operates as an MPLS LER. The ISAM-V continues to operate as in the present non-MPLS network, while the hub ISAM performs the necessary interworking to send the ISAM-V traffic onto an MPLS pseudowire. • Adding ISAM-V cards into an MPLS-enabled ISAM by using:
• SIP Distributed IP addressing model •
•
Each voice LT board is assigned a different IP address. The Network Termination board simply bridges the signaling and RTP traffic via a VPLS service. SIP Centralized IP addressing model All voice LT boards share the same IP address for RTP and/or for signaling traffic. The Network Termination board performs L3/L4 routing using a Virtual Router (VRF). This VRF is connected to a “VLAN VPLS” (V-VPLS) service instance, which in turn connects to a full VPLS service instance to encapsulate the traffic into an MPLS pseudowire. H.248 model All voice LT boards share the same IP address for RTP and/or internal signaling (XLES) traffic. The Network Termination board performs L3/L4 routing using a Virtual Router (VRF). This VRF is connected to a V-VPLS service and a VPLS service. Additionally, when sending traffic to/from the NVPS card, the same V-VPLS and VPLS service instances are used to bridge the (internal) signaling and the RTP traffic from the NVPS card onto the MPLS pseudowire.
It is possible to provide a combination of the above models when needed for a specific deployment. In order to achieve the last configuration (that is, supporting a VRF on top of a V-VPLS (doing L3 forwarding), which in turn is connected to a VPLS (doing the MPLS encapsulation/decapsulation)), the operator needs to associate the V-VPLS and the VPLS to the same physical port using SAPs with different encapsulation values. The port itself must be placed in loopback, so that packets are sent from the V-VPLS SAP to the VPLS SAP and vice versa.
22-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
22 — MPLS
The port chosen to be placed in loopback can be any of the faceplate ports of either the NT or the NTIO board. As a consequence, this port can no longer be used for external network connectivity. Note — When using a faceplate port on an NTIO, the loopback configuration can be performed, even when this NTIO is not physically equipped in the system (but only “planned” in the system configuration).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
22-13
22 — MPLS
22-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
23 — ATM Pseudowire emulation
23.1 Introduction
23-2
23.2 Solution description 23.3 Cell concatenation 23.4 QoS
23-2 23-3
23-4
23.5 Known restrictions 23.6 Support on the ISAM
23-4 23-4
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
23-1
23 — ATM Pseudowire emulation
23.1
Introduction When migrating from an ATM-based access network to an Ethernet packet-based access network, operators are faced with the challenge to maintain their existing ATM-based services. Many ATM services are based on AAL5 encapsulation (that is, these services are packet-based) and are rather straightforward to migrate by terminating the AAL5 layer in an Ethernet Access Node. However, also non-AAL5-based ATM services are commonly used, in which case this is not possible. Moreover, an operator offering wholesale services to 3rd party service providers has no view on the legacy ATM services that are used by the wholesaler. The ISAM supports ATM Pseudowire (ATM PWE3) technology on a number of ADSL2+ and SHDSL LT boards. This enables the transport of legacy ATM services over a packet-based access network.
23.2
Solution description The ATM Pseudowire network architecture is shown in Figure 23-1. Figure 23-1 ATM Pseudowire network architecture Protocol stack ATM
VLAN or S-VLAN
PWE3 MPLS
IP DSLAM
ATM PVC
PWE3 in N:1 mode with N > 1
8/35 80/32
Residential
Pseudowire
VLAN
Aggregation Network
8/35 80/33 8/35
80/32 80/33 80/34
OLO with shared bandwidth
80/34 8/35
90/32
9/40
90/33
8/35
VLAN A
90/32 90/33 90/34
90/34 92/32 92/33
92/32 OLO with dedicated bandwidth/business
PWE3 GW
8/35 8/36
92/33
8/35
93/33
8/35
94/33
93/33 94/33
PWE3 in N:1 mode with N = 1
The “ATM Pseudowire” feature is based on IETF RFC 4717, and is also referred to as ATM Pseudowire Emulation Edge to Edge (ATM PWE3). In this mode, the ISAM can receive upstream ATM traffic from DSL subscribers and encapsulate this traffic into one or more ATM Pseudowires sent over an MPLS tunnel towards the aggregation network. On the other side of the network, a Pseudowire Gateway (for example, the Alcatel-Lucent 7750) terminates the ATM Pseudowires from several ISAMs and aggregates the traffic on one or more STM-1 interfaces connected to the ATM core network.
23-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
23 — ATM Pseudowire emulation
In downstream direction, the PWE3 Gateway encapsulates the received ATM traffic into the corresponding ATM Pseudowires, and sends them in MPLS tunnels towards the different ISAMs. The ISAM terminates the MPLS tunnels and ATM Pseudowires, extracts the ATM cells and sends them on the correct DSL line. The feature co-exists with the standard ISAM L2 forwarding behavior, that is, on the same ISAM LT board some user ports can be configured as regular Ethernet / AAL5 lines while other user ports can be configured for ATM Pseudowire handling. Each ATM Pseudowire can be configured to either carry traffic from a single ATM PVC or from multiple ATM PVCs:
• “N-to-One mode, with N=1”: the ATM Pseudowire only carries traffic from a single ATM PVC. Each ATM Pseudowire packet either contains a single ATM cell, or multiple ATM cells all using the same VPI/VCI • “N-to-One mode, with N>1”: the ATM Pseudowire carries traffic from multiple ATM PVCs. Each ATM Pseudowire packet either contains a single ATM cell, or multiple ATM cells using the same or different VPI/VCIs In order to establish the MPLS tunnels and ATM Pseudowires, the ISAM supports the necessary commands to configure the connections. It should be noted that the ATM Pseudowire functionality is supported on the DSL LT board, with no intervention of the NT card. As a result of this, each DSL LT board which offers ATM Pseudowire services will have to be configured with one or more separate IP interfaces and MPLS tunnels. This increases the total number of MPLS tunnels at the system level. For instance, if each DSL LT board would be configured with one MPLS tunnel, then there will be 16 MPLS tunnels at system level.
23.3
Cell concatenation In case each ATM cell is encapsulated in a separate ATM Pseudowire packet, the additional overhead of the MPLS header can become very high, making the solution less bandwidth efficient. To avoid this, it is possible to group multiple ATM cells into a single ATM Pseudowire packet. This “cell concatenation” feature reduces the encapsulation overhead, making the solution more bandwidth efficient. The maximum number of ATM cells that may be concatenated into a single ATM Pseudowire packet can be configured. Up to eight cells can be concatenated. Configuring a high value of cell concatenation could result in putting an additional transmission delay on the ATM cells, since the ATM Pseudowire packet would only be sent out once the ATM Pseudowire packet has been filled up to its maximum number of concatenated cells. To avoid excessive transmission delays, the maximum additional transmission delay that may be put on the ATM cells can be configured. When the configured transmission delay is reached, the ATM Pseudowire packet will be sent out, regardless of whether or not it contains the maximum number of concatenated cells.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
23-3
23 — ATM Pseudowire emulation
23.4
QoS The QoS implementation is based on the regular DSL LT QoS framework. All QoS features are packet-based, not ATM cell-based. QoS is based on the use of the Ethernet priority bits and the MPLS Exp bits. This means there is no ATM QoS, no cell-based QoS, and no F4/F5 termination. Different service types can be defined which are identified with different Ethernet p-bits or MPLS Exp bits. This allows mixing Residential/shared bandwidth and Business/dedicated bandwidth services over the ATM Pseudowires. When mapping ATM cells into an ATM Pseudowire packet, the ISAM supports setting the p-bits and MPLS Exp bits of those packets according to a two-rate Three Color Marker. Policing can be done on a combination of the Committed Information Rate (CIR) and the Excess Information Rate (EIR). In downstream direction, color-aware RED can be applied to the different queues, in order to discard traffic with a relative lower priority.
23.5
Known restrictions The MPLS control plane is not supported. In other words, MPLS tunnel and ATM Pseudowire configuration needs to be provisioned rather than signaled. Note — Please consult the Customer Release Notes for additional details concerning the restrictions of the ATM Pseudowire Emulation implementation.
23.6
Support on the ISAM The ISAM supports configuring ATM Pseudowires (ATM PWE3) in combination with the NANT-D Network Termination board. Note that the ATM Pseudowire functionality is independent of the MPLS functionality supported on IHub-based NT boards. In other words, it is perfectly possible to configure the ATM Pseudowire functionality on the DSL LT boards, and continue to use Ethernet switching on the NT board.
23-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
24 — Application Intelligence Platform
24.1 Introduction
24-2
24.2 Solution description 24.3 Benefits
24-2
24-4
24.4 Support in ISAM
24-4
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
24-1
24 — Application Intelligence Platform
24.1
Introduction The ISAM high-capacity NT cards (NANT-E and FANT-F) introduce the ISAM Application Intelligence Platform (AI Platform), as a generic capability for hosting applications in the ISAM. The AI Platform enables the ISAM base node functionality to be enhanced with future, generic or customer specific application level functionalities. Target fields for enhanced application level functionality in ISAM may exploit the location and unique knowledge and control of the access node for such value-add features as active and passive traffic/triple play QoE monitoring, service assurance, troubleshooting agents, management and provisioning helper agents, support for optimized content delivery (for example, live video delivery over http), virtualization of home network functions, and so on. Dedicated applications on the ISAM AI Platform may be developed by Alcatel-Lucent or by Alcatel-Lucent customers and/or third parties, in cooperation with Alcatel-Lucent. For any proposals on porting application level functionality on the ISAM AI Platform, please contact your local Alcatel-Lucent sales representative.
24.2
Solution description The ISAM AI Platform leverages the NANT-E/FANT-F NT hardware. Specifically, NANT-E and FANT-F feature dedicated processing resources, reserved for applications: dedicated CPU cores, as well as dedicated partitions in DRAM and flash memories, and dedicated full duplex 10Gbps interface bandwidth into the central IHub switch (Figure 24-1). Figure 24-1 AI platform hardware resources NT on-board processor Flash
ISAM SW
ISAM SW
core0
core1
RAM
AI platform & Apps Linux OS core2
core3
Packet dispatcher core0/core1 interfaces
10Gbps to core2 and 3 IHub Network
NANT-E/FANT-F NT board
LTs
24-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
24 — Application Intelligence Platform
The AI Platform can be enabled on a live ISAM node. It provides a management framework for downloading and installing applications on the AI Platform, networking them to the ISAM forwarder(s) and starting/stopping them, all under ISAM operator control. The AI Platform also provides facilities for health monitoring, alarms and system recovery. Optionally, applications may be managed and provisioned through their own MIB, reachable through the ISAM public management IP address, using a separate SNMP community string/context identifier, or by application-specific CLI extensions through a Telnet into the AI Platform from the ISAM CLI prompt. Applications may be supported in AMS through dedicated AMS plug-ins. Alternatively, the model where application management and provisioning is decoupled from the ISAM/AMS management framework, is also fully supported. The AI Platform offers an SMP linux OS to applications. Applications on the AI Platform can exchange packets with subscriber and network sides through the ISAM forwarders. Applications can also be defined as the target of an IHub port mirror. In addition, applications can retrieve and/or control ISAM state through the SNMP protocol. The concept and design of the ISAM AI Platform is such that applications running on the AI platform will not impact the operation of the base node in terms of stability and performance. This is enabled by virtue of dedicated processing resources for applications, isolated from the ISAM core forwarding and control functions, as well as by careful design and testing of the interfaces between applications and the core ISAM. In this way, the AI Platform enables the life cycle of applications to be fully decoupled from the release cycle of the ISAM base software, meaning that applications can be updated without a dependency to the ISAM base release. Applications will be made available as separately downloadable executables, with an independent life cycle (see Figure 24-2).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
24-3
24 — Application Intelligence Platform Figure 24-2 ISAM Applications life cycle management AI Platform Software on core0&1 • Manage AI platform • Download&install applications on AI platform • Enable external communication • (optional) Application Management relay (SNMP/CLI)
AI Platform Software on core2&3 • Start/stop/restart application instances • Bind network interface to application instances • (optional) Application Management (SNMP/CLI)
ISAM Rx.y Application Utilities
AI platform
Application_1 subject to licensing
ISAM Application_n
ISAM Applications (individually downloadable executables) = versioned
24.3
Benefits Benefits of the ISAM AI Platform include:
• Enabling applications to make use of the location and unique knowledge and control of the access node.
• Leveraging cost-effective and industrially rated hardware, as well as centralized platform management, for hosting applications. • Dedicated hardware resources and carefully controlled interfaces between applications and the core ISAM, ensuring stability and security of the core ISAM functions. • Base system control over hosted applications, such as application download and install, start and stop, access to ISAM forwarders, health monitoring and recovery. • Application life cycle management, fully decoupled from the ISAM base release, enabling agile fast-track application development and shorter life-cycles for applications.
24.4
Support in ISAM The ISAM AI Platform is supported on NANT-E and FANT-F NT boards equipped with 4 GB of compact flash. The ISAM AI Platform is supported in combination with any access flavor (xDSL, PTP, GPON, EPON) and any ISAM LT.
24-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A.
Cross-domain solutions
A.1 Overview
A-2
A.2 Mobile backhaul
A-3
A.3 E1/T1 Leased Line Replacement (SHDSL/PON) A.4 E1/PRA Interfaces on ISAM
A-11
A-15
A.5 Ethernet Business Access over ISAM
A-21
A.6 ISAM Backhaul (Rural DSL, Ultra-high Broadband) A.7 Hospitality solution
A-27
A-33
A.8 Open Community Broadband for Smart Communities
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-39
A-1
A. Cross-domain solutions
A.1
Overview This section provides a description of various applications for which the ISAM provides an effective solution.
Mobile Backhaul Fixed 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 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, EPON and point-to-point fibre access technologies.
E1/T1 Leased Line Replacement Legacy 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.
Ethernet Business Access Access and service providers are migrating the delivery of business access services, originally dominated by TDM and ATM-based offerings, to Ethernet access. This migration is driven mainly to achieve converged access and aggregation networks, thereby reducing CAPEX and OPEX. In a fully converged access network, we expect residential-, business- and mobile backhaul customers to be served from the same access node. The ISAM, in conjunction with a portfolio of CPEs/NTU/ONTs is equipped with best-in-class features to fulfill the requirements for Ethernet business access services, and this over a choice of copper and fiber access technologies.
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 is 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 solutions can be proposed.
Hospitality solution To 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. A-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
Open Community Broadband for Smart Communities The 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
Scope This section describes solutions for backhaul of 2G/3G and LTE mobile base stations over 7302 ISAM, 7330 ISAM FTTN or 7360 ISAM FX. Mobile backhaul over (bonded) ADSL2+, over (bonded) SHDSL, over (bonded) VDSL2, over point-to-point Ethernet (FE/GE) and over GPON and over EPON is included, covering solutions for data off-load as well as full backhaul of voice and data. Apart from the 7302 ISAM, 7330 ISAM FTTN or 7360 ISAM FX node, the solution also proposes the cell site devices (residential DSL CPE/ONT, dedicated DSL CPE/ONT 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 Alcatel-Lucent Mobile Backhaul Blueprint Solutions for a description of Alcatel-Lucent end-to-end mobile backhaul solutions.
Introduction Mobile 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-3
A. Cross-domain solutions
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 re-use existing outside plant (copper, GPON and EPON 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 challenges The 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. For example, 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
A-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
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, for example, ~ 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 (*). Note —
(*): See section “QoS and High Availability for mission critical traffic” for distinction between data off-load and full backhaul.
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. 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 pseudo wire 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 (that is, 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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-5
A. Cross-domain solutions
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 network These synchronization methods classify in 2 flavours:
• Physical layer mechanisms
•
These 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 mechanisms These 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. For instance, 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 to terminate 1588v2 in an external client in the CO, to feed the output of that client into the BITS of the ISAM and to go with physical layer synchronization from there. Access node features:
• NT with BITS/SyncE/1588v2 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.
A-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
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 xSTP) and the first aggregation node (with multi-chassis LAG or xSTP). For PON access, ISAM provides enhanced Type-B protection shortly in a future release. DSL bonding inherently provides a level of resiliency for a first mile over bonded DSL. Figure A-1 High availability: points of failure ISAM dual uplinks with LAG, multi-chassis LAG, mSTP
ISAM NT redundancy TDM ATM ETH
AGG CSG
Base station
AN
GTW L2 aggregation
AGG
GTW Controller
inherent redundancy in DSL bonding
IP/MPLS or Carrier Ethernet repair mechanisms
Access node features:
• • • •
QoS (as for triple play) NT redundancy dual homed ISAM uplinks (with LAG, multi-chassis LAG or xSTP) transparent for IP/MPLS based redundancy (handled in the cell site gateway and/or in the IP/MPLS core) • enhanced Type-B protection (future release) • inherent redundancy in DSL bonding (for ATM IMA and EFM).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-7
A. Cross-domain solutions
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 description Figure 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 ADSL2+ CPE (o) 1-2p ADSL2+ 3 rd party SHDSL CPE 1-4p SHDSL 1-4p SHDSL + 1-2p xDSL SAR-M combo
CellPipe 5Ve.A4010 (o)
2p VDSL2 7302/7330 ISAM
2-8p VDSL2 or 2p ADSL2+ SAR-M xDSL point-to-point Ethernet (FE|GE)
(o) offload only
SAR-M/SAR-F Data ONT (o) GPON SAR-M GPON Business ONT
Low-end residential type DSL CPEs/ONTs (ADSL2+, 7130 Cellpipe VDSL2), indoor/outdoor ONT 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. The Business ONT is a mid-range solution for off-load and full backhaul of TDM and Ethernet services over GPON. The Business ONT is MEF8 pseudowire based. 7705 SAR-F (fiber uplink) and 7705 SAR-M (with modular uplink of fiber), GPON, 2-8pair bonded VDSL2, 4-pair bonded SHDSL + 2-pair bonded ADSL2+ (SAR-M 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.
A-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
Figure A-3 shows the logical end-to-end topologies for mobile backhaul between multiple mobile base stations and a centralized mobile controller. Figure A-3 Mobile backhaul end-to-end-topologies (logical) IP/MPLS TDM ATM ETH
CSG
AN
AGG
L2 tunnel (IP/MPLS) GTW
Base station
TDM ATM ETH
Controller PWE3 IP/MPLS pseudowire (TDM/ATM/ETH)
Mixed
TDM ETH
CSG
AN
AGG
L2 tunnel (IP/MPLS) GTW
Base station
TDM ETH
Controller MEF8 PW (TDM) + raw Ethernet
Carrier Eth
TDM ETH
CSG
AN
AGG
Carrier Ethernet
Base station
GTW
TDM ETH
Controller MEF8 PW (TDM) + raw Ethernet
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 pseudo wire level and interfacing to the mobile controller(s) over TDM STM-x, ATM STM-x or Ethernet interfaces. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-9
A. Cross-domain solutions
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. Figure A-4 and Figure A-5 show the physical layer synchronization architecture of ISAM. Figure A-4 ISAM physical layer synchronization architecture (DSL and point-to-point)
SHDSL.bis PHY NTR
BITS G.703
FE/GE (SAR-M) FE/GE unsynchronized rd 7705 SAR-M (3 party CPE)
SHDSL LT
GigE SyncE
3rd party CPE
VDSL2 PHY NTR
E1 FE/GE
VDSL2 LT
7705 SAR-M Optical GE SyncE
E1
Base station interface
NT
E1
FE/GE PTP GE LT 8 kHz backplane
7705 SAR-M Optical GE SyncE to 7354 REM
Optical GE SyncE direct connection to base station
7302/7330 ISAM
Figure A-5 ISAM physical layer synchronization architecture (GPON)
BITS G.703 GigE SyncE
LT
E1
GPON ODN Business ONT
8 kHz backplane E1
7302/7330 ISAM FE/GE 7705 SAR-M
Base station interface
NT
FE/GE unsynchronized
Physical layer synchronization can be fed into ISAM either via BITS or via SyncE from the network through synchronization-capable dedicated NT variants. If no BITS or SyncE is available in the CO, we recommend to terminate 1588v2 in an external client in the CO, to feed the output of that client into the BITS of the ISAM and to go with physical layer synchronization from there. Synchronization can then be propagated over the first mile to a synchronization-capable cell site gateway through a physical layer mechanism: SHDSL NTR, VDSL2 NTR, GPON PHY or SyncE (GE point-to-point LT board). Finally, the cell site gateway provides synchronization to the base station either through a synchronized E1 or through a SyncE interface.
A-10
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
The physical layer synchronization entails frequency synchronization only. Apart from physical layer synchronization, the Business ONT also provides ACR and DCR clock recovery mechanisms.
A.3
E1/T1 Leased Line Replacement (SHDSL/PON)
Scope This 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). • over GPON, using the Business ONT (up to four E1/T1 interfaces) In principle, E1/T1 leased lines can also be emulated over point-to-point ethernet access, with a dedicated fibre CPE.
Introduction Operators 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, for example, decommission dedicated line systems for (E1/T1) leased line access. It may also be an element in an ongoing decommissioning (partial or full) of the legacy TDM network in favour of a packet switched network.
Technical Challenges
Leased line emulation
TDM pseudo wire 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 pseudo wire 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, Business ONT) and a peer device (either a peer CPE or Business ONT on another customer site or a centralized device interfacing to the core TDM network, usually over STM1/STM4).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-11
A. Cross-domain solutions
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 pseudo wire, 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, and so is GPON. 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 (that is, 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. For instance, 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 the CO, we recommend to terminate 1588v2 in an external client in the CO, to feed the output of that client into the BITS of the ISAM and to go with physical layer synchronization from there. Access node features:
• NT with BITS/SyncE/1588v2 in • SHDSL NTR/GPON PHY on the last mile. A-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
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 xSTP) and the first aggregation node (with multi-chassis LAG or xSTP). For PON access, ISAM provides enhanced Type-B protection shortly in a future release. 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 xSTP), transparent for IP/MPLS based redundancy (handled in business CPE)
• enhanced Type-B protection (future release) • inherent redundancy in DSL bonding (ATM IMA and EFM). Solution description Figure A-6 shows the access components for a leased line replacement solution over (bonded) SHDSL and GPON. Figure A-6 Access components for E1/T1 leased line replacement 3 rd party SHDSL CPE 1-4p shdsl
1-4 * E1/T1 (+ Eth)
GPON
4* E1/T1 (+Eth)
7302/7330 ISAM Business ONT
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 pseudo wire encapsulation is IP/MPLS with static MPLS labels. SAToP and CESoPSN encapsulations are supported. The Business ONT provides circuit emulation for up to 4 E1/T1 (possibly in conjunction with Ethernet access) over GPON. The pseudo wire encapsulation is MEF-8. SAToP and CESoPSN encapsulations are supported. Figure A-7 shows the logical end-to-end topologies for leased line emulation between 2 business customer sites.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-13
A. Cross-domain solutions Figure A-7 End-to-end topologies for E1/T1 leased line emulation TDM pseudowire (MEF-8 or IP/MPLS)
E1
CPE/ ONT
AN
Aggregation (ETH, IP/MPLS)
AN
CPE/ ONT
Customer TDM equipment
E1
Customer TDM equipment
TDM pseudowire (MEF-8 or IP/MPLS)
E1
CPE/ ONT
AN
Customer TDM equipment
Aggregation(*) (ETH, IP/MPLS)
CES GTW
SDH ADM
E1
Customer TDM equipment
(*): optionally, AN could also directly connect to CES GTW in CO
Two connectivity models can be envisaged and will possibly be deployed in parallel:
• A business CPE/ONT connected back-to-back over an end-to-end pseudo wire to a peer business CPE/ONT, without crossing an SDH/PDH segment. • A business CPE/ONT connected over a pseudowire to a core SDH/PDH network (typically groomed over an STM1/STM4 interface). The pseudo wire could cover the access segment only (with the pseudo wire 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). The solution components are:
• A business CPE/ONT that performs media adaptation to the access technology (SHDSL, GPON) 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 section “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.
A-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
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 Alcatel-Lucent 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. If no BITS or SyncE is available in the CO, we recommend to terminate 1588v2 in an external client in the CO, to feed the output of that client into the BITS of the ISAM and to go with physical layer synchronization from there. Synchronization can then be propagated over the first mile to the business CPE/ONT over SHDSL NTR/GPON. Finally, the business CPE/ONT provides a synchronized E1/T1 to the customer TDM equipment.
A.4
E1/PRA Interfaces on ISAM
Scope This chapter describes the ISAM capabilities to terminate E1 TDM lines or ISDN PRA (PRI) on an ISAM faceplate port. A similar approach is taken as in the previous section “E1/T1 Leased Line Replacement (SHDSL/PON)”but with this difference that we are not using a CPE or ONT to terminate the E1 but an SFP (Small Form-factor Pluggable) instead. The E1 or the ISDN PRA is directly terminated on the ISAM. The ISAM can be in a central office location or in a remote outdoor cabinet. The E1 TDM SFP is terminating the TDM circuits and carrying the TDM data via Ethernet packets through the ISAM and across a packet switched network (i.e. using pseudowire technology). We are NOT referring to Trunking Gateway functionality where PSTN data is converted into VoIP.
Introduction The SFP (SmartSFP) used in this solution is a dual-channel TDM SFP, capable of terminating up to two E1 ports. The SFP is MSA compliant and fits into a standard Gigabit Ethernet SFP cage.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-15
A. Cross-domain solutions Figure A-8 Dual-Channel TDM Pseudowire SFP
E1 SFP cage VLAN ECID
PAYLOAD
CES CES
E1
VLAN ECID
RJ45 shielded connector
PAYLOAD
GE
Via its build-in TDM pseudowire interworking function (CES), the SFP is encapsulating/extracting TDM traffic into/from Ethernet packets. The Metro Ethernet Forum standard (MEF-8) payload format and pseudo-wire (PW) technology is used to allow interoperability with third-party CES interworking devices. Figure A-9 E1/PRA Termination (pseudowire) in ISAM: MEF8 interworking
Using an SFP-based approach provides a flexible and scalable solution for legacy interfaces on the ISAM. No dedicated board is required, it is a port-based solution: any GE SFP port can be converted in an E1/PRA port by plugging in the E1 TDM PW SFP. Fully integrated in the ISAM management system, the E1 TDM PW SFP can be provisioned and monitored via ISAM TL1 and through the 5520 AMS.
A-16
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
Technical characteristics
Line termination
The E1 TDM PW SFP is a dual-channel SFP capable of terminating two independent tributaries. Each tributary has its own pseudowire to transport its TDM data across the packet switched network. The connector type of the SFP is a shielded RJ45 connector which is standard pin compliant for a single E1. If two E1 needs to be terminated on the RJ45 connector a dedicated Y-split cable is required to terminate the 2nd E1. The E1 line impedance can be configured to 75Ω or 120Ω. An unbalanced (Coax) or balanced (RJ45) cable is provided according the requested line/impedance type. The TDM line interface supports both framed (LOF and CRC4 checks only) and unframed E1. Depending on the distance requirement the receiver sensitivity can be configured for Short Haul or Long Haul applications. Pseudowire capabilities
As shown in Figure A-8, a pseudowire is applied per tributary. The pseudowire is constructed according to the implementation agreement for the emulation of PDH circuits over Metro Ethernet Networks (MEF8). Although the line interface framer supports both framed and unframed lines, the pseudowire encapsulation is structure-agnostic. The TDM payload is backhauled transparently via the pseudowire over the packet switched network. Due to the structure-agnostic emulation only, DS0 grooming or fractional E1 backhaul is not supported. The tributary pseudowire will be uniquely identified via its circuit-identifier in compliance with MEF8. Dedicated VLAN, CoS priority, source and destination MAC addresses can be configured per pseudowire (per tributary) if required. Synchronization
To meet the TDM wander requirements (per ITU-T G.823), both ends of the pseudowire connection need to be synchronized. Different options exist to provide an end-to-end solution to synchronize the interconnected circuits (E1/PRA). The solution requires a PRC-traceable network clock to be provided to the E1 TDM SFP. There are several ways in providing the network clock (derived from PRC) to the SFP. This is depending on the node (NT) features where the SFP is residing. Depending on the controller type of the ISAM, the NT can be synchronized via BITS, SyncE or IEEE1588v2. Through the backplane clock circuit, all boards in the shelf are being synchronized. The synchronization of the SFP itself is done via SyncE (SERDES) to provide the network timing from the NE (ISAM).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-17
A. Cross-domain solutions
The network clock can be imposed upon the customer TDM network, both tributaries of the SFP can be synchronized from the SFP (host) clock which is derived from the network clock via SyncE, as described above. Alternatively, the SFP can take one of the E1s as clock source. The 2E1-SFP solution in ISAM does not support the transport of the E1 service clock across the packet network. An overview of the different synchronization options in an end-to-end solution is provided in Figure A-10. Figure A-10 E1 TDM SFP, End-to-End Synchronization options
Alarms
E1 and TDM related alarms detected by the SFP are autonomously reported to the ISAM and AMS. On request the operator can also retrieve the active alarms on the SFP through the ISAM. Depending on the configuration of the E1 line interface, whether in framed or unframed mode additional alarm detection and reporting is supported. In unframed mode, the SFP supports LOS and AIS detection. In the framed mode, the SFP can also detect RDI, REI, LOF, LOMF and CRC4 bit failure on top of the LOS and AIS. Besides the alarm detection and reporting, the SFP allows also the forwarding of alarms, either towards the network via circuit emulation (MEF8) or towards the line interface (E1). The forwarding of alarms can be configured per alarm (AIS, RDI and REI) and for each direction (network or E1) independently. Service diagnostic capabilities
Loopbacks
A-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
The 2E1-SFP supports different type of loopbacks. Loopbacks can be activated in both, E1 and packet network direction. In each direction, loopback points can be set on different places on the SFP, e.g. framer only, including the pseudowire interworking function or not. The following loopback options are supported:
• Loopbacks towards E1 (see Figure A-11): • Loopback towards E1 line interface without including the framer function • Loopback towards E1 line interface, including the framer function • Loopback towards E1 on SGMII, including the framer and CES IWF. • Loopbacks towards packet network (see Figure A-12): • Loopback towards Ethernet network, passing the CES IWF, without including the framer
• Loopback towards Ethernet network, passing the CES IWF and including the framer • Loopback towards Ethernet network on SGMII. This loop will be in front of the CES IWF and only does the MAC address swap on the pseudowire packets.
• Loopback on SERDES towards Ethernet network, not passing any function of the SFP. Figure A-11 2E1-SFP loopback towards E1 (including framer)
SERDES
SGMII
ETH-ITF
CESoP (IWF)
FRAMER
LIU
E1
ISAM (PSN)
Figure A-12 2E1-SFP loopback towards network (including framer)
SERDES
SGMII
ETH-ITF
CESoP (IWF)
FRAMER
LIU
E1
ISAM (PSN)
Performance monitoring via E1 CRC4 checks For framed E1 the 2E1-SFP can perform bit error monitoring through CRC4. When the CRC4 check is activated, the SFP will raise a CRC4 alarm when a frame with bad CRC has been received. An additional CRC4 threshold alarm is raised when the bad CRC4 frame count reaches a certain threshold (currently set to 915 frames). TDM Pseudowire packet-loss detection The 2E1-SFP has ability to detect packet-loss on the pseudowire. A time window (in msec) can be configured in which packet-loss is being monitored. In case a loss of packet is detected a LOS (from IWF) is asserted. When in the same window no packet-loss is detected anymore, the LOS alarm is de-asserted. A specific packet-loss LOS alarm is supported per tributary pseudowire.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-19
A. Cross-domain solutions
Solution description The picture below illustrates possible deployment scenarios. In summary, the E1 TDM SFP based solution:
• Is providing a flexible pluggable solution: pay as you grow • Leverages on existing ISAM and Ethernet based aggregation/service network for • • • • •
TDM (V)LL for TDM service/network migration resulting in CAPEX and OPEX savings. Is a scalable solution: SFP based, no need for dedicated board which consumes a full slot. Supports solid synchronization through Synchronous Ethernet Is fully integrated in the ISAM provisioning system and element manager (5520 AMS) Is ITU (E1) compliant Uses MEF8 encapsulation ensuring transparency to any TDM networking protocol Figure A-13 Solution Description ISAM E1/PRA backhaul
A-20
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
A.5
Ethernet Business Access over ISAM
Scope This section describes solutions for Ethernet business access over ISAM:
• Over (bonded) SHDSL, using a 7230 BG 3Se Series Cellpipe CPE, 1521 CLIP, 7705 SAR-M(E) combo or a third party SHDSL business CPE/NTU at the customer premises. • Over point-to-point ethernet, using the ISAM Gigabit Ethernet LT board + 1522 FLIP, 1850 TSS-3, 7705 SAR-F/SAR-M(E) or a third party fiber business CPE/NTU at the customer premises. • Over GPON and EPON, using an indoor or outdoor data ONT at the customer premises.
Introduction Access and service providers are gradually migrating the delivery of business access services, originally dominated by TDM and ATM-based offerings, to Ethernet access. This migration is driven mainly to achieve converged access and aggregation networks, thereby reducing CAPEX and OPEX. In a fully converged access network, we expect residential-, business- and mobile backhaul customers to be served from the same access node. The ISAM, in conjunction with a portfolio of CPEs/NTUs/ONTs is equipped with best-in-class features to fulfill the requirements for Ethernet business access services, and this over a choice of copper and fiber access technologies.
Technical Challenges
Bandwidth
Ethernet business access subscribers may have bandwidth requirements varying anywhere from a few Mbps up to 1Gbps. A scalable solution tailored to the bandwidth needs is required. Bandwidth requirements for Ethernet business access are mostly symmetric (except for business internet access). ISAM provides high symmetrical bandwidth over SHDSL by means of g.SHDSL.bis (up to 5.7 Mbps per copper pair over 3km nominally) and g.SHDSL.bis bonding (up to 8 pairs for ATM IMA; up to 4 pairs for PTM (providing a bandwidth of 22.8 Mbps nominally)). Of the bonding flavors, ATM IMA and PTM bonding are preferred for reasons of resiliency: if one pair goes down, the group will not be impacted. Of the two, PTM bonding is superior with respect to bandwidth efficiency, provisioning simplicity and flexibility in data rates for the different pairs. With GPON, EPON and point-to-point Ethernet, ISAM can provide bandwidth scaling up to hundreds of Mbps and 1Gbps respectively.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-21
A. Cross-domain solutions
Access node features:
• • • •
g.SHDSL.bis and SHDSL bonding GPON EPON Gigabit Ethernet LT
Ethernet Business Service Delivery
The Ethernet business services that this solution covers include:
• L2 VPN (E-LINE, E-LAN, E-TREE) • L3 VPN • Business Internet Access (BIA) In each of these service models, the function of the business CPE/NTU/ONT and the access node is to provide a layer 2 access spoke to an aggregation network implementing the layer 2 service (L2 VPN) or connecting to the layer 3 router (L3 VPN, BIA). Figure A-14 Ethernet Business Service Delivery inter-metro ETH
CPE or NTU
L2 VPN
AN
AGG
L2 aggregation
inter-metro L3 VPN
Customer router
internet BIA L2 access segment
L2 aggregation virtual line or virtual LAN carrier Ethernet or IP/MPLS
Ethernet business services may be offered with varying levels of functionality and quality; from low-end basic connectivity to high-end service delivery governed by stringent SLAs. For L2 VPNs (and in extrapolation also for the layer 2 access to L3 VPN and BIA services), the Metro Ethernet Forum (MEF) provides a framework for the definition of layer 2 services at the UNI between the customer equipment and the service provider, and this for all but the more basic connectivity services. MEF Service Requirements at the UNI (MEF6.1, MEF10.2) specify such things as:
• Service types: E-LINE, E-LAN, E-TREE. • Service multiplexing and service selection: all:1, 1:1, n:1 VLAN mapping. • Transparency for customer frames (VLANs, MTUs, L2CP, multicast/broadcast and so on)
• Layer 2 control protocol (L2CP) handling: discard, tunnel, peer • Ingress and Egress bandwidth profiles and - rate limiting.
A-22
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
Service Requirements at the UNI (MEF of other) can be implemented by either of two architectures:
• In the UNI model, the UNI requirements are implemented by the access node LT board. The customer premises device connecting to the customer router can be a simple CPE or media convertor with basic functionality. • In the NTU model, the UNI requirements are implemented by a dedicated, operator managed NTU/ONT at the customer premises. The NTU/ONT has enhanced demarcation features over a simple CPE/media convertor and is possibly MEF-certified. The access node should be transparent in this model. Figure A-15 Implementing service requirements at the UNI UNI model UNI
Customer site ETH
UNI-N
CPE/MC
AN
L2 aggregation
AN
L2 aggregation
Customer router
NTU model UNI
Customer site UNI-N ETH
NTU
Customer router
As a particular instance of the service requirements at the UNI, full transparency for customer frames is required for particular L2 VPN service delivery models (for example, Ethernet private lines). Transparency requirements may pertain to such features as preservation of customer VLAN tags (including 802.1q p-bits), support of customer MTUs, transparency for multicast/broadcast and for L2CP protocols that the customer wants to use to manage his network end-to-end (like LACP, (m)STP and so on). ISAM implements full transparency for customer frames, by making use of transparent VLAN cross-connect forwarding mode. Alternatively, ISAM can initiate an IP/MPLS based VLL providing full transparency. Access node features:
• UNI model: transparent VLAN cross-connect (1:1, tunneling mode, mapping mode) or MPLS PE (VLL), L2CP handling (discard, tunnel), MTUs, ingress rate limiting • NTU model: transparency of VLAN cross-connect or MPLS PE (VLL)
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-23
A. Cross-domain solutions
High availability
In terms of high availability of the Ethernet business service, prime concerns are focused on the network links and elements that aggregate a (large) number of customers (ISAM node and ISAM uplinks, aggregation nodes and aggregation links, edge routers implementing L3VPN or BIA, GPON feeder), and less so on the first mile. Figure A-16 High Availability: points of failure ISAM dual uplinks with LAG, multi-chassis LAG, mSTP
ISAM NT redundancy
AGG CPE/ NTU
AN
L2 aggregation AGG
Customer router
IP/MPLS or Carrier Ethernet repair mechanisms
Access node features:
• • • • • •
NT redundancy dual homed ISAM uplinks Ethernet based redundancy (with LAG, multi-chassis LAG or xSTP) IP/MPLS based redundancy (LSP path redundancy, pseudowire redundancy) enhanced Type-B protection (future release) inherent redundancy in DSL bonding (ATM IMA and EFM bonding).
QoS
Business services come with more or less stringent SLAs governing QoS KPIs of bandwidth, loss, delay and jitter for the service or services presented at the UNI. In general, business traffic will have to compete with residential traffic (and possibly mobile backhaul traffic) running in the same access node. The ISAM access node, being already engineered for triple play services is well positioned to provide differentiated QoS for business traffic streams of varying nature, also in competition with residential and mobile traffic in the same node. Access node features: Ingress policing/color marking, four queues per port, QoS marking. OAM, including SLA monitoring
Stringent SLAs on Ethernet service availability (% availability, maximum time to restore, and so on) require that operators have tools for connectivity fault monitoring and -troubleshooting. Also, business access customers may require SLA monitoring and SLA reporting (availability, loss, delay, jitter). A-24
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
In carrier Ethernet, 802.1ag/Y.1731 connectivity fault monitoring and its Y.1731 extensions for performance monitoring provide the means for above OAM functions, while IP/MPLS has its own dedicated OAM tools. Access node features:
• Transparency for end-to-end 802.1ag/Y.1731 OAM PDUs • Optional 802.1ag MIP/MEPs in the access node for troubleshooting • LSP ping/traceroute and VCCV ping for MPLS PE Solution description Figure A-17 shows the solution components for Ethernet business access over (bonded) SHDSL, point-to-point Ethernet, GPON and EPON using ISAM 7302/7330/7360. Figure A-17 Ethernet Business Access Portfolio 1521 CLIP rd or 3 party SHDSL NTU/CPE
1-4p SHDSL
1-4p SHDSL + 1-2p xDSL SAR-ME combo point-to-point Ethernet (FE|GE) 1850 TSS-3 or 1522 FLIP or 3rd party fiber NTU/CPE
7302/7330 ISAM
point-to-point Ethernet (FE|GE) SAR-ME fiber or SAR-F Data ONT GPON SAR-ME GPON
Low-end SHDSL CPEs are low-cost solutions for basic ethernet business access services, using UNI-N functionality of the ISAM SHDSL LT board. 1521 CLIP, 7705 SAR-ME combo and dedicated 3rd party SHDSL NTUs can be positioned as mid-range to high-end solutions for SHDSL access in an NTU architecture. 1522 FLIP, 1850 TSS-3, 7705 SAR-F, 7705-SAR-ME fiber, and dedicated 3rd party fiber NTUs can be positioned as mid-range to high-end solutions for fiber access in an NTU architecture. Simpler 3rd party fiber CPEs/media convertors can be positioned, using UNI-N functionality of the ISAM GE LT board. The Alcatel-Lucent indoor or outdoor residential type data ONT, or a more feature-rich 7705 SAR-ME GPON and EPON is positioned for GPON and EPON access. For the logical end-to-end topologies for Ethernet business services (L2VPN, L3VPN, BIA), see Figure A-14. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-25
A. Cross-domain solutions
The solution components are:
• A customer router that connects to the L2 VPN/L3 VPN/BIA service. The customer router is beyond the responsibility of the business access provider. • A provider managed NTU at the customer premises, or a simpler CPE/media convertor. In the NTU model, the service selection is fully performed by the NTU, adding a per-service VLAN. The NTU also performs other UNI-N functions (L2CP handling, ingress rate limiting …) as well as non-UNI-N functions required for service assurance (connectivity monitoring, SLA monitoring …). • The access node (AN) cross-connects customer traffic, either to a per-service VLAN or to a per-service MPLS VLL. In the NTU model, this is a 1:1 cross-connect of the service VLAN added by the NTU. In both VLAN cross-connect mode and MPLS VLL mode, full transparency for customer frames is assured. In the UNI model, the service selection (all:1, 1:1, n:1) is performed by the ISAM LT board, along with other UNI-N functions. The aggregation network implements either a point-to-point service (E-LINE) or a LAN service (E-LAN). This L2 aggregation function is valid, both for a L2 VPN service as for the L2 aggregation function towards a L3 edge router implementing a L3 VPN or BIA service. Local bridging/VPLS in ISAM is not required to implement an E-LAN service. Instead, a L2 spoke through the CPE/NTU and ISAM to the first aggregation node can be implemented, while the aggregation network takes on the E-LAN functionality. The aggregation network can be either carrier Ethernet or IP/MPLS. In the case of IP/MPLS based aggregation, the first aggregation router performs the MPLS PE function. Alternatively, the MPLS PE function can be further distributed into the access node. For L3 VPN and BIA services, an edge router at a PoP location takes on the L3 functions and is fed by the L2 aggregation network. The L3 function could also be distributed. In terms of high availability, the access node can be dual homed to a single aggregation node or to redundant aggregation nodes (with LAG, multi-chassis LAG or xSTP for an Ethernet access node, with LSP path redundancy for an MPLS access node). The aggregation network is protected by either carrier ethernet or IP/MPLS based resiliency mechanisms with no dependency on the access segment. Access to resilient L3 edge routers is either handled by the customer router or by the L2 aggregation network and has no dependency on the access segment. For SHDSL, ATM IMA bonding and PTM bonding inherently provide a level of resiliency for the first mile. In terms of QoS, the ingress bandwidth enforcement (optionally including color marking) is performed by the NTU in the NTU-model and by the ISAM LT board in the UNI-model. The regular ISAM QoS features enable differentiated treatment of business traffic in competition with residential and mobile traffic inside the node as well as correct marking of packets for further QoS treatment in the aggregation network (upstream) or in the NTU (downstream). A-26
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
In terms of OAM, end-to-end monitoring of the business access service (including the first mile) is typically handled between an NTU at the customer premises and either a peer NTU (for L2 VPN) or the edge router at the PoP location (for L3 VPN, BIA). 802.1ag and Y.1731 can be used for end-to-end checks, either on a continuous basis (connectivity fault monitoring, SLA monitoring) or on-demand (troubleshooting). The ISAM should be transparent for end-to-end 802.1ag/Y.1731 PDUs. Optionally, 802.1ag MEPS and MIPS can be placed in ISAM for further troubleshooting and fault isolation. For MPLS PE in the access node, LSP ping/traceroute and VCCV ping can be used to troubleshoot the MPLS segment of the service.
A.6
ISAM Backhaul (Rural DSL, Ultra-high Broadband)
Introduction The 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 re-using legacy (incumbent) network • Re-use of high-capacity national infrastructure • Complementing fiber based FTTN deployment
Solution description The 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 (for example, 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 another Ethernet based transport layer (illustrated by Figure A-18). 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), …
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-27
A. Cross-domain solutions Figure A-18 ISAM fiber backhaul Remote / Cabinet Location
Optical Distribution Network
Central Office / Aggregation Location
7330 ISAM FTTN ODF 7302 ISAM CO ISP 1
7354/7324 ISAM RU Active Optical Network
Aggregation Network ISP 2
7330 ISAM CO 7356 ISAM REM
7330 ISAM RA Ethernet 7357 ISAMSEM
Corporations and Residences
Remote / Cabinet Location
Central Office / Aggregation Location
Backhaul option
7330 ISAM FTTN 7302 ISAM CO ISP 1
7330 ISAM CO
Transport Network
Converter
ISP 2
Converter
Aggregation Network
7354/7324 ISAM RU
7356 ISAM REM
7330 ISAM RA Ethernet
7357 ISAMSEM
Corporations and Residences
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 (for example, ML-PPP). Bandwidth
In many cases the backhaul transport network cannot 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, and so on). Possibly, multiple links need to be bundled to increase the bandwidth.
A-28
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
In industrialized countries with subscriber dense areas and high bandwidth per user (for example, 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 cannot be served by fiber (fiber black spots) to obtain 100% user coverage with ISAM based broadband access. 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, that is, 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 (that is, 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-19 gives an example of the header/trailer bytes added by the GFP and HDLC encapsulation method.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-29
A. Cross-domain solutions Figure A-19 Encapsulation overhead GFP versus HDLC
GFP Encapsulation
HDLC Encapsulation
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 Framed E1 (31 Timeslots) = 1984 kbit/s GFP-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
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 (for example, link failure). The priority scheduler in the converter will ensure high priority traffic (for example, voice) gets precedence over other concurrent traffic in case of congestion. This is illustrated in Figure A-20.
A-30
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions Figure A-20 ISAM backhaul with point-to-multipoint converter Central Office / Aggregation Location
Remote / Cabinet Location
Backhaul option PDH (nxE1)
NT
NT Converter
LT Protocol based VLAN tag. + Pbit
Converter
E1 VoIP
VoIP
VoIP
FE/ GE
VoIP
NW Ctrl
SP
...
NW Ctrl
SP
HSI
shaping
WRR
shaping
SP
NW Ctrl
GE
DSL Link Policies
ML-PPP
FE/ GE
HSI
SP
NW Ctrl
GE
DSL 1 UP
WRR HSI
HSI
E1
DOWN
VoIP SP
NW Ctrl
DSL 48
WRR HSI
NT GE
Mgmt IP
VoIP : Strict Priority 1 NW Ctrl : Strict Priority 2 HSI : Best Effort
In case of point-to-point converters (see Figure A-21), 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-21 ISAM backhaul with point-to-point converter Central Office / Aggregation Location
Remote / Cabinet Location Backhaul option PDH (nxE1)
NT
LT
NT
Protocol based VLAN tag. + Pbit
VoIP
VoIP
E1
E1
GE
SP
NW Ctrl
WRR
HSI
HSI
VoIP
VoIP
GE
E1
E1
GE
L A G
L A G
HSI
GE VoIP
GE
E1
E1
GE
SP
NW Ctrl
GE
DSL 1 UP
WRR HSI VoIP
VoIP
shaping
WRR
shaping
SP
NW Ctrl
shaping
WRR
shaping
SP
NW Ctrl
DSL Link Policies
GE
shaping
WRR
shaping
SP
NW Ctrl
SP
WRR
WRR
HSI
DOWN SP
NW Ctrl
NW Ctrl
HSI
HSI
DSL 48
VoIP
VoIP
GE
E1
E1
GE
shaping
WRR
shaping
SP
NW Ctrl
SP
NT
NW Ctrl
GE Mgmt IP
WRR
HSI
HSI
VoIP : Strict Priority 1 NW Ctrl : Strict Priority 2 HSI : Best Effort
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), and so on. 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 but also offer the means to provide more aggregated bandwidth on the backhaul link.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-31
A. Cross-domain solutions
As shown in Figure A-21, the LAG function of the ISAM is being used to aggregate 4x E1 based backhaul links into one pipe. Figure A-20 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 (for example, LAG) and a port-down alarm (LOS) is presented to the management system. In a non-redundant backhaul scenario the alert should indicate 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:
• Re-using 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, re-use 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-22 provides a high-level overview of possible ISAM configurations and converters to provide the backhaul connectivity.
A-32
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions Figure A-22 ISAM backhaul options
A.7
Hospitality solution
Introduction Many hotels and retirement homes are wired with Category3 cable which was very popular in the 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, Wi-Fi (shared) hotspots were made available to which the hotel guest can connect. 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-23 Standard offering for voice and internet access in hotel guest rooms
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-33
A. Cross-domain solutions
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 re-using the existing Cat3 wiring for xDSL the hotelier can achieve this over the existing infrastructure, without too costly cabling costs. So no “rip and 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-24 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, and so on) using a single copper pair. A modem (for example, 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.
A-34
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
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-25. • Medium to large size hotels with multiple equipment rooms (for example, 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-26. • A variant to the previous deployment scenario is with larger properties where the hotel guest rooms are distributed over different buildings or multiple, collocated, remote sites (for example, a campus). The same ISAM solution applies as in the previous case; see Figure A-27. Figure A-25 IP DSLAM Deployment scenario for hospitality, centralized
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-35
A. Cross-domain solutions Figure A-26 IP DSLAM Deployment scenario for hospitality, distributed (single building)
Figure A-27 IP DSLAM Deployment scenario for hospitality, distribute (multiple sites)
A-36
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
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-28 ISAM in hospitality: triple-play high-level network topology
Two options apply:
• The existing telephony/POTS can co-exist 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-28, “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-28, “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, and so on) on the same DSL line. Broadband bandwidth requirements
The total bandwidth required is determined by the services offered to the hotel guest.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-37
A. Cross-domain solutions
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 (for example, 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 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 online gaming (might be part of Internet service), in-room control, hotel camera views (for example, bar, swimming pool, and so on), Figure A-29 Hotel Room Bandwidth requirement
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
All the data-streams described in Figure A-29 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
A-38
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
• 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, and so on • Distance: loop length limits, especially for VDSL2 • Bridged Taps: copper pairs that are interconnected together are causing reduced DSL performance • Environment Interference: air-conditioning, elevator engines, and so on • 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.8
Open Community Broadband for Smart Communities
Introduction End-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 EPON) and other flavours of FTTx depending on the case-by-case needs. Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-39
A. Cross-domain solutions
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 and EPON 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-30. 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-30 OCB: roles and wholesaling levels
The focus of OCB lies on the full separation case. A-40
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions
Roles and responsibilities
As shown in Figure A-31, in the fully separated case there are distinct responsibilities at each level. Figure A-31 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, and so on) 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 has to support a very granular configuration of bandwidth and QoS per RSP per end-user.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-41
A. Cross-domain solutions
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 and 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 (for example, 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.
A-42
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
A. Cross-domain solutions Figure A-32 L2 access architecture for OCB (residential user depicted with 1 RGW per RSP)
Solution description: Management subsystem The 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 does not 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 | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
A-43
A. Cross-domain solutions
A-44
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
B.
RADIUS Attributes
B.1 RADIUS Attributes
B-2
B.2 Vendor specific RADIUS attributes
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
B-2
November 2013
B-1
B. RADIUS Attributes
B.1
RADIUS Attributes
NAS-Port The system sets the NAS-port attribute as described below:
• 802.1x sessions: The NAS-port attribute contains the ifIndex of underlying bridge port.
• PPPoE sessions: The NAS-port attribute contains the ifIndex of the PPPoE sessions.
NAS-Port-Id The system sets the NAS-Port-Id attribute according to the following text format: atm ///:. The fields indicated between “” 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
B-2
Vendor specific RADIUS attributes
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
B. RADIUS Attributes
General Vendor 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. Note — If the radius server supplies the 7330 with VSA privileges in
the authentication response for a CLI operator, the response must contain a VSA and privilege level for all supported VSA's on the 7330. Otherwise, the 7330 will use the default values for ALL attributes as set in the default-profile on the ISAM. The default-profile settings can be viewed in CLI using the info configure system security default-profile command.
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-Name The QoS-Profile-Name is a character string of maximum 32 characters identifying the QoS user profile configured in the system. The QoS user profile contains both marker and policer information. Note: This attribute cannot be specified together with QoS-Parms attribute.
• • • •
Vendor Type: 1794 Vendor Length: 4 < length < 35 Vendor Value: STRING Packet: Access-Accept
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
B-3
B. RADIUS Attributes
QoS-Parms Note: This attribute cannot be specified together with QoS-Profile-Name attribute.
• • • •
Vendor Type: 1795 Vendor Length: 4 < length < 249 Vendor Value: STRING Packet: Access-Accept
Possible values are:
• [marker up {.1p }] • [policer up {cir cbs }] • [policer down {cir cbs }] where:
• cir: 4 bytes in kbit/s • cbs: 4 bytes in bytes TL1 domain parameters Table B-1 lists the VSAs and their default values for the TL1 domain. Table B-1 TL1 domain parameters Domain
VSA
Value
Default Value
Maintenance
1536
Integer (0..7)
4
Provisioning
1537
Integer (0..7)
4
Security
1538
Integer (0..7)
7
Test
1539
Integer (0..7)
0
The possible values for each domain are:
• • • • • • • •
0: no privilege 1: privilege level 1 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 parameters Table B-2 lists the VSAs and their default values for the CLI domain.
B-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
B. RADIUS Attributes Table B-2 CLI domain parameters Domain
VSA
Value
Default Value
AAA
1801
Integer (0..3)
1
ATM
1802
Integer (0..3)
3
Alarm
1803
Integer (0..3)
3
DHCP
1804
Integer (0..3)
3
EQP
1805
Integer (0..3)
3
IGMP
1806
Integer (0..3)
3
CPEproxy
1807
Integer (0..3)
3
IP
1808
Integer (0..3)
3
PPPoE
1809
Integer (0..3)
3
QoS
1810
Integer (0..3)
3
SWMgt
1811
Integer (0..3)
3
Transport
1812
Integer (0..3)
3
VLAN
1813
Integer (0..3)
3
XDSL
1814
Integer (0..3)
3
Security
1815
Integer (0..3)
0
Cluster
1816
Integer (0..3)
3
SLOT-NUMBERING
1820
Integer (0..2)
2
Service
1821
Integer (0..3)
3
Debug
1822
Integer (0..3)
3
Debugmirror
1823
Integer (0..3)
3
Filter
1824
Integer (0..3)
3
Link
1825
Integer (0..3)
3
Log
1826
Integer (0..3)
3
OAM
1827
Integer (0..3)
3
SIP
1828
Integer (0..3)
3
MEGACO
1829
Integer (0..3)
3
LACP
1830
Integer (0..3)
3
MSTP
1831
Integer (0..3)
3
DROUTER
1832
Integer (0..3)
3
The possible values for each domain are:
• • • •
0: no privilege 1: read privileges 2: write privileges 3: read-write privileges
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
B-5
B. RADIUS Attributes
CLI profile parameters Table B-2 lists the VSAs and their default values for the CLI profile. Table B-3 CLI profile parameters
B-6
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
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX 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).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-1
Glossary
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.
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.
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.
GL-2
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
AAL2
ATM Adaptation Layer 2 Type 2 class of AAL service characterized by voice and video transfer.
AAL5
ATM Adaptation Layer 5 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.
ACR
Adaptive service Clock Recovery This technique allows to recover the service clock, applied by a transmitter using an asynchronous transmission channel (packet or cell), at the receiver side, by monitoring the filling level of the reception data buffer, and by adapting the clock that is used for data extraction from the buffer such that this filling level varies around a pre-defined setting, without letting the buffer overflow, or become empty.
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.
AF
Assured Forwarding
AGG Node
Aggregation Node
AI
Application Intelligence
AIS
Alarm Indication Signal
ALG
Application Layer Gateway
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.
AMSL
Above Mean Sea Level
ANCP
Access Node Control Protocol
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-3
Glossary
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
BCMP
Broadband Access Network Cluster Management Protocol
BE
Best Effort
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.
GL-4
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
BFD
Bidirectional Forwarding Detection
BGP
Border Gateway Protocol
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.
BITSoIP
BITS over IP - refers to IEEE1588
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.
BW
Bandwidth
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
CBS
Committed Burst Size
CCSA
Checkpoint Certified Security Administrator or China Communications Standards Association
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-5
Glossary
CDC
Carrier Data Collection
CDE
Customer Dependant Engineering The CDE file on a card contains country-specific information.
CDR
Clock Data Recovery
CEP
Current Equipment Practice
CES
Circuit Emulation Service
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.
CIR
Committed Information Rate
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
CMTS
Cable Modem Termination Systems
GL-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
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.
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-7
Glossary
DBA
Dynamic Bandwidth Allocation The capacity of subdividing large high-capacity network transmission resources among multiple applications almost instantaneously and providing each application only the share of bandwidth each application requires
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.
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
DOCSIS
Data Over Cable Service Interface Specification
DoD
Downstream on Demand
DoU
Downstream Unsolicited
DPoE
DOCSIS Provisioning of EPON
DS1
Digital Service Level-1 A digital circuit with a total bandwidth or transmission speed of 1.5444 million bits per second. The trunk level-1 standard of 1.5444 is in support of 24-voice conversations each encoded at 64 Kb per second.
GL-8
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
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
EEC
Ethernet Equipment Clock Option 1: designed for interworking with 2048 kHz hierarchy based TDM equipment Option 2: designed for interworking with 1544 kHz hierarchy based TDM equipment
EF
Expedited
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).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-9
Glossary
EM
Element Manager
EMAN
Ethernet Metropolitan Area Network
EMC
Electromagnetic Compatibility EMC designates the ability of commodities to function normally in the electromagnetic environment (this ability is termed Electromagnetic Susceptibility [EMS]), and the ability not to generate unbearable electromagnetic interference to other devices and equipment in the same environment (this ability is termed Electromagnetic Interference [EMI]. These two abilities are collectively named EMC.
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.
F FC
GL-10
Forwarding Class
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
FDB
Forwarding Database
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.
FRR
Fast ReRoute
FTP
File Transfer Protocol
FTTN
Fiber to the node See 7330 ISAM FTTN.
G GE
Gigabit Ethernet Ethernet interface running at 1000 Mb/s.
GEM
GPON Encapsulation Method
GFC
General Facilities Card
GPON
Gigabit-capable Passive Optical Network
GMMI
Gigabit Media Independent Interface, with data clock of 125 MHz and clock accuracy of ± 1.0×10-4 (100 ppm)
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-11
Glossary
H H1
High-1
H2
High-2
HPNA
Home Phoneline Networking Alliance
HSD
High Speed Data
HSI
High Speed Internet
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.
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 IHub
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.
GL-12
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
IP
Internet Protocol A connectionless packet-switching protocol that works together with TCP.
IPCP
IP Control Protocol A protocol that configures, enables, and disables the IP protocol modules on both ends of a point-to-point link. IPCP is tied to PPP, and activated when PPP reaches the network layer-to-protocol phase. If IPCP packets are received prior to this phase, they are discarded.
IPoA
Internet Protocol over ATM
IPoE
Internet Protocol over Ethernet
IPTV
IP Video/Television The delivery of video services over an end-to-end IP infrastructure. IPTV can include various classes of video services including video on demand, broadcast TV, video conferencing, and mobile video.
ISAM
Intelligent Services Access Manager 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
L L1
Low-1
L2
Low-2
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.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-13
Glossary
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.
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.
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.
LDP
Label Distribution Protocol
LED
Light Emitting Diode A semiconductor diode that emits light when a current is passed through it.
LER
Label Edge Router
LLDP
Link Layer Discovery Protocol
LMI
Line Management Interface
LOID
LOgical Identifier
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.
GL-14
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
LSM
Line Server Module A generic term including xDSL line interface modules and any other server application-specific module.
LSR
Label Switch Router
LT
Line Termination
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
MBS
Maximum Burst Size
MC
Multicast
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.
MDU
Multi Dwelling Unit
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-15
Glossary
ME
Managed Entity
MEF
Metro Ethernet Forum
Megaco
Media Gateway Controller
MEP
Maintenance Endpoint
MEPID
Maintenance Endpoint Identifier
MHF
MIP Half Function
MIB
Management Information Base
MIP
Maintenance Intermediate Point
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
MPLS
Multi Protocol Label Switching
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
NC
Network Control
NE
Network Element
GL-16
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
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.
NTA slot
Network Termination slot A
NTB slot
Network Termination slot B
NTIO
Network Termination Input/Output
NTP
Non-Trouble Procedure or Network Timing Protocol
NTR
Network Timing Reference
NTU
Network Termination Unit
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
OLT
Optical Line Termination
ONC
Open Network Computing
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-17
Glossary
ONT
Optical Network Terminal Equipment that provides voice, data, and video services and terminates the network at a subscriber location. ONTs provide services to a single family home, a business location, or a multidwelling residence, such as an apartment complex or condominium. Services can include POTS, high-speed Ethernet, IPTV, and RF video
ONU
Optical Network Terminal Equipment that provides voice, data, and video services and terminates the network at a subscriber location. ONTs provide services to a single family home, a business location, or a multidwelling residence, such as an apartment complex or condominium. Services can include POTS, high-speed Ethernet, IPTV, and RF video
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
OSSI
Operations Support System Infrastructure
OSWP
Overall Software Package
P PADI
PPPoE Active Discovery Initiation
PBO
Power Back-Off
PC
Personal computer A PC can be used as a craft terminal.
PDF
Power Distribution Frame
PDH
Plesiochronous Digital Hierarchy
PDV
Packet Delay Variation
PDU
Protocol Data Unit
GL-18
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
PHY
Physical layer
PID
Protocol Identifier A part of the SNAP header that identifies the protocol to be encapsulated.
PIR
Peak Information Rate
PM
Performance Monitoring
PMD
Physical Media Dependence
P-OLT
Packet Optical Line Termination
PoE
Power over Ethernet
PON
Passive Optical Network A fiber-based network that uses passive splitters to deliver signals to multiple users.
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.
PTP
Precision Timing Protocol
PSU
Power Supply Unit
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-19
Glossary
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
PW
Pseudo-Wire
PWE3
Pseudo Wire Emulation Edge to Edge
Q QL
Quality Level of an external NTR source, determined by SSM messaging, or by default, as specified in ITU-T Rec G.781 section 5.3.1
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
REM
7356 ISAM FTTB Remote Expansion Module
GL-20
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
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.
RMI
Remote Management Interface
RNM
Residential Network Manager
RR
Round Robin
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.
RSVP-TE
Resource Reservation Protocol - Traffic Engineering
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).
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-21
Glossary
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
SAToP
Structure Agnostic TDM over Packet
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.
SEC
SDH/SONET Equipment slave clock ITU-T Rec G.813 “Option 1": the (SDH based) 2048 kb/s synchronization clock hierarchy ITU-T Rec G.813 “Option 2": the (SONET based) 1544 kb/s synchronization clock hierarchy
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
SI
Système international d’unités
GL-22
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
SIP
Session Initiation Protocol
SLA
Service Level Agreements
SLIC
Subscriber Line Interface Circuit
SLID
Subscriber Location Identifier
SLM
Synthetic Loss Measurement
SLR
Synthetic Loss Reply
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.
SOHO
Small Office Home Office
SONET
Synchronous Optical Network A transmission network that uses high-speed optical carriers.
SP
Strict Priority
SRA
Seamless Rate Adaptation
SSCS
Service-specific convergence sublayer
SSH
Secure Shell
SSM
Source-specific multicast or Synchronization Status Message: indicate the synchronization status of a communication link (SDH/SONET or Synchronous Ethernet based)
SSU
Synchronization Supply Unit - ETSI market equivalent for BITS, typically supplying a plain 2048 kHz clock interface, rather than a framed E1 PDH interface
SyncE
Synchronous Ethernet, that is, Ethernet based on a transmission clock that is stable and accurate enough to derive NTR information for slaved network nodes and their interfaces.
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-23
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
TC
Transmission Convergence Layer
TCA
Threshold Crossing Alarm
T-CONT
Transmission Container, Traffic Container
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.
TDD
GL-24
Time Division Duplex
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
TDM
Time Division Multiplex A transmission technique used to transmit several signals across a single channel or bus by interleaving the signals in successive time slots. A specific time slot or interval is assigned to each signal source
TDMA
Time Division Multiple Access
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.
T-LDP
Targeted LDP
TNG
Training Document
TNV
Telecom Network Voltage
ToD
Time of Day
TOP
Task-Oriented Practice The TOP method is a documentation system that supports the installation, operation, and maintenance of telecommunications equipment and software through different layers of documentation.
Tx
transmit To send or carry signals or data from a device; any part of the equipment that converts or encodes signals or data exiting from the equipment into the desired form for transmission to other equipment.
U UA
User Agent
UC
Unicast
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
UNI
User-to-Network Interface
UPBO
Upstream Power Back-Off
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-25
Glossary
UPS
Uninterruptible Power Supply
upstream
Transmission from the customer location to the network. On the network termination (NT) side, transmit (Tx) indicates the upstream direction of the transmission to the network. On the line termination (LT) side, receive (Rx) indicates the upstream direction of the transmission to the OLT.
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.
VCL
Virtual Channel Link
vCM
virtual Cable Modem
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
VL
Vectoring Link
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.
VLL
Virtual Leased Line
VoD
Video on Demand
GL-26
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Glossary
VoIP
Voice over IP VoIP carries voice transmissions in packets and uses Internet Protocols (IP) instead of using legacy public switched telephone network (PSTN) circuit-switched technologies and protocols.
VP
Virtual Path A single communications connection identified by an office equipment number and a VPI.
VP
Vectoring Processing
VPI
Virtual Path Identifier An identifier in an ATM cell that distinguishes the data of one VP from the data of another VP.
VPLS
Virtual Private LAN Service
VPRN
Virtual Private Routed Network
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
WDM
Wavelength Division Multiplexing
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
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
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
GL-27
Glossary
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
GL-28
A general term used to refer to an unspecified type of encapsulation over ATM.
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Index
Numbers 802.1x support, 16-17
A Access node control protocol about, 4-31 ADSL about, 2-6 ADSL1 about, 2-6 ADSL2 about, 2-7, 2-7 ADSL2+ about, 2-8, 2-8 alarm filters logging filters, 4-23 programmable filters, 4-23 reporting filters, 4-23 alarm LEDs, 4-20 alarm management, 4-19 alarm delta logging, 4-21 alarm filters, 4-23 alarm identification, 4-19 alarm lists, 4-21 alarm logging, 4-21 alarm severity, 4-20
alarm types, 4-19 critical alarm LED, 4-20 current alarm list, 4-21 derived alarms, 4-19, 4-23 disable alarms, 4-21 enable alarms, 4-21 major alarm LED, 4-20 minor alarm LED, 4-20 NSE alarms, 4-19 programmable alarm configuration, 4-25 programmable alarm filters, 4-23 SE alarms, 4-19 snapshot alarm list, 4-21 spatial alarm filters, 4-23, 4-23 temporal alarm filters, 4-23, 4-23 view alarms, 4-21 ARP layer 2, 16-19 layer 3, 18-2 ATM PW about, 23-2, 24-2 cell concatenation, 23-3, 24-4 description, 23-2, 24-2 QoS, 23-4, 24-4 restrictions, 23-4 support, 23-4
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
IN-1
Index B — ISAM Voice
B
G
Bonding, 2-5 about, 2-5 ATM, 2-24 ATM bonding, 2-24 EFM, 2-25 PTM bonding, 2-25
GPON implementation, 8-3, 9-7 network architecture, 8-2, 9-5 introduction, 8-2, 9-2
H
C
Hospitality solution, A-33 C-VLAN cross-connect, 15-49 configuration description EPON system, 10-1, 11-1 Configuration overrule about, 7-13 current alarm list, 4-21
I
D DELT about, 5-8 derived alarms, 4-19, 4-23 DHCP layer 2, 16-20 layer 3, 18-3 DPBO, 7-9
E E1/T1 Leased Line Replacement, A-11 EFMOAM general description, 5-12 EPON system configuration description, 10-1, 11-1 TL1 commands, 10-22 Ethernet about, 2-13, 2-13 ethernet auto-negotiation, 2-13 modes, 2-13
IN-2
November 2013
iBridge, 15-29 iBridge mode features, 15-30 IEEE 802.1q tagging, 15-2 IGMP forwarding models, 19-19 Impulse noise sensor about, 7-10 IPoA cross-connect, 15-61 ISAM Backhaul, A-27 ISAM management via loop-back interface about, 4-15 ISAM Voice forwarding Layer 4, 12-22 MEGACO, 12-24 L2/L3 addressing MEGACO, 12-44, 12-53 SIP, 12-63, 12-68 MEGACO network topology, 12-3 protocol stacks MEGACO, 12-75 SIP, 12-79 SIP network topology, 12-5 traffic types MEGACO, 12-14 SIP, 12-15
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Index L — QoS profiles
L
N
LACP about, 16-4 layer 2 protocol handling, 16-2 user access interface, 15-26 layer 2 forwarding IPoA cross-connect, 15-61 layer 2 forwarding mode iBridge, 15-29 VLAN cross-connect, 15-49 layer 3 forwarding, 17-2 protocol handling, 18-2 Line Instability Test features, 5-14 Link transmission technology, 2-4 logging alarms, 4-21 Low power modes L2 low-power mode, 7-4 L3 idle power mode, 7-4 low power modes about, 7-4
non-service affecting alarms, 4-19 NT redundancy about, 3-2 link only protection, 3-5
M Mobile backhaul, A-3 MSTP about, 16-9 MTA in 7302 ISAM, 5-6 in 7330 ISAM FTTN, 5-6 TAC, 5-7 test access modes, 5-5 multi-ADSL ADSL, 2-6 ADSL2, 2-7 ADSL2+, 2-8 READSL2, 2-9 SELT, 5-8, 5-8 multicast forwarding models, 19-19
O ONT overview ONT product identification, 11-4 ONT product identification, 11-4 Open Community Broadband, A-39 Operational modes ADSL1, 2-6 ADSL2, 2-8 ADSL2+, 2-8 READSL, 2-9
P performance statistics, 4-18 PPPoE about, 16-26 PPPoE relay, 16-26 programmable alarm filters, 4-23 configuration, 4-25 spatial alarm filters, 4-23 temporal alarm filters, 4-23 protocol aware cross-connect, 15-56 Protocol Tracing about, 5-17 PSD shaping about, 7-9
Q QoS about, 20-2 downstream, 20-13 policy framework, 20-41 profiles, 20-31 traffic classes, 20-15 QoS profiles CAC profile, 20-31 marker profile, 20-38
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
IN-3
Index QoS profiles (continued) — VLAN forwarding
system logs configuring, 4-11 filters, 4-12 message types, 4-12 monitoring, 4-13 severity level, 4-12
policer profile, 20-39 queue profile, 20-32 scheduler profile, 20-37 session profile, 20-37
R
T
RADIUS about, 6-2, 21-2, 22-2 authentication, 21-3 encryption, 21-3 features, 21-2 proxy, 21-2 server, 21-2 READSL about, 2-9 READSL2 about, 2-9 RSTP about, 16-8 in 7302 ISAM, 16-9
Test Line Instability, 5-14 TL1 commands for EPON system, 10-22 Transfer modes, 2-5
U UPBO equal FEXT, 7-8 policing, 7-8 user access interface layer 2, 15-26
S
V
S-VLAN cross-connect, 15-52 S-VLAN/C-VLAN cross-connect, 15-51 Seamless rate adaptation modes, 7-6 security SSH, 4-10 SELT about, 5-7 multi-ADSL, 5-8, 5-8 VDSL, 5-8, 5-8 service affecting alarms, 4-19 SHDSL about, 2-11, 2-11, 2-11 supported standards, 2-12 snapshot alarm list, 4-21 SRA about, 7-6 SSH Secure shell, 4-10 statistics performance statistics, 4-18
IN-4
November 2013
V-OLT GPON functions, 8-12 VDSL about, 2-9 SELT, 5-8, 5-8 VDSL1 about, 2-9, 2-9 VDSL2 about, 2-10, 2-10 operational modes, 2-10 profile overview, 2-11 profiles, 2-10 Virtual noise about, 7-10 VLAN cross-connect, 15-49 C-VLAN cross-connect, 15-49 protocol aware cross-connect, 15-56 S-VLAN cross-connect, 15-52 S-VLAN/C-VLAN cross-connect, 15-51 VLAN forwarding, 15-2
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Index VLAN frame — xDSL
VLAN frame tagging, 15-2
X xDSL INP, 7-3
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 3HH-11651-BAAA-TQZZA Edition 03 Released System Description for FD 100/320Gbps NT and FX NT
November 2013
IN-5
Index
IN-6
November 2013
Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 Edition 03 Released 3HH-11651-BAAA-TQZZA System Description for FD 100/320Gbps NT and FX NT
Customer documentation and product support
Customer documentation http://www.alcatel-lucent.com/myaccess Product 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 Support http://support.alcatel-lucent.com
Documentation feedback
[email protected]
© 2013 Alcatel-Lucent. All rights reserved. 3HH-11651-BAAA-TQZZA Edition 03 Released
