SONET: Evolution or Revolution

Next Generation SDH/SONET Evolution or Revolution? Huub van Helvoort Networking Consultant, The Netherlands Next Gene...

Author: Huub van Helvoort

40 downloads 753 Views 1MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Next Generation SDH/SONET Evolution or Revolution? Huub van Helvoort Networking Consultant, The Netherlands

Next Generation SDH/SONET

Next Generation SDH/SONET Evolution or Revolution? Huub van Helvoort Networking 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): [email protected] Visit our Home Page on www.wiley.com All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under the terms of the Copyright, Designs and Patents 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 of the 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 [email protected], 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, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the Publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services 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, Singapore 129809 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 in print 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 forestry in which at least two trees are planted for each one used for paper production.

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

Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Concatenation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Payload container concatenation . . . . . . . . . . . . . . . . . . 2.2 Contiguous concatenation . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 CCAT of VC–4 and STS–1 SPE . . . . . . . . . . . . . 2.2.2 CCAT of VC–2 . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Virtual concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Payload distribution and reconstruction . . . . . . 2.3.2 VCAT of VC–n . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 VCAT of VC–m . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 VCAT of PDH . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Applications of concatenation . . . . . . . . . . . . . . . . . . . . 2.4.1 Contiguous to virtual to contiguous conversion 2.4.2 VCAT and data transport . . . . . . . . . . . . . . . . . 2.4.3 VCAT and OTN signal transport . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

9 9 13 14 17 17 18 21 25 28 32 32 34 34

3 Link capacity adjustment scheme . . . . . . . . . . . 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3.2 LCAS for virtual concatenation . . . . . . . . . 3.2.1 Methodology . . . . . . . . . . . . . . . . . . 3.2.2 Control packet . . . . . . . . . . . . . . . . . 3.3 Changing the size of a virtual concatenated

. . . . . .

. . . . . .

35 35 36 36 37 47

...... ...... ...... ...... ...... group .

. . . . . .

. . . . . .

. . . . . .

viii

Contents

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

47 48 49 51 51 51 51 52 54 57 61

4 The LCAS protocol. . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Asymmetric connections . . . . . . . . . . . . 4.1.2 Symmetric connections . . . . . . . . . . . . . 4.1.3 Unidirectional operation . . . . . . . . . . . . 4.2 The size of a VCG. . . . . . . . . . . . . . . . . . . . . . . 4.3 The LCAS protocol described using SDL . . . . . 4.3.1 Used SDL symbols . . . . . . . . . . . . . . . . 4.3.2 LCAS state machines . . . . . . . . . . . . . . . 4.3.3 LCAS events used in the SDL diagrams 4.3.4 The SDL diagrams . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

67 67 67 68 68 69 70 70 70 71 74

5 LCAS time sequence diagrams . . . . . . . . . . . . . . . . 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Provisioning a member . . . . . . . . . . . . . . . . . . . 5.3 VCG state transition examples . . . . . . . . . . . . . 5.3.1 An increase of the bandwidth of a VCG 5.3.2 A decrease of the bandwidth of a VCG . 5.3.3 Decrease of bandwidth due to a network problem . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

81 81 82 83 83 88

.......

93

3.4

3.5

3.3.1 3.3.2 3.3.3 LCAS 3.4.1 3.4.2 LCAS 3.5.1 3.5.2 3.5.3 3.5.4

Planned addition of member(s) . . . Planned deletion of member(s) . . . Temporary removal of member . . . to non-LCAS interworking . . . . . . . LCAS Source and non-LCAS Sink . Non-LCAS Source and LCAS Sink. control packet details . . . . . . . . . . . The higher order VLI. . . . . . . . . . . The lower order VLI . . . . . . . . . . . The OTN VLI . . . . . . . . . . . . . . . . The PDH VLI. . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

6 Generic framing procedure . . . . . . . . . . . . . . . . . . . . . . . 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Common aspects of GFP for octet-aligned payloads . 6.2.1 Basic signal structure for GFP client frames. . 6.2.2 GFP client frames . . . . . . . . . . . . . . . . . . . . . 6.2.3 GFP control frames . . . . . . . . . . . . . . . . . . . . 6.2.4 GFP frame-level functions . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

99 100 102 102 109 112 112

ix

Contents

6.3

6.4

6.5 6.6

Client specific aspects for frame-mapped GFP . . . . . 6.3.1 Ethernet MAC payload . . . . . . . . . . . . . . . . . 6.3.2 IP/PPP payload . . . . . . . . . . . . . . . . . . . . . . . 6.3.3 RPR payload . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.4 Fibre Channel payload via FC-BBW . . . . . . . 6.3.5 Direct mapping of MPLS . . . . . . . . . . . . . . . . 6.3.6 Error handling in frame-mapped GFP . . . . . . Client specific aspects for transparent-mapped GFP . 6.4.1 Common aspects of GFP-T . . . . . . . . . . . . . . 6.4.2 Client-specific signal fail aspects . . . . . . . . . . Server specific aspects of GFP. . . . . . . . . . . . . . . . . . GFP PDU examples . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1 GFP-F PDU . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.2 GFP-T PDU . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.3 GPT CMF PDU . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

114 114 114 115 117 117 118 119 119 121 121 122 122 124 124

7 Functional models for LCAS and GFP. . . . . . . . . . . . . . 7.1 Virtual concatenation functions. . . . . . . . . . . . . . . . 7.1.1 Sn–Xv Trail Termination function . . . . . . . . 7.1.2 Sn–Xv/Sn–X adaptation function . . . . . . . . 7.1.3 Sn–X Trail Termination function . . . . . . . . . 7.1.4 Sn Trail Termination function . . . . . . . . . . . 7.2 S4–Xc to S4–Xc interworking function . . . . . . . . . . 7.3 LCAS-capable VCAT functions . . . . . . . . . . . . . . . . 7.3.1 Sn–Xv–L Layer Trail Termination function . 7.3.2 Sn–Xv/Sn–X–L adaptation function . . . . . . 7.3.3 Sn–X–L Trail Termination function . . . . . . . 7.3.4 Sn Trail Termination function . . . . . . . . . . . 7.3.5 Sn–X–L to Client adaptation function . . . . . 7.4 GFP adaptation functions . . . . . . . . . . . . . . . . . . . . 7.4.1 Source side GFP adaptation processes . . . . . 7.4.2 Sink side GFP adaptation processes. . . . . . . 7.5 Equipment models for GFP . . . . . . . . . . . . . . . . . . 7.5.1 Ethernet tributary port. . . . . . . . . . . . . . . . . 7.5.2 IP router port. . . . . . . . . . . . . . . . . . . . . . . . 7.5.3 SAN tributary port . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

125 125 126 126 129 131 135 141 141 142 146 149 149 151 152 158 165 167 167 168

8 The LCAS procedure exercised . . . . . . . . . . . . . 8.1 Basic configuration . . . . . . . . . . . . . . . . . . . 8.1.1 The VCG Source side configuration . 8.1.2 The VCG Sink side configuration. . .

. . . .

. . . .

. . . .

. . . .

169 169 171 173

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

x

Contents

8.1.3

8.2

8.3

8.4

8.5 8.6 8.7 8.8 8.9

VCG Source, VCG Sink and subnetwork configuration . . . . . . . . . . . . . . . . . . . . . . Exercise 1: Initiate a 3-member VCG. . . . . . . . . . 8.2.1 Step a: provision the connectivity . . . . . . 8.2.2 Step b: provision the Sink . . . . . . . . . . . . 8.2.3 Step c: provision the Source. . . . . . . . . . . Exercise 2: Addition of a member . . . . . . . . . . . . 8.3.1 Step a: provision the Sink . . . . . . . . . . . . 8.3.2 Step b: provision the connectivity . . . . . . 8.3.3 Step c: provision the Source. . . . . . . . . . . Exercise 3: Removal of a member . . . . . . . . . . . . 8.4.1 Step a: provision the Source . . . . . . . . . . 8.4.2 Step b: provision the Sink . . . . . . . . . . . . 8.4.3 Step c: remove the connectivity . . . . . . . . Exercise 4: Member failure . . . . . . . . . . . . . . . . . Exercise 5: Member recovery . . . . . . . . . . . . . . . Exercise 6: Network degraded . . . . . . . . . . . . . . For further study. . . . . . . . . . . . . . . . . . . . . . . . . Configuration with LCAS disabled . . . . . . . . . . . 8.9.1 The VCG Source side configuration . . . . . 8.9.2 The VCG Sink side configuration. . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

177 178 178 181 182 189 190 192 194 200 201 205 208 210 215 220 226 226 227 228

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Preface Since the turn of the 20th century, telecommunication has shifted from the traditional voice transport to data transport, although digitized voice is still a large contributor. Instead of an evolution of the existing transport standards, a revolution was necessary to enable the additional data related transport. This revolution is the justification for the title of this book: Next Generation SDH/SONET. In this book I describe the extensions and adaptations made to the telecommunication standards to provide more granularity in order to accommodate the bandwidth requirements of the data signals. The emphasis in this book is on the explanation of the design considerations and use of Virtual Concatenation (VCAT), the additional flexibility provided by the Link Capacity Adjustment Scheme (LCAS) and the Generic Framing Procedure (GFP). Examples are provided to help the reader understand the operation of these procedures. All SDH/ SONET equipment that supports VCAT, LCAS and GFP will be considered to be of the next generation. The application of VCAT, LCAS and GFP has even been extended beyond SDH/SONET to OTN and PDH. In fact they can be applied to any synchronous means of transport. Based on the sources of the questions that I have answered in the Usenet newsgroup, comp.dcom.sdh-sonet, I expect that many readers of this book will be employed by SDH/SONET equipment manufacturers, SDH/SONET device manufacturers and SDH/SONET network operators and that it will help them in developing and deploying the Next Generation SDH/SONET network and its Network Elements. I also hope that this book will be used by students in telecommunication technology and members of the IEEE community as a reference for understanding the operation of the Next Generation SDH/ SONET.

Acknowledgements I especially thank Trevor Wilson, Chris Murton, Nevin Jones, Mark Carson, James McKee and Enrique Hernandez-Valencia for their cooperation and for sharing my enthusiasm. They stood with me at the 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 the operation of the Synchronous Digital Hierarchy (SDH) and/or the Synchronous Optical NETwork (SONET), this book starts with a short history of the revolutions and evolutions that have taken place during and after the design of the SDH/SONET standards. The conventions adopted in this book will be explained to avoid confusion caused by the different terminology used in the SDH, SONET, OTN and PDH standards and to provide a consistent description of the features of the next generation SDH/SONET.

1.1 HISTORY During the evolution of digital multiplexes, e.g. from the primary rate multiplexes 2048 kbit/s E1 and 1544 kbit/s DS1 up to the fourth order multiplexes 139.264 Mbit/s E4 and 274.176 Mbit/s DS4, in general referred to as Pleisiochronous Digital Hierarchy (PDH) signals, it became clear that the application of these multiplexes in larger networks required an improvement of the network synchronisation and a better Operations, Administration and Maintenance (OA&M) structure. The OA&M structure should provide a measure for the quality of the transported signals and a validation of the connection through the network. 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

2


requirements and so a revolution was needed; it was a revolution because it requires new equipment and a new network structure. The revolutionary Synchronous Digital Hierarchy (SDH) and Synchronous Optical NETwork (SONET) were designed to meet the required improvements. A PDH network has a strong vertical structure and is star shaped. The SDH/SONET network has a strong horizontal structure with ring shaped hierarchical layers and Add/Drop Multiplexors (ADM) providing the interconnection between the layers and connections 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 signals and private lines the SDH and SONET multiplex were designed initially to transport the same signals. Because of their nature of multiplexing they are referred to as Time Division Multiplexes (TDM). An additional advantage of the revolutionary design of SDH/SONET is the multiplexing structure where tributary signals are mapped as payload into containers. These containers, together with their own timing information and OA&M overhead, are transported as independent virtual containers in the SDH/SONET network. The multiplex structure of SDH/SONET is also designed to enable the evolution to higher order multiplexes to meet the demand for transporting more and more payload. See Chapter 2 for the evolution of SDH/SONET to provide the increased bandwidth by defining Contiguous conCATenation (CCAT) and the introduction of CCAT in existing networks by using Virtual conCATenation (VCAT). Once defined, it appeared that VCAT could also be used to provide efficiently a matching bandwidth for non-voice related signals. The most recent defined application is the deployment of VCAT to enable the gradual introduction of an allOptical Transport Network (OTN) as an evolution of existing SDH/ SONET networks. The multiplexing of the optical signal or wavelength is commonly referred to as Wavelength Division Multiplexing (WDM). In the last years of the 20th century, due to the enormous popularity of the Internet and the expansion of Internet Protocol (IP) based networks, an explosion in the number of IP-based end systems occurred, e.g. Internet Service Providers (ISP) Points of Presence (PoP). At the same time, the application of Ethernet was growing beyond the limits of the Local Area Network (LAN) into the Metro Area Network (MAN) and the even larger Wide Area Networks (WAN). Also the demand for data storage shared among systems in remote locations was growing, i.e. the introduction of a Storage Area

Introduction

3

Network (SAN). The expansion of these packet data and streaming data based signals created a growing demand for transport of data in an efficient and secure way. Because of the existence and availability of SDH/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 as it had already been doing for voice signals and private lines. Initially, however, the transport bandwidth provided by SDH/SONET containers did not match efficiently the bandwidth required by the data signals. In Chapter 2, it is explained how VCAT can provide an efficient 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 always utilized efficiently. To improve this utilisation, a protocol has been designed to flexibly adjust the payload container size: the Link Capacity Adjustment Scheme (LCAS). Chapter 3 provides the methodology used by the LCAS protocol, i.e. the LCAS overhead signals added to the virtual concatenation control information that were required to provide a flexible and hitless increase or decrease of a virtual concatenated signal. Chapter 3 also provides a description of the operation of LCAS during an increase and decrease of the payload bandwidth. The LCAS protocol is described in state machine diagrams in Chapter 4. The state machines are depicted using the ITU-T Specification and Description Language (SDL). Chapter 5 contains examples of the operation of LCAS under different conditions by using Time Sequence Diagrams (TSD). The major part of IP, Ethernet traffic is transported over the public network 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 protocols such as Fibre Channel (FC), Enterprise Systems CONnectivity (ESCON) and Fibre CONnectivity (FICON) have originally been transported over the public network by using proprietary (and in most cases vendor-specific) solutions. Figure 1.1 gives an example of how packet data can be transported. Currently, most line interfaces for IP edge routers and most Frame Relay and PPP interfaces operate at PDH rates or low order SDH/ SONET rates, although STM-16/OC-48 and STM-64/OC-192 interfaces are being introduced very rapidly, especially in MAN and WAN networks. Considering the widespread availability of inexpensive 10/100/1000 Mbit/s Ethernet interfaces on Customer Premises

4

Next Generation SDH/SONET SDH/SONET

POS

ATM

HDLC PDH PPP Fibre Channel

ESCON

FICON

Ethernet

SAN

IP

Figure 1.1 Packet data transfer

Equipment (CPE), e.g. switches and routers, the growing need to improve the transport capabilities of ISP PoP equipment and SAN interconnectivity, as well as the recent introduction of Virtual LAN based Virtual Private Networking (VPN), there is a renewed interest for a QoS friendly, standard-based mechanism to transport IP, Ethernet and SAN traffic over TDM and WDM networks. Based on this interest, a mapping of all these Variable Bit Rate (VBR) signals into a Constant Bit Rate (CBR) signal was developed. This mapping is defined as Generic Frame Procedure (GFP) and is described in detail in Chapter 6.

1.2 CONVENTIONS This book tries to cover both the SDH standards as defined or recommended by the global standardisation committee ITU-T and by the regional European standardisation committee ETSI and the SONET standards as defined by regional standardisation committee ANSI T1.When appropriate, mention will also be made of connections to equivalent uses of VCAT in OTN, also defined by the ITU-T. To avoid confusion that would be caused by mixing terminology and abbreviations used in the SDH, SONET, OTN and PDH standards,

Introduction

5

this book uses a limited set of abbreviations and terms. To avoid even more confusion, it employs abbreviations and terms that are already in use by the ITU-T. An SDH Container is the equivalent of a SONET Synchronous Payload Envelope (SPE). C–n (n ¼ 3,4) – a continuous payload container of type n, a term used by the ITU-T. Normally represented as a frame structure by using a matrix with 9 rows by p columns where each cell contains an octet. The frame time is 125 ms. This container can transport a CBR signal of 9 p 8 8 kbit/s. A container C– 4 (p ¼ 260) can transport 149 760 kbit/s and a container C–3 (p ¼ 84) can transport 48 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 by q columns where each cell contains an octet. The frame time is 500 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, a container 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 with an additional 9 bytes Path Overhead and optional fixed stuff. In this book, it is used for the SDH virtual containers VC– 4 and VC–3, and the equivalent SONET Synchronous Transport Signal STS–3c SPE and STS–1 SPE. VC–m – a Virtual Container of type m, equal to a container C–m with an additional 4 bytes Path Overhead and optional fixed stuff. In this book, it is used for the SDH virtual containers VC–2, VC–12 and 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 X times the size of a container C–n. VC–n–Xc – a Virtual Container transporting a container C–n–Xc with an additional Path overhead and optional fixed stuff columns. VC–n–Xv – X virtual concatenated VC–n, used in this book to indicate 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 to indicate 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.

6


Sn – used in functional models to refer to the higher order VC–n layer (n ¼ 3, 4, 4–Xc) or lower order VC–3 layer. Sm – used in functional models to refer to the lower order VC–m layer (m ¼ 11, 12, 2). OPUk (k ¼ 1,2) – (OTN) an Optical channel Payload Unit of type k can be compared to an SDH payload container C–n. OPUk–Xv – X virtual concatenated OPUk. Each OPUk in an OPUk–Xv is transported in an individual ODUk. ODUk – (OTN) an Optical channel Data Unit of type k. An ODUk can 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 octets at a frame rate of 125 msec. Two octets (consecutive timeslots 0) are used for the transport overhead. For additional Quality of Service, a CRC–4 multi-frame is used consisting of 16 basic frames at a multiframe rate of 2 ms. E3 – a 34 368 kbit/s framed PDH signal connected to electrical interface E31. It has a frame structure of 59 octet columns and 9 rows plus 6 octets at a frame rate of 125 msec. 7 octets are used for the transport overhead. DS1 – a 1544 kbit/s framed PDH signal connected to electrical interface E11. It has a basic frame structure of 24 timeslots or octets and a single bit transport overhead per frame at a frame rate of 125 msec. 24 basic frames form an extended superframe with a frame rate of 3 ms. DS3 – a 44 736 kbit/s framed PDH signal connected to electrical interface E32. It has a basic frame structure of 680 bit columns and 7 rows. Each row consists of 8 blocks containing 1 transport overhead bit and 84 payload bits. The frame rate is 106 msec. In this book, the term Section is used for the means for transportation of information between two network elements and no distinction is made between an SDH Regenerator Section, in SONET termed Section, and an SDH Multiplex Section, in SONET termed Line, i.e. the physical connection including the regenerators. Both SDH and SONET use the term Path for the connection through a network between the points where a container is assembled and disassembled. The total information transported over a path, i.e. the payload plus the OA&M information, is in SDH normally referred to as a Trail.

Introduction

7

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

2 Concatenation Extending the range of available bandwidth The introduction of the methodology of concatenation has extended the payload transport capability of SDH/SONET networks. On the one hand, contiguous concatenation provides the higher order multiplexes and on the other hand, virtual concatenation provides the flexibility needed for backwards compatibility and enables a staged introduction of contiguous concatenation in existing networks. The standardisation of concatenation is driven mainly by the evolution of the applicable technology, 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 of Virtual Containers VC–4, VC–3, VC–2, VC–12 and VC–11 and for SONET the set of Synchronous Transport Signals STS–1, and Virtual Tributaries VT6, VT3, VT2, VT1.5, did provide a wide range of payload capacities: from 1600 kbit/s up to 149.76 Mbit/s. The initially available payload sizes were sufficient to transport efficiently PDH multiplexes from the 1.544 Mbit/s DS1 and 2.048 Mbit/s E1 up to the 44.736 Mbit/s DS3 and 139.264 Mbit/s E4. Figure 2.1 shows the original multiplex structures of SDH and SONET. Constant bit-rate signals or tributaries, e.g. the PDH signals,


10

Next Generation SDH/SONET SDH multiplex structure

xN

pointer processing multiplexing aligning mapping

TUG-2

STM-1 x1 AUG-1 x1 AU-4

SONET multiplex structure

AU-3

VC-4 TUG-3 x1 x7

x3

SPE STS-1

x1 TU-2

TU-3

x4 VT1.5

x3 VT2

VC-11 VC-12

VC-2

VC-3

VT1.5

C-2 DS2

C-3 E3/DS3

C-11 DS1

C-11 DS1

C-12 E1

Figure 2.1

x7

TUG-2

x3 TU-12

x4 TU-11

OC-1 x1

C-4 E4

x2

x1

VT3

VT6

VT2

VT3

VT6

SPE

C-12 E1

DS1 C

C-2 DS2

C-3 DS3/E3

SDH and SONET initial multiplex structure

are mapped into the appropriate payload containers C–n or C–m. These containers together with their OA&M information constitute a VC–n or VC–m. Pointer processing is used to maintain the individual timing of the tributaries through the network from ingress to egress, and multiplexing is used to transport one or more lower order tributaries or multiplexes in a higher order multiplex over the same section in the network. Figure 2.1 also shows that the basic transport element in SDH networks is the VC–4 and that the SONET network uses the STS–1 SPE as a basic transport element. Driven by a demand for even higher order SDH and SONET multiplexes and enabled by new developments in the optical technology, the standardisation committees have extended the existing multiplex structures. Similar to the ITU-T multiplexing schemes of PDH, each next higher order multiplex in SDH/SONET has a four times larger payload transport capability than the previous multiplex. The payload capacity of these new higher order multiplexes cannot only be used to transport four times the payload container from the previous multiplex but can also be used to transport a single contiguous payload container. The methodology used is called concatenation; a procedure whereby a multiplicity of payload containers is associated one with another with the result that their combined capacity can be used as a single payload container across which bit sequence integrity

11

Concatenation STM-1 x1

STM-4 x1

STM-16 x1

STM-64 x1

AUG-64 AUG-16 AUG-4

xN

AUG-1 x1 AU-4


TUG-2 x4 TU-11

VC-4 TUG-3 x1 x7

x1 TU-2

TU-3

VC-11 VC-12

VC-2

VC-3

C-2

C-3

C-12

x4

x4

higher order multiplexes

x4 x1

x1

x1

x1

AU-4-4c

AU-4-16c

AU-4-64c AU-4-256c

VC-4-4c

VC-4-16c

VC-4-64c VC-4-256c

x3

contiguous concatenation

x3 TU-12

C-11

x4

STM-256 x1 AUG-256

Figure 2.2

C-4

C-4-4c

C-4-16c

C-4-64c

C-4-256c

SDH extended multiplex structures

is maintained. See Figure 2.2 for the multiplex structure of the additional higher order multiplexes and contiguous concatenated payload containers of SDH. Figure 2.3 shows the multiplex structure of the additional higher order multiplexes and contiguous concatenated payload containers of SONET. Note that the extension of the SONET multiplex structure uses the same elements as used in the SDH extension. In general, a contiguous concatenated (CCAT) payload container is referred to as a C–n–Xc, a contiguous concatenation of X payload containers C–n with X ¼ 4,16,64,256. For the transport of a C–n–Xc between the two path termination points, all intermediate network elements in the transport network are required to support crossconnecting C–n–Xc. At the time of introduction of contiguous concatenated signals, the installed equipment in the SDH/SONET network supported crossconnection of non-concatenated signals only, i.e. in the network only

12

Next Generation SDH/SONET OC-1 x1

OC-3 x1

OC-12 x1

OC-48 x1

OC-192 x1

AUG-64 AUG-16 AUG-4

xN

AUG-1


x3 AU-3

SPE STS-1

x1

x4

x4

x4 higher order multiplexes

x1

x1

x1

x1

AU-4

AU-4-4c

AU-4-16c AU-4-64c AU-4-256c

STS-3c

STS-12c

STS-48c STS-192c STS-768c

x7

TUG-2 x3 x4 VT1.5 VT2

x2

VT3

VT6

VT1.5

VT2

VT3

VT6

SPE

C-11

C-12

C-2

C-3

x1

Figure 2.3

x4

OC-768 x1 AUG-256

contiguous concatenation

C-4

C-4-4c

C-4-16c

C-4-64c

C-4-256c

SONET extended multiplex structures

payload containers up to container size C–n could be transported. After the upgrade or installation of equipment supporting contiguous concatenation, there still appeared to be a limitation to the use of contiguous concatenated signals. Even though there are enough free VC–ns in an STM–N or OC–3N to provide the transport of a VC–n–Xc they are not available as a consecutive set. This is caused by the fragmentation of the total payload area in the STM–N or OC–3N; a result of the continuous set up and break down of trails through the network. Virtual concatenation has been defined to overcome these limiting factors for an introduction of contiguous concatenation in SDH/SONET networks. Virtual concatenation (VCAT) enables the transport of a contiguous payload container C–n–Xc through an SDH or SONET network that contains intermediate network elements not supporting the transport of a C–n–Xc (X ¼ 4,16,64,256). The only prerequisite for the definition of VCAT was the requirement that in the network the intermediate

Concatenation

13

nodes should not be aware of the fact that a transported C–n is part of a virtual concatenated signal. Only the equipment containing the path termination functions of the virtual concatenated signal shall support VCAT. In the VCAT process, the content of the payload container C–n–Xc is at the sending side distributed over the payload containers C–n of X individual VC–ns. This is sometimes referred to as inverse multiplexing. The X individual VC–ns can now be transported through the network without the intermediate network elements being aware of the fact that these VC–ns are each transporting a part of a C–n–Xc. At the receiving side the original C–n–Xc can be reconstructed from the payload containers transported by the X individual VC–ns. In general, a virtual concatenated payload container is referred to as a VC–n–Xv. Apart from the advantage provided by VCAT that network operators can introduce the transport of CCAT payload containers more gradually, VCAT also provides more granularity in payload container sizes by allowing any value of X. The VCAT methodology is also applicable on low order payload containers VC–m–Xv providing even more granularity. In the next sections of this chapter, I will explain the methodology of contiguous concatenation and virtual concatenation in more detail.

2.2 CONTIGUOUS CONCATENATION To provide a bandwidth larger than that of an SDH VC–4 or a SONET STS–1 SPE, contiguous concatenation has been defined. In the SDH and SONET standards the contiguous concatenated payload container is in general referred to as a C–n–Xc, i.e. the provided payload size is equivalent to the total payload provided by X individual payload containers C–n. Because the ITU-T defines the next higher order multiplex with a size four times larger than the existing multiplex, and contiguous concatenation was at first used by higher order multiplexes, the value of X was limited to orders of four, i.e. X ¼ 4,16,64,256 for a C–n–Xc. The equivalent of the SDH VC–4 is the SONET STS–3c SPE, i.e. three contiguous concatenated STS–1 SPEs. The values N ¼ 3 X (X ¼ 1,4,16,64,256) are defined for an STS–Nc. The value N ¼ 3 for an STS–3c SPE is defined to ensure that the resulting contiguous payload container provides exactly the same payload capacity as provided by a

14


VC–4, and as a consequence it will facilitate the transport of a VC–4 in a network based on STS–1 SPE cross connections (i.e. most SONET networks). At the time of the first definition of contiguous concatenation there were already applications that required a payload bandwidth between the bandwidth provided by a VC–2 and that of a VC–3. To meet this requirement the C–2–Xc (X ¼ 1. . .7) concatenated container has been defined.

2.2.1 CCAT of VC–4 and STS–1 SPE In SDH, the payload container providing the largest payload bandwidth was initially a VC–4. To provide larger payloads, contiguous concatenation of VC–4s has been defined in ITU-T recommendation G.707. The total payload bandwidth provided by a contiguous concatenated container C–4–Xc (X ¼ 4,16,64,256) is equal to the payload provided by X virtual containers VC–4 as shown in Figure 2.4. In

X.260

1 1

C-4-Xc

9 X+1

1

X.261

9

Path overhead bytes

1

fixed stuff

C-4-Xc

VC-4-Xc

Figure 2.4

SDH VC-4-Xc structure

15

Concatenation

general, the frame structure of a contiguous concatenated payload container VC–4–Xc is depicted as a matrix consisting of 9 rows by X 261 columns where each cell contains a single byte or octet. The frame is repeated every 125 msec. The VC–4–Xc is constructed by byte interleaving the X individual VC–4s. The result is that the columns containing the OA&M Path Overhead (POH) of the individual VC–4s are located in the first X columns of the VC–4–Xc. Out of the X columns containing the POH bytes from the original VC–4s only one, located in the first column, is used as the POH common for the whole VC–4–Xc and consists of 9 bytes/octets. Columns 2 to X inclusive contain fixed stuff bytes. The remaining X 260 columns provide the payload area of the VC–4–Xc that has exactly the same size as a C–4–Xc. In SONET, the payload container providing the largest payload capacity is an STS–1 SPE. To provide larger payloads, contiguous concatenation of STS–1s is defined in the SONET standard T1.105. The total payload bandwidth provided by an STS–Nc (N ¼ 3,12,48,192,768) is equal to the payload provided by N synchronous transport signals STS–1 SPE as shown in Figure 2.5.

N.87 - N/3

1 1

STS-Nc SPE payload

9 N/3+1

1

N.87

9

Path overhead bytes

1

fixed stuff

STS-Nc SPE

Figure 2.5

SONET STS-Nc structure

16


Out of the N columns containing Path Overhead bytes from the original STS–1s only one, located in the first column, is used as common for the whole STS–Nc. Columns 2 to N/3 (N > 3) contain fixed stuff bytes. The STS–3c frame has no fixed stuff column and exists of 9 rows by 3 87 columns which is exactly the same as an SDH VC–4 frame. A VC–4–Xc will be transported in X contiguous AU–4s in the STM–N signal. The first column of the VC–4–Xc will always be located in the first AU–4 of X contiguous AU–4s, e.g. for a VC–4–4c this will be either the AU–4 #1, AU–4 #5, AU–4 #9 or AU–4 #13 in an STM–16. The pointer to this first AU–4 indicates the position of the first octet in the OA&M Path Overhead of the VC–4–Xc, i.e. the octet in row 1, column 1 of the frame. The pointers to the remaining AU–4s, i.e. AU–4 #2 to #X, are set to the concatenation indication, i.e. the pointer bytes H1 and H2 of those AU–4s contain the value ‘1001xx11 11111111’, to indicate the contiguous concatenated payload. Pointer justification is performed in common for the X concatenated AU–4s and X 3 stuffing bytes are used. In a similar way an STS–Nc will be transported in N contiguous STS–1s. The payload capacity provided by the different contiguous concatenated containers is:

149.76 Mbit/s for (a VC–4 and) an STS–3c; 599.04 Mbit/s for a VC–4–4c and an STS–12c; 2396.16 Mbit/s for a VC–4–16c and an STS–48c; 9584.64 Mbit/s for a VC–4–64c and an STS–192c; and 38 338.56 Mbit/s for a VC–4–256c and an STS–768c.

Note that high rate VC–4–Xc and STS–Nc SPE can be used without any constraint in point-to-point connections. In SDH or SONET networks with ring or mesh topologies the transport of high rate VC–4–Xc or STS–Nc may be limited to a certain payload bandwidth of the VC–4–Xc, e.g. X 16 for an STM–64 based SDH ring or N 48 for an STS–48 based SONET ring. This limit is imposed by the protection methodology used in the network, e.g. rings with MS–SPRing or BLSR have to reserve 50% of the available STM–X or STS–N bandwidth for protection. Also, since not every AU–4 can be used as the first AU–4 for a contiguous concatenated VC–4–Xc, a situation can arise where there are enough unused AU–4s in an STM–N to transport a VC–4–16c but due to previous provisioning there are no 16 contiguous AU–4s available.

17

Concatenation X.106

1 1 C-2-Xc 4 X+1

4

POH bytes

1 1

X.107

fixed stuff VC-2-Xc

Figure 2.6

VC2-Xc structure

2.2.2 CCAT of VC–2 Contiguous concatenation of X VC–2s in a higher order VC–3, i.e. a VC–2–Xc (X ¼ 1. . .7), provides more choice of bandwidth between the bandwidth of a VC–2 and that of a VC–3. The frame structure of a VC–2–Xc is depicted as a matrix consisting of 4 rows by X 107 columns. The first column is designated for the four VC–2 POH bytes or octets. It provides a payload area of X payload containers VC–2 as shown in Figure 2.6. One common set of POH, corresponding to the POH of the first VC–2, is used for the whole VC–2–Xc and located in the first column. Columns 2 to X inclusive contain fixed stuff. The VC–2–Xc is located in X contiguous TU–2 in a higher order VC–3. The first column of the VC–2–Xc is always located in the first TU–2. The pointer to this first TU–2 indicates the position of the first POH byte/octet of the VC–2–Xc. The pointers of the TU–2 #2 to #X are set to the concatenation indication, i.e. the pointer bytes V1 and V2 contain the value ‘1001xx11 11111111’, to indicate the contiguous concatenated payload. Pointer justification is performed in common for the X concatenated TU–2s and X stuffing bytes are used. The payload capacity provided by the contiguous container C–2–Xc is: 6784 kbit/s up to 47 488 kbit/s in steps of 6784 kbit/s for X ¼ 1. . .7.

2.3 VIRTUAL CONCATENATION The payload container of a virtual concatenated signal is a contiguous container of size C–n–Xc that is transported through the network by X

18


individual VC–ns each with a payload container size C–n. The X VC–ns, i.e. the VC–n–Xv, is in general referred to as a Virtual Concatenation Group (VCG), the X individual VC–ns are referred to as members of the VCG. The concatenation function providing virtual concatenation is only required at the path terminating equipment; the intermediate nodes are not aware of the fact that a transported VC–n is part of a virtual concatenated container. After the introduction of the C–4–4c, equipment makers updated their cross-connection functions to support the C–n–Xc payload container sizes too, creating the possibility that a mix can exist in a network of network elements supporting contiguous concatenation and network elements not (yet) supporting contiguous concatenation. For this situation a conversion function is defined by the ITU-T that performs a conversion between contiguous concatenated payload containers VC–n–Xc and virtual concatenated payload containers VC–n–Xv. This conversion function can be supported by network elements that support connecting contiguous concatenated signals to network elements that do not support CCAT.

2.3.1 Payload distribution and reconstruction For virtual concatenation, the contiguous payload container C–n–Xc is mapped in the payload containers C–n of X individual VC–ns that constitute the VC–n–Xv. The distribution of the contents of the contiguous payload container C–n–Xc is byte-wise; each byte or octet out of a consecutive sequence of X bytes in the C–n–Xc is mapped into the appropriate payload container C–n in successive order. A unique sequence number (SQ) is assigned to each VC–n member of the VCG by the Network Management System (NMS). The SQ determines the order in which the bytes are distributed as shown in the example in Figure 2.7. The value assigned to the SQs in a VCG of size X will be in the range 0 to (X–1). As each member VC–n of the VC–n–Xv is transported individually through the network between the network elements with the path termination functions, it can transverse a different path through the network from any other member VC–n in the VCG; this feature is known as diverse routing. To improve the availability of an individual member of the VCG, the standard SDH/SONET path protection feature can be used where the working path and the protection path

19

Concatenation (0)

(1)

(2)

(3)

(0) C-4-4v C 4 (0) C 4 (1) C 4 (2) C 4 (3)

Figure 2.7

Byte-wise distribution of a C-4-4c

should use different routes. See Figure 2.8 for an example of both features. Each member VC–n in the VCG will experience a different fibre delay due to the differences in the physical length of the path. Also, the different routes through the network mean the number of network elements passed by the individual VC–ns can be different. Each node will impose a transfer delay on the VC–n passing through the node. The total of fibre delay and transfer delay for each VC–n, i.e. the propagation delay, will be different between the VC–ns in a VCG. The difference in delay between the fastest and the slowest VC–n in the VCG is called the differential delay. This differential delay has to be detected at the receiving path termination equipment in order to be compensated. The compensation or realignment is required for each individual VC–n before the original contiguous payload of the VCG can be reconstructed. Because of the possibility that a protection switch can occur at any moment, the delay compensation has to be dynamic. For the detection of the differential delay, the Multi-Frame

working path

m

em

m

be

rq

em

be r

p

protection path

Figure 2.8

Causes of differential delay

20


Indicator (MFI) is defined. The X individual payload containers C–n transporting a total payload container C–n–Xc will have the same unique MFI value assigned at the sending side. The differential delay can be determined by comparing the MFI values at the receive side. The member with the lowest delay will have, relatively, the highest MFI value; the member with the largest delay will have the lowest MFI value. Compensation of the differential delay is accomplished by delaying the faster members in the VCG. This is accomplished by using variable buffers for each member in a VCG. The standards require that the realignment process shall be able to compensate a differential delay of at least 125 msec. Initially, the maximum differential delay was defined at 125 ms but this was too restrictive; it required all VC–ns in a VCG to travel exactly the same path through the network and limited the number of intermediate network elements. Indirectly this would also require that the NMS should be aware of the VCG during path setup for the individual members and this was against the prerequisite for the introduction of VCAT. It would also put the burden on the NMS to find a protection path with almost exactly the same propagation delay as the working path. The maximum allowed differential delay is now defined at 256 ms. With a physical propagation delay of 5 ms per 1000 km, the maximum acceptable difference in physical path is 50 000 km, enough for global applications. In this definition, the MFI is considered to be a counter with a maximum value that starts again at ‘0’ if it overflows. The 256 ms is used to determine the maximum value of the MFI that should at least be supported. The number of available bits in the VCAT OA&M overhead also determined the maximum value of the MFI. Due to the limited value of the MFI it will not be possible to detect an alias, i.e. it will be impossible to determine whether a signal has a delay of d ms or d þ (n MFIMAX) ms. The actual (implemented) acceptable differential delay will be determined by the available buffer size and has to be negotiated between vendor and the buyer of the equipment. The reconstruction of the original container is depicted in Figure 2.9 showing a VC–4–4v. Figure 2.9 (a) shows the timing relation between the members of the VCG when they arrive at the termination point having experienced different delays while being transported through the network. Figure 2.9 (b) shows the members after passing the differential delay compensation buffers using the MFI information. Finally, Figure 2.9 (c) shows the C–n–4v after ordering using the SQ information.

21

Concatenation

C-4 (0) C-4 (1) C-4 (2) C-4 (3) (a) C-4 (0) C-4 (1) C-4 (2) C-4 (3) (b) C-4-4c (c)

Figure 2.9 Re-construction of a C-4-4c

2.3.2 VCAT of VC–n A high order VCAT payload container C–n–Xc provides the transport of a continuous payload by using the transport capacity of X individual payload containers C–n. The frame structure of a virtual container VC–n consists of 9 rows by (p þ 1) columns, i.e. one column containing the OA&M path overhead and p columns containing the payload. A VC–4 frame is repeated every 125 ms. Table 2.1 shows a list of possible payload containers C–n–Xc and their sizes. Figure 2.10 shows the generic distribution of the contiguous container C–n–Xc over the X individual containers C–n of the VC–n–Xv structure. The payload area of a VC–3 and that of an STS–1 SPE do not match exactly, i.e. 9 rows by 84 columns and 9 rows by 86 columns respectively because the SDH and SONET standards were not developed at the same time. This is not a problem when both are sub-structured. Table 2.1 HO VCAT payload containers and their capacity VC–n–Xv (X ¼ 1. . .256)

VC–n

p

Payload capacity

VC–4–Xv STS–3c–Xv SPE VC–3–Xv STS–1–Xv SPE

VC–4 STS–3c SPE VC–3 STS–1 SPE

260 260 84 84

X 149 760 kbit/s X 149 760 kbit/s X 48 384 kbit/s X 48 384 kbit/s

see Figure 2.4 see Figure 2.5

22

Next Generation SDH/SONET 1

p.X

X

1

C-n-Xc

9 1

p+1

1

bytes

1 p+1

9

Path overhead bytes

1

C-n VC-n (X) VC-n-Xv VC-n (1)

Figure 2.10

VC-n-Xv structure

However, for transport through an SDH network the STS–1 SPE needs to be mapped into a VC–4 and needs to match exactly the size of a VC–3. This requirement is also applicable for virtual concatenated STS–1 SPEs. Figure 2.11 shows the position of the fixed stuff columns in the STS–1 SPE required to make the transported payload container size of a STS–1–Xv SPE exactly the same as that of an VC–3–Xv. Each VC–n has its own OA&M path overhead. The H4 byte in the path overhead of a VC–n that is a member of a VCG is allocated to contain the virtual concatenation path overhead. This VCAT path overhead will contain the sequence number SQ and multi-frame indication MFI as mentioned above and defined below. The use of the H4 byte for this specific purpose is implied by the value of the signal label, i.e. the C2 byte, in the OA&M path overhead. A two-stage VCAT multi-frame is introduced to detect differential delays of 125 ms and above. The value 512 ms has been chosen to be able to detect differential delays up to 256 ms. The H4 byte bits [5. . .8] are used for the first stage and provide a 4-bit multi-frame indicator (MFI–1). This MFI–1 counter is incremented every basic payload

23

Concatenation 1

X

84.X

1

STS-1-Xv SPE payload area

9 1

30

59

87

59

fixed stuff

fixed stuff

Path overhead bytes

9

9

87 fixed stuff

30

1

fixed stuff

1

bytes

1

STS-1 SPE (X) STS-1-Xv SPE STS-1 SPE (1)

Figure 2.11

SONET STS-1-Xv SPE structure

container frame and counts from 0 to 15. These 16 basic frames constitute the VCAT path overhead frame that is also referred to as a control packet. The second stage of the VCAT multi-frame uses an 8bit multi-frame indicator (MFI–2) that is located in the H4 byte bits [1. . .4] of VCAT overhead frame (MFI–1 ¼ 0) for MFI–2 bits [1. . .4] and frame (MFI–1 ¼ 1) for MFI–2 bits [5. . .8] as shown in Table 2.2. MFI–2 is incremented once every VCAT multi-frame of the first stage and counts from 0 to 255. The resulting overall VCAT multiframe consists of 4096 basic payload container frames and will be repeated every 512 ms. The sequence indicator SQ identifies the sequence/order in which the individual VC–ns of the VC–n–Xv are combined to form the contiguous container VC–n–Xc as shown in Figure 2.10. Each individual member VC–n of a VCG has a fixed unique sequence number in the range of 0 to (X 1). The VC–n transporting the time slots 1, (X þ 1), (2X þ 1). . . of the C–n–Xc has the sequence number 0, the VC–n transporting the timeslots 2, (X þ 2), (2X þ 2). . . of the C–n–Xc has

24

Next Generation SDH/SONET Table 2.2

H4 coding for high order VCAT OH

H4 byte ———————————————— —————— —————————— 1st Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8 multi———————————————— —————— —————————— frame MFI–1 bits [1. . .4] number

2nd multiframe number

Reserved (¼ ‘0000’) SQ MSB bits [1. . .4] SQ LSB bits [5. . .8]

1 1 1

1 1 1

0 1 1

1 0 1

13 14 15

n–1

MFI–2 MSB bits [1. . .4] MFI–2 LSB bits [5. . .8] Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) Reserved (¼ ‘0000’) SQ MSB bits [1. . .4] SQ LSB bits [5. . .8]

0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1

0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1

0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1

0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

n

MFI–2 MSB bits [1. . .4] MFI–2 LSB bits [5. . .8] Reserved (¼ ‘0000’)

0 0 0

0 0 0

0 0 1

0 1 0

0 1 2

nþ1

the sequence number 1 and so on up to the VC–n transporting the time slot X, 2X, 3X. . . of the C–n–Xc with the sequence number (X 1). VCAT provides a fixed payload container size and consequently the set of sequence numbers is fixed. This set has to be provisioned by the NMS at both the Source side and the Sink side of the path through the network. Changing the size of a VCG can only be accomplished by complete removal of the original VCG and setting up a new VCG between the path terminating equipment causing an interruption of the transported payload. The assignment of unique SQ numbers allows the checking of the constitution of a VCG without using the path trace identifier but this is not recommended. The 8-bit sequence number SQ (which supports values of X up to 256) uses the H4 byte bits [1. . .4] in VCAT overhead frame (MFI–1 ¼ 14) for SQ bits [1. . .4] and frame (MFI–1 ¼ 15) for SQ bits [5. . .8] as shown in Table 2.2.

25

Concatenation C-n-Xc

VC-n-Xv

POH

17

POH

multiframe

16

MFI-1 = 0

MFI-1 = 0 MFI-2 = 0 MFI-2 = 0 MFI-1 = 1 POH

POH

POH

2

MFI-1 = 1 MFI-2 = 0 MFI-2 = 0 POH

X

MFI-1 = 15

MFI-1 = 15 MFI-2 = 0 MFI-2 = 0 MFI-1 = 0 POH

1

POH

1

MFI-1 = 0 MFI-2 = 1 MFI-2 = 1

MFI-1 = 15

MFI-1 = 15MFI-2 = 255 MFI-2 = 255 MFI-1 = 0 POH

POH

POH

1

POH

4096

MFI-1 = 0 MFI-2 = 0 MFI-2 = 0

SQ = (X-1) SQ = 0

Figure 2.12 VC-n-Xv VCAT multi-frame structure

Figure 2.12 shows how the MFI–1 and MFI–2 counter values and the SQ numbers are used for distribution of timeslots from the C–n–Xv over the X individual VC–ns.

2.3.3 VCAT of VC–m The definitions for lower order payload container virtual concatenation are similar to those of the higher order VCAT. In this section only the relevant differences are mentioned. A low order VCAT payload container C–m–Xc provides the transport of a continuous payload by using the total transport capacity of X individual payload containers C–m. The frame structure of a VC–m

26


LO VCAT payload containers and their capacity

VC–m–Xv (X ¼ 1. . .64)

VC–m

VC–2–Xv VC–12–Xv VC–11–Xv VT6–Xv SPE VT3–Xv SPE VT2–Xv SPE VT1.5–Xv SPE

VC–2 VC–12 VC–11 VT6 SPE VT3 SPE VT2 SPE VT1.5 SPE

q 106 34 25 106 52 34 25

Payload capacity Structure X 6784 kbit/s X 2176 kbit/s X 1600 kbit/s X 6784 kbit/s X 3328 kbit/s X 2176 kbit/s X 1600 kbit/s

see Figure 2.12

consists of 4 rows by (q þ 1) columns and is repeated every 500 ms. The first column contains the 4 bytes POH. Table 2.3 shows the value of q and the payload capacity of the individual payload containers for the different types of virtual containers. The value of X is for low order VCAT limited to 1 to 64 because it is inefficient and unlikely to map more than 63 VC–11 or VC–12 into a VC–4 and the SQ field can thus be limited to 6 bits. The distribution of the content of the C–m–Xc over the X individual VC–m in the VCG is shown in Figure 2.13. Each VC–m has its own POH. In the existing POH, there were not enough reserved bits available to be used for the low order VCAT OH. A two stage process was defined to provide the required bits.

1

X

q.X

1 C-m-Xc 4

4

POH bytes

1 1

4

POH bytes

1 1

q+1

q+1 VC-m (1)

C-m

VC-m-Xv VC-m (1)

Figure 2.13

VC-m-Xv structure

Concatenation

27

The only free value of the signal label in the V5 byte bits 5 through 7, i.e. ‘101’, is assigned to indicate ‘extended signal label’. This extension of the range of signal labels was necessary anyway due to the introduction of virtual concatenation and the requirement to provide some spare values reserved for future applications. The presence of the value ‘extended signal label’ indicates that in the K4 byte bit 1 is used to provide the additional signal label values. If one of these additional extended signal labels indicates that the application is using virtual concatenation, the low order VCAT OH can be found in the K4 byte bit 2. This overhead will contain the sequence number SQ and multiframe indication MFI required by VCAT as has been mentioned above and will be defined below. If the value of the V5 byte bits [5. . .7] is ‘101’ the K4 byte bit 1 contains a 32 frame multi-frame providing a 32 bit string as depicted in Table 2.4. The 32 bit string contains the Multi-Frame Alignment Signal (MFAS) consisting of the string ‘0111 1111 110’, an 8 bit extended signal label field, a separator bit with value ‘0’ and 12 bits reserved for future use all set to ‘0’. If the reserved bits are used in the future, care should be taken to ensure that an imitation of the MFAS string is avoided. The extended signal label multi-frame is repeated every 16 ms, i.e. 32 bits 500 ms/bit. In addition, Table 2.4 shows that the phase of the low order VCAT OH multi-frame in K4 byte bit 2 is the same as the phase of the K4 byte bit 1 extended signal label multi-frame providing the MFAS signal. The low order VCAT OH multi-frame or control packet consists of the following fields: The multi-frame indicator field MFI. The low order VCAT MFI is contained in bits 1 through 5 of the control packet. It provides a measure for the differential delay with a granularity of 16 ms. The total time of the low order VCAT multi-frame is determined by the 5 bits MFI and is equal to 512 ms, i.e. 32 16 ms. The sequence number field SQ. The low order VCAT SQ is contained in bits 6 through 11 of the control packet. Reserved. The remaining 21 bits of the control packet are reserved for future standardisation and shall be set to ‘0’. The reserved bits shall be ignored by the receiver. Figure 2.14 shows the use of the MFI counter and the SQ number for the distribution of timeslots from the C–m–Xc over the X individual VC–ms of the VC–m–Xv VCG.

28


MFAS in K4 bit 1 ———————————— Function Value

Multi-Frame Alignment Signal

0 1 1 1 1 1 1 1 1 1 0

Extended signal label Not used by VCAT Fixed Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved

0 0 0 0 0 0 0 0 0 0 0 0 0

Virtual concatenation overhead VCAT OH in K4 bit 2 ————————————— Function Value MSB MFI (bits 1–5) LSB MSB SQ (bits 1–6)

Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved

LSB 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Bit number 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

2.3.4 VCAT of PDH The most recent (April 2004) development in the application of VCAT and LCAS is the use of PDH signals as members of a VCG. The new ITU-T recommendation G.7043 describes this application for the PDH signals with the following rates: the primary rates 2048 kbit/s E1 and

29

Concatenation C-n-Xc

VC-n-Xv

X

POH

multiframe

POH

2

MFI = 0

MFI = 0 POH

1

POH

1

MFI = 1

MFI = 1

MFI = 0

POH

POH

MFI = 31

POH

1

POH

32 MFI-1 = 15 MFI = 31 MFI-2 = 0 MFI-1 = 0 MFI = 0 MFI-2 = 1 SQ = (X-1) SQ = 0

Figure 2.14

VC-m-Xv VCAT multi-frame

1544 kbit/s DS1 and the ternary rates 34 368 kbit/s E3 and 44 736 kbit/s DS3. The container size for these signals is determined as follows. 2048 kbit/s VCAT For the E1, the 16 frame CRC–4 multi-frame is used with a repetition rate of 2 ms (16 0.125 ms) providing a 1984 kbit/s usable bandwidth. The first payload octet of the multi-frame is used for the PDH VCAT overhead resulting in a 1980 kbit/s payload bandwidth. See Figure 2.15 for the mapping of the payload. 1544 kbit/s VCAT For the DS1–ESF, the 24 frame extended superframe is used with a repetition rate of 3 ms (24 0.125 ms) providing a 1536 kbit/s usable bandwidth. The first payload octet of the superframe is used for the PDH VCAT overhead resulting in a 1533 kbit/s payload bandwidth. The payload mapping is shown in Figure 2.16.

30

Next Generation SDH/SONET X

1 1

32

1 VLI

1 VLI

1

32

16 (16 x 31) – 1 bytes

PDH OH

E12-Xc

PDH OH

1

E12 (X)

16

E12-Xv E12 (1)

495

2 ms

Figure 2.15

E12-Xv structure

X

1

1 1 VLI

E11-Xc

24

PDH OH bits

1

OH bits

1

1 VLI

24 (24 x 24) – 1 bytes

24

E11 (X) E11-Xv

E11 (1)

575

3 ms

Figure 2.16

24

E11-Xv structure

31

Concatenation X

1 1

1

1

6

OH

VLI

PDH

E31-Xc

1

6

OH

59 VLI

PDH

1

59

9 (9 x 59) – 2 bytes

9

E31 (X) E31-Xv

E31 (1)

529

125 us

Figure 2.17

E31-Xv structure

34 368 kbit/s VCAT For the E3, the single frame is used with a repetition rate of 125 ms providing a 33 920 kbit/s usable bandwidth. The first payload octet of the frame is used for the PDH VCAT overhead resulting in a 33 856 kbit/s payload bandwidth. Figure 2.17 depicts the payload mapping.

44 736 kbit/s VCAT For the DS3, the 7 subframe masterframe is used with a repetition rate of 106 ms providing a 44 209 kbit/s usable bandwidth. The first payload octet of the masterframe is used for the PDH VCAT overhead resulting in a 44 134 kbit/s payload bandwidth. The payload mapping is illustrated in Figure 2.18. The resulting payload bandwidth of the PDH VCG will be used for GFP mapping. The new ITU-T recommendation G.8040 describes this mapping.

32

Next Generation SDH/SONET X

1 1

1

680 bits

VLI

1 E32-Xc

1

VLI

PDH OH

1 (7 x 84) – 1 bytes

E32 (X)

7 E32 (1)

E32-Xv

587

106 us

Figure 2.18

E32-Xv structure

2.4 APPLICATIONS OF CONCATENATION 2.4.1 Contiguous to virtual to contiguous conversion As mentioned in Section 2.1, virtual concatenation enables the transport of contiguous concatenated signals in a legacy SDH/SONET network. VCAT also enables the transport of CCAT signals over sections that are so fragmented that the CCAT signal does not fit. In addition, VCAT enables transport of CCAT signals in a network where a single section cannot transport the whole CCAT signal by using divers routing. This is an important feature of VCAT and so the ITU-T has standardised a conversion function that—in addition to the already defined distribution of the payload container C–4–Xc contents over the X member containers C–4—also defines the distribution of the VC–4–Xc OA&M path overhead over the X member VC–4s overhead and the combining of the overhead of the X individual member VC–4s into the VC–4–Xc overhead. Special care has been taken to

33

Concatenation Table 2.5 The efficiency of VCAT transport Packet signal

No VCAT

Eff.

Ethernet 10 Mbit/s

VC–3 STS–1 SPE 48.38 Mbit/s

20%

Fast Ethernet 100 Mbit/s

VC–4 STS–3c SPE 149.76 Mbit/s

67%

GbEthernet 1 Gbit/s

VC–4–16c STS–48c SPE 2.39 Gbit/s

42%

10 GbEthernet 10 Gbit/s

VC–4–64c STS–192c SPE 9.58 Gbit/s

100%

ATM 25 Mbit/s

VC–3 STS–1 SPE 48.38 Mbit/s

24%

VCAT VC–12–5v 10.88 Mbit/s VT1.5–7v 11.20 Mbit/s VC–3–2v 96.77 Mbit/s VC–12–46v 100.09 Mbit/s

Eff. 92% 89%

100%

VC–4–7v STS–3c–7v SPE 95% 1.05 Gbit/s 98% VC–3–21v STS–1–21v SPE VC–4–64v STS–1–192v 9.58 Gbit/s VC–12–12v 26.11 Mbit/s VT1.5–16v 25.6 Mbit/s

100% 95% 97%

FICON 850 Mbit/s

VC–4–16c STS–48 SPE 2.39 Gbit/s

35%

VC–4–6v STS–3c–6v 898.56 Mbit/s

94%

ESCON 160 Mbit/s

VC–4–4c STS–12c SPE 599 Mbit/s

27%

VC–3–4v STS–1–4v 193.54 Mbit/s

82%

Fibre Channel 425 Mbit/s 850 Mbit/s 1700 Mbit/s

VC–4–4c STS–12c SPE 599 Mbit/s VC–4–16c STS–48c SPE 2.39 Gbit/s

Infiniband 2 Gbit/s

VC–4–16c STS–48c 2.39 Gbit/s

83%

VC–4–14v STS–3C 14v 2.09 Gbit.s

95%

DVB–ASI (digital video) 216 Mbit/s

VC–4–4c STS–12c SPE 599 Mbit/s

36%

VC–3–5v STS–1–5v 241.92 Mbit/s

89%

70% 35% 71%

94% VC4–3v STS–3c–3v SPE 449.28 Mbit/s 94% VC–4–6v STS–3c–6v SPE 898.56 Mbit/s VC–4–12v 94%

34


avoid loss of information concerning the bit errors experienced by the CCAT signal and the VCAT signals.

2.4.2 VCAT and data transport The most recent application of virtual concatenation is the transport of packet data in an efficient way. When using the traditional SDH/ SONET payload containers, i.e. without virtual concatenation, the efficiency of the transported bandwidth versus the provided bandwidth can be as low as 20%. Virtual concatenated payload containers provide an efficiency of 90% or better. As an example, Table 2.5 shows several packet signals, the closest matching traditional payload container (without VCAT), the closest matching virtual concatenated payload container and the efficiencies of both means of SDH/ SONET transport.

2.4.3 VCAT and OTN signal transport Even before the deployment of OTN equipment, it has been envisioned that the introduction of OTN will be gradual and that initially there will be islands of OTN in the sea of SDH and SONET networks. To be able to connect these OTN islands, it is necessary to have a pipe through the SDH/SONET network that will transport OTN signals. Selecting a virtual concatenated payload container of the right size can provide this pipe. The actual mapping of the OTN signals into the VCAT container has been defined in ITU-T recommendation G.707 clause 10.7 (see Table 2.6).

Table 2.6 VC–4s

Mapping of OTN elements in SDH/SONET virtually concatenated

OTN entity

Nominal bit rate of ODUk

ODU1

2499 Mit/s

ODU2

10 037 Mbit/s

VCAT entity VC–4–17v STS–3c–17v VC–4–68v STS–3c–68v

Nominal bit rate of VCAT 2546 Mbit/s 10 184 Mbit/s

3 Link capacity adjustment scheme Fitting the right pipe Virtual concatenation extends the payload transport capability of SDH/ SONET networks. On the one hand, virtual concatenation provides a staged introduction of higher order contiguous concatenated multiplexes in the network and flexible transport of those multiplexes through the network. On the other hand, virtual concatenation provides the flexibility to match the concatenated container size with the client signal bandwidth. However, if the client signal is packet based, the demanded transport bandwidth will vary over time. The standardisation of the Link Capacity Adjustment Scheme (LCAS) adds flexibility to virtual concatenation to meet this demand. This concept is new in SDH/ SONET networks and can be considered a revolution in the SDH/ SONET technology.

3.1 INTRODUCTION In an SDH, SONET or OTN network, the transported payload container can be matched very efficiently to the client signal bandwidth by using Virtual Concatenation (VCAT) as has been demonstrated in Chapter 2. The payload container is transported in a virtual concatenated container VC–n–Xv and in general is referred to as a Virtual


36


Concatenation Group (VCG). A VCG consists of X individual Virtual Containers (VC), generally referred to as members of the VCG. This chapter describes the methodology used to dynamically and hitlessly change (i.e. increase and decrease) the capacity of a contiguous payload container that is transported in a generic SDH, SONET or OTN transport network. In addition to changing the capacity of the contiguous payload container, this methodology also provides survivability capabilities, i.e. an automatic decrease of the payload capacity of the VCG if a member experiences a failure in the network, and a hitless increase of the payload capacity when the network fault is repaired. This methodology is standardised and can be found in recommendation ITU-T G.7042, it is referred to as Link Capacity Adjustment Scheme (LCAS). ANSI T1 has adopted this recommendation as a standard so it is applicable to SONET signals too. The methodology will be applied to the entire VCG, i.e. every member in the same VCG shall support LCAS. The methodology depends on the close cooperation of the Source (or send) side process and the Sink (or receive) side process. This is achieved by exchanging control information between Source side and Sink side processes. This chapter will give a detailed description of this control information and how this control information is used at the Source side and Sink side of the VCG trail. In Chapter 4, the LCAS processes operating at the Source side and the Sink side are described by using state transition diagrams and in Chapter 5 a number of examples explain the operation of LCAS by using time sequence diagrams.

3.2 LCAS FOR VIRTUAL CONCATENATION 3.2.1 Methodology LCAS is an addition to the virtual concatenation methodology described in Chapter 2 and will be present in the VCAT Source and the VCAT Sink adaptation functions only. The LCAS methodology assumes that any change in the VCAT payload capacity, i.e. the initiation, increase, decrease or termination of a VCG, and the set-up or breakdown of the end-to-end path through the network of each individual member is the responsibility of the Network and Element Management Systems (NMS).

Link capacity adjustment scheme

37

3.2.2 Control packet To synchronise all the changes in the payload capacity of the transmitter or Source side and the receiver or Sink side, a control packet is used to convey the required control information. This control packet is the same as the VCAT multi-frame mentioned in Chapter 2 and LCAS uses some of the reserved bits and bytes in this multiframe. Control packets are sent continuously, even if there is no change in the information that it contains. By definition, each control packet describes the state of the member during the next control packet. In this way all changes are sent in advance so that the Sink side process can switch to a new configuration as soon as it arrives and has been validated. This ensures that all planned changes of the VCG will be hitless. The control packet consists of a number of fields each dedicated to a specific function. The control packet contains both control information sent from Source side to Sink side and control information sent from Sink side to Source side. In the forward direction, from Source side to Sink side: Multi-Frame Indicator (MFI) field, reused from the original VCAT multi-frame; Sequence Indicator (SQ) field, reused from the original VCAT multi-frame; Control (CTRL) field; Group Identification (GID) bit. In the return direction, from Sink side to Source side: Member Status (MST) field; Re-Sequence Acknowledge (RS-Ack) bit. Note that the control packets of all members of the VCG contain the same MST and RS-Ack information. This enables the Source side to select the control packet received from one member to retrieve all the MST and RS-Ack information. If that particular member should experience a failure, the Source side can select another member control packet without losing MST and RS-Ack information. In both directions: CRC field; Unused bits are reserved and shall be set to ‘0’.

38


information sent in control packer_y of member_p in VCG_z

MST_a RS-Ack_a

MFI_z SQ_p CTRL_p GID_z CRC_y

member_p in VCG_z member_n in VCG_a

member_p in VCG_z member_n in VCG_a

MFI_a SQ_n CTRL_n GID_a CRC_x

information sent in control packer_x of member_n in VCG_a

MST_z RS-Ack_z

Figure 3.1 Transmitted control packet information

Note that to allow consistent timing relationships between the individual members, it is assumed that all LCAS control packets are processed at the Sink side after differential delay compensation has taken place. Figure 3.1 shows that a control packet contains control information from different functional parts in a VCG. Figure 3.2 shows the control information of a member in the VCG and in which direction it is sent.

information of member_n in VCG_a member_p in VCG_z member_n in VCG_a

MST_a(n) RS-Ack_a

MFI_a SQ_n CTRL_n GID_a CRC_x

Figure 3.2

MFI_z SQ_p CTRL_p GID_z CRC_y

MST_z(p) RS-Ack_z

information of member_p in VCG_z

Members control packet information

member_p in VCG_z member_p in VCG_z


39

The next sub-sections will provide more details of each control information field. 3.2.2.1

The Multi-Frame Indicator (MFI) field

In a VCG with X members, the payload container that has to be transported is sliced into parts containing X bytes or octets. Each one of these X successive bytes is transported by one of the X members in the VCG in its (smaller) member payload container; this is sometimes referred to as byte-slicing or inverse multiplexing. To be able to reconstruct the original payload container at the receiving end of the link each part has to be reconstructed from the bytes received by the X individual members. To facilitate this, each successive payload container frame is assigned a unique number. This number is transmitted as control information in each member container. In the standard a counter is defined, the value of the counter is the number assigned to the container frame and is incremented by one for the next container frame. Due to the limited number of bits available for the counter, the counter starts again at zero when the maximum value is reached. Because container frames are counted, the counter is in general termed frame-counter and the full set of counter values is termed multi-frame. The counter value itself is referred to as Multi-Frame Indicator (MFI). At the Source side the MFI value is equal for all member container frames C–n of the VCG and will be incremented each frame. At the Sink side the MFI value has to be used to realign all member container frames of a VCG before the reconstruction of the original payload container frame C–n–Xc can take place. The MFI is used to determine the difference in propagation delay experienced by the individual members of the VCG caused by the diverse routing through the network. This propagation delay is 5 ms per 1000 km of physical path. The difference in delay between the fastest path and the slowest path through the network is referred to as the differential delay. At the Sink side, between the member path termination function and the VCAT adaptation, function buffers are used to compensate the experienced delay in order to realign the member container frames C–n before the reconstruction of the original payload container can be achieved. To simplify the MFI multi-framing process, it is allowed to disregard the result of the control packet CRC check for the MFI element that is covered by the CRC check defined below. This makes the multi-framing process of the virtual concatenation methodology with or without support of LCAS identical.

40

3.2.2.2


The Sequence Indicator (SQ) field

For the reconstruction of the original payload container C–n–Xv after the differential delay is compensated, it is necessary to know the order of the bytes. For this purpose, the members in a VCG are assigned a unique sequence number by the LCAS process at the Source side. Note that this is different from VCAT where the SQ is provisioned by the NMS. The numbering of the members starts at zero and is consecutive, so the last member in a VCG with n members has sequence number (n–1). The sequence number is transmitted from Source side to Sink side in the Sequence Indicator (SQ) field of the control packet. The use of the sequence numbers is similar to the SQ used in the recommendations for Virtual Concatenation as described in Chapter 2. The value of the sequence number shall be ignored by the Sink side process for all members that are not an active member of the VCG, e.g. a member removed from the VCG retains its assigned SQ value and a new member added to the VCG is assigned the same SQ value. Even though this requirement is sufficient for proper operation of the LCAS process, it is recommended that the initial SQ of a member or the SQ of a member removed from the VCG shall be set to the highest possible value. 3.2.2.3

The Control (CTRL) field

In the LCAS process, at the Source side each member can be in a specific state of operation; see Chapter 4 for a detailed description of these states. It is important that the Sink side is aware of the state a member is in at the Source side. The state of the member at the Source side is a determining factor in the reconstruction process at the Sink side. The control (CTRL) field is used to transfer the state or status information from the Source side to the Sink side process. The status information is used to synchronise the Sink side with the Source side and reflects the status of each individual member in the group. Because each member in the LCAS process can be in any of the currently five distinctive states and VCAT without LCAS has already used one value (i.e. all zero because the reserved bits are all set to zero), four bits have been allocated to contain the Control field. This leaves enough room for possible future expansions of LCAS with more states. The values assigned to each state as recommended in ITU-T recommendation G.7042 are shown in Table 3.1. At the initiation of a VCG source side process all provisioned members shall send CTRL code IDLE until they are added to the VCG (and then send CTRL code ADD).


CT1 0

0

0 0

1 0

3.2.2.4

41

Table 3.1 LCAS CTRL words CTRL bits Remarks CT2 CT3 CT4 Code 0 0 0 FIXED The indication that the Source side uses a fixed bandwidth (i.e. non-LCAS mode). This is backwards compatible because in the virtual concatenation standards these bits are set to all zero. 0 0 1 ADD The indication that the member is about to be added to the VCG; it is a transition state from the IDLE state to the NORM/EOS state. 0 1 0 NORM Normal transmission; the payload of this member should be used to reconstruct the original container C–n–Xv. 0 1 1 EOS The End of Sequence indication; this is a special case of the NORMAL transmission state. It indicates that this is the last member of the VCG transporting valid payload. Only one member in a VCG shall send this code. 1 1 1 IDLE This member is not part of the VCG or is about to be removed from the VCG. 1 0 1 DNU Do Not Use the payload transported by this member. The Sink side reported a FAIL status for this member.

The Group Identification (GID) bit

In a network and in a network element several VCGs can exist at the same time. For the individual member paths the VC–n Path Overhead (POH) provides a means to check the network connectivity, i.e. the Trail Trace Identifier (TTI). However, to provide an efficient implementation, separate VCGs with a payload container size C–n–Xv could share a pool of payload containers C–n. This implementation requires a connection function between the adaptation function C–n– Xv_A and the pool of termination functions C–n_TT (see Figure 3.3). Due to wrong provisioning of this connection function, the possibility exists that two or more individual members of two or more different VCGs are interchanged. For example, in Figure 3.3 member (a) is connected to VCGy and not to VCGx, and member (b) is connected to VCGx and not to VCGy.

42


VCGx

C-n_TT

C-n-Xv_A

C-n_TT

C-n_TT

VCGy

C-n_TT

C-n-Xv_A

C-n_TT

C-n_TT

C-n_TT C-n pool

member (a)

Figure 3.3

member (b)

Multiple VCGs with member resource pool

To detect this misconnection, the group identification (GID) bit is introduced. It is used for the identification of the VCG. The GID bit of all members of the same VCG has the same value in frames with the same MFI value. In this way the GID provides the LCAS process at the Sink side of a VCG with a means to verify that all the arriving members originate from only one transmitter VCG. The content of the GID bit are the consecutive bits generated by a pseudo-random generator providing a pattern with a length of 215 1 bits. At the Sink side it is not required to synchronise to the pattern derived from the incoming stream for verification. It is sufficient to check that the GID bits of all members in the VCG, after eliminating the differential delay, have the same value. Without the GID bit, it would not be possible to detect that members are interchanged between different VCGs in the following cases: The Trail Trace Identifier (TTI) of the members is identical or not used. This would be impossible if the operator complies with ITU-T recommendation G.831 defining the use of the TTI. The differential delay is not excessive, i.e. the MFI is within acceptable range. (Note: the MFI counters of separate VCGs existing in a network element or in a network are not synchronised.) The SQ numbers are identical. Although it is very unlikely that members interchanged between different VCGs are not identified, the GID can be particularly helpful in certain implementations as shown in Figure 3.3.


43

Note that the GID bit is not evaluated for members sending IDLE in the control field. 3.2.2.5

The Cyclic Redundancy Check (CRC) field

In SDH and SONET, it was common to validate a signal by looking for three to five consecutive identical values. Applying the same procedure to signals from the LCAS overhead would cause a considerable slowdown of the process. A new control packet is transmitted every 2 ms (for high order LCAS) or 16 ms (for low order LCAS) and a ‘normal’ validation would then require 4 to 10 ms (or 32 to 80 ms). To simplify and speed up the validation of the changes in the virtual concatenation overhead, a CRC is used to protect and validate each control packet. The CRC check is performed on every control packet after it has been received, and the contents are rejected if the check fails. If the control packet passes the CRC test, then its contents are used immediately. If the control packet containing control information to change the payload size experiences a bit error, the increase or decrease will not be hitless; however, the CRC validation limits this hit to a single container frame. ‘Normal’ validation would have caused a hit lasting much longer. The CRC multiplication/division process The bits of the control packet can be regarded the coefficients of a polynomial where the first bit of the control packet to be transmitted is the most significant bit. A particular CRC–n block is the remainder after multiplication of the control packet polynomial by xn and then division (modulo 2) by the application specific generator polynomial. The remainder is a polynomial of, at most, degree (n 1). When representing the contents of the control packet as a polynomial, the first bit in the control packet, bit 1, should be taken as being the most significant bit. Consequently, C1 is defined to be the most significant bit of the remainder and Cn the least significant bit of the remainder. The CRC encoding procedure The control packet is considered to be static, i.e. its content will not change during the CRC encoding process. This means that the CRC–n checksum can be calculated a priori over the control packet.

44


The encoding procedure is as follows: (1) The CRC–n bits in the control packet are replaced by binary 0s. (2) The control packet is then acted upon by the multiplication/ division process as described above. (3) The remainder resulting from the multiplication/division process is inserted into the CRC–n bits location in the control packet. The CRC–n bits generated do not affect the result of the multiplication/division process because, as indicated in (1) above, the CRC–n bit positions are initially set to 0 during the multiplication/ division process. The CRC decoding procedure The decoding procedure is as follows: (1) A received control packet is acted upon by the division process as described above. (2) If the remainder calculated in the decoder is zero, it is assumed that the checked control packet is error free. 3.2.2.6

The Member Status (MST) field

The MST is used to report the status of all the members in a VCG at the Sink side to the LCAS process at the Source side. The status of the members at the Sink side is affected by the status of the same members at the Source side and this status is transferred from Source side to Sink side by the CTRL codes in the control packet; the status is also affected by the behavior of the network, e.g. fibre cuts, misconnection, excessive bit-errors, etc. At the Sink side, the members belonging to a VCG either are operational and in the state OK, or are experiencing a problem and are in the state FAIL. Members at the Sink side that are not provisioned to be a member of a VCG are in the state IDLE; for the interworking between Source side and Sink side this state is considered to be the same as the FAIL state. Since there are only two states at the Sink side, the MST is defined as a single bit. The values of the MST bit are: OK (bit set to zero, ‘0’) and FAIL (bit set to one, ‘1’). To ensure that the member status at the Sink side is received at the Source side, the status of all members in the VCG is transported in the LCAS overhead of all members from Sink side to Source side. Now the LCAS process at the Source side can


45

select any one member from the VCG to retrieve the MST of all members in the VCG. The maximum number of members in a VCG is application specific and will be described in Section 3.5. Reporting the MST of all possible members in a single control packet would affect the size of the control packets considerably, and consequently the refresh rate of the information sent from Source side to Sink side. For this reason the MST field has been limited to 8 bits per control packet and the MST of all members is distributed across multiple control packets: an MST multi-frame. With this scheme the MST of all possible members in a VCG will be refreshed every 64 ms for high order LCAS and 128 ms for low order LCAS, i.e. (maximum number of members)/8 control packet repetition time. The quantity of members in the VCG can be any number in the allocated range and can be changed by provisioning from the NMS. For each member, the Sink side uses the SQ number it receives from the Source side as the MST number for its response to the Source side. In this manner, the MST value received by the Source side will always correspond directly to the SQ value that it assigned to a member. (In the non-LCAS mode, the receiver function is provisioned to expect a fixed number of members.) To allow the receiver to determine the number of members in the VCG, the following should be noted. The highest non-failed active member will be sending the End Of Sequence (EOS) code in the control field. The VCG may have other members with a higher SQ value in the Do-Not-Use (DNU) state. At initiation of a VCG sink all members shall report MST ¼ FAIL. A transition to MST ¼ OK occurs when a control packet is received for that member with a CTRL code ADD, i.e. the reception of the code ADD implies that the setup of the path through the network was successful. MST ¼ OK will also be sent when CTRL codes NORM or EOS are received at the Sink side. All members at the Sink side that are not provisioned to be a member of a VCG, and members that receive CTRL code IDLE, shall send MST ¼ FAIL. 3.2.2.7

The Re-Sequence Acknowledge (RS-Ack) bit

Changing the size of a VCG at the Source side by adding or removing members will cause a change in the sequence numbers of the group. In the standard it is recommended to add new members at the end of the VCG. Removing one or more members can happen at any place in the VCG. It is also allowed to interchange the numbers in a VCG without

46


changing the size of the VCG. Changing the size of the VCG at the Sink side will have no effect on the sequence numbers because a change in the sequence numbering is the responsibility of the Source side LCAS process only. Changes in the sequence numbering at the Source side are detected at the Sink side. The Sink side will consequently change the MST of the affected members and report the changed MST values to the Source side. Hence, from the time the changed sequence numbers are sent by the Source until the changed MST values are received, the Source side shall not use the received MST values to avoid misinterpretation and losing status synchronisation between Source side and Sink side. To acknowledge from Sink side to Source side that a change in sequence numbers is detected and the changed MST to SQ relation is valid, the re-sequence acknowledge (RS-Ack) signal is introduced. When a renumbering of the SQ numbers of the members sending CTRL code NORM, DNU, EOS, or when a change of the SQ numbers of these members is detected at the Sink side, a notification to the Source side has to be performed per VCG by toggling the RS-Ack bit (i.e. change from ‘0’ to ‘1’ or from ‘1’ to ‘0’). More formally, the causes that trigger the toggling of RS-Ack bit can be listed as follows: The addition of on or more members to the VCG, i.e. a change in the CTRL code of a member from ADD to EOS or NORM. The latter occurs when multiple members are added to the VCG at the same time. This addition will increase the payload bandwidth of the VCG. The removal of one or more members from the VCG, i.e. a change in the CTRL code of a member from NORM or EOS to IDLE. This removal will decrease the payload bandwidth of the VCG. The removal of one or more failed members from the VCG, i.e. a change in the CTRL code of a member from DNU to IDLE. This removal does not affect the payload bandwidth of the VCG. Any change in the sequence numbering of the VCG, i.e. a reallocation of the SQ numbers in a VCG. The change in the sequence numbering is detected at the Sink side for the members sending CTRL codes NORM or EOS or DNU only. This change does not affect the payload bandwidth of the VCG. Note that following an ADD command from management interface (i.e. when a transition CTRL ¼ ‘IDLE’ ! CTRL ¼ ‘ADD’ occurs),


47

no RS-Ack has to be transmitted. In fact, RS-Ack should be toggled only when a change in sequence of the members belonging to the VCG is detected at the Sink side. During the first phase of the addition of new members (IDLE to ADD state transition), even if a SQ assignment may happen, it does not yet affect the VCG, therefore no RS-Ack is needed. The RS-Ack bit can only be toggled after the status of all members of the VCG has been evaluated and the sequence change has taken place. In the event that the RS-Ack toggle is not detected at the Source side, the synchronisation between Sink side and Source side is achieved with the activation of a RS-Ack time-out timer. The RS-Ack timer is started during operations requiring a resequence or variation of the member’s number in a VCG. The expiration of the timer is equivalent to the toggling of the RS-Ack bit and detected at Source side. The Source side LCAS process will use the toggling of the RS-Ack bit or the expiration of the RS-Ack time-out as an indication that the change initiated by the Source side has been accepted and completed, and will start accepting and evaluating new MST information. This means that MST values received in the control packet that contains the toggled RS-Ack bit and MST values received in subsequent control packets correspond to the new sequence. (Note that to avoid losing the status synchronisation between the Source side and the Sink side, no new change in the VCG should be committed until the RS-Ack is received or the RS-Ack time-out has expired for the currently active change request.)

3.3 CHANGING THE SIZE OF A VIRTUAL CONCATENATED GROUP 3.3.1 Planned addition of member(s) The first step that will be taken when the LCAS process at the Source side receives an ADD command via the management interface from the NMS is to notify the Sink side of the intended addition. When a member is added to the VCG, it is recommended that it shall always be assigned a sequence number one larger than the currently highest sequence number. The member with the highest current sequence number has the CTRL code EOS (or DNU if there is a problem in the network); i.e. when adding a member to a VCG of size n it shall be assigned SQ ¼ n because the sequence numbering starts at zero. When

48


multiple members are added at the same time, they shall each be assigned a unique sequence number so there will be a unique MST report for each of the additional members. Following an ADD command, the first member to respond with MST ¼ OK shall be allocated the next highest sequence number and shall change its CTRL code to EOS coinciding with the currently highest member changing its CTRL code to NORM (or remaining DNU). (Note that when CTRL ¼ EOS/NORM is sent by the added member together with the new allocated SQ, the Source side LCAS process will stop evaluation of the MST information until the Sink side notifies the change in SQ by toggling the RS-Ack bit.) In case two or more members (for example, p) are added to the VCG, and MST ¼ OK is received simultaneously for more than one member, then the allocation of SQ numbers is arbitrary provided they are the next p sequence numbers after the currently highest sequence number. The CTRL code of the member that has been sending EOS until this moment is being changed from EOS to NORM, coinciding with the new highest numbered member’s CTRL code being changed from ADD to EOS. All other new member’s CTRL codes will be changed from ADD to NORM. 3.3.1.1

Addition of the added member(s) payload capacity

The final step for adding a member to a VCG is to add the payload area of that particular member to the VCG payload container. The first container frame to contain payload data of the new member shall be the container frame immediately following the container frame that contains the last bit(s) (i.e. the CRC) of the control packet with NORM/ EOS code in the CTRL field for that member.

3.3.2 Planned deletion of member(s) When members are deleted from a VCG, the sequence numbers and corresponding member status number of the other members shall be renumbered to maintain a consecutive SQ numbering. The deleted member shall send the IDLE code in its CTRL field and set SQ to the maximum value. (1) If the deleted member was allocated the highest SQ number of the VCG and was sending the EOS code in the CTRL field, the


49

member containing the previous highest SQ number and sending the CTRL code NORM shall change this to the EOS code coinciding with the deleted member sending the IDLE code. (2) If the deleted member was allocated the highest SQ number of the VCG and was sending the DNU code in the CTRL field, the sequence numbering and CTRL fields of the other members in the group will not change. (3) If the deleted member was not allocated the highest SQ number, then the other members with SQ numbers between the SQ number of the deleted member and the highest SQ number shall update their SQ numbers and send these in their control packets coinciding with the control packet containing the change in the CTRL code of the deleted member from NORM/DNU to IDLE. Note that when the CTRL ¼ IDLE is sent together with the changed SQ, the Source side LCAS process will stop evaluation of the MST information until the Sink side notifies the change in SQ by toggling the RS-Ack bit. Also, to ensure a hitless decrease of the available bandwidth, it is important that the member is deleted first at the Source side. After the Sink side process has detected and processed the removal of the member, the member can be deleted at the Sink side and the network path can be broken down. 3.3.2.1

Deletion of member(s) payload

The final step for removing a member from a VCG is to remove the payload area of that particular member from the VCG payload container. The last container frame that contains payload of the deleted member shall be the container frame containing the last bit(s) of the control packet containing the IDLE code in the CTRL field for the first time.

3.3.3 Temporary removal of member When a member sending a NORM or EOS code in the CTRL field experiences a failure in the network, this is detected at the Sink side by defect monitoring in the member’s path termination function. The service provided by each member of the VCG can be operational, degraded (due to bit errors) or unavailable. When the service is degraded or unavailable the Sink side will send in the MST of that

50


particular member the status FAIL. The Source side will then either replace the transmitted NORM code by the DNU code, or replace the transmitted EOS code with the DNU code and at the same time replace the NORM code sent by the member that has a preceding sequence number with the EOS code. When the defect causing the degraded or unavailable condition is cleared, the Sink side will consequently send in the MST of that particular member the status OK. The Source side will then either replace the DNU code by the NORM code, if the member has not been assigned the highest SQ number, or replace the DNU code with the EOS code and at the same time replace the EOS code of the member that has a preceding sequence number with the NORM code. 3.3.3.1

Temporary removal of member payload

The final step for temporary removal of a member is to remove the payload area of that particular member from the VCG. At the Sink side, the payload area of the member is not used for the reconstruction as soon as the LCAS process receives the Member Service Unavailable (MSU_L) signal from the members path termination. If the member signal is degraded, i.e. the TSD signal is received, the member’s payload area will continue to be used for the reconstruction. The bit errors in the payload area of that member have to be handled by the server (e.g. Ethernet) layer of the payload transported by the VCG. At the Source side, the last container frame that contains payload of the removed member shall be the container frame containing the last bit(s) of the control packet containing the first DNU control field. The following container frames will contain all zeroes in the payload area. From the time the MSU_L is received, until the time the Source side starts sending CTRL code DNU, the reconstructed payload is not equal to the original payload: the transported data will experience this as a hit. Upon reception at the Sink side of the DNU code in the CTRL field, the payload of this particular member shall remain unused to reconstruct the original VCG. The final step after recovering from a temporary removal is to start using the payload area of that member again. The first container frame to contain payload data for the member shall be the container frame immediately following the container frame that contained the last bit(s) of the control packet containing the first NORM or EOS code in the CTRL field for that member.


51

3.4 LCAS TO NON-LCAS INTERWORKING During the development of LCAS it was foreseen that in a transitory phase LCAS supporting equipment could be connected to equipment not (yet) supporting LCAS. Inter-working between non-LCAS and LCAS virtual concatenation can be achieved as described in the next two paragraphs. Changes to the number of members in the VCG will be possible only by provisioning.

3.4.1 LCAS Source and non-LCAS Sink An LCAS Source can inter-work with a non-LCAS Sink in non-LCAS mode without any special consideration. The LCAS Source will place the MFI and SQ as described at the beginning of this chapter. The nonLCAS Sink will only use the MFI and SQ information and ignore all other bits, i.e. the LCAS overhead information. The member status MST returned from Sink side to Source side will always be MST ¼ OK because the reserved bits are recommended to be set to zero.

3.4.2 Non-LCAS Source and LCAS Sink An LCAS Sink normally expects a CTRL code that is not ‘0000’ (FIXED) and a correct CRC calculated over the control packet. A non-LCAS Source will transmit ‘0000’ in the LCAS overhead CTRL field as well as in the CRC field because in non-LCAS mode these bits are reserved and recommended to be set to all zeroes. When an LCAS Sink is interworking with a non-LCAS Source and receives (CTRL code equal to ‘0000’) AND (CRC equal to ‘0000’) it shall: Ignore all information (except MFI and SQ); Use MFI and SQ defect detection as defined for virtual concatenation.

3.5 LCAS CONTROL PACKET DETAILS As LCAS is an extension to VCAT, the LCAS control packet re-uses the VCAT OH. The position of the MFI and SQ information remains the

52


same; for the additional LCAS OH the reserved bits are used. In the next sections, the allocation of the LCAS OH bits and bytes are described for high order LCAS and low order LCAS. In the standards, the VCAT and LCAS OH is generally referred to as VCAT/LCAS Information (VLI).

3.5.1 The higher order VLI Table 3.2 depicts the modified higher order VLI in the H4 byte. The high order LCAS control packet starts at MFI–1 [8] of MFI–2 [n] and stops at MFI–1 [7] of MFI–2 [n þ 1] as indicated by the heavy lined box in Table 3.2. This is different from the definition of the start MFI–1 [0] and stop MFI–1 [15] of the control packet of VCAT without LCAS. The reason to change the definition of the start of the control packet was to enable the placement of the CRC result in the last nibbles of the LCAS

Table 3.2 Higher order VLI H4 byte Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8 MFI–1 (bits 1–4) Reserved (‘0000’) 0 0 0 0 C1 C2 C3 C4 0 1 1 0 C5 C6 C7 C8 0 1 1 1 M1 M2 M3 M4 1 0 0 0 M6 M7 M8 1 0 0 1 M5 0 0 0 RS_Ack 1 0 1 0 Reserved (‘0000’) 1 0 1 1 Reserved (‘0000’) 1 1 0 0 Reserved (‘0000’) 1 1 0 1 SQ MSB (bits 1–4) 1 1 1 0 SQ LSB (bits 5–8) 1 1 1 1 MFI-2 MSB (bits 1–4) 0 0 0 0 MFI–2 LSB (bits 5–8) 0 0 0 1 CT1 CT2 CT3 CT4 0 0 1 0 Reserved (‘0000’) 0 0 1 1 0 0 0 GID 0 1 0 0 Reserved (‘0000’) 0 1 0 1 C2 C3 C4 0 1 1 0 C1 C5 C6 C7 C8 0 1 1 1 M2 M3 M4 1 0 0 0 M1 M5 M6 M7 M8 1 0 0 1 0 0 0 RS_Ack 1 1 1 1

1st multi- 2nd multiframe frame number number 5 6 7 8 9 n 10 11 12 13 14 15 0 1 2 3 4 nþ1 5 6 7 8 9 10

53


Don’t care

1

Table 3.3 Higher order LCAS MST multi-frame MST multi-frame number Member based on MFI–2 value M2 M1 2 3 4 5 6 7 8 M5 M6 0 0 0 0 0 0 1 4 5 0 0 0 0 1 8 9 12 13

number M3 M7 2 6 10 14

M4 M8 3 7 11 15

240 241 242 243 244 245 246 247 1 1 1 1 1 248 249 250 251 252 253 254 255 The interpretation of the MST bits is based on the MFI–2 value at the moment the MST octet M1 . . . M8 is received, i.e. the MFI–2 value received in the previous control packet. The value of MFI–2 is used modulo 32 as an index for this table. 1

1

1

1

0

control packet. However, the length of the control packet remains the same: i.e.16 nibbles. The higher order control packet contains: The MST field – eight bits located in the two nibbles MFI–1 [8] and MFI–1 [9]; the status report of all the individual members in a VCG uses the MST multi-frame as shown in Table 3.3. The status of all 256 members is transferred in 64 ms, i.e. eight member statuses M1, M2, M3, M4, M5, M6, M7 and M8 are reported per control packet, 32 consecutive control packets are required to convey 256 statuses, and the control packet rate is 2 ms because it is transferred in the H4 byte of 16 VC–n frames at a rate of 125 ms. Table 3.3 also shows the relation of the MST multi-frame to the MFI–2 counter value. The RS-Ack bit – located in bit 4 of nibble MFI–1 [10]. The SQ field – eight bits located in the two nibbles MFI–1 [14] and MFI–1 [15]; the SQ value range for high order LCAS is 0 to 255 inclusive. The MFI–2 field – eight bits located in the two nibbles MFI–1 [0] and MFI–1 [1]; the combination of MFI–1 and MFI–2 provides the higher order LCAS multi-frame counter [0–4095].

54


The CTRL field – four bits located in the nibble MFI–1 [2]; contains the LCAS control code. For the coding of the bits CT1, CT2, CT3 and CT4, see Table 3.1. The GID bit – one bit located in bit 4 of the nibble MFI–1 [3]. The CRC–8 field – eight bits located in the two nibbles MFI–1 [6] and MFI–1 [7]; the CRC bits C1, C2, C3, C4, C5, C6, C7 and C8 contain the remainder of the CRC–8 calculation over the high order LCAS control packet. The CRC–8 remainder is calculated as follows: the first 14 nibbles of the control packet bits represent a polynomial M(x) of degree 55, where MFI–1 [8] bit 1 in Table 3.2 is the most significant bit and MFI–1 [7] bit 4 is the least significant bit. M(x) is first multiplied by x8 and then divided (modulo 2) by generator polynomial G(x) ¼ x8 þ x2 þ x þ 1 to produce a remainder R(x) of degree 7 or less. R(x) is the CRC–8 code with x7 of R(x) corresponding to C1 as the most significant bit of the remainder and x0 of R(x) corresponding to C8 as the least significant bit of the remainder. With the defined generator polynomial G(x) the probability of an undetected error is better than 1.52 1016. The remaining nibbles, i.e. MFI–1 [3], MFI–1 [5], MFI–1 [11], MFI–1 [12] and MFI–1 [13], are reserved for the future and shall be set to ‘0000’, bits 1, 2, 3 of MFI–1 [4] and MFI–1 [10] are also reserved and set to ‘0’. 3.5.1.1

Example of CRC–8 computation for higher order LCAS

Table 3.4 shows an arbitrary control packet of a higher order VCG to provide an example of a properly computed CRC.

3.5.2 The lower order VLI Table 3.5 depicts the modified lower order VLI in the K4 (in SONET Z7) byte bit 2. The lower order LCAS control packet is phase aligned with the MFAS signal in K4/Z7 byte bit 1. This 32 bit sequence in K4/ Z7 bit 1 can be considered the MFI–1 of the lower order LCAS. The lower order control packet shown in Table 3.5 consists of: The MFI–2 field – five bits located in the positions MFI–1 [1] to MFI–1 [5]; the combination of MFI–1 and MFI–2 provides the LCAS multi-frame counter [0–1024]. The SQ field – six bits located in the positions MFI–1 [6] to MFI–1 [11]; the SQ value range for low order LCAS is 0 to 63 inclusive.

55

Link capacity adjustment scheme High order LCAS CRC calculation example

Reserved (‘0’) SQ ¼ 19 (0x13) MFI–2 ¼ 202 (0xCA) CTRL ¼ NORM GID (‘1’) Reserved (‘0’) CRC–8 (0x7C) MST [80-87] RS-Ack (‘1’) Reserved (‘0’)

MFI-- 2 counter = 203

SQ ¼ 19 (0x13) MFI–2 ¼ 203 (0xCB) CTRL ¼ NORM GID (‘0’) Reserved CRC–8 (0x39)

LCAS control packet

MFI--2 counter = 201 MFI--2 counter = 202

MST [72–79] RS-Ack (‘1’)

bit 1 bit 2 bit 3 bit 4 bit 5 bit 6 bit 7 bit 8 0 1 1 0 1 0 0 0 8 1 0 0 0 1 0 0 1 9 0 0 0 1 1 0 1 0 10 0 0 0 0 1 0 1 1 11 0 0 0 0 1 1 0 0 12 0 0 0 0 1 1 0 1 13 0 0 0 1 1 1 1 0 14 0 0 1 1 1 1 1 1 15 1 1 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 1 0 0 1 0 0 0 1 0 2 0 0 0 1 0 0 1 1 3 0 0 0 0 0 1 0 0 4 0 0 0 0 0 1 0 1 5 0 1 1 1 0 1 1 0 6 1 1 0 0 0 1 1 1 7 0 0 0 0 1 0 0 0 8 1 0 0 1 1 0 0 1 9 0 0 0 1 1 0 1 0 10 0 0 0 0 1 0 1 1 11 0 0 0 0 1 1 0 0 12 0 0 0 0 1 1 0 1 13 0 0 0 1 1 1 1 0 14 0 0 1 1 1 1 1 1 15 1 1 0 0 0 0 0 0 0 1 0 1 1 0 0 0 1 1 0 0 1 0 0 0 1 0 2 0 0 0 0 0 0 1 1 3 0 0 0 0 0 1 0 0 4 0 0 0 0 0 1 0 1 5 0 0 1 1 0 1 1 0 6 1 0 0 1 0 1 1 1 7

LCAS Control Packet

H4 byte LCAS OH

MFI-1

Table 3.4

The CTRL field – four bits located in the positions MFI–1 [12] to MFI–1 [15]; contains the LCAS control code. For the coding of the bits CT1, CT2, CT3 and CT4 see Table 3.1. The GID bit – located in position MFI–1 [16]. The RS-Ack bit – located in position MFI–1 [21]. The MST field – eight bits located in the positions MFI–1 [22] to MFI–1 [29]; the status report of all the individual members in a

56


Table 3.5 Lower order concatenation overhead MFAS lower order VLI K4/Z7 byte bit 2 K4/Z7 byte bit 1 Function Value Function Value Multi-Frame 0 MFI–2 (bits 1–5) MSB Alignment Signal 1 1 1 1 LSB 1 SQ (bits 1–6) MSB 1 1 1 1 0 LSB CTRL (bits 1–4) CT1 CT2 Extended signal CT3 signal label CT4 Not used by GID VCAT Reserved 0 Reserved 0 Reserved 0 Fixed 0 Reserved 0 Reserved 0 RS_Ack Reserved 0 M1 Reserved 0 M2 Reserved 0 M3 Reserved 0 M4 MST (bits 1–8) Reserved 0 M5 Reserved 0 M6 Reserved 0 M7 Reserved 0 M8 Reserved 0 C1 Reserved 0 C2 CRC (bits 1–3) Reserved 0 C3

MFI–1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

VCG uses the MST multi-frame as shown in Table 3.6. The status of all 64 members is transferred in 128 ms, i.e. eight member statuses M1, M2, M3, M4, M5, M6, M7 and M8 are reported per control packet, 8 consecutive control packets are required to convey 64 statuses, and the control packet rate is 16 ms because it is transferred in the

57

Link capacity adjustment scheme Table 3.6 MFI–2 frame number 0, 8, 16, 24 1, 9, 17, 25 2, 10, 18, 26 3, 11, 19, 27 4, 12, 20, 28 5, 13, 21, 29 6, 14, 22, 30 7, 15, 23, 31

M1 0 8 16 24 32 40 48 56

Low order LCAS MST multi-frame Member number M2 M3 M4 M5 M6 1 2 3 4 5 9 10 11 12 13 17 18 19 20 21 25 26 27 28 29 33 34 35 36 37 41 42 43 44 45 49 50 51 52 53 57 58 59 60 61

M7 6 14 22 30 38 46 54 62

M8 7 15 23 31 39 47 55 63

K4 byte of 32 VC–m frames at a rate of 500 ms. Table 3.6 also shows the relation of the MST multi-frame to the MFI–2 counter value. The CRC–3 field – three bits located in the positions MFI–1 [30] to MFI–1 [32]; the CRC bits C1, C2 and C3 contain the remainder of the CRC–3 calculation over the low order LCAS control packet. The CRC–3 remainder is calculated as follows: the first 29 bits of the control packet represent a polynomial M(x) of degree 28, where the bit MFI–1 [1] in Table 3.5 is the most significant bit and the bit MFI–1 [29] is the least significant bit. M(x) is first multiplied by x3 and then divided (modulo 2) by generator polynomial G(x) ¼ x3 þ x þ 1 to produce a remainder R(x) of degree 2 or less. R(x) is the CRC–3 code with x2 of R(x) corresponding to C1 as the most significant bit of the remainder and x0 of R(x) corresponding to C3 as the least significant bit of the remainder. With the defined generator polynomial G(x) the probability of an undetected error in a signal with an average bit error rate of 5.32 109 is better than 4 1030. The remaining bits located in the positions MFI–1 [17], [18], [19] and [20] are reserved for future use and shall be set to ‘0’. 3.5.2.1

Example of CRC–3 computation for lower order LCAS

Table 3.7 shows an arbitrary control packet of a lower order VCG to provide an example of a properly computed CRC.

3.5.3 The OTN VLI The OTN OPUk/ODUk [k ¼ 1,2,3] VLI is transported in the OTN control packet that can be depicted as a 3 column by 32 row frame. The

58


MFI--1

Table 3.7

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

Low order VLI example

frame 15

MFI–2

SQ ¼ 11

CTRL NORM GID Reserved RS-Ack MST of members 56–63

CRC

frame 16 0 1 1 1 1 0 0 1 0 1 1 0 0 1 0 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 1

MFI–2

SQ ¼ 11


CRC

frame 17 1 0 0 0 0 0 0 1 0 1 1 0 0 1 0 1 0 0 0 0 1 0 1 0 0 1 0 0 0 1 1 0

MFI–2

SQ ¼11


CRC

1 0 0 0 1 0 0 1 0 1 1 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 1

OPUk bytes VCOH1, VCOH2, and VCOH3 located in the OPUk column 14, rows 1, 2 and 3 respectively, each provide a column. The OTN control packet multi-frame or row counter is related to the OPUk MFAS bits [4. . .8] located in OPUk column 7, row 1. There is no separate definition of OTN VCAT as this standard was developed after the introduction of LCAS. By provisioning the LCAS protocol can be disabled.


59

The OTN control packet shown in Table 3.8 consists of: The MFI fields – 16 bits located in frames 1 and 2 VCOH 1; provides the LCAS multi-frame counter [0–65536]. The SQ field – eight bits located in frame 4 VCOH 1; the SQ value range for OTN LCAS is 0 to 255 inclusive. The CTRL field – four bits located in MFAS frame 5, VCOH1 byte, bits [1. . .4]; contains the LCAS control code. For the coding of the bits CT1, CT2, CT3 and CT4 see Table 3.1. The GID bit – located in MFAS frame 5, VCOH1 byte, bit [5]. The RS-Ack bit – located in MFAS frame 5, VCOH1 byte, bit [6]. The MST field – 256 bits located in the VCOH2 byte; the status report of all the individual members in a VCG uses the MST multiframe as shown in Table 3.9. The status of all 256 members is transferred in 1.5 ms or less, i.e. eight member statuses M1, M2, M3, M4, M5, M6, M7 and M8 are reported per MFAS frame, 32 consecutive MFAS frames are required to convey the status of 256 members, and the MFAS frame rate is 49 ms for an OPU1, 12 ms for an OPU2 and 3 ms for an OPU3. Table 3.9 shows the relation of the MST multi-frame to the MFAS frame value. The CRC–8 field – eight bits located in the VCOH3 byte; the CRC bits C1, C2, C3, C4, C5, C6, C7 and C8 contain the remainder of the CRC–8 calculation over the OTN VLI in VCOH1 and VCOH2. The CRC–8 remainder is calculated as follows: the 16 bits in VCOH1 and VCOH2 in the same MFAS frame represent a polynomial M(x) of degree 15, where bit 1 of VCOH1 in Table 3.8 is the most significant bit and bit 8 of VCOH2 is the least significant bit. M(x) is first multiplied by x8 and then divided (modulo 2) by generator polynomial G(x) ¼ x8 þ x2 þ x þ 1 to produce a remainder R(x) of degree 7 or less. R(x) is the CRC–8 code with x8 of R(x) corresponding to C1 as the most significant bit of the remainder and x0 of R(x) corresponding to C8 as the least significant bit of the remainder; The remaining bits located in MFAS frame 2, frame 3, frame 5 bits [7,8] and frames 6 through 31 are reserved for future use and shall be set to ‘0’. 3.5.3.1

Example of CRC–8 computation for OTN VLI

Table 3.10 shows an arbitrary control packet of an OTN VCG to provide an example of a properly computed CRC.

2

3

5 0 0 0 0 0

0

0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1

4 0 0 0 0 0

0

0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1

1

6 0 0 0 0 1

1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1

0

7 0 0 1 1 0

0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1

8 0 1 0 1 0

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

5

0 1 2 3 4

1

3

CTRL

2

8

7

4 5 6 MFI–1 MFI–2 Reserved Reserved SQ

VCOH1

Reserved

1

2

OTN VLI

RS-Ack

MFAS

frame

Table 3.8

Reserved

GID

1

Don’t care

Reserved

3

5

MST 256 bits

4

VCOH2 6

7

8

1

2

3

5

CRC field 32 x 8 bits

4

VCOH3 6

7

8

61

Link capacity adjustment scheme Table 3.9 MFAS frame (modulo 32) 0 1 30 31

M1 0 8 240 248

OTN LCAS MST multi-frame Member number M2 M3 M4 M5 M6 1 2 3 4 5 9 10 11 12 13 241 242 243 244 245 249 250 251 252 253

M7 6 14 246 254

M8 7 15 247 255

3.5.4 The PDH VLI The most recent (April 2004) development in the application of VCAT and LCAS is the use of PDH signals as members of a VCG. The concatenation of the different PDH signals is described in Chapter 2, Section 2.3.4. This section explains the VLI structure as defined in the new ITU-T recommendation G.7043.

VCOH1

0

0

1

0

0

0

0

0

0

1 2 3 4 5

CTRL ¼ NORM

0

0

0

0

0

0

6 7

1

0 1 1 Reserved 0 0 0 0 Reserved 0 0 0 0 etc.

7

8

1

2

0

1

0

0

0

0

0

0

0

0

0

1

0

0

0

0

0

1

0

0

3 4 5 6 MST [0–7] 0 0 0 1 MST [8–15] 0 0 0 0 MST [16–23] 0 0 0 0 MST [24–31] 0 0 0 0 MST [32–39] 0 1 0 0

VCOH3 7

8

1

2

3

0

0

0

1

0

0

0

1

1

1

0

0

0

1

0

0

0

0

0

0

0

0

0

1

1

MST [40–47]

Res.

0

0

VCOH2

3 4 5 6 MFI–1 ¼ 25 0 1 1 0 MFI–2 ¼ 72 0 0 1 0 Reserved 0 0 0 0 Reserved 0 0 0 0 SQ ¼ 17 0 1 0 0

Res.

2

GID

1

RS-Ack

MFAS

Table 3.10 OTN VLI example

0

0

0

0

0

0

0

0

1

0

0 0 0 0 0 MST [48–55] 0 0 0 0 0 1 MST [56–63] 1 1 1 1 1 1 etc.

4 5 CRC–8 0 1 CRC–8 1 1 CRC–8 0 0 CRC–8 0 0 CRC–8 0 0

6

7

8

0

1

1

1

1

1

0

0

0

0

0

0

1

1

1

1

0

1

1

1

1

CRC–8

0

0

1

1

0

0

1

1

1

1

0 0 0 CRC–8 0 0 0 0 CRC–8 1 1 1 1 etc.

62


To enable an efficient implementation, and because there were no restrictions on the availability of spare bits, the PDH VLI re-uses the octet structure of the SDH higher order H4 control packet. Note, however, that the range of SQ numbers has been reduced because it was considered very unlikely that a PDH VCG would contain up to 256 members. The reduction will only affect the MST multi-frame, as explained below. 3.5.4.1

The E1 and DS1 PDH VLI

Table 3.11 depicts the modified SDH higher order H4 VLI for re-use in the E1/DS1 application. The modification is the limiting of the number of SQ values to a maximum of 16 members per primary rate PDH VCG. The time required to transmit a PDH control packet is 32 ms (16 2 ms) for the E1 signal and 48 ms (16 3 ms) for the DS1–ESF. The primary rate PDH control packet contains: Table 3.11 Primary rate PDH VLI H4 byte 1st multi- 2nd multiframe frame Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8 number number MFI-1 (bits 1-4) C5 C6 C7 C8 0 1 1 1 7 M1 M2 M3 M4 1 0 0 0 8 M6 M7 M8 1 0 0 1 9 M5 0 0 0 RS_Ack 1 0 1 0 10 Reserved (0000) 1 0 1 1 11 Reserved (0000) 1 1 0 0 12 Reserved (0000) 1 1 0 1 13 Reserved (0000) 1 1 1 0 14 SQ MSB (bits 1-4) 1 1 1 1 15 MFI-2 MSB (bits 1-4) 0 0 0 0 0 nþ1 MFI-2 LSB (bits 5-8) 0 0 0 1 1 CT1 CT2 CT3 CT4 0 0 1 0 2 Reserved (0000) 0 0 1 1 3 0 0 0 GID 0 1 0 0 4 Reserved (0000) 0 1 0 1 5 C1 C2 C3 C4 0 1 1 0 6 C5 C6 C7 C8 0 1 1 1 7 M2 M3 M4 1 0 0 0 8 M1


1

63

Table 3.12 Primary rate PDH LCAS MST multi-frame MST multi-frame number Member number based on MFI–2 value M1 M2 M3 M4 2 3 4 5 6 7 8 M5 M 6 M 7 M 8 0 1 2 3 0 4 5 6 7 Don’t care 8 9 10 11 1 12 13 14 15

The interpretation of the MST bits is based on the MFI–2 value at the moment the MST octet M1. . .M8 is received, i.e. the MFI–2 value received in the previous control packet. Only the LSB of MFI–2 is used as an index for this table because there are only 16 members.

The MST field – the status report of all the individual members in a E1/DS1 VCG uses the MST multi-frame as shown in Table 3.12. The status of all 16 members is transferred in two consecutive control packets. The MST multi-frame rate is 4 ms for an E1 and 6 ms for a DS1. The SQ field – four bits located in the nibble MFI–1 [15]; the SQ value range for the primary rate PDH LCAS is 0 to 15 inclusive. The MFI–2 field – the combination of MFI–1 and MFI–2 provides the E1/DS1 VCAT multi-frame counter [0–4095]. This counter enables the detection of a differential delay of up to 256 ms for an E1 and 384 ms for a DS1. The nibble MFI–1 [14] is reserved and set to ‘0000’. The RS-Ack bit, the CTRL field, the GID bit, the CRC–8 field and the remaining reserved bits are re-used but not modified. 3.5.4.2

Example of CRC–8 computation for primary rate PDH LCAS

Table 3.13 shows an arbitrary control packet of a PDH VCG provided as an example of a properly computed CRC. 3.5.4.3

The E3 and DS3 PDH VLI

Table 3.14 depicts the modified SDH higher order H4 VLI for re-use in the E3/DS3 application. The modification is the limiting of the number of SQ values to a maximum of 8 members per ternary rate PDH VCG. The time required to transmit a PDH control packet is 2 ms (16 0.125 ms) for the E3 signal and 1.7 ms (16 0.106 ms) for the DS3 signal.

64

Next Generation SDH/SONET PDH LCAS CRC calculation example

MFI--2 counter = 52 MFI--2 counter = 53

MST [0-7] RS-Ack (‘0’) Reserved (‘0’) SQ ¼ 3 (0x03) MFI-2 ¼ 53 (0x35) CTRL ¼ EOS GID (‘1’) Reserved (‘0’) CRC-8 (0xA0)

bit 1 bit 2 bit 3 bit 4 bit 5 bit 6 bit 7 bit 8 0 1 0 0 1 0 0 0 1 0 1 1 1 0 0 1 0 0 0 1 1 0 1 0 0 0 0 0 1 0 1 1 0 0 0 0 1 1 0 0 0 0 0 0 1 1 0 1 0 0 0 0 1 1 1 0 0 0 1 1 1 1 1 1 0 0 1 1 0 0 0 0 0 1 0 1 0 0 0 1 0 0 1 1 0 0 1 0 0 0 0 1 0 0 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 1 1 0 1 0 0 1 1 0 0 0 0 0 0 1 1 1

8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7

LCAS control packet

VLI byte LCAS OH

MFI-1

Table 3.13

Table 3.14 Ternary rate PDH VLI H4 byte 1st multi- 2nd multiframe frame Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8 number number MFI-1 (bits 1-4) C5 C6 C7 C8 0 1 1 1 7 M1 M2 M3 M4 1 0 0 0 8 M5 M6 M7 M8 1 0 0 1 9 0 0 0 RS_Ack 1 0 1 0 10 Reserved (0000) 1 0 1 1 11 Reserved (0000) 1 1 0 0 12 Reserved (0000) 1 1 0 1 13 Reserved (0000) 1 1 1 0 14 0 SQ LSB (bits 1-3) 1 1 1 1 15 MFI-2 MSB (bits 1-4) 0 0 0 0 0 nþ1 MFI-2 LSB (bits 5-8) 0 0 0 1 1 CT1 CT2 CT3 CT4 0 0 1 0 2 Reserved (0000) 0 0 1 1 3 0 0 0 GID 0 1 0 0 4 Reserved (0000) 0 1 0 1 5 C1 C2 C3 C4 0 1 1 0 6 C6 C7 C8 0 1 1 1 7 C5 M1 M2 M3 M4 1 0 0 0 8


1

65

Table 3.15 Ternary rate PDH LCAS MST multi-frame MST multi-frame number Member number based on MFI–2 value M1 M2 M3 M4 2 3 4 5 6 7 8 M5 M 6 M 7 M 8 0 1 2 3 Don’t care 4 5 6 7

The MST octet M1. . . M8 contains the status of all members in the VCG, hence the MFI–2 value is irrelevant.

The ternary rate PDH control packet contains: The MST field – the status of the eight individual members in a E3/ DS3 VCG M1. . .M8 is reported each control packet. The status of all 8 members is transferred every 2 ms for the E3 signal and every 1.7 ms for the DS3 signal. The SQ field – three bits located in the nibble MFI–1 [15]; the SQ value range for ternary rate PDH LCAS is 0 to 7 inclusive. The MFI–2 field – the combination of MFI–1 and MFI–2 provides the higher order LCAS multi-frame counter [0–4095]. This counter enables the detection of a differential delay of up to 256 ms for an E3 and 217 ms for a DS3. All bits of nibble MFI–1 [14] as well as bit 1 of MFI–1 [15] are reserved for future use and set to ‘0’. The RS-Ack bit, the CTRL field, the GID bit, the CRC–8 field and the remaining reserved bits are re-used but not modified. 3.5.4.4

Example of CRC–8 computation for ternary rate PDH LCAS

Table 3.15 shows an arbitrary control packet of a higher order VCG to provide an example of a properly computed CRC.

4 The LCAS protocol A detailed description Unambiguous interpretation in the specification and description of a protocol is very difficult. ITU-T has developed a language that provides an excellent means to perform this task defined in recommendation Z.100: SDL, a Specification and Description Language. SDL provides two representations: one is graphical and uses symbols to envision the different elements in the language, e.g. state, events, tasks, decisions, etc.; the other is textual and uses statements as elements of the language. The textual representation even allows the text to be compiled producing code that can be used to verify the correctness of the protocol. In this chapter, only the graphical representation is used.

4.1 INTRODUCTION 4.1.1 Asymmetric connections Diverse routing is a feature of virtual concatenation; it allows a better utilisation of the available bandwidth in a network and intermediate nodes are unaware of the VC–ns affiliation with a VCG. Due to the diverse routing, it is very possible that some member paths from node A to node Z do experience a network problem, while the member paths from node Z to node A do not experience any network problem. If the LCAS protocol had been designed with a strict symmetrical


68


behaviour in this case the forward signal problems would have affected the return signal bandwidth. It was also envisioned that for certain applications the downstream path to the client would require more bandwidth than the upstream link, e.g. in the video on demand application. A drawback of this decision is the requirement that the Sink side status of all VCG_a members has to be transferred by each VCG_z members return channel (see Figures 3.1 and 3.2). Generally, the LCAS protocol assumes a directional independence of individual members of a VCG. This implies connection asymmetry, i.e. the bandwidth of the forward transport is independent of the bandwidth of the return transport.

4.1.2 Symmetric connections This application of virtual concatenation with LCAS is noted ‘for further study’ in the recommendation G.7042. A virtually concatenated connection is considered to be symmetrical if each constituent member in the group has an accompanying member in the opposite direction, similar to a bi-directional connection. The Sink side member status is only reported on its partner, similar to the RDI bit in a bidirectional connection. If it is desired to keep the connection symmetric, it is recommended that this shall be provisionable per VCG from the network management system.

4.1.3 Unidirectional operation The operation of LCAS is designed to be unidirectional. This means that in order to change the payload size in both directions, or bidirectionally by adding or removing members, the add or remove procedure has to be performed twice, once in the forward direction for VCG_a and once in the return direction for VCG-z (see Figure 3.1). Note that these actions are independent of each other and it is not necessarily required that they are synchronised. The LCAS protocol provides a hitless increase and decrease of available bandwidth under the control of a network management system. In addition to the changes under management control, LCAS will autonomously remove failed members temporarily from the group. When the failure condition is remedied, LCAS will add the member back into the group. In general, due to path layer failures, the removal of a member, and the

The LCAS protocol

69

part of the total payload it is transporting, will not be hitless for the service carried by the virtually concatenated group. The autonomous addition of the failed members payload, after a failure is repaired, is again hitless.

4.2 THE SIZE OF A VCG The size of the VCG is determined by three parameters; these parameters are used to define the payload container C–n–Xc transported by a VC–n–Xv: (1) The parameter XM indicating the maximum size of the VCG. The value of this parameter will be determined by equipment specific definition for the applicable transport network technology. For SDH, the definition is in ITU-T G.707 (M ¼ 63 for C–11, C–12, C–2 and M ¼ 255 for C–3 and C–4). For SONET, the definition is in ANSI T1.105 (M ¼ 63 for VT1.5 and M ¼ 255 for STS–1 and STS– 3c). For OTN, the definition is in ITU-T G.709 (M ¼ 255 for OPUk). The value may be further restricted to lower values in specific implementations. (2) The parameter XP indicating the number of provisioned members in the VCG, i.e. all members transmitting the code NORM, EOS or DNU in the CTRL field. The value of this parameter will be determined by commands from the network management system. Each completed MI_ADD command will increment XP by 1 and each completed MI_REMOVE command will decrement XP by 1. Furthermore, the relationship 0 XP XM holds. (3) The parameter XA indicating the actual number of active members in the VCG. The value of this parameter will be determined by the LCAS protocol itself and is influenced by the autonomous adding or deleting of members in the case of individual member failures, i.e. XA is the number of members that are actually transporting the payload, and are transmitting the code NORM or EOS in their CTRL field. The relationship 0 XA XP XM holds. Each of these parameters can then be further qualified in separate terms. When the Source (Transmit) side or the Sink (Receive) side process needs to be referenced specifically, a ‘T’ or an ‘R’ is added to the terms, respectively; e.g. XPT is the provisioned number of members at the Source (Transmit) side of the VCG and XAR is the actual number of members carrying payload as determined at the Sink (Receive) side.

70


To avoid possible misalignment between the Source side and the Sink side regarding the sequence numbers and the corresponding received far-end statuses, the number of provisioned members in the VCG is only changed under network management control. The sequence number received just before an MSU_L is detected will be used for the reporting of the member status, but the payload will not be used to reconstruct the original signal. If the failed member is removed (by network manager action) there will be a renumbering of the remaining sequence numbers. Replacement of a failed member (in the state DNU) because the failure in the network cannot be repaired has to be performed by using a MI_REMOVE – MI_ADD sequence.

4.3 THE LCAS PROTOCOL DESCRIBED USING SDL A model was developed and defined to specify and describe the behaviour of a VCG supporting LCAS. The LCAS protocol is described using state machines because in the LCAS protocol stable states can be identified, transitions from one state to the other are caused by events or input signals, and during the transitions events or output signals are sent. ITU-T has recommendation Z.100, a Specification and Description Language, to model such a state machine diagram. It can be used in two ways, either a graphical presentation using symbols representing states, inputs, outputs, tasks, decisions, etc. or a textual presentation like a high level programming language.

4.3.1 Used SDL symbols In ITU-T G.7042 the graphical representation is used. Figure 4.1 shows the SDL symbols used in this chapter.

4.3.2 LCAS state machines Four distinct state machines can be recognised to support the LCAS protocol: At the Source side, the state machine representing the transmit side of the LCAS protocol of a single member in the VCG. When a VCG

71

The LCAS protocol N

steady state

N

event received / signal input, required for a state transition event sent / signal output, during state transition delay processing of an event until after transition to next state task to be performed during state transition

N

decision symbol

N

procedure call symbol

N

procedure start symbol

NXYZ NXYZ N

return from procedure

Figure 4.1

LCAS SDL symbols

has been provisioned with n members, n instances of this state machine will be active concurrently. At the Source side, the state machine representing the receive side of the LCAS protocol common for all members in the Source side VCG. At the Sink side, the state machine representing the receive side of the LCAS protocol of a single member in the VCG. When a VCG has been provisioned with m members, m instances of this state machine will be active simultaneously. In this state, machine procedure calls are made; these specific procedures are also presented using SDL. At the Sink side, the state machine representing the transmit side of the LCAS protocol common for all members in the Sink side VCG.

4.3.3 LCAS events used in the SDL diagrams To indicate the possible events in the SDL descriptions, the following conventions are used: The next five control events will be forwarded from the Source side towards the Sink side. A particular member will always forward only one of these events repeatedly in its control packet (so there

72


are always XMT control events transmitted). The messages pertain to the member from which the event is sent. (1) FIDLE is the control event to indicate that this container is not provisioned to be a member of the VCG and that no ADD requests are pending. (2) FADD is the control event to indicate that there is a request to add this member to the group, i.e. an MADD event has been received at the Source side from the network management system. This member is considered to be a provisioned member. (3) FNORM is the control event to indicate that this is a normal, active, provisioned member of the VCG. It does not have the highest sequence number. (4) FEOS is the control event to indicate that this is a normal, active, provisioned member of the VCG that has the highest sequence number among the active, provisioned members in the group. (5) FDNU is the control event to indicate that the payload container of this provisioned member in the VCG shall not be used. This member is considered not to be an active member in the VCG. The next three control events will be sent between members. These events will occur in the Source side Send state machines only. (1) CNRM is the control event sent by member(i) to member(i 1) to indicate that it will transmit CTRL code NORM, i.e. member(i) or one of the members next in sequence is transmitting CTRL code EOS. (2) CEOS is the control event sent by member(i) to member(i 1) to indicate that it will transmit CTRL code EOS, i.e. all provisioned members next in sequence are transmitting CTRL code DNU. (3) CEOS is the control event sent by member(i) to member(I þ 1) to indicate that it will decrement its SQ value, i.e. member(i) is removed from the VCG and all provisioned members next in sequence shall decrement their SQ number to keep the SQ sequence contiguous. Four control events will be returned from Sink side to Source side to indicate the status at the Sink side of each member and the VCG. (1) ROK is the control event to indicate that the member is able to transport payload.

The LCAS protocol

73

(2) RFAIL is the control event to indicate that the member cannot transport payload or that the payload signal is degraded. (3) RMST is the control event returned from Sink side to Source side and contains the control events ROK or RFAIL of all individual Sink side members. In the return direction all members of the VCG send the same RMST event. Now the Source side can, for example, read the returned status information from member No. 1 and, if that member’s information is unavailable, the same status information can be retrieved from member No. 2, etc. As long as no return status information is available, the Source end will use the last received valid status information. (4) RACK is the control event returned from Sink side to Source side to acknowledge the detection at the Sink side of a renumbering of the sequence of the members in the Source side VCG or a change in the number of provisioned members at the Source side of the VCG. This acknowledgement is used to synchronise Source side and Sink side. It is also intended to eliminate the influence of network delays. Due to the renumbering of the sequence at the time of an ADD or a REMOVE request the received member status shall not be used for a time period that is determined by transmission delays and framing delays. The next two control events are management control events received from the network management system at both Source side and Sink side. (1) MADD is the control event requesting to ADD a member to the VCG. Adding a new member is always at the end of the group with a new, highest, sequence number. (2) MREM is the control event requesting to REMOVE a member from the VCG. The remove operation affects a specific member. The next two control events are received at the Sink side from the path termination of each individual member(i). (1) TSD is the control event to indicate that a degraded signal has been detected. (2) MSU_L is the control event to indicate that Member Service Unavailable in LCAS mode has been detected. Figure 4.2 shows the location of the separate state machines and where the control events originate and terminate.

74

Next Generation SDH/SONET Source side Sink side

VCG

RACK RMST

RMST

RX

RX RX

S RSQ

SRSQ

VCG

RACK

RX

SRSQ

R

SRSQ

R

SRSQ

R

CRSQ

F

SRSQ

R F

CRSQ

CX member(i)

CX

member(i) member(i + 1)

member(i + 1)

Figure 4.2

LCAS flow of events

4.3.4 The SDL diagrams All of the following state machines will run concurrently for all Source XMT, Sink XMR, Source VCG and Sink VCG functions. 4.3.4.1

Source side transmit state machine

There is a separate state machine for each of the XMT members at the Source side (Figure 4.3). Each of these Source side Transmit state machines can be in one of the following five states: (1) IDLE: This member is not provisioned to participate in the VCG. (2) NORM: This member is provisioned to participate in the VCG and has a good path to the Sink side, confirmed by the MST ¼ OK received for this member from the Sink side. (3) DNU: This member is provisioned to participate in the VCG and has a failed path to the Sink side, indicated by the MST ¼ FAIL received for this member from the Sink side. (4) ADD: This member is in the process of being added to the VCG. (5) REMOVE: This member is in the process of being deleted from the VCG.

75

The LCAS protocol State diagram of member(i) with sequence number SQ(i) in a VCG with n provisioned members at the transmitting Source side

Start FIDLE

IDLE MADD SQ(i) := SQ(n)+x

x>1

FADD

NORM/EOS CRSQ

CNRM

CEOS

SQ(i) := SQ(i)-1

FNRM

FEOS

ADD

MREM

RFAIL

EOS

N

SQ(i) := SQ(n)+1 n := n+1

CEOS

FEOS

FDNU

SRSQ

stop sending payload

CNRM start sending payload

DNU CRSQ

C NRM

CEOS

SQ(i) := SQ(i)-1

CNRM

CEOS

SQ(i) larger than SQ of member sending EOS ?

MREM

ROK Y

Y MREM

ROK

member n

CEOS

N CRSQ

n := n-1 SRSQ

Y FEOS

> EOS

N FNRM

CNRM

stop sending payload SQ(i) := (max)

start sending payload

FIDLE REMOVE RFAIL

Figure 4.3

LCAS Source side: transmit

76


State diagram of member(i) in a VCG with n provisioned members TSD

cleared

TSD

MSU_L

raised

WTR

OK FIDLE

raised

HO

Y

MREM

FEOS

changed

N

SQ

changed

MSU_L N cleared

N

Y TSD

RFAIL

Y S RSQ

RFAIL

Y

cleared

discard payload

ROK

Start FAIL MSU_L

FADD N

cleared

RFAIL

Y OTHER

Fx?

ADD

NRM/EOS DNU WTR N

MREM

SQ

correct

discard payload IDLE

MSU_L

MADD

cleared

Y N

TSD

cleared

Y OTHER

Fx?

FDNU

discard use payload payload

SQ

RSAck

FNRM

ADD DNU

NRM EOS use payload ROK

Figure 4.4 LCAS Sink side: receive

N

77

The LCAS protocol

4.3.4.2

Sink side receive state machine

There is a separate state machine for each of the XMR members at the Sink side (Figure 4.4). Each of these Sink side Receive state machines can be in one of the following three states: (1) IDLE: This member is not provisioned to participate in the VCG. (2) OK: The incoming signal for this member experiences no failure condition (e.g. TSD or MSU_L) or has received and acknowledged a request for addition of this member (i.e. the code ADD in the CTRL field). (3) FAIL: The incoming signal for this member experiences a failure condition or an incoming request for removal of a member has been received and acknowledged.

Procedures at the Sink side receive end (Figure 4.5) The WTR procedure describes the Wait To Restore timer activation and deactivation procedure. It is used to avoid unwanted effects due to intermittent alarms, as described in ITU-T recommendation G.808.1. The HO procedure describes the Hold Off timer activation and deactivation procedure. It is used to limit the number of temporary removal actions in case of nested protection switches, as described in ITU-T recommendation G.808.1.

TSD

raised

WTR

HO

TSTART

TSTART

wait for WTR time out

wait for HO time out

MSU_L raised

M REM

TEXP

MREM

MREM

MREM

TSTOP

TSTOP

TEXP

Figure 4.5 LCAS Sink side: WTR and HO procedures

78

Next Generation SDH/SONET State diagram of a VCG with n provisioned members at the receiving Source side

Start

process MST RMST

SRSQ

MST disassemble

Tstart

for each bit(i) in the MST field send ROK/FAIL to member(i)

RX RX RX

wait for RS-Ack Texpiry

RACK

S RSQ

Tstop

Trestart

Figure 4.6

4.3.4.3

RMST

LCAS Source side: receive

Source side receive state machine

At the Source side, there is a Source side Receive state machine for the VCG as a whole (Figure 4.6). This state machine can be in one of the following two states: (1) Process MST: The status information of each member at the Sink side of the VCG of size n is extracted from the MST field in the control packets and sent to the appropriate member(i) with 0 i (n 1). (2) Wait for RS-Ack: There is a change in the SQ numbering of the VCG at the Source transmit side. Processing of the MST information is stopped until a toggling of the RS–Ack bit will be received from the Sink side or until the RS-Ack response will timed out. 4.3.4.4

Sink side transmit state machine

At the Sink side, there is a Sink side Transmit state machine for the VCG as a whole (Figure 4.7). This state machine has only one single state:

79

The LCAS protocol State diagram of a VCG with n provisioned members at the transmit Sink side

Start

assemble MST SRSQ RACK

RX RX RX assemble MST

for each member(i) place ROK/FAIL in bit(i) of the MST field sent

RMST

Figure 4.7

LCAS Sink side: transmit

(1) Assemble MST: At the Sink side VCG of size n, the status information of each member(i) with 0 i (n 1) is inserted in the appropriate bit of the MST field sent in the control packet. When the Sink side LCAS process detects a change in the SQ numbering of the VCG, the Source side LCAS process will be notified by toggling the RS–Ack bit.

5 LCAS time sequence diagrams Timing the procedure Even though the LCAS protocol has been defined using SDL, which would be sufficient to implement the protocol correctly, the ITU-T recommendation G.7042 contains some examples of specific LCAS operations to enhance its understanding. These examples are in the form of time sequence diagrams to explain the time relation between the successive steps taken during the operation of the protocol. As the SDL diagrams are state-machines they do not contain this timing information. This chapter also provides some examples of typical LCAS state transitions. Some are based on planned changes of the size of a VCG and some are based on unplanned occurrences in the network affecting one or more members in a VCG.

5.1 INTRODUCTION In the provided time sequence diagrams, the time progresses from top to bottom. A scale is not given because some of the time intervals depend on the propagation delay of the physical path between both VCG path termination functions at the Source side and at the Sink side. There are also time intervals that depend on the internal processing of events and transitions between the different states. Horizontally, from left to right, are depicted the Network Management System (NMS), the VCG Source side shown as a group and the VCG Sink side showing the individual members. Next Generation SDH/SONET: Evolution or Revolution? Huub van Helvoort # 2005 John Wiley & Sons, Ltd ISBN: 0-470-09120-7

82


5.2 PROVISIONING A MEMBER The provisioning of new additional members (or a new VCG) will be initiated by the NMS. The NMS shall provision for each new member the path termination function at both the Source side and the Sink side of the VCG. The NMS shall also setup the required new member path between the path termination functions at the Source side and the Sink side. The order of provisioning path and termination functions is arbitrary. The following examples show the preferred order. When a new VC–n or VC–m is provisioned to be a member of the VCG of size n, initially it will have the following conditions: At the Source side of the VCG the LCAS process will take care that for the new provisioned member: (1) the CTRL code IDLE will be sent. This code indicates that this member is not yet active in the VCG. (2) the SQ shall be set to a value larger than the currently highest sequence number used in the VCG. In a VCG of size n the highest sequence number is (n 1). The active member that has the highest sequence number is transmitting the CTRL code EOS (or DNU when this member experiences a network fault). Even though the value assigned to the SQ of the new member will not be interpreted at the Sink side as long as the CTRL code IDLE is sent, it is recommended to use the highest possible value. In the following examples the value (max) is used to indicate that the SQ number to be assigned is the highest possible value. Because the highest possible value is technology specific, the notation (max) is used in this chapter. For the actual maximum values, refer to Chapter 4. (3) the GID bit shall be equal to the GID bit of the already existing members of the VCG and will represent the group ID for this particular VCG. At the Sink side of the VCG, the LCAS process will take care that for the new provisioned member: 1. the member status MST ¼ FAIL is sent. The MSU_L signal received from the member termination function because the path setup has not been completed will maintain this status. Also, the reception of the CTRL code IDLE after the MSU_L has cleared because the path through the network is OK will maintain the transmission of the MST ¼ FAIL status.

LCAS time sequence diagrams

83

5.3 VCG STATE TRANSITION EXAMPLES During the lifetime of a VCG in a network, the following most common changes in bandwidth can occur: (1) An increase of the payload bandwidth of the VCG by adding one or more members to the group. The new members will always be added to the VCG after the member that currently is sending the highest SQ number. (2) A decrease of the payload bandwidth of the VCG by removing one or more members from the group. A distinction is made between removing the member from the VCG that has the highest SQ number and removing any other member(s) from the VCG. (3) A temporary decrease of the payload bandwidth of the VCG due to a network fault. Again a distinction is made between the member of the VCG that has the highest SQ number and any other member experiencing a network problem.

5.3.1 An increase of the bandwidth of a VCG Two distinctive timing diagrams are provided to illustrate the operation of the LCAS process during the addition of members to a VCG. The first diagram shows the addition of multiple members to a VCG and illustrates that the order of arrival and acceptance at the Sink side determines the assigned sequence numbers. The second diagram depicts the addition of a single new member to a VCG where a network problem causes an RS-Ack time-out. 5.3.1.1

A planned increase of a VCG with two members

In this example, two members are added to a VCG of size n. According to the ITU-T recommendation the new members shall be added after the member of the VCG that has the highest SQ number. The example shows the addition of two members because the addition of a single member can be derived easily from this example and adding more that two members will be similar. The example illustrates also that the LCAS process can handle situations where the new information is received in a different order as when it was initially transmitted. Figure 5.1 shows the timing diagram for the addition procedure. The addition is planned and will have to be initiated by the NMS. Also, the

84


LCAS VCG(n)

Step 1 NMS Step 2

SQ=(n-1) CTRL=EOS MST=OK

Source

Sink

member (a)

member (b)

SQ=(max) CTRL=IDLE MST=FAIL


Sink

Sink

MI_ADD

SQ=(n+1) CTRL=ADD

Step 3 SQ=(n) CTRL=ADD

connectivity check Step 4 Step 5

MST=OK

CTRL=NORM

Step 6

SQ=(n) CTRL=EOS

SQ=(n+1)

toggle RS-Ack

connectivity check Step 7

MST=OK

Step 8

CTRL=NORM

CTRL=EOS

Step 9

toggle RS-Ack

LCAS VCG(n+2)

Figure 5.1

SQ=(n-1) CTRL=NORM MST=OK

SQ=(n+1) CTRL=EOS MST=OK

SQ=(n) CTRL=NORM MST=OK

Planned addition of multiple members

NMS is expected to setup the path through the network for each individual additional member and to provision the new member termination functions at both the Source side and the Sink side of the VCG. Step 1 The initial condition. In a VCG with n members, the last member in the sequence is transmitting SQ ¼ (n 1) and CTRL ¼ EOS. The additional members that are not yet part of the VCG are


85

transmitting SQ ¼ (max) and CTRL code IDLE at the Source side and MST ¼ FAIL at the Sink side. Step 2 The NMS issues the MI_ADD commands to the Source side LCAS process and the Sink side LCAS process. Because in this example two members are added, the LCAS process assigns sequence number SQ ¼ (n) to member (a) and assigns SQ ¼ (n þ 1) to member (b). Step 3 At the Source side the added members change their CTRL code from IDLE to ADD and transmit this code together with the assigned SQ numbers. Due to experienced network delays requiring differential delay compensation and delays caused by the connectivity check at the Sink side, the CTRL ¼ ADD of member (b) is detected first by the LCAS process. Consequently the change to MST ¼ OK of member (b) arrives at the Source side first. The assigned sequence numbers of the added members have to be changed such that the member (b) will be reassigned SQ ¼ (n). Consequently, in this example the other additional member (a) will be re-assigned SQ ¼ (n þ 1). (Note that this example shows new member (b) responding with MST ¼ OK before new member (a). This is arbitrary, in general the first member to respond with MST ¼ OK shall be allocated the SQ ¼ n, then the next new member to respond with MST ¼ OK shall be allocated SQ ¼ (n þ 1), etc. If for any reason a member being added does not respond with MST ¼ OK within a certain time the Source side LCAS process may report a failure for that member to the NMS.) Step 4 The member (b) will start transmitting CRTL code EOS and the member previously transmitting CTRL ¼ EOS will change its CTRL code to NORM. The LCAS process at the Source side will now stop MST evaluation until an RS-Ack toggle is received or timed out. Step 5 At the Sink side, the change in the VCG size is detected by observing the SQ numbers. This is reported back to the Source side by toggling the RS-Ack bit. When the Source side LCAS process detects the toggle it will start evaluating the MST values again. The Sink side LCAS process will add the payload of the additional member (b) to the total VCG payload.

86


Step 6 Finally, the MST ¼ OK for member (a) arrives at the Source side. In this example no further re-sequencing is required. Step 7 The member (a) will now start transmitting CTRL code EOS and the previously added member (b) will change the transmitted CTRL code to NORM. The LCAS process will stop the MST processing until an RS-Ack toggle is received or timed out. Step 8 The change in VCG size is detected at the Sink side due to the change in SQ numbers and consequently the RS-Ack bit is toggled. The Sink side LCAS process will add the payload of the added member (a) to the total VCG payload. 5.3.1.2

A planned increase of a VCG with RS-Ack timeout

In this example, a single member is added after the member with the highest SQ number in a VCG of size n. The example shows that the LCAS process can handle situations where the expected toggling of the RS-Ack bit does not occur and a timeout is used to recover from this situation. Figure 5.2 shows the timing diagram for this addition. The addition is planned and initiated by the NMS and also the NMS is expected to setup the path through the network and provision the new member at both the Source side and the Sink side of the VCG. Step 1 The initial condition. In a VCG with n members, the last member in the sequence is transmitting SQ ¼ (n 1) and CTRL ¼ EOS. The member not yet part of the VCG is transmitting SQ ¼ (max) and CTRL ¼ IDLE from the Source side and MST ¼ FAIL from the Sink side. Step 2 The NMS issues the MI_ADD commands to the Source side LCAS process and to the Sink side LCAS process. Because in this example one member will be added, this member (a) is assigned sequence number SQ ¼ (n) by the LCAS process. Step 3 At the Source side, the added member changes its CTRL code from IDLE to ADD and starts transmitting this code together with the assigned SQ number. After performing the connectivity check of the network path at the Sink side the status MST ¼ OK for member (a) is sent to the Source side. Because

87

LCAS time sequence diagrams member (a) LCAS VCG(n)

Step 1 NMS Step 2


Source


Sink

Sink

Sink

MI_ADD

CTRL=ADD SQ=(n) connectivity check

Step 3 MST=OK Step 4

CTRL=NORM

network fault

MST=FAIL

Step 5 Step 6

CTRL=EOS SQ=(n)

RS-Ack time-out

Step 7

CTRL=EOS

CTRL=DNU

fault repaired MST=OK

Step 8 Step 9

CTRL=NORM LCAS VCG(n+2)

Figure 5.2

CTRL=EOS


SQ=(n) CTRL=EOS MST=OK

Planned addition of one member with network problem

member (a) is the only additional member it will maintain its assigned SQ ¼ (n). Step 4 Member (a) will change the CRTL code from ADD to EOS and at the same time the member previously transmitting CTRL code EOS will change the CTRL code to NORM. The LCAS process at the Source side will now stop MST evaluation until an RS-Ack toggle is received or timed out.

88


Step 5 Before the control packet with the new CTRL code EOS arrives at the Sink side a network problem occurs that causes an MSU-L signal to be sent from the member (a) trail termination function to the Sink side LCAS process. As a consequent action, the member (a) status MST ¼ FAIL is sent to the Source side. Because the LCAS process at the Sink side does not detect a change in the size of the VCG it will not toggle the RS-Ack bit. Step 6 When the MST ¼ FAIL of member (a) is received at the Source side it will not be evaluated because the Source side LCAS process is still waiting for an RS-Ack (see also Step 4). Only when the RS-Ack timer expires imitating a toggled RS-Ack bit will the received MST values be evaluated again. Step 7 Upon detection of the MST ¼ FAIL for member (a), the LCAS process will change its state to DNU. Member (a) starts transmitting CTRL code DNU and the member with SQ ¼ (n 1) will at the same time change the CTRL code from NORM to EOS. Step 8 When the network problem is repaired, the MSU-L signal clears, and after the Wait To Restore (WTR) timer expires, the normal LCAS overhead of member (a) can be processed again. The CTRL code DNU will be detected and as a consequent action MST ¼ OK for member (a) is sent to the Source side. Step 9 At the Source side, the received MST ¼ OK for member (a) will change its state to NORM. Member (a) will change its transmitted CTRL code from DNU to EOS and at the same time the member that was sending CTRL code EOS will change its CTRL code to NORM. The Sink side LCAS process will add the payload of the additional member (a) to the total VCG payload the moment the CTRL code EOS is detected.

5.3.2 A decrease of the bandwidth of a VCG Two distinctive timing diagrams are provided to explain the operation of the LCAS process during a planned decrease of the payload bandwidth of a VCG. The first diagram shows the removal from a VCG of multiple members that do not have the highest SQ number.

89


The second diagram shows the removal of the member of a VCG that has the highest SQ number. 5.3.2.1 Planned removal of multiple members NOT including the last In this example, two members are removed from a VCG of size n. None of these members is the last member of the VCG, i.e. they do not have the SQ value (n 1). One member is removed while it experiences a problem in the network and is sending CTRL code DNU. Possibly, this member is removed because the network fault cannot be repaired. The other member is transporting payload and sending CTRL code NORM. Figure 5.3 shows the timing diagram for the multiple member removal. The removal is planned and initiated by the NMS. To ensure a hitless decrease of the payload bandwidth of a VCG, first the NMS issues an MI_REM command to the Source side LCAS process then waits until the LCAS process has completed the remove operation before issuing an MI_REM command to the Sink side LCAS process and breaking down the network path used by the removed member. member (a) LCAS VCG(n)

Step 1 NMS Step 2


Source

SQ=(n-2) CTRL=DNU MST=FAIL Sink

Sink

SQ=(n-1) CTRL=EOS MST=OK Sink

fault

MI_REM

Step 3

member (b)

CTRL=IDLE

CTRL=IDLE

SQ=(n-3)

SQ=(max)

SQ=(max)

MST=FAIL toggle RS-Ack

Step 4 Step 5

MI_REM

LCAS VCG(n-2)

Figure 5.3



Planned removal of multiple members


90


The removal of a single member that is either in the NORM state or in the DNU state from a VCG can be derived easily from the given example. The removal of more than two members is also similar. Step 1 Initial condition. In a VCG with n members, the last member in the sequence is transmitting SQ ¼ (n 1) and CTRL code EOS. Member (b) is transmitting SQ ¼ (n 2) and experiences a problem in the network reported by MST ¼ FAIL. Consequently, this member is transmitting CTRL code DNU. All other active operational members, including member (a), are transmitting CTRL code NORM. Step 2 The total payload transported by this VCG has to be decreased. This will be achieved in this example by removing member (a) and member (b). The NMS issues an MI_REM command to the Source side LCAS process to provision the removal of the two members. Step 3 At the Source side, member (a) and member (b) start transmitting CTRL code IDLE and SQ ¼ (max). At the same time the payload size of the VCG is decreased and distributed over the remaining active provisioned members. All members with an SQ number larger than the original SQ number of the removed members will be allocated a new sequence number to keep the sequence of the VCG consecutive. In this example, the last member of the VCG shall start to transmit SQ ¼ (n 3). The LCAS process at the Source side will stop MST evaluation until an RS-Ack toggle is received or timed out. Step 4 At the Sink side, the change in the VCG size, i.e. the decrease in sequence numbering, is detected. This is reported back to the Source side by toggling the RS-Ack bit. After detection of the toggled RS-Ack bit, the Source side LCAS process will start evaluating the MST again. The Sink side LCAS process will also detect the CTRL code IDLE of the removed member (a) and will send MST ¼ FAIL for this member. The MST value shall be updated at the latest in the same control packet sending the toggled RS-Ack bit. Because of the network problem, the Sink side process cannot detect the CTRL code IDLE of member (b) and will maintain the transmission of MST ¼ FAIL for member (b). Immediately, the LCAS process will stop using the payload of member (a) in the re-assembly of the total VCG payload; the

91


payload of member (b) was not used for the re-assembly from the moment the network problem was detected. Step 5 The removed members can now be de-provisioned by the NMS, if desired, by issuing an MI_REM command to the Sink side LCAS process. The NMS can now also break down the removed members path through the network. Both members are moved to the IDLE state and will not be affected by server signals nor CTRL codes. 5.3.2.2

Planned removal of a single (i.e. last) member

In this second example of a planned removal, the last (but not necessarily final) member is removed from a VCG of size n (n > 1), i.e. it has the SQ value (n 1) and is sending CTRL code EOS. The removal of multiple members including the last member of the VCG is a combination of this example and the previous example. Figure 5.4 member (a) LCAS VCG(n)

Step 1 NMS Step 2

SQ=(n-2) CTRL=NORM MST=OK Sink

Source

SQ=(n-1) CTRL=EOS MST=OK Sink

MI_REM

Step 3

CTRL=EOS

CTRL=IDLE SQ = (max)

toggle RS-Ack MST=FAIL

Step 4

Step 5

MI_REM

LCAS VCG(n-1)


Figure 5.4 Planned removal of the last member


92


shows the timing diagram for the removal of the last member from the VCG. The removal is planned and initiated by the NMS that issues an MI_REM command to the LCAS process.

Step 1 Initial condition. In a VCG with n members, the last member in the sequence is transmitting SQ ¼ (n 1) and CTRL ¼ EOS. All other active operational members are transmitting CTRL ¼ NORM. Step 2 The total payload transported by this VCG has to be decreased. To achieve this member (a), the last member in the sequence, is removed. The NMS issues an MI_REM command to the Source side LCAS process. Step 3 At the Source side, member (a) starts transmitting CTRL code IDLE and SQ ¼ (max). At the same time the payload of the VCG is decreased and distributed over the remaining active provisioned members. Because the last member in the sequence is removed no re-allocation of the SQ numbers is required. In this case the new last member remains transmitting SQ ¼ (n 2). The LCAS process at the Source side will stop MST evaluation until an RS-Ack toggle is received or timed out. Step 4 At the Sink side, the change in the VCG size, i.e. the decrease in sequence numbering, is detected. This is reported back to the Source side by toggling the RS-Ack bit. After detection of the toggled RS-Ack bit, the Source side will start evaluating the MST again. The Sink side LCAS process detects the CTRL code IDLE of the removed member (a) and consequently will send MST ¼ FAIL for this member. The MST value should be updated at the latest in the same control packet sending the toggled RS-Ack bit. Immediately, the LCAS process will stop using the payload of member (a) in the re-assembly of the total VCG payload. Step 5 The removed member can now be de-provisioned by the NMS, if desired, by issuing an MI_REM command to the Sink side LCAS process. The NMS can now also break down the removed members path through the network.

93


5.3.3 Decrease of bandwidth due to a network problem Two distinctive timing diagrams are provided. The first diagram shows the removal of a member that is not the last member in a VCG, i.e. the member that is transmitting CTRL code EOS. The second diagram shows the removal of the member of a VCG of size n (n >1) that is transmitting CTRL code EOS. In both timing diagrams, the temporary decrease is caused by a complete loss of the member signal. If the network problem is a degraded signal due to bit errors, the response of the LCAS process is slightly different as explained in the last section. 5.3.3.1

Decrease due to network fault (NOT last member)

In this example, one member is removed from a VCG of size n due to a problem in the network. This member is not the last member of the VCG, i.e. it does not have the SQ value (n 1), it is sending CTRL code NORM and it is transporting payload. The removal of multiple members from within the VCG is similar. Figure 5.5 shows the timing diagram for the single member removal. The removal is not planned. member (a) SQ=(i) CTRL=NORM MST=OK

LCAS VCG(n)

Step 1 NMS

Sink fault

Source

Step 2 Step 3 Step 4

Sink

MST=FAIL member failed

CTRL=DNU

Step 5

Note

repaired MST=OK

Step 6

Step 7

SQ=(n−1) CTRL=EOS MST=OK

member OK

CTRL=NORM

LCAS VCG(n)

Figure 5.5

SQ=(i) CTRL=NORM MST=OK


Temporary removal of a member (not the last)

94


Step 1 Initial condition. In a VCG with n members, the last member in the sequence is transmitting SQ ¼ (n 1) and CTRL ¼ EOS. All other active operational members are transmitting CTRL ¼ NORM. Step 2 A network fault occurs and affects the path of member (a) in the VCG. This is detected by the trail termination function of member (a) and is forwarded to the Sink side LCAS process by the Member Service Unavailable _ LCAS-mode (MSU_L) signal. Step 3 The Sink side LCAS process receives the MSU_L event and will immediately change the status of member (a) to MST ¼ FAIL. At the same time the payload of member (a) will not be used anymore to reconstruct the original VCG payload. For the reassembly of the payload of the VCG, only the payload of members sending CTRL code NORM or EOS is used. For a certain time, i.e. the (propagation time from Sink side to Source side) þ (reaction time of the Source side) þ (propagation time from Source side to Sink side), the re-assembled payload will be erroneous because it is sent on all n members as per prefault. This is indicated in Figure 5.5 by the bold dotted line of member (a). Step 4 The Source side LCAS process detects the MST ¼ FAIL of member (a) and consequently will start sending CTRL code DNU and at the same time stop using the payload area of member (a). The reduced the payload size of the VCG is distributed over the remaining members sending the CTRL code NORM or EOS. From the time the CTRL ¼ DNU would have arrived at the Sink side, the transported, reduced, payload of the VCG is free of errors. This is indicated in Figure 5.5 by the start of the bold solid line of member (a). A message reporting the failed member (a) is sent to the NMS. Because the sequence numbering is not changed, the temporary change of bandwidth does not have to be acknowledged by the RS-Ack bit toggle. Step 5 The network fault is repaired and the trail termination function of member (a) will detect this and remove the MSU_L signal sent to the Sink side LCAS process.


95

Step 6 The Sink side process is now able to detect the CTRL code DNU sent by the Source side process as indicated in Step 4 and consequently will send the status MST ¼ OK for member (a) to the Source side. The payload of member (a) will remain unused. Step 7 The Source side detects the MST ¼ OK of member (a) and consequently will start sending CTRL code NORM for member (a). At the same time the payload area of member (a) is used again and the VCG will be able to transport the full payload. This is indicated in Figure 5.5 by the end of the bold solid line for member (a). A message reporting the OK status of member (a) is sent to the NMS. (Note that if the failed channel is deleted through a planned decrease prior to the fault clearing, the Sink side will not be able to see the change in the failed member’s control packet. However, as the SQ numbers will change, the Sink side LCAS process will detect the planned decrease and consequently will toggle the RS-Ack bit. The bandwidth of the VCG is not affected.) 5.3.3.2

Decrease due to network fault last member

In this example, one member is removed from a VCG of size n due to a problem in the network. This member is the last member of the VCG, i.e. it does have the SQ value (n 1), it is sending CTRL code EOS and it is transporting payload. The removal of multiple members including the last one from the VCG is a combination of this example and the previous example. Figure 5.6 shows the timing diagram for the single last member removal. The removal is not planned. Step 1 Initial condition. In a VCG with n members, the last member in the sequence is transmitting SQ ¼ (n 1) and CTRL code EOS. All other active operational members are transmitting CTRL code NORM. Step 2 A network fault occurs affecting the path of member (a) in the VCG. This is detected by the path termination function of member (a) and is forwarded to the Sink side LCAS process by the MSU_L signal.

96

Next Generation SDH/SONET member (a) SQ=(n−2) CTRL=NORM MST=OK

LCAS VCG(n)

Step 1 NMS

Source

Sink fault

Sink

Step 2

Step 3 Step 4

MST=FAIL member failed

CTRL=EOS

CTRL=DNU repaired

Step 5

Note

MST=OK

Step 6

Step 7


member OK

CTRL=NORM

LCAS VCG(n)

Figure 5.6

CTRL=EOS

SQ=(n−2) CTRL=NORM MST=OK


Temporary removal of the last member

Step 3 The Sink side LCAS process receives the MSU_L signal and will immediately change the status of member (a) to MST ¼ FAIL. At the same time the payload of member (a) will not be used anymore to reconstruct the original VCG payload. For the re-assembly of the payload of the VCG only the payload of members sending CTRL code NORM or EOS is used. For a certain time, i.e. the (propagation time from Sink side to Source side) þ (reaction time of the Source side) þ (propagation time from Source side to Sink side), the re-assembled payload will be erroneous because it is sent on all n members as per prefault. This is indicated in Figure 5.6 by the bold dotted line of member (a). Step 4 The Source side LCAS process detects the MST ¼ FAIL of member (a) and consequently will start sending CTRL code DNU and at the same time stop using the payload area of member (a). The reduced the payload size of the VCG is distributed over the members sending the CTRL code NORM or EOS. From the time the CTRL code DNU would have arrived at the Sink side, the transported, reduced, payload of


97

the VCG is free of errors. This is indicated in Figure 5.6 by the start of the bold solid line of member (a). Because member (a) was the last member in sequence, the indication of EOS has to be taken over by the last but one member in the sequence; the member with SQ ¼ (n2) will change its CTRL code from NORM to EOS. A message reporting the failed member (a) is sent to the NMS. Because the sequence numbering is not changed, the temporary change of bandwidth does not have to be acknowledged by the RS-Ack bit toggle. Step 5 The network fault is repaired and the path termination function of member (a) will detect this and remove the MSU_L signal forwarded to the Sink side LCAS process. Step 6 The Sink side will now detect the CTRL code DNU sent by the Source side in Step 4 and send the status MST ¼ OK for member (a) to the Source side. The payload of member (a) will remain unused. Step 7 The Source side detects the MST ¼ OK of member (a) and consequently will start sending CTRL code EOS for member (a) and CTRL code NORM for the member with SQ ¼ (n 2). At the same time the payload area of member (a) is used again and the VCG can transport the full payload. This is indicated in Figure 5.6 by the end of the bold solid line for member (a). A message reporting the OK status of member (a) is sent to the NMS. (Note that if the failed channel is deleted through a planned decrease prior to the fault clearing, the Sink side will not be able to see the change in the failed member’s control packet. Also, the Sink side LCAS process will not be able to detect the change in the SQ numbers. As a result, the RS-Ack bit will not be toggled due to this planned decrease. The Source side LCAS process will have to rely on the RS-Ack timeout to get a confirmation of the decrease. The payload bandwidth of the VCG is not affected.) 5.3.3.3

Decrease due to degraded network performance

In case the path through the network is experiencing enough bit errors to degrade the service, this is detected at the path termination function

98


of each member. Because of the nature of the transported data signals, they are not affected necessarily by the bit errors. In this case, the affected payload is not discarded. The data layer shall deal with the affected payload. In this case, Steps 2 and 3 in the two examples in sections 5.3.3.1 and 5.3.3.2 can be replaced by: Step 2 A network degrade occurs affecting the path of member (a) in the VCG. This is detected by the path termination function of member (a) and is forwarded to the Sink side LCAS process by the Trail Signal Degraded (TSD) signal. Step 3 The Sink side LCAS process receives the TSD signal and immediately will change the status of member (a) to MST ¼ FAIL. The payload of member (a) will continue to be used to reconstruct the original VCG payload. For a certain time, i.e. the (propagation time from Sink side to Source side) þ (reaction time of the Source side) þ (propagation time from Source side to Sink side), the re-assembled payload will be erroneous because of the degraded member (a) payload. This is indicated by the bold dotted line of member (a) in the appropriate figure.

6 Generic framing procedure (GFP) Instead of a proliferation of data signal mapping methods, the ITU-T has defined GFP to provide a uniform methodology to be used for transporting data-related signals. GFP evolved from the earlier proposals for data transport over SDH/SONET, e.g. Packet over SONET (PoS), Ethernet over SONET (EoS) and Simple Data Link (SDL). GFP re-uses many aspects of the Asynchronous Transfer Mode (ATM). Compared to Link Access Protocol SDH (LAPS), GFP supports more client signals and transports them more efficiently. There are two flavours of GFP: frame-mapped GFP (GFP-F) is used for mapping packet oriented data, e.g. Ethernet, and transparent-mapped GFP (GFP-T) is used for streaming data, e.g. video. GFP can be used to map all these asynchronous or Variable Bit Rate (VBR) signals into a Constant Bit Rate (CBR) signal. The resulting CBR signal can be mapped in a container provided by SDH/SONET, e.g. a VC–n, VC–n–Xc or VC–n–Xv, an optical unit provided by OTN, e.g. an ODUk or ODUk– Xv and the payload area of (virtual concatenated) PDH signals. In fact the CBR signal can be transported by any synchronous transport system. This chapter explains the GFP frame formats and the GFP mapping methodology.


100


6.1 INTRODUCTION GFP as defined in ITU-T recommendation G.7041 is utilised to encapsulate the variable length payload of various client signals for subsequent transport over SDH and OTN networks. The definition includes: The frame formats of the Protocol Data Units (PDUs) transferred between the GFP Source and Sink termination points. The mapping procedure for the client signals into GFP PDUs. Figure 6.1 depicts the environment in which GFP operates in the current multiplex structure.

dark fiber

C/D-WDM

OTN

SDH/SONET

PDH

GFP ATM HDLC PDH PPP Fibre Channel

ESCON

FICON

Ethernet

IP, IPX, MPLS, etc.

Figure 6.1

SAN

The location of GFP in the multiplex structures

101

Generic Framing Procedure

The mapping procedure described for GFP can be applied to: The encapsulation and transport of entire client frames: GFP-F or frame mapped GFP, i.e. a single client PDU, for example, IP/PPP or Ethernet Media Access Control (MAC) frame, is mapped into a single GFP PDU. The mapping and transport of client data characters: GFP-T or transparent GFP, i.e. a number of client data characters, for example, Fibre Channel or ESCON/SBCON block codes, are mapped into efficient block codes for transport as a GFP PDU. Figure 6.2 illustrates the relationship between the higher-layer client signals, GFP, and the lower-layer server transport paths. Figure 6.3 shows a simplified functional model of the client layer to server layer adaptation using GFP mapping. More detailed examples of functional models containing the GFP mapping are given in Chapter 7. The Server/Client adaptation function using GFP-F mapping may operate at the data link layer (or a higher layer) of the client signal and requires Client PDU visibility. This visibility is obtained when the client PDUs are received from a bridge, switch or router function located in a transport network element (TNE), e.g. an SDH Add-Drop Multiplexer, or in a data network element (DNE), e.g. an IP router fabric. In the former case, the client PDUs are received via, for example, an Ethernet interface (physical port b in Figure 6.3).

Ethernet

other client signals

ESCON

GFP − Client specific aspects (payload dependent) GFP − common aspects (payload/mapping independent) GFP − Server specific aspects (mapping dependent) SDH VC-n path

Figure 6.2

any octetsynchronous path

OTN ODUk path

GFP relation to client signals and transport paths

102

Next Generation SDH/SONET Data Layer Network

EthP-DNE EthP-TNE GFP-T PHY

EthP-TNE GFP-F

GFP-F

GFP-F

GFP-F

GFP-T

PHY

PHY

A

B

C

C'

B'

PHY

A'

Sn / Sn-Xv / Sn-Xc 10baseT ESCON 100baseT FICON ..... ..... part b

Transport Layer Network

part a

ESCON 10baseT FICON 100baseT ..... ..... part a

Figure 6.3

part b

GFP functional models

The Server/Client adaptation function using GFP-T mapping operates on the client character stream, rather than on the incoming client PDUs. This requires processing of the incoming codeword space for the client signal (physical port a in Figure 6.3). Typically, interconnections can be set up between termination points A and A0 , B and B0 , C and C0 , B and C0 and C and B0 . Note that the type of physical port a must be the same to support an interconnection, while the type of physical port b may be different.

6.2 COMMON ASPECTS OF GFP FOR OCTET-ALIGNED PAYLOADS Two kinds of GFP frames are defined: GFP client frames and GFP control frames. Frame formats for GFP client and control frames are defined in clauses 6.1 and 6.2. GFP also supports a flexible (payload) header extension mechanism to facilitate the adaptation of GFP for use with diverse transport mechanisms. Currently defined payload extension header types are specified in clause 6.1.2.3.

6.2.1 Basic signal structure for GFP client frames The format for GFP frames is shown in Figure 6.4. GFP PDUs are octetaligned and consist of a GFP Core Header and, except for GFP Idle frames, a GFP Payload Area. The transmission order starts at bit 1 of octet 1 up to bit 8 of octet n.

103

Generic Framing Procedure 1 2 3 4 5 6 7 8 4

Core Header

4 - 65535

Payload Area

Figure 6.4

6.2.1.1

1 . . . . . . . n

GFP PDU and transmission order

GFP Core Header

The GFP Core Header format is shown in Figure 6.5. This header allows GFP frame delineation independent of the content of the higher layer PDUs. The four octets of the GFP Core Header consist of the following: a 16-bit PDU Length Indicator (PLI) field contains a binary number representing the number of octets in the GFP Payload Area. The absolute minimum value of the PLI field in a GFP client frame is 4 octets. PLI values 0–3 are reserved for GFP control frame usage (see Section 6.2.3). a 16-bit Core Header Error Check (cHEC) field contains a CRC-16 error control code that protects the integrity of the contents of the Core Header. The cHEC value is the remainder of the CRC-16 calculation over the four Core Header octets performed by the source adaptation process. The polynomial G(x) ¼ x16 þ x12 þ x5 þ 1

1 2 3 4 5 6 7 8 PLI

[15...8]

1

PLI

[7...0]

2

cHEC [15...8]

3

cHEC [7...0]

4

Figure 6.5

GFP Core Header format

104


is used. The process uses the following steps (see ITU-T Recommendation V.41, Appendix I): (1) The first two octets of the GFP Core Header are taken in network octet order, to form a 16-bit sequence representing the coefficients of a polynomial M(x) of degree 15. (2) M(x) is multiplied by x16 and divided (modulo 2) by G(x), producing a remainder R(x) of degree 15 or less. (3) The coefficients of R(x) are considered to be a 16-bit sequence, where x15 is the most significant bit. This is the CRC-16, the first bit transmitted is the coefficient of x15 and the last bit transmitted is the coefficient of x0. The sink adaptation process performs the same CRC-16 calculation. In the absence of bit errors, the remainder will be zero. A single error in the Core Header can be corrected. A Core Header with multi-bit errors will be recorded for performance monitoring purposes. The associated GFP PDU will be discarded. The Core Header is scrambled to improve the robustness of the GFP frame delineation procedure and to provide a sufficient number of 0 ! 1 and 1 ! 0 transitions for DC balancing. The scrambler performs a modulo 2 addition with the hexadecimal number 0xB6AB31E0. This number is the maximum transition, minimum side-lobe, Barker-like sequence of length 32. 6.2.1.2

GFP Payload Area

All octets in the GFP frame after the GFP Core Header are considered the GFP Payload Area. The GFP Payload Area is used to transport the client specific protocol information. This variable length area may include from 4 to 65 535 octets. As shown in Figure 6.6, the GFP 1 2 3 4 5 6 7 8 4 - 64 (X)

0 - 65535 -X 4

Payload Header Payload Information Field Payload FCS (optional)

1 . . . . . . . n

Figure 6.6 GFP Payload Area format

105


1 2 3 4 5 6 7 8 2

Type

2

tHEC

0 - 60

2 Figure 6.7

Extension Header Field eHEC

1 . . . . . . . . n

GFP Payload Header format

Payload Area consists of two common components: a Payload Header and a Payload Information field. An optional Payload FCS (pFCS) field is also supported. GFP Payload Header The Payload Header is a variable-length area, 4 to 64 octets long, intended to support data link management procedures specific to the client signal. The structure of the GFP Payload Header is illustrated in Figure 6.7. The area contains two mandatory fields, the Type and the tHEC fields, and a variable number of additional payload header fields. This group of additional payload header fields is referred to as the Extension Header. The presence of the Extension Header, its format, and the presence of the optional Payload FCS are specified by the Type field. The tHEC protects the integrity of the Type field. GFP Type field The GFP Type field is a mandatory two-octet field in the Payload Header indicating the content and the format of the GFP Payload Information field. The Type field distinguishes between GFP frame types and between different services in a multi-service environment. As shown in Figure 6.8, the Type field consists of: the Payload Type Identifier (PTI). A 3-bit field identifying the type of GFP client frame. Currently, two kinds of client frames are defined: User Data frames (PTI ¼ 000) and Client Management frames (PTI ¼ 100).

106


PTI

PFI

1 2 3 4 5 6 7 8

UPI Figure 6.8

EXI

5 6

GFP Type Field format

the Payload FCS Indicator (PFI). A single bit indicating the presence (PFI ¼ 1) or absence (PFI ¼ 0) of the Payload FCS field. the Extension Header Identifier (EXI). A 4-bit field identifying the type of Extension Header GFP. Currently, three kinds of Extension Headers are defined: a Null Extension Header (¼ 0000), a Linear Extension Header (¼ 0001), and a Ring Extension Header (¼ 0010). the User Payload Identifier (UPI). An 8-bit field identifying the type of payload conveyed in the GFP Payload Information field. Interpretation of the UPI field is relative to the type of GFP client frame as indicated by the PTI subfield. UPI values for client data frames are specified in Section 6.2.2.1 and UPI values for Client Management frames are specified in Section 6.2.2.2. Type HEC (tHEC) field The two-octet Type Header Error Control field contains a CRC-16 error control code that protects the integrity of the contents of the Type Field by enabling both single-bit error correction and multi-bit error detection. The tHEC value is the remainder of the CRC-16 calculation over the two Type Field octets performed by the source adaptation process. The polynomial G(x) ¼ x16 þ x12 þ x5 þ 1 is used. The process uses the following steps: (1) The first two octets of the GFP Type Field are taken in network octet order, to form a 16-bit sequence representing the coefficients of a polynomial M(x) of degree 15. (2) M(x) is multiplied by x16 and divided (modulo 2) by G(x), producing a remainder R(x) of degree 15 or less. (3) The coefficients of R(x) are considered to be a 16-bit sequence, where x15 is the most significant bit. This is the CRC-16, the first bit transmitted is the coefficient of x15 and the last bit transmitted is the coefficient of x0. The GFP sink adaptation process applies the same CRC-16 calculation and will perform single-bit error correction on the Type field. A

107


Type field with multi-bit errors will be recorded for performance monitoring purposes. The associated GFP PDU will be discarded. GFP Extension Headers The payload Extension Header is a 0-to-60 octet field (including the eHEC) that supports technology specific data link headers such as virtual link identifiers, source and destination addresses, port numbers, Class of Service, etc. The type of extension header is indicated by the content of the EXI bits in the Type Field of the payload header, i.e.: the Null Extension Header applies to a logical point-to-point configuration. It is intended for scenarios where the transport path is dedicated to one client signal. As the name implies, only the Type field and tHEC field are present. the Linear Extension Header is intended for scenarios where there are several independent links requiring aggregation onto a single transport path. The Payload Header for a Linear (Point-to-Point) frame with an Extension Header is shown in Figure 6.9. Apart from the Type field and the tHEC field, it contains a Channel Identification (CID) field, an 8-bit binary number used to indicate one of the 256 communications channels at the GFP termination points, an 8bit Spare field reserved for future use and a two-octet eHEC field. the Ring Extension Header is for further study. Extension HEC (eHEC) field A two-octet Extension Header Error Control (eHEC) field contains a CRC-16 error control code that protects the integrity of the contents of the Extension header. The 1 2 3 4 5 6 7 8 Type

[15...8] [7...0]

tHEC [15...8] [7...0]

[7...0] CID Spare [7...0]

eHEC [15...8] [7...0]

Figure 6.9

5 6 7 8 9 10 11 12

Linear PDU Payload Header

108


eHEC value is the remainder of the CRC-16 calculation over all the Extension Header octets performed by the source adaptation process. The polynomial G(x) ¼ x16 þ x12 þ x5 þ 1 is used. The process uses the following steps: (1) All octets of the GFP Extension Header, except the eHEC octets, are taken in network octet order, to form a n-bit sequence representing the coefficients of a polynomial M(x) of degree (n 1). (2) M(x) is multiplied by x16 and divided (modulo 2) by G(x), producing a remainder R(x) of degree 15 or less. (3) The coefficients of R(x) are considered to be a 16-bit sequence, where x15 is the most significant bit. This is the CRC-16, the first bit transmitted is the coefficient of x15 and the last bit transmitted is the coefficient of x0. The sink adaptation process performs the same CRC-16 calculation. In the absence of bit errors, the remainder will be zero. Optionally, a single error in the Extension Header can be corrected. An Extension Header with multi-bit errors will be recorded for performance monitoring purposes. The associated GFP PDU will be discarded. Payload Information field The Payload Information field contains the client PDU for frame mapped GFP or a group of client signal characters for transparent mapped GFP. This variable length field may include from 0 to 65 535-X octets, where X is the size of the Payload Header. The client PDU/ signal is always mapped octet-aligned into the GFP Payload Information field. Payload FCS field The Payload Information field may include an optional GFP Payload FCS field, a four-octet frame check sequence. It contains a CRC-32 error control code that protects the contents of the GFP Payload Information field. The GFP Payload FCS value is the remainder of the CRC-32 calculation over all the Payload Information octets performed by the source adaptation process. The polynomial G(x) ¼ x32 þ x26 þ x23 þ x22 þ x16 þ x12 þ x11 þ x10 þ x8 þ x7 þ x5 þ x4 þ x2þ x1 þ 1 is used. The process uses the following steps: (1) All octets of the GFP Payload Information field, except the FCS octets, are taken in network octet order, to form an n-bit sequence representing the coefficients of a polynomial M(x) of degree (n 1).


109

(2) M(x) is multiplied by x32, added to the all-ones polynomial U(x) ¼ 1 þ x1 þ x2 þ . . . þ x31, and divided (modulo 2) by G(x), producing a remainder R(x) of degree 31 or less. (3) The coefficients of R(x) are considered to be a 32-bit sequence, where x31 is the most significant bit. The complement of this 32-bit sequence is the CRC-32. The sink adaptation process performs the same CRC-32 calculation. A Payload Information field with bit errors will be recorded for performance monitoring purposes. Payload area scrambling The GFP Payload Area is scrambled to prevent payload information replicating the server layer scrambling word (or its inverse). All octets in the GFP Payload Area are scrambled using a 1 þ x43 self-synchronous scrambler. In the adaptation process, the (de)scrambler is enabled starting at the first bit of the first octet transmitted after the cHEC field, and is disabled after the last bit of the last octet of the GFP frame is transmitted. When the (de)scrambler is disabled its content is retained. 6.2.1.3

Detailed GFP-F frame format

Figure 6.10 shows the detailed format of the GFP-F PDU; shading indicates optional fields. The maximum value of m is 4 þ 65 536 octets, i.e. four Core Header octets and 216 octets determined by the 16 bit Length indication in the Core Header.

6.2.2 GFP client frames Currently, two types of GFP client frames are defined: Client Data frames and Client Management frames. 6.2.2.1

GFP Client Data Frames

GFP Client Data Frames (CDF) are used to transport data from the client signal. These frames consist of a Core Header and a Payload Area. The Type field of a CDF uses the following Type subfield values: PTI ¼ 000; PFI ¼ Payload specific, set as required (FCS enabled or disabled);

110

Next Generation SDH/SONET 1 2 3 4 5 6 7 8

Extension Header (optional)

2

Length

2

cHEC

2

PTI PFI EXI UPI

2

tHEC

0 - 58

0/2

n

GFP FCS (optional)

0/4

Extension Header

eHEC

Payload area

p FCS

Figure 6.10

1 2 3 4 5 6 7 8 . . . . . . . . . . . . . . . . m

GFP Core Header

Payload Header

Client Payload

GFP PDU

EXI ¼ Payload specific, set consistently with the frame multiplexing and topology requirements for the GFP connection; UPI ¼ Payload specific, set according to the transported client signal type. Defined UPI values for client data frames are given Table 6.1. 6.2.2.2

GFP Client Management Frames

GFP Client Management Frames (CMF) are used to transport information associated with the management of the client signal or the GFP connection. They provide a generic mechanism for the GFP client specific source adaptation process optionally to send management information to the GFP client specific sink adaptation process. The CMF consists of a Core Header and a Payload Area. The Type field of the CMF uses the following Type subfield values:

111

Generic Framing Procedure Table 6.1

User Payload Identifiers for GFP Client Frames

UPI (hex)

PTI ¼ 000 GFP Frame Payload Area

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E through 0xEF 0xF0 through 0xFE 0xFF

Reserved and not available Frame-Mapped Ethernet Frame-Mapped PPP Transparent Fibre Channel Transparent FICON Transparent ESCON Transparent Gb Ethernet Reserved for future Frame-Mapped Multiple Access Protocol over SDH Transparent DVB ASI Frame-Mapped IEEE 802.17 Resilient Packet Ring Frame-Mapped Fibre Channel FC-BBW Asynchronous Transparent Fibre Channel Frame Mapped MPLS Reserved for future standardisation Reserved for proprietary use Reserved and not available

PTI ¼ 100; PFI ¼ Payload specific, set as required (FCS enabled or disabled. (The use of FCS in the CMF reduces the amount of spare bandwidth that can be used for such frames); EXI ¼ Payload specific. The use of an Extension Header in the CMF will reduce significantly the amount of spare bandwidth that can be used for such frames); UPI ¼ Payload specific, defines the use of the CMF payload. In this way the CMF may be used for multiple purposes. Table 6.2 defines the CMF payload uses. An example CMF is provided in Section 6.6.3. Table 6.2

GFP Client Management frame User Payload Identifier PTI ¼ 100

UPI value (hex)

Usage

0x00 0x01 0x02 0x03 through 0xFE 0xFF

Reserved and not available Client Signal Fail (Loss of Client Signal) Client Signal Fail (Loss of Character Synchronisation) Reserved for future use Reserved and not available

112

Next Generation SDH/SONET scrambled

1 2 3 4 5 6 7 8 0x00

1

0xB6

0x00

2

0xAB

0x00

3

0x31

0x00

4

0xE0

Figure 6.11 GFP Idle frame format

6.2.3 GFP control frames GFP control frames are used in the management of the GFP connection. The only control frame specified at this time is the GFP Idle frame. The GFP Idle frame is a special four-octet GFP control frame consisting of only a GFP Core Header with the PLI and cHEC fields set to 0, and no Payload Area. The Idle frame is used to maintain a constant bit-rate when no client PDUs are available. The GFP Idle frame format is shown in Figure 6.11, with the values in the dashed frame indicating the values after the Barker-like scrambling has been performed. Control frames with PLI ¼ 1, 2, or 3 are for further study.

6.2.4 GFP frame-level functions This section describes the frame-level processes common to all payloads that are framed via GFP-F and GFP-T. Processes specific to particular payloads are discussed in Section 6.3 for GFP-F PDUs and Section 6.4 for GFP-T PDUs. 6.2.4.1

GFP frame delineation process

GFP frame delineation is based on the content of the GFP Core Header. It uses the correlation between the first two octets of the GFP frame, i.e. the PLI, and the following two-octet cHEC. Figure 6.12 shows the state diagram for the GFP frame delineation process. The state diagram works as follows: In the HUNT state, the GFP process searches octet by octet for a faultless PLI and cHEC combination in the Core Header. In this state, the error correction is disabled. Once a correct PLI/cHEC is

113

Generic Framing Procedure octet by octet

PDU by PDU

(error correction disabled)

(error correction disabled)

correct cHEC HUNT

Pre-SYNC incorrect cHEC

incorrect cHEC

correct cHEC

(multiple bit errors)

SYNC

PDU by PDU (error correction enabled)

Figure 6.12

GFP frame delineation

detected in the candidate Core Header, a candidate GFP PDU is identified and the delineation process enters the Pre-SYNC state. In the Pre-SYNC state, the GFP process checks PDU by PDU, for a correct PLI/cHEC match in the candidate Core Header of the next GFP PDU. The PLI field in the Core Header of the preceding GFP PDU is used to find the beginning of the next candidate GFP PDU. Single error correction remains disabled while in this state. If an incorrect PLI/cHEC is detected, the process returns to the HUNT state. In the SYNC state, the GFP process checks for a correct PLI/cHEC match on the next candidate GFP PDU. The PLI field in the Core Header of the preceding GFP PDU is used to find the beginning of the next candidate GFP PDU. In this state, single-bit Core Header error correction is enabled. Whenever multiple bit errors are detected in the PLI/cHEC, a GFP Loss of Frame Delineation defect is declared and the delineation process returns to the HUNT state. A client Server Signal Failure (SSF) is forwarded to the client adaptation process. Idle GFP frames also participate in the delineation process and are then discarded.

114

6.2.4.2


GFP Frame multiplexing

GFP PDUs from multiple ports and multiple client types can be multiplexed on a PDU-by-PDU basis in a single stream. When there are no client GFP PDUs available for transmission, GFP Idle frames will be inserted to provide a continuous stream of GFP PDUs for mapping into an octet aligned physical layer.

6.3 CLIENT SPECIFIC ASPECTS FOR FRAME-MAPPED GFP This section describes the client specific aspects of the generic encapsulation using a frame-by-frame mapping of the client PDUs into GFP.

6.3.1 Ethernet MAC payload The format of Ethernet MAC frames is defined in IEEE 802.3, section 3.1. There is a one-to-one mapping between a client PDU and a GFP PDU. The relationship between Ethernet MAC PDUs and GFP PDUs is illustrated in Figure 6.13. The Ethernet MAC octets from Destination Address through Frame Check Sequence, inclusive, are placed in the GFP Payload Information field. Specifically, on an octet-by-octet basis, bits 0 and 7 in IEEE 802.3 part 3 correspond to bits 8 and 1, respectively, in the GFP specification.

6.3.2 IP/PPP payload IP/PPP payloads are first encapsulated in an HDLC-like frame. The format of a PPP frame is defined in the IETF RFC 1661, section 2. The format of the HDLC-like frame is defined in RFC 1662, section 3. Unlike RFC 1662, no octet stuffing procedure is performed on flag or control escape characters. There is a one-to-one mapping between a higher-layer PPP/HDLC PDU and a GFP PDU. The relationship between PPP/HDLC frame and the GFP frame is illustrated in Figure 6.14. All octets from the PPP/HDLC frame, including any optional PPP Information field padding, are placed in the Payload Information field of a GFP frame. Bits 0 and 7 of the PPP/HDLC byte (see ISO/IEC 3309) correspond to bits 8 and 1 of the GFP payload byte, respectively. PPP payload configuration procedures are client-specific and transparent to the GFP process.

115

Generic Framing Procedure GFP PDU

Ethernet PDU octets

Preamble

Start of Frame Delimiter

7

1

2

PLI

2

cHEC

2

PTI PFI EXI UPI

2

tHEC

0-60

PTI = 000 PFI = 0 UPI = 0x01

GFP Extension Hdr.

Destination Address (DA) 6

Source Address (SA)

Length / Type

6

2

GFP Payload Information

MAC client data (Pad)

MAC FCS 7 6 5 4 3 2 1 0

4 1 2 3 4 5 6 7 8

Figure 6.13 Ethernet PDU to GFP PDU relationship

6.3.3 RPR payload There is a one-to-one mapping between an RPR frame and a GFP PDU. The format of the RPR frames is defined in IEEE 802.17, section 8. The relationship between an RPR frame and a GFP frame is shown in Figure 6.15. All of the RPR frame octets are placed in the GFP Payload Information field. The default is no header extension and the pFCS field is not used (PFI ¼ 0). Octet-alignment is maintained and bit identification within octets is maintained. Specifically, on an octetby-octet basis, bits LSB and MSB in IEEE 802.17 Clause 8 and Annex C correspond to bits 8 and 1, respectively. A complete definition of this encapsulation is contained in IEEE 802.17, Annex C.

GFP PDU

PPP/HDLCPDU octets

Flag Address Control

PPP protocol ID

1 1 1 2

2

PLI

2

cHEC

2

PTI PFI EXI UPI

2

tHEC

0-60

PTI = 000 PFI = 0 UPI = 0x02

GFP Extension Hdr.


PPP client data (Pad)

HDLC FCS

4

7 6 5 4 3 2 1 0

Figure 6.14

1 2 3 4 5 6 7 8

PPP/HDLC PDU to GFP relationship

GFP PDU

RPR PDU octets

MSB . . . . . . LSB PHY support

N

RPR FCS

4

Figure 6.15

PLI

2

cHEC

2

PTI PFI EXI UPI

2

tHEC

0(-60)

RPR frame

7 6 5 4 3 2 1 0

2

GFP Extension Hdr.


1 2 3 4 5 6 7 8 RPR PDU to GFP PDU relationship

PTI = 000 PFI = 0 EXI = 0 UPI = 0x0A

117


6.3.4 Fibre Channel payload via FC-BBW The format of a Fibre Channel Broadband-2 for SONET (FC-BBW) PDU is defined in ANSI INCITS 342-2001 (FC-BB), section 6. All octets in the FC-BBW PDU starting from the LLC/SNAP Header to the BBW Message Payload, inclusive, are placed in the Payload Information field of a GFP PDU. The relationship between an FC-BBW PDU and a GFP PDU is illustrated in Figure 6.16.

6.3.5 Direct mapping of MPLS The MPLS PDU frame contains one or more MPLS-specific label stack entries (as specified in RFC 3032) and a MPLS payload information field. All octets of the MPLS PDU are placed in the Payload Information field of a GFP-F frame. Both octet-alignment and bit identification

GFP PDU

FC-BBW_SONET PDU octets

2

PLI

2

cHEC

2

PTI PFI EXI UPI

2

tHEC

0-60

LLC / SNAP Header

8

BBW Header

4

BBW Message Payload

GFP Extension Hdr.


0-2148

7 6 5 4 3 2 1 0

Figure 6.16

PTI = 000 PFI = 0 UPI = 0x0B

7 6 5 4 3 2 1 0

FC-BBW_SONET PDU to GFP PDU relationship

118


GFP PDU

MPLS PDU octets

2

PLI

2

cHEC

2

PTI PFI EXI UPI

2

tHEC

0-60 Label stack entry

Nx4 (N > 0)

GFP Extension Hdr.


Label stack entry

MPLS payload

PTI = 000 PFI = 1 UPI = 0x0D

N packets

7 6 5 4 3 2 1 0 4

pFCS

1 2 3 4 5 6 7 8 Figure 6.17

MPLS PDU to GFP PDU relationship

within octets are maintained within the GFP-F PDU. The GFP Payload FCS is required and is computed as specified in on page . . . and inserted in the pFCS field. The PFI field is set to 1. This relationship between MPLS PDU and GFP-F PDU is depicted in Figure 6.17.

6.3.6 Error handling in frame-mapped GFP On ingress, received client PDUs detected in error by the client source adaptation process will be discarded. Client PDUs detected in error while transferred by the client source adaptation process will be padded up with an ‘all ones’ bit sequence. If the Payload FCS is present, all its 32-bits are complemented. These actions ensure that the client sink adaptation process, or the client termination process, will drop the errored PDU.

119


6.4 CLIENT SPECIFIC ASPECTS FOR TRANSPARENTMAPPED GFP Transparent mapping of 8B/10B payloads into GFP is intended to facilitate the transport of 8B/10B block-coded client signals for applications that require very low transmission latency, e.g. Fibre Channel, ESCON, FICON, and Gigabit Ethernet. Rather than buffering a client PDU and mapping it in a GFP frame, the individual characters of the client signal are recovered from the client block codes and mapped into periodic, fixed-length GFP frames. The mapping occurs regardless of whether the client character is a data or a control character, which thus preserves the client 8B/10B control codes.

6.4.1 Common aspects of GFP-T The GFP-T frame uses the same frame structure as the GFP-F frame. The Payload FCS is again optional. 6.4.1.1

Adapting 8B/10B client signals via 64B/65B block codes

The first step in the client adaptation process is decoding the physical layer of the client signal. Each received 10-bit character of the 8B/10B line code is decoded into its original 8-bit data character, or into one of the twelve original control codewords. All decoded 8B/10B characters and codewords are then mapped into a 64-bit/65-bit (64B/65B) block code. The structure of the 64B/65B block code is shown in Figure 6.18. 8B/10B line code 8 octet = 64B block 64B/65B block flag 8 x 64B/65B block

CRC-16

GFP (536,520) Superblock GFP PDU

N x (536,520) Superblocks GFP Payload Header GFP FCS (optional) GFP Core Header

Figure 6.18

8B/10B to GFP-T PDU relationship

120


The leading bit of the 65-bit block, the Flag bit, indicates whether that block contains only 8-bit data characters (flag ¼ 0) or whether coded control codewords are also present in that block (flag ¼ 1). In the demapper, the 8-bit data and control codewords are recovered from the 64B/65B blocks and then encoded into the original 8B/10B data codewords. The following special 64B/65B codes are used: 10B_ERR code Certain client signal defects may produce 8B/10B codewords on ingress to the GFP source adaptation process that cannot be recognised. A special 64B/65B control character, the 10B_ERR code, is provided to convey such ‘unrecognised 8B/10B codeword’ client signal defects. When reconstructing the client signal on egress from the transport network, it is recommended that received 10B_ERR codes typically be re-coded by the demapper into an invalid transmission character. 65B_PAD code To maintain a constant bit-rate when no client characters are available, a 65B_PAD padding character is inserted. The pad character is mapped into the GFP frame in the same manner as a control character and is recognised and removed by the GFP demapper. 6.4.1.2

Adapting 64B/65B code blocks into GFP

To preserve the octet alignment of the GFP-T frame with the transport SDH/ODUk container, eight 64B/65B codes are grouped into a GFP (536, 520) superblock as shown in Figure 6.18. The flag bits of each of the eight 64B/65B codes are grouped together into the first trailing octet. The last two trailing octets are used for a CRC-16 error check over the bits of this superblock. Assuming a Null Extension header and no Payload FCS, the resulting GFP frame is [(4 8) þ (4 8) þ (N ((65 8) þ 16))] bits long, where N is the number of superblocks in the GFP frame. The minimum value of N depends on the data rate of the client signal, the size of the GFP Header and the size of the payload container. GFP-T superblock CRC A CRC-16 error control code protects the integrity of the contents of the superblock. It is the remainder of the CRC-16 calculation over the 536 bits in that superblock performed by the source adaptation process. The polynomial G(x) ¼ x16 þ x15 þ x12 þ x10 þ x4 þ x3 þ


121

x2 þ x þ 1 is used. The sink adaptation process performs the same CRC-16 calculation. In the absence of bit errors, the remainder will be zero. If the sink adaptation process detects an error, it will output either a 10B error character or an unrecognized 10B character in place of all of the client characters contained in the processed superblock. This replacement guarantees that the client receiver will be able to detect the presence of the error. The superblock CRC is generated by the source adaptation process using the following steps: (1) The first 65 octets of a superblock are taken in network octet order (see Figure 6.18), to form a 520-bit sequence that represents the coefficients of a polynomial M(x) of degree 519. (2) M(x) is multiplied by x16 and divided (modulo 2) by G(x), producing a remainder R(x) of degree 15 or less. (3) The coefficients of R(x) are considered to be a 16-bit sequence, where x15 is the most significant bit. This 16-bit sequence is the CRC-16. (Note that with this CRC-16, it is possible to correct single bit errors. However, since the signal is scrambled at the Source and de-scrambled at the Sink, the CRC-16 error correction circuit should account for single bit errors as well as double errors spaced 43 bits apart coming out of the descrambler.) The sink adaptation process performs steps 1–3 in the same manner as the source adaptation process. In the absence of bit errors, the remainder shall be 0000 0000 0000 0000.

6.4.2 Client-specific signal fail aspects When GFP-T mapping detects a client signal failure at ingress, it may send Client Signal Fail (CSF). GFP-T CSF conditions include at least a loss of 8B/10B synchronisation and, in some cases, loss-of-signal or loss-of-clock. Server layer failures that occur in the GFP process itself, in the 64B/65B adaptation process, or in the transport network, may induce a CSF indication to the client adaptation process.

6.5 SERVER SPECIFIC ASPECTS OF GFP The server specific aspects of GFP are related to the mapping process. The mapping of the framed payloads into an SDH VC-n is specified in

122


ITU-T Recommendation G.707. The mapping of the framed payloads into an OTN ODUk payload is specified in ITU-T Recommendation G.709. The mapping of the framed payloads into PDH signals payload is specified in ITU-T Recommendation G.8040. When LCAS is used in the server layer, the GFP frame rate has to be adapted to the available bandwidth as indicated by the signal XA (i.e. the number of active members in a VCG) received from the server layer. The client layer or client layer specific processing should implement the appropriate measures (e.g. traffic policing, traffic shaping) to adjust the client payload accordingly.

6.6 GFP PDU EXAMPLES This section provides an example of a GFP-F PDU illustrating the transmission order and CRC calculation. The processes performed to transport a client PDU are: Transmit: Client data ! GFP source encapsulation ! scramble and DC_balance ! SDH Receive: SDH ! un_DC_balance and unscramble ! GFP sink decapsulation ! client data

6.6.1 GFP-F PDU The following example shows the encapsulation of a 64-byte Ethernet frame with linear header and GFP Payload FCS, before DC balancing and self-synchronous scrambling.1,2

1

The Ethernet data octet bit numbering is different from the GFP bit numbering, i.e., the (LSB) bit 0 in IEEE 802.3 part 3 corresponds to GFP octet bit 8, and the (MSB) bit 7 corresponds to GFP octet bit 1. In the hex values given in this example the MSB is the leftmost bit and the LSB rightmost bit. 2 In this example the GFP payload FCS is shown for illustration only. Normally Ethernet PDU mapping is performed without GFP FCS. Be aware that the Ethernet FCS calculation is different from the GFP FCS calculation.

Generic Framing Procedure Byte 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

Field PLI [15. . .8]

123

Value Comment 0x00 PLI ¼ Length: GFP Payload Header þ GFP Payload Information Field þ GFP Payload PLI [7. . .0] 0x2E FCS ¼ 8 þ 34 þ 4 ¼ 46 bytes cHEC [15. . .8] 0xC5 cHEC calculated over PLI cHEC [7. . .0] 0xAC PTI [15. . .13] ¼ ‘000’ (client data) Type [15. . .8] 0x11 PFI [12] ¼ ‘1’ (GFP Payload FCS enabled) EXI [11. . .8] ¼ ‘0001’ (linear header) Type [7. . .0] 0x01 UPI [7. . .0] ¼ 0x01 (Ethernet) tHEC [15. . .8] 0x20 tHEC calculated over Type tHEC [7. . .0] 0x63 EHDR [15. . .8] 0x80 CID [7. . .0] ¼ 0x80 (the value is an example) EHDR [7. . .0] 0x00 SPARE [7. . .0] ¼ 0x00 eHEC [15. . .8] 0x1B eHEC calculated over CID, SPARE eHEC [7. . .0] 0x98 DATA 0xFF 1 Ethernet Destination Address DATA 0xFF 2 DA ¼ 0xFFFFFFFFFFFF DATA 0xFF 3 DATA 0xFF 4 DATA 0xFF 5 DATA 0xFF 6 DATA 0x41 7 Ethernet Source Address DATA 0x6C 8 SA ¼ 0x416C6D657265 DATA 0x6D 9 DATA 0x65 10 DATA 0x72 11 DATA 0x65 12 DATA 0x00 13 Ethernet TYPE / LENGTH DATA 0x10 14 DATA 0x41 15 Ethernet payload DATA 0x73 16 DATA 0x74 17 DATA 0x65 18 DATA 0x72 19 DATA 0x69 20 DATA 0x78 21 DATA 0x20 22 DATA 0x26 23 DATA 0x20 24 DATA 0x4F 25 DATA 0x62 26 DATA 0x65 27 DATA 0x6C 28 DATA 0x69 29 DATA 0x78 30 DATA 0x9F 31 Ethernet FCS computed over 30 bytes. DATA 0xA5 32

124 45 46 47 48 49 50

Next Generation SDH/SONET DATA DATA FCS [31. . .24] FCS [23. . .16] FCS [15. . .8] FCS [7. . .0]

0xB2 0xDD 0x01 0xA9 0x10 0xC8

33 34 GFP payload FCS (optional) covers only the Payload (in this case Ethernet PDU) Information Field, i.e. 34 bytes

6.6.2 GFP-T PDU A GFP-T PDU only differs from a GFP-F PDU with respect to the mapped payload and so the following example only shows a superblock with its calculated CRC. Byte Field

Value

Comment

1 2 3 4 ... 62 63

Data Data Data Data

0x80 0x00 0x00 all 0x00

1st octet of 1st 64B/65B codeblock 2nd octet of 1st 64B/65B codeblock 3rd octet of 1st 64B/65B codeblock octets of codeblocks

Data

0x00

7th octet of 8th 64B/65B codeblock

64 65 66 67

Data Flags CRC [15. . .8] CRC [7. . .0]

0x00 0x00 0x9A 0xA2

8th octet of 8th 64B/65B codeblock Leading Flags of 1st to 8th 64B/65B codeblock GFP (536,520) superblock CRC [16. . .0]

6.6.3 GPT CMF PDU The following example shows the GFP Client Management Frame for transferring a detected Client Loss of Signal from the ingress to the egress. This is the minimum size to affect the spare bandwidth the least. Byte

Field

Value

1 2 3 4

PLI [15. . .8] PLI [7. . .0] cHEC [15. . .8] cHEC [7. . .0]

0x00 0x08 0x00 0x38

5

Type [15. . .8]

0x80

6 7 8

Type [7. . .0] tHEC [15. . .8] tHEC [7. . .0]

0x01 0x00 0xB1

Comment PLI ¼ Length: GFP Payload Header ¼ 8 octets cHEC calculated over PLI PTI [15. . .13] ¼ ‘100’ (client data) PFI [12] ¼ ‘0’ (GFP Payload FCS disabled) EXI [11. . .8] ¼ ‘0000’ (Null extension header) UPI [7. . .0] ¼ 0x01 (Loss Of client Signal) tHEC calculated over Type

7 Functional models for LCAS and GFP The atomic building blocks ITU-T recommendations G.803 and G.805 and ETSI standard EN 400 317 specify a library of basic building blocks and a set of rules by which they may be combined in order to describe digital transmission equipment (e.g. in ITU-T recommendation G.783 and G.798). The specification method is based on functional decomposition of the equipment into atomic and compound functions. This chapter describes the functional models and the decompositions of the virtual concatenation compound function, the virtual to contiguous concatenation interworking compound functions and the LCAS enabled virtual concatenated compound functions. Only the Trail Termination functions and adaptation functions are described that have a relation with the concatenation process. Since Chapter 6 includes a description of GFP, this chapter also contains some examples of equipment specifications that feature the adaptation functions where GFP is used in the mapping process. Only a brief description of the atomic functions is provided. The functional models described in this chapter are for information only, but complete the description of the concatenation and mapping process.

7.1 VIRTUAL CONCATENATION FUNCTIONS The Virtual Concatenated Trail Termination function generally referred to as Sn–Xv_TT is a compound function. This means that it is composed Next Generation SDH/SONET: Evolution or Revolution? Huub van Helvoort # 2005 John Wiley & Sons, Ltd ISBN: 0-470-09120-7

126


of the Sn–X Trail Termination function Sn–X_TT, the Sn–Xv to Sn–X adaptation function Sn–Xv/Sn–X_A and the X separate member Sn Trail Termination functions Sn_TT. The Source side Sn–Xv/Sn–X_So_A function takes care that the contiguous signal Sn–Xc received from the Sn–X_TT function will be distributed and output as the signals Sn of the X individual Sn_TT functions. In the opposite direction, the Sink side Sn–Xv/Sn–X_Sk_A function composes—from the signals received from the X individual Sn_TT functions—the original contiguous signal Sn–Xc output to and terminated by the Sn–X_TT function.

7.1.1 Sn–Xv Trail Termination function Note that this Trail Termination function does not support LCAS (or LCAS is disabled). The LCAS capable function is described in Section 7.3. The client payload signal that will be adapted for the transport through the network, in functional model terminology the SN–X_AI (Adapted Information) that passes the Sn–X_AP (Access point), is distributed over the X individual member signals SN_CI (Characteristic Information) passing the Sn_CP (Connection Point). The operation of the functions is provided in the next sections of this chapter. The bidirectional VCAT Trail Termination function Sn–Xv_TT and its decomposition are shown in Figure 7.1.

7.1.2 Sn–Xv/Sn–X adaptation function This is the function that performs the adaptation of the (contiguous concatenated) client signal to the (virtual concatenated) server layer signals transported by the members of the VCG. Figure 7.2 shows the bi-directional functional model. Bi-directional model: Sn–Xv/Sn–X_So_A This model can be further decomposed into the uni-directional models depicted in Figures 7.3 and 7.4. Source side: Sn–Xv/Sn–X_So_A The Source side VCAT adaptation function performs the distribution of the incoming contiguous concatenated signal Sn–Xc received at the Connection Point as Sn–X_CI_D to form the virtual concatenated signal Sn–Xv transmitted at the Access Point as Sn–Xv_AI_D. This signal

127

Functional models for LCAS and GFP Sn-X_AI

Sn-X_AI

Sn-X_AP

Sn-X_AP

Sn-X

Sn-X_CI

Sn-X_CP

Sn-Xv Sn-Xv/Sn-X

Sn-Xv_AI = Sn_AI[1...X] Sn

1.......X

Sn_CP

Sn

1 . . . . . . . . . X

Sn_CP

Sn_CI

Sn_CI

Sn-Xv_CI = Sn_CI[1...X]

Sn_AP

Figure 7.1 Decomposition of the Sn-Xv trail termination function

is the equivalent of the combined payload of the X individual member signals Sn transmitted as Sn_AI_D over the member Access Points. X can have any value 1 X (max) where (max) is technology specific, e.g. 256 for a VC–4. The input and output signals of this function are: At the Connection Point Sn–X_CI_D Data Sn–X_CI_CK I Clock Sn–X_CI_FS Frame Start

At the Access Sn_AI[1. . .X]_D Sn_AI[1. . .X]_CK O Sn_AI[1. . .X]_FS

Point Data Clock Frame Start

The VCAT specific multi-framing and sequencing processes are described in Chapter 2. The SQ numbers will start at 0 and the maximum assigned value will be (X–1). CP MP

Sn-Xv/Sn-X

1

Figure 7.2

. . . . . . . X

AP

Bi-directional Sn-Xv/Sn-X adaptation model

128

Next Generation SDH/SONET Sn-X_CI Sn-X_CP Sn-Xv/Sn-X 1

. . . . . . . X

Sn_AP

Sn-Xv_AI = Sn_AI[1...X]

Figure 7.3

Source side adaptation function

Sink side: Sn–Xv/Sn–X_So_A The sink side VCAT adaptation function performs the reconstruction of the contiguous concatenated signal Sn–Xc transmitted at the Connection Point as Sn–X_CI_D from the virtual concatenated signal Sn–Xv received at the Access Point as Sn–Xv_AI_D. This signal is the equivalent of the combined payload of the X individual member signals Sn received as Sn_AI_D at the member Access Points. X can have any value 1 X (max) where (max) is technology specific, e.g. 256 for a VC–4. The input and output signals of this function are: At the Access Point Sn_AI[1. . .X]_D Data Sn_AI[1. . .X]_CK Clock Sn_AI[1. . .X]_FS I Frame Start Sn_AI[1. . .X]_TSF Trail Signal Fail

At the Connection Point Sn–X_CI_D Data Sn–X_CI_CK Clock O Frame Start Sn–X_CI_FS Sn–X_CI_SSF Server Signal Fail

Sn-X_CI Sn-X_CP Sn-Xv/Sn-X_Sk_MP

Sn-Xv/Sn-X

Sn-Xv/Sn-X_Sk_MI 1

. . . . . . . X

Sn-Xv_AP


Figure 7.4 Sink side adaptation function

Functional models for LCAS and GFP At the Management Point Sn–Xv/Sn–X_A_Sk_MI_AcSQ[1. . .X] Sn–Xv/Sn–X_A_Sk_MI_cLOM[1. . .X] I Sn–Xv/Sn–X_A_Sk_MI_cSQM[1. . .X] Sn–Xv/Sn–X_A_Sk_MI_cLOA

129

Accepted SQ number Loss of Multi-frame SQ Mismatch Loss of Alignment

The VCAT multi-frame and sequence processes as described in Chapter 2 will take care of the re-alignment and re-ordering of the payload bytes transported by the individual members. The received sequence number (SQ) of each member in the VCG is made available to the network management system. Any changes in the SQ numbers are accepted if the received SQ has the same value in m consecutive multi-frames (3 m 10). The following defects will be detected by this function: Loss of Multi-frame: The VCAT overhead multi-frame cannot be recovered from the received signal. Loss of Sequence: the received SQ number of a member does not match the expected SQ number. The expected SQ number of member p in a VCG is (p 1). Loss of Alignment: the differential delay, i.e. the difference in time between the member experiencing the least propagation delay and the member experiencing the most propagation delay in the network, exceeds the implemented alignment buffer. Upon detection of one or more of the defects the consequent action is to replace the outgoing signal by an all-ones signal, i.e. the Alarm Inhibit Signal (AIS) and sending the Server Signal Fail (SSF) indication to the next function. When the defects are persistent an alarm is raised and sent to the network management system via the Sn–Xv/Sn–X_Sk_MP Management Point.

7.1.3 Sn–X Trail Termination function This function serves as the start and end point of the virtual trail that is used to transport the virtual concatenated signal through the network. The bi-directional model is shown in Figure 7.5.

130


AP

MP

Sn-X

CP

Figure 7.5 Bi-directional Sn-X trail termination model

Bi-directional model: Sn–Xv/Sn–X_So_A This model can be further decomposed into the uni-directional Source and Sink models as illustrated in Figures 7.6 and 7.7. Source side: Sn–X_So_TT The Sn–Xv trail termination function at the Source side is used only for providing a correct model. It does not contain any specific processes. The input and output signals of this function are: At the Connection Point Sn–X_CI_D Data Sn–X_CI_CK O Clock Sn–X_CI_FS Frame Start

At the Access Point Sn–X_AI_D Data Sn–X_AI_CK I Clock Sn–X_AI_FS Frame Start

Sn-X_AI Sn-X_AP

Sn-X

Sn-X_CP

Sn-X_CI

Figure 7.6 The source side trail termination function

131

Functional models for LCAS and GFP Sn-X_AI Sn-X_AP Sn-X_TT_Sk_MP

Sn-X

Sn-X_TT_Sk_MI Sn-X_CP

Sn-X_CI

Figure 7.7

The sink side termination function

Sink side: Sn–X_Sk_TT The Sn–Xv trail termination function at the sink side transfers the concatenated signal without further processing, it is used only for correct modeling. The input and output signals of this function are: At the Access Point Sn_AI[1. . .X]_D Data Sn_AI[1. . .X]_CK Clock Sn_AI[1. . .X]_FS I Frame Start Sn_AI[1. . .X]_TSF Trail Signal Fail

At the Connection Point Sn–X_CI_D Data Sn–X_CI_CK Clock Sn–X_CI_FS O Frame Start Sn–X_CI_SSF Server Signal Fail

At the Management Point Sn–X_TT_Sk_MI_SSF_Reported I Sn–X_TT_Sk_MI_cSSF O

Enable Reporting SSF Server Signal Fail

A received Server Signal Fail (SSF) will be forwarded as Trail Signal Fail (TSF) to the next function to maintain the transparency. If the SSF reporting has been enabled, the SSF status will be reported to the network management system via the management point Sn– X_TT_Sk_MP.

7.1.4 Sn Trail Termination function This function serves as the start and end point of the member trails that are actually used to transport the virtual concatenated signal

132


AP

MP

RP

Sn

CP

Figure 7.8 Bi-directional Sn trail termination model

through the network. These are the trails that intermediate nodes will ‘see’ without knowing that they are members of a VCG. Figure 7.8 shows the bi-directional model. Bi-directional model: Sn–Xv/Sn–X_So_A This model can be further decomposed into the uni-directional Source and Sink models. These models are shown in Figures 7.9 and 7.10. Source side: Sn_So_TT The Source function adds error monitoring and status overhead bytes to the VCG member payload container to form a complete Sn that is

Sn_AI Sn_AP

Sn_TT_So_MI

Sn_RP

Sn

Sn_RI_RDI Sn_RI_REI

Sn_TT_So_MP

Sn_CP

Sn_CI

Figure 7.9 The source side trail termination function

133

Functional models for LCAS and GFP Sn_AI Sn_AP

Sn_TT_Sk_MI

Sn_RP

Sn

Sn_RI_RDI Sn_RI_REI

Sn_TT_Sk_MP

Sn_CP

Sn_CI

Figure 7.10

The sink side termination function

forwarded to the Sn layer connection function. The input and output signals of this function are: At the Access Point Sn_AI_D Data Sn_AI_CK I Clock Sn_AI_FS Frame Start

Sn_TT_So_MI_TxTI

At the Connection Point Sn–X_CI_D Data Sn–X_CI_CK O Clock Sn–X_CI_FS Frame Start

At the Management Point O Transmitted Trail Identifier

Sn_RI_RDI Sn_RI_REI

At the Remote Point Remote Defect Indicator I Remote Error Indicator

The bit interleaved parity (BIP) is computed over all bits of the previous Sn and placed in parity byte position. The trail trace identifier (TTI) will be inserted. Its value is provisioned by the network management system and received as Sn_TT_So_MI information. The path trace format is described in ITU-T recommendation G.806. The RDI alarm and the REI alarm reported by the Sink side termination function Sn_Sk_TT as Remote Information (Sn_TT_RI),

134


will be sent to the far-end and will be used for performance monitoring. Sink side: Sn_Sk_TT The Sink function monitors the VCG member payload container Sn received from the Sn layer connection function. It recovers the error monitoring and status overhead bytes to determine the status and performance of the trail through the network. The input and output signals of this function are: At the Access Point Sn_AI_D Data Sn_AI_CK Clock Sn_AI_FS O Frame Start Sn_AI_TSF Trail Signal Fail Sn_AI_TSD Trail Signal Degrade

At the Connection Point Sn–X_CI_D Data Sn–X_CI_CK Clock I Frame Start Sn–X_CI_FS Sn–X_CI_SSF Server Signal Fail

At the Management Point Sn_TT_Sk_MI_TPmode Termination Point mode Sn_TT_Sk_MI_ExTI Expected Trail Identifier Sn_TT_Sk_MI_RDI_Reported Enable Reporting RDI Sn_TT_Sk_MI_SSF_Reported Enable Reporting SSF Sn_TT_Sk_MI_DEGTHR Degraded Signal Threshold Sn_TT_Sk_MI_DEGM I Degraded Monitor Period Sn_TT_Sk_MI_EXC_X Excessive Threshold Select Sn_TT_Sk_MI_DEG_X Degraded Threshold Select Sn_TT_Sk_MI_1second 1 Second Period Indication Sn_TT_Sk_MI_TIMdis Disable TIM detection Sn_TT_Sk_MI_TIMAISdis Disable sending AIS on TIM Sn_TT_Sk_MI_cTIM Sn_TT_Sk_MI_cUNEQ Sn_TT_Sk_MI_cEXC Sn_TT_Sk_MI_cDEG Sn_TT_Sk_MI_cRDI Sn_TT_Sk_MI_cSSF Sn_TT_Sk_MI_AcTI Sn_TT_Sk_MI_pN_EBC Sn_TT_Sk_MI_pF_EBC Sn_TT_Sk_MI_pN_DS Sn_TT_Sk_MI_pF_DS

O

Trail Identifier Mismatch Unequipped signal received Excessive Errors detected Degraded Signal detected Remote Defect Indicator Server Signal Fail Accepted Trail Identifier Near-end Error Block Count Far-end Error Block Count Near-end Defect Seconds Far-end Defect Seconds

Functional models for LCAS and GFP

Sn_RI_RDI Sn_RI_REI

135

At the Remote Point Remote Defect Indicator O Remote Error Indicator

A received SSF will be alarmed as TSF to the next function. If the SSF reporting has been enabled, the SSF status will be reported. The trail trace identifier (TTI) is recovered from Sn overhead. The received value is reported after acceptation (AcTI) and it is compared to the provisioned expected (ExTI) value. A detected mismatch defect (cTIM) is reported if the reporting is not disabled (TIMdis). If the consequent action is not disabled (TMAISdis), the signal will be replaced by AIS. The unequipped defect (UNEQ) is detected and reported; the unequipped signal indicates an open connection in the network path. Upon detection the AIS signal will replace the original signal. The parity byte (BIP) is recovered and will be compared with the computed parity for the previous Sn frame. A detected excessive (EXC) or degraded (DEG) error rate is reported. The thresholds for the excessive and degraded bit error rate are provisioned. The received Remote Error Indication (REI) and Remote Defect Indication (RDI) will be processed and the derived performance, i.e. the Near-End and Far-End Defect Seconds (DS) and Error Block Count (EBC), will be reported. The number of Error Detection Code Violations (EDCV) is reported to the far-end as the REI alarm via the Sn_TT_RI interface. Upon detection of an SSF, UNEQ defect or TIM defect the RDI alarm is reported to the far end via the Sn_TT_RI interface. All defects and performance data will be reported as management information (Sn_TT_Sk_MI) to the element or network management system if the Termination Point mode is true. Definitions of defect processing and performance processing are described in ITU-T recommendation G.806.

7.2 S4–Xc TO S4–Xc INTERWORKING FUNCTION A special symbol has been defined for the function that provides the transformation between contiguous concatenation and virtual

136


MP CP 1 . . .

CP S4-Xc S4-Xv

X

Figure 7.11

Bi-directional S4-XcS4-Xv interworking model

concatenation: the interworking function. The application is limited to concatenated S4 signals; more specifically X is limited to the values 4, 16, 64 and 256. The symbol that has been defined for the interworking function is depicted in Figure 7.11. Bi-directional model: Sn–Xc < > Sn–Xv This model can be further decomposed into the contiguous-to-virtual interworking Source function shown in Figure 7.12, and the virtual-tocontiguous interworking Sink function shown in Figure 7.13. Source side: S4–Xc > S4–Xv_I The source side interworking function will convert a contiguous concatenated signal S4–Xc_CI into a virtual concatenated signal S4–Xv_CI that is equivalent to X individual signals S4_CI. Currently,

S4-Xc > S4-Xv_I_MI S4-Xc > S4-Xv_I_MP S4-Xv_CP S4-Xc_CP S4-Xc > S4-Xv S4-Xc_CI

1 . . S4_CI[1...X] . X

Figure 7.12

The source side interworking function

137

Functional models for LCAS and GFP S4-Xv>S4-Xc_I_MI S4-Xv>S4-Xc_I_MP S4-Xv_CP

S4-Xv_CI = S4_CI[1...X]

Figure 7.13

1 . . . . X

S4-Xc_CP S4-Xv > S4-Xc

S4-Xc_CI

The sink side interworking function

values of X ¼ 4, 16, 64 and 256 are allowed. The input and output signals of this function are: At the contiguous concatenated Connection Point S4–Xc_CI_D Data S4–Xc_CI_CK Clock I S4–Xc_CI_FS Frame Start S4–Xc_CI_SSF Server Signal Fail

At the virtual concatenated Connection Point S4_CI[1. . .X]_D Data S4_CI[1. . .X]_CK Clock O S4_CI[1. . .X]_FS Frame Start S4_CI[1. . .X]_SSF Server Signal Fail

At the Management Point S4–Xc > S4–Xv_I_MI_TIEn Enable different TTI I S4–Xc > S4–Xv_I_MI_TxTI[2. . .X] Individual Trail Identifier

The received TTI in the S4–Xc overhead will either be sent in the overhead of all S4s of the S4–Xv or only in the overhead of the first S4 of the S4–Xv. In the latter case (TIEn ¼ true), the TTI of the remaining S4s has to be provisioned by the NMS. The number of bit errors detected in the S4–4c signal will be added to the BIP calculated before insertion in the first S4 (SQ ¼ 0) of the

138


S4–4v. For the remaining S4s of the S4–Xv, the BIP is calculated and inserted without change. The signal label of the S4–Xc will be inserted in the overhead of all individual S4s of the S4–Xv signal. The REI of the S4–Xc will be inserted in the first S4 of the S4–Xv. The REI of all other S4s of the S4–Xv will be set to 0. The RDI of the S4–Xc will be inserted in all S4s of the S4–Xv. If the Tandem Connection (TC) Overhead (TCOH) bits 1 to 4, the Incoming Error Count (IEC), of the S4–Xc contain the code ‘1110’ (Incoming AIS), the TCOH bits 1 to 4 of all S4s of the S4–v will be set to ‘1110’. If the IEC of the S4–Xc contains the code ‘0000’ (part of TC Unequipped), the IEC of all S4s of the S4–Xv will be set to ‘0000’. Otherwise, the IEC of the S4–Xc will be copied to the IEC of the first S4 of the S4–Xv and the IEC of all other S4s of the S4–Xv shall be set to an ‘1001’ indicating IEC ¼ 0. The TC Overhead bits 5 to 8 will be inserted in the first S4 of the S4–Xv. The TCOH bits 5 to 8 of all other S4s of the S4–Xv will be set to 0. The remaining overhead bytes of the S4–Xc will be inserted in the first S4 of the S4–Xv signal. The remaining overhead bytes of all other S4s of the S4–Xv will be set to 00h.

The multi-frame and sequencing processes are described in Chapter 2. Because the interworking function is applicable for S4, the H4 byte is used for the VCAT overhead. The SQ numbers will start at 0 and the maximum assigned value will be (X 1) in a S4–Xv. A received SSF will be sent as SSF on all S4s of the S4–Xv and the signal of all S4s is replaced by AIS. Sink side: S4–Xc > S4–Xv_I The sink side interworking function will convert a virtual concatenated signal S4–Xv_CI transported by X individual signals S4_CI into a contiguous concatenated signal S4–Xc_CI. Currently, values of X ¼ 4, 16, 64 and 256 are allowed. The input and output signals of this function are: At the virtual concatenated Connection Point S4_CI[1. . .X]_D S4_CI[1. . .X]_Ck S4_CI[1. . .X]_FS S4_CI[1. . .X]_SSF

I

Data Clock Frame Start Server Signal Fail

139

Functional models for LCAS and GFP At the contiguous concatenated Connection Point S4–Xc_CI_D Data S4–Xc_CI_CK Clock O S4–Xc_CI_FS Frame Start S4–Xc_CI_SSF Server Signal Fail

At the Management Point S4–Xv > S4–Xc_I_MI_Tpmode Termination Point mode S4–Xv > S4–Xc_I_MI_SSF_Reported Enable SSF Reporting S4–Xv > S4–Xc_I_MI_ExTI[1. . .X] I Expected Trail Identifier S4–Xv > S4–Xc_I_1second 1 Second Period Indication S4–Xv > S4–Xc_I_TIMdis[1...X] Disable TIM detection S4–Xv > S4–Xc_I_MI_cTIM[1. . .X] S4–Xv > S4–Xc_I_MI_cUNEQ[1...X] S4–Xv > S4–Xc_I_MI_cSSF[1...X] S4–Xv > S4–Xc_I_MI_AcTI[1...X] S4–Xv > S4–Xc_I_MI_cLOM[1...X] S4–Xv > S4–Xc_I_MI_cSQM[1...X] S4–Xv > S4–Xc_I_MI_cLOA S4–Xv > S4–Xc_I _MI_AcSQ[1..X]

O

Trail Identifier Mismatch Unequipped Signal received Server Signal Fail Accepted Trail Identifier Loss of Multi-frame SQ Mismatch Loss of Alignment Accepted SQ number

The following processes are performed per individual S4: The TTI is recovered from S4 overhead. The accepted value is reported as AcTI and it is compared to the provisioned expected (ExTI) value. A detected mismatch defect (cTIM) is reported if the reporting is not disabled (TIMdis). If the consequent action is not disabled (TMAISdis) the signal will be replaced by AIS. (If no individual TTIs are configured for the S4s in the S4–Xc > S4–Xv_I function, the expected TTI for all S4s has to be set equal to the expected TTI of the first S4, or TTIdis has to be set for these S4[2. . .(X–1)). The signal label byte will be recovered. It will be used to detect and report an UNEQ or an AIS condition. The SQ will be recovered and after acceptation it will be reported as AcSQ. A new sequence number is accepted if it has m times the same value with 3 m 10. After re-aligning, i.e. using the multi-frame process, and reordering, i.e. using the sequence process, the X individual S4s (see

140


Chapter 2 for more details), the following defects are detected for the VCG: Loss of Multi-frame: The VCAT overhead multi-frame cannot be recovered from the received signal. Loss of Sequence: the received SQ number of a member does not match the expected SQ number. The expected SQ number of member p in a VCG is (p 1). Loss of Alignment: the differential delay, i.e. the difference in time between the member experiencing the least propagation delay and the member experiencing the most propagation delay in the network, exceeds the implemented alignment buffer. If one of these defects is detected, the S4–Xc signal will be replaced by AIS. For the S4–Xc the following functions will be performed: The H4 byte of the S4–Xc will be set to ‘0’. The received TTI of the first S4 of the S4–Xv shall be inserted to the S4–Xc. The BIP–8 will be calculated for each S4 frame of the S4–Xv and compared with the related received BIP–8 to determine the bit errors per S4. The bit errors of all S4s of the S4–Xc will be added together and the result will be added to the BIP–8 calculated for S4–Xc frame. The resulting BIP–8 will be inserted in the S4–Xc overhead. The signal label of the first S4 of the S4–Xv shall be inserted in the S4–Xc. The REI values of all S4s of the S4–Xv will be added together. The result will be inserted in the S4–Xc. If the RDI of any S4 of the S4–Xv is set, the RDI of the S4–Xc shall be set to ‘1’. If the TCOH bits 1 to 4 (IEC) of any S4 of the S4–Xv contain the code ‘1110’ (Incoming AIS), TCOH bits 1 to 4 of the S4–Xc shall be set to ‘1110’. If the IEC of the first S4 of the S4–Xv contain the code ‘0000’ (TC Unequipped), the IECof the S4–Xc shall be set to ‘0000’. Otherwise the IEC values of all S4s of the S4–Xv will be added together and inserted as IEC in the S4–Xc. TCOH bits 5 to 8 of the first S4 of the S4–Xv will be copied to TCOH bits 5 to 8 of the S4–Xc. The remaining overhead bytes of the first S4 of the S4–Xv will be copied to the S4–Xc.

141


7.3 LCAS-CAPABLE VCAT FUNCTIONS The LCAS-capable virtual concatenated Sn path layer functional model is similar to the virtual concatenation model with the addition of the LCAS functionality. To make the distinction, it will be referred to as Sn–Xv–L.

7.3.1 Sn–Xv–L Layer Trail Termination function The decomposition for this virtual concatenation function with LCAS enabled is almost the same as the one shown and described in Section 7.1. The Sn–Xv–L_TT function can be further decomposed as depicted in Figure 7.14. _CI

_CI

CP

CP Sn-X-L/client

Sn-X-L/client

Sn-X-L_AI XA

Sn-X-L_AI

Sn-X-L_AP Sn-X-L

XA

Sn-X-L_AP XA

Sn-X-L_CI Sn-X-L_CP

Sn-Xv/Sn-X-L

Sn-Xv-L


Sn_AP

Sn

Sn

X = XM 1.......X

Sn_CP

Sn-Xv_CI = Sn_CI[1...X]

Figure 7.14

X=X 1 . . . . . . M. . . X

Sn_CI

Sn_CP

Sn_CI

Decomposition of Sn-Xv-L_TT function

142


Note the following technology-specific particularisations: The Sn–Xv/Sn–X–L_A adaptation function contains LCAS specific processes The Sn–X–L_TT termination function contains LCAS specific processes. The maximum value of X, i.e. XM, or XMT for the transmit side and XMR for the receive side, is technology specific. The number of members that are actually carrying payload or active members is XA.

7.3.2 Sn–Xv/Sn–X–L adaptation function This is the function that performs the adaptation of the (contiguous concatenated) client signal to the (virtual concatenated) server layer signals transported by the members of the VCG. An indication of the available transport bandwidth (XA) is sent towards the client layer. Figure 7.15 shows the bi-directional model. Bi-directional model: Sn–Xv/Sn–X_So_A This model can be further decomposed into the uni-directional Source and Sink atomic models, (see Figures 7.16 and 7.17). Source side: Sn–Xv/Sn–X–L_A_So The input and output signals of this function are At the Access Point

Sn_AI[1. . .X]_D Sn_AI[1. . .X]_CK Sn_AI[1. . .X]_FS

At the Connection Point

Data Clock Frame Start

O

XA MP

.

.

.

Data Clock Frame Start No. of Active Members

CP RP

Sn-Xv/Sn-X-L

1

Figure 7.15

Sn–X–L_CI_D Sn–X–L_CI_CK I Sn–X–L_CI_FS Sn–X–L_CI_XAT O

X = X MR . . .

.

X

AP

Bi-directional Sn-Xv/Sn-X-L adaptation model

143

Functional models for LCAS and GFP Sn-X-L_CI X AT MP Sn-Xv/ Sn-X-L_A_So_MI

Sn-X-L_CP

Sn-Xv/Sn-X-L

1

. . .

. .

.

. X

RP

Sn-Xv/ Sn-X-L_A_RI Sn-Xv_AP X = X MT


Figure 7.16

The Sn-Xv/Sn-X-L source side adaptation function

At the Management Point Sn–Xv/Sn–X–L_A_So_MI_LCASEnable LCAS enabled Sn–Xv/Sn–X–L_A_So_MI_ProvM[1...X] I Provisioned Member Sn–Xv/Sn–X–L_A_So_MI_PLCTThr PLC-T Threshold Sn–Xv/Sn–X–L_A_So_MI_XAT Sn–Xv/Sn–X–L_A_So_MI_XMT Sn–Xv/Sn–X–L_A_So_MI_TxSQ[1...X] Sn–Xv/Sn–X–L_A_So_MI_cPLCT Sn–Xv/Sn–X–L_A_So_MI_cTLCT Sn–Xv/Sn–X–L_A_So_MI_cFOPT

O

Active members Maximum members Transmitted SQ nr Partial Loss of Capacity Total Loss of Capacity Failure of Protocol

Sn-X-L_CI X AR MP Sn-Xv/ Sn-X-L_Sk_MI

Sn-X-L_CP

Sn-Xv/Sn-X-L

1

.

.

.

.

.

.

. X

RP

Sn-Xv/ Sn-X-L_A_RI Sn-X-L_AP


Figure 7.17

Sink side adaptation function

X = X MR

144


At the Remote Point Sn–Xv/Sn–X–L_A_So_RI_RS_Ack_rec Sn–Xv/Sn–X–L_A_So_RI_RS_Ack_gen Sn–Xv/Sn–X–L_A_So_RI_MST_rec[0. . .(max)] Sn–Xv/Sn–X–L_A_So_RI_MST_gen[0. . .(max)]

I

Received RS-Ack Generated RS-Ack Received MST Generated MST

The process definitions for this function are the same as for the Sn–Xv/Sn–X_A_So function described in Section 7.1.1, with the technology-specific particularisations shown below. The distribution process will perform the following tasks: The incoming signal Sn–X–L_CI will be distributed to the active members XAT; all provisioned members that are not active (XPT XAT) will send an all-zeros signal. The VLI, i.e. the MFI, SQ, CTRL, MST, GID, RS-Ack, will be assembled, the CRC is calculated and all this information is inserted in the designated fields in the control packet. If a member is transmitting the CTRL code IDLE and the Sink side reports a persistent MST ¼ OK via the Sn–Xv/Sn–X–L_RI interface, a Failure Of Protocol (FOP) is reported. If at least one member is sending CTRL code DNU, a Partial Loss of payload Capacity is reported. If all members in the VCG are sending CTRL code DNU, a Total Loss of payload Capacity is reported. The number of active members XAT is returned to the VCG termination function Sn–X–L_TT_So.

Sink side: Sn–Xv/Sn–X–L_A_Sk The input and output signals of this function are:

At the Access Point Sn_AI[1. . .X]_D Data Sn_AI[1. . .X]_CK Clock Sn_AI[1. . .X]_FS I Frame Start Sn_AI[1. . .X]_TSF Trail Signal Fail Sn_AI[1. . .X]_TSD Trail Signal Degraded

145

Functional models for LCAS and GFP At the Connection Point Sn–X–L_CI_D Data Sn–X–L_CI_CK Clock Sn–X–L_CI_FS O Frame Start Sn–X–L_CI_SSF Server Signal Fail Sn–X–L–CI_XAR No. of Active Members

At the Management Point Sn–Xv/Sn–X–L_A_Sk_MI_ProvM[1. . .X] Sn–Xv/Sn–X–L_A_Sk_MI_LCASEnable Sn–Xv/Sn–X–L_A_Sk_MI_PLCRThr Sn–Xv/Sn–X–L_A_Sk_MI_TSDEnable Sn–Xv/Sn–X–L_A_Sk_MI_HOTime Sn–Xv/Sn–X–L_A_Sk_MI_WTRTime Sn–Xv/Sn–X–L_A_Sk_MI_XMR Sn–Xv/Sn–X–L_A_Sk_MI_XAR Sn–Xv/Sn–X–L_A_Sk_MI_DMFI[1. . .M] Sn–Xv/Sn–X–L_A_Sk_MI_LCAS_So_Detected Sn–Xv/Sn–X–L_A_Sk_MI_cPLCR Sn–Xv/Sn–X–L_A_Sk_MI_cTLCR Sn–Xv/Sn–X–L_A_Sk_MI_cFOPR Sn–Xv/Sn–X–L_A_Sk_MI_cLOM[1. . .X] Sn–Xv/Sn–X–L_A_Sk_MI_cSQM[1. . .M] Sn–Xv/Sn–X–L_A_Sk_MI_cMND[1. . .M] Sn–Xv/Sn–X–L_A_Sk_MI_AcSQ[1. . .M]

I

Provision member LCAS enabled PLC-T Threshold TSD Enabled Hold-off time Wait-to-Restore Time

O

Max no. of members Active no. of members Diff. Delay LCAS Source detected Partial Loss of Capacity Total Loss of Capacity Failure of Protocol Loss of Multi-frame SQ number Mismatch Member not De-skewable Accepted SQ number

At the Remote Point Sn–Xv/Sn–X–L_A_Sk_RI_RS_Ack_rec Sn–Xv/Sn–X–L_A_Sk_RI_RS_Ack_gen Sn–Xv/Sn–X–L_A_Sk_RI_MST_rec[0. . .(max)] Sn–Xv/Sn–X–L_A_Sk_RI_MST_gen[0. . .(max)]

O

Received RS-Ack Generated RS-Ack Received MST Generated MST

The process definitions for this function are the same as for the Sn–Xv/Sn–X_A_Sk function described in Section 7.1.2, with the technology-specific particularisations shown below. The reconstruction process will perform the following tasks: The XAR individual incoming signals Sn_AI of the active members are re-aligned and re-ordered to reconstruct the original signal Sn–X–L_CI. A detected LOM will be reported as well as a Non

146


Consistent SQ (SQNC). If the differential delay is too large the re-alignment fails and will be reported by the Member Not Deskewable (MND) defect. The VLI, i.e. the MFI, SQ, CTRL, MST, GID and RS-Ack, will be extracted. The CRC is calculated and compared to the received CRC. If the number of CRC errors exceeds a provisioned threshold this will be reported. If either a TSF is received from a member termination function Sn_TT, a LOM or a MND is detected, a Member Service Unavailable–LCAS active (MSU–L) defect will be detected and consequently the signal is replaced by AIS and an SSF signal is sent to the VCG termination function Sn–X–L_TT. The number of active members XAR is forwarded to the VCG termination function Sn–X–L_TT_Sk.

7.3.3 Sn–X–L Trail Termination function This function serves as the start and end point of the virtual trail that is used to transport the virtual concatenated signal through the network. If LCAS is enabled, the payload size of the virtual trail can vary. The bi-directional model is shown in Figure 7.18. Bi-directional model: Sn–Xv/Sn–X_So_A This model can be further decomposed into the uni-directional Source and Sink models (see Figures 7.19 and 7.20).

XA MP

Sn-X-L

XA

Figure 7.18

AP

RP

CP

Bi-directional Sn-X-L trail termination model

147

Functional models for LCAS and GFP Sn-X-L_AI X AT

Sn-X-L_AP

Sn-X-L

Sn-X-L_CP

X AT

Sn-X-L_CI

Figure 7.19

The Sn-X-L Source side trail termination model

Source side: Sn–X–L_TT_So The input and output signals of this function are:

Sn–X–L_AI_D Sn–X–L_AI_CK Sn–X–L_AI_FS Sn–X–L_AI_XAT

At the Access Point Data I Clock Frame Start O

No. of Active Members

Sn-X-L_AI X AR

Sn-X-L_AP

Sn-X-L

Sn-X-L_TT_Sk_MP

Sn-X-L_TT_Sk_MI X AR

Sn-X-L_CP

Sn-X-L_CI

Figure 7.20

The Sn-X-L Sink side termination function

148

Next Generation SDH/SONET At the Connection Point I No. of Active Members Sn–X–L_CI_XAT Sn–X–L_CI_D Sn–X–L_CI_CK Sn–X–L_CI_FS

O


The process definitions for this function are the same as for the Sn–X_TT_So function described in Section 7.1.3 with the following technology-specific particularisation: The number of active members XAT in the VCG is transferred back to the Sn–X–L/client_A_So adaptation function. Sink side: Sn–X–L_TT_Sk The input and output signals of this function are: Sn–X–L_AI_D Sn–X–L_AI_CK Sn–X–L_AI_FS Sn–X–L_AI_TSF Sn–X–L_AI_XAR

At the Access Point Data Clock O Frame Start Trail Signal Fail No. of Active Members

At the Connection Point Sn–X–L_CI_D Data Sn–X–L_CI_CK Clock Sn–X–L_CI_FS I Frame Start Sn–X–L_CI_SSF Server Signal Fail Sn–X–L_CI_XAR No. of Active Members

At the Management Point Sn–X–L_TT_Sk_MI_SSF_Reported I Enable Reporting SSF Sn–X–L_TT_Sk_MI_cSSF O Server Signal Fail

The process definitions for this function are the same as for the Sn–X_A_Sk function described in Section 7.1.3 with the following technology-specific particularisation: The number of active members XAR in the VCG is transferred to the Sn–X–L/client_A_Sk adaptation function.

149


7.3.4 Sn Trail Termination function See Section 7.1.3 for the description. This function does not have any LCAS specific functionality. However, because LCAS is by definition asymmetrical, the member trails are unidirectional and hence RDI and REI are not supported when LCAS is enabled.

7.3.5 Sn–X–L to Client adaptation function This function requires client specific inputs, outputs and processes. It is included here to show that the XAT and XAR signals received from the VCG Adaptation function have to be processed by this function to adjust the client signal to the available bandwidth. Figure 7.21 shows the bi-directional model of this adaptation function. Bi-directional model: Sn–Xv/Sn–X_So_A This model can be further decomposed into the uni-directional models of the Source and Sink side, (see Figures 7.22 and 7.23). Source side: Sn–X–L/client_A_So The input and output signals of this function are:The process has the following technology-specific particularisations: Sn–X–L_XAT Sn–X–L_D Sn–X–L_CK Sn–X–L_FS

At the Access Point I No. of Active Members O


CP MP

Sn-X-L/client

XA

Figure 7.21

AP

Bi-directional Sn-X-L/client adaptation model

150

Next Generation SDH/SONET client_CI client_CP

Sn-X-L/ client_Sk_MI Sn-X-L/client MP X AT

Sn-X-L_AP

Sn-X-L_AI

Figure 7.22

The Sn-X-L/client Source side adaptation function

At the Connection Point Client specific I/O Characteristic Information

client_CI

At the Management Point Sn–X–L/client_Sk_MI I/O Client specific Management Information

client_CI client_CP

Sn-X-L/ client_Sk_MI Sn-X-L/client MP X AR

Sn-X-L_AP

Sn-X-L_AI

Figure 7.23

The Sn-X-L/client Sink side adaptation function


151

The incoming client signal is mapped into the payload area of the Sn–X–L signal. The number of active members XAT determines the available payload size. XAT is received via the VCG Trail Termination function Sn–X–L_TT_So from its adaptation function Sn-Xv/ Sn–X–L_A_So. Sink side: Sn–X–L/client_A_Sk The input and output signals of this function are:

Sn–X–L_D Sn–X–L_CK Sn–X–L_FS Sn–X–L_TSF Sn–X–L_XAT

client_CI

At the Access Point Data Clock I Frame Start Trail Signal Fail No. of Active Members

At the Connection Point I/O Client specific Characteristic Information

At the Management Point Sn–X–L/client_Sk_MI I/O Client specific Management Information

The process has the following technology-specific particularisations: The outgoing client signal is retrieved from the payload area of the Sn–X–L signal. The number of active members XAT determines the actual payload size. XAT is received from the VCG adaptation function Sn-Xv/Sn–X–L_A_Sk.

7.4 GFP ADAPTATION FUNCTIONS The most obvious mapping methodology that can be used in an Sn-X/ client_A is GFP. The adaptation process using GFP can be separated

152

Next Generation SDH/SONET client_CI client_CP server/client

server/client_MI server/client_MP

client specific processes client specific processes client specific processes client specific GFP FP client specific GFP FP client specific GFP common GFP processes server specific GFP server specific processes XA

server_AP

server_AI

Figure 7.24

The server/client GFP adaptation function

into three generic parts as shown in Figure 7.24 and is similar to Figure 6.2: one or more instances of client layer specific processes with a client GFP part; common GFP processes; and server layer specific processes with a server GFP part. This section only describes the GFP related functionality of the adaptation function.

7.4.1 Source side GFP adaptation processes Client specific GFP mapping The client specific GFP processes perform the mapping of client data into GFP frames. There are two types of mapping, as described in Chapter 6: frame-mapped GFP (GFP-F) and transparent-mapped GFP (GFP-T). Client layer specific deviations or extensions to the processes might be defined in the adaptation functions of the technology specific equipment recommendations.

153

Functional models for LCAS and GFP client specific processes

client data mapper

Client_SF

pFCS generator

FCSEnable

PTI and UPI generator

CSFEnable

common GFP processes

Figure 7.25 Client specific GFP-F Source processes

Client specific GFP-F Source processes The inputs to this process are client frames and, optionally, a Signal Fail (Client_SF). The processes are performed on a frame per frame base. The client specific GFP-F Source processes are shown in Figure 7.25. Client data mapping process. Inserts the client frame into the client payload information field of the GFP frame. One client frame results in one GFP frame. For the mapping of different client signals, see Section 6.3. pFCS generator. If pFCS generation is enabled (FCSEnable ¼ true), the pFCS is calculated over the client payload information field of a GFP frame and inserted into the pFCS fields of the same GFP frame as shown in the Payload FCS field section (page 108). The PFI field of the type header is set to ‘1’. If pFCS generation is disabled (FCSEnable ¼ false), no pFCS field is added to the GFP frame. The PFI field of the type header is in this case set to ‘0’. PTI and UPI generator. The PTI field of the GFP-F type header is fixed and set to ‘000’. The UPI field of the GFP type header is set according to the specific client signal and mapping. The UPI codes are shown in Table 6.1.

154


If both CSFEnable and Client_SF are true, GFP Client Management Frames are inserted instead of GFP-F client data frames. The PTI field of the GFP type header of the GFP client management frame is set to ‘100’. The UPI field is set to ‘0000 0010’. These GFP client management frames have no payload information field. They are generated as described in Section 6.2.2.2. Client specific GFP-T Source processes Figure 7.26 shows the client specific GFP-T Source processes. The input to this process is a stream of data and control words and a Loss of Signal (Client_LOS) and Loss of Character Synchronisation (Client_LCS) indication from the client layer. Clock process. The process generates the clock for the generation of the GFP-T frames. The clock rate has to be such that client data can be accommodated at its maximum rate. The clock can be locked to the server layer clock (Server_CK).

client specific processes

64B/65B encoder

pFCS generator

N

Server_CK

superblock mapper

clock

FCSEnable

Client_LOS Client_LCS

PTI and UPI generator


Figure 7.26 Client specific GFP-T Source processes


155

64B/65B encoder process. The process constructs a 64B/65B code word from eight consecutive received 8B/10B coded data or control words as described in Section 6.4.1.1. Superblock mapper process. First the process constructs a GFP-T superblock from eight received 65B data words as described in Section 6.4.1.2 and appends the calculated CRC-16 code at the end of the superblock. Second, the process will group N superblocks together in the Client Payload Information field of the GFP frame. The value of N depends on the client bit rate and server layer capacity. It is either fixed or configurable (Superblock_N). pFCS generation. The same as GFP-F. PTI and UPI generation. The PTI field of the GFP-T type header is fixed and set to ‘000’. The UPI field of the GFP type header is set according to the specific client signal and mapping. The UPI codes are shown in Table 6.1. In case Client_LOS or Client_LCS is true, GFP client management frames are inserted instead of GFP-T client data frames. The PTI field of the GFP type header of the GFP client management frames is set to ‘100’. If Client_LOS is true, the UPI is set to ‘0000 0001’ and if Client_LCS is true, the UPI is set to ‘0000 0010’. These GFP client management frames have no payload information field. They are generated as described in Section 6.2.2.2. Common GFP Source processes Figure 7.27 shows the common GFP source processes. The processes are performed on a frame per frame base. The input is the GFP frame. Channel multiplexing process. The process can perform the channel multiplexing, linear extension header generation and EXI generation: - If GFP channel multiplexing is supported and CMuxActive is true the frames from up to 256 channels are extended with the linear extension header and multiplexed together on a frame per frame base. The CID field of the linear extension header (see page 107) corresponds to the port at which the frame is received, i.e. CID[port n] ¼ ‘(n 1)’. The spare field contains all ‘0’s and the eHEC is generated as described on page 107. The EXI field of the type header is set to ‘0001’. The number of supported

156

Next Generation SDH/SONET client specific GFP processes 1.......

256 ports

CMuxConfig CMuxActive

channel multiplexor

tHEC generator

payload scrambler

core header generator

server specific GFP processes

Figure 7.27 Common GFP Source processes

channels is implementation specific. It is either fixed or configurable (CMuxConfig). - If GFP channel multiplexing is not supported or CMuxActive is not active only the GFP frames of a single channel (i.e. port 1) are forwarded. No extension header is added and the EXI field of the type header is set to ‘0000’. tHEC generation. The generation of tHEC in the payload header is described on page 106. Payload area scrambler. The scrambling of the GFP payload area is described on page 109. Core header generation. The length of the GFP payload area is calculated in octets and the value is inserted in the PLI field of the core header; the cHEC for the core header is generated and the core header is scrambled as described in Section 6.2.1.1. If the length of the GFP payload area exceeds 65 535 octets, the frame will be discarded. Server layer specific GFP Source processes Figure 7.28 shows the server layer specific GFP Source processes. The input to the processes is the GFP frame. Server layer specific

157

Functional models for LCAS and GFP common GFP processes

payload mapping

server specific processes

Figure 7.28

Server specific GFP Source processes

deviations or extensions to the processes might be defined in the adaptation functions of the technology specific equipment recommendations, e.g. in the application supporting VCAT with LCAS enabled, the signal Sn-X-L_AI_XAT shall control the GFP frame rate. Payload mapping process. The mapping process maps a GFP frame, if available, into the payload area of the server layer frame structure. If no GFP frame is available, a GFP Idle frame as described in Section 6.2.3 is inserted. If the GFP frame rate exceeds the server payload capacity, GFP frames are discarded. An octet mapping is performed. GFP Source specific inputs and outputs

Client_frame Client_FS Client_SF

At the Client Connection Point Client PDU GFP-F I Frame Start indicator Client Signal Fail

Client_data þ control Client_control - indicator Client_CK Client_LOS Client_LCS

Server_XAT Server_D Server_CK Server_FS

GFP-T

I

8B/10B characters Controlword indicator Client clock signal Loss of Signal Loss of Character Synchr.

At the Server Access Point I Active members in case LCAS enabled Server data O Clock Frame Start

158

Next Generation SDH/SONET At the Management Point

Server/Client_A_So_MI_CSFEnable Server/Client_A_So_MI_CmuxActive Server/Client_A_So_MI_CmuxConfig Server/Client_A_So_MI_FCSenable Server/Client_A_So_MI_Superblock_N

I

Client SF enabled GFP multiplexing active GFP multiplex config. FCS generation enabled Superblock size

7.4.2 Sink side GFP adaptation processes Client specific GFP de-mapping The client specific GFP processes at the Sink side perform the de-mapping of client data frames from GFP frames. The two types of de-mapping GFP-F and GFP-T are described. Client layer specific deviations or extensions to the processes might be defined in the adaptation functions of the technology specific equipment recommendations. Client specific GFP-F Sink processes Figure 7.29 shows the client specific GFP-F sink processes. The processes are performed on a frame per frame base. The input is the GFP frame; the output is the original client frame and Signal Fail (Client_SF). PTI and UPI monitor process. GFP frames with an accepted PTI value AcPTI (AcPTI is the value of the PTI field of the type header in a GFP frame with a correct tHEC) of ‘000’ are GFP client data frames. GFP frames with an accepted UPI value AcUPI (AcUPI is the value of the UPI field of the type header in a GFP frame with correct tHEC) that equals the expected UPI for the specific client signal and mapping are forwarded to the client specific processes. The UPI codes are shown in Table 6.1. The AcUPI value is reported to the management. The GFP User Payload Mismatch defect dUPM is raised when the accepted UPI is different from the expected UPI and consequently a Client Signal Fail (Client_SF) is sent to the client specific processes and the frame is discarded. cUPM is reported to the management.

159

Functional models for LCAS and GFP client specific processes

client data de-mapper FCSDiscard AcPFI

pFCS monitor

p_FCSError

cCSF CSF_Reported AcUPI

PTI and UPI monitor

cUPM p_FDis


Figure 7.29

Client specific GFP-F Sink processes

GFP frames with an AcPTI value of ‘100’ are GFP Client Management Frames (CMF). If the UPI value of a CMF equals ‘0000 0010’ the Client Signal Fail defect dCSF is raised and the frame is discarded. dCSF is cleared when no such CMF is received in m 1000 ms (m ¼ 3 is recommended) or when a valid GFP client data frame is received. cCSF is reported to the management and Client_SF is sent to the client specific processes. All other frames are discarded. The number of discarded frames, except the discarded CMFs, is added to the total number of discarded frames p_FDis reported to the management. pFCS monitor process. If the accepted PFI value AcPFI (AcPFI is the value of the PFI field of the type header in a GFP frame with correct tHEC) is set to ‘1’, the pFCS of the frame is checked as described on page 109. In case one or more errors are detected and FCSDiscard is true, the frame is discarded. AcPFI and the total number of errored frames (p_FCSError) is reported to the management. Client data de-mapping process. The client data frame is extracted from client payload information field of the GFP frame. One GFP frame results in one client frame.

160

Next Generation SDH/SONET client specific processes

64B/65B decoder

ECEnable

AcPFI

superblock de-mapper

FCS monitor

p_CRC16Err

p_FCSErr

cCSF AcUPI

PTI and UPI monitor

cUPM p_FDis


Figure 7.30

Client specific GFP-T Sink processes

Client specific GFP-T Sink processes Figure 7.30 shows the client specific GFP-T Sink processes. The input is the GFP frame; the output is a stream of client data and client control codeword octets. PTI and UPI monitor process. GFP frames with an AcPTI value of ‘000’ are GFP client data frames. If the accepted UPI (AcUPI) of these frames equals the expected value for the specific client signal and mapping, they are forwarded to the de-mapping process. The UPI codes are shown in Table 6.1. AcUPI is reported to the management. The GFP User Payload Mismatch defect dUPM is raised when the accepted UPI is different from the expected UPI, consequently a Client Signal Fail (Client_SF) is sent to the client specific processes and the frame is discarded. cUPM is reported to the management. GFP frames with an AcPTI value of ‘100’ are GFP Client Management Frames (CMF). If the UPI value of a CMF equals ‘0000 0001’ or


161

‘0000 0010’, the Client Signal Fail defect dCSF is raised and the frame is discarded. dCSF is cleared when no such CMF is received in m 1000 ms (m ¼ 3 is recommended) or when a valid GFP client data frame is received. cCSF is reported to the management and Client_SF is sent to the client specific processes. All other frames are discarded. The number of discarded frames, except the discarded CMFs, is added to the total number of discarded frames p_FDis reported to the management. pFCS monitor process. The same as GFP-F. (Frames with pFCS errors are not discarded in the case of GFP-T mapping as the CRC-16 of the GFP-T superblock can correct single bit errors (see below).) Superblock de-mapper process. The process starts by extracting N superblocks from the client payload information field of a GFP frame. The value N is defined by the size of the received GFP frame. Next, the process checks the received superblock for CRC-16 errors. Single bit error correction may be performed on each superblock if enabled by ECEnable. If one (ECEnable ¼ false) or more errors are detected, all 64 data octets of the superblock are replaced by 10B_ERR control words and the block is marked as an errored block. The total number of errored blocks is reported as p_CRC16Err to the management. Eight 65B data words are extracted from the superblock as described in Section 6.4.1.2. 64B/65B decoder process. The process extracts the eight data and/or control octets from the 65B code word as described in Section 6.4.1.1. These eight octets will be 8B/10B coded and transmitted at the output. All 65B_PAD characters are dropped from the data stream. Common GFP Sink processes Figure 7.31 shows the common GFP Sink processes. The processes are performed on a frame per frame base. The input is a GFP frame. Payload area descrambler process. The GFP payload area is descrambled as described on page 109. tHEC monitor process. The tHEC is checked as described on page 106. Single bit error correction on all the fields protected by the tHEC (i.e. the Type field) will be performed. In the case of multiple errors, the GFP frame is discarded. The number of discarded frames is added to the total number of discarded frames p_FDis reported to the management.

162

Next Generation SDH/SONET client specific GFP processes MuxConfig MuxActive AcEXI

1.......

256 ports

channel de-multiplexor

cEXM

p_FDis tHEC monitor

payload de-scrambler

server specific GFP processes

Figure 7.31

Common GFP Sink processes

Channel de-multiplexing process. If GFP channel multiplexing is supported and active (CmuxActive ¼ true), the accepted EXI value AcEXI (AcEXI is the value of the EXI field of the type header in a GFP frame with a correct tHEC) is compared to the value ‘0001’. If it has a different value the frame is discarded. Otherwise the eHEC of the linear extension header is checked as described on page 108. Single bit error correction on the extension header may be performed. In the case of multiple errors or a single error when error correction is not used, the frame is discarded. The frames are demultiplexed according to the value of the accepted CID value AcCID (AcCID is the value of the CID field in a GFP frame with linear extension header and correct eHEC). The frame is assigned to channel number (AcCID þ 1) where channel number corresponds to the port at which the frame is transmitted. Frames with channel numbers that are not active are discarded. The number of active channels is implementation specific. It is either fixed or configurable (CMuxConfig). The spare field of the linear extension header is ignored. In case GFP channel multiplexing is not supported or not active (CmuxActive ¼ false), the accepted EXI (AcEXI) is compared with the value ‘0000’. If it has a different value the frame is discarded.

163

Functional models for LCAS and GFP common GFP processes

GFP frame delineation

cLFD

payload de-mapping

server specific processes

Figure 7.32 Server specific GFP Sink processes

The value AcEXI is reported to the management. The GFP Extension Header mismatch defect (dEXM) is raised when the accepted EXI is different from the expected EXI, consequently the frame is discarded and cEXM is reported to the management. The number of discarded frames is added to the total number of discarded frames p_FDis reported to the management. Server layer specific GFP Sink processes Figure 7.32 shows the server layer specific GFP sink processes. The input to the processes is the server layer data. Server layer specific deviations or extensions to the processes might be defined in the adaptation functions of the technology specific equipment recommendations, e.g. in the application supporting VCAT with LCAS enabled the signal Sn-X-L_AI_XAT shall control the GFP frame rate. Payload de-mapping process. The de-mapping process extracts the GFP frames from the payload area of the server layer frame structure. An octet de-mapping is performed. GFP frame delineation process. GFP frame delineation is performed as described in Section 6.2.4.1. Frame delineation is assumed to be achieved when the process is in the ‘SYNC’ state. Frame delineation is assumed to be lost when the process is not in the ‘SYNC’ state. Idle GFP frames participate in the delineation process and are then discarded. In the ‘HUNT’ state searching for a correctly formatted core header includes the core header descrambling see Section 6.2.1.1. In the ‘PRESYNC’ and ‘SYNC’ state the core header descrambling is

164


applied to the assumed core header positions. The GFP loss of frame delineation defect (dLFD) is raised when the frame delineation process is not in the ‘SYNC’ state. Consequently, the Client Signal Fail (Client_SF) is forwarded to the client specific processes and cLFD is reported to the management. GFP Sink specific inputs and outputs At the Client Connection Point Client_frame Client_FS Client_SSF

GFP-F

O

Client PDU Frame Start indicator Server Signal Fail

Client_data þ control Client_control - indicator Client_CK Client_SSF

GFP-T

O

8B/10B characters Controlword indicator Client clock signal Server Signal Fail

Server_D Server_CK Server_FS Server_SF

At the Server Access Point Server data Clock I Frame Start Signal fail

_XAR

Active members in case LCAS enabled

At the Management Point Server/Client_A_Sk_MI_FCSDiscard Discard FCS Server/Client_A_Sk_MI_CmuxActive Client Multiplex Active Server/Client_A_Sk_MI_CMuxConfig I Client Multiplex Config. Server/Client_A_Sk_MI_ECEnable Error Correction enabled Server/Client_A_Sk_MI_CSF_Reported Report Client Signal Fail Server/Client_A_Sk_MI_AcPFI Server/Client_A_Sk_MI_AcUPI Server/Client_A_Sk_MI_AcEXI Server/Client_A_Sk_MI_p_FDis Server/Client_A_Sk_MI_p_FCSError Server/Client_A_Sk_MI_p_CRC16Err Server/Client_A_Sk_MI_cUPM Server/Client_A_Sk_MI_cCSF Server/Client_A_Sk_MI_cEXM Server/Client_A_Sk_MI_cLFD

O

Accepted PFI Accepted UPI Accepted EXI No. of discarded frames No. of FCS errors No. of CRC-16 errors UPI mismatch report Client Signal Fail report EXM report LFD report

165


7.5 EQUIPMENT MODELS FOR GFP GFP can be deployed in transport network elements (e.g. SDH) and in data network elements (e.g. IP, Ethernet Routers). As GFP is a mapping methodology, it will be found in the application specific functional model of the adaptation function that maps a PDU based client signal into a Sn, Sn–Xv or Sn–Xc signal. GFP provides the mapping of a multitude of client signals and so a selection has been made to give some examples of the GFP functional model. Figure 7.33 shows the functional model of an Ethernet tributary port on a transport network element. Figure 7.34 depicts the functional model where GFP processing is performed in an IP Router, or an IP router function embedded in a hybrid SDH/IP network element. Figure 7.35 shows the functional model of a SAN (8B/10B coded

EthP CBR-t_CP EthS/EthP

PHY-t_AP

CBR-t_CP Sn-Xv-L/EthP

Sn-Xv-L_AP Sn-Xv-L

EthS

PHY-t_CP

Sn-Xv_CP

PHY-t/EthS

PHY-t_AP PHY-t

PHY-t_CP

Figure 7.33

Ethernet signal transport using GFP-F

166


IP

IP_CP Sn-Xv-L/IP

Sn-Xv-L_AP Sn-Xv-L

Sn-Xv_CP

Figure 7.34

IP router interface

CBR-t_CP

Sn-Xv-L/CBR-t

PHY-t/CBR-t

PHY-t_AP

Sn-Xv-L

PHY-t

PHY-t_CP

Figure 7.35

Sn-Xv-L_AP

Sn-Xv_CP

SAN signal transport using GFP-T


167

signal) tributary port on a transport network element. All figures provide the bi-directional functional model. To avoid confusion, the atomic functions are described for a signal flow from left to right; in the opposite direction the same atomic functions will perform the reverse operation.

7.5.1 Ethernet tributary port For the case where only a part of the physical interface bandwidth is carrying traffic and only this traffic is to be transported through the transport network, the physical data interface signal is terminated, data PDUs are extracted and forwarded via GFP–F mapping over a Sn, Sn–Xc, or Sn–Xv signal. The PHY–t termination function terminates the physical Ethernet signal. The PHY–t/EthS adaptation function provides the Ethernet PHY decoding and data/clock recovery. The EthS termination function processes the Ethernet control characters. The EthS/EthP adaptation function extracts the Ethernet MAC frames. The EthP connection function is used to connect the tributary port signal to the network port for further transport. It has the same functionality as an Ethernet bridge or switch function. The Sn–Xv–L/EthP adaptation function encapsulates the Ethernet MAC frames into GFP–F frames and maps the GFP stream into a Sn–Xv (or Sn, or Sn–Xc). The Sn–Xv–L termination function provides the Sn–Xv (or Sn, or Sn–Xc) path termination.

7.5.2 IP router port Only the part of the functional model, where GFP processing is performed in-between the IP Router fabric and, for example, the STM–N interface port functions, is shown. The IP connection function is the representation of an IP router with many ports.

168


The Sn–Xv–L/IP adaptation function provides the encapsulation of IP frames into PPP frames, the encapsulation of PPP frames into PPP/HDLC frames, the PPP/HDLC frames into GFP–F frames and the mapping of the GFP stream into a Sn–Xv (or Sn, or Sn–Xc). The Sn–Xv–L termination function provides the Sn–Xv (or Sn, or Sn–Xc) path termination.

7.5.3 SAN tributary port For the case where the physical data signal is an 8B/10B coded signal, it can be transported through the transport network as a transparent stream using GFP–T mapping. The PHY–t termination function terminates the physical SAN signal, e.g. Fibre Channel, ESCON, FICON or GbEthernet. The PHY–t/CBR–t adaptation function provides the 8B/10B decoding and data/clock recovery. The Sn–Xv–L/CBR–t adaptation function encapsulates the PHY layer characters (data and control) into fixed-length GFP–T frames and maps the GFP stream into a Sn–Xv (or Sn, or Sn–Xc). The Sn–Xv–L termination function provides the Sn–Xv (or Sn, or Sn–Xc) path termination.

8 The LCAS procedure exercised Step by step This chapter shows some exercises explaining the operation of the processes within the LCAS-capable adaptation Source and Sink functions in detail. All these exercises are intended to illustrate the dynamic interactions among the processes, and between the processes and the LCAS protocol. Together with the SDL diagrams in Chapter 4 and the TSD diagrams described in Chapter 5, it is hoped that these exercises will provide an even better understanding of the LCAS protocol. In order to explain the behaviour in detail it was necessary to select a particular implementation. However, this does not preclude that other implementations are also possible. Of course, every implementation has to comply with the ITU-T recommendations G.7042 and G.806. In all the exercises provided in this chapter, the maximum size of the VCG will be six members, i.e. XMT ¼ 6, XMR ¼ 6 (this value is just an example). More appropriate values can be found in Table 2.5.

8.1 BASIC CONFIGURATION This configuration is depicted by using the functional models described in Chapter 7, Section 7.3. However, for the exercises in this chapter, there is one exception: the VCAT adaptation functions are drawn with much more detail. They show all the processes supporting


170


the VCAT and LCAS functionality as separate entities. But this does not preclude the possibility of designing an implementation where the processes are less distinguishable or where the functions are distributed in a different way. As long as the external behaviour at the connection points CP and access points AP is the same, and complies with the standards. In all the exercises in this chapter, it is assumed that the LCAS capability is enabled at both the Source side and the Sink side of the VCG. For the sake of simplicity, all of the following inputs are supposed to be set:

input Sn–Xv/Sn–X–L_A_So_MI_LCASEnable Sn–Xv/Sn–X–L_A_Sk_MI_LCASEnable Sn–Xv/Sn–X–L_A_So_MI_PLCTThr Sn–Xv/Sn–X–L_A_Sk_MI_PLCRThr Sn–Xv/Sn–X–L_A_Sk_MI_HOTime Sn–Xv/Sn–X–L_A_Sk_MI_WTRTime Sn–Xv/Sn–X–L_A_Sk_MI_TSDEnable Sn–Xv/Sn–X–L_RI_selector

value true true 0 0 0 0 true 1

In addition to the fixed inputs there will be neither external events nor consequent actions in the exercises that will cause any of the following outputs to change (and they will not be mentioned):

output

value

Sn–X–L_CI_SSF Sn–Xv/Sn–X–L_A_So_MI_cPLCT Sn–Xv/Sn–X–L_A_So_MI_cTLCT Sn–Xv/Sn–X–L_A_So_MI_cFOPT Sn–Xv/Sn–X–L_A_Sk_MI_LCAS_So_Detected Sn–Xv/Sn–X–L_A_Sk_MI_cPLCR Sn–Xv/Sn–X–L_A_Sk_MI_cTLCR Sn–Xv/Sn–X–L_A_Sk_MI_cFOPR Sn–Xv/Sn–X–L_A_Sk_MI_cSQM[1..XMR] Sn–Xv/Sn–X–L_A_Sk_MI_cLOA Sn–Xv/Sn–X–L_A_Sk_MI_cLOM Sn–Xv/Sn–X–L_A_Sk_MI_cMND[1..XMR]

false false false false true false false false false false false false

171

The LCAS Procedure Exercised

Sn-X-L/client

client to LCAS enabled VCG Adaptation Sn-X-L/client_So_A

Sn-X-L

LCAS enabled VCG Trail Termination Sn-X-L_So_TT

XAT

Sn-X-L_CI

Sn-X-L_CP

distribution

Sn-Xv/Sn-X-L_RP

0

1

2

3

4

1

2

3

4

5

5

IDLE VLI SQ SQ SQ SQ SQ SQ SQ = ins = 0 = 1 = 2 = 3 = 4 = 5 (max)

6

1

2

3

4

Figure 8.1

5

6

Sn-Xv/Sn-X-L_RI Sn-Xv/Sn-X-L_MP

Sn-Xv/Sn-X-L_So_MI

trail selection Sn_AP

LCAS enabled VCG to member AdaptationSn-Xv/Sn-X-L_So_A

Sn_AI

individual member Trail Terminations Sn_So_TT

VCG Source configuration

8.1.1 The VCG Source side configuration Figure 8.1 shows the Source side VCG adaptation function (Sn–Xv/ Sn–X–L_So_A). The XMT outputs are connected to the individual member trail terminations (Sn_So_TT) at the access points (Sn_AP) to transfer the adapted information (Sn_AI). The input is connected to the client layer trail termination function (Sn–X–L_So_TT) and adaptation function (Sn–X–L/client_So_A) at the connection point (Sn–X– L_CP) that transfers the characteristic information (Sn–X–L_CI). The remote information (Sn–Xv/Sn–X–L_RI) is received from the related VCG Sink side adaptation function at the remote information point (Sn–Xv/Sn–X–L_RP) and the management information (Sn–Xv/Sn– X–L_So_MI) is exchanged with the element or network management system (NMS) via the management point (Sn–Xv/Sn–X–L_So_MI). The timing information (Sn–Xv/Sn–X–L_TI) is not shown. The following functions are shown in Figure 8.1: Distribution. In this process the payload area of VCG characteristic information Sn–X–L_CI received at its input Sn–X–L_CP is

172


distributed octet by octet over XAT out of XPT octet streams. See Chapter 2, Section 2.3.1, for a detailed explanation of the distribution process. This process has a total of XMT outputs; XAT outputs will transmit the octet streams containing the distributed client payload and the remaining outputs (XMT XAT) will transmit an all zero payload signal. The path overhead information present in the Sn–X–L_CI is transferred to every output. The connections in the distribution process are reflected by the parameter _So_PC[SQ] (¼ 1 if it is payload carrying, ¼ 0 if no payload is carried) where SQ(is the assigned sequence number. The total of (_So_PC[SQ] that equals 1) ¼ XAT. Since the value XAT is communicated to the higher client layer functions this Source process expects to receive an Sn–Xc (X ¼ XAT) structured signal at the Sn–X–L_CP. (According to ITU-T recommendations G.707, G.709 and G.7043: X 1, hence the structure of this signal will be at least Sn–1c, even when XAT ¼ 0). VLI insertion. The VCAT and LCAS specific overhead information will be inserted for each individual member(i) where i ¼ 1. . .XMT, i.e. each member will transmit the same MFI, GID, MST and RSAck information and each individual member(i) will transmit its particular SQ[i], CTRL[i] and CRC[i]. Trail selection. This switch process connects the individual member signal Sn__AI to the assigned member trail termination Source function Sn_So_TT via its access point Sn__AP. Similar to the UNEQ (unequipped) signal used in other connection functions this process has a VLI inserter that transmits CTRL code IDLE, SQ value (max) and an all zero payload signal. The SQ value (max) is application specific, e.g. it is 63 for K4 based VCAT (e.g. VC-12), or 255 for H4 based VCAT (e.g. VC-4). Initiation LCAS Source Engine -

When the LCAS engine is started it will use the inputs:

i So_MI_ProvM[i]

1

2

3

4

5

0

0

0

0

0

6 0

173

The LCAS Procedure Exercised SQ

-

0

1

2

3

4

So_RI_RS-Ack_rec So_ RI_MST_rec[SQ] 1

1

0 (see Sink) 1 1 1

5 1

Since in these exercises XMT ¼ 6 only So_ RI_MST_rec[1. . .6] are relevant; So_ RI_MST_rec[7. . .(max)] will always ¼ 1. The LCAS Source engine will calculate and set the following parameters in the Source Adaptation function: i

1

_CTRL[i] _SQmap[i]

IDLE (max)

SQ _XAT _So_PC[SQ]

2

3

4

5

6

IDLE IDLE IDLE IDLE IDLE (max) (max) (max) (max) (max)

0

1

2

3

4

5

0 (there are no active members) 0 0 0 0 0 0

-

The calculated number of active members _XAT is output as Sn–X–L_CI_XAT to the Sn–X–L_CP and as Sn–X–Xv/ Sn–X– L_A_So_MI_XAT to the management point. Output i is connected to the VLI inserter with number _SQmap[i]; this SQ number is also provided to the NMS as So_MI_TxSQ[i]. Distribution. Since _XAT ¼ 0 and _So_PC ¼ 0 for all VCG members, no payload is distributed and no connections are set. All outputs will transmit an all-zero payload signal. Trail selection. All member Trail Terminations are connected to the SQ ¼ (max) VLI inserter. As a result, the VCG Adaptation Source function will produce at every output a path-layer signal Sn__AI with overhead bytes equal to those of the Sn–X–L_AI, a valid VLI overhead structure with a sequence number SQ ¼ (max) and a CTRL word IDLE, and a payload area containing all zeroes.

8.1.2 The VCG Sink side configuration Figure 8.2 shows the Sink side adaptation function (Sn–Xv/Sn–X– L_Sk_A). The output is connected to the client layer trail termination

174

Next Generation SDH/SONET LCAS enabled VCG to client signal Adaptation Sn-X-L/client_Sk_A

Sn-X-L/client Sn-X-L

LCAS enabled VCG Trail Termination Sn-X-L_Sk_TT

XAR

Sn-X-L_AI

Sn-X-L_CP

member to LCAS enabled VCG Adaptation Sn/Sn-X-L_Sk_A

assembly 0 1 diff del

Sn_AP

1

Sn-Xv/Sn-X-L_RP

1 2 3 4 re-alignment 2 3 4 5 diff del

diff del

2

diff del

3

diff del

4

Figure 8.2

5

Sn/Sn-X-L_RI 6 diff del

5

Sn-Xv/Sn-X-L_Sk_MP

Sn/Sn-X-L_Sk_MI Sn_AI

6

individual member Trail Terminations Sn-Sk-TT

VCG Sink configuration

function (Sn–X–L_Sk_TT) and the adaptation function (Sn–X–L/client_Sk_A) at the connection point (Sn–X–L_CP) to transfer its characteristic information (Sn–X–L_CI). The inputs are connected to the individual member trail termination functions (Sn_Sk_TT) at the access points (Sn_AP) to transfer the adapted information (Sn_AI). The remote information (Sn–Xv/Sn–X–L_RI) is transmitted to the related VCG Source side process at the remote information point (Sn–Xv/Sn–X–L_RP) and the management information (Sn–Xv/ Sn–X–L_Sk_MI) is exchanged with the element or network management system (NMS) via the management point (Sn–Xv/Sn–X– L_Sk_MP). The following processes can be distinguished in Figure 8.2: Differential delay. For each individual member with a valid VLI, this process determines the differential delay by analysing the received MFI and comparing it with the MFI of the other members. The calculated differential delay _D[i] is minimised to optimise the propagation delay of the VCG. The resulting _D[i] is used to re-align the individual member octet streams in preparation for the re-order process. It is made available to the management system


175

as Sn–Xv/Sn–X–L_A_Sk_MI_DMFI[i]. See Chapter 2, Section 2.3.1, for an explanation of the differential delay compensation. Re-alignment. This switch process re-orders the individual member octet streams based on their SQ numbers. The member with SQ number 0 and CTRL word NORM/EOS/DNU shall be connected to the first output, the member with SQ number 1 and CTRL word NORM/EOS/DNU to the second output, etc. The connections are determined by the parameter _SQv[i] (the received and validated SQ number). _SQv[i] is reported to the management system as Sn–Xv/Sn–X–L_A_Sk_MI_Ac_SQ[i]. Assembly. This process has XMR inputs. It reconstructs from the signals present at these inputs the original VCG characteristic information Sn–X–L_CI by using the parameter _Sk_PC[SQ] (¼ 1 if payload carrying, ¼ 0 if no payload carried) where SQ is the assigned sequence number. The total of (_Sk_PC[SQ] ¼ 1) equals XAR. The value XAR is sent to the higher client-layer functions to inform them that an Sn–Xc (X ¼ XAR) structured signal is presented at the Sn–X–L_CP. (According to ITU-T recommendations G.707, G.709 and G.7043: X 1, hence the structure of this signal will be at least Sn–1c, even when XAT ¼ 0.) Initiation Differential delay. Since there are no network connections provisioned, all member trail termination functions Sn_TT_Sk will receive an UNEQ signal and consequently will set Sn_AI_ TSF[1. . .XMR] ¼ true and output an AIS signal towards the Sn_AP. Due to the AIS signal, the MFI value cannot be derived and consequently the differential delay cannot be calculated and a Loss of Multi-frame defect will be detected for all members (i.e. dLOM[1. . .XMR] ¼ true). However, the condition MI_cLOM [1. . .XMR] ¼ true will not be declared because Sn_AI_TSF[1. . . XMR] ¼ true (see G.806 clause 10.1.1.2 defect correlations). Since no members are provisioned, this process will use for each member the default delay _D[1. . .XMR] ¼ 0. LCAS Sink Engine - This process is started using the inputs shown in the table. Because of the received Sn_AI_TSF[1. . .XMR] ¼ true, this process will not be able to detect and validate the VLI of each member and consequently all _CRC_ok, _CTRL and _SQv[1. . .XMR] are noted as not available (n/a).

176


-

i

1

2

MI_ProvM[i] Sn_AI_TSF[i] Sn_AI_TSD[i] dLOM[i] _D[i] _CRC_ok[i] _CTRL[i] _SQv[i]

0 true false true 0 n/a n/a n/a


3 0 true false true 0 n/a n/a n/a

4

5

6




After processing this information the following outputs are present: i

1

MI_DMFI[i] Sk_RI_selector

n/a

SQ _XAR _Sk_PC[SQ] Sk_RI_RS-Ack_gen Sk_RI_MST_gen[SQ]

2

3

4

5

6

n/a n/a n/a n/a n/a (none available)

0 0 1

1

2

3

4

0 0 0 0 0 (for example) 1 1 1 1 0

n/a

5 0 1

The calculated number of active members _XAR is output as Sn–X–L_CI_XAR to the connection point Sn–X–L_CP and as Sn– X–Xv/ Sn–X–L_A_Sk_MI_XAR to the management point Sn–X– Xv/ Sn–X–L_A_Sk_MI. The Sk_RI_selector parameter indicates from which member the RS-Ack and MST information is retrieved. It is selected among the members that have CTRL word NORM/EOS/ DNU/ADD and _CRC_ok[i] ¼ true. This parameter is output to the companion VCG in the opposite direction. Re-alignment. Since there is no valid _SQv[i] for all VCG members, an all-zero payload signal is present at every output. Assembly. Since _XAR ¼ 0 and _Sk_PC[SQ] ¼ 0 for all VCG members, there is no payload signal to reconstruct. Since Sn_AI_TSF ¼ true for all VCG members, there is no path overhead information to reconstruct.

177


As a result, the VCG Adaptation Source function will output characteristic information Sn_CI consisting of an Sn–1c structured signal (i.e. the minimum value of an Sn–Xc) containing all ones, i.e. an AIS signal.

8.1.3 VCG Source, VCG Sink and subnetwork configuration The VCG Source function and the VCG Sink function are connected via a subnetwork. The configuration in Figure 8.3 will be used as the basis for the exercises in this chapter. In this configuration only the forward direction of transmission is shown from node A to node Z. The assumption is that in the opposite direction (from node Z to node A) a VCG exists already that is operational and is transferring valid MST and RS-Ack information for the VCG in these exercises. The configuration shows an LCASenabled Source function, an LCAS-enabled Sink function (MI_LCASEnable is active) and an Sn subnetwork providing the Sn path layer node A

node Z Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

MAX

X AT

2

3

4

5

6 Sn

UNEQ

1

2

3

4

5

Sn subnetwork

Figure 8.3

Example of the complete VCG configuration

6 Sn

178


connectivity for the individual member trails. Since, initially, there are no connections in the Sn subnetwork, all 1. . .XMR member Sn Trail Termination Sink functions are connected to an UNEQ Sn Trail Termination Source function. All member Sn_TT_Sk functions will detect the UNEQ signal and consequently output an AIS signal and a TSF ¼ true signal towards the VCG Adaptation Sink function. Any changes in the configuration, e.g. adding/removing members from VCGs and/or provisioning the connectivity in the subnetwork, are initiated by the network management system (NMS).

8.2 EXERCISE 1: INITIATE A 3-MEMBER VCG In this first exercise a three member VCG is created from scratch. There are three steps that need to be performed to achieve this goal: Step a: provision the path-layer connectivity, i.e. establish three member paths through the network; Step b: provision the Sink to use three members; and Step c: provision the Source to use three members. (These three steps can be taken in any order. This particular exercise will show the order as mentioned above.)

8.2.1 Step a: provision the connectivity The intended path-layer connectivity shall be established at (sub)network level and shall be performed independently for each intended member of the VCG. This satisfies the VCAT design requirement that intermediate nodes are not aware of the fact that a member‘s trail is part of a VCG. Note, however, that the more diverse the trails routed, the less members are affected by a network fault and the better the availability of the VCG will be. In the Sn subnetwork In this exercise three trails are provisioned by the NMS: from Source member 1 to Sink member 4; from Source member 3 to Sink member 5; and from Source member 5 to Sink member 2.

179


In the Sink adaptation Differential delay. For the VCG members with a (sub)network connection (i ¼ 2, 4, 5), the TSF will clear because the UNEQ signals are replaced by the signals from the Source VCG. The process will now be able to recover the MFI of those members. All the other members (i ¼ 1, 3, 6) still receive AI_TSF[i] ¼ true and dLOM[i] ¼ true will be declared. For the provisioned members (i ¼ 2, 4, 5 with MI_ProvM[i] ¼ 1) only, this process will use the received MFIs to calculate the buffer delay _D[i] required to compensate the differential delay. The delay calculation shall also take care that the propagation delay of the VCG through the network is as short as possible. For this exercise it is assumed that the calculated buffer delays among the considered members are within the supported range, hence dMND[i] ¼ false. LCAS Sink Engine - Because the members 2, 4 and 5 receive the signals from the Source VCG (TSF ¼ false), their VLI can be validated and used as an input for further processing. (Shading indicates the inputs that have changed; this indication is used in all exercises.)

i

1


-


2

3

4

5

6

0 false false false bb true IDLE (max)


0 false false false dd true IDLE (max)

0 false false false ee true IDLE (max)


Based on the received VLI this process will output:

i

1


n/a

2 n/a

3

4

n/a n/a n/a

5

6

n/a n/a

180

Next Generation SDH/SONET SQ _XAR _Sk_PC[SQ] Sk_RI_RS-Ack_gen Sk_RI_MST_gen[SQ]

0

1

2

0

0

0

3

4

5

0

0

0

1

1

1

0 0 1

1

1

Re-alignment. Since _SQv[i] is either n/a or (max) with CTRL word IDLE, this process will present all-zero path-layer signals at all its outputs. Assembly. Since _XAR ¼ 0 and _Sk_PC[0. . .(XMR –1)] ¼ 0, the Adaptation Source function will produce at the output a signal Sn_CI in an Sn–1c structured signal consisting of all ones, i.e. an AIS signal. In the Source adaptation There are no changes because it is still provisioned for a size of zero members: XPT ¼ 0 (i.e. So_MI_ProvM[1. . .XMT] ¼ 0). After the three trails have been established through the (sub)network, the status of the configuration will be as shown in Figure 8.4.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

MAX

X AT

2

3

4

5

6

UNEQ

1

2

Sn

Figure 8.4

VCG initiation step a

3

4

5

6 Sn

181


8.2.2 Step b: provision the Sink Next the Sink will be configured by the NMS to use the VCG members 2, 4 and 5 for transporting the client payload (Sk_MI_ProvM[2, 4, 5] ¼ 1). The status of the configuration will become as follows. In the Sink adaptation Differential delay. No changes, but this process continues to adjust the differential delay if necessary. LCAS Sink Engine - The inputs to this process are now: i

1


-


2

3

4

5

6

1 false false false bb true IDLE (max)


1 false false false dd true IDLE (max)

1 false false false ee true IDLE (max)


This process will now be able to report the buffer delay value of members 2, 4 and 5 to the NMS. i

1


n/a


2

3

bbb

4

5

n/a ddd n/a

0

1

2

0

0

0

6

eee n/a

3

4

5

0

0

0

1

1

1

0 0 1

1

1

Re-alignment. No change, because there are still no payload carrying members.

182


Assembly. Since _XAR ¼ 0 and _Sk_PC[0. . .(XMR –1)] ¼ 0, an Sn–1c structured all ones or AIS signal will be output towards the Sn–X– L_CP. In the Source adaptation There are no changes. After the Sink has been provisioned the configuration situation is as shown in Figure 8.5. (Shading indicates the active differential delay buffers ; this indication of active delay buffers and also active VLI inserters is used in all figures of these exercises.)

8.2.3 Step c: provision the Source In the final step of this exercise, the Source is configured by the NMS to use the outputs 1, 3 and 5 (So_MI_ProvM[1, 3, 5] ¼ 1). There are two distinctive stages in this step. In the first stage, the Source will notify the

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

MAX

X AT

2

3

4

5

6 Sn

Figure 8.5

UNEQ

1

VCG initiation step b

2

3

4

5

6 Sn

183


Sink of the addition and the Sinks acknowledges it is ready to accept the addition. In the second stage, the Source starts transmitting the payload received at its input and the Sink will output the received payload. In the Source adaptation (stage 1) LCAS Source Engine -

In the first stage of the addition the inputs are: i So_MI_ProvM[i]

-

1

2

3

4

5

1

0

1

0

1

3

4

1

1

SQ

0

1

2

So_RI_RS-Ack_rec So_RI_MST_rec[SQ]

1

1

1

6 0

5

0 1

The LCAS engine will calculate and set the following parameters in the Source adaptation function: i _CTRL[i] _SQmap[i]

1

2

ADD 0

IDLE (max)

3

4

ADD IDLE 1 (max)

1

2

3

5

6

ADD 2

IDLE (max)

SQ

0

4

5

_XAT _So_PC[SQ]

0 (there are no active members) 0 0 0 0 0 0

Distribution. Since _XAT ¼ 0 and _So_PC[SQ] ¼ 0 for all VCG members, all outputs will transmit an all-zero payload signal. Trail selection. Will connect input _SQmap[i] for i ¼ 1. . .XMT to output i, e.g. VLI inserter SQ-0 to output 1, SQ-(max) to output 2, etc.

184


As a result, the Source will output Sn structured trail signals Sn_AI at all its Sn_AP. All the Sn_AI[1. . .XMT] signals will have a valid VLI overhead structure. The CTRL words will be ADD for Sn_AI[1, 3, 5] and IDLE for the rest of the outputs. The Source process is now waiting for an acknowledgement from the Sink that the above changes have been detected, i.e. wait for So_RI_MST_rec[0, 1, 2] ¼ 0. In the Sink adaptation (stage 1) The VCG Sink will detect that the additional, or in this case initial, members of the VCG are becoming active and will take the actions defined by the LCAS procedure. Differential delay. No change. LCAS Sink Engine - The inputs to this process are the changes of the CTRL words from IDLE to ADD and the assigned SQ numbers: i

1


-


2

3

4

5

6

1 false false false bb true ADD 2


1 false false false dd true ADD 0

1 false false false ee true ADD 1


This process will now change the following outputs: i

1

2

3


n/a

bbb

n/a


4

5

6

ddd

eee

n/a

2

0

1

2

0

0

0

3

4

5

0

0

0

1

1

1

0 0 0

0

0

185


-

Because there are now three members with a valid VLI, one of these can be selected as the source for the RS-Ack and MST information of the companion VCG. For this exercise the value 2 is chosen, but 4 or 5 could also have been selected for the Sk_RI_selector value. Re-alignment. This process will connect input 2 to output 2, input 4 to output 0 and input 5 to output 1 based on the received and validated _SQv[i]. For the other outputs, this process will insert allzero path-layer signals. Assembly. Since _Sk_PC[0. . . (XMR 1)] ¼ 0 and _XAR ¼ 0, this process output an Sn–1c structured signal with an all-zero payload area and a valid path overhead derived from the Sn_AI[2, 4, 5] signals. The result is that the VCG Sink has detected the addition of members and notified the Source by sending MST ¼ OK for these new members. The situation of the configuration after the first stage of step c is shown in Figure 8.6.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

MAX

X AT

2

3

4

5

6 Sn

UNEQ

1

2

3

Figure 8.6 VCG initiation stage 1 of step c

4

5

6 Sn

186


In the Source adaptation (stage 2) The second stage of the addition starts when the Source receives the expected MST ¼ OK of the added members. LCAS Source Engine - At the start of the second stage the inputs are: i So_MI_ProvM[i]

1

2

3

4

5

1

0

1

0

1

SQ So_RI_RS-Ack_rec So_RI_MST_rec[SQ]

-

1

2

0

0

0

0

3

4

5

1

1

1

0

Assuming that So_RI_MST_rec[0, 1, 2] ¼ 0 are received in the same MST multiframe, there is no reason to re-assign the SQ numbers. The LCAS engine will now calculate and set the following parameters in the Source adaptation function: i

_CTRL[i] _SQmap[i]

1 NORM 0

SQ _XAT _So_PC[SQ]

-

0

6

2

3

4

5

6

IDLE (max)

NORM 1

IDLE (max)

EOS 2

IDLE (max)

0

1

2

1

1

1

3

4

0

0

5

3 0

Since the additional members become active now, the total of SQ numbers changes and consequently the Source Engine will stop processing new MST values until an RS-Ack has been received confirming that the Sink has detected the activation of the three new members. To prevent a deadlock situation in case the RS-Ack is lost or not generated, an RS-Ack_timeout timer is started. The expiry of this timer will also be used as a confirmation (i.e. RS-Ack imitation).

187


Distribution. Since _XAT ¼ 3, this process will distribute the Sn–3c structured Sn–X–L_CI_D information octet by octet over its outputs. Because _So_PC[0,1,2] ¼ 1 the distributed payload will be output to the first three VLI inserters, i.e. one octet is sent to output 0, the next octet is sent to output 1, the next octet is sent to output 2, the next octet is sent to output 0, etc. Trail selection. No change from stage 1 of step c. As a result, the Source will produce three path-layer signals Sn_AI[1, 3, 5] containing the distributed payload from Sn–X–L_CI_D and three non-payload-carrying (all-zero) path-layer signals Sn_AI [2, 4, 6]. The Sn–AI[1. . .XMT] signals will have a valid VLI overhead structure, a NORM, EOS or IDLE control word and Sn_AI_OH bytes equal to those in the Sn–X–L_CI_OH. Figure 8.7 shows the moment where the bandwidth will change (in general: increase or decrease). It is the moment between the Sn–Xv structured frame that contains the last bit/byte of the VLI and the next Sn–Xv frame (containing the first bit/byte of the VLI). In the Sink adaptation (stage 2) The LCAS Sink engine will detect that the added members have become active and will carry payload. It will start re-assembly of the original client payload. Differential delay. No change. LCAS Sink Engine

control packet last bit VLI i.e. CRC LSB

Sn frame

adjust bandwidth here control packet first bit VLI

Figure 8.7

Sn frame

LCAS bandwidth adjustment moment

188


-

The inputs to this process will contain the changed CTRL words:

i

1


-


2

3

4

5

6

1 false false false bb true EOS 2


1 false false false dd true NORM 0

1 false false false ee true NORM 1


In the VLI of members 2, 4 and 5, this process will now detect the CTRL word NORM/EOS and the associated SQ number, and consequently toggle the RS-Ack bit. Other outputs will change too: i

1

2


n/a

bbb


3

4

n/a

5

ddd

6

eee n/a

2

0 1 0

1

2

3

4

3 1 0 0 0 ¼>1 (toggle) 0 0 1 1 1

5 0 1

Re-alignment. No change, because the assigned SQ numbers did not change. Assembly. Since _XAR ¼ 3 and _Sk_PC[0, 1, 2] ¼ 1, this process will recover an Sn–3c structured payload signal by interleaving the 3 path-layer signals at its inputs 0, 1 and 2. The path overhead is derived from Sn_AI[2, 4, 5]. The moment the client payload contains valid information is indicated in Figure 8.7.

189


In the Source adaptation (stage 2) LCAS Source Engine - The only input that changes is the expected RS-Ack (or the expiry of the RS-Ack_timeout timer): i So_MI_ProvM[i]

-

1

2

3

4

5

1

0

1

0

1

SQ

0

1


0

0

2

3

6 0

4

5

0 )1 (toggled) 0 1 1

1

The LCAS engine will now continue evaluating the received MST values. None of the outputs changes. i

1

_CTRL[i] _SQmap[i]

NORM 0

2

3

4

5

6

IDLE (max)

NORM 1

IDLE (max)

EOS 2

IDLE (max)

SQ

0

1

2

_XAT _So_PC[SQ]

1

1

1

3

4

0

0

5

3 0

Distribution. No change. Trail selection. No change. The situation of the configuration, as it is after the second stage of the initiation of a VCG containing (in this exercise) three members, is shown in Figure 8.8.

8.3 EXERCISE 2: ADDITION OF A MEMBER In this second exercise, a member will be added to the three member VCG that was created in Exercise 1 in Section 8.2. It starts with the configuration depicted in Figure 8.8.

190


Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

MAX

X AT

2

3

4

5

6 Sn

Figure 8.8

UNEQ

1

2

3

4

5

6 Sn

VCG initiation final configuration

There are three steps that need to be performed by the NMS to achieve this goal: Step a: provision the Sink to add a member (i.e. member 1); Step b: provision the path-layer connectivity, i.e. establish the additional member’s path through the network (i.e. from So member 6 to Sk member 1); and Step c: provision the Source to add a member (i.e. member 6). (These three steps can be taken in any order. This particular exercise will show the order as mentioned above.)

8.3.1 Step a: provision the Sink First the Sink is provisioned by the NMS to add a new member. Since the (sub)network connectivity has not yet been provided the additional member trail termination function Sn will continue to

191


receive the UNEQ signal. The status of the system will become as follows. In the Sink adaptation The LCAS Sink engine will receive from the NMS the signal Sk_MI_ ProvM[1] ¼ 1 and, because this member still receives the UNEQ signal, there will be no change. Differential delay. No change. LCAS Sink Engine - The only input that will change is Sk_MI_ProvM[1]. i

1



-

2

3



4

5

6




None of the outputs will change: i

1


n/a

2

3

bbb

n/a


Re-alignment. No change. Assembly. No change.

4

5

6

ddd

eee

n/a

2

0

1

2

1

1

1

3

4

5

0

0

0

1

1

1

3 1 0

0

0

192


In the Source adaptation Nothing will change. The situation of the configuration has not changed, the configuration shown in Figure 8.8 is still valid. The provisioning of member 1 in the Sink has no effect in the Source adaptation and in the Sn subnetwork connectivity.

8.3.2 Step b: provision the connectivity In this particular exercise the connectivity through the network is established after the Sink has been provisioned. In the Sn subnetwork In this step, one additional trail is provisioned by the NMS: from Source member 6 to Sink member 1, providing a connecting from the Sn_CP[6] of the Source VCG to the Sn_CP[1] of the Sink VCG (see Figure 8.9). This connection replaces the connection at the Sink side from the Sn_CP[1] to the UNEQ Sn_CP.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

MAX

X AT

2

3

4

5

6 Sn

Figure 8.9

UNEQ

1

2

Member addition stage b

3

4

5

6 Sn

193


In the Sink Adaptation Differential delay. The Sink will now be able to use the MFI of the valid VLI that is transferred by the additional member trail. This process will now include this MFI in the calculation of _D[i] necessary to compensate the differential delay. Assuming the relative delays among the considered members are within the allowed (defined by implementation) range, the defect dMND[i] will not be raised. LCAS Sink Engine - The inputs to this process will change as indicated: i

1


-

1 false false false aa true IDLE (max)

2

3

4

5

6






This process will now detect in the VLI of member 1 the CTRL word IDLE and change the following outputs: i

1


aaa

2

3

bbb

n/a

4

5

6

ddd

eee

n/a

2



0

1

2

1

1

1

3

4

5

0

0

0

1

1

1

3 1 0

0

0

194


In the Source adaptation Nothing changes. As a result, the Sink will see the IDLE status of the member that is about to be added. The only change is the incorporation of the additional member for delay calculation. The current configuration is shown in Figure 8.9.

8.3.3 Step c: provision the Source Finally, the Source is provisioned, i.e. the NMS sets MI_ProvM[6] ¼ 1 and the status of the system will change in two stages. In the first stage, the Source is provisioned and will inform the Sink by sending the ADD control word; the Sink acknowledges the reception by sending MST ¼ OK for the additional member. In the second stage, the Source will start using the payload of the added member and the Sink will follow and increase the bandwidth too. In the Source adaptation (stage 1) LCAS Source Engine - After the reception of the ADD command from the NMS, the inputs are: i So_MI_ProvM[i]

1

2

3

4

5

1

0

1

0

1


-

0

1

2

0

0

0

6 1

3

4

5

1

1

1

1

The LCAS engine will now calculate and set the following parameters in the Source adaptation function:

i _CTRL[i] _SQmap[i]

1 NORM 0

2

3

4

5

6

IDLE (max)

NORM 1

IDLE (max)

EOS 2

ADD 3

195

The LCAS Procedure Exercised SQ _XAT _So_PC[SQ]

0

1

2

1

1

1

3

4

0

0

5

3 0

Distribution. No change. Since XAT ¼ 3, this process will continue to distribute the Sn–3c structured Sn–X–L_CI_D information over its outputs 0, 1 and 2. Trail selection. Will change the connection of output 6 to input _SQmap[6] for the provisioned additional member. As a result, the Source adaptation function will start to transmit a non-payload-carrying path-layer signal Sn_AI[6]. This signal will have a valid VLI overhead structure, the CRTL word ADD and Sn_AI_OH bytes equal to those in the Sn–X–L_CI_OH. All other Sn–AI[i] signals will remain the same. The Source process will now wait until the Sink acknowledges the reception of the additional member. This situation is shown in Figure 8.10.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

MAX

X AT

2

3

4

5

6 Sn

Figure 8.10

UNEQ

1

2

3

4

5

6 Sn

Member addition stage 1 of step c, Source provisioned

196


In the Sink adaptation (stage 1) The Sink will detect the change of the CTRL word from IDLE to ADD and will take the appropriate actions. Differential delay. No change. The MFI of the added member is already taken into account when the differential delay of the VCG is calculated. LCAS Sink Engine - The following inputs to this process will change: i

1


1 false false false aa true ADD 3

-

2

3



4

5

6




This process will now detect in the VLI of member 1 the CTRL word ADD and the assigned SQ number, and change the following outputs: i

1


aaa

2

3

bbb

n/a

4

5

6

ddd

eee

n/a

2


0

1

2

1

1

1

3

4

5

0

0

0

0

1

1

3 1 0

0

0

Re-alignment. This process will connect input 1 to output 3 based on _SQv[i]. For the other outputs nothing changes. Assembly. No changes from previous step, since member 1 is still in the ADD state, hence _Sk_PC[3] ¼ 0.

197


Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

2

3

4

5

Figure 8.11

MAX

X AT

1

UNEQ

6 Sn

2

3

4

5

6 Sn

Member addition stage 1 of step c, sink provisioned

As a result, the Sink will see the CTRL ¼ ADD request from member 1. It will respond by sending MST ¼ OK to indicate that it is ready take member 1 with SQ ¼ 3 into service. See Figure 8.11 for the configuration. In the Source adaptation (stage 2) The Source will now detect and interpret the changed MST value of the additional member. LCAS Source Engine - In the second stage of the step c the inputs are:

i So_MI_ProvM[i]

1

2

3

4

5

1

0

1

0

1

6 1

198

Next Generation SDH/SONET SQ So_RI_RS-Ack_rec So_RI_MST_rec[SQ]

-

0

1

2

0

0

0

3

4

5

0

1

1

1

Since only a single member is added there is no reason to reassign the SQ numbers. The LCAS engine will calculate and set the following parameters in the Source Adaptation function:


1 NORM 0

SQ _XAT _So_PC[SQ]

2

3

4

5

6

IDLE (max)

NORM 1

IDLE (max)

NORM 2

EOS 3

0

1

2

1

1

1

3

4

1

0

5

4 0

-

Because the additional member becomes active now, the total of SQ numbers changes and consequently the Source Engine will stop processing new MST values until an RS-Ack (or an RSAck_timeout timer expiry) has been received confirming that the Sink has detected the activation. Distribution. Since _XAT ¼ 4, this process will distribute the Sn–4c structured Sn–X–L_CI_D information over the outputs 0, 1, 2 and 3. Trail selection. No change. As a result, the Source will produce four path-layer signals at Sn_AI[1, 3, 5, 6] containing the distributed payload from Sn–X– L_CI_D and non-payload-carrying path-layer signals at the remaining Sn_AI[2, 4]. All Sn_AI[i] signals will have a valid VLI overhead structure, a sequence number according to _SQmap[i], an NORM, EOS or IDLE control word and Sn_AI_OH bytes equal to those in the Sn–X–L_CI_OH. The timing of the change in the payload size is depicted in Figure 8.7.

199


In the Sink adaptation (stage 2) In the second stage the LCAS Sink Engine will detect that the added member becomes active and starts re-assembly of the original client payload. Differential delay. No change. LCAS Sink Engine - The following inputs will have changed: i

1


1 false false false aa true EOS 3

-

2

3

1 false false false bb true NORM 2


4

5

6




This process will now detect that the total of SQ numbers has changed, i.e. the changed CTRL in the VLI of members 1 and 2, and toggle the RS-Ack bit, the following outputs are changed too: i

1


aaa

2

3

bbb

n/a


4

5

6

ddd

eee

n/a

2

0

1

1

1

0

2

3

4

4 1 1 0 1 ¼> 0 (toggle) 0 0 0 1

5 0 1

Re-alignment. No change from the status in stage 1. Assembly. Since now _XAR ¼ 4, this process will recover an Sn–4c structured payload signal by interleaving the four path-layer signals at its inputs 0, 1, 2 and 3 and a valid path overhead derived from Sn[1, 2, 4, 5].

200


In the Source adaptation(stage 2) LCAS Source Engine - Processes the following inputs: i So_MI_ProvM[i]

1

2

3

4

5

1

0

1

0

1


-

6 1

0

1

2

3

4

5

0

0

1¼> 0 0 0

1

1

Will detect the toggled RS-Ack (or RS-Ack_timeout timer expiry) and continues processing the MST. i

1

_CTRL[i] _SQmap[i]

NORM 0

2

3

4

5

6

IDLE (max)

NORM 1

IDLE (max)

NORM 2

EOS 3

SQ

0

1

2

_XAT _So_PC[SQ]

1

1

1

3

4

1

0

5

4 0

Distribution. No change. Trail selection. No change. As a result, the Sink will accept the new member as an active member and start using its payload at the point in time indicated in Figure 8.7. The situation of the configuration is shown in Figure 8.12.

8.4 EXERCISE 3: REMOVAL OF A MEMBER In this third exercise, a member is removed from the four member VCG created in Exercise 2 in Section 8.3. The configuration at the end of Exercise 2 is used as the starting point for this exercise (see Figure 8.12).

201


Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

MAX

X AT

2

3

4

5

6 Sn

Figure 8.12

UNEQ

1

2

3

4

5

6 Sn

Member additiion final configuration

There are three steps that need to be taken by the NMS to achieve this goal: Step a: provision the Source to remove a member (i.e. member 5); Step b: provision the Sink to remove a member (i.e. member 2); and Step c: de-provision the path-layer connectivity, i.e. delete the removed member’s path through the network (i.e. from So member 5 to Sk member 2). (Although these three steps can be taken in any order, it is recommended to always remove the member at the Source first (step a). This guarantees a hitless decrease of the available payload bandwidth. This particular exercise will show the order as mentioned above.)

8.4.1 Step a: provision the Source For this exercise it will be assumed that the Source provisioning is done first (as recommended by the standard). If the member to be

202


removed is, for example, member 5 (i.e. MI_ProvM[5] ¼ 0), the status of the system will become as follows. In the Source adaptation LCAS Source Engine - After receiving the remove message from the NMS the inputs are: I So_MI_ProvM[I]

-

-

2

3

4

5

1

0

1

0

0

SQ

0

1

2


0

0

0

6 1

3

4

5

0

1

1

0

since a single member is removed from the VCG that is not the member with the highest valid SQ number, the SQ of some members will be re-assigned (i.e. the SQ number of the members with an SQ larger that the SQ number of the member that is removed will be decremented by 1). The LCAS engine will now calculate and set the following parameters in the Source adaptation function: i

1

_CTRL[i] _SQmap[i]

-

1

NORM 0

2

3

4

5

6

IDLE (max)

NORM 1

IDLE (max)

IDLE (max)

EOS 2

SQ

0

1

2

_XAT _So_PC[SQ]

1

1

1

3

4

0

0

5

3 0

Because a member is removed now, the total of SQ numbers changes and consequently the Source Engine will stop processing new MST values until an RS-Ack has been received (or an RS-Ack_timeout timer expiry) confirming that the Sink has detected the removal.

203


Distribution. Since _XAT ¼ 3, this process will distribute the Sn–3c structured Sn–X–L_CI_D information over its outputs. The payload transport capability has decreased by the payload area of an Sn structure. Because _So_PC[3] changed from 1 to 0, the connection to output 3 is removed and output 3 will transmit an all-zero payload signal. Trail selection. Will just connect output 5 to input _SQmap[(max)] for the removed member. As a result, the Source will stop mapping payload onto Sn_AI[5] and notify the client layer processes of the reduction of the available bandwidth (send _XAR ¼ 3). This client bandwidth will be mapped onto the three remaining provisioned members. For Sn_AI[5], a signal with an IDLE control word and an SQ number (max) will be sourced, indicating to the Sink that this member does no longer carry payload. The change in the payload size will be timed according Figure 8.7. In the Sink adaptation Differential delay. No changes from the last exercise, since the provisioned membership is still the same. LCAS Sink Engine - Among the inputs to this process, the only ones that have changed will be the new received control words and re-assigned SQ numbers due to the member that was removed at the Source: I

1



-

2 1 false false false bb true IDLE (max)


4

5

6




This process will now detect in the VLI of member 2 the CTRL word IDLE and the SQ number (max) and will remove that member from the set of payload carrying members. The following outputs are changed:

204

Next Generation SDH/SONET i

1


aaa

2

3

bbb

n/a

4

5

6

ddd

eee

n/a

1


0

1

1

1

2

3

4

3 1 0 0 0 ¼ >1 (toggle) 0 0 1 1

0

5 0 1

-

The Sk_RI_selector has been changed because member 2 cannot provide the required RS-Ack and MST information of the companion VCG. Re-alignment. This process will remove the connection from input 2 to output 2 and change the connection of input 1 from output 3 to output 2. The inputs 4 and 5 will remain connected to outputs 0 respectively 1. Assembly. Since _XAR ¼ 3, this process will recover an Sn–3c structured signal by interleaving the 3 path-layer signals at its inputs 0, 1 and 2. The Sink will toggle the RS-Ack bit because the sequence numbering has changed, i.e. decreased by one. (In the specific case that the removal concerns a member that experiences a network fault (see Exercise 4 in Section 8.5), the Source sends CTRL word DNU AND it is the member with the highest SQ number in the VCG, the Sink will not detect a change in the sequence numbering and consequently does not toggle the RS-Ack bit. Now the Source has to wait for the expiry of the RS-Ack_timeout timer before continuing the MST processing. In the Source adaptation LCAS Source Engine - The following inputs change: I So_MI_ProvM[I]

1

2

3

4

5

1

0

1

0

0

6 1

205

The LCAS Procedure Exercised SQ So_RI_RS-Ack_rec So_RI_MST_rec[SQ]

-

0

1

0

0

2

3

4

5

0 )1 (toggle) 0 1 1

1

The toggled RS-Ack is detected (or the RS-Ack_timeout timer expires) and the Source engine continues processing the MST. i

1

_CTRL[i] _SQmap[i]

NORM 0

2

3

IDLE (max)

NORM 1

SQ

0

1

2

_XAT _So_PC[SQ]

1

1

1

4

5

6

IDLE (max)

IDLE (max)

EOS 2

3

4

0

0

5

3 0

Distribution. No change. Trail selection. No change. As a result, the Sink will stop accepting payload from the removed member currently sending IDLE in the control word and will reduce the bandwidth forwarded towards the client layer via the Sn–X–L_CP. The moment of reducing the bandwidth is shown in Figure 8.7. Since the member is still provisioned, it is still taken into consideration for realignment and its VLI is still analysed for LCAS purposes. This situation is shown in Figure 8.13.

8.4.2 Step b: provision the Sink Assuming the Sink is updated next to remove the member (by setting Sk_MI_ProvM[2] ¼ 0), the status of the system will become as follows. In the Sink adaptation Differential delay. Even though member 2 has been removed as a provisioned member, it is still connected through the network to

206


Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

2

3

4

5

MAX

X AT

2

3

4

5

6 Sn

1

1

UNEQ

Figure 8.13

1

2

3

4

5

6 Sn

Member removal step a

the Source and receives a valid MFI. This MFI will continue to be used for the calculation of the differential delay _D[2]. LCAS Sink Engine - Among the inputs to this process, the only ones that will change will be the ones related to the member that was removed at the Source: i

1



-

2 0 false false false bb true IDLE (max)


4

5

6




This process will now stop processing the VLI of member 2, however, there is no change in any output:

207

The LCAS Procedure Exercised i

1


aaa

2

3

bbb

n/a

4

5

6

ddd

eee

n/a

1 SQ

_XAR _Sk_PC[SQ] Sk_RI_RS-Ack_gen Sk_RI_MST_gen[SQ]

0

1

2

1

1

1

3

4

5

0

0

0

1

1

1

3 1 0

0

0

Re-alignment. No change, since _SQv[i] did not change. Assembly. No change, since _Sk_PC[SQ] did not change. In the Source adaptation Nothing will change for the Source inputs and outputs. As a result, the Sink will just stop considering Sn_AI[2] for transporting payload. This situation is shown in Figure 8.14.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

MAX

X AT

2

3

4

5

6 Sn

Figure 8.14

UNEQ

1

2

Member removal step b

3

4

5

6 Sn

208


8.4.3 Step c: remove the connectivity In the final step, the connectivity for the removed member is deleted by the NMS. The state of the system only changes slightly as shown below. In the Sn subnetwork In this step, the NMS provisions the subnetwork to remove trail connection between the two removed members: from Source member 5 to Sink member 2, i.e. removing the connecting from the Sn_CP[5] of the Source VCG to the Sn_CP[2] of the Sink VCG (see Figure 8.15). A connection will be made at the Sink side from the Sn_CP[2] to the UNEQ Sn_CP as defined by recommendation G.783.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

2

3

4

5

MAX

X AT

6 Sn

UNEQ

1

2

3

4

Figure 8.15 Member removal final configuration

5

6 Sn

209


In the Sink adaptation Differential delay. The only change is that now AI_TSF[2] is present because the member Sn–TT receives the UNEQ signal. As the MFI cannot be retrieved anymore the member will no longer be considered for calculating the differential delay, and consequently dLOM[2] ¼ true will be declared for this member. LCAS Sink Engine - The inputs for this process that will change are the ones related to the member trail that was removed in the network: i

1



-

2

3



4

5

6




This process will detect the TSF of member 2, but since the member was already removed from the Sink VCG in the previous step, none of the outputs will change: i

1


aaa

2

3

bbb

n/a

5

6

ddd

eee

n/a

1


Re-alignment. No change. Assembly. No change. In the Source adaptation No changes.

4

0

1

2

1

1

1

3

4

5

0

0

0

1

1

1

3 1 0

0

0

210


As a result the Sink will receive the AI_TSF[2] ¼ true but, since this member was not provisioned for service, the visible behaviour of the function will not change. Figure 8.15 shows the condition of the configuration when the removal of a member is completed.

8.5 EXERCISE 4: MEMBER FAILURE When an active member fails due to a problem in the network, the LCAS protocol will temporarily remove that member—and even more specifically its corrupted payload—from service, and continues operation with a reduced set of active members. In this exercise, using the VCG as it exists at the end of Exercise 3 in Section 8.4 (see also Figure 8.15), the failure of one of the members is exercised. Assuming the member signal arriving at the VCG Sink at Sn_AI[5] fails as indicated in Figure 8.16 by an X (i.e. the signal is affected completely), the following events will happen.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

2

3

4

5

Figure 8.16

MAX

X AT

6 Sn

UNEQ

1

2

3

4

Additional connectivity provisioned

5

6 Sn

211


In the Sink adaptation Differential delay. The trail termination of member 5 will detect the network failure and output an Sn_AI_D[5] ¼ AIS signal with an Sn_AI_TSF[5] ¼ true, and consequently dLOM[5] ¼ true will be declared for this member. For the remaining two Sn_APs for which MI_ProvM[i] ¼ 1 and Sn_AI_TSF[i] ¼ false (i ¼ 1, 4), this process will continue to calculate _D[i] as it did before. For i ¼ 5, as well as for the other members, AI_TSF[i] is active and therefore MI_DMFI[i] ¼ n/a, _D[i] ¼ 0. In other words, Sn_AI[5] will no longer be considered for multiframe alignment and differential delay compensation. LCAS Sink Engine - Among the inputs to this process, the only ones that will change will be the ones related to the member path that was affected by the network failure: i

1



-

-



4

5

6


1 true false true 0 false (NORM) (1)


This process will now detect the raised TSF of member 5; it will remember the last valid CTRL word (NORM) and SQ number (1) of this affected member. The following outputs are changed: _XAR and _Sk_PC[5] to discard the payload of member 5; the signal output to the Sn–X–L_CP will be corrupt because the Source is still using the payload area of member 5 for transport. This condition will last until the Source receives the MST ¼ FAIL for member 5 and starts transmitting CTRL word DNU for this member. The Sink will send the signal MST ¼ FAIL to the Source indicating that a failure was detected for the member with sequence number SQ ¼ 1. The following outputs are changed to inform the Source of the detected problem:

212

Next Generation SDH/SONET i

1


aaa

2

3

bbb

n/a

4

5

6

ddd

n/a

n/a

1


0

1

2

1

0

1

3

4

5

0

0

0

1

1

1

2 1 0

1

0

Re-alignment. No change. The SQ of the failed member is remembered: _SQv[5] ¼ (1). Assembly. Since _Sk_PC[1] ¼ 0 and _XAR ¼ 2, this process will recover an Sn–2c structured signal by interleaving the 2 path-layer signals at its inputs 0 and 2. As a result, the Sink will stop accepting payload from the failed member signal Sn_AI[5] and will reduce the bandwidth forwarded towards the client layer. At the same time, it will start signalling towards the Source that a failure was detected for sequence number 1. This transient situation is shown in Figure 8.17. (Since the Source is still sending an Sn–3c structured signal the reconstructed Sn–2c signal will be corrupt (will experience a hit) as long as the Source does not adjust the size of the transported bandwidth.) In the Source Adaptation The following reaction will happen at the Source as soon as it receives the MST ¼ FAIL for the affected member as is reported by the Sink. LCAS Source Engine - After receiving So_RI_MST_rec[1] ¼ 1 the inputs are:

I So_MI_ProvM[i]

1

2

3

4

5

1

0

1

0

0

6 1

213


Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

X AT

0

1

1

2

3

4

2

3

4

5

5

MAX

==

6 Sn

1

UNEQ

2

3

4

5

6 Sn

Figure 8.17 Member failure detected at Sink


-

-

0

1

2

0

1

0

3

4

5

1

1

1

1

Because the payload of the affected member is already discarded at the Sink, the Source will reduce its bandwidth for transport by the remaining members. The affected member will be set to transmit CTRL word DNU and an all-zero payload. The LCAS engine will now calculate and set the following parameters in the Source adaptation function:


1 NORM 0

2 IDLE (max)

3 DNU 1

4

5

6

IDLE (max)

IDLE (max)

EOS 2

214

Next Generation SDH/SONET SQ _XAT _So_PC[SQ]

0

1

2

1

0

1

3

4

5

0

0

0

2

Distribution. Since _So_PC[1] ¼ 0 and _XAT ¼ 2, this process will distribute the Sn–2c structured Sn–X–L_CI_D information over its outputs 0 and 2. The payload transport capability has decreased by the payload area of one Sn structure. Trail selection. No change. As a result, the Source will stop mapping payload onto Sn_AP[3] and will reduce the accepted bandwidth from the client layers. The remaining client bandwidth will be mapped onto the two provisioned, non-failed members. The Sn_AI[3] signal will be sourced with a CTRL word DNU, a sequence number as per _SQmap[3] and an all-zero payload, indicating to the Sink that this member does no longer carry payload. This situation is shown in Figure 8.18. The timing of the

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

X AT

0

1

1

2

3

4

5

2

3

4

5

Figure 8.18

MAX

==

6 Sn

UNEQ

1

2

3

4

Member failure temporary configuration

5

6 Sn

215


change in the payload size is shown in Figure 8.7. As the Sink did already reduce the bandwidth by discarding the bandwidth of the failed member, it is only using the total bandwidth of the two remaining members. The transported client signal will be faultless again as soon as the change in bandwidth initiated at the Source has reached the Sink.

8.6 EXERCISE 5: MEMBER RECOVERY When a failed member recovers, the LCAS protocol reinstates that member into service, continuing operation with the original planned set of active members. In this scenario, the recovery of one of the members is exercised. Assume the situation is as described at the end of Exercise 4 in Section 8.5. Then, the network problem experienced by the member arriving at the Sink via Sn_AP[5] is repaired (see Figure 8.19). Again the Sink will receive a valid VLI that will be processed.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L

X AR

0

1

1

2

3

4

5

MAX

X AT

2

3

4

5

6 Sn

Figure 8.19

UNEQ

1

Network recovered

2

3

4

5

6 Sn

216


In the Sink adaptation Differential delay. The clearing of both Sn_AI_TSF[5] and dLOM[5] will be detected. Now, the process is able to calculate again for the three members (i ¼ 1, 4, 5) with MI_ProvM[i] ¼ 1 and Sn_AI_TSF[i] ¼ false, the differential delay_D[i] as required. In other words, Sn_AI[5] will be considered again for MFI extraction. LCAS Sink Engine - The only input that will change will be the one related to the member trail that was affected by the network failure and has been repaired: i

1



-

2

3



4

5

6


1 false false false ee true DNU 1


This process will now detect the cleared TSF of member 5 and change the outputs, i.e. the Sink will start transmitting the signal Sk_RI_MST_gen[1] ¼ 0 to the Source indicating that the failure was repaired for the member 5 with SQ number 1. i

1


aaa

2

3

bbb

n/a


4

5

6

ddd

eee

n/a

1

0

1

2

1

0

1

3

4

5

0

0

0

1

1

1

2 1 0

0

0

217


Re-alignment. No change. Assembly. Since there are no changes in _PC[i] or _XAR, this process continues recovering an Sn–2c structured signal by interleaving the two path-layer signals at the inputs with _So_PC [SQ] ¼ 1. As a result, the Sink will start considering the recovered member Sn_AI[5] for realignment and LCAS purposes. At the same time, it will start signalling towards the Source that the failure condition was repaired for sequence number 1 indicated by its MST ¼ OK. The configuration has not changed, i.e. it is the same as depicted in Figure 8.19. In the Source adaptation The following will happen as soon as the Source receives the MST ¼ OK that is being reported by the Sink for the member with SQ number 1. LCAS Source Engine - After receiving So_RI_MST_rec[1] ¼ 0 the inputs are: i So_MI_ProvM[i]

1

2

3

4

5

1

0

1

0

0


-

0

1

2

0

0

0

6 1

3

4

5

1

1

1

1

The Source can now start using the payload of the repaired member and increase its bandwidth. The LCAS engine will calculate and set the following parameters in the Source adaptation function:


1 NORM 0

2 IDLE (max)

3 NORM 1

4

5

6

IDLE (max)

IDLE (max)

EOS 2

218

Next Generation SDH/SONET SQ _XAT _So_PC[SQ]

0

1

2

1

1

1

3

4

5

0

0

0

3

Distribution. Since _So_PC[1] ¼ 1 and _XAT ¼ 3, this process will distribute the Sn–3c structured Sn–X–L_CI_D information over its outputs 0, 1 and 2. Trail selection. No change. As a result, the Source will start mapping payload onto Sn_AP[3] (for the timing see Figure 8.7) and will enlarge the available bandwidth to the client layers. This client bandwidth will be mapped onto the three provisioned members. The Sn_AI[3] signal will contain a CTRL word NORM and a sequence number as per _SQmap[3], indicating to the Sink that this member again carries payload. As soon as these changes at the Source arrive at the Sink, the following will change at that function. In the Sink adaptation Differential delay. No change. LCAS Sink Engine - The only input that will change will be the one related to the member path that was affected by the network failure and was repaired: I

1



-



4

5

6




This process will now detect the CTRL word NORM of member 5 and change the following outputs:

219


1


aaa

2

3

bbb

n/a

4

5

6

ddd

eee

n/a

1 SQ

_XAR _Sk_PC[SQ] Sk_RI_RS-Ack_gen Sk_RI_MST_gen[SQ]

0

1

2

1

1

1

3

4

5

0

0

0

1

1

1

3 1 0

0

0

Re-alignment. No change. Assembly. Since _Sk_PC[1] ¼ 1 and _XAR ¼ 3, this process will recover an Sn–3c structured signal by interleaving the 3 pathlayer signals at its inputs 0, 1 and 2. As a result, the Sink will start accepting payload from the restored member’s Sn_AP[6] and will increase the bandwidth forwarded towards the client layer. This situation is shown in Figure 8.20. The timing of the increase in bandwidth is depicted in Figure 8.7.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L XAR

0 1 2 3 4 5

1

2

3

4

5

MAX

XAT

6

UNEQ

1

2

3

4

Sn

Figure 8.20

Final configuration after recovery

5

6

Sn

220


8.7 EXERCISE 6: NETWORK DEGRADED For this exercise, the parameter Sn–Xv/Sn–X–L_A_Sk_MI_TSDEnable should be set true. When an active member experiences bit errors and the threshold for the Trail Signal Degraded defect dTSD is crossed, the member (payload) will be removed from the VCG but not until the Source has been notified via the MST and has responded with the DNU signal. At that time the LCAS protocol removes that member from service and continues operation with a reduced set of active members. From the time the dTSD is raised until the CTRL word DNU is received, the reconstructed payload will have bit errors. It is assumed that these will be handled in the client layer, e.g. the FCS monitor in the Ethernet MAC drops only those Ethernet frames that are affected by bit errors, or a client can have built-in error correction capabilities. In this exercise, using the VCG as it exists at the end of Exercise 5 in Section 8.6 (see Figure 8.20), the degradation of one of the member trails is exercised. Assuming the member signal arriving at the VCG Sink at Sn_AI[5] degrades as indicated in Figure 8.21 by a dashed line, the following events will happen.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L XAR

0 1 2 3 4 5

1

2

3

4

5

MAX

XAT

6

UNEQ

1

2

4

5

6

Sn

Sn

Figure 8.21

3

Member path degraded

221


In the Sink adaptation Differential delay. The trail termination of member 5 will detect the network degradation and output Sn_AI_TSD ¼ true. The differential delay calculation will not change. LCAS Sink Engine: - Among the inputs to this process, the only ones that will change will be the ones related to the member trail that was affected by the degraded network: i

1



-

2

3



4

5

6


1 false true false ee true NORM 1


This process will now detect the raised TSD of member 5 and change the outputs accordingly, i.e. the Sink will send the signal MST ¼ FAIL to the Source to indicate that a failure was detected for the member 5 with SQ number 1. i

1


aaa

2

3

bbb

n/a

4

5

6

ddd

eee

n/a

1



0

1

2

1

1

1

3

4

5

0

0

0

1

1

1

3 1 0

1

0

222


Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L XAR

0 1 2 3 4 5

1

2

3

4

5

MAX

XAT

1

UNEQ

6

2

3

4

5

Figure 8.22

6

Sn

Sn

Member degraded detectd at sink

As a result, the Sink will continue accepting payload from the degraded member’s signal Sn_AI[5]. The experienced bit errors are supposed to be treated in the client layer. At the same time, it will start signalling towards the Source that a failure was detected for the member with SQ number 1. This temporary situation is shown in Figure 8.22. In the Source adaptation The following reaction will happen at the Source as soon as it receives the MST ¼ FAIL that is being reported by the Sink. LCAS Source Engine - After receiving So_RI_MST_rec[1] ¼ 1 the inputs are:

i So_MI_ProvM[i]

1

2

3

4

5

1

0

1

0

0

6 1

223

The LCAS Procedure Exercised SQ So_RI_RS-Ack_rec So_RI_MST_rec[SQ]

-

-

0

1

2

0

1

0

3

4

5

1

1

1

1

The Source will now reduce its bandwidth for transport by the not affected members. The affected member will be set to transmit CTRL word DNU and an all-zero payload. The LCAS engine will calculate and set the following parameters in the Source adaptation function:


1 NORM 0

SQ _XAT _So_PC[SQ]

2

3

IDLE (max)

DNU 1

0

1

2

1

0

1

4

5

6

IDLE (max)

IDLE (max)

EOS 2

3

4

0

0

5

2 0

Distribution. Since _So_PC[1] ¼ 1 and _XAT ¼ 2, this process will distribute the Sn–2c structured Sn–X–L_CI_D information over its outputs 0 and 2. The payload transport capability decreases by the payload area of one Sn structure. Trail selection. No change.

As a result, the Source will stop mapping payload onto Sn_AP[3] and will reduce the bandwidth available to the client layers. The available client bandwidth will be mapped onto the two remaining provisioned members. For Sn_AI[3], a signal with a DNU control word, a sequence number as per _SQmap[3] and all-zero payload will be sourced, indicating to the Sink that this member no longer carries payload. This situation is illustrated in Figure 8.23. The timing of the change of the payload size is shown in Figure 8.7.

224


Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L XAR

0 1 2 3 4 5

1

2

3

4

5

MAX

XAT

UNEQ

6

1

2

3

4

5

6

Sn

Sn

Figure 8.23 Member degraded compensated at source

In the Sink adaptation Differential delay. No change. LCAS Sink Engine - Will have as input: I

1

MI_ProvM[i] Sn_AI_TSF[i] Sn_AI_TSD[i] dLOM[I] _D[i] _CRC_ok[I] _CTRL[i] _SQv[i]


-



4

5

6


1 false true false ee true DNU 1


The Sink will continue signalling to the Source that a (degraded) failure was detected for sequence number 1. It will also detect the _CTRL[1] ¼ DNU and stop using the payload of that particular member:

225


1


aaa

2

3

bbb

n/a

4

5

6

ddd

eee

n/a

1


0

1

2

1

0

1

3

4

5

0

0

0

1

1

1

2 1 0

1

0

Re-alignment. No change. Assembly. No change. As a result, the Sink will now discard the payload from the degraded member Sn_AI[5] and transmit the reduced but error free payload to the client layer. This temporary situation is shown in Figure 8.24.

Sn-X-L/client

Sn-X-L/client

Sn-X-L

Sn-X-L XAR

0 1 2 3 4 5

1

2

3

4

5

MAX

XAT

6

UNEQ

1

2

3

4

5

Sn

Figure 8.24

Member degraded temporary configuration

6

Sn

226


The situation at the Source and the Sink is now similar to the situation at the end of Exercise 4 in Section 8.5. The recovery from this condition is identical to that of Exercise 5 in Section 8.6.

8.8 FOR FURTHER STUDY Other exercises, e.g. changing the configuration from LCAS-disabled to LCAS-enabled functions and from LCAS-enabled So to LCASdisabled functions, or the interworking between non-VCAT So and LCAS-capable Sk functions, are not provided in this book because they are not yet defined by any standard at the time of writing.

8.9 CONFIGURATION WITH LCAS DISABLED In case VCAT is deployed with LCAS disabled, the same configurations can be used as described in Section 8.1 with the following changes in the inputs.

input

value

Sn–Xv/Sn–X–L_A_So_MI_LCASEnable Sn–Xv/Sn–X–L_A_Sk_MI_LCASEnable

false false

and the outputs:

output Sn–Xv/Sn–X–L_A_Sk_MI_LCAS_So_Detected

value false

In this case the initial settings of the processes in the VCG adaptation function will not change during the lifetime of the connection. The LCAS disabled configurations can be depicted as shown below.

227


client to LCAS disabled VCG Adaptation Sn-X/client_A

Sn-X/client Sn-X

LCAS disabled VCG Trail TerminationSn-X_TT

distribution IDLE LCAS disabled VCG to member Adaptation Sn/Sn-X_A

VLI SQ SQ SQ SQ SQ SQ SQ = ins = 0 = 1 = 2 = 3 = 4 = 5 (max)

individual member Trail Terminations Sn-TT

Figure 8.25

VCG Source configuration – LCAS disabled

8.9.1 The VCG Source side configuration Figure 8.25 depicts the Source configuration when LCAS is disabled. The following particular settings are used (in this example the VCG contains six members, i.e. XMT ¼ 6). The input signal is distributed over all outputs: XAT ¼ XPT XMT. The CTRL word FIXED is inserted for all members 1. . .XMT. The following bits are set: GID ¼ 0 and CRC ¼ 0. For the companion VCG (in the opposite direction): RSAck_gen ¼ 0 and all MST_gen ¼ 0. All member Trail Terminations are used and connected to the VLI insertion process. LCAS-disabled Source Engine - It uses the following inputs:

i So_MI_ProvM[i]

1

2

3

4

5

1

1

1

1

1

6 1

228


-

It will not respond to the following inputs: SQ

0


-

1

2

n/a n/a

3

n/a

n/a n/a

4

5

n/a

n/a

It will always set the following outputs: i

1

_CTRL[i] _SQmap[i]

FIXED 0

2

3

FIXED 1

SQ

FIXED 2

0

_XAT _So_PC[SQ]

4

1

1

5

FIXED 3

2

3

FIXED 4

4

6 (for this example) 1 1 1 1

6 FIXED 5

5 1

8.9.2 The VCG Sink side configuration Figure 8.26 illustrates the Sink configuration when LCAS is disabled. The following particular settings are used: All members carry payload, i.e. _Sk_PC[0. . .(XMR 1)] ¼ 1. The output signal is reconstructed from all XAR ¼ XPR XMR inputs. LCAS-disabled Sink Engine - The following input values are used. i

1


1 false false false aa false FIXED 0

2 1 false false false bb false FIXED 1

3 1 false false false cc false FIXED 2

4

5

6

1 false false false dd false FIXED 3

1 false false false ee false FIXED 4

1 false false false ff false FIXED 5

229


LCAS disabled VCG to client signal Adaptation Sn-X/client_A

Sn-X/client Sn-X

LCAS disabled VCG Trail Termination Sn-X-TT

assembly

member to LCAS disabled VCG Adaptation Sn/Sn-X_A diff del

diff del

diff del

diff del

diff del

diff del

individual member Trail Terminations Sn-TT

Figure 8.26

-

VCG Sink configuration – LCAS disabled

The Sink will always output the following signals. Only calculated and compensated differential delay MI_DMFI[i] will be updated. i

1


aaa


2

3

bbb

ccc

4

5

6

ddd

eee

fff

...

(max)

...

1

...

0

n/a

0

1

1

1

0

0

2

3

6 (for this example) 1 1 0 0 0

Glossary ADM ANSI ASI ATM CBR CCAT cHEC CID C–m C–n C–n–Xc C–n–Xv CoS CPE CRC CTRL CSF DNE DNU DVB eHEC EOF EOS ESCON ETSI EXI

Add Drop Multiplexor American National Standards Institute Asynchronous Interface for DVB Asynchronous Transfer Mode Constant Bit Rate Contiguous Concatenated Core header HEC Channel Identification Payload Container of lower order m Payload Container of higher order n Cn Contiguous concatenated Cn Virtual concatenated Class of Service Customer Premises Equipment Cyclic Redundancy Check Control field sent from source to sink Client Signal Fail Data Network Element Do Not Use Digital Video Broadcast Extension header HEC End of Frame End of Sequence Enterprise Systems Connectivity European Telecommunication Standards Institute Extension Header Identifier


232

FC FCS FICON GFP GFP-F GFP-T GID HDLC HEC IEEE IP ISP ITU-T LAN LCAS LSB MAC MAN MFI MPLS MSB MST MSU-L NE NORM OA&M OCn ODUk OPUk OTN PDH PDU PFI PLI PoP PoS PTI PPP QoS RPR

Glossary

Fibre Channel Frame Check Sequence Fibre Connectivity Generic Framing Procedure Frame mapped GFP Transparent GFP Group Identification High-level Data Link Control Header Error Check Institute of Electrical and Electronic Engineers Internet Protocol Internet Service Provider International Telecommunication Union – Telecommunication Standardization Sector Local Area Network Link Capacity Adjustment Scheme Least Significant Bit Media Access Control Metro Area Network Multi-Frame Indicator Multi-Protocol Label Switching Most Significant Bit Member Status Member Signal Unavailable – LCAS criteria enabled Network Element Normal Operating Mode Operations, Administration & Maintenance SONET Optical Channel of order n Optical channel Data Unit of order k Optical channel Payload Unit of order k Optical Transport Network Pleisiochronous Digital Hierarchy Protocol Data Unit Payload FCS Identifier Payload Length Indicator Point of Presence Packet over SDH/SONET Payload Type Identifier Point-to-Point Protocol Quality of Service Resilient Packet Ring

233

Glossary

RS-Ack SAN SBCON SDH SDL Sk So SQ SSF SONET SPE SRC STM-n STS SSF TDM tHEC TNE TSD TSF TTI TTL UPI VBR VC–m VC–n VC–n–Xc VC–n–Xv VCAT VCG VLI VPN VTn WAN WDM

Re-Sequence Acknowledge Storage Area Network Single-Byte Command Code Sets Connection Synchronous Digital Hierarchy Simple Data Link Specification and Description Language Sink Source Sequence Indicator Server Signal Failure Synchronous Optical Network Synchronous Payload Envelop Source SDH Synchronous Transport Module of order n Synchronous Transport Signal Server Signal Fail Time Division Multiplex Type header HEC Transport Network Element Time Sequence Diagram Trail Signal Degrade Trail Signal Fail Trail Trace Identifier Time-to-Live User Payload Identifier Variable Bit Rate Virtual Container of lower order m Virtual Container of higher order n VC-n Contiguous concatenated with X members VC-n Virtual concatenated with X members Virtual Concatenated Virtual Concatenation Group VCAT/LCAS Information Virtual Private Network Virtual Tributary of order n Wide Area Network Wavelength Division Multiplex

References ITU-T Recommendation G.704 (10/1998), Synchronous frame structures used at 1544, 6312, 2048, 8488 and 44736 kbit/s hierarchical levels. ITU-T Recommendation G.707/Y.1322 (12/2003), Network node interface for the Synchronous Digital Hierarchy SDH. ITU-T Recommendation G.709/Y.1331 (03/2003), Network node interface for the Optical Transport Network (OTN). ITU-T Recommendation G.783 (02/2004), Characteristics of Synchronous Digital Hierarchy (SDH) Equipment Functional Blocks. ITU-T Recommendation G.798 (01/2002), Characteristics of optical transport network hierarchy equipment functional blocks. ITU-T Recommendation G.7042/Y.1305 (02/2004), Link Capacity Adjustment Scheme (LCAS) for Virtual Concatenated Signals. ITU-T Recommendation G.7041/Y.1303 (12/2003), Generic Framing Procedure (GFP). ITU-T Recommendation G.7043/Y.1343 (04/2004), Virtual Concatenation of Plesiochronous Digital Hierarchy (PDH) signals. ITU-T Recommendation G.806 (02/2004), Characteristics of transport equipment – Description methodology and generic functionality. ITU-T Recommendation G.832 (10/1998), Transport of sdh elements on pdh networks – Frame and multiplexing structures. ITU-T Recommendation G.8040/Y.1340 (04/2004), GFP frame mapping into Plesiochronous Digital Hierarchy (PDH). ITU-T Recommendation V.41 (11/1988), Code-independent error-control system. ITU-T Recommendation Z.100 (08/2002), Specification and description language (SDL). ETSI EN 300 417-1-1 v1.2.1 (10/2001), Generic requirements of transport functionality of equipment: Generic processes and performance. ETSI EN 300 417-4-1 v1.2.1 (10/2001), Generic requirements of transport functionality of equipment: SDH path layer functions.


236

References

ETSI EN 300 417-9-1 v1.1.1 (09/2001), Generic requirements of transport functionality of equipment: SDH concatenated path layer functions; requirements. ANSI T1.105 (2001), SONET – Basic description including Multiplex Structures, Rates and Formats. ANSI T1.105.2 (1999), Synchronous Optical Networks (SONET) – Payload Mappings. Telcordia GR-253-CORE, Rev. 3 (09/2000), SONET Common Generic Criteria. IEEE 802.3-2002, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications – 10M/100M/1G/ 10G Ethernet. ISO/IEC 3309:1993, Information Technology – Telecommunications and Information Exchange Between Systems – High-level Data Link Control (HDLC) Procedures – Frame Structure. ANSI X3.230-1994, Fibre Channel Physical and Signaling Interface (FC-PH). ANSI X3.296-1997, Information Technology – Single-Byte Command Code Sets Connection (SBCON) Architecture. ANSI INCITS 342-2001, Fibre Channel – Backbone (FC-BB). ANSI INCITS 372-2003, Fibre Channel – Backbone – 2 (FC-BB-2). IETF RFC 1661 (06/1994), The Point-to-Point Protocol (PPP). IETF RFC 1662 (07/1994), PPP in HDLC-like Framing. IETF RFC 2003 (10/1996), IP Encapsulation within IP. IETF RFC 2516 (02/1999), A Method for transmitting PPP over Ethernet (PPPoE). IETF RFC 2615 (06/1999), PPP over SONET/SDH (PoS). IETF RFC 3031 (01/2001), Multi-Protocol Label Switching Architecture. IETF RFC 3032 (01/2001), MPLS Label Stack Encoding. IETF RFC 3255 (04/2002), Extending PPP over SONET/SDH with Virtual Concatenation. High Order and Low Order payloads. ETSI (CENELEC): EN 50083-9: Cable distribution systems for television, sound signals and interactive multimedia signals; Part 9: Interfaces for CATV/SMATV Headends and Similar Professional Equipment for DVB/MPEG-2 transport streams (DVB Blue Book A010), Annex B, Asynchronous Serial Interface, 1998. IEEE 802.17-2004, IEEE Standard for Information Technology – Telecommunications and information exchange between systems – IEEE standard for local and metropolitan area networks – Specific requirements – Part 17: Resilient Packet Rings (RPR) Access Method and Physical Layer Specifications.

Index Adaptation function: GFP, 151 VCAT, 126 VCAT, LCAS capable, 142, 149 Add drop multiplexor, 2 Add member, 41, 72, 74 Alarm inhibit signal, 129 Assembly, 18, 39, 175, 176 Asymmetric connections, 67 Asynchronous interface for DVB, 111 Asynchronous transfer mode, 99 Bandwidth decrease, 36 Bandwidth increase, 36 Capacity, 21, 26 Channel identification, 107 Client signal fail, 121 Concatenation, 9–34 Contiguous concatenation (CCAT), 11, 13 Virtual concatenation (VCAT), 12, 17 Higher order SDH/SONET, 21 Lower order SDH/SONET, 25 PDH, 28 OTN, 34 Constant bit rate , 4, 5, 99, 165, 166, 168

Container, 5, 6 Contiguous concatenated container, 5 Continuous payload container, 5 Virtual concatenated container, 5 Virtual container, 5 Virtual tributary container, 5 Control field, 37, 40 Control packet, see also VLI, 23, 27, 37, 51, 187 Conversion, 32 Customer premises equipment, 4 Cyclic Redundancy Check (CRC), 37, 43 CRC decoding, 44 CRC division, 43 CRC encoding, 43 CRC multiplication, 43 CRC superblock, 120 Delay: Delay compensation, 19, 38 Differential delay, 19, 22, 27, 39, 129, 140, 146, 174, 175 Fiber delay, 19 Propagation delay, 19, 39 Transfer delay, 19 Digital video broadcast, 111


238 Distribution, 18, 171, 173 Diverse routing, 18, 39, 67 Do not use, 41, 72, 74 DS1, 1, 6, 29 DS3, 6, 31 E1, 1, 6, 29 E3, 6, 31 Efficiency, 33, 34 End of sequence, 41, 72, 74 Enterprise systems connectivity, 111 Ethernet, 2, 33, 99, 101, 111, 114, 115, 119, 122, 165, 167, 220 Ethernet over SDH/SONET, 99 Exercises, LCAS, 169–229 Exercise 1, VCG initiation, 178–189 Exercise 2, member addition, 189–200 Exercise 3, member removal, 200–210 Exercise 4, member failure, 210–215 Exercise 5, member recovery, 215–219 Exercise 6, degraded network, 220–226 Extended signal label, 27, 28 Extension header identifier, 106 Fibre channel, 111, 114 Fixed bandwidth, 41 Frame check sequence, 108 Frame mapped GFP, 101, 114–118 Fibre connectivity, 111 Fixed stuff, 5, 15, 16, 17, 22 Frame relay, 3 Functional models, 125–168 GFP adaptation functions, 151–164 GFP equipment functions, 165–168 Interworking function, 125–140 LCAS capable VCAT functions, 141–151 Virtual concatenation functions, 125–135

Index Generic Framing Procedure (GFP), 99–124 Basic structure, 102 Client data frames, 109 Client management frames, 110 Control frames, 112 8B/10B client signals, 119 Error handling, 118 Examples, 122–124 Extension header, 107 Frame delineation, 112 Frame multiplexing, 114 Frame mapped, 101, 114–118 Functional model, 102 Mapping, 121 Payload area, 104 Payload FCS field, 108 Payload header, 105 Payload information field, 108 Payload scrambling, 109 Relation, 101 64B/65B code blocks, 120 Transparent mapped, 101, 119–121 Type field, 105 GFP payload: Ethernet MAC, 111, 114 Fibre channel, 111, 117 IP/PPP, 111, 114 MPLS, 111, 117 RPR, 111, 115 Group identification, 37, 41 Header Error Check (HEC): Core header HEC (cHEC), 103 Extension header HEC (eHEC), 107 Type header HEC (tHEC), 106 High-level data link control, 100 Idle state, 41, 72, 74 Implementation, 20, 41, 42, 62, 69, 81, 122, 129, 140, 156, 162, 169 Intermediate network element, 18, 20 Internet protocol, 2, 101, 114

239

Index Internet service provider, 2 Interworking function, 51, 135 Layer, 6 Line, 6 Link Access Protocol SDH (LAPS), 99 Link Capacity Adjustment Scheme (LCAS), 35–65 LCAS disabled, 226 Local area network, 2 Media access control, 101, 114 Member, 18, 36 Member signal unavailable, 50, 73, 146 Member status, 37, 44 Member status multi-frame, 45 Metro area network, 2 Multi-frame, 22 Multi-frame indicator, 20, 27, 37, 39 Multi-frame structure, 25, 29–32, 37 Multiplexes: Multiplex structure, 100 PDH, 9 SDH, 10, 11 SONET, 10, 12 Multiplex section, 6 Multi-protocol label switching, 111, 114 Network element, 18 Network management system, 18 Normal operation, 41, 72, 74 Operations, administration & maintenance, 1 Optical channel, 3 Optical channel data unit, 6 Optical channel payload unit, 6 Optical Transport Network (OTN), 2 Order of transmission, 7 Least significant bit, 7 Most significant bit, 7

Packet over SDH/SONET, 99 Path, 6 Path overhead, 15, 16, 17, 22 VCAT path overhead, 23, 24, 28 Path protection, 18 Path termination, 18 Payload container, 5, 9 Payload distribution, 18, 171, 173 Payload FCS Identifier, 106 Payload length indicator, 103 Payload reconstruction, 18, 39, 175, 176 Payload type identifier, 105 Planned member addition 47 Planned member deletion 48 Pleisiochronous Digital Hierarchy (PDH), 1 Point of presence, 2 Point-to-point protocol, 3 Protection connection, 3, 16 Protection path, 18, 20 Protection switch, 19, 77 Protocol data unit, 100, 103 Quality of service, 3 Re-alignment, 175, 176 Regenerator section, 6 Remove member, 72, 74 Re-sequence acknowledge, 37, 45 Resilient packet ring, 114 Section, 6 Sequence number, 18 Sequence indicator, 37, 40 Server signal fail, 129, 131 Simple data link, 99 Sink, 37, 74, 78, 100 Sink engine, 175 Sink states: IDLE–OK–FAIL, 77 Source, 37, 77, 78, 100 Source engine, 172

240 Source states: IDLE–NORM–DNU–ADD– REMOVE, 74 Specification and Description Language (SDL), 67, 70–79 Diagrams, 74 Events, 71 Hold off, 77 State machine, source, 74, 78 State machine, sink, 77, 78 Symbols, 70 Wait to restore, 77 Standards, 4 ANSI, 4 ETSI, 4 IEEE, 114 ITU-T, 4 Storage area network, 3 Survivability, 36 Symmetric connections, 68 Synchronous Digital Hierarchy (SDH), 2 Synchronous Optical Network (SONET), 2 Synchronous payload envelop, 5 Synchronous transport module, 3 Synchronous transport signal, 5 Temporary member removal, 49 Time division multiplex, 4 Time sequence diagram, 81 Trail, 6 Trail selection, 172, 173 Trail signal degrade, 73, 220 Trail signal fail, 131, 211, 216 Trail termination function: VCAT, 126, 129, 131 VCAT, LCAS capable, 141, 146, 149

Index Trail trace identifier, 41, 42, 135, 137 Transparent mapped GFP, 101, 119– 121 Transport signals, 9 Tributaires, virtual, 9 User payload identifier, 106 Variable bit rate, 4, 99 Virtual Concatenation Group (VCG), 18, 36 Provisioning, 82 Planned bandwidth increase, 83–88 Planned member addition, 83–88 Planned bandwidth decrease, 88– 92 Planned member removal, 88–92 Size, 69 Unplanned decrease, 93–98 Unplanned member removal, 93– 98 VCAT + LCAS Information (VLI): Higher order VLI structure, 51 Higher order VLI MST multiframe, 53 Higher order VLI example, 54 Insertion, 172 Lower order VLI structure, 54 Lower order VLI MST multi-frame, 57 Lower order VLI example, 57 OTN VLI structure, 57 OTN VLI example, 59 PDH VLI, 61, 62, 63 PDH VLI example, 63, 65 Wavelength division multiplex, 4 Wide area network, 2

SONET: Evolution or Revolution

Sonet or SDH Demystified

Rebellion or Revolution?

Evolution and Molecular Revolution

Planning Chinese Characters: Reaction, Evolution or Revolution? (Language Policy)

Evolution - fact or fable

Evolution: Science Or Ideology?

Latin America: Underdevelopment or Revolution

SONET and SDH

SONET SDH Demystified

New SONET SDH whitepaper1 en

SONET-based Metro Area Networks

Charles Darwin: And the Evolution Revolution

Evolution and Revolution in Linguistic Theory

Charles Darwin and the Evolution Revolution

The Burger Court: Counter-Revolution or Confirmation?

Revolution and Evolution in Twentieth-Century Macroeconomics

Evolution and Revolution in Linguistic Theory

The European Social Model: Modernisation Or Evolution?

European Financial Cross-Border Consolidation: At the crossroads in Europe? By exception, evolution or revolution?

Revolution

Revolution

Revolution

Revolution

Revolution

Revolution

Revolution and Counter-revolution

Revolution

Revolution

Revolution

Revolution

SONET: Evolution or Revolution

Sonet or SDH Demystified

Rebellion or Revolution?

Evolution and Molecular Revolution

Planning Chinese Characters: Reaction, Evolution or Revolution? (Language Policy)

Evolution - fact or fable

Evolution: Science Or Ideology?

Latin America: Underdevelopment or Revolution

SONET and SDH

SONET SDH Demystified

New SONET SDH whitepaper1 en

SONET-based Metro Area Networks

Charles Darwin: And the Evolution Revolution

Evolution and Revolution in Linguistic Theory

Charles Darwin and the Evolution Revolution

The Burger Court: Counter-Revolution or Confirmation?

Revolution and Evolution in Twentieth-Century Macroeconomics

Evolution and Revolution in Linguistic Theory

The European Social Model: Modernisation Or Evolution?

European Financial Cross-Border Consolidation: At the crossroads in Europe? By exception, evolution or revolution?

Revolution

Revolution

Revolution

Revolution

Revolution

Revolution

Revolution and Counter-revolution

Revolution

Revolution

Revolution

Revolution

Recommend Documents