Tellabs 8611 Configuration Guide
Tellabs 8611 Configuration Guide
76.8610-50149A
18.08.2011
Document Information
Revision History
This Tellabs manual is owned by Tellabs or its licensors and protected by U.S. and international copyright laws, conventions and
treaties. Your right to use this manual is subject to limitations and restrictions imposed by applicable licenses and copyright laws.
Unauthorized reproduction, modification, distribution, display or other use of this manual may result in criminal and civil penalties.
The following trademarks and service marks are owned by Tellabs Operations, Inc. or its affiliates in the United States and/or
other countries: TELLABS ®, TELLABS ® logo, TELLABS and T symbol ®, and T symbol ®.
Any other company or product names may be trademarks of their respective companies.
The specifications and information regarding the products in this manual are subject to change without notice. All statements,
information, and recommendations in this manual are believed to be accurate but are presented without warranty of any kind,
express or implied. Users must take full responsibility for their application of any products.
Adobe ® Reader ® are registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.
2
Document Information
Term Explanation
AAL ATM Adaptation Layer
ACFC Address and Control Field Compression
AIS Alarm Indication Signal
ATM Asynchronous Transfer Mode
BE Best Effort
BER Bit Error Ratio
BFD Bidirectional Forwarding Detection
CAC Connection Admission Control
CBR Constant Bit Rate
CESoPSN Circuit Emulation Service over Packet Switched Network
CLI Command Line Interface
CRC Cyclic Redundancy Check
DEG Degraded
ESF Extended Super Frame
FCS Frame Check Sequence
FE Fast Ethernet
GE Gigabit Ethernet
HDLC High-Level Data Link Control
HM High speed Module
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IMA Inverse Multiplexing for ATM
IP Internet Protocol
IPCP IP Network Control Protocol of the PPP
IS-IS Intermediate System to Intermediate System (Interior Gateway Protocol)
LAN Local Area Network
LCP Link Control Protocol
LLC Logical Link Control
LM Line Module
LOF Loss Of Frame
MAC Media Access Control
MC-MLPPP Multiclass MLPPP
MGE Management GE
3
Document Information
4
Document Information
5
Tellabs ® 8600 Managed Edge System 76.8610-50149A
Tellabs ® 8609 Access Switch FP1.0 Tellabs ® 8611 Access Switch FP1.1 Interface Configuration Guide © 2011 Tellabs.
6
Table of Contents
Table of Contents
Objectives....................................................................................................................................................................... 10
Audience......................................................................................................................................................................... 10
Related Documentation .................................................................................................................................................. 10
Interface Numbering Conventions ................................................................................................................................. 11
Document Conventions .................................................................................................................................................. 12
Documentation Feedback............................................................................................................................................... 12
1 Overview ...................................................................................................................... 13
7
Table of Contents
6 Performance Monitoring............................................................................................. 28
8 References ................................................................................................................... 34
8
Table of Contents
Layer Descriptions............................................................................................................ 55
9
About This Manual
• Objectives
• Audience
• Related Documentation
• Conventions
• Documentation Feedback
Objectives
This manual provides an overview of the Tellabs 8609 access switch and Tellabs 8611 access switch
interface functions and instructions on how to configure them using Command-Line Interface (CLI)
and ASCII textual commands with a router’s console or remote terminal (Telnet).
Audience
This manual is designed for administration personnel for configuring the Tellabs 8609 access switch
and Tellabs 8611 access switch interface functions with CLI. On the other hand, Tellabs ® 8000
Intelligent Network Manager provides access to equal functionality for administration personnel
with a graphical user interface.
It is assumed that you have a basic understanding of networks and network interfaces of different
technologies (ATM, PDH, PPP, Ethernet).
Related Documentation
The document numbering scheme consists of the document ID, indicated by numbers, and the
document revision, indicated by a letter. The references in the Related Documentation table below
are generic and include only the document ID. To make sure the references point to the latest
available document versions, please refer to the relevant product document program on the Tellabs
Portal by navigating to www.portal.tellabs.com > Product Documentation > Data Networking >
Tellabs 8600 Managed Edge System > Technical Documentation.
10
About This Manual
Tellabs ® 8600 Managed Edge System FP1.1 Describes network element features: enclosure,
Tellabs ® 8611 Access Switch Reference baseboard, interfaces and power supply modules.
Manual (76.8611-40087)
Tellabs ® 8600 Managed Edge System ATM and Provides an overview of Tellabs 8600 system ATM
TDM Configuration Guide (76.8600–50110) and TDM functions and instructions on how to
configure them with CLI.
Tellabs ® 8600 Managed Edge System CLI Provides commands available to configure, monitor
Commands Manual (76.8600-50117) and maintain Tellabs 8600 system products with CLI.
Tellabs ® 8600 Managed Edge System Provides an overview of Tellabs 8600 system HW
Equipment Management Configuration Guide inventory, software management and CDC equipment
(76.8600-50118) protection and instructions on how to configure them
with CLI.
Tellabs ® 8600 Managed Edge System Ethernet Provides an overview of Tellabs 8600 system Ethernet
Configuration Guide (76.8600-50133) Applications and instructions on how to configure
them with CLI.
Tellabs ® 8600 Managed Edge System Provides an overview of Tellabs 8600 system fault
Fault Management Configuration Guide management and instructions on how to configure it
(76.8600-50115) with CLI.
Tellabs ® 8600 Managed Edge System Provides an overview of Tellabs 8600 system IP
IP Forwarding and Traffic Management forwarding and traffic management and instructions
Configuration Guide (76.8600-50122) on how to configure them with CLI.
Tellabs ® 8600 Managed Edge System Provides an overview of Tellabs 8600 system MPLS
MPLS Applications Configuration Guide applications and instructions on how to configure
(76.8600-50123) them with CLI.
Tellabs ® 8600 Managed Edge System Provides an overview of Tellabs 8600 system
Synchronization Configuration Guide synchronization functions and instructions on how to
(76.8600-50114) configure them with CLI.
Tellabs ® 8600 Managed Edge System Test Provides an overview of Tellabs 8600 system testing
and Measurement Configuration Guide and measurement tools, connectivity verification and
(76.8600-50124) instructions on how to configure them with CLI.
Tellabs ® 8000 Intelligent Network Manager Provides instructions on how different operations
Online Help are performed with Tellabs 8000 intelligent network
manager. Describes also different parameters and
controls of the Tellabs 8000 intelligent network
manager dialogs and windows.
Note that the online help is not available on the portal
but it is incorporated in Tellabs 8000 intelligent
network manager.
To be able to follow more easily the feature descriptions and configuration examples given in this
document, see also the Tellabs 8600 system interface numbering and related figures described in
Tellabs ® 8600 Managed Edge System CLI Commands Manual.
11
About This Manual
Document Conventions
This is a caution symbol. It indicates that damage to equipment is possible if the instructions
are not followed.
This is a warning symbol. It indicates that bodily injury is possible if the instructions are not
followed.
Documentation Feedback
Email: [email protected]
Fax: +358.9.4131.2430
12
1 Overview
1 Overview
This document gives an overview of the data service interface features supported by the Tellabs
8609 access switch and Tellabs 8611 access switch. The emphasis is on the software configuration
of the interfaces. The existing components, their features and installation instructions are presented
in the documents mentioned below.
Tellabs ® 8600 Managed Edge System Tellabs ® 8609 Access Switch Reference Manual and Tellabs ®
8600 Managed Edge System Tellabs ® 8611 Access Switch Reference Manual and Tellabs ® 8600
Managed Edge System Hardware Installation Guide provide more information about the Network
Element (NE) including the supported Physical Line Modules (PLMs) and interfaces.
13
2 Network Element Interfaces
2.1.1 Overview
The Tellabs 8609 access switch provides fixed Ethernet interfaces and two slots for the Line
Modules (LM). The NE supports numerous layer 2 and 3 protocols needed on the edge of the data
network to adapt various TDM, cell and packet based services to the IP/MPLS.
The Tellabs 8609 access switch supports up to 12 Ethernet interfaces, which are fixed to the
chassis of the NE. There are two virtual modules, M0 and M1, with each comprising of 4 Ethernet
interfaces that support 100/1000BASE-X modes, in total there are 8 optical Gigabit Ethernet
interfaces available. An additional virtual module M2, comprises 4 Ethernet interfaces that support
10/100BASE-TX/1000BASE-T modes.
Ethernet Interfaces
The Ethernet interface functionality is implemented according to [IEEE 802.3]. At ingress, the
Ethernet interfaces accept frames with length or type encoding. The length encapsulated frames
support LLC/SNAP according to [IEEE 802.3]. At egress, the Ethernet interface always generates
frames with type encapsulation.
The NE supports VLAN tagging on Ethernet interfaces. All interfaces can accept VLAN
tagged, priority-tagged and untagged frames. The interface performs input filtering based on the
VLAN identifiers. The Ethernet ports can be configured to optionally discard all untagged and
priority-tagged frames. A VLAN identifier can be selected from the full VLAN identifier space
(1–4095 are valid values, 0 and 4096 are reserved).
14
2 Network Element Interfaces
• Synchronous Ethernet concept where the received line clock can be used as a reference to the
timing block and the Ethernet egress can be synchronized from the timing block
• Ethernet line and equipment loopbacks
• Support of IEEE802.1ag Ethernet OAM Fault Management
• Loopback (ping) function
• Continuity check function
• Linktrace function
• Support of ITU-T Y.1731 Performance Monitoring
• Frame loss ratio
• Frame delay
• Frame delay variation
• Support of IEEE1588 slave frequency synchronization
Configuration Option
Ethernet Physical Layer Configuration
Ethernet Layer Failure Reporting
The Tellabs 8609 access switch provides two line module slots, M3 and M4, for the LMs. Any
combination of the supported LMs is allowed in the slots. The following are the LMs currently
supported:
• 8xchE1/chT1
• 8x10/100BASE-TX
2.2.1 Overview
The Tellabs 8611 access switch provides a flexible modular architecture, allowing the NE to
be equipped with various combination of Physical Line Module (PLM) types. The NE supports
numerous layer 2 and 3 protocols needed on the edge of the data network to adapt various TDM, cell
and packet based services to the IP/MPLS. There are several types of PLMs supported by the NE:
15
2 Network Element Interfaces
The Tellabs 8611 access switch provides four PLM slots, numbered M0 through M3 for the LMs
and three PLM slots, numbered M4 through M6, for the HMs. The NE architecture set some rules to
the PLMs equipping as following:
• There can be furnished up to four 8xchE1/chT1 LMs without any interference with the HMs.
• The 8x10/100BASE-TX LM, the 4x100/1000BASE-X and the 4x10/100/1000BASE-TX HMs
share resources in the NE.
• A maximum of three 8x10/100BASE-TX LMs are supported and they can be in any of the four
LM slots.
• Any combination of 4x100/1000BASE-X HMs and 4x10/100/1000BASE-TX HMs is allowed.
The following two figures illustrate possible combination of PLMs equipping in the Tellabs 8611
access switch:
16
2 Network Element Interfaces
Fig. 1 LM Combination
Fig. 2 HM Combination
17
3 Physical Line Modules
3.1.1 8xchE1/chT1 LM
Overview
The 8xchE1/chT1 LM provides 8 physical E1/T1 interfaces with HDB3/B8ZS line coding and
supports numerous layer 2 and 3 protocols needed on the edge of the data network to adapt various
TDM, cell and packet based services to the IP/MPLS.
• E1 mode
• Each interface supports unframed and framed P12s [G.704], [G.706] modes
• G.826 performance monitoring
• T1 mode
• Each interface supports DS1 framed [T1.403] and unframed modes
• Unframed, D4 Super Frame (SF) and Extended Super Frame (ESF) formats
• Remote line loopback
• GR-253/GR-820 performance monitoring
• E1 and T1 modes
• ATM/IMA payload, (ML)PPP, PPPmux, SAToP PWE3, CESoPSN PWE3, HDLC PWE3,
P12s/DS1 XC
• ATM/IMA group and MLPPP group across configuration LMs
• Non-intrusive P12s/DS1 frame monitoring for SAToP
• L1 line and equipment loops
• Adaptive timing from SAToP and CESoPSN PWE3 to physical E1/DS1 interface
18
3 Physical Line Modules
NE and LM Type: Tellabs 8609 Access Switch, Tellabs 8611 Access Switch and 8xchE1/chT1
MS
TLP Type Unframed Framed Nx64k (for ATM and
MLPPP N is fixed)
Service IP MPLS PWE3 IP MPLS PWE3
Routing Switching Routing Switching
cHDLC — — — — — —
HDLC — — X — — X
FR — — — — — —
(ML)PPP X X X (PPP X X (PPP only)
only)
ETHo(ML)PPP — — — — — X
ATM — — — X — X
2M/1.5M TDM — — X — — —
Nx64 TDM — — — — — X
E1/DS1 Interface
ATM Features
The ATM configured tributary enables the NE to be connected via an SDH transport network to
another device using ATM interfaces. The interfaces support simultaneous ATM switching, ATM
PWE3 tunneling [RFC 4717] and IP routing functions on an ATM-circuit basis.
All tributaries and ATM circuits can be configured independently on each layer. The 8xchE1/chT1
LM supports UNI and NNI interface types. As the NE supports a permanent type of ATM circuits,
the UNI/NNI configuration parameter has an impact only to the available VPI range. The following
protocol encapsulations are available:
19
3 Physical Line Modules
HDLC Features
HDLC PWE3 tunneling enables tunneling of the PPP in a transparent way [RFC4618].
The TDM configured PDH interface enables the NE to provide transparent primary rate TDM circuit
emulation services over an MPLS network. The P12s/DS1 signal is encapsulated as unframed to a
TDM PWE3 circuit with SAToP encapsulation according to [RFC4553]. Frame alignment can be
optionally monitored.
The TDM-configured PDH interface enables the NE to provide Nx64k TDM circuit emulation
services over an MPLS network. The P12s/DS1 signal is terminated and desired Nx64k signals
(timeslot groups) are encapsulated to a TDM PWE3 circuit with CESoPSN encapsulation according
to [RFC5086].
The PPP and Multilink PPP (MLPPP) interface enables the NE to be connected to another Tellabs
8600 NE or third party equipment using a single logical link having capacity of several P12s/DS1
[RFC1990]. Within MLPPP the following features are supported:
• PPP Multiplexing (PPPMux) [RFC3153], for more details refer to PPPMux Layer Configuration;
• MC-MLPPP [RFC2686], for more details refer to MC-MLPPP Layer Configuration;
The PPP link is terminated and may carry IP traffic towards a customer router, or MPLS traffic
towards an MPLS core network. Both framed and unframed E1 and DS1 are supported.
The PPP/MLPPP interface supports also Ethernet over PPP and Ethernet over MLPPP encapsulation.
However only port mode Ethernet PWE3 is supported. For more Ethernet details please refer to
Tellabs ® 8600 Managed Edge System Ethernet Applications Configuration Guide.
The TDM cross-connection support enables the NE to be used as a native P12x (unstructured
E1/DS1) TDM cross-connect device.
Configuration Option
E1 Physical Layer Configuration
20
3 Physical Line Modules
Configuration Option
P12s Layer Configuration
DS1 Physical Layer Configuration
DS1 Layer Configuration
ATM Interface (Transmission Convergence) Layer Configuration
ATM IMA Interface Configuration
HDLC Interface Layer Configuration
Unframed E1/T1 SAToP TDM PWE3 Layer Configuration
Nx64k CESoPSN TDM PWE3 Layer Configuration
PPP Layer Configuration
MLPPP Layer Configuration
Fault Management
The 8xchE1/chT1 LM supports G.826 performance monitoring for E1/P12s layers as described in
chapter 6.1.1 G.826 Performance Monitoring.
3.1.2 8x10/100BASE-TX LM
Overview
The 8-port Fast Ethernet LM supports eight 10/100BASE-TX. The Ethernet interface functionality
is implemented according to [IEEE 802.3]. At ingress, the Ethernet interfaces accept frames with
length or type encoding. The length encapsulated frames support LLC/SNAP according to [IEEE
802.3]. At egress, the Ethernet interface always generates frames with type encapsulation.
The NE supports VLAN tagging on Ethernet interfaces. All interfaces can accept VLAN-tagged,
priority-tagged and untagged frames. Double tagged VLAN frames 802.1q-in-q are also supported.
The interfaces perform input filtering based on the VLAN identifiers. The Ethernet ports can be
configured to optionally discard all untagged and priority-tagged frames. A VLAN identifier can be
selected from the full VLAN identifier space (1–4095 are valid values, 0 and 4096 are reserved).
21
3 Physical Line Modules
• Auto-negotiation function, which can be optionally disabled. In such cases a manually configured
operation mode (speed, half/full duplex) is used
• Ethernet line and equipment loopbacks
• Synchronous Ethernet concept where the received line clock can be used as a reference to timing
block and the Ethernet egress can be synchronized to timing block
• Support of IEEE802.1ag Ethernet OAM Fault Management
• Loopback (ping) function
• Continuity check function
• Linktrace function
• Support of ITU-T Y.1731 Performance Monitoring
• Frame loss ratio
• Frame delay
• Frame delay variation
Layer Configuration
Configuration Option
Ethernet Physical Layer Configuration
Ethernet Layer Failure Reporting
The Tellabs 8611 access switch provides support for High speed Modules (HM) covered in this
section.
3.2.1 4x100/1000BASE-X HM
Overview
The Ethernet interface functionality is implemented according to [IEEE 802.3]. At ingress, the
Ethernet interfaces accept frames with length or type encoding. The length encapsulated frames
support LLC/SNAP according to [IEEE 802.3]. At egress, the Ethernet interface always generates
frames with type and length encoding.
The Tellabs 8600 system supports VLAN tagging on Ethernet interfaces. All interfaces can accept
VLAN-tagged, priority-tagged and untagged frames. Double tagged VLAN frames 802.1q-in-q
are also supported. The interfaces perform input filtering based on the VLAN identifiers. The
Ethernet ports can be configured to optionally discard all untagged and priority-tagged frames. A
VLAN identifier can be selected from the full VLAN identifier space (1–4095 are valid values, 0
and 4096 are reserved).
22
3 Physical Line Modules
Layer Configuration
Configuration Option
Ethernet Physical Layer Configuration
Ethernet Layer Failure Reporting
Ethernet OAM
3.2.2 4x10/100/1000BASE-TX HM
Overview
The Ethernet interface functionality is implemented according to [IEEE 802.3]. At ingress, the
Ethernet interfaces accept frames with length or type encoding. The length encapsulated frames
support LLC/SNAP according to [IEEE 802.3]. At egress, the Ethernet interface always generates
frames with type and length encoding.
23
3 Physical Line Modules
The Tellabs 8600 system supports VLAN tagging on Ethernet interfaces. All interfaces can accept
VLAN-tagged, priority-tagged and untagged frames. Double tagged VLAN frames 802.1q-in-q
are also supported. The interfaces perform input filtering based on the VLAN identifiers. The
Ethernet ports can be configured to optionally discard all untagged and priority-tagged frames. A
VLAN identifier can be selected from the full VLAN identifier space (1–4095 are valid values, 0
and 4096 are reserved).
Layer Configuration
Configuration Option
Ethernet Physical Layer Configuration
Ethernet Layer Failure Reporting
Ethernet OAM
24
4 Management Port (MGMT)
The Tellabs 8611 access switch can have two SCMs for equipment protection purposes. Each SCM
has its own MGMT port. The MGMT port is automatically protected if the SCM is protected. The
MGMT port protection mechanism of the Tellabs 8600 system resembles the MSP1+1/ APS1+1
protection scheme used for STM-N POS interfaces. The protected MGMT port shares the same
configuration except for the MAC address that is unique in both sides. Status information, fault
reports and counters are gathered separately for both MGMT ports. Depending on the line status and
the equipment status of the SCMs, one of the two MGMT ports is active passing traffic through,
while the other MGMT port is passive. The passive MGMT port drops traffic at ingress direction.
25
5 Fault Management Operation and Configuration
5.1.1 Principles
The fault management processing (f1, f2, f3 and f4 filter) of TDM layers is done according to
[G.806] and [ETS 300 417-7-1].
Defect filter f1, consequent action filter f2 and fault cause filter f3 are components of the fault
management process located within atomic functions (e.g. a trail termination point). These filters are
specified per atomic function and the time constants are fixed. Defect filter f1 integrates anomalies
into defects by performing a persistency check.
Consequent action filter f2 controls consequent actions (for instance AIS, RDI or SSF) that are
generated by an atomic function due to a detected defect.
A fault can cause multiple defect detectors to be activated. The activated defects are correlated
by a fault cause filter f3 to obtain the fault cause (correlated defect). The fault cause filter can
also suppress the fault according to management information. The parameters that are used for
suppression are atomic function specific (for example, AISreported, RDIreported, LOCreported).
Suppression of a fault has an impact only on the emitting of a particular fault, it does not suppress
the fault from the correlation processes for the upper layer alarms. The f2 and f3 filters are only
applied to TDM layer (layer L1) defects by the Tellabs 8600 NE.
Failure filter f4 integrates fault cause failures (detected faults) by performing a persistency check on
the fault before it declares the fault cause a failure [ETS 300 417-7-1]. A fault persistency filter is
used in order to reduce failures that are reported to the management system. A TDM transmission
failure is declared if the fault cause continuously persists for approximately 2.5 ± 0.5 seconds. The
failure is cleared if the fault cause is continuously absent for approximately 10 ± 0.5 seconds, the
exception is DS1 AIS which has a 15 seconds clearing time.
26
5 Fault Management Operation and Configuration
In the Tellabs 8600 system AIS, RDI and SSF faults are suppressed by default. This is based on the
principles that in a homogenous Tellabs 8600 NE a network failure is reported only once by the NE
which detects the primary reason of the failure. E.g. in the case of a received AIS signal the fault is
not reported by default because the root cause of the fault is not detected by the particular NE.
Typically the AIS reporting should be activated within the boundaries of the network areas managed
by different management systems or network operators.
27
6 Performance Monitoring
6 Performance Monitoring
The following table shows the performance monitoring (G.826 and GR-253/GR-820) supported for
each TDM interface.
The TDM interface can report 15-min and 24-hour current statistics and 15-minute and 24-hour
history statistics for the primitives as indicated in the following table. Both near-end and far-end
performance monitoring is supported. The unavailable seconds are counted separately for the
near-end and far-end. The NE stores 1 history 24-hour record and 31 15-minute history records
for each supported primitive. Monitoring is according [G.826].
28
6 Performance Monitoring
The TDM interface can report 15-min and 24-hour current statistics and 15-minute and 24-hour
history statistics for the primitives as indicated in the following table. Both near-end and far-end
performance monitoring is supported. The unavailable seconds are counted separately for the
near-end and far-end. The NE stores 1 history 24-hour record and 31 15-minute history records
for each supported primitive.
For detailed DS1 performance monitoring functionality [GR-253] refers to [GR-820]. The DS1
far-end information is supported only in ESF mode which supports far-end defect reporting.
29
7 ANSI Loopback Operations
The line loopback loops the received DS1 signal from DS1 line back to the line. The line loopback
can be controlled by local configuration using CLI or Tellabs 8000 intelligent network manager,
or remotely by responding to a remote loopback request commands received from the line side of
the DS1 interface. Line loopback is supported when the DS1 is terminated and also when the DS1
signal is transparently connected to SAToP PWE3. Both the local line loopback setting and the
remote command received from the DS1 line side control the same physical loop entity and the
latest action is in force. Analogously the loopback activated by both methods is released after the
loop timeout timer expires.
The equipment loopback loops the transmitted DS1 signal from DS1 line back to the equipment.
The equipment loopback is typically controlled by local configuration using CLI or Tellabs 8000
intelligent network manager. Both the local equipment loopback setting and remote command
received from the DS1 equipment side controls the same physical equipment loop entity and
the latest action is in force. In the SAToP service the remote loopback request can be received
from the equipment side of the DS1 interface over the SAToP PWE3. In this case the equipment
loopback is performed. Analogously the loop activated by both the methods is released after the
loop timeout timer expires.
The operator can invoke a remote loopback by generating a remote loopback command. In the
Tellabs 8600 system it is possible to generate the commands only to the line direction of the DS1
interface. The remote loopback request does not contain any dedicated information about the
line/equipment loop selection. It is up to the receiver to decide which one of the loops is activated
on the basis of the direction where the request is received.
30
7 ANSI Loopback Operations
The Tellabs 8600 system supports inband and bit-patterned methods with a wide set of
activation/deactivation codes as shown in the table below.
Inband Method
The inband method is available both in the terminated framed DS1 interface and unframed
(SAToP) DS1 interface. When the remote loopback is invoked, the interface sends the configured
activation/deactivation codes among the user data for a five-second period. If the far-end is capable
of detecting the codes, it performs the loop. The request causes a five-second break to the user
traffic. The Tellabs 8600 system monitors only one activation/deactivation code pair at the time in a
particular DS1 interface and therefore the code pair is configurable. The default code is 1-in-5/1-in-3.
If the interface is in Framed mode (SF or ESF), it generates framed inband commands and, when
the interface is in Unframed mode (connected to SAToP PWE3), it generates unframed inband
commands. The DS1 interface always monitors both framed and unframed inband commands.
Bit-Patterned Method
The bit-patterned method is available only in ESF mode and only in the end points of the DS1 path.
The commands are carried over the facility data link and are available only in ESF mode. When the
remote loopback is invoked, the interface sends the activation/deactivation code 10 times to the
facility data link. If the far-end is capable of detecting the codes, it performs the loop. The Tellabs
8600 system monitors all the activation/deactivation codes shown in the table above at the time in a
particular DS1 interface without any configuration.
• Examples a) and b) in the figure below show CLI or Tellabs 8000 intelligent network manager
activated line and equipment loopback operations.
• Example c) in the figure below shows a remote loopback over the whole DS1 path. The Tellabs
8600 system is transparent for the request. The transparency can be achieved by disabling the
remote loopback function in the Tellabs 8600 system or using bit-patterned commands which
are carried over the facility data link or using inband commands when intermediate elements
(Monitor= A/B) and terminating elements (Monitor=C) use different inband codes.
31
7 ANSI Loopback Operations
• Example d) in the figure below shows how a line loopback is activated remotely. The DS1 inter-
faces in the Tellabs 8600 NEs are in unframed modes and therefore only inband commands can
be sent and received. However, both unframed and framed inband commands are available.
• Example e) in the figure below shows how an equipment loopback is activated remotely. The DS1
interfaces in the Tellabs 8600 NEs are in unframed modes and therefore only inband commands
can be sent and received. However, both unframed and framed inband commands are available.
• Examples a) and b) in the figure below show CLI or Tellabs 8000 intelligent network manager
activated line and equipment loopback operations.
• Example c) in the figure below shows how an equipment loopback is activated remotely. Both
inband and bit-oriented commands can be used.
32
7 ANSI Loopback Operations
Fig. 5 DS1 Loops in the Case of DS1 Multiservice Interface and DS1 CESoPSN PWE3 Service
33
8 References
8 References
[af-arch-0193.000] af-arch-0193.000 (2002-11), ATM User-Network Interwork Interface
(UNI) Specification Version 4.1
[af-phy-0054.000] af-phy-0054.000 (1996-01), DS3 Physical Layer Interface Specification
[af-phy-0086.000] af-phy-0086.000 (1997-07), Inverse multiplexing for ATM (IMA)
specification version 1.0
[af-phy-0086.001] af-phy-0086.001 (1999-09), Inverse multiplexing for ATM (IMA)
specification version 1.1
[af-tm-0121.000] af-tm-0121.000 (1999-03), Traffic management specification version 4.1
[af-uni-0010.002 ] af-uni-0010.002 (1994–09), ATM User-Network Interface Specification
Version 3.1
[ETS 300 417-7-1] ETSI EN 300 417-7-1 V1.1.1 (2000-10); Transmission and Multiplexing
(TM); Generic requirements of transport functionality of equipment;
Part 7-1: Equipment management and auxiliary layer functions
[G.704] ITU-T Recommendation G.704 (1998-10), Synchronous frame
structures used at 1544, 6312, 2048, 8448 and 44 736 Kbps hierarchical
levels
[G.705] ITU-T Recommendation G.705 (2000-10), Characteristics of
plesiochronous digital hierarchy (PDH) equipment functional blocks
[G.781] ITU-T Recommendation G.781 (1999-07), Synchronization layer
functions
[G.806] ITU-T Recommendation G.806 (2006-03), Characteristics of transport
equipment – Description methodology and generic functionality
[G.813] ITU-T Recommendation G.813 (2003-03), Timing characteristics of
SDH equipment slave clocks (SEC)
[G.826] ITU-T Recommendation G.826 (2002–12) End-to-end error performance
parameters and objectives for international, constant bit-rate digital paths
and connectionsTypes and characteristics of SDH network protection
architectures
[GR-253] Telecordia, GR-253 (2005), Issue 4 – Synchronous optical network
transport systems: common generic criteria
[GR-312] Telecordia, GR-312 (2003-10), Functional Criteria for the DS1 Interface
Connector
[GR-499] Telecordia, GR-499 (2004-09), Transport Systems Generic Requirements
(TSGR): Common Requirements
[GR-820] Telecordia, GR-820–CORE (1997), Issue 2 – Generic Digital
Transmission Surveillance
[I.361] ITU-T Recommendation I.361 (1999-02), B-ISDN ATM layer
specification
[I.371] ITU-T Recommendation I.371 (2000-03), Traffic control and congestion
control in B-ISDN
[I.432.1] ITU-T Recommendation I.432.1 (1999-02), B-ISDN user-network
interface – Physical layer specification: General characteristics
34
8 References
35
9 Interface Configuration Examples
For more details on ATM related functionality, refer to Tellabs ® 8600 Managed Edge System ATM
and TDM Configuration Guide. For a full list of interface configuration commands, the exact
notations and the syntax of the commands that are entered in the Interface Configuration mode, see
Tellabs ® 8600 Managed Edge System CLI Commands Manual.
The following table shows the names of the interfaces. These names are used to specify the interface
when entering the Interface Configuration mode.
This chapter contains configuration examples of transmission layers of the interfaces in the:
The configuration examples given below are applicable to all NE in the Tellabs 8600 system
and use the interface convention naming and syntax of the Tellabs 8630 access switch or
Tellabs 8660 edge switch where the line card slot number is part of the interface name (e.g.
ge 5/1/0). Card slot is not applicable to Tellabs 8609 access switch , therefore the syntax
applied to this NE should follow module#/Interface#. The card slot on theTellabs 8611 access
switch refers to the working side Switching Control Module (SCM) used to control the HMs
and LMs, and must be set to value 2 (e.g. SCM slot#/module#/Interface#). Please take this
into consideration when applying the examples to Tellabs 8609 access switch and Tellabs
8611 access switch.
The following tables provides an illustration of interface name convention and syntax.
36
9 Interface Configuration Examples
The following step list contains basic configuration commands that are often used when configuring
interfaces in the Tellabs 8600 system. The list is not comprehensive, and there are optional
commands that are not necessarily required in order to get an interface working. For more
information on how to configure an interface of a certain type, refer to the interface specific sections
that follow. For a full list of interface configuration commands, refer to Tellabs ® 8600 Managed
Edge System CLI Commands Manual.
37
9 Interface Configuration Examples
Command Description
NODE(cfg-if[fe5/0/2])# mtu 1518 The Maximum Transfer Unit (MTU) defines the
largest amount of data that can be sent or received
on an interface. The MTU does not count in the
header bytes of an L2 frame. Make sure that
MTU is configured appropriately in both ends of a
network link.
Note that there are upper layer MTU settings
supported in the configuration like IP MTU
and MPLS MTU. For more details please
refer to Tellabs ® 8600 Managed Edge System IP
Forwarding and Traffic Management Configuration
Guide and Tellabs ® 8600 Managed Edge System
MPLS Applications Configuration Guide.
This section shows commands that can be used when looking for information on the status of an
interface. See also Tellabs ® 8600 Managed Edge System Test and Measurement Configuration
Guide for information on tools for testing connections.
38
9 Interface Configuration Examples
Command Description
NODE# show running-config Use this command to check that the interface is
configured properly. The default values (except
for shutdown) are not shown in the listing of
configuration commands.
NODE# show interface fe 5/0/2 Use the show interface command to check the
status of the interface. This command also shows
information on the state of certain configuration
parameters of the interface in question. The
output of this command includes the values of the
counters. The format and the information content
of the output depend on the interface type.
NODE# show ip interface brief Use the show ip interface commands to check the
NODE# show ip interface fe 5/0/2 status of the IP interfaces. This command with the
brief option is an effective tool to get a summary
of the status of the interfaces.
NODE# show faults active Use the show faults commands to check the
NODE# show faults active | block fe fault status of the interface. A properly operating
5/0/2 interface should not typically have any active faults
NODE# show faults history reported. Tellabs ® 8600 Managed Edge System
Fault Management Configuration Guide provides
more information on the fault management in the
Tellabs 8600 system.
39
9 Interface Configuration Examples
NODE(cfg-if[fe5/0/1])# clear interface Use this command when you want to clear all
statistics fe 5/0/2 counters of an interface. This command has
optional parameters that can be used to specify
the exact target of the clear command. For
example, use the ether-logical parameter to
clear the counters of the Ethernet interface only.
Refer to Tellabs ® 8600 Managed Edge System
CLI Commands Manual for information on the
parameters available for all types of interfaces.
40
9 Interface Configuration Examples
This section shows basic configurations of the Ethernet interface in the Tellabs 8600 system.
Command Description
41
9 Interface Configuration Examples
Command Description
NODE(cfg-if[fe5/0/2])# mode speed 100 Configure the Ethernet port fe5/0/2 to half
duplex half duplex operation mode with a speed set to 100
NODE(cfg-if[fe5/0/2])# interface fe Mbps. The command as given above disables the
5/0/3 Auto-Negotiation function.
NODE(cfg-if[fe5/0/3])# mode auto speed The mode command given above to the fe5/0/3
100 duplex full interface enables the Auto-Negotiation function.
The Auto-Negotiation function will try to negotiate
the speed to 100 Mbps and to full-duplex mode.
42
9 Interface Configuration Examples
Command Description
Command Description
Command Description
NODE(config)# no interface fe 5/0/2.45 You can delete a VLAN sub-interface by using the
no form of the VLAN sub-interface configuration
mode command.
9.5 8xchE1/chT1 LM
This chapter contains configuration examples of transmission layers of the PDH interfaces in the
8xchE1/chT1 LM.
43
9 Interface Configuration Examples
The configuration examples given below are applicable to all NEs in the Tellabs 8600 system
and use the interface convention naming and syntax of the Tellabs 8630 access switch or
Tellabs 8660 edge switch where the line card slot number is part of the interface name (e.g.
pdh 4/1/0). Card slot is not applicable to Tellabs 8609 access switch , therefore the syntax
applied to this NE should be module#/Interface#. The card slot on theTellabs 8611 access
switch refers to the working side Switching Control Module (SCM) used to control the HMs
and LMs, and must be set to value 2 (e.g. SCM slot#/module#/Interface#). Please take this
into consideration when applying the examples to Tellabs 8609 access switch and Tellabs
8611 access switch.
The following tables provides an illustration of interface name convention and syntax.
The PDH interface is accessed in the same way as any other interface in the Tellabs 8600 NEs.
Command Description
44
9 Interface Configuration Examples
This section shows configuration examples of physical layer of the PDH interface. The commands
are independent from each other and need not to be in sequence.
Command Description
NODE(config)# interface pdh 4/1/0 Configure the timeout to be 2 minutes after the
NODE(cfg-if[pdh4/1/0])# loopback loop is automatically released. Activate the line
timeout 2 loopback first, then deactivate the line loopback
NODE(cfg-if[pdh4/1/0])# loopback and activate the equipment loopback. If no other
to-line configurations is made the loopback is released
NODE(cfg-if[pdh4/1/0])# no loopback after 2 minutes.
to-line
NODE(cfg-if[pdh4/1/0])# loopback
to-equipment
NODE(cfg-if[pdh4/1/0])# pdh timing Configure the NE to use loop timing for the
loop-timing interface instead of node clock derived timing.
This chapter shows how the P12s layer is configured. The configuration is essential to enable ATM
protocol to be used in the interface. The timeslot group concept is used to model the individual
Nx64 channels multiplexed to P12s signal. In the current releases only one timeslot group can be
created to P12s and it has a fixed 30 timeslots configuration.
Command Description
NODE(config)# interface pdh 4/1/0 Configure the desired P12s interface on the module.
NODE(cfg-if[pdh4/1/0])# pdh framed Configure the framing of the interface to use P12s
NODE(cfg-if[pdh4/1/0])# interface pdh (G-704) framing. Configure the timeslot group.
4/1/0:0 Configure the timeslots 1-15 and 17-31 for E1 to
NODE(cfg-if[pdh4/1/0:0])# pdh timeslots the assigned timeslot group. Configure the port
all protocol to ATM .
NODE(cfg-if[pdh4/1/0:0])# port-protocol
atm
NODE(cfg-if[pdh4/1/0:0])# interface pdh Configure the PDH interface to report AIS and RDI
4/1/0 failures.
NODE(cfg-if[pdh4/1/0])# pdh report p12s
ais
NODE(cfg-if[pdh4/1/0])# pdh report p12s
rdi
45
9 Interface Configuration Examples
This chapter shows how the DS1 layer is configured. The configuration is essential to enable ATM
protocol to be used in the interface. The timeslot group concept is used to model the individual
Nx64 channels multiplexed to DS1.
Command Description
NODE(config)# interface pdh 4/1/0 Configure the desired physical DS1 interface.
NODE(cfg-if[pdh4/1/0])# pdh framed Configure the framing of the interface to use DS1
NODE(cfg-if[pdh4/1/0])# interface pdh framing. Configure the line type (super frame
4/1/0:0 or extended super frame) used in DS1 interface.
NODE(cfg-if[pdh4/1/0:0])# pdh line-type Configure the timeslot group to be used (0).
esf Configure the timeslots 1-24 to assigned to the
NODE(cfg-if[pdh4/1/0:0])# pdh timeslots timeslot group as a single command. Configure the
all port protocol to ATM.
NODE(cfg-if[pdh4/1/0:0])# port-protocol
atm
The HDLC PWE3 or port protocol HDLC creates an interface that can be attached to pseudowire
only and it cannot terminate. The HDLC PWE3 can carry any kind of traffic that uses HDLC
protocol, i.e.: PPP. The Tellabs 8600 system implementation of the HDLC PWE3 conforms to
[RFC4618].
The following example shows how a P12s/DS1 interface is configured to use the HDLC protocol for
HDLC PWE3.
Command Description
NODE(config)# pwe3 circuit test1 1001 Initialize a PWE3 circuit in the NE with a circuit
mpls manual name and a pseudowire ID.
NODE(config)# interface pdh 4/1/0 Configure the interface to use HDLC port protocol;
NODE(cfg-if[pdh4/1/0])# pdh framed associate it to the PWE3 circuit created in the step
NODE(cfg-if[pdh4/1/0])# interface pdh above and activate the interface with no shutdown
4/1/0:1 command.
NODE(cfg-if[pdh4/1/0:1])# pdh timeslots
all
NODE(cfg-if[pdh4/1/0:1])# port-protocol
hdlc
NODE(cfg-if[pdh4/1/0:1])# pwe3 circuit
test1
NODE(cfg-if[pdh4/1/0:1])# no shutdown
NODE(cfg-if[pdh4/1/0:1])# exit
46
9 Interface Configuration Examples
This example shows how a regular PPP interface is created, how a PPP group is created and how
parameters are set to it. Finally, the PPP interfaces are added to the group. The commands are
available only in P12s/DS1 mode.
Command Description
NODE(cfg-if[mp4/0])# ppp mp sequence- Set the sequence number type to short. Enable
number-type short fragmentation with the maximum frame size of
NODE(cfg-if[mp4/0])# ppp mp fragmenta- 100 bytes.
tion static 100
NODE(cfg-if[mp4/0])# exit
NODE(config)# interface pdh 4/1/0 Configure PPP links first to be regular PPP
NODE(cfg-if[pdh4/1/0])# pdh framed interfaces.
NODE(cfg-if[pdh4/1/0])# interface pdh
4/1/0:0
NODE(cfg-if[pdh4/1/0:0)# pdh timeslots
all
NODE(cfg-if[pdh4/1/0:0)# port-protocol
ppp
NODE(cfg-if[pdh4/1/0:0)# crc 32 Configure the length of the check sum in the PPP
frame.
NODE(config)# interface pdh 4/1/1 Repeat the PPP link configuration for the interfaces
NODE(cfg-if[pdh4/1/1])# ... pdh4/1/1 and pdh4/1/2 as shown previously.
In this example three member links are configured to use differential delay monitoring for maximum
one-way differential delay target value of 3700 µs and restore value of 2500 to allow 1200 µs
variance tolerance. The objective is to detect enduring link one-way differential delay increase of
3700 µs within 5 seconds and take the link out of use. The link will be taken back into use within
13 seconds if measured consecutive one-way differential delay is below maximum differential
delay restore value limit.
47
9 Interface Configuration Examples
Consecutive values over 3700 µs will always exceed and drop the link after the drop threshold is
reached. When differential delay value is exceeded, consecutive values below 2500 µs will take
the link back into use after the threshold value has been reached and guarantee that the link is
not taken into use too early.
Command Description
NODE(config)# interface pdh 4/1/0:0 Configure the first PPP interface and the keepalive
NODE(cfg-if[pdh4/1/0:0])# ppp keepalive timer. Enable delay monitoring on the first PPP
1 3 monitor-delay link.
NODE(cfg-if[pdh4/1/0:0])# exit
NODE(config)# interface pdh 4/1/1:0 Configure the second PPP interface and the
NODE(cfg-if[pdh4/1/1:0])# ppp keepalive keepalive timer. Enable delay monitoring on the
1 3 monitor-delay second PPP link.
NODE(cfg-if[pdh4/1/1:0])# exit
NODE(config)# interface pdh 4/1/2:0 Configure the third PPP interface and the keepalive
NODE(cfg-if[pdh4/1/2:0])# ppp keepalive timer. Enable delay monitoring on the third PPP
1 3 monitor-delay link.
NODE(cfg-if[pdh4/1/2:0])# exit
NODE(cfg-if[mp4/0])# ppp mp diff-delay Set the thresholds for dropping and taking link
threshold drop 4 back-to-use 12 back into use on the MLPPP group.
NODE(cfg-if[mp4/0])# ppp mp member pdh Add the PPP links to the MLPPP group.
4/1/0:0
NODE(cfg-if[mp4/0])# ppp mp member pdh
4/1/1:0
NODE(cfg-if[mp4/0])# ppp mp member pdh
4/1/2:0
NODE(cfg-if[mp4/0])# exit
The following is an example showing the performance of MLPPP differential delay monitoring.
48
9 Interface Configuration Examples
49
9 Interface Configuration Examples
MC-MLPPP Configuration
MC-MLPPP provides a finer granularity of differentiated services scheduling for high and low
priority traffic flows. The latency experienced by high priority traffic can be reduced when
MC-MLPPP is used. Please see details in MC-MLPPP Layer Configuration. To configure
MC-MLPPP operation, the following steps are required:
• Configure MLPPP group, see details in 9.5.6 Configuring P12s/DS1 for PPP and MLPPP.
• Enable MC-MLPPP operation on the MLPPP group.
• Optionally configure QoS mapping to DiffServ traffic classes, otherwise default mapping will be
used.
Node-I Configuration
The following example shows how to configure MC-MLPPP operation on MLPPP group. The
example assume three suspension class levels are configured in TX direction.
Command Description
In the Tellabs 8600 NEs the default QoS mapping to DiffServ traffic classes is covered in QoS
Mapping Consideration. However in cases where the default QoS mapping needs to be modified
(e.g. interoperability reasons), the following is an illustration of QoS mapping setup (the example
reverses the default mapping order).
When configuring QoS to DiffServ traffic classes mapping the following should be taken
into consideration:
— MLPPP group class equals number of multi link classes used, which depends on
negotiation and it is configurable in range 2..4 (except 1).
— CS7 and EF can be mapped independently to any suspension level. However AF and BE
must always be mapped to the same suspension class level.
Command Description
In this example to the peer node we only enable MC-MLPPP and negotiation will be used to agree
on all parameters.
50
9 Interface Configuration Examples
Command Description
MC-MLPPP Status
51
9 Interface Configuration Examples
This chapter shows how the DS1 remote loopback is configured in SF mode and how inband and
outband loopback is invoked. Finally, the local line loop is activated. The remote loopback function
is not available in the E1/P12S interface.
Command Description
NODE(cfg-if[pdh4/1/0])# loopback remote Invoke outband remote loopback using ansi code
fdl ansi over Facility Data Link (FDL). By using the ansi
parameter the activation code is set to 0 000111 0
11111111. This command sends a request to the
remote equipment to activate the line loop.
For details of the supported commands and options to adjust PDH fault monitoring and reporting,
please refer to Tellabs ® 8600 Managed Edge System CLI Commands Manual.
The following samples of commands give an example of adjusting fault monitoring and reporting
for P12s and DS1.
E1/P12
52
9 Interface Configuration Examples
Command Description
NODE(pdh4/1/0])# no pdh layer report The commands listed above turn off the fault
e1phy reporting on a physical layer of E1 interface.
NODE(pdh4/1/0])# no pdh report p12s ais The commands listed above turn off the fault
NODE(pdh4/1/0])# no pdh report p12s rdi reporting of AIS and RDI faults on a P12s layer.
NODE(cfg-if[pdh4/1/0])# pdh signal- The commands configure the threshold and sliding
degraded seconds 4 window parameters for signal degraded fault. CRC
NODE(cfg-if[pdh4/1/0])# pdh signal- error is selected as a source for calculation.
degraded threshold 10
NODE(cfg-if[pdh4/1/0])# pdh signal-
degraded source crc
T1/DS1
Command Description
NODE(pdh4/1/0])# no pdh report ds1 ais The commands listed above turn off the fault
NODE(pdh4/1/0])# no pdh report ds1 rai reporting of AIS and RAI faults on a DS1 layer.
NODE(cfg-if[pdh4/1/0])# pdh signal- The commands configure the threshold and sliding
degraded seconds 4 window parameters for signal degraded fault.
NODE(cfg-if[pdh4/1/0])# pdh signal-
degraded threshold 10
53
9 Interface Configuration Examples
The MGMT port on SCM of Tellabs 8611 access switch automatically becomes protected when
another SCM is added to the inventory of the network element and SCM becomes an equipment
protected card. Therefore, the Tellabs 8611 access switch does not have separate commands for
establishing or removing the MGMT protection group.
Command Description
NODE# protection manual-switchover Use this command to select an active MGMT either
interface mfe slot 2 the MGMT port on SCM in slot 1, or the MGMT
port on SCM in slot 2. The command given in this
example activates the MGMT port of the SCM
in slot 2 as indicated by the last parameter of the
command.
Command Description
NODE# show protection interface mfe Show information on the status of the MGMT
protection group.
The output is shown below.
54
Layer Descriptions
Layer Descriptions
The following layer-related chapters present the configuration options that are listed in the context
of each PLM chapter earlier in the document. The following chapters are organized according to
themes and the ones relevant to each PLM are offered as links in each PLM chapter which you
can refer to for more details.
PDH Layers
There is a support of line loop configuration independently in each physical E1 interface. When
the line loop is activated, the interface loops the received E1 signal in the input interface after
the clock recovery process back to the output interface. While this loop is on, the ingress data
path operates normally.
When the loop is activated, it can be deactivated by the operator or automatically after the user
configurable timer expires. Only either line or equipment loop can be active in the E1 interface
simultaneously.
Interface Timing
There is support of output interface timing configuration independently in each physical interface.
By default the timing of the output signal is derived from the accurate centralized node clock in the
NE. This mode is referred to as node timing. It is also possible to configure the output interface to
derive the timing from the received side of the same RX/TX interface pair. This mode is know as
loop timing. Loop timing can be used e.g. when the last element in the edge of the network has an
E1/T1 interface but does not have any other reason to use an accurate clock. Refer to Tellabs ® 8600
Managed Edge System Synchronization Guide for more information about timing configuration.
Failure Reporting
Physical line layer failure reporting can be enabled or disabled by the operator. Disabling may be
used during the provisioning phase to avoid flooding of temporary failures to the management
system.
55
Layer Descriptions
P12s Framing
P12s (G.704) framing is supported with optional CRC4 multi-framing. Also the generation of REI
bit in the P12s frame can be set to be generated dynamically according to the receiving status
or as fixed.
Failure Reporting
P12 layer failure reporting can be enabled/disabled by the operator. Disabling may be used during
the provisioning phase to avoid flooding of temporary failures to the management system. The faults
can also be enabled individually according to the operator needs.
The P12 layer monitors the BER of the 2M path. Fault detection uses CRC-4 multiframe errors or
an errored frame synchronization word as the source information based on the configuration. The
P12 layer supports the Signal Degraded type of monitoring as described below.
The Signal Degraded fault is used to indicate the quality of the particular path for the network
management system. The signal degraded fault uses the concept of Errored Seconds for monitoring
assuming bursty distribution of the errors. When all seconds over the configured observation
window size (N) are classified as errored seconds, the fault is declared. A second is classified as
errored if more errors have been detected than the threshold parameter (M) indicates. The fault is
cleared when during the observation period there are no errored seconds. The default threshold
values are recommended to be used. Due to the long integration time the DEG fault is generated
with a delayed when compared to the actual status of the line signal.
See section 7 ANSI Loopback Operations for a detailed explanation of loops in the DS1 interface.
56
Layer Descriptions
Interface Timing
The output interface timing configuration is supported independently in each physical interface. By
default the timing of the output signal is derived from the accurate centralized node clock in the NE.
This mode is referred to as node timing. It is also possible to configure the output interface to derive
the timing from the received side of the same RX/TX interface pair. This mode is known as loop
timing. Loop timing can be used e.g. when the last element in the edge of the network has an DS1
interface but does not have any other reason to use an accurate clock.
Line Length
The line length can be configured to each DS1 interface for the following distances: 133, 266 , 399,
533 and 655 feet. The line length is used to adjust the output pulse mask measured at the distribution
frame. Line length can be configured only when line buildout is disabled (0 dB).
Line Buildout
Line buildout can be configured to each DS1 interface with 0, 7.5, 15, 22.5 dB attenuation. When
attenuation is disabled (0 dB) the line length is automatically set to 133 ft. Line buildout is used
to attenuate the output signal for reducing the crosstalk between long T1 lines or overdriving the
receiver of the connected equipment.
Failure Reporting
Physical line layer failure reporting can be enabled or disabled by the operator. Disabling may be
used during the provisioning phase to avoid flooding of temporary failures to the management
system.
There is support of configurable super frame and extended super frame format options.
Failure Reporting
DS1 layer failure reporting can be enabled or disabled by the operator. Disabling may be used
during the provisioning phase to avoid flooding of temporary failures to the management system.
The faults can also be enabled individually according to the operator needs.
57
Layer Descriptions
The DS1 layer monitors the Bit Error Rate (BER) of the DS1 path. Fault detection uses CRC-6
multiframe errors or an errored frame synchronization word as the source information based on the
configuration. The DS1 layer supports The Excessive Error rate type of monitoring as described
below.
The excessive error rate fault is used to indicate that the BER of a particular path has exceeded the
configurable bit error threshold. Excessive error rate detection assumes poison distributed errors.
Excessive error rate monitoring uses CRC6 multiframe errors or an errored frame synchronization
word as the source information to declare the fault. The source is configurable.
The excessive error rate tries to monitor the actual BER of the line signal each second. The EXC-A
(Excessive Error - Signal Fail fault ) error is used to detect the BER level between 10 EXP-3...10
EXP-5 on the basis of the user configuration. EXC-A forces the signal to AIS when detected. The
EXC-B (Excessive Error - Signal Degrade fault) error is used to detect the BER level between 10
EXP-5...10 EXP-9 on the basis of the user configuration. EXC-B only generates a fault and does not
insert AIS. The higher the BER is, the shorter the detection time will be.
Ethernet Layers
An optical Ethernet interface is equipped with Small Form factor Pluggable (SFP) optical transceiver
module. Refer to Tellabs ® 8600 Managed Edge System Hardware Installation Guide for more
information about the supported SFP module types. The SFP modules are hot-swappable devices
that can be replaced without switching the power off or without disabling the interface in any other
way. The system monitors the existence of the SFP modules. The Tellabs 8600 NEs generate an
alarm (Missing connector module) if the SFP stick of an interface is not present (or it is broken).
There is a support of line loop configuration independently in each physical interface. When the line
loop is activated, all frames arriving from the line side are looped back to line without modifying
the header or payload.
Supported is also equipment loop configuration independently in each physical Ethernet interface.
When the equipment loop is activated, all frames arriving from the equipment side are looped back
to the system without modifying the header or payload.
When Ethernet physical layer loops are used operator shall be aware that the traffic to be looped
does not cause routing loops either in the local end when equipment loop is activated or in far-end
when line loop is activated. The loops are typically applicable only when all the Ethernet traffic is
PWE3 tunnelled either using Ethernet raw mode or Ethernet tagged mode PWE3. If the interface
forwards IP traffic unwanted routing loops may occur.
58
Layer Descriptions
When the loop is activated, it can be deactivated by the operator or automatically after the user
configurable timer expires. Only either line or equipment loop can be active in the Ethernet interface
simultaneously. If a loop is enabled remotely, the user must be aware of the network topology to
avoid losing the management communication.
Laser On/Off
An optical Ethernet interface provides support of laser transmitter disabling and enabling
independently in each physical interface. By default the laser is enabled. The feature can be utilized
in network testing or used for security purposes during the maintenance and installation.
Ethernet layer failure reporting can be enabled or disabled by the operator. Disabling may be used
during the provisioning phase to avoid flooding of temporary failures to the management system.
Ethernet OAM
The Ethernet OAM functionality supported in the Tellabs 8600 system is covered in Tellabs ® 8600
Managed Edge System Ethernet Configuration Guide.
Port Protocols
An ATM interface provides the ATM transmission convergence layer functionality and de-couples
the ATM cell processing from TDM frame processing. The mapping or demapping of cells to
PDH/SDH signals operates as defined in [I.432.3]. The following table shows the available TDM
channelization and the timeslot configuration, which the ATM port protocol requires.
Refer to Tellabs ® 8600 Managed Edge System ATM and TDM Configuration Guide for a more
detailed description of the ATM layer functionality.
59
Layer Descriptions
An empty IMA group is created first. It is not possible to create connections to an IMA group which
does not have any IMA links, nor delete the group which does have configured connections. The
user is able to restart the IMA group any time.
ATM IMA is supported in the P12s/DS1 interfaces and it requires the interfaces to be configured to
ATM port protocol mode as shown in the previous section (interface configuration examples) in
this document.
The capacity of the IMA group depends on the number of the configured links and IMA frame
length parameter and is detailed described in Tellabs ® 8600 Managed Edge System ATM and TDM
Configuration Guide. IMA scalability is shown in the following table.
The framed PDH interface (P12s/DS1) can be configured to HDLC port protocol mode to forward
HDLC traffic. The following table shows the available TDM channelization and the timeslot
configuration, which the HDLC port protocol requires.
60
Layer Descriptions
The unframed PDH interface (P12x/DS1) can be configured to TDM/SAToP mode to terminate
SAToP PWE3 encapsulation [RFC4553] for the TDM payload. The following table shows the
available TDM channelization and the timeslot configuration, which the SAToP protocol requires.
The TDM pseudowire functionality is detailed described in Tellabs ® 8600 Managed Edge System
ATM and TDM Configuration Guide.
The framed PDH interface (P12s/DS1) can be configured to have several timeslot groups. Each
group can be configured to TDM/CESoPSN mode to terminate CESoPSN PWE3 encapsulation
[CESoPSN] for the TDM payload. The following table shows the available TDM channelization
and the timeslot configuration, which the CESoPSN protocol requires.
61
Layer Descriptions
The TDM pseudowire functionality is detailed described in Tellabs ® 8600 Managed Edge System
ATM and TDM Configuration Guide.
Detailed Operation
PPP Negotiations
In order to establish communication over a point–to–point link, each end of the PPP link sends Link
Control Protocol (LCP) frames to configure and test the data link. Before sending any data the
link is set up by running LCP negotiation with the Maximum Receive Unit (MRU) option. The
Maximum Transmission Unit (MTU) value sets the upper limit to the MRU value. The default value
of MTU is 1600 bytes. As part of LCP negotiation, protocol field compression (PFC) and magic
number options are supported as defined in [RFC 1661].
The Network Control Protocol (NCP) options such as Internet Protocol Control Protocol (IPCP),
Multiplexed Control Protocol (MuxCP), optionally MPLS Control Protocol (MPLSCP), OSI
Network Layer Control Protocol (OSINLCP) (if the IS-IS router is enabled) are negotiated to carry
network protocol on the link. Once each of the chosen network layer protocol has been configured,
datagrams from each network layer protocol are sent over the link.
The frame format of PPP encapsulation is defined in [RFC1661]. The unframed or framed PDH
interface can be configured to PPP port protocol mode to terminate PPP encapsulation [RFC1662]
for frame payload.
Configuration Options
The available TDM channelization and timeslot configuration options required for PPP protocol
are presented below.
62
Layer Descriptions
PPP Multiplexing (PPPMux) is used to increase the bandwidth usage by concatenating multiple
PPP frames arriving on Multilink PPP (MLPPP) group into a single PPP multiplexed frame. This is
achieved by avoiding addition of PPP header in each received PPP frame on MLPPP group.
Network Applications
PPPMux is used to achieve efficient bandwidth by decreasing frame overhead for delay sensitive
real time frames such as Voice over Internet Protocol (VoIP). Each encapsulated PPP frame within
the multiplexed frame is called as PPP subframe. The subframe length is configurable as a PPPMux
parameter. When frames to be multiplexed are larger than the configured subframe length, the
frames are transmitted without multiplexing and hence bandwidth efficiency is not be achieved.
The Tellabs 8600 system supports:
Detailed Operation
PPPMuxCP Negotiation
The local and remote nodes provide their ability to receive multiplexed frames through NCP
negotiation PPP multiplexing [RFC3153]. A transmitter may not send a multiplexed frame unless
the peer has provided its ability to receive multiplexed frames. Therefore support of multiplexed
frame reception is negotiated in each direction independently.
Successful negotiation of PPPMuxCP does not obligate a peer to transmit multiplexed frames. As
part of the PPPMuxCP negotiation, a ‘default Protocol ID (PID)’ option is always negotiated. This
enables the transmitter to transmit the first subframe of a PPP multiplexed frame without a PID
(Protocol Field Flag (PFF) =0), thus resulting in a saving of one or two bytes. The receiver will
interpret a received PPPMux frame using the default PID it offered.
The format of a complete PPP frame along with multiple subframes for PPP in HDLC is defined
in [RFC3153].
PPPMux Transmitter
During the transmission of a PPP multiplexed frame, the transmitter has a state variable last
PID, which is used to hold the most recent value of protocol field in a subframe with PFF=1. At
the start of the multiplexing process, the last PID is set to the default PID value negotiated in
PPPMuxCP. The transmitter starts compiling a multiplexed PPP frame with the protocol field value
corresponding to PPP multiplexed frame (0x59). For each subframe, protocol field value of the
subframe is compared with to last PID value. If they are equal, PFF is set to 0 and the protocol field
is deleted. If not, PFF is set to 1 and the protocol field is included, after PFC, in the subframe and
the last PID is set to the protocol field value of the current subframe.
The transmitter uses the following criteria for transmitting a PPP multiplexed frame:
63
Layer Descriptions
1. Expire of transmit timer - timeout value for which the transmitter would wait before sending
the multiplexed frame.
2. Maximum frame length - the accumulated total maximum frame length threshold of the multi-
plexed frame.
3. Maximum subframe count - the maximum number of frames that can be multiplexed in a single
frame.
4. Maximum subframe length - is another parameter based on which the decision is made if a
particular PPP frame is allowed to be multiplexed or not.
PPPMux Receiver
If a frame with protocol field value equal to PPP multiplexed frame (0x0059) is received, the frame
is de-multiplexed in the correct order using the following criteria:
• The last received PID (the value of protocol field in the most recently de-multiplexed subframe
with PFF=1) is initialized to the default PID value negotiated by PPPMuxCP:
• If PFF=0 for a subframe, the last received PID is appended to the beginning of the subframe
as determined by the length field.
• If PFF=1 for a subframe, the last received PID is set to the default PID value.
• Each succeeding subframe is processed similarly. This processing is completed when all sub-
frames have been processed, or when the size field of a subframe exceeds the amount of data
remaining in a frame.
Configuration Options
The available configuration parameters required for PPPMux are presented below.
MLPPP groups multiple physical links into a single logical bundle with a larger bandwidth called as
MLPPP group. It is possible to add or remove links when required from a group.
Network Applications
In the transmission direction, MLPPP uses a fragmentation algorithm to split large frames into
smaller fragments. These fragments (appended with MLPPP header containing sequence numbers)
are then sent to the member links in a round-robin fashion. The receiving side accepts these
fragments, reorders and reassembles the fragments into a complete frame using the sequence
numbers.
64
Layer Descriptions
During the transmission of a large data frame, if a delay sensitive frame arrives will be queued and
transmitted only after the large data frame has been fully transmitted. This process adds to the
delay experienced by delay sensitive frames.
Interleaving allows delay sensitive frames which are not fragmented by MLPPP (no MLPPP header
and sequence numbers added) to be inserted among the fragments of large data frames without
having to wait for all the fragments of large frames to be transmitted on the MLPPP group. It
minimizes latency caused by the large frames. Interleaving works properly only when multi link
group consist of one link since interleaved frames are being sent without the sequence numbers. If
multi link group consist of multiple links, then the receiving side forwards the received frames in the
order they arrive and short interleaved packets may pass long interleaved packet, thus reordering
may appear. When interleaving is enabled in Tellabs 8600 system packets with CS7 and EF traffic
classes are interleaved while the packets with other traffic classes are fragmented. Interleaving is
also supported with PPPMux to achieve efficient bandwidth and latency improvement. When
interleaving is enabled (not negotiable option) along with PPPMux, the PPP multiplexed frames are
interleaved, i.e. they are sent to the PPP member link without MLPPP header to reduce the packet
overhead. When “no MP header usage” option is configured on a single link of the MLPPP group,
frames are sent without any MLPPP header.
When MLPPP fragments are sent over multiple links, the receiver is required to buffer the frames
when they arrive out of sequence. Therefore, the differential delay between the links must be
smaller compared to the tolerable delay of delay sensitive real-time traffic. When the differential
delay between the member links is higher, then chance of getting the frames dropped increases due
to large difference in the delay of the arriving fragments over different member links.
Detailed Operation
PPP Negotiation
When a link is added to an MLPPP group, LCP negotiations are automatically run with the
Maximum receive reconstructed Unit (MRRU) option over the link. This procedure activates the
link in the MLPPP group and, if the link is the first link in the group, it also negotiates MTU for
the MLPPP group (subsequent links must use the same MTU value in the MRRU options as the
first link of the MLPPP group). Once multilink has been successfully negotiated with peer, then it
sends MLPPP encapsulated packets with or without fragmentation.
If the negotiations fail, the link is not activated. Additionally, if the user has selected to use the short
sequence number mode to reduce the protocol overhead, the short sequence number format option is
included in the LCP negotiations. If both parties agree to use the short sequence number format,
the 12-bit sequence number format is used instead of the default 24-bit format. If a short sequence
number format is rejected by the peer, the default long (24-bit) sequence format is used even when
the user has configured to use the short sequence number format.
Multiple PPP links may be grouped to form a single higher capacity logical link by using the
MLPPP [RFC1990]. An empty MLPPP group is created first and P12s/DS1 interfaces which
are configured to PPP mode are further added to the MLPPP group. It is not possible to create
connections to an MLPPP group which does not have any PPP links nor delete the group which
does have configured connections.
MLPPP supports frame fragmentation (a large frame is fragmented to multiple pieces, the fragments
are sent over different links of the MLPPP group, and the frame is reassembled by the receiving
end) which reduces transmission delay. There are three selectable fragmentation modes:
65
Layer Descriptions
• Dynamic
• Static
• Disabled
In Dynamic mode a fragment size is calculated automatically (fragment size = negotiated
MRRU/number of open links) to the maximum fragment size. The idea is that a frame of 1540
bytes (which is a typical maximum large frame size when potential protocol overhead is added) is
split into fragments that are sent in parallel on the links of the multilink bundle in a round robin
fashion. In Static mode the fragment size is user-configurable.
Configuration Options
The available TDM channelization and timeslot configuration options required for MLPPP are
presented below.
MLPPP delay difference between the member links leads to additional delay to all frames
transmitted over the MLPPP group. Large enough delay difference causes frame loss as possible
fragments of the frames are eventually timed out and discarded in the receiver side reassembly
buffer. MLPPP differential delay measurement provides a tool for link differential delay monitoring
between the MLPPP group links.
The maximum differential delay (maximum tolerated delay between the fragments of a frame)
configuration can be used to limit the maximum delay of an MLPPP group. A frame can be sent
further only when all fragments have been received, therefore the slowest path defines the overall
delay.
66
Layer Descriptions
There are several adjustable parameters related to MLPPP differential delay measurements:
• Maximum one-way differential delay in microseconds (default 25000 µs), which must be equally
set in both sides
• Thresholds for action when exceeding values are detected
• Execution action, which is based on the transmitter side hardware timestamps:
• Dropping a link (default) exceeding one-way differential delay
• Raising fault
• Threshold for link back to use, which sets the link back up into use, or sets fault off
Full performance monitoring and accurate calculations of one-way differential delay can be achieved
only when both ends of the link support hardware timestamps. Moreover additional performance
information can be monitored if NTP is configured.
When unidirectional protection is used and transmit and receive are on different ports on the NE,
receiver side one-way differential delay performance and hardware RTT information is not available.
Multiclass MLPPP (MC-MLPPP) is used to decrease the latency observed by delay sensitive high
priority frames going through MLPPP group. This can be achieved by allowing high priority frames
to interrupt the low priority frame transmission. Without MC-MLPPP, the low priority frames are
always sent as a whole to the line before a high priority frame can be sent.
Network Applications
MC-MLPPP enables fragmentation of data frames of different priorities into multiple classes in
an MLPPP group. It enables a transmission of high priority frames between fragments of lower
priority frames.
67
Layer Descriptions
MC-MLPPP ensures the delivery of high priority, delay-sensitive traffic, such as voice and video
in the proper sequence by creating separate transmit and receive context for every multi link class
in the multilink group. Transmit and receive contexts contain separate sequence numbers and all
other statistics pertaining to each multi link class. The data frames of each multi link class are
encapsulated in an MLPPP header. The sequence numbers of each of the classes are also embedded
within the header before transmission. The receiving peer processes each class independently and
uses the sequence number in the MLPPP header to internally reorder and reassemble frames in
the desired sequence.
MC-MLPPP advantage will not be applicable in cases where all traffic belongs to the same DiffServ
traffic class or when fragmentation is not enabled. Due to the suspension of low priority frames by
high priority frame, MC-MLPPP process increases the latency of low priority traffic. MC-MLPPP
with interleaving is not supported since MC-MLPPP already takes care of suspending lower priority
frames for transmitting higher priority frames. Hence, interleaving with multiclass does not give
any additional advantages.
Detailed Operation
LCP Negotiation
Local and remote peers receive fragments with the format given by the code number, maximum
number of suspendable classes as defined in [RFC2686] for multilink header format LCP option.
Once LCP negotiation is successfully between peers, then peers transmit all subsequent multilink
frames with negotiated class values on all links of the group.
When Address and Control Field Compression (ACFC) is enabled , the PPP header would exclude
the address and control field. When Protocol Field Compression (PFC) is enabled, the leading
zeroes in PID would be excluded. The Tellabs 8600 system by default disables ACFC, while PFC
is enabled.
The number of multi link classes in transmit direction can be configured by the user. The actual
number of used multi link classes is based on the negotiation between local and remote node
like the following table shows. Explicit multi link class numbers or QoS mappings to multi link
classes are not negotiated.
MC-MLPPP frame format has two options with 12 and 24 bits sequence number. By default, the
sequence field is 24 bits long, but can be negotiated to be 12 bits.
68
Layer Descriptions
The Tellabs 8600 system supports a maximum of 4 multi link transmit classes (suspension levels).
Maximum up to 3 multi link classes can be enabled at the same time. Depending on the networking
conditions 1..7 DiffServ traffic classes can be mapped to 1..3 multi link classes. Because the actual
number of multi link classes is a result of a negotiation with peer node the system allows to use
different mapping depending on the result of the negotiation. This is configured using Group Class
parameter. Group Class is configured separately for cases where 2, 3 and 4 multi link classes are
used. A user can map CS7 and EF independently to any multi link class, but there is a restriction
that all the AF and BE shall be mapped to the same multi link class.
Group class concept provides a flexibility and interoperability with other vendors which may have
different QoS to multi link class mapping schemes. The mappings is local to the node where it is
configured and Class field in the MC-MLPPP frame is just informative for a receiver.
When mappings are not configured explicitly, default mappings are used as shown in the following
table.
69
Layer Descriptions
The following figure shows the default mapping when 4 multi link classes are negotiated (Group
Class = 4) .
Latency Consideration
The frame size and traffic rates play an important role in the latency improvement of the high
priority frame when sent together with the low priority frames. Without MC-MLPPP, high priority
frames have to wait for the whole low priority frame to be transmitted over the link. The latency
improvement with MC-MLPPP is more evident, when low priority frames are interrupted frequently
by the high priority frames.
70
Layer Descriptions
Fig. 10 depicts two cases of latency scenario. The example assumes an MLPPP group with an E1
member link of 1920 kbps bandwidth capacity and fragmentation size of 375 bytes.
Without MC-MLPPP, all fragments of the BE frame would be transmitted without considering
high priority CS7 frame. The CS7 frame would have to wait for the whole BE fragments to be
transmitted. Thus the latency experienced by high priority traffic Tla, i.e. the total time taken to
transfer CS7 queue frame can be calculated as following:
Where:
• Tbe is the time taken to transfer the whole fragmented BE frame. In this example Tbe = (4*375
*8 bits)/1920 kbps = 6.250 ms
• Tcs7 is the time taken to transfer CS7 subframe. Tcs7 = (64*8 bits)/1920 kbps = 0.267 ms
In this case example, high priority traffic would experience a latency of 6.517 ms.
Enabling MC-MLPPP allows interruption of low priority traffic (BE frame) fragments by high
priority traffic as illustrated in Fig. 10. After CS7 frame is transmitted, then transmission of BE
fragments is resumed. The latency experienced by high priority traffic Tla, when using MC-MLPPP
can be calculated as following:
Where:
• Tfbe is the time taken to transfer one BE fragment. Tfbe = (375*8 bits)/1920 kbps = 1.560 ms
71
Layer Descriptions
The latency of high priority traffic when MC-MLPPP is enabled in this example is 1.827 ms.
However, the processing delay (typically less than 1 ms) is also present and thus theoretical delays
will not be achieved exactly.
Configuration Options
The available configuration options required for MC-MLPPP are presented below.
Frames arriving first to the multiplexing process must wait for other high priority frames adding
to the latency. Selecting PPPMux configuration parameters (PPPMux Transmitter) appropriately
to reduce the overhead for higher priority frames) and enabling multiclass with suitable MLPPP
fragment size ensures that further latency is not introduced due to multiplexing frames. MC-MLPPP
is mainly focused to reduce the latency of high priority frames. The latency of low priority frames is
increased because of high priority frames interruption.
Consider the following configuration when PPPMux is only enabled on an MLPPP group with
bandwidth of 1920 kbps (E1 link) and fragmentation size of 375 bytes.
• Transmit timer = 4 ms
• Maximum frame-size = 256 bytes
• Subframe count = 4
• Subframe size = 64 bytes
Assuming that CS7 traffic (frame size of 64 bytes) is received at 1 frame/ms. The configuration
above ensures that every PPP multiplexed frame will consist of four CS7 subframe. The first CS7
subframe arriving, will have to wait Tw = 3 ms for the next three CS7 subframe. The size of BE
frame in this example is 1500 bytes.
72
Layer Descriptions
Where:
• Tw is the waiting time for the first CS7 frame before the remaining frames arrived, 3 ms in this
example
• Tmux is the time taken to transmit the PPP multiplexed frame over the link. Tmux = (4*64*8
bits)/1920 kbps = 1.06 ms
• Tbe is the time taken to transmit the whole BE frame. Tbe = (4*375*8 bits)/1920 kbps = 6.25 ms
In this case example, a latency of PPP multiplexed frame is 10.31 ms.
Where:
• Tfbe is the time taken to transfer one BE fragment. Tfbe = (375*8 bits)/1920 kbps = 1.56 ms
The latency of PPP multiplexed frame when MC-MLPPP is enabled in this example is 5.62 ms.
However, the processing delay (typically less than 1 ms) is also present and thus theoretical delays
will not be achieved exactly.
73
Layer Descriptions
There are only two multi link classes when MC-MLPPP is enabled with PPPMux. Although,
multiclass negotiation can happen with more than 2 classes, the system enforces traffic to use two
multilink classes; EF and CS7 are placed to the same multilink class because preceding PPPmux
function has already multiplexed CS7 and EF frames to the same PPPmux packet. Rest of the traffic
classes are enforced to another multilink class.
In Fig. 12, when PPPMux is enabled with multiclass (negotiated with 4 classes), CS7 and EF are
mapped to multi link class 2. Whereas, AF4, AF3, AF2, AF1 and BE are mapped to multi link class
0. CS7 and EF are multiplexed to the same frame, thus it is not meaningful to allow CS7 suspend
EF and therefore they must be in the same class
Fault Management
The supported TDM fault management function is available as described in chapter 5 Fault
Management Operation and Configuration.
74