dn03492199 4 en global pdf paper a4

252
Provisioning dn03492199 Issue 4 en # Nokia Corporation Nokia Proprietary and Confidential 1 (252) C33990.90--A0 Nokia D500, Rel. 3.2, Product Documentation

Upload: forseil

Post on 24-Oct-2015

24 views

Category:

Documents


0 download

DESCRIPTION

asd

TRANSCRIPT

Page 1: Dn03492199 4 en Global PDF Paper a4

Provisioning

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

1 (252)

C33990.90--A0Nokia D500, Rel. 3.2, Product Documentation

Page 2: Dn03492199 4 en Global PDF Paper a4

The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This document is intended for the useof Nokia's customers only for the purposes of the agreement under which the document issubmitted, and no part of it may be reproduced or transmitted in any form or means without theprior written permission of Nokia. The document has been prepared to be used by professionaland properly trained personnel, and the customer assumes full responsibility when using it.Nokia welcomes customer comments as part of the process of continuous development andimprovement of the documentation.

The information or statements given in this document concerning the suitability, capacity, orperformance of the mentioned hardware or software products cannot be considered binding butshall be defined in the agreement made between Nokia and the customer. However, Nokia hasmade all reasonable efforts to ensure that the instructions contained in the document areadequate and free of material errors and omissions. Nokia will, if necessary, explain issueswhich may not be covered by the document.

Nokia's liability for any errors in the document is limited to the documentary correction of errors.NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENTOR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARYLOSSES), that might arise from the use of this document or the information in it.

This document and the product it describes are considered protected by copyright according tothe applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

Other product names mentioned in this document may be trademarks of their respectivecompanies, and they are mentioned for identification purposes only.

Copyright © Nokia Corporation 2004. All rights reserved.

2 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 3: Dn03492199 4 en Global PDF Paper a4

Contents

Contents 3

1 Service provisioning 71.1 Introduction to service provisioning 71.1.1 Information required for service provisioning of ATM switched

connections 71.2 Provisioning DSL/ATM service 81.3 Disconnect service 101.4 Provisioning examples 111.4.1 Provisioning task list for ATM switched connections 121.4.2 POTS splitter 121.4.3 ADSL through a Gigabit Ethernet trunk 121.4.4 ADSL through an OC-3/STM-1 unit 151.4.5 ADSL through an OC-12/STM-4 trunk 171.4.6 SHDSL through an OC-3/STM-1 trunk 191.4.7 VDSL through an OC-12/STM-4 trunk unit 20

2 Interface provisioning 232.1 ADSL provisioning 232.1.1 ADSL profiles 242.1.2 Alarm thresholds profiles 252.1.3 ADSL operation modes 252.1.4 Rate modes 262.1.5 Port training mode 272.1.6 Port data mode 302.1.7 ATUR/ATUC channel parameter values 312.1.8 ADSL thresholds 322.1.9 Actuals 352.2 SHDSL provisioning 382.2.1 SHDSL profiles 392.2.2 Alarm thresholds profiles 392.2.3 SHDSL features 402.2.4 STUC and STUR terminology 412.2.5 SHDSL operational modes 412.2.6 Data mode 412.2.7 Rates tab 412.2.8 SHDSL tab 442.2.9 Thresholds tab 452.2.10 Transmission status actuals 482.2.11 Error actuals 502.3 VDSL provisioning 512.3.1 VDSL profiles 522.3.2 Alarm thresholds profiles 532.3.3 VDSL operation modes 532.3.4 Rate modes 542.3.5 Port training mode 552.3.6 Port data mode 572.3.7 VTU-R/VTU-O channel parameter values 58

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

3 (252)

Contents

Page 4: Dn03492199 4 en Global PDF Paper a4

2.3.8 Band plan management 592.3.9 VDSL thresholds 622.3.10 Actuals 642.4 OC-3/STM-1 and OC-12/STM-4 provisioning 672.4.1 OC-3/STM-1 and OC-12/STM-4 ATM interface specifications 682.4.2 OC-3/STM-1 and OC-12/STM-4 provisioning parameters 682.5 Gigabit Ethernet provisioning 752.5.1 Gigabit Ethernet interface specification 762.5.2 Interval sampling 762.5.3 Ethernet actuals and performance thresholds 772.6 DS3 provisioning 792.6.1 DS3 ATM interface specifications 802.6.2 Provisioning parameters 802.6.2.1 Framing and ATM mapping options 802.6.2.2 Scrambling option 812.6.2.3 HEC coset option 812.6.2.4 Equalisation option 812.6.2.5 Interface timing option 812.6.3 Counters and thresholds 812.7 E1 provisioning 852.7.1 IMA 862.7.2 E1 card applications 882.7.3 Provisioning parameters 882.7.4 Provisioning E1 parameters 882.7.5 E1 thresholds 882.7.6 Performance monitoring counters 902.7.7 ATM performance management 902.7.8 Provisioning IMA 912.7.9 IMA group actuals and performance statistics 932.7.10 IMA link actuals and performance statistics 96

3 Timing provisioning 1013.1 Timing settings 1013.1.1 Node timing 1013.1.2 Interface timing 1043.1.3 Recommended settings 1063.2 Connecting external timing 111

4 Packet-based provisioning 1154.1 Subinterface provisioning 1154.1.1 Routed subinterface 1154.1.1.1 Parameters of a routed interface 1164.1.1.2 One-to-one routed connection (PVC-VLAN) 1184.1.1.3 Routed subinterface isolation 1204.1.1.4 Routing table 1214.1.2 Routed bridge subinterface (RBE) 1214.1.2.1 Parameters of a RBE interface 1224.1.2.2 RBE interface operation 1234.1.2.3 RBE with loopback IP addressing 1264.1.2.4 PPPoE grooming with the RBE client subinterface 1284.1.2.5 Multicast (IGMP proxy) functionality with RBE as a client subinterface 129

4 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 5: Dn03492199 4 en Global PDF Paper a4

4.1.2.6 RBE subinterface isolation 1314.1.2.7 RBE with DHCP relay (Option 82) 1324.1.3 Bridged subinterface 1344.1.3.1 Parameters of a bridged interface 1344.1.3.2 Bridged one-to-one connection (PVC-VLAN) 1354.1.3.3 Bridge groups (PVCs-VLAN) 1364.1.3.4 PPPoE grooming with a bridged client subinterface 1384.1.3.5 Protocol filter 1394.1.3.6 Bridged subinterface priority 1404.1.3.7 MAC address table 1414.1.3.8 Managing the MAC address table 1424.1.3.9 Bridged subinterface with the DHCP relay (Option 82) 1444.1.3.10 Bridged connection with IGMP snooping 1444.1.3.11 Bridged connections with client side VLANs 1454.1.4 PPPoA subinterface 1454.1.5 L2TP 1464.1.5.1 PPPoE 1474.1.5.2 PPPoA 1484.1.5.3 Testing 1494.1.6 Subinterface profile definition 1504.1.7 In-Band management connection 1534.1.8 DHCP relay pools in the D500 1554.1.9 Connection type 1564.1.9.1 VLAN/non-VLAN connection 1564.1.9.2 ATM AAL5 encapsulation 1594.1.10 Subinterface protocol types 1614.1.10.1 PPP grooming 1614.1.10.2 Multicast 1624.2 Basic packet forwarding rules 1674.2.1 Downstream packets 1674.2.2 Upstream packets 168

5 ATM VC cross-connection provisioning 1715.1 ATM VC cross-connection provisioning 1715.1.1 A PVC connection 1725.1.2 DSL port parameters 1735.1.3 Provisioning with Craft Terminal 1735.1.4 Examples of cross-connections 1735.1.5 Provisioning parameters 1775.1.6 Quick connection creation 1795.1.7 Craft Terminal reference information 180

6 QoS provisioning 1816.1 D500 traffic management 1816.1.1 Best effort only mode for line cards 1856.2 IP CoS based on DiffServ 1866.2.1 IP CoS in different service modes 1876.2.1.1 Bridged subinterface 1876.2.1.2 Routed subinterface 1886.2.1.3 RBE subinterface 1896.2.2 CoS in the D500 189

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

5 (252)

Contents

Page 6: Dn03492199 4 en Global PDF Paper a4

6.2.2.1 EF 1896.2.2.2 AF 1906.2.2.3 DF 1916.3 Ethernet CoS based on VLAN user priorities 1926.3.1 High priority Ethernet CoS 1956.3.2 Medium priority Ethernet CoS 1966.3.3 Low priority Ethernet CoS 1976.4 QoS in ATM networks 1996.4.1 CBR 1996.4.2 VBR-rt 2006.4.3 VBR-nrt 2036.4.4 UBR 2046.5 Traffic descriptors 2066.5.1 Packet traffic descriptors and PTD policies 2086.5.2 ATM traffic descriptors 2126.5.2.1 Traffic profiles/traffic descriptors 2156.5.3 Port QoS features 217

7 Provisioning concepts and parameters 2197.1 Provisioning parameters 2197.1.1 DSL provisioning parameters 2197.1.2 QoS queue provisioning parameters 2267.1.3 OC-3/STM-1 provisioning parameters 2287.1.4 DS3 provisioning parameters 2307.1.5 E1 provisioning parameters 2327.1.6 ATM/Ethernet connection provisioning parameters 2357.1.7 VLAN provisioning parameters 2367.1.8 Gigabit Ethernet trunk provisioning parameters 2367.2 Policer limitations and granularity rates 2377.2.1 Limitations for an ATM policer 2377.2.2 Limitations for a packet policer 2397.2.3 Packet policer granularity rates 2407.2.4 ATM policer granularity rates 2407.3 ATM QoS concepts 2447.3.1 Multiple service categories 2447.3.2 ATM performance parameters 2457.3.3 CLP (Cell Loss Priority) 2477.3.4 ATM QoS scheduling 2487.3.5 Traffic policing 2497.3.6 Congestion control and avoidance 2517.3.7 Connection admission and control (CAC) 251

6 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 7: Dn03492199 4 en Global PDF Paper a4

1 Service provisioning

1.1 Introduction to service provisioning

The D500 is ready for provisioning when all initial commissioning procedureshave been completed. This procedure on ATM switched connections providesdetailed instructions on how to create a permanent virtual circuit (PVC) toconnect a subscriber to an ATM network service provider, and unlock the linecard port to provide service.

In addition to ATM switched connections, the D500 system also supports packet-based services, for instance bridging, routing, RBE, multicast, PPP grooming,and L2TP tunneling. In connection with packet-based services, an idea of asubinterface is introduced. A subinterface is a logical entity created as part of atrunk port or a line card port. There can be one or more subinterfaces associatedwith a port. Subinterfaces of a trunk port have different characteristics thansubinterfaces of a line card port.

For the packet-based service provisioning refer to Subinterface provisioning.

Note

The following procedures assume that a service order is used to record subscriberprovisioning information. A service order is an official form used bytelecommunication companies which specifies customer services for newconnections, changes, and disconnections.

1.1.1 Information required for service provisioning of ATM switchedconnections

To begin this task you will need the following information from the service order:

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

7 (252)

Service provisioning

Page 8: Dn03492199 4 en Global PDF Paper a4

. Line card and port

. Minimum and maximum data rates

. Subscriber�s VPI/VCI address of link A virtual connections

. Traffic descriptors for upstream (A->Z) and downstream (Z->A) direction

Note

For additional information on traffic descriptor types and profiles, refer to Trafficdescriptors.

. ATM network VPI/VCI interface addresses for link Z.

Note

Rates are not applicable to the tributary units.

There may be multiple PVCs defined for a single subscriber�s local loop.

1.2 Provisioning DSL/ATM service

Purpose

Follow these steps to provision a line card port, add a virtual connection, and tounlock the port to provide service as specified on the service order.

Before you start

The Admimistration State of the port must be Locked.

Steps

1. Right-click the line card object in the Subrack View. A pop-up menuappears. Select Port Views.

2. On the Ports tab page, double-click the port you want to provision tohave the Port Configuration dialog box.

8 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 9: Dn03492199 4 en Global PDF Paper a4

3. Click the Rates tab. Set the values for the parameters specified on theservice order:

. Data Rate Type (The default is Interleave Rate.)

- The Data Rate Type box does not exist on the Rates tab of theSHDSL Port Configuration dialog box.

. Interleave Rates for ADSL and VDSL ports, Data Rates for SHDSLports

. Thresholds

. RADSL Mode (The default is Startup.)

. Parameters for SHDSL ports

. Pair Bonding for SHDSL ports

. Band Configuration for the VDSL port .

Click Apply to commit the changes and keep the dialog box open.

4. Click the DSL Thresholds tab and do the following: Set the values forthe Failure Thresholds and Frame Thresholds as specified on theservice order. Click Apply.

5. Add a Virtual Connection. Click the Connections tab to get theconnection Information for the port.

6. Right-click on the tab page and select New Connection.

The New Connection dialog box is used to establish the permanent virtualcircuit (PVC) on the subscriber�s service order.

7. The line card name and port number are logical cue address mappingvalues for Virtual Link A (the subscriber�s side interface); the activetrunk/control unit name and port number in the D500 is the logical cueaddress for Virtual Link Z (the ATM network interface).

Enter manually or select (from the drop-down list boxes) the followinginformation from the subscriber�s service order:

. VPI/VCI for Link A, for example: 0, 38

. VPI/VCI for Link Z, for example: 10, 71

. Traffic descriptors for the upstream and downstream direction.

8. Click OK.

A Connection ID number is assigned and the Port Configuration dialogbox displays the information for the connection.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

9 (252)

Service provisioning

Page 10: Dn03492199 4 en Global PDF Paper a4

9. Repeat Steps 2 through 8 for each ATM virtual connection specified onthe service order for this line card port.

10. Unlock the line card port. The connection is not activated until theport is unlocked. To unlock the port, click the Status tab page andselect Unlocked for the Administration State.

You can do the same operation in the following way as well: In theSubrack View, click the port icon of the line card to have the port-selectionpane. Right-click the port number to obtain a pop-up menu and chooseView Properties. In the Working Area of the GUI, the Status tab page ofthe port appears. Select Unlocked for the Administration State. Click OK.

Further information

Do not unlock the port until the subscriber�s end user equipment has beeninstalled and is ready for service. An alarm condition is generated when theline card port is unlocked before the end user equipment has been installed.

11. To save the changes to the MIB, select Node => Save.

1.3 Disconnect service

Purpose

Follow these steps using Web-based Craft Terminal to disconnect a subscriberservice by deleting the PVC connection from the D500 GUI:

Before you start

There may be multiple PVCs defined for a single subscriber�s loop. A disconnectorder may delete one, some, or all of the PVCs defined for that loop.

Steps

1. In the Web-based Craft Terminal GUI, right-click the line card listedin the Subrack View.

A pop-up menu appears. Select Port Views.

2. The list of ports on that unit is seen in the Working Area. In that list,double-click the port you want to work on.

3. In the Port Configuration dialog box, select the Connections tab to getthe connection information for the port.

10 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 11: Dn03492199 4 en Global PDF Paper a4

4. Right-click the PVC specified on the change order. Click DeleteConnection.

The connection disappears from the tab page.

5. Repeat Step 4 to delete additional PVCs on the port as indicated on thechange order.

6. Lock the port (only if you have deleted all connections on that port).

. If the Port Configuration dialog box is already open, as is the case inthe above step, click the Status tab.

. Click Locked in the Administration Sate box.

. Click OK or Apply.

If the Port Configuration dialog box is not open:

. Click the port icon in the Subrack View. A port-selection pane withport numbers appears.

. Right-click the port you want to lock. Click View Properties.

. On the Status tab, click Locked in the Administration State box.

. Click OK.

1.4 Provisioning examples

This chapter provides examples of some typical provisioning profiles used bynetwork operators. The examples include sets of parameters for the followingservices:

1. ADSL through a Gigabit Ethernet trunk

. Bridged connection

. RBE connection

2. ADSL through an OC-3/STM-1tributary unit (as a trunk)

3. ADSL through an OC-12/STM-4 trunk:

. application for SOHO users

. application for home users

4. SHDSL through an OC-12/STM-4 trunk

. SOHO users (bronze, silver, gold)

5. VDSL through an OC-12/STM-4 trunk

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

11 (252)

Service provisioning

Page 12: Dn03492199 4 en Global PDF Paper a4

. symmetrical band plan (SOHO users)

. asymmetrical band plan (home users).

Provisioning values that differ from the default values are indicated with boldtypeface in the service-specific tables. The topology of a connection is notprovisionable; it is always duplex.

1.4.1 Provisioning task list for ATM switched connections

1. Check that there are traffic descriptors for upstream and downstreamdirection, which are suitable for the service you are provisioning.

2. Select an xDSL port that matches the service.

3. Set the xDSL parameters for the port according to the service chosen.

4. Make a virtual channel cross-connection from the DSL port to the correctaggregate port.

For a more detailed provisioning procedure, refer to Provisioning DSL/ATMservice.

1.4.2 POTS splitter

The POTS splitter is mentioned frequently in the following provisioningexamples. The 17-slot or 4-slot LPFS (low pass filter shelf) is a POTS splitter.

A 4-slot LPFS can be used with a D500 RAM (Remote Access Module).

1.4.3 ADSL through a Gigabit Ethernet trunk

The following figure shows an example of ADSL service through a GigabitEthernet (GE) trunk. The tables list parameters for 1024k/512k ADSL servicethrough a GE trunk.

12 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 13: Dn03492199 4 en Global PDF Paper a4

Figure 1. ADSL service through a GE trunk with a routed/RBE/bridgedconnection

Table 1. DSL parameters, ADSL through a GE trunk

Rate ATU-C ATU-R

Fast max (kbit/s) 1024 512

Fast min (kbit/s) 1024 512

Mode Startup (rateadaptive)

Table 2. One-to-one routed connection

Client subinterface Trunk subinterface

Name OneToOne1 TrunkOne1

Unit 3 11

Internet

Internet Service Provider

IPNetwork

D500

POTSNetwork

POTSSplitter

ADSLGigabitEthernet

ADSL

SOHO or Residential User

CPE(Bridge)

+POTSSplitter

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

13 (252)

Service provisioning

Page 14: Dn03492199 4 en Global PDF Paper a4

Table 2. One-to-one routed connection (cont.)

Client subinterface Trunk subinterface

Port 14 1

Client subinterface profile - -

Connection type Routed Routed

Encapsulation type LLC -

VPI 0 -

VCI 100 -

VLAN ID 20 20

Local IP address 10.1.1.1 20.1.1.1

Local IP mask 255.255.255.0 255.255.255.0

Table 3. Client RBE and trunk routed connection

Client subinterface Trunk subinterface

Name Client2 Trunk2

Unit 3 11

Port 13 1

Client subinterface profile - -

Connection type Routed bridged Routed

Encapsulation type LLC -

VPI 0 -

VCI 100 -

VLAN ID 10 10

Local IP address - 30.1.1.1

Local IP mask - 255.255.255.0

14 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 15: Dn03492199 4 en Global PDF Paper a4

Table 4. Client bridged and trunk bridged connection

Client subinterface Trunk subinterface

Name Client1 Trunk1

Unit 3 11

Port 12 1

Client subinterface profile - -

Connection type Bridged Bridged

Encapsulation type LLC -

VPI 0 -

VCI 100 -

VLAN ID 0 0

1.4.4 ADSL through an OC-3/STM-1 unit

The following figure shows an example of ADSL service through an OC-3/STM-1 tributary unit as a trunk. The tables list parameters for ADSL service through anOC-3/STM-1 tributary unit as a trunk.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

15 (252)

Service provisioning

Page 16: Dn03492199 4 en Global PDF Paper a4

Figure 2. ADSL service through an OC-3/STM-1 unit

. Parameters for 256k/128k ADSL service, interleaved rates, rate adaptive

Table 5. DSL parameters, ADSL through an OC-3/STM-1 tributary unit

Rate ATU-C ATU-R

Interleave max (kbit/s) 256 128

Interleave min (kbit/s) 32 32

Mode Startup (rate adaptive)

Table 6. ATM parameters, ADSL through an OC-3STM-1 tributary unit

Slot Port VPI VCI Trafficdescriptor

Admin state

Link A 3 1 0 100 9 Unlocked

Internet

Internet Service Provider

ATMNetwork

D500

SOHO or Residential User

CPE

+POTSSplitter

POTSNetwork

POTSSplitter

ADSLOC-3/STM-1

16 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 17: Dn03492199 4 en Global PDF Paper a4

Table 6. ATM parameters, ADSL through an OC-3STM-1 tributary unit(cont.)

Slot Port VPI VCI Trafficdescriptor

Admin state

Link Z 5 1-4 15 400 9

1.4.5 ADSL through an OC-12/STM-4 trunk

The following figure shows an example of ADSL services through an OC-3/STM-1 trunk. The tables list parameters for ADSL service through an OC-12/STM-4 trunk.

Figure 3. ADSL service for SOHO and residential users

a) Parameters for a SOHO application: 512k/512k, 512 kbit/s symmetricalservice, fixed rates.

Internet

Internet Service Provider

ATMNetwork

D500

SOHO or Residential User

CPE

+POTSSplitter

POTSNetwork

POTSSplitter

ADSLOC-12/STM-4

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

17 (252)

Service provisioning

Page 18: Dn03492199 4 en Global PDF Paper a4

Table 7. DSL parameters, ADSL SOHO service through an OC-12/STM-4trunk

Rate ATU-C ATU-R

Interleave max (kbit/s) 512 512

Interleave min (kbit/s) 512 512

Mode None (fixed)

Table 8. ATM parameters, ADSL SOHO service through an OC-12/STM-4 trunk

Slot Port VPI VCI Trafficdescriptor

Admin state

Link A 1 1 0 100 9 Unlocked

Link Z 11 1 15 360 9 -

b) Parameters for a home user application: 256k profile, 256 kbit/s downstream,128 kbpit/s upstream, rate adaptive.

Table 9. DSL parameters, ADSL home user service via an OC-12/STM-4trunk

Rate ATU-C ATU-R

Interleave max (kbit/s) 256 128

Interleave min (kbit/s) 32 32

Mode Startup (rate adaptive)

18 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 19: Dn03492199 4 en Global PDF Paper a4

Table 10. ATM parameters, ADSL home user service via an OC-12/STM-4 trunk

Slot Port VPI VCI Trafficdescriptor

Admin state

Link A 2 1 0 100 9 Unlocked

Link Z 11 1 15 380 9 -

1.4.6 SHDSL through an OC-3/STM-1 trunk

The following figure shows an example of SHDSL service through an OC-3/STM-1 trunk. The tables list parameters for 512k/512k SHDSL service an OC-3/STM-1 trunk.

Figure 4. SHDSL service for small and medium size enterprises

Internet

Internet Service Provider

POTSNetwork

Corporate LAN

IP/ATMNetwork

Inter-Exchange Carrier

Enterprise

Users

AnalogVoice

IAD

PBX

PCM

D500

OC-3/STM-1SHDSL

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

19 (252)

Service provisioning

Page 20: Dn03492199 4 en Global PDF Paper a4

. Parameters for 512k/512k SHDSL service through an OC-3/STM-1 trunk

Table 11. DSL parameters, SHDSL through an OC-3/STM-1 trunk

Rate STUC

Max (kbit/s) 512

Min (kbpit/s) 512

Mode None (fixed)

Table 12. ATM parameters, SHDSL through an OC-3/STM-1 trunk

Slot Port VPI VCI Trafficdescriptor

Admin state

Link A 3 1 0 100 9 Unlocked

Link Z 11 1 15 400 9 Unlocked

1.4.7 VDSL through an OC-12/STM-4 trunk unit

The following figure shows an example of VDSL services through an OC-12/STM-4 trunk. The table lists parameters for VDSL service through an OC-12/STM-4 trunk.

20 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 21: Dn03492199 4 en Global PDF Paper a4

Figure 5. VDSL service for SOHO and residential users

Table 13. DSL parameters, VDSL SOHO service through an OC-12/STM-4 trunk

Rate: Fast orInterleave

Band plan

997_2B 997_3B 998_2B 998_3B

Minimum upstream(kbit/s)

64 64 64 64

Maximum upstream(kbit/s)

10048 25024 3008 10048

Minimum downstream(kbit/s)

64 64 64 64

Maximumdownstream (kbit/s)

10048 25024 22016 45056

Mode RADSL

Internet

Internet Service Provider

IP/ATMNetwork

D500

POTSNetwork

POTSSplitter

VDSLOC-12/STM-4

VDSL

SOHO or Residential User

CPE

+POTSSplitter

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

21 (252)

Service provisioning

Page 22: Dn03492199 4 en Global PDF Paper a4

22 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 23: Dn03492199 4 en Global PDF Paper a4

2 Interface provisioning

2.1 ADSL provisioning

The following describes ADSL provisioning parameters and the operation of theD500 ADSL line cards.

Note

D500 ADSL line cards include the following code suffixes for identification: aindicates that the card is Annex A compliant, b indicates that the card is Annex Bcompliant, f indicates that this line card has front mounting cable or loopterminations, r indicates the card has rear mounting cable or loop terminations,and t indicates that the card is using the TI chipset.

Note

Additional provisioning information can be located in Provisioning parameters.

The ADSL line card provides 48 RADSL (Rate Adaptive Digital SubscriberLine) lines using Discrete Multi-Tone (DMT) modulation technique. The cardsupports �full-rate� (G.DMT/ANSI) ADSL and is provisionable on an individualport basis. Key differences between G.DMT/ANSI, ADSL2, ADSL2+, andREADSL2 are shown in the table below:

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

23 (252)

Interface provisioning

Page 24: Dn03492199 4 en Global PDF Paper a4

Table 14. Mode differences

G.DMT/ANSI ADSL2 ADSL2+ READSL2

Frequency spectrumused

25 kHz to 1104kHz

25 kHz to 1104kHz

25 kHz to 2208kHz

25 kHz to 552kHz

Number of the highestbin used

255 255 511 127

2.1.1 ADSL profiles

It is possible to create line profiles that can be applied to ADSL ports of the sametype. The New DSL Line Profile dialog box is found by selecting Node Viewsand clicking the node icon => Profiles tab => DSL Line Profiles tab =>Configure menu => New Line Profile command.

In the New DSL Line Profile dialog box, select the correct card type and namethe profile. Define the following parameters for the profile: the ATUC and ATURvalues for the Fast Rate/Interleave Rate, RADSL mode, and noise margins. Youcan also import the parameters of another port or profile to the new profile byselecting Port or Profile from the drop-down menu in the Import box andclicking Load. If you want to have the default values, select Defaults from thedrop-down menu.

When you have created new profiles, you can assign more ports to them in thefollowing way: Select the profile on the DSL Line Profile tab => Configure =>Modify Line Profile => Associations. If you want to assign several ports for theprofile, keep the shift key down when you click the ports.

If the line profile is modified, all the ports assigned to the line profile start usingthe new parameters.

You can select a profile for a port also on a port level: Click the Port Views icon=> line card => port => Configure menu => Modify Port command => Ratestab and select the desired profile from the drop-down menu.

24 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 25: Dn03492199 4 en Global PDF Paper a4

2.1.2 Alarm thresholds profiles

It is possible to create DSL alarm thresholds profiles that can be applied to ADSLports of the same type. The New DSL Alarm Thresholds Profile dialog box isfound by selecting Node Views and clicking the node icon => Profiles tab =>DSL Alarm Thresholds Profiles tab => Configure menu => New AlarmProfile command.

In the New DSL Alarm Thresholds Profile dialog box, name the alarm thresholdsprofile and define the failure thresholds and frame thresholds. You can alsoimport the parameters of another port or profile to the new profile by selectingPort or Profile from the drop-down menu in the Import box and clicking Load.If you want to have the default values, select Defaults from the drop-down menu.

When you have created alarm profiles, you can assign more ports to them in thefollowing way: Select the profile on the DSL Alarm Thresholds Profile tab =>Configure => Modify Alarm Profile => Associations. If you want to assignseveral ports for the profile, keep the shift key down when you click the ports.

If the alarm thresholds profile is modified, all the ports assigned to the line profilestart using the new parameters.

You can select a profile for a port also on a port level: Click the Port Views icon=> line card => port => Configure menu => Modify Port command =>Thresholds tab and select the desired profile from the drop-down menu.

2.1.3 ADSL operation modes

In order to establish communications with the CPE, DMT-based ADSL mustundergo a training sequence at the line card port. ADSL ports have three basicoperational modes:

. Idle mode

- The ADSL port transmitter and receiver are �locked� and disabled.

. Training mode

- The ADSL port transmitter and receiver are �unlocked.� The ADSLport is attempting to establish a connection with CPE equipmentduring the training mode. Training time is approximately 20seconds.

. Data mode

- The ADSL port connection is established and opened fortransmission of ATM data traffic

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

25 (252)

Interface provisioning

Page 26: Dn03492199 4 en Global PDF Paper a4

The signal quality of the ATUR *) and ATUC channels are determined early inthe training process. This is one of the first and most critical steps in theestablishment of an ADSL data connection because it determines the data ratesthat can be supported on a given local loop facility. After the channels areestablished, their quality, combined with other provisioned settings, determinesthe actual data rate delivered.

*) The terms ADSL Transceiver Unit � Central Office (ATUC) and ADSLTransceiver Unit � Remote (ATUR) are used in DMT ADSL provisioning todescribe the DSL port hardware required at both the Central Office and remote(CPE) ends of the local loop.

2.1.4 Rate modes

Latency path selection

Fast Rate is designed to correct random errors rather than bursts of errors. IfInterleave Rate is used, Reed-Solomon can also correct error bursts.

The default mode is Interleave Rate. This is because the Interleave modeprovides a more robust and reliable service. However, Fast Rate mode may bepreferable for latency sensitive applications.

Interleave and Fast Rates

Table 15. Parameters for Interleave and Fast Rates

Line cards ATUR ATUC

Range Defaultfor themax.setting

Defaultfor themin.setting

Range Defaultfor themax.setting

Defaultfor themin.setting

ADSL48af,ADSL48bf

32�1024kbit/s

1024 32 32�8128kbit/s

8128 32

ADSL48aft,ADSL48art

32�1024kbit/s

1024 32 32�10816kbit/s

8128 32

ADSL2+af,ADSL2+bf

32�1088kbit/s

1088 32 32 kbit/s�32,736Mbit/s

32,736 32

26 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 27: Dn03492199 4 en Global PDF Paper a4

Rate Degraded threshold

If the actual rate is less than or equal to this threshold, a Rate Degraded conditionis reported. The default setting is 0 (disabled).

LPort Tx Rate

The default value of the LPort Tx Rate is the downstream capacity of a carddivided by the number of the ports. For example the default value of the LPort TxRate for the ADSL2+af card is 500 Mbit/s : 48 = 10,416 Mbit/s. The value of theLport should equal or be less than the ADSL downstream speed so that QoSwould function properly. The Lport configuration can be disabled with the BestEffort mode (CLI command: conf unit <slot> qos disable).

2.1.5 Port training mode

For each ADSL port, the port can be set to adapt to the line conditions at startup,or set to a fixed line rate. The ADSL port supports two configurable settings forthe ATUC and ATUR channels:

. None

- Fixed rate training

. Startup

- Rate Adaptive DSL (RADSL).

Startup (RADSL training)

Startup is the default setting. During the training process, the port measures thequality of the line (taking into account the Noise Margin provisioned for the port)and determines the best RADSL upstream and downstream transmit rates that theline can support. The Max (kbit/s) and Min (kbit/s) settings determine the rangefrom which to obtain the best transmit rate (see the figure below).

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

27 (252)

Interface provisioning

Page 28: Dn03492199 4 en Global PDF Paper a4

Figure 6. Transmit rates

A Rate Degraded condition is displayed by Craft Terminal if the actual transmitrate is below the provisioned Rate Degraded threshold.

None (fixed rate training)

The ADSL port trains to the maximum rates provisioned for either the Fast Rateor Interleave Rate ATUR and ATUC channels, depending on which rate mode isin use.

The port has an LOS (Loss of Signal) condition until training at the fixed rate issuccessful.

Target Noise Margin

This parameter sets the margin (in dB) for both ATUR and ATUC used duringRADSL and fixed rate training processes. The Target Noise Margin parameterestablishes the amount that noise can increase on the line for the channel tooperate at 10�7 BER (Bit Error Rate). A larger margin lowers the rate, butincreases the line�s immunity to noise.

. The ADSL port trains to the maximum data rate supportable on the line,while operating within the provisioned Target Noise Margin. Any excesschannel capacity is used to increase the margin if the port can train to themaximum rate; in this case the actual margin is higher than the provisionedmargin.

. Target Noise Margin parameters are provisionable for both ATUR andATUC. The range is from 0 dB to 15 dB; the default is 6 dB.

28 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 29: Dn03492199 4 en Global PDF Paper a4

ATUC Operation Mode

This parameter allows the user to set the operational standard for the port. ForADSL48af and ADSL48bf the options are Auto (default), Advanced Auto, G.DMT, and ANSI. For ADSL48aft and ADSL48art the options are Auto (default),G.DMT, and ANSI. For ADSL2+af and ADSL2+bf the options are Auto(default), ADSL2+, READSL, ADSL2, ADSL, G.DMT, and ANSI.

When the Auto mode is selected, the system trains to the mode supported by theCPE modem. Refer to the Actuals tab after training is complete to see the actualOperation Mode selected.

In the Advanced Auto mode, the port first starts training using the Auto as anoperation mode. If training does not succeed within 90 seconds, training isrestarted using the ANSI operation mode. If training does not succeed within 90seconds in the ANSI mode either, the operation mode is changed to gDMT. Iftraining does not succeed in the gDMT mode within 90 seconds, training isrestarted using the Auto mode again. This sequence is repeated until the line is upand running. This mode is designed to be used only with CPEs, which are notable to do proper handshaking.

The Auto mode is the recommended mode of operation. When the Auto mode isselected on ADSL2+af or ADSL2+bf, the ATUC connects automatically in theADSL2+, READSL2, ADSL2 or ADSL mode, depending on the loop and ATURcapability. When the Auto mode is selected on ADSL48af, ADSL48bf,ADSL48aft, or ADSL48art, the ATUC connects in the ADSL mode.

When the ADSL2+ mode is selected, the ATUC connects automatically in theADSL2+, ADSL2 or ADSL mode, depending on the ATUR capability. Thismode can be used to prevent the ATUC from connecting in the READSL2 mode.

When the READSL2 mode is selected, the ATUC connects automatically in theREADSL2, ADSL2, or ADSL mode, depending on the ATUR capability. Thismode can be used to force the line into the READSL2 mode if the ATURsupports it. If the ATUR does not support READSL2, then the ADSL2 or ADSLmode will be used.

When the the ADSL2 mode is selected, the ATUC connects automatically in theADSL2 or ADSL mode, depending on the ATUR capability. This mode can beused when connecting in neither ADSL2+ nor READSL mode is desirable.

When the ADSL mode is selected, the ATUC connects in the ADSL mode.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

29 (252)

Interface provisioning

Page 30: Dn03492199 4 en Global PDF Paper a4

Note

In the ADSL mode the connection can be in either T1.413 (ANSI) or G.DMTmode, depending on what the ATUR supports.

2.1.6 Port data mode

The ADSL port enters the data mode when the training process has finished.During the data mode the ADSL port provides actual measurements that resultfrom the training process.

The following ADSL parameters, except Error Alarms, affect port operationduring the data mode:

ATUC and ATUR Interleave Delay

This parameter allows the user to increase or decrease the delay (latency) at boththe ATUC and ATUR channels. By adjusting latency in the loop, you increase ordecrease the immunity to impulse noise. In general, the lower settings are used forlatency-sensitive voice transmissions, and the higher settings are for data. Thisapplies to the Interleave Rate operation only.

The maximum value of the delay can be set for both ATUC and ATUR. Thesetting options are 1 ms, 2 ms, 4 ms, 8 ms, 16 ms, 32 ms and 64 ms; the defaultsetting is 32 ms for the ATUC and 16 ms for the ATUR.

If the provisioned setting cannot be attained, the parameter is rounded down tothe nearest available setting.

FEC (RS Correction)

This parameter enables or disables downstream forward error correction (FEC).The default setting is Enable. The default setting for RS Correction timing is 2 msfor the ATUC and 1 ms for the ATUR.

Automatic Coding Gain (Enable/Disable)

Coding Gain is the gain due to Reed-Solomon coding, interleaving and TrellisCoding. Automatic coding is normally enabled for automatic bit allocation. WhenAutomatic Coding Gain is disabled, the gain can be set manually. The range is 0to 7 dB in 1 dB increments.

30 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 31: Dn03492199 4 en Global PDF Paper a4

Trellis Coding

This parameter enables Trellis Coding, a method of forward error correctionwhich combines convolutional coding and modulation. This allows the user tomeet performance margin requirements for long loops, or increase thetransmission throughput under a specified performance margin. It providesincreased gain against background and crosstalk noise. Set to Enable or Disable.The default setting is Enable.

Note

Trellis Coding should only be disabled for test purposes. If Trellis Coding isdisabled, performance may significantly decrease.

Transmit Power Reduction

This ATUC parameter sets the amount to reduce the transmitted power (dB)below the maximum allowed transmit power. The default setting is 0 dB.

Error Retrain Threshold

This ATUC parameter sets the number of near end �errored frames� per secondallowed during the data mode before the ADSL port retrains. The range is 1 to 60seconds, and the default is 10; the inactive setting is 0.

Error Alarm

This ATUC parameter sets the number of near-end errored frames per secondallowed during the Data mode before an event (alarm) is sent to ElementManager.

Bit Swap

Bit swapping enables the change of the number of bits assigned to a subcarrier(Bin) without interrupting data flow.

2.1.7 ATUR/ATUC channel parameter values

The following tables provide the ATUR and ATUC channel provisioningparameters.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

31 (252)

Interface provisioning

Page 32: Dn03492199 4 en Global PDF Paper a4

Table 16. ATUR provisioning parameters

Parameter Values Units Defaults

Maximum Rate *) 32�1024

32�1088

kbit/s 1024

1088

Minimum Rate *) 32�1024

32�1088

kbit/s 32

Target Noise Margin 0�15 dB 6

Interleave Delay 1�64 ms 16

*) ATUR Maximum and Minimum Rate values are set in multiples of 32 kbit/s.

Table 17. ATUC provisioning parameters

Parameter Values Units Defaults

Maximum Interleave Rate *) 32�8128

32 kbit/s�32,736Mbit/s

kbit/s

Mbit/s

8128

32,736

Minimum Interleave Rate *) 32�8128

32 kbit/s�32,736Mbit/s

kbit/s

Mbit/s

32

Target Noise Margin 0�15 dB 6

Interleave Delay 1�64 ms 32

Error Retrain Threshold 1�60 Errors/Sec 10

*) ATUC Maximum and Minimum Rate values are set in multiples of 32 kbit/s.

2.1.8 ADSL thresholds

The default setting for the following thresholds is 0 (zero) or inactive, exceptwhere noted. Daily and 15-minute thresholds can be set for the ATUC unit.

32 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 33: Dn03492199 4 en Global PDF Paper a4

LOF Seconds thresholds

The Loss of Frame condition is monitored during the data mode. The LOFSeconds threshold settings are the number of seconds during which an LOFcondition was present. An event is reported to Craft Terminal when the LOFSeconds threshold is crossed.

LOS Seconds thresholds

The Loss of Signal condition is monitored during the data mode. The LOSSeconds threshold settings are the number of seconds during which an LOScondition was present. An event is reported to Craft Terminal when the LOSSeconds threshold is crossed.

LPR Seconds thresholds

The Loss of Power condition is monitored during the data mode. The LPRSeconds threshold is set to monitor power shutdown signals at the ATUR

Note

The LOF, LOS and LPR conditions are mutually exclusive, and are reported inthe following priority:

. If all three conditions are present, LPR is reported.

. If LOS and LOF are present, LOS is reported.

. LOF is reported when it is the only condition.

LCD Seconds thresholds

The Loss of Cell Delineation condition is monitored during the data mode. TheLCD Seconds threshold settings are the number of seconds during which an LCDcondition was present. An event is reported to Craft Terminal when the LCDSeconds threshold is crossed.

LOF Retrains

LOF Retrains is the number of times a port has retrained due to LOF. An event isreported to Craft Terminal when the LOF Retrains threshold is crossed.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

33 (252)

Interface provisioning

Page 34: Dn03492199 4 en Global PDF Paper a4

Error Rate Retrains

Error Rate Retrains is the number of times a port has retrained due to excessiveNear End errored frames. Coding Violation conditions include CRC (CyclicRedundancy Check) errors. Error Rate Retrains are monitored during alloperational modes. An event is reported to Craft Terminal when the Error RateRetrains threshold is crossed.

FE Error Rate Retrains

FE Error Rate Retrains is the number of times a port has retrained due toexcessive Far End (FE) errored frames. Coding Violation conditions include CRC(Cyclic Redundancy Check) errors. FE Error Rate Retrains are monitored duringall operational modes. An event is reported to Craft Terminal when the FE ErrorRate Retrains threshold is crossed.

Errored Seconds thresholds

(Near End) Errored Seconds are the cumulative number of seconds the port is inan LOF, LOS, LPR, LCD, or a Coding Violation condition. Coding Violationconditions include CRC (Cyclic Redundancy Check) errors. Errored Seconds aremonitored during all operational modes. An event is reported to Craft Terminalwhen the Errored Seconds threshold is crossed.

Table 18. LOS, LOF, LPR, LCD and Errored Seconds parameters

Parameter 15-minutevalues

Daily values Units Defaults

Loss of Frame (LOF) 1�900 1�86400 Seconds 0

Loss of Signal (LOS) 1�900 1�86400 Seconds 0

Loss of Power (LPR) 1�900 1�86400 Seconds 0

Loss of CellDelineation (LCD)

1�900 1�86400 Seconds 0

NE and FE ErroredSeconds Threshold

1�900 1�86400 Seconds 0

Coding Violation thresholds

Near End Coding Violation errors are a count of the Cyclic Redundancy Check(CRC) errored frames received for the ATUC unit during the data mode. TheCoding Violation parameters have thresholds for reporting an event to CraftTerminal.

34 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 35: Dn03492199 4 en Global PDF Paper a4

The following table provides the expected number of ATUC Coding Violation(CRC) errors. They can be used as threshold settings.

Note

The number of expected Coding Violation errors varies based on the data rate.The values in the following table provide guidelines to help establish thresholds.

Table 19. ATUC Coding Violation threshold settings

Parameters Threshold settings based on data rates Sensitivity toCV errors

Upstream datarate

32000 64000 320000 640000

Daily settings 270000 530000 2200000 3500000 Low

28000 55000 270000 530000 Medium Low

2800 5600 28000 55000 Medium

280 560 2800 5600 Medium High

28 56 280 560 High

15-minutesettings

2800 5500 23000 36000 Low

290 580 2800 5500 Medium Low

29 58 290 580 Medium

3 6 29 58 Medium High

0 1 3 6 High

2.1.9 Actuals

The ADSL port can measure channel quality established over the existingtelephone copper network (the local loop). The ADSL port reports actuals sincethe card or the counter was reset or for the following operational parameters:

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

35 (252)

Interface provisioning

Page 36: Dn03492199 4 en Global PDF Paper a4

Noise Margin: Actual amount of noise margin measured on the ATUR andATUC channels. The range is -64.0 dB to +63.5 dB, measured in increments of .5dB.

Loop Attenuation: Decrease in power of the signal received from the far endover the loop. The range is 0 dB to +63.5 dB, measured increments of .5 dB.

Transmit Power: Actual power being transmitted on the channel, measured indBm.

Transmit Rate: Actual ATUR and ATUC data rate for the channel; this rate iseither fixed or determined by the ADSL port during the training process. SeeStartup (RADSL training for more information on the RADSL training process.

Previous Transmit Rate: Recorded upon termination of a successful datatransport session; reports the rate according to whether the line is trained or nottrained:

. Not Trained � the rate achieved by the most recent successful training

. Trained � the rate achieved by the most recent successful link-up prior tothe current link-up.

Best Transmit Rate: Highest rate the port has linked up at successfully. If it isless than the Transmit Rate after training, the port copies in the Transmit Ratevalue.

Payload Transmit Rate: Actual ATUR and ATUC payload rate for the channel,calculated by subtracting the ATM cell overhead from the Transmit Rate.

Maximum Achievable Rate:Maximum transmit rate that is possible on the line.It may be greater than the maximum provisioned rate, or equal to the maximumprovisioned rate if the line is not limited.

Best Maximum Achievable Rate: Highest rate supportable by the loop. If it isless than the Maximum Achievable Transmit Rate after training, the port copiesin the Maximum Achievable Transmit Rate value.

Cells Received: Number of valid, non-idle cells �received� on the line card portfrom the CPE since the card was reset.

Cells Transmitted: Number of valid, non-idle cells received from the line cardand �transmitted� to the CPE since the card was reset.

Operational Mode: Actual operation mode. Refer to ATUC Operation Mode.

R (bytes per RS codeword): Number of R (redundancy) bytes per RS codeword.

36 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 37: Dn03492199 4 en Global PDF Paper a4

Interleave Depth: Interleave Depth value achieved.

Coding Gain: Coding gain value achieved.

S (symbols/codeword): Number of DMT symbols per RS codeword.

Vendor ID: Vendor identification number of the CPE at the far-end of the loop.

Vendor Version: Version number of the CPE at the far-end of the loop.

Serial Number: Serial number of the CO/CPE reported.

LOF Failures: Loss of Frame errors.

LOS Failures: Loss of Signal errors. An LOS condition takes precedence over anLOF condition

LPR Failures: Loss of Power errors.

LCD Failures: Loss of Cell Delineation errors.

LOF Seconds: Total number of seconds during which the port detects an LOFScondition.

LOS Seconds: Total number of seconds during which the port detects an LOScondition.

LPR Seconds: Total number of seconds during which the port detects an LPRcondition.

LCD Seconds: Total number of seconds during which the port detects an LCDcondition.

Errored Seconds: Total number of seconds the near-end detected frame CRCerrors.

Coding Violations: Coding violations detected by the near-end.

FE Errored Seconds: Total number of seconds the far-end detected frame CRCerrors

FE Coding Violations: Coding violations detected by the far-end.

HEC Errors: Total number of received cells that have Header Error Control(HEC) errors detected in their header.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

37 (252)

Interface provisioning

Page 38: Dn03492199 4 en Global PDF Paper a4

FE HEC Errors: Far-end HEC errors on this DSL port.

LOF Retrains: Retrains on the DSL port triggered by LOF errors.

Training Starts: Total number of times a port has detected the CPE, andattempted to train up with the CPE.

Corrected Errors: Total number of corrected Forward Error Correction (FEC)errors.

FE Corrected Errors: Far-end error corrections.

Bad Provisioning Status: This parameter provides a short description of theprovisioning error. In the case of multiple errors, only one error appears;additional errors appear as each preceding error is cleared.

Elapsed Time (Current 15 minutes): Total amount of time in the current 15-minute performance monitoring interval.

Elapsed Time (Current 24 hours): Total amount of time in the current 24-hourperformance monitoring interval.

Elapsed Time (Previous day): Total amount of time in the performancemonitoring interval of the preceding day.

Error Retrains: Number of ADSL port retrains (based on near-end �erroredframes� per second allowed during the data mode).

FE Error Retrains: Number of ADSL port retrains (based on far-end �erroredframes� per second allowed during the data mode).

2.2 SHDSL provisioning

This document describes the provisioning parameters and operation of the D500SHDSL24 (Single-pair High-speed Digital Subscriber Line) line card. Details areprovided on how the SHDSL24 port establishes its data rate during the �training�operational mode.

The SHDSL24 line cards support 24 ports of symmetric bit rate transmissionusing multi-level Trellis Coded Pulse Amplitude Modulation (TC-PAM) lineencoding.

Note

38 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 39: Dn03492199 4 en Global PDF Paper a4

Additional provisioning information is available in Provisioning parameters.

2.2.1 SHDSL profiles

It is possible to create line profiles that can be applied to SHDSL ports of thesame type. The New DSL Line Profile dialog box is found by selecting NodeViews and clicking the node icon => Profiles tab => DSL Line Profiles tab =>Configure menu => New Line Profile command.

In the New DSL Line Profile dialog box, select the correct card type and namethe profile. Define the following parameters for the profile: the STUC data rates,RADSL mode, and noise margins. You can also import the parameters of anotherport or profile to the new profile by selecting Port or Profile from the drop-downmenu in the Import box and clicking Load. If you want to have the defaultvalues, select Defaults from the drop-down menu.

When you have created new profiles, you can assign more ports to them in thefollowing way: Select the profile on the DSL Line Profile tab => Configure =>Modify Line Profile => Associations. If you want to assign several ports for theprofile, keep the shift key down when you click the ports.

If the line profile is modified, all the ports assigned to the line profile start usingthe new parameters.

You can select a profile for a port also on a port level: Click the Port Views icon=> line card => port => Configure menu => Modify Port command => Ratestab and select the desired profile from the drop-down menu.

2.2.2 Alarm thresholds profiles

It is possible to create DSL alarm thresholds profiles that can be applied toSHDSL ports of the same type. The New DSL Alarm Thresholds Profile dialogbox is found by selecting Node Views and clicking the node icon => Profiles tab=> DSL Alarm Thresholds Profiles tab => Configure menu => New AlarmProfile command.

In the New DSL Alarm Thresholds Profile dialog box, name the alarm thresholdsprofile and define the failure thresholds and frame thresholds. You can alsoimport the parameters of another port or profile to the new profile by selectingPort or Profile from the drop-down menu in the Import box and clicking Load.If you want to have the default values, select Defaults from the drop-down menu.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

39 (252)

Interface provisioning

Page 40: Dn03492199 4 en Global PDF Paper a4

When you have created alarm profiles, you can assign more ports to them in thefollowing way: Select the profile on the DSL Alarm Thresholds Profile tab =>Configure => Modify Alarm Profile => Associations. If you want to assignseveral ports for the profile, keep the shift key down when you click the ports.

If the alarm thresholds profile is modified, all the ports assigned to the line profilestart using the new parameters.

You can select a profile for a port also on a port level: Click the Port Views icon=> line card => port => Configure menu => Modify Port command =>Thresholds tab and select the desired profile from the drop-down menu.

2.2.3 SHDSL features

The SHDSL24 line card has the following features:

Variable data rate range

The SHDSL24 line card allows provisioning of variable data rates within a rangeof 144 to 2304 kbit/s. With the E1 CES feature the data rate can be set to 2312kbit/s.

Pair bonding

This feature is used to select two ports to establish a single ATM connection. Pairbonding doubles the transmission bandwidth by using 4-wire pairs between theDSLAM and CPE instead of 2-wire pairs. Pair bonding is supported only in thefixed mode. In other words, in provisioning the SHDSL ports the RADSL Modemust be set to none.

Adjacent odd-numbered and even-numbered ports are bonded together, the odd-numbered port always coming first. For example, you can bond together ports 1and 2, 3 and 4, 5 and 6, and so on.

Pair bonding is accomplished by provisioning the even ports only. Also theconnection should be created on the even ports only. For example, if you bondtogether ports 1 and 2, port 2 becomes the "master" port, and port 1 the "slave"port. The "master" port is available for full configuration, whereas the settings ofthe "slave" port can be viewed only.

Note

SHDSL24 features are available only with compatible CPE.

40 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 41: Dn03492199 4 en Global PDF Paper a4

2.2.4 STUC and STUR terminology

The terms SHDSL Transceiver Unit � Central Office (STUC) and SHDSLTransceiver Unit � Remote (STUR) are used in SHDSL24 provisioning todescribe the DSL port hardware required at both the Central Office and Remote(CPE) ends of the local loop.

2.2.5 SHDSL operational modes

The SHDSL24 line card has 24 ports. Each port has three basic operationalmodes: idle, training, and data. These operational modes are defined as follows:

. Idle: The SHDSL24 port transmitter and receiver are �locked� or disabled.

. Training: Training starts when the SHDSL24 port is �unlocked�. TheSHDSL24 port is attempting to establish a connection with CPE during thetraining mode. Training time is approximately 20 seconds.

. Data: The SHDSL24 port connection to the CPE is established, andpayload data is carried.

2.2.6 Data mode

The SHDSL24 port enters the data mode upon completion of the training process.After the data channel is established, the ATM backplane interface is enabled andpayload cells start to flow.

2.2.7 Rates tab

Line Profile

Refer to SHDSL profiles.

Data Rates

Refer to Variable data range.

The following SHDSL24 parameters affect port training:

. Maximum Rate

The STUC maximum data rate can be provisioned for the SHDSL24 portin kilobits per second. The setting options are in the range of 144 to 2304kbit/s; the default setting is 2304 kbit/s. With the E1 CES feature the datarate can be set to 2312 kbit/s.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

41 (252)

Interface provisioning

Page 42: Dn03492199 4 en Global PDF Paper a4

. Minimum Rate

The STUC minimum data rate should be entered in kilobits per second forthe SHDSL24 port. The setting options are in the range of 144 to 2304kbit/s; the default setting is 1152 kbit/s.

CES

Circuit emulation service (CES) is supported for user rates up to 2048 kbit/s (afull E1 rate). The SHDSL standard specifies that byte synchronisation ismaintained between the ATM and SHDSL payload. Since byte synchronisation isnot possible in E1 transport, the operator must ensure that the intended CPE cansupport full E1 CES over SHDSL.

ATM CES adds approximately 13 % overhead to the signal. The SHDSL rate tobe selected can be calculated with the following formula: BWSHDSL > (53 /46.875) x Buser where > means that the next N x 64 kbit/s that is greater thanBWSHDSL is selected. This enables byte synchronisation.

For full E1 transport the E1 CES setting is 2312 kbit/s. It is recommended tocheck that the CPE can support full E1 CES (data rate 2312 kbit/s or sometimesgiven as 2320 kbit/s).

Note

The Gigabit Ethernet trunk/control unit does not support CES.

RADSL Mode

RADSL training modes adjust line rates to compensate for line conditions. TheSHDSL24 port supports the following training modes for the STUR and STUCchannels:

. None (fixed rate mode)

In this mode (fixed), the STUC is set at the provisioned rate usingmaximum and minimum rates. Using the G.handshake protocol*), theSTUC communicates the provisioned data rate to the STUR and theyattempt to link at that rate. Training continues until the configured rate isreached. If the maximum rate is equal to the minimum rate, the CPEattempts to train to that fixed provisioned rate. If unsuccessful, no link is

42 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 43: Dn03492199 4 en Global PDF Paper a4

established with the port, training restarts, and the port remains in the LOScondition. If the maximum rate is greater than the minimum rate, the CPEattempts to train to the maximum rate and if unsuccessful, falls back to theminimum provisioned rate.

*) International Telecommunication Union Recommendation G.994.1.

. Startup (default, Rate Adaptive at startup only).

In this mode, the port is set to the provisioned maximum and minimumdata rates. Using the G.handshake protocol, the STUC and STURalternately send line probing signals to evaluate the loop quality. When theSTUC and STUR have obtained sufficient information on the loop quality,they each decide the rate that the loop can support. This information isexchanged between the STUC and the STUR using the G.handshakeprotocol. The STUC and STUR then train at the highest rate that both cansupport.

If the highest rate the loop can support is greater than the provisionedmaximum rate, the STUC and the STUR train at the provisioned maximumrate. If the highest rate the loop can support is lower than the provisionedminimum rate, no link is established, training restarts, and the port remainsin the LOS condition.

The actual data rate is displayed by Element Manager and Craft Terminal.

Noise Margins

. Target Noise Margin (dB)

The Target Noise Margin is the difference in dB between noise at whichthe port will operate at an error rate of 10-7 BER and the set noise margin indB. The noise margin is usually set higher than the noise in dB for a 10-7

BER. The Target Noise Margin has a direct effect on the maximum localloop length supported for a provisioned fixed STUC/STUR data rate. Thisis available for both the STUC and the STUR sides of the connection. Thedefault value is 6 dB.

. Worst Case Noise Margin

Signal-to-noise ration (SNR) margin indicates how much noise a line cantolerate before the synchronisation is lost. The target SNR margin is thedesired SNR margin for a unit. The Worst Case Target Margin specifies themargin between the signal power level and worst case crosstalk levelspecified in the standard. The Worst Case Noise Margin is not a currentnoise level in a line.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

43 (252)

Interface provisioning

Page 44: Dn03492199 4 en Global PDF Paper a4

Both Target Noise Margin and Worst Case Noise Margin can be enabled anddisabled independently. The Target Noise Margin is enabled by default and theWorst Case Noise Margin is disabled.

Thresholds

. Error Retrain (STUC)

This STUC parameter sets the number of near-end �errored frames�allowed per second during the data mode before the SHDSL24 portretrains. The inactive Error Retrain threshold setting is �0�, the defaultsetting is �10�.

. Error Alarm

This STUC parameter sets the number of near-end �errored frames�allowed per second during the data mode before an Error Rate Alarmcondition is reported to Element Manager and Craft Terminal. The inactiveError Alarm Threshold setting is �0�, the default setting is �0�. Thisparameter does not affect port operation.

. Rate Degraded (kbit/s)

The Rate Degraded threshold rate should be set at or below the STUCprovisioned rate. When the actual transmission rate drops below this rate, aRate Degraded condition is generated in Element Manager and CraftTerminal. The default setting is 0 (disabled).

Pair bonding

Refer to Pair bonding.

Advanced Configuration

The default value of the LPort Tx Rate is the downstream capacity of a carddivided by the number of the ports. For example the default value of the LPort TxRate for the ADSL2+af card is 500 Mbit/s : 48 = 10,416 Mbit/s. The value of theLport should equal or be less than the ADSL downstream speed so that QoSwould function properly. The Lport configuration can be disabled with the BestEffort mode (CLI command: conf unit <slot> qos disable).

2.2.8 SHDSL tab

Advanced Configuration Mode

This parameter, when set to Auto, sets the advanced configuration parameters foroptimal performance. Auto is the default and recommended setting. When set toManual, the following configuration parameters must be set.

44 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 45: Dn03492199 4 en Global PDF Paper a4

Clock Source

The source clock settings for the SHDSL interface are Node Clock and Internal.When the Node Clock has been selected for the clock source setting, an 8-kHztiming signal derived from the node clock is transferred over the SHDSL line tothe CPE. If the NTE mode is supported by the CPE, the CPE can synchronise theoutgoing user data signal to the provided 8-kHz reference signal, if supported,when the NTR support is turned on in the CPE.

Power BackOff

Power Backoff�Select this option to enable/disable downstream powerreduction on short loops.

STUC Operation Mode

Select Annex A if the deployment area is North America or Annex B for Europe.

2.2.9 Thresholds tab

The following thresholds are set and viewed using Element Manager or CraftTerminal. They do not affect port operation. The default setting is 0 (zero) orinactive, except where noted:

Alarm Thresholds Profile

Refer to Alarm thresholds profiles.

Frame Thresholds

. Coding Violations

Coding Violation errors are a count of the Cyclic Redundancy Check(CRC) errored frames received for the STUC unit during the data mode.Daily and 15-minute thresholds can be set for the STUC unit. The CodingViolation parameters have thresholds for reporting an event to ElementManager and Craft Terminal.

The following table provides the expected number of STUC CodingViolation (CRC) errors in 15-minute and daily intervals*); they can be usedas threshold settings.

*) Coding Violation errors are single bit errors randomly distributed with amean equal to the Bit Error Rate.

Note

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

45 (252)

Interface provisioning

Page 46: Dn03492199 4 en Global PDF Paper a4

The number of expected Coding Violation errors varies based on the data rate.The values in the following table provide guidelines to help establish thresholds.

Table 20. STUC Coding Violation threshold settings

Parameters Thresholds settings basedon data rates (bit/s)

Sensitivity toCV errors

320000 640000

Daily settings 2200000 3500000 Low

27000 530000 Medium Low

2800 5600 Medium

2800 5600 Medium High

280 560 High

15-minute settings 23000 36000 Low

2800 5500 Medium Low

290 580 Medium

29 58 Medium High

3 6 High

. Errored Seconds

(Near End) Errored Seconds are the cumulative number of seconds the portis in an LOF, LOS, LCD, or a Coding Violation condition. CodingViolation conditions include CRC (Cyclic Redundancy Check) errors.Errored Seconds are monitored during all operational modes. Daily and 15-minute thresholds can be set for the STUC unit. An event is reported toElement Manager and Craft Terminal when the Errored Seconds thresholdis crossed.

46 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 47: Dn03492199 4 en Global PDF Paper a4

Table 21. LOS, LOF, LCD and Errored Seconds parameters

Parameter 15-minutevalue

Daily value Unit Default

Loss of Frame (LOF) 1�900 1�86400 Seconds 0

Loss of Signal (LOS) 1�900 1�86400 Seconds 0

Loss of Cell Delineation(LCD)

1�900 1�86400 Seconds 0

Errored SecondsThreshold

1�900 1�86400 Seconds 0

Failure Thresholds

. LOF Seconds thresholds

The Loss of Frame condition is monitored during the data mode. Daily and15-minute thresholds can be set for the STUC unit. The LOF Secondsthreshold settings are the number of seconds during which an LOFcondition was present. An event is reported to Element Manager and CraftTerminal when the LOF Seconds threshold is crossed.

. LOS Seconds thresholds

The Loss of Signal condition is monitored during the data mode. Daily and15-minute thresholds can be set for the STUC unit. The LOS Secondsthreshold settings are the number of seconds during which an LOScondition was present. An event is reported to Element Manager and CraftTerminal when the LOS Seconds threshold is crossed.

Note

The LOF and LOS conditions are mutually exclusive, and are reported in thefollowing priority:

- If LOS and LOF are present, LOS is reported.

- LOF is reported when it is the only condition.

. LCD Seconds thresholds

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

47 (252)

Interface provisioning

Page 48: Dn03492199 4 en Global PDF Paper a4

The Loss of Cell Delineation condition is monitored during the data mode.Daily and 15-minute thresholds can be set for the STUC unit. The LCDSeconds threshold settings are the number of seconds during which anLCD condition was present. An event is reported to Element Manager andCraft Terminal when the LCD Seconds threshold is crossed.

. LOF Retrains

LOF Retrains is the number of times a port has retrained due to Loss ofFrame (LOF). Daily and 15-minute thresholds can be set for the STUCunit. An event is reported to Element Manager and Craft Terminal whenthe LOF Retrains threshold is crossed.

. Error Rate Retrains

Error Rate Retrains is the number of times a port has retrained due toexcessive Near End errored frames. Coding Violation conditions includeCRC (Cyclic Redundancy Check) errors. Error Rate Retrains aremonitored during all operational modes. Daily and 15-minute thresholdscan be set for the STUC unit. An event is reported to Element Manager andCraft Terminal when the Error Rate Retrains threshold is crossed.

2.2.10 Transmission status actuals

The SHDSL24 port has the functionality to measure the transmission qualityestablished over the existing telephone copper network�the �local loop�. Actualtransmission quality parameters provided by the SHDSL24 port include:

Noise Margin: Level of noise in dB that the loop can tolerate before BER goesbelow 10-7 and modems retrain. This is available for both the STUC and STURsides of the connection.

Loop Attenuation: Overall signal power attenuation or �decrease in power of theDSL signal� over the local loop expressed in dB. The current measured differencebetween the transmit power level and the received power level at the far end ofthe loop is seen in the actuals for both the STUC and STUR sides of theconnection.

Transmit Power: This is available for both the STUC and STUR sides of theconnection.

Transmit Rate: Actual data rate set by training for the port.

Previous Transmit Rate: Recorded upon termination of a successful datatransport session; reports the rate according to whether the line is trained or nottrained:

48 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 49: Dn03492199 4 en Global PDF Paper a4

. Not Trained � the rate achieved by the most recent successful training

. Trained � the rate achieved by the most recent successful link-up prior tothe current link-up.

Best Transmit Rate: Highest rate the port has since the last unit restartsuccessfully linked up. If it is less than the Transmit Rate after training, the portcopies in the Transmit Rate value.

Payload Transmit Rate: Actual STUR and STUC payload rate, calculated bysubtracting the ATM cell overhead from the Transmit Rate.

Maximum Achievable Rate:Maximum transmit rate that is possible on the line.It may be greater than the maximum provisioned rate, or equal to the maximumprovisioned rate if the line is not limited.

Best Maximum Achievable Rate: Best of the Maximum Achievable Rates sincethe card was reset. If it is less than the Maximum Achievable Transmit Rate aftertraining, the port copies the Maximum Achievable Transmit Rate value.

Cells Received: Number of valid, non-idle cells �received� on the line card portfrom the CPE since the card was reset.

Cells Transmitted: Number of valid, non-idle cells received from the line cardand �transmitted� to the CPE since the card was reset.

Operational Mode: Actual operation mode, whether G.shdsl Annex A or G.shdsl Annex B.

Vendor ID: Vendor identification number of the CPE at the far-end of the loop.

Vendor Version: Version number of the CPE at the far end of the loop.

Serial Number: Serial number of the CO/CPE reported.

Receiver Gain: Actual gain applied to the received signal as a result of thetraining process. Receiver Gain is measured in dB, from �99.99 to +99.99 dB. Anegative value indicates attenuation. Receiver Gain is measured for bothchannels.

Received Blocks: Total number of blocks received on the line card port since thecard was reset.

Transmitted Blocks: Total number of blocks transmitted on the line card portsince the card was reset.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

49 (252)

Interface provisioning

Page 50: Dn03492199 4 en Global PDF Paper a4

2.2.11 Error actuals

The SHDSL24 card counts the following performance items during the datamode:

LOF (Loss of Frame) Failures: Loss of Frame errors since the line card wasreset, or since the physical performance monitoring data was cleared.

LOS (Loss of Signal) Failures: Loss of Signal errors since the line card wasreset, or since the physical performance monitoring data was cleared. An LOScondition takes precedence over an LOF condition.

LCD (Loss of Cell Delineations) Failures: Loss of Cell Delineation failure sincethe line card was reset, or since the physical performance monitoring data wascleared.

LOF (Loss of Frame) Seconds: Number of seconds in a Loss of Frame (LOF)condition.

LOS (Loss of Signal) Seconds: Number of seconds in a Loss of Signal (LOS)condition.

LCD (Loss of Cell Delineations) Seconds: Number of seconds when a Loss ofCell Delineation condition was present.

Errored Seconds: Cumulative number of near end seconds the port is in an LOF,LOS, and a CV condition.

Coding Violations: Counts the number of Cyclic Redundancy Check (CRC)errored frames received*) on the near end.

FE (Far End) Errored Seconds: Cumulative number of far end seconds the portis in an LOF, LOS, and a CV condition on the near end.

FE (Far End) Coding Violations: Counts the number of Cyclic RedundancyCheck (CRC) errored frames received**) on the far end.

HEC (Header Error Control) Errors: Number of received cells that have HECerrors detected in their header.

FE HEC (Far End Header Error Control) Errors: Number of received cellsthat have HEC errors detected in their header on the far end.

LOF (Loss of Frames) Retrains: Number of times the port had to retrain due toloss of frames.

50 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 51: Dn03492199 4 en Global PDF Paper a4

Training Starts: Total number of times a port has detected the CPE, andattempted to train up with the CPE since the last unit restart. The count will notincrement if the CPE is not connected at the other end of the loop. This featureallows the user to determine whether the port cannot train to the CPE, or whetherthere is no CPE.

Bad Provisioning Status: Number of out-of-range or invalid configurationvalues.

FE (Far End) Error Retrains: Number of times the port had to retrain on the farend owing to errored frames.

Error Retrains: Number of times the port had to retrain on the near end owing toerrored frames.

Note

Not every performance monitoring counter has a performance monitoringthreshold.

*) STUC Coding Violations are measured in Far End Block Error (FEBE). FEBEis the number of "received" frames that contain an FEBE bit set. The receiver endsets the FEBE when it "receives" a CRC error frame. The FEBE is cleared in thenext frame it transmits.

**) STUR Coding Violations are measured in Far End Block Error (FEBE).FEBE is the number of "received" frames that contain an FEBE bit set. Thereceiver end sets the FEBE when it "receives" a CRC error frame. The FEBE iscleared in the next frame it transmits.

2.3 VDSL provisioning

This chapter describes VDSL provisioning parameters and the operation of theD500 VDSL24*) line card. Details are provided on how:

. The port adjusts its data rate during the training operational mode

. The port is provisioned to obtain the best line rates for the loop conditions.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

51 (252)

Interface provisioning

Page 52: Dn03492199 4 en Global PDF Paper a4

Note

Additional provisioning information can be located in Provisioning parameters.

The VDSL24 line card provides 24 ports using Discrete Multi-Tone (DMT)modulation. Provisioning options for band plans determine asymmetric andsymmetric data rates and port assignments for upstream and downstreambandwidth.

*) D500 VDSL24 line cards include the following code suffixes foridentification: d indicates that the card is Annex D compliant, e indicates that thecard is Annex E compliant, f indicates that this line card has front mounting cableor loop terminations, r indicates the card has rear mounting cable or loopterminations.

2.3.1 VDSL profiles

It is possible to create line profiles that can be applied to VDSL ports of the sametype. The New DSL Line Profile dialog box is found by selecting Node Viewsand clicking the node icon => Profiles tab => DSL Line Profiles tab =>Configure menu => New Line Profile command.

In the New DSL Line Profile dialog box, select the correct card type and namethe profile. Define the following parameters for the profile: the VTU-O and VTU-R values for the Fast Rate/Interleave Rate, RADSL mode, and noise margins.You can also import the parameters of another port or profile to the new profile byselecting Port or Profile from the drop-down menu in the Import box andclicking Load. If you want to have the default values, select Defaults from thedrop-down menu.

When you have created new profiles, you can assign more ports to them in thefollowing way: Select the profile on the DSL Line Profile tab => Configure =>Modify Line Profile => Associations. If you want to assign several ports for theprofile, keep the shift key down when you click the ports.

If the line profile is modified, all the ports assigned to the line profile start usingthe new parameters.

You can select a profile for a port also on a port level: Click the Port Views icon=> line card => port => Configure menu => Modify Port command => Ratestab and select the desired profile from the drop-down menu.

52 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 53: Dn03492199 4 en Global PDF Paper a4

2.3.2 Alarm thresholds profiles

It is possible to create DSL alarm thresholds profiles that can be applied to VDSLports of the same type. The New DSL Alarm Thresholds Profile dialog box isfound by selecting Node Views and clicking the node icon => Profiles tab =>DSL Alarm Thresholds Profiles tab => Configure menu => New AlarmProfile command.

In the New DSL Alarm Thresholds Profile dialog box, name the alarm thresholdsprofile and define the failure thresholds and frame thresholds. You can alsoimport the parameters of another port or profile to the new profile by selectingPort or Profile from the drop-down menu in the Import box and clicking Load.If you want to have the default values, select Defaults from the drop-down menu.

When you have created alarm profiles, you can assign more ports to them in thefollowing way: Select the profile on the DSL Alarm Thresholds Profile tab =>Configure => Modify Alarm Profile => Associations. If you want to assignseveral ports for the profile, keep the shift key down when you click the ports.

If the alarm thresholds profile is modified, all the ports assigned to the line profilestart using the new parameters.

You can select a profile for a port also on a port level: Click the Port Views icon=> line card => port => Configure menu => Modify Port command =>Thresholds tab and select the desired profile from the drop-down menu.

2.3.3 VDSL operation modes

In order to establish communications with the CPE, DMT-based VDSL mustundergo a training sequence at the line card port. VDSL24 ports have three basicoperational states:

. Idle mode: The VDSL24 port transmitter and receiver are �locked� anddisabled.

. Training mode: Training starts when the VDSL24 port is �unlocked�. TheVDSL24 port is attempting to establish a connection with CPE equipmentduring the training mode.

. Data mode: The VDSL24 port connection is established and opened fortransmission of ATM data traffic.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

53 (252)

Interface provisioning

Page 54: Dn03492199 4 en Global PDF Paper a4

2.3.4 Rate modes

Latency path selection

Fast Rate is designed to correct random errors rather than bursts of errors. IfInterleave Rate is used, Reed-Solomon can also correct error bursts.

The default mode is Interleave Rate. This is because the Interleave modeprovides a more robust and reliable service in response to variable loopconditions. However, Fast Rate mode may be preferable for latency sensitiveapplications.

Maximum and minimum fast rates

The range for both the minimum and maximum rate for the VTU-R and VTU-Odepend on the band plan, see the table below. The default setting for the minimumfast rate parameter of the the VTU-R is 64. The default settings for the maximumfast rate parameters of the VTU-O depend on the band plans, see the table below.

Table 22. Maximum and minimum rates

Band plan 997_2B 997_3B 998_2B 998_3B

# of bands 2 3 2 3

# of ports 24 12 24 12

Start frequency [kHz] 138 or 1104 138 or 1104 138 or 1104 138 or 1104

Stop frequency [kHz] 4400 8500 4400 8500

Default for maximumdownstream [kbit/s]

10048 25024 22016 45056

Maximum downstream[kbit/s]

23616 48384 23616 53760

Default for minimumdownstream [kbit/s]

64 64 64 64

Minimum downstream[kbit/s]

64 64 64 64

Default for maximumupstream [kbit/s]

10048 25024 3008 10048

Maximum upstream[kbit/s]

13056 30464 5440 12288

54 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 55: Dn03492199 4 en Global PDF Paper a4

Table 22. Maximum and minimum rates (cont.)

Band plan 997_2B 997_3B 998_2B 998_3B

Default for minimumupstream {kbit/s]

64 64 64 64

Minimum upspstream[kbit/s]

64 64 64 64

Maximum and minimum interleave rates

The range for both the minimum and maximum rate for the VTU-R and thedefault for the maximum setting of the VTU-R depend on the band plan, see thetable above. The default for the minimum setting of the VTU-R and VTU-O is64. The range for both the minimum and maximum rate for the VTU-O and thedefault for the maximum setting of the VTU-O depend on the band plan, see thetable above.

Rate Degraded threshold

If the actual rate is less than or equal to this threshold, a Rate Degraded conditionis reported. The default setting is 0 (disabled).

LPort Tx Rate

The default value of the LPort Tx Rate is the downstream capacity of a carddivided by the number of the ports. For example the default value of the LPort TxRate for the ADSL2+af card is 500 Mbit/s : 48 = 10,416 Mbit/s. The value of theLport should equal or be less than the ADSL downstream speed so that QoSwould function properly. The Lport configuration can be disabled with the BestEffort mode (CLI command: conf unit <slot> qos disable).

2.3.5 Port training mode

For each VDSL24 port, the port can be set to adapt to the line conditions atstartup. The port training modes supported by the VDSL24 line card are RateAdaptive DSL (RADSL) and fixed rate training. The setting is either Startup orNone.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

55 (252)

Interface provisioning

Page 56: Dn03492199 4 en Global PDF Paper a4

Startup (RADSL training)

During the training process, the port measures the quality of the line (allowing forthe Noise Margin provisioned for the port) and determines the best RADSLupstream and downstream transmit rates that the line can support. The Max (kbit/s) and Min (kbit/s) settings determine the range from which to obtain the besttransmit rate, see the figure below:

Figure 7. Provisioning for RADSL training

None (Fixed rate training)

The VDSL24 port trains to the maximum rates provisioned for either the FastRate or Interleave Rate VTU-R and VTU-O channels, depending on which ratemode is in use.

The port has LOS (Loss of Signal) condition until training at the fixed rate issuccessful.

Target Noise Margin

This parameter sets the margin (in dB) for VTU-O used during RADSL and fixedrate training processes. The Target Noise Margin parameter establishes theamount that noise can increase on the line for the channel to operate at 10-7 BER(Bit Error Rate). A larger margin lowers the rate, but increases the line�simmunity to noise.

. The VDSL24 port will train to the maximum data rate supportable on theline, while operating within the provisioned Target Noise Marginparameter, and maintaining the bit error rate at 10-7 BER. The actual andprovisioned margins should be approximately equal. Any excess channelcapacity is used to increase the margin if the port can train to the maximumrate; in this case the actual margin is higher than the provisioned margin.

. Target Noise Margin parameters are provisionable for VTU-O. The rangeis from 0 dB to 31 dB; the default is 6 dB.

VTU-O Operation Mode

This operational mode for the port is "auto". In the "auto" mode, the CO directsthe modem.

56 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 57: Dn03492199 4 en Global PDF Paper a4

2.3.6 Port data mode

The VDSL24 port enters the data mode upon completion of the training process.After the data channel is established, the ATM backplane interface is enabled andpayload cells start to flow.

The following VDSL24 parameters, except Error Alarms, affect port operationduring the data mode. If the setting of any of these parameters is changed, theconnection drops and resynchronises with new parameters.

VTU-O and VTU-R Interleave Delay

These parameters allow the user to increase or decrease the delay (latency) inboth the VTU-O and VTU-R channels. By adjusting latency in the loop, youincrease or decrease the immunity to impulse noise. In general, the lower settingsare used for latency-sensitive voice transmissions, and the higher settings are fordata. This applies to the Interleave Rate operation only.

Maximum parameters can be set for both VTU-O and VTU-R. The settingoptions are 0 ms 1 ms, 2 ms, 4 ms, 8 ms, 16 ms, 32 ms and 64 ms; the defaultsetting is 16 ms for VTU-O and 16 ms for VTU-R.

If the provisioned setting cannot be attained, the parameter is rounded down tothe nearest available setting.

Error Retrain threshold

This VTU-O parameter sets the number of near end �errored frames� per secondallowed during the data mode before the VDSL24 port retrains. The range is 1 to60 seconds, and the default is 10; the inactive setting is 0.

Rates Max/Min

Max/Min rates are the rates provisioned for the port.

Interleave Rate/Fast Rate

Rate modes are used to select Reed-Solomon latency control modes, Fast Rateand Interleave Rate, for Forward Error Correction (FEC) in both upstream anddownstream directions. Reed-Solomon Fast Rate is designed to correct randomerrors rather than bursts of errors. If Interleave Rate is used, Reed-Solomon canalso correct error bursts.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

57 (252)

Interface provisioning

Page 58: Dn03492199 4 en Global PDF Paper a4

Band plan

The VDSL24 line card supports the 997 or 998 band plans of two or three bands(see below the VDSL24 band plans table). The band plans support bothasymmetrical and symmetrical throughput.

Band configuration

The supported RFI (radio frequency interference) bands are listed in thefollowing table:

Table 23. RFI bands:

ANSI ETSI

RFI 1 (1810�2000 kHz) RFI 1 (1810�2000 kHz)

RFI 2 (3500�4000 kHz) RFI 2 (3500�3800 kHz)

RFI 3 (7000�7300 kHz) RFI 3 (7000�7100 kHz)

Start Tones

Start Tones are the starting tones for VDSL band plans. The setting is either 138kHz or 1104 kHz.

Noise Margin

Noise Margin is the maximum tolerable increase in external noise power allowedon the line for the port to operate at 10-7 BER. The Noise Margin is measured indB�it has a direct effect on the maximum local loop length supported for aprovisioned fixed VTU-O/VTU-R data rate.

Test

The terminal loopback test is used for testing the ATM network side of the D500operating environment.

2.3.7 VTU-R/VTU-O channel parameter values

The following tables provides the VTU-O channel provisioning parameters:

58 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 59: Dn03492199 4 en Global PDF Paper a4

Table 24. VTU-O provisioning parameters

Parameter Value Unit Default

Target Noise Margin 0�31 dB 6

Minimum Noise Margin 0�31 dB 1

Maximum Noise Margin 0�31 dB 28

Interleave Delay 1�64 ms 16

Error Retrain Threshold 1�60 Error/Sec 0

FE Error Retrain Threshold 1�60 Error/Sec 0

2.3.8 Band plan management

The VDSL24 line card supports the 997 or 998 band plans of two or three bands(see the table below). The band plans support asymmetrical (998) andsymmetrical (997) throughput.

Band plans can be selected on the unit level: all the ports in one unit have thesame band plan. Depending on the band plan selected, power will automaticallybe applied to all ports to achieve the required power spectral density (PSD) at thetransmitting ports. The following band plans are available:

Table 25. VDSL24 band plans

No ofports

Band plan MHz 0.40mm (26 AWG)Mbit/s

0.50 mm (24AWG) Mbit/s

24-port

998-025-U0-138-D1-3750-U1-4400 �Asymmetric

Refer to the figure below.

22/3 @ 3.6 Kft

16/1 @ 4.6 Kft

22/3@ 1.34 km(4.4 Kft)

16/1 @ 1.76 km(5.8 Kft)

997-025-U0-138-D1-3000-U1-4400 �Symmetric

Refer to the figure below.

16/1 @ 4.6 Kft

10/10 @ 2.6 Kft

16/1 @ 1.76 km(5.8 Kft)

10/10 @ 1.07 km(3.5 Kft)

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

59 (252)

Interface provisioning

Page 60: Dn03492199 4 en Global PDF Paper a4

Table 25. VDSL24 band plans (cont.)

No ofports

Band plan MHz 0.40mm (26 AWG)Mbit/s

0.50 mm (24AWG) Mbit/s

12-port

998-138-D1-3750-U1-5200-D2-8500 �Asymmetric

Refer to the figure below.

6/6 @ 3.8 Kft

52/11 @ 1.9 Kft

22/3 @ 3.7 Kft

6/6 @ 1.28 km (4.2Kft)

52/11 @ 0.73 km(2.4 Kft)

22/3 @ 1.46 km(4.8 Kft)

997-138-D1-3000-U1-5100-D2-7050 U28500 � Asymmetric

Refer to the figure below.

10/10 @ 3.3 Kft

16/1 @ 4.6 Kft

22/3 @ 3.7 Kft

10/10 @ 1.25 km(4.1 Kft)

16/1 @ 1.77 km(5.8 Kft)

22/3 @ 1.40 km(4.6 Kft)

Figure 8. 24-port band plans

UP 0 UP 1DOWN 1

0.025 0.138 3.75 4.40 MHz

UP 0 UP 1DOWN 1

0.025 0.138 3.00 4.40 MHz

unoccupied

unoccupied

60 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 61: Dn03492199 4 en Global PDF Paper a4

Figure 9. 12-port band plans

Band plans are selected with the VTU-O drop-down box. When you click the SetBand Plans button, a confirmation message asks you to confirm theimplementation of your choice.

Note

The Apply button is shaded (not active); the setting of band plans takes placeonly with the Set Band Plans button.

The configurations of the shaded (not used) ports can only be viewed. The datarates of the manageable ports change in accordance with the rates of the new bandplan.

The VDSL24 line card has two PSD (Power Spectral Density) masks: FTTCab(fiber to the cabinet) and FTTEx (fiber to the exchange). The FTTCab mask isintended for the deployment scenario where VDSL is deployed from the cabinetand other DSL services in the same cable are deployed from the exchange.FTTEx is used when also VDSL is deployed from the exchange. The use of thecorrect PSD mask ensures that VDSL is spectrally compatible with other DSLservices in the same cable.

UP 0 UP 1DOWN 1

0.138 3.75 8.50 MHz

UP 0 UP 1DOWN 1

0.138 3.00 8.50 MHz5.10

5.20

DOWN 2

DOWN 2 UP 2

7.05

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

61 (252)

Interface provisioning

Page 62: Dn03492199 4 en Global PDF Paper a4

2.3.9 VDSL thresholds

The following thresholds are set and viewed using Craft Terminal. The defaultsetting is 0 (zero) or inactive, except where noted. Daily and 15-minutethresholds can be set for the VTU-O unit.

LOF Seconds thresholds

The Loss of Frame condition is monitored during the data mode. The LOFSeconds threshold settings are the number of seconds during which an LOFcondition was present. An event is reported to Craft Terminal when the LOFSeconds threshold is crossed.

LOS Seconds thresholds

The Loss of Signal condition is monitored during the data mode. The LOSSeconds threshold settings are the number of seconds during which an LOScondition was present. An event is reported to Craft Terminal when the LOSSeconds threshold is crossed.

LCD Seconds thresholds

The Loss of Cell Delineation condition is monitored during the data mode. TheLCD Seconds threshold settings are the number of seconds during which an LCDcondition was present. An event is reported to Craft Terminal when the LCDSeconds threshold is crossed.

LOF Retrains

LOF Retrains is the number of times a port has retrained due to LOF. An event isreported to Craft Terminal when the LOF Retrains threshold is crossed.

Error Retrains

Error Retrains is the number of times a port has retrained due to excessive NearEnd errored frames. Coding Violation conditions include CRC (CyclicRedundancy Check) errors. Error Retrains are monitored during all operationalmodes. An event is reported to Craft Terminal when the Error Retrains thresholdis crossed.

Errored Seconds thresholds

(Near End) Errored Seconds are the cumulative number of seconds the port is inan LOF, LOS, LCD, or a Coding Violation condition. Coding Violationconditions include CRC (Cyclic Redundancy Check) errors. Errored Seconds aremonitored during all operational modes. An event is reported to Craft Terminalwhen the Errored Seconds threshold is crossed.

62 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 63: Dn03492199 4 en Global PDF Paper a4

Table 26. LOS, LOF, LCD and Errored Seconds parameters

Parameter 15-minutesvalue

Daily value Unit Default

Loss of Frame (LOF) 1�900 1�86400 Seconds 0

Loss of Signal (LOS) 1�900 1�86400 Seconds 0

Loss of Cell Delineation(LCD)

1�900 1�86400 Seconds 0

Coding Violation thresholds

Coding Violation errors are a count of the Cyclic Redundancy Check (CRC)errored frames received for the VTU-O unit during the data mode. The CodingViolation parameters have thresholds for reporting an event to Craft Terminal.The following table provides the expected number of VTU-O Near and FECoding Violation (CRC) errors *).They can be used as threshold settings.

Note

The number of expected Coding Violation errors varies based on the data rate.The values in the following table provide guidelines to help establish thresholds.

*) Coding Violation errors are single bit errors randomly distributed with a meanequal to the Bit Error Rate.

Table 27. VTU-O Coding Violation threshold settings

Parameter Threshold settings based on data rates (bit/s) Sensitivity toCV errors

32000 64000 320000 640000

Daily settings

270000 530000 2200000 3500000 Low

28000 55000 270000 530000 Medium Low

2800 5600 28000 55000 Medium

280 560 2800 5600 Medium High

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

63 (252)

Interface provisioning

Page 64: Dn03492199 4 en Global PDF Paper a4

Table 27. VTU-O Coding Violation threshold settings (cont.)

Parameter Threshold settings based on data rates (bit/s) Sensitivity toCV errors

32000 64000 320000 640000

28 56 280 560 High

15-minute settings

2800 5500 23000 36000 Low

290 580 2800 5500 Medium Low

29 58 290 580 Medium

3 6 29 58 Medium High

0 1 3 6 High

2.3.10 Actuals

The VDSL24 port can measure channel quality established over the existingtelephone copper network (the local loop). The VDSL24 port reports actualssince the card or the counter was reset or for the following operationalparameters:

Noise Margin: Actual amount of noise margin measured on the VTU-R andVTU-O channels. The range is -64.0 dB to +63.5 dB, measured in increments of.5 dB.

Loop Attenuation: Decrease in power of the signal received from the far endover the loop. The range is 0 dB to +63.5 dB, measured increments of .5 dB.

Transmit Power: Actual power being transmitted on the channel, measured indBm.

Transmit Rate: Actual VTU-R and VTU-O data rate for the channel; this rate iseither fixed or determined by the VDSL24 port during the training process.

Previous Transmit Rate: Recorded upon termination of a successful datatransport session; reports the rate according to whether the line is trained or nottrained.

. Not Trained � the rate achieved by the most recent successful training

. Trained � the rate achieved by the most recent successful link-up prior tothe current link-up.

64 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 65: Dn03492199 4 en Global PDF Paper a4

Best Transmit Rate: Highest rate the port has linked up at successfully. If it isless than the Transmit Rate after training, the port copies in the Transmit Ratevalue.

Payload Transmit Rate: Actual VTU-R and VTU-O payload rate for thechannel, calculated by subtracting the ATM cell overhead from the TransmitRate.

Cells Received: Number of valid, non-idle cells �received� on the line card portfrom the CPE since the card was reset.

Cells Transmitted: Number of valid, non-idle cells received from the line cardand �transmitted� to the CPE since the card was reset.

Operational Mode: Band plan mode used.

Training Starts: Total number of times a port has detected the CPE, andattempted to train up with the CPE.

Interleave Depth: Interleave-depth value achieved.

Coding Gain: Coding gain value achieved.

S (symbols/codeword): Number of DMT symbols per RS codeword.

Vendor ID: Vendor identification number of the CPE at the far-end of the loop.

Vendor Version: Version number of the CO/CPE at the far-end of the loop.

Serial Number: Serial number of the CO/CPE reported.

Received Blocks: Number of blocks received on the line card port since the cardwas reset.

Transmitted Blocks: Number of blocks transmitted on the line card port sincethe card was reset.

LOF Retrains: Retrains on the DSL port triggered by LOF errors.

HEC Errors: Total number of received cells that have Header Error Control(HEC) errors detected in their header.

Corrected Errors: Total number of corrected Forward Error Correction (FEC)errors.

LOF Failures: Loss of Frame errors.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

65 (252)

Interface provisioning

Page 66: Dn03492199 4 en Global PDF Paper a4

FE LOF (RDI) Failures: Far-end Loss of Frame � LOF-FE failure is declaredafter 2.5 ± 0.5 s of a contiguous RDI defect, except when a far-end LOS defect orfailure is present (see the LOS definition). A far-end LOF failure is cleared whena far-end LOS failure is declared, or after 10 ± 0.5 s of no RDI defect (RDI =Remote Defect Indication).

LOS Failures: Loss of Signal errors. An LOS condition takes precedence over anLOF condition.

LCD Failures: Loss of Cell Delineation errors.

ESE Failures: Excessive Severe Error failures.

LOF Seconds: Total number of seconds during which the port detects an LOFScondition.

LOS Seconds: Total number of seconds during which the port detects an LOScondition.

LCD Seconds: Total number of seconds during which the port detects an LCDcondition.

Severly Errored Seconds: The number of CRC errors is 18 or more per second.

Errored Seconds: Total number of seconds the far-end detected frame CRCerrors.

Coding Violations: Coding violations detected by the near-end.

Error Retrains: Number of VDSL24 port retrains (based on near-end �erroredframes� per second allowed during the data mode).

FE Error Retrains: Number of VDSL24 port retrains (based on far-end �erroredframes� per second allowed during the data mode).

Elapsed Time (Current 15 minutes): Total amount of time in the current 15-minute performance monitoring interval.

Elapsed Time (Current 24 hours): Total amount of time in the current 24-hourperformance monitoring interval.

Elapsed Time (Previous day): Total amount of time in the performancemonitoring interval of the preceding day.

FE HEC Errors: Far-end HEC errors on this DSL port.

66 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 67: Dn03492199 4 en Global PDF Paper a4

Fe Corrected Errors: Far-end error corrections.

2.4 OC-3/STM-1 and OC-12/STM-4 provisioning

This document describes provisioning parameters and operation of the D500 OC-3/STM-1 and OC-12/STM-4 trunk/control units (TKATM_155_622) and OC-3/STM-1 tributary unit (TRB155).

TKATM_155_622 (shortened to the ATM trunk/control unit or ATM trunk)supports the following interfaces using small form-factor pluggable (SFP)modules:

. OC-3/STM-1 MM SH�1310-nm multimode fiber/medium powerinterface for short range operation (2 km or 1.25 miles)

. OC-3/STM-1 SM SH�1310-nm singlemode fiber/low power interface forlong range operation (15 km or 9.3 miles)

. OC-3/STM-1 SM LH�1310-nm singlemode fiber/high power interfacefor long range operation (40 km or 25 miles).

Note

There can be only one SFP module per unit. It is inserted in the upper port.

The ATM trunk/control unit can multiplex and deliver traffic from up to 15 linecards (in a 17-slot D500 subrack) or 19 line cards (in a 21-slot D500 subrack) intothe OC-12/STM-4 trunk.

The tributary unit supports four OC-3/STM-1 tributary interfaces, with threevariations:

. OC-3/STM-1 MM SH�Multi mode fiber/medium power interface forshort range operation (2 km or 1.25 miles)

. OC-3/STM-1 SM SH�Single mode fiber/low power interface for mediumrange operation (15 km or 9.3 miles)

. OC-3/STM-1 SM LH�Single mode fiber/high power interface for longrange operation (40 km or 25 miles).

The subrack is divided into four sections. It is recommended that there is amaximum of two tributary units per section.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

67 (252)

Interface provisioning

Page 68: Dn03492199 4 en Global PDF Paper a4

. Section 1 comprises slots 1�5

. Section 2 comprises slots 6�10

. Section 3 comprises slots 13�17.

. Section 4 comprises slots 17�21.

2.4.1 OC-3/STM-1 and OC-12/STM-4 ATM interface specifications

The OC-3/STM-1 and OC-12/STM-4 interface provides a GR-253/ITU-G.707compliant SONET/SDH interface for connecting the D500 system to an OC-3/STM-1- or OC-12/STM-4-based data network. It also provides egress addresstranslation, multiplexing, and timing resources. The OC-3/STM-1 and OC-12/STM-4 interface passes the ATM data stream to and from the ATM data network.

The OC-3/STM-1 tributary interface provides an ATM UNI compliant interfacefor connecting another D500 node, ATM switch, D50(e) or a third-party DSLAMto the D500 node. It can also be used as an additional trunk for traffic balancingpurposes.

Additional provisioning information can be located in Provisioning parameters.

2.4.2 OC-3/STM-1 and OC-12/STM-4 provisioning parameters

All OC-3/STM-1 and OC-12/STM-4 provisioning parameters can be set usingCraft Terminal and the command line interface (CLI). For details on the userinterface, see Web-based Craft Terminal and Command Line Interface.

Facility type

The OC-3/STM-1 and OC-12/STM-4 facility type setting on the trunk/controlunit and the OC-3/STM-1 facility type setting on the tributary unit must matchthe parameters set on the far-end ATM router or switch. The default settingdepends on the subrack type. The facility type default is:

. SDH for the 17-slot subrack

. SONET for the 21-slot subrack.

Thresholds

The OC-3/STM-1 and OC-12/STM-4 interface allows the user to set a number ofthresholds for near-end and far-end performance parameters. The followingparameters affect port operation, and can be set for both 15-minute and dailyintervals:

68 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 69: Dn03492199 4 en Global PDF Paper a4

The Intervals group on this tab page allows you to specify several line, path, andsection error rate thresholds, for both 15-minute and daily intervals:

. Coding Violations is the count of CP-bit parity errors occurring in theaccumula-tion period.

. Errored Seconds is the count of seconds containing one or more CP-bitparity errors, one or more SEF defects, or one or more AIS defects.

. Severely Errored Seconds is the count of seconds containing more than 44CP-bit parity errors, one or more SEF defects, or one or more AIS defects.

. Unavailable Seconds is the count of one second intervals during which theOC-12/STM-4 or OC-3/STM-1 path is unavailable.

. Severely Err. (errored) Framing Seconds is the count of seconds containingone or more SEF defects or one or more AIS defects.

The BERT (Bit Error Rate Threshold) group allows you to set thresholds for theSignal Degrade and Signal Fail Conditions.

For provisioning parameter tables, see Provisioning parameters.

Note

Save these new settings permanently with the Save command.

For details on setting these thresholds, see the tables below:

Table 28. Near-end performance parameters

Line/Path/Section

Acronym Meaning Daily interval 15-minute interval

Line

CV Coding Violations:Count of BIP errors(using B2 byte)occurring in theaccumulation period.Up to 8XN BIP errorscan be detected perSTM-1 or STN-N frame,with each errorincrementing the CV-Lcurrent second register

0�1,048,575Default settingis 0 (inactive)

0�16383 Defaultsetting is 0 (inactive)

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

69 (252)

Interface provisioning

Page 70: Dn03492199 4 en Global PDF Paper a4

Table 28. Near-end performance parameters (cont.)

Line/Path/Section

Acronym Meaning Daily interval 15-minute interval

ES Errored Seconds:Cound of secondscontaining one or moreLine Layer BIP errors oran AIS-L defect waspresent.

0�65535Default settingis 0 (inactive)

0�900 Default settingis 0 (inactive)

SES Severly ErroredSeconds: Count ofseconds containing2,500 or more LineLayer BIP errors or anAIS-L defect waspresent.

0�65535Default settingis 0 (inactive)

0�900 Default settingis 0 (inactive)

UAS Unavailable Seconds:Count of one secondintervals during whichthe Line is unavailable.The Line is unavailableat the onset of 10contiguous SES-Ls.The 10 SES-Ls areincluded in unavailabletime and since it is notknown until the tenthsecond that unavailabletime started tenseconds ago, thecounts for all theparameters must beadjusted back to whatthey were ten secondsago. Once unavailable,the Line becomesavailable at the onset of10 contiguous secondswith no SES-Ls. Theten seconds with noSES-Ls are excludedfrom available time sothe counts of theparameters do not needto be adjusted.

0�65535Default settingis 0 (inactive)

0�900 Default settingis 0 (inactive)

Path

CV Coding Violations:Count of BIP errors(using B3 byte)occurring in the

0�1,048,575Default settingis 250

0�16383 Defaultsetting is 25

70 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 71: Dn03492199 4 en Global PDF Paper a4

Table 28. Near-end performance parameters (cont.)

Line/Path/Section

Acronym Meaning Daily interval 15-minute interval

accumulation period.Up to 8 BIP errors canbe detected per frame,with each errorincrementing the CV-Pcurrent second register.

ES Errored Seconds:Count of secondscontaining one or morePath Layer BIP errorsor an AIS-P or LOP-Pdefect was present.

0�65535Default settingis 200

0�900 Default settingis 20

SES Severely ErroredSeconds: Count ofseconds containing2,400 or more LineLayer BIP errors orwhen an AIS-P or LOP-P defect was present.

0�65535Default settingis 7

0�900 Default settingis 3

UAS Unavailable Seconds:Count of one secondintervals during whichthe Path is unavailable.The Path is unavailableat the onset of 10contiguous SES-Ps.The 10 SES-Ps areincluded in unavailabletime and since it is notknown until the tenthsecond that unavailabletime started tenseconds ago, thecounts for all theparameters must beadjusted back to whatthey were ten secondsago. Once unavailable,the Path becomesavailable at the onset of10 contiguous secondswith no SES-Ps. Theten seconds with noSES-Ps are excludedfrom available time sothe counts of the

0�65535Default settingis 10

0�900 Default settingis 10

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

71 (252)

Interface provisioning

Page 72: Dn03492199 4 en Global PDF Paper a4

Table 28. Near-end performance parameters (cont.)

Line/Path/Section

Acronym Meaning Daily interval 15-minute interval

parameters do not needto be adjusted.

Section

SEFS Section SeverelyErrored FramingSeconds: Count ofseconds containing oneor more SeverelyErrored Framing (SEF)defects (defined as atime at which theincoming signal has aminimum of fourconsecutive erroredframing patterns). ASEF defect isterminated upondetecting twosuccessive error-freeframing patterns.

0�65535Default settingis 0 (inactive)

0�900 Defaultsetting is 0 (inactive)

Table 29. Far-end performance parameters

Line/Path Acronym Meaning Daily interval 15-minuteinterval

Line

CV Coding Violations:Count of BIP errors(using REI-L indicationin the Line Overhead)detected by the far-endLTE. Up to 8XN BIPerrors can be indicatedby the REI-L, with eacherror incrementing theCV-LFE current secondregister.

0�1,048,575Default setting is 0(inactive)

0�16383 Defaultsetting is 0(inactive)

ES Errored Seconds:Count of secondscontaining one or moreLine Layer BIP errorswas reported by thefar-end LTE (using theREI-L indication) or anRDI-L defect was

0�65535 Defaultsetting is 0(inactive)

0�900 Defaultsetting is 0(inactive)

72 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 73: Dn03492199 4 en Global PDF Paper a4

Table 29. Far-end performance parameters (cont.)

Line/Path Acronym Meaning Daily interval 15-minuteinterval

present.

SES Severely ErroredSeconds: Count ofseconds containing2,500 or more LineLayer BIP errorsreported by the far-endLTE (using the REI-Lindication) or an RDI-Ldefect was present.

0�65535 Defaultsetting is 0(inactive)

0�900 Defaultsetting is 0(inactive)

UAS Unavailable Seconds:Count of one secondintervals during whichthe OC-3/STM-1 Line isunavailable at the far-end. The far-end Lineis unavailable at theonset of 10 contiguousSES-LFEs. The 10SES-LFEs are includedin unavailable time andsince it is not knownuntil the tenth secondthat unavailable timestarted ten secondsago, the counts for allthe parameters mustbe adjusted back towhat they were tenseconds ago. Onceunavailable, the Linebecomes available atthe onset of 10contiguous secondswith no SES-LFEs. Theten seconds with noSES-LFEs areexcluded fromavailable time so thecounts of theparameters do notneed to be adjusted.

0�65535 Defaultsetting is 0(inactive)

0�900 Defaultsetting is 0(inactive)

Path

CV Coding Violations:Count of BIP errors(using REI-P indicationin the Path Overhead)

0�1,048,575Default setting is250

0�16383 Defaultsetting is 25

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

73 (252)

Interface provisioning

Page 74: Dn03492199 4 en Global PDF Paper a4

Table 29. Far-end performance parameters (cont.)

Line/Path Acronym Meaning Daily interval 15-minuteinterval

detected by the far-endPTE. Up to 8 BIP errorscan be indicated by theREI-P, with each errorincrementing the CV-PFE current secondregister.

ES Errored Seconds:Count of secondscontaining one or morePath Layer BIP errorswas reported by thefar-end PTE (using theREI-P indication) or anRDI-P defect waspresent.

0�65535 Defaultsetting is 200

0�900 Defaultsetting is 20

SES Severely ErroredSeconds: Count ofseconds containing2400 or more PathLayer BIP errorsreported by the far-endPTE (using the REI-Pindication) or an RDI-Pdefect was present.

0�65535 Defaultsetting is 7

0�900 Defaultsetting is 3

UAS Unavailable Seconds:Count of one secondintervals during whichthe Path is unavailableat the far-end. ThePath is unavailable atthe onset of 10contiguous SES-PFEs.The 10 SES-PFEs areincluded in unavailabletime and since it is notknown until the tenthsecond thatunavailable timestarted ten secondsago, the counts for allthe parameters mustbe adjusted back towhat they were tenseconds ago. Onceunavailable, the Line

0�65535 Defaultsetting is 10

0�900 Defaultsetting is 10

74 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 75: Dn03492199 4 en Global PDF Paper a4

Table 29. Far-end performance parameters (cont.)

Line/Path Acronym Meaning Daily interval 15-minuteinterval

becomes available atthe onset of 10contiguous secondswith no SES-PFEs.The ten seconds withno SES-PFEs areexcluded fromavailable time so thecounts of theparameters do notneed to be adjusted.

2.5 Gigabit Ethernet provisioning

The D500 Gigabit Ethernet trunk/control unit (TK1000, TKETH1G) is hereshortened to the Gigabit Ethernet trunk or GE trunk.

The D500 supports the following Gigabit Ethernet trunk/control units:

. TK1000S3 � short haul (<250 m), 850-nm multimode version

. TK1000L3 � long haul (<10 km), 1310-nm singlemode version

. TK1000E3 � extended long haul (<20 km), 1310-nm singlemode version.

. TKETH1G with the following small form-factor pluggable (SFP) modules:

- Multimode (850 nm), short range (with a 50/125-¼m fibre the rangeis 2�550 m and with a 62.5/125-¼m fibre the range is 2�275 m),duplex LC connector

- Singlemode (1310 nm), medium range (<10 km), duplex LCconnector

- Singlemode (1310 nm), long range (<40 km), duplex LC connector

Note

There are two SFP module holders in TKETH1G. Only the upper one is in useand active.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

75 (252)

Interface provisioning

Page 76: Dn03492199 4 en Global PDF Paper a4

The GE trunk is mounted in slot 11 in the D500 subrack and in slot 1 in the D500RAM.

Note

Do not install a redundant trunk/control unit in slot 12 because Release 3.2 of theD500 does not support the redundant trunk/control unit and if it is in place, it candistub the operation of the main trunk/control unit.

The network applications supported by the GE trunk are described in Bridgedsubinterface and Routed bridge subinterface.

2.5.1 Gigabit Ethernet interface specification

The Gigabit Ethernet interface provides standard IEEE802.3-compliant opticalEthernet interface for connecting the D500 system to the Gigabit Metro Ethernetnetwork. The GE interface also provides IEEE802.1Q VLAN and IEEE802.1Ethernet class of service.

2.5.2 Interval sampling

D500 Craft Terminal and the CLI can sample and report historical data forpredefined periods of time called intervals, using the following parameters.Interval data reports the same types of statistical information as Ethernet Actuals.For details see Ethernet actuals below.

History Interval (secs) is the time interval in seconds for which interval data issampled and reported by the Ethernet trunk counters. The allowed sampling rangeis from 1 to 3600 seconds. It is important that interval time should not exceed thefill time for the counter buffer. If the buffer fills before the interval time expires,the counter will reset to 0. The default value is 1,800 seconds.

Bin is the number of sampling history intervals for which historical data isreported. The user can provision up to 576 intervals. Bin 1 is always the currentinterval being sampled.

Interval Status is the status of data obtained during the current interval.

76 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 77: Dn03492199 4 en Global PDF Paper a4

2.5.3 Ethernet actuals and performance thresholds

The user can set thresholds to the counters listed below. The thresholds defineEthernet performance thresholds at the Ethernet port. Thresholds are set andviewed in Craft Terminal or the CLI. An error is reported when the threshold iscrossed.

The Actuals tab page displays received and transmitted connectivity data at theport level. The information on the Actuals tab is read-only. The actuals belowreport values for Ethernet statistical data.

These are the counters available for reporting statistical data and for which theuser can set thresholds:

. Total Octets

- Received: Total number of octets of data (including those in badframes) received (exluding framing bits but including FCS octets).This includes the count of bytes from first byte of the destinationaddress to the last byte of the FCS field.

- Transmitted: Total number of octets of data and padding (exludingpreamble, SFD, destination/source address, length/type field, Q-Tagprefix, and FCS) octets of frames that are successfylly transmittedover the MAC interface.

. Total Packets

- Received: Total number of frames that are successfully received.

- Transmitted: Total number of frames that are successfullytransmitted over the MAC interface.

. Unicast Packets

- Received: Total number of unicast packets successfully received.

- Transmitted: Total number of unicast packets successfullytransmitted.

. Non-Unicast Packets

- Received: Total number of frames that are successfully received anddirected to a multicast or broadcast group.

- Transmitted: Total number of frames that are successfullytransmitted to a multicast or broadcast address.

. Discarded Packets

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

77 (252)

Interface provisioning

Page 78: Dn03492199 4 en Global PDF Paper a4

- Received: Total number of received frames that are too long, tooshort, or contain a length error, or are classified as jabbers orfragments.

- Transmitted: Count of frames that would otherwise be transmittedby the device but could not be sent correctly because of:

1) MAC FIFO underrun

2) POS-PHY Level 3 TERR signal assertion on the last word of thecurrent frame without any further immediately following frames.

. Errored Packets

- Received: Total number of received frames that are too long, tooshort, or contain a length error or an FCS error, or are discardedbecause of FIFO overrun physical device symbol error.

- Transmitted: Total number of frames that would otherwise betransmitted by the device but could not be sent because of anindication of an internal error.

. Max BW Utilization

- Received: Shows the percentage of bandwidth used in the Rxdirection.

- Transmitted: Shows the percentage of bandwidth used in the Txdirection.

. Undersize Packets

- Received: Total number of frames received (excluding framing bitsbut including FCS octets) that are less than 64 octets.

. Oversize Packets

- Received: Total number of packets received (excluding framing bitsbut including FCS octets) that are over 1518 octets.

. Collisions

- Received: Count of received frames that are an integral number ofoctets in length and do not pass the FCS check This does no includeframes received that are too long (jabbers) or too short (fragments).

Besides the actuals, the following features are presented:

. MTU Size: Size in octets of the largest datagram that can be sent orreceived at the Ethernet trunk/control unit interface.

. Speed (Mbit/s): Transmission speed. An estimate of the current bandwidthin use by the interface. If the bandwidth does not change or cannot beestimated, this actual displays the nominal interface bandwidth.

78 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 79: Dn03492199 4 en Global PDF Paper a4

. MAC Address: MAC address of the D500 set by the Local IP Addressparameter assigned in the VLAN View.

. Ageing Time: Time in seconds until MAC addresses are purged from theMAC Address Table if they are not in use. The MAC ageing time is set bythe MAC Maximum Ageing Time parameter.

. MAC Utilization: Percentage of the total capacity of the forwarding MACAddress Table currently utilised.

. Locally Reset Counters: Resets the settings to 0.

2.6 DS3 provisioning

The following describes provisioning parameters and operation of the D500trunk/control unit with DS3 interface (also referred to as TKDS3) and DS3tributary unit (also referred to as TBDS3).

Note

Relase 3.2 does not include the DS3 trunk/control unit.

The DS3 trunk/control unit is similar to the OC-3/STM-1 trunk (TRK155) exceptthat instead of an OC-3/STM-1 interface it supports a single DS3 aggregateinterface. The DS3 trunk/control unit can multiplex and deliver traffic from up to15 line cards (in a 17-slot D500 subrack) or 19 line cards (in a 21-slot D500subrack) into the DS3 trunk.

The DS3 tributary unit supports eight DS3 tributary interfaces. The maximumnumber of tributary units per subrack is four. The subrack is divided into foursections. There can be only one tributary unit per section:

. Section 1 comprises slots 1�5

. Section 2 comprises slots 6�10

. Section 3 comprises slots 13�16

. Section 4 comprises slot 17 (in a 17-slot D500 subrack) or slots 17�21 (ina 21-slot D500 subrack).

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

79 (252)

Interface provisioning

Page 80: Dn03492199 4 en Global PDF Paper a4

2.6.1 DS3 ATM interface specifications

The DS3 interface provides a GR-499 compliant metallic SONET interface forconnecting the D500 system to the data network. It also provides egress addresstranslation, multiplexing, and timing resources. The DS3 interface passes theATM data stream to and from the ATM data network.

The DS3 tributary interface provides an interface for connecting another D500node, ATM switch, D50(e) or a third-party DSLAM to the D500 node. It can alsobe used as an additional trunk for traffic balancing purposes.

2.6.2 Provisioning parameters

All DS3 provisioning parameters can be set using Craft Terminal and thecommand line interface (CLI). For details on the user interface, see Web-basedCraft Terminal .

2.6.2.1 Framing and ATM mapping options

Framing option defines the usage of overhead bits of the DS3 frame whereas theATM mapping option defines the method of mapping of ATM cells to the DS3frame payload. These options must match the configuration of the far end. Thereare two framing options: DS3 C-bit parity application and DS3 M23 application.The C-bit parity application is recommended whenever the far end supports itbecause it is equal in payload peformance and has more features than the M23application. For example, far end alarms and far end performace monitoring arenot available with M23.

There are also two ATM cell mapping options to choose from: ATM directmapping (ADM) and Physical Layer Convergence Protocol (PLCP). The PLCPprovides an additional layer for fault and performance monitoring whilesacrificing some payload bandwidth.

The combined framing and ATM mapping options shown on the DS3 tab page inthe Line Type group are the following:

. Cbit Parity

- DS3 C-bit parity ATM direct mapping

. PLCP Cbit Parity

- DS3 C-bit parity, PLCP mapping (default)

. M23

- DS3 M23, ATM direct mapping

80 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 81: Dn03492199 4 en Global PDF Paper a4

. PLCP M23

- DS3 M23, PLCP mapping

2.6.2.2 Scrambling option

The user can select whether the ATM cell scrambling is enabled or disabled. Theoption affects the scrambling of both cell header and payload at the same time.The option must match the configuration of the far end. Cell Scrambling isenabled by default.

2.6.2.3 HEC coset option

The option affects the method of the header error checksum (HEC) check. If it isenabled, the coset polynomial is added to the checksum before comparison, asrequired by the ATM Forum UNI specification and ITU-T RecommendationI.432. The option must match the configuration of the far end. HEC Coset isenabled by default.

2.6.2.4 Equalisation option

In the DS3 line equalisation Default is used for lines longer than 255 feet (77.7m) and Low for shorter lines.

2.6.2.5 Interface timing option

There are two timing reference options for the DS3 unit in the Clock Sourcegroup:

. Node clock selects the mode in which the DS3 port is synchronised to theDS3 node clock (also known as the system synchroniser) of the D500node.

. Loop timing selects the mode in which the port uses the timing of its ownreceived signal as the timing reference.

The default setting is Node clock.

For additional provisioning information see Provisioning parameters.

2.6.3 Counters and thresholds

The DS3 interface allows the user to set a number of thresholds for near-end andfar-end performance parameters. The DS3 performace parameters are designedaccording to the ANSI standard T1.231. When a count exceeds a threshold, athreshold crossing warning appears on the management interface.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

81 (252)

Interface provisioning

Page 82: Dn03492199 4 en Global PDF Paper a4

The Physical PM tab page includes the following provisionable parameters in theSelection group:

. Interval (15 min/daily)

. Type (near/far end)

. Bin is used for browsing history records of the performance parameters;value 1 refes to current parameters.

The Clear button clears all current and history parameters and Graph& opens anew window to show history information graphically.

In monitoring the operation of DS3 ports, the user can select the PM data perinterval, type, and bin.

The Thresholds tab page allows the user to modify the following thresholds in 15-minute or daily intervals per line, path or PLCP:

. Coding Violations (CV) is the count of CP-bit parity errors occurring in theaccumulation period. The threshold parameter x yields 10x errorsthreshold.

. Errored Seconds (ES) is the count of seconds containing one or more CP-bit parity errors, one or more SEF defects, or one or more AIS defects.

. Severly Errored Seconds (SES) is the count of seconds containing 45 ormore CP-bit (P-bit in the M23 application) parity errors, one or more SEFdefects, or one or more AIS defects.

. Unavailable Seconds (UAS) is the count of one second intervals duringwhich the DS3 path is unavailable.

. Severly Errored Framing Seconds (SEFS) is the count of secondscontaining one or more SEF defects.

. SEF/AIS Seconds (SAS) is the count of seconds containing one or moreSEF defects or one or more AIS defects.

The BERT (Bit Error Rate Threshold) group allows the user to set thresholds forthe signal degrade and signal fail conditions.

Table 30. BERT

Parameter Default Range

Signal DegradeCondition

6 6�9

82 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 83: Dn03492199 4 en Global PDF Paper a4

Table 30. BERT (cont.)

Parameter Default Range

Signal Fail Condition 3 3�5

For additional provisioning information see Provisioning parameters.

Note

The Save command saves the new settings permanently.

For details on setting these thresholds, see the table below:

Table 31. Performance parameters

Line/Path/PLCP

Acronym Meaning Daily interval 15-minute interval

Line (NE)

CV-L Count of bipolarviolations (BPV) orexcessive zeros (EXZ)anomalies during theinterval

Range: 6�10

Default: 9

Range: 6�10

Default: 9

ES-L Count of secondsduring the interval inwhich one or more, butless than 45 CV-Lerrors have occurred

Range: 0�86400

Default: 250

Range: 0�900

Default: 25

SES-L Count of secondsduring the interval inwhich 45 or more CV-Lerrors have occurred

Range: 0�86400

Default: 0

0�900

Default: 0

UAS-L Count of secondsduring the interval inwhich LOS defect hasbeen active (defined inT1.231 as LOSS-L)

Range: 0�86400

Default: 0

0�900

Default: 0

Path (NE/FE)CV-P Count of path

anomalies during theinterval: In the DS3 C-

Range: 6�10

Default: 9

Range: 6�10

Default: 9

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

83 (252)

Interface provisioning

Page 84: Dn03492199 4 en Global PDF Paper a4

Table 31. Performance parameters (cont.)

Line/Path/PLCP

Acronym Meaning Daily interval 15-minute interval

bit parity application theCP-bit parity errors arecounted, and in the M23application P-bit errorsare counted as pathanomalies.

ES-P Count of secondsduring the interval inwhich one or more, butless than 45 pathanomalies haveoccurred

Range: 0�86400

Default: 250

Range: 0�900

Default: 25

SES-P Count of secondsduring the interval inwhich 45 or more pathanomalies haveoccurred

Range: 0�86400

Default: 40

Range: 0�900

Default: 4

UAS-P Count of secondsduring the interval inwhich the path hasbeen unavailable: Thepath becomesunavailable after 10continuous SES-Ps.The path becomesunavailable after 10continuous secondswithout SES-Ps

Range: 0�86400

Default: 10

Range: 0�900

Default: 10

SAS-P Count of seconds forwhich the out-of-frame(OOF) or AIS defecthas been active

Range: 0�86400

Default: 8

Range: 0�900

Default: 2

PLCP (NE/FE)

CVPLCP Count of PLCP BIPerrors during theinterval

Range: 6�10

Default: 9

Range: 6�10

Default: 9

ESPLCP Count of secondsduring the interval inwhich one or more, butless than 45 CVPLCP-P errors have occurred

Range: 0�86400

Default: 250

0�900

Default: 25

SEFS-PLCP Count of secondsduring the interval in

Range: 0�86400

Range: 0�900

84 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 85: Dn03492199 4 en Global PDF Paper a4

Table 31. Performance parameters (cont.)

Line/Path/PLCP

Acronym Meaning Daily interval 15-minute interval

which 45 or moreCVPLCPP errors haveoccurred

Default: 40 Default: 4

UASPLCP Count of secondsduring the interval inwhich the path hasbeen unavailable: ThePLCP path becomesunavailable after 10continuousSESPLCPPs. ThePLCP path becomesavailable after 10continuous secondswithout SESPLCPPs.

Range: 0�86400

Default: 10

Range: 0�900

Default: 10

SEFS-PLCP Count of seconds forwhich the out-of-frame(OOF) or AIS defecthas been active

Range: 0�86400

Default: 8

Range: 0�900

Default: 2

2.7 E1 provisioning

The following describes the provisioning parameters and operation of the D500E1 interface.

E1 can deliver 2048 kbit/s of data in both directions. The E1 trunk unit (TKE1)provides eight E1 ports to connect ATM end-users with the ATM backbone overE1 leased line replacement services. The E1 tributary unit (TBE1) provides 16 E1ports.

Note

The E1 trunk/control unit is not included in Release 3.2.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

85 (252)

Interface provisioning

Page 86: Dn03492199 4 en Global PDF Paper a4

2.7.1 IMA

The E1 interface supports IMA (Inverse Multiplexing for ATM) functionality.

The purpose of IMA is to provide inverse multiplexing of an ATM cell streamover multiple physical links and to retrieve the original stream at the far-end fromthese physical links. The multiplexing of the ATM cell stream is performed on acell by cell basis across the multiple physical links.

The main inverse multiplexing function is to control the distribution of cells ontothe group of physical links made available to the IMA interface. Other mainfunctions include handling of differential delays and actions to be taken whenlinks are added or dropped or when they are failed or need to be restored. In thereceive direction, the IMA interface performs differential delay compensation andrecombines the cells into the original cell stream while introducing minimal celldelay variation (CDV). In essence, the inverse multiplexing functions emulate asingle UNI/NNI/BICI physical link; the IMA process of splitting andrecombining streams is as transparent to the layer above as a traditional single-link physical layer interface.

The ATM inverse multiplexing technique involves inverse multiplexing and de-multiplexing of ATM cells in a cyclical fashion among links grouped to form ahigher bandwidth logical link whose rate is approximately the sum of the linkrates. This is referred to as an IMA group.

The figure below provides a simple illustration of the ATM inverse multiplexingtechnique in one direction. The same technique applies in the opposite direction.

Figure 10. Inverse multiplexing and de-multiplexing of ATM cells via IMA groups

IMA GroupPHY

PHY

PHY

Physical link #0

Physical link #1

Physical link #2

IMA GroupPHY

PHY

PHY

IMA Virtual Link

TX direction: cells distributed across links in round robinsequenceRX direction: cells recombined into single ATM stream

Single ATM CellStream from ATMLayer

Original ATM CellStream to ATMLayer

86 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 87: Dn03492199 4 en Global PDF Paper a4

IMA groups terminate at each end of the IMA virtual link. In the transmitdirection, the ATM cell stream received from the ATM layer is distributed on acell by cell basis across the multiple links within the IMA group. At the far-end,the receiving IMA unit recombines the cells from each link, on a cell by cellbasis, recreating the original ATM cell stream. The aggregate cell stream is thenpassed to the ATM layer.

The IMA interface periodically transmits special cells that contain informationthat permit reconstruction of the ATM cell stream at the receiving end of the IMAvirtual link. The receiver end reconstructs the ATM cell stream after taking intoaccount the link differential delays, smoothing CDV introduced by the controlcells, etc. These cells, defined as IMA Control Protocol (ICP) cells, provide thedefinition of an IMA frame. The transmitter must align the transmission of IMAframes on all links. This allows the receiver to adjust for differential link delaysamong the constituent physical links. Based on this required behaviour, thereceiver can detect the differential delays by measuring the arrival times of theIMA frames on each link.

At the transmitting end, the cells are transmitted continuously. If there are noATM layer cells to be sent between ICP cells within an IMA frame, then the IMAtransmitter sends filler cells to maintain a continuous stream of cells at thephysical layer. The insertion of filler cells provides cell rate decoupling at theIMA sublayer. The filler cells should be discarded by the IMA receiver.

IMA utilisation alarms

Each IMA group provides a bandwidth utilisation % value. The value shows thecurrent bandwidth utilisation level of the group as percentage.

When the total bandwidth utilisation of all active E1 links in the IMA groupexceeds the Severe Level% bandwidth utilisation threshold for a set period oftime, a utilisation alarm is generated (Active Report). Severe Level% and ActiveReport can be configured for each IMA group separately. The default value forSevere Level% is 90 (90%).

When the utilisation alarm is active and the bandwidth utilisation of all active E1links in the IMA group drops below the Abate Level% threshold for a set periodof time, a utilisation alarm is cleared (Clear Report). Abate Level% and ClearReport can be configured for each IMA group separately. The default value forAbate Level% is 70 (70%).

The utilisation alarm can be configured in both ingress and egress direction. It ispossible to enable/disable the utlisation alarm in the IMA group and the defaultsetting is Disabled.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

87 (252)

Interface provisioning

Page 88: Dn03492199 4 en Global PDF Paper a4

2.7.2 E1 card applications

The E1 units provide an E1 ATM-based leased line replacement service for ATMservices over E1. Compared to xDSL technology, the ATM-based E1 service canprovide an extensive reach well beyond the Central Office with the use ofrepeated E1 lines over existing line terminal (Span) systems.

2.7.3 Provisioning parameters

The E1 interface provisioning parameters include:

. E1 parameters: Per port provisioning of the E1 transmission from the farend user equipment to the E1 unit.

. Thresholds: Setting of thresholds to generate events or alarms in CraftTerminal for purposes of performance data collection.

2.7.4 Provisioning E1 parameters

The following parameters must be provisioned for the E1 port.

. Transmit clock source

Select the timing mode from the following two options:

- Loop timing: The E1 card obtains the timing from the far-end userequipment.

- Node clock: The E1 card obtains timing from the D500 system. Thefar-end user equipment must either use the same network timingsource or be configured for loop timing if the D500 E1 unit is set tothe node clock, and vice versa.

. Line loopback: The E1 interfaces support line loopback at the physicallayer.

. Terminal loopback: The E1 interfaces support terminal loopback at thephysical layer.

. BERT (Bit Error Rate Test): The E1 interfaces support BERT per portbasis.

2.7.5 E1 thresholds

The following thresholds are set and viewed using Craft Terminal or the CLI. Thedefault setting is 0 (zero) or inactive, except where noted:

88 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 89: Dn03492199 4 en Global PDF Paper a4

. Loss of frame (LOF) seconds thresholds

Daily and 15-minute thresholds can be set. The LOF seconds thresholdsettings are the number of seconds during which an LOF condition waspresent. An event is reported to Craft Terminal when the LOF secondsthreshold is crossed.

. Loss of signal (LOS) seconds thresholds

The loss of signal condition is monitored during the data mode. Daily and15-minute thresholds can be set. The LOS seconds threshold settings arethe number of seconds during which an LOS condition was present. Anevent is reported to Craft Terminal when the LOS seconds threshold iscrossed.

. Loss of cell delineation (LCD)

The LCD seconds threshold settings are the number of seconds duringwhich an LCD condition was present. An event is reported to CraftTerminal when the LCD seconds threshold is crossed.

. Coding violation thresholds

Coding violation errors are a count of BPV (bipolar violations) errorsreceived during the data mode. Daily and 15-minute thresholds can be setfor path and line. The coding violation parameters have thresholds forreporting an event to Craft Terminal.

. Errored seconds thresholds

Errored seconds are the cumulative number of seconds the port is in anLOF, LOS, or a coding violation condition. Errored seconds are monitoredduring all operational modes. Daily and 15-minute thresholds can be set forpath and line. An event is reported to Craft Terminal when the erroredseconds threshold is crossed.

. Severely errored seconds (SES)

This is the count of seconds containing one or more severe errors. Dailyand 15-minute thresholds can be set for path and line. An event is reportedto Craft Terminal when the SES threshold is crossed.

. Unavailable seconds (UAS)

This is the count of one second intervals during which the E1 unit is notavailable. Daily and 15-minute thresholds can be set for path and line. Anevent is reported to Craft Terminal when the UAS threshold is crossed.

. SEF/AIS seconds (SAS)

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

89 (252)

Interface provisioning

Page 90: Dn03492199 4 en Global PDF Paper a4

This is the count of seconds containing one or more SEF (severely erroredframes) defects or AIS (alarm indication signal) defects. Daily and 15-minute thresholds can be set for path and line. An event is reported to CraftTerminal when the SAS threshold is crossed.

2.7.6 Performance monitoring counters

The following physical layer performance monitoring counters are available forthe E1 interfaces:

. LOF: Loss of frame seconds

. LOS: Loss of signal seconds

. LCD: Loss of cell delineation

. CV-L: Code violations�line

. ES-L: Errored seconds�line

. SES-L: Severely errored seconds�line

. UAS-L: Unavailable seconds�line

. SEFS-P: Severly errored framing seconds, (RFC 2495)

. CV-P: Code violations�path, (RFC 2495)

. ES-P: Errored seconds�path, (RFC 2595)

. SES-P: (or SAS-P): Severly errored seconds�path, (RFC 2495)

. UAS-P: Unavailble seconds�path, (RFC 2495, G.826)

. Elapsed time (current 15 minutes): Total amount of time in the current 15-minute performance monitoring interval

. Elapsed time (current 24 hours): Total amount of time in the current 24-hour performance monitoring interval

. Elapsed time (previous day): Total amount of time in the performancemonitoring interval of the preceding day.

2.7.7 ATM performance management

The following ATM performance management actuals are available:

90 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 91: Dn03492199 4 en Global PDF Paper a4

. Cells received: Total number of cells received on the channel since the cardreset or counter reset

. Cells transmitted: Total number of cells transmitted on the channel sincethe card reset, or counter reset

. HEC errors: Total number of received cells that have header error control(HEC) errors detected in their header.

2.7.8 Provisioning IMA

To use IMA (Inverse Multiplexing for ATM) functionality of the E1 interface, theuser must create IMA groups by specifying which ports form the group. An IMAgroup in TKE1 may contain 1�8 ports (links). It is possible to create up to 8groups for an E1 trunk unit. An IMA group in TBE1 may contain 1�8 ports. It ispossible to create up to 16 groups for an E1 tributary unit. One port, the masterport, of the group identifies the IMA group and cannot be removed from thegroup. Other ports, which do not belong to any group, can be added to and laterremoved from the group. The IMA protocol version can be chosen between v1.0or v1.1. The default is v1.1. V1.0 is needed to ensure inter-operatibility, if the far-end supports only IMA v1.0.

To provision the following IMA parameters common to all IMA groups, selectTools => View Properties, click the E1 unit and then the Configuration tab page:

. Alpha Value: The 'alpha' value is used to specify the number ofconsecutive invalid ICP cells to be detected before moving to the IMAHunt state from the IMA Sync state. The value range is 1�2.

. Beta Value: The 'beta' value is used to specify the number of consecutiveerrored ICP cells to be detected before moving to the IMA Hunt state fromthe IMA Sync state. The value range is 1�5.

. Gamma Value: Configure the 'gamma' value used to specify the number ofconsecutive valid ICP cells to be detected before moving to the IMA Syncstate from the IMA PreSync state. The value range is 1�5.

To provision the following parameters in the New IMA Group dialog box, selectConfigure => New IMA Group... at the unit level.

. Minimum Links: Minimum number of transmit and receive links requiredto be active for the IMA group to be in the Operational state

. Tx Clock Mode: Transmit clocking mode used by the IMA group

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

91 (252)

Interface provisioning

Page 92: Dn03492199 4 en Global PDF Paper a4

- Common Transmit Clock (CTC): The transmit clock of all IMAlinks are derived from the same source.

- Independent Transmit Clock (ITC): There is at least one IMA linkwhose transmit clock is derived from a source different than at leastanother link transmit clock.

Note

To modify the transmit clocking mode of an existing IMA group, delete the IMAgroup and then create it again with the required transmit clocking mode.

. Tx IMA ID: Value range 0�255

. Frame Length: Frame length to be used by the IMA group in the transmitdirection

. Diff Delay Max: Maximum number of milliseconds of differential delayamong the links that will be tolerated.

The following Bandwidth Utilization alarm parameters are provisionable at theIMA group level. The parameters are similar in the ingress and egress directions.

. Enable/disable: Enables/disables the alarm detection

- By default the alarm is disabled.

. Abatement: Abatement level % for the Bandwidth Utilization alarm

. Severe: Severe level % for the Bandwidth Utilization alarm

. RptAct: Active report time (in seconds) for the Bandwidth Utilizationalarm

. RptClr: Clear report time (in seconds) for the Bandwidth Utilization alarm

The links of an IMA group can be tested during normal operation withoutdisturbing the payload. The following parameters are used for provisioning thetest:

. Test Link is used in the test pattern procedure. Value Any means that theimplementation chooses the test link.

. Tx Pattern is used in an IMA group loopback operation. The range 0 to 255designates a specific pattern. The distinguished value of -1 specifies thatthe implementation chooses the value.

. Start/Stop starts or stops the test pattern procedure.

92 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 93: Dn03492199 4 en Global PDF Paper a4

2.7.9 IMA group actuals and performance statistics

The following actuals are available for the IMA groups:

. State

NE/FE: State of an IMA group

. Failures

NE/FE: Number of times a group failure (Config-Aborted, Insufficient-Links) has been reported since power-up or reboot

. Tx Clock Mode

NE/FE: Indicates the transmit clock mode of an IMA group

- There are two possible modes: Common Transmit Clock (CTC) andIndependent Transmit Clock (ITC). The CTC mode corresponds tothe case when the transmit clock of all IMA links are derived fromthe same source. The ITC configuration corresponds to the casewhere there is at least one IMA link whose transmit clock is derivedfrom a source that is different from a minimum of one source used inthe IMA group.

. IMA ID

Tx/Rx: IMA ID currently in use by the near-end/far-end IMA function

. Timing Ref. Link

Tx: Port index of the transmit timing reference link to be used by the near-end for IMA data cell clock recovery from the ATM layer

- Value 0 may be used, if no link has been configured in the IMAgroup, or if the transmit timing reference link has not yet beenselected.

Rx: Port index of the receive timing reference link to be used by the near-end for IMA data cell clock recovery toward the ATM layer

- Value 0 may be used, if no link has been configured in the IMAgroup, or if the receive timing reference link has not yet beendetected.

. Frame Length

Tx/Rx: Length of the IMA frames

. Configured Links

Tx: Number of links that are configured to transmit in this IMA group

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

93 (252)

Interface provisioning

Page 94: Dn03492199 4 en Global PDF Paper a4

- This attribute overwrites the value of the imaGroupNumRxActLinksattribute when the IMA group is configured in the SymmetricalConfiguration group symmetry mode.

Rx: Number of links that are configured to receive in this IMA group

- This attribute is overwritten by the value of theimaGroupNumTxActLinks attribute when the IMA group isconfigured in the Symmetrical Configuration group symmetrymode.

. Active links

Tx: Number of links that are configured to transmit and are currently activein this IMA group

Rx: Number of links that are configured to receive and are currently activein this IMA group

. Available Cell Rate

Tx: Current cell rate (truncated value in cells per second) provided by thisIMA group in the transmit direction, considering all the transmit links inthe active state

Rx: Current cell rate (truncated value in cells per second) provided by thisIMA group in the receive direction, considering all the receive links in theactive state

. Cell Counter

Tx: Number of ATM cells transmitted by this IMA group

Rx: Number of ATM cells received by this IMA group

. Curr. BW Utilization

Tx: Current transmit bandwidth utilization level of the group as percentage

Rx: Current receive bandwidth utilization level of the group as percentage

. OAM Label Value

Tx: IMA OAM Label value transmitted by the NE IMA unit

Rx: IMA OAM Label value transmitted by the FE IMA unit

- Value 0 may mean that the IMA unit has not received an OAMLabel from the FE IMA unit.

. Failure Status

NE/FE: Failure reason of an IMA group

. Least Delay Link

94 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 95: Dn03492199 4 en Global PDF Paper a4

Port index of the link configured in the IMA group that has the smallestlink propagation delay.

- Value 0 may be used if no link has been configured in the IMAgroup, or if the link with the smallest link propagation delay has notyet been determined.

. Max Diff. Delay Obs

Latest maximum differential delay observed (in milliseconds) between thelinks having the smallest and biggest link propagation delay, among thereceive links that are currently configured in the IMA group

. Last Change

Time-of-day the IMA group last changed the NE operational state

. Curr. Interval Secs

Number of seconds that have elapsed since the beginning of the currentmeasurement period

- This attribute is mandatory only when the IMA Group CurrentStatistics are implemented.

. Running Seconds

Amount of time (in seconds) since the IMA group has been in theoperational state

. Unavail Seconds

Count of one second intervals, where the IMA Group Traffic StateMachine is down

. Valid Intervals

Number of the previous 15-minute intervals for which the valid data wascollected

- The value is 96 unless the IMA group was created within the last 24hours, in which case the value is the number of the complete 15-minute intervals since the IMA group creation.

. Invalid Intervals

Number of intervals for which no valid data is available.

The following performance monitoring statistics are available for IMA groups:

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

95 (252)

Interface provisioning

Page 96: Dn03492199 4 en Global PDF Paper a4

. Unavailable seconds (UAS)

Count of one-second intervals where the IMA Group Traffic State Machineis down in the current 15-minute interval

. Ne Num Failures (NeFC)

Number of times a near-end group failure (Config-Aborted, Insufficient-Links) has been reported in the current 15-minute interval

. Fe Num Failures (FeFC)

Number of times a far-end group failure (Config-Aborted-FE, Insufficient-Links-FE, Blocked-FE) has been reported in the current 15-minute interval

. Status

Interval status is the selected valid interval.

The performance monitoring statistics can be retrieved from the followingperiods:

. Current: Statistics for the current 15 minute interval

. Interval: Statistics for the past 24 hours broken into 96 completed 15-minute intervals

. Total: The cumulative sum of statistics for the 24 hour period preceding thecurrent interval.

2.7.10 IMA link actuals and performance statistics

To see the IMA link tab pages, select a link from the Current Links box and clickView Link... on the Links tab page in the IMA Group Configuration dialog box.The following actuals are available for each IMA link:

. Tx State

NE: Current state of the near-end transmit link

FE: Current state of the far-end transmit link as reported via ICP cells

. Rx State

NE: Current state of the near-end receive link

FE: Current state of the far-end receive link as reported via ICP cells

. Rx Failure Status

96 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 97: Dn03492199 4 en Global PDF Paper a4

NE: Current link failure status of the near-end receive link

FE: Current link failure status of the far-end receive link as reported viaICP cells

. Sev. Errored Seconds

NE: Count of one-second intervals containing >= 30% of the ICP cellscounted as IV-IMAs, or one or more link defects (for example LOS, OOF/LOF, AIS, or LCD), LIF defects, or LODS defects, except during the UAS-IMA condition

FE: Count of one-second intervals containing one or more RDI-IMAdefects, except during the UAS-IMA-FE condition

. Unavailable Seconds

NE: Count of unavailable seconds at the near-end: unavailability begins atthe onset of 10 contiguous SES-IMA conditions and ends at the onset of 10contiguous seconds with no SES-IMA conditions

FE: Count of unavailable seconds at the far-end: unavailability begins atthe onset of 10 contiguous SES-IMA-FE conditions and ends at the onsetof 10 contiguous seconds with no SES-IMA-FE conditions

. Tx Unusable Seconds

NE: Count of Tx Unusable Seconds at the near-end Tx LSM

FE: Count of seconds with Tx unusable indications from the far-end TxLSM

. Rx Unusable Seconds

NE: Count of Rx Unusable Seconds at the near-end Rx LSM

FE: Count of seconds with Rx unusable indications from the far-end RxLSM

. Tx Failures

NE: Number of times a near-end transmit failure alarm condition has beenentered on this link

FE: Number of times a far-end transmit failure alarm condition has beenentered on this link

. Rx Failures

NE: Current link failure status of the near-end receive link

FE: Current link failure status of the far-end receive link as reported viaICP cells

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

97 (252)

Interface provisioning

Page 98: Dn03492199 4 en Global PDF Paper a4

. Link ID

Tx: Outgoing LID used currently on the link by the local end

- This value has meaning only if the link belongs to an IMA group.

Rx: Incoming LID used currently on the link by the remote end as reportedvia ICP cells

- This value has meaning only if the link belongs to an IMA group.

. Stuff Events

Tx: Count of stuff events inserted in the transmit direction

Rx: Count of stuff events detected in the receive direction

. Cell Counter

Tx: Number of ATM cells transmitted

Rx: Number of ATM cells received

. Relative Delay (ms)

Latest measured delay on this link relative to the link with the least delay inthe same IMA group

. ICP Violations

Count of errored, invalid or missing ICP cells, except during SES-IMA orUAS-IMA conditions

. OIF Anomalies

NE: Number of OIF anomalies, except during SES-IMA or UAS-IMAconditions

. Valid Intervals

Number of previous 15-minute intervals for which valid data was collected

- The value is 96 unless the IMA group table entry has been createdwithin the last 24 hours, in which case the value is the number ofcomplete 15-minute intervals since the IMA group table entry wascreated.

. Invalid Intervals

Number of intervals for which no valid data is available

. Curr. Interval Secs

Number of seconds that have elapsed since the beginning of the currentmeasurement period.

98 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 99: Dn03492199 4 en Global PDF Paper a4

The following performance statistics are available for each IMA link:

. ICP Violations

Count of errored, invalid or missing ICP cells, except during SES-IMA orUAS-IMA conditions

. OIF Anomalies

NE: Number of OIF anomalies, except during SES-IMA or UAS-IMAconditions

. SevErrorSec

NE: Count of one-second intervals containing >= 30% of the ICP cellscounted as IV-IMAs, or one or more link defects (for example LOS, OOF/LOF, AIS, or LCD), LIF defects, or LODS defects, except during the UAS-IMA condition

FE: Count of one-second intervals containing one or more RDI-IMAdefects, except during the UAS-IMA-FE condition

. Unavailable Sec

NE/FE: Count of unavailable seconds

. Tx Unusable Sec

NE: Count of unusable seconds at the near-end Tx LSM

FE: Count of seconds with Tx unusable indications from the far-end TxLSM

. Rx Unusable Sec

NE: Count of unusable seconds at the near-end Rx LSM in the current 15-minute interval

FE: Count of seconds with Rx unusable indications from the far-end RxLSM

. Tx Num Failures

NE: Number of times a near-end transmit failure alarm condition has beenentered on this link

FE: Number of times a far-end transmit failure alarm condition has beenentered on this link

. Rx Num Failures

NE: Number of times a near-end receive failure alarm condition has beenentered on this link

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

99 (252)

Interface provisioning

Page 100: Dn03492199 4 en Global PDF Paper a4

FE: Number of times a far-end receive failure alarm condition has beenentered on this link

. Tx Stuffs

Count of stuff events inserted in the transmit direction

. Rx Stuffs

Count of stuff events detected in the receive direction.

100 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 101: Dn03492199 4 en Global PDF Paper a4

3 Timing provisioning

3.1 Timing settings

The following provides information on timing settings for the node clock andeach interface in the D500 system.

3.1.1 Node timing

In an SDH or SONET network, it is essential that all the nodes operate insynchronisation with each other. In the D500 system, this is ensured by using thesignal of any supported line interface received from the SDH/SONET network asthe timing reference.

The node clock can operate in a free-run, locked or hold-over mode. The clocktype is configurable; the user can select either SDH Equipment Clock (SEC) orSONET Minimum Clock (SMC). The default clock type depends on the subrackas follows:

. 17-slot subrack: SDH

. 21-slot subrack: SONET

. RAM subrack: SDH.

The clock quality is according to ITU-T G.813 SEC Option 1 (SDH) or Option 2(SONET). In the free-run mode accuracy has been relaxed to ±20 ppm andholdover stability to 4.6 ppm.

Node timing options

There are three timing options available for the node clock in the D500 subrack:Internal, Line and External. You can access them by opening the tab pages forthe subrack in the Node views of Craft Terminal.

If the timing option is set to Internal, the node uses its internal clock as the timingreference. In other words, the node clock is in a free-run mode.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

101 (252)

Timing provisioning

Page 102: Dn03492199 4 en Global PDF Paper a4

If the timing option is set to Line, the node retrieves its timing from an outsidereference, for example:

. from the OC-3/STM-1 or OC-12/STM-4 trunk signal coming from the corenetwork

. from the signal of any supported line interface (for example OC-3/STM-1,DS3, or E1) connected to a tributary unit.

The timing reference can be received from the signal of any supported lineinterface (OC-3/STM-1, OC-12/STM-4, DS3 or E1). Together with theLine timing option, the reference port is shown by Craft Terminal, forexample: Line (Port 1 / Unit 11).

Note

Two different mappings are specified for transporting the ATM cell overDS3 transmission systems: PLCP-based system and direct mapping system.This affects how the timing reference is derived from the DS3 signal. If thePLCP-based mapping is selected, the reference for the node clock is retrievedfrom the received PLCP frame rate. If direct mapping is selected, thereference is retrieved from the received DS3 line rate. As the DS3 line rate istypically not used to distribute network timing information, be careful innetwork planning if the DS3 signal with direct mapping is used as the timingreference.

If the timing option is set to External, the external timing input signal is used asthe node clock reference. The external timing interface can be 1.5Mbit/s, 2Mbit/s,1.5MHz, or 2MHz.

The connectors for external timing are located on the connector panel. Input andoutput connectors can be used to daisy chain several nodes. A 120-ohmtermination resistor must be connected to the output of the last node.

102 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 103: Dn03492199 4 en Global PDF Paper a4

Figure 11. External synchronisation

The default setting for the timing option depends on the interface type of trunk/control unit installed in the D500 subrack. In an ATM trunk/control unit(TKATM_155_622) the default setting is Line. In a trunk/control unit withGigabit Ethernet interface (TK1000, TKETH1G) the default setting is Internal.

Note

Always use the Line timing option in a D500 node connected to an SDH/SONETnetwork.

In SDH and SONET networks, synchronisation status messaging is used to avoidsynchronisation loops. The D500 node monitors the received SSM(Synchronisation Status Message) for each STM-n interface. If the received SSMis QL-DNU (do not use, value = 15), the interface cannot be selected as the nodeclock reference. If the received SSM for a selected reference switches to QL-DNU, the node clock enters the hold-over mode.

By default the transmitted SSM is QL-SEC (value = 11) if node clock type SEC isselected (SDH mode), or QL-SMC (value = 12) if node clock type SMC isselected (SONET mode). QL-DNU is transmitted from the interface that has beenselected as the timing reference.

The node switches to the hold-over mode if the interface used as a timingreference has one of the following conditions:

Cable from thetiming source

Termination resistor(or the cable to thenext D500 node)

Tip

ShieldRing

SYNCIN

SYNCOUT

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

103 (252)

Timing provisioning

Page 104: Dn03492199 4 en Global PDF Paper a4

. LOS

. LOF

. line AIS

. received SSM = DNU.

The node clock enters a hold-over mode before the failure is declared in themanagement interface.

The D500 rises an alarm and a standing condition if the node clocksynchronisation is lost for a period longer than five minutes.

Setting the timing option for the node clock

Follow these steps to set the timing option:

1. In setting the node clock to lock to the OC-3/STM-1 or OC-12/STM-4signal (or to the signal of any other supported line interface), internal clockor external clock, select Node => Properties => ManagementConfiguration => General Configuration.

2. In the Timing Option box, select Internal, Line or External.

. Line is the default setting for the node with the OC-3/STM-1 or OC-12/STM-4 trunk. Line can be selected for the node with the GigabitEthernet trunk if there is a tributary unit in any slot that canaccommodate a tributary unit. Select an appropriate tributary unitand port.

. Internal is the default setting for the node with the Gigabit Ethernet(GE) trunk.

. External is selected when the node with the ATM or GE trunk usesthe external timing input signal as the node clock reference.

3. Click Apply.

3.1.2 Interface timing

In addition to the node-clock timing-reference options for the subrack, the OC-3/STM-1, DS3, and E1 tributary units have two timing options for their lineinterfaces: Node clock and Loop Portn (n = 1�4).

When Node clock is selected for a line interface, the interface uses the sametiming reference as the rest of the node, that is, the node clock which is either inexternal, internal or line timing, depending on the setting described above. Thedefault setting is Node clock for each interface.

104 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 105: Dn03492199 4 en Global PDF Paper a4

Loop timing is a feature that allows building ATM networks with separate clockdomains for single links, instead of using a top-down common clock distributionthrough the whole network. In loop timing, the line interface is in a separate clockdomain instead of being locked to the D500 node clock. The interface at the otherend of the link cannot be in loop timing because a link with both ends set to looptiming does not work properly.

The interface on the ATM trunk is always locked to the node clock, in otherwords, it does not support loop timing.

OC-3/STM-1 interface timing

For an OC-3/STM-1 tributary unit the interface timing option is selected per unit,not per port. All line interfaces in a tributary unit use the same timing reference,either the node clock or one of the received signals as the loop timing reference.

When the OC-3/STM-1 tributary interfaces are in loop timing, all transmitters arelocked to the received signal in the selected port that can be any of the four portsof the same unit. However, if one of the ports has been selected as the node clockreference, only that port can be used for loop timing reference. On the other hand,there is usually no reason to use loop timing in an interface that has already beenselected as the line timing reference for the node clock.

When an interface of the OC-3/STM-1 tributary unit is set to loop timing, thesynchronisation status message (SSM) that it sends is set to DNU (Do Not Use).When it is no longer in loop timing, the previous SSM value is restored. Only theinterface that is used as the timing reference sends DNU. The other interfaces aresending the SSM that has been configured.

DS3 interface timing

Two different mappings are specified for transporting the ATM cell over DS3transmission systems: PLCP-based system and direct mapping system. Thisaffects how the timing reference is derived from the DS3 signal. If the PLCP-based mapping is selected when the DS3 interface is in loop timing, thetransmitted PLCP frame rate is locked to the received PLCP frame rate in eachDS3 interface. If direct mapping is selected, the transmitted line rate is locked tothe received line rate.

E1 interface timing

All IMA groups in the Common Transmit Clock (CTC) mode use the node clockas a line transmit clock for all E1 ports in the group. In other words, for these E1interfaces the timing option is Node clock. All IMA groups in the IndependentTransmit Clock (ITC) mode use Loop timing for each E1 port within the group.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

105 (252)

Timing provisioning

Page 106: Dn03492199 4 en Global PDF Paper a4

Setting the timing option for OC-3/STM-1 tributary interfaces

Follow these steps to set the loop timing or locked to the node clock option:

1. Select Tools => View Properties.

2. Click a tributary unit.

3. Click the Configuration tab page.

4. In the Interface Timing drop-down menu, select Loop Portn (n = 1�4) orNode clock.

5. Click Apply.

Setting the timing option for DS3 and E1 tributary and trunk interfaces

Follow these steps to select the timing option:

1. Right-click the unit and select Go to Port Views.

2. Double-click the port for which you want to set the timing option.

3. Select the DS3 or E1 tab page.

4. In the Interface Timing drop-down menu, select Loop timing or Nodeclock.

5. Click Apply.

3.1.3 Recommended settings

Which timing option you should use, depends on

. the interface type of trunk/control unit: whether you use an ATM trunk/control unit or a Gigabit Ethernet (GE) trunk/control unit

. if you use a GE trunk/control unit, whether you have an OC-3/STM-1,DS3 or E1 tributary unit installed in any slots in the D500 subrack that canaccommodate a tributary unit.

1) ATM trunk unit (TKATM_155_622)

In a configuration including an OC-3/STM-1 or OC-12/STM-4 trunk, asillustrated in the following figure, use the Line (Port 1 / Unit 11) timing option toselect the received OC-3/STM-1 or OC-12/STM-4 signal as timing reference. AnOC-3/STM-1 or OC-12/STM-4 signal that transports timing quality generated atleast by a SEC or SMC must be used to ensure that the D500 operatessynchronously with the rest of the SDH/SONET network.

106 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 107: Dn03492199 4 en Global PDF Paper a4

Figure 12. ATM trunk unit

2) GE trunk unit (TK1000, TKETH1G) with a tributary unit installed in any slotthat can accommodate a tributary unit

In this configuration, the node can retrieve its timing from the received signal inthe selected port of an OC-3/STM-1, DS3 or E1 tributary unit installed in any slotin the D500 subrack that can accommodate a tributary unit.

2.a If a tributary unit is connected to an SDH or SONET network, as shown in thefigure below, a signal from the SDH or SONET network that transports a timingquality generated at least by a SEC or SMC must be used as the timing reference.Set the timing option to Line (Port n/ Unit m) (n = 1�4, m = any slot that canaccommodate a tributary unit).

Note

Two different mappings are specified for transporting the ATM cell overDS3 transmission systems: PLCP-based system and direct mapping system.This affects how the timing reference is derived from the DS3 signal. If thePLCP-based mapping is selected, the reference for the node clock is retrievedfrom the received PLCP frame rate. If direct mapping is selected, the

TKATM

ATM

Node Timing Option:Line (Port 1 / Unit 11)

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

107 (252)

Timing provisioning

Page 108: Dn03492199 4 en Global PDF Paper a4

reference is retrieved from the received DS3 line rate. As the DS3 line rate istypically not used to distribute network timing information, be careful innetwork planning if the DS3 signal with direct mapping is used as the timingreference.

Figure 13. GE trunk with the tributary unit connected to the SDH/SONETnetwork

2.b In a multiple node configuration, as shown in the following figure, use timingoption Internal in the node acting as the timing source. Use timing optionExternal if an external timing reference is available. Use timing option Line(Port 1/ Unit 11) in the subtended node(s).

SDH

SONET

IP

Node Timing Option:Line (Port 1 / Unit 2)

TK1000

TRB155

108 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 109: Dn03492199 4 en Global PDF Paper a4

Figure 14. Multiple node configuration

3) GE trunk (TK1000) without a tributary unit in the D500 subrack

In this configuration, use Internal or External as the timing option.

IP

TRK155

TK1000

Node TimingOption: Line(Port 1 / Unit 11)

TRB155

Node TimingOption: Internalor external (if anexternal referenceis available)

Synchronisation referencefrom an externalsynchronisation source

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

109 (252)

Timing provisioning

Page 110: Dn03492199 4 en Global PDF Paper a4

Figure 15. GE trunk without a tributary unit

4) ATM trunk unit (TKATM_155_622) connecting the ATM networks of twodifferent operators in the D500 subrack.

In this configuration,

. for the node clock timing, use the Line (Port 1 / Unit 11) timing option

. for tributary interfaces, use the Loop Portn (n = 1�4).

Note

Even when not using the loop timing mode, error-free transmission is guaranteedwith up to 4.6 ppm frequency difference between Carrier 1 and Carrier 2networks.

IP

TK1000

Node TimingOption: Internalor external (if anexternal referenceis available)

Synchronisation referencefrom an externalsynchronisation source

110 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 111: Dn03492199 4 en Global PDF Paper a4

Note

If a tributary port is set to loop timing (as in the figure below), the correspondinginterface in the network of Carrier 2 must not be in loop timing, because a linkwith both ends set to loop timing mode does not work properly.

Figure 16. ATM trunk connecting two ATM networks

3.2 Connecting external timing

Purpose

The D500 RAM can accept external timing signals from two primary referencesources:

TRB155

Interface TimingMode Option: Loop

Node TimingOption: Line(Port 1 / Unit 11)

ATMCarrier 2

ATMCarrier 1

TKATM

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

111 (252)

Timing provisioning

Page 112: Dn03492199 4 en Global PDF Paper a4

. ATM network: The timing signal is received directly at the port of theATM trunk/control unit or tributary unit.

. BITS/SSU: An intraoffice timing source, such as a BITS or SSU, suppliesthe primary reference source to the D500 RAM. The timing signal isreceived at the 3-pin SYNC connectors on the power unit.

The following procedure explains how to connect an interoffice timing source tothe D500 RAM power unit. The power unit contains two 3-pin sync connectorsfor timing signal input and output. The output connector allows you to transmitthe same timing signal to a second D500 RAM.

Steps

1. Locate and route the Feed A and Feed B cables from the BITS/SSUclock to D500 RAM.

2. Using wire cutters, strip back insulation on Feed A, Feed B, and theground wires by 1/4 inch on both the input cable wires.

Note

If you are using the output connector to subtend timing to another D500 RAM,prepare the output cable in the same way as the input cable.

3. Insert the three wires into the terminal block.

Figure 17. 3-pin terminal block

Wire Holes

TighteningScrews

Plug into SYNCConnector onPower Unit

112 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 113: Dn03492199 4 en Global PDF Paper a4

4. Tighten the screws on the terminal blocks until a good connection ismade.

5. Route the input and output cables (if used) to the termination point forthe terminal blocks on the D500 RAM, per local procedures.

6. Plug the terminal block for the input cable into the 3-pin SYNC INconnector on the power unit.

If you are subtending timing to a second device, connect the terminal blockfor the output cable to the second device into the 3-pin SYNC OUTconnector on the power unit.

Figure 18. Power unit SYNC IN and OUT connectors

Further information

Repeat the procedure for all additional D500 RAM subracks at the site.

Alarm Connectors

1234

GNDGND

A B AB

S Y N C

O U T I N

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

113 (252)

Timing provisioning

Page 114: Dn03492199 4 en Global PDF Paper a4

114 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 115: Dn03492199 4 en Global PDF Paper a4

4 Packet-based provisioning

4.1 Subinterface provisioning

A subinterface is a logical entity created as part of a trunk port, tributary port, or aline card port. There can be one or more subinterfaces associated with a physicalport. Depending on a port type (ATM or Ethernet), a subinterface is defined as anendpoint for an ATM virtual circuit (VCC), or a VLAN on the Ethernet side.

Unlike in ATM switched connections where ATM cells are switched on the basisof cell headers only, in packet-based operation layer 2/3 switching is based on theMAC or IP header of the packet. This means that ATM subinterfaces cantransport only AAL5 traffic and the RFC 2684 -based AAL5 encapsulation type(for instance LLC/SNAP or VC Muxed, bridged or routed) must be defined foreach packet-based ATM connection.

The following subinterfaces can be provisioned:

. Routed

. Routed Bridged (RBE)

- Client side connection

. Bridged

. PPPoA

- Client side connection

4.1.1 Routed subinterface

In a routed connection the D500 routes IP packets between the D500 clientsubinterface and the trunk subinterface according to the IP routing table. The CPEmust use routed encapsulation. Both client and trunk subinterfaces must berouted. Different routed trunk subinterfaces must use unique 802.1q VLAN tags.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

115 (252)

Packet-based provisioning

Page 116: Dn03492199 4 en Global PDF Paper a4

To have full IP connectivity the network behind the CPE must be defined in theD500 IP routing table. Client-to-client connectivity can be configured eitherthrough the D500 IP routing table or the IP routing table of the broadband remoteaccess server (BRAS).

Packet forwarding between different routed client and trunk subinterfaces isperformed according to the D500 IP routing table. The routing table containsstatically configured host and network routes and dynamic, DHCP-learned hostroutes.

In case client-to-client connectivity is not desired through the D500 IP routingtable, one-to-one routed connection must be used. In this configuration, the clientsubinterface is bound to the trunk subinterface, and packets are passed betweenthe interfaces without the routing table.

The one-to-one routed connection is the recommended scenario for the customerswith fixed IP address needs and advanced IP traffic generation, in other words,business customers that need private network managing behind the CPE and/orprioritisation of upstream traffic flows with differentiated services code point(DSCP).

4.1.1.1 Parameters of a routed interface

The following information must be defined in a routed connection:

1. Subinterface name

2. IP address netmask

3. Diffserv enable/disable (optional)

4. VPI/VCI for the ATM interface

5. VLAN for the Ethernet interface

6. Ping enable/disable (optional)

7. PTD (optional).

The following is an example of a normal routed connection:

configure subinterface trunk new 11/1 routed1

routed

vlan 20

ip 10.30.18.1 255.255.255.0

116 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 117: Dn03492199 4 en Global PDF Paper a4

done

end

configure subinterface client new 1/1 client1

routed

ip 10.30.20.254 255.255.255.252

pvc 0 100 llc

ping

done

end

configure subinterface client new 1/2 client2

routed

ip 10.30.30.254 255.255.255.252

pvc 0 100 llc

ping

done

end

conf ip route new 0.0.0.0 0.0.0.0 11/1 routed1 10.30.18.254

conf ip route new 10.30.21.0 255.255.255.0 1/1 client110.30.20.253

conf ip route new 10.30.31.0 255.255.255.0 1/2 client210.30.30.253

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

117 (252)

Packet-based provisioning

Page 118: Dn03492199 4 en Global PDF Paper a4

Figure 19. Normal routed connection

4.1.1.2 One-to-one routed connection (PVC-VLAN)

A one-to-one routed connection is the recommended scenario if client-to-clientconnectivity is not desired through the D500 IP routing table but through theBRAS IP routing table. The trunk and client subinterface are bound together andthe D500 IP routing table is bypassed, leaving the routing task to the next hoprouter.

There can be only one client subinterface bound to each trunk subinterface.

The client subinterface must be created first. It specifies the next hop IP and anoptional MAC addresses for all IP traffic upstream. The IP subnet does not needto be unique; the IP subnet of two or more clients can overlap or can be the same.

The trunk subinterface configuration defines the client subinterface to which it isbound for the downstream IP traffic.

The following is an example of a one-to-one connection:

configure subinterface client new 1/1 client1

routed

ADSLrouters

10.30.30.253/30

0/100Routing

10.30.20.254/30VLAN 2010.30.18.254/24

NORMAL ROUTED

10.30.20.253/30

10.30.30.254/30

10.30.18.1/24

0/100

11/1

D500

10.30.31.0/24

10.30.21.0/24

routed1

client1

1/1

1/2

client2

Router

118 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 119: Dn03492199 4 en Global PDF Paper a4

ip 10.0.2.254 255.255.255.252

gateway_mac 00:20:30:00:00:10

gateway_ip 10.0.3.254

pvc 0 100 llc

ping

done

end

conf subinterface trunk new 11/1 routed100

routed

vlan 100

ip 10.0.3.253 255.255.255.252

clientsubif 1/1 client1

done

end

configure subinterface client new 1/2 client2

routed

ip 10.0.5.254 255.255.255.252

gateway_mac 00:20:30:00:00:10

gateway_ip 10.0.6.254

pvc 0 100 llc

ping

done

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

119 (252)

Packet-based provisioning

Page 120: Dn03492199 4 en Global PDF Paper a4

end

conf subinterface trunk new 11/1 routed101

routed

vlan 101

ip 10.0.6.253 255.255.255.252

clientsubif 1/2 client2

done

end

Figure 20. One-to-one routed connection

4.1.1.3 Routed subinterface isolation

The operator can isolate each IP routed client subinterface by defining asubinteface IP gateway. If the IP gateway MAC address is defined D500 clientside subnetworks can overlap. Otherwise the corresponding IP circuit is createdinto the D500 (this operation is part of the one-to-one routed connection).

Example:

1-to-1 forwarding

10.0.5.254/30 10.0.6.253/30

10.0.1.0/24

10.0.4.0/24

10.0.2.253/30

10.0.5.253/30

0/100

0/100

routed100

11/1

routed101

1-to-1 forwarding

D500

10.0.2.254/30 Router

1-to-1 ROUTEDADSLrouters

10.0.3.253/30

client1

1/1

1/2

client2

10.0.3.254/30

VLAN 100

VLAN 101

10.0.6.254/30

120 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 121: Dn03492199 4 en Global PDF Paper a4

conf sub client new 2/1 c1 routed pvc 0 38 llc gateway_ip10.12.2.2 gateway_mac 00:01:02:03:04:05

4.1.1.4 Routing table

A routing table is a mapping that maps <IP subnet address, IP subnet mask> pairsto <subinterface, gateway> pairs. A packet with a destination address thatmatches the <IP subnet address, IP subnet mask> table entry should be forwardedto the corresponding gateway on the subinterface given in the table entry. Ifmultiple table entries match the destination address, the most specific match wins.This is called the longest prefix match algorithm. The routing table alwayscontains a static entry, which maps the least specific route, <0.0.0.0, 0.0.0.0>, tothe default route.

For an example of a routing table configuration see the example of a normalrouted connection above.

4.1.2 Routed bridge subinterface (RBE)

The routed bridge encapsulation (RBE) subinterface was designed to overcomesome of the less favourable features of both bridged virtual interfaces (BVI) andintegrated routed and bridged (IRB) interfaces. RBE interfaces emulate routedinterfaces by only forwarding frames based on their encapsulated layer 3information. The D500 interfaces support DHCP and PPPoE through selectableconnection options. RBE is a described as having the functionality of a routedinterface and a half-bridge. RBE interfaces receive RFC 2684 bridged Ethernetframes, but only examine the IP portion of the PDU. If the PDU does not containany layer 3 information it is discarded. There are three exceptions with regard tothe implementation of RBE interfaces in the D500:

. ARP

During the initial stages of connection establishment the D500 supplies itsMAC address (proxy ARP) for all non-local ARP broadcasts. This proxyARP supplies CPE side devices with a local destination MAC address.

. DHCP

DHCP broadcast are relayed to a preconfigured DHCP server, through theuse of a helper-address. If configured, the D500 can snoop both the DHCPrequest and reply. This information is then used to create a static host routefor a specific subscriber.

. PPPoE

PPPoE is not natively supported on RBE connections. If PPPoE servicesare required, the PPPoE option and destination parameter are specified inthe initial connection configuration.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

121 (252)

Packet-based provisioning

Page 122: Dn03492199 4 en Global PDF Paper a4

4.1.2.1 Parameters of a RBE interface

The following information must be defined in a RBE connection:

1. Subinterface name

2. IP address netmask

3. VPI/VCI for an ATM interface

4. VLAN for an Ethernet interface

5. Diffserv enable/disable (optional)

6. PPPoE enable/disable (optional)

. PPPoE destination port ID and name

7. PPP enable/disable (optional)

. PPP MAX sessions

. PPP threshold sessions

8. Multicast PTD (optional)

9. DHCP helper address (optional)

. Option 82 support (Cisco or Redback)

10. Max multicast channel (optional).

The following is an example of a RBE multicasting subinterface:

conf sub client new 4/1 "myRBEClient" rbe

pvc 0 100 llc

ip 151.1.1.1 255.255.255.0

multicast DEFVAL_PTD_DF 3

ptdid DEFVAL_PTD_DF

done

122 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 123: Dn03492199 4 en Global PDF Paper a4

4.1.2.2 RBE interface operation

RBE interfaces operate either in a numbered or unnumbered mode. Numberedinterfaces require a one-to-one mapping between an interface and IP address.Unnumbered interfaces use or borrow an IP address from another interface. Bothconfigurations are extremely similar in operation. In the D500, the RBE interfacesupports client-to-client communication. This kind of connectivity is achievedinternally through the D500 IP routing table. Operational examples are providedbelow.

Numbered interface operation

In the numbered interface operation there is one fixed IP address in the clientsubinterface and another fixed IP in the trunk subinterface.

One IP network has to be assigned to every client subinterface potentially wastingIP addresses.

The following is an example of a numbered connection:

conf subinterface trunk new 11/1 routed1

routed

vlan 100

ip 10.0.2.1 255.255.255.252

done

end

configure subinterface client new 1/1 client1

rbe

ip 10.0.1.254 255.255.255.0

pvc 0 100 llc

ping

done

end

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

123 (252)

Packet-based provisioning

Page 124: Dn03492199 4 en Global PDF Paper a4

configure subinterface client new 1/2 client2

rbe

ip 10.0.1.1 255.255.255.0

pvc 0 100 llc

ping

done

end

conf ip route new 0.0.0.0 0.0.0.0 11/1 routed1 10.0.2.2

Figure 21. RBE connection

Unnumbered interface operation

In the unnumbered interface operation there is one fixed IP address in one clientsubinterface while others borrow that IP. This scenario allows several clientsubinterfaces to be in the same IP subnet, maximising the use of available IPaddresses.

10.0.2.254/24

10.0.3.1/30

10.0.1.1/24

10.0.2.1/24

0/100

0/100

D500

10.0.1.254/24

ADSLbridges

client11/1

1/2

client2

VLAN 10010.0.3.2/30

PCs

11/1

routed1

Router

RBERouting

124 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 125: Dn03492199 4 en Global PDF Paper a4

The following is an example of an unnumbered connection:

conf subinterface trunk new 11/1 routed1

routed

vlan 100

ip 10.0.2.1 255.255.255.252

done

end

configure subinterface client new 1/1 client1

rbe

ip 10.0.1.254 255.255.255.0

pvc 0 100 llc

ping

done

end

configure subinterface client new 1/2 client2

rbe

unnumbered 1/1 client1

pvc 0 100 llc

ping

done

end

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

125 (252)

Packet-based provisioning

Page 126: Dn03492199 4 en Global PDF Paper a4

conf ip route new 0.0.0.0 0.0.0.0 11/1 routed1 10.0.2.2

Figure 22. Unnumbered RBE connection

4.1.2.3 RBE with loopback IP addressing

This scenario has one fixed IP address in a loopback interface. When clientsubinterfaces borrow that IP, they can in the same IP subnet, maximising the useof available IP addresses.

The advantage compared to RBE with unnumbered IP addressing is that no clientsubinterface needs to be dedicated to define the IP subnet to use. The logicalloopback interface is used instead.

If unnumbered interfaces are used when there are two subscribers in the samesubnet, RBE uses proxy ARP.

Example:

conf subinterface trunk new 11/1 routed1

routed

vlan 100

ip 10.0.2.1 255.255.255.252

done

Unnumbered10.0.2.1/30

10.0.1.1/24

10.0.1.2/24

0/100

0/100

D500

10.0.1.254/24

ADSLbridges

client1

1/1

1/2

client2

VLAN 10010.0.2.2/30

PCs

11/1routed1

Router

UNNUMBERED RBERouting

126 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 127: Dn03492199 4 en Global PDF Paper a4

end

conf ip loopback new lb1 10.0.1.254 255.255.255.0

configure subinterface client new 1/1 client1

rbe

loopback lb1

pvc 0 100 llc

ping

done

end

configure subinterface client new 1/2 client2

rbe

loopback lb1

pvc 0 100 llc

ping

done

end

conf ip route new 0.0.0.0 0.0.0.0 11/1 routed1 10.0.2.2

The figure below provides an example of an unnumbered interface: 10.0.1.2(Host A) wants to communicate with 10.0.1.1 (Host B). However, in this case ofunnumbered interfaces, Host A is in the same subnet as Host B.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

127 (252)

Packet-based provisioning

Page 128: Dn03492199 4 en Global PDF Paper a4

Figure 23. IP unnumbered operation

Host A learns the MAC address of Host B by sending out an ARP broadcast toHost B via the D500. When the RBE interface at the D500 receives this broadcastmessage, it sends out a proxy ARP response with the MAC address 10.0.1.254 toHost A. Host A takes that MAC address, place it in its Ethernet header, and sendsthe packet back. When the D500 receives the packet, it skips the Ethernet header,looks at the IP destination header, and then routes it to the correct interface.

4.1.2.4 PPPoE grooming with the RBE client subinterface

This scenario is suitable for customers who want to separate the PPPoE trafficfrom the rest of traffic, in other words, PPPoE remote office VPN. The PPPoEsession uses a different trunk subinterface (in other words, a different VLAN)than the rest of the user traffic.

The client subinterface is RBE, the trunk subinterface that forwards PPPoE trafficis bridged and the trunk subinterface for the rest of user traffic is routed.

10.0.2.1/30

IP=10.0.1.1/24GW=10.0.1.254/24

0/100

0/100

D500

Loopback10.0.1.254/24

ADSLbridges

client1

1/1

1/2

client2

VLAN 10010.0.2.2/30

Host B

11/1

routed1

Router

RBE/LOOPBACK

Routing

Host A

IP=10.0.1.2/24GW=10.0.1.254/24

128 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 129: Dn03492199 4 en Global PDF Paper a4

Figure 24. PPPoE grooming with RBE as a client subinterface

4.1.2.5 Multicast (IGMP proxy) functionality with RBE as a client subinterface

IGMP-capable clients interact with the D500 through the exchange of IGMPmessages. When the IGMP proxy has been configured, the D500 interacts withthe next hop multicast router on its Gigabit Ethernet upstream interface throughthe exchange of IGMP messages as follows:

When queried, the D500 sends upstream group membership reports to the group.

When one of the client subinterfaces of the D500 joins a multicast address groupto which none of its other client subinterfaces belong, the D500 sends anupstream unsolicited group membership reports to that group. Any subsequentclient subinterfaces joining the same group receives the multicast stream with nomore upstream membership reports being generated.

When the last of the client subinterfaces of the D500 in a particular multicastgroup leaves the group, the D500 sends an upstream unsolicited leave groupmembership report to the all-routers group (244.0.0.2).

It is possible to use multicast authentication in the D500. In that case somechannel packages must be created first. A channel package includes a list ofmulticast IP addresses. After channel packages are created, authentication isenabled by configuring client authentication entries (<client MAC-channel

10.0.1.1/24

0/100

D500ADSLbridges

VLAN 100

POs PPPoEGrooming

Bridging

Client1_RBE1/1

Pppoe_trunk

Bridge_trunk11/1

Router

10.0.1.254/24VLAN 200

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

129 (252)

Packet-based provisioning

Page 130: Dn03492199 4 en Global PDF Paper a4

package ID> pairs). By default there is no authentication in the D500. Once thefirst client authentication entry is created, authentication is enabled for the wholeD500. Authentication is disabled again by deleting all client authenticationentries.

The following is an application example:

conf subinterface trunk new 11/1 routed1

routed

vlan 20

ip 10.30.18.1 255.255.255.0

done

end

conf ptd new video af4 3500 15000 3000 15000

conf ip multicast igmp enable 11/1 routed1

configure subinterface client new 1/1 client1

rbe

ip 10.30.20.254 255.255.255.0

pvc 0 100 llc

multicast video 3

ping

done

end

configure subinterface client new 1/2 client2

rbe

130 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 131: Dn03492199 4 en Global PDF Paper a4

ip 10.30.30.254 255.255.255.0

pvc 0 100 llc

multicast video 3

ping

done

end

conf ip route new 0.0.0.0 0.0.0.0 11/1 routed1 10.30.18.254

Figure 25. Multicast

4.1.2.6 RBE subinterface isolation

The D500 RBE client subinterface request a specific gateway IP configuration. Ifthe gateway is specified, all the traffic from the given subinterface is sent to thegateway (default: no gateway).

Example:

iTVManager

BroadcastServer

Encoders &Transcoders

MOSPF, PIM,DVMRP

IGMPv2IGMPv2

D500CPE

STB

InternetVideo serviceauthentication data

IP Address ofmulticast router

Snoop requestStop video

IGMP leave

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

131 (252)

Packet-based provisioning

Page 132: Dn03492199 4 en Global PDF Paper a4

conf sub client new 2/1 client1 rbe pvc 0 38 llc gateway_ip10.12.2.2

The RBE user isolation prevents the users in the same subinterface from seeingeach other (private ports). In the RBE subinterface the ports can be configured asprivate or community ports. The RBE user isolation is achieved by configuringthe default gateway per client subinterface. A DHCP-enabled RBE clientsubinterface accepts traffic only from clients receiving their addresses with theDHCP.

4.1.2.7 RBE with DHCP relay (Option 82)

The D500 RBE client subinterface relays the DHCP request from the clientendpoint to a predefined DHCP server. It can be configured to append the Option82 tag to the DHCP request.

The Option 82 tag contains traceabilty information, for example the DSL slot andport.

The format of the option 82 tag is shown below:

Figure 26. Format of the Option 82 tag

The DHCP relay is enabled by specifying the DHCP server IP address in theclient subinterface.

The following figure is an application example:

Option82

Lengthxx

Suboption1

Lengthxx

Information Suboption2

Length19

Information

Subinterface name stringMax. 32 bytes

Port type0x01(RBE)

Ver.1 byte

Forfuture2 bytes

Port IP Address(loop-back address)

4 bytes

DSLAM MACAddress6bytes

Slot1 bytes

Port1 bytes

VPI1 bytes

VCI1 bytes

132 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 133: Dn03492199 4 en Global PDF Paper a4

Figure 27. Application of the DHCP relay

The DHCP relay feature can be enabled in a RBE subinterface that refers to therelay pool, see the example below and refer to DHCP relay pools in the D500.

conf sub client new <unit/port> <name> rbe

pvc <vpi> <vci> <encaps>

ptdid DEFVAL_PTD_DF

loopback lb 1

dhcp r 1

done

D500

DHCP relayagent

D500 SMS

IPEthernet / IPE

ADSLmodem

Ethernetswitch

ADSLmodem

The SMS cannot identify customers beforethey have got IP address from the DHCP server.

The D500 acts as a DHCP relay agent andadds and strips relay Option 82 from DHCPmessages.

The D500 is the only network element that hasreliable knowledge about each customer(customer = slot, port, VPI, VCI). In the D500network side, there are only IP flows.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

133 (252)

Packet-based provisioning

Page 134: Dn03492199 4 en Global PDF Paper a4

4.1.3 Bridged subinterface

Bridged interfaces were designed to support both connectionless and connectionoriented protocols. The D500 implements a specialised bridging model based onstandard RFC 2684 and centred around bridged Ethernet scenarios. The D500also supports a variety of bridged encapsulation types and tunneling technologies.

Bridging is based on a MAC address table. This table maps MAC addresses toconnections. A table entry is created whenever a MAC address shows up in thesource address field of the MAC header of an upstream (ingress) packet. Theentries are used to map the destination address of unicast downstream (egress)packets to client connections. If no traffic is detected from the node for a certaininterval, a table ageing process deletes the MAC entry. The ageing time-outperiod is a configurable parameter. Each bridged connection endpoint on theclient side belongs to a single bridge group (5�400 bridge groups). A bridgegroup consists of a minimum of one client interface and only one trunk sideinterface (VCC or VLAN, in case of the Gigabit Ethernet trunk). If the number ofmembers in the bridge group is one, up to 4094 bridge groups are supported(direct mapping between customer PVCs and VLANs in the trunk interface).

By default downstream broadcasts, in other words arp requests, are flooded to allmembers of the bridge group. If this is not wanted, it is possible to configureBroadcast Off in the bridged trunk subinterface. The Broadcast Off configurationblocks downstream broadcast (including ARP requests) and multicast traffic inthat bridge-group.

A directed DHCP response is supported even though DHCP proxy is disabled inthe bridged subinterface. The D500 forwards the broadcasted DHCP responseonly to the subinterface where the DHCP request came from.

Upstream broadcasts are only sent to the trunk subinterface.

Client-to-client connectivity inside the bridge group in the D500 is not possible.

It is possible to define a DHCP relay pool in a bridged client subinterface. In thatcase the D500 acts as a relay adding the DHCP Option 82 tag. DHCP messageshas to use a routed trunk subinterface.

It is possible to enable IGMP snooping for one bridge group in the D500.

In a bridged client subinterface it is possible to use VLAN ID. It is possible to useIEEE 802.1Q VLAN tags in RFC2684-encapsulated Ethernet PDUs going tosubscribers via bridged line cards.

4.1.3.1 Parameters of a bridged interface

The following information must be defined in a bridged connection:

134 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 135: Dn03492199 4 en Global PDF Paper a4

1. Subinterface name

2. Priority (optional)

3. VPI/VCI for an ATM interface

4. VLAN for an Ethernet interface

5. PPPoE enable/disable (optional)

6. Filter (optional).

Example:

conf sub trunk new 11/1 t1 bridged

vlan 10

ptdid DEFVAL_PTD_DF

done

4.1.3.2 Bridged one-to-one connection (PVC-VLAN)

This scenario is the minimum configuration for a bridge group, consisting of oneclient subinterface and a trunk subinterface. All upstream Ethernet frames areforwarded to the trunk subinterface with a 802.1q VLAN tag. All downstreamEthernet frames belonging to the trunk subintreface VLAN are stripped of the802.1q tag and forwarded untagged to the client subinterface.

The following is an example of a bridged one-to-one connection:

conf subinterface trunk new 11/1 bridge100

bridged

vlan 100

done

end

conf subinterface client new 1/1 client1

bridged

pvc 0 100 llc

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

135 (252)

Packet-based provisioning

Page 136: Dn03492199 4 en Global PDF Paper a4

bridged_subif 11/1 bridge100

done

end

Figure 28. Bridged one-to-one connection

4.1.3.3 Bridge groups (PVCs-VLAN)

The maximum number of bridge groups in the system is configured at a systemlevel. It is possible to configure 5�400 bridge groups (default 20). If there arefive groups, the number of clients per group is 1600 (5 x 1600 = 8000). If thereare 400 groups, the number of clients per group is 20 (400 x 20 = 8000). Anexception to this system level setting is that the number of bridge groups can beup to 4000 if each bridge group has only one bridge client side member. The newconfiguration comes into effect after rebooting the node.

This configuration consists of several client subinterfaces bound to a trunksubinterface. All upstream Ethernet frames are forwarded to the trunksubinterface with a 802.1q VLAN tag. All downstream Ethernet framesbelonging to the trunk subintreface VLAN are stripped of the 802.1q tag andforwarded untagged to the right client subinterface based on the self learningbridging table.

The D500 supports new node level configuration that defines how the 8000multicast resources shall be devided into bridge groups. This configurationrequires that the user reboots the D500.

conf sys bridge_groups 40 [| 1-4000]

10.0.1.1/24

0/100

D500ADSLbridges

VLAN 100

PCs BRIDGE GROUPS

Bridging

client11/1

bridge100

Router

10.0.1.254/24

11/1

136 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 137: Dn03492199 4 en Global PDF Paper a4

The following is an example of a bridge group configuration:

conf subinterface trunk new 11/1 bridge100

bridged

vlan 100

done

end

conf subinterface client new 1/1 client1

bridged

pvc 0 100 llc

bridged_subif 11/1 bridge100

done

end

conf subinterface client new 1/2 client2

bridged

pvc 0 100 llc

bridged_subif 11/1 bridge100

done

end

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

137 (252)

Packet-based provisioning

Page 138: Dn03492199 4 en Global PDF Paper a4

Figure 29. Configuration of bridged groups

4.1.3.4 PPPoE grooming with a bridged client subinterface

The following is an example of PPPoE grooming with a bridged clientsubinterface:

conf subinterface trunk new 11/1 bridge_trunk

bridged

vlan 100

done

end

conf subinterface trunk new 11/1 pppoe_trunk

bridged

vlan 200

done

end

10.0.1.1/24

0/100

D500ADSLbridges

VLAN 100

PCs BRIDGE GROUPS

Bridging

client11/1

10.0.1.2/24

1/2 client2

bridge10011/1

Router

10.0.1.254/24

0/100

138 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 139: Dn03492199 4 en Global PDF Paper a4

conf subinterface client new 1/1 client1

bridged

pvc 0 100 llc

bridged_subif 11/1 bridge_trunk

pppoe 11/1 pppoe_trunk

done

end

Figure 30. PPPoE grooming with a bridged client subinterface

4.1.3.5 Protocol filter

Protocol filters apply only to bridged subinterfaces. The protocol filter is appliedto the PDUs received by the subinterface (upstream direction). Any combinationof the following can be enabled to pass the filter:

1. ALL

2. PPPoE

3. IP_NO_NETBEUI

4. IP_WITH_NETBEUI.

10.0.1.1/24

0/100

D500ADSLbridges

VLAN 100

PCs PPPoEGrooming

Bridging

client11/1

Pppoe_trunk

Bridge_trunk11/1

Router

10.0.1.254/24VLAN 200

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

139 (252)

Packet-based provisioning

Page 140: Dn03492199 4 en Global PDF Paper a4

4.1.3.6 Bridged subinterface priority

The D500 supports priority bit settings to bridged subinterfaces. Three priorityclasses for the VLAN priority field are supported: high, medium, and low. VLANpriority bits can be used to prioritise high/medium/low traffic or disable it. VLANpriority field mapping to priority classes is configrable. VLAN priority fieldmapping to priority classes defines which priority field value belong to whichclass. The default priority mapping configuration is as follows:

. high�4, 5, 6, 7

. medium�2, 3

. low�0, 1

There can be only one priority mapping configuration per node. The settingsbecome effective only after the node has been rebooted.

In the priority mapping mode, the incoming subinterface's priority mappingconfiguration defines the PDU's outgoing queue and the VLAN priority fieldvalue (= the priority field is set to a new value).

In the priority pass mode, the incoming PDU's VLAN priority value defines thePDU's outgoing queue. The VLAN priority value is preserved.

Both modes are supported in the upstream direction. In the downstream directiononly the pass mode is supported.

Examples:

conf sub client new 2/1 c1 bridged pvc 0 38 llc [priority<high | medium | low>]

conf sub trunk new 11/1 t1 bridged vlan 10 [priority <on |off>]

configure system vlan_priority_map inlow <> inmed <>inhigh <> outlow <> outmed <> outhigh <>

show system vlan_priority_map

The following is a summary of possible configurations on the client and trunkside:

140 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 141: Dn03492199 4 en Global PDF Paper a4

. Trunk

- Downstream priority handling VLAN/off (default: off)

VLAN�VLAN priority bits select the priority.

Off�There is no priority bit handling.

- PTDs for each CoS level (high, medium, low) via profiles

- Mapping of priority levels (pass mode, map mode) via PTD policies

. Client

- PVC priority; high/medium/low VLAN (default: low = no handling)

High�Traffic is mapped to the trunk's high priority queue.

Medium�Traffic is mapped to the trunk's medium priority queue.

Low�Traffic is mapped to the trunk's low priority queue.

VLAN�VLAN priority bits select the priority.

If VLAN is selected, PTDs are needed for each CoS:

- PTDs for each CoS level (high, medium, low) via profiles

- Mapping of priority levels (pass mode, map mode) via PTD policies

4.1.3.7 MAC address table

The MAC address table associates the subinterface MAC address or MACaddress/VLAN ID pairs with the ATM VC used to connect the client to the linecard. Source MAC addresses are being learned in the upstream direction and adatabase containing these learned entries are then used in the downstreamdirection to forward the Ethernet frame to its proper recipient.

The Gibabit Ethernet trunk uses these MAC addresses or MAC address/VLANID pairs to direct Ethernet data to the appropriate client.

If the MAC address of the recipient in the frame coming from the Ethernet trunkis not found from the MAC forwarding table, the frame is broadcasted to allmembers in the same bridge group.

The table is automatically maintained by ageing out MAC addresses that have notbeen in use for a specified period of time or when MAC addresses exceed thetable critical capacity. The table can maintain a maximum of 8000 MACaddresses. The age of MAC addresses can be controlled with the MACMaximumAgeing Time parameter if the table volume is less than critical capacity. Fordetails see Managing the MAC address table.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

141 (252)

Packet-based provisioning

Page 142: Dn03492199 4 en Global PDF Paper a4

A subinterface has a user defined limit on the number of MAC addresses that canbe learned (default = 10, and max is 1000).

Figure 31. Ethernet to ATM address forwarding

4.1.3.8 Managing the MAC address table

The ageing time that MAC addresses remain in the MAC address table iscontrolled by a provisionable MAC Maximum Ageing Time or automatically byan accelerated MAC ageing algorithm. If MAC addresses exceed an internally setcritical capacity, an accelerated ageing algorithm ages out inactive MACaddresses on a first-in-first-out basis, freeing up table space for new MACaddresses. The following figure illustrates MAC ageing within the MAC addresstable.

Customer PCMAC=00A0C9662B51

Customer PCMAC=00904500000D

LAN

Link A0/25

Eth

Trunk

MAC Address Table

VPI/VCI MAC Address

Link A 0/25Link A 0/25

00A0C9662B5100904500000D

EthernetSwitch

CPE

Line

Card

D500

AAL5 SAR

ATM PDU

142 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 143: Dn03492199 4 en Global PDF Paper a4

Figure 32. MAC ageing over time

The following parameters are used to manage the MAC address table:

. MAC Maximum Ageing Time (secs x 10)

Sets the time in tens of seconds. A MAC address remains in the MACaddress table if it is not in use. This ageing time is applied only to MACaddresses when table fill does not exceed the internally-set critical capacity.When this capacity is exceeded, an accelerated ageing algorithm calculatesan accelerated ageing of MAC addresses in place of the of the MACMaximum Ageing Time. The provisioned value range for MAC Time isfrom 10 to 655,350 seconds. The default value is 30 (300 seconds).

. Alarm Ageing Threshold (secs x 10)

Sets the alarm threshold for accelerated ageing of MAC addresses in 10second intervals. As more MAC addresses enter the database while atcritical capacity, the accelerated aging algorithm ages out MAC addressesat shorter intervals in order to keep the table from overflowing. An alarm isgenerated if the ageing time for MAC addresses drops below the ageingthreshold for this parameter. This value should be less than the MACMaximum Ageing Time. The value range is 0 to 655,350 seconds (MACMaximum Time�10 seconds). The default value is 10 (100 seconds).

MAC Table Capacity

CriticalCapacity

Historical Time Interval

0 %

100 %

Accelerated Aging

Legend: Current MAC Capacity

MAC Aging Time

MACMaximumTime

Historical Time Interval

0 Sec.

AlarmTreshold Resource

Overflow

Legend: Current MAC Aging

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

143 (252)

Packet-based provisioning

Page 144: Dn03492199 4 en Global PDF Paper a4

4.1.3.9 Bridged subinterface with the DHCP relay (Option 82)

The D500 bridged client subinterface relays the DHCP request from the clientendpoint to a predefined DHCP server. It can be configured to append the Option82 tag to the DHCP request.

A routed trunk subinterface with a route to the DHCP server has to be created forcarrying DHCP messages. Also a loopback interface has to be created. DHCPmessages from the D500 to the DHCP server are unicast packets having aloopback address as the source IP address.

The DHCP relay is enabled by specifying the name of the loopback and the nameof DHCP relay pool interface in the client subinterface. DHCP relay poolspecifies 1�2 DHCP server IP addresses and Option 82 and mobility parameters.

The Option 82 tag contains traceability information such as the DSL slot andport.

The Nokia Option 82 tag has two sub options. The first one is Agent Circuit Idand the second one is Agent Remote Id.

The DHCP server should reside behind a routed trunk subinterface. The D500forwards downstream DHCP broadcast response messages from the DHCP serverto the original requester only. Refer to DHCP relay pools in the D500.

Example:

conf sub client new <unit/port> <name> bridged pvc <vpi><vci> <encaps>

bridged_subif <unit/port> <name>

ptdid DEFVAL_PTD_DF

loopback lb 1

dhcp r 1

done

4.1.3.10 Bridged connection with IGMP snooping

The D500 replicates multicast streams to all those bridged client subinterfacesthat have joined that multicast group.

IGMP snooping is enabled as follows:

144 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 145: Dn03492199 4 en Global PDF Paper a4

1. The global configuration defines the trunk subinterface that forwards theIGMP messages to the next hop multicast router.

2. The global configuration defines a loopback interface that belongs to thesame subnet as the bridge clients.

3. The client subinterface defines the name of the loopback interface,multicast packet traffic descriptor (PTD), and the maximum number ofallowed channels.

4.1.3.11 Bridged connections with client side VLANs

The Ethernet switch behind the CPE modem or the CPE modem can tag Ethernetpackets with the VLAN ID. That is why it is possible to have end-to-end CoS forbridged connections using 802.1p VLAN priorities starting from the clientdevice.

The configuration consists of bridged client subinterface(s) with a VLAN IDbound to a certain bridged trunk subinterface. Multiple VLANs (max 10) can betransferred inside one client side PVC.

All upstream Ethernet frames are forwarded to the trunk subinterface byswitching the client VLAN ID to the VLAN ID defined in the trunk subinterface.

All downstream Ethernet frames belonging to the trunk subinterface VLAN IDare forwarded with the client VLAN ID to the right client subinterface based onthe self-learning bridging table.

4.1.4 PPPoA subinterface

In the PPPoA subinterface connection the D500 terminates the ATM connectionand forwards the PPP session via Ethernet towards the PPPoE server (= thebroadband remote access server, BRAS). In this scenario, the D500 emulates aPPPoE client (RFC 2516). The CPE must use PPPoA encapsulation (RFC 1483and 2364), acting as a router. Trunk subinterfaces must be bridged and clientsubinterface PPPoA. The client subinterface is bound to the bridged trunksubinterface that forwards the PPP session as PPPoE to be terminated in theBRAS. Different bridged trunk subinterfaces must use unique 802.1q VLANtags. Client-to-client connectivity is achieved via the BRAS.

This subinterface is suitable for operators who want to support their existingPPPoA customer base with the IP based DSLAM trunk. There is no IPconfiguration in the client subinterface or trunk.

Parameters of a PPPoA interface

The following information must be defined for a PPPoA interface:

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

145 (252)

Packet-based provisioning

Page 146: Dn03492199 4 en Global PDF Paper a4

1. Subinterface name

2. PVC VCI/VPI VCMUX/LLC

3. PPPoE subinterface.

Example:

conf subinterface trunk new 11/1 pppoe_trunk

bridged

vlan 100

done

end

conf subinterface client new 1/1 client1

pppoa

pvc 0 100 vcmux

pppoe 11/1 pppoe_trunk

done

end

4.1.5 L2TP

The D500 supports a partial L2TP implementation: the D500 only supportsstatically configured tunnels and (PPP) aggregative services. Although the D500does not support tunnel switching for PPP sessions it does support partial linkcontrol protocol (LCP) forwarding for PPP over ATM (PPPoA) and PPP overEthernet (PPPoE) clients.

In the D500 L2TP tunnels are statically created entities between a link accesscontrol (LAC) and an L2TP network server (LNS). The LNS is typically anaccess router on the trunk side. The trunk unit implements the LAC functionalityallowing PPP sessions to be tunneled to a single endpoint. Each PPP protocolsession is terminated on the server end by the LNS, and on the client end by eithera CPE router or a host running PPPoE.

146 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 147: Dn03492199 4 en Global PDF Paper a4

L2TP tunnels may be created over both ATM connections and Gigabit EthernetVLANs. The LAC creates and manages L2TP tunnels. Once the tunnel is up anda tunnel ID is selected, a PPP session can be initiated.

IP packets containing L2TP control messages are processed locally and used tocrank state machines for configured L2TP tunnels. L2TP data is forwarded to theappropriate PPPoE or PPPoA endpoint, which is identified on the basis of thesession ID carried in the header.

Release 3 supports most L2TP link access control (LAC) functionality and usesthe well-known UDP port 1701. The entire L2TP packet is encapsulated in aUDP datagram. These packets are then forwarded via the appropriated tunnel ID.The tunnels are maintained and created over a reliable L2TP control channel,which transmits packets "in-band" over the same packet transport.

Tunnel creation is static and requires manual configuration. This process occursindependently of all other protocol negotiations and requires only that the LNS beconfigured and accepting L2TP calls. After tunnels are established, the D500LAC continually maintains the tunnels through the use of L2TP maintenance andcontrol messages.

The L2TP connection can be created only over the routed trunk interface. Thefollowing two cases show how to create a complex testing environment forPPPoE and PPPoA connections.

4.1.5.1 PPPoE

To have a PPPoE connection, execute the following CLI commands.

. Create a routed trunk subinterface:

conf sub trunk new 11/1 routed

ip 20.1.1.1 255.255.255.0

vlan 10

ptdid DEFVAL_PTD_DF

done

top

. Create a L2TP subinterface and wait until the tunnel is up:

conf l2tp new 2 <tunnel ident>

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

147 (252)

Packet-based provisioning

Page 148: Dn03492199 4 en Global PDF Paper a4

ns_ipaddress 20.1.1.2 <LNS(Cisco router) ip address>

remote_host R3 passwd <LNS host name and password>

done

top

. To have a client PPPoE onnection over L2TP, create a RBE/bridgedsubinterface and enable L2TP by giving the created L2TP tunnel ident.

conf sub client new 4/1 c1 rbe

pvc 0 38 llc

ptdid DEFVAL_PTD_DF

ip 10.1.1.1 255.255.255.0

l2tp 2

ping

done

top

4.1.5.2 PPPoA

To have a PPPoA connection, execute the following CLI commands.

. Create a routed trunk subinterface:

conf sub trunk new 11/1 routed

ip 20.1.1.1 255.255.255.0

vlan 10

ptdid DEFVAL_PTD_DF

done

top

. Create a L2TP subinterface and wait until the tunnel is up:

conf l2tp new 2 <tunnel ident>

ns_ipaddress 20.1.1.2 <LNS(Cisco router) ip address>

remote_host R3 passwd <LNS host name and password>

148 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 149: Dn03492199 4 en Global PDF Paper a4

done

top

. To have a client PPPoA onnection over L2TP, create a PPPoA clientsubinterface and enable L2TP by giving the created L2TP tunnel ident.

conf sub client new 16/2 c2 pppoa

pvc 0 42 vcmux

l2tp 2

done

top

4.1.5.3 Testing

If the tunnel is not up:

1. Verify that the LNS IP address and password are right

2. Try to ping the LNS from the D500 to verify that there is a routedconnection

3. Check the trunk statistic counters

4. Check the installation and set the LNS (Cisco router) to the L2TPdebugging mode to find out whether any L2TP messages are coming fromthe D500

5. Check the L2TP tunnel and PPP session state with the following CLIcommand:

show l2tp <tunnel_id> session

The following figures are test case examples:

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

149 (252)

Packet-based provisioning

Page 150: Dn03492199 4 en Global PDF Paper a4

Figure 33. PPPoE over L2TP

Figure 34. PPPoA over L2TP

4.1.6 Subinterface profile definition

The subinterface profile is a set of pre-defined configuration variables, which canbe applied to one subinterface or many subinterfaces (objects of the same type)during the provisioning process. The use of profiles decreases configuration timeand increases accuracy.

PPPoE_L2TP

D500

Routed 20.1.1.1

10.0.1.1

20.1.1.2

Router / L2TPserver

ADSLbridges

PCs

1/1 Client1_RBE

11/1

VLAN 10

PPPoE L2TP tunnel 2

Routed_trunk

10.0.1.2

PPP_L2TP

Routed_trunk

D500

Routed 20.1.1.1

10.0.1.1

20.1.1.2

Router / L2TPserver

ADSLbridges

PCs

1/1 Client1_PPPoA

11/1

VLAN 10

PPPoA

L2TP tunnel 2

150 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 151: Dn03492199 4 en Global PDF Paper a4

The following are the profile parameters:

1. Profile name

2. Profile subinterface type (routed/bridged/RBE/PPPoA)

3. subinterface connection parameters.

Example:

conf subinterface trunk new 11/1 routed1

routed

vlan 20

ip 10.30.18.1 255.255.255.0

done

end

conf ptd new video af4 3500 15000 3000 15000

conf ip multicast igmp enable 11/1 routed1

conf ip loopback new lb1 10.30.15.254 255.255.255.0

configure subinterface client profile new rbe1

rbe

loopback lb1

pvc 0 100 llc

multicast video 3

igmp client_last_member_query_interval 3

dhcp 10.30.50.24 nokia

ping

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

151 (252)

Packet-based provisioning

Page 152: Dn03492199 4 en Global PDF Paper a4

done

end

conf dsl profile line new dsl1 unit adsl48aft

conf dsl profile line dsl1

rate fast

noise 8 8

end

conf dsl 1/1:48 profile line dsl1

configure subinterface client new 1/1 client1

rbe

profile rbe1

done

end

configure subinterface client new 1/2 client2

rbe

profile rbe1

done

end

conf ip route new 0.0.0.0 0.0.0.0 11/1 routed1 10.30.18.254

152 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 153: Dn03492199 4 en Global PDF Paper a4

There are three different kinds of profiles, which makes provisioning easier:client subinterface profile, DSL line profile, and DSL alarm threshold profile. Allthose profile types are dynamic. It means that at the moment when some setting ina profile (which is in use) is modified, modification takes place in all DSL portsor client subinterfaces, which use that profile. This kind of dynamic profiles areextremely useful, if for example DSL line rates for certain service has to beincreased.

It is also possible to use a profile just as a way to copy certain parameters to aDSL port or client subinterface. For example when you create a clientsubinterface, you can select a suitable profile and after creating the subinterface,you can modify the subinterface so that you disable the profile (profile �None� inWeb-based Craft Terminal or NetAct). Thus, all the settings from the profile arecopied to that subinterface, but the subinterface does not have a reference to theprofile any more. Also if a profile in use is deleted, all the settings from theprofile are copied to the client subinterface/DSL port.

A client subinterface profile includes different parameters depending on the typeof the client subinterface: bridged, RBE, routed or PPPoA. The type is specifiedwhen a client subinterface profile is created. A DSL line profile includes ratesettings (fast/interleave, max/min rates, startup mode) and some DMT settingslike Noise Margin.

The DSL alarm threshold profile includes alarm thresholds for physical alarms ofa DSL port. If some threshold is exceeded, D500 sends a trap for that.

4.1.7 In-Band management connection

The In-Band management connection is used for remote management of theD500. In-Band management traffic is totally separated from data traffic. It uses itsown VLAN ID or ATM PVC. The physical trunk port in an In-Band managementconnection can be either the GE trunk port or STM-1 tributary port.

When In-Band management is created through a Gigabit Ethernet trunk, the In-Band subinterface has to be created with the IP address and VLAN ID defined (itis automatically a routed subinterface). In addition to the IP gatewayconfiguration, a static route to the management network has to be created. WhenIn-Band management is created through a tributary port, the In-Band subinterfacehas to be created with the IP address and VPI/VCI value (it is also a routedsubinterface with the RFC-2684 routed LLC encapsulation). In this case aseparate static route is not needed (an IP gateway configuration is enough).

The following is an example of an In-Band connection through a GE trunk:

conf sys inband address 10.10.10.1

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

153 (252)

Packet-based provisioning

Page 154: Dn03492199 4 en Global PDF Paper a4

conf sys inband netmask 255.255.255.0

conf sys ip gateway 10.10.10.254

conf sys inband subinterface new 11/1 mgmt

ip 10.10.10.1 255.255.255.0

vlan 10

done

end

conf ip route new 10.30.40.0 255.255.255.0 11/1 mgmt10.10.10.254

The following is an example of an In-Band connection through a tributary port:

conf sys inband address 10.10.10.1

conf sys inband netmask 255.255.255.0

conf sys ip gateway 10.10.10.254

conf sys inband subinterface new 6/1 mgmt

ip 10.10.10.1 255.255.255.0

pvc 0 900 llc

done

end

154 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 155: Dn03492199 4 en Global PDF Paper a4

4.1.8 DHCP relay pools in the D500

It is possible to create multiple relay pools, change their properties (for exampleenable/disable Option 82, and change the DHCP server address) and delete relaypools. Relay pools support the configuration of two DHCP servers (primary andsecondary) behind the routed trunk. The DHCP relay pool name is needed toenable the DHCP relay on a subinterface. The relay pool name is required also forcreating the subinterface profiles.

The MIB database can be converted from R3.1 to R3.2. The old DHCP relayconfiguration data in a subinterface and subinterface profile context is convertedto the DHCP relay pool configuration data while upgrading the node.

DHCP-enabled interfaces prevent clients from using static IP addresses. DHCPbroadcast response messages from the DHCP server are unicasted by the D500 tothe original requester.

To create a new DHCP relay poo,l use the following CLI command:

CONFIGURE IP DHCP NEW <poolname> <server_ip>[<server_ip2>] [OPTION82 <DISABLE|NOKIA>]

. <poolname> the DHCP relay pool name (string enclosed in double quotes)

. <server_ip> is the DHCP server IP address (mandatory)

. <server_ip2> is another DHCP server IP address (optional)

. OPTION82 <DISABLE|NOKIA> configures DHCP RA Option 82handling (optional, default DISABLE)

To change the properties of an existing relay pool, use the following command:

CONFIGURE IP DHCP <poolname>

To edit an existing DHCP relay pool, use the following commads:

. Add a new DHCP server IP address: SERVER ADD <server_ip>

. Delete a DHCP server IP address: SERVER DELETE <server_ip>

. Configure the DHCP RA option 82 handling: OPTION82 <DISABLE|NOKIA>

The pool can be deleted only if it is not used by some client subinterface orsubinterface profile. To delete an existing relay pool, use the following command:

CONFIGURE IP DHCP DELETE <poolname>

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

155 (252)

Packet-based provisioning

Page 156: Dn03492199 4 en Global PDF Paper a4

To display the properties of a relay pool, use the following command:

SHOW IP DHCP <poolname

To display all existing relay pools, use the following command:

SHOW IP DHCP ALL

To display the list of client subinterfaces and subinterface profiles using a givenDHCP relay pool, use the following command:

SHOW IP DHCP <poolname> USER

DHCP spoofing/ARP spoofing

When spoofing is enabled, clients can move across different DSL ports freely.DHCP spoofing can be enabled by selecting the Mobility check box in the NewDHCP Relay Pool dialogue box. The default setting for ARP spoofing isdisabled.

If ARP spoofing is enabled for the DHCP-enabled client subinterfaces in thesame subnet, ARP spoofing/IP spoofing is protected by the system.

The system checks the ARP source MAC and source IP pattern against theDHCP's lease database. This database contains MAC IP pairs for which theDHCP server has provided the IP address. If the pattern match fails then thepacket is dropped.

4.1.9 Connection type

4.1.9.1 VLAN/non-VLAN connection

With VLANs the Ethernet switch can be divided into several broadcast domains.The most common VLANs are port-based VLANs and IEEE802.1Q VLANs. Ina port-based VLAN switch a port accepts Ethernet frames without VLAN taggingand tags all incoming packets with a predifined port VLAN. The port has a list ofall VLAN IDs it accepts for outgoing packets. It strips VLAN tags before it sendspackets out. An IEEE802.1Q capable port supports IEEE 802.1Q VLAN tagging,which defines the VLAN membership by inserting a 12-bit VLAN ID into theEthernet frame. VLANs are like independent subports for this port. It is notpossible to switch packets between VLANs; routing is needed to pass trafficbetween VLANs.

156 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 157: Dn03492199 4 en Global PDF Paper a4

The D500 supports port-based VLANs in the subcriber subinterface andIEEE802.1Q tag -based VLANs in trunk ports. IEEE 802.1Q VLAN tags are notused in RFC2684-encapsulated Ethernet PDUs going to subscribers via linecards. Internally the subscriber subinterface has a port-based VLAN ID that isinserted into incoming packets. The same VLAN ID is used for acceptingoutgoing packets.

For VLAN bridged networks, only the VLAN ID is required to establish VLANmembership. The VLAN ID identifies the subinterface (ATM PVC) as a memberof a particular VLAN. The VLAN ID is inserted into the trunk interface Ethernetframe to uniquely identify the VLAN membership of the frame. The VLAN IDfield can accept up to 4094 different VLAN IDs. Value 0 is used to disable aVLAN.

The figure below shows protocol stacks used by VLAN bridged connections. Themain difference between the VLAN and non-VLAN cases is that VLAN VCs aremapped not only to MAC addresses, but to MAC address and VLAN ID pairs.Although VLANs are used to create the logical channel in the D500 Ethernetinterface, clients do not see VLAN IDs in their LANs. The client MAC address isused to forward data from the CPE to the client host. AVLAN tag is added to theEthernet frame in the upstream direction and stripped out in the downstreamdirection.

The GE trunk supports Ethernet frames of size from 64 to 1518 octets. If VLANtags are used, the maximum frame size increases to 1522 bytes.

Figure 35. Protocol stacks in the VLAN bridged network

The figure below shows an example of VLAN support in the D500:

Client PC CPE D500 SMS

RFC-2684Bridged

DSLEthernet PhysicalLayer 1000B-TX

AAL5ATM-PVC

AAL5ATM-PVC

RFC-2684Bridged

802.3 802.3

802.1Q802.1Q

Ethernet

802.3

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

157 (252)

Packet-based provisioning

Page 158: Dn03492199 4 en Global PDF Paper a4

Figure 36. VLAN support (IEEE 802.1Q)

The figure below shows an example of the protocol stacks used where a non-VLAN bridged connection is configured through the D500. The upper layerprotocol used is PPP, but in principle the D500 does not distinguish between theprotocol types carried over Ethernet. In the case of a non-VLAN bridgedconnection, the decision on which VCC to forward a downstream Ethernet frameis based entirely on the client MAC addresses.

DestinationMac

6 bytes

SourceMac

6 bytes

Length/Type2 bytes

Payload0 - n bytes

DestinationMac

6 bytes

SourceMac

6 bytes

Length/Type2 bytes

Payload0 - n bytes

VLANID Up to4 bytes

D500

CPE

BridgedEth/ATM/DSL

PPPoE

PPPoE

0/100

CPE

RBE0/100

CPE

Bridged0/100

DHCP

DHCP

DHCP

VLAN 3

VLAN 2

VLAN 1

Priority bits

EthernetNetwork

ATM ETH

ISP

iTVManager

BroadcastServer

Encoders &Transcoders

With the D500 R3.1 VLAN can be used

To separate individual DSL customersTo wholesale DSLTo isolate services, such as TV/VoDTo offer layer 2 connections for businesses

158 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 159: Dn03492199 4 en Global PDF Paper a4

When an Ethernet frame is sent in the upstream (ingress) direction to the OSIlayer 3 device (SMS), the MAC Address Table in the Ethernet trunk learns thesource MAC addresses. If the frame is valid and the format is correct, the frame�ssource MAC address and VC used are entered into the MAC Address Table. TheATM encapsulation is stripped off and the frame is sent to the Ethernet interface.In the downstream (egress) direction, the Ethernet trunk uses the MAC address tolocate the associated VC from the MAC Address Table to forward frames in theappropriate clients.

Figure 37. Protocol stacks in the Non-VLAN bridged network

4.1.9.2 ATM AAL5 encapsulation

The subscriber interface supports RFC-2648 Multiprotocol Encapsulation overAAL5 for encapsulating Ethernet or IP traffic over ATM. Using AAL5Segmentation and Reassembly (SAR), the subinterface converts data payloadsbetween Ethernet/IP PDUs and ATM Common Part Convergence Sublayer(CPCS) PDUs. Ethernet or IP PDUs are carried in the payload field of the ATMCPCS PDU over the D500 ATM connections. The D500 supports two methods ofAAL5 encapsulation:

. LLC encapsulation: This method allows multiplexing of multipleprotocols over a single ATM VC. The protocol is identified by prefixing anIEEE 802.2 Logical Link Header/Subnetwork Access Protocol (LLC/SNAP) field to the PDU per RFC-2648 specifications. The LLC/SNAPfield contains information to identify the PDU as a routed or bridged PDU.

. VC based multiplexing: This method performs a higher layermultiplexing implicitly by placing the Ethernet or IP PDUs directly into theAAL5 frame without any encapsulation. Each protocol must be carriedover a separate VC.

Client PC CPE D500 SMS

PPP

RFC-2684Bridged

DSLEthernet PhysicalLayer 1000B-TX

AAL5ATM-PVC

AAL5ATM-PVC

RFC-2684Bridged

PPP

802.3

802.3

Ethernet802.3

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

159 (252)

Packet-based provisioning

Page 160: Dn03492199 4 en Global PDF Paper a4

The D500 supports PPP over ATM in the VC muxed and LLC encapsulationformat (as per RFC2364).

As shown in the following figure, the subscriber subinterface supports fourprovisionable ATM interworking descriptors (based on the above two methods)for encapsulating Ethernet traffic and VLAN tagging.

Figure 38. AAL5 encapsulation for Ethernet

AAL5 encapsulation type

This parameter provides four user-selectable interworking descriptors for theencapsulation of Ethernet PDUs into the payloads of AAL5 PDUs. AAL5encapsulation is provisioned separately for each individual subscriber (VCconnection). The encapsulation type provides instructions on how to carrydifferent kinds of PDUs over AAL5 CPCS PDU.

. VC Mux Bridged � In VC Multiplexing of Bridged Protocols, only PDUsof bridged protocol are carried in the payload of the AAL5 PDU. Sincethere is no need for protocol identification information, this reducespayload overhead.

. LLC Bridged � In LLC for Bridged Protocols, bridged PDUs areencapsulated by identifying the type of bridged media in the LLC/SNAPheader.

CRC

CRC

CRC

LLC IP

LLC/SNAP IP PDU

VC MUX IP

IP PDU

LLC Bridged No FCS

LLC/SNAP MAC HDR MAC Data

VC MUX Bridged No FCS

MAC HDR MAC Data

Egress/Downstream

802.1Q Routed VLAN Frame

MAC HDR VLAN TAG Ether Type

Non-VLAN Bridged Frames

MAC HDR MAC Data

802.1Q Bridged VLAN Frames

MAC HDR VLAN TAG MAC Data

MAC Data/IP PDU

160 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 161: Dn03492199 4 en Global PDF Paper a4

4.1.10 Subinterface protocol types

4.1.10.1 PPP grooming

PPP grooming can be enabled or disabled for each subinterface. If PPP groomingis enabled, the following information must be provided:

. PPP encapsulation

- PPPoE

- PPPoA

. Destination ID

- VCC or VLAN

. PPPoE max allowed sessions

. PPPoE threshold sessions.

The first option for PPP grooming is to have a PPPoE server behind the trunk sideVLAN/VCC. In this case, the client side PPPoA and PPPoE traffic is forwardedto the configured trunk side VLAN/VCC. The client side PPPoE traffic groomingis straightforward: PPPoE sessions are transparent to the D500 node, and framesare passed transparently (just like regular bridging). If a PPP destination has beenspecified for a specific connection, the D500 node forwards all PPP traffic to theselected VLAN/VCC. In case of PPPoA connections, the D500 node has to act asa PPPoE client, thus opening/closing PPPoE sessions upon PPPoA clients'requests. Egress (downstream) PPPoE (data) traffic is forwarded to PPPoA clientsaccording to the PPPoE session IDs, and PPPoE control traffic is sent to the CPU.

Point-to-point protocol

Point-to-point protocol (PPP) defines an encapsulation mechanism fortransporting multi-protocol packets across layer 2 (L2) point-to-point links.

In the DSL application, PPP can manage point-to-point connections for multipleclient hosts through the D500 to a broadband remote access server (BRAS), suchas SE800. Each client, either PC or CPE, uses its own PPP protocol stack. Accesscontrol, billing, and service subscription, based on session time or services used,can be provided independently to each subscriber by associating user ID profilesto a user name and password.

PPP has two distinct stages: discovery stage and authentication stage. When theclient host initiates a PPP session, it must first discover which BRAS can initiatethe client�s request. The server authenticates the identity of the client�s user nameand password. If authentication is successful, the client and server establish apoint-to-point connection.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

161 (252)

Packet-based provisioning

Page 162: Dn03492199 4 en Global PDF Paper a4

From the traditional ATM based DSLAM point of view, the PPP sessions throughthe DSLAM have been transparent. The connections have been switched on theATM layer without any knowledge about the cell payloads.

There are two implementation choices for PPP connections, PPP over Ethernet(PPPoE) or PPP over ATM (PPPoA). Since the PPPoA does not have an Ethernetlayer it saves some overhead but in practise also requires the session to beterminated in the ADSL CPE, which in turn leads to a need for a routingfunctionality. The PPPoE adds overhead but has in practise been more widelydeployed because of the easier installation of a bridged CPE. Another advantageof PPPoE over PPPoA is the ability to have several simultaneous PPP sessionsover one layer 2 connection.

The D500 provides new opportunities for PPP deployments. The new enhancedmodel to manage traffic enables the D500 to switch and queue PPP sessions,allows simultaneous PPPoE connections with RBE connections, converts PPPoAsessions to PPPoE when the GE trunk is used, and aggregates sessions to savelayer 2 provisioning work.

The most common option for PPP deployments is to have a PPPoE server behindthe trunk side VLAN/VCC. In this case, PPPoA and PPPoE traffic of the clientside is forwarded to the configured trunk side VLAN/VCC. For PPPoE traffic onthe client side grooming is straightforward: PPPoE sessions are transparent to theDSLAM, and frames are passed transparently, just like in regular bridging. If aPPP destination has been specified for a specific connection, the D500 forwardsall PPP traffic to the selected VLAN/VCC. If there are PPPoA connections, theD500 has to act as a PPPoE client, thus opening and closing PPPoE sessions uponPPPoA clients� requests. PPPoE traffic returning from the network is forwardedto PPPoA clients according to the PPPoE session.

4.1.10.2 Multicast

There are three modes: IGMP proxy, IGMP snooping, and none. IGMP snoopingis supported in the bridged subinterface. IGMP proxy is supported in routed,RBE, and bridged subinterfaces. When IGMP is enabled, the mode is chosen onthe basis of the trunk subinterface. If the trunk subinterface is bridged and IGMPis enabled, the mode is IGMP snooping. If the trunk subinterface is routed andIGMP is enabled, the mode is IGMP proxy.

A routed or RBE subinterface can be enabled to support multicast. Multicast issupported by an IP services type of connection. If multicast is supported via anATM connection, then the traffic descriptor defines the bandwidth supported bythat connection. The subinterface defines the number of multicast channelssupported. This number restricts the number of multicast flows to be concurrentlycarried within the ATM connection. Multicast flows in this kind of connection

162 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 163: Dn03492199 4 en Global PDF Paper a4

have to be provisioned to have the highest priority (with the exception of VODtraffic). If the type of the IP services subinterface is DiffServe, then a packettraffic descriptor defines the bandwidth available for each class of service (CoS).It is recommended that the type of multicast is AF4.

The D500 provides functionality to deliver multicast video traffic to thesubscriber by replicating (multicasting) the data streams within the D500. This isnecessary when implementing TV broadcast-like delivery networks using DSLtechnology to avoid multiplying data streams per subsciber in the transmissionnetwork, thus saving transmission bandwidth. The Nokia D500 provides supportfor IP multicasting in the ATM or Gigabit Ethernet trunk/control unit.

The multicasting function allows communication with core network contentservers, also called the head-end, which transmit by IP multicasting 100�250channels of digital TV at 2�6 Mbit/s per channel. Subtended from a multicastrouter network or directly from the video server, the D500 provides an InternetGroup Management Protocol (IGMP) proxy function, authorisation function, andthe ability to replicate and forward MPEG over IP video streams to the digitalsubscriber lines.

When the system receives video channel IGMP join requests from the Set TopBox (STB) behind the DSL, the D500:

. Verifies user (STB) access rights to the requested channel againstinformation on the authorisation database resident in the D500

. Joins the STB to the appropriate IP multicast stream if authorised

. Delivers (replicates) the IP packets on the channel to the subscriber line.

The D500 stops the channel flow to the DSL when the user switches off thechannel by an IGMP leave request from the STB. Subsequent leave-join requestscreate the equivalent of channel switching in normal broadcast TV. If the user isnot authorised, the system returns a service denial message.

IGMP requests are forwarded upstream to request the channel from an IPmulticast router if the channel is not yet available at the D500, thus the D500 actsas an IGMP proxy. If the channel stream is already resident in the D500, theIGPM join is processed locally. It is practical to flood all frequent channels to theD500 initially because the network dimensioning typically has to support allchannels anyway. If all the possible channels are initially flooded to the D500, allsubsequent channel change functions are local to the D500. Then there is no needto have any upstream IP multicast routers in the network.

The local authorisation database enables fast channel switching (zapping)because all channel switching control function takes place within the D500without central database access.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

163 (252)

Packet-based provisioning

Page 164: Dn03492199 4 en Global PDF Paper a4

Communication for video delivery

Communication for video delivery through the DSL access network breaks intothree specific events and interchanges:

1. D500 start-up: Initiation of broadcast content to the D500 (with class Daddresses) and, if required, provisioning of user authentication information

2. STB start-up: Initial negotiation between the set top box (STB) and amanagement database to generate an electronic program guide (EPG). ThisEPG contains the map of class D addresses associated with the broadcastvideo content at the D500, so, for instance, it becomes clear that CNN onChannel 63 can be found at xxx class D address.

3. Channel selection: Request and delivery of video content to the STB basedon IGMP join and leave requests for the class D addresses of the videocontent available at the D500. The key to this function is authentication ofa particular STB to receive specific video content.

The D500 can negotiate these activities in a number of ways, depending onoperator requirements for channel flexibility, capital investment and channelchange times. Each interchange is described with its options below.

At the D500 start-up, the delivery of broadcast content from higher in the networkmust be initiated. This can occur in two ways:

1. The D500 is flooded with the multicast channels without having to requestthem. In this case, the negotiation between a multicast router and the D500is not required at all.

2. The D500 uses IGMP to request a multicast channel only when asubscriber requests that channel and it is currently not available at theD500. This method would most often be used to add less popular contentto the stream already sent to the D500 using method 1 or 2, above. In thiscase, the D500 issues an IGMP leave request from the multicast groupwhen it is not requested by any subscribers. This feature is useful when theaggregate interface of the D500 cannot support the bandwidth required forall flooded channels.

At the STB start-up, an Electronic Program Guide (EPG) must be downloaded.The EPG maps user identifiable content onto the class D addresses available atthe D500. Most commonly, this occurs by an exchange in the data networkbetween the STB and through the iTV application. In addition, many STBsrequire that their operating software be downloaded at power-up, and thisinterchange occurs over the data network as well. It should also be noted thateach EPG "ages", that is, it has a specified lifetime, and needs to be refreshedthrough the data network periodically.

164 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 165: Dn03492199 4 en Global PDF Paper a4

At the channel selection, the STB sends an IGMP join request for a particularclass D address to receive content. This join request is authenticated; that is, itshould be possible to determine that the subscriber is allowed to see the content.There are three methods for authentication:

1. No authentication performed

This is the simplest method, and assumes that all STBs that have beengiven an EPG are authorised to join a multicast group that they know theclass D address for. This method suffers from security issues with regard to�pirating� content; a subscriber not paying for the video service coulddetermine the class D address and request the content without paying for it.In the case where all subscribers are authorised to see all content, this maybe a viable implementation since it simplifies the provisioning of thesystem.

2. Channel authentication at the D500

The D500 is pre-provisioned with which subscribers (as identifiedoptionally by their STB MAC address or port or both) are allowed tosubscribe to which class D addresses. This allows only authorisedsubscribers to view content, and also allows provisioning of "premium"channels to a particular subscriber. In general the broadcast IP streams areassigned to either one or several �Channel Packages�, and individualsubscribers are given access to Channel Packages rather than individualmulticast streams. Both these operations are supported in the D500.

3. Channel authentication at higher network resources, through the iTVapplication

This occurs for non-multicast content, where a subscriber is paying for avideo stream not currently multicast. Authentication and billing occurshigher in the network, and the video stream is initiated at that time. Thismethod is preferred for the first instance of near video on demand (NVoD)content. Subsequent subscribers to the address may be authenticated at theD500.

The authorisation table of point 2 above is downloaded to the D500 from theNetAct Network management system of the D500. It is possible to implement afully centralised management of the channel authorisation by interfacingcustomer care system to the NetAct, for example using the Corba interface. Theexact design of this functionality is related to the selected identification anddelivery methods of the DSL and the STBs, among other things, so it is normallyimplemented in a system integration project.

Example 1.

The following figure shows an example of a small multicast set-up.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

165 (252)

Packet-based provisioning

Page 166: Dn03492199 4 en Global PDF Paper a4

Figure 39. Small multicast test setup

The server is broadcasting four streams with multicast addresses from 225.1.1.1to 225.1.1.4, and there are two customers with Set Top Boxes (STBs) whose IPaddresses are 151.1.1.2 (MAC address 00 40 43 F6 01 02) and 151.1.2.2 (MACaddress 00 40 43 F6 10 4B). The four streams are to be configured as onepackage whose name is TestPackage1. The needed commands to the D500 are thefollowing:

configure ip multicast chanpkg new TestPackage1 225.1.1.1225.1.1.2 225.1.1.3 225.1.1.4configure ip multicastclientauth new 00:40:43:F6:01:02 TestPackage1configureip multicast clientauth new 00:40:43:F6:10:4BTestPackage1

Note

These are the only commands needed to configure the D500 to allow theconditional access. There may be several configuration operations needed toconfigure the STBs to allow them to present the channels to the end user, but thisis a function of an individual STB.

Videoserver

D500

CPE 1

CPE 2

STB 1

STB 2

TV set 1

TV set 2

PVC 0/38

PVC 0/39

IP 161.1.1.1 IP 161.1.1.2 IP 151.1.1.1

IP 151.1.2.1

IP 151.1.2.2

IP 151.1.1.2

Ch 1 IP 225.1.1.1Ch 2 IP 225.1.1.2Ch 3 IP 225.1.1.3Ch 4 IP 225.1.1.4

166 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 167: Dn03492199 4 en Global PDF Paper a4

Egress packets arriving from the trunk side are either forwarded to one or moreATM VCs or discarded. Ingress packets arriving on an ATM VC are eitherforwarded to a VCC, VLAN, an L2TP tunnel or, to a PPPoE session, ordiscarded.

IP fragmenting is not supported in the trunk unit. It is assumed that the originatorof the packet has performed MTU size discovery or has restricted the packetlength to the appropriate value by manual configuration.

Multicast and broadcast packets arriving from the trunk side need to beduplicated and sent to multiple ATM VCs. Broadcast packets need to beselectively copied to all ATM VCs, which belong to the bridge group associatedwith the VLAN ID of the arriving Ethernet packet. Multicast packets need to beselectively copied to subscriber side ATM VCs on which one or more hosts haverecently joined a multicast group. This requires that the D500 terminates allIGMP traffic and detects when any host on a VC enters or leaves a multicastgroup.

Video-on-demand

The D500 node does not participate in the VOD transaction between the VODclient and server. This means that the D500 node does not separate VOD PDUsfrom other traffic. To make sure that VOD PDUs get priority over less time-critical traffic, DiffServ should be enabled and VOD PDUs should be tagged witha DiffServ code point that indicates higher priority. It is recommended that AF41would be used for VOD traffic.

4.2 Basic packet forwarding rules

4.2.1 Downstream packets

Two basic types of subinterfaces are supported at the trunk interface: bridged androuted. Bridged interfaces can handle PPPoE traffic separately from the othertraffic.

. Unicast packets received on a bridged VLAN/VCC

If the unicast packet's MAC address matches the Ethernet address at thetrunk interface, it can be destined to the D500 node or it can be a locallyterminated IP packet. If the MAC does not belong to the D500 system, theframe is a handled like a typical bridged frame and is forwarded to a singleATM VC based on the destination MAC.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

167 (252)

Packet-based provisioning

Page 168: Dn03492199 4 en Global PDF Paper a4

The MAC address table is built and maintained dynamically by learningsource MAC addresses from ingress traffic.

. Broadcast packets received on a bridged VLAN/VCC

These are duplicated and forwarded to all ATM VCs belonging to the samebridge group as the receiving VLAN.

. Multicast packets received on a bridged VLAN/VCC

Multicast packets are forwarded to all ATM VCs belonging to the samebridge group as the receiving VLAN.

. Unicast packets received on a routed VLAN/VCC

The forwarding decision is based on the destination IP address. The MACheader should contain the MAC address of the D500 node. The destinationaddress is matched against the current routing table with the longest prefixmatch selected. The packet is then encapsulated in accordance with theparameters of the outgoing subinterface, and sent on its way.

. Broadcast packets received on a routed VLAN/VCC

The handling of these packets depends on their content.

If the ARP is directed to the configured IP address of the D500 node onthis subinterface, the trunk unit responds with an ARP reply on the sameVLAN containing the Ethernet MAC address of the D500 node.

. Multicast packets received on a routed VLAN/VCC

Multicast packets are forwarded to all ATM VCs that have at least oneauthenticated multicast recipient host.

. Packets received on a one-to-one routed VLAN

All the unicast and multicast packets are forwarded to the identified clientVCC. Broadcast packets are discraded with the exception of ARP packetsthat are handled as in the regular subinterface�s case.

4.2.2 Upstream packets

Three basic types of subinterfaces are supported at the client interface: bridged,routed and routed bridged (RBE).

In a routed subinterface, all the packets are forwarded based on the destination IPaddress.

In bridging, anything other than PPPoE is forwarded based on the destinationMAC address. If the interface is such configured, PPPoE frames can be passed tothe trunk side PPPoE server.

168 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 169: Dn03492199 4 en Global PDF Paper a4

In a bridged subinterface a received frame that does not contain PPPoE (with orwithout MAC) traffic is simply forwarded to the corresponding bridge group�strunk subinterface. Source MAC addresses are also learned when bridged framesare passed in the ingress direction.

In RBE subinterfaces, IP packets are routed normally, but PPPoE packets can beconfigured to be handled as in bridging.

. Unicast packets received on a bridged subinterface

If so configured, PPPoE packets are forwarded to the PPPoE serverassigned to the sending subinterface. In PPPoE forwarding, the D500 justforwards PPPoE PDUs between the identified subinterfcaes.

Non-PPPoE ingress packets are forwarded to the configured trunk sidesubinterface (VCC or VLAN).

. Broadcast packets received on a bridged subinterface

These packets are handled in the same way as unicast packets. Broadcastpackets are not broacasted to other line subiterfaces although they belongto the same bridge group and VLAN.

. Multicast packets received on a bridged subinterface

Examples of multicast packets arriving in the ingress direction are packetsaddressed to the "ALL OSPF ROUTERS", "DHCP RELAY AGENT"addresses.

Handling is the same as in the broadcast frame case.

. Unicast packets received on a routed subinterface

Based on the destination IP address and routing table, a single copy of thepacket is routed to a single subinterface. The subinterface is selected fromthe routing table by means of the longest prefix match algorithm. If thepacket is destined to a D500, the packet is dropped.

. Broadcast packets received on a routed VC

These packets are dropped.

. Multicast packets received on a routed VC

These packets are dropped.

. Packets recived on a one-to-one routed subinterface

All incoming packets are forwarded to the identified trunk subinterface.

. Unicast packets received on RBE subinterface

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

169 (252)

Packet-based provisioning

Page 170: Dn03492199 4 en Global PDF Paper a4

All IP packets are routed as in the case of the routed interface. PPPoEpackets are forwarded to the configured PPPoE server. If the PPPoEhandling has not been enabled, the packet is dropped. RBE interface dropsmost packets not containing IP.

. Broadcast packets received on RBE subinterface

Other type of broadcast packets than ARP, BOOTP (DHCP) and PPPoEdiscovery frames are dropped at this interface. ARPs that query the MACaddress of the D500 are passed to the CPU, and there to the ARP module.BOOTP messages are passed to the CPU, and there to the DHCP relaymodule. The DHCP relay passes the request to the DHCP server that hasbeen configured onto this connection. Just like in the bridging case, PPPoEdiscovery PDUs are passed to the configured PPPoE server.

. Multicast packets received on RBE subinterface

All multicast PDUs are dropped at the RBE subinterface.

170 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 171: Dn03492199 4 en Global PDF Paper a4

5 ATM VC cross-connection provisioning

5.1 ATM VC cross-connection provisioning

The D500 Multiservice Access Platform (MSAP) cross-connects two ends of anATM data pipe. This data pipe is called a virtual connection. In a typical DSLAMapplication one end of this data pipe goes to an ATM network via the trunkinterface and the other end goes to the CPE via a line card port. The DSLAM isused to multiplex virtual connections coming from the subscribers to the trunkinterface. The D500 MSAP, however, does not only multiplex virtualconnections. The trunk/control unit in a D500 subrack acts as an ATM switch,and can be used to to flexibly cross-connect ATM virtual connections. Four maintypes of cross-connections are supported:

. Line card port to a trunk unit port

. Line card port to a tributary unit port

. Tributary unit port to a trunk unit port

. Tributary unit port to a tributary unit port.

These cross-connection types are discussed in more detail later in this chapter.

The D500 node supports a maximum of 8000 ATM connections. The trunk/control unit with OC-12/STM-4 interface (TK622) and the OC-3/STM-1 tributaryunit (TRB155) each support a maximum of 8000 connections. The maximumnumber of connections per a D500 DSL unit is 400. The maximum bandwidthcapacity per a DSL unit is 1 Gbit/s.

Note

Additional provisioning information can be located in Provisioning parameters.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

171 (252)

ATM VC cross-connection provisioning

Page 172: Dn03492199 4 en Global PDF Paper a4

5.1.1 A PVC connection

ATM supports two types of circuits: permanent virtual circuit (PVC) andswitched virtual circuit (SVC). The D500 supports PVC connections. A PVC isprovisioned by the network service provider as part of setting up subscriberservice. Once a PVC is established, data goes in one end of the pipe, and comesout the other end.

PVC provisioning in the D500 consists of the following components:

. Connection ID number

. Virtual Link A: Link A can be either a line card or a tributary unit. Thefollowing must be specified for Link A: unit, port number, virtual pathidentifier (VPI), and virtual circuit identifier (VCI).

Note

See the figures later in this chapter to determine Link A for each type of cross-connection.

. Virtual Link Z: Link Z can be either a trunk unit or a tributary unit. Thefollowing must be specified for Link Z: unit, port number, VPI, and VCI.

Note

See the figures later in this chapter to determine Link Z for each type of cross-connection.

A connection ID number is an integer from 1 to 4064, assigned sequentially bythe D500 system as each connection is established. When the D500 breaks aconnection, that ID number is free. The connection ID number is reused when IDnumbers are assigned up to 4064; the counter then starts back at the first free ID.

The D500 node has two ATM connection resources that are limited: bandwithand cell buffers. If the node runs out of either bandwith or cell buffers, no newcross-connection can be made.

172 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 173: Dn03492199 4 en Global PDF Paper a4

5.1.2 DSL port parameters

Associated with the line card port are a series of DSL parameters that control howthe line card port sends data over the copper network. Refer to ADSLprovisioning, and/or VDSL provisioning for detailed information on theseparameters. DSL provisioning information required from the service orderincludes maximum and minimum upstream and downstream data rates.

5.1.3 Provisioning with Craft Terminal

Detailed procedures for provisioning are provided in Service provisioning.

5.1.4 Examples of cross-connections

Line card to trunk unit

The figure below shows a typical DSLAM application, where DSLAMmultiplexes traffic coming from the CPE to the ATM network interface located inthe trunk unit.

The line card port is connected to the subscriber�s residence or business�via theexisting copper �twisted pair� network�using digital subscriber line (DSL)technology.

At the ATM network interface, the D500 MSAP sends and receives ATM cellscontaining customer �payload�. At the subscriber�s end of the twisted pair, theNIC or external router/modem extracts the customer �payload� out of the ATMcell format, and reassembles the �payload� back into its original form.

From the perspective of the subscriber or the ATM network backbone, the datagoes in one end of the data pipe at the ATM network interface, and comes out theother end at the customer�s PC.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

173 (252)

ATM VC cross-connection provisioning

Page 174: Dn03492199 4 en Global PDF Paper a4

Figure 40. Line card to trunk unit

Line card to tributary unit

Tributary units can also be utilised as network interfaces. The trunk capacity canbe increased by adding more tributary ports to the aggregate direction, forexample, to offer the extra capacity desired to allow streaming media connectionsto subscribers. A tributary unit is typically used in the aggregate side also whenseveral D500 nodes or D500 RAMs have been cascaded. In the ingress directionof this application, connections of the first D500 element exit from the tributaryunit port(s) and enter the second D500 again via the tributary unit port(s). Thesecond D500 then uses the trunk/control unit (or tributary unit) as a trunkinterface to the ATM network.

In this VC cross-connection case, traffic from a line card connection is firstforwarded to the trunk unit. The trunk unit cross-connects (switches) the traffic toa tributary unit, which sends the traffic out to the ATM network in the upstreamdirection. The reverse path is followed in the downstream direction. The linecard is provisioned as Link A and the tributary unit as Link Z. The figurebelow illustrates this configuration:

ATMNetwork

CPE

Ports

TrunkUnit

LineCard

D500

Upstream

Downstream

Link Z Link A

Connectionsare multiplexed

VirtualConnection

174 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 175: Dn03492199 4 en Global PDF Paper a4

Figure 41. Line card to trinbutary unit

Tributary unit to trunk unit

This kind of cross-connection can be used when several DSLAMs have beencascaded. The subtended DSLAM(s) can be connected to the port(s) of a tributaryunit, and the trunk unit can be used as an interface to the ATM network. In thistype of cross-connection, traffic from the subtended DSLAM is forwarded fromthe tributary unit to the trunk/control unit. The trunk unit cross-connects thetraffic to the trunk interface and out to the ATM network in the upstreamdirection. The reverse path is followed in the downstream direction. The trunkunit is provisioned as Link Z and the tributary unit as Link A. The figurebelow illustrates this configuration:

ATMNetwork

CPE

Ports

Ports

Trib.Unit

TrunkUnit

LineCard

D500

Upstream

Downstream

Link Z Link A

Connection switchedto the Tributary Unit

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

175 (252)

ATM VC cross-connection provisioning

Page 176: Dn03492199 4 en Global PDF Paper a4

Figure 42. Tributary unit to trunk unit

Tributary unit to tributary unit

This cross-connection application is similar to the one explained above(cascading of DSLAMs). This example, however, shows that it is possible to usetributary units on both sides of the ATM connection. In the upstream direction ofthis type of cross-connection, traffic from the tributary unit is cross-connected inthe trunk unit back to the tributary unit (the same or different tributary unit) andout to the ATM network. The reverse path is followed in the downstreamdirection. The tributary unit nearest to the ATM network is Link Z and the onecloser to the ATM switch (another DSLAM, for instance) is Link A. The figurebelow: tributary unit to tributary unit figure illustrates this configuration:

ATMNetwork

Ports

TrunkUnit

Trib.Unit

D500

Upstream

Downstream

Link Z Link A

Connectionsare switched

VirtualConnection

ATM Switch/Router

176 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 177: Dn03492199 4 en Global PDF Paper a4

Figure 43. Tributary unit to tributary unit

Note

In all of the VC cross-connection cases described above, incoming traffic ispoliced in both the egress and ingress directions.

5.1.5 Provisioning parameters

The following parameters are seen in the New Connection dialog box:

Link A/Z VPI/VCI values: VPI and VCI specify the ATM circuit address foreach end of the connection. The VPI (virtual path identifier) identifies the route tobe used by the ATM cell. A virtual path may include multiple virtual channels.The VCI (virtual channel identifier) identifies the specific virtual channel towhich the cell belongs. The VPI and VCI are translated at each ATM switch andare unique only for a given physical link.

Ranges for the VPI and VCI values on the OC-12/STM-4 trunk side are:

ATMNetwork

Ports PortsTrib.Unit

TrunkUnit

D500

Upstream

Downstream

Link Z Link A

Connection switchedto the Tributary Unit

Trib.Unit

ATM Switch/Router

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

177 (252)

ATM VC cross-connection provisioning

Page 178: Dn03492199 4 en Global PDF Paper a4

. VPI: 0�4095

. VCI: 32�65535.

Ranges for the VPI and VCI values on the OC-3/STM-1 tributary unit side are:

. VPI: 0�255

. VCI: 32�65535.

Ranges for the VPI and VCI values on the line side are:

. VPI: 0�255

. VCI: 32�65535.

Select VP Connection to set up a Virtual Path (VP) without setting up individualVirtual Circuits within the VP. For example, if you have multiple PCs connectedto a single ADSL router at the remote end CPE, use the VP Connection option toconfigure the same parameters for all nodes attached to the router.

The topology of a connection is always duplex (bi-directional).

Administration State: This specifies whether the connection is available forservice.

. Unlocked makes the connection usable if there are no other conditionsblocking its use.

. Locked makes the connection unavailable for service. The administrationstate should be set to Locked when configuring or deleting a connection.

Traffic descriptors: Two ATM traffic descriptors must be provisioned for eachconnection, including VC cross-connections. Separate traffic descriptors fordownstream (Z to A) and upstream (A to Z) direction allow you to provisiondifferent bandwidths for each direction. You can select from a set of default trafficdescriptors or create new traffic descriptors. For more information on how tocreate and use traffic descriptors, refer to Traffic descriptors.

The Craft Terminal New Connection dialog box shows the provisioningparameters.

178 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 179: Dn03492199 4 en Global PDF Paper a4

Figure 44. New connection

Default settings for Link A are VPI 0, VCI 100, and the default traffic descriptoris 9. The default setting for Link Z is the trunk/control unit. The defaults are alsoseen in the Preferences dialog box in Web-based Craft-Terminal.

For additional information on creating UBR connections, see QoS in ATMnetworks.

5.1.6 Quick connection creation

Web-based Craft Terminal includes the Quick Connection Creation feature,which provides an effective way to configure new connections. It allows you topre-select the slot and port in the Tree View for Link A and Link Z settings. Whenyou open the New Connection dialog box, these pre-selected settings appearautomatically in the dialog box, and the only settings you need to enter for eachconnection are the VPI/VCI and the traffic descriptors (and optionally the VPConnection check box).

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

179 (252)

ATM VC cross-connection provisioning

Page 180: Dn03492199 4 en Global PDF Paper a4

5.1.7 Craft Terminal reference information

For additional reference information on the various sets of tab pages and dialogboxes used for setting up and modifying ATM connections, see Web-based CraftTerminal.

180 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 181: Dn03492199 4 en Global PDF Paper a4

6 QoS provisioning

6.1 D500 traffic management

Traffic management and traffic descriptors are required to ensure proper resourceallocation and to quarantee the agreed quality of service (QoS). The D500supports simultaneous feeds from ATM and IP/Ethernet interfaces while itprovides the required service levels over both QoS (ATM) and CoS (IP, Ethernet)connections and flows simultaneously.

As packets and cells enter the D500 they go through several processing steps,which ensures that they are handled appropriately according to the type ofinformation or services they are carrying. These major steps of the D500 trafficmanagement are described below:

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

181 (252)

QoS provisioning

Page 182: Dn03492199 4 en Global PDF Paper a4

Figure 45. Major traffic management steps in the D500

Classification

Classification identifies the PDUs. In the D500 the classification process consistsof two phases. The first pass examines the received data in a cell/block level (forexample, the interface which the cell came from, the connection which it belongsto, or the ATM CLP bit, if it has been set). The second pass inspects the completePDUs and makes the final classification decision (based on the IP destinationaddress and DiffServ code points, for instance). The classification decision is aprerequisite for all the actions that follow: policing incoming traffic based on thedefined traffic parameters, routing the PDU to the correct interface and to theappropriate priority queue, scheduling the PDU according to its service category,and the rest.

Policing

Policing ensures that the incoming traffic conforms to the rules embodied in thetraffic contract. In principal the policing process in the D500 is implementedsimilarly for both ATM and IP/Ethernet traffic. But because ATM as a cell-basedprotocol differs from packet-based IP/Ethernet protocols and the monitored

voice data video data video voice

WRED,EPD

Outgoingpackets

(in priority order)

Priorityscheduling &class-basedshaping

Classification,policing &marking

Incomingpackets

Scheduling

UBR-DF-Eth. low

VBRnrtwith tag

VBRnrt w/o tag-AF4-Eth. medium

VBRrt-EF-Eth. high

CBR

QoS/CoSqueues

Queuing &congestionmanagement

182 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 183: Dn03492199 4 en Global PDF Paper a4

parameters are different, there are also some differencies in their policingprocesses. ATM connections can use a generic cell rate algorithm (GCRA),whereas a Two Rate Three Color Marker (trTCM) algorithm can be applied topacket-based subinterfaces. Based on the policing results:

. PDU can be forwarded as such

. marking can be applied to the PDU (for example, setting the CLP bit inATM cells, changing the DiffServ drop precedence from AF41 to AF42 inIP packets)

. PDU can be dropped.

Queueing

Queueing stands here for a function in which PDUs are forwarded to correctoutput ports and to appropriate priority queues. An output port can be forexample an xDSL interface, a Gigabit Ethernet interface, or an STM-1 interface.For each output port there are five QoS/CoS queues as shown in Major trafficmanagement steps in the D500. For ATM traffic all five queues can be used. ForIP DiffServ traffic or for Ethernet traffic supporting IEEE 802.1p user prioritiesthere are three priority queues. The selection of the QoS/CoS queue is basedpurely on the classification results. The policing process cannot change thedestination queue.

Note

The five queues are per output port, not per subinterface (PVC/VLAN).

Congestion management

Congestion management (or congestion control and avoidance) is actually a partof a queuing function. The QoS/CoS queue sizes and filling thresholds arepredetermined. When a congestion threshold is reached in a queue, a packetdropping and congestion avoidance mechanism is applied to the queue. The D500uses a proprietary implementation of a weighted random early detection (WRED)mechanism for this purpose. When a 50-% threshold is exceeded in a queue, 50% of the received traffic destined for this queue will be dropped randomly. Whenthe queue reaches the 100-% level, all incoming traffic for the queue will bedropped.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

183 (252)

QoS provisioning

Page 184: Dn03492199 4 en Global PDF Paper a4

Early packet discard (EPD) (also called frame discard) is supported for ATMinterfaces. EPD makes an intelligent choice and drops all cells of an incomingpacket instead of randomly dropping cells from many packets. Also explicitforward congestion indication (EFCI) is supported for ATM interfaces. EFCI isused to notify other network resources that a given queue is in a congestion state.The EFCI bit will be asserted in the ATM cell headers once an 80-% threshold isexceeded in a QoS/CoS queue.

Scheduling and shaping

Scheduling and shaping provide the appropriate servicing of the queues so trafficcan be presented into the network in an appropriate manner, with respect to trafficclass priorities. The D500 supports scheduling and shaping on a traffic class andqueue basis. The actual implementation is described in the following figure:

Figure 46. Traffic scheduling and shaping

Inside the routing switch processor (RSP) a logical port is used to limit the rate ofthe total traffic that can be forwarded to an interface (for example an ADSL portor a trunk interface). Behind the logical port there are three schedulers � twodynamic and one first in first out (FIFO) � and these schedulers are servicing fiveQoS/CoS queues.

UBR-DF-Eth. low

VBRnrtwith tag

VBRnrt w/o tagAF4-Eth. medium

VBRrt-EF-Eth. high

CBR

FIFOscheduler

Dynamicscheduler 2

Dynamicscheduler 1

Logicalport

Bandwidthreservedby CAC

Qos/CoSqueues

Queue levelshaping /rate limiting

Interface levelrate limiting &strict priorityscheduling

184 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 185: Dn03492199 4 en Global PDF Paper a4

Connection admission control

The connection admission control (CAC) process is defined as the set of actionstaken during the packet subinterface or ATM connection establishment todetermine whether the predefined CoS/QoS parameters can be met when theconnection is set up or whether the connection should be rejected. The CACfunction is always enabled in the D500.

The scheduling/shaping rates used for queues (=queue drain speeds) arecalculated by the connection admission control (CAC) process. The CAC uses aformula to determine a quaranteed bandwidth for each queue. The shaping ratefor the CBR and EF/Ethernet high priority traffic is established by summing thepeak cell rates (PCRs) of all the provisioned CBR connections or peakinformation rates (PIRs) of all the EF/high priority flows respectively. For theVBRrt, VBRnrt w/o tag, VBRnrt with tag, and for AF4/Ethernet medium priorityqueues the shaping rate is derived by summing the sustainable cell rates (SCRs)or committed information rates (CIRs) of the respective connections/flows, andby adding some excess bandwidth to this based on the bursts configured. TheUBR or DF/Ethernet low priority queue gets the remaining capacity left for thelogical port (= logical port rate minus quaranteed bandwidths for the port).

The D500 supports also CAC overbooking. If this feature is enabled, it is possibleto allocate more bandwidth to the traffic going to the CBR, VBRrt-EF-Eth. high,VBRnrt w/o tag-AF4-Eth. medium and VBRnrt with tag queues than is supportedby the logical port. As a result the bandwidths for these queues are no longerquaranteed, and in case of congestion lower priority traffic may have to bediscarded.

Thus, in the D500 scheduling process the dynamic scheduler 1 has the highestpriority, dynamic scheduler 2 the second highest priority, and the FIFO schedulertakes care of the remaining bandwidth left for the logical port. If there are twoqueues behind one scheduler, a weighted round robin (WRR) type of mechanismis used to determine the queue to be serviced (weights are calculated automaticlyby the CAC process).

6.1.1 Best effort only mode for line cards

It is possible to provision any line card to a best effort only mode. If this mode isenabled, all the ATM QoS, IP DiffServ and Ethernet 802.1p priority features forthat unit are disabled, and the unit�s traffic is processed in both directions as besteffort only (one logical port and the FIFO scheduler is used for the whole unit inthe downstream direction, but each port has its own UBR, DF, Eth., low queue).The benefit of using this mode is that it is not necessary to allocate a fixed amountof quaranteed bandwidth for each port in the card. As a result the sum of all theports� maximum bandwidths is allowed to exceed the unit�s total bandwidth.Consequently, more bandwidth can be supported per port providing that all ports

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

185 (252)

QoS provisioning

Page 186: Dn03492199 4 en Global PDF Paper a4

are not using the full bandwidth at the same time. The drawback is that the QoS/CoS features cannot be used in this case and all the ports in the card will competeof the total card bandwidth in a best effort fashion. The line card must not haveany subinterfaces/connections when this mode is changed.

6.2 IP CoS based on DiffServ

The following describes how the D500 supports IP class of service (CoS). Rulesthat apply to packet policing, queueing, dropping and modification are presentedfor the bridged, routed and RBE modes.

IP CoS is based on the differentiated services code points (DSCP), which arelocated in the service type field of the IPv4 header as shown in DSCP in the IPv4header. These six bits are used to indicate the service class of the flow (EF, AFxor DF). In the case of the AFx class, the bits indicate also the drop probability thatshould be applied to the flow (packets with higher drop precedence should bediscarded first in a case of congestion).

Figure 47. DSCP in the IPv4 header

IPv4 Typeof Service(ToS) octet

IP precedencebitsor

class selectorcodepoints

Diffrentiated Service(DS) field

not usedby DiffServ

Drop precedence bits for AF class:010 -> low drop precedence (AFx1)100 -> medium drop precedence (AFx2)110 -> high drop precedence (AFx3)

DiffServ Codepoint (DSCP) is a value,which is encoded in the DS field:101110 -> expedited forwarding (EF)

100xxx -> assured forwarding (AF4)011xxx -> assured forwarding (AF3)010xxx -> assured forwarding (AF2)001xxx -> assured forwarding (AF1)

000000 -> default forwarding (DF)

186 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 187: Dn03492199 4 en Global PDF Paper a4

The queues and schedulers used for DiffServ CoS classes in the D500 are shownin the figure below:

Figure 48. Queues and schedulers user for IP DiffServ traffic

6.2.1 IP CoS in different service modes

IP CoS has three modes: bridged, routed, and RBE.

6.2.1.1 Bridged subinterface

IP class of service based on the DiffServ code points cannot be used for bridgedsubinterfaces. When a subinterface is configured to a bridged mode and ifEthernet user priorities are not supported, all the incoming packets are forwardedto DF queues. If Ethernet user priorities are supported, these priority bits can beused to direct packets to appropriate CoS queues (refer to Ethernet CoS based onVLAN user priorities). The DiffServ code point bits are not examined, and theyare never modified in the D500.

DF (= BE)

AF4

EF

Dynamicscheduler 2

Dynamicscheduler 1

Logicalport

Bandwidthreservedby CAC

Qos/CoSqueues

Queue levelshaping /rate limiting

Interface levelrate limiting &strict priorityscheduling

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

187 (252)

QoS provisioning

Page 188: Dn03492199 4 en Global PDF Paper a4

6.2.1.2 Routed subinterface

Routed subinterfaces can be configured to either non-DiffServ or DiffServ mode.In a non-DiffServ mode the incoming packets are always forwarded to a DFqueue. The CoS bits are not touched (assuming that both input and outputsubinterfaces are configured to the non-DiffServ mode; however, if the outputsubinterface is set to the DiffServ mode, the outgoing packet has CoS bits set toDF).

DiffServ mode supports two options: pass mode and map mode. In the pass modethe DiffServ code points (DSCP) of the incoming packet are used directly forqueue selection. The D500 supports three CoS queues for DiffServ traffic: EF,AF4 and DF. The following table explains how the DiffServ traffic classes of theincoming packets are converted into the three service classes supported by the theD500:

Table 32. DiffServ traffic classsesconverted into service classes

IPprece-dence bits

DiffServtraffic class

D500trafficclass

111 AF4

110 AF4

101 EF EF

100 AF4 AF4

011 AF3 AF4

010 AF2 AF4

001 AF1 AF4

000 DF DF

When a subinterface is set to a map mode, the user can remap any receivedDiffServ code point to any of the three code points supported by the D500 (EF ->{EF|AF4|DF}, AF -> {EF|AF4|DF}, DF -> {EF|AF4|DF}). For example it ispossible to convert packets received from a device not supporting DSCPs into�fixed DSCP packets� by mapping code points of all the packets received fromthat subinterface to the same value. These new remapped DSCP values are thenused in policing and queue selection.

188 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 189: Dn03492199 4 en Global PDF Paper a4

For routed subinterfaces in the map mode, the D500 gives the DSCP field of theoutgoing packets one of the three possible values: EF, AF4 or DF. For AF4 trafficthe default drop precedence is AF41, but it may be changed to AF42 by thepolicing process. In the pass mode the packets going out from a routedsubinterface contain the same DSCP values as were received in the incomingpackets.

6.2.1.3 RBE subinterface

When a routed bridged encapsulation (RBE) is configured to a client sidesubinterface, bridged AAL5 encapsulation is used towards the CPE, but the D500skips the Ethernet header (layer 2) and does all the processing based on the IPheader (layer 3). From the traffic management�s point of view, an RBEsubinterface functions in many ways as a routed subinterface. However, there isone difference: the packets going out from the RBE subinterface always containthe same DSCP values as were received in the incoming packets (the D500 leavesthe DSCP field untouched, also in the case where the map mode is used in arouted input subinterface). However, when packets are received from an RBEsubinterface, both the pass and map modes are supported exactly as in routedsubinterfaces.

6.2.2 CoS in the D500

The different classes of service are processed in the D500 as follows:

6.2.2.1 EF

Expedited forwarding (EF) is designed for providing a low-loss, low-latency,low-jitter, and assured bandwidth service. Applications such as Voice over IP(VoIP), video, and online trading programs require such a robust networktreatment.

The policing process (based on trTCM) tests the EF traffic against the peakinformation rate (PIR) and the peak burst size (PBS) defined in a packet trafficdescriptor (PTD) for the policed subinterface. If the packet conforms with thePTD, it is queued to the VBRrt-EF queue, which is scheduled by dynamicscheduler 1, otherwise it is dropped.

The following table summarises how the D500 processes EF traffic:

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

189 (252)

QoS provisioning

Page 190: Dn03492199 4 en Global PDF Paper a4

Table 33. EF traffic processed by the D500

Fillfactorof thequeue(%)

Packet forwarding Cell modification Packet DSCPmodification

Packetout

Routed

Packetout

RBE

Green Red CLP bit EFCI EF xx

0�50 Forward Drop Assign Same aspacket in

50�80 Drop 50%randomly

Drop Assign Same aspacket in

80�100 Drop 50%randomly

Drop Assign Assign Same aspacket in

100 Drop Drop

Note

Green: The packet conforms to PIR and PBS criteria.

Red: The packet violates PIR and PBS criteria.

6.2.2.2 AF

Assured forwarding (AF) is not intended to provide latency-bounded service. Itdefines a method with which similar type of flows can be given a forwardingbehavior with some assigned level of queuing resources and different forwardingassurances by controlling the drop probability of the AF marked packets.

The policing process (based on trTCM) tests the AF traffic against the peakinformation rate (PIR) and the peak burst size (PBS) as well as against thecommitted information rate (CIR) and the committed burst size (CBS) defined ina packet traffic descriptor (PTD). Conforming packets are queued to the VBR-nrtw/o tag-AF4 queue, which is scheduled by dynamic scheduler 2.

190 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 191: Dn03492199 4 en Global PDF Paper a4

The following table summarises how the D500 processes AF traffic:

Table 34. AF traffic processed by the D500

Fillfactorof thequeue(%)

Packet forwarding Cellmodification

Packet DSCP modification

Out

Routed

Map

Out

Routed

Pass

Out

RBE

Green Yel-low

Red CLPbit

EFCI AF41 AF42 xx xx

0�50 For-ward

For-ward

Drop Assignif yellow

Assignif green

Assignifyellow

Same aspacket in

Same aspacket in

50�80 Drop50 %ran-domly

Drop Drop Assign Same aspacket in

Same aspacket in

80�100

Drop50 %ran-domly

Drop Drop Assign Assign Same aspacket in

Same aspacket in

100 Drop Drop Drop

Note

Green: The packet conforms to CIR and CBS criteria.

Yellow: The packet violates CIR and CBS criteria, but conforms with PIR andPBS criteria.

Red: The packet violates PIR and PBS criteria.

6.2.2.3 DF

Default forwarding (DF) specifies that a packet marked with DSCP value 000000gets the traditional best effort (BE) service after EF and AF traffic.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

191 (252)

QoS provisioning

Page 192: Dn03492199 4 en Global PDF Paper a4

The policing process tests the DF traffic against the peak information rate (PIR)and the peak burst size (PBS). DF traffic is queued to the UBR-DF queue, whichis scheduled by the FIFO scheduler.

The following table summarises how the D500 processes DF traffic:

Table 35. DF traffic processed by the D500

Fillfactorof thequeue(%)

Packet forwarding Cell modification Packet DSCPmodification

Packetout

Routed

Packetout

RBE

Green Red CLP bit EFCI DF xx

0�50 Forward Forward Assign ifred

Assign Same aspacket in

50�80 Drop 50%randomly

Drop Assign Same aspacket in

80�100 Drop 50%randomly

Drop Assign Assign Same aspacket in

100 Drop Drop

Note

Green: The packet conforms to PIR and PBS criteria.

Red: The packet violates PIR and PBS criteria.

6.3 Ethernet CoS based on VLAN user priorities

The following describes how the D500 supports Ethernet CoS in bridgedsubinterfaces. The description includes the rules that apply to packet policing,queueing, dropping, and modification.

192 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 193: Dn03492199 4 en Global PDF Paper a4

IP CoS based on DiffServ code points (refer to IP CoS based on DiffServ) is amethod that can be used to differentiate layer 3 service classes, so that the D500traffic management can process packets according to their priority level. Themethod is, however, not applicable to bridged subinterfaces, which examine thepackets only at the Ethernet (layer 2) level. To support different service classesalso in the bridging mode, it is possible to separate different Ethernet CoS classesby using Ethernet user priority bits. These three user priority bits are part of theEthernet frame�s VLAN tag (described in IEEE 802.1p/802.1q) as shown in thefollowing figure.

Figure 49. User priority bits in the Ethernet VLAN tag

Internally the D500 supports three Ethernet priority service classes: high, mediumand low. The user can configure the global mapping of the VLAN tag userpriority field values to the D500 priority service classes (in other words the usercan decide which group the user priority field values belong to). The configuredmapping applies to the whole node (in other words. there is only one globalVLAN user priority mapping per node) and the new mapping settings take effectonly after the node has been rebooted.

By default the global mapping between the Ethernet VLAN tag user priority fieldvalues and the D500 Ethernet priority service classes is as shown in the followingtable:

Table 36. Global mapping of the VLAN user priority field values

Ethernet userpriority fieldvalues ofincoming frames

D500 internalservice class in thepass mode *)

Ethernet userpriority field valuesof outgoing framesin the map mode **)

4, 5, 6, or 7 High 5

2 or 3 Medium 3

0 or 1 Low 1

1 0 0 0 0 0 0 1

0 0 0 0 0 0 0 0

user p. CFI

VLAN identifier (VID)

Octet 1:

Octet 2:

Octet 3:

Octet 4:

length / type = 802.1Q tag type

Tag control information

VLAN tag (QTag):

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

193 (252)

QoS provisioning

Page 194: Dn03492199 4 en Global PDF Paper a4

*) In the pass mode the internal service class is determined directly from the userpriority field of the incoming frame. In the map mode the user can remap theinternal service class per subinterface.

**) In the pass mode the outgoing frame has the same user priority field value theincoming frame had. In the map mode the outgoing frame has the user priorityfield value determined by the global user priority of the internal service classmapping.

The queuing and scheduling of Ethernet CoS traffic is handled in the D500basically in the same way as IP DiffServ traffic. The same three queues (high/EF,medium/AF4 and low/DF) and the same schedulers are used in both cases. Thesequeues and schedulers depicted from the point of view of Ethernet CoS are shownin the following figure:

Figure 50. Queues and schedulers used for Ethernet 802.1p CoS traffic

As mentioned above, Ethernet CoS based on user priority bits can be used only inthe bridging mode. If Ethernet CoS is not enabled for a bridged subinterface,incoming packets are always forwarded to UBR/DF/Eth. low queues. By defaultthe Ethernet CoS is disabled.

802.1pHigh priority

Dynamicscheduler 2

Dynamicscheduler 1

Logicalport

Bandwidthreservedby CAC

Qos/CoSqueues

Queue levelshaping /rate limiting

Interface levelrate limiting &strict priorityscheduling

802.1pMedium priority

802.1pLow priority

194 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 195: Dn03492199 4 en Global PDF Paper a4

If Ethernet CoS is enabled, there are two options: pass mode and map mode. Inthe pass mode the user priority bits of the incoming packet are used directly toselect the internal Ethernet priority service class, which determines the policing,queue selection and scheduling behaviour. In the map mode the received Ethernetpriority service class can be remapped per subinterface to any of the three serviceclasses (high, medium or low) supported by the D500.

The D500 supports both pass and map modes in the upstream direction. In thedownstream direction only pass mode is supported.

Mapping can be applied also in cases where there is no VLAN tag included in thereceived Ethernet frame. This feature may be usefull for example when VLANtags are not used in the client side subinterface. (The D500 supports both Ethernetframes with VLAN tag and without VLAN tag in the client side.) In this case inthe upstream direction Ethernet CoS mapping can be done on a PVC basis: allframes received from a subinterface (PVC) are mapped to the preconfiguredpriority service class. This mapped service class is then used for selecting thepolicing and queuing behaviour, and the respective user priority field value isinserted into the VLAN tag in the trunk interface.

For more information on how different Ethernet classes of service are processedin the D500, refer to High priority Ethernet CoS, Medium priority Ethernet CoS,and Low priority Ethernet CoS.

6.3.1 High priority Ethernet CoS

The policing process (based on trTCM) tests the high priority traffic against thepeak information rate (PIR) and the peak burst size (PBS) defined in a packettraffic descriptor (PTD) for the policed subinterface. If the packet conforms to thePTD, it is forwarded to the VBRrt-EF-Eth. high queue, which is scheduled bydynamic scheduler 1, otherwise it is dropped.

The following table summarises how high priority traffic is processed in theD500:

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

195 (252)

QoS provisioning

Page 196: Dn03492199 4 en Global PDF Paper a4

Table 37. High priority traffic processed by the D500

Fillfactorof thequeue(%)

Packet forwarding Cell modification Ethernet userprioritymodification

Packet out

Bridged

Green Red CLP bit EFCI Mapmode

Passmode

0�50 Forward Drop High Same aspacket in

50�80 Drop 50%randomly

Drop High Same aspacket in

80�100 Drop 50%randomly

Drop Assign High Same aspacket in

100 Drop Drop

Note

Green: The packet conforms to PIR and PBS criteria.

Red: The packet violates PIR and PBS criteria.

6.3.2 Medium priority Ethernet CoS

The policing process (based on trTCM) tests the medium priority traffic againstthe peak information rate (PIR) and the peak burst size (PBS) as well as againstthe committed information rate (CIR) and the committed burst size (CBS) definedin a packet traffic descriptor (PTD). Conforming packets are forwarded to theVBR-nrt w/o tag-AF4-Eth. medium queue, which is scheduled by dynamicscheduler 2.

The following table summarises how medium priority traffic is processed in theD500:

196 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 197: Dn03492199 4 en Global PDF Paper a4

Table 38. Medium priority traffic processed by the D500

Fillfactorof thequeue(%)

Packet forwarding Cell modification Ethernet userprioritymodification

Packet out

Bridged

Green Yellow Red CLP bit EFCI Mapmode

Passmode

0�50 Forward Forward Drop Assign ifyellow

Medium Same aspacket in

50�80 Drop 50%randomly

Drop Drop Medium Same aspacket in

80�100 Drop 50%randomly

Drop Drop Assign Medium Same aspacket in

100 Drop Drop Drop

Note

Green: The packet conforms to CIR and CBS criteria.

Yellow: The packet violates CIR and CBS criteria, but conforms with PIR andPBS criteria.

Red: The packet violates PIR and PBS criteria.

6.3.3 Low priority Ethernet CoS

The policing process tests the low priority traffic against the peak information rate(PIR) and the peak burst size (PBS). The low priority traffic is forwarded to theUBR-DF-Eth. low queue, which is scheduled by the FIFO scheduler.

The following table summarises how low priority traffic is processed in the D500:

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

197 (252)

QoS provisioning

Page 198: Dn03492199 4 en Global PDF Paper a4

Table 39. Low priority traffic processed by the D500

Fillfactorof thequeue(%)

Packet forwarding Cell modification Ethernet userprioritymodification

Packet out

Bridged

Green Red CLP bit EFCI Mapmode

Passmode

0�50 Forward Forward Assign ifred

Low Same aspacket in

50�80 Drop 50%randomly

Drop Low Same aspacket in

80�100 Drop 50%randomly

Drop Assign Low Same aspacket in

100 Drop Drop

Note

Green: The packet conforms to PIR and PBS criteria.

Red: The packet violates PIR and PBS criteria.

Note

In routed and RBE modes, which do not support Ethernet user priorities, the userpriority bits in the VLAN tags are set to their default (= 000) values.

198 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 199: Dn03492199 4 en Global PDF Paper a4

6.4 QoS in ATM networks

The following describes how the D500 supports ATM quality of service (QoS).Rules that apply to ATM cell policing, queueing, dropping and modification arepresented separately for each ATM service class.

The following figure shows queues and schedulers used for ATM service classes:

Figure 51. Queues and schedulers used for ATM traffic

6.4.1 CBR

Constant bit rate (CBR) is used by connections that request a static amount ofbandwidth to be continuously available during the connection lifetime. Examplesare real-time video, audio, circuit emulation services, and audio-videodistribution such as TV, pay-per-view, and distant learning. CBR services provideconnectivity up to a peak cell rate with an upper bound of cell delay variationtolerance. The source may emit cells at or below the negotiated peak cell rate atany time for any duration and the QoS commitments still pertain.

UBR (= BE)

VBRnrtwith tag

VBRnrt w/o tag

VBRrt

CBR

FIFOscheduler

Dynamicscheduler 2

Dynamicscheduler 1

Logicalport

Bandwidthreservedby CAC

Qos/CoSqueues

Queue levelshaping/

rate limiting

Interface levelrate limiting &strict priorityscheduling

-WRR type scheduling-no shaping/rate limiting

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

199 (252)

QoS provisioning

Page 200: Dn03492199 4 en Global PDF Paper a4

The policing process (which is based on GCRA) tests the CBR traffic against thepeak cell rate (PCR) and the cell delay variation tolerance (CDVT) defined in anATM traffic descriptor (TD) for the policed connection/subinterface. If the cellconforms with the TD, it is queued to the CBR queue, which is scheduled bydynamic scheduler 1, otherwise it is dropped.

The following table summarises how CBR traffic (CBR.1) is processed in theD500:

Table 40. CBR traffic processed by the D500

Fill factor ofthe queue(%)

Cell forwarding Cell modification

Green Red CLP bit EFCI

0�50 Forward Drop

50�80 Drop 50 %randomly

Drop

80�100 Drop 50 %randomly

Drop Assign

100 Drop Drop

Note

Green: The cell (CLP=0+1) conforms to PCR and CDTV criteria.

Red: The cell (CLP=0+1) violates PCR and CDTV criteria.

6.4.2 VBR-rt

Variable bit rate real-time (VBR-rt) supports applications requiring variablebandwidth with tight bounds on delay. Cell traffic is generated in bursts. Traffic isguaranteed an average rate of bandwidth, although the amount varies dependingon the traffic requirements of the connection (peak cell rate, sustained cell rate,and maximum burst size). Examples are variable bit rate CODECs, aggregatedvoice with silence removal, video conferencing, and loop emulation services withAAL2.

200 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 201: Dn03492199 4 en Global PDF Paper a4

The policing process tests the VBR-rt traffic against the peak cell rate (PCR) andthe cell delay variation tolerance (CDVT) as well as against the sustained cell rate(SCR) and the maximum burst size (MBS) defined in an ATM traffic descriptor(TD). If the cell conforms to the SCR and the MBS parameters, it is queued to theVBR-rt, EF queue, which is scheduled by dynamic scheduler 1. If the cell doesnot conform to the PCR and CDVT parameters, it is always dropped. For othercases the cell processing depends on the model selected. The details of thesemodels are described below.

The D500 supports both CLP-transparent and CLP-significant models for VBRtraffic. In the CLP-transparent model, the CLP bit is ignored in the policingprocess, and the whole CLP=0+1 cell stream is processed. In the CLP-significantmodel only the CLP=0 cell stream is policed against the SCR and MBS criteria,while the CLP=1 cell stream is handled according to its own rules. In addition tothese two models, tagging (assertion of the CLP bit) may be enabled or disabledfor CLP-significant model connections.

The following tables summarise how the D500 processes VBR-rt traffic:

CLP-transparent model, tagging disabled (VBR.1)

Table 41. VBR.1

Fill factor ofthe queue(%)

Cell forwarding Cell modification

Green Yellow Red CLP bit EFCI

0�50 Forward Drop Drop

50�80 Drop 50 %randomly

Drop Drop

80�100 Drop 50 %randomly

Drop Drop Assign

100 Drop Drop Drop

Note

Green: The cell (CLP=0+1) conforms to SCR and MBS criteria.

Yellow: The cell (CLP=0+1) violates SCR and MBS criteria, but conforms toPCR and CDTV criteria.

Red: The cell (CLP=0+1) violates PCR and CDTV criteria.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

201 (252)

QoS provisioning

Page 202: Dn03492199 4 en Global PDF Paper a4

CLP-significant model, tagging disabled (VBR.2)

Table 42. VBR.2

Fill factorof thequeue(%)

Cell forwarding Cell modification

Green_CL-P0

Yel-low_CLP0

Green_Yel-low_CLP1 Red CLP bit EFCI

0�50 Forward Drop Forward Drop

50�80 Drop 50 %randomly

Drop Drop Drop

80�100 Drop 50 %randomly

Drop Drop Drop Assign

100 Drop Drop Drop Drop

Note

Green_CLP0: The cell with CLP=0 conforms to SCR and MBS criteria.

Yellow_CLP0: The cell with CLP=0 violates SCR and MBS criteria, butconforms to PCR and CDTV criteria.

Green-Yellow_CLP1: The cell with CLP=1 conforms to PCR and CDTV criteria.

Red: The cell (CLP=0+1) violates PCR and CDTV criteria.

CLP-significant model, tagging enabled (VBR.3)

Table 43. VBR.3

Fill factorof thequeue(%)

Cell forwarding Cell modification

Green_CL-P0

Yel-low_CLP0

Green_Yel-low_CLP1 Red CLP bit EFCI

0�50 Forward Drop Forward Drop Yel-low_CLP0:Assign

202 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 203: Dn03492199 4 en Global PDF Paper a4

Table 43. VBR.3 (cont.)

Fill factorof thequeue(%)

Cell forwarding Cell modification

Green_CL-P0

Yel-low_CLP0

Green_Yel-low_CLP1 Red CLP bit EFCI

50�80 Drop 50 %randomly

Drop Drop Drop

80�100 Drop 50 %randomly

Drop Drop Drop Assign

100 Drop Drop Drop Drop

Note

Green_CLP0: The cell with CLP=0 conforms to SCR and MBS criteria.

Yellow_CLP0: The cell with CLP=0 violates SCR and MBS criteria, butconforms to PCR and CDTV criteria.

Green-Yellow_CLP1: The cell with CLP=1 conforms to PCR and CDTV criteria.

Red: The cell (CLP=0+1) violates PCR and CDTV criteria.

6.4.3 VBR-nrt

Variable bit rate non-real-time (VBR-nrt) supports applications requiring variablebandwidth with less stringent bounds on delay (as in transaction processing).However, VBR-nrt does not provide delay guarantees. VBR-nrt is typically usedfor management and signalling applications.

The policing, dropping and tagging rules for VBR-nrt service category areexactly the same as used for the VBR-rt category. Thus, both CLP-transparentand CLP-significant models are supported. The CLP-significant model has bothtagging enabled and tagging disabled options.

The queuing function differs from the VBR-rt case. If tagging is disabled, all thecells are forwarded to the VBRnrt w/o tag-AF4 queue, which is serviced bydynamic scheduler 2. If tagging is enabled, cells are forwarded to the VBRnrtwith tag queue, which is scheduled by using the FIFO scheduler.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

203 (252)

QoS provisioning

Page 204: Dn03492199 4 en Global PDF Paper a4

6.4.4 UBR

Unspecified bit rate (UBR) is intended for applications that do not require a fixedbandwidth or fixed interval of transmission, and are highly tolerant of delay andloss. Examples are file transfer, e-mail, and LANs. There is no explicitcommitment from the network provider regarding capacity or throughput in theUBR class. The network transmits cells based on available bandwidth withoutdelay or throughput guarantees.

The policing process tests the UBR traffic against the peak cell rate (PCR) and thecell delay variation tolerance (CDVT). The UBR traffic is forwarded to the UBR-DF queue, which is scheduled by the FIFO scheduler. The UBR service classsupports both tagging enabled and tagging disabled options.

The following tables summarise how the D500 processes UBR traffic.

UBR with tagging disabled (UBR.1)

Table 44. UBR.1

Fill factor ofthe queue(%)

Cell forwarding Cell modification

Green_CL-P0

Green_CL-P1 Red CLP bit EFCI

0�50 Forward Forward Drop

50�80 Drop 50 %randomly

Drop Drop

80�100 Drop 50 %randomly

Drop Drop Assign

100 Drop Drop Drop

Note

Green_CLP0: The cell with CLP=0 conforms to PCR and CDTV criteria.

Green_CLP1: The cell with CLP=1 conforms to PCR and CDTV criteria.

Red: The cell (CLP=0+1) violates PCR and CDTV criteria.

204 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 205: Dn03492199 4 en Global PDF Paper a4

UBR with tagging eanbled (UBR.2)

Table 45. UBR.2

Fill factor ofthe queue(%)

Cell forwarding Cell modification

Green_CL-P0

Green_CL-P1 Red CLP bit EFCI

0�50 Forward Forward Forward Red: Assign

50�80 Drop 50 %randomly

Drop Drop

80�100 Drop 50 %randomly

Drop Drop Assign

100 Drop Drop Drop

Note

Green_CLP0: The cell with CLP=0 conforms to PCR and CDTV criteria.

Green_CLP1: The cell with CLP=1 conforms to PCR and CDTV criteria.

Red: The cell (CLP=0+1) violates PCR and CDTV criteria.

Note

When early packet Ddiscard (EPD) is enabled for an ATM connection, policing isexecuted in a PDU-based mode. In this case:

. Only CLP-transparent model is supported

. Tagging (if used) is applied to all the cells of a PDU

. Granularity rates for policing are the same as in the packet mode.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

205 (252)

QoS provisioning

Page 206: Dn03492199 4 en Global PDF Paper a4

6.5 Traffic descriptors

The D500 supports two types of traffic descriptors: ATM traffic descriptors (TDs)and packet traffic descriptors (PTDs). ATM switched connections support onlyATM traffic descriptors defining ATM QoS service categories CBR, VBR-rt,VBR-nrt, UBR and their parameters.

Packet-based services may be used both with Ethernet interfaces and ATM-basedinterfaces (for example SDH or xDSL ports). Ethernet subinterfaces always usepacket traffic descriptors. Depending on the subinterface type, Ethernet CoS,DiffServ CoS, or no-CoS alternatives can be selected as shown in QoS/CoShierachy used in the D500.

For ATM subinterfaces operating in a packet-based mode (packets transferredover ATM), packet traffic descriptors are typically preferred. However, if sowished, ATM traffic descriptors are also available in packet-based mode (in casethere is a need to use Ethernet trunks of Release 2).

206 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 207: Dn03492199 4 en Global PDF Paper a4

Figure 52. QoS/CoS hierarchy used in the D500

For native ATM switched connections a single traffic descriptor per direction isadequate to specify the policing, queueing and scheduling/shaping behaviour,while ATM connections always go end-to-end (for example all the way fromclient side to trunk side).

QoS / CoSprovisioning

ATM switchedservices

Packet-basedservices

DiffServCoS

Passmode

Mapmode

CBRCBR

RT-VBR RT-VBR

NRT-VBR NRT-VBR

UBR UBR

EF->EF

AFx->AFx

DF->DF

Non-DiffServNo CoS

DF

NativeATM

connections

Packet-basedservices, ATMinterfaces

Bridgedwithout

CoS or IPwithoutDiffServ

IP with DiffServ

ATMQoS ATMQoSEthernetCoS

Mapmode

Passmode

DSCP in-> EF

DSCP in-> AF4

DSCP in-> DF

user p.in->user p.out

user p.in->user p.out

user p.in->user p.out

user p.in->high prior.

user p.in->medium p.

user p.in->low prior.

Ethernet withuser priorities

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

207 (252)

QoS provisioning

Page 208: Dn03492199 4 en Global PDF Paper a4

For packet-based services, the subinterfaces (PVCs, VLANs or PVC-VLANpairs) are always terminated in the D500. That is why both client and trunk sidesmust have their own traffic descriptors and separately for both directions. Theinput traffic descriptor (inPTD) of a subinterface is used to specify the policingbehaviour and the queue selection. The output traffic descriptor (outPTD) isneeded to specify parameters for scheduling/shaping (CAC uses these parametersto calculate the scheduling/shaping rates for the QoS/CoS queues).

Traffic descriptors are used to specify the traffic parameters for different services(for example PIR, PBS, CIR, and CBS for packet-based services; PCR, CDVT,SCR, and MBS for ATM connections). In addition to traffic descriptors, PTDpolicies may need to be defined for packet based services. These PTD policies areused to define how DiffServ or Ethernet priorities are remapped in the Map mode.

6.5.1 Packet traffic descriptors and PTD policies

PIR, PBS, CIR, CBS are the traffic parameters that can be used to measure theinformation rate and the burstiness of traffic for packet-based services. The trafficparameters defined in the input PTD are used in policing process to determinewhether the incoming traffic is in conformance with the agreed traffic contract.The traffic parameters of the output PTD are needed to specify the scheduling/shaping rates for the subinterface�s output traffic.

Based on these traffic parameters, three basic packet traffic descriptor types canbe defined for different sevice types. The same three basic service types can beapplied to both IP DiffServ traffic and Ethernet VLAN priority (802.1p) traffic. Inthe D500 the IP DiffServ CoS is supported in the routed and RBE modes,whereas Ethernet 802.1p CoS can be used in the bridged mode. The three basicpacket traffic descriptor types are described in the following table:

Table 46. PTD types

Service type DiffServserviceclasscategory

Ethernet802.1pserviceclasscategory

Trafficparameters

Description

Delaysensitive,assuredbandwidthservice

EF Highpriority

PIR in kbit/s

PBS in bytes

Traffic conformance is basedon the PIR and PBSparameters. Non-conformingpackets are discarded.

Non-delaysensitive,

AFx Mediumpriority

PIR in kbit/s

PBS in bytes

Traffic conformance is basedon the PIR, PBS, CIR, and

208 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 209: Dn03492199 4 en Global PDF Paper a4

Table 46. PTD types (cont.)

Service type DiffServserviceclasscategory

Ethernet802.1pserviceclasscategory

Trafficparameters

Description

assuredbandwidthservice

CIR in kbit/s

CBS in bytes

CBS parameters. Packetsviolating PIR and PBS arediscarded. Packets violatingCIR and CBS may be markedand are discarded first in casethere is congestion.

Best effortservice

DF Low priority PIR in kbit/s

PBS in bytes

Traffic conformance is basedon the PIR and PBSparameters. Non-conformingpackets may be marked andare discarded first in casethere is congestion.

Additionally, the user may need to define in the PTD policies whether asubinterface is required to function in a pass or map mode and which PTDs areused in the selected mode.

The following example shows a client side configuration for a case where a clientside bridged subinterface (for example in an ADSL port) is using VLAN tags,and the user priority bits defined in the VLAN tags are used to select the CoSapplied for the traffic in the D500:

1. Packet traffic descriptors are first defined separately for both directions andfor all three service classes:

CONFIGURE PTD NEW ADSL1_RXPTD_HIGH EF <PIR> <PBS>

CONFIGURE PTD NEW ADSL1_RXPTD_MEDIUM AF4 <PIR> <PBS><CIR> <CBS>

CONFIGURE PTD NEW ADSL1_RXPTD_LOW DF <PIR> <PBS>

CONFIGURE PTD NEW ADSL1_TXPTD_HIGH EF <PIR> <PBS>

CONFIGURE PTD NEW ADSL1_TXPTD_MEDIUM AF4 <PIR> <PBS><CIR> <CBS>

CONFIGURE PTD NEW ADSL1_TXPTD_LOW DF <PIR> <PBS>

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

209 (252)

QoS provisioning

Page 210: Dn03492199 4 en Global PDF Paper a4

(In case of VLAN priority PTDs: EF=HIGH, AF4=MEDIUM, andDF=LOW)

In Web-based Craft Terminal, the New PTD Dialog dialogue box is foundby selecting Node Views and clicking the node icon => Descriptors tab=> PTD tab => Configure menu => New PTD Dialog command.

Figure 53. New PTD Dialog

2. Next a PTD policy is defined, in this example for the pass mode:

CONFIGURE PTD POLICY NEW POLICY1 PASSADSL1_RXPTD_HIGH ADSL1_RXPTD_MEDIUMADSL1_RXPTD_LOW TX ADSL1_TXPTD_HIGHADSL1_TXPTD_MEDIUM ADSL1_TXPTD_LOW

In Web-based Craft Terminal, the New PTD Policy dialogue box is foundby selecting Node Views and clicking the node icon => Descriptors tab=> PTD Policies tab => Configure menu => New PTD Policy command.

210 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 211: Dn03492199 4 en Global PDF Paper a4

Figure 54. New PTD Policy

3. Finally the new subinterface can be created. The subinterface refers to thecreated PTD policy:

CONFIGURE SUBINTERFACE CLIENT NEW 4/1 C1 BRIDGED

PVC 0 100 VCMUX

VLAN 10

BRIDGED_SUBIF 11/1 T1

PRIORITY VLAN

PTD POLICY1

DONE

In Web-based Craft Terminal, the New Client Sub Interface Profiledialogue box is found by selecting Node Views and clicking the node icon=> Profiles tab => Client Sub Interface Profiles tab => Configure menu=> New Client Sub Interface Profile command.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

211 (252)

QoS provisioning

Page 212: Dn03492199 4 en Global PDF Paper a4

Figure 55. New Client Sub Interface Profile

6.5.2 ATM traffic descriptors

PCR, SCR, MBS and CDVT are traffic parameters that measure the inter-cellarrival time for resource allocation. Based on these traffic parameters, six basic,pre-defined traffic descriptor types corresponding to seven traffic contracts areavailable for different categories of service.

Table 47. Traffic descriptor types (templates)

QoScategory

Trafficdescriptortype

Traffic parameters Description

CBR ClpTransparentNoScr (CBR.1)

Parameter 1 PCR in cells/secondfor CLP*) = 0 + 1traffic

Traffic conformanceis based on theCLP-transparentmodel with no SCR.In a CLP-transparent model,the networkdisregards the CLP

Parameter 2 CDVT in tenths ofmicroseconds

212 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 213: Dn03492199 4 en Global PDF Paper a4

Table 47. Traffic descriptor types (templates) (cont.)

QoScategory

Trafficdescriptortype

Traffic parameters Description

Parameters 3, 4 and5

Not used

VBR ClpTransparentScr (VBR.1)

Parameter 1 PCR in cells/secondfor CLP=0+1.

bit

Parameter 2

CDVT in tenths ofmicroseconds

Parameters 3, 4 and5

Not used

VBR ClpTransparent Scr(VBR.1)

Parameter 1

PCR in cells/secondfor CLP=0+1.

Trafficconfor-mance isbased onthe CLP-transparentmodel withSCR. In aCLP-transparentmodel, thenetworkdisregardsthe CLP bit.

Parameter 2 SCR CLP=0+1.

Parameter 3 MBS in cells

Parameter 4 CDVT in tenths ofmicroseconds

Parameter 5 Not used

VBR ClpNoTaggingScrCdvt (VBR.2)

Parameter 1 PCR in cells/secondfor CLP=0+1.

Traffic conformanceis based on CLPwith SCR withouttaggingParameter 2 SCR in cells/second

for CLP=0 traffic

Parameter 3 MBS in cells

Parameter 4 CDVT in tenths ofmicroseconds

Parameter 5 Not used

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

213 (252)

QoS provisioning

Page 214: Dn03492199 4 en Global PDF Paper a4

Table 47. Traffic descriptor types (templates) (cont.)

QoScategory

Trafficdescriptortype

Traffic parameters Description

VBR ClpTaggingScrCdvt (VBR.3)

Parameter 1 PCR in cells/secondfor CLP=0+1

Traffic conformanceis based on CLPwith SCR andtaggingParameter 2 SCR in cells/second

for CLP=0 traffic,excess tagged**) asCLP=1

Parameter 3 MBS in cells

Parameter 4 CDVT in tenth ofmicroseconds

Parameter 5 Not used.

UBR NoClpNoScrCdvt(UBR.1)

Parameter 1 PCR in cells/secondfor CLP=0+1

Traffic conformanceis based on no CLPand no SCR

Parameter 2 CDVT in tenths ofmicroseconds

Parameters 3, 4 and5

Not used

UBR NoClpTagging-NoScr (UBR.2)

Parameter 1 PCR in cells/secondfor CLP=0+1

Traffic conformanceis based on CLPwith tagging and noSCRParameter 2 CDVT in tenths of

microseconds

Parameters 3,4 and5

Not used

*) CLP=0 cells are a higher priority than CLP=1 cells. Lower priority (CLP=1)cells can be discarded under a congestion situation. CLP=0+1 refers to anaggregate cell stream.

**) Tagging is a process of setting the CLP bit of cells entering an ATM networkto 1 because they do not conform to the subscribed traffic descriptor. Thesemarked cells can be dropped based on the network congestion.

214 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 215: Dn03492199 4 en Global PDF Paper a4

6.5.2.1 Traffic profiles/traffic descriptors

The traffic descriptor types listed in the previous table � Traffic descriptor types(templates) � function as templates. Based on these templates, traffic profiles(known as traffic descriptors in the GUI) can be created when the user requires adifferent set of characteristics other than those pre-defined.

Creating traffic profiles/traffic descriptors

Traffic profiles/traffic descriptors can be created by assigning specific parametervalues to an ATM connection in Craft Terminal and the command line interface(CLI). Each profile is assigned an index number by the system for identificationpurposes. The indices of 1 to 32 are reserved by the system; indices from 1 to 12are pre-defined (see the following table).

Note

The New Traffic Descriptor dialog box in Craft Terminal enables users to createtraffic profiles/traffic descriptors. For details, see Web-based Craft Terminal.

The twelve default traffic profiles/traffic descriptors are available in the followingtable:

Table 48. Pre-defined traffic profiles/traffic descriptors

Index Servicecategory

TrDtype

Performance parameters Congestion controlfeatures

PCR CD-VT

SCR MBS MCR Tagging Framediscard

1 CBR CBR.1 X X X

2 VBR-rt VBR.1 X X X X

3 VBR-rt VBR.1 X X X X X

4 VBR-nrt VBR.2 X X X X

5 VBR-nrt VBR.3 X X X X X

6 VBR-nrt VBR.3 X X X X X X

7 VBR-nrt VBR.1 X X X X X

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

215 (252)

QoS provisioning

Page 216: Dn03492199 4 en Global PDF Paper a4

Table 48. Pre-defined traffic profiles/traffic descriptors (cont.)

Index Servicecategory

TrDtype

Performance parameters Congestion controlfeatures

PCR CD-VT

SCR MBS MCR Tagging Framediscard

8 UBR UBR.1 X X

9 UBR UBR.1 X X X

10 UBR UBR.2 X X

11 VBR.nrt VBR.1 X X X X X

The user can also choose an index number for the traffic descriptor (refer to thefollowing figure). It is easier to create connections to the D500 nodes in a samenetwork when the user can make sure that all the nodes have the same trafficdescriptor numbering.

In creating or editing the traffic descriptor it is possible to name it according tothe use (for instance, home user gold/silver/bronze, SOHO, corporate or VDSLuser). The description is entered in the Name field, see the following figure.

Figure 56. New traffic descriptor with a chosen ID number

Rules for traffic profiles/traffic descriptors

The following rules apply:

216 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 217: Dn03492199 4 en Global PDF Paper a4

. A traffic profile/traffic descriptor must exist before a connection can becreated.

. A traffic profile/traffic descriptor cannot be deleted unless all theassociated connections are deleted.

. Traffic descriptors with index 1 to 32, such as the twelve default trafficprofiles/descriptors, cannot be modified or deleted.

. A traffic profile/traffic descriptor cannot be modified, once created.

. An existing connection can be moved from one traffic profile/trafficdescriptor to the other by first deleting the connection and then re-creatingit and associating it with the desired traffic profile/traffic descriptor.

. The two directions of a connection can be mapped either to differentdescriptors or a single traffic descriptor. If different traffic descriptors areused, they must have the same traffic type (for example CBR) but differentspeeds can be used.

6.5.3 Port QoS features

The following features should be noted when creating multicast clients:

. Input & output bandwidth (called CAC before) setting and PTDs

. Port output statistics (in the context of the network processor of the Release3 trunk/control unit) including queue passed & discarded PDUs, andcurrent buffer occupancy

You can utilise this in trying to find suitable buffer sizes; in other words, ifdiscards occur, increase the buffer.

The following is an example of a multicast client configuration including the newCLI commands:

conf ptd new ef_rx EF 200 100

conf ptd new af_rx AF4 200 200 150 200

conf ptd new df_rx DF 200 200

conf ptd new ef_tx EF 1000 500

conf ptd new af_tx AF4 1000 500 1000 500

conf ptd new df_tx DF 500 500

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

217 (252)

QoS provisioning

Page 218: Dn03492199 4 en Global PDF Paper a4

conf ptd policy new client_policy pass ef_rx af_rx df_rx TXef_tx af_tx df_tx

conf ptd new video_ef EF 4000 1000

conf dsl 1/1 rate lport 6875

conf port 1/1 bandwidth 6875 900

conf sub client new 1/1 c1 rbe pvc 0 38 llc ip 151.1.1.1255.255.255.0 ptd client_policy

multicast video_ef 3 done

top

show port 1/1 buffer

show port 1/1 actuals

show port 1/1 actuals reset

218 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 219: Dn03492199 4 en Global PDF Paper a4

7 Provisioning concepts and parameters

7.1 Provisioning parameters

This section provides provisioning parameters for the D500 line cards at the portlevel. The provisioning tables list parameter data by tabs within individual dialogboxes as they appear in Craft Terminal.

7.1.1 DSL provisioning parameters

Table 49. Status tab

Provisionableparameter

ADSL

Default values

VDSL

Default values

SHDSL

Default values

Administration State Locked Locked Locked

Managed Interface Unmanaged Unmanaged Unmanaged

Table 50. Test tab

Provisionableparameter

ADSL

Default values

VDSL

Default values

SHDSL

Default values

Test Mode None None None

Test Duration(s) 28800 28800 28800

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

219 (252)

Provisioning concepts and parameters

Page 220: Dn03492199 4 en Global PDF Paper a4

Table 51. Rates tab

Provisionableparameter

ADSL

Default values

VDSL

Default values

SHDSL

Default values

Data Rate Type Interleave Rate Interleave Rate N/A

Interleave Rate, Max

(ATUC, VTU-O)

8128 kbit/s

The maximum rate forADSL48aft and ADSL48artline cards is 10816 kbit/s.

The maximum rate for ADSL2+af and ADSL2+bf cards is32,736 Mbit/s.

Ranges: 32 to 8128 kbit/s, 32�10816, and 32 kbit/s�32,736 Mbit/s

997_2B: 10048 kbit/s

997_3B: 25024 kbit/s

998_2B: 22016 kbit/s

998_3B: 45056 kbit/s

(Range depends on theband plan)

N/A

Interleave Rate, Min

(ATUC, VTU-O)

32 kbit/s

Ranges: 32 to 8128 kbit/s, 32�10816, and 32 kbit/s�32,736 Mbit/s

64 kbit/s

(Range depends on theband plan)

N/A

Interleave Rate, Max

(ATUR, VTU-R)

1024 kbit/s

ADSL2+: 1088 kbit/s

Ranges: 32�1024 kbit/s and32�1088 kbit/s

997_2B: 10048 kbit/s

997_3B: 25024 kbit/s

998_2B: 3008 kbit/s

998_3B: 10048 kbit/s

(Range depends on theband plan)

N/A

Interleave Rate, Min

(ATUR, VTU-R)

32 kbit/s

Ranges: 32�1024 kbit/s and32�1088 kbit/s

64 kbit/s

(Range depends on theband plan)

N/A

Interleave Delay

(ATUC, VTU-O)

32 ms

(Setting Options: 1, 2, 4, 8,16, 32, 64)

16 ms

(Setting Options: 0, 1,2, 4, 8, 16, 32, 64)

N/A

Interleave Delay

(ATUR)

16 ms

(Setting Options: 1, 2, 4, 8,16, 32, 64)

N/A N/A

Fast Rate, Max

(ATUC, VTU-O)

0 kbit/s

The maximum rate forADSL48aft and ADSL48art

997_2B: 10048 kbit/s

997_3B: 25024 kbit/s

N/A

220 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 221: Dn03492199 4 en Global PDF Paper a4

Table 51. Rates tab (cont.)

Provisionableparameter

ADSL

Default values

VDSL

Default values

SHDSL

Default values

line cards is 10816 kbit/s.

The maximum rate for ADSL2+af and ADSL2+bf cards is32,736 Mbit/s.

Ranges: 32 to 8128 kbit/s, 32�10816, and 32 kbit/s�32,736 Mbit/s

998_2B: 22016 kbit/s

998_3B: 45056 kbit/s

(Range depends on theband plan)

Fast Rate, Min

(ATUC, VTU-O)

0 kbit/s

Ranges: 32 to 8128 kbit/s, 32�10816, and 32 kbit/s�32,736 Mbit/s

64 kbit/s

(Range depends on theband plan)

N/A

Fast Rate, Max

(ATUR, VTU-R)

1024 kbit/s

ADSL2+: 1088 kbit/s

Ranges: 32�1024 kbit/s and32�1088 kbit/s

997_2B: 10048 kbit/s

997_3B: 25024 kbit/s

998_2B: 3008 kbit/s

998_3B: 10048 kbit/s

(Range depends on theband plan)

N/A

Fast Rate, Min

(ATUR, VTU-R)

32 kbit/s

Ranges: 32�1024 kbit/s and32�1088 kbit/s

64 kbit/s

(Range depends on theband plan)

N/A

Data Rates, Max

(STUC)

N/A N/A 2304

(Range 144 to 2304)

Data Rates, Min

(STUC)

N/A N/A 1152

(Range 144 to 2304)

RADSL Mode

(ATUC, VTU-O, or STUC)

Startup Startup Startup

Error Retrain Near

(ATUC, VTU-O, STUC)

10

(Range 0�60) (Unit = Errors/Sec)

10

(Range 0�60) (Unit =Errors/Sec)

10

(Range 0�60) (Unit= Errors/Sec)

Error Retrain Far

(STUC, VTUO, STUC)

10

(Range 0�60) (Unit = Errors/Sec)

10

(Range 0�60) (Unit =Errors/Sec)

10

(Range 0�60) (Unit= Errors/Sec)

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

221 (252)

Provisioning concepts and parameters

Page 222: Dn03492199 4 en Global PDF Paper a4

Table 51. Rates tab (cont.)

Provisionableparameter

ADSL

Default values

VDSL

Default values

SHDSL

Default values

Error Alarm, Near

(ATUC, VTU-O, STUC)

0

(Range 0�65535) (Unit =Errors/Sec)

0

(Range 0�65535)(Unit = Errors/Sec)

0

(Range 0�65535)(Unit = Errors/Sec)

Error Alarm, Far

(ATUC, VTU-O, STUC)

0

(Range 0�65535) (Unit =Errors/Sec)

0

(Range 0�65535)(Unit = Errors/Sec)

0

(Range 0�65535)(Unit = Errors/Sec)

Rate Degraded

(ATUC, VTU-O,STUC)

0 kbit/s

The maximum rate forADSL48aft and ADSL48artline cards is 10816 kbit/s.

The maximum rate for ADSL2+af and ADSL2+bf cards is32,736 Mbit/s.

Ranges: 32 to 8128 kbit/s, 32�10816, and 32 kbit/s�32,736 Mbit/s

0 kbit/s

(Range depends on theband plan)

0 kbit/s

(Range 144 to 2304)

Rate Degraded

(ATUR, VTU-R)

0 kbit/s

The maximum rate for ADSL2+ is 1088 kbit/s

Ranges: 32�1024 kbit/s and32�1088 kbit/s

0 kbit/s

(Range depends on theband plan)

N/A

RFI Bands N/A None N/A

Start Tone N/A 138 kHz

(Setting Options: 25,138, 1104)

N/A

Pair Bonding N/A N/A Unbonded

Table 52. DSL Thresholds tab

Provisionableparameter

ADSL

Default Values

VDSL

Default Values

SHDSL

Default Values

LOF Seconds 15 min. 0 0 0

222 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 223: Dn03492199 4 en Global PDF Paper a4

Table 52. DSL Thresholds tab (cont.)

Provisionableparameter

ADSL

Default Values

VDSL

Default Values

SHDSL

Default Values

(ATUC) (Range 1�900) (Range 1�900) (Range 1�900)

LOS Seconds 15 min.

(ATUC)

0

(Range 1�900)

0

(Range 1�900)

0

(Range 1�900)

LCD Seconds 15 min.

(ATUC, VTU-O, STUC)

0

(Range 1�900)

0

(Range 1�900)

0

(Range 1�900)

LOF Retrains 15 min.

(ATUC, VTU-O, STUC)

0 0 0

Error Rate Retrains 15min.

(ATUC, VTU-O, STUC)

0 0 0

FE Error Rate Retrains15 min.

(ATUC, VTU-O, STUC)

0 0 0

LPR Seconds 15 min.

(ATUC, VTU-O, STUC)

0

(Range 1�900)

N/A N/A

LOF Seconds Daily

(ATUC, VTU-O, STUC)

0

(Range 1�86400)

0

(Range 1�86400)

0

(Range 1�86400)

LOS Seconds Daily

(ATUC, VTU-O, STUC)

0

(Range 1�86400)

0

(Range 1�86400)

0

(Range 1�86400)

LCD Seconds Daily

(ATUC, VTU-O, STUC)

0

(Range 1�86400)

0

(Range 1�86400)

0

(Range 1�86400)

LOF Retrains Daily

(ATUC, VTU-O, STUC)

0

(Range 0�65535)

0

(Range 0�65535)

0

(Range 0�65535)

Error Rate Retrains Daily

(ATUC, VTU-O, STUC)

0

(Range 0�65535)

0

(Range 0�65535)

0

(Range 0�65535)

FE Error Rate RetrainsDaily

(ATUC, VTU-O, STUC)

0

(Range 0�65535)

0

(Range 0�65535)

0

(Range 0�65535)

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

223 (252)

Provisioning concepts and parameters

Page 224: Dn03492199 4 en Global PDF Paper a4

Table 52. DSL Thresholds tab (cont.)

Provisionableparameter

ADSL

Default Values

VDSL

Default Values

SHDSL

Default Values

LPR Seconds Daily

(ATUC, VTU-O, STUC)

0

(Range 1�86400)

N/A N/A

Coding Violations Near,15 min.

0 0 0

Errored Seconds Near,15 min.

0

(Range 1�900)

0

(Range 1�900)

0

(Range 1�900)

Coding Violations Near,Daily

0 0 0

Errored Seconds, Near,Daily

0

(Range 1�86400)

0

(Range 1�86400)

0

(Range 1�86400)

Coding Violations Far, 15min.

0 0 0

Errored Seconds Far, 15min.

0

(Range 1�900)

0

(Range 1�900)

0

(Range 1�900)

Coding Violations Far,Daily

0 0 0

Errored Seconds Far,Daily

0

(Range 1�86400)

0

(Range 1�86400)

0

(Range 1�86400)

Table 53. DMT tab

Provisionableparameter

ADSL

Default Values

VDSL

Default Values

SHDSL

Default Values

Advanced ConfigurationMode

(ATUC)

Auto Auto Refer to the SHDSLtab

Automatic Coding Gain Enabled N/A N/A

Set Gain 0 dB N/A N/A

224 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 225: Dn03492199 4 en Global PDF Paper a4

Table 53. DMT tab (cont.)

Provisionableparameter

ADSL

Default Values

VDSL

Default Values

SHDSL

Default Values

Trellis CodingModulation

Enabled N/A N/A

RS Correction Enabled N/A N/A

ATUC Time 2 ms

Setting Options: 125, 250, 500µs, and 1, 2, 4 ms

N/A N/A

ATUR Time 1 ms

Setting Options: 125, 250, 500µs, and 1, 2, 4 ms

N/A N/A

BitSwap Enabled N/A N/A

Operation Mode

(ATUC, VTU-O)

Auto Auto Refer to the SHDSLtab

Target Noise Margin

(ATUC, VTU-O)

6 dB

(Range 0�16 dB)

6 dB (Range 0�32dB)

N/A

Target Noise Margin

(ATUR)

6 dB

(Range 0�16 dB)

N/A N/A

Minimum Noise Margin N/A 1

(Range 0�32 dB)

N/A

Maximum Noise Margin N/A 28

(Range 0�32 dB)

N/A

Transmit PowerReduction

(ATUC)

0 dB N/A N/A

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

225 (252)

Provisioning concepts and parameters

Page 226: Dn03492199 4 en Global PDF Paper a4

Table 54. SHDSL tab

Provisionableparameter

SHDSL24

Default Values

Advanced ConfigurationMode

Auto

ACP1 (STUC) 0

ACP2 (STUC) 0

Power BackOff Enabled

STUC Operation Mode D500-21: Annex A

D500-17: Annex B

7.1.2 QoS queue provisioning parameters

Table 55. Queue Manager tab

Provisionableparameter

ADSL

Default Values

VDSL

Default Values

SHDSL

Default Values

Priority Low

Options:. Low. Medium. High

Low

Options:. Low. Medium. High

Low

Options:. Low. Medium. High

EPD/PPD Enabled Enabled Enabled

EFCI Enabled Enabled Enabled

PPD 95% 95% 95%

EPD Onset 75% 75% 75%

EPD Abate 65% 65% 65%

EFCI 65% 65% 65%

Starvation Cycles 0 0 0

226 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 227: Dn03492199 4 en Global PDF Paper a4

Table 55. Queue Manager tab (cont.)

Provisionableparameter

ADSL

Default Values

VDSL

Default Values

SHDSL

Default Values

Queue Size Low = 693 cells

Medium = 298 cells

High = 32 cells

Low = 693 cells

Medium = 298 cells

High = 32 cells

Low = 693 cells

Medium = 298 cells

High = 32 cells

Table 56. Queue PM tab

Provisionableparameter

ADSL

Default Values

VDSL

Default Values

SHDSL

Default Values

Priority Low

Options:. Low. Medium. High

Low

Options:. Low. Medium. High

Low

Options:. Low. Medium. High

CongestionMeasurement

Disabled Disabled Disabled

Weight Factor 0.300

(Range .001 to 1.000)

0.300

(Range .001 to1.000)

0.300

(Range .001 to 1.000)

Severe Level (%) 90% 90% 90%

Abate Level (%) 70% 70% 70%

Intermed Level (%) 40% 40% 40%

Active Report (secs) 30 seconds 30 seconds 30 seconds

Clear Report (secs) 30 seconds 30 seconds 30 seconds

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

227 (252)

Provisioning concepts and parameters

Page 228: Dn03492199 4 en Global PDF Paper a4

7.1.3 OC-3/STM-1 provisioning parameters

Table 57. OC-3/STM-1 provisioning parameters

Parameter Values Default

Node Configuration tab page

Timing Option . Line (Port 1/Unit 1�5 (with theEthernet trunk)

. Line (Port 1/Unit 11 (OC-3/STM-1trunk)

. Internal

. Line for OC-3/STM-1 trunk

. Internal for Ethernet trunk

Unit Configuration tab page

Facility Type . SONET. SDH

Depends on subrack type:. SONET for the 21-slot subrack. SDH for the 17-slot subrack.

Timing Mode . Node clock. Loop Portn (tributary unit)

Node clock

OC-3 tab page

Path RDI: Loss of CellDelineation

. Enabled

. Disabled

Disabled

Path RDI: Payload LabelMismatch

. Enabled

. Disabled

Disabled

Path RDI: Trace IdentifierMismatch

. Enabled

. Disabled

Disabled

S1 Sync Status �Transmit

1 to 15 bits 15 (Trunk) *

*) With the OC-3/STM-1 and Ethernet trunk unit the default transmitted timingmarker value for the STM-1/OC-3 tributary interfaces is 11 in the 17-slot subrackand 12 in the 21-slot subrack. However, if the tributary unit is installed in section1 (slots 1-5) in the subrack that has an Ethernet trunk, the transmitted timingmarker value for port 1 of the tributary unit is 15.

228 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 229: Dn03492199 4 en Global PDF Paper a4

Table 58. OC-3/STM-1 provisioning parameters - OC3 Thresholds tab

Parameter Daily Interval Values 15 Minute Interval Values

Line or MS

Line Coding Violations Range 0�1048575

Default = 0 (inactive)

Range 0�16383

Default = 0 (inactive)

Line Errored Seconds Range 0�65535

Default = 0 (inactive)

Range 0�900

Default = 0 (inactive)

Line Severely ErroredSeconds

Range 0�65535

Default = 0 (inactive)

Range 0�900

Default = 0 (inactive)

Line Unavailable Seconds Range 0�65535 Default = 0(inactive)

Range 0�900

Default = 0 (inactive)

Path or HP

Path Coding Violations Range 0�1048575

Default = 250

Range 0�16383

Default = 25

Path Errored Seconds Range 0�65535

Default = 200

Range 0�900

Default = 20

Path Severely ErroredSeconds

Range 0�65535

Default = 7

Range 0�900

Default = 3

Path UnavailableSeconds

Range 0�65535

Default = 10

Range 0�900

Default = 10

Section or RS

Severely Errored FramingSeconds

Range 0�65535

Default = 0 (inactive)

Range 0�900

Default = 0 (inactive)

BERT Values Default

BERT Signal DegradeCondition

6�9 6

BERT Signal FailCondition

3�6 3

(Applicable to the trunk unit only)

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

229 (252)

Provisioning concepts and parameters

Page 230: Dn03492199 4 en Global PDF Paper a4

7.1.4 DS3 provisioning parameters

Table 59. DS3 tab page

Group Parameters Default

Parameters . Cell Scrambling. HEC Coset

Both enabled

Line Type . Cbit Parity. PLCP Cbit Parity. M23. PLCP M23

PLCP Cbit Parity

Receive Equalization . Low. Default (Longer cables)

Default

Clock Source . Node clock. Loop timing

Node colck

Table 60. DS3 Thresholds (Intervals)

Line/Path/PLCP

Acronym Daily interval 15-minute Interval

Line (NE)

CV-L Range: 6�10

Default: 9

Range: 6�10

Default: 9

ES-L Range: 0�86400

Default: 250

Range: 0�900

Default: 25

SES-L Range: 0�86400

Default: 0

0�900

Default: 0

UAS-L Range: 0�86400

Default: 0

0�900

Default: 0

Path (NE/FE)

CV-P Range: 6�10

Default: 9

Range: 6�10

Default: 9

ES-P Range: 0� Range: 0�900

230 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 231: Dn03492199 4 en Global PDF Paper a4

Table 60. DS3 Thresholds (Intervals) (cont.)

Line/Path/PLCP

Acronym Daily interval 15-minute Interval

86400

Default: 250

Default: 25

SES-P Range: 0�86400

Default: 40

Range: 0�900

Default: 4

UAS-P Range: 0�86400

Default: 10

Range: 0�900

Default: 10

SAS/SEFS-P Range: 0�86400

Default: 8

Range: 0�900

Default: 2

PLCP (NE/FE)

CV-PLCP Range: 6�10

Default: 9

Range: 6�10

Default: 9

ES-PLCP Range: 0�86400

Default: 250

0�900

Default: 25

SES-PLCP Range: 0�86400

Default: 40

Range: 0�900

Default: 4

UAS-PLCP Range: 0�86400

Default: 10

Range: 0�900

Default: 10

SAS/SEFS-PLCP

Range: 0�86400

Default: 8

Range: 0�900

Default: 2

Table 61. BERT

Parameter Default Range

Signal DegradeCondition

6 6�9

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

231 (252)

Provisioning concepts and parameters

Page 232: Dn03492199 4 en Global PDF Paper a4

Table 61. BERT (cont.)

Parameter Default Range

Signal Fail Condition 3 3�5

7.1.5 E1 provisioning parameters

Table 62. E1 tab page

Parameter Values

Interface Timing Node clock (default)

Loop timing

Cell Scrambling Enbled by default

Table 63. E1 Thresholds tab page (Frame)

Line/Path Acronym Daily interval 15-minute Interval

Line

CV-L (NE) Range: 0�65535

Default: 0

Range: 0�16383

Default: 0

ES-L (NE) Range: 0�65535

Default: 0

Range: 0�900

Default: 0

SES-L (NE) Range: 0�65535

Default: 0

0�900

Default: 0

UAS-L (NE) Range: 0�65535

Default: 0

0�900

Default: 0

Path

CV-P (NE/FE) Range: 6�65535

Default: 0

Range: 0�16383

Default: 0

ES-P (NE/FE) Range: 0� Range: 0�900

232 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 233: Dn03492199 4 en Global PDF Paper a4

Table 63. E1 Thresholds tab page (Frame) (cont.)

Line/Path Acronym Daily interval 15-minute Interval

65535

Default: 0

Default: 0

SES-P (NE) Range: 0�65535

Default: 0

Range: 0�900

Default: 0

UAS-P (NE) Range: 0�65535

Default: 0

Range: 0�900

Default: 0

SAS-P (NE) Range: 0�65535

Default: 0

Range: 0�900

Default: 0

Table 64. E1 Thresholds (Failure)

Parameter Daily interval 15-minute interval

LOF Seconds Range:0�900

Default: 0

Range:0�65535

Default: 0

LOS Seconds Range:0�900

Default: 0

Range:0�65535

Default: 0

LCD Seconds Range:0�900

Default: 0

Range:0�65535

Default: 0

Table 65. Configuration tab page (In the Properties View)

IMA parameters Values

Alpha Value Range: 1�2

Default: 2

Beta Value Range: 1�5

Default: 2

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

233 (252)

Provisioning concepts and parameters

Page 234: Dn03492199 4 en Global PDF Paper a4

Table 65. Configuration tab page (In the Properties View) (cont.)

IMA parameters Values

Gamma Value Range: 1�5

Default: 2

Table 66. New IMA Group dialog box

Parameter Values

Minimum Links Default: 1

Tx Clock Mode CTC (default)

ITC

Tx IMA ID Default: 0

Frame Length m256, m128 (default), m64, m32

Diff Delay Max (ms) Default: 25

IMA Version Ver 1.0

Ver 1.1 (default)

Table 67. BwUtil tab page (IMA Group Configuration dialogbox)

Parameter Tx Rx

Alarm Default: disabled Default: disabled

Abatement Default: 70 Default: 70

Severe Default: 90 Default: 90

RptAct Default: 300 Default: 300

RptClr Default: 300 Default: 300

234 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 235: Dn03492199 4 en Global PDF Paper a4

7.1.6 ATM/Ethernet connection provisioning parameters

Table 68. New connection dialog box

Parameter Values Default

Link A Unit (slot) (Depends on the unit selection)

Link A Port 1�48 (Depends on the port selection)

Link A VPI (Per service order) 0

Link A VCI (Per service order) 100

Link Z Unit (slot) Trunk/Tributary (Depends on the unit selection)

Link Z Port 1 (trunk)

1�4 (tributary)

(Depends on the unit selection)

Link Z VPI (Per service order) 0

Link Z VCI (Per service order) 32

Traffic Descriptor Z->A (Depends on the setting given in theconnection preference)

Traffic Descriptor A->Z (Depends on the setting given in theconnection preference)

Administration State . Unlocked. Locked

Unlocked

Encapsulation Type MuxRouted

MuxBridged

LLCRouted

LLCBridged

LLCBridged

VLAN ID (optional forbridged PVCs)

0�4,095

0 (VLAN disabled for bridged PVC)

0 (applicable to bridged PVCs only)

VP Connection . Select. Deselect

Deselected

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

235 (252)

Provisioning concepts and parameters

Page 236: Dn03492199 4 en Global PDF Paper a4

7.1.7 VLAN provisioning parameters

Table 69. VLANs dialog box

Parameter Values Default

Local IP Address 0.0.0.0

Gateway Address 0.0.0.0

Protocol Filter All

PPPoE

IP without NETBIOS

IP with NETBIOS

All

7.1.8 Gigabit Ethernet trunk provisioning parameters

Table 70. Ethernet tab page

Parameter Values Default

History Interval (secs) 1�3600 1800

Maximum Ageing Time(secs)

10�65,535 (secs X 10) 30

Alarm Ageing Threshold(secs)

0�65,535 (secs X 10)

0 = no threshold

10

Table 71. Thresholds tab page

Parameter Range Default

Octets Received 0

Packets Received 0

Uni-Cast Pkts Received 0

Non-Uni Pkts Received 0

Discards Received 0

236 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 237: Dn03492199 4 en Global PDF Paper a4

Table 71. Thresholds tab page (cont.)

Parameter Range Default

Erros Received 0

Max BW Util Received 0�100 0

Undersize Pkts Received 0

Oversize Pkts Received 0

Undersize Pkts Receivedwith FCS Error

0

Oversize Pkts Receivedwith FCS Error

0

Collisions Received 0

Octets Transmitted 0

Packets Transmitted 0

Uni-Cast Pkts Transmitted 0

Non-Uni Pkts Transmitted 0

Discards Transmitted 0

Errors Transmitted

Max BW Util Transmitted 0�100 0

7.2 Policer limitations and granularity rates

7.2.1 Limitations for an ATM policer

There are few limitations on the rates that can be configured and depending onthose rates there are limitations on the burst size to support at those rates.

There are minimum and maximum rates for both PCR and SCR. The minimumrate is 96 and the maximum rate is 6234374 cells per second.

For CDVT the minimum rate is 2 and 105117 tenths of microseconds.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

237 (252)

Provisioning concepts and parameters

Page 238: Dn03492199 4 en Global PDF Paper a4

The burst size limitations depend on the PCR and SCR rates. For rate less than 1mega cells per second it should be OK with the current policer where SCR ratesshould be less than 85 % of PCR at least.

Since the burst size is too dependent on PCR and SCR, the user should calculatethe burst for configured values based on GCRA requirements as burst size =MBS � 1 * (1/scr �1/pcr)/resolution where resolution for the current parser is1.60401E-07.

Class settings

. CBR has settings

- PCR XXX (in cells/s) Note 1) 2)

- CDVT XXX (in 0.1¼s) 2).

Policing uses a leaky bucket drained at PCR and with bucket sizePCR*CDVT*10-7. All incoming packets causing bucket overflow aredropped. Default CDVT = 1/PCR*(107*1cell).

. VBRrt has settings

- PCR XXX (in cells/s) Note 1) 2)

- CDVT XXX (in 0.1 ¼s) 2)

- SCR XXX (in cells/s)

- MBS XXX (in cells).

Policing uses a dual leaky bucket approach. The first bucket is drained atPCR and has bucket size PCR*CDVT*10-7. The second bucket is drainedat SCR and has size MBS. All incoming packets causing bucket overflow(first or second) are dropped.

. VBRnrt has settings

- PCR XXX (in cells/s) Note 1) 2)

- CDVT XXX (in 0.1 ¼s) 2)

- SCR XXX (in cells/s)

- MBS XXX (in cells).

Policing uses a dual leaky bucket approach. The first bucket is drained atPCR and has bucket size PCR*CDVT*10-7. The second bucket is drainedat SCR and has size MBS. Incoming packets causing bucket overflow (firstor second) are either dropped or CLP-tagged (configurable feature).

. UBR has settings

- PCR XXX (in cells/s) Note 1) 2)

- CDVT XXX (in 0.1 ¼s) 2).

238 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 239: Dn03492199 4 en Global PDF Paper a4

Policing uses a leaky bucket drained at PCR and with bucket sizePCR*CDVT*10-7. Incoming packets causing bucket overflow are droppedor CLP-marked (configurable feature).

7.2.2 Limitations for a packet policer

The minimum value for PIR and CIR is 1 kbit/s, which is the minimum unit thatcan be specified.

Maximum rates thet the policer can handle is 48706 kbit/s, see Packet policergranularity rates. If the user configures above this value the policing does nothappen for the flow all traffic is allowed to go through. The user is responsibilefor validating the higher rates against the granularity rates.

Class settings

. EF class has settings

- PIR XXX (in kbit/s) Note 1) 2)

- PBS XXX (in bytes) 2).

Policing uses a leaky bucket drained at PIR and with bucket size PBS. Allincoming packets causing bucket overflow are dropped.

. AF class has settings

- PIR XXX (in kbit/s) Note 1) 2)

- CIR XXX (in kbit/s) Note 1) 2)

- PBS XXX (in bytes) 2)

- CBS XXX (in bytes) 2).

Policing uses a dual leaky bucket approach. The first bucket is drained atPIR and has bucket size PBS. Incoming packets causing the bucket tooverflow are dropped (red packets). The second bucket is drained at CIRand has size CBS. Incoming packets causing bucket overflow are markedand passed through. Marking means setting CLP = 1 (ATM output) oryellow (packet data).

. DF class has settings

- PIR XXX (in kbit/s) Note 1) 2)

- PBS XXX (in bytes) 2).

The policing uses a leaky bucket drained at PIR and with bucket size PBS.Incoming packets causing bucket overflow are marked (CLP=1 or yellow)and passed through.

Note

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

239 (252)

Provisioning concepts and parameters

Page 240: Dn03492199 4 en Global PDF Paper a4

The PIR rate is approximated to the closest higher value listed in the data rate list.

Note

If a PIR, CIR, PBS, CBS value higher than the highest possible (listed value)value is selected, there will not be any packet dropping or marking.

7.2.3 Packet policer granularity rates

The following are the higher granular rates in kbit/s for a packet policer, whichcan be used in configuring higher rates for a flow. If the user-specified value is inbetween two granular values, policing is done at a higher granular value. Thus theuser has to choose the higher value when policing is configured.

48706,24353,16235,12176,9741,8117,6958,6088,5411,4870,4427,4058,3746,3-479,3247,3044,2865,2705,2563,2435,2319,2213,2117,2029,1948,1873,1803,17-39,1679,1623,1571,1522,1475,1432,1391,1352,1316,1281,1248,1217,1187,115-9,1132,1106,1082,1058,1036,1014,994,974,955,936,918,901,885,869,854,839,-825,811,798,785,773,761,749,737,726,716,705,695,686,676,667,658,649,640,6-32,624,616,608,601,593,586,579,573,566,559,553,547,541,535,529,523,518,51-2,507,502,497,491,487,482,477,472,468,463,459,455,450,446,442,438,434,431-,427,423,419,416,412,409,405,402,399,395,392,389,386,383,380,377,374,371,-368,366,363,360,358,355,352,350,347,345,343,340,338,335,333,331,329,326,3-24,322,320,318,316,314,312,310,308,306,304,302,300,298,296,295,293,291,28-9,288,286,284,283,281,279,278,276,275,273,272,270,269,267,266,264,263,261-,260,259,257,256,255,253,252,251,249,248,247,245,244,243,242,241,239,238,-237,236,235,234,233,231,230 and up to the minimum value of 1 kbit/s

7.2.4 ATM policer granularity rates

The following are the higher granular rates in cps for an ATM policer, which canbe used in configuring higher rates for a flow. If the user-specified value is inbetween two granular values, policing is done at higher granular value. Thus theuser has to choose the higher value when policing is configured.

6234374,3117187,2078124,1558593,1246874,1039062,890624,779296,692708-,623437,566761,519531,479567,445312,415624,389648,366727,346354,32812-4,311718,296874,283380,271059,259765,249374,239783,230902,222656,2149-78,207812,201108,194824,188920,183363,178124,173177,168496,164062,159-

240 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 241: Dn03492199 4 en Global PDF Paper a4

855,155859,152057,148437,144985,141690,138541,135529,132646,129882,12-7232,124687,122242,119891,117629,115451,113352,111328,109374,107489,1-05667,103906,102202,100554,98958,97412,95913,94460,93050,91681,90353,-89062,87808,86588,85402,84248,83124,82031,80965,79927,78916,77929,769-67,76028,75112,74218,73345,72492,71659,70845,70049,69270,68509,67764,6-7036,66323,65624,64941,64271,63616,62973,62343,61726,61121,60527,5994-5,59374,58814,58265,57725,57196,56676,56165,55664,55171,54687,54211,53-744,53285,52833,52389,51953,51523,51101,50685,50277,49874,49479,49089,-48706,48328,47956,47590,47230,46874,46525,46180,45840,45506,45176,448-51,44531,44215,43904,43597,43294,42995,42701,42410,42124,41841,41562,4-1287,41015,40747,40482,40221,39963,39709,39458,39209,38964,38722,3848-3,38247,38014,37784,37556,37331,37109,36889,36672,36458,36246,36036,35-829,35624,35422,35222,35024,34828,34635,34444,34254,34067,33882,33699,-33518,33338,33161,32986,32812,32640,32470,32302,32135,31971,31808,316-46,31486,31328,31171,31016,30863,30711,30560,30411,30263,30117,29972,2-9829,29687,29546,29407,29269,29132,28997,28862,28729,28598,28467,2833-8,28209,28082,27956,27832,27708,27585,27464,27343,27224,27105,26988,26-872,26756,26642,26529,26416,26305,26194,26085,25976,25868,25761,25655,-25550,25446,25342,25240,25138,25037,24937,24838,24739,24641,24544,244-48,24353,24258,24164,24070,23978,23886,23795,23704,23615,23525,23437,2-3349,23262,23176,23090,23005,22920,22836,22753,22670,22588,22506,2242-5,22345,22265,22186,22107,22029,21952,21874,21798,21722,21647,21572,21-497,21423,21350,21277,21205,21133,21062,20991,20920,20850,20781,20712,-20643,20575,20507,20440,20373,20307,20241,20175,20110,20046,19981,199-18,19854,19791,19729,19666,19604,19543,19482,19421,19361,19301,19241,1-9182,19123,19065,19007,18949,18892,18834,18778,18721,18665,18610,1855-4,18499,18444,18390,18336,18282,18229,18176,18123,18070,18018,17966,17-914,17863,17812,17761,17711,17661,17611,17561,17512,17463,17414,17365,-17317,17269,17222,17174,17127,17080,17033,16987,16941,16895,16849,168-04,16759,16714,16669,16624,16580,16536,16493,16449,16406,16363,16320,1-6277,16235,16193,16151,16109,16067,16026,15985,15944,15904,15863,1582-3,15783,15743,15703,15664,15624,15585,15547,15508,15469,15431,15393,15-355,15317,15280,15242,15205,15168,15131,15095,15058,15022,14986,14950,-14914,14879,14843,14808,14773,14738,14703,14669,14634,14600,14566,145-32,14498,14464,14431,14398,14364,14331,14299,14266,14233,14201,14169,1-4136,14104,14073,14041,14009,13978,13947,13916,13885,13854,13823,1379-2,13762,13732,13701,13671,13641,13612,13582,13552,13523,13494,13465,13-436,13407,13378,13349,13321,13292,13264,13236,13208,13180,13152,13124,-13097,13069,13042,13015,12988,12961,12934,12907,12880,12854,12827,128-01,12775,12749,12723,12697,12671,12645,12620,12594,12569,12544,12518,1-2493,12468,12443,12419,12394,12369,12345,12320,12296,12272,12248,1222-4,12200,12176,12152,12129,12105,12082,12058,12035,12012,11989,11966,11-943,11920,11897,11874,11852,11829,11807,11785,11762,11740,11718,11696,-11674,11653,11631,11609,11588,11566,11545,11523,11502,11481,11460,1143-9,11418,11397,11376,11355,11335,11314,11294,11273,11253,11233,11212,11-192,11172,11152,11132,11112,11093,11073,11053,11034,11014,10995,10976,-10956,10937,10918,10899,10880,10861,10842,10823,10804,10786,10767,107-

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

241 (252)

Provisioning concepts and parameters

Page 242: Dn03492199 4 en Global PDF Paper a4

48,10730,10711,10693,10675,10657,10638,10620,10602,10584,10566,10548,1-0531,10513,10495,10477,10460,10442,10425,10407,10390,10373,10356,1033-8,10321,10304,10287,10270,10253,10237,10220,10203,10186,10170,10153,10-137,10120,10104,10087,10071,10055,10039,10023,10007,9990,9974,9959,994-3,9927,9911,9895,9880,9864,9848,9833,9817,9802,9787,9771,9756,9741,9726-,9710,9695,9680,9665,9650,9635,9620,9606,9591,9576,9561,9547,9532,9518,-9503,9489,9474,9460,9446,9431,9417,9403,9389,9374,9360,9346,9332,9318,9-305,9291,9277,9263,9249,9236,9222,9208,9195,9181,9168,9154,9141,9127,91-14,9101,9088,9074,9061,9048,9035,9022,9009,8996,8983,8970,8957,8944,893-1,8918,8906,8893,8880,8868,8855,8843,8830,8818,8805,8793,8780,8768,8756-,8743,8731,8719,8707,8695,8682,8670,8658,8646,8634,8622,8611,8599,8587,-8575,8563,8551,8540,8528,8516,8505,8493,8482,8470,8459,8447,8436,8424,8-413,8402,8390,8379,8368,8357,8345,8334,8323,8312,8301,8290,8279,8268,82-57,8246,8235,8224,8213,8203,8192,8181,8170,8160,8149,8138,8128,8117,810-7,8096,8086,8075,8065,8054,8044,8033,8023,8013,8003,7992,7982,7972,7962-,7952,7941,7931,7921,7911,7901,7891,7881,7871,7861,7851,7841,7832,7822,-7812,7802,7792,7783,7773,7763,7754,7744,7734,7725,7715,7706,7696,7687,7-677,7668,7658,7649,7640,7630,7621,7612,7602,7593,7584,7575,7565,7556,75-47,7538,7529,7520,7511,7502,7493,7484,7475,7466,7457,7448,7439,7430,742-1,7413,7404,7395,7386,7377,7369,7360,7351,7343,7334,7325,7317,7308,7300-,7291,7283,7274,7266,7257,7249,7240,7232,7224,7215,7207,7199,7190,7182,-7174,7165,7157,7149,7141,7133,7124,7116,7108,7100,7092,7084,7076,7068,7-060,7052,7044,7036,7028,7020,7012,7004,6997,6989,6981,6973,6965,6958,69-50,6942,6934,6927,6919,6911,6904,6896,6888,6881,6873,6866,6858,6850,684-3,6835,6828,6820,6813,6806,6798,6791,6783,6776,6769,6761,6754,6747,6739-,6732,6725,6718,6710,6703,6696,6689,6682,6674,6667,6660,6653,6646,6639,-6632,6625,6618,6611,6604,6597,6590,6583,6576,6569,6562,6555,6548,6541,6-534,6528,6521,6514,6507,6500,6494,6487,6480,6473,6467,6460,6453,6447,64-40,6433,6427,6420,6413,6407,6400,6394,6387,6381,6374,6368,6361,6355,634-8,6342,6335,6329,6322,6316,6310,6303,6297,6290,6284,6278,6272,6265,6259-,6253,6246,6240,6234,6228,6221,6215,6209,6203,6197,6191,6184,6178,6172,-6166,6160,6154,6148,6142,6136,6130,6124,6118,6112,6106,6100,6094,6088,6-082,6076,6070,6064,6058,6052,6046,6041,6035,6029,6023,6017,6011,6006,60-00,5994,5988,5983,5977,5971,5965,5960,5954,5948,5943,5937,5931,5926,592-0,5914,5909,5903,5898,5892,5887,5881,5875,5870,5864,5859,5853,5848,5842-,5837,5831,5826,5821,5815,5810,5804,5799,5794,5788,5783,5777,5772,5767,-5761,5756,5751,5745,5740,5735,5730,5724,5719,5714,5709,5703,5698,5693,5-688,5683,5677,5672,5667,5662,5657,5652,5647,5641,5636,5631,5626,5621,56-16,5611,5606,5601,5596,5591,5586,5581,5576,5571,5566,5561,5556,5551,554-6,5541,5536,5531,5526,5522,5517,5512,5507,5502,5497,5492,5488,5483,5478-,5473,5468,5463,5459,5454,5449,5444,5440,5435,5430,5425,5421,5416,5411,-5407,5402,5397,5393,5388,5383,5379,5374,5369,5365,5360,5355,5351,5346,5-342,5337,5333,5328,5323,5319,5314,5310,5305,5301,5296,5292,5287,5283,52-78,5274,5269,5265,5261,5256,5252,5247,5243,5238,5234,5230,5225,5221,521-7,5212,5208,5203,5199,5195,5190,5186,5182,5178,5173,5169,5165,5160,5156-,5152,5148,5143,5139,5135,5131,5126,5122,5118,5114,5110,5105,5101,5097,-5093,5089,5085,5080,5076,5072,5068,5064,5060,5056,5052,5048,5043,5039,5-

242 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 243: Dn03492199 4 en Global PDF Paper a4

035,5031,5027,5023,5019,5015,5011,5007,5003,4999,4995,4991,4987,4983,49-79,4975,4971,4967,4963,4959,4955,4951,4947,4943,4940,4936,4932,4928,492-4,4920,4916,4912,4908,4905,4901,4897,4893,4889,4885,4882,4878,4874,4870-,4866,4863,4859,4855,4851,4847,4844,4840,4836,4832,4829,4825,4821,4817,-4814,4810,4806,4803,4799,4795,4791,4788,4784,4780,4777,4773,4769,4766,4-762,4759,4755,4751,4748,4744,4740,4737,4733,4730,4726,4723,4719,4715,47-12,4708,4705,4701,4698,4694,4691,4687,4683,4680,4676,4673,4669,4666,466-2,4659,4655,4652,4649,4645,4642,4638,4635,4631,4628,4624,4621,4618,4614-,4611,4607,4604,4601,4597,4594,4590,4587,4584,4580,4577,4574,4570,4567,-4563,4560,4557,4553,4550,4547,4544,4540,4537,4534,4530,4527,4524,4520,4-517,4514,4511,4507,4504,4501,4498,4494,4491,4488,4485,4481,4478,4475,44-72,4469,4465,4462,4459,4456,4453,4449,4446,4443,4440,4437,4434,4430,442-7,4424,4421,4418,4415,4412,4409,4405,4402,4399,4396,4393,4390,4387,4384-,4381,4378,4374,4371,4368,4365,4362,4359,4356,4353,4350,4347,4344,4341,-4338,4335,4332,4329,4326,4323,4320,4317,4314,4311,4308,4305,4302,4299,4-296,4293,4290,4287,4284,4281,4278,4275,4273,4270,4267,4264,4261,4258,42-55,4252,4249,4246,4243,4241,4238,4235,4232,4229,4226,4223,4220,4218,421-5,4212,4209,4206,4203,4201,4198,4195,4192,4189,4186,4184,4181,4178,4175-,4172,4170,4167,4164,4161,4159,4156,4153,4150,4147,4145,4142,4139,4136,-4134,4131,4128,4125,4123,4120,4117,4115,4112,4109,4106,4104,4101,4098,4-096,4093,4090,4088,4085,4082,4080,4077,4074,4072,4069,4066,4064,4061,40-58,4056,4053,4050,4048,4045,4043,4040,4037,4035,4032,4029,4027,4024,402-2,4019,4016,4014,4011,4009,4006,4004,4001,3998,3996,3993,3991,3988,3986-,3983,3981,3978,3976,3973,3970,3968,3965,3963,3960,3958,3955,3953,3950,-3948,3945,3943,3940,3938,3935,3933,3930,3928,3925,3923,3920,3918,3916,3-913,3911,3908,3906,3903,3901,3898,3896,3894,3891,3889,3886,3884,3881,38-79,3877,3874,3872,3869,3867,3865,3862,3860,3857,3855,3853,3850,3848,384-6,3843,3841,3838,3836,3834,3831,3829,3827,3824,3822,3820,3817,3815,3813-,3810,3808,3806,3803,3801,3799,3796,3794,3792,3789,3787,3785,3782,3780,-3778,3776,3773,3771,3769,3766,3764,3762,3760,3757,3755,3753,3751,3748,3-746,3744,3742,3739,3737,3735,3733,3730,3728,3726,3724,3722,3719,3717,37-15,3713,3710,3708,3706,3704,3702,3699,3697,3695,3693,3691,3688,3686,368-4,3682,3680,3678,3675,3673,3671,3669,3667,3665,3662,3660,3658,3656,3654-,3652,3650,3647,3645,3643,3641,3639,3637,3635,3633,3630,3628,3626,3624,-3622,3620,3618,3616,3614,3612,3609,3607,3605,3603,3601,3599,3597,3595,3-593,3591,3589,3587,3585,3582,3580,3578,3576,3574,3572,3570,3568,3566,35-64,3562,3560,3558,3556,3554,3552,3550,3548,3546,3544,3542,3540,3538,353-6,3534,3532,3530,3528,3526,3524,3522,3520,3518,3516,3514,3512,3510,3508-,3506,3504,3502,3500,3498,3496,3494,3492,3490,3488,3486,3484,3482,3479,-3477,3475,3473,3471,3469,3467,3465,3463,3461,3459,3457,3455,3452,3450,3-448,3446,3444,3442,3440,3438,3436,3433,3431,3429,3427,3425,3423,3421,34-19,,3416,3414,3412,3410,3408,3406,3403,3401,3399,3397,3395,3393,3390,33-88,3386,3384,3382,3379,3377,3375,3373,3371,3368,3366,3364,3362,3359,335-7,3355,3353,3350,3348,3346, 3344,3341,3339,3337,3335,3332,3330,3328,3326and up to 96 cps.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

243 (252)

Provisioning concepts and parameters

Page 244: Dn03492199 4 en Global PDF Paper a4

7.3 ATM QoS concepts

The following concepts are pieces of general information on ATM QoS.

7.3.1 Multiple service categories

ATM QoS provides the following four service categories:

. Constant Bit Rate (CBR) is an ATM category that supports a constant orguaranteed rate of bandwidth during the connection lifetime. Examples arereal time video, audio, circuit emulation services, and audio-videodistribution such as TV, pay-per-view, or distance learning. CBR servicesprovide connectivity up to a peak cell rate with an upper bound of celldelay variation tolerance. The source may emit cells at or below thenegotiated peak cell rate at any time for any duration and the QoScommitments still pertain.

. Variable Bit Rate real-time (VBR-rt) is a service category that supportsapplications requiring variable bandwidth with tight limits on delay. VBR-rt is guaranteed an average rate of bandwidth, based on the trafficrequirements of the connection (Peak Cell Rate, Sustained Cell Rate, andMaximum Burst Size). Cells are generated at arbitrary time intervals basedon connection use and delivered with bounded cell delay variation and cellloss ratio. Examples are variable bit rate CODECs, aggregated voice withsilence removal, video conferencing and loop emulation services withAAL2.

. Variable Bit Rate non-real-time (VBR-nrt) is a service category thatsupports applications requiring variable bandwidth with fewer delayguarantees as in the case of transaction processing. Cells are generated atarbitrary time intervals based on connection use and delivered withbounded cell delay variation and cell loss ratio.

. Unspecified Bit Rate (UBR) is intended for applications that do notrequire a fixed bandwidth or fixed interval of transmission, and are highlytolerant of delay and loss. Examples are file transfer, e-mail, and LANs.

In the case of UBR, there is no explicit commitment from the networkprovider regarding capacity or throughput. The network transmits cellsbased on available bandwidth without delay or throughput guarantees, andthe only traffic parameter is PCR.

The following figure shows the bandwidth occupied by various service categoriesin a network circuit.

244 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 245: Dn03492199 4 en Global PDF Paper a4

Figure 57. CBR, VBR, and UBR

7.3.2 ATM performance parameters

The following QoS and traffic parameters are used in this chapter to describeATM performance.

CLR (Cell Loss Ratio)

CLR is a QoS parameter that gives the ratio of the lost cells to the total number oftransmitted cells on a given VCC. This is preset for the connection admissioncontrol algorithm to be 10-7 for VBR-rt and VBR-nrt.

CTD (Cell Transfer Delay)

CTD is a QoS parameter that measures the maximum or worst-case time for a cellto be transferred from its source to its destination over a virtual connection. It isthe sum of buffering, propagation, processing and queuing delays.

CDV (Cell Delay Variance)

CDV is a QoS parameter that measures the peak-to-peak cell delay through thenetwork; it is the difference between the worst case delay as determined by theCTD and the best case delay or fixed delay achievable on the virtual connection.It is a very important parameter for time-sensitive service categories such as CBRand VBR-rt and it provides a measure of how closely cells are spaced in a VCC.CDV is usually introduced due to cell multiplexing, buffering or the insertion ofOAM cells.

CDVT (Cell Delay Variance Tolerance)

CDVT is a parameter that specifies in tenths of microseconds the acceptabletolerance to cell-by-cell variations of the CDV (jitter). The CDVT is typicallyvery low for CBR and VBR-rt connections, a bit higher for VBR-nrt connectionsand very high for UBR connections. This is provisionable for each virtualconnection.

CircuitCapacityin Cellsper Second

UBR

VBR

CBRPCR

SCR

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

245 (252)

Provisioning concepts and parameters

Page 246: Dn03492199 4 en Global PDF Paper a4

PCR (Peak Cell Rate)

Figure 58. PCR

PCR is a traffic parameter in cells per second that specifies the maximum sourcetransmission rate. The fraction 1/PCR represents the time between two cells overa given virtual connection. PCR is assigned to all service categories. It can onlybe set at a speed lower than the port connection speed.

Table 72. Mapping data rates to ATM peak cell rates

Data rates (kbit/s) *) Peak cell rate cells/sec.

192 453

384 906

768 1812

1152 2717

1536 3623

2320 5472

*) One ATM cell equals 424 bits.

SCR (Sustainable Cell Rate)

Figure 59. SCR

SCR is an ATM traffic parameter in cells per second that characterises a burstysource and specifies a maximum average rate at which cells can be sent over agiven ATM virtual connection.

246 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 247: Dn03492199 4 en Global PDF Paper a4

Burst Tolerance

Burst Tolerance is the maximum length of time that a connection can send at thePeak Cell Rate. The parameter measures how long a connection may exceed theSustained Cell Rate.

MBS (Maximum Burst Size)

Figure 60. MBS

MBS is a traffic parameter that specifies the maximum number of cells in a burstthat can be transmitted at the peak rate assuming that, at the beginning of theburst, the receiving buffers are empty.

7.3.3 CLP (Cell Loss Priority)

CLP is a one-bit field in the ATM cell header that corresponds to the loss priorityof a cell. CLP=0 cells are a higher priority than CLP=1 cells. Lower priority(CLP=1) cells can be discarded first during a congestion situation. CLP=0+1refers to an aggregate cell stream.

The following figure illustrates PCR, SCR, and MBS in a sample ATM trafficstream. It also shows that non-conforming cells are tagged to be discarded in theevent of network congestion.

Figure 61. PCR, SCR, and MBS

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

247 (252)

Provisioning concepts and parameters

Page 248: Dn03492199 4 en Global PDF Paper a4

7.3.4 ATM QoS scheduling

The differentiated Quality of Service of different ATM Service categories areimplemented by differentiated scheduling of cell transmission. The availablebandwidth is shared by all connections. The bandwidth is yielded to connectionsas guaranteed service and best-effort service; what the proportions of service are,depends on the service category.

Guaranteed service guarantees reserved bandwidth for a connection. Best-effortservice uses excess bandwidth that is left over from guaranteed servicereservations, or is currently unused by the guaranteed service. Excess bandwidthis shared by different service categories in proportion to the bandwidth allocatedto connections in each category.

Service categories

The different service categories have the following profiles:

. CBR connections have PCR guaranteed bandwidth. Any traffic exceedingPCR will be subject to traffic contract violation and policing. CBRconnections do not use excess bandwidth.

. Real-time VBR connections have guaranteed bandwidth of effectivebandwidth. The proportion of excess bandwidth available for the real-timeVBR service category as a whole is the sum of effective bandwidths of theconnections divided by the sum of bandwidths of all service categories.

. Non-real-time VBR connections have guaranteed bandwidth of effectiveband-width. The proportion of excess bandwidth available for the non-real-time VBR service category as a whole is the sum of effective bandwidthsof the connections divided by the sum of bandwidths of all servicecategories.

. UBR connections have no guaranteed bandwidth. They use only excessbandwidth providing only best-effort service. The proportion of excessbandwidth available for the UBR service category as a whole is the sum ofUBR PCRs of the connections, divided by the sum of bandwidths of allservice categories.

The following table summarises the service category profiles:

248 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 249: Dn03492199 4 en Global PDF Paper a4

Table 73. Summary of service category scheduling profiles

Service category Guaranteedbandwidth of aconnection

Excess bandwidthproportion of theservice category

CBR PCR Zero

rt-VBR EBW*) Sum of EBW/Total BW**)

nrt-VBR EBW Sum of EBW/ TotalBW

UBR Zero Sum of PCR/TotalBW

*) EBW = Effective Bandwidth calculated from PCR,SCR and MBS. SCR<EBW < PCR.

**) TotalBW = sum of bandwidth of all connections in all service categories

The connections within each service category are treated equally. Note thateffective bandwidth of real-time VBR is calculated to be higher than for non-real-time VBR, giving better service for real-time VBR. CBR is excluded fromcalculations of excess bandwidth.

7.3.5 Traffic policing

Once a virtual connection is established, active processes monitor and enforce therules embodied in the traffic contract. This is called traffic policing.

Traffic policing is carried out by a process component called the Usage ParameterControl (UPC), resident in the trunk/control unit. In the D500, both trafficentering the node on Link Z and traffic entering the node on Link A is policed.

Generic Cell Rate Algorithm (Dual Leaky Bucket)

The UPC tags or discards errant cells based on the Generic Cell Rate Algorithm(GCRA), also known as the Dual Leaky Bucket algorithm. The GCRA provides amethod to explain how an ATM switch measures the bandwidth conformance ofeach CBR and VBR connection. It is a flow control algorithm where cells aremonitored to check whether they comply with the established connectionparameters.

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

249 (252)

Provisioning concepts and parameters

Page 250: Dn03492199 4 en Global PDF Paper a4

The �dual leaky bucket� analogy conceptually describes the traffic policing andshaping performed by the complex Generic Cell Rate Algorithm. In the followingfigure there is a burst of cells entering the network from the ATM CustomerPremises Equipment. The leak out of the first bucket represents the Peak CellRate. Cells may enter at above the Peak Cell Rate, and the tolerance for this isrepresented by CDVT (Cell Delay Variance Tolerance), which is the depth of thefirst bucket. Cells are discarded when the bucket fills. This is true for all types ofconnections: CBR, VBR-rt, VBR-nrt, and UBR.

For VBR connections, cells then enter the second bucket. The leak out of thesecond bucket represents the Sustainable Cell Rate, and the depth of the bucket isthe Burst Tolerance, which is the maximum length of time a connection can sendcells at the Peak Cell Rate. Cells overflowing from the second bucket are eithertagged or discarded.

Figure 62. Generic Cell Rate Algorithm (Dual Leaky Bucket)

Discarded

Peak Cell Rate

ATM CPE

Incoming Burstof Cells

CellDelayVarianceTolerance

Tagged orDiscarded

Sustainable CellRate

BurstTolerance

250 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning

Page 251: Dn03492199 4 en Global PDF Paper a4

7.3.6 Congestion control and avoidance

Early Packet Discard (EPD) parameters can be enabled to control congestion.

Early Packet Discard (also called Frame Discard) can be enabled on a trafficdescriptor basis for AAL5 type of connections, both upstream and downstream,for VBR and UBR service categories. When the provisioned threshold is reached,EPD stops all new incoming packets (a protocol data unit comprising a series ofATM cells) and makes an intelligent choice of dropping all cells in a packetinstead of randomly dropping cells from many packets.

EPD determines the packet boundaries by examining the Service Data UnitIdentifier (SDUI) in the Payload Type (PT) field of the ATM cell header.

Figure 63. Three bits in the Payload Type field of the ATM cell header

7.3.7 Connection admission and control (CAC)

The connection admission and control (CAC) traffic management functionensures that the network does not accept new connection requests when it cannotprovide the requested QoS.

For each connection request, the CAC evaluates the bandwidth request based onthe following information obtained from the traffic contract:

ATM Cell

0 or VPI VPI

VPI VCI

VCI

VCI PT CLP

Header Error Check

Payload

PTI EFCI SDUI

Payload Type (PT)

dn03492199Issue 4 en

# Nokia CorporationNokia Proprietary and Confidential

251 (252)

Provisioning concepts and parameters

Page 252: Dn03492199 4 en Global PDF Paper a4

. Values of parameters in the source traffic descriptor

. Requested and acceptable values of each QoS parameter and the requestedQoS category

. CDVT value

. Requested conformance definition.

CAC reserves bandwidth for each QoS as follows:

. For CBR connections, CAC reserves bandwidth for Peak Cell Rate (PCR)

. For VBR connections, CAC reserves bandwidth for Sustained Cell Rate(SCR)

. For UBR connections, no bandwidth is reserved.

252 (252) # Nokia CorporationNokia Proprietary and Confidential

dn03492199Issue 4 en

Provisioning