Nokia 7450 ESS, 7750 SR, 7950 XRS Interface Configuration Manual

Download

Page 1

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

7450 ETHERNET SERVICE SWITCH 7750 SERVICE ROUTER 7950 EXTENSIBLE ROUTING SYSTEM VIRTUALIZED SERVICE ROUTER

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

3HE 11968 AAAC TQZZA 01

Issue: 01

September 2017

Nokia — Proprietary and confidential. Use pursuant to applicable agreements.

Page 2

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Nokia is a registered trademark of Nokia Corporation. Other products and company names mentioned herein may be trademarks or tradenames of their respective owners.

The information presented is subject to change without notice. No responsibility is assumed for inaccuracies contained herein.

Contains proprietary/trade secret information which is the property of Nokia and must not be made available to, or copied or used by anyone outside Nokia without its written authorization. Not to be used or disclosed except in accordance with applicable agreements.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 3

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

1 Getting Started ...............................................................................9

1.1 About This Guide.........................................................................................9

1.2 Interface Configuration Process ................................................................11

2 Interfaces .......................................................................................13

2.1 Configuration Overview .............................................................................13

2.1.1 Chassis Slots and Cards ..........................................................................13

2.1.2 MCMs .......................................................................................................15

2.1.3 MDA-a, MDA-aXP, MDA, MDA-XP and MDA-e Modules..........................15

2.1.4 XMAs/C-XMAs...........................................................................................18

2.1.5 CMAs.........................................................................................................19

2.1.6 Versatile Service Module (VSM)................................................................20

2.1.7 Oversubscribed Ethernet MDAs ................................................................20

2.1.7.1 Rate Limiting..............................................................................................21

2.1.7.2 Packet Classification and Scheduling........................................................21

2.1.8 Channelized MDA/CMA Support ...............................................................23

2.1.8.1 Channelized DS-1/E-1 CMA ......................................................................23

2.1.8.2 Channelized DS-3/E-3 CMA ......................................................................23

2.1.8.3 Channelized Any Service Any Port (ASAP) CHOC-3/STM-1 ....................23

2.1.8.4 Channelized OC-12/STM-4 ASAP MDAs..................................................24

2.1.8.5 Channelized DS-3/E-3 ASAP MDA (4-Port) ..............................................24

2.1.8.6 Channelized DS-3/E-3 ASAP MDA (12-Port) ............................................24

2.1.8.7 Channelized OC-3/STM-1 Circuit Emulation Services (CES) CMA

and MDA....................................................................................................25

2.1.8.8 Network Interconnections ..........................................................................26

2.2 Digital Diagnostics Monitoring ...................................................................27

2.2.1 SFPs and XFPs.........................................................................................31

2.2.2 Statistics Collection ...................................................................................31

2.3 Ports ..........................................................................................................32

2.3.1 Port Types .................................................................................................32

2.3.2 Port Features.............................................................................................35

2.3.2.1 Port State and Operational State...............................................................35

2.3.2.2 802.1x Network Access Control ................................................................36

2.3.2.3 MACsec .....................................................................................................41

2.3.2.4 SONET/SDH Port Attributes......................................................................56

2.3.2.5 SONET/SDH Path Attributes .....................................................................57

2.3.2.6 Multilink Frame Relay ................................................................................58

2.3.2.7 FRF.12 End-to-End Fragmentation ...........................................................61

2.3.2.8 FRF.12 UNI/NNI Link Fragmentation ........................................................62

2.3.2.9 MLFR/FRF.12 Support of APS, BFD, and Mirroring Features ..................63

2.3.2.10 Multilink Point-to-Point Protocol (MLPPP) .................................................64

2.3.2.11 Multi-Class MLPPP....................................................................................68

2.3.2.12 Cisco HDLC...............................................................................................75

2.3.2.13 Automatic Protection Switching (APS) ......................................................77

2.3.2.14 Inverse Multiplexing Over ATM (IMA)......................................................106

Issue: 01 3HE 11968 AAAC TQZZA 01 3

Page 4

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

2.3.2.15 Ethernet Local Management Interface (E-LMI) .......................................109

2.3.2.16 Link Layer Discovery Protocol (LLDP).....................................................110

2.3.2.17 Exponential Port Dampening...................................................................114

2.3.3 Per Port Aggregate Egress Queue Statistics Monitoring.........................117

2.4 Port Cross-Connect (PXC) ......................................................................119

2.4.1 PXC Terminology ....................................................................................120

2.4.2 PXC - Physical Port in Cross-Connect (Loopback) Mode .......................121

2.4.2.1 Operational State.....................................................................................122

2.4.3 PXC Sub-Ports ........................................................................................122

2.4.3.1 PXC Sub-Port Operational State .............................................................124

2.4.4 Port Statistics...........................................................................................125

2.4.4.1 Statistics on Physical PXC Ports .............................................................125

2.4.5 LAG with PXC Ports – PXC LAG.............................................................126

2.4.6 Basic PXC Provisioning...........................................................................127

2.4.7 QoS .........................................................................................................128

2.4.7.1 Queue Allocation on PXC Sub-Ports.......................................................128

2.4.7.2 Pool Allocations on PXC Ports ................................................................129

2.4.7.3 QoS Summary .........................................................................................129

2.4.8 Mirroring and LI on PXC Ports.................................................................130

2.4.9 Multi-Chassis Redundancy ......................................................................130

2.4.10 Health Monitoring on the PXC Sub-Ports ................................................130

2.4.11 Configuration Example ............................................................................131

2.5 Forwarding Path Extensions (FPE) ........................................................134

2.6 LAG .........................................................................................................136

2.6.1 LACP .......................................................................................................136

2.6.1.1 LACP Multiplexing ...................................................................................137

2.6.1.2 LACP Tunneling ......................................................................................137

2.6.2 Active-Standby LAG Operation ...............................................................138

2.6.3 LAG on Access QoS Consideration ........................................................140

2.6.3.1 Adapt QoS Modes ...................................................................................140

2.6.3.2 Per-fp-ing-queuing...................................................................................142

2.6.3.3 Per-fp-egr-queuing ..................................................................................142

2.6.3.4 Per-fp-sap-instance .................................................................................143

2.6.4 LAG and ECMP Hashing.........................................................................144

2.6.4.1 Per Flow Hashing ....................................................................................145

2.6.4.2 Per Link Hashing .....................................................................................152

2.6.4.3 Explicit Per Link Hash Using LAG Link Mapping Profiles........................154

2.6.4.4 Consistent Per Service Hashing ..............................................................155

2.6.4.5 ESM – LAG Hashing per Vport................................................................157

2.6.5 LAG Hold Down Timers...........................................................................160

2.6.6 BFD over LAG Links................................................................................161

2.6.7 Mixed Port-Speed LAG Support ..............................................................162

2.6.7.1 LAG Upgrade...........................................................................................164

2.6.8 Multi-Chassis LAG...................................................................................164

2.6.8.1 Overview..................................................................................................165

2.6.8.2 MC-LAG and Subscriber Routed Redundancy Protocol (SRRP) ............169

2.6.8.3 Point-to-Point (p2p) Redundant Connection Across Layer 2/3 VPN

Network ..................................................................................................169

2.6.8.4 DSLAM Dual Homing in Layer 2/3 TPSDA Model...................................171

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 5

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2.7 G.8031 Protected Ethernet Tunnels ........................................................172

2.8 G.8032 Protected Ethernet Rings............................................................173

2.9 Ethernet Port Monitoring .........................................................................174

2.10 802.3ah OAM ..........................................................................................178

2.10.1 OAM Events ............................................................................................180

2.10.1.1 Link Monitoring ........................................................................................181

2.10.2 Remote Loopback ...................................................................................187

2.10.3 802.3ah OAM PDU Tunneling for Epipe Service.....................................188

2.10.3.1 802.3ah Grace Announcement................................................................188

2.11 MTU Configuration Guidelines ................................................................195

2.11.1 Default MTU Values ................................................................................195

2.11.2 Modifying MTU Defaults ..........................................................................196

2.11.3 Configuration Example ............................................................................196

2.12 Deploying Preprovisioned Components ..................................................198

2.13 Setting Fabric Speed ...............................................................................199

2.13.1 fabric-speed-a (SFM5/CPM5)..................................................................199

2.13.2 fabric-speed-b (SFM5/CPM5)..................................................................199

2.14 Versatile Service Module .........................................................................200

2.14.1 VSM-CCA-XP ..........................................................................................200

2.15 Configuration Process Overview .............................................................203

2.16 Configuration Notes.................................................................................204

2.17 Configuring Physical Ports with CLI ........................................................205

2.17.1 Preprovisioning Guidelines......................................................................205

2.17.1.1 Predefining Entities..................................................................................205

2.17.1.2 Preprovisioning a Port .............................................................................205

2.17.1.3 Maximizing Bandwidth Use .....................................................................206

2.17.2 Basic Configuration .................................................................................207

2.17.3 Common Configuration Tasks .................................................................209

2.17.3.1 Configuring Cards and MDAs ..................................................................209

2.17.3.2 Configuring Cards, MCMs, and MCAs ....................................................211

2.17.3.3 Configuring Ports.....................................................................................212

2.18 Service Management Tasks ....................................................................266

2.18.1 Modifying or Deleting an MDA, MCM, CMA or XMA ...............................266

2.18.2 Modifying a Card Type ............................................................................266

2.18.3 Deleting a Card........................................................................................267

2.18.4 Deleting Port Parameters ........................................................................268

2.18.5 Soft IOM Reset ........................................................................................268

2.18.5.1 Soft Reset................................................................................................268

2.18.5.2 Deferred MDA Reset ...............................................................................269

2.19 Configuration Command Reference ........................................................271

2.19.1 Command Hierarchies.............................................................................271

2.19.1.1 Card Commands .....................................................................................271

2.19.1.2 MCM Commands.....................................................................................272

2.19.1.3 MDA Commands .....................................................................................272

2.19.1.4 Power Commands ...................................................................................273

2.19.1.5 Virtual Scheduler Commands..................................................................274

2.19.1.6 Forwarding Plane (FP) Commands .........................................................274

2.19.1.7 Port Configuration Commands ................................................................276

2.19.1.8 Port XC Commands.................................................................................279

Issue: 01 3HE 11968 AAAC TQZZA 01 5

Page 6

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

2.19.1.9 Forwarding Path Extension (FPE) Commands........................................279

2.19.1.10 Port APS Commands ..............................................................................279

2.19.1.11 Ethernet Commands................................................................................280

2.19.1.12 Interface Group Handler Commands.......................................................288

2.19.1.13 Multilink Bundle Commands ....................................................................288

2.19.1.14 SONET-SDH Commands ........................................................................290

2.19.1.15 TDM Commands .....................................................................................292

2.19.1.16 DS3 Commands ......................................................................................295

2.19.1.17 E1 Commands.........................................................................................296

2.19.1.18 E3 Commands.........................................................................................298

2.19.1.19 LAG Commands ......................................................................................300

2.19.1.20 MACsec Commands................................................................................303

2.19.1.21 Ethernet Tunnel Commands....................................................................303

2.19.1.22 Multi-Chassis Redundancy Commands ..................................................305

2.19.2 Configuration Command Descriptions.....................................................306

2.19.2.1 Generic Commands.................................................................................307

2.19.2.2 Card Commands .....................................................................................310

2.19.2.3 MCM Commands.....................................................................................313

2.19.2.4 MDA (XMA) Commands ..........................................................................314

2.19.2.5 MDA/Port QoS Commands .....................................................................321

2.19.2.6 Power Commands ...................................................................................327

2.19.2.7 Virtual Scheduler Commands..................................................................329

2.19.2.8 Forwarding Plane Configuration Commands...........................................333

2.19.2.9 MACsec Commands................................................................................358

2.19.2.10 General Port Commands .........................................................................366

2.19.2.11 Port XC Commands.................................................................................410

2.19.2.12 Forwarding Path Extension (FPE) Commands........................................412

2.19.2.13 APS Commands ......................................................................................415

2.19.2.14 Ethernet Port Commands ........................................................................423

2.19.2.15 802.1x Port Commands...........................................................................488

2.19.2.16 LLDP Port Commands.............................................................................496

2.19.2.17 Network Port Commands ........................................................................499

2.19.2.18 Interface Group Handler Commands.......................................................501

2.19.2.19 Multilink-Bundle Port Commands ............................................................502

2.19.2.20 SONET/SDH Port Commands.................................................................520

2.19.2.21 SONET/SDH Path Commands................................................................526

2.19.2.22 ATM Interface Commands.......................................................................534

2.19.2.23 Frame Relay Commands.........................................................................538

2.19.2.24 TDM Commands .....................................................................................545

2.19.2.25 LAG Commands ......................................................................................566

2.19.2.26 Eth Tunnel Commands............................................................................585

2.19.2.27 ETH-CFM Configuration Commands.......................................................596

2.19.2.28 Multi-Chassis Redundancy Commands ..................................................609

2.19.2.29 Forwarding Plane Tools Commands .......................................................628

2.20 Show, Monitor, Clear, Debug, and Tools Command Reference .............629

2.20.1 Command Hierarchies.............................................................................629

2.20.1.1 Show Commands ....................................................................................629

2.20.1.2 Monitor Commands .................................................................................632

2.20.1.3 Clear Commands.....................................................................................632

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 7

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2.20.1.4 Debug Commands...................................................................................633

2.20.1.5 Tools Commands ....................................................................................633

2.20.2 Command Descriptions ...........................................................................634

2.20.2.1 Hardware Show Commands....................................................................635

2.20.2.2 PEQ Show Commands............................................................................699

2.20.2.3 APS Show Commands ............................................................................706

2.20.2.4 Port Show Commands.............................................................................710

2.20.2.5 Multilink Bundle Show Commands ..........................................................805

2.20.2.6 LAG Show Commands ............................................................................825

2.20.2.7 MACsec Show Commands......................................................................836

2.20.2.8 Monitor Commands .................................................................................847

2.20.2.9 Clear Commands.....................................................................................856

2.20.2.10 Tools Commands ....................................................................................861

3 Standards and Protocol Support ..............................................887

Issue: 01 3HE 11968 AAAC TQZZA 01 7

Page 8

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 9

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

1 Getting Started

1.1 About This Guide

This guide describes system concepts and provides configuration examples to provision Input/Output modules (IOMs), XMA Control Modules (XCMs), also referred to as cards, Media Dependent Adapters (MDAs), XRS Media Adapters (XMAs), and ports.

This guide is organized into functional chapters and provides concepts and descriptions of the implementation flow, as well as Command Line Interface (CLI) syntax and command usage.

The topics and commands described in this document apply to the:

• 7450 ESS

Getting Started

• 7750 SR

• 7950 XRS

• VSR

Table 1 lists the available chassis types for each SR OS router.

Table 1 Supported SR OS Router Chassis Types

7450 ESS 7750 SR 7950 XRS

• 7450 ESS-7/12 running in standard mode (not mixedmode)

• 7450 ESS-7/12 running in mixed-mode (not standard mode)

• 7750 SR-a4/a8

• 7750 SR-c4/c12

• 7750 SR-1e/2e/3e

• 7750 SR-7/12

• 7750 SR-12e

•7950XRS-16c

• 7950 XRS-20/40

For a list of unsupported features by platform and chassis, refer to the SR OS

R15.0.Rx Software Release Notes, part number 3HE 12060 000x TQZZA or the VSR Release Notes, part number 3HE 12092 000x TQZZA.

Command outputs shown in this guide are examples only; actual displays may differ depending on supported functionality and user configuration.

Issue: 01 3HE 11968 AAAC TQZZA 01 9

Page 10

Getting Started

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Note: This guide generically covers Release 15.0.Rx content and may contain some content that will be released in later maintenance loads. Refer to the SR OS R15.0.Rx Software Release Notes, part number 3HE 12060 000x TQZZA or the VSR Release Notes, part number 3HE 12092 000x TQZZA, for information on features supported in each load of the Release 15.0.Rx software.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 11

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

1.2 Interface Configuration Process

Table 2 lists the tasks necessary to configure IOMs and XCMs (also referred to as

cards), MDAs and XMAs, and ports.

Note: For consistency across platforms, XMAs are modeled in the SR OS (CLI and SNMP) as MDAs.

Unless specified otherwise:

• the term “card” is used generically to refer to both IOMs and XCMs

• the term “MDA” is used generically to refer to both MDAs and XMAs

Table 2 Configuration Process

Area Task Section

Getting Started

Provisioning Chassis slots and cards Chassis Slots and Cards

MCMs MCMs

MDAs MDA-a, MDA-aXP, MDA, MDA-XP

and MDA-e Modules

Versatile Service Module Versatile Service Module (VSM)

Ports Ports

Interface Configuration MTU Configuration MTU Configuration Guidelines

Configure fabric speed Setting Fabric Speed

Preprovisioning Preprovisioning Guidelines

Configure cards and MDAs Configuring Cards and MDAs

Configure cards, MCMs, and MDAs Configuring Cards, MCMs, and MCAs

Configure ports Configuring Ports

Service management Service Management Tasks

Issue: 01 3HE 11968 AAAC TQZZA 01 11

Page 12

Getting Started

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 13

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2 Interfaces

2.1 Configuration Overview

Note: This document uses the term preprovisioning in the context of preparing or

preconfiguring entities such as chassis slots, cards, Media Dependent Adapters (MDAs), compact media adapters (CMAs), ports, and interfaces, prior to initialization. These entities can be installed while remaining administratively disabled (shutdown). When the entity is in a no shutdown state (administratively enabled), then the entity is considered to be provisioned.

Note: For consistency across platforms, XRS Media Adapters (XMAs) and Compact XMAs (C-XMAs) are modeled as MDAs.

Interfaces

Unless specified otherwise:

• the term “card” is used generically to refer to both Input Output Modules (IOMs) and XCMs

• the term “MDA” is used generically to refer to both MDAs and XMAs

Nokia routers provide the capability to configure chassis slots to accept specific card and MDA types and set the relevant configurations before the equipment is actually installed. The preprovisioning capability allows you to plan your configurations as well as monitor and manage your router hardware inventory. Ports and interfaces can also be preprovisioned. When the functionality is needed, the cards can be inserted into the appropriate chassis slots when required.

2.1.1 Chassis Slots and Cards

To preprovision a chassis slot, the card type must be specified. Operators can enter card type information for each slot. When a card is installed in a slot and enabled, the system verifies that the installed card type matches the provisioned card type. If the parameters do not match, the card remains offline. A preprovisioned slot can remain empty without conflicting with populated slots.

Issue: 01 3HE 11968 AAAC TQZZA 01 13

Page 14

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

The general syntax for the configuration of card slots is similar for all platforms, though the number of available slots varies by platform and chassis model. The supported card-types vary by chassis. Refer to the appropriate platform Installation Guide for more information.

The 7950 XRS platforms accept XCMs in slots. An XCM has two slots, each of which accept an XMA or C-XMA module. The C-XMA modules require a mechanical adapter to fit in an XMA slot.

In the config context, use the following CLI commands and syntax examples to provision the chassis slot and XCM:

A:XRS20>config# card 1 A:XRS20>config>card# card-type xcm-x20

The 7450 ESS-7/12, and 7750 SR-7/12, and 7750 SR-12e platforms support a variety of IOM types (including the IOM3-XP, IOM3-XP-B, IOM3-XP-C, IOM4-e and IOM4-e-B) in designated chassis slots. IOMs have two slots for pluggable MDAs. The IOM3-XP, IOM3-XP-B and IOM3-XP-C support MDA and MDA-XPs. The IOM4-e and IOM4-e-B support MDA-e modules.

In the config context, use the following CLI commands and syntax examples to provision a chassis slot and an IOM:

A:SR12-1>config# card 1 A:SR12-1>config>card# card-type iom3-xp

The 7450 ESS-7/12, and 7750 SR-7/12, and 7750 SR-12e platforms also support a variety of IMMs in designated chassis slots. IMMs have integrated MDAs. The provisioning requirements depends on the generation of IMM that you use. Refer to the IMM Installation Guide for more information.

The 7750 SR-a platforms support IOM-a cards in dedicated chassis slots. The 7750 SR-a4 supports one physical IOM-a in slot 3. This IOM-a is represented in the CLI as card 1. The 7750 SR-a8 supports two physical IOM-a cards, one in slot 3, the other in slot 6. These IOM-a cards are represented in the CLI as card 1 and card 2 respectively. The IOM-a does not have pluggable MDA slots. Each IOM-a can be configured to support up to four MDA-a or MDA-aXP modules. IOM-a cards are configured in the same manner as IOMs.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 15

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

The 7750 SR-e platforms support the IOM-e modules in dedicated slots in the rear of each chassis. The 7750 SR-1e supports one physical IOM-e module. This IOM-e is represented in the CLI as card 1. The 7750 SR-2e supports two physical IOM-e cards. These IOM-e cards are represented in the CLI as card 1 and card 2 respectively. The 7750 SR-3e supports three physical IOM-e cards. These IOM-e cards are represented in the CLI as card 1, card 2, and card 3 respectively. The IOM-e does not have pluggable MDA slots. An IOM-e can be configured to support up to four MDA-e modules. IOM-e cards are configured in the same manner as IOMs.

The 7750 SR-c4/c12 platforms do not have slots for IOM or IMM cards. The system is modeled as having a fixed system-provisioned IOM in slot 1. The chassis has positions that accept MCMs or CMAs. MCMs accept MDAs. CMAs can be directly inserted into the 7750 SR-c4/c12 without the need for MCMs. CMAs are modeled as MDAs in SR OS.

2.1.2 MCMs

Interfaces

MCMs are only supported on the 7750 SR-c12 and SR-c4 systems.

An MCM must be configured before an MDA can be provisioned. If you provision an MDA type before an MCM is configured, it is assumed you are provisioning a CMA. CMAs do not require MCM preconfiguration. Up to six MCMs may be provisioned on a 7750 SR-c12. Even-numbered CMA positions are invalid for MCM installation (MCMs physically span two CMA positions; “mcm 1” spans CMA position 1 and 2). Up to two MCMs can be provisioned on the 7750 SR-c4.

Refer to the CMA Installation Guide and MDA Installation Guide for more information on the physical characteristics of each card.

2.1.3 MDA-a, MDA-aXP, MDA, MDA-XP and MDA-e Modules

MDAs are pluggable adapter cards that provide physical interface connectivity. MDAs are available in a variety of interface and density configurations. MDA modules differ by chassis. Refer to the individual chassis guide and the individual MDA installation guides for more information about specific MDAs.

Issue: 01 3HE 11968 AAAC TQZZA 01 15

Page 16

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

On the 7750 SR-c4/c12 platforms, the MDAs plug into MCMs. MCMs must be provisioned before an MDA can be provisioned with a type. Up to six MDAs (each seated in an MCM) may be provisioned on a 7750 SR-c12. Even-numbered CMA positions are invalid for MDA installation (MDAs physically span two CMA positions; “mda 1” spans CMA positions 1 and 2). Up to two MDAs (each seated in an MCM) can be provisioned on the 7750 SRc4. CMAs are also supported on 7750 SR-c4/c12 platforms, as described in CMAs.

The following displays a show card state command. In this example, an m60-10/ 100eth-tx MDA is installed in position 1 on a 7750 SR-c12.

A:ALU-3>config>card# show card state =============================================================================== Card State =============================================================================== Slot/ Provisioned Equipped Admin Operational Num Num Comments Id Type Type State State Ports MDA

------------------------------------------------------------------------------1 iom-xp iom-xp up up 12 1/1 mcm-xp mcm-xp up up 1/3 mcm-xp up unprovisioned 1/1 m60-10/100eth-tx m60-10/100eth-tx up up 1/5 c8-10/100eth-tx c8-10/100eth-tx up up 1/6 c1-1gb-sfp up unprovisioned 1/7 c8-chds1 up unprovisioned 1/8 c4-ds3 up unprovisioned 1/9 c8-10/100eth-tx up unprovisioned 1/10 c1-1gb-sfp up unprovisioned 1/11 c8-chds1 up unprovisioned 1/12 c4-ds3 up unprovisioned A cfm-xp cfm-xp up up Active B cfm-xp up down Standby =============================================================================== A:ALU-3>config>card#

On the 7450 ESS-7/12, 7750 SR-7/12, and 7750 SR-12e, MDAs plug into IOMs. (MDA and MDA-XP modules plug into the IOM3-XP/-B/-C. MDA-e modules plug into the IOM4-e and IOM4-e-B). Up to two MDAs can be provisioned on an IOM.

IMMs are designed with fixed integrated media cards, which may require provisioning, depending on the generation of the IMM.

MDA-a and MDA-aXP modules are used in the 7750 SR-a and the MDA-e and ISA2 modules are used in the 7750 SR-e chassis. Up to four MDAs can be provisioned for each IOM.

In all cases, the card slot and IOM or IMM card-type must be provisioned before an MDA can be provisioned. A preprovisioned MDA slot can remain empty without interfering with services on populated equipment. When an MDA is installed and enabled, the system verifies that the MDA type matches the provisioned type. If the parameters do not match, the MDA remains offline.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 17

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

On the 7750 SR-c12/SR-c4, 7450 ESS-7/12, 7750 SR-7/12, and 7750 SR-12e platforms, MDA names in the CLI start with the letter 'm' (for example, m10-1gb-xpsfp).

The following example displays the card, card-type, mda, and mda-type command usage in the 7750 SR-7:

A:SR7>config# card 1 A:SR7>config>card# card-type iom3-xp A:SR7>config>card# mda 1 A:SR7>config>card>mda# mda-type m60-10/100eth-tx A:SR7>config>card>mda# exit A:SR7>config>card# mda 2 A:SR7>config>card>mda# mda-type m10-1gb-sfp A:SR7>config>card>mda# exit

The following example displays the configuration:

A:SR7# admin display-config ...

---------------------------------------------echo "Card Configuration " #-----------------------------------------card 1

card-type iom3-xp mda 1

mda-type m60-10/100eth-tx exit mda 2

mda-type m10-1gb-sfp exit

exit

----------------------------------------------

Interfaces

The 7750 SR-a4 and 7750 SR-a8 support only MDA-a and MDA-aXP modules, which are identified in the CLI with an “ma” prefix (for example, ma4-10gb-sfp+), or “max” prefix (for example, maxp10-10gb-sfp+). Likewise, the 7750 SR-1e, 7750 SR-2e, and 7750 SR-3e support only MDA-e modules, which are identified in the CLI with an “me” prefix, such as me1-100gb-cfp2.

The following example shows the card, card-type, mda, and mda-type command usage in the 7750 SR-1e:

A:SR1e>config# card 1 A:SR1e>config>card# card-type iom-e A:SR1e>config>card# mda 1 A:SR1e>config>card>mda# mda-type me10-10gb-sfp+ A:SR1e>config>card>mda# exit A:SR1e>config>card# mda 4 A:SR1e>config>card>mda# mda-type me1-100gb-cfp2 A:SR1e>config>card>mda# exit

The following example displays the configuration:

Issue: 01 3HE 11968 AAAC TQZZA 01 17

Page 18

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

A:SR1e# admin display-config ...

---------------------------------------------echo "Card Configuration" #---------------------------------------------

card 1

card-type iom-e mda 1

mda-type me10-10gb-sfp+ exit mda 4

mda-type me1-100gb-cfp2 exit

exit

---------------------------------------------A:SR1e#

2.1.4 XMAs/C-XMAs

Note: For consistency across platforms, XMAs are modeled in the system as MDAs, and

unless specified otherwise, the term MDA is used generically in this document to refer to both MDAs and C-XMA/XMAs. When the term XMA is used, it refers to both XMAs and CXMAs unless specified otherwise.

XMAs are supported on the 7950 XRS platforms. XMAs plug into XCMs. XCMs must be provisioned before an XMA can be provisioned with a type.

The XMA information must be configured before ports can be configured. After you configure the XCM, use the following CLI commands to provision XMAs.

A maximum of two XMAs can be configured on an XCM. The following example displays the card slot, card type, MDA slot, and MDA type command usage:

A:XRS20>config# card 1 A:XRS20>config>card# card-type xcm-x20 A:XRS20>config>card# mda 1 A:XRS20>config>card>mda# mda-type cx2-100g-cfp A:XRS20>config>card>mda# power-priority-level 130 A:XRS20>config>card>mda# exit A:XRS20>config>card# mda 2 A:XRS20>config>card>mda# mda-type cx20-10g-sfp A:XRS20>config>card>mda# power-priority-level 135 A:XRS20>config>card>mda# exit

The following example displays the configuration:

A:XRS20# admin display-config ...

----------------------------------------------

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 19

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

echo "Card Configuration " #------------------------------------------

card 1

card-type xcm-x20 mda 1

mda-type cx2-100g-cfp

power-priority-level 130 exit mda 2

mda-type cx20-10g-sfp

power-priority-level 135

exit

---------------------------------------------A:XRS20#

On the 7950 XRS, the show card state output displays an “x” in the name of the XMA and “cx” in the name of a C-XMA:

A:Dut-A# show card state =============================================================================== Card State =============================================================================== Slot/ Provisioned Type Admin Operational Num Num Comments Id Equipped Type (if different) State State Ports MDA

------------------------------------------------------------------------------1 xcm-x20 up up 2 1/1 cx20-10g-sfp up up 20 1/2 cx20-10g-sfp up up 20 2 xcm-x20 up up 2 2/1 cx20-10g-sfp up up 20 A cpm-x20 up up Active B cpm-x20 up up Standby ===============================================================================

Interfaces

2.1.5 CMAs

CMAs (Compact Media Adapter) are supported on the 7750 SR-c12 and SR-c4 and are configured and provisioned in the same manner as MDAs. Up to twelve CMAs may be provisioned on a 7750 SR-c12, and up to four CMAs may be provisioned on an SR-c4. CMA names in the CLI start with the letter “c” (for example, c4-ds3). The following shows show card state command output. In this example, a c8-10/100eth- tx CMA is installed in CMA position 5.

A:7750-3# show card state ==================================================================================== Card State ==================================================================================== Slot/ Provisioned Equipped Admin Operational Num Num Comments Id Type Type State State Ports MDA

------------------------------------------------------------------------------1 iom-xp iom-xp up up 12

Issue: 01 3HE 11968 AAAC TQZZA 01 19

Page 20

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

1/5 c8-10/100eth-tx c8-10/100eth-tx up up 8 1/6 c8-10/100eth-tx c8-10/100eth-tx up up 8 1/7 c8-chds1 up unprovisioned 1/8 c4-ds3 up unprovisioned 1/9 c8-10/100eth-tx up unprovisioned 1/10 c1-1gb-sfp up unprovisioned 1/11 c8-chds1 up unprovisioned 1/12 c4-ds3 up unprovisioned A cfm-xp cfm-xp up up Active B cfm-xp up provisioned Standby ==================================================================================== A:7750-3#

On the 7750 SR-c4 platform there are two fixed 10GbE ports that are modeled in CLI as an icm2-10gb-xp-xfp (integrated CMA) in position 1/5. A preprovisioned CMA slot can remain empty without conflicting with populated slots.

Once installed and enabled, the system verifies that the installed CMA type matches the provisioned type. If the parameters do not match, the CMA remains offline.

2.1.6 Versatile Service Module (VSM)

The Versatile Service Module (VSM) is a module that allows operators to internally connect a VPLS or VLL service into an IES or IPVPN service. Each module is capable of 10 Gb/s throughput.

A VSM, like an MDA, is installed and provisioned as a pluggable module in an IOM.

The VSM is supported on the 7450 ESS-7/12, 7750 SR-7/12, and 7750 SR-12e platforms. The VSM is not supported on the 7950 XRS or on the 7750 SR-c12/c4 platforms.

See Versatile Service Module for more details.

2.1.7 Oversubscribed Ethernet MDAs

The 7750 SR and 7450 ESS support oversubscribed Ethernet MDAs and CMAs. These have more bandwidth towards the user than the capacity between the MDA and IOM.

A traffic management function is implemented on the MDA to control the data entering the IOM. This function consists of two parts:

• rate limiting

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 21

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

• packet classification and scheduling

2.1.7.1 Rate Limiting

The oversubscribed MDA or CMA limits the rate at which traffic can enter the MDA or CMA on a per-port basis. If a port exceeds its configured limits then the excess traffic will be discarded, and 802.3x flow control frames (pause frames) are generated.

2.1.7.2 Packet Classification and Scheduling

The classification and scheduling function implemented on the oversubscribed MDA or CMA ensures that traffic is correctly prioritized when the bus from the MDA or CMA to the IOM is over-committed. This could occur if the policing parameters configured are such that the sum of the traffic being admitted into the MDA or CMA is greater than the capacity between the MDA and the IOM.

Interfaces

The classification function uses the bits set in the DSCP or Dot1p fields of the customer packets to perform classification. It can also identify locally addressed traffic arriving on network ports as Network Control packets. This classification on the oversubscribed MDA or CMA uses the following rules.

• If the service QoS policy for the SAP (port or VLAN) uses the default classification policy, all traffic is classified as Best Effort (be).

• If the service QoS policy for the SAP contains a Dot1p classification, the Dot1p field in the customer packets is used for classification on the MDA or CMA.

• If the service QoS policy for the SAP contains a DSCP classification, the DSCP field in the customer packets is used for classification on the MDA or CMA.

• If a mix of Dot1p and DSCP classification definitions are present in the service QoS policy, then the field used to perform classification is the type used for the highest priority definition. For example, if High Priority 1 is the highest priority definition and it specifies that the DSCP field should be used, then the DSCP field is used for classification on the MDA or CMA and the Dot1p field is ignored.

• If the service QoS policy for the SAP specifies IP or MAC filters for forwarding class identification, then traffic is treated as Best Effort. Full MAC or IP classification is not possible on the MDA/CMA (but is possible on the IOM).

Issue: 01 3HE 11968 AAAC TQZZA 01 21

Page 22

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

• The packet is classified into 16 classes. Typically, these are the eight forwarding classes and each packet is assigned one priority per forwarding class. After classification, the packet is offered to the queuing model. This queuing model is limited to three queues each having four thresholds. These thresholds define whether an incoming packet, after classification, is accepted in the queue or not.

Table 3 shows typical mapping of classes onto queues and thresholds.

Table 3 Typical Mapping Of Classes Onto Queues/Threshold

Counter {Queue Threshold Traffic Class}

0 {2 3 “fc-nc / in-profile”}

1 {2 2 “fc-nc / out-profile”}

2 {2 1 “fc-h1 / in-profile”}

3 {2 0 “fc-h1 / out-profile”}

4 {1 3 “fc-ef / in-profile”}

5 {1 2 “fc-ef / out-profile”}

6 {1 1 “fc-h2 / in-profile”}

7 {1 0 “fc-h2 / out-profile”}

8 {0 3 “fc-l1 / in-profile”}

9 {0 3 “fc-l1 / out-profile”}

10 {0 2 “fc-af / in-profile”}

11 {0 2 “fc-af / out-profile”}

12 {0 1 “fc-l2 / in-profile”}

13 {0 1 “fc-l2 / out-profile”}

14 {0 0 “fc-be / in-profile”}

15 {0 0 “fc-be / out-profile”}

A counter is associated with each mapping. The above is an example and is dependent on the type of classification (such as dscp-exp, dot1p, and so on). When the threshold of a particular class is reached, packets belonging to that class are not accepted in the queue. The packets are dropped and the associated counter is incremented.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 23

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

The scheduling of the three queues is done in a strict priority, highest priority basis is associated with queue 2. This means that scheduling is done at queue level, not on the class that resulted from the classification. As soon as a packet has been accepted by the queue there is no way to differentiate it from other packets in the same queue (for example, another classification result not exceeding its threshold). All packets queued in the same queue have the same priority from a scheduling point of view.

2.1.8 Channelized MDA/CMA Support

2.1.8.1 Channelized DS-1/E-1 CMA

Each 8-port channelized DS-1/E-1 CMA supports channelization down to DS-0. Each 8-port channelized DS-1/E-1 CMA supports 64 channel groups. This MDA is supported on the 7750 SR-7/12 and 7750 SR-c4/c12 platforms. This CMA is supported on the 7750 SR-c4/c12 platforms.

Interfaces

2.1.8.2 Channelized DS-3/E-3 CMA

On the E-3 CMA, bit stuffing is not supported in G.751 framing mode. All of the 12 justification service bits and the four justification bits contain valid data on the transmitted signal. Incoming bitstreams should contain valid data in the 12 justification service bits and four justification bits, otherwise the link will not function.

This CMA is supported on the 7750 SR-c4/c12 platforms.

2.1.8.3 Channelized Any Service Any Port (ASAP) CHOC-3/STM-1

Each port for the channelized ASAP OC-3/STM-1 MDA supports channelization down to DS-0 and accepts one OC-3/STM-1 SFP small form factor pluggable (SFP) module. The same SFP optics used on Nokia’s SONET/SDH MDAs can be used on the channelized ASAP OC-3/STM-1 MDA.

Each channelized OC-3/STM-1 supports up to 512 channels with DS-0 timeslots with per-channel encapsulation configuration (for example, Frame Relay, PPP, cHDLC, ATM). DS-3 TDM channels can be further channelized to DS-1/E-1 channel groups. An E3 TDM channel cannot be channelized and can only be configured in clear channel operation. The MDA is based on a programmable data path architecture that

Issue: 01 3HE 11968 AAAC TQZZA 01 23

Page 24

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

enables enhanced Layer 1 and Layer 2 data path functionality, for example ATM TM features, MDA-based channel or port queuing, or multilink applications like Inverse ATM Multiplexing (IMA). This MDA is supported on the 7750 SR-7/12 and the 7750 SR-c4/c12 platforms.

2.1.8.4 Channelized OC-12/STM-4 ASAP MDAs

The channelized OC-12/STM-4 variant of the ASAP MDAs has features and channelization options similar to the 4-port channelized OC-3/STM-1 ASAP MDA.

DS-3 TDM channels can be further channelized to DS-1/E-1 channel groups. An E3 TDM channel cannot be channelized and can only be configured in clear channel operation. This MDA is supported on the 7750 SR-7/12 and the 7750 SR-c4/c12 platforms.

2.1.8.5 Channelized DS-3/E-3 ASAP MDA (4-Port)

The 4-port MDA provides four ports configurable as DS-3 or E-3. The MDA has eight (8) 1.0/2.3 connectors and accepts up to eight (8) DS-3/E-3 coax patch cables.

Each physical DS-3 connection can support a full clear-channel DS-3, or it can be channelized into independent DS-1/E-1 data channels. Each DS-1/E-1 channel can then be further channelized down to DS-0s. All DS-0 channels within a DS-3 port must be configured for the same channel speed.: 56 kb/s or 64 kb/s. The 56 kb/s speed value is only supported on DS-1 channels (ESF and SF framing) and not on E-1 (G.704) channels. Also, 56 kb/s channels cannot be part of a bundle. E-3 ports do not support channelization, only clear channel operation. This MDA is supported on the 7750 SR-7/12 and the 7750 SR-c4/c12 platforms. This MDA is supported on the 7750 SR-7/12 and the 7750 SR-c4/c12 platforms.

2.1.8.6 Channelized DS-3/E-3 ASAP MDA (12-Port)

The 12-port MDA provides 12 ports configurable as DS-3 or E-3. The MDA has 24

1.0/2.3 connectors and accepts up to 24 DS-3/E-3 coax patch cables.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 25

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

E-1 (G.704) channels. Also, 56 kb/s channels cannot be part of a bundle. E-3 ports do not support channelization, only clear channel operation. This MDA is supported on the 7750 SR-7/12 and the 7750 SR-c4/c12 platforms.

2.1.8.7 Channelized OC-3/STM-1 Circuit Emulation Services (CES) CMA and MDA

The channelized OC-3/STM-1/OC-12/STM-4 CES MDAs (c1-choc3-ces-sfp / m1choc3-ces-sfp, m4-choc3-ces-sfp, m1-choc12-ces-sfp) provide an industry leading consolidation for DS-1, E-1 and n*64 kb/s for CES.

The channelized OC-3/STM-1/OC-12/STM-4 CES CMA/MDAs support CES. Circuit emulation services are interoperable with the existing 7705 SAR and 7250 SAS circuit emulation services. They are also interoperable with the 1850 TSS-5 circuit emulation services.

Two modes of circuit emulation are supported: unstructured and structured. Unstructured mode is supported for DS-1 and E-1 channels as per RFC4553 (SAToP). Structured mode is supported for n*64 kb/s circuits as per RFC 5086,

Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN). In addition, DS-1, E-1 and n*64 kb/s circuits are also supported as per MEF8, Circuit Emulation Services over Ethernet (CESoETH) (Oct 2004). TDM circuits are optionally encapsulated in MPLS or

Ethernet as per the applicable standards.

Interfaces

All channels on the CES CMA/MDA are supported as circuits to be emulated across the packet network. This includes DS-1, E-1 and n*64 kb/s channels. Structure agnostic mode is supported for DS-1 and E-1 channels. Structure aware mode is supported for n*64 kb/s channel groups in DS-1 and E-1 carriers. N*64 kb/s circuit emulation supports basic and Channel Associated Signaling (CAS) options. CAS configuration must be identical for all channel groups on a given DS-1 or E-1.

Circuits encapsulated in MPLS use circuit pipes (Cpipes) to connect to the far end circuit. Cpipes support either SAP-spoke SDP or SAP-SAP connections.

Circuits encapsulated in Ethernet can be selected as a SAP in Epipes. Circuits encapsulated in Ethernet can be either SAP-spoke SDP or SAP-SAP connections for all valid Epipe SAPs. An EC-ID and far-end destination MAC address must be configured for each circuit.

Issue: 01 3HE 11968 AAAC TQZZA 01 25

Page 26

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Each OC-3/STM-1 port can be independently configured to be loop-timed or nodetimed. Each OC-3/STM-1 port can be configured to be a timing source for the node. Each DS-1 or E-1 channel can be independently configured to be loop-timed, nodetimed, adaptive-timed, or differential-timed. One adaptive timed circuit is supported per CMA or MDA. The CES circuit configured for adaptive timing can be configured to be a timing source for the node. This is required to distribute network timing to network elements which only have packet connectivity to network.

On the 7750 SR-c12 CES CMA, a BITS port is also provided. The BITS port can be configured as one reference sources (ref1, ref2) in the system timing subsystem. These MDAs are supported on the 7750 SR-7/12 and the 7750 SR-c4/c12 platforms.

2.1.8.8 Network Interconnections

Nokia routers can fill the needs of smaller service providers as well as the more remote point of presence (PoPs) locations for larger service providers. To support the use of lower speed links as network links in the likelihood that lower speed circuits are used as network or backbone links, the routers support a DS-1/E-1/DS-3/E-3 port (ASAP MDAs) or channel and an MLPPP bundle (ASAP MDAs) as network ports to transport and forwarding of all service types. This feature allows service providers to use lower speed circuits to interconnect small PoPs and CoS that do not require large amounts of network or backbone bandwidth.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 27

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2.2 Digital Diagnostics Monitoring

Some Nokia SFPs, XFPs, QSFPs, CFPs and the MSA DWDM transponder have the Digital Diagnostics Monitoring (DDM) capability where the transceiver module maintains information about its working status in device registers including:

• temperature

• supply voltage

• transmit (TX) bias current

• TX output power

• received (RX) optical power

For QSFPs and CFPs, DDM Temperature and Supply voltage is available only at the Module level as shown in Table 5.

Refer to the Statistics Collection section for details about the QSFP and CFP sample DDM and DDM Lane information.

Interfaces

For the QSFPs and CFPs, the number of lanes is indicated by DDM attribute “Number of Lanes: 4”.

Subsequently, each lane threshold and measured values are shown per lane.

If a given lane entry is not supported by the given QSFP or CFP specific model, then it is shown as “-“ in the entry.

A sample QSFP and CFP lane information is provided below:

Transceiver Data Transceiver Type : QSFP+ Model Number : 3HE06485AAAA01 ALU IPUIBMY3AA TX Laser Wavelength: 1310 nm Diag Capable : yes Number of Lanes : 4 Connector Code : LC Vendor OUI : e4:25:e9 Manufacture date : 2012/02/02 Media : Ethernet Serial Number : 12050188 Part Number : DF40GELR411102A Optical Compliance : 40GBASE-LR4 Link Length support: 10km for SMF =============================================================================== Transceiver Digital Diagnostic Monitoring (DDM) ===============================================================================

------------------------------------------------------------------------------Temperature (C) +35.6 +75.0 +70.0 +0.0 -5.0 Supply Voltage (V) 3.23 3.60 3.50 3.10 3.00 =============================================================================== =============================================================================== Transceiver Lane Digital Diagnostic Monitoring (DDM)

Value High Alarm High Warn Low Warn Low Alarm

Issue: 01 3HE 11968 AAAC TQZZA 01 27

Page 28

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

===============================================================================

High Alarm High Warn Low Warn Low Alarm Lane Tx Bias Current (mA) 78.0 75.0 25.0 20.0 Lane Rx Optical Pwr (avg dBm) 2.30 2.00 -11.02 -13.01

------------------------------------------------------------------------------Lane ID Temp(C)/Alm Tx Bias(mA)/Alm Tx Pwr(dBm)/Alm Rx Pwr(dBm)/Alm

-------------------------------------------------------------------------------

1 - 43.5 - 0.42 2 - 46.7 - -0.38 3 - 37.3 - 0.55 4 - 42.0 - -0.52

===============================================================================

Transceiver Type : CFP Model Number : 3HE04821ABAA01 ALU IPUIBHJDAA TX Laser Wavelength: 1294 nm Diag Capable : yes Number of Lanes : 4 Connector Code : LC Vendor OUI : 00:90:65 Manufacture date : 2011/02/11 Media : Ethernet Serial Number : C22CQYR Part Number : FTLC1181RDNL-A5 Optical Compliance : 100GBASE-LR4 Link Length support: 10km for SMF =============================================================================== Transceiver Digital Diagnostic Monitoring (DDM) ===============================================================================

Value High Alarm High Warn Low Warn Low Alarm

------------------------------------------------------------------------------Temperature (C) +48.2 +70.0 +68.0 +2.0 +0.0 Supply Voltage (V) 3.24 3.46 3.43 3.17 3.13 =============================================================================== =============================================================================== Transceiver Lane Digital Diagnostic Monitoring (DDM) ===============================================================================

High Alarm High Warn Low Warn Low Alarm

------------------------------------------------------------------------------Lane Temperature (C) +55.0 +53.0 +27.0 +25.0 Lane Tx Bias Current (mA) 120.0 115.0 35.0 30.0 Lane Tx Output Power (dBm) 4.50 4.00 -3.80 -4.30 Lane Rx Optical Pwr (avg dBm) 4.50 4.00 -13.00 -16.00

------------------------------------------------------------------------------Lane ID Temp(C)/Alm Tx Bias(mA)/Alm Tx Pwr(dBm)/Alm Rx Pwr(dBm)/Alm

-------------------------------------------------------------------------------

1 +47.6 59.2 0.30 -10.67 2 +43.1 64.2 0.27 -10.31 3 +47.7 56.2 0.38 -10.58 4 +51.1 60.1 0.46 -10.37

===============================================================================

The transceiver is programmed with warning and alarm thresholds for low and high conditions that can generate system events. These thresholds are programmed by the transceiver manufacturer.

There are no CLI commands required for DDM operations, however, the show>port port-id detail command displays DDM information in the Transceiver Digital Diagnostics Monitoring output section.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 29

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

DDM information is populated into the router’s MIBs, so the DDM data can be retrieved by Network Management using SNMP. Also, RMON threshold monitoring can be configured for the DDM MIB variables to set custom event thresholds if the factory-programmed thresholds are not at the desired levels.

The following are potential uses of the DDM data:

• Optics degradation monitoring — With the information returned by the DDMcapable optics module, degradation in optical performance can be monitored and trigger events based on custom or the factory-programmed warning and alarm thresholds.

• Link/router fault isolation — With the information returned by the DDM-capable optics module, any optical problem affecting a port can be quickly identified or eliminated as the potential problem source.

Supported real-time DDM features are summarized in Table 4.

Table 4 Real-Time DDM Information

Interfaces

Parameter User Units SFP/XFP

Units

Temperature Celsius C Supported Supported Supported

Supply Voltage

TX Bias Current

TX Output Power

RX Received Optical Power4

AUX1 parameter dependent

AUX2 parameter dependent

Volts µV Supported Supported Not supported

mA µA Supported Supported Supported

dBm (converted from mW) mW Supported Supported Supported

dBm (converted from dBm) (Avg Rx Power or OMA)

(embedded in transceiver)

mW Supported Supported Supported

- Not supported Supported Not supported

SFP XFP MSA DWDM

The factory-programmed DDM alarms and warnings that are supported are summarized in Table 5.

Issue: 01 3HE 11968 AAAC TQZZA 01 29

Page 30

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Table 5 DDM Alarms and Warnings

Parameter SFP/XFP Units SFP XFP Required? MSA DWDM

Temperature

- High Alarm

- Low Alarm

- High Warning

- Low Warning

Supply Voltage

- High Alarm

- Low Alarm

- High Warning

- Low Warning

TX Bias Current

- High Alarm

- Low Alarm

- High Warning

- Low Warning

TX Output Power

- High Alarm

- Low Alarm

- High Warning

- Low Warning

C Yes Yes Yes Yes

µV YesYesYesNo

µA YesYesYesYes

mW YesYesYesYes

RX Optical Power

- High Alarm

- Low Alarm

- High Warning

- Low Warning

AUX1

- High Alarm

- Low Alarm

- High Warning

- Low Warning

AUX2

- High Alarm

- Low Alarm

- High Warning

- Low Warning

mW YesYesYesYes

parameter dependent (embedded in transceiver)

3HE 11968 AAAC TQZZA 01 Issue: 01

No Yes Yes No

Page 31

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2.2.1 SFPs and XFPs

The availability of the DDM real-time information and the warning and alarm status is based on the transceiver. It may or may not indicate that DDM is supported. Although some Nokia SFPs support DDM, Nokia has not required DDM support in releases prior to Release 6.0. Non-DDM and DDM-supported SFPs are distinguished by a specific ICS value.

For SFPs that do not indicate DDM support in the ICS value, DDM data is available although the accuracy of the information has not been validated or verified.

For non-Nokia transceivers, DDM information may be displayed, but Nokia is not responsible for formatting, accuracy, and so on.

2.2.2 Statistics Collection

Interfaces

The DDM information and warnings and alarms are collected at one minute intervals, so the minimum resolution for any DDM events when correlating with other system events is one minute.

In the Transceiver Digital Diagnostic Monitoring section of the show port port-id detail command output:

• if the present measured value is higher than either or both of the High Alarm and High Warn thresholds, an exclamation mark “!” displays along with the threshold value

• if the present measured value is lower than either or both of the Low Alarm and Low Warn thresholds, an exclamation mark “!” displays along with the threshold value

B:SR7-101# show port 2/1/6 detail

......

=============================================================================== Transceiver Digital Diagnostic Monitoring (DDM), Internally Calibrated ===============================================================================

Value High Alarm High Warn Low Warn Low Alarm

------------------------------------------------------------------------------Temperature (C) +33.0+98.0 +88.0 -43.0-45.0 Supply Voltage (V) 3.31 4.12 3.60 3.00 2.80 Tx Bias Current (mA)5.7 60.0 50.00.1 0.0 Tx Output Power (dBm) -5.45 0.00 -2.00 -10.50 -12.50 Rx Optical Power (avg dBm) -0.65-3.00! -4.00! -19.51 -20.51 ===============================================================================

Issue: 01 3HE 11968 AAAC TQZZA 01 31

Page 32

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

2.3 Ports

2.3.1 Port Types

Before a port can be configured, the slot must be provisioned with a card type and MDA type.

Nokia routers support the following port types:

• Ethernet — Supported Ethernet port types include:

− Fast Ethernet (10/100BASE-T)

− Gb Ethernet (1GbE, 1000BASE-T)

− 10 Gb Ethernet (10GbE, 10GBASE-X)

− 40 Gb Ethernet (40GbE)

− 100 Gb Ethernet (100GbE)

Router ports must be configured as either access, hybrid, or network. The default is network.

− Access ports — Configured for customer facing traffic on which services are configured. If a Service Access Port (SAP) is to be configured on the port or channel, it must be configured as an access port or channel. When a port is configured for access mode, the appropriate encapsulation type must be configured to distinguish the services on the port or channel. Once a port has been configured for access mode, one or more services can be configured on the port or channel depending on the encapsulation value.

− Network ports — Configured for network-facing traffic. These ports participate in the service provider transport or infrastructure network. Dot1q is supported on network ports.

− Hybrid ports — Configured for access and network-facing traffic. While the default mode of an Ethernet port remains network, the mode of a port cannot be changed between the access, network, and hybrid values unless the port is shut down and the configured SAPs or interfaces are deleted. Hybrid ports allow a single port to operate in both access and network modes. The MTU of a port in hybrid mode is the same as in network mode, except for the 10/100 MDA. The default encapsulation for hybrid port mode is dot1q; it also supports QinQ encapsulation on the port level. Null hybrid port mode is not supported.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 33

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Once the port is changed to hybrid, the default MTU of the port is changed to match the value of 9212 bytes currently used in network mode (higher than an access port), ensuring that both SAP and network VLANs can be accommodated. The only exception is when the port is a 10/100 Fast Ethernet. In those cases, the MTU in hybrid mode is set to 1522 bytes, which corresponds to the default access MTU with QinQ, which is larger than the network dot1q MTU or access dot1q MTU for this type of Ethernet port. The configuration of all parameters in access and network contexts continues to be done within the port using the same CLI hierarchy as in existing implementation. The difference is that a port configured in mode hybrid allows both ingress and egress contexts to be configured concurrently.

An Ethernet port configured in hybrid mode can have two values of encapsulation type: dot1q and QinQ. The NULL value is not supported since a single SAP is allowed, and can be achieved by configuring the port in the access mode, or a single network IP interface is allowed, which can be achieved by configuring the port in network mode. Hybrid mode can be enabled on a LAG port when the port is part of a single chassis LAG configuration. When the port is part of a multi-chassis LAG configuration, it can only be configured to access mode since MC-LAG is not supported on a network port and consequently is not supported on a hybrid port. The same restriction applies to a port that is part of an MC-Ring configuration.

Interfaces

For a hybrid port, the amount of the allocated port buffers in each of ingress and egress is split equally between network and access contexts using the following config>port>hybrid-buffer-allocation>ing-weight access

access-weight [0 to 100] network network-weight [0 to 100] and config>port>hybrid-buffer-allocation>egr-weight access access-

weight [0 to 100] network network-weight [0 to 100] commands. Adapting the terminology in buffer-pools, the port’s access active bandwidth

and network active bandwidth in each ingress and egress are derived as follows (egress formulas shown only):

• total-hybrid-port-egress-weights = access-weight + network-weight

• hybrid-port-access-egress-factor = access-weight / total-hybrid-portegress-weights

• hybrid-port-network-egress-factor = network-weight / total-hybrid-portegress-weights

• port-access-active-egress-bandwidth = port-active-egress-bandwidth x

• hybrid-port-access-egress-factor

• port-network-active-egress-bandwidth = port-active-egress-bandwidth x

• hybrid-port-network-egress-factor

Issue: 01 3HE 11968 AAAC TQZZA 01 33

Page 34

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

When a named pool policy is applied to the hybrid port’s MDA or to the hybrid port, the port’s fair share of total buffers available to the MDA is split into three parts: default pools, named pools local to the port, and named pools on the ports MDA. This allocation can be altered by entering the corresponding values in the port-allocation-weights parameter.

• WAN PHY — 10 G Ethernet ports can be configured in WAN PHY mode (using the ethernet xgig config). When configuring the port to be in WAN mode, you can change certain SONET/SDH parameters to reflect the SONET/SDH requirements for this port.

• SONET-SDH and TDM — Supported SONET-SDH and TDM port types include:

− n*DS-0 inside DS-1/E-1

− DS-1/E-1DS-3/E-3

− OC3/STM-1

− OC12/STM-4

− OC48/STM-16

− OC192/STM-64 SONET/SDH

− OC768/STM-256

A SONET/SDH port/path or a TDM port/channel can be configured with the following encapsulations depending on the MDA type:

− Frame Relay

− PPP

− cHDLC

• ATM — Some MDAs support ATM encapsulation on SONET/SDH and TDM ports. The ATM cell format and can be configured for either UNI or NNI cell format. The format is configurable on a SONET/SDH or TDM port/channel path basis. All VCs on a path, channel or port must use the same cell format. The ATM cell mapping can also be configured on per-interface basis for either Direct or PLCP on some MDAs (for example ASAP MDA).

• Several Media Dependent Adapters (MDAs) support channelization down to the DS-0 level. ATM, Frame Relay, PPP, and cHDLC are supported encapsulations on channelized ports.

• Link Aggregation (LAG) — LAG can be used to group multiple ports into one logical link. The aggregation of multiple physical links allows for load sharing and offers seamless redundancy. If one of the links fails, traffic is redistributed over the remaining links.

• Multilink Bundles — A multilink bundle is a collection of channels on channelized ports that physically reside on the same MDA. Multilink bundles are used by providers who offer either bandwidth-on-demand services or fractional bandwidth services (fraction of a DS-3/E-3 for example). Multilink bundles are supported over PPP channels (MLPPP) and ATM channels (IMA).

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 35

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

• APS — Automatic Protection Switching (APS) is a means to provide redundancy on SONET equipment to guard against linear unidirectional or bidirectional failures. The network elements (NEs) in a SONET/SDH network constantly monitor the health of the network. When a failure is detected, the network proceeds through a coordinated pre-defined sequence of steps to transfer (or switchover) live traffic to the backup facility (called protection facility.) This is done very quickly to minimize lost traffic. Traffic remains on the protection facility until the primary facility (called working facility) fault is cleared, at which time the traffic may optionally be reverted to the working facility.

• Bundle Protection Group (BPGRP) — A BPGRP is a collection of two bundles created on the APS Group port. Working bundle resides on the working circuit of the APS group, while protection bundle resides on the protection circuit of the APS group. APS protocol running on the circuits of the APS Group port monitors the health of the SONET/SDH line and based on it or administrative action moves user traffic from one bundle to another in the group as part of an APS switch.

• Cross connect adapter (CCA) — A CCA on a VSM module interconnects the egress forwarding path on the IOM directly to the ingress forwarding path. This eliminates the need for the physical port MAC, PHY, cable and other MDAspecific components producing a less costly and more reliable adapter.

Interfaces

• Optical Transport Network (OTN) — Including OTU2, OTU2e, and OTU3. OTU2 encapsulates 10-Gigabit Ethernet WAN and adds FEC (Forward Error Correction). OTU2e encapsulates 10-Gigabit Ethernet LAN and adds FEC (Forward Error Correction). OTU3 encapsulated OC768 and adds FEC.

2.3.2 Port Features

2.3.2.1 Port State and Operational State

There are two port attributes that are related and similar but have slightly different meanings: Port State and Operational State (or Operational Status).

The following descriptions are based on normal individual ports. Many of the same concepts apply to other objects that are modeled as ports in the router such as PPP/ IMA/MLFR multilink bundles or APS groups but the show output descriptions for these objects should be consulted for the details.

• Port State

− Displayed in port summaries such as show port or show port 1/1

− tmnxPortState in the TIMETRA-PORT-MIB

Issue: 01 3HE 11968 AAAC TQZZA 01 35

Page 36

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

− Values: None, Ghost, Down (linkDown), Link Up, Up

• Operational State

− Displayed in the show output of a specific port such as show port 2/1/3

− tmnxPortOperStatus in the TIMETRA-PORT-MIB

− Values: Up (inService), Down (outOfService)

The behavior of Port State and Operational State are different for a port with link protocols configured (Eth OAM, Eth CFM or LACP for Ethernet ports, LCP for PPP/ POS ports). A port with link protocols configured only transitions to the Up Port State when the physical link is up and all the configured protocols are up. A port with no link protocols configured transitions from Down to Link Up and then to Up immediately once the physical link layer is up.

The linkDown and linkUp log events (events 2004 and 2005 in the SNMP application group) are associated with transitions of the port Operational State. Note that these events map to the RFC 2863, The Interfaces Group MIB, (which obsoletes RFC 2233, The Interfaces Group MIB using SMIv2) linkDown and linkUp traps as mentioned in the SNMPv2-MIB.

An Operational State of Up indicates that the port is ready to transmit service traffic (the port is physically up and any configured link protocols are up). The relationship between port Operational State and Port State is shown in Table 6:

Table 6 Relationship of Port State and Oper State

Operational State (Oper State or Oper Status) (as displayed in “show port x/y/z”)

Port State (as displayed in the show port summary)

Up Up Up

Link Up (indicates the physical link is ready)

Down Down Down

For ports that have no link layer protocols configured

Up Down

For ports that have link layer protocols configured (PPP, LACP, 802.3ah EFM, 802.1ag Eth-CFM)

2.3.2.2 802.1x Network Access Control

Nokia routers support network access control of client devices (PCs, STBs, and so on) on an Ethernet network using the IEEE. 802.1x standard. 802.1x is known as Extensible Authentication Protocol (EAP) over a LAN network or EAPOL.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 37

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2.3.2.2.1 802.1x Modes

Nokia routers support port-based network access control for Ethernet ports only. Every Ethernet port can be configured to operate in one of three different operation modes, controlled by the port-control parameter:

• force-auth — Disables 802.1x authentication and causes the port to transition to the authorized state without requiring any authentication exchange. The port transmits and receives normal traffic without requiring 802.1x-based host authentication. This is the default setting.

• force-unauth — Causes the port to remain in the unauthorized state, ignoring all attempts by the hosts to authenticate. The switch cannot provide authentication services to the host through the interface.

• auto — Enables 802.1x authentication. The port starts in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. Both the router and the host can initiate an authentication procedure as described below. The port remains in unauthorized state (no traffic except EAPOL frames is allowed) until the first client is authenticated successfully. After this, traffic is allowed on the port for all connected hosts.

Interfaces

2.3.2.2.2 802.1x Basics

The IEEE 802.1x standard defines three participants in an authentication conversation (see Figure 1 which shows an example with the 7450 ESS).

• The supplicant — This is the end-user device that requests access to the network.

• The authenticator — Controls access to the network. Both the supplicant and the authenticator are referred to as Port Authentication Entities (PAEs).

• The authentication server — Performs the actual processing of the user information.

Figure 1 802.1x Architecture

Client 7450 ESS RADIUS

Supplicant

EAPOL RADIUS

Authenticator

Authentication

Authenticator

Server

OSSG038

Issue: 01 3HE 11968 AAAC TQZZA 01 37

Page 38

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

The authentication exchange is carried out between the supplicant and the authentication server, the authenticator acts only as a bridge. The communication between the supplicant and the authenticator is done through the Extended Authentication Protocol (EAP) over LANs (EAPOL). On the back end, the communication between the authenticator and the authentication server is done with the RADIUS protocol. The authenticator is thus a RADIUS client, and the authentication server a RADIUS server.

The messages involved in the authentication procedure are shown in Figure 2. The router initiates the procedure when the Ethernet port becomes operationally up, by sending a special PDU called EAP-Request/ID to the client. The client can also initiate the exchange by sending an EAPOL-start PDU, if it doesn't receive the EAPRequest/ID frame during bootup. The client responds on the EAP-Request/ID with a EAP-Response/ID frame, containing its identity (typically username + password).

Figure 2 802.1x Authentication Scenario

Client

EAPOL-Start

EAP-Request/ID

EAP-Response/ID

EAP-Request/OTP

EAP-Response/OTP

EAP-Success

EAP-Logoff

EAP-Request/ID

7450 ESS RADIUS

Authentication

Server

Port Unauthorized

Access Request

Access Challenge

Access Request

Access Accept

Port Authorized

Port Unauthorized

quiet-period

OSSG039

After receiving the EAP-Response/ID frame, the router will encapsulate the identity information into a RADIUS AccessRequest packet, and send it off to the configured RADIUS server.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 39

INTERFACE CONFIGURATION GUIDE

OSSG040-7750

Client

quiet-period

supplicanttimeout

transmitperiod

EAP-Request/ID

7750 SR

RADIUS

Authentication

Server

Client

Access Request

quiet-period

server-

timeout

max-auth-request

EAP-Request/ID

EAP-Response/ID

EAP-Failure

EAP-Request/ID

7750 SR

RADIUS

Authentication

Server

802.1x EAPOL Timers

802.1x RADIUS Timers

Port Unauthorized

RELEASE 15.0.R5

The RADIUS server checks the supplied credentials, and if approved will return an Access Accept message to the router. The router notifies the client with an EAPSuccess PDU and puts the port in authorized state.

2.3.2.2.3 802.1x Timers

The 802.1x authentication procedure is controlled by a number of configurable timers and scalars. There are two separate sets, one for the EAPOL message exchange and one for the RADIUS message exchange. See Figure 3 for an example of the timers on the 7750 SR.

Figure 3 802.1x EAPOL Timers (left) and RADIUS Timers (right)

Interfaces

• transit-period — Indicates how many seconds the Authenticator will listen for an EAP-Response/ID frame. If the timer expires, a new EAP-Request/ID frame will be sent and the timer restarted. The default value is 60. The range is 1 to 3600 seconds.

EAPOL timers:

• supplicant-timeout — This timer is started at the beginning of a new authentication procedure (transmission of first EAP-Request/ID frame). If the timer expires before an EAP-Response/ID frame is received, the 802.1x authentication session is considered as having failed. The default value is 30.

Issue: 01 3HE 11968 AAAC TQZZA 01 39

The range is 1 to 300.

Page 40

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

• quiet-period — Indicates number of seconds between authentication sessions It is started after logoff, after sending an EAP-Failure message or after expiry of the supplicant-timeout timer. The default value is 60. The range is 1 to 3600.

RADIUS timer and scaler:

• max-auth-req — Indicates the maximum number of times that the router will send an authentication request to the RADIUS server before the procedure is considered as having failed. The default value is value 2. The range is 1 to 10.

• server-timeout — Indicates how many seconds the authenticator will wait for a RADIUS response message. If the timer expires, the access request message is sent again, up to max-auth-req times. The default value is 60. The range is 1 to 3600 seconds.

The router can also be configured to periodically trigger the authentication procedure automatically. This is controlled by the enable re-authentication and reauth-period parameters. Reauth-period indicates the period in seconds (since the last time that the authorization state was confirmed) before a new authentication procedure is started. The range of reauth-period is 1 to 9000 seconds (the default is 3600 seconds, one hour). Note that the port stays in an authorized state during the reauthentication procedure.

2.3.2.2.4 802.1x Tunneling

Tunneling of untagged 802.1x frames received on a port is supported for both Epipe and VPLS service using either null or default SAPs (for example 1/1/1:*) when the port dot1x port-control is set to force-auth.

When tunneling is enabled on a port (using the command configure port port-id ethernet dot1x tunneling), untagged 802.1x frames are treated like user frames and are switched into Epipe or VPLS services which have a corresponding null SAP or default SAP on that port. In the case of a default SAP, it is possible that other nondefault SAPs are also present on the port. Untagged 802.1x frames received on other service types, or on network ports, are dropped.

When tunneling is required, it is expected that it is enabled on all ports into which

802.1x frames are to be received. The configuration of dot1x must be configured consistently across all ports in LAG as this is not enforced by the system.

Note that 802.1x frames are treated like user frames, that is, tunneled, by default when received on a spoke or mesh SDP.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 41

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2.3.2.2.5 802.1x Configuration and Limitations

Configuration of 802.1x network access control on the router consists of two parts:

• Generic parameters, which are configured under config>security>dot1x

• Port-specific parameters, which are configured under

config>port>ethernet>dot1x

801.x authentication:

• Provides access to the port for any device, even if only a single client has been authenticated.

• Can only be used to gain access to a pre-defined Service Access Point (SAP). It is not possible to dynamically select a service (such as a VPLS service) depending on the 802.1x authentication information.

• If 802.1x access control is enabled and a high rate of 802.1x frames are received on a port, that port will be blocked for a period of 5 minutes as a DoS protection mechanism.

Interfaces

2.3.2.3 MACsec

Media Access Control Security (MACsec) is an industry-standard security technology that provides secure communication for almost all types of traffic on Ethernet links. MACsec provides point-to-point and point-to-multipoint security on Ethernet links between directly-connected nodes or nodes connected via a Layer 2 cloud. It is capable of identifying and preventing most security threats, including:

• denial of service

• intrusion

• man-in-the-middle

• masquerading

• passive wiretapping

• playback attacks

MACsec is standardized in IEEE 802.1AE, and is a Layer 2 encryption. MACsec encrypts anything from the 802.1AE header to the end of the payload including

802.1Q. MACsec leaves the DMAC and SMAC in clear text.

Figure 4 shows the 802.1AE LAN-Mode structure.

Issue: 01 3HE 11968 AAAC TQZZA 01 41

Page 42

Interfaces

sw0118

211 4 8

octets octet octet

SLANTCIMACsec Ethertype PN

SecTAG

SCI (encoding

is optional)

octets octets

Figure 4 802.1 AE LAN-MODE

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Autheticated

802.1AE LAN-MODE

0x88e5

MISEec Ether

Type

802.1QDMAC SMAC

TCI/AN SL

Excrypted

Payload

PAC KET

NUMBER

The forwarding on a MACSec packet is performed using the destination MAC address, which is in clear text.

2.3.2.3.1 MAC Sec 802.1AE Header (SecTAG)

The 802.1AE header includes a security TAG which includes:

• the association number within the channel

• the packet number to provide a unique initialization vector for encryption and authentication algorithms as well as protection against replay attack

• an optional LAN-Wide secure channel identifier

The security TAG (SecTAG) is identified by the MACsec EtherType and conveys the following:

ICV CRCETYPE802.1AE Header

SCI (optional)

sw0126

• TAG Control Information (TCI)

• Association Number (AN)

• Short Length (SL)

• Packet Number (PN)

• Optionally-encoded Secure Channel Identifier (SCI)

Figure 5 shows the format of the SecTAG.

Figure 5 SecTAG Format

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 43

INTERFACE CONFIGURATION GUIDE

sw0119

Excrypted

Payload ICV CRCETYPE802.1AE Header

MISEec Ether

Type

TCI/AN SL

PAC KET

NUMBER

SCI (optional)

802.1QDMAC SMAC

Excrypted

Autheticated

802.1AE LAN-MODE, VLAN Encrypted

802.1AE WAN-MODE, VLAN in clear

Payload

0x88e5

ICV CRCETYPE802.1AE Header

MISEec Ether

Type

TCI/AN SL

PAC KET

NUMBER

SCI (optional)

802.1QDMAC SMAC

RELEASE 15.0.R5

2.3.2.3.2 MAC Sec encryption mode

There are two main modes of encryption in MACSec:

• VLAN in clear text (WAN Mode)

• VLAN encrypted

802.1AE dictates that the 802.1Q VLAN needs to be encrypted. Some vendors give the option of configuring the MACSec on a port with VLAN in clear text.

SR OS supports both modes. On the 7750 SR, 7450 ESS, and 7950 XRS, 1/10 Gig cards support both mode of operation.

Figure 6 shows the VLAN encrypted and VLAN in clear.

Figure 6 802.1 AE LAN/WAN Modes and VLAN Encrypted/Clear

Interfaces

2.3.2.3.3 MACSec Key management modes

Table 7 MACsec Key Management Modes

Keying Explanation SR OS Support Where Used

Static SAK Manually configure

Issue: 01 3HE 11968 AAAC TQZZA 01 43

There are four-main, key management modes in MACSec. Table 7 describes these management modes.

each node with a static SAK, SAM, or CLI

NA Switch to switch

Page 44

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Table 7 MACsec Key Management Modes (Continued)

Keying Explanation SR OS Support Where Used

Static CAK PRE SHARED KEY Uses a dynamic

MACSec Key Management (MKA) and uses a configured pre shared key to drive the CAK. The CAK encrypts the SAK between two peers and authenticates the peers

Dynamic CAK EAP Authentication

Dynamic CAK MSK distribution via RADIUS and EAP-TLS

Uses a dynamic MKA and uses a EAP MSK (Master System Key) to drive the CAK. The CAK encrypts the SAK between two peers and authenticates the peers

MSKs are stored in the Radius server and distributed to the hosts via EAP-TLS. This is usually used in the access networks where there are a large number of hosts using MACSec and connecting to an access switch. MKA uses MSK to drive the CAK. The CAK encrypts the SAK between 2 peers and authenticates the peers

Supported Switch to switch

Not Supported Switch to switch

Not Supported Host to switch

2.3.2.3.4 MACsec Terminology

Figure 7 illustrates some of the main concepts used in MACSec for the static-CAK

scenario.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 45

INTERFACE CONFIGURATION GUIDE

sw0120

MKA

Node 2 CA1 Port 1/1/1 security zone 1 SecY 1 TxSC1 TxSA1 (Inactive) TxSA2 (Active) RxSC1 RxSA1 RxSA2

Node 1 CA1 Port 1/1/1 security zone 1 SecY 1 TxSC1 TxSA1 (Active) TxSA2 (Inactive) RxSC1 RxSA1 RxSA2

SC1-node1

SCI-node2

CA1

RELEASE 15.0.R5

Figure 7 MACsec Concepts for Static-CAK

Table 8 describes the MACsec terminology.

Table 8 MACsec Terms

Interfaces

MACsec Term Description

CA: Connectivity Association

A security relationship, established and maintained by key agreement protocols (MKA), that comprises a fully-connected subset of the service access points in stations attached to a single LAN that are to be supported by MACsec.

MKA: MACSec Key Agreement Protocol

Control protocol between MACSec peers, which is used for peer aliveness and encryption key distribution. MACsec Key Agreement is responsible for discovering, authenticating, and authorizing the potential participants in a CA.

SecY: MAC Security Entity

Operates the MAC Security protocol within a system. Manages and identifies the SC and the corresponding active SA.

SC: Security Channel SC provides a unidirectional point-to-point or point-to-multipoint communication.

Each SC contains a succession of SAs and each SC has a different SAK.

Issue: 01 3HE 11968 AAAC TQZZA 01 45

Page 46

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Table 8 MACsec Terms (Continued)

MACsec Term Description

SA: Security Association In the cases of SR OS 2 SA per SC, each with a different SAK, each SC comprises

a succession of SAs. Each SA is identified by the SC identifier, concatenated with a two-bit association number. The Secure Association Identifier (SAI), thus created, allows the receiving SecY to identify the SA, and thus the SAK used to decrypt and authenticate the received frame. The AN, and hence the SAI, is only unique for the SAs that can be used or recorded by participating SecYs at any instant.

MACsec Key Agreement is responsible for creating and distributing SAKs to each of the SecYs in a CA. This key creation and distribution is independent of the cryptographic operation of each of the SecYs. The decision to replace one SA with its successor is made by the SecY that transmits using the SC, after MACsec Key Agreement has informed it that all the other SecYs are prepared to receive using that SA. No notification, other than receipt of a secured frame with a different SAI is sent to the receiver. A SecY must always be capable of storing SAKs for two SAs for each inbound SC, and of swapping from one SA to another without notice. Certain LAN technologies can reorder frames of different priority, so reception of frames on a single SC can use interleaved SA.

SAK: Security Association Key

2.3.2.3.5 MACsec Static CAK

SAK is the encryption key used to encrypt the datapath of MACSec.

MACsec uses SAs for encryption of packets. SA is a security relationship that provides security guarantees for frames transmitted from one member of a CA to the others. Each SA contains a single secret key (SAK) where the cryptographic operations used to encrypt the datapath PDUs.

SAK is the secret key used by an SA to encrypt the channel.

When enabled, MACsec uses a static CAK security mode. Two security keys, a connectivity association key (CAK) that secures control plane traffic and a randomlygenerated secure association key (SAK) that secures data plane traffic are used to secure the point-to-point or point-to-multipoint Ethernet link. Both keys are regularly exchanged between both devices on each end of the Ethernet link to ensure link security.

Figure 8 illustrates MACsec generating the CAK.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 47

INTERFACE CONFIGURATION GUIDE

sw0121

MKA Protocol

RADIUS

EAP Authentication

Server

MKPDU: MACsec Key Agreement Protocol Data Unit

EAP

Supplicant

PSK:

CAK Value: 128 or 256 CKN Value: 16 Char

PSK:

CAK Value: CKN Value:

Key Server

RNG

SAK:

MKPDU MKPDUMKPDUControl Plane: Using Kek, ICK

Data Plane: Using SAKs Encrypted DATA Encrypted DATA

EAPoL for Authentication

CAK: derived from EAP or PSK

KEK: Key encryption

key to wrap SAK

Encrypt wrap SAK Integrity MKPDU

ICK: Integrity check

value (ICV) key

oror

EAP

Authenticator

RELEASE 15.0.R5

Figure 8 MACsec Generating the CAK

Interfaces

The node initially needs to secure the control plain communication to distribute the SAKs between two or more members of a CA domain.

The securing of control plain is done via CAK. To generate the CAK, there are two main methods:

• EAPoL (SR OS does not support EAPoL)

• pre shared key (CAK and CKN values are configured manually via CLI). The following CAK and CKN rules apply.

− CAK is a 32 hexadecimal characters for 128-bit key and 64 hexadecimal characters for 256-bit key depending on which algorithm is used for control plain encryption (for example, aes-128-cmac or aes-256-cmac).

− CKN is a 32 octets char (64 hex) and it is the connectivity association key name which identifies the CAK. This allows each of the MKA participants to select which CAK to use to process a received MKPDU. MKA places no restriction on the format of the CKN, except that it must comprise an integral number of octets, between 1 and 32 (inclusive), and that all potential members of the CA use the same CKN.

− CKN and CAK must match on peers to create a MACsec Secure CA.

Issue: 01 3HE 11968 AAAC TQZZA 01 47

Figure 9 illustrates the MACsec control plane authentication and encryption.

Page 48

Interfaces

sw0122

MKA Protocol

RADIUS

EAP Authentication

Server

MKPDU: MACsec Key Agreement Protocol Data Unit

EAP

Supplicant

EAP

Authenticator

PSK:

CAK Value: 128 or 256 CKN Value: 16 Char

PSK:

CAK Value: CKN Value:

Key Server

RNG

SAK:

Datapath

security Association Key

MKPDU MKPDUMKPDU

EAPoL for Authentication

CAK:

derived from EAP or PSK

KEK: Key encryption

key to wrap SAK

Encrypt wrap SAK Integrity MKPDU

ICK: Integrity check

value (ICV) key

oror

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Figure 9 MACsec Control Plane

Once the CAK is generated, it can obtain two other keys. These keys are:

• KEK (Key Encryption Key) — used to wrap and encrypt the SAKs

• ICK (Integrity Connection Value (ICV) Key) — used to for integrity check of each MKPDU send between two CA

The key server then creates a SAK, that is shared with the CAs of the security domain, and that SAK secures all data traffic traversing the link. The key server will continue to periodically create and share a randomly-created SAK over the point-topoint link for as long as MACsec is enabled.

The SAK will be encrypted via the AES-CMAC, the KEK as encryption key, and ICK as integration key.

2.3.2.3.6 SAK Rollover

SR OS re-generates the SAK after the following events:

• when a new host has joined the CA domain and MKA hellos are received from this host

• when the sliding window is reaching the end of its 32-bit or 64-bit length

• when a new PSK is configured and a rollover of PSK has been executed

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 49

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2.3.2.3.7 MKA

Each peer operates the MACsec Key Agreement Protocol (MKA). Each node can operate multiple MKAs base on the number of CA that it belongs to. Each instance of MKA is protected by a distinct secure connectivity Association key (CAK), that allows each PAE to ensure that information for a given MKA instance is only accepted from other peer that also possess that CAK, and therefore identifying themselves as members or potential members of the same CA. See MACsec Static

CAK for a description of how the CAK identification is done via CKN.

2.3.2.3.8 Pre-shared Key

A peer may support the use of one or more pre-shared key (PSKs). An instance of MKA operates for each PSK that is administratively configured as active.

A pre-shared key may be created by NSP, or entered in CLI manually.

Interfaces

Each PSK is configured with two fields. The two fields are:

• CKN (connectivity association name)

• CAK value

The CAK name (CKN) is required to be different from that for existing keys and can be used to identify the key in subsequent management operations.

Each static CAK configuration can have two pre-shared key entries for rollover. The active PSK index dictates which CAK is being used for encrypting the MKA PDUs and the SAK.

NSP has additional functionality to roll over and configure the PSK. The rollover via NSP can be based on a configured timer.

2.3.2.3.9 MKA Hello Timer

MKA uses a member identifier (MI) to identify each node in the CA domain.

A participant proves liveness to each of its peers by including their MI, together with an acceptably-recent message number (MN), in an MKPDU.

Issue: 01 3HE 11968 AAAC TQZZA 01 49

Page 50

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

To avoid a new participant having to respond to each MKPDU from each partner as it is received, or trying to delay its reply until it is likely that MI MN tuples have been received from all potential partners, each participant maintains and advertises both a live peers list and a potential peers list. The live peers list includes all the peers that have included the participant's MI and a recent MN in a recent MKPDU. The potential peers list includes all the other peers that have transmitted an MKPDU that has been directly received by the participant or that were included in the Live Peers List of a MKPDU transmitted by a peer that has proved liveness. Peers are removed from each list when an interval of between MKA life time and MKA life time plus MKA Hello Time has elapsed since the participant's recent MN was transmitted. This time is sufficient to ensure that two or more MKPDUs will have been lost or delayed prior to the incorrect removal of a live peer.

Note: The specified use of the live and potential peer lists permits rapid removal of participants that are no longer active or attached to the LAN while reducing the number of MKPDUs transmitted during group formation. For example, a new participant will be admitted to an established group after receiving, then transmitting, one MKPDU.

Table 9 shows the MKA participant timer values used on SR OS.

Table 9 MKA Participant Timer Values

Timer Use Timeout

(parameter)

Per participant periodic transmission, initialized on each transmission on expiry

Per peer lifetime, initialized when adding to or refreshing the Potential Peers List or Live Peers List, expiry causes removal from the list

participant created or following receipt of an MKPDU, expiry causes participant to be deleted

Delay after last distributing a SAK, before the Key Server will distribute a fresh SAK following a change in the Live Peer List while the Potential Peer List is still not empty

MKA Hello Time or MKA Bounded Hello

Time

MKA Life Time 6.0Participant lifetime, initialized when

Timeout (parameter)

2.0

0.5

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 51

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2.3.2.3.10 MACsec Capability, Desire, and Encryption Offset

802.1x-2010 had identified two fields in the MKA PDU. Those fields are:

• MACsec Capability

•Desire

MACsec Capability signals weather MACsec is capable of integrity and confidentiality. Table 10 describes the four basic settings for MACsec Capability.

Table 10 MACsec Basic Settings

Setting Description

0 MACsec is not implemented

1 Integrity without confidentiality

2 The following are supported:

Interfaces

• Integrity without confidentiality

• Integrity and confidentiality with a confidentiality offset of 0

Note:

1. SR OS supports (3) Integrity without confidentiality and Integrity and confidentiality with a confidentiality offset of 0, 30, or 50.

Encryption offset of 0, 30, or 50 starts from the byte after the SecTAG (802.1ae header). Ideally, the encryption offset should be configured for IPv4 (offset 30) and IPv6 (offset 50) to leave the IP header in the clear text. This will allow routers and switches to use the IP header for LAG or ECMP hashing.

2.3.2.3.11 Key Server

The participants, in a given MKA instance agree on a Key Server, are responsible for the following:

The following are supported:

• Integrity without confidentiality

• Integrity and confidentiality with a confidentiality offset of 0, 30, or 5

• deciding on the use of MACsec

Issue: 01 3HE 11968 AAAC TQZZA 01 51

Page 52

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

• cipher suite selection

• SAK generation and distribution

• SA assignment

• identifying the CA when two or more CAs merge

Each participant in an MKA instance uses the Key Server priority (an 8-bit integer) encoded in each MKPDU to agree on the Key Server. Each participant selects the live participant advertising the highest priority as its Key Server whenever the Live Peers List changes, provided that highest priority participant has not selected another as its Key Server or is unwilling to act as the Key Server. If a Key Server cannot be selected, SAKs are not distributed. In the event of a tie for highest priority Key Server, the member with the highest priority SCI is chosen. For consistency with other uses of the SCI's MAC address component as a priority, numerically lower values of the Key Server Priority and SCI are accorded the highest priority.

Note: With SCI, each SC is identified by an SCI that comprises a globally unique MAC address and a Port Identifier, unique within the system that has been allocated that address.

2.3.2.3.12 SA Limits and Network Design

Each MACsec device supports 64 TX-SAs and 64 RX-SAs. An SA (Security Association) is the key to encrypt or decrypt the data.

As per 802.1AE document, each SecY contains a SC. An SC is a unidirectional concept; for example, Rx-SC or Tx-SC. Each SC contains at least one SA for encryption on Tx-SC and decryption on Rx-SC. Also, for extra security, each SC should be able to roll over the SA and, as such, it is recommended for each SC to have two SAs for rollover purposes.

MACsec phy will be known as a MACsec security zone. Each MACsec security zone supports 64Tx-SAs and 64 RX-SAs. Assuming two SAs per SC for SA rollover, then each zone will support 32 RX-SC and 32 TX-SC.

Table 11 describes the port mapping to security zones.

Table 11 Port Mapping to Security Zone

MDA Ports in

Security Zone 1

12-port SFP+/SFP MDA-e Ports 1, 2, 3, 4 Ports 5, 6, 7, 8 Ports 9, 10, 11, 12Rx-SA = 64

Ports in Security Zone 2

Ports in Security Zone 3

SA Limit per Security Zone

Tx-SA = 64

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 53

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2.3.2.3.13 P2P (Switch to Switch) Topology

In a point-to-point topology, each router needs a single security zone and single TxSC for encryption and a single Rx-SC for decryption. Each SC has two SAs. In total for point-to-point topology, four SAs are needed, two RxSA for RxSC1 and two TXSA for TxSC1. See Figure 10.

Figure 10 Switch Point to Switch Point Topology

Interfaces

N1 is Server N1 Send SAK to every body

SAI: (11:22:33:44:55:01, 00. 01) SAI: (11:22:33:44:55:02, 00. 01)

Node 1 CA1 Port 1/1/1 security zone 1 SecY 1 TxSC1-----TxSA1, TxSA2 RxSC1-----RxSA1, RxSA2

CA1

Node 2 CA1 Port 1/1/1 security zone 1 SecY 1 TxSC1-----TxSA1-----TxSA2 RxSC1-----RxSA1-----RxSA2

2.3.2.3.14 P2MP (Switch to Switch) Topology

In a multipoint topology with N nodes, each node will need a single TxSC and N RxSC, one for each one of the peers. As such, 64 max RX-SA per security zone will translate to 32 Rx-SCs, which will break down to only 32 peers (for example, only 33 nodes in the multipoint topology per security zone, from each node perspective there is one TxSC and 32 RxSC).

sw0123

Issue: 01 3HE 11968 AAAC TQZZA 01 53

Page 54

Interfaces

Figure 11 Switch Multi-point to Switch Multi-point Topology

SAI: (11:22:33:44:55:02, 00, 01)

N1 is Server N1 Send SAK to every body

SAI: (11:22:33:44:55:01, 00, 01)

Node 1 CA1 SecY 1 TxSC1-----TxSA1, TxSA2 RxSC1-----RxSA1, RxSA2-peer1 RxSC2-----RxSA3, RxSA4-peer2 ... RxSC32-----RxSA63, RxSA64-peer32 RxSC33-----NA-peer33

SAI: (11:22:33:44:55:33, 00, 01)

Node 34 CA1 SecY 1 TxSC1-----TxSA1, TxSA2 RxSC1-----RxSA1, RxSA2-peer1 RxSC2-----RxSA3, RxSA4-peer2 ... RxSC32-----RxSA63, RxSA64-peer32 RxSC33-----NA-peer33

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Node 2 CA1 SecY 1 TxSC1-----TxSA1, TxSA2 RxSC1-----RxSA1, RxSA2-peer1 RxSC2-----RxSA3, RxSA4-peer2 ... RxSC32-----RxSA63, RxSA64-peer32 RxSC33-----NA-peer33

SAI: (11:22:33:44:55:03, 00, 01)

Node 3 CA1 SecY 1 TxSC1-----TxSA1, TxSA2 RxSC1-----RxSA1, RxSA2-peer1 RxSC2-----RxSA3, RxSA4-peer2 ... RxSC32-----RxSA63, RxSA64-peer32 RxSC33-----NA-peer33

sw0124

In Figure 11, when the 34rd node joins the multi-point topology, all other 33 nodes already part of this domain will not have any SAs to create an RxSC for this 34th node. However, the 34th node will have a TxSC and will accept 32 peers. The 34th node will start to transmit and encrypt the PDUs based on its TxSC. However, because all other nodes do not have a SC for this SAI, they will drop all Rx PDUs.

It is recommended to ensure that a multicast domain, for a single security zone, does not exceed 32 peers or the summation of all the nodes, in a security zone's CA domain, do not exceed 33. This is the same is if a security zone has four CAs, the summation of all nodes in the four CAs should be 33 or less.

2.3.2.3.15 SA Exhaustion Behavior

In SA Limits and Network Design, it was explained that the a security zone has 64 RxSAs and 64 TxSAs. Two RxSAs will be used for each RxSC for rollover purposes and two TxSAs will be used for TxSC for rollover purposes. This translates to 32 peers per security zone.

Under each port, a max-peer parameter can be configured. This parameter assigns how many peers are allowed on that port.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 55

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Note: The operator must ensure that the number of peers do not exceed the limit of maximum peers per security zone or maximum peers per port (for example, exceeds the port max-peer parameter).

If the maximum peer is exceeded, the peer connectivity will be random in case of a node failure or packet loss. Peers will join the CA randomly, on a first-come firstserved basis.

Caution: It is highly recommended that the operator ensures the maxpeer does not exceed per-security zone or port.

2.3.2.3.16 Clear Tag Mode

In most Layer 2 networks, MAC forwarding is done via destination MAC address. The

802.1AE standard dictates that any field after source and destination MAC address and after the SecTAG is required to be encrypted. This includes the 802.1Q tags. In some VLAN switching networks, it might be desired to leave the 802.1Q tag in clear text.

Interfaces

SR OS allows the configuration of 802.1Q tag, in clear text, by placing the 802.1Q tag before the SecTAG or encrypted, by placing it after the SecTAG.

Table 12 lists the MACsec encryption of 802.1Q tags when the clear-tag is

configured on SR OS.

Table 12 MACsec Encryption of 802.1Q Tags with Clear-tag Configured

Unencrypted format Clear-tag-mode

configuration

Single tag (dot1q) Single-tag DA, SA, TPID, VID, Etype DA, SA, TPID, VID, SecTAG

Single tag (dot1q) Double-tag DA, SA, TPID, VID, Etype DA, SA, TPID, VID, SecTAG

Double tag (q-in-q) Single-tag DA, SA, TPID1, VID1,

Double tag (q-in-q) Double-tag DA, SA, TPID1, VID1,

Pre-encryption (Tx) Pre-decryption (Rx)

DA, SA, TPID1, VID1,

IPID2, VID2, Etype

SecTAG

DA, SA, TPID1, VID1, IPID2, VID2, SecTAG

Issue: 01 3HE 11968 AAAC TQZZA 01 55

Page 56

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

2.3.2.3.17 802.1X Tunneling and Multihop MACsec

MACsec is an Ethernet packet and, as with any other Ethernet packet, can be forwarded through multiple switches via Layer 2 forwarding. The encryption and decryption of the packets will be performed via the 802.1x (MKA) capable ports.

To ensure that MKA is not terminated on any intermediate switch or router, the user can enable 802.1x tunneling on the corresponding port.

A sample check to see if tunneling is enabled, is provided below.

*A:SwSim28>config>port>ethernet>dot1x# info

---------------------------------------------tunneling

By enabling tunneling, the 802.1X MKA packets will be transit that port, without being terminated, as such MKA negotiation will not happen on a port that has 802.1X tunneling enabled.

2.3.2.3.18 EAPoL Destination Address

The MKA packets are transported over EAPoL with a multicast destination MAC address. At some point, it might be desired to have the MKA have a point-to-point connection to a peer node over a Layer 2 multihop cloud. In this case, the EAPoL destination MAC address can be set to the peer MAC address. This will force the MKA to traverse multiple nodes and establish an MKA session with the specific peer.

2.3.2.3.19 Mirroring Consideration

Mirroring is performed prior to the MACsec encryption engine. Therefore, if a port is MACsec-enabled and also, that same port is being mirrored, all the mirrored packets will be in clear text.

2.3.2.4 SONET/SDH Port Attributes

One OC-3/STM-1 port is supported on the CMA. One OC-3/STM-1 port is supported on the MDA. OC-3/STM-1 ports are also supported on TDM satellites. The ports can be configured for either SONET or SDH operation. SONET ports are configured for channelized OC-3 operation. SDH ports can be configured for channelized STM-1 operation.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 57

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

The port’s transmit clock rate can be node or loop timed. The port’s receive clock rate can be used as a synchronization source for the system. The Section Trace (C1) byte can be configured by the user to ensure proper physical cabling. The port can activate and deactivate local line and internal loopbacks.

All SONET/SDH line alarms are configurable to be either enabled (default) or disabled. Link hold timers can be configured in 100ms increments to control link up and link down indications. The line signal degradation bit error rate (ber-sd) threshold and the line signal failure bit error rate (ber-sf) threshold can be configured.

The CMAs, MDAs, and TDM satellite support all standard SR OC-3/STM-1 SFP optics including multi-mode, intermediate reach, and long reach. Single fiber mode is not supported.

The CMA contains 3 LEDs for power, status and link state of port #1. The MDA contains LEDs for power, status and one for each link state. The power LED is blue if power is connected and off if no power is present. The status LED is green when operationally up, amber when operationally down, off when administratively shutdown and blinking green during initialization. The link state LED is green when the link is established; amber when the link is down; and unlit when the port is shutdown.

Interfaces

When an Ethernet port is configured in WAN mode (xgig wan), you can change certain SONET/SDH parameters to reflect the SONET/SDH requirements for this port. See SONET/SDH Port Commands for more information.

2.3.2.5 SONET/SDH Path Attributes

Any CES path can only be configured to operate in access mode. Each path has a configurable text description. The SONET/SDH signal label byte (C2) is configurable. The SONET/SDH path trace string (J1) is configurable. Payload scrambling can not be enabled on CES paths. The valid SONET and SDH path configurations are shown in Table 13.

Table 13 Valid SONET and SDH Path Configurations

Framing Path Configuration Options

Per Physical Port

SDH STM1>AUG1>VC4>TUG3>TUG2>VC12>

E1 STM1>AUG1>VC3>TUG2>VC12>E1

SONET OC3>STS1 SPE>DS3>E1 —

Max Number of Paths Per Physical Port

63 E1 or 512 n*64 kb/s 63 E1

Max Number of Paths Per TDM Satellite Port

Issue: 01 3HE 11968 AAAC TQZZA 01 57

Page 58

Interfaces

INTERFACE CONFIGURATION GUIDE

Table 13 Valid SONET and SDH Path Configurations (Continued)

RELEASE 15.0.R5

Framing Path Configuration Options

Per Physical Port

SONET OC3>STS1 SPE>VT GROUP>VT1.5

SPE>DS1

SONET OC3>STS1 SPE>DS3 3 DS3 —

SONET OC3>STS1 SPE>DS3>DS1 84 DS1, 63 E1 or 512

SDH STM1>AUG1>VC4>TUG3>TUG2>TU11>

VC11>DS1 STM1>AUG1>VC3>TUG2>VC11>DS1

SDH STM1>AUG1>VC3>DS3>DS1 84 DS1, 63 E1 or 512

SDH STM1>AUG1>VC4>TUG3>VC3>E3

STM1>AUG1>VC3>E3

SDH STM1>AUG1>VC3>DS3 3 DS3 —

SDH STM1>AUG1>VC3>DS3>E1 3 DS3 —

Max Number of Paths Per Physical Port

84 DS1 or 512 n*64 kb/s 84 DS1

n*64 kb/s

84 DS1 or 512 n*64 kb/s 84 DS1

n*64 kb/s

3 E3 —

Max Number of Paths Per TDM Satellite Port

—

All SONET/SDH path alarms are configurable to be either enabled (the default) or disabled. The MTU size is configurable per path in the range of 512 to 2092. The path uses a default MTU size set to equal the largest possible CES packet size.

Load balancing options are not applicable to channelized CES paths.

When an Ethernet port is configured in WAN mode (xgig wan), you can change certain SONET/SDH parameters to reflect the SONET/SDH requirements for this port. See SONET/SDH Path Commands for details.

2.3.2.6 Multilink Frame Relay

MLFR is a bundling capability allowing users to spray FR frame fragments over multiple T1/E1 links. This allows a dynamic provisioning of additional bandwidth by adding incremental bandwidth between T1/E1 and DS3/E3. A MLFR bundle increases fault tolerance and improves QoS characteristics since one single large frame of low priority cannot block a higher priority frame.

A MLFR supports up to eight (8) member links and a maximum of 128 bundles with up to 336 T1/252 E1 members links can be configured per MDA. NxDS0 circuits or higher speed circuits are not supported.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 59

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

The MLFR implementation supports FRF.16.1 bundle link integrity protocol to verify serviceability of a member link.

2.3.2.6.1 MLFR Bundle Data Plane

FRF.16.1 reuses the UNI/NNI fragmentation procedures defined in FRF.12. Frames on all FR SAP on the MLFR bundle have the UNI/NNI fragmentation header added regardless if they are fragmented or not. A separate sequence number state machine is used for each FR SAP configured on the bundle. The fragmentation threshold is configurable in the range 128 to 512 bytes.

In order to provide priority based scheduling of the FR SAP fragments over the bundle links, the user configures a FR scheduling class for each FR SAP configured on the bundle. As in MC-MLPPP, four scheduling classes are supported.

A separate fragmentation context is used by each FR SAP. FR SAPs of the same scheduling class share the same egress FR scheduling class queue with fragments of each SAP packets stored contiguously. The fragments from each scheduling class queue are then sprayed over the member links. Furthermore, the user may select the option to not fragment but spray the FR frames with the fragmentation header included over the member links.

Interfaces

Received fragments over the member links are re-assembled on a per SAP basis to re-create the original FR frame.

A user is not allowed to add an FR SAP with FRF.12 e2e fragmentation enabled to an MLFR bundle. Conversely, the user cannot enable FRF.12 e2e fragmentation on an FR SAP configured on an MLFR bundle. If an FR frame with the e2e fragmentation header is received on a bundle, it is forwarded if the FR SAP is part of an Fpipe service. It will be discarded if the FR SAP is part of any other service.

Note that the operator must disable LMI before adding a link to an MLFR bundle. Also, the operator must shut down the bundle in order to change the value of the fragmentation threshold.

An FR SAP configured on an MLFR bundle can be part of a VLL, VPLS, IES, or VPRN service.

Issue: 01 3HE 11968 AAAC TQZZA 01 59

Page 60

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

2.3.2.6.2 MLFR Bundle Link Integrity Protocol

FRF.16.1 defines a MLFR Bundle Link Integrity Protocol which verifies the serviceability of a member link. If a problem is found on the member link the link integrity protocol will identify the problem, flag the link as unusable, and adjust the Bundle’s available bandwidth. For MLFR Bundles the link integrity protocol is always enabled.

For each member link of a bundle the link integrity protocol will do the following:

• Confirm frame processing capabilities of each member link.

• Verify membership of a link to a specific remote bundle.

• Report to the remote end of the member link the bundle to which the link belongs

• Detect loopbacks on the member link. This is always enabled on the 7750 SR. The near-end monitors the magic number Information Element (IE) sent by the far-end and if its value matches the one it transmitted in ten consecutive control messages, it sends a remove_link message to the far-end and brings the link down. The near-end will attempt to add the link until it succeeds.

• Estimate propagation delay on the member link. The differential delay is calculated as follows in the 7750 SR implementation. Every time the near-end sends an add_link or Hello message to the far-end, it includes the Timestamp Information Element (IE) with the local time the packet was sent. FRF16.1 standard requires that the remote equipment includes the timestamp IE and copies the received timestamp value unchanged if the sender included this IE. When the far-end node sends back the ACK for these messages, the near-end calculates the round trip time. The 7750 SR implementation maintains a history of the last “N” round-trip-times that were received. It takes the fastest of these samples for each member link to find out the member link with the fastest RTT. Then for each link it calculates the difference between the fastest links RTT, and the RTT for the current link. The user has the option to coordinate link removal between the local and remote equipment. Note, however, that in the SR 7750 implementation, the addition of a link will be hitless but the removing a link is not.

Specifically, the MLFR Bundle Link Integrity Protocol defines the following control messages:

• ADD_LINK

• ADD_LINK_ACK

• ADD_LINK_REJ

• HELLO

• HELLO_ACK

• REMOVE_LINK

• REMOVE_LINK_ACK

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 61

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

The control messages are encapsulated in a single-fragment frame where the C-bit, the B-bit, and the E-bit are all set. The details of the message format are given in FRF.16.1. Table 14 lists the user configured control parameters with values as specified in FRF.16.1.

Table 14 FRF.16.1 Values

Parameter Default Value Minimum Value Maximum Value

Timer T_HELLO 10 seconds 1 second 180 seconds

Timer T_ACK 4 seconds 1 second 10

Count N_MAX_RETRY 2 1 5

T_HELLO Timer - this timer controls the rate at which hello messages are sent. Following a period of T_HELLO duration, a HELLO message is transmitted onto the Bundle Link.

Interfaces

Note that T_HELLO Timer is also used, during the Bundle Link adding process, as an additional delay before re-sending an ADD_LINK message to the peer Bundle Link when this peer Bundle Link does not answer as expected.

T_ACK Timer - this timer defines the maximum period to wait for a response to any message sent onto the Bundle Link before attempting to retransmit a message onto the Bundle Link.

N_RETRY - this counter specifies the number of times a retransmission onto a Bundle Link will be attempted before an error is declared and the appropriate action taken.

2.3.2.7 FRF.12 End-to-End Fragmentation

The user enables FRF.12 e2e fragmentation on a per FR SAP basis. A fragmentation header is added between the standard Q.922 header and the payload. This header consists of a 2-byte Network Layer Protocol ID (NLPID) of value 0xB1 to indicate e2e fragmentation payload and a 2-byte containing the Beginning bit (B-bit), the End-bit (E-bit), the Control bit (C-bit), and the Sequence Number field.

Issue: 01 3HE 11968 AAAC TQZZA 01 61

Page 62

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

The following is the mode of operation for the fragmentation in the transmit direction of the FR SAP. Frames of all the FR SAP forwarding class queues are subject to fragmentation. The fragmentation header is, however, not included when the frame size is smaller than the user configured fragmentation size. The SAP transmits all fragments of a frame before sending the next full or fragmented frame. The fragmentation threshold is configurable in the range 128 to 512 bytes. In the receive direction, the SAP accepts a full frame interleaved with fragments of another frame to interoperate with other vendor implementations.

An FR SAP with FRF.12 e2e fragmentation enabled can be part of a VPLS service, an IES service, a VPRN service, an Ethernet VLL service, or an IP VLL service. This SAP cannot be part of a FR VLL service or an FRF.5 VLL service. However, fragmented frames received on such VLLs will be passed transparently as in current implementation.

2.3.2.7.1 SAP Fragment Interleaving Option

This option provides a different mode of operation for the fragmentation in the transmit direction of the FR SAP than in the default behavior of a FRF.12 end-to-end fragmentation. It allows for the interleaving of high-priority frames and fragments of low-priority frames.

When the interleave option is enabled, only frames of the FR SAP non expedited forwarding class queues are subject to fragmentation. The frames of the FR SAP expedited queues are interleaved, with no fragmentation header, among the fragmented frames. In effect, this provides a behavior like in MLPPP Link Fragment Interleaving (LFI). The receive direction of the FR SAP supports both modes of operation concurrently, for example, with and without fragment interleaving.

2.3.2.8 FRF.12 UNI/NNI Link Fragmentation

The user enables FRF.12 UNI/NNI link fragmentation on a per FR circuit basis. All FR SAPs configured on this circuit are subject to fragmentation. A fragmentation header is added on top of the standard Q.922 header. This header consists of 2 bytes containing the beginning bit (B-bit), the End-bit (E-bit), the Control bit (C-bit), and the sequence number field. The fragmentation header is included on frames of all SAPs regardless if the frame size is larger or not than the fragment size.

The FECN, BECN, and DE bits of all fragments of a given FR frame are set to the same value as the original frame. The FECN, BECN, and DE bits of a re-assembled frame are set to the logical OR of the corresponding bits on the constituent fragments.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 63

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

The operator must delete all configured FR SAPs on a port before enabling or disabling FRF.12 UNI/NNI on that port. Also, the user must shut down the port in order to change the value of the fragmentation threshold.

A FR SAP on a FR circuit with FRF.12 UNI/NNI fragmentation enabled can be part of a VLL, VPLS, IES, or VPRN service.

QoS for a link with FRF.12 UNI/NNI fragmentation is the same as for a MLFR bundle. The FR class queue parameters and its scheduling parameters are configured by applying an egress QoS profile to an FRF.12 UNI/NNI port. The FR scheduling class ingress re-assembly timeout is not applicable to a FRF.12 UNI/NNI port.

2.3.2.9 MLFR/FRF.12 Support of APS, BFD, and Mirroring Features

The following APS support is provided:

• Single-chassis APS is supported on a SONET/SDH port with FRF.12 UNI/NNI fragmentation enabled on the port or on a constituent TDM circuit.

Interfaces

• Single-chassis APS is supported on a SONET/SDH port with FRF.12 e2e fragmentation enabled on one or more FR SAPs on the port or on a constituent TDM circuit.

• Single-chassis APS is not supported on a SONET/SDH port with MLFR bundles configured.

• Multi-chassis APS is not supported on a SONET/SDH port with FR encapsulation configured on the port or on a constituent TDM circuit.

• APS is not supported on TDM satellite.

The following BFD support is provided:

• BFD is supported on an IP interface configured over a FR SAP with e2e fragmentation enabled.

• BFD is supported on an IP interface configured over a FR SAP on a port or channel with UNI/NNI fragmentation enabled.

• BFD is not supported on an FR SAP configured on an MLFR bundle.

The following mirroring support is provided:

• Port mirroring and FR SAP mirroring on an MLFR bundle.

• IP mirroring for an FR SAP on an MLFR bundle.

• A mirror source can be an MLFR bundle or a FR SAP on an FR bundle.

• Mirror destinations must be FR SAPs and must not be part of an APS group or an MLFR bundle.

Issue: 01 3HE 11968 AAAC TQZZA 01 63

Page 64

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

2.3.2.10 Multilink Point-to-Point Protocol (MLPPP)

Multilink point-to-point protocol is defined in the IETF RFC 1990, The PPP Multilink Protocol (MP), and provides a way to distribute data across multiple links within an

MLPPP bundle to achieve high bandwidth. MLPPP allows for a single frame to be fragmented and transmitted across multiple links. This allows for lower latency and also allows for a higher maximum receive unit (MRU).

MP is negotiated during the initial LCP option negotiations of a standard PPP session. A router indicates to its peer that it is willing to perform MLPPP by sending the MP option as part of the initial LCP option negotiation. This negotiation indicates the following:

1. The system offering the option is capable of combining multiple physical links into one logical link;

2. The system is capable of receiving upper layer protocol data units (PDU) fragmented using the MP header and reassembling the fragments back into the original PDU for processing;

3. The system is capable of receiving PDUs of size N octets where N is specified as part of the option even if N is larger than the maximum receive unit (MRU) for a single physical link.

Once MLPPP has been successfully negotiated, the sending system is free to send PDUs encapsulated and/or fragmented with the MP header.

MP introduces a new protocol type with a protocol ID (PID) of Ox003d. Figure 12 and

Figure 13 show the MLPPP fragment frame structure. Framing to indicate the

beginning and end of the encapsulation is the same as that used by PPP, and described in PPP in HDLC-like framing [RFC 1662]. MP frames use the same HDLC address and control pair value as PPP, namely: Address - OxFF and Control - Ox03. The two octet protocol field is also structured the same as in PPP encapsulation.

Figure 12 MLPPP 24-bit Fragment Format

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 65

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Figure 13 MLPPP 12-bit Fragment Format

The required and default format for MP is the 24-bit format. During the LCP state the 12-bit format can be negotiated. The SR-series routers can support and negotiate the alternate 12-bit frame format.

2.3.2.10.1 Protocol Field (PID)

Interfaces

The protocol field is two octets its value identifies the datagram encapsulated in the Information field of the packet. In the case of MP the PID also identifies the presence of a 4-octet MP header (or 2-octet, if negotiated).

A PID of Ox003d identifies the packet as MP data with an MP header.

The LCP packets and protocol states of the MLPPP session follow those defined by PPP in RFC 1661, The Point-to-Point Protocol (PPP). The options used during the LCP state for creating an MLPPP NCP session are described below.

2.3.2.10.2 B & E Bits

The B&E bits are used to indicate the epoch of a packet. Ingress packets to the MLPPP process will have an MTU, which may or may not be larger than the MRRU of the MLPPP network. The B&E bits manage the fragmentation of ingress packets when it exceeds the MRRU.

The B-bit indicates the first (or beginning) packet of a given fragment. The E-bit indicates the last (or ending) packet of a fragment. If there is no fragmentation of the ingress packet both B&E bits are set true (=1).

Issue: 01 3HE 11968 AAAC TQZZA 01 65

Page 66

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

2.3.2.10.3 Sequence Number

Sequence numbers can be either 12 or 24 bits long. The sequence number is zero for the first fragment on a newly constructed AVC bundle and increments by one for each fragment sent on that bundle. The receiver keeps track of the incoming sequence numbers on each link in a bundle and reconstructs the desired unbundled flow through processing of the received sequence numbers and B&E bits. For a detailed description of the algorithm refer to RFC 1990.

2.3.2.10.4 Information Field

The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the protocol field.

The MRRU will have the same default value as the MTU for PPP. The MRRU is always negotiated during LCP.

2.3.2.10.5 Padding

On transmission, the Information field of the ending fragment may be padded with an arbitrary number of octets up to the MRRU. It is the responsibility of each protocol to distinguish padding octets from real information. Padding must not be added to any but the last fragment (the E-bit set true).

2.3.2.10.6 FCS

The FCS field of each MP packet is inherited from the normal framing mechanism from the member link on which the packet is transmitted. There is no separate FCS applied to the reconstituted packet as a whole if transmitted in more than one fragment.

2.3.2.10.7 LCP

The Link Control Protocol (LCP) establishes the connection through an exchange of configure packets. This exchange is complete, and the LCP opened state entered, once a Configure-Ack packet has been both sent and received.

LCP allows for the negotiation of multiple options in a PPP session. MLPPP is somewhat different than PPP and therefore the following options are set for MLPPP and not negotiated:

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 67

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

• No async control character map

• No link quality monitoring

• No compound frames

• No self-describing-padding

Any non-LCP packets received during this phase must be silently discarded.

2.3.2.10.8 Link Fragmentation and Interleaving Support

Link Fragmentation and Interleaving (LFI) provides the ability to interleave high priority traffic within a stream of fragmented lower priority traffic. This feature helps avoid excessive delays to high priority, delay-sensitive traffic over a low-speed link. This can occur if this traffic type shares a link with lower priority traffic that utilizes much larger frames. Without this ability, higher priority traffic must wait for the entire packet to be transmitted before being transmitted, which could result in a delay that is too large for the application to function properly

Interfaces

For example, if VoIP traffic is being sent over a DS-1 or fractional DS-1 which is also used for Best Effort Internet traffic, LFI could be used so the small (usually 64-128B) VoIP packets can be transmitted between the transmission of fragments from the lower priority traffic.

Figure 14 shows the sequence of events as low priority and high priority frames

arrive and are handled by LFI.

Figure 14 Frame Sequence of Events

High Priority Queue

Low Priority Queue

1 2 6 5 3

MLPPP

Fragmentation

1. A low priority frame arrives in the low priority queue. At this particular instant, there are no packets in the high priority queue so low priority frame is de-queued and passed to the fragmentation mechanism for MLPPP.

Egress

Fig_2

2. The original packet is divided into ‘n’ fragments based on the size of the packet and the fragment threshold configuration.

Issue: 01 3HE 11968 AAAC TQZZA 01 67

Page 68

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

3. The fragments are then transmitted out the egress port.

4. After the transmission of the fragments has begun, high priority frames arrive in the high priority queue.

5. The transmission of the remaining fragments stops and the high priority packets are transmitted out the egress interface. Note that high priority packets are not fragmented.

6. When the high priority traffic is transmitted, the remaining lower priority fragments are then transmitted.

On the ingress side, LFI requires that the ingress port can receive non-fragmented packets within the fragment stream and pass these packets directly on to the forwarding engine and then continue with the reassembly process for the fragmented frames.

2.3.2.11 Multi-Class MLPPP

Multi-class MLPPP (MC-MLPPP) allows for the prioritization of multiple types of traffic flowing between the cell site routers and the mobile operator’s aggregation routers. MC-MLPPP is an extension of the MLPPP standard which allows multiple classes of service to be transmitted over a MLPPP bundle. Originally, link fragmentation and interleaving (LFI) was added to MLPPP that allowed two classes, but in some applications, two classes of service can be insufficient.

The MLPPP header includes two class bits to allow for up to four classes of service. This enhancement to the MLPPP header format is detailed in RFC 2686, The Multi- Class Extension to Multi-Link PPP. This allows multiple classes of services over a single MLPPP connection and allows the highest priority traffic to be transmitted over the MLPPP bundle with minimal delay regardless of the order in which packets are received.

Table 15 shows the header formats and Table 16 shows the original MLPP header

format and the enhanced header format.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 69

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Table 15 Header Formats

Original MLPPP Header Format MC-MLPPP Short Sequence Header Format

Interfaces

The new MC-MLPPP header format uses the two (previously unused) bits before the sequence number as the class identifier. This allows four distinct classes of service to be identified into separate re-assembly contexts.

2.3.2.11.1 QoS in MC-MLPPP

If the user enables the multiclass option under an MLPPP bundle, the MDA egress data path provides a queue for each of the four classes of MLPPP. The user configures the required number of MLPPP classes to use on a bundle. The forwarding class of the packet, as determined by the ingress QoS classification, determines the MLPPP class for the packet and hence which of the four egress MDA queues to store the packet. The mapping of forwarding class to MLPPP class is a function of the user configurable number of MLPPP classes. The default mapping for a 4-class, 3-class, and 2-class MLPPP bundle is shown in Table 16.

Table 16 Default Packet Forwarding Class to MLPPP Class Mapping

FC ID FC Name Scheduling Priority

(Default)

7 NC Expedited 0 0 0

MLPPP Class 4class bundle

MLPPP Class 3class bundle

MLPPP Class 2-class bundle

6 H1 Expedited 0 0 0

5 EF Expedited 1 1 1

Issue: 01 3HE 11968 AAAC TQZZA 01 69

Page 70

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Table 16 Default Packet Forwarding Class to MLPPP Class Mapping (Continued)

FC ID FC Name Scheduling Priority

(Default)

4 H2 Expedited 1 1 1

3 L1 Non-Expedited 2 2 1

2 AF Non-Expedited 2 2 1

1 L2 Non-Expedited 3 2 1

0 BE Non-Expedited 3 2 1

MLPPP Class 4class bundle

MLPPP Class 3class bundle

Table 17 shows a different mapping enabled when the user applies one of three pre-

defined egress QoS profiles in the 4-class bundle configuration only.

Table 17 Packet Forwarding Class to MLPPP Class Mapping

FC ID FC Name Scheduling Priority (Default) MLPPP Class

(MLPPP Egress QoS profile 1, 2, and 3)

7 NC Expedited 0

6 H1 Expedited 0

MLPPP Class 2-class bundle

5 EF Expedited 1

4 H2 Expedited 2

3 L1 Non-Expedited 2

2 AF Non-Expedited 2

1 L2 Non-Expedited 2

0 BE Non-Expedited 3

The MLPPP class queue parameters and its scheduling parameters are also configured by applying one of the three pre-defined egress QoS profiles to an MLPPP bundle.

Table 18 and Figure 15 provide the details of the class queue threshold parameters.

Packets marked with a high drop precedence, such as out-of-profile, by the service or network ingress QoS policy will be discarded when any class queue reaches the OOP threshold. Packet with a low drop precedence marking, such as in-profile, will be discarded when any class queue reaches the max threshold.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 71

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Table 18 MLPPP Class Queue Threshold Parameters

Class 0 Class 1 Class 2 Class 3

Interfaces

Queue Threshold (in ms

Max Oop Max Oop Max Oop Max Oop

@ Available bundle rate)

2-Class Bundle Default

250 125 750 375 N/A N/A N/A N/A

Egress QoS Profile

3-Class Bundle Default

50 25 200 100 750 375 N/A N/A

Egress QoS Profile

4-Class Bundle Default

10 5 50 25 150 75 750 375

Egress QoS Profile

4-Class Bundle

25 12 5 3 200 100 1000 500

Egress QoS Profile 1

4-Class Bundle

25 12 5 3 200 100 1000 500

Egress QoS Profile 2

4-Class Bundle

25 12 5 3 200 100 1000 500

Egress QoS Profile 3

Figure 15 MLPPP Class Queue Thresholds for In-Profile and Out-of-Profile Packets

Service Egress SAP Queue

MDA Class Queue

Fabric

Out

Mbs

Scheduler

(pir, cir)

Cbs

High-prio-only

Out

Max Out of Profile

(oop)

OSSG258

Table 19 and Figure 16 provide the details of the class queue scheduling

parameters.

Table 19 MLPPP Class Queue Scheduling Parameters

WRR Parameters

4-class MLPPP Egress QoS Profile

Profile 1 85% <1% 66% 33%

Issue: 01 3HE 11968 AAAC TQZZA 01 71

MIR W1 W2 W3

Page 72

Interfaces

OSSG259

Class0

> 100%

Strict

Priority

Class1

> MIR

Yes

wrr

Class2

Class3

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Table 19 MLPPP Class Queue Scheduling Parameters (Continued)

WRR Parameters

Profile 2 90% <1% 89% 10%

Profile 3 85% <1% 87% 12%

Figure 16 MLPPP Class Queue Scheduling Scheme

Note that all queue threshold and queue scheduling parameters are adjusted to the available bundle rate. If a member link goes down or a new member link is added to the bundle, the scheduling parameters MIR, W1, W2, W3, as well as the per class queue thresholds OOP and max are automatically adjusted to maintain the same values.

Class 0 queue is serviced at MLPPP at available bundle rate. Class 1 queue is guaranteed a minimum service rate but is allowed to share additional bandwidth with class 2 and 3 queues based on the configuration of WRR weight W1.

Class queues 2 and 3 can be given bandwidth guarantee by limiting MIR of class 1 queue to less than 100% and by setting the WRR weights W1, W2, and W3 to achieve the desired bandwidth distribution among all three class queues.

Note that there is one queue per bundle member link to carry link control packets, such as LCP: PPP, and which are serviced with strict priority over the 4 class queues (not shown).

In the default 2-class, 3-class, and 4-class egress QoS profile, the class queues are service with strict priority in ascending order of class number.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 73

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Ingress MLPPP Class Reassembly

For an MLPPP bundle with the multi-class option enabled, there is a default profile for setting the re-assembly timer value for each class. When the pre-defined MLPPP ingress QoS profile 1 is applied to a 4-class bundle, the values of the timers are modified as shown in Table 20.

Table 20 MLPPP Ingress QoS Profile: Reassembly Timers (msec)

Interfaces

Class 0 Class 1 Class 2 Class 4

MLPPP ingress QoS default profile (2-Class bundle)

MLPPP ingress QoS default profile (3-Class bundle)

MLPPP ingress QoS default profile (4-Class bundle)

MLPPP ingress QoS profile 1 (4-class bundle)

25ms 25ms NA NA

25ms 25ms 25ms NA

25ms 25ms 100ms 1000ms

10 10 100 1000

Configuring MC-MLPPP QoS Parameters

A 4-class MLPPP bundle can be configured with user-defined MLPPP QoS attributes. This feature cannot be used with MC-MLPPP bundles with fewer than 4 classes or with non-multiclass bundles.

The following describe the parameters and the configuration processes and rules

1. The user creates an ingress QoS profile in the mlppp-profile-ingress context, to configure a preferred value of the ingress per-class re-assembly timer. Ingress QoS profile 1 is reserved for the pre-defined profile with parameter values shown in Table 20. The user is allowed to edit this profile and change the parameter values. When a user creates a profile with a profile-id greater than 1, or performs the no option command on the parameter, the parameter's default value will always be the 1 in Table 20 for ingress QoS Profile #1 regardless of the parameter value the edited Profile 1 has at that point.

2. The user creates an egress QoS profile in the mlppp-profile-egress context to configure preferred values for the per-class queue and queue scheduling parameters. The user can also configure system forwarding class mapping to the MLPPP classes. Egress QoS profiles 1, 2, and 3, are reserved for the predefined profiles with parameter values shown in Table 17, Table 18, or Table 19. Users can edit these profiles and change the parameter values. When a user creates a profile with a profile-id higher than 3, or when the user specifies the no

Issue: 01 3HE 11968 AAAC TQZZA 01 73

Page 74

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

option command on the parameter, the default value will be the one shown in

Table 17, Table 18, or Table 19 for the egress QoS Profile 1. This is regardless

of the parameter value the edited profiles have at that point in time.

3. A maximum of 128 ingress and 128 egress QoS profiles can be created on the system.

4. The values of the ingress per-class re-assembly timer are configured in the ingress QoS profile.

5. The mapping of the system forwarding classes to the MLPPP Classes are configured in the egress QoS profile. There is a many-to-one relationship between the system FC and an MLPPP class. See Table 17 for the mapping when one of the three pre-defined 4-class egress QoS profiles is selected.

6. The maximum size for each MLPPP class queue in units of msec at the available bundle rate is configured in the egress QoS profile. This is referred to as max in

Figure 15 and as max-queue-size in CLI. The out-of-profile threshold for an

MLPPP class queue, referred to as oop in Figure 15, is not directly configurable and is set to 50% of the maximum queue size rounded up to the nearest higher integer value.

7. The MLPPP class queue scheduling parameters is configured in the egress QoS profile. The minimum information rate, referred to as MIR in Figure 16 and mir in CLI, applies to Class 1 queue only. The MIR parameter value is entered as a percentage of the available bundle rate. The WRR weight, referred to as W1, W2, and W3 in Figure 16 and weight in CLI, applies to class 1, class 2, and class 3 queues. Note that W1 in Figure 16 is not configurable and is internally set to a value of 1 such that Class 1 queue shares 1% of the available bundle rate when the sum of W1, W2, and W3 equals 100. W2 and W3 weights are integer values and are user configurable such that Class 2 queue shares (W2/(W1 + W2 + W3)) and Class 3 queue shares (W3/(W1 + W2 + W3)) of the available bundle rate.

8. The user applies the ingress and egress QoS profiles to a 4-class MLPPP bundle for the configured QoS parameter values to take effect on the bundle.

9. The following operations require the bundles associated with a QoS profile to be shutdown to take effect.

− A change of the numbered ingress or egress QoS profile associated with a bundle.

− A change of the bundle associated ingress or egress QoS profile from default profile to a numbered profile and vice-versa.

10. The following operations can be performed without shutting down the associated bundles:

− Changes to any parameters in the ingress and egress QoS profiles.

The CLI commands for the creation of ingress and egress QoS profiles and configuration of the individual QoS parameters are described in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 75

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

2.3.2.12 Cisco HDLC

Cisco HDLC (cHDLC) is an encapsulation protocol for information transfer. It is a bitoriented synchronous data-link layer protocol that specifies a data encapsulation method on synchronous serial links using frame characters and checksums.

cHDLC monitors line status on a serial interface by exchanging keepalive request messages with peer network devices. It also allows routers to discover IP addresses of neighbors by exchanging Serial Link Address Resolution Protocol (SLARP) (see

SLARP) address-request and address-response messages with peer network

devices.

The basic frame structure of a cHDLC frame is shown in Table 21. This frame structure is similar to PPP in an HDLC-link frame (RFC 1662, PPP in HDLC-like Framing). The differences to PPP in and HDLC-like frames are in the values used in the address, control, and protocol fields.

Table 21 cHDLC I-Frame

Interfaces

Flag Address Control Protocol Information

Field

0x7E 0x0F/0x8F 0x00 — — 16/32 bits

FCS

• Address field — The values of the address field include: 0x0F (unicast), 0x8F (broadcast).

• Control field — The control field is always set to value 0x00.

• Protocol field — The following values are supported for the protocol field:

Table 22 shows the cHDLC protocol fields.

Table 22 cHDLC Protocol Fields

Protocol Field Value

IP 0x0800

Cisco SLARP 0x8035

ISO CLNP/ISO ES-IS DSAP/SSAP1 0xFEFE

• Information field — The length of the information field is in the range of 0 to 9kbytes.

Issue: 01 3HE 11968 AAAC TQZZA 01 75

Page 76

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

• FCS field — The FCS field can assume a 16-bit or 32-bit value. The default is 16-bits for ports with a speed equal to or lower than OC-3, and 32-bits for all other ports. The FCS for cHDLC is calculated in the same manner and same polynomial as PPP.

2.3.2.12.1 SLARP

A cHDLC interface on a Nokia router will transmit a SLARP address resolution reply packet in response to a received SLARP address resolution request packet from peers. The cHDLC interface will not transmit SLARP address resolution request packets.

For the SLARP keepalive protocol, each system sends the other a keepalive packet at a user-configurable interval. The default interval is 10 seconds. Both systems must use the same interval to ensure reliable operation. Each system assigns sequence numbers to the keepalive packets it sends, starting with zero, independent of the other system. These sequence numbers are included in the keepalive packets sent to the other system. Also included in each keepalive packet is the sequence number of the last keepalive packet received from the other system, as assigned by the other system. This number is called the returned sequence number. Each system keeps track of the last returned sequence number it has received. Immediately before sending a keepalive packet, it compares the sequence number of the packet it is about to send with the returned sequence number in the last keepalive packet it has received. If the two differ by 3 or more, it considers the line to have failed, and will not route higher-level data across it until an acceptable keepalive response is received.

There is interaction between the SLARP address resolution protocol and the SLARP keepalive protocol. When one end of a serial line receives a SLARP address resolution request packet, it assumes that the other end has restarted its serial interface and resets its keepalive sequence numbers. In addition to responding to the address resolution request, it will act as if the other end had sent it a keepalive packet with a sequence number of zero, and a returned sequence number the same as the returned sequence number of the last real keepalive packet it received from the other end.

2.3.2.12.2 SONET/SDH Scrambling and C2-Byte

SONET/SDH scrambling and overhead for cHDLC follow the same rules used for POS (RFC 2615, PPP over SONET/SDH).

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 77

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

The two key SONET/SDH parameters are scrambling and signal-label (C2-byte). Scrambling is off by default. The default value of the C2-byte is 0xCF. These two parameters can be modified using the CLI. The other SONET overhead values (for example, j0) follow the same rules as the current POS implementation.

SONET/SDH scrambling and overhead for cHDLC is not supported on TDM satellite.

2.3.2.12.3 Timers

Cisco HDLC (cHDLC) has two timers associated with the protocol, the keepalive interval and the timeout interval. The keepalive interval sends periodic keepalive packets. The receiver process expects to receive a keepalive packet at the rate specified by the keepalive interval. The link is declared down if the receiver process does not receive a keepalive within the timeout interval. The link is declared up when the number of continual keepalive packets received equals the up-count.

It is recommended that the nodes at the two endpoints of the cHDLC link are provisioned with the same values.

Interfaces

2.3.2.13 Automatic Protection Switching (APS)

APS is designed to protect SONET/SDH equipment from linear unidirectional or bidirectional failures. The Network Elements (NEs) in a SONET/SDH network constantly monitor the health of the network. When a failure is detected, the network proceeds through a coordinated pre-defined sequence of steps to transfer (or switchover) live traffic to the backup facility (protection facility). This happens very quickly to minimize lost traffic. Traffic remains on the protection facility until the primary facility (working facility) fault is cleared, at which time the traffic may optionally be reverted to the working facility. An example is shown in Figure 17.

Issue: 01 3HE 11968 AAAC TQZZA 01 77

Page 78

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Figure 17 APS Protection (Single Chassis APS) and Switchover

GigE

7750 SR

Data Flow

SAT

GigE

SAT

GigE

SAT

GigE

SAT

GigE

SAT

GigE

SAT

Working Facility

Protection Facility

7750 S

Working Facility

Protection Facility

7750 S

Working Facility

Protection Facility

7750 S

sw0092

Note that “facility” in the router’s context refers to the physical line (including intermediate transport/switching equipment) and directly attached line terminating hardware (SFP module, MDA and IOM). “Circuit” is also a term used for a link/facility (working-circuit).

A 1+1 APS group contains two circuits.

APS is configured on a port by port basis. If all ports on an MDA or IOM need to be protected then each port on the MDA or IOM must be individually added into an APS group.

Working and protection circuits can be connected to a variety of types of network elements (ADMs, DACSes, ATM switches, routers) and serve as an access or network port providing one or more services or network interfaces to the router. APSprotected SONET/SDH ports may be further channelized, and may contain bundled channels MLPPP or IMA Bundle Protection Groups). The ports may be one of a variety of encapsulation types as supported by the MDA including PPP, ATM, FR and more. For information about MDAs, port types, switching modes, bundles and encapsulations supported with APS, see APS Applicability, Restrictions and

Interactions.

This section discusses the different APS architectures and their implementations.

• Single Chassis and Multi-Chassis APS

• APS Switching Modes

• APS Channel and SONET Header K Bytes

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 79

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

• Revertive Switching

• Bidirectional 1+1 Switchover Operation Example

• Protection of Upper Layer Protocols and Services

• APS User-Initiated Requests

• APS and SNMP

• APS Applicability, Restrictions and Interactions

• Sample APS Applications

2.3.2.13.1 Single Chassis and Multi-Chassis APS

APS can operate in a single chassis configuration (SC-APS) or in a multi-chassis configuration (MC-APS).

An SC-APS group can span multiple ports, MDAs or IOMs within a single node whereas as MC-APS can span two separate nodes as shown in Table 23.

Interfaces

Table 23 SC-APS versus MC-APS Protection

Single Chassis APS

Short form name SC-APS MC-APS

Link failure protection (including intermediate transmission equipment failure)

Optical/electrical module (SPF, XFP) failure protection

MDA failure protection Yes Yes

IOM failure protection Yes Yes

Node failure protection No Yes

Yes Yes

Multi-Chassis APS

The support of SC-APS and MC-APS depends on switching modes, MDAs, port types and encaps. For a definitive description of the MDAs, port types, switching modes, bundles and encapsulations supported with APS, see APS Applicability,

Restrictions and Interactions.

Issue: 01 3HE 11968 AAAC TQZZA 01 79

Page 80

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

APS on a Single Node (SC-APS)

In a single chassis APS both circuits of an APS group are terminated on the same node.

The working and protect lines of a single chassis APS group can be:

• Two ports on the same MDA

• Two ports on different MDAs but on the same IOM

• Two ports on different MDAs on two different IOMs (installed in different slots)

• Two ports on two TDM satellites

If the working and protection circuits are on the same MDA, protection is limited to the physical port and the media connecting the two devices. If the working and protection circuits are on different IOMs then protection extends to MDA or IOM failure. Figure 18 shows a configuration that provides protection against circuit, port, MDA or IOM failure on the 7750 SR connected to an Add-Drop-Multiplexer (ADM).

Figure 18 SC-APS Group with MDA and IOM Protection

Link 1

sc-aps

Link 2

ADM

group

7750 SR

OSSG656

APS Across Two Nodes (MC-APS)

Multi-Chassis APS functionality extends the protection offered by SC-APS to include protection against nodal (7750 SR) failure by configuring the working circuit of an APS group on one 7750 SR node while configuring the protect circuit of the same APS group on a different 7750 SR node.

These two nodes connect to each other with an IP link to establish an MC-APS signaling path between the two 7750 SRs. Note that the working circuit and the protect circuit must have compatible configurations (such as the same speed, framing, and port-type). The relevant APS groups in both the working and protection routers must have same group ID, but they can have different names (for example, group port descriptions). Although the working and protection routers can be different platforms (7750 SR-7 and a 7750 SR-c12), switchover performance may be

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 81

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

impacted so it is recommended to avoid a mix of platforms in the same MC-APS group where possible. The configuration consistency between the working circuit/ router and the protection circuit/router is not enforced by the 7750 SR. Service or network-specific configuration data is not signaled nor synchronized between the two service routers.

Signaling is provided using the direct connection between the two service routers. A heartbeat protocol can be used to add robustness to the interaction between the two routers. Signaling functionality includes support for:

• APS group matches between service routers.

• Verification that one side is configured as a working circuit and the other side is configured as the protect circuit. In case of a mismatch, a trap (incompatible neighbor) is generated.

• Change in working circuit status is sent from the working router to keep the protect router in sync.

• Protect router, based on K1/K2 byte data, member circuit status, and external request, selects the active circuit, and informs the working router to activate or de-activate the working circuit.

Interfaces

Note that external requests like lockout, force, and manual switches are allowed only on the APS group having the protection circuit.

The Figure 19 shows a Multi-Chassis APS group being used to protect against link, port, MDA, IOM or node failure.

Figure 19 MC-APS Group Protects Against Node Failure

7750 SR A

Link 1

mc-aps

group

Link 2

mc-aps Signaling Link

7750 SR B

OSSG65

Issue: 01 3HE 11968 AAAC TQZZA 01 81

Page 82

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

2.3.2.13.2 APS Switching Modes

APS behavior and operation differs based on the switching mode configured for the APS group as shown in Table 24. Several switching modes are supported in the router.

The switching mode affects how the two directions of a link behave during failure scenarios and how APS tx operates.

Unidirectional / Bidirectional configuration must be the same at both sides of the APS group. The APS protocol (K byte messages) exchange switching mode information to ensure that both nodes can detect a configuration mismatch.

• If one end of an APS group is configured in a Unidirectional mode (Uni 1+1 Sig APS or Uni 1+1 Sig+Data APS) then the other end must also be configured in a Unidirectional mode (Uni 1+1 Sig+Data APS).

• If one end of an APS group is configured in a Bidirectional mode then the other end must also be configured in Bidirectional mode.

Table 24 APS Switching Modes

Bidirectional 1+1 Signaling APS

Short form name Bidir 1+1 Sig APS Uni 1+1 Sig APS Uni 1+1 Sig+Data APS

CLI bi-directional uni-directional uni-1plus1

Interworks with a standards compliant APS implementation

Full 1+1 APS standardsbased signaling

Data is transmitted simultaneously on both links/ circuits (1+1 Data)

Yes Yes Yes

No No Yes

Unidirectional 1+1 Signaling APS

Unidirectional 1+1 Signaling and Datapath APS

The support of switching modes depends on SC-APS / MC-APS, MDAs, port types and encaps. For a definitive description of the MDAs, port types, switching modes, bundles and encapsulations supported with APS, see APS Applicability, Restrictions

and Interactions.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 83

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Bidirectional 1+1 Signaling APS

In Bidir 1+1 Sig APS switching mode the Tx data is sent on the active link only (it is not bridged to both links simultaneously). 1+1 signaling, however, is used for full interoperability with signaling-compliant 1+1 architectures.

In the ingress direction (Rx), the decision to accept data from either the working or protection circuit is based on both locally detected failures/degradation and on what circuit the far-end is listening on (as indicated in the K bytes). If the far-end indicates that it has switched its active receiver, then the local node will also switch its receiver (and Tx) to match the far-end. If the local Rx changes from one circuit to another it notifies the far end using the K bytes.

In the egress direction (Tx), the data is only transmitted on the active circuit. If the active Rx changes, then Tx will also change to the same circuit.

Bidirectional 1+1 Signaling APS ensures that both directions of active data flow (including both Rx) are using the same link/circuit (using the two directions of the same fiber pair) as required by the APS standards. If one end of the APS group changes the active receiver, it will signal the far end using the K bytes. The far end will then also change its receiver to listen on the same circuit.

Interfaces

Because the router transmits on active circuits only and keeps active TX and RX on the same port, both local and remote switches are required to restore the service.

The APS channel (bytes K1 and K2 in the SONET header – K bytes) exchanges requests and acknowledgments for protection switch actions. In Bidirectional 1+1 Signaling APS switching mode, the router sends correct status on the K bytes and requires the far-end to also correctly update/send the K-bytes to ensure that data is transmitted on the circuit on which the far-end has selected as its active receiver.

Line alarms are processed and generated independently on each physical circuit.

In Bidirectional 1+1 Signaling APS mode, the highest priority local request is compared to the remote request (received from the far end node using an APS command in the K bytes), and whichever has the greater priority is selected. The relative priority of all events that affect APS 1+1 protection is listed in the Table 25 in descending order. The requests can be automatically initiated (such as signal failure or signal degrade), external (such as lockout, forced switch, request switch), and state requests (such as revert-time timers, and so on).

Issue: 01 3HE 11968 AAAC TQZZA 01 83

Page 84

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Unidirectional 1+1 Signaling APS

In Uni 1+1 Sig APS switching mode the Tx data is sent on the active link only (it is not bridged to both links simultaneously). 1+1 signaling, however, is used for full interoperability with signaling-compliant 1+1 architectures.

In the ingress direction (Rx), the decision to accept data from either the working or protection circuit is based on both locally detected failures/degradation and on what circuit the far-end is listening on (as indicated in the K bytes). Although it is not required in the APS standards, the system’s implementation of Unidirectional 1+1 Signaling APS uses standards based signaling to keep both the Rx and Tx on the same circuit / port. If the far-end indicates that it has switched its active receiver, then the local node will also switch its receiver (and Tx) to match the far-end. If the local Rx changes from one circuit to another it notifies the far end using the K bytes.

In the egress direction (Tx), the data is only transmitted on the active circuit. If the active Rx changes, then Tx will also change to the same circuit.

Because the router transmits on active circuits only and keeps active TX and RX on the same port, both local and remote switches are required to restore the service. For a single failure a data outage is limited to a maximum of 100 milliseconds.

The APS channel (bytes K1 and K2 in the SONET header – K bytes) exchanges requests and acknowledgments for protection switch actions. In Unidirectional 1+1 Signaling APS switching mode, the router sends correct status on the K bytes and requires the far-end to also correctly update/send the K-bytes to ensure that data is transmitted on the circuit on which the far-end has selected as its active receiver.

Line alarms are processed and generated independently on each physical circuit.

In Unidirectional 1+1 Signaling APS switching mode:

• K-bytes are generated/transmitted based on local request/condition only (as required by the APS signaling).

• Local request priority is compliant to 1+1 U-APS specification.

• RX and TX are always forced on to the same (active) circuit (bi-directional). This has the following caveats:

− If an APS switch is performed due to a local condition, then the TX direction will be moved as well to the newly selected RX circuit (old inactive). The router will send LAIS on the old active TX circuit to force the remote end to APS switch to the newly active circuit. Note that some local request may not cause an APS switch when a remote condition prevents both RX and TX direction to be on the same circuit (for example an SD detected locally on a working circuit will not cause a switch if the protection circuit is locked out by the remote end).

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 85

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

− If the remote end indicates an APS switch and the router can RX and TX on the circuit newly selected by the remote end, then the router will move its TX direction and will perform an APS switch of its RX direction (unless the router already TX and RX on the newly selected circuit).

− If the remote end indicates an APS switch and the router cannot RX and TX on the circuit newly selected by the remote end (for example due to a higher priority local request, like a force request or manual request, and so on), then L-AIS are sent on the circuit newly selected by the remote end to force it back to the previously active circuit.

− The sent L-AIS in the above cases can be either momentary or persistent. The persistent L-AIS is sent under the following conditions:

• On the protection circuit when the protection circuit is inactive and cannot be selected due to local SF or Lockout Request.

• On the working circuit as long as the working circuit remains inactive due to a local condition. The persistent L-AIS is sent to prevent revertive switching at the other end.

In all other cases a momentary L-AIS is sent. The system provides debugging information that informs operators about the APS-induced L-AIS.

Interfaces

Unidirectional 1+1 Signaling and Datapath APS

Uni 1+1 Sig+Data APS supports unidirectional switching operations, 1+1 signaling and 1+1 data path.

In the ingress direction (Rx) switching is done based on local requests only as per the APS specifications. K-bytes are used to signal the far end the APS actions taken.

In the egress direction (Tx), the data is transmitted on both active and protecting circuits.

Each end of the APS group may be actively listening on a different circuit.

The APS channel (bytes K1 and K2 in the SONET header) exchanges APS protocol messages.

In Uni 1+1 Sig+Data APS a received L-RDI signal on the active circuit does not cause that circuit (port) to be placed out of service. The APS group can continue to use that circuit as the active receiver. This behavior is not configurable.

Uni 1+1 Sig+Data APS also supports configurable:

• Debounce timers for signal failure and degradation conditions

• Suppression of L-RDI alarm generation

Issue: 01 3HE 11968 AAAC TQZZA 01 85

Page 86

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

2.3.2.13.3 APS Channel and SONET Header K Bytes

The APS channel (bytes K1 and K2 in the SONET header) exchanges APS protocol messages for all APS modes.

K1 Byte

The switch priority of a request is assigned as indicated by bits 1 through 4 of the K1 byte (as described in the rfc3498 APS-MIB); see Table 25.

Table 25 K1 Byte, Bits 1 to 4: Type of Request

Bit 1234 Condition

1111 Lockout of protection

1110 Force switch

1101 SF - High priority

1100 SF - Low priority

1011 SD - High priority

1010 SD - Low priority

1001 (not used)

1000 Manual switch

0111 (not used)

0110 Wait-to-restore

0101 (not used)

0100 Exercise

0011 (not used)

0010 Reverse request

0001 Do not revert

0000 No request

The channel requesting switch action is assigned by bits 5 through 8. When channel number 0 is selected, the condition bits show the received protection channel status. When channel number 1 is selected, the condition bits show the received working channel status. Channel values of 0 and 1 are supported.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 87

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Interfaces

Table 26 shows bits 5 to 8 of a K1 byte and K2 Bits 1 to 4 and the channel number

code assignments.

Table 26 K1 Byte, Bits 5 to 8 (and K2 Bits 1 to 4), Channel Number Code Assignments

Channel Number Code

0 Null channel.

1 to 14 Working channel.

15 Extra traffic channel.

Channel and Notes

SD and SF requests apply to conditions detected on the protection line. For 1+1 systems, Forced and Request Switch requests apply to the protection line

(for the 7750 SR only). Only code 0 is used with Lockout of Protection request.

Only code 1 applies in a 1+1 architecture. Codes 1 through n apply in a 1:n architecture (for the 7750 SR only). SD and SF conditions apply to the corresponding working lines.

May exist only when provisioned in a 1:n architecture. Only No Request is used with code 15.

K2 Byte

The K2 byte indicates the bridging actions performed at the line-terminating equipment (LTE), the provisioned architecture and mode of operation.

The bit assignment for the K2 byte is listed in Table 27.

Table 27 K2 Byte Functions

Bits 1 to 8 Function

1 to 4 Channel number. The 7750 SR supports only values of 0 and 1.

5 0 Provisioned for 1+1 mode

1 Provisioned for 1:n mode

Issue: 01 3HE 11968 AAAC TQZZA 01 87

Page 88

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Table 27 K2 Byte Functions (Continued)

Bits 1 to 8 Function

6 to 8 111 Line AIS

110 Line RDI 101 Provisioned for bi-directional switching 100 Provisioned for uni-directional switching 011 (reserved for future use) 010 (reserved for future use) 001 (reserved for future use) 000 (reserved for future use)

Differences in SONET/SDH Standards for K Bytes

SONET and SDH standards are slightly different with respect to the behavior of K1 and K2 Bytes.

Table 28 shows the differences between the two standards.

Table 28 Differences Between SONET and SDH Standards

SONET SDH Comments

SONET/SDH standards use different codes in the transmitted K1 byte (bits 1-

4) to notify the far-end of a signal fail/signal degrade detection.

SONET systems signal the switching mode in bits 5-8 of the K2 byte whereas SDH systems do not signal at all.

1100 for signal fail 1010 for signal degrade 1101 unused 1011 unused

101 for bi-dir 100 for uni-dir

1101 for signal fail 1011 for signal degrade 1100 unused 1010 unused

Not used. 000 is signaled in bits 5 to 8 of K2 byte for both bi-directional as well as uni-directional switching.

Failures Indicated by K Bytes

The following sections describe failures indicated by K bytes.

None.

SONET systems raise a mode mismatch alarm as soon as a mismatch in the TX and RX K2 byte (bits 5 to 8) is detected. SDH systems do not raise the mode mismatch alarm.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 89

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

APS Protection Switching Byte Failure

An APS Protection Switching Byte (APS-PSB) failure indicates that the received K1 byte is either invalid or inconsistent. An invalid code defect occurs if the same K1 value is received for 3 consecutive frames (depending on the interface type (framer) used, the 7750 SR may not be able to strictly enforce the 3 frame check per GR-253 and G.783/G.841) and it is either an unused code or irrelevant for the specific switching operation. An inconsistent APS byte defect occurs when no three consecutive received K1 bytes of the last 12 frames are the same.

If the failure detected persists for 2.5 seconds, a Protection Switching Byte alarm is raised. When the failure is absent for 10 seconds, the alarm is cleared. This alarm can only be raised by the active port operating in bi-directional mode.

APS Channel Mismatch Failure

An APS channel mismatch failure (APS-CM) identifies that there is a channel mismatch between the transmitted K1 and the received K2 bytes. A defect is declared when the received K2 channel number differs from the transmitted K1 channel number for more than 50 ms after three identical K1 bytes are sent. The monitoring for this condition is continuous, not just when the transmitted value of K1 changes.

Interfaces

If the failure detected persists for 2.5 seconds, a channel mismatch failure alarm is raised. When the failure is absent for 10 seconds, the alarm is cleared. This alarm can only be raised by the active port operating in a bi-directional mode.

APS Mode Mismatch Failure

An APS mode mismatch failure (APS-MM) can occur for two reasons. The first is if the received K2 byte indicates that 1:N protection switching is being used by the farend of the OC-N line, while the near end uses 1+1 protection switching. The second is if the received K2 byte indicates that uni-directional mode is being used by the farend while the near-end uses bi-directional mode.

This defect is detected within 100 ms of receiving a K2 byte that indicates either of these conditions. If the failure detected persists for 2.5 seconds, a mode mismatch failure alarm is raised. However, it continues to monitor the received K2 byte, and should it ever indicate that the far-end has switched to a bi-directional mode the mode mismatch failure clearing process starts. When the failure is absent for 10 seconds, the alarm is cleared, and the configured mode of 1+1 bidirectional is used.

Issue: 01 3HE 11968 AAAC TQZZA 01 89

Page 90

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

APS Far-End Protection Line Failure

An APS far-end protection line (APS-FEPL) failure corresponds to the receipt of a K1 byte in 3 consecutive frames that indicates a signal fail (SF) at the far end of the protection line. This forces the received signal to be selected from the working line.

If the failure detected persists for 2.5 seconds, a far-end protection line failure alarm is raised. When the failure is absent for 10 seconds, the alarm is cleared. This alarm can only be raised by the active port operating in a bi-directional mode.

2.3.2.13.4 Revertive Switching

The APS implementation also provides the revertive and non-revertive modes with non-revertive switching as the default option. In revertive switching, the activity is switched back to the working port after the working line has recovered from a failure (or the manual switch is cleared). In non-revertive switching, a switch to the protection line is maintained even after the working line has recovered from a failure (or if the manual switch is cleared).

A revert-time is defined for revertive switching so frequent automatic switches as a result of intermittent failures are prevented. A change in this value takes effect upon the next initiation of the wait to restore (WTR) timer. It does not modify the length of a WTR timer that has already been started. The WTR timer of a non-revertive switch can be assumed to be infinite.

In case of failure on both working and the protection line, the line that has less severe errors on the line will be active at any point in time. If there is signal degrade on both ports, the active port that failed last will stay active. When there is signal failure on both ports, the working port will always be active. The reason is that the signal failure on the protection line is of a higher priority than on the working line.

2.3.2.13.5 Bidirectional 1+1 Switchover Operation Example

Table 29 outlines the steps that a bi-directional protection switching process will go

through during a typical automatic switchover.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 91

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Table 29 Actions for the Bi-directional Protection Switching Process

Interfaces

Status APS Commands Sent in K1 and

K2 Bytes on Protection Line

B -> A A -> B At Site B At Site A

No failure (Protection line is not in use).

Working line Degraded in direction A->B.

Site A receives SD failure condition.

Site B receives Reverse request.

No request. No request. No action. No action.

SD on working channel 1.

Same. Reverse

Same. Same. No action. No action.

No request. Failure

request.

2.3.2.13.6 Annex B (1+1 Optimized) Operation

Action

No action. detected, notify A and switch to protection line.

No action. Remote failure detected,

acknowledge and switch

to protection line.

Operation and behavior conferment with Annex B of ITU.T G.841 can be configured for an APS group. Characteristics of this mode include are the following:

• Annex B operates in non-revertive bi-directional switching mode only as defined in G.841.

• Annex B operates with 1+1 signaling, but 1:1 data path where by data is transmitted on the active link only.

• K bytes are transmitted on both circuits.

Due to the request/reverse-request nature of an Annex B switchover, the data outage is longer than a typical (non Annex B single chassis) APS switchover. IMA bundles that are protected with Annex B APS have to resynchronize after a switchover. It is recommended to use maintenance commands (tools>perform>aps…) for planned switchovers (not MDA or IOM shutdown) to minimize the outage.

Issue: 01 3HE 11968 AAAC TQZZA 01 91

Page 92

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Annex B APS Outage Reduction Optimization

Typical standard Annex B behavior when a local SF is detected on the primary section (circuit), and this SF is the highest priority request on both the local side and from the remote side as per the APS specifications, is to send a request to the remote end and then wait until a reverse request is received before switching over to the secondary section. To reduce the recovery time for traffic, the router will switch over to the secondary section immediately upon detecting the local SF on the primary section instead of waiting for the reverse request from the remote side. If the remote request is not received after a period of time then an “PSB Failure is declared” event is raised (Protection Switching Byte Failure – indicates an inconsistent or invalid Rx K1 Bytes), and the APS group on the local side switches back to the primary section.

When the remote side is in Lockout, and a local SF is detected then a reverse request will not be received by the local side. In this case, the traffic will no longer flow on the APS group since neither the primary nor secondary sections can carry traffic, and the outage reduction optimization will cause a temporary switchover from the primary to the secondary and then back again (which causes no additional outage or traffic issue since neither section is usable). If this temporary switchover is not desired then it is recommended to either perform Lockout from the router side, or to Lockout from both sides, which will avoid the possibility of the temporary switchover.

Failures detected on the secondary section cause immediate switch over as per the Annex B specification. There is no outage reduction optimization in the router for this case as it is not needed.

Some examples of events that can cause a local SF to be detected include: a cable being cut, laser transmitter or receiver failure, a port administratively “shutdown”, MDA failure or shutdown, IOM failure or shutdown.

Note: In Annex B operation, all switch requests are for a switch from the primary section to the secondary section. Once a switch request clears normally, traffic is maintained on the section to which it was switched by making that section the primary section. The primary section may be working circuit 1 or working circuit 2 at any particular moment.

2.3.2.13.7 Protection of Upper Layer Protocols and Services

APS prevents upper layer protocols and services from being affected by the failure of the active circuit.

The following example with figures and description illustrate how services are protected during a single-chassis APS switchover.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 93

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Figure 20 shows an example in which the APS working circuit is connected to IOM-

1/MDA-1 and the protection circuit is connected to IOM-2/MDA-1. In this example, assume that the working circuit is currently used to transmit and receive data.

Figure 20 APS Working and Protection Circuit Example

Interfaces

APS-CTL

Services

IOM-1

IOM-2

IOM-3

IOM-CPU

MDA-1

MDA-2

MDA-1

MDA-2

MDA-1

MDA-2

Flexible FastPath

Complex

Flexible FastPath

Complex

Flexible FastPath

Complex

Flexible FastPath

Complex

Flexible FastPath

Complex

Flexible FastPath

Complex

APS Working

APS Protect

Fig_4

Switchover Process for Transmitted Data

For packets arriving on all interfaces that need to be transmitted over APS protected interfaces, the next hop associated with all these interfaces are programmed in all Flexible Fast-Path complexes in each MDA with a logical next-hop index. This next hop-index identifies the actual next-hop information used to direct traffic to the APS working circuit on IOM-1/MDA-1.

All Flexible Fast-Path complexes in each MDA are also programmed with next hop information used to direct traffic to the APS protect circuit on IOM-2/MDA-1. When the transmitted data needs to be switched from the working to the protect circuit, only the relevant next hop indexes need to be changed to the pre-programmed next-hop information for the protect circuit on IOM-2/MDA-1.

Although the control CFM/CPM on the SF/CPM blade initiates the changeover between the working to protect circuit, the changeover is transparent to the upper layer protocols and service layers that the switchover occurs.

Physical link monitoring of the link is performed by the CPU on the relevant IOM for both working and protect circuits.

Issue: 01 3HE 11968 AAAC TQZZA 01 93

Page 94

Interfaces

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

Switchover Process for Received Data

The Flexible Fast-Path complexes for both working and protect circuits are programmed to process ingress. The inactive (protect) circuit however is programmed to ignore all packet data. To perform the switchover from working circuit to the protect circuit the Flexible Fast-Path complex for the working circuit is set to ignore all data while the Flexible Fast-Path complex of the protect circuit will be changed to accept data.

The ADM or compatible head-end transmits a valid data signal to both the working and protection circuits. The signal on the protect line will be ignored until the working circuit fails or degrades to the degree that requires a switchover to the protect circuit. When the switchover occurs all services including all their QoS and filter policies are activated on the protection circuit.

2.3.2.13.8 APS User-Initiated Requests

The following subsections describe APS user-initiated requests.

Lockout Protection

The lockout of protection disables the use of the protection line. Since the tools>perform>aps>lockout command has the highest priority, a failed working line using the protection line is switched back to itself even if it is in a fault condition. No switches to the protection line are allowed when locked out.

Request Switch of Active to Protection

The request or manual switch of active to protection command switches the active line to use the protection line unless a request of equal or higher priority is already in effect. If the active line is already on the protection line, no action takes place.

Request Switch of Active to Working

The request or manual switch of active to working command switches the active line back from the protection line to the working line unless a request of equal or higher priority is already in effect. If the active line is already on the working line, no action takes place.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 95

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

Forced Switching of Active to Protection

The forced switch of active to protection command switches the active line to the protection line unless a request of equal or higher priority is already in effect. When the forced switch of working to protection command is in effect, it may be overridden either by a lockout of protection or by detecting a signal failure on the protection line. If the active line is already on the protection line, no action takes place.

Forced Switch of Active to Working

The forced switch of active to working command switches the active line back from the protection line to the working unless a request of equal or higher priority is already in effect.

Exercise Command

Interfaces

The exercise command is only supported in the bi-directional mode of the 1+1 architecture. The exercise command is specified in the tools>perform>aps>force>exercise context and exercises the protection line by sending an exercise request over the protection line to the tail-end and expecting a reverse request response back. The switch is not actually completed during the exercise routine.

2.3.2.13.9 APS and SNMP

SNMP Management of APS uses the APS-MIB (from rfc3498) and the TIMETRAAPS-MIB.

Table 30 shows the mapping between APS switching modes and MIB objects.

Table 30 Switching Mode to MIB Mapping

switching-mode TIMETRA-APS-MIB

tApsProtectionType

Bidir 1+1 Sig APS (bi-directional)

onePlusOneSignalling (1) bidirectional

APS-MIB apsConfigDirection

(2)

Uni 1+1 Sig APS (uni-directional)

Issue: 01 3HE 11968 AAAC TQZZA 01 95

onePlusOneSignalling (1) unidirectional

(1)

Page 96

Interfaces

Table 30 Switching Mode to MIB Mapping (Continued)

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

switching-mode TIMETRA-APS-MIB

tApsProtectionType

Uni 1+1 Sig+Data APS (uni-1plus1)

onePlusOne (2)

apsConfigMode in the APS-MIB is set to onePlusOneOptimized for Annex B operation.

2.3.2.13.10 APS Applicability, Restrictions and Interactions

Note: The Release Notes for the relevant SR OS release should be consulted for details

about APS restrictions.

Table 31 shows the supported APS mode combinations.

Table 31 Supported APS Mode Combinations

Bidirectional 1+1 Signaling APS

Unidirectional 1+1 Signaling APS

APS-MIB apsConfigDirection

unidirectional (1)

Unidirectional 1+1 Signaling and Datapath APS

Single Chassis APS (SC-APS)

Multi-Chassis APS (MC-APS)

Supported

Supported Not supported Not supported

Note:

1. TDM satellite supports this mode only.

Supported Supported for 7750 SR-c4/12

platforms only

APS and Bundles

Bundles (such as IMA and MLPPP) can be protected with APS through the use of Bundle Protection Groups (BPGRP). For APS-protected bundles, all members of a working bundle must reside on the working port of an APS group. Similarly all members of a protecting bundle must reside on the protecting circuit of that APS group. Bundles are not supported on TDM satellite.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 97

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

IMA APS protection is supported only when the router is connected to another piece of equipment (possibly through an ADM) running a single IMA instance at the far end. By design, the IMA APS implementation is expected to keep the IMA protocol up as long as the far end device can tolerate some frame loss. Similarly, the PPP protocol state machine for PPP channels and MLPPP bundles remains UP when a switchover occurs between the working and protect circuits.

When APS protects IMA groups, IMA control cells, but not user traffic, are sent on the inactive circuit (as well as the active) to keep the IMA protocol up during an APS switch.

For details on MLFR/FRF.12 support with APS see MLFR/FRF.12 Support of APS,

BFD, and Mirroring Features.

APS Switchover Impact on Statistics

All SAP-level statistics are retained with an APS switch. A SAP will reflect the data received regardless of the number of APS switches that has occurred. ATM statistics, however, are cleared after an APS switch. Thus, any ATM statistics viewed on an APS port are only the statistics since the current active member port became active.

Interfaces

Physical layer packet statistics on the APS group reflect what is currently on the active member port.

Port and path-level statistics follow the same behavior as described above.

Any SONET physical-layer statistics (for example, B1,B2,B3,...) on the APS port are only what is current on the active APS member port.

Supported APS MDA/Port Combinations

Table 32 shows examples of the port types that can be paired to provide APS

protection. Both ports must be the same type and must be configured at the same speed.

Issue: 01 3HE 11968 AAAC TQZZA 01 97

Page 98

Interfaces

Table 32 MDA/Port Type Pairing for APS

INTERFACE CONFIGURATION GUIDE

RELEASE 15.0.R5

MDA Type Unchannelized

SONET/SDH (POS) For example: m16-oc12/3sfp

Unchannelized SONET/SDH (POS)

For example: m16-oc12/3-sfp

ATM For example:

m4-atmoc12/3sfp

Circuit Emulation (CES)

For example: m4-choc3-cessfp

Supported — — — —

— Supported — — —

— — Supported — —

ATM For example: m4-atmoc12/3sfp

Circuit Emulation (CES) For example: m4-choc3-cessfp

Channelized Any Service Any Port (ASAP) For example: m1-choc12-assfp

SONET/SDH Satellite

Channelized Any Service Any Port (ASAP)

For example: m1-choc12-assfp

SONET/SDH Satellite

— — — Supported —

————

Supported

For example, an APS group can be comprised of a pair of ports where each port is on one of the two following MDAs:

• m16-atmoc3-sfp

• m4-atmoc12/3-sfp (port in oc3 mode)

For example, an APS group can not be comprised of a pair of ports where one port is on an m16-oc12/3-sfp and the other port is on an m1-choc12-as-sfp.

3HE 11968 AAAC TQZZA 01 Issue: 01

Page 99

INTERFACE CONFIGURATION GUIDE RELEASE 15.0.R5

APS Switchover During CFM/CPM Switchover

An APS switchover immediately before, during or immediately after a CFM/CPM switchover may cause a longer outage than normal.

Removing or Failure of a Protect MDA

The detection of a CMA/MDA removal or a CMA/MDA failure can take additional time. This can affect the APS switchover time upon the removal or failure of a protection CMA/MDA. If the removal is scheduled during maintenance, it is recommended that the port and/or protect circuit be shutdown first to initiate an APS switchover before the CMA/MDA maintenance is performed.

Mirroring Support

Mirroring parameters configured on a specific port or service, are maintained during an APS failover.

Interfaces

2.3.2.13.11 Sample APS Applications

The following subsections provide sample APS application examples.

Sample APS Application: MLPPP with SC-APS and MC-APS on Channelized Interfaces

The 7750 SR supports APS on channelized interfaces. This allows the router to be deployed as the radio access network (RAN) aggregation router which connects the base transceiver station (BTS) and the radio network controller (RNC).

Figure 21 shows an example of MLPPP termination on APS protected channelized

OC-n/STM-n links. This example illustrates the following:

• SC-APS (the APS circuits terminate on the same node aggregation router A).

• APS protecting MLPPP bundles (bundles are between the BTS and aggregation router A, but APS operates on the SONET links between the DACS and the aggregation router).

• APS on channelized access interfaces (OC-3/OC-12 links).

Issue: 01 3HE 11968 AAAC TQZZA 01 99

Page 100

Interfaces

INTERFACE CONFIGURATION GUIDE

Figure 21 SC-APS MLPPP on Channelized Access Interfaces Example

OAM PDSN, AAA

RELEASE 15.0.R5

EV-DO

BTS

PRS

BITS I/F

T1 # 2

DACS

T1 # 1

RAN Data VLAN

Hand-off Network VLAN

PDSN, AAA VLAN

OAM VLAN

T3/OC-3/OC-12

DHCP Relay

Aggregation

Router A

MLS B

GigE

MLS A

Hand-off Network

GigE

Switch

GigE

Switch

OSSG142

Figure 22 shows an APS group between a digital access cross-connect system

(DACS) and a pair of aggregation routers. At one end of the APS group both circuits (OC-3/STM-1 and/or OC-12/STM-4 links) are terminated on the DACS and at the other end each circuit is terminated on a different aggregation routers to provide protection against router failure. The MLPPP bundle operates between the BTS and the aggregation routers. At any one time only one of the two aggregation routers is actually terminating the MLPPP bundle (whichever aggregation router is processing the active APS circuit).

100

This example shows the following:

• MC-APS (the APS circuits terminate on different aggregation routers)

• APS protecting MLPPP bundles (bundles are between the BTS and the aggregation routers but APS operates on the SONET links between the DACS and the aggregation routers)

• APS on channelized access interfaces (OC-3/OC-12 links)

3HE 11968 AAAC TQZZA 01 Issue: 01

Nokia 7450 ESS, 7750 SR, 7950 XRS Interface Configuration Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Table of Contents

1 Getting Started

1.1 About This Guide

1.2 Interface Configuration Process

2 Interfaces

2.1 Configuration Overview

2.1.1 Chassis Slots and Cards

2.1.2 MCMs

2.1.3 MDA-a, MDA-aXP, MDA, MDA-XP and MDA-e Modules

2.1.4 XMAs/C-XMAs

2.1.5 CMAs

2.1.6 Versatile Service Module (VSM)

2.1.7 Oversubscribed Ethernet MDAs

2.1.7.1 Rate Limiting

2.1.7.2 Packet Classification and Scheduling

2.1.8 Channelized MDA/CMA Support

2.1.8.1 Channelized DS-1/E-1 CMA

2.1.8.2 Channelized DS-3/E-3 CMA

2.1.8.3 Channelized Any Service Any Port (ASAP) CHOC-3/STM-1

2.1.8.4 Channelized OC-12/STM-4 ASAP MDAs

2.1.8.5 Channelized DS-3/E-3 ASAP MDA (4-Port)

2.1.8.6 Channelized DS-3/E-3 ASAP MDA (12-Port)

2.1.8.7 Channelized OC-3/STM-1 Circuit Emulation Services (CES) CMA and MDA

2.1.8.8 Network Interconnections

2.2 Digital Diagnostics Monitoring

2.2.1 SFPs and XFPs

2.2.2 Statistics Collection

2.3 Ports

2.3.1 Port Types

2.3.2 Port Features

2.3.2.1 Port State and Operational State

2.3.2.2 802.1x Network Access Control

2.3.2.3 MACsec

2.3.2.4 SONET/SDH Port Attributes

2.3.2.5 SONET/SDH Path Attributes

2.3.2.6 Multilink Frame Relay

2.3.2.7 FRF.12 End-to-End Fragmentation

2.3.2.8 FRF.12 UNI/NNI Link Fragmentation

2.3.2.9 MLFR/FRF.12 Support of APS, BFD, and Mirroring Features

2.3.2.10 Multilink Point-to-Point Protocol (MLPPP)

2.3.2.11 Multi-Class MLPPP

2.3.2.12 Cisco HDLC

2.3.2.13 Automatic Protection Switching (APS)