You are on page 1of 252

C33990.90--A0 Nokia D500, Rel. 3.

2, Product Documentation

Provisioning

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

1 (252)

Provisioning

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia's customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia and the customer. However, Nokia has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia will, if necessary, explain issues which 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 DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), 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 to the applicable laws. NOKIA logo is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only. Copyright Nokia Corporation 2004. All rights reserved.

2 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Contents

Contents
Contents 3 1 1.1 1.1.1 1.2 1.3 1.4 1.4.1 1.4.2 1.4.3 1.4.4 1.4.5 1.4.6 1.4.7 2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8 2.1.9 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 2.2.9 2.2.10 2.2.11 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7 Service provisioning 7 Introduction to service provisioning 7 Information required for service provisioning of ATM switched connections 7 Provisioning DSL/ATM service 8 Disconnect service 10 Provisioning examples 11 Provisioning task list for ATM switched connections 12 POTS splitter 12 ADSL through a Gigabit Ethernet trunk 12 ADSL through an OC-3/STM-1 unit 15 ADSL through an OC-12/STM-4 trunk 17 SHDSL through an OC-3/STM-1 trunk 19 VDSL through an OC-12/STM-4 trunk unit 20 Interface provisioning 23 ADSL provisioning 23 ADSL profiles 24 Alarm thresholds profiles 25 ADSL operation modes 25 Rate modes 26 Port training mode 27 Port data mode 30 ATUR/ATUC channel parameter values 31 ADSL thresholds 32 Actuals 35 SHDSL provisioning 38 SHDSL profiles 39 Alarm thresholds profiles 39 SHDSL features 40 STUC and STUR terminology 41 SHDSL operational modes 41 Data mode 41 Rates tab 41 SHDSL tab 44 Thresholds tab 45 Transmission status actuals 48 Error actuals 50 VDSL provisioning 51 VDSL profiles 52 Alarm thresholds profiles 53 VDSL operation modes 53 Rate modes 54 Port training mode 55 Port data mode 57 VTU-R/VTU-O channel parameter values 58

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

3 (252)

Provisioning

2.3.8 2.3.9 2.3.10 2.4 2.4.1 2.4.2 2.5 2.5.1 2.5.2 2.5.3 2.6 2.6.1 2.6.2 2.6.2.1 2.6.2.2 2.6.2.3 2.6.2.4 2.6.2.5 2.6.3 2.7 2.7.1 2.7.2 2.7.3 2.7.4 2.7.5 2.7.6 2.7.7 2.7.8 2.7.9 2.7.10 3 3.1 3.1.1 3.1.2 3.1.3 3.2 4 4.1 4.1.1 4.1.1.1 4.1.1.2 4.1.1.3 4.1.1.4 4.1.2 4.1.2.1 4.1.2.2 4.1.2.3 4.1.2.4 4.1.2.5

Band plan management 59 VDSL thresholds 62 Actuals 64 OC-3/STM-1 and OC-12/STM-4 provisioning 67 OC-3/STM-1 and OC-12/STM-4 ATM interface specifications 68 OC-3/STM-1 and OC-12/STM-4 provisioning parameters 68 Gigabit Ethernet provisioning 75 Gigabit Ethernet interface specification 76 Interval sampling 76 Ethernet actuals and performance thresholds 77 DS3 provisioning 79 DS3 ATM interface specifications 80 Provisioning parameters 80 Framing and ATM mapping options 80 Scrambling option 81 HEC coset option 81 Equalisation option 81 Interface timing option 81 Counters and thresholds 81 E1 provisioning 85 IMA 86 E1 card applications 88 Provisioning parameters 88 Provisioning E1 parameters 88 E1 thresholds 88 Performance monitoring counters 90 ATM performance management 90 Provisioning IMA 91 IMA group actuals and performance statistics 93 IMA link actuals and performance statistics 96 Timing provisioning 101 Timing settings 101 Node timing 101 Interface timing 104 Recommended settings 106 Connecting external timing 111 Packet-based provisioning 115 Subinterface provisioning 115 Routed subinterface 115 Parameters of a routed interface 116 One-to-one routed connection (PVC-VLAN) 118 Routed subinterface isolation 120 Routing table 121 Routed bridge subinterface (RBE) 121 Parameters of a RBE interface 122 RBE interface operation 123 RBE with loopback IP addressing 126 PPPoE grooming with the RBE client subinterface 128 Multicast (IGMP proxy) functionality with RBE as a client subinterface 129

4 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Contents

4.1.2.6 4.1.2.7 4.1.3 4.1.3.1 4.1.3.2 4.1.3.3 4.1.3.4 4.1.3.5 4.1.3.6 4.1.3.7 4.1.3.8 4.1.3.9 4.1.3.10 4.1.3.11 4.1.4 4.1.5 4.1.5.1 4.1.5.2 4.1.5.3 4.1.6 4.1.7 4.1.8 4.1.9 4.1.9.1 4.1.9.2 4.1.10 4.1.10.1 4.1.10.2 4.2 4.2.1 4.2.2 5 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 5.1.7 6 6.1 6.1.1 6.2 6.2.1 6.2.1.1 6.2.1.2 6.2.1.3 6.2.2

RBE subinterface isolation 131 RBE with DHCP relay (Option 82) 132 Bridged subinterface 134 Parameters of a bridged interface 134 Bridged one-to-one connection (PVC-VLAN) 135 Bridge groups (PVCs-VLAN) 136 PPPoE grooming with a bridged client subinterface 138 Protocol filter 139 Bridged subinterface priority 140 MAC address table 141 Managing the MAC address table 142 Bridged subinterface with the DHCP relay (Option 82) 144 Bridged connection with IGMP snooping 144 Bridged connections with client side VLANs 145 PPPoA subinterface 145 L2TP 146 PPPoE 147 PPPoA 148 Testing 149 Subinterface profile definition 150 In-Band management connection 153 DHCP relay pools in the D500 155 Connection type 156 VLAN/non-VLAN connection 156 ATM AAL5 encapsulation 159 Subinterface protocol types 161 PPP grooming 161 Multicast 162 Basic packet forwarding rules 167 Downstream packets 167 Upstream packets 168 ATM VC cross-connection provisioning 171 ATM VC cross-connection provisioning 171 A PVC connection 172 DSL port parameters 173 Provisioning with Craft Terminal 173 Examples of cross-connections 173 Provisioning parameters 177 Quick connection creation 179 Craft Terminal reference information 180 QoS provisioning 181 D500 traffic management 181 Best effort only mode for line cards 185 IP CoS based on DiffServ 186 IP CoS in different service modes 187 Bridged subinterface 187 Routed subinterface 188 RBE subinterface 189 CoS in the D500 189

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

5 (252)

Provisioning

6.2.2.1 6.2.2.2 6.2.2.3 6.3 6.3.1 6.3.2 6.3.3 6.4 6.4.1 6.4.2 6.4.3 6.4.4 6.5 6.5.1 6.5.2 6.5.2.1 6.5.3 7 7.1 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.1.6 7.1.7 7.1.8 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.3 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.3.7

EF 189 AF 190 DF 191 Ethernet CoS based on VLAN user priorities 192 High priority Ethernet CoS 195 Medium priority Ethernet CoS 196 Low priority Ethernet CoS 197 QoS in ATM networks 199 CBR 199 VBR-rt 200 VBR-nrt 203 UBR 204 Traffic descriptors 206 Packet traffic descriptors and PTD policies 208 ATM traffic descriptors 212 Traffic profiles/traffic descriptors 215 Port QoS features 217 Provisioning concepts and parameters 219 Provisioning parameters 219 DSL provisioning parameters 219 QoS queue provisioning parameters 226 OC-3/STM-1 provisioning parameters 228 DS3 provisioning parameters 230 E1 provisioning parameters 232 ATM/Ethernet connection provisioning parameters 235 VLAN provisioning parameters 236 Gigabit Ethernet trunk provisioning parameters 236 Policer limitations and granularity rates 237 Limitations for an ATM policer 237 Limitations for a packet policer 239 Packet policer granularity rates 240 ATM policer granularity rates 240 ATM QoS concepts 244 Multiple service categories 244 ATM performance parameters 245 CLP (Cell Loss Priority) 247 ATM QoS scheduling 248 Traffic policing 249 Congestion control and avoidance 251 Connection admission and control (CAC) 251

6 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Service provisioning

1
1.1

Service provisioning
Introduction to service provisioning
The D500 is ready for provisioning when all initial commissioning procedures have been completed. This procedure on ATM switched connections provides detailed instructions on how to create a permanent virtual circuit (PVC) to connect a subscriber to an ATM network service provider, and unlock the line card port to provide service. In addition to ATM switched connections, the D500 system also supports packetbased services, for instance bridging, routing, RBE, multicast, PPP grooming, and L2TP tunneling. In connection with packet-based services, an idea of a subinterface is introduced. A subinterface is a logical entity created as part of a trunk port or a line card port. There can be one or more subinterfaces associated with a port. Subinterfaces of a trunk port have different characteristics than subinterfaces 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 subscriber provisioning information. A service order is an official form used by telecommunication companies which specifies customer services for new connections, changes, and disconnections.

1.1.1

Information required for service provisioning of ATM switched connections


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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

7 (252)

Provisioning

Line card and port Minimum and maximum data rates Subscribers 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 Traffic descriptors.

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 to unlock 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 menu appears. Select Port Views. On the Ports tab page, double-click the port you want to provision to have the Port Configuration dialog box.

2.

8 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Service provisioning

3.

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

Data Rate Type (The default is Interleave Rate.) The Data Rate Type box does not exist on the Rates tab of the SHDSL Port Configuration dialog box. Interleave Rates for ADSL and VDSL ports, Data Rates for SHDSL ports 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 for the Failure Thresholds and Frame Thresholds as specified on the service order. Click Apply. Add a Virtual Connection. Click the Connections tab to get the connection Information for the port. Right-click on the tab page and select New Connection. The New Connection dialog box is used to establish the permanent virtual circuit (PVC) on the subscriber s service order. 7. The line card name and port number are logical cue address mapping values for Virtual Link A (the subscribers side interface); the active trunk/control unit name and port number in the D500 is the logical cue address for Virtual Link Z (the ATM network interface). Enter manually or select (from the drop-down list boxes) the following information from the subscriber s service order:
. . .

5.

6.

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 dialog box displays the information for the connection.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

9 (252)

Provisioning

9.

Repeat Steps 2 through 8 for each ATM virtual connection specified on the service order for this line card port. Unlock the line card port. The connection is not activated until the port is unlocked. To unlock the port, click the Status tab page and select Unlocked for the Administration State. You can do the same operation in the following way as well: In the Subrack View, click the port icon of the line card to have the port-selection pane. Right-click the port number to obtain a pop-up menu and choose View Properties. In the Working Area of the GUI, the Status tab page of the port appears. Select Unlocked for the Administration State. Click OK.
Further information

10.

Do not unlock the port until the subscriber s end user equipment has been installed and is ready for service. An alarm condition is generated when the line 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 subscriber service 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 disconnect order 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 listed in 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. In the Port Configuration dialog box, select the Connections tab to get the connection information for the port.

3.

10 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Service provisioning

4.

Right-click the PVC specified on the change order. Click Delete Connection. The connection disappears from the tab page.

5.

Repeat Step 4 to delete additional PVCs on the port as indicated on the change order. Lock the port (only if you have deleted all connections on that port).
.

6.

. .

If the Port Configuration dialog box is already open, as is the case in the 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 with port 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 by network operators. The examples include sets of parameters for the following services: 1. ADSL through a Gigabit Ethernet trunk
. .

Bridged connection RBE connection

2. 3.

ADSL through an OC-3/STM-1tributary unit (as a trunk) 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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

11 (252)

Provisioning

. .

symmetrical band plan (SOHO users) asymmetrical band plan (home users).

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

1.4.1

Provisioning task list for ATM switched connections


1. 2. 3. 4. Check that there are traffic descriptors for upstream and downstream direction, which are suitable for the service you are provisioning. Select an xDSL port that matches the service. Set the xDSL parameters for the port according to the service chosen. Make a virtual channel cross-connection from the DSL port to the correct aggregate port.

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

1.4.2

POTS splitter
The POTS splitter is mentioned frequently in the following provisioning examples. 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 Gigabit Ethernet (GE) trunk. The tables list parameters for 1024k/512k ADSL service through a GE trunk.

12 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Service provisioning

POTS Network POTS Splitter ADSL Gigabit Ethernet ADSL D500

IP Network
Internet

POTS + Splitter Internet Service Provider CPE (Bridge) SOHO or Residential User

Figure 1.

ADSL service through a GE trunk with a routed/RBE/bridged connection

Table 1. Rate

DSL parameters, ADSL through a GE trunk ATU-C


1024 1024 Startup (rate adaptive)

ATU-R
512 512

Fast max (kbit/s) Fast min (kbit/s) Mode

Table 2.

One-to-one routed connection Client subinterface Trunk subinterface


TrunkOne1 11

Name Unit

OneToOne1 3

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

13 (252)

Provisioning

Table 2.

One-to-one routed connection (cont.) Client subinterface Trunk subinterface


1 Routed 20 20.1.1.1 255.255.255.0

Port Client subinterface profile Connection type Encapsulation type VPI VCI VLAN ID Local IP address Local IP mask

14 Routed LLC 0 100 20 10.1.1.1 255.255.255.0

Table 3.

Client RBE and trunk routed connection Client subinterface Trunk subinterface
Trunk2 11 1 Routed 10 30.1.1.1 255.255.255.0

Name Unit Port Client subinterface profile Connection type Encapsulation type VPI VCI VLAN ID Local IP address Local IP mask

Client2 3 13 Routed bridged LLC 0 100 10 -

14 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Service provisioning

Table 4.

Client bridged and trunk bridged connection Client subinterface Trunk subinterface
Trunk1 11 1 Bridged 0

Name Unit Port Client subinterface profile Connection type Encapsulation type VPI VCI VLAN ID

Client1 3 12 Bridged LLC 0 100 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/STM1 tributary unit as a trunk. The tables list parameters for ADSL service through an OC-3/STM-1 tributary unit as a trunk.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

15 (252)

Provisioning

POTS Network POTS Splitter ADSL OC-3/ STM-1 D500

ATM Network
Internet

POTS + Splitter Internet Service Provider CPE SOHO or Residential User

Figure 2.

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

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

Table 5. Rate

DSL parameters, ADSL through an OC-3/STM-1 tributary unit ATU-C


256 32 Startup (rate adaptive)

ATU-R
128 32

Interleave max (kbit/s) Interleave min (kbit/s) Mode

Table 6. Slot Port

ATM parameters, ADSL through an OC-3STM-1 tributary unit VPI VCI Traffic descriptor
9

Admin state

Link A

100

Unlocked

16 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Service provisioning

Table 6.

ATM parameters, ADSL through an OC-3STM-1 tributary unit (cont.) VPI VCI Traffic descriptor
9

Slot

Port

Admin state

Link Z

1-4

15

400

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.

POTS Network POTS Splitter ADSL OC-12/ STM-4 D500

ATM Network
Internet

POTS + Splitter Internet Service Provider CPE SOHO or Residential User

Figure 3.

ADSL service for SOHO and residential users

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

17 (252)

Provisioning

Table 7.

DSL parameters, ADSL SOHO service through an OC-12/STM-4 trunk ATU-C


512 512 None (fixed)

Rate
Interleave max (kbit/s) Interleave min (kbit/s) Mode

ATU-R
512 512

Table 8.

ATM parameters, ADSL SOHO service through an OC-12/ STM-4 trunk VPI VCI Traffic descriptor
9 9

Slot

Port

Admin state

Link A Link Z

1 11

1 1

0 15

100 360

Unlocked -

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-4 trunk ATU-C
256 32 Startup (rate adaptive)

Rate
Interleave max (kbit/s) Interleave min (kbit/s) Mode

ATU-R
128 32

18 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Service provisioning

Table 10.

ATM parameters, ADSL home user service via an OC-12/ STM-4 trunk VPI VCI Traffic descriptor
9 9

Slot

Port

Admin state

Link A Link Z

2 11

1 1

0 15

100 380

Unlocked -

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.

Corporate LAN

D500 IP/ATM Network

SHDSL

OC-3/STM-1

Internet

Internet Service Provider

PBX
PCM
IAD

Analog Voice

POTS Network

Inter-Exchange Carrier Enterprise Users

Figure 4.

SHDSL service for small and medium size enterprises

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

19 (252)

Provisioning

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

Table 11. Rate


Max (kbit/s) Min (kbpit/s) Mode

DSL parameters, SHDSL through an OC-3/STM-1 trunk STUC


512 512 None (fixed)

Table 12. Slot Port

ATM parameters, SHDSL through an OC-3/STM-1 trunk VPI VCI Traffic descriptor
9 9

Admin state

Link A Link Z

3 11

1 1

0 15

100 400

Unlocked 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Service provisioning

POTS Network POTS Splitter VDSL OC-12/ STM-4 VDSL D500

IP/ATM Network
Internet

POTS + Splitter Internet Service Provider

CPE
SOHO or Residential User

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 or Interleave

Band plan 997_2B 997_3B


64

998_2B
64

998_3B
64

Minimum upstream (kbit/s) Maximum upstream (kbit/s) Minimum downstream (kbit/s) Maximum downstream (kbit/s) Mode

64

10048

25024

3008

10048

64

64

64

64

10048

25024

22016

45056

RADSL

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

21 (252)

Provisioning

22 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

2
2.1

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

Note
D500 ADSL line cards include the following code suffixes for identification: a indicates that the card is Annex A compliant, b indicates that the card is Annex B compliant, f indicates that this line card has front mounting cable or loop terminations, 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 Subscriber Line) lines using Discrete Multi-Tone (DMT) modulation technique. The card supports full-rate (G.DMT/ANSI) ADSL and is provisionable on an individual port basis. Key differences between G.DMT/ANSI, ADSL2, ADSL2+, and READSL2 are shown in the table below:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

23 (252)

Provisioning

Table 14.

Mode differences ADSL2


25 kHz to 1104 kHz 255

G.DMT/ANSI
Frequency spectrum used Number of the highest bin used 25 kHz to 1104 kHz 255

ADSL2+
25 kHz to 2208 kHz 511

READSL2
25 kHz to 552 kHz 127

2.1.1

ADSL profiles
It is possible to create line profiles that can be applied to ADSL ports of the same type. The New DSL Line Profile dialog box is found by selecting Node Views 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 name the profile. Define the following parameters for the profile: the ATUC and ATUR 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 by selecting Port 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 new profiles, you can assign more ports to them in the following way: Select the profile on the DSL Line Profile tab => Configure => Modify Line Profile => Associations. If you want to assign several ports for the profile, 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 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 => Rates tab and select the desired profile from the drop-down menu.

24 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

2.1.2

Alarm thresholds profiles


It is possible to create DSL alarm thresholds profiles that can be applied to ADSL ports of the same type. The New DSL Alarm Thresholds Profile dialog box is found by selecting Node Views and clicking the node icon => Profiles tab => DSL Alarm Thresholds Profiles tab => Configure menu => New Alarm Profile command. In the New DSL Alarm Thresholds Profile dialog box, name the alarm thresholds profile and define the failure thresholds and frame thresholds. You can also import the parameters of another port or profile to the new profile by selecting Port 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 the following way: Select the profile on the DSL Alarm Thresholds Profile tab => Configure => Modify Alarm Profile => Associations. If you want to assign several 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 profile start 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 must undergo a training sequence at the line card port. ADSL ports have three basic operational modes:
.

Idle mode The ADSL port transmitter and receiver are locked and disabled.

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

Data mode The ADSL port connection is established and opened for transmission of ATM data traffic

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

25 (252)

Provisioning

The signal quality of the ATUR *) and ATUC channels are determined early in the training process. This is one of the first and most critical steps in the establishment of an ADSL data connection because it determines the data rates that can be supported on a given local loop facility. After the channels are established, their quality, combined with other provisioned settings, determines the actual data rate delivered. *) The terms ADSL Transceiver Unit  Central Office (ATUC) and ADSL Transceiver Unit  Remote (ATUR) are used in DMT ADSL provisioning to describe 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. If Interleave Rate is used, Reed-Solomon can also correct error bursts. The default mode is Interleave Rate. This is because the Interleave mode provides a more robust and reliable service. However, Fast Rate mode may be preferable for latency sensitive applications.
Interleave and Fast Rates

Table 15. Line cards ATUR Range

Parameters for Interleave and Fast Rates ATUC

Default for the max. setting


1024

Default for the min. setting


32

Range

Default for the max. setting


8128

Default for the min. setting


32

ADSL48af, ADSL48bf

32 1024 kbit/s 32 1024 kbit/s 32 1088 kbit/s

32 8128 kbit/s 32 10816 kbit/s 32 kbit/s 32,736 Mbit/s

ADSL48aft, ADSL48art

1024

32

8128

32

ADSL2+af, ADSL2+bf

1088

32

32,736

32

26 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Rate Degraded threshold

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

The default value of the LPort Tx Rate is the downstream capacity of a card divided by the number of the ports. For example the default value of the LPort Tx Rate for the ADSL2+af card is 500 Mbit/s : 48 = 10,416 Mbit/s. The value of the Lport should equal or be less than the ADSL downstream speed so that QoS would function properly. The Lport configuration can be disabled with the Best Effort 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 for the 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 the quality of the line (taking into account the Noise Margin provisioned for the port) and determines the best RADSL upstream 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 best transmit rate (see the figure below).

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

27 (252)

Provisioning

Figure 6.

Transmit rates

A Rate Degraded condition is displayed by Craft Terminal if the actual transmit rate is below the provisioned Rate Degraded threshold.
None (fixed rate training)

The ADSL port trains to the maximum rates provisioned for either the Fast Rate or Interleave Rate ATUR and ATUC channels, depending on which rate mode is in use. The port has an LOS (Loss of Signal) condition until training at the fixed rate is successful.
Target Noise Margin

This parameter sets the margin (in dB) for both ATUR and ATUC used during RADSL and fixed rate training processes. The Target Noise Margin parameter establishes the amount that noise can increase on the line for the channel to operate at 107 BER (Bit Error Rate). A larger margin lowers the rate, but increases the lines 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 excess channel capacity is used to increase the margin if the port can train to the maximum rate; in this case the actual margin is higher than the provisioned margin. Target Noise Margin parameters are provisionable for both ATUR and ATUC. The range is from 0 dB to 15 dB; the default is 6 dB.

28 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

ATUC Operation Mode

This parameter allows the user to set the operational standard for the port. For ADSL48af 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 the CPE modem. Refer to the Actuals tab after training is complete to see the actual Operation Mode selected. In the Advanced Auto mode, the port first starts training using the Auto as an operation mode. If training does not succeed within 90 seconds, training is restarted using the ANSI operation mode. If training does not succeed within 90 seconds in the ANSI mode either, the operation mode is changed to gDMT. If training does not succeed in the gDMT mode within 90 seconds, training is restarted using the Auto mode again. This sequence is repeated until the line is up and running. This mode is designed to be used only with CPEs, which are not able to do proper handshaking. The Auto mode is the recommended mode of operation. When the Auto mode is selected on ADSL2+af or ADSL2+bf, the ATUC connects automatically in the ADSL2+, READSL2, ADSL2 or ADSL mode, depending on the loop and ATUR capability. 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 the ADSL2+, ADSL2 or ADSL mode, depending on the ATUR capability. This mode can be used to prevent the ATUC from connecting in the READSL2 mode. When the READSL2 mode is selected, the ATUC connects automatically in the READSL2, ADSL2, or ADSL mode, depending on the ATUR capability. This mode can be used to force the line into the READSL2 mode if the ATUR supports it. If the ATUR does not support READSL2, then the ADSL2 or ADSL mode will be used. When the the ADSL2 mode is selected, the ATUC connects automatically in the ADSL2 or ADSL mode, depending on the ATUR capability. This mode can be used when connecting in neither ADSL2+ nor READSL mode is desirable. When the ADSL mode is selected, the ATUC connects in the ADSL mode.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

29 (252)

Provisioning

Note
In the ADSL mode the connection can be in either T1.413 (ANSI) or G.DMT mode, 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 result from the training process. The following ADSL parameters, except Error Alarms, affect port operation during the data mode:
ATUC and ATUR Interleave Delay

This parameter allows the user to increase or decrease the delay (latency) at both the ATUC and ATUR channels. By adjusting latency in the loop, you increase or decrease the immunity to impulse noise. In general, the lower settings are used for latency-sensitive voice transmissions, and the higher settings are for data. This applies to the Interleave Rate operation only. The maximum value of the delay can be set for both ATUC and ATUR. The setting options are 1 ms, 2 ms, 4 ms, 8 ms, 16 ms, 32 ms and 64 ms; the default setting is 32 ms for the ATUC and 16 ms for the ATUR. If the provisioned setting cannot be attained, the parameter is rounded down to the 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 ms for 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 Trellis Coding. Automatic coding is normally enabled for automatic bit allocation. When Automatic Coding Gain is disabled, the gain can be set manually. The range is 0 to 7 dB in 1 dB increments.

30 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Trellis Coding

This parameter enables Trellis Coding, a method of forward error correction which combines convolutional coding and modulation. This allows the user to meet performance margin requirements for long loops, or increase the transmission throughput under a specified performance margin. It provides increased 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 is disabled, 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 second allowed during the data mode before the ADSL port retrains. The range is 1 to 60 seconds, and the default is 10; the inactive setting is 0.
Error Alarm

This ATUC parameter sets the number of near-end errored frames per second allowed during the Data mode before an event (alarm) is sent to Element Manager.
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 provisioning parameters.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

31 (252)

Provisioning

Table 16. Parameter

ATUR provisioning parameters Values


321024 321088

Units
kbit/s

Defaults
1024 1088

Maximum Rate *)

Minimum Rate *)

321024 321088

kbit/s

32

Target Noise Margin Interleave Delay

015 164

dB ms

6 16

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

Table 17. Parameter

ATUC provisioning parameters Values


328128 32 kbit/s32,736 Mbit/s

Units
kbit/s Mbit/s

Defaults
8128 32,736

Maximum Interleave Rate *)

Minimum Interleave Rate *)

328128 32 kbit/s32,736 Mbit/s

kbit/s Mbit/s

32

Target Noise Margin Interleave Delay Error Retrain Threshold

015 164 160

dB ms Errors/Sec

6 32 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, except where noted. Daily and 15-minute thresholds can be set for the ATUC unit.

32 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

LOF Seconds thresholds

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

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

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

Note
The LOF, LOS and LPR conditions are mutually exclusive, and are reported in the 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. The LCD Seconds threshold settings are the number of seconds during which an LCD condition was present. An event is reported to Craft Terminal when the LCD Seconds threshold is crossed.
LOF Retrains

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

33 (252)

Provisioning

Error Rate Retrains

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

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

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

Table 18. Parameter

LOS, LOF, LPR, LCD and Errored Seconds parameters Daily values Units Defaults

15-minute values
1900 1900 1900 1900

Loss of Frame (LOF) Loss of Signal (LOS) Loss of Power (LPR) Loss of Cell Delineation (LCD) NE and FE Errored Seconds Threshold

186400 186400 186400 186400

Seconds Seconds Seconds Seconds

0 0 0 0

1900

186400

Seconds

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. The Coding Violation parameters have thresholds for reporting an event to Craft Terminal.

34 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

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. Parameters Upstream data rate


Daily settings

ATUC Coding Violation threshold settings Sensitivity to CV errors 640000

Threshold settings based on data rates 32000 64000 320000

270000 28000 2800 280 28

530000 55000 5600 560 56 5500 580 58 6 1

2200000 270000 28000 2800 280 23000 2800 290 29 3

3500000 530000 55000 5600 560 36000 5500 580 58 6

Low Medium Low Medium Medium High High Low Medium Low Medium Medium High High

15-minute settings

2800 290 29 3 0

2.1.9

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

35 (252)

Provisioning

Noise Margin: Actual amount of noise margin measured on the ATUR and ATUC 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 end over 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 in dBm. Transmit Rate: Actual ATUR and ATUC data rate for the channel; this rate is either fixed or determined by the ADSL port during the training process. See Startup (RADSL training for more information on the RADSL training process. Previous Transmit Rate: Recorded upon termination of a successful data transport session; reports the rate according to whether the line is trained or not trained:
.

Not Trained  the rate achieved by the most recent successful training Trained  the rate achieved by the most recent successful link-up prior to the current link-up.

Best Transmit Rate: Highest rate the port has linked up at successfully. If it is less than the Transmit Rate after training, the port copies in the Transmit Rate value. 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 maximum provisioned rate if the line is not limited. Best Maximum Achievable Rate: Highest rate supportable by the loop. If it is less than the Maximum Achievable Transmit Rate after training, the port copies in the Maximum Achievable Transmit Rate value. Cells Received: Number of valid, non-idle cells received on the line card port from the CPE since the card was reset. Cells Transmitted: Number of valid, non-idle cells received from the line card and 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

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 an LOF 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 LOFS condition. LOS Seconds: Total number of seconds during which the port detects an LOS condition. LPR Seconds: Total number of seconds during which the port detects an LPR condition. LCD Seconds: Total number of seconds during which the port detects an LCD condition. Errored Seconds: Total number of seconds the near-end detected frame CRC errors. Coding Violations: Coding violations detected by the near-end. FE Errored Seconds: Total number of seconds the far-end detected frame CRC errors 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.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

37 (252)

Provisioning

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, and attempted 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 the provisioning 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 15minute 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 performance monitoring interval of the preceding day. Error Retrains: Number of ADSL port retrains (based on near-end errored frames per second allowed during the data mode). FE Error Retrains: Number of ADSL port retrains (based on far-end errored frames per second allowed during the data mode).

2.2

SHDSL provisioning
This document describes the provisioning parameters and operation of the D500 SHDSL24 (Single-pair High-speed Digital Subscriber Line) line card. Details are provided 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 transmission using multi-level Trellis Coded Pulse Amplitude Modulation (TC-PAM) line encoding.

Note

38 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

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 the same type. The New DSL Line Profile dialog box is found by selecting Node Views 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 name the profile. Define the following parameters for the profile: the STUC data rates, RADSL mode, and noise margins. You can also import the parameters of another port or profile to the new profile by selecting Port 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 new profiles, you can assign more ports to them in the following way: Select the profile on the DSL Line Profile tab => Configure => Modify Line Profile => Associations. If you want to assign several ports for the profile, 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 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 => Rates tab 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 to SHDSL ports of the same type. The New DSL Alarm Thresholds Profile dialog box is found by selecting Node Views and clicking the node icon => Profiles tab => DSL Alarm Thresholds Profiles tab => Configure menu => New Alarm Profile command. In the New DSL Alarm Thresholds Profile dialog box, name the alarm thresholds profile and define the failure thresholds and frame thresholds. You can also import the parameters of another port or profile to the new profile by selecting Port 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.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

39 (252)

Provisioning

When you have created alarm profiles, you can assign more ports to them in the following way: Select the profile on the DSL Alarm Thresholds Profile tab => Configure => Modify Alarm Profile => Associations. If you want to assign several 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 profile start 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 range of 144 to 2304 kbit/s. With the E1 CES feature the data rate can be set to 2312 kbit/s.
Pair bonding

This feature is used to select two ports to establish a single ATM connection. Pair bonding doubles the transmission bandwidth by using 4-wire pairs between the DSLAM and CPE instead of 2-wire pairs. Pair bonding is supported only in the fixed mode. In other words, in provisioning the SHDSL ports the RADSL Mode must be set to none. Adjacent odd-numbered and even-numbered ports are bonded together, the oddnumbered port always coming first. For example, you can bond together ports 1 and 2, 3 and 4, 5 and 6, and so on. Pair bonding is accomplished by provisioning the even ports only. Also the connection should be created on the even ports only. For example, if you bond together 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 of the "slave" port can be viewed only.

Note
SHDSL24 features are available only with compatible CPE.

40 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

2.2.4

STUC and STUR terminology


The terms SHDSL Transceiver Unit  Central Office (STUC) and SHDSL Transceiver Unit  Remote (STUR) are used in SHDSL24 provisioning to describe 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 operational modes: 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. The SHDSL24 port is attempting to establish a connection with CPE during the training mode. Training time is approximately 20 seconds. Data: The SHDSL24 port connection to the CPE is established, and payload 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 and payload 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 port in kilobits per second. The setting options are in the range of 144 to 2304 kbit/s; the default setting is 2304 kbit/s. With the E1 CES feature the data rate can be set to 2312 kbit/s.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

41 (252)

Provisioning

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

CES

Circuit emulation service (CES) is supported for user rates up to 2048 kbit/s (a full E1 rate). The SHDSL standard specifies that byte synchronisation is maintained between the ATM and SHDSL payload. Since byte synchronisation is not possible in E1 transport, the operator must ensure that the intended CPE can support full E1 CES over SHDSL. ATM CES adds approximately 13 % overhead to the signal. The SHDSL rate to be 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 than BWSHDSL is selected. This enables byte synchronisation. For full E1 transport the E1 CES setting is 2312 kbit/s. It is recommended to check that the CPE can support full E1 CES (data rate 2312 kbit/s or sometimes given 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. The SHDSL24 port supports the following training modes for the STUR and STUC channels:
.

None (fixed rate mode) In this mode (fixed), the STUC is set at the provisioned rate using maximum and minimum rates. Using the G.handshake protocol*), the STUC communicates the provisioned data rate to the STUR and they attempt to link at that rate. Training continues until the configured rate is reached. If the maximum rate is equal to the minimum rate, the CPE attempts to train to that fixed provisioned rate. If unsuccessful, no link is

42 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

established with the port, training restarts, and the port remains in the LOS condition. If the maximum rate is greater than the minimum rate, the CPE attempts to train to the maximum rate and if unsuccessful, falls back to the minimum 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 minimum data rates. Using the G.handshake protocol, the STUC and STUR alternately send line probing signals to evaluate the loop quality. When the STUC and STUR have obtained sufficient information on the loop quality, they each decide the rate that the loop can support. This information is exchanged between the STUC and the STUR using the G.handshake protocol. The STUC and STUR then train at the highest rate that both can support. If the highest rate the loop can support is greater than the provisioned maximum rate, the STUC and the STUR train at the provisioned maximum rate. If the highest rate the loop can support is lower than the provisioned minimum rate, no link is established, training restarts, and the port remains in 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 which the port will operate at an error rate of 10-7 BER and the set noise margin in dB. 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 local loop length supported for a provisioned fixed STUC/STUR data rate. This is available for both the STUC and the STUR sides of the connection. The default value is 6 dB.

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

43 (252)

Provisioning

Both Target Noise Margin and Worst Case Noise Margin can be enabled and disabled independently. The Target Noise Margin is enabled by default and the Worst 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 port retrains. The inactive Error Retrain threshold setting is 0, the default setting 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 Alarm condition is reported to Element Manager and Craft Terminal. The inactive Error Alarm Threshold setting is 0, the default setting is 0. This parameter does not affect port operation.

Rate Degraded (kbit/s) The Rate Degraded threshold rate should be set at or below the STUC provisioned rate. When the actual transmission rate drops below this rate, a Rate Degraded condition is generated in Element Manager and Craft Terminal. 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 card divided by the number of the ports. For example the default value of the LPort Tx Rate for the ADSL2+af card is 500 Mbit/s : 48 = 10,416 Mbit/s. The value of the Lport should equal or be less than the ADSL downstream speed so that QoS would function properly. The Lport configuration can be disabled with the Best Effort 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 for optimal performance. Auto is the default and recommended setting. When set to Manual, the following configuration parameters must be set.

44 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

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-kHz timing signal derived from the node clock is transferred over the SHDSL line to the CPE. If the NTE mode is supported by the CPE, the CPE can synchronise the outgoing 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 BackoffSelect this option to enable/disable downstream power reduction 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 Craft Terminal. They do not affect port operation. The default setting is 0 (zero) or inactive, 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 Coding Violation parameters have thresholds for reporting an event to Element Manager and Craft Terminal. The following table provides the expected number of STUC Coding Violation (CRC) errors in 15-minute and daily intervals*); they can be used as threshold settings. *) Coding Violation errors are single bit errors randomly distributed with a mean equal to the Bit Error Rate.

Note

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

45 (252)

Provisioning

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 Thresholds settings based on data rates (bit/s) 320000 640000
3500000 530000 5600 5600 560 36000 5500 580 58 6 Low Medium Low Medium Medium High High Low Medium Low Medium Medium High High

Parameters

Sensitivity to CV errors

Daily settings

2200000 27000 2800 2800 280

15-minute settings

23000 2800 290 29 3

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

46 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Table 21. Parameter

LOS, LOF, LCD and Errored Seconds parameters Daily value Unit Default

15-minute value
1900 1900 1900

Loss of Frame (LOF) Loss of Signal (LOS) Loss of Cell Delineation (LCD) Errored Seconds Threshold

186400 186400 186400

Seconds Seconds Seconds

0 0 0

1900

186400

Seconds

Failure Thresholds
.

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

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

Note
The LOF and LOS conditions are mutually exclusive, and are reported in the following priority: If LOS and LOF are present, LOS is reported. LOF is reported when it is the only condition.

LCD Seconds thresholds

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

47 (252)

Provisioning

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 LCD Seconds threshold settings are the number of seconds during which an LCD condition was present. An event is reported to Element Manager and Craft Terminal when the LCD Seconds threshold is crossed.
.

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

Error Rate Retrains Error Rate Retrains is the number of times a port has retrained due to excessive Near End errored frames. Coding Violation conditions include CRC (Cyclic Redundancy Check) errors. Error Rate Retrains are monitored during all operational modes. Daily and 15-minute thresholds can be set for the STUC unit. An event is reported to Element Manager and Craft 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 quality established over the existing telephone copper networkthe local loop. Actual transmission quality parameters provided by the SHDSL24 port include: Noise Margin: Level of noise in dB that the loop can tolerate before BER goes below 10-7 and modems retrain. This is available for both the STUC and STUR sides of the connection. Loop Attenuation: Overall signal power attenuation or decrease in power of the DSL signal over the local loop expressed in dB. The current measured difference between the transmit power level and the received power level at the far end of the loop is seen in the actuals for both the STUC and STUR sides of the connection. Transmit Power: This is available for both the STUC and STUR sides of the connection. Transmit Rate: Actual data rate set by training for the port. Previous Transmit Rate: Recorded upon termination of a successful data transport session; reports the rate according to whether the line is trained or not trained:

48 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Not Trained  the rate achieved by the most recent successful training Trained  the rate achieved by the most recent successful link-up prior to the current link-up.

Best Transmit Rate: Highest rate the port has since the last unit restart successfully linked up. If it is less than the Transmit Rate after training, the port copies in the Transmit Rate value. Payload Transmit Rate: Actual STUR and STUC payload rate, 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 maximum provisioned rate if the line is not limited. Best Maximum Achievable Rate: Best of the Maximum Achievable Rates since the card was reset. If it is less than the Maximum Achievable Transmit Rate after training, the port copies the Maximum Achievable Transmit Rate value. Cells Received: Number of valid, non-idle cells received on the line card port from the CPE since the card was reset. Cells Transmitted: Number of valid, non-idle cells received from the line card and 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 the training process. Receiver Gain is measured in dB, from 99.99 to +99.99 dB. A negative value indicates attenuation. Receiver Gain is measured for both channels. Received Blocks: Total number of blocks received on the line card port since the card was reset. Transmitted Blocks: Total number of blocks transmitted on the line card port since the card was reset.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

49 (252)

Provisioning

2.2.11

Error actuals
The SHDSL24 card counts the following performance items during the data mode: LOF (Loss of Frame) Failures: Loss of Frame errors since the line card was reset, or since the physical performance monitoring data was cleared. LOS (Loss of Signal) Failures: Loss of Signal errors since the line card was reset, or since the physical performance monitoring data was cleared. An LOS condition takes precedence over an LOF condition. LCD (Loss of Cell Delineations) Failures: Loss of Cell Delineation failure since the line card was reset, or since the physical performance monitoring data was cleared. 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 of Cell 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 port is in an LOF, LOS, and a CV condition on the near end. FE (Far End) Coding Violations: Counts the number of Cyclic Redundancy Check (CRC) errored frames received**) on the far end. HEC (Header Error Control) Errors: Number of received cells that have HEC errors detected in their header. FE HEC (Far End Header Error Control) Errors: Number of received cells that 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 to loss of frames.

50 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Training Starts: Total number of times a port has detected the CPE, and attempted to train up with the CPE since the last unit restart. The count will not increment if the CPE is not connected at the other end of the loop. This feature allows the user to determine whether the port cannot train to the CPE, or whether there is no CPE. Bad Provisioning Status: Number of out-of-range or invalid configuration values. FE (Far End) Error Retrains: Number of times the port had to retrain on the far end owing to errored frames. Error Retrains: Number of times the port had to retrain on the near end owing to errored frames.

Note
Not every performance monitoring counter has a performance monitoring threshold.

*) STUC Coding Violations are measured in Far End Block Error (FEBE). FEBE is the number of "received" frames that contain an FEBE bit set. The receiver end sets the FEBE when it "receives" a CRC error frame. The FEBE is cleared in the next 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. The receiver end sets the FEBE when it "receives" a CRC error frame. The FEBE is cleared in the next frame it transmits.

2.3

VDSL provisioning
This chapter describes VDSL provisioning parameters and the operation of the D500 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.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

51 (252)

Provisioning

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 and symmetric data rates and port assignments for upstream and downstream bandwidth. *) D500 VDSL24 line cards include the following code suffixes for identification: d indicates that the card is Annex D compliant, e indicates that the card is Annex E compliant, f indicates that this line card has front mounting cable or loop terminations, r indicates the card has rear mounting cable or loop terminations.

2.3.1

VDSL profiles
It is possible to create line profiles that can be applied to VDSL ports of the same type. The New DSL Line Profile dialog box is found by selecting Node Views 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 name the profile. Define the following parameters for the profile: the VTU-O and VTUR 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 by selecting Port 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 new profiles, you can assign more ports to them in the following way: Select the profile on the DSL Line Profile tab => Configure => Modify Line Profile => Associations. If you want to assign several ports for the profile, 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 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 => Rates tab and select the desired profile from the drop-down menu.

52 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

2.3.2

Alarm thresholds profiles


It is possible to create DSL alarm thresholds profiles that can be applied to VDSL ports of the same type. The New DSL Alarm Thresholds Profile dialog box is found by selecting Node Views and clicking the node icon => Profiles tab => DSL Alarm Thresholds Profiles tab => Configure menu => New Alarm Profile command. In the New DSL Alarm Thresholds Profile dialog box, name the alarm thresholds profile and define the failure thresholds and frame thresholds. You can also import the parameters of another port or profile to the new profile by selecting Port 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 the following way: Select the profile on the DSL Alarm Thresholds Profile tab => Configure => Modify Alarm Profile => Associations. If you want to assign several 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 profile start 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 must undergo a training sequence at the line card port. VDSL24 ports have three basic operational states:
.

Idle mode: The VDSL24 port transmitter and receiver are locked and disabled. Training mode: Training starts when the VDSL24 port is unlocked. The VDSL24 port is attempting to establish a connection with CPE equipment during the training mode. Data mode: The VDSL24 port connection is established and opened for transmission of ATM data traffic.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

53 (252)

Provisioning

2.3.4

Rate modes
Latency path selection

Fast Rate is designed to correct random errors rather than bursts of errors. If Interleave Rate is used, Reed-Solomon can also correct error bursts. The default mode is Interleave Rate. This is because the Interleave mode provides a more robust and reliable service in response to variable loop conditions. However, Fast Rate mode may be preferable for latency sensitive applications.
Maximum and minimum fast rates

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

Table 22. Band plan


# of bands # of ports Start frequency [kHz] Stop frequency [kHz] Default for maximum downstream [kbit/s] Maximum downstream [kbit/s] Default for minimum downstream [kbit/s] Minimum downstream [kbit/s] Default for maximum upstream [kbit/s] Maximum upstream [kbit/s]

Maximum and minimum rates 997_3B


3 12 138 or 1104 8500 25024

997_2B
2 24 138 or 1104 4400 10048

998_2B
2 24 138 or 1104 4400 22016

998_3B
3 12 138 or 1104 8500 45056

23616

48384

23616

53760

64

64

64

64

64

64

64

64

10048

25024

3008

10048

13056

30464

5440

12288

54 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Table 22. Band plan


Default for minimum upstream {kbit/s] Minimum upspstream [kbit/s]

Maximum and minimum rates (cont.) 997_3B


64

997_2B
64

998_2B
64

998_3B
64

64

64

64

64

Maximum and minimum interleave rates

The range for both the minimum and maximum rate for the VTU-R and the default for the maximum setting of the VTU-R depend on the band plan, see the table above. The default for the minimum setting of the VTU-R and VTU-O is 64. The range for both the minimum and maximum rate for the VTU-O and the default for the maximum setting of the VTU-O depend on the band plan, see the table above.
Rate Degraded threshold

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

The default value of the LPort Tx Rate is the downstream capacity of a card divided by the number of the ports. For example the default value of the LPort Tx Rate for the ADSL2+af card is 500 Mbit/s : 48 = 10,416 Mbit/s. The value of the Lport should equal or be less than the ADSL downstream speed so that QoS would function properly. The Lport configuration can be disabled with the Best Effort 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 at startup. The port training modes supported by the VDSL24 line card are Rate Adaptive DSL (RADSL) and fixed rate training. The setting is either Startup or None.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

55 (252)

Provisioning

Startup (RADSL training)

During the training process, the port measures the quality of the line (allowing for the Noise Margin provisioned for the port) and determines the best RADSL upstream 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 best transmit 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 Fast Rate or Interleave Rate VTU-R and VTU-O channels, depending on which rate mode is in use. The port has LOS (Loss of Signal) condition until training at the fixed rate is successful.
Target Noise Margin

This parameter sets the margin (in dB) for VTU-O used during RADSL and fixed rate training processes. The Target Noise Margin parameter establishes the amount 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 lines immunity to noise.
.

The VDSL24 port will train to the maximum data rate supportable on the line, while operating within the provisioned Target Noise Margin parameter, and maintaining the bit error rate at 10-7 BER. The actual and provisioned margins should be approximately equal. Any excess channel capacity is used to increase the margin if the port can train to the maximum rate; in this case the actual margin is higher than the provisioned margin. Target Noise Margin parameters are provisionable for VTU-O. The range is 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 directs the modem.

56 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

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 and payload cells start to flow. The following VDSL24 parameters, except Error Alarms, affect port operation during the data mode. If the setting of any of these parameters is changed, the connection 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) in both the VTU-O and VTU-R channels. By adjusting latency in the loop, you increase or decrease the immunity to impulse noise. In general, the lower settings are used for latency-sensitive voice transmissions, and the higher settings are for data. This applies to the Interleave Rate operation only. Maximum parameters can be set for both VTU-O and VTU-R. The setting options are 0 ms 1 ms, 2 ms, 4 ms, 8 ms, 16 ms, 32 ms and 64 ms; the default setting is 16 ms for VTU-O and 16 ms for VTU-R. If the provisioned setting cannot be attained, the parameter is rounded down to the nearest available setting.
Error Retrain threshold

This VTU-O parameter sets the number of near end errored frames per second allowed during the data mode before the VDSL24 port retrains. The range is 1 to 60 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 Rate and Interleave Rate, for Forward Error Correction (FEC) in both upstream and downstream directions. Reed-Solomon Fast Rate is designed to correct random errors rather than bursts of errors. If Interleave Rate is used, Reed-Solomon can also correct error bursts.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

57 (252)

Provisioning

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 both asymmetrical and symmetrical throughput.
Band configuration

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

Table 23. ANSI


RFI 1 (18102000 kHz) RFI 2 (35004000 kHz) RFI 3 (70007300 kHz)

RFI bands: ETSI


RFI 1 (18102000 kHz) RFI 2 (35003800 kHz) RFI 3 (70007100 kHz)

Start Tones

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

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

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

2.3.7

VTU-R/VTU-O channel parameter values


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

58 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Table 24. Parameter

VTU-O provisioning parameters Value


031 031 031 164 160 160

Unit
dB dB dB ms Error/Sec Error/Sec

Default
6 1 28 16 0 0

Target Noise Margin Minimum Noise Margin Maximum Noise Margin Interleave Delay Error Retrain Threshold FE Error Retrain Threshold

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) and symmetrical (997) throughput. Band plans can be selected on the unit level: all the ports in one unit have the same band plan. Depending on the band plan selected, power will automatically be applied to all ports to achieve the required power spectral density (PSD) at the transmitting ports. The following band plans are available:

Table 25. No of ports Band plan MHz

VDSL24 band plans 0.40mm (26 AWG) Mbit/s


22/3 @ 3.6 Kft 16/1 @ 4.6 Kft

0.50 mm (24 AWG) Mbit/s


22/3@ 1.34 km (4.4 Kft) 16/1 @ 1.76 km (5.8 Kft)

998-025-U0-138-D1-3750-U1-4400  Asymmetric 24-port Refer to the figure below.

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)

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

59 (252)

Provisioning

Table 25. No of ports Band plan MHz

VDSL24 band plans (cont.) 0.40mm (26 AWG) Mbit/s


6/6 @ 3.8 Kft 52/11 @ 1.9 Kft 22/3 @ 3.7 Kft

0.50 mm (24 AWG) Mbit/s


6/6 @ 1.28 km (4.2 Kft) 52/11 @ 0.73 km (2.4 Kft) 22/3 @ 1.46 km (4.8 Kft)

998-138-D1-3750-U1-5200-D2-8500  Asymmetric Refer to the figure below.

12-port 997-138-D1-3000-U1-5100-D2-7050 U2 8500  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)

UP 0
0.025 0.138 unoccupied

DOWN 1

UP 1
3.75 4.40 MHz

UP 0
0.025 0.138 unoccupied

DOWN 1
3.00

UP 1
4.40 MHz

Figure 8.

24-port band plans

60 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

UP 0
0.138

DOWN 1
3.75

UP 1
5.20

DOWN 2
8.50 MHz

UP 0
0.138

DOWN 1
3.00

UP 1
5.10

DOWN 2
7.05

UP 2
8.50 MHz

Figure 9.

12-port band plans

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

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

The configurations of the shaded (not used) ports can only be viewed. The data rates of the manageable ports change in accordance with the rates of the new band plan. 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 is intended for the deployment scenario where VDSL is deployed from the cabinet and 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 the correct PSD mask ensures that VDSL is spectrally compatible with other DSL services in the same cable.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

61 (252)

Provisioning

2.3.9

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

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

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

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

LOF Retrains is the number of times a port has retrained due to LOF. An event is reported 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 Near End errored frames. Coding Violation conditions include CRC (Cyclic Redundancy Check) errors. Error Retrains are monitored during all operational modes. An event is reported to Craft Terminal when the Error Retrains threshold is crossed.
Errored Seconds thresholds

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

62 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Table 26. Parameter

LOS, LOF, LCD and Errored Seconds parameters Daily value Unit Default

15-minutes value
1900 1900 1900

Loss of Frame (LOF) Loss of Signal (LOS) Loss of Cell Delineation (LCD)

186400 186400 186400

Seconds Seconds Seconds

0 0 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 Coding Violation parameters have thresholds for reporting an event to Craft Terminal. The following table provides the expected number of VTU-O Near and FE 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.

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

Table 27. Parameter

VTU-O Coding Violation threshold settings Sensitivity to CV errors

Threshold settings based on data rates (bit/s) 32000


270000 28000

64000
530000 55000 5600 560

320000
2200000 270000 28000 2800

640000
3500000 530000 55000 5600 Low Medium Low Medium Medium High

Daily settings 2800 280

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

63 (252)

Provisioning

Table 27. Parameter

VTU-O Coding Violation threshold settings (cont.) Sensitivity to CV errors

Threshold settings based on data rates (bit/s) 32000


28 2800 290

64000
56 5500 580 58 6 1

320000
280 23000 2800 290 29 3

640000
560 36000 5500 580 58 6 High Low Medium Low Medium Medium High High

15-minute settings

29 3 0

2.3.10

Actuals
The VDSL24 port can measure channel quality established over the existing telephone copper network (the local loop). The VDSL24 port reports actuals since the card or the counter was reset or for the following operational parameters: Noise Margin: Actual amount of noise margin measured on the VTU-R and VTU-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 end over 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 in dBm. Transmit Rate: Actual VTU-R and VTU-O data rate for the channel; this rate is either fixed or determined by the VDSL24 port during the training process. Previous Transmit Rate: Recorded upon termination of a successful data transport session; reports the rate according to whether the line is trained or not trained.
.

Not Trained  the rate achieved by the most recent successful training Trained  the rate achieved by the most recent successful link-up prior to the current link-up.

64 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Best Transmit Rate: Highest rate the port has linked up at successfully. If it is less than the Transmit Rate after training, the port copies in the Transmit Rate value. Payload Transmit Rate: Actual VTU-R and VTU-O payload rate for the channel, calculated by subtracting the ATM cell overhead from the Transmit Rate. Cells Received: Number of valid, non-idle cells received on the line card port from the CPE since the card was reset. Cells Transmitted: Number of valid, non-idle cells received from the line card and 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, and attempted 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 card was reset. Transmitted Blocks: Number of blocks transmitted on the line card port since the 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.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

65 (252)

Provisioning

FE LOF (RDI) Failures: Far-end Loss of Frame  LOF-FE failure is declared after 2.5 0.5 s of a contiguous RDI defect, except when a far-end LOS defect or failure is present (see the LOS definition). A far-end LOF failure is cleared when a 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 an LOF 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 LOFS condition. LOS Seconds: Total number of seconds during which the port detects an LOS condition. LCD Seconds: Total number of seconds during which the port detects an LCD condition. 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 CRC errors. Coding Violations: Coding violations detected by the near-end. Error Retrains: Number of VDSL24 port retrains (based on near-end errored frames per second allowed during the data mode). FE Error Retrains: Number of VDSL24 port retrains (based on far-end errored frames per second allowed during the data mode). Elapsed Time (Current 15 minutes): Total amount of time in the current 15minute 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 performance monitoring interval of the preceding day. FE HEC Errors: Far-end HEC errors on this DSL port.

66 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

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 OC3/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 SH1310-nm multimode fiber/medium power interface for short range operation (2 km or 1.25 miles) OC-3/STM-1 SM SH1310-nm singlemode fiber/low power interface for long range operation (15 km or 9.3 miles) OC-3/STM-1 SM LH1310-nm singlemode fiber/high power interface for 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 line cards (in a 17-slot D500 subrack) or 19 line cards (in a 21-slot D500 subrack) into the OC-12/STM-4 trunk. The tributary unit supports four OC-3/STM-1 tributary interfaces, with three variations:
.

OC-3/STM-1 MM SHMulti mode fiber/medium power interface for short range operation (2 km or 1.25 miles) OC-3/STM-1 SM SHSingle mode fiber/low power interface for medium range operation (15 km or 9.3 miles) OC-3/STM-1 SM LHSingle mode fiber/high power interface for long range operation (40 km or 25 miles).

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

67 (252)

Provisioning

Section 1 comprises slots 15 Section 2 comprises slots 610 Section 3 comprises slots 1317. Section 4 comprises slots 1721.

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.707 compliant 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 address translation, 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 interface for connecting another D500 node, ATM switch, D50(e) or a third-party DSLAM to the D500 node. It can also be used as an additional trunk for traffic balancing purposes. 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 using Craft Terminal and the command line interface (CLI). For details on the user interface, 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/control unit and the OC-3/STM-1 facility type setting on the tributary unit must match the parameters set on the far-end ATM router or switch. The default setting depends 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 of thresholds for near-end and far-end performance parameters. The following parameters affect port operation, and can be set for both 15-minute and daily intervals:

68 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

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

Coding Violations is the count of CP-bit parity errors occurring in the accumula-tion period. Errored Seconds is the count of seconds containing one or more CP-bit parity errors, one or more SEF defects, or one or more AIS defects. Severely Errored Seconds is the count of seconds containing more than 44 CP-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 the OC-12/STM-4 or OC-3/STM-1 path is unavailable. Severely Err. (errored) Framing Seconds is the count of seconds containing one or more SEF defects or one or more AIS defects.

The BERT (Bit Error Rate Threshold) group allows you to set thresholds for the Signal 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. Line/Path/ Section Acronym

Near-end performance parameters Meaning Daily interval 15-minute interval

CV

Line

Coding Violations: Count of BIP errors (using B2 byte) occurring in the accumulation period. Up to 8XN BIP errors can be detected per STM-1 or STN-N frame, with each error incrementing the CV-L current second register

01,048,575 Default setting is 0 (inactive)

016383 Default setting is 0 (inactive)

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

69 (252)

Provisioning

Table 28. Line/Path/ Section Acronym

Near-end performance parameters (cont.) Meaning Daily interval 15-minute interval

ES

Errored Seconds: Cound of seconds containing one or more Line Layer BIP errors or an AIS-L defect was present. Severly Errored Seconds: Count of seconds containing 2,500 or more Line Layer BIP errors or an AIS-L defect was present. Unavailable Seconds: Count of one second intervals during which the Line is unavailable. The Line is unavailable at the onset of 10 contiguous SES-Ls. The 10 SES-Ls are included in unavailable time and since it is not known until the tenth second that unavailable time started ten seconds ago, the counts for all the parameters must be adjusted back to what they were ten seconds ago. Once unavailable, the Line becomes available at the onset of 10 contiguous seconds with no SES-Ls. The ten seconds with no SES-Ls are excluded from available time so the counts of the parameters do not need to be adjusted. Coding Violations: Count of BIP errors (using B3 byte) occurring in the

065535 Default setting is 0 (inactive)

0900 Default setting is 0 (inactive)

SES

065535 Default setting is 0 (inactive)

0900 Default setting is 0 (inactive)

UAS

065535 Default setting is 0 (inactive)

0900 Default setting is 0 (inactive)

CV Path

01,048,575 Default setting is 250

016383 Default setting is 25

70 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Table 28. Line/Path/ Section Acronym

Near-end performance parameters (cont.) Meaning Daily interval 15-minute interval

accumulation period. Up to 8 BIP errors can be detected per frame, with each error incrementing the CV-P current second register. ES Errored Seconds: Count of seconds containing one or more Path Layer BIP errors or an AIS-P or LOP-P defect was present. Severely Errored Seconds: Count of seconds containing 2,400 or more Line Layer BIP errors or when an AIS-P or LOPP defect was present. Unavailable Seconds: Count of one second intervals during which the Path is unavailable. The Path is unavailable at the onset of 10 contiguous SES-Ps. The 10 SES-Ps are included in unavailable time and since it is not known until the tenth second that unavailable time started ten seconds ago, the counts for all the parameters must be adjusted back to what they were ten seconds ago. Once unavailable, the Path becomes available at the onset of 10 contiguous seconds with no SES-Ps. The ten seconds with no SES-Ps are excluded from available time so the counts of the 065535 Default setting is 200 0900 Default setting is 20

SES

065535 Default setting is 7

0900 Default setting is 3

UAS

065535 Default setting is 10

0900 Default setting is 10

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

71 (252)

Provisioning

Table 28. Line/Path/ Section Acronym

Near-end performance parameters (cont.) Meaning Daily interval 15-minute interval

parameters do not need to be adjusted. SEFS Section Severely Errored Framing Seconds: Count of seconds containing one or more Severely Errored Framing (SEF) defects (defined as a time at which the incoming signal has a minimum of four consecutive errored framing patterns). A SEF defect is terminated upon detecting two successive error-free framing patterns. 065535 Default setting is 0 (inactive) 0900 Default setting is 0 (inactive)

Section

Table 29. Line/Path Acronym

Far-end performance parameters Meaning Daily interval 15-minute interval


016383 Default setting is 0 (inactive)

CV

Line ES

Coding Violations: Count of BIP errors (using REI-L indication in the Line Overhead) detected by the far-end LTE. Up to 8XN BIP errors can be indicated by the REI-L, with each error incrementing the CV-LFE current second register. Errored Seconds: Count of seconds containing one or more Line Layer BIP errors was reported by the far-end LTE (using the REI-L indication) or an RDI-L defect was

01,048,575 Default setting is 0 (inactive)

065535 Default setting is 0 (inactive)

0900 Default setting is 0 (inactive)

72 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Table 29. Line/Path Acronym

Far-end performance parameters (cont.) Meaning Daily interval 15-minute interval

present. SES Severely Errored Seconds: Count of seconds containing 2,500 or more Line Layer BIP errors reported by the far-end LTE (using the REI-L indication) or an RDI-L defect was present. Unavailable Seconds: Count of one second intervals during which the OC-3/STM-1 Line is unavailable at the farend. The far-end Line is unavailable at the onset of 10 contiguous SES-LFEs. The 10 SES-LFEs are included in unavailable time and since it is not known until the tenth second that unavailable time started ten seconds ago, the counts for all the parameters must be adjusted back to what they were ten seconds ago. Once unavailable, the Line becomes available at the onset of 10 contiguous seconds with no SES-LFEs. The ten seconds with no SES-LFEs are excluded from available time so the counts of the parameters do not need to be adjusted. Coding Violations: Count of BIP errors (using REI-P indication in the Path Overhead) 065535 Default setting is 0 (inactive) 0900 Default setting is 0 (inactive)

UAS

065535 Default setting is 0 (inactive)

0900 Default setting is 0 (inactive)

CV Path

01,048,575 Default setting is 250

016383 Default setting is 25

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

73 (252)

Provisioning

Table 29. Line/Path Acronym

Far-end performance parameters (cont.) Meaning Daily interval 15-minute interval

detected by the far-end PTE. Up to 8 BIP errors can be indicated by the REI-P, with each error incrementing the CVPFE current second register. ES Errored Seconds: Count of seconds containing one or more Path Layer BIP errors was reported by the far-end PTE (using the REI-P indication) or an RDI-P defect was present. Severely Errored Seconds: Count of seconds containing 2400 or more Path Layer BIP errors reported by the far-end PTE (using the REI-P indication) or an RDI-P defect was present. Unavailable Seconds: Count of one second intervals during which the Path is unavailable at the far-end. The Path is unavailable at the onset of 10 contiguous SES-PFEs. The 10 SES-PFEs are included in unavailable time and since it is not known until the tenth second that unavailable time started ten seconds ago, the counts for all the parameters must be adjusted back to what they were ten seconds ago. Once unavailable, the Line 065535 Default setting is 200 0900 Default setting is 20

SES

065535 Default setting is 7

0900 Default setting is 3

UAS

065535 Default setting is 10

0900 Default setting is 10

74 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Table 29. Line/Path Acronym

Far-end performance parameters (cont.) Meaning Daily interval 15-minute interval

becomes available at the onset of 10 contiguous seconds with no SES-PFEs. The ten seconds with no SES-PFEs are excluded from available time so the counts of the parameters do not need to be adjusted.

2.5

Gigabit Ethernet provisioning


The D500 Gigabit Ethernet trunk/control unit (TK1000, TKETH1G) is here shortened 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 range is 2550 m and with a 62.5/125-m fibre the range is 2275 m), duplex LC connector Singlemode (1310 nm), medium range (<10 km), duplex LC connector 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 use and active.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

75 (252)

Provisioning

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

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

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

2.5.1

Gigabit Ethernet interface specification


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

2.5.2

Interval sampling
D500 Craft Terminal and the CLI can sample and report historical data for predefined 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 is sampled and reported by the Ethernet trunk counters. The allowed sampling range is from 1 to 3600 seconds. It is important that interval time should not exceed the fill 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 is reported. The user can provision up to 576 intervals. Bin 1 is always the current interval being sampled. Interval Status is the status of data obtained during the current interval.

76 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

2.5.3

Ethernet actuals and performance thresholds


The user can set thresholds to the counters listed below. The thresholds define Ethernet performance thresholds at the Ethernet port. Thresholds are set and viewed in Craft Terminal or the CLI. An error is reported when the threshold is crossed. The Actuals tab page displays received and transmitted connectivity data at the port level. The information on the Actuals tab is read-only. The actuals below report values for Ethernet statistical data. These are the counters available for reporting statistical data and for which the user can set thresholds:
.

Total Octets Received: Total number of octets of data (including those in bad frames) received (exluding framing bits but including FCS octets). This includes the count of bytes from first byte of the destination address to the last byte of the FCS field. Transmitted: Total number of octets of data and padding (exluding preamble, SFD, destination/source address, length/type field, Q-Tag prefix, and FCS) octets of frames that are successfylly transmitted over the MAC interface.

Total Packets Received: Total number of frames that are successfully received. Transmitted: Total number of frames that are successfully transmitted over the MAC interface.

Unicast Packets Received: Total number of unicast packets successfully received. Transmitted: Total number of unicast packets successfully transmitted.

Non-Unicast Packets Received: Total number of frames that are successfully received and directed to a multicast or broadcast group. Transmitted: Total number of frames that are successfully transmitted to a multicast or broadcast address.

Discarded Packets

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

77 (252)

Provisioning

Received: Total number of received frames that are too long, too short, or contain a length error, or are classified as jabbers or fragments. Transmitted: Count of frames that would otherwise be transmitted by 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 the current frame without any further immediately following frames.

Errored Packets Received: Total number of received frames that are too long, too short, or contain a length error or an FCS error, or are discarded because of FIFO overrun physical device symbol error. Transmitted: Total number of frames that would otherwise be transmitted by the device but could not be sent because of an indication of an internal error.

Max BW Utilization Received: Shows the percentage of bandwidth used in the Rx direction. Transmitted: Shows the percentage of bandwidth used in the Tx direction.

Undersize Packets Received: Total number of frames received (excluding framing bits but including FCS octets) that are less than 64 octets.

Oversize Packets Received: Total number of packets received (excluding framing bits but including FCS octets) that are over 1518 octets.

Collisions Received: Count of received frames that are an integral number of octets in length and do not pass the FCS check This does no include frames 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 or received at the Ethernet trunk/control unit interface. Speed (Mbit/s): Transmission speed. An estimate of the current bandwidth in use by the interface. If the bandwidth does not change or cannot be estimated, this actual displays the nominal interface bandwidth.

78 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

MAC Address: MAC address of the D500 set by the Local IP Address parameter assigned in the VLAN View. Ageing Time: Time in seconds until MAC addresses are purged from the MAC Address Table if they are not in use. The MAC ageing time is set by the MAC Maximum Ageing Time parameter. MAC Utilization: Percentage of the total capacity of the forwarding MAC Address Table currently utilised. Locally Reset Counters: Resets the settings to 0.

2.6

DS3 provisioning
The following describes provisioning parameters and operation of the D500 trunk/control unit with DS3 interface (also referred to as TKDS3) and DS3 tributary 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) except that instead of an OC-3/STM-1 interface it supports a single DS3 aggregate interface. The DS3 trunk/control unit can multiplex and deliver traffic from up to 15 line cards (in a 17-slot D500 subrack) or 19 line cards (in a 21-slot D500 subrack) into the DS3 trunk. The DS3 tributary unit supports eight DS3 tributary interfaces. The maximum number of tributary units per subrack is four. The subrack is divided into four sections. There can be only one tributary unit per section:
.

Section 1 comprises slots 15 Section 2 comprises slots 610 Section 3 comprises slots 1316 Section 4 comprises slot 17 (in a 17-slot D500 subrack) or slots 1721 (in a 21-slot D500 subrack).

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

79 (252)

Provisioning

2.6.1

DS3 ATM interface specifications


The DS3 interface provides a GR-499 compliant metallic SONET interface for connecting the D500 system to the data network. It also provides egress address translation, multiplexing, and timing resources. The DS3 interface passes the ATM data stream to and from the ATM data network. The DS3 tributary interface provides an interface for connecting another D500 node, ATM switch, D50(e) or a third-party DSLAM to the D500 node. It can also be 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 the command line interface (CLI). For details on the user interface, see Web-based Craft Terminal .

2.6.2.1

Framing and ATM mapping options

Framing option defines the usage of overhead bits of the DS3 frame whereas the ATM mapping option defines the method of mapping of ATM cells to the DS3 frame payload. These options must match the configuration of the far end. There are two framing options: DS3 C-bit parity application and DS3 M23 application. The C-bit parity application is recommended whenever the far end supports it because it is equal in payload peformance and has more features than the M23 application. For example, far end alarms and far end performace monitoring are not available with M23. There are also two ATM cell mapping options to choose from: ATM direct mapping (ADM) and Physical Layer Convergence Protocol (PLCP). The PLCP provides an additional layer for fault and performance monitoring while sacrificing some payload bandwidth. The combined framing and ATM mapping options shown on the DS3 tab page in the 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

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. The option 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 is enabled by default.
2.6.2.3 HEC coset option

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

In the DS3 line equalisation Default is used for lines longer than 255 feet (77.7 m) 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 Source group:
.

Node clock selects the mode in which the DS3 port is synchronised to the DS3 node clock (also known as the system synchroniser) of the D500 node. Loop timing selects the mode in which the port uses the timing of its own received 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 and far-end performance parameters. The DS3 performace parameters are designed according to the ANSI standard T1.231. When a count exceeds a threshold, a threshold crossing warning appears on the management interface.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

81 (252)

Provisioning

The Physical PM tab page includes the following provisionable parameters in the Selection 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 a new window to show history information graphically. In monitoring the operation of DS3 ports, the user can select the PM data per interval, type, and bin. The Thresholds tab page allows the user to modify the following thresholds in 15minute or daily intervals per line, path or PLCP:
.

Coding Violations (CV) is the count of CP-bit parity errors occurring in the accumulation period. The threshold parameter x yields 10x errors threshold. Errored Seconds (ES) is the count of seconds containing one or more CPbit parity errors, one or more SEF defects, or one or more AIS defects. Severly Errored Seconds (SES) is the count of seconds containing 45 or more CP-bit (P-bit in the M23 application) parity errors, one or more SEF defects, or one or more AIS defects. Unavailable Seconds (UAS) is the count of one second intervals during which the DS3 path is unavailable. Severly Errored Framing Seconds (SEFS) is the count of seconds containing one or more SEF defects. SEF/AIS Seconds (SAS) is the count of seconds containing one or more SEF defects or one or more AIS defects.

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

Table 30. Parameter

BERT Default
6

Range
69

Signal Degrade Condition

82 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Table 30. Parameter

BERT (cont.) Default


3

Range
35

Signal Fail Condition

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. Line/Path/ PLCP Acronym

Performance parameters Meaning Daily interval 15-minute interval

CV-L

Count of bipolar violations (BPV) or excessive zeros (EXZ) anomalies during the interval Count of seconds during the interval in which one or more, but less than 45 CV-L errors have occurred Count of seconds during the interval in which 45 or more CV-L errors have occurred Count of seconds during the interval in which LOS defect has been active (defined in T1.231 as LOSS-L) Count of path anomalies during the interval: In the DS3 C-

Range: 610 Default: 9

Range: 610 Default: 9

ES-L

Range: 0 86400 Default: 250

Range: 0900 Default: 25

Line (NE) SES-L

Range: 0 86400 Default: 0 Range: 0 86400 Default: 0

0900 Default: 0

UAS-L

0900 Default: 0

CV-P Path (NE/FE)

Range: 610 Default: 9

Range: 610 Default: 9

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

83 (252)

Provisioning

Table 31. Line/Path/ PLCP Acronym

Performance parameters (cont.) Meaning Daily interval 15-minute interval

bit parity application the CP-bit parity errors are counted, and in the M23 application P-bit errors are counted as path anomalies. ES-P Count of seconds during the interval in which one or more, but less than 45 path anomalies have occurred Count of seconds during the interval in which 45 or more path anomalies have occurred Count of seconds during the interval in which the path has been unavailable: The path becomes unavailable after 10 continuous SES-Ps. The path becomes unavailable after 10 continuous seconds without SES-Ps Count of seconds for which the out-of-frame (OOF) or AIS defect has been active Count of PLCP BIP errors during the interval Count of seconds during the interval in which one or more, but less than 45 CVPLCPP errors have occurred Count of seconds during the interval in Range: 0 86400 Default: 250 Range: 0900 Default: 25

SES-P

Range: 0 86400 Default: 40

Range: 0900 Default: 4

UAS-P

Range: 0 86400 Default: 10

Range: 0900 Default: 10

SAS-P

Range: 0 86400 Default: 8 Range: 610 Default: 9 Range: 0 86400 Default: 250

Range: 0900 Default: 2

CVPLCP

Range: 610 Default: 9 0900 Default: 25

ESPLCP PLCP (NE/FE)

SEFS-PLCP

Range: 0 86400

Range: 0900

84 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Table 31. Line/Path/ PLCP Acronym

Performance parameters (cont.) Meaning Daily interval 15-minute interval

which 45 or more CVPLCPP errors have occurred UASPLCP Count of seconds during the interval in which the path has been unavailable: The PLCP path becomes unavailable after 10 continuous SESPLCPPs. The PLCP path becomes available after 10 continuous seconds without SESPLCPPs. Count of seconds for which the out-of-frame (OOF) or AIS defect has been active

Default: 40

Default: 4

Range: 0 86400 Default: 10

Range: 0900 Default: 10

SEFS-PLCP

Range: 0 86400 Default: 8

Range: 0900 Default: 2

2.7

E1 provisioning
The following describes the provisioning parameters and operation of the D500 E1 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 over E1 leased line replacement services. The E1 tributary unit (TBE1) provides 16 E1 ports.

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

85 (252)

Provisioning

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 stream over multiple physical links and to retrieve the original stream at the far-end from these physical links. The multiplexing of the ATM cell stream is performed on a cell by cell basis across the multiple physical links. The main inverse multiplexing function is to control the distribution of cells onto the group of physical links made available to the IMA interface. Other main functions include handling of differential delays and actions to be taken when links are added or dropped or when they are failed or need to be restored. In the receive direction, the IMA interface performs differential delay compensation and recombines the cells into the original cell stream while introducing minimal cell delay variation (CDV). In essence, the inverse multiplexing functions emulate a single UNI/NNI/BICI physical link; the IMA process of splitting and recombining streams is as transparent to the layer above as a traditional singlelink physical layer interface. The ATM inverse multiplexing technique involves inverse multiplexing and demultiplexing of ATM cells in a cyclical fashion among links grouped to form a higher bandwidth logical link whose rate is approximately the sum of the link rates. This is referred to as an IMA group. The figure below provides a simple illustration of the ATM inverse multiplexing technique in one direction. The same technique applies in the opposite direction.

IMA Group PHY

Physical link #0

IMA Group PHY

PHY Single ATM Cell Stream from ATM Layer

Physical link #1

PHY Original ATM Cell Stream to ATM Layer

Physical link #2 PHY PHY

IMA Virtual Link TX direction: cells distributed across links in round robinsequence RX direction: cells recombined into single ATM stream

Figure 10.

Inverse multiplexing and de-multiplexing of ATM cells via IMA groups

86 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

IMA groups terminate at each end of the IMA virtual link. In the transmit direction, the ATM cell stream received from the ATM layer is distributed on a cell 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 cell basis, recreating the original ATM cell stream. The aggregate cell stream is then passed to the ATM layer. The IMA interface periodically transmits special cells that contain information that permit reconstruction of the ATM cell stream at the receiving end of the IMA virtual link. The receiver end reconstructs the ATM cell stream after taking into account the link differential delays, smoothing CDV introduced by the control cells, etc. These cells, defined as IMA Control Protocol (ICP) cells, provide the definition of an IMA frame. The transmitter must align the transmission of IMA frames on all links. This allows the receiver to adjust for differential link delays among the constituent physical links. Based on this required behaviour, the receiver can detect the differential delays by measuring the arrival times of the IMA frames on each link. At the transmitting end, the cells are transmitted continuously. If there are no ATM layer cells to be sent between ICP cells within an IMA frame, then the IMA transmitter sends filler cells to maintain a continuous stream of cells at the physical layer. The insertion of filler cells provides cell rate decoupling at the IMA 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 the current bandwidth utilisation level of the group as percentage. When the total bandwidth utilisation of all active E1 links in the IMA group exceeds the Severe Level% bandwidth utilisation threshold for a set period of time, a utilisation alarm is generated (Active Report). Severe Level% and Active Report can be configured for each IMA group separately. The default value for Severe Level% is 90 (90%). When the utilisation alarm is active and the bandwidth utilisation of all active E1 links in the IMA group drops below the Abate Level% threshold for a set period of time, a utilisation alarm is cleared (Clear Report). Abate Level% and Clear Report can be configured for each IMA group separately. The default value for Abate Level% is 70 (70%). The utilisation alarm can be configured in both ingress and egress direction. It is possible to enable/disable the utlisation alarm in the IMA group and the default setting is Disabled.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

87 (252)

Provisioning

2.7.2

E1 card applications
The E1 units provide an E1 ATM-based leased line replacement service for ATM services over E1. Compared to xDSL technology, the ATM-based E1 service can provide an extensive reach well beyond the Central Office with the use of repeated 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 far end user equipment to the E1 unit. Thresholds: Setting of thresholds to generate events or alarms in Craft Terminal 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 user equipment. Node clock: The E1 card obtains timing from the D500 system. The far-end user equipment must either use the same network timing source or be configured for loop timing if the D500 E1 unit is set to the node clock, and vice versa.

Line loopback: The E1 interfaces support line loopback at the physical layer. Terminal loopback: The E1 interfaces support terminal loopback at the physical layer. BERT (Bit Error Rate Test): The E1 interfaces support BERT per port basis.

2.7.5

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

88 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Loss of frame (LOF) seconds thresholds Daily and 15-minute thresholds can be set. The LOF seconds threshold settings are the number of seconds during which an LOF condition was present. An event is reported to Craft Terminal when the LOF seconds threshold is crossed.

Loss of signal (LOS) seconds thresholds The loss of signal condition is monitored during the data mode. Daily and 15-minute thresholds can be set. The LOS seconds threshold settings are the number of seconds during which an LOS condition was present. An event is reported to Craft Terminal when the LOS seconds threshold is crossed.

Loss of cell delineation (LCD) The LCD seconds threshold settings are the number of seconds during which an LCD condition was present. An event is reported to Craft Terminal when the LCD seconds threshold is crossed.

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

Errored seconds thresholds Errored seconds are the cumulative number of seconds the port is in an LOF, LOS, or a coding violation condition. Errored seconds are monitored during all operational modes. Daily and 15-minute thresholds can be set for path and line. An event is reported to Craft Terminal when the errored seconds threshold is crossed.

Severely errored seconds (SES) This is the count of seconds containing one or more severe errors. Daily and 15-minute thresholds can be set for path and line. An event is reported to 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 not available. Daily and 15-minute thresholds can be set for path and line. An event is reported to Craft Terminal when the UAS threshold is crossed.

SEF/AIS seconds (SAS)

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

89 (252)

Provisioning

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

2.7.6

Performance monitoring counters


The following physical layer performance monitoring counters are available for the E1 interfaces:
.

LOF: Loss of frame seconds LOS: Loss of signal seconds LCD: Loss of cell delineation CV-L: Code violationsline ES-L: Errored secondsline SES-L: Severely errored secondsline UAS-L: Unavailable secondsline SEFS-P: Severly errored framing seconds, (RFC 2495) CV-P: Code violationspath, (RFC 2495) ES-P: Errored secondspath, (RFC 2595) SES-P: (or SAS-P): Severly errored secondspath, (RFC 2495) UAS-P: Unavailble secondspath, (RFC 2495, G.826) Elapsed time (current 15 minutes): Total amount of time in the current 15minute performance monitoring interval Elapsed time (current 24 hours): Total amount of time in the current 24hour performance monitoring interval Elapsed time (previous day): Total amount of time in the performance monitoring interval of the preceding day.

2.7.7

ATM performance management


The following ATM performance management actuals are available:

90 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Cells received: Total number of cells received on the channel since the card reset or counter reset Cells transmitted: Total number of cells transmitted on the channel since the 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, the user must create IMA groups by specifying which ports form the group. An IMA group in TKE1 may contain 18 ports (links). It is possible to create up to 8 groups for an E1 trunk unit. An IMA group in TBE1 may contain 18 ports. It is possible to create up to 16 groups for an E1 tributary unit. One port, the master port, of the group identifies the IMA group and cannot be removed from the group. Other ports, which do not belong to any group, can be added to and later removed from the group. The IMA protocol version can be chosen between v1.0 or v1.1. The default is v1.1. V1.0 is needed to ensure inter-operatibility, if the farend supports only IMA v1.0. To provision the following IMA parameters common to all IMA groups, select Tools => View Properties, click the E1 unit and then the Configuration tab page:
.

Alpha Value: The 'alpha' value is used to specify the number of consecutive invalid ICP cells to be detected before moving to the IMA Hunt state from the IMA Sync state. The value range is 12. Beta Value: The 'beta' value is used to specify the number of consecutive errored ICP cells to be detected before moving to the IMA Hunt state from the IMA Sync state. The value range is 15. Gamma Value: Configure the 'gamma' value used to specify the number of consecutive valid ICP cells to be detected before moving to the IMA Sync state from the IMA PreSync state. The value range is 15.

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

Minimum Links: Minimum number of transmit and receive links required to be active for the IMA group to be in the Operational state Tx Clock Mode: Transmit clocking mode used by the IMA group

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

91 (252)

Provisioning

Common Transmit Clock (CTC): The transmit clock of all IMA links are derived from the same source. Independent Transmit Clock (ITC): There is at least one IMA link whose transmit clock is derived from a source different than at least another link transmit clock.

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

Tx IMA ID: Value range 0255 Frame Length: Frame length to be used by the IMA group in the transmit direction Diff Delay Max: Maximum number of milliseconds of differential delay among the links that will be tolerated.

The following Bandwidth Utilization alarm parameters are provisionable at the IMA 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 Utilization alarm RptClr: Clear report time (in seconds) for the Bandwidth Utilization alarm

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

Test Link is used in the test pattern procedure. Value Any means that the implementation chooses the test link. Tx Pattern is used in an IMA group loopback operation. The range 0 to 255 designates a specific pattern. The distinguished value of -1 specifies that the implementation chooses the value. Start/Stop starts or stops the test pattern procedure.

92 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

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, InsufficientLinks) 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) and Independent Transmit Clock (ITC). The CTC mode corresponds to the case when the transmit clock of all IMA links are derived from the same source. The ITC configuration corresponds to the case where there is at least one IMA link whose transmit clock is derived from a source that is different from a minimum of one source used in the 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 nearend for IMA data cell clock recovery from the ATM layer Value 0 may be used, if no link has been configured in the IMA group, or if the transmit timing reference link has not yet been selected.

Rx: Port index of the receive timing reference link to be used by the nearend for IMA data cell clock recovery toward the ATM layer Value 0 may be used, if no link has been configured in the IMA group, or if the receive timing reference link has not yet been detected.

Frame Length Tx/Rx: Length of the IMA frames

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

93 (252)

Provisioning

This attribute overwrites the value of the imaGroupNumRxActLinks attribute when the IMA group is configured in the Symmetrical Configuration group symmetry mode.

Rx: Number of links that are configured to receive in this IMA group This attribute is overwritten by the value of the imaGroupNumTxActLinks attribute when the IMA group is configured in the Symmetrical Configuration group symmetry mode.

Active links Tx: Number of links that are configured to transmit and are currently active in this IMA group Rx: Number of links that are configured to receive and are currently active in this IMA group

Available Cell Rate Tx: Current cell rate (truncated value in cells per second) provided by this IMA group in the transmit direction, considering all the transmit links in the active state Rx: Current cell rate (truncated value in cells per second) provided by this IMA group in the receive direction, considering all the receive links in the active 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 OAM Label from the FE IMA unit.

Failure Status NE/FE: Failure reason of an IMA group

Least Delay Link

94 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

Port index of the link configured in the IMA group that has the smallest link propagation delay. Value 0 may be used if no link has been configured in the IMA group, or if the link with the smallest link propagation delay has not yet been determined.

Max Diff. Delay Obs Latest maximum differential delay observed (in milliseconds) between the links having the smallest and biggest link propagation delay, among the receive 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 current measurement period This attribute is mandatory only when the IMA Group Current Statistics are implemented.

Running Seconds Amount of time (in seconds) since the IMA group has been in the operational state

Unavail Seconds Count of one second intervals, where the IMA Group Traffic State Machine is down

Valid Intervals Number of the previous 15-minute intervals for which the valid data was collected The value is 96 unless the IMA group was created within the last 24 hours, in which case the value is the number of the complete 15minute 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:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

95 (252)

Provisioning

Unavailable seconds (UAS) Count of one-second intervals where the IMA Group Traffic State Machine is down in the current 15-minute interval

Ne Num Failures (NeFC) Number of times a near-end group failure (Config-Aborted, InsufficientLinks) has been reported in the current 15-minute interval

Fe Num Failures (FeFC) Number of times a far-end group failure (Config-Aborted-FE, InsufficientLinks-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 following periods:
.

Current: Statistics for the current 15 minute interval Interval: Statistics for the past 24 hours broken into 96 completed 15minute intervals Total: The cumulative sum of statistics for the 24 hour period preceding the current 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 click View 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

NE: Current link failure status of the near-end receive link FE: Current link failure status of the far-end receive link as reported via ICP cells
.

Sev. Errored Seconds NE: Count of one-second intervals containing >= 30% of the ICP cells counted 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 UASIMA condition FE: Count of one-second intervals containing one or more RDI-IMA defects, except during the UAS-IMA-FE condition

Unavailable Seconds NE: Count of unavailable seconds at the near-end: unavailability begins at the onset of 10 contiguous SES-IMA conditions and ends at the onset of 10 contiguous seconds with no SES-IMA conditions FE: Count of unavailable seconds at the far-end: unavailability begins at the onset of 10 contiguous SES-IMA-FE conditions and ends at the onset of 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 Tx LSM

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 Rx LSM

Tx Failures NE: Number of times a near-end transmit failure alarm condition has been entered on this link FE: Number of times a far-end transmit failure alarm condition has been entered 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 via ICP cells

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

97 (252)

Provisioning

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 reported via 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 in the same IMA group

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

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

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 created within the last 24 hours, in which case the value is the number of complete 15-minute intervals since the IMA group table entry was created.

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 current measurement period.

98 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Interface provisioning

The following performance statistics are available for each IMA link:
.

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

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

SevErrorSec NE: Count of one-second intervals containing >= 30% of the ICP cells counted 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 UASIMA condition FE: Count of one-second intervals containing one or more RDI-IMA defects, 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 Tx LSM

Rx Unusable Sec NE: Count of unusable seconds at the near-end Rx LSM in the current 15minute interval FE: Count of seconds with Rx unusable indications from the far-end Rx LSM

Tx Num Failures NE: Number of times a near-end transmit failure alarm condition has been entered on this link FE: Number of times a far-end transmit failure alarm condition has been entered on this link

Rx Num Failures NE: Number of times a near-end receive failure alarm condition has been entered on this link

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

99 (252)

Provisioning

FE: Number of times a far-end receive failure alarm condition has been entered 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Timing provisioning

3
3.1
3.1.1

Timing provisioning
Timing settings
The following provides information on timing settings for the node clock and each interface in the D500 system.

Node timing
In an SDH or SONET network, it is essential that all the nodes operate in synchronisation with each other. In the D500 system, this is ensured by using the signal of any supported line interface received from the SDH/SONET network as the timing reference. The node clock can operate in a free-run, locked or hold-over mode. The clock type is configurable; the user can select either SDH Equipment Clock (SEC) or SONET Minimum Clock (SMC). The default clock type depends on the subrack as 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 and holdover 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 for the subrack in the Node views of Craft Terminal. If the timing option is set to Internal, the node uses its internal clock as the timing reference. In other words, the node clock is in a free-run mode.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

101 (252)

Provisioning

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

from the OC-3/STM-1 or OC-12/STM-4 trunk signal coming from the core network 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 line interface (OC-3/STM-1, OC-12/STM-4, DS3 or E1). Together with the Line timing option, the reference port is shown by Craft Terminal, for example: Line (Port 1 / Unit 11).

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

If the timing option is set to External, the external timing input signal is used as the 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 and output connectors can be used to daisy chain several nodes. A 120-ohm termination resistor must be connected to the output of the last node.

102 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Timing provisioning

Cable from the timing source

SYNC IN Tip

Termination resistor (or the cable to the next D500 node)

Ring Shield SYNC OUT

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 with Gigabit Ethernet interface (TK1000, TKETH1G) the default setting is Internal.

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

In SDH and SONET networks, synchronisation status messaging is used to avoid synchronisation loops. The D500 node monitors the received SSM (Synchronisation Status Message) for each STM-n interface. If the received SSM is QL-DNU (do not use, value = 15), the interface cannot be selected as the node clock reference. If the received SSM for a selected reference switches to QLDNU, the node clock enters the hold-over mode. By default the transmitted SSM is QL-SEC (value = 11) if node clock type SEC is selected (SDH mode), or QL-SMC (value = 12) if node clock type SMC is selected (SONET mode). QL-DNU is transmitted from the interface that has been selected as the timing reference. The node switches to the hold-over mode if the interface used as a timing reference has one of the following conditions:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

103 (252)

Provisioning

LOS LOF line AIS received SSM = DNU.

The node clock enters a hold-over mode before the failure is declared in the management interface. The D500 rises an alarm and a standing condition if the node clock synchronisation 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-4 signal (or to the signal of any other supported line interface), internal clock or external clock, select Node => Properties => Management Configuration => General Configuration. In the Timing Option box, select Internal, Line or External.
.

2.

Line is the default setting for the node with the OC-3/STM-1 or OC12/STM-4 trunk. Line can be selected for the node with the Gigabit Ethernet trunk if there is a tributary unit in any slot that can accommodate a tributary unit. Select an appropriate tributary unit and 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 uses the 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 line interfaces: Node clock and Loop Portn (n = 14). When Node clock is selected for a line interface, the interface uses the same timing reference as the rest of the node, that is, the node clock which is either in external, internal or line timing, depending on the setting described above. The default setting is Node clock for each interface.

104 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Timing provisioning

Loop timing is a feature that allows building ATM networks with separate clock domains for single links, instead of using a top-down common clock distribution through the whole network. In loop timing, the line interface is in a separate clock domain instead of being locked to the D500 node clock. The interface at the other end of the link cannot be in loop timing because a link with both ends set to loop timing does not work properly. The interface on the ATM trunk is always locked to the node clock, in other words, 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 are locked to the received signal in the selected port that can be any of the four ports of the same unit. However, if one of the ports has been selected as the node clock reference, 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 been selected 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, the synchronisation 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 the interface that is used as the timing reference sends DNU. The other interfaces are sending the SSM that has been configured.
DS3 interface timing

Two different mappings are specified for transporting the ATM cell over DS3 transmission systems: PLCP-based system and direct mapping system. This affects how the timing reference is derived from the DS3 signal. If the PLCPbased mapping is selected when the DS3 interface is in loop timing, the transmitted PLCP frame rate is locked to the received PLCP frame rate in each DS3 interface. If direct mapping is selected, the transmitted line rate is locked to the received line rate.
E1 interface timing

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

105 (252)

Provisioning

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. 2. 3. 4. 5. Select Tools => View Properties. Click a tributary unit. Click the Configuration tab page. In the Interface Timing drop-down menu, select Loop Portn (n = 14) or Node clock. Click Apply.

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

Follow these steps to select the timing option: 1. 2. 3. 4. 5. Right-click the unit and select Go to Port Views. Double-click the port for which you want to set the timing option. Select the DS3 or E1 tab page. In the Interface Timing drop-down menu, select Loop timing or Node clock. 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 can accommodate 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, as illustrated in the following figure, use the Line (Port 1 / Unit 11) timing option to select the received OC-3/STM-1 or OC-12/STM-4 signal as timing reference. An OC-3/STM-1 or OC-12/STM-4 signal that transports timing quality generated at least by a SEC or SMC must be used to ensure that the D500 operates synchronously with the rest of the SDH/SONET network.

106 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Timing provisioning

ATM

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

T K A T M

Figure 12.

ATM trunk unit

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

In this configuration, the node can retrieve its timing from the received signal in the selected port of an OC-3/STM-1, DS3 or E1 tributary unit installed in any slot in 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 the figure below, a signal from the SDH or SONET network that transports a timing quality 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 = 14, m = any slot that can accommodate a tributary unit).

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

107 (252)

Provisioning

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

IP

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

T R B 1 5 5

T K 1 0 0 0

SDH SONET

Figure 13.

GE trunk with the tributary unit connected to the SDH/SONET network

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

108 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Timing provisioning

Synchronisation reference from an external synchronisation source

IP

Node Timing Option: Internal or external (if an external reference is available)

T R B 1 5 5

T K 1 0 0 0

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

T R K 1 5 5

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.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

109 (252)

Provisioning

Synchronisation reference from an external synchronisation source

IP

Node Timing Option: Internal or external (if an external reference is available)

T K 1 0 0 0

Figure 15.

GE trunk without a tributary unit

4) ATM trunk unit (TKATM_155_622) connecting the ATM networks of two different 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 = 14).

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

110 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Timing provisioning

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

ATM Carrier 1

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

T K A T M

T R B 1 5 5

ATM Carrier 2

Interface Timing Mode Option: Loop

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 reference sources:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

111 (252)

Provisioning

ATM network: The timing signal is received directly at the port of the ATM trunk/control unit or tributary unit. BITS/SSU: An intraoffice timing source, such as a BITS or SSU, supplies the primary reference source to the D500 RAM. The timing signal is received at the 3-pin SYNC connectors on the power unit.

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

1.

Locate and route the Feed A and Feed B cables from the BITS/SSU clock to D500 RAM. Using wire cutters, strip back insulation on Feed A, Feed B, and the ground wires by 1/4 inch on both the input cable wires.

2.

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.

Tightening Screws Plug into SYNC Connector on Power Unit

Wire Holes

Figure 17.

3-pin terminal block

112 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Timing provisioning

4.

Tighten the screws on the terminal blocks until a good connection is made. Route the input and output cables (if used) to the termination point for the terminal blocks on the D500 RAM, per local procedures. Plug the terminal block for the input cable into the 3-pin SYNC IN connector on the power unit. If you are subtending timing to a second device, connect the terminal block for the output cable to the second device into the 3-pin SYNC OUT connector on the power unit.
S Y N C O U T I N

5.

6.

Alarm Connectors

B GND

B GND

Figure 18.

Power unit SYNC IN and OUT connectors

Further information

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

113 (252)

Provisioning

114 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

4
4.1

Packet-based provisioning
Subinterface provisioning
A subinterface is a logical entity created as part of a trunk port, tributary port, or a line card port. There can be one or more subinterfaces associated with a physical port. Depending on a port type (ATM or Ethernet), a subinterface is defined as an endpoint 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 basis of cell headers only, in packet-based operation layer 2/3 switching is based on the MAC or IP header of the packet. This means that ATM subinterfaces can transport only AAL5 traffic and the RFC 2684 -based AAL5 encapsulation type (for instance LLC/SNAP or VC Muxed, bridged or routed) must be defined for each 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 client subinterface and the trunk subinterface according to the IP routing table. The CPE must use routed encapsulation. Both client and trunk subinterfaces must be routed. Different routed trunk subinterfaces must use unique 802.1q VLAN tags.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

115 (252)

Provisioning

To have full IP connectivity the network behind the CPE must be defined in the D500 IP routing table. Client-to-client connectivity can be configured either through the D500 IP routing table or the IP routing table of the broadband remote access server (BRAS). Packet forwarding between different routed client and trunk subinterfaces is performed according to the D500 IP routing table. The routing table contains statically configured host and network routes and dynamic, DHCP-learned host routes. In case client-to-client connectivity is not desired through the D500 IP routing table, one-to-one routed connection must be used. In this configuration, the client subinterface is bound to the trunk subinterface, and packets are passed between the interfaces without the routing table. The one-to-one routed connection is the recommended scenario for the customers with fixed IP address needs and advanced IP traffic generation, in other words, business customers that need private network managing behind the CPE and/or prioritisation 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. 2. 3. 4. 5. 6. 7. Subinterface name IP address netmask Diffserv enable/disable (optional) VPI/VCI for the ATM interface VLAN for the Ethernet interface Ping enable/disable (optional) 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

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 client1 10.30.20.253 conf ip route new 10.30.31.0 255.255.255.0 1/2 client2 10.30.30.253

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

117 (252)

Provisioning

ADSL routers

D500

NORMAL ROUTED

Routing 10.30.20.253/30 0/100 1/1 client1


10.30.21.0/24

10.30.20.254/30 routed1 10.30.18.1/24 10.30.30.253/30 client2 1/2 10.30.30.254/30 0/100 11/1

VLAN 20 10.30.18.254/24

Router

10.30.31.0/24

Figure 19. 4.1.1.2

Normal routed connection

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

A one-to-one routed connection is the recommended scenario if client-to-client connectivity is not desired through the D500 IP routing table but through the BRAS IP routing table. The trunk and client subinterface are bound together and the D500 IP routing table is bypassed, leaving the routing task to the next hop router. 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 an optional MAC addresses for all IP traffic upstream. The IP subnet does not need to 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 is bound for the downstream IP traffic. The following is an example of a one-to-one connection: configure subinterface client new 1/1 client1 routed

118 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

119 (252)

Provisioning

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

ADSL routers 10.0.2.253/30 1/1


0/100

D500 1-to-1 forwarding client1


10.0.2.254/30

1-to-1 ROUTED

routed100
10.0.3.253/30

10.0.1.0/24

10.0.3.254/30 VLAN 100 Router

11/1 1-to-1 forwarding


0/100 VLAN 101 10.0.6.254/30

10.0.5.253/30

client2
10.0.5.254/30

routed101
10.0.6.253/30

1/2

10.0.4.0/24

Figure 20. 4.1.1.3

One-to-one routed connection

Routed subinterface isolation

The operator can isolate each IP routed client subinterface by defining a subinteface IP gateway. If the IP gateway MAC address is defined D500 client side subnetworks can overlap. Otherwise the corresponding IP circuit is created into the D500 (this operation is part of the one-to-one routed connection). Example:

120 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

conf sub client new 2/1 c1 routed pvc 0 38 llc gateway_ip 10.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> pairs to <subinterface, gateway> pairs. A packet with a destination address that matches the <IP subnet address, IP subnet mask> table entry should be forwarded to the corresponding gateway on the subinterface given in the table entry. If multiple table entries match the destination address, the most specific match wins. This is called the longest prefix match algorithm. The routing table always contains a static entry, which maps the least specific route, <0.0.0.0, 0.0.0.0>, to the default route. For an example of a routing table configuration see the example of a normal routed connection above.

4.1.2

Routed bridge subinterface (RBE)


The routed bridge encapsulation (RBE) subinterface was designed to overcome some of the less favourable features of both bridged virtual interfaces (BVI) and integrated routed and bridged (IRB) interfaces. RBE interfaces emulate routed interfaces by only forwarding frames based on their encapsulated layer 3 information. The D500 interfaces support DHCP and PPPoE through selectable connection options. RBE is a described as having the functionality of a routed interface and a half-bridge. RBE interfaces receive RFC 2684 bridged Ethernet frames, but only examine the IP portion of the PDU. If the PDU does not contain any layer 3 information it is discarded. There are three exceptions with regard to the implementation of RBE interfaces in the D500:
.

ARP During the initial stages of connection establishment the D500 supplies its MAC address (proxy ARP) for all non-local ARP broadcasts. This proxy ARP supplies CPE side devices with a local destination MAC address.

DHCP DHCP broadcast are relayed to a preconfigured DHCP server, through the use of a helper-address. If configured, the D500 can snoop both the DHCP request and reply. This information is then used to create a static host route for a specific subscriber.

PPPoE PPPoE is not natively supported on RBE connections. If PPPoE services are required, the PPPoE option and destination parameter are specified in the initial connection configuration.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

121 (252)

Provisioning

4.1.2.1

Parameters of a RBE interface

The following information must be defined in a RBE connection: 1. 2. 3. 4. 5. 6. Subinterface name IP address netmask VPI/VCI for an ATM interface VLAN for an Ethernet interface Diffserv enable/disable (optional) PPPoE enable/disable (optional)
.

PPPoE destination port ID and name

7.

PPP enable/disable (optional)


. .

PPP MAX sessions PPP threshold sessions

8. 9.

Multicast PTD (optional) 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

4.1.2.2

RBE interface operation

RBE interfaces operate either in a numbered or unnumbered mode. Numbered interfaces require a one-to-one mapping between an interface and IP address. Unnumbered interfaces use or borrow an IP address from another interface. Both configurations are extremely similar in operation. In the D500, the RBE interface supports client-to-client communication. This kind of connectivity is achieved internally through the D500 IP routing table. Operational examples are provided below.
Numbered interface operation

In the numbered interface operation there is one fixed IP address in the client subinterface and another fixed IP in the trunk subinterface. One IP network has to be assigned to every client subinterface potentially wasting IP 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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

123 (252)

Provisioning

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

D500 PCs ADSL bridges 1/1 10.0.1.1/24


0/100

RBE Routing client1 10.0.1.254/24 routed1 10.0.3.1/30


0/100

VLAN 100 10.0.3.2/30 11/1

Router

client2 10.0.2.254/24

1/2 10.0.2.1/24

Figure 21.

RBE connection

Unnumbered interface operation

In the unnumbered interface operation there is one fixed IP address in one client subinterface while others borrow that IP. This scenario allows several client subinterfaces to be in the same IP subnet, maximising the use of available IP addresses.

124 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

125 (252)

Provisioning

conf ip route new 0.0.0.0 0.0.0.0 11/1 routed1 10.0.2.2

D500 PCs ADSL bridges UNNUMBERED RBE Routing

1/1
10.0.1.1/24
0/100

client1
10.0.1.254/24

VLAN 100 Router 10.0.2.2/30

routed1 10.0.2.1/30
0/100 Unnumbered

11/1

client2

1/2
10.0.1.2/24

Figure 22. 4.1.2.3

Unnumbered RBE connection

RBE with loopback IP addressing

This scenario has one fixed IP address in a loopback interface. When client subinterfaces borrow that IP, they can in the same IP subnet, maximising the use of available IP addresses. The advantage compared to RBE with unnumbered IP addressing is that no client subinterface needs to be dedicated to define the IP subnet to use. The logical loopback interface is used instead. If unnumbered interfaces are used when there are two subscribers in the same subnet, 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

126 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

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 of unnumbered interfaces, Host A is in the same subnet as Host B.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

127 (252)

Provisioning

D500 Host B ADSL bridges Routing

RBE/LOOPBACK

1/1
IP=10.0.1.1/24 GW=10.0.1.254/24
0/100

client1 routed1 10.0.2.1/30 11/1


VLAN 100 Router 10.0.2.2/30

Loopback 10.0.1.254/24 0/100

Host A

client2

1/2
IP=10.0.1.2/24 GW=10.0.1.254/24

Figure 23.

IP unnumbered operation

Host A learns the MAC address of Host B by sending out an ARP broadcast to Host B via the D500. When the RBE interface at the D500 receives this broadcast message, it sends out a proxy ARP response with the MAC address 10.0.1.254 to Host A. Host A takes that MAC address, place it in its Ethernet header, and sends the 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 traffic from the rest of traffic, in other words, PPPoE remote office VPN. The PPPoE session 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 traffic is bridged and the trunk subinterface for the rest of user traffic is routed.

128 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

D500 POs ADSL bridges 1/1 10.0.1.1/24


0/100

PPPoEGrooming Client1_RBE Bridging Bridge_trunk 11/1 Pppoe_trunk VLAN 200 10.0.1.254/24 Router

VLAN 100

Figure 24. 4.1.2.5

PPPoE grooming with RBE as a client subinterface

Multicast (IGMP proxy) functionality with RBE as a client subinterface

IGMP-capable clients interact with the D500 through the exchange of IGMP messages. When the IGMP proxy has been configured, the D500 interacts with the next hop multicast router on its Gigabit Ethernet upstream interface through the 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 group to which none of its other client subinterfaces belong, the D500 sends an upstream unsolicited group membership reports to that group. Any subsequent client subinterfaces joining the same group receives the multicast stream with no more upstream membership reports being generated. When the last of the client subinterfaces of the D500 in a particular multicast group leaves the group, the D500 sends an upstream unsolicited leave group membership report to the all-routers group (244.0.0.2). It is possible to use multicast authentication in the D500. In that case some channel packages must be created first. A channel package includes a list of multicast IP addresses. After channel packages are created, authentication is enabled by configuring client authentication entries (<client MAC-channel

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

129 (252)

Provisioning

package ID> pairs). By default there is no authentication in the D500. Once the first client authentication entry is created, authentication is enabled for the whole D500. Authentication is disabled again by deleting all client authentication entries. 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

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

IGMP leave STB

Snoop request Stop video


iTV Manager

CPE
IGMPv2

D500
IGMPv2 MOSPF, PIM, DVMRP

Broadcast Server Encoders & Transcoders

Video service authentication data IP Address of multicast router

Internet

Figure 25. 4.1.2.6

Multicast

RBE subinterface isolation

The D500 RBE client subinterface request a specific gateway IP configuration. If the gateway is specified, all the traffic from the given subinterface is sent to the gateway (default: no gateway). Example:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

131 (252)

Provisioning

conf sub client new 2/1 client1 rbe pvc 0 38 llc gateway_ip 10.12.2.2 The RBE user isolation prevents the users in the same subinterface from seeing each other (private ports). In the RBE subinterface the ports can be configured as private or community ports. The RBE user isolation is achieved by configuring the default gateway per client subinterface. A DHCP-enabled RBE client subinterface accepts traffic only from clients receiving their addresses with the DHCP.
4.1.2.7 RBE with DHCP relay (Option 82)

The D500 RBE client subinterface relays the DHCP request from the client endpoint to a predefined DHCP server. It can be configured to append the Option 82 tag to the DHCP request. The Option 82 tag contains traceabilty information, for example the DSL slot and port. The format of the option 82 tag is shown below:

Option 82

Length xx

Suboption 1

Length xx

Information Suboption 2

Length 19

Information

Subinterface name string Max. 32 bytes

Port type Ver. 0x01(RBE) 1 byte

For future 2 bytes

Port IP Address (loop-back address) 4 bytes

DSLAM MAC Address 6bytes

Slot Port VPI VCI 1 bytes 1 bytes 1 bytes 1 bytes

Figure 26.

Format of the Option 82 tag

The DHCP relay is enabled by specifying the DHCP server IP address in the client subinterface. The following figure is an application example:

132 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

ADSL modem

D500

Ethernet switch
E

SMS Ethernet / IP IP

The SMS cannot identify customers before they have got IP address from the DHCP server.

ADSL modem

D500

DHCP relay agent

The D500 acts as a DHCP relay agent and adds and strips relay Option 82 from DHCP messages. The D500 is the only network element that has reliable knowledge about each customer (customer = slot, port, VPI, VCI). In the D500 network side, there are only IP flows.

Figure 27.

Application of the DHCP relay

The DHCP relay feature can be enabled in a RBE subinterface that refers to the relay 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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

133 (252)

Provisioning

4.1.3

Bridged subinterface
Bridged interfaces were designed to support both connectionless and connection oriented protocols. The D500 implements a specialised bridging model based on standard RFC 2684 and centred around bridged Ethernet scenarios. The D500 also supports a variety of bridged encapsulation types and tunneling technologies. Bridging is based on a MAC address table. This table maps MAC addresses to connections. A table entry is created whenever a MAC address shows up in the source address field of the MAC header of an upstream (ingress) packet. The entries 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 certain interval, a table ageing process deletes the MAC entry. The ageing time-out period is a configurable parameter. Each bridged connection endpoint on the client side belongs to a single bridge group (5400 bridge groups). A bridge group consists of a minimum of one client interface and only one trunk side interface (VCC or VLAN, in case of the Gigabit Ethernet trunk). If the number of members 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 all members of the bridge group. If this is not wanted, it is possible to configure Broadcast Off in the bridged trunk subinterface. The Broadcast Off configuration blocks downstream broadcast (including ARP requests) and multicast traffic in that bridge-group. A directed DHCP response is supported even though DHCP proxy is disabled in the bridged subinterface. The D500 forwards the broadcasted DHCP response only 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 that case the D500 acts as a relay adding the DHCP Option 82 tag. DHCP messages has 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 use IEEE 802.1Q VLAN tags in RFC2684-encapsulated Ethernet PDUs going to subscribers 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

1. 2. 3. 4. 5. 6.

Subinterface name Priority (optional) VPI/VCI for an ATM interface VLAN for an Ethernet interface PPPoE enable/disable (optional) 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 one client subinterface and a trunk subinterface. All upstream Ethernet frames are forwarded to the trunk subinterface with a 802.1q VLAN tag. All downstream Ethernet frames belonging to the trunk subintreface VLAN are stripped of the 802.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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

135 (252)

Provisioning

bridged_subif 11/1 bridge100 done end

D500 PCs ADSL bridges 1/1 10.0.1.1/24


0/100

BRIDGE GROUPS client1 Bridging bridge100 11/1 10.0.1.254/24

VLAN 100

Router

Figure 28. 4.1.3.3

Bridged one-to-one connection

Bridge groups (PVCs-VLAN)

The maximum number of bridge groups in the system is configured at a system level. It is possible to configure 5400 bridge groups (default 20). If there are five groups, the number of clients per group is 1600 (5 x 1600 = 8000). If there are 400 groups, the number of clients per group is 20 (400 x 20 = 8000). An exception to this system level setting is that the number of bridge groups can be up to 4000 if each bridge group has only one bridge client side member. The new configuration comes into effect after rebooting the node. This configuration consists of several client subinterfaces bound to a trunk subinterface. All upstream Ethernet frames are forwarded to the trunk subinterface with a 802.1q VLAN tag. All downstream Ethernet frames belonging to the trunk subintreface VLAN are stripped of the 802.1q tag and forwarded untagged to the right client subinterface based on the self learning bridging table. The D500 supports new node level configuration that defines how the 8000 multicast resources shall be devided into bridge groups. This configuration requires that the user reboots the D500. conf sys bridge_groups 40 [| 1-4000]

136 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

137 (252)

Provisioning

D500 PCs ADSL bridges 1/1 0/100 10.0.1.1/24 client1 Bridging bridge100 1/2 10.0.1.2/24
0/100

BRIDGE GROUPS

VLAN 100 11/1

Router

client2 10.0.1.254/24

Figure 29. 4.1.3.4

Configuration of bridged groups

PPPoE grooming with a bridged client subinterface

The following is an example of PPPoE grooming with a bridged client subinterface: 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

138 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

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

D500 PCs ADSL bridges 1/1 0/100 10.0.1.1/24 client1 Bridging Bridge_trunk 11/1 Pppoe_trunk VLAN 200 10.0.1.254/24 PPPoEGrooming

VLAN 100

Router

Figure 30. 4.1.3.5 Protocol filter

PPPoE grooming with a bridged client subinterface

Protocol filters apply only to bridged subinterfaces. The protocol filter is applied to the PDUs received by the subinterface (upstream direction). Any combination of the following can be enabled to pass the filter: 1. 2. 3. 4. ALL PPPoE IP_NO_NETBEUI IP_WITH_NETBEUI.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

139 (252)

Provisioning

4.1.3.6

Bridged subinterface priority

The D500 supports priority bit settings to bridged subinterfaces. Three priority classes for the VLAN priority field are supported: high, medium, and low. VLAN priority bits can be used to prioritise high/medium/low traffic or disable it. VLAN priority field mapping to priority classes is configrable. VLAN priority field mapping to priority classes defines which priority field value belong to which class. The default priority mapping configuration is as follows:
.

high4, 5, 6, 7 medium2, 3 low0, 1

There can be only one priority mapping configuration per node. The settings become effective only after the node has been rebooted. In the priority mapping mode, the incoming subinterface's priority mapping configuration defines the PDU's outgoing queue and the VLAN priority field value (= the priority field is set to a new value). In the priority pass mode, the incoming PDU's VLAN priority value defines the PDU's outgoing queue. The VLAN priority value is preserved. Both modes are supported in the upstream direction. In the downstream direction only 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 trunk side:

140 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

Trunk Downstream priority handling VLAN/off (default: off) VLANVLAN priority bits select the priority. OffThere 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) HighTraffic is mapped to the trunk's high priority queue. MediumTraffic is mapped to the trunk's medium priority queue. LowTraffic is mapped to the trunk's low priority queue. VLANVLAN 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 MAC address/VLAN ID pairs with the ATM VC used to connect the client to the line card. Source MAC addresses are being learned in the upstream direction and a database containing these learned entries are then used in the downstream direction to forward the Ethernet frame to its proper recipient. The Gibabit Ethernet trunk uses these MAC addresses or MAC address/VLAN ID pairs to direct Ethernet data to the appropriate client. If the MAC address of the recipient in the frame coming from the Ethernet trunk is not found from the MAC forwarding table, the frame is broadcasted to all members in the same bridge group. The table is automatically maintained by ageing out MAC addresses that have not been in use for a specified period of time or when MAC addresses exceed the table critical capacity. The table can maintain a maximum of 8000 MAC addresses. The age of MAC addresses can be controlled with the MAC Maximum Ageing Time parameter if the table volume is less than critical capacity. For details see Managing the MAC address table.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

141 (252)

Provisioning

A subinterface has a user defined limit on the number of MAC addresses that can be learned (default = 10, and max is 1000).

Ethernet Switch D500 MAC Address Table VPI/VCI MAC Address Link A 0/25 00A0C9662B51 Link A 0/25 00904500000D AAL5 SAR ATM PDU L i n e C a r d E t h T r u n k

Link A 0/25 Customer PC MAC=00A0C9662B51

LAN CPE

Customer PC MAC=00904500000D

Figure 31. 4.1.3.8

Ethernet to ATM address forwarding

Managing the MAC address table

The ageing time that MAC addresses remain in the MAC address table is controlled by a provisionable MAC Maximum Ageing Time or automatically by an accelerated MAC ageing algorithm. If MAC addresses exceed an internally set critical capacity, an accelerated ageing algorithm ages out inactive MAC addresses on a first-in-first-out basis, freeing up table space for new MAC addresses. The following figure illustrates MAC ageing within the MAC address table.

142 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

MAC Table Capacity 100 % Accelerated Aging Critical Capacity

MAC Aging Time

MAC Maximum Time

Alarm Treshold 0% Historical Time Interval


Legend: Current MAC Capacity

0 Sec.
Legend:

Resource Overflow Historical Time Interval


Current MAC Aging

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 MAC address table if it is not in use. This ageing time is applied only to MAC addresses when table fill does not exceed the internally-set critical capacity. When this capacity is exceeded, an accelerated ageing algorithm calculates an accelerated ageing of MAC addresses in place of the of the MAC Maximum Ageing Time. The provisioned value range for MAC Time is from 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 10 second intervals. As more MAC addresses enter the database while at critical capacity, the accelerated aging algorithm ages out MAC addresses at shorter intervals in order to keep the table from overflowing. An alarm is generated if the ageing time for MAC addresses drops below the ageing threshold for this parameter. This value should be less than the MAC Maximum Ageing Time. The value range is 0 to 655,350 seconds (MAC Maximum Time10 seconds). The default value is 10 (100 seconds).

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

143 (252)

Provisioning

4.1.3.9

Bridged subinterface with the DHCP relay (Option 82)

The D500 bridged client subinterface relays the DHCP request from the client endpoint to a predefined DHCP server. It can be configured to append the Option 82 tag to the DHCP request. A routed trunk subinterface with a route to the DHCP server has to be created for carrying DHCP messages. Also a loopback interface has to be created. DHCP messages from the D500 to the DHCP server are unicast packets having a loopback address as the source IP address. The DHCP relay is enabled by specifying the name of the loopback and the name of DHCP relay pool interface in the client subinterface. DHCP relay pool specifies 12 DHCP server IP addresses and Option 82 and mobility parameters. The Option 82 tag contains traceability information such as the DSL slot and port. The Nokia Option 82 tag has two sub options. The first one is Agent Circuit Id and the second one is Agent Remote Id. The DHCP server should reside behind a routed trunk subinterface. The D500 forwards downstream DHCP broadcast response messages from the DHCP server to 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 subinterfaces that have joined that multicast group. IGMP snooping is enabled as follows:

144 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

1. 2. 3.

The global configuration defines the trunk subinterface that forwards the IGMP messages to the next hop multicast router. The global configuration defines a loopback interface that belongs to the same subnet as the bridge clients. The client subinterface defines the name of the loopback interface, multicast packet traffic descriptor (PTD), and the maximum number of allowed channels.

4.1.3.11

Bridged connections with client side VLANs

The Ethernet switch behind the CPE modem or the CPE modem can tag Ethernet packets with the VLAN ID. That is why it is possible to have end-to-end CoS for bridged connections using 802.1p VLAN priorities starting from the client device. The configuration consists of bridged client subinterface(s) with a VLAN ID bound to a certain bridged trunk subinterface. Multiple VLANs (max 10) can be transferred inside one client side PVC. All upstream Ethernet frames are forwarded to the trunk subinterface by switching the client VLAN ID to the VLAN ID defined in the trunk subinterface. All downstream Ethernet frames belonging to the trunk subinterface VLAN ID are forwarded with the client VLAN ID to the right client subinterface based on the self-learning bridging table.

4.1.4

PPPoA subinterface
In the PPPoA subinterface connection the D500 terminates the ATM connection and forwards the PPP session via Ethernet towards the PPPoE server (= the broadband remote access server, BRAS). In this scenario, the D500 emulates a PPPoE client (RFC 2516). The CPE must use PPPoA encapsulation (RFC 1483 and 2364), acting as a router. Trunk subinterfaces must be bridged and client subinterface PPPoA. The client subinterface is bound to the bridged trunk subinterface that forwards the PPP session as PPPoE to be terminated in the BRAS. Different bridged trunk subinterfaces must use unique 802.1q VLAN tags. Client-to-client connectivity is achieved via the BRAS. This subinterface is suitable for operators who want to support their existing PPPoA customer base with the IP based DSLAM trunk. There is no IP configuration in the client subinterface or trunk.
Parameters of a PPPoA interface

The following information must be defined for a PPPoA interface:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

145 (252)

Provisioning

1. 2. 3.

Subinterface name PVC VCI/VPI VCMUX/LLC 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 supports statically configured tunnels and (PPP) aggregative services. Although the D500 does not support tunnel switching for PPP sessions it does support partial link control protocol (LCP) forwarding for PPP over ATM (PPPoA) and PPP over Ethernet (PPPoE) clients. In the D500 L2TP tunnels are statically created entities between a link access control (LAC) and an L2TP network server (LNS). The LNS is typically an access router on the trunk side. The trunk unit implements the LAC functionality allowing PPP sessions to be tunneled to a single endpoint. Each PPP protocol session is terminated on the server end by the LNS, and on the client end by either a CPE router or a host running PPPoE.

146 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

L2TP tunnels may be created over both ATM connections and Gigabit Ethernet VLANs. The LAC creates and manages L2TP tunnels. Once the tunnel is up and a tunnel ID is selected, a PPP session can be initiated. IP packets containing L2TP control messages are processed locally and used to crank state machines for configured L2TP tunnels. L2TP data is forwarded to the appropriate PPPoE or PPPoA endpoint, which is identified on the basis of the session ID carried in the header. Release 3 supports most L2TP link access control (LAC) functionality and uses the well-known UDP port 1701. The entire L2TP packet is encapsulated in a UDP 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 occurs independently of all other protocol negotiations and requires only that the LNS be configured and accepting L2TP calls. After tunnels are established, the D500 LAC continually maintains the tunnels through the use of L2TP maintenance and control messages. The L2TP connection can be created only over the routed trunk interface. The following two cases show how to create a complex testing environment for PPPoE 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>

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

147 (252)

Provisioning

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/bridged subinterface 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

done top
.

To have a client PPPoA onnection over L2TP, create a PPPoA client subinterface 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. 2. 3. 4. Verify that the LNS IP address and password are right Try to ping the LNS from the D500 to verify that there is a routed connection Check the trunk statistic counters Check the installation and set the LNS (Cisco router) to the L2TP debugging mode to find out whether any L2TP messages are coming from the D500 Check the L2TP tunnel and PPP session state with the following CLI command: show l2tp <tunnel_id> session The following figures are test case examples:

5.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

149 (252)

Provisioning

PCs

D500 ADSL bridges 10.0.1.2 Routed 20.1.1.1 1/1 Client1_RBE Router / L2TP server VLAN 10 Routed_trunk PPPoE PPPoE_L2TP 20.1.1.2 11/1 L2TP tunnel 2

10.0.1.1

Figure 33.

PPPoE over L2TP

PCs

ADSL bridges

D500 Routed 20.1.1.1 1/1 Client1_PPPoA Router / L2TP server VLAN 10 PPPoA Routed_trunk 11/1 L2TP tunnel 2 PPP_L2TP 20.1.1.2

10.0.1.1

Figure 34.

PPPoA over L2TP

4.1.6

Subinterface profile definition


The subinterface profile is a set of pre-defined configuration variables, which can be applied to one subinterface or many subinterfaces (objects of the same type) during the provisioning process. The use of profiles decreases configuration time and increases accuracy.

150 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

The following are the profile parameters: 1. 2. 3. Profile name Profile subinterface type (routed/bridged/RBE/PPPoA) 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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

151 (252)

Provisioning

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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

There are three different kinds of profiles, which makes provisioning easier: client subinterface profile, DSL line profile, and DSL alarm threshold profile. All those profile types are dynamic. It means that at the moment when some setting in a profile (which is in use) is modified, modification takes place in all DSL ports or client subinterfaces, which use that profile. This kind of dynamic profiles are extremely useful, if for example DSL line rates for certain service has to be increased. It is also possible to use a profile just as a way to copy certain parameters to a DSL port or client subinterface. For example when you create a client subinterface, you can select a suitable profile and after creating the subinterface, you can modify the subinterface so that you disable the profile (profile None in Web-based Craft Terminal or NetAct). Thus, all the settings from the profile are copied to that subinterface, but the subinterface does not have a reference to the profile any more. Also if a profile in use is deleted, all the settings from the profile are copied to the client subinterface/DSL port. A client subinterface profile includes different parameters depending on the type of the client subinterface: bridged, RBE, routed or PPPoA. The type is specified when a client subinterface profile is created. A DSL line profile includes rate settings (fast/interleave, max/min rates, startup mode) and some DMT settings like Noise Margin. The DSL alarm threshold profile includes alarm thresholds for physical alarms of a 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 the D500. In-Band management traffic is totally separated from data traffic. It uses its own VLAN ID or ATM PVC. The physical trunk port in an In-Band management connection can be either the GE trunk port or STM-1 tributary port. When In-Band management is created through a Gigabit Ethernet trunk, the InBand subinterface has to be created with the IP address and VLAN ID defined (it is automatically a routed subinterface). In addition to the IP gateway configuration, a static route to the management network has to be created. When In-Band management is created through a tributary port, the In-Band subinterface has to be created with the IP address and VPI/VCI value (it is also a routed subinterface with the RFC-2684 routed LLC encapsulation). In this case a separate 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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

153 (252)

Provisioning

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 mgmt 10.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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

4.1.8

DHCP relay pools in the D500


It is possible to create multiple relay pools, change their properties (for example enable/disable Option 82, and change the DHCP server address) and delete relay pools. Relay pools support the configuration of two DHCP servers (primary and secondary) behind the routed trunk. The DHCP relay pool name is needed to enable the DHCP relay on a subinterface. The relay pool name is required also for creating the subinterface profiles. The MIB database can be converted from R3.1 to R3.2. The old DHCP relay configuration data in a subinterface and subinterface profile context is converted to the DHCP relay pool configuration data while upgrading the node. DHCP-enabled interfaces prevent clients from using static IP addresses. DHCP broadcast response messages from the DHCP server are unicasted by the D500 to the 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 82 handling (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 or subinterface profile. To delete an existing relay pool, use the following command: CONFIGURE IP DHCP DELETE <poolname>

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

155 (252)

Provisioning

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 given DHCP 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 New DHCP Relay Pool dialogue box. The default setting for ARP spoofing is disabled. If ARP spoofing is enabled for the DHCP-enabled client subinterfaces in the same subnet, ARP spoofing/IP spoofing is protected by the system. The system checks the ARP source MAC and source IP pattern against the DHCP's lease database. This database contains MAC IP pairs for which the DHCP server has provided the IP address. If the pattern match fails then the packet is dropped.

4.1.9
4.1.9.1

Connection type
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. In a port-based VLAN switch a port accepts Ethernet frames without VLAN tagging and tags all incoming packets with a predifined port VLAN. The port has a list of all VLAN IDs it accepts for outgoing packets. It strips VLAN tags before it sends packets 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 the Ethernet frame. VLANs are like independent subports for this port. It is not possible to switch packets between VLANs; routing is needed to pass traffic between VLANs.

156 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

The D500 supports port-based VLANs in the subcriber subinterface and IEEE802.1Q tag -based VLANs in trunk ports. IEEE 802.1Q VLAN tags are not used in RFC2684-encapsulated Ethernet PDUs going to subscribers via line cards. Internally the subscriber subinterface has a port-based VLAN ID that is inserted into incoming packets. The same VLAN ID is used for accepting outgoing packets. For VLAN bridged networks, only the VLAN ID is required to establish VLAN membership. The VLAN ID identifies the subinterface (ATM PVC) as a member of a particular VLAN. The VLAN ID is inserted into the trunk interface Ethernet frame to uniquely identify the VLAN membership of the frame. The VLAN ID field can accept up to 4094 different VLAN IDs. Value 0 is used to disable a VLAN. The figure below shows protocol stacks used by VLAN bridged connections. The main difference between the VLAN and non-VLAN cases is that VLAN VCs are mapped 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 Ethernet interface, clients do not see VLAN IDs in their LANs. The client MAC address is used to forward data from the CPE to the client host. A VLAN tag is added to the Ethernet frame in the upstream direction and stripped out in the downstream direction. The GE trunk supports Ethernet frames of size from 64 to 1518 octets. If VLAN tags are used, the maximum frame size increases to 1522 bytes.

Client PC

CPE

D500
802.1Q

SMS
802.1Q

802.3 RFC-2684 Bridged RFC-2684 Bridged AAL5 ATM-PVC 802.3 802.3

Ethernet

AAL5 ATM-PVC

DSL

Ethernet Physical Layer 1000B-TX

Figure 35.

Protocol stacks in the VLAN bridged network

The figure below shows an example of VLAN support in the D500:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

157 (252)

Provisioning

Priority bits
Destination Source Length/ Payload Mac Mac Type 0 - n bytes 6 bytes 6 bytes 2 bytes PPPoE Destination Source VLAN Length/ Payload Mac Mac ID Up to Type 0 - n bytes 6 bytes 6 bytes 4 bytes 2 bytes

D500
Eth/ATM/DSL 0/100 CPE PPPoE Bridged

ISP Ethernet Network


VLAN 1

iTV Manager Broadcast Server Encoders & Transcoders

0/100 CPE DHCP

RBE

VLAN 2 VLAN 3

ATM DHCP 0/100 CPE DHCP Bridged

ETH

With the D500 R3.1 VLAN can be used To To To To separate individual DSL customers wholesale DSL isolate services, such as TV/VoD offer layer 2 connections for businesses

Figure 36.

VLAN support (IEEE 802.1Q)

The figure below shows an example of the protocol stacks used where a nonVLAN bridged connection is configured through the D500. The upper layer protocol used is PPP, but in principle the D500 does not distinguish between the protocol types carried over Ethernet. In the case of a non-VLAN bridged connection, the decision on which VCC to forward a downstream Ethernet frame is based entirely on the client MAC addresses.

158 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

When an Ethernet frame is sent in the upstream (ingress) direction to the OSI layer 3 device (SMS), the MAC Address Table in the Ethernet trunk learns the source MAC addresses. If the frame is valid and the format is correct, the frames source MAC address and VC used are entered into the MAC Address Table. The ATM 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 to locate the associated VC from the MAC Address Table to forward frames in the appropriate clients.

Client PC
PPP

CPE

D500

SMS
PPP

802.3 Ethernet
RFC-2684 Bridged AAL5 ATM-PVC RFC-2684 Bridged AAL5 ATM-PVC 802.3 802.3

DSL

Ethernet Physical Layer 1000B-TX

Figure 37. 4.1.9.2

Protocol stacks in the Non-VLAN bridged network

ATM AAL5 encapsulation

The subscriber interface supports RFC-2648 Multiprotocol Encapsulation over AAL5 for encapsulating Ethernet or IP traffic over ATM. Using AAL5 Segmentation and Reassembly (SAR), the subinterface converts data payloads between Ethernet/IP PDUs and ATM Common Part Convergence Sublayer (CPCS) PDUs. Ethernet or IP PDUs are carried in the payload field of the ATM CPCS PDU over the D500 ATM connections. The D500 supports two methods of AAL5 encapsulation:
.

LLC encapsulation: This method allows multiplexing of multiple protocols over a single ATM VC. The protocol is identified by prefixing an IEEE 802.2 Logical Link Header/Subnetwork Access Protocol (LLC/ SNAP) field to the PDU per RFC-2648 specifications. The LLC/SNAP field contains information to identify the PDU as a routed or bridged PDU. VC based multiplexing: This method performs a higher layer multiplexing implicitly by placing the Ethernet or IP PDUs directly into the AAL5 frame without any encapsulation. Each protocol must be carried over a separate VC.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

159 (252)

Provisioning

The D500 supports PPP over ATM in the VC muxed and LLC encapsulation format (as per RFC2364). As shown in the following figure, the subscriber subinterface supports four provisionable ATM interworking descriptors (based on the above two methods) for encapsulating Ethernet traffic and VLAN tagging.

LLC IP
LLC/SNAP IP PDU

802.1Q Routed VLAN Frame


MAC HDR VLAN TAG Ether Type MAC Data/IP PDU CRC

VC MUX IP
IP PDU

Egress/ Downstream LLC Bridged No FCS


LLC/SNAP MAC HDR MAC Data

Non-VLAN Bridged Frames


MAC HDR MAC Data CRC

VC MUX Bridged No FCS


MAC HDR MAC Data

802.1Q Bridged VLAN Frames


MAC HDR VLAN TAG MAC Data CRC

Figure 38.

AAL5 encapsulation for Ethernet

AAL5 encapsulation type

This parameter provides four user-selectable interworking descriptors for the encapsulation of Ethernet PDUs into the payloads of AAL5 PDUs. AAL5 encapsulation is provisioned separately for each individual subscriber (VC connection). The encapsulation type provides instructions on how to carry different kinds of PDUs over AAL5 CPCS PDU.
.

VC Mux Bridged  In VC Multiplexing of Bridged Protocols, only PDUs of bridged protocol are carried in the payload of the AAL5 PDU. Since there is no need for protocol identification information, this reduces payload overhead. LLC Bridged  In LLC for Bridged Protocols, bridged PDUs are encapsulated by identifying the type of bridged media in the LLC/SNAP header.

160 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

4.1.10
4.1.10.1

Subinterface protocol types


PPP grooming

PPP grooming can be enabled or disabled for each subinterface. If PPP grooming is 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 side VLAN/VCC. In this case, the client side PPPoA and PPPoE traffic is forwarded to the configured trunk side VLAN/VCC. The client side PPPoE traffic grooming is straightforward: PPPoE sessions are transparent to the D500 node, and frames are passed transparently (just like regular bridging). If a PPP destination has been specified for a specific connection, the D500 node forwards all PPP traffic to the selected VLAN/VCC. In case of PPPoA connections, the D500 node has to act as a PPPoE client, thus opening/closing PPPoE sessions upon PPPoA clients' requests. Egress (downstream) PPPoE (data) traffic is forwarded to PPPoA clients according 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 for transporting multi-protocol packets across layer 2 (L2) point-to-point links. In the DSL application, PPP can manage point-to-point connections for multiple client hosts through the D500 to a broadband remote access server (BRAS), such as SE800. Each client, either PC or CPE, uses its own PPP protocol stack. Access control, billing, and service subscription, based on session time or services used, can be provided independently to each subscriber by associating user ID profiles to a user name and password. PPP has two distinct stages: discovery stage and authentication stage. When the client host initiates a PPP session, it must first discover which BRAS can initiate the clients request. The server authenticates the identity of the clients user name and password. If authentication is successful, the client and server establish a point-to-point connection.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

161 (252)

Provisioning

From the traditional ATM based DSLAM point of view, the PPP sessions through the DSLAM have been transparent. The connections have been switched on the ATM 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 Ethernet layer it saves some overhead but in practise also requires the session to be terminated in the ADSL CPE, which in turn leads to a need for a routing functionality. The PPPoE adds overhead but has in practise been more widely deployed because of the easier installation of a bridged CPE. Another advantage of PPPoE over PPPoA is the ability to have several simultaneous PPP sessions over one layer 2 connection. The D500 provides new opportunities for PPP deployments. The new enhanced model to manage traffic enables the D500 to switch and queue PPP sessions, allows simultaneous PPPoE connections with RBE connections, converts PPPoA sessions to PPPoE when the GE trunk is used, and aggregates sessions to save layer 2 provisioning work. The most common option for PPP deployments is to have a PPPoE server behind the trunk side VLAN/VCC. In this case, PPPoA and PPPoE traffic of the client side is forwarded to the configured trunk side VLAN/VCC. For PPPoE traffic on the client side grooming is straightforward: PPPoE sessions are transparent to the DSLAM, and frames are passed transparently, just like in regular bridging. If a PPP destination has been specified for a specific connection, the D500 forwards all PPP traffic to the selected VLAN/VCC. If there are PPPoA connections, the D500 has to act as a PPPoE client, thus opening and closing PPPoE sessions upon PPPoA clients requests. PPPoE traffic returning from the network is forwarded to PPPoA clients according to the PPPoE session.
4.1.10.2 Multicast

There are three modes: IGMP proxy, IGMP snooping, and none. IGMP snooping is supported in the bridged subinterface. IGMP proxy is supported in routed, RBE, and bridged subinterfaces. When IGMP is enabled, the mode is chosen on the basis of the trunk subinterface. If the trunk subinterface is bridged and IGMP is enabled, the mode is IGMP snooping. If the trunk subinterface is routed and IGMP is enabled, the mode is IGMP proxy. A routed or RBE subinterface can be enabled to support multicast. Multicast is supported by an IP services type of connection. If multicast is supported via an ATM connection, then the traffic descriptor defines the bandwidth supported by that connection. The subinterface defines the number of multicast channels supported. This number restricts the number of multicast flows to be concurrently carried within the ATM connection. Multicast flows in this kind of connection

162 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

have to be provisioned to have the highest priority (with the exception of VOD traffic). If the type of the IP services subinterface is DiffServe, then a packet traffic 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 the subscriber by replicating (multicasting) the data streams within the D500. This is necessary when implementing TV broadcast-like delivery networks using DSL technology to avoid multiplying data streams per subsciber in the transmission network, thus saving transmission bandwidth. The Nokia D500 provides support for IP multicasting in the ATM or Gigabit Ethernet trunk/control unit. The multicasting function allows communication with core network content servers, also called the head-end, which transmit by IP multicasting 100250 channels of digital TV at 26 Mbit/s per channel. Subtended from a multicast router network or directly from the video server, the D500 provides an Internet Group Management Protocol (IGMP) proxy function, authorisation function, and the ability to replicate and forward MPEG over IP video streams to the digital subscriber lines. When the system receives video channel IGMP join requests from the Set Top Box (STB) behind the DSL, the D500:
.

Verifies user (STB) access rights to the requested channel against information 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 the channel by an IGMP leave request from the STB. Subsequent leave-join requests create the equivalent of channel switching in normal broadcast TV. If the user is not authorised, the system returns a service denial message. IGMP requests are forwarded upstream to request the channel from an IP multicast router if the channel is not yet available at the D500, thus the D500 acts as an IGMP proxy. If the channel stream is already resident in the D500, the IGPM join is processed locally. It is practical to flood all frequent channels to the D500 initially because the network dimensioning typically has to support all channels anyway. If all the possible channels are initially flooded to the D500, all subsequent channel change functions are local to the D500. Then there is no need to 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 D500 without central database access.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

163 (252)

Provisioning

Communication for video delivery

Communication for video delivery through the DSL access network breaks into three specific events and interchanges: 1. 2. D500 start-up: Initiation of broadcast content to the D500 (with class D addresses) and, if required, provisioning of user authentication information STB start-up: Initial negotiation between the set top box (STB) and a management database to generate an electronic program guide (EPG). This EPG contains the map of class D addresses associated with the broadcast video content at the D500, so, for instance, it becomes clear that CNN on Channel 63 can be found at xxx class D address. Channel selection: Request and delivery of video content to the STB based on IGMP join and leave requests for the class D addresses of the video content available at the D500. The key to this function is authentication of a particular STB to receive specific video content.

3.

The D500 can negotiate these activities in a number of ways, depending on operator requirements for channel flexibility, capital investment and channel change times. Each interchange is described with its options below. At the D500 start-up, the delivery of broadcast content from higher in the network must be initiated. This can occur in two ways: 1. The D500 is flooded with the multicast channels without having to request them. In this case, the negotiation between a multicast router and the D500 is not required at all. The D500 uses IGMP to request a multicast channel only when a subscriber requests that channel and it is currently not available at the D500. This method would most often be used to add less popular content to the stream already sent to the D500 using method 1 or 2, above. In this case, the D500 issues an IGMP leave request from the multicast group when it is not requested by any subscribers. This feature is useful when the aggregate interface of the D500 cannot support the bandwidth required for all flooded channels.

2.

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 at the D500. Most commonly, this occurs by an exchange in the data network between the STB and through the iTV application. In addition, many STBs require that their operating software be downloaded at power-up, and this interchange occurs over the data network as well. It should also be noted that each EPG "ages", that is, it has a specified lifetime, and needs to be refreshed through the data network periodically.

164 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

At the channel selection, the STB sends an IGMP join request for a particular class D address to receive content. This join request is authenticated; that is, it should 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 been given an EPG are authorised to join a multicast group that they know the class D address for. This method suffers from security issues with regard to pirating content; a subscriber not paying for the video service could determine 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 may be a viable implementation since it simplifies the provisioning of the system. 2. Channel authentication at the D500 The D500 is pre-provisioned with which subscribers (as identified optionally by their STB MAC address or port or both) are allowed to subscribe to which class D addresses. This allows only authorised subscribers to view content, and also allows provisioning of "premium" channels to a particular subscriber. In general the broadcast IP streams are assigned to either one or several Channel Packages, and individual subscribers are given access to Channel Packages rather than individual multicast streams. Both these operations are supported in the D500. 3. Channel authentication at higher network resources, through the iTV application This occurs for non-multicast content, where a subscriber is paying for a video stream not currently multicast. Authentication and billing occurs higher in the network, and the video stream is initiated at that time. This method is preferred for the first instance of near video on demand (NVoD) content. Subsequent subscribers to the address may be authenticated at the D500. The authorisation table of point 2 above is downloaded to the D500 from the NetAct Network management system of the D500. It is possible to implement a fully centralised management of the channel authorisation by interfacing customer care system to the NetAct, for example using the Corba interface. The exact design of this functionality is related to the selected identification and delivery methods of the DSL and the STBs, among other things, so it is normally implemented in a system integration project. Example 1. The following figure shows an example of a small multicast set-up.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

165 (252)

Provisioning

TV set 1

IP 161.1.1.1

IP 161.1.1.2 PVC 0/38

IP 151.1.1.1

CPE 1

STB 1
IP 151.1.1.2

Video server

D500
PVC 0/39

CPE 2
IP 151.1.2.1

Ch Ch Ch Ch

1 IP 225.1.1.1 2 IP 225.1.1.2 3 IP 225.1.1.3 4 IP 225.1.1.4

TV set 2

STB 2
IP 151.1.2.2

Figure 39.

Small multicast test setup

The server is broadcasting four streams with multicast addresses from 225.1.1.1 to 225.1.1.4, and there are two customers with Set Top Boxes (STBs) whose IP addresses are 151.1.1.2 (MAC address 00 40 43 F6 01 02) and 151.1.2.2 (MAC address 00 40 43 F6 10 4B). The four streams are to be configured as one package whose name is TestPackage1. The needed commands to the D500 are the following: configure ip multicast chanpkg new TestPackage1 225.1.1.1 225.1.1.2 225.1.1.3 225.1.1.4configure ip multicast clientauth new 00:40:43:F6:01:02 TestPackage1configure ip multicast clientauth new 00:40:43:F6:10:4B TestPackage1

Note
These are the only commands needed to configure the D500 to allow the conditional access. There may be several configuration operations needed to configure the STBs to allow them to present the channels to the end user, but this is a function of an individual STB.

166 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

Egress packets arriving from the trunk side are either forwarded to one or more ATM VCs or discarded. Ingress packets arriving on an ATM VC are either forwarded to a VCC, VLAN, an L2TP tunnel or, to a PPPoE session, or discarded. IP fragmenting is not supported in the trunk unit. It is assumed that the originator of the packet has performed MTU size discovery or has restricted the packet length to the appropriate value by manual configuration. Multicast and broadcast packets arriving from the trunk side need to be duplicated and sent to multiple ATM VCs. Broadcast packets need to be selectively copied to all ATM VCs, which belong to the bridge group associated with the VLAN ID of the arriving Ethernet packet. Multicast packets need to be selectively copied to subscriber side ATM VCs on which one or more hosts have recently joined a multicast group. This requires that the D500 terminates all IGMP traffic and detects when any host on a VC enters or leaves a multicast group.
Video-on-demand

The D500 node does not participate in the VOD transaction between the VOD client and server. This means that the D500 node does not separate VOD PDUs from other traffic. To make sure that VOD PDUs get priority over less timecritical traffic, DiffServ should be enabled and VOD PDUs should be tagged with a DiffServ code point that indicates higher priority. It is recommended that AF41 would be used for VOD traffic.

4.2
4.2.1

Basic packet forwarding rules


Downstream packets
Two basic types of subinterfaces are supported at the trunk interface: bridged and routed. Bridged interfaces can handle PPPoE traffic separately from the other traffic.
.

Unicast packets received on a bridged VLAN/VCC If the unicast packet's MAC address matches the Ethernet address at the trunk interface, it can be destined to the D500 node or it can be a locally terminated IP packet. If the MAC does not belong to the D500 system, the frame is a handled like a typical bridged frame and is forwarded to a single ATM VC based on the destination MAC.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

167 (252)

Provisioning

The MAC address table is built and maintained dynamically by learning source 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 same bridge group as the receiving VLAN.

Multicast packets received on a bridged VLAN/VCC Multicast packets are forwarded to all ATM VCs belonging to the same bridge group as the receiving VLAN.

Unicast packets received on a routed VLAN/VCC The forwarding decision is based on the destination IP address. The MAC header should contain the MAC address of the D500 node. The destination address is matched against the current routing table with the longest prefix match selected. The packet is then encapsulated in accordance with the parameters 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 on this subinterface, the trunk unit responds with an ARP reply on the same VLAN 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 one authenticated multicast recipient host.

Packets received on a one-to-one routed VLAN All the unicast and multicast packets are forwarded to the identified client VCC. Broadcast packets are discraded with the exception of ARP packets that are handled as in the regular subinterfaces 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 IP address. In bridging, anything other than PPPoE is forwarded based on the destination MAC address. If the interface is such configured, PPPoE frames can be passed to the trunk side PPPoE server.

168 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Packet-based provisioning

In a bridged subinterface a received frame that does not contain PPPoE (with or without MAC) traffic is simply forwarded to the corresponding bridge groups trunk subinterface. Source MAC addresses are also learned when bridged frames are passed in the ingress direction. In RBE subinterfaces, IP packets are routed normally, but PPPoE packets can be configured to be handled as in bridging.
.

Unicast packets received on a bridged subinterface If so configured, PPPoE packets are forwarded to the PPPoE server assigned to the sending subinterface. In PPPoE forwarding, the D500 just forwards PPPoE PDUs between the identified subinterfcaes. Non-PPPoE ingress packets are forwarded to the configured trunk side subinterface (VCC or VLAN).

Broadcast packets received on a bridged subinterface These packets are handled in the same way as unicast packets. Broadcast packets are not broacasted to other line subiterfaces although they belong to the same bridge group and VLAN.

Multicast packets received on a bridged subinterface Examples of multicast packets arriving in the ingress direction are packets addressed 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 the packet is routed to a single subinterface. The subinterface is selected from the routing table by means of the longest prefix match algorithm. If the packet 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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

169 (252)

Provisioning

All IP packets are routed as in the case of the routed interface. PPPoE packets are forwarded to the configured PPPoE server. If the PPPoE handling has not been enabled, the packet is dropped. RBE interface drops most packets not containing IP.
.

Broadcast packets received on RBE subinterface Other type of broadcast packets than ARP, BOOTP (DHCP) and PPPoE discovery frames are dropped at this interface. ARPs that query the MAC address 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 relay module. The DHCP relay passes the request to the DHCP server that has been configured onto this connection. Just like in the bridging case, PPPoE discovery 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

ATM VC cross-connection provisioning

5
5.1

ATM VC cross-connection provisioning


ATM VC cross-connection provisioning
The D500 Multiservice Access Platform (MSAP) cross-connects two ends of an ATM data pipe. This data pipe is called a virtual connection. In a typical DSLAM application one end of this data pipe goes to an ATM network via the trunk interface and the other end goes to the CPE via a line card port. The DSLAM is used to multiplex virtual connections coming from the subscribers to the trunk interface. The D500 MSAP, however, does not only multiplex virtual connections. 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 main types 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 tributary unit (TRB155) each support a maximum of 8000 connections. The maximum number of connections per a D500 DSL unit is 400. The maximum bandwidth capacity per a DSL unit is 1 Gbit/s.

Note
Additional provisioning information can be located in Provisioning parameters.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

171 (252)

Provisioning

5.1.1

A PVC connection
ATM supports two types of circuits: permanent virtual circuit (PVC) and switched virtual circuit (SVC). The D500 supports PVC connections. A PVC is provisioned by the network service provider as part of setting up subscriber service. Once a PVC is established, data goes in one end of the pipe, and comes out 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. The following must be specified for Link A: unit, port number, virtual path identifier (VPI), and virtual circuit identifier (VCI).

Note
See the figures later in this chapter to determine Link A for each type of crossconnection.

Virtual Link Z: Link Z can be either a trunk unit or a tributary unit. The following 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 crossconnection.

A connection ID number is an integer from 1 to 4064, assigned sequentially by the D500 system as each connection is established. When the D500 breaks a connection, that ID number is free. The connection ID number is reused when ID numbers 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: bandwith and cell buffers. If the node runs out of either bandwith or cell buffers, no new cross-connection can be made.

172 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

ATM VC cross-connection provisioning

5.1.2

DSL port parameters


Associated with the line card port are a series of DSL parameters that control how the line card port sends data over the copper network. Refer to ADSL provisioning, and/or VDSL provisioning for detailed information on these parameters. DSL provisioning information required from the service order includes 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 DSLAM multiplexes traffic coming from the CPE to the ATM network interface located in the trunk unit. The line card port is connected to the subscriber s residence or businessvia the existing copper twisted pair networkusing digital subscriber line (DSL) technology. At the ATM network interface, the D500 MSAP sends and receives ATM cells containing customer payload. At the subscriber s end of the twisted pair, the NIC or external router/modem extracts the customer payload out of the ATM cell format, and reassembles the payload back into its original form. From the perspective of the subscriber or the ATM network backbone, the data goes in one end of the data pipe at the ATM network interface, and comes out the other end at the customer s PC.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

173 (252)

Provisioning

D500 Upstream Downstream Ports

ATM Network

Trunk Unit

Line Card Virtual Connection CPE

Link Z Connections are multiplexed

Link A

Figure 40.

Line card to trunk unit

Line card to tributary unit

Tributary units can also be utilised as network interfaces. The trunk capacity can be increased by adding more tributary ports to the aggregate direction, for example, to offer the extra capacity desired to allow streaming media connections to subscribers. A tributary unit is typically used in the aggregate side also when several D500 nodes or D500 RAMs have been cascaded. In the ingress direction of this application, connections of the first D500 element exit from the tributary unit port(s) and enter the second D500 again via the tributary unit port(s). The second D500 then uses the trunk/control unit (or tributary unit) as a trunk interface to the ATM network. In this VC cross-connection case, traffic from a line card connection is first forwarded to the trunk unit. The trunk unit cross-connects (switches) the traffic to a tributary unit, which sends the traffic out to the ATM network in the upstream direction. The reverse path is followed in the downstream direction. The line card is provisioned as Link A and the tributary unit as Link Z. The figure below illustrates this configuration:

174 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

ATM VC cross-connection provisioning

D500 Upstream Downstream Ports Ports ATM Network Trib. Unit Trunk Unit Line Card CPE Link Z Connection switched to the Tributary Unit Link A

Figure 41.

Line card to trinbutary unit

Tributary unit to trunk unit

This kind of cross-connection can be used when several DSLAMs have been cascaded. The subtended DSLAM(s) can be connected to the port(s) of a tributary unit, and the trunk unit can be used as an interface to the ATM network. In this type of cross-connection, traffic from the subtended DSLAM is forwarded from the tributary unit to the trunk/control unit. The trunk unit cross-connects the traffic to the trunk interface and out to the ATM network in the upstream direction. The reverse path is followed in the downstream direction. The trunk unit is provisioned as Link Z and the tributary unit as Link A. The figure below illustrates this configuration:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

175 (252)

Provisioning

D500 Upstream Downstream

Ports ATM Network Trunk Unit Trib. Unit Virtual ATM Switch/ Connection Router Link Z Connections are switched Link A

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 use tributary units on both sides of the ATM connection. In the upstream direction of this type of cross-connection, traffic from the tributary unit is cross-connected in the trunk unit back to the tributary unit (the same or different tributary unit) and out to the ATM network. The reverse path is followed in the downstream direction. The tributary unit nearest to the ATM network is Link Z and the one closer to the ATM switch (another DSLAM, for instance) is Link A. The figure below: tributary unit to tributary unit figure illustrates this configuration:

176 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

ATM VC cross-connection provisioning

D500 Upstream Downstream

Ports ATM Network Trib. Unit Trunk Unit Trib. Unit

Ports

ATM Switch/ Router Link Z Connection switched to the Tributary Unit Link A

Figure 43.

Tributary unit to tributary unit

Note
In all of the VC cross-connection cases described above, incoming traffic is policed 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 for each end of the connection. The VPI (virtual path identifier) identifies the route to be used by the ATM cell. A virtual path may include multiple virtual channels. The VCI (virtual channel identifier) identifies the specific virtual channel to which the cell belongs. The VPI and VCI are translated at each ATM switch and are unique only for a given physical link. Ranges for the VPI and VCI values on the OC-12/STM-4 trunk side are:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

177 (252)

Provisioning

VPI: 04095 VCI: 3265535.

Ranges for the VPI and VCI values on the OC-3/STM-1 tributary unit side are:
.

VPI: 0255 VCI: 3265535.

Ranges for the VPI and VCI values on the line side are:
.

VPI: 0255 VCI: 3265535.

Select VP Connection to set up a Virtual Path (VP) without setting up individual Virtual Circuits within the VP. For example, if you have multiple PCs connected to a single ADSL router at the remote end CPE, use the VP Connection option to configure 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 for service.
.

Unlocked makes the connection usable if there are no other conditions blocking its use. Locked makes the connection unavailable for service. The administration state should be set to Locked when configuring or deleting a connection.

Traffic descriptors: Two ATM traffic descriptors must be provisioned for each connection, including VC cross-connections. Separate traffic descriptors for downstream (Z to A) and upstream (A to Z) direction allow you to provision different bandwidths for each direction. You can select from a set of default traffic descriptors or create new traffic descriptors. For more information on how to create and use traffic descriptors, refer to Traffic descriptors. The Craft Terminal New Connection dialog box shows the provisioning parameters.

178 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

ATM VC cross-connection provisioning

Figure 44.

New connection

Default settings for Link A are VPI 0, VCI 100, and the default traffic descriptor is 9. The default setting for Link Z is the trunk/control unit. The defaults are also seen in the Preferences dialog box in Web-based Craft-Terminal. For additional information on creating UBR connections, see QoS in ATM networks.

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 to pre-select the slot and port in the Tree View for Link A and Link Z settings. When you open the New Connection dialog box, these pre-selected settings appear automatically in the dialog box, and the only settings you need to enter for each connection are the VPI/VCI and the traffic descriptors (and optionally the VP Connection check box).

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

179 (252)

Provisioning

5.1.7

Craft Terminal reference information


For additional reference information on the various sets of tab pages and dialog boxes used for setting up and modifying ATM connections, see Web-based Craft Terminal.

180 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

6
6.1

QoS provisioning
D500 traffic management
Traffic management and traffic descriptors are required to ensure proper resource allocation and to quarantee the agreed quality of service (QoS). The D500 supports simultaneous feeds from ATM and IP/Ethernet interfaces while it provides 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 of information or services they are carrying. These major steps of the D500 traffic management are described below:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

181 (252)

Provisioning

Incoming packets

Classification, policing & marking

Queuing & congestion management

QoS/CoS queues CBR VBRrtEF-Eth. high VBRnrt w/o tagAF4-Eth. medium

Priority scheduling & class-based shaping

Outgoing packets (in priority order)

Scheduling voice data video VBRnrt with tag UBRDF-Eth. low WRED, EPD data video voice

Figure 45.

Major traffic management steps in the D500

Classification

Classification identifies the PDUs. In the D500 the classification process consists of two phases. The first pass examines the received data in a cell/block level (for example, the interface which the cell came from, the connection which it belongs to, or the ATM CLP bit, if it has been set). The second pass inspects the complete PDUs and makes the final classification decision (based on the IP destination address and DiffServ code points, for instance). The classification decision is a prerequisite for all the actions that follow: policing incoming traffic based on the defined traffic parameters, routing the PDU to the correct interface and to the appropriate 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 the traffic contract. In principal the policing process in the D500 is implemented similarly for both ATM and IP/Ethernet traffic. But because ATM as a cell-based protocol differs from packet-based IP/Ethernet protocols and the monitored

182 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

parameters are different, there are also some differencies in their policing processes. ATM connections can use a generic cell rate algorithm (GCRA), whereas a Two Rate Three Color Marker (trTCM) algorithm can be applied to packet-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 in ATM cells, changing the DiffServ drop precedence from AF41 to AF42 in IP packets) PDU can be dropped.

Queueing

Queueing stands here for a function in which PDUs are forwarded to correct output ports and to appropriate priority queues. An output port can be for example 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 traffic management steps in the D500. For ATM traffic all five queues can be used. For IP DiffServ traffic or for Ethernet traffic supporting IEEE 802.1p user priorities there are three priority queues. The selection of the QoS/CoS queue is based purely on the classification results. The policing process cannot change the destination 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 part of a queuing function. The QoS/CoS queue sizes and filling thresholds are predetermined. When a congestion threshold is reached in a queue, a packet dropping and congestion avoidance mechanism is applied to the queue. The D500 uses 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. When the queue reaches the 100-% level, all incoming traffic for the queue will be dropped.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

183 (252)

Provisioning

Early packet discard (EPD) (also called frame discard) is supported for ATM interfaces. EPD makes an intelligent choice and drops all cells of an incoming packet instead of randomly dropping cells from many packets. Also explicit forward congestion indication (EFCI) is supported for ATM interfaces. EFCI is used 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 is exceeded in a QoS/CoS queue.
Scheduling and shaping

Scheduling and shaping provide the appropriate servicing of the queues so traffic can be presented into the network in an appropriate manner, with respect to traffic class priorities. The D500 supports scheduling and shaping on a traffic class and queue basis. The actual implementation is described in the following figure:

Qos/CoS queues
CBR VBRrtEF-Eth. high

Queue level shaping / rate limiting


Dynamic scheduler 1

Interface level rate limiting & strict priority scheduling

Bandwidth reserved by CAC

VBRnrt w/o tag AF4-Eth. medium VBRnrt with tag UBRDF-Eth. low

Dynamic scheduler 2

Logical port

FIFO scheduler

Figure 46.

Traffic scheduling and shaping

Inside the routing switch processor (RSP) a logical port is used to limit the rate of the total traffic that can be forwarded to an interface (for example an ADSL port or a trunk interface). Behind the logical port there are three schedulers  two dynamic and one first in first out (FIFO)  and these schedulers are servicing five QoS/CoS queues.

184 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

Connection admission control

The connection admission control (CAC) process is defined as the set of actions taken during the packet subinterface or ATM connection establishment to determine whether the predefined CoS/QoS parameters can be met when the connection is set up or whether the connection should be rejected. The CAC function is always enabled in the D500. The scheduling/shaping rates used for queues (=queue drain speeds) are calculated by the connection admission control (CAC) process. The CAC uses a formula to determine a quaranteed bandwidth for each queue. The shaping rate for the CBR and EF/Ethernet high priority traffic is established by summing the peak cell rates (PCRs) of all the provisioned CBR connections or peak information rates (PIRs) of all the EF/high priority flows respectively. For the VBRrt, VBRnrt w/o tag, VBRnrt with tag, and for AF4/Ethernet medium priority queues the shaping rate is derived by summing the sustainable cell rates (SCRs) or committed information rates (CIRs) of the respective connections/flows, and by adding some excess bandwidth to this based on the bursts configured. The UBR or DF/Ethernet low priority queue gets the remaining capacity left for the logical port (= logical port rate minus quaranteed bandwidths for the port). The D500 supports also CAC overbooking. If this feature is enabled, it is possible to 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 supported by the logical port. As a result the bandwidths for these queues are no longer quaranteed, and in case of congestion lower priority traffic may have to be discarded. Thus, in the D500 scheduling process the dynamic scheduler 1 has the highest priority, dynamic scheduler 2 the second highest priority, and the FIFO scheduler takes care of the remaining bandwidth left for the logical port. If there are two queues behind one scheduler, a weighted round robin (WRR) type of mechanism is used to determine the queue to be serviced (weights are calculated automaticly by 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 is enabled, all the ATM QoS, IP DiffServ and Ethernet 802.1p priority features for that unit are disabled, and the units traffic is processed in both directions as best effort only (one logical port and the FIFO scheduler is used for the whole unit in the 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 amount of quaranteed bandwidth for each port in the card. As a result the sum of all the ports maximum bandwidths is allowed to exceed the units total bandwidth. Consequently, more bandwidth can be supported per port providing that all ports

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

185 (252)

Provisioning

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 compete of the total card bandwidth in a best effort fashion. The line card must not have any 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). Rules that apply to packet policing, queueing, dropping and modification are presented for the bridged, routed and RBE modes. IP CoS is based on the differentiated services code points (DSCP), which are located in the service type field of the IPv4 header as shown in DSCP in the IPv4 header. These six bits are used to indicate the service class of the flow (EF, AFx or DF). In the case of the AFx class, the bits indicate also the drop probability that should be applied to the flow (packets with higher drop precedence should be discarded first in a case of congestion).
Diffrentiated Service (DS) field not used by DiffServ

IPv4 Type of Service (ToS) octet IP precedence bits or class selector codepoints 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 011xxx 010xxx 001xxx -> -> -> -> assured assured assured assured forwarding forwarding forwarding forwarding (AF4) (AF3) (AF2) (AF1)

000000 -> default forwarding (DF)

Figure 47.

DSCP in the IPv4 header

186 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

The queues and schedulers used for DiffServ CoS classes in the D500 are shown in the figure below:

Qos/CoS queues

Queue level shaping / rate limiting


Dynamic scheduler 1

Interface level rate limiting & strict priority scheduling

EF

Bandwidth reserved by CAC

AF4

Dynamic scheduler 2

Logical port

DF (= BE)

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 bridged subinterfaces. When a subinterface is configured to a bridged mode and if Ethernet user priorities are not supported, all the incoming packets are forwarded to DF queues. If Ethernet user priorities are supported, these priority bits can be used to direct packets to appropriate CoS queues (refer to Ethernet CoS based on VLAN user priorities). The DiffServ code point bits are not examined, and they are never modified in the D500.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

187 (252)

Provisioning

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 DF queue. The CoS bits are not touched (assuming that both input and output subinterfaces are configured to the non-DiffServ mode; however, if the output subinterface is set to the DiffServ mode, the outgoing packet has CoS bits set to DF). DiffServ mode supports two options: pass mode and map mode. In the pass mode the DiffServ code points (DSCP) of the incoming packet are used directly for queue selection. The D500 supports three CoS queues for DiffServ traffic: EF, AF4 and DF. The following table explains how the DiffServ traffic classes of the incoming packets are converted into the three service classes supported by the the D500:

Table 32.

DiffServ traffic classses converted into service classes DiffServ traffic class D500 traffic class
AF4 AF4 EF AF4 AF3 AF2 AF1 DF EF AF4 AF4 AF4 AF4 DF

IP precedence bits
111 110 101 100 011 010 001 000

When a subinterface is set to a map mode, the user can remap any received DiffServ 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 is possible to convert packets received from a device not supporting DSCPs into fixed DSCP packets by mapping code points of all the packets received from that subinterface to the same value. These new remapped DSCP values are then used in policing and queue selection.

188 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

For routed subinterfaces in the map mode, the D500 gives the DSCP field of the outgoing packets one of the three possible values: EF, AF4 or DF. For AF4 traffic the default drop precedence is AF41, but it may be changed to AF42 by the policing process. In the pass mode the packets going out from a routed subinterface contain the same DSCP values as were received in the incoming packets.
6.2.1.3 RBE subinterface

When a routed bridged encapsulation (RBE) is configured to a client side subinterface, bridged AAL5 encapsulation is used towards the CPE, but the D500 skips the Ethernet header (layer 2) and does all the processing based on the IP header (layer 3). From the traffic managements point of view, an RBE subinterface functions in many ways as a routed subinterface. However, there is one difference: the packets going out from the RBE subinterface always contain the same DSCP values as were received in the incoming packets (the D500 leaves the DSCP field untouched, also in the case where the map mode is used in a routed input subinterface). However, when packets are received from an RBE subinterface, both the pass and map modes are supported exactly as in routed subinterfaces.

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 network treatment. The policing process (based on trTCM) tests the EF traffic against the peak information rate (PIR) and the peak burst size (PBS) defined in a packet traffic descriptor (PTD) for the policed subinterface. If the packet conforms with the PTD, it is queued to the VBRrt-EF queue, which is scheduled by dynamic scheduler 1, otherwise it is dropped. The following table summarises how the D500 processes EF traffic:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

189 (252)

Provisioning

Table 33. Fill factor of the queue (%)

EF traffic processed by the D500 Packet forwarding Cell modification Packet DSCP modification Packet out Routed Green Red
Drop

Packet out RBE xx


Same as packet in Same as packet in

CLP bit

EFCI

EF
Assign

050

Forward

5080

Drop 50 % randomly Drop 50 % randomly Drop

Drop

Assign

80100

Drop

Assign

Assign

Same as packet in

100

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. It defines a method with which similar type of flows can be given a forwarding behavior with some assigned level of queuing resources and different forwarding assurances by controlling the drop probability of the AF marked packets. The policing process (based on trTCM) tests the AF traffic against the peak information rate (PIR) and the peak burst size (PBS) as well as against the committed information rate (CIR) and the committed burst size (CBS) defined in a packet traffic descriptor (PTD). Conforming packets are queued to the VBR-nrt w/o tag-AF4 queue, which is scheduled by dynamic scheduler 2.

190 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

The following table summarises how the D500 processes AF traffic:

Table 34. Fill factor of the queue (%) Packet forwarding

AF traffic processed by the D500 Cell modification Packet DSCP modification Out Routed Map Out Routed Pass AF42 xx xx Out RBE

Green

Yellow
Forward

Red

CLP bit
Assign if yellow

EFCI

AF41

050

Forward

Drop

Assign if green

Assign if yellow

Same as packet in

Same as packet in

5080

Drop 50 % randomly Drop 50 % randomly Drop

Drop

Drop

Assign

Same as packet in

Same as packet in

80 100

Drop

Drop

Assign

Assign

Same as packet in

Same as packet in

100

Drop

Drop

Note
Green: The packet conforms to CIR and CBS criteria. Yellow: The packet violates CIR and CBS criteria, but conforms with PIR and PBS 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 000000 gets the traditional best effort (BE) service after EF and AF traffic.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

191 (252)

Provisioning

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, which is scheduled by the FIFO scheduler. The following table summarises how the D500 processes DF traffic:

Table 35. Fill factor of the queue (%)

DF traffic processed by the D500 Packet forwarding Cell modification Packet DSCP modification Packet out Routed Green Red
Forward

Packet out RBE xx


Same as packet in Same as packet in

CLP bit
Assign if red

EFCI

DF
Assign

050

Forward

5080

Drop 50 % randomly Drop 50 % randomly Drop

Drop

Assign

80100

Drop

Assign

Assign

Same as packet in

100

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 bridged subinterfaces. The description includes the rules that apply to packet policing, queueing, dropping, and modification.

192 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

IP CoS based on DiffServ code points (refer to IP CoS based on DiffServ) is a method that can be used to differentiate layer 3 service classes, so that the D500 traffic management can process packets according to their priority level. The method is, however, not applicable to bridged subinterfaces, which examine the packets only at the Ethernet (layer 2) level. To support different service classes also in the bridging mode, it is possible to separate different Ethernet CoS classes by using Ethernet user priority bits. These three user priority bits are part of the Ethernet frames VLAN tag (described in IEEE 802.1p/802.1q) as shown in the following figure.
VLAN tag (QTag): Octet 1: Octet 2: Octet 3: Octet 4: 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 user p. CFI VLAN identifier (VID) length / type = 802.1Q tag type Tag control information

Figure 49.

User priority bits in the Ethernet VLAN tag

Internally the D500 supports three Ethernet priority service classes: high, medium and low. The user can configure the global mapping of the VLAN tag user priority field values to the D500 priority service classes (in other words the user can decide which group the user priority field values belong to). The configured mapping applies to the whole node (in other words. there is only one global VLAN user priority mapping per node) and the new mapping settings take effect only after the node has been rebooted. By default the global mapping between the Ethernet VLAN tag user priority field values and the D500 Ethernet priority service classes is as shown in the following table:

Table 36.

Global mapping of the VLAN user priority field values D500 internal service class in the pass mode *) Ethernet user priority field values of outgoing frames in the map mode **)
5 3 1

Ethernet user priority field values of incoming frames


4, 5, 6, or 7 2 or 3 0 or 1

High Medium Low

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

193 (252)

Provisioning

*) In the pass mode the internal service class is determined directly from the user priority field of the incoming frame. In the map mode the user can remap the internal service class per subinterface. **) In the pass mode the outgoing frame has the same user priority field value the incoming frame had. In the map mode the outgoing frame has the user priority field value determined by the global user priority of the internal service class mapping. The queuing and scheduling of Ethernet CoS traffic is handled in the D500 basically 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. These queues and schedulers depicted from the point of view of Ethernet CoS are shown in the following figure:

Qos/CoS queues

Queue level shaping / rate limiting


Dynamic scheduler 1

Interface level rate limiting & strict priority scheduling

802.1p High priority

Bandwidth reserved by CAC

802.1p Medium priority

Dynamic scheduler 2

Logical port

802.1p Low priority

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 in the bridging mode. If Ethernet CoS is not enabled for a bridged subinterface, incoming packets are always forwarded to UBR/DF/Eth. low queues. By default the Ethernet CoS is disabled.

194 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

If Ethernet CoS is enabled, there are two options: pass mode and map mode. In the pass mode the user priority bits of the incoming packet are used directly to select the internal Ethernet priority service class, which determines the policing, queue selection and scheduling behaviour. In the map mode the received Ethernet priority service class can be remapped per subinterface to any of the three service classes (high, medium or low) supported by the D500. The D500 supports both pass and map modes in the upstream direction. In the downstream direction only pass mode is supported. Mapping can be applied also in cases where there is no VLAN tag included in the received Ethernet frame. This feature may be usefull for example when VLAN tags are not used in the client side subinterface. (The D500 supports both Ethernet frames with VLAN tag and without VLAN tag in the client side.) In this case in the upstream direction Ethernet CoS mapping can be done on a PVC basis: all frames received from a subinterface (PVC) are mapped to the preconfigured priority service class. This mapped service class is then used for selecting the policing and queuing behaviour, and the respective user priority field value is inserted into the VLAN tag in the trunk interface. For more information on how different Ethernet classes of service are processed in 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 the peak information rate (PIR) and the peak burst size (PBS) defined in a packet traffic descriptor (PTD) for the policed subinterface. If the packet conforms to the PTD, it is forwarded to the VBRrt-EF-Eth. high queue, which is scheduled by dynamic scheduler 1, otherwise it is dropped. The following table summarises how high priority traffic is processed in the D500:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

195 (252)

Provisioning

Table 37. Fill factor of the queue (%)

High priority traffic processed by the D500 Packet forwarding Cell modification Ethernet user priority modification Packet out Bridged Green Red CLP bit EFCI Map mode
High

Pass mode
Same as packet in Same as packet in

050

Forward

Drop

5080

Drop 50 % randomly Drop 50 % randomly Drop

Drop

High

80100

Drop

Assign

High

Same as packet in

100

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 against the peak information rate (PIR) and the peak burst size (PBS) as well as against the committed information rate (CIR) and the committed burst size (CBS) defined in a packet traffic descriptor (PTD). Conforming packets are forwarded to the VBR-nrt w/o tag-AF4-Eth. medium queue, which is scheduled by dynamic scheduler 2. The following table summarises how medium priority traffic is processed in the D500:

196 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

Table 38. Fill factor of the queue (%) Packet forwarding

Medium priority traffic processed by the D500 Cell modification Ethernet user priority modification Packet out Bridged

Green

Yellow

Red

CLP bit

EFCI

Map mode
Medium

Pass mode
Same as packet in Same as packet in

050

Forward

Forward

Drop

Assign if yellow

5080

Drop 50 % randomly Drop 50 % randomly Drop

Drop

Drop

Medium

80100

Drop

Drop

Assign

Medium

Same as packet in

100

Drop

Drop

Note
Green: The packet conforms to CIR and CBS criteria. Yellow: The packet violates CIR and CBS criteria, but conforms with PIR and PBS 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 the UBR-DF-Eth. low queue, which is scheduled by the FIFO scheduler. The following table summarises how low priority traffic is processed in the D500:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

197 (252)

Provisioning

Table 39. Fill factor of the queue (%)

Low priority traffic processed by the D500 Packet forwarding Cell modification Ethernet user priority modification Packet out Bridged Green Red CLP bit EFCI Map mode
Low

Pass mode
Same as packet in Same as packet in

050

Forward

Forward

Assign if red

5080

Drop 50 % randomly Drop 50 % randomly Drop

Drop

Low

80100

Drop

Assign

Low

Same as packet in

100

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 user priority bits in the VLAN tags are set to their default (= 000) values.

198 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

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 are presented separately for each ATM service class. The following figure shows queues and schedulers used for ATM service classes:

Qos/CoS queues
CBR

Queue level shaping/ rate limiting


Dynamic scheduler 1

Interface level rate limiting & strict priority scheduling

VBRrt

Bandwidth reserved by CAC

VBRnrt w/o tag VBRnrt with tag

Dynamic scheduler 2

Logical port

FIFO scheduler

UBR (= BE) -WRR type scheduling -no shaping/rate limiting

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 of bandwidth to be continuously available during the connection lifetime. Examples are real-time video, audio, circuit emulation services, and audio-video distribution such as TV, pay-per-view, and distant learning. CBR services provide connectivity up to a peak cell rate with an upper bound of cell delay variation tolerance. The source may emit cells at or below the negotiated peak cell rate at any time for any duration and the QoS commitments still pertain.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

199 (252)

Provisioning

The policing process (which is based on GCRA) tests the CBR traffic against the peak cell rate (PCR) and the cell delay variation tolerance (CDVT) defined in an ATM traffic descriptor (TD) for the policed connection/subinterface. If the cell conforms with the TD, it is queued to the CBR queue, which is scheduled by dynamic scheduler 1, otherwise it is dropped. The following table summarises how CBR traffic (CBR.1) is processed in the D500:

Table 40.

CBR traffic processed by the D500 Cell forwarding Green


Forward Drop 50 % randomly Drop 50 % randomly Drop

Fill factor of the queue (%)


050 5080

Cell modification CLP bit EFCI

Red
Drop Drop

80100

Drop

Assign

100

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 variable bandwidth with tight bounds on delay. Cell traffic is generated in bursts. Traffic is guaranteed an average rate of bandwidth, although the amount varies depending on the traffic requirements of the connection (peak cell rate, sustained cell rate, and maximum burst size). Examples are variable bit rate CODECs, aggregated voice with silence removal, video conferencing, and loop emulation services with AAL2.

200 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

The policing process tests the VBR-rt traffic against the peak cell rate (PCR) and the 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 the VBR-rt, EF queue, which is scheduled by dynamic scheduler 1. If the cell does not conform to the PCR and CDVT parameters, it is always dropped. For other cases the cell processing depends on the model selected. The details of these models are described below. The D500 supports both CLP-transparent and CLP-significant models for VBR traffic. In the CLP-transparent model, the CLP bit is ignored in the policing process, and the whole CLP=0+1 cell stream is processed. In the CLP-significant model 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 to these two models, tagging (assertion of the CLP bit) may be enabled or disabled for CLP-significant model connections. The following tables summarise how the D500 processes VBR-rt traffic:
CLP-transparent model, tagging disabled (VBR.1)

Table 41. Fill factor of the queue (%)


050 5080

VBR.1 Cell modification Red


Drop Drop

Cell forwarding Green


Forward Drop 50 % randomly Drop 50 % randomly Drop

Yellow
Drop Drop

CLP bit

EFCI

80100

Drop

Drop

Assign

100

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 to PCR and CDTV criteria. Red: The cell (CLP=0+1) violates PCR and CDTV criteria.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

201 (252)

Provisioning

CLP-significant model, tagging disabled (VBR.2)

Table 42. Fill factor of the queue (%)


050 5080

VBR.2 Cell modification Green_Yellow_CLP1


Forward Drop

Cell forwarding Green_CLP0


Forward Drop 50 % randomly Drop 50 % randomly Drop

Yellow_CLP0
Drop Drop

Red
Drop Drop

CLP bit

EFCI

80100

Drop

Drop

Drop

Assign

100

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, but conforms 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. Fill factor of the queue (%)


050

VBR.3 Cell modification Green_Yellow_CLP1


Forward

Cell forwarding Green_CLP0


Forward

Yellow_CLP0
Drop

Red
Drop

CLP bit
Yellow_CLP0: Assign

EFCI

202 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

Table 43. Fill factor of the queue (%)


5080

VBR.3 (cont.) Cell modification Green_Yellow_CLP1


Drop

Cell forwarding Green_CLP0


Drop 50 % randomly Drop 50 % randomly Drop

Yellow_CLP0
Drop

Red
Drop

CLP bit

EFCI

80100

Drop

Drop

Drop

Assign

100

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, but conforms 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 variable bandwidth with less stringent bounds on delay (as in transaction processing). However, VBR-nrt does not provide delay guarantees. VBR-nrt is typically used for management and signalling applications. The policing, dropping and tagging rules for VBR-nrt service category are exactly the same as used for the VBR-rt category. Thus, both CLP-transparent and CLP-significant models are supported. The CLP-significant model has both tagging enabled and tagging disabled options. The queuing function differs from the VBR-rt case. If tagging is disabled, all the cells are forwarded to the VBRnrt w/o tag-AF4 queue, which is serviced by dynamic scheduler 2. If tagging is enabled, cells are forwarded to the VBRnrt with tag queue, which is scheduled by using the FIFO scheduler.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

203 (252)

Provisioning

6.4.4

UBR
Unspecified bit rate (UBR) is intended for applications that do not require a fixed bandwidth or fixed interval of transmission, and are highly tolerant of delay and loss. Examples are file transfer, e-mail, and LANs. There is no explicit commitment from the network provider regarding capacity or throughput in the UBR class. The network transmits cells based on available bandwidth without delay or throughput guarantees. The policing process tests the UBR traffic against the peak cell rate (PCR) and the cell delay variation tolerance (CDVT). The UBR traffic is forwarded to the UBRDF queue, which is scheduled by the FIFO scheduler. The UBR service class supports 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. Fill factor of the queue (%) Cell forwarding Green_CLP0
Forward Drop 50 % randomly Drop 50 % randomly Drop

UBR.1 Cell modification

Green_CLP1
Forward Drop

Red
Drop Drop

CLP bit

EFCI

050 5080

80100

Drop

Drop

Assign

100

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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

UBR with tagging eanbled (UBR.2)

Table 45. Fill factor of the queue (%) Cell forwarding Green_CLP0
Forward Drop 50 % randomly Drop 50 % randomly Drop

UBR.2 Cell modification

Green_CLP1
Forward Drop

Red
Forward Drop

CLP bit
Red: Assign

EFCI

050 5080

80100

Drop

Drop

Assign

100

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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

205 (252)

Provisioning

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 only ATM 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-based interfaces (for example SDH or xDSL ports). Ethernet subinterfaces always use packet traffic descriptors. Depending on the subinterface type, Ethernet CoS, DiffServ CoS, or no-CoS alternatives can be selected as shown in QoS/CoS hierachy used in the D500. For ATM subinterfaces operating in a packet-based mode (packets transferred over ATM), packet traffic descriptors are typically preferred. However, if so wished, ATM traffic descriptors are also available in packet-based mode (in case there is a need to use Ethernet trunks of Release 2).

206 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

QoS / CoS provisioning

ATM switched services

Packet-based services

ATMQoS

ATMQoS

Non-DiffServ No CoS

DiffServ CoS

Ethernet CoS

Pass mode

Map mode

Pass mode

Map mode

CBR

CBR

RT-VBR

RT-VBR

EF->EF

DSCP in -> EF

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.

NRT-VBR

NRT-VBR

AFx->AFx

DSCP in -> AF4 DSCP in -> DF

UBR

UBR

DF

DF->DF

Native ATM connections

Packet-based services, ATM interfaces

Bridged without CoS or IP without DiffServ

IP with DiffServ

Ethernet with user priorities

Figure 52.

QoS/CoS hierarchy used in the D500

For native ATM switched connections a single traffic descriptor per direction is adequate to specify the policing, queueing and scheduling/shaping behaviour, while ATM connections always go end-to-end (for example all the way from client side to trunk side).

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

207 (252)

Provisioning

For packet-based services, the subinterfaces (PVCs, VLANs or PVC-VLAN pairs) are always terminated in the D500. That is why both client and trunk sides must have their own traffic descriptors and separately for both directions. The input traffic descriptor (inPTD) of a subinterface is used to specify the policing behaviour and the queue selection. The output traffic descriptor (outPTD) is needed to specify parameters for scheduling/shaping (CAC uses these parameters to 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, PTD policies may need to be defined for packet based services. These PTD policies are used 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 the information rate and the burstiness of traffic for packet-based services. The traffic parameters defined in the input PTD are used in policing process to determine whether 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 subinterfaces output traffic. Based on these traffic parameters, three basic packet traffic descriptor types can be defined for different sevice types. The same three basic service types can be applied to both IP DiffServ traffic and Ethernet VLAN priority (802.1p) traffic. In the 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 basic packet traffic descriptor types are described in the following table:

Table 46. Service type DiffServ service class category

PTD types Ethernet 802.1p service class category


High priority

Traffic parameters

Description

Delay sensitive, assured bandwidth service Non-delay sensitive,

EF

PIR in kbit/s PBS in bytes

Traffic conformance is based on the PIR and PBS parameters. Non-conforming packets are discarded.

AFx

Medium priority

PIR in kbit/s PBS in bytes

Traffic conformance is based on the PIR, PBS, CIR, and

208 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

Table 46. Service type DiffServ service class category

PTD types (cont.) Ethernet 802.1p service class category Traffic parameters Description

assured bandwidth service

CIR in kbit/s CBS in bytes

CBS parameters. Packets violating PIR and PBS are discarded. Packets violating CIR and CBS may be marked and are discarded first in case there is congestion. Traffic conformance is based on the PIR and PBS parameters. Non-conforming packets may be marked and are discarded first in case there is congestion.

Best effort service

DF

Low priority

PIR in kbit/s PBS in bytes

Additionally, the user may need to define in the PTD policies whether a subinterface is required to function in a pass or map mode and which PTDs are used in the selected mode. The following example shows a client side configuration for a case where a client side 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 CoS applied for the traffic in the D500: 1. Packet traffic descriptors are first defined separately for both directions and for 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>

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

209 (252)

Provisioning

(In case of VLAN priority PTDs: EF=HIGH, AF4=MEDIUM, and DF=LOW) In Web-based Craft Terminal, the New PTD Dialog dialogue box is found by 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 PASS ADSL1_RXPTD_HIGH ADSL1_RXPTD_MEDIUM ADSL1_RXPTD_LOW TX ADSL1_TXPTD_HIGH ADSL1_TXPTD_MEDIUM ADSL1_TXPTD_LOW In Web-based Craft Terminal, the New PTD Policy dialogue box is found by selecting Node Views and clicking the node icon => Descriptors tab => PTD Policies tab => Configure menu => New PTD Policy command.

210 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

Figure 54.

New PTD Policy

3.

Finally the new subinterface can be created. The subinterface refers to the created 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 Profile dialogue 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.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

211 (252)

Provisioning

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-cell arrival time for resource allocation. Based on these traffic parameters, six basic, pre-defined traffic descriptor types corresponding to seven traffic contracts are available for different categories of service.

Table 47. QoS category Traffic descriptor type


ClpTransparent NoScr (CBR.1)

Traffic descriptor types (templates) Traffic parameters Description

CBR

Parameter 1

PCR in cells/second for CLP*) = 0 + 1 traffic CDVT in tenths of microseconds

Parameter 2

Traffic conformance is based on the CLP-transparent model with no SCR. In a CLPtransparent model, the network disregards the CLP

212 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

Table 47. QoS category Traffic descriptor type

Traffic descriptor types (templates) (cont.) Traffic parameters Description

Parameters 3, 4 and 5 VBR ClpTransparent Scr (VBR.1) Parameter 1

Not used

PCR in cells/second for CLP=0+1.

bit

Parameter 2 CDVT in tenths of microseconds Parameters 3, 4 and 5 VBR Not used

ClpTransparent Scr (VBR.1)

Parameter 1 PCR in cells/second for CLP=0+1.

Traffic conformance is based on the CLPtransparent model with SCR. In a CLPtransparent model, the network disregards the CLP bit. VBR

Parameter 2 Parameter 3 Parameter 4 CDVT in tenths of microseconds Not used

SCR CLP=0+1. MBS in cells

Parameter 5

ClpNoTagging ScrCdvt (VBR.2)

Parameter 1

PCR in cells/second for CLP=0+1. SCR in cells/second for CLP=0 traffic MBS in cells CDVT in tenths of microseconds Not used

Parameter 2

Traffic conformance is based on CLP with SCR without tagging

Parameter 3 Parameter 4

Parameter 5

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

213 (252)

Provisioning

Table 47. QoS category Traffic descriptor type


ClpTagging ScrCdvt (VBR.3)

Traffic descriptor types (templates) (cont.) Traffic parameters Description

VBR

Parameter 1

PCR in cells/second for CLP=0+1 SCR in cells/second for CLP=0 traffic, excess tagged**) as CLP=1 MBS in cells CDVT in tenth of microseconds Not used. PCR in cells/second for CLP=0+1 CDVT in tenths of microseconds Not used

Parameter 2

Traffic conformance is based on CLP with SCR and tagging

Parameter 3 Parameter 4

Parameter 5 UBR NoClpNoScrCdvt (UBR.1) Parameter 1

Traffic conformance is based on no CLP and no SCR

Parameter 2

Parameters 3, 4 and 5 UBR NoClpTaggingNoScr (UBR.2) Parameter 1

PCR in cells/second for CLP=0+1 CDVT in tenths of microseconds Not used

Parameter 2

Traffic conformance is based on CLP with tagging and no SCR

Parameters 3,4 and 5

*) 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 an aggregate cell stream. **) Tagging is a process of setting the CLP bit of cells entering an ATM network to 1 because they do not conform to the subscribed traffic descriptor. These marked cells can be dropped based on the network congestion.

214 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

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 a different set of characteristics other than those pre-defined.
Creating traffic profiles/traffic descriptors

Traffic profiles/traffic descriptors can be created by assigning specific parameter values to an ATM connection in Craft Terminal and the command line interface (CLI). Each profile is assigned an index number by the system for identification purposes. The indices of 1 to 32 are reserved by the system; indices from 1 to 12 are pre-defined (see the following table).

Note
The New Traffic Descriptor dialog box in Craft Terminal enables users to create traffic profiles/traffic descriptors. For details, see Web-based Craft Terminal.

The twelve default traffic profiles/traffic descriptors are available in the following table:

Table 48. Index Service category TrD type

Pre-defined traffic profiles/traffic descriptors Performance parameters Congestion control features MCR Tagging Frame discard

PCR

CDVT
X X X X X X X

SCR

MBS

1 2 3 4 5 6 7

CBR VBR-rt VBR-rt VBR-nrt VBR-nrt VBR-nrt VBR-nrt

CBR.1 VBR.1 VBR.1 VBR.2 VBR.3 VBR.3 VBR.1

X X X X X X X

X X X X X X X X X X X X X X X X X X

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

215 (252)

Provisioning

Table 48. Index Service category TrD type

Pre-defined traffic profiles/traffic descriptors (cont.) Performance parameters Congestion control features MCR Tagging Frame discard

PCR

CDVT
X X X X

SCR

MBS

8 9 10 11

UBR UBR UBR VBR.nrt

UBR.1 UBR.1 UBR.2 VBR.1

X X X X

The user can also choose an index number for the traffic descriptor (refer to the following figure). It is easier to create connections to the D500 nodes in a same network when the user can make sure that all the nodes have the same traffic descriptor numbering. In creating or editing the traffic descriptor it is possible to name it according to the use (for instance, home user gold/silver/bronze, SOHO, corporate or VDSL user). 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

QoS provisioning

A traffic profile/traffic descriptor must exist before a connection can be created. A traffic profile/traffic descriptor cannot be deleted unless all the associated connections are deleted. Traffic descriptors with index 1 to 32, such as the twelve default traffic profiles/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/traffic descriptor to the other by first deleting the connection and then re-creating it and associating it with the desired traffic profile/traffic descriptor. The two directions of a connection can be mapped either to different descriptors or a single traffic descriptor. If different traffic descriptors are used, they must have the same traffic type (for example CBR) but different speeds 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 Release 3 trunk/control unit) including queue passed & discarded PDUs, and current buffer occupancy You can utilise this in trying to find suitable buffer sizes; in other words, if discards occur, increase the buffer.

The following is an example of a multicast client configuration including the new CLI 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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

217 (252)

Provisioning

conf ptd policy new client_policy pass ef_rx af_rx df_rx TX ef_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.1 255.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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

7
7.1

Provisioning concepts and parameters


Provisioning parameters
This section provides provisioning parameters for the D500 line cards at the port level. The provisioning tables list parameter data by tabs within individual dialog boxes as they appear in Craft Terminal.

7.1.1

DSL provisioning parameters

Table 49. Provisionable parameter


Administration State Managed Interface

Status tab VDSL Default values


Locked Unmanaged

ADSL Default values


Locked Unmanaged

SHDSL Default values


Locked Unmanaged

Table 50. Provisionable parameter


Test Mode Test Duration(s)

Test tab VDSL Default values


None 28800

ADSL Default values


None 28800

SHDSL Default values


None 28800

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

219 (252)

Provisioning

Table 51. Provisionable parameter


Data Rate Type Interleave Rate, Max (ATUC, VTU-O)

Rates tab VDSL Default values


Interleave Rate 997_2B: 10048 kbit/s 997_3B: 25024 kbit/s 998_2B: 22016 kbit/s 998_3B: 45056 kbit/s (Range depends on the band plan)

ADSL Default values


Interleave Rate 8128 kbit/s The maximum rate for ADSL48aft and ADSL48art line cards is 10816 kbit/s. The maximum rate for ADSL2 +af and ADSL2+bf cards is 32,736 Mbit/s. Ranges: 32 to 8128 kbit/s, 32 10816, and 32 kbit/s 32,736 Mbit/s

SHDSL Default values


N/A 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 1024 kbit/s ADSL2+: 1088 kbit/s Ranges: 321024 kbit/s and 321088 kbit/s

64 kbit/s (Range depends on the band plan)

N/A

Interleave Rate, Max (ATUR, VTU-R)

997_2B: 10048 kbit/s 997_3B: 25024 kbit/s 998_2B: 3008 kbit/s 998_3B: 10048 kbit/s (Range depends on the band plan)

N/A

Interleave Rate, Min (ATUR, VTU-R)

32 kbit/s Ranges: 321024 kbit/s and 321088 kbit/s 32 ms (Setting Options: 1, 2, 4, 8, 16, 32, 64) 16 ms (Setting Options: 1, 2, 4, 8, 16, 32, 64) 0 kbit/s The maximum rate for ADSL48aft and ADSL48art

64 kbit/s (Range depends on the band plan) 16 ms (Setting Options: 0, 1, 2, 4, 8, 16, 32, 64) N/A

N/A

Interleave Delay (ATUC, VTU-O)

N/A

Interleave Delay (ATUR)

N/A

Fast Rate, Max (ATUC, VTU-O)

997_2B: 10048 kbit/s 997_3B: 25024 kbit/s

N/A

220 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Table 51. Provisionable parameter ADSL

Rates tab (cont.) VDSL Default values


998_2B: 22016 kbit/s 998_3B: 45056 kbit/s (Range depends on the band plan)

SHDSL Default values

Default values
line cards is 10816 kbit/s. The maximum rate for ADSL2 +af and ADSL2+bf cards is 32,736 Mbit/s. Ranges: 32 to 8128 kbit/s, 32 10816, and 32 kbit/s 32,736 Mbit/s

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 1024 kbit/s ADSL2+: 1088 kbit/s Ranges: 321024 kbit/s and 321088 kbit/s

64 kbit/s (Range depends on the band plan)

N/A

Fast Rate, Max (ATUR, VTU-R)

997_2B: 10048 kbit/s 997_3B: 25024 kbit/s 998_2B: 3008 kbit/s 998_3B: 10048 kbit/s (Range depends on the band plan)

N/A

Fast Rate, Min (ATUR, VTU-R)

32 kbit/s Ranges: 321024 kbit/s and 321088 kbit/s N/A

64 kbit/s (Range depends on the band plan) N/A

N/A

Data Rates, Max (STUC) Data Rates, Min (STUC) RADSL Mode (ATUC, VTU-O, or STUC) Error Retrain Near (ATUC, VTU-O, STUC)

2304 (Range 144 to 2304)

N/A

N/A

1152 (Range 144 to 2304)

Startup

Startup

Startup

10 (Range 060) (Unit = Errors/ Sec) 10 (Range 060) (Unit = Errors/ Sec)

10 (Range 060) (Unit = Errors/Sec) 10 (Range 060) (Unit = Errors/Sec)

10 (Range 060) (Unit = Errors/Sec) 10 (Range 060) (Unit = Errors/Sec)

Error Retrain Far (STUC, VTUO, STUC)

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

221 (252)

Provisioning

Table 51. Provisionable parameter


Error Alarm, Near (ATUC, VTU-O, STUC)

Rates tab (cont.) VDSL Default values


0 (Range 065535) (Unit = Errors/Sec) 0 (Range 065535) (Unit = Errors/Sec) 0 kbit/s (Range depends on the band plan)

ADSL Default values


0 (Range 065535) (Unit = Errors/Sec) 0 (Range 065535) (Unit = Errors/Sec) 0 kbit/s The maximum rate for ADSL48aft and ADSL48art line cards is 10816 kbit/s. The maximum rate for ADSL2 +af and ADSL2+bf cards is 32,736 Mbit/s. Ranges: 32 to 8128 kbit/s, 32 10816, and 32 kbit/s 32,736 Mbit/s

SHDSL Default values


0 (Range 065535) (Unit = Errors/Sec) 0 (Range 065535) (Unit = Errors/Sec) 0 kbit/s (Range 144 to 2304)

Error Alarm, Far (ATUC, VTU-O, STUC)

Rate Degraded (ATUC, VTU-O,STUC)

Rate Degraded (ATUR, VTU-R)

0 kbit/s The maximum rate for ADSL2 + is 1088 kbit/s Ranges: 321024 kbit/s and 321088 kbit/s

0 kbit/s (Range depends on the band plan)

N/A

RFI Bands Start Tone

N/A N/A

None 138 kHz (Setting Options: 25, 138, 1104)

N/A N/A

Pair Bonding

N/A

N/A

Unbonded

Table 52. Provisionable parameter


LOF Seconds 15 min.

DSL Thresholds tab VDSL Default Values


0

ADSL Default Values


0

SHDSL Default Values


0

222 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Table 52. Provisionable parameter


(ATUC) LOS Seconds 15 min. (ATUC) LCD Seconds 15 min. (ATUC, VTU-O, STUC) LOF Retrains 15 min. (ATUC, VTU-O, STUC) Error Rate Retrains 15 min. (ATUC, VTU-O, STUC) FE Error Rate Retrains 15 min. (ATUC, VTU-O, STUC) LPR Seconds 15 min. (ATUC, VTU-O, STUC) LOF Seconds Daily (ATUC, VTU-O, STUC) LOS Seconds Daily (ATUC, VTU-O, STUC) LCD Seconds Daily (ATUC, VTU-O, STUC) LOF Retrains Daily (ATUC, VTU-O, STUC) Error Rate Retrains Daily (ATUC, VTU-O, STUC) FE Error Rate Retrains Daily (ATUC, VTU-O, STUC) 0 0 0

DSL Thresholds tab (cont.) VDSL Default Values


(Range 1900) 0 (Range 1900) 0 (Range 1900) 0

ADSL Default Values


(Range 1900) 0 (Range 1900) 0 (Range 1900) 0

SHDSL Default Values


(Range 1900) 0 (Range 1900) 0 (Range 1900) 0

N/A

N/A

(Range 1900) 0 (Range 186400) 0 (Range 186400) 0 (Range 186400) 0 (Range 065535) 0 (Range 065535) 0 (Range 065535) 0 (Range 186400) 0 (Range 186400) 0 (Range 186400) 0 (Range 065535) 0 (Range 065535) 0 (Range 065535) 0 (Range 186400) 0 (Range 186400) 0 (Range 186400) 0 (Range 065535) 0 (Range 065535) 0 (Range 065535)

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

223 (252)

Provisioning

Table 52. Provisionable parameter


LPR Seconds Daily (ATUC, VTU-O, STUC) Coding Violations Near, 15 min. Errored Seconds Near, 15 min. Coding Violations Near, Daily Errored Seconds, Near, Daily Coding Violations Far, 15 min. Errored Seconds Far, 15 min. Coding Violations Far, Daily Errored Seconds Far, Daily

DSL Thresholds tab (cont.) VDSL Default Values


N/A

ADSL Default Values


0 (Range 186400) 0

SHDSL Default Values


N/A

0 (Range 1900) 0

0 (Range 1900) 0

0 (Range 1900) 0

0 (Range 186400) 0

0 (Range 186400) 0

0 (Range 186400) 0

0 (Range 1900) 0

0 (Range 1900) 0

0 (Range 1900) 0

0 (Range 186400)

0 (Range 186400)

0 (Range 186400)

Table 53. Provisionable parameter


Advanced Configuration Mode (ATUC) Automatic Coding Gain Set Gain Enabled 0 dB

DMT tab VDSL Default Values


Auto

ADSL Default Values


Auto

SHDSL Default Values


Refer to the SHDSL tab

N/A N/A

N/A N/A

224 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Table 53. Provisionable parameter


Trellis Coding Modulation RS Correction ATUC Time

DMT tab (cont.) VDSL Default Values


N/A

ADSL Default Values


Enabled

SHDSL Default Values


N/A

Enabled 2 ms Setting Options: 125, 250, 500 s, and 1, 2, 4 ms

N/A N/A

N/A N/A

ATUR Time

1 ms Setting Options: 125, 250, 500 s, and 1, 2, 4 ms

N/A

N/A

BitSwap Operation Mode (ATUC, VTU-O) Target Noise Margin (ATUC, VTU-O) Target Noise Margin (ATUR) Minimum Noise Margin

Enabled Auto

N/A Auto

N/A Refer to the SHDSL tab N/A

6 dB (Range 016 dB) 6 dB (Range 016 dB) N/A

6 dB (Range 032 dB) N/A

N/A

1 (Range 032 dB)

N/A

Maximum Noise Margin

N/A

28 (Range 032 dB)

N/A

Transmit Power Reduction (ATUC)

0 dB

N/A

N/A

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

225 (252)

Provisioning

Table 54.

SHDSL tab SHDSL24 Default Values


Auto

Provisionable parameter
Advanced Configuration Mode ACP1 (STUC) ACP2 (STUC) Power BackOff STUC Operation Mode

0 0 Enabled D500-21: Annex A D500-17: Annex B

7.1.2

QoS queue provisioning parameters

Table 55. Provisionable parameter


Priority

Queue Manager tab VDSL Default Values


Low Options:
. . .

ADSL Default Values


Low Options:
. . .

SHDSL Default Values


Low Options:
. . .

Low Medium High

Low Medium High

Low Medium High

EPD/PPD EFCI PPD EPD Onset EPD Abate EFCI Starvation Cycles

Enabled Enabled 95% 75% 65% 65% 0

Enabled Enabled 95% 75% 65% 65% 0

Enabled Enabled 95% 75% 65% 65% 0

226 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Table 55. Provisionable parameter


Queue Size

Queue Manager tab (cont.) VDSL Default Values


Low = 693 cells Medium = 298 cells High = 32 cells

ADSL Default Values


Low = 693 cells Medium = 298 cells High = 32 cells

SHDSL Default Values


Low = 693 cells Medium = 298 cells High = 32 cells

Table 56. Provisionable parameter


Priority

Queue PM tab VDSL Default Values


Low Options:
. . .

ADSL Default Values


Low Options:
. . .

SHDSL Default Values


Low Options:
. . .

Low Medium High

Low Medium High

Low Medium High

Congestion Measurement Weight Factor

Disabled

Disabled

Disabled

0.300 (Range .001 to 1.000)

0.300 (Range .001 to 1.000) 90% 70% 40% 30 seconds 30 seconds

0.300 (Range .001 to 1.000)

Severe Level (%) Abate Level (%) Intermed Level (%) Active Report (secs) Clear Report (secs)

90% 70% 40% 30 seconds 30 seconds

90% 70% 40% 30 seconds 30 seconds

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

227 (252)

Provisioning

7.1.3

OC-3/STM-1 provisioning parameters

Table 57. Parameter Values

OC-3/STM-1 provisioning parameters Default

Node Configuration tab page Timing Option


.

Line (Port 1/Unit 15 (with the Ethernet trunk) Line (Port 1/Unit 11 (OC-3/STM-1 trunk) 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 Cell Delineation Path RDI: Payload Label Mismatch Path RDI: Trace Identifier Mismatch S1 Sync Status  Transmit
. .

Enabled Disabled Enabled Disabled Enabled Disabled

Disabled

. .

Disabled

. .

Disabled

1 to 15 bits

15 (Trunk) *

*) With the OC-3/STM-1 and Ethernet trunk unit the default transmitted timing marker value for the STM-1/OC-3 tributary interfaces is 11 in the 17-slot subrack and 12 in the 21-slot subrack. However, if the tributary unit is installed in section 1 (slots 1-5) in the subrack that has an Ethernet trunk, the transmitted timing marker value for port 1 of the tributary unit is 15.

228 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Table 58. Parameter


Line or MS Line Coding Violations

OC-3/STM-1 provisioning parameters - OC3 Thresholds tab 15 Minute Interval Values

Daily Interval Values

Range 01048575 Default = 0 (inactive)

Range 016383 Default = 0 (inactive) Range 0900 Default = 0 (inactive) Range 0900 Default = 0 (inactive) Range 0900 Default = 0 (inactive)

Line Errored Seconds

Range 065535 Default = 0 (inactive)

Line Severely Errored Seconds Line Unavailable Seconds

Range 065535 Default = 0 (inactive) Range 065535 Default = 0 (inactive)

Path or HP Path Coding Violations Range 01048575 Default = 250 Path Errored Seconds Range 065535 Default = 200 Path Severely Errored Seconds Path Unavailable Seconds Section or RS Severely Errored Framing Seconds BERT BERT Signal Degrade Condition BERT Signal Fail Condition Range 065535 Default = 0 (inactive) Values 69 Range 0900 Default = 0 (inactive) Default 6 Range 065535 Default = 7 Range 065535 Default = 10 Range 016383 Default = 25 Range 0900 Default = 20 Range 0900 Default = 3 Range 0900 Default = 10

36

3 (Applicable to the trunk unit only)

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

229 (252)

Provisioning

7.1.4

DS3 provisioning parameters

Table 59. Group


Parameters

DS3 tab page Default


Both enabled

Parameters
. .

Cell Scrambling HEC Coset Cbit Parity PLCP Cbit Parity M23 PLCP M23 Low Default (Longer cables) Node clock Loop timing

Line Type

. . . .

PLCP Cbit Parity

Receive Equalization

. .

Default

Clock Source

. .

Node colck

Table 60. Line/Path/ PLCP

DS3 Thresholds (Intervals) Acronym Daily interval 15-minute Interval

CV-L

Range: 610 Default: 9

Range: 610 Default: 9 Range: 0900 Default: 25

ES-L

Range: 0 86400 Default: 250

Line (NE)

SES-L

Range: 0 86400 Default: 0

0900 Default: 0

UAS-L

Range: 0 86400 Default: 0

0900 Default: 0

CV-P Path (NE/FE) ES-P

Range: 610 Default: 9 Range: 0

Range: 610 Default: 9 Range: 0900

230 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Table 60. Line/Path/ PLCP

DS3 Thresholds (Intervals) (cont.) Acronym Daily interval 15-minute Interval

86400 Default: 250 SES-P Range: 0 86400 Default: 40 UAS-P Range: 0 86400 Default: 10 SAS/SEFS-P Range: 0 86400 Default: 8 CV-PLCP Range: 610 Default: 9 ES-PLCP Range: 0 86400 Default: 250 SES-PLCP PLCP (NE/FE) UAS-PLCP Range: 0 86400 Default: 40 Range: 0 86400 Default: 10 SAS/SEFSPLCP Range: 0 86400 Default: 8

Default: 25

Range: 0900 Default: 4

Range: 0900 Default: 10

Range: 0900 Default: 2

Range: 610 Default: 9 0900 Default: 25

Range: 0900 Default: 4

Range: 0900 Default: 10

Range: 0900 Default: 2

Table 61. Parameter

BERT Default
6

Range
69

Signal Degrade Condition

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

231 (252)

Provisioning

Table 61. Parameter

BERT (cont.) Default


3

Range
35

Signal Fail Condition

7.1.5

E1 provisioning parameters

Table 62. Parameter

E1 tab page Values


Node clock (default) Loop timing

Interface Timing

Cell Scrambling

Enbled by default

Table 63. Line/Path

E1 Thresholds tab page (Frame) Acronym


CV-L (NE)

Daily interval
Range: 0 65535 Default: 0

15-minute Interval
Range: 016383 Default: 0

ES-L (NE)

Range: 0 65535 Default: 0

Range: 0900 Default: 0

Line SES-L (NE) Range: 0 65535 Default: 0 UAS-L (NE) Range: 0 65535 Default: 0 CV-P (NE/FE) Path ES-P (NE/FE) Range: 6 65535 Default: 0 Range: 0 Range: 0900 Range: 016383 Default: 0 0900 Default: 0 0900 Default: 0

232 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Table 63. Line/Path

E1 Thresholds tab page (Frame) (cont.) Acronym Daily interval


65535 Default: 0 SES-P (NE) Range: 0 65535 Default: 0 UAS-P (NE) Range: 0 65535 Default: 0 SAS-P (NE) Range: 0 65535 Default: 0 Range: 0900 Default: 0 Range: 0900 Default: 0 Range: 0900 Default: 0

15-minute Interval
Default: 0

Table 64. Parameter

E1 Thresholds (Failure) Daily interval


Range:0900 Default: 0

15-minute interval
Range:065535 Default: 0 Range:065535 Default: 0 Range:065535 Default: 0

LOF Seconds

LOS Seconds

Range:0900 Default: 0

LCD Seconds

Range:0900 Default: 0

Table 65.

Configuration tab page (In the Properties View) Values


Range: 12 Default: 2

IMA parameters
Alpha Value

Beta Value

Range: 15 Default: 2

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

233 (252)

Provisioning

Table 65.

Configuration tab page (In the Properties View) (cont.) Values


Range: 15 Default: 2

IMA parameters
Gamma Value

Table 66. Parameter

New IMA Group dialog box Values


Default: 1 CTC (default) ITC

Minimum Links Tx Clock Mode

Tx IMA ID Frame Length Diff Delay Max (ms) IMA Version

Default: 0 m256, m128 (default), m64, m32 Default: 25 Ver 1.0 Ver 1.1 (default)

Table 67.

BwUtil tab page (IMA Group Configuration dialog box) Rx


Default: disabled Default: 70 Default: 90 Default: 300 Default: 300

Parameter
Alarm Abatement Severe RptAct RptClr

Tx
Default: disabled Default: 70 Default: 90 Default: 300 Default: 300

234 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

7.1.6

ATM/Ethernet connection provisioning parameters

Table 68. Parameter


Link A Unit (slot) Link A Port Link A VPI Link A VCI Link Z Unit (slot) Link Z Port 148

New connection dialog box Default


(Depends on the unit selection) (Depends on the port selection) 0 100 (Depends on the unit selection) (Depends on the unit selection)

Values

(Per service order) (Per service order) Trunk/Tributary 1 (trunk) 14 (tributary)

Link Z VPI Link Z VCI Traffic Descriptor Z->A

(Per service order) (Per service order)

0 32 (Depends on the setting given in the connection preference) (Depends on the setting given in the connection preference)

Traffic Descriptor A->Z

Administration State

. .

Unlocked Locked

Unlocked

Encapsulation Type

MuxRouted MuxBridged LLCRouted LLCBridged

LLCBridged

VLAN ID (optional for bridged PVCs) VP Connection

04,095 0 (VLAN disabled for bridged PVC)


. .

0 (applicable to bridged PVCs only)

Select Deselect

Deselected

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

235 (252)

Provisioning

7.1.7

VLAN provisioning parameters

Table 69. Parameter


Local IP Address Gateway Address Protocol Filter All PPPoE

VLANs dialog box Default


0.0.0.0 0.0.0.0 All

Values

IP without NETBIOS IP with NETBIOS

7.1.8

Gigabit Ethernet trunk provisioning parameters

Table 70. Parameter

Ethernet tab page Values


13600 1065,535 (secs X 10)

Default
1800 30

History Interval (secs) Maximum Ageing Time (secs) Alarm Ageing Threshold (secs)

065,535 (secs X 10) 0 = no threshold

10

Table 71. Parameter

Thresholds tab page Range Default


0 0 0 0 0

Octets Received Packets Received Uni-Cast Pkts Received Non-Uni Pkts Received Discards Received

236 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Table 71. Parameter

Thresholds tab page (cont.) Range Default


0 0100 0 0 0 0

Erros Received Max BW Util Received Undersize Pkts Received Oversize Pkts Received Undersize Pkts Received with FCS Error Oversize Pkts Received with FCS Error Collisions Received Octets Transmitted Packets Transmitted Uni-Cast Pkts Transmitted Non-Uni Pkts Transmitted Discards Transmitted Errors Transmitted Max BW Util Transmitted 0100

0 0 0 0 0 0

7.2
7.2.1

Policer limitations and granularity rates


Limitations for an ATM policer
There are few limitations on the rates that can be configured and depending on those 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 minimum rate is 96 and the maximum rate is 6234374 cells per second. For CDVT the minimum rate is 2 and 105117 tenths of microseconds.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

237 (252)

Provisioning

The burst size limitations depend on the PCR and SCR rates. For rate less than 1 mega cells per second it should be OK with the current policer where SCR rates should be less than 85 % of PCR at least. Since the burst size is too dependent on PCR and SCR, the user should calculate the burst for configured values based on GCRA requirements as burst size = MBS  1 * (1/scr 1/pcr)/resolution where resolution for the current parser is 1.60401E-07.
Class settings
.

CBR has settings PCR XXX (in cells/s) Note 1) 2) CDVT XXX (in 0.1s) 2). Policing uses a leaky bucket drained at PCR and with bucket size PCR*CDVT*10-7. All incoming packets causing bucket overflow are dropped. 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 at PCR and has bucket size PCR*CDVT*10-7. The second bucket is drained at 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 at PCR and has bucket size PCR*CDVT*10-7. The second bucket is drained at SCR and has size MBS. Incoming packets causing bucket overflow (first or 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Policing uses a leaky bucket drained at PCR and with bucket size PCR*CDVT*10-7. Incoming packets causing bucket overflow are dropped or 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 that can be specified. Maximum rates thet the policer can handle is 48706 kbit/s, see Packet policer granularity rates. If the user configures above this value the policing does not happen for the flow all traffic is allowed to go through. The user is responsibile for 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. All incoming 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 at PIR and has bucket size PBS. Incoming packets causing the bucket to overflow are dropped (red packets). The second bucket is drained at CIR and has size CBS. Incoming packets causing bucket overflow are marked and passed through. Marking means setting CLP = 1 (ATM output) or yellow (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

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

239 (252)

Provisioning

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, which can be used in configuring higher rates for a flow. If the user-specified value is in between two granular values, policing is done at a higher granular value. Thus the user has to choose the higher value when policing is configured. 48706,24353,16235,12176,9741,8117,6958,6088,5411,4870,4427,4058,3746,3479,3247,3044,2865,2705,2563,2435,2319,2213,2117,2029,1948,1873,1803,1739,1679,1623,1571,1522,1475,1432,1391,1352,1316,1281,1248,1217,1187,1159,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,632,624,616,608,601,593,586,579,573,566,559,553,547,541,535,529,523,518,512,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,324,322,320,318,316,314,312,310,308,306,304,302,300,298,296,295,293,291,289,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 can be used in configuring higher rates for a flow. If the user-specified value is in between two granular values, policing is done at higher granular value. Thus the user 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,328124,311718,296874,283380,271059,259765,249374,239783,230902,222656,214978,207812,201108,194824,188920,183363,178124,173177,168496,164062,159-

240 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

855,155859,152057,148437,144985,141690,138541,135529,132646,129882,127232,124687,122242,119891,117629,115451,113352,111328,109374,107489,105667,103906,102202,100554,98958,97412,95913,94460,93050,91681,90353,89062,87808,86588,85402,84248,83124,82031,80965,79927,78916,77929,76967,76028,75112,74218,73345,72492,71659,70845,70049,69270,68509,67764,67036,66323,65624,64941,64271,63616,62973,62343,61726,61121,60527,59945,59374,58814,58265,57725,57196,56676,56165,55664,55171,54687,54211,53744,53285,52833,52389,51953,51523,51101,50685,50277,49874,49479,49089,48706,48328,47956,47590,47230,46874,46525,46180,45840,45506,45176,44851,44531,44215,43904,43597,43294,42995,42701,42410,42124,41841,41562,41287,41015,40747,40482,40221,39963,39709,39458,39209,38964,38722,38483,38247,38014,37784,37556,37331,37109,36889,36672,36458,36246,36036,35829,35624,35422,35222,35024,34828,34635,34444,34254,34067,33882,33699,33518,33338,33161,32986,32812,32640,32470,32302,32135,31971,31808,31646,31486,31328,31171,31016,30863,30711,30560,30411,30263,30117,29972,29829,29687,29546,29407,29269,29132,28997,28862,28729,28598,28467,28338,28209,28082,27956,27832,27708,27585,27464,27343,27224,27105,26988,26872,26756,26642,26529,26416,26305,26194,26085,25976,25868,25761,25655,25550,25446,25342,25240,25138,25037,24937,24838,24739,24641,24544,24448,24353,24258,24164,24070,23978,23886,23795,23704,23615,23525,23437,23349,23262,23176,23090,23005,22920,22836,22753,22670,22588,22506,22425,22345,22265,22186,22107,22029,21952,21874,21798,21722,21647,21572,21497,21423,21350,21277,21205,21133,21062,20991,20920,20850,20781,20712,20643,20575,20507,20440,20373,20307,20241,20175,20110,20046,19981,19918,19854,19791,19729,19666,19604,19543,19482,19421,19361,19301,19241,19182,19123,19065,19007,18949,18892,18834,18778,18721,18665,18610,18554,18499,18444,18390,18336,18282,18229,18176,18123,18070,18018,17966,17914,17863,17812,17761,17711,17661,17611,17561,17512,17463,17414,17365,17317,17269,17222,17174,17127,17080,17033,16987,16941,16895,16849,16804,16759,16714,16669,16624,16580,16536,16493,16449,16406,16363,16320,16277,16235,16193,16151,16109,16067,16026,15985,15944,15904,15863,15823,15783,15743,15703,15664,15624,15585,15547,15508,15469,15431,15393,15355,15317,15280,15242,15205,15168,15131,15095,15058,15022,14986,14950,14914,14879,14843,14808,14773,14738,14703,14669,14634,14600,14566,14532,14498,14464,14431,14398,14364,14331,14299,14266,14233,14201,14169,14136,14104,14073,14041,14009,13978,13947,13916,13885,13854,13823,13792,13762,13732,13701,13671,13641,13612,13582,13552,13523,13494,13465,13436,13407,13378,13349,13321,13292,13264,13236,13208,13180,13152,13124,13097,13069,13042,13015,12988,12961,12934,12907,12880,12854,12827,12801,12775,12749,12723,12697,12671,12645,12620,12594,12569,12544,12518,12493,12468,12443,12419,12394,12369,12345,12320,12296,12272,12248,12224,12200,12176,12152,12129,12105,12082,12058,12035,12012,11989,11966,11943,11920,11897,11874,11852,11829,11807,11785,11762,11740,11718,11696,11674,11653,11631,11609,11588,11566,11545,11523,11502,11481,11460,11439,11418,11397,11376,11355,11335,11314,11294,11273,11253,11233,11212,11192,11172,11152,11132,11112,11093,11073,11053,11034,11014,10995,10976,10956,10937,10918,10899,10880,10861,10842,10823,10804,10786,10767,107-

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

241 (252)

Provisioning

48,10730,10711,10693,10675,10657,10638,10620,10602,10584,10566,10548,10531,10513,10495,10477,10460,10442,10425,10407,10390,10373,10356,10338,10321,10304,10287,10270,10253,10237,10220,10203,10186,10170,10153,10137,10120,10104,10087,10071,10055,10039,10023,10007,9990,9974,9959,9943,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,9305,9291,9277,9263,9249,9236,9222,9208,9195,9181,9168,9154,9141,9127,9114,9101,9088,9074,9061,9048,9035,9022,9009,8996,8983,8970,8957,8944,8931,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,8413,8402,8390,8379,8368,8357,8345,8334,8323,8312,8301,8290,8279,8268,8257,8246,8235,8224,8213,8203,8192,8181,8170,8160,8149,8138,8128,8117,8107,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,7677,7668,7658,7649,7640,7630,7621,7612,7602,7593,7584,7575,7565,7556,7547,7538,7529,7520,7511,7502,7493,7484,7475,7466,7457,7448,7439,7430,7421,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,7060,7052,7044,7036,7028,7020,7012,7004,6997,6989,6981,6973,6965,6958,6950,6942,6934,6927,6919,6911,6904,6896,6888,6881,6873,6866,6858,6850,6843,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,6534,6528,6521,6514,6507,6500,6494,6487,6480,6473,6467,6460,6453,6447,6440,6433,6427,6420,6413,6407,6400,6394,6387,6381,6374,6368,6361,6355,6348,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,6082,6076,6070,6064,6058,6052,6046,6041,6035,6029,6023,6017,6011,6006,6000,5994,5988,5983,5977,5971,5965,5960,5954,5948,5943,5937,5931,5926,5920,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,5688,5683,5677,5672,5667,5662,5657,5652,5647,5641,5636,5631,5626,5621,5616,5611,5606,5601,5596,5591,5586,5581,5576,5571,5566,5561,5556,5551,5546,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,5342,5337,5333,5328,5323,5319,5314,5310,5305,5301,5296,5292,5287,5283,5278,5274,5269,5265,5261,5256,5252,5247,5243,5238,5234,5230,5225,5221,5217,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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

035,5031,5027,5023,5019,5015,5011,5007,5003,4999,4995,4991,4987,4983,4979,4975,4971,4967,4963,4959,4955,4951,4947,4943,4940,4936,4932,4928,4924,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,4762,4759,4755,4751,4748,4744,4740,4737,4733,4730,4726,4723,4719,4715,4712,4708,4705,4701,4698,4694,4691,4687,4683,4680,4676,4673,4669,4666,4662,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,4517,4514,4511,4507,4504,4501,4498,4494,4491,4488,4485,4481,4478,4475,4472,4469,4465,4462,4459,4456,4453,4449,4446,4443,4440,4437,4434,4430,4427,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,4296,4293,4290,4287,4284,4281,4278,4275,4273,4270,4267,4264,4261,4258,4255,4252,4249,4246,4243,4241,4238,4235,4232,4229,4226,4223,4220,4218,4215,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,4096,4093,4090,4088,4085,4082,4080,4077,4074,4072,4069,4066,4064,4061,4058,4056,4053,4050,4048,4045,4043,4040,4037,4035,4032,4029,4027,4024,4022,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,3913,3911,3908,3906,3903,3901,3898,3896,3894,3891,3889,3886,3884,3881,3879,3877,3874,3872,3869,3867,3865,3862,3860,3857,3855,3853,3850,3848,3846,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,3746,3744,3742,3739,3737,3735,3733,3730,3728,3726,3724,3722,3719,3717,3715,3713,3710,3708,3706,3704,3702,3699,3697,3695,3693,3691,3688,3686,3684,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,3593,3591,3589,3587,3585,3582,3580,3578,3576,3574,3572,3570,3568,3566,3564,3562,3560,3558,3556,3554,3552,3550,3548,3546,3544,3542,3540,3538,3536,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,3448,3446,3444,3442,3440,3438,3436,3433,3431,3429,3427,3425,3423,3421,3419,,3416,3414,3412,3410,3408,3406,3403,3401,3399,3397,3395,3393,3390,3388,3386,3384,3382,3379,3377,3375,3373,3371,3368,3366,3364,3362,3359,3357,3355,3353,3350,3348,3346, 3344,3341,3339,3337,3335,3332,3330,3328,3326 and up to 96 cps.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

243 (252)

Provisioning

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 or guaranteed rate of bandwidth during the connection lifetime. Examples are real time video, audio, circuit emulation services, and audio-video distribution such as TV, pay-per-view, or distance learning. CBR services provide connectivity up to a peak cell rate with an upper bound of cell delay variation tolerance. The source may emit cells at or below the negotiated peak cell rate at any time for any duration and the QoS commitments still pertain. Variable Bit Rate real-time (VBR-rt) is a service category that supports applications requiring variable bandwidth with tight limits on delay. VBRrt is guaranteed an average rate of bandwidth, based on the traffic requirements of the connection (Peak Cell Rate, Sustained Cell Rate, and Maximum Burst Size). Cells are generated at arbitrary time intervals based on connection use and delivered with bounded cell delay variation and cell loss ratio. Examples are variable bit rate CODECs, aggregated voice with silence removal, video conferencing and loop emulation services with AAL2. Variable Bit Rate non-real-time (VBR-nrt) is a service category that supports applications requiring variable bandwidth with fewer delay guarantees as in the case of transaction processing. Cells are generated at arbitrary time intervals based on connection use and delivered with bounded cell delay variation and cell loss ratio. Unspecified Bit Rate (UBR) is intended for applications that do not require a fixed bandwidth or fixed interval of transmission, and are highly tolerant of delay and loss. Examples are file transfer, e-mail, and LANs. In the case of UBR, there is no explicit commitment from the network provider regarding capacity or throughput. The network transmits cells based on available bandwidth without delay or throughput guarantees, and the only traffic parameter is PCR.

The following figure shows the bandwidth occupied by various service categories in a network circuit.

244 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Circuit Capacity in Cells per Second

UBR VBR CBR


SCR PCR

Figure 57.

CBR, VBR, and UBR

7.3.2

ATM performance parameters


The following QoS and traffic parameters are used in this chapter to describe ATM performance.
CLR (Cell Loss Ratio)

CLR is a QoS parameter that gives the ratio of the lost cells to the total number of transmitted cells on a given VCC. This is preset for the connection admission control 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 cell to be transferred from its source to its destination over a virtual connection. It is the 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 the network; it is the difference between the worst case delay as determined by the CTD 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 CBR and 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 of OAM cells.
CDVT (Cell Delay Variance Tolerance)

CDVT is a parameter that specifies in tenths of microseconds the acceptable tolerance to cell-by-cell variations of the CDV (jitter). The CDVT is typically very low for CBR and VBR-rt connections, a bit higher for VBR-nrt connections and very high for UBR connections. This is provisionable for each virtual connection.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

245 (252)

Provisioning

PCR (Peak Cell Rate)

Figure 58.

PCR

PCR is a traffic parameter in cells per second that specifies the maximum source transmission rate. The fraction 1/PCR represents the time between two cells over a given virtual connection. PCR is assigned to all service categories. It can only be set at a speed lower than the port connection speed.

Table 72.

Mapping data rates to ATM peak cell rates Peak cell rate cells/sec.
453 906 1812 2717 3623 5472

Data rates (kbit/s) *)


192 384 768 1152 1536 2320

*) 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 bursty source and specifies a maximum average rate at which cells can be sent over a given ATM virtual connection.

246 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Burst Tolerance

Burst Tolerance is the maximum length of time that a connection can send at the Peak Cell Rate. The parameter measures how long a connection may exceed the Sustained Cell Rate.
MBS (Maximum Burst Size)

Figure 60.

MBS

MBS is a traffic parameter that specifies the maximum number of cells in a burst that can be transmitted at the peak rate assuming that, at the beginning of the burst, 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 priority of 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+1 refers to an aggregate cell stream. The following figure illustrates PCR, SCR, and MBS in a sample ATM traffic stream. It also shows that non-conforming cells are tagged to be discarded in the event of network congestion.

Figure 61.

PCR, SCR, and MBS

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

247 (252)

Provisioning

7.3.4

ATM QoS scheduling


The differentiated Quality of Service of different ATM Service categories are implemented by differentiated scheduling of cell transmission. The available bandwidth is shared by all connections. The bandwidth is yielded to connections as 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-effort service uses excess bandwidth that is left over from guaranteed service reservations, or is currently unused by the guaranteed service. Excess bandwidth is shared by different service categories in proportion to the bandwidth allocated to connections in each category.
Service categories

The different service categories have the following profiles:


.

CBR connections have PCR guaranteed bandwidth. Any traffic exceeding PCR will be subject to traffic contract violation and policing. CBR connections do not use excess bandwidth. Real-time VBR connections have guaranteed bandwidth of effective bandwidth. The proportion of excess bandwidth available for the real-time VBR service category as a whole is the sum of effective bandwidths of the connections divided by the sum of bandwidths of all service categories. Non-real-time VBR connections have guaranteed bandwidth of effective band-width. The proportion of excess bandwidth available for the non-realtime VBR service category as a whole is the sum of effective bandwidths of the connections divided by the sum of bandwidths of all service categories. UBR connections have no guaranteed bandwidth. They use only excess bandwidth providing only best-effort service. The proportion of excess bandwidth available for the UBR service category as a whole is the sum of UBR PCRs of the connections, divided by the sum of bandwidths of all service categories.

The following table summarises the service category profiles:

248 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

Table 73.

Summary of service category scheduling profiles Guaranteed bandwidth of a connection


PCR EBW*) EBW Zero

Service category

Excess bandwidth proportion of the service category


Zero Sum of EBW/Total BW**) Sum of EBW/ TotalBW Sum of PCR/TotalBW

CBR rt-VBR nrt-VBR UBR

*) 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 that effective bandwidth of real-time VBR is calculated to be higher than for non-realtime VBR, giving better service for real-time VBR. CBR is excluded from calculations of excess bandwidth.

7.3.5

Traffic policing
Once a virtual connection is established, active processes monitor and enforce the rules embodied in the traffic contract. This is called traffic policing. Traffic policing is carried out by a process component called the Usage Parameter Control (UPC), resident in the trunk/control unit. In the D500, both traffic entering 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 a method to explain how an ATM switch measures the bandwidth conformance of each CBR and VBR connection. It is a flow control algorithm where cells are monitored to check whether they comply with the established connection parameters.

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

249 (252)

Provisioning

The dual leaky bucket analogy conceptually describes the traffic policing and shaping performed by the complex Generic Cell Rate Algorithm. In the following figure there is a burst of cells entering the network from the ATM Customer Premises Equipment. The leak out of the first bucket represents the Peak Cell Rate. Cells may enter at above the Peak Cell Rate, and the tolerance for this is represented by CDVT (Cell Delay Variance Tolerance), which is the depth of the first bucket. Cells are discarded when the bucket fills. This is true for all types of connections: CBR, VBR-rt, VBR-nrt, and UBR. For VBR connections, cells then enter the second bucket. The leak out of the second bucket represents the Sustainable Cell Rate, and the depth of the bucket is the Burst Tolerance, which is the maximum length of time a connection can send cells at the Peak Cell Rate. Cells overflowing from the second bucket are either tagged or discarded.

Incoming Burst of Cells ATM CPE

Discarded

Cell Delay Variance Tolerance Peak Cell Rate Burst Tolerance

Tagged or Discarded

Sustainable Cell Rate

Figure 62.

Generic Cell Rate Algorithm (Dual Leaky Bucket)

250 (252)

# Nokia Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en

Provisioning concepts and parameters

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 traffic descriptor 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 of ATM cells) and makes an intelligent choice of dropping all cells in a packet instead of randomly dropping cells from many packets. EPD determines the packet boundaries by examining the Service Data Unit Identifier (SDUI) in the Payload Type (PT) field of the ATM cell header.

ATM Cell
0 or VPI VPI VCI VCI PT CLP PTI EFCI VPI VCI

Payload Type (PT)

Header Error Check

SDUI

Payload

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 function ensures that the network does not accept new connection requests when it cannot provide the requested QoS. For each connection request, the CAC evaluates the bandwidth request based on the following information obtained from the traffic contract:

dn03492199 Issue 4 en

# Nokia Corporation Nokia Proprietary and Confidential

251 (252)

Provisioning

Values of parameters in the source traffic descriptor Requested and acceptable values of each QoS parameter and the requested QoS 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 Corporation Nokia Proprietary and Confidential

dn03492199 Issue 4 en