Next GenerationSDH/SONETEvolution or Revolution?

Huub van HelvoortNetworking Consultant, The Netherlands

Innodata0470091215.jpg

Next GenerationSDH/SONET

Next GenerationSDH/SONETEvolution or Revolution?

Huub van HelvoortNetworking Consultant, The Netherlands

Copyright # 2005 John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester,West Sussex PO19 8SQ, England

Telephone (+44) 1243 779777

Email (for orders and customer service enquiries): cs-books@wiley.co.ukVisit our Home Page on www.wiley.com

All Rights Reserved. No part of this publication may be reproduced, stored in a retrievalsystem or transmitted in any form or by any means, electronic, mechanical, photocopying,recording, scanning or otherwise, except under the terms of the Copyright, Designs andPatents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd,90 Tottenham Court Road, London W1T 4LP, UK, without the permission in writing ofthe Publisher. Requests to the Publisher should be addressed to the Permissions Department,John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ,England, or emailed to permreq@wiley.co.uk, or faxed to (+44) 1243 770620.

Designations used by companies to distinguish their products are often claimed as trademarks.All brand names and product names used in this book are trade names, service marks, trademarksor registered trademarks of their respective owners. The publisher is not associated withany product or vendor mentioned in this book.

This publication is designed to provide accurate and authoritative information in regard tothe subject matter covered. It is sold on the understanding that the Publisher is not engagedin rendering professional services. If professional advice or other expert assistance is required, theservices of a competent professional should be sought.

Other Wiley Editorial Offices

John Wiley & Sons Inc., 111 River Street, Hoboken, NJ 07030, USA

Jossey-Bass, 989 Market Street, San Francisco, CA 94103-1741, USA

Wiley-VCH Verlag GmbH, Boschstr. 12, D-69469 Weinheim, Germany

John Wiley & Sons Australia Ltd, 33 Park Road, Milton, Queensland 4064, Australia

John Wiley & Sons (Asia) Pte Ltd, 2 Clementi Loop # 02-01, Jin Xing Distripark, Singapore129809

John Wiley & Sons Canada Ltd, 22 Worcester Road, Etobicoke, Ontario, Canada M9W 1L1

Wiley also publishes its books in a variety of electronic formats. Some content that appears inprint may not be available in electronic books.

British Library Cataloguing in Publication Data

A catalogue record for this book is available from the British Library

ISBN 0-470-09120-7 (HB)

Typeset in 10/12pt Palantino by Thomson Press (India) Limited, New Delhi, India.Printed and bound in Great Britain by TJ International Ltd, Padstow, Cornwall.This book is printed on acid-free paper responsibly manufactured from sustainable forestryin which at least two trees are planted for each one used for paper production.

http://www.wiley.com

To my wife Leontine, my daughter Mayke and son Arjanand my grandson Reshano for their support and patience

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Concatenation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1 Payload container concatenation . . . . . . . . . . . . . . . . . . . . 92.2 Contiguous concatenation . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 CCAT of VC–4 and STS–1 SPE . . . . . . . . . . . . . . . 142.2.2 CCAT of VC–2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Virtual concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.1 Payload distribution and reconstruction . . . . . . . . 182.3.2 VCAT of VC–n . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.3 VCAT of VC–m. . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.4 VCAT of PDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4 Applications of concatenation . . . . . . . . . . . . . . . . . . . . . . 322.4.1 Contiguous to virtual to contiguous conversion . . 322.4.2 VCAT and data transport . . . . . . . . . . . . . . . . . . . 342.4.3 VCAT and OTN signal transport . . . . . . . . . . . . . . 34

3 Link capacity adjustment scheme . . . . . . . . . . . . . . . . . . . . . . 353.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2 LCAS for virtual concatenation . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2.2 Control packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3 Changing the size of a virtual concatenated group . . . . . . 47

3.3.1 Planned addition of member(s) . . . . . . . . . . . . . . 473.3.2 Planned deletion of member(s) . . . . . . . . . . . . . . 483.3.3 Temporary removal of member . . . . . . . . . . . . . . 49

3.4 LCAS to non-LCAS interworking . . . . . . . . . . . . . . . . . . 513.4.1 LCAS Source and non-LCAS Sink . . . . . . . . . . . . 513.4.2 Non-LCAS Source and LCAS Sink. . . . . . . . . . . . 51

3.5 LCAS control packet details . . . . . . . . . . . . . . . . . . . . . . 513.5.1 The higher order VLI. . . . . . . . . . . . . . . . . . . . . . 523.5.2 The lower order VLI . . . . . . . . . . . . . . . . . . . . . . 543.5.3 The OTN VLI . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.5.4 The PDH VLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4 The LCAS protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.1.1 Asymmetric connections . . . . . . . . . . . . . . . . . . . 674.1.2 Symmetric connections . . . . . . . . . . . . . . . . . . . . 684.1.3 Unidirectional operation . . . . . . . . . . . . . . . . . . . 68

4.2 The size of a VCG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.3 The LCAS protocol described using SDL . . . . . . . . . . . . 70

4.3.1 Used SDL symbols . . . . . . . . . . . . . . . . . . . . . . . 704.3.2 LCAS state machines . . . . . . . . . . . . . . . . . . . . . . 704.3.3 LCAS events used in the SDL diagrams . . . . . . . 714.3.4 The SDL diagrams . . . . . . . . . . . . . . . . . . . . . . . . 74

5 LCAS time sequence diagrams . . . . . . . . . . . . . . . . . . . . . . . 815.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.2 Provisioning a member . . . . . . . . . . . . . . . . . . . . . . . . . . 825.3 VCG state transition examples . . . . . . . . . . . . . . . . . . . . 83

5.3.1 An increase of the bandwidth of a VCG . . . . . . . 835.3.2 A decrease of the bandwidth of a VCG . . . . . . . . 885.3.3 Decrease of bandwidth due to

a network problem . . . . . . . . . . . . . . . . . . . . . . . 93

6 Generic framing procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 996.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.2 Common aspects of GFP for octet-aligned payloads . . . . 102

6.2.1 Basic signal structure for GFP client frames. . . . . 1026.2.2 GFP client frames . . . . . . . . . . . . . . . . . . . . . . . . 1096.2.3 GFP control frames . . . . . . . . . . . . . . . . . . . . . . . 1126.2.4 GFP frame-level functions . . . . . . . . . . . . . . . . . . 112

viii Contents

6.3 Client specific aspects for frame-mapped GFP . . . . . . . . 1146.3.1 Ethernet MAC payload . . . . . . . . . . . . . . . . . . . . 1146.3.2 IP/PPP payload. . . . . . . . . . . . . . . . . . . . . . . . . . 1146.3.3 RPR payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.3.4 Fibre Channel payload via FC-BBW . . . . . . . . . . 1176.3.5 Direct mapping of MPLS . . . . . . . . . . . . . . . . . . . 1176.3.6 Error handling in frame-mapped GFP . . . . . . . . . 118

6.4 Client specific aspects for transparent-mapped GFP . . . . 1196.4.1 Common aspects of GFP-T . . . . . . . . . . . . . . . . . 1196.4.2 Client-specific signal fail aspects . . . . . . . . . . . . . 121

6.5 Server specific aspects of GFP. . . . . . . . . . . . . . . . . . . . . 1216.6 GFP PDU examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.6.1 GFP-F PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.6.2 GFP-T PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246.6.3 GPT CMF PDU . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7 Functional models for LCAS and GFP. . . . . . . . . . . . . . . . . . 1257.1 Virtual concatenation functions. . . . . . . . . . . . . . . . . . . . 125

7.1.1 Sn–Xv Trail Termination function . . . . . . . . . . . . 1267.1.2 Sn–Xv/Sn–X adaptation function . . . . . . . . . . . . 1267.1.3 Sn–X Trail Termination function . . . . . . . . . . . . . 1297.1.4 Sn Trail Termination function . . . . . . . . . . . . . . . 131

7.2 S4–Xc to S4–Xc interworking function . . . . . . . . . . . . . . 1357.3 LCAS-capable VCAT functions . . . . . . . . . . . . . . . . . . . . 141

7.3.1 Sn–Xv–L Layer Trail Termination function . . . . . 1417.3.2 Sn–Xv/Sn–X–L adaptation function . . . . . . . . . . 1427.3.3 Sn–X–L Trail Termination function . . . . . . . . . . . 1467.3.4 Sn Trail Termination function . . . . . . . . . . . . . . . 1497.3.5 Sn–X–L to Client adaptation function . . . . . . . . . 149

7.4 GFP adaptation functions . . . . . . . . . . . . . . . . . . . . . . . . 1517.4.1 Source side GFP adaptation processes . . . . . . . . . 1527.4.2 Sink side GFP adaptation processes. . . . . . . . . . . 158

7.5 Equipment models for GFP . . . . . . . . . . . . . . . . . . . . . . 1657.5.1 Ethernet tributary port. . . . . . . . . . . . . . . . . . . . . 1677.5.2 IP router port. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677.5.3 SAN tributary port . . . . . . . . . . . . . . . . . . . . . . . 168

8 The LCAS procedure exercised . . . . . . . . . . . . . . . . . . . . . . . 1698.1 Basic configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

8.1.1 The VCG Source side configuration . . . . . . . . . . . 1718.1.2 The VCG Sink side configuration. . . . . . . . . . . . . 173

Contents ix

8.1.3 VCG Source, VCG Sink and subnetworkconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

8.2 Exercise 1: Initiate a 3-member VCG. . . . . . . . . . . . . . . . 1788.2.1 Step a: provision the connectivity . . . . . . . . . . . . 1788.2.2 Step b: provision the Sink . . . . . . . . . . . . . . . . . . 1818.2.3 Step c: provision the Source. . . . . . . . . . . . . . . . . 182

8.3 Exercise 2: Addition of a member . . . . . . . . . . . . . . . . . . 1898.3.1 Step a: provision the Sink . . . . . . . . . . . . . . . . . . 1908.3.2 Step b: provision the connectivity . . . . . . . . . . . . 1928.3.3 Step c: provision the Source. . . . . . . . . . . . . . . . . 194

8.4 Exercise 3: Removal of a member . . . . . . . . . . . . . . . . . . 2008.4.1 Step a: provision the Source . . . . . . . . . . . . . . . . 2018.4.2 Step b: provision the Sink . . . . . . . . . . . . . . . . . . 2058.4.3 Step c: remove the connectivity . . . . . . . . . . . . . . 208

8.5 Exercise 4: Member failure . . . . . . . . . . . . . . . . . . . . . . . 2108.6 Exercise 5: Member recovery . . . . . . . . . . . . . . . . . . . . . 2158.7 Exercise 6: Network degraded . . . . . . . . . . . . . . . . . . . . 2208.8 For further study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2268.9 Configuration with LCAS disabled . . . . . . . . . . . . . . . . . 226

8.9.1 The VCG Source side configuration . . . . . . . . . . . 2278.9.2 The VCG Sink side configuration. . . . . . . . . . . . . 228

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

x Contents

Preface

Since the turn of the 20th century, telecommunication has shifted fromthe traditional voice transport to data transport, although digitizedvoice is still a large contributor. Instead of an evolution of the existingtransport standards, a revolution was necessary to enable theadditional data related transport. This revolution is the justificationfor the title of this book: Next Generation SDH/SONET.

In this book I describe the extensions and adaptations made to thetelecommunication standards to provide more granularity in order toaccommodate the bandwidth requirements of the data signals. Theemphasis in this book is on the explanation of the design considera-tions and use of Virtual Concatenation (VCAT), the additional flex-ibility provided by the Link Capacity Adjustment Scheme (LCAS) andthe Generic Framing Procedure (GFP). Examples are provided to helpthe reader understand the operation of these procedures. All SDH/SONET equipment that supports VCAT, LCAS and GFP will beconsidered to be of the next generation. The application of VCAT,LCAS and GFP has even been extended beyond SDH/SONET to OTNand PDH. In fact they can be applied to any synchronous means oftransport.

Based on the sources of the questions that I have answered in theUsenet newsgroup, comp.dcom.sdh-sonet, I expect that many readersof this book will be employed by SDH/SONET equipment manufac-turers, SDH/SONET device manufacturers and SDH/SONET networkoperators and that it will help them in developing and deploying theNext Generation SDH/SONET network and its Network Elements.

I also hope that this book will be used by students in telecommu-nication technology and members of the IEEE community as a refer-ence for understanding the operation of the Next Generation SDH/SONET.

Acknowledgements

I especially thank Trevor Wilson, Chris Murton, Nevin Jones, MarkCarson, James McKee and Enrique Hernandez-Valencia for theircooperation and for sharing my enthusiasm. They stood with me atthe cradle of the LCAS and GFP standards.

Huub van Helvoort, M.S.E.E., Senior member IEEE

1

Introduction

To the next generation SDH/SONET

Although it is assumed that the reader has a basic understanding of theoperation of the Synchronous Digital Hierarchy (SDH) and/or theSynchronous Optical NETwork (SONET), this book starts with a shorthistory of the revolutions and evolutions that have taken place duringand after the design of the SDH/SONET standards.

The conventions adopted in this book will be explained to avoidconfusion caused by the different terminology used in the SDH,SONET, OTN and PDH standards and to provide a consistentdescription of the features of the next generation SDH/SONET.

1.1 HISTORY

During the evolution of digital multiplexes, e.g. from the primary ratemultiplexes 2048 kbit/s E1 and 1544 kbit/s DS1 up to the fourth ordermultiplexes 139.264 Mbit/s E4 and 274.176Mbit/s DS4, in generalreferred to as Pleisiochronous Digital Hierarchy (PDH) signals, itbecame clear that the application of these multiplexes in larger net-works required an improvement of the network synchronisation and abetter Operations, Administration and Maintenance (OA&M) struc-ture. The OA&M structure should provide a measure for the quality ofthe transported signals and a validation of the connection through thenetwork. The existing PDH structure could not be used to fulfil these

Next Generation SDH/SONET: Evolution or Revolution? Huub van Helvoort# 2005 John Wiley & Sons, Ltd ISBN: 0-470-09120-7

requirements and so a revolution was needed; it was a revolutionbecause it requires new equipment and a new network structure. Therevolutionary Synchronous Digital Hierarchy (SDH) and SynchronousOptical NETwork (SONET) were designed to meet the requiredimprovements. A PDH network has a strong vertical structure andis star shaped. The SDH/SONET network has a strong horizontalstructure with ring shaped hierarchical layers and Add/Drop Multi-plexors (ADM) providing the interconnection between the layers andconnections for client or tributary signals. The first generation SDH/SONET appeared after the standardisation in 1986.

As the PDH multiplexes were designed to transport voice signalsand private lines the SDH and SONET multiplex were designedinitially to transport the same signals. Because of their nature of multi-plexing they are referred to as Time Division Multiplexes (TDM). Anadditional advantage of the revolutionary design of SDH/SONET isthe multiplexing structure where tributary signals are mapped as pay-load into containers. These containers, together with their own timinginformation and OA&M overhead, are transported as independentvirtual containers in the SDH/SONET network. The multiplex struc-ture of SDH/SONET is also designed to enable the evolution to higherorder multiplexes to meet the demand for transporting more and morepayload. See Chapter 2 for the evolution of SDH/SONET to providethe increased bandwidth by defining Contiguous conCATenation(CCAT) and the introduction of CCAT in existing networks by usingVirtual conCATenation (VCAT). Once defined, it appeared that VCATcould also be used to provide efficiently a matching bandwidth fornon-voice related signals. The most recent defined application is thedeployment of VCAT to enable the gradual introduction of an all-Optical Transport Network (OTN) as an evolution of existing SDH/SONET networks. The multiplexing of the optical signal or wave-length is commonly referred to as Wavelength Division Multiplexing(WDM).

In the last years of the 20th century, due to the enormous popularityof the Internet and the expansion of Internet Protocol (IP) basednetworks, an explosion in the number of IP-based end systemsoccurred, e.g. Internet Service Providers (ISP) Points of Presence(PoP). At the same time, the application of Ethernet was growingbeyond the limits of the Local Area Network (LAN) into the MetroArea Network (MAN) and the even larger Wide Area Networks(WAN). Also the demand for data storage shared among systems inremote locations was growing, i.e. the introduction of a Storage Area

2 Next Generation SDH/SONET

Network (SAN). The expansion of these packet data and streamingdata based signals created a growing demand for transport of data inan efficient and secure way. Because of the existence and availability ofSDH/SONET networks, including the provided Quality of Service(QoS) and connection protection mechanisms, it was clear that SDH/SONET could provide the transport of data signals in the same way asit had already been doing for voice signals and private lines. Initially,however, the transport bandwidth provided by SDH/SONET contain-ers did not match efficiently the bandwidth required by the datasignals. In Chapter 2, it is explained how VCAT can provide anefficient transport of data signals.

As the demand by data applications for bandwidth can vary in time,the payload container capacity provided by VCAT is not alwaysutilized efficiently. To improve this utilisation, a protocol has beendesigned to flexibly adjust the payload container size: the LinkCapacity Adjustment Scheme (LCAS). Chapter 3 provides the metho-dology used by the LCAS protocol, i.e. the LCAS overhead signalsadded to the virtual concatenation control information that wererequired to provide a flexible and hitless increase or decrease of avirtual concatenated signal. Chapter 3 also provides a description ofthe operation of LCAS during an increase and decrease of the payloadbandwidth. The LCAS protocol is described in state machine diagramsin Chapter 4. The state machines are depicted using the ITU-TSpecification and Description Language (SDL). Chapter 5 containsexamples of the operation of LCAS under different conditions byusing Time Sequence Diagrams (TSD).

The major part of IP, Ethernet traffic is transported over the publicnetwork by encapsulating it in Frame Relay, Point-to-Point Protocol(PPP), High-Level Data Link Control (HDLC), Packet over SONET/SDH (POS) or Asynchronous Transport Multiplex (ATM). SAN pro-tocols such as Fibre Channel (FC), Enterprise Systems CONnectivity(ESCON) and Fibre CONnectivity (FICON) have originally beentransported over the public network by using proprietary (and inmost cases vendor-specific) solutions. Figure 1.1 gives an example ofhow packet data can be transported.

Currently, most line interfaces for IP edge routers and most FrameRelay and PPP interfaces operate at PDH rates or low order SDH/SONET rates, although STM-16/OC-48 and STM-64/OC-192 inter-faces are being introduced very rapidly, especially in MAN andWAN networks. Considering the widespread availability of inexpen-sive 10/100/1000Mbit/s Ethernet interfaces on Customer Premises

Introduction 3

Equipment (CPE), e.g. switches and routers, the growing need toimprove the transport capabilities of ISP PoP equipment and SANinterconnectivity, as well as the recent introduction of Virtual LANbased Virtual Private Networking (VPN), there is a renewed interestfor a QoS friendly, standard-based mechanism to transport IP, Ether-net and SAN traffic over TDM and WDM networks. Based on thisinterest, a mapping of all these Variable Bit Rate (VBR) signals into aConstant Bit Rate (CBR) signal was developed. This mapping isdefined as Generic Frame Procedure (GFP) and is described in detailin Chapter 6.

1.2 CONVENTIONS

This book tries to cover both the SDH standards as defined orrecommended by the global standardisation committee ITU-Tand by the regional European standardisation committee ETSI andthe SONET standards as defined by regional standardisationcommittee ANSI T1.When appropriate, mention will also be madeof connections to equivalent uses of VCAT in OTN, also defined bythe ITU-T.

To avoid confusion that would be caused by mixing terminologyand abbreviations used in the SDH, SONET, OTN and PDH standards,

SDH/SONET

POS

Ethernet

PPP

ATM

HDLC

IP SAN

FICONESCONFibre Channel

PDH

Figure 1.1 Packet data transfer

4 Next Generation SDH/SONET

this book uses a limited set of abbreviations and terms. To avoid evenmore confusion, it employs abbreviations and terms that are already inuse by the ITU-T.

� An SDH Container is the equivalent of a SONET Synchronous Pay-load Envelope (SPE).

� C–n (n¼ 3,4) – a continuous payload container of type n, a termused by the ITU-T. Normally represented as a frame structure byusing a matrix with 9 rows by p columns where each cell containsan octet. The frame time is 125 ms. This container can transport aCBR signal of 9 � p � 8 � 8 kbit/s. A container C– 4 (p¼ 260) cantransport 149 760 kbit/s and a container C–3 (p¼ 84) can transport48 384 kbit/s.

� C–m (m¼ 2,12,11) – a continuous payload container of type m.Represented as a frame structure by using a matrix with 4 rows byq columns where each cell contains an octet. The frame time is500 ms. This container can transport a CBR signal of 4 � q � 8 �8 kbit/s. A container C–2 (q¼ 106) will transport 6784 kbit/s, acontainer C–12 (q¼ 43) 2176 kbit/s and a container C–11 (q¼ 25)1600 kbit/s.

� VC–n – a Virtual Container of type n, equal to a container C–n withan additional 9 bytes Path Overhead and optional fixed stuff. In thisbook, it is used for the SDH virtual containers VC– 4 and VC–3, andthe equivalent SONET Synchronous Transport Signal STS–3c SPEand STS–1 SPE.

� VC–m – a Virtual Container of type m, equal to a container C–mwith an additional 4 bytes Path Overhead and optional fixed stuff.In this book, it is used for the SDH virtual containers VC–2, VC–12and VC–11, and the SONET virtual tributaries VT6 SPE, VT3 SPE,VT2 SPE and VT1.5 SPE.

� C–n–Xc – a contiguous concatenated payload container of size Xtimes the size of a container C–n.

� VC–n–Xc – a Virtual Container transporting a container C–n–Xcwith an additional Path overhead and optional fixed stuff columns.

� VC–n–Xv – X virtual concatenated VC–n, used in this book toindicate any of the following: a VC–4–Xv, a VC–3–Xv, an STS–3c–Xv SPE and an STS–1–Xv SPE.

� VC–m–Xv – X virtual concatenated VC–m, used in this book toindicate any of the following: a VC–2–Xv, a VC–12–Xv, a VC–11–Xv, a VT6–Xv SPE, a VT3–Xv SPE, a VT2–Xv SPE and a VT1.5–Xv SPE.

Introduction 5

� Sn – used in functional models to refer to the higher order VC–nlayer (n¼ 3, 4, 4–Xc) or lower order VC–3 layer.

� Sm – used in functional models to refer to the lower order VC–mlayer (m¼ 11, 12, 2).

� OPUk (k¼ 1,2) – (OTN) an Optical channel Payload Unit of type kcan be compared to an SDH payload container C–n.

� OPUk–Xv – X virtual concatenated OPUk. Each OPUk in anOPUk–Xv is transported in an individual ODUk.

� ODUk – (OTN) an Optical channel Data Unit of type k. An ODUkcan be compared to an SDH virtual container VC–n.

� ODUk–Xv – X virtual concatenated ODUk.� E1 – a 2048 kbit/s framed PDH signal connected to electrical

interface E12. It has a basic frame structure of 32 timeslots or octetsat a frame rate of 125 msec. Two octets (consecutive timeslots 0) areused for the transport overhead. For additional Quality of Service, aCRC–4 multi-frame is used consisting of 16 basic frames at a multi-frame rate of 2 ms.

� E3 – a 34 368 kbit/s framed PDH signal connected to electricalinterface E31. It has a frame structure of 59 octet columns and 9rows plus 6 octets at a frame rate of 125 msec. 7 octets are used forthe transport overhead.

� DS1 – a 1544 kbit/s framed PDH signal connected to electricalinterface E11. It has a basic frame structure of 24 timeslots or octetsand a single bit transport overhead per frame at a frame rate of125 msec. 24 basic frames form an extended superframe with aframe rate of 3 ms.

� DS3 – a 44 736 kbit/s framed PDH signal connected to electricalinterface E32. It has a basic frame structure of 680 bit columns and 7rows. Each row consists of 8 blocks containing 1 transport overheadbit and 84 payload bits. The frame rate is 106 msec.

In this book, the term Section is used for the means for transport-ation of information between two network elements and no distinc-tion is made between an SDH Regenerator Section, in SONETtermed Section, and an SDH Multiplex Section, in SONET termedLine, i.e. the physical connection including the regenerators. BothSDH and SONET use the term Path for the connection through anetwork between the points where a container is assembled anddisassembled. The total information transported over a path, i.e. thepayload plus the OA&M information, is in SDH normally referredto as a Trail.

6 Next Generation SDH/SONET

The order of transmission of information in all the figures in thisbook is first from left to right, and then from top to bottom. Withineach byte or octet the most significant bit is transmitted first. The MostSignificant Bit (MSB) (bit 1) is shown at the left side in all the figuresand the Least Significant Bit (LSB) at the right side.

Introduction 7

2

Concatenation

Extending the range of available bandwidth

The introduction of the methodology of concatenation has extended thepayload transport capability of SDH/SONET networks. On the onehand, contiguous concatenation provides the higher order multiplexesand on the other hand, virtual concatenation provides the flexibilityneeded for backwards compatibility and enables a staged introduction ofcontiguous concatenation in existing networks. The standardisation ofconcatenation is driven mainly by the evolution of the applicabletechnology, i.e. the operational speed of optics and electronics.

Concatenation is the normal evolution of the SDH/SONET technology.

2.1 PAYLOAD CONTAINER CONCATENATION

The original standard set of payload containers, i.e. for SDH the set ofVirtual Containers VC–4, VC–3, VC–2, VC–12 and VC–11 and forSONET the set of Synchronous Transport Signals STS–1, and VirtualTributaries VT6, VT3, VT2, VT1.5, did provide a wide range of payloadcapacities: from 1600 kbit/s up to 149.76 Mbit/s. The initially availablepayload sizes were sufficient to transport efficiently PDH multiplexesfrom the 1.544Mbit/s DS1 and 2.048Mbit/s E1 up to the 44.736 Mbit/sDS3 and 139.264Mbit/s E4.

Figure 2.1 shows the original multiplex structures of SDH andSONET. Constant bit-rate signals or tributaries, e.g. the PDH signals,

Next Generation SDH/SONET: Evolution or Revolution? Huub van Helvoort# 2005 John Wiley & Sons, Ltd ISBN: 0-470-09120-7

are mapped into the appropriate payload containers C–n or C–m.These containers together with their OA&M information constitute aVC–n or VC–m. Pointer processing is used to maintain the individualtiming of the tributaries through the network from ingress to egress,and multiplexing is used to transport one or more lower ordertributaries or multiplexes in a higher order multiplex over the samesection in the network. Figure 2.1 also shows that the basic transportelement in SDH networks is the VC–4 and that the SONET networkuses the STS–1 SPE as a basic transport element.

Driven by a demand for even higher order SDH and SONETmultiplexes and enabled by new developments in the optical technol-ogy, the standardisation committees have extended the existing multi-plex structures. Similar to the ITU-T multiplexing schemes of PDH,each next higher order multiplex in SDH/SONET has a four timeslarger payload transport capability than the previous multiplex.

The payload capacity of these new higher order multiplexes cannotonly be used to transport four times the payload container from theprevious multiplex but can also be used to transport a single contig-uous payload container. The methodology used is called concatenation;a procedure whereby a multiplicity of payload containers is associatedone with another with the result that their combined capacity can beused as a single payload container across which bit sequence integrity

C-2

AU-3

TUG-2

C-12 C-3

STS-1

VT6

x7

x2x3

OC-1x1

SPE

SPE

x4VT3

VT2 VT3 VT6

C-11

VT1.5

VT1.5

VT2x1

SONET multiplex structure

DS1 DS3/E3E1 DS1 C DS2

AUG-1

AU-4

TUG-2

TUG-3

C-4C-11 C-12 C-3C-2

VC-11 VC-12 VC-2 VC-3

VC-4

TU-11 TU-12 TU-2 TU-3

x7

x1

x3

x1

x1

x3x4

STM-1x1

mappingaligningmultiplexingpointer processing

xN

SDH multiplex structure

E1 E4E3/DS3DS1 DS2

Figure 2.1 SDH and SONET initial multiplex structure

10 Next Generation SDH/SONET