OPTICAL NETWORKING STANDARDS: A COMPREHENSIVE GUIDE
OPTICAL NETWORKING STANDARDS: A COMPREHENSIVE GUIDE
Edited by Khurram Kazi
Springer
Khurram Kazi, Ph.D
[email protected] Optical Networking Standards: A Comprehensive Guide
Library of Congress Control Number: 2006921777 ISBN 0-387-24062-4 ISBN 978-0-387-24062-6
e-ISBN 0-387-24063-2
Printed on acid-free paper. "The materials in Chapters 10 and 12 have been reproduced by Springer with the permission of Cisco Systems, Inc. COPYRIGHT © 2006 CISCO SYSTEMS, INC. ALL RIGHTS RESERVED." © 2006 Springer Science+Business Media, LLC All rights reserved. This work may not be translated or copied in whole or in part without the written permission of the publisher (Springer Science-HBusiness Media, Inc., 233 Spring Street, New York, NY 10013, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection with any form of information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now know or hereafter developed is forbidden. The use in this publication of trade names, trademarks, service marks and similar terms, even if the are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. Printed in the United States of America. 9 8 7 6 5 4 3 2 1 springer.com
Dedication
This book is dedicated to my wife Sameema, my family and friends and all the folks who have spent countless hours developing networking standards
Contents
Foreword
xix
Preface
xxi
Acknowledgements
xxiii
About the Authors
xxv
CHAPTER 1 OVERVIEW 1.1. Optical Transport Network Infrastructure 7.7.7 Functional Modeling Specification Technique 1.1.2 Multiservice Optical Transport Network Infrastructure 1.1.3 Global Optical Transport Network Timing 1.2. Carriage of Services over Transport Networks 7.2.7 Ethernet Services Architecture and Definitions 1.2.2 Storage Area Services Over SONET 1.3. Control and Management of Optical Transport Networks 1.4. Intra-Network Element Communication and Component-centric Standards 1.4.1 Intra-Network Element Communication 1.4.2 Optical Interfaces 1.4.3 High-Speed Serial Interconnects 1.5. Standards Development Process
1 1 2 3 6 7 7 10 10 11 11 12 12 13
vni PARTI Optical Transport Network Infrastructure
15
CHAPTER 2 ARCHITECTURE OF TRANSPORT NETWORKS
17
2.1. Introduction. 2.2. Transport Functional Modeling 2.2.1 Basic Concepts 2.2.2 Functionality 2.2.3 Connections and Points 2.2.4 Connection Dimension Model. 2.2.5 Sublayers and Function Decomposition 2.2.6 Examples 2.2.7 Equipment Packaging 2.2.8 Application Examples 2.2.9 Equipment Control 2.2.10 Equipment Supervisory Process 2.2.11 Modeling Connectionless Layer Networks 2.2.12 Summary 2.3. Notes 2.4. References
17 18 20 29 31 32 35 36 39 40 50 53 60 61 61 62
CHAPTER 3 INTERFACES FOR OPTICAL TRANSPORT NETWORKS 3.1. Introduction. 3.2. OTN Standards 3.3. Standardized Interfaces 3.4. Forward Error Correction 3.4.1 Theoretical Description 3.4.2 Coding Gain. 3.5. Tandem Connection Monitoring 3.6. OTN Hierarchy Overview 3.7. OTN G.709 Frame Structure 3.8. G.709 Overhead Bytes: In-Depth Analysis and Processing 3.8.1 OPUk Overhead Bytes and Client Mapping Structure 3.8.2 Similarly Valued/Formatted Fields within G.709 Frame 3.8.3 ODUk Overhead and Processing 3.8.4 Tandem Connection Monitoring (TCM) 3.9. OTUk Overhead and Processing 3.9.1 Scrambling 3.9.2 Frame Alignment Overhead 3.9.3 Section Monitoring Byte Descriptions 3.9.4 General Communication Channel 0 (GCCO) 3.10. ODUk Multiplexing 3.10.1 Multiplexing Data Rates 3.10.2 4 XODUl to 0DU2 Multiplexing 3.10.3 0DU1/0DU2 to 0DU3 Multiplexing 3.10.4 Summary
63 63 64 66 67 68 70 73 76 79 81 82 88 90 95 98 99 100 101 104 104 105 107 112 117
Contents 3.11. References
ix 117
CHAPTER 4 MULTIPLEX STRUCTURES OF THE OPTICAL TRANSPORT NETWORK 4.1. Introduction 4.2. The Situation in the Previous Century 4,2.1. SDH structure details 4.3. The Evolution of the Bandwidth 4.4. New Clients 4.5. Virtual Concatenation 4.5.1. Differential Delay 4.5.2. Pay load Distribution and Reconstruction 4.5.3. Additional Benefits 4.5.4. Restrictions 4.5.5. VCATDetails 4.6. Link Capacity Adjustment Scheme (LCAS) 4.6.1. Link Capacity Increase 4.6.2. Link Capacity Decrease (Planned) 4.6.3. Temporary Link Capacity Decrease 4.6.4. LCAS Details 4.1. Advantages of Using VCAT LCAS and GFP 4.8. Implementers Guide for VCAT and LCAS 4.8.1. Detection of Differential Delay 4.8.2. Compensation of Differential Delay 4.8.3. Structure and Management of Differential Delay Buffers 4.8.4. Differential Delay Buffer Overview 4.8.5. Alignment within a VCG 4.8.6. Sizing the Delay Buffers 4.8.7. Processing Time 4.8.8. Controlling Distribution/Reconstruction Order 4.8.9. Member Status 4.9. References
119 119 120 120 127 130 131 131 133 136 136 137 140 140 140 141 141 144 144 144 145 146 147 148 149 149 150 151 152
CHAPTER 5 GENERIC FRAMING PROCEDURE (GFP) 5.1. Introduction 5.2. Background 5.2.1 Packet Transport on Public Networks 5.2.2 Other Traffic Adaptation Approaches 5.2.3 Other Design Considerations 5.3. Formats and Procedures 5.3.1 GFP Frame Formats 5.3.2 GFP Control Frames 5.3.3 Client-Independent Procedures 5.3.4 Client-Dependent Procedures 5.4. Implementation Considerations 5.4.1 Virtual Framer Management
153 153 155 155 156 157 15 8 159 164 164 166 171 171
5.4.2 Scrambler Options 5.5. Performance 5.5.1 Probability of GFP Frame Delineation Loss (FDL) 5.5.2 Probability of False Frame Synchronization (FFS) 5.5.3 Probability of Frame Unavailability (FUA) 5.5.4 Frame Acquisition Delay 5.5.5 Scrambler Resynchronization Delay 5.5.6 Link Efficiency 5.6. Applications 5.6.1 Ethernet Private Lines 5.6.2 Virtual Leased Lines 5.6.3 Packet Rings 5.7. Future Directions 5.8. References CHAPTER 6 SYNCHRONIZATION OF OPTICAL NETWORKS 6.1. The Field of Network Synchronization Engineering 6.LI Introduction 6.2. Background on Timing, Synchronization, and Jitter 6.2.1 Basics of Digital Transmission, Timing Jitter, and A lignment Jitter 6.2.2 Jitter Tolerance, Transfer, Generation, and Network Limit 6.2.3 Mapping and Multiplexing 6.2.4 Pointer Adjustments 6.2.5 Timing Signal Imperfections 6.2.6 Characterization of Timing Performance 6.2.7 Wander Network Limits and Wander Performance 6.3. Roadmap of Current ITU-T Recommendations on Timing, and Jitter, For OTN, SDH, and PDH 6.4. Timing and Jitter Requirements for SONET/SDH and OTN 6.4.1 SEC and ODC Frequency Accuracy, Clock Modes, Pull-in and Pull-out/Hold-in Ranges 6.4.2 STM-N and OTUk Jitter Network Limit and Tolerance, STM-N Regenerator and ODCr Jitter Generation and Transfer, and STM-N and OTUk Jitter Accumulation 6.4.3 Jitter and Wander Accumulation for PDH Clients of SDH Networks and SDH Clients of OTN 6.5. Reliable Distribution of Synchronization 6.5.1 The Need for Synchronization 6.5.2 Synchronization A reas 6.5.3 Reference Duplication and Reference Selection 6.5.4 Synchronization Status Messages 6.5.5 Satellite Timing 6.5.6 Synchronization Network Engineering 6.6. Conclusions and Closing Remarks 6.6.1 Conclusions 6.6.2 Closing Remarks
172 174 174 175 J 76 179 182 182 184 184 185 186 187 187
189 189 189 191 191 196 200 203 206 209 212 214 216 218
219 227 233 234 235 241 243 248 249 250 250 251
Contents 6.7. Notes 6.8. References
xi 252 254
CHAPTER 7 SYNCHRONIZATION ARCHITECTURES FOR SONET/SDH SYSTEMS AND NETWORKS 7.1. Synchronization Concepts 7.2. Timing Traceability 7.2.7 Source Traceability 7.3. Synchronization Distribution 7.4. Network Element (NE) Architecture 7.4.1 Timing Engine (TE) Functions 7.4.2 Timing Distributor (TD) Functions 7.4.3 Network Element System A rchitecture 7.4.4 Small Network Element A rchitecture 7.4.5 Medium Network Element A rchitecture 7.4.6 Large Network Element A rchitecture 7.5. External Timing Configurations 7.5.1 Direct-Source Timing Method. 7.5.2 Bridged-Source Timing Method 7.5.3 Line/External Timing Method 7.5.4 Mult Timing Method 7.6. Clock Backup Modes and Implications 7.7. Synchronization Guidelines 7.8. Notes 7.9. References
257 257 261 262 266 268 269 270 2 75 2 76 2 77 2 78 279 280 281 282 285 286 292 293 294
CHAPTER 8 NETWORK SURVIVABILITY 8.1. Introduction 8.2. Network Survivability Techniques 8.3. Survivability Offered by Protection 8.3.1 Network Objectives 8.3.2 Protection Switching Architectures 8.3.3 Protection Switching Parameters 8.3.4 Protection Switching Classes 8.3.5 Hold-off Timer 8.3.6 Protection Switching Trigger Criteria 8.3.7Null Signal 8.3.8 Automatic Protection Switching (APS) Protocol 8.3.9 Examples 8.3.10 Optical Transport Networks (OTN) Survivability 8.4. Survivability Offered by Restoration 8.4.1 Network Restoration Techniques 8.4.2 Restoration time 8.4.3 Interoperability 8.5. Link Capacity Adjustment Scheme (LCAS) 8.6. Multilayer Survivability
295 295 295 296 297 297 303 306 309 310 310 310 312 313 314 315 315 316 317 318
xu 8.7. References PART 2 Services Offered over Transport Networks CHAPTER 9 METRO ETHERNET OVERVIEW AND ARCHITECTURE 9.1. Metro Ethernet Demand and Requirements 9.1.1 Network Resiliency 9.1.2 Trajfic and Performance Management 9.1.3 Circuit Emulation Services 9.2. Metro Ethernet Forum Charter 9.3. Metro Ethernet Network (MEN) Architecture 9.3.1 MEN Reference Model 9.3.2 MEN Layer Network Model 9.3.3 MEN Reference Points 9.3.4 MEN Architectural Components 9.3.5 MEN Layer Relationship to the Architecture Model Components 9.4. References CHAPTER 10 ETHERNET SERVICES OVER METRO ETHERNET NETWORKS 10.1. Introduction 10.2. Services Model 10.2.1 Customer Edge View 10.2.2 User Network Interface 10.2.3 Service Frame 10.2.4 Ethernet Virtual Connection 10.2.5 Identifying an EVC at a UNI 10.3. Service Features 10.3.1 CE-VLAN ID Preservation 10.3.2 All-to-One Bundling Map 10.3.3 Service Multiplexing 10.3.4 Feature Constraints 10.3.5 E-Line and E-LAN Service 10.3.6 Class of Service 10.3.7 Bandwidth Profiles 10.3.8 Layer 2 Control Protocols 10.4. Conclusion and Future Work 10.5. Appendix A: Ethernet Basics 10.5.1 Ethernet Physical Layers 10.5.2 Ethernet Media Access Control Layer 10.5.3 Ethernet VLANs 10.6. Notes 10.7. References
319
321 323 323 323 324 324 325 326 326 327 329 334 337 341
343 343 343 344 344 345 346 348 349 350 350 352 355 356 356 359 365 367 367 368 368 370 371 372
Contents
xiii
CHAPTER 11 ETHERNET SERVICES OVER PUBLIC WAN 11.1. Introduction 77.7.7 Why Ethernet over the public WAN? 11.1.2 Organization of the chapter 11.1.3 Related standards activity 11.1.4 Definition of some technical terms in this chapter 11.2. Service Types and Characteristics 77.2.7 Ethernet connection (EC) attributes 11.2.2 Ethernet Private Line (EPL) service 11.2.3 Ethernet virtual private line service (EVPL) 11.2.4 Ethernet private LAN (EPLAN) service 11.2.5 Ethernet virtual private LAN service 11.3. Transport Network Models In Support of Ethernet Connectivity Services 11.4. Ethernet Client Interfaces 7 7. '^. 7 Multiplexed access 11.4.2 VLAN mapping. 11.4.3 Bundling 11.4.4 Bandwidth profile 11.4.5 Layer 2 Control Protocol processing 11.4.6 Summary of UNI Service Attributes for Different Services 11.5. Ethernet Transport Network To Network Interface (NNI) 11.6.0AM 11.7. Protection and Restoration 11.7.1 Service Protection or Restoration Provided by the Transport Network 11.7.2 Service Restoration at Layer 2 11.8. Conclusion 11.9. Notes 11.10. References
420 421 421 422 423
CHAPTER 12 ETHERNET SERVICES OVER MPLS NETWORKS 12.1. Virtual Private Networks 72.7.7 Traditional Layer 2 Virtual Private Networks 12.1.2 Classification of VPNs 12.1.3 Multiservice Converged Packet Switched Backbone \1.1. L2VPNS over MPLS Backbone 72.2.7 L2VPNs Architecture Generic Components 12.3. Metro Ethernet Services 72. J. 7 Ethernet Virtual Connection (EVC) 12.3.2 E-Line Service 12.3.3 E-LAN Service 12.4. Metro Ethernet Services Over MpPLS 72.^.7 Emulation of E-Line Services using VPWS
425 425 425 426 427 428 428 436 436 436 436 437 438
373 373 373 3 75 377 378 379 381 387 388 389 391 392 401 402 404 404 404 404 405 405 411 419
XIV
12.4.2 E-Line Service Emulation Walk-Through Example 12.4.3 Emulation ofE-LAN Services using VPLS 12.4.4 E-LAN Service Emulation Walk-Through Example 12.5. Importance of VPLS for Metro Ethernet Services 12.6. Summary 12.7. Appendix A: MPLS Basics 12.7.1 Forwarding Equivalence Class 12.7.2 Labels 12.7.3 Label Encoding 12.7.4 Label Switched Router (LSR) 12.7.5 Label Stack Operations — Imposition, Disposition, Swapping 12.7.6 MPLS Control Plane 12.7.7 MPLS Forwarding Plane 12.7.8 Label Switched Path (LSP) 12.7.9 Benefits of MPLS Technology 12.8. References
441 443 448 449 450 451 451 451 452 453 453 453 454 454 455 455
CHAPTER 13 METRO ETHERNET CIRCUIT EMULATION SERVICES 13.1. Metro Ethernet Circuit Emulation Services 13.1.1 Circuit Emulation Service Definition, 13.1.2 Circuit Emulation Service Framework, 13.2. References
457 457 457 466 496
CHAPTER 14 METRO ETHERNET NETWORK RESILIENCY AND TRAFFIC MANAGEMENT 14.1. Metro Ethernet Network Resiliency 14.1.1 Introduction 14.1.2 Protection Terminology 14.1.3 Discussion of Terminology 14.1.4 Protection Reference Model 14.1.5 Requirements for Ethernet Services protection mechanisms 14.1.6 Framework for Protection in the Metro Ethernet 14.2. Metro Ethernet Traffic and Performance Management 14.2.1 Ethernet Traffic Management Overview 14.3. References
497 497 497 499 504 505 516 521 524 524 526
CHAPTER 15 SONET SERVICES FOR STORAGE AREA NETWORKS
527
15.1. Data Growth 15.2. Storage Networking 15.3. Storage Area Networks 15.3.1 Factors Driving SAN Extension 15.3.2 Fibre Channel: The Storage Protocol of Choice 15.4. Distance Extension Requirements 15.5. Distance Extension Alternatives 75.5.7 Legacy Private Line
527 528 5 31 532 534 536 538 539
Contents 15.5.2 WDM, 15.5.3 Storage over IP 15.5.4 SONET/SDH 15.6. SONET - An Ideal Distance Extension Protocol 15,6,1 Making SONET Fit - The Role of Standards 15.7. Summary 15.8. References PART 3 Control and Management of Transport Networks CHAPTER 16 ARCHITECTING THE AUTOMATICALLY SWITCHED TRANSPORT NETWORK 16.1. Introduction 16.2. Network Requirements (G.807) 16.2.1 Architectural Context 16.2.2 Call and Connection Control 16.2.3 Business and Operational Aspects 16.2.4 Reference Points and Domains 16.2.5 Architecture Principles 16.2.6 Supporting Functions and Requirements 16.2.7 Signaling Communications Network Requirements 16.2.8 Support for Transport Network Survivability 16.3. Architecture (G.8080) 16.3.1 The Control Plane View of the Transport Network, 16.3.2 Identifying Components 16.3.3 General Component Properties and Special Components 16.3.4 Component Overview 16.3.5 Interlay er Modeling 16.3.6 Distribution models 16.3.7 An Example of Components in A ction, 16.3.8 Identifier Spaces 16.3.9 Restoration A rchitecture 16.4. Signaling Communications Network Architecture (G.7712) 16.4.1 Signaling Methods 16.4.2 Delivery of Control Plane Messages 16.4.3 DCN Topologies 16.4.4 DCN Reliability Considerations 16.4.5 DCN Security Considerations 16.5. Service Activation Process Elements 16.6. Discovery (G.7714) 16.6.1 Discovery and Connectivity Verification 16.6.2 Discovery A rchitecture 16.6.3 Types of Discovery 16.6.4 Discovery Considerations across Administrative Boundaries 16.7. Routing (G.7715 and G.7715.1) 16,7,1 Requirements
xv 539 540 541 542 544 547 548
549
551 551 553 554 555 559 562 564 567 570 571 571 576 578 580 580 583 585 586 588 593 595 596 597 599 602 603 603 604 605 606 607 611 611 611
XVI
16.72 A rchitecture 16.73 Hierarchy in Routing 16.7.4 Routing Information Exchange 16.8. Signaling (G.7713) 16.8.1 Call and Connection Management Operations 16.8.2 Basic Call and Connection Control Sequences 16.8.3 Signaling Attributes 16.8.4 Signaling Application Example 16.9. Control Plane Management 16.10. Protocol Analysis 16.10.1 Analysis Approach 16.10.2 Requirements Implications on Protocol Solutions 16.11. Methods and Protocols — Discovery 16.11.1 Layer Adjacency Discovery Methods 16.12. Methods and Protocols — Signaling 16.12.1 G. 7713.1 PNNI Signaling 16.12.2 G,7713,2 GMPLS RSVP-TE Signaling 16.12.3 G.7713.3 GMPLS CR-LDP 16.12.4 Interoperability and Interworking 16.13. METHODS AND PROTOCOLS — ROUTING 16.14. Signaling Communications Network — Mechanisms (G.7712) 16.15. Futures 16.16. Acknowledgements 16.17. References PART 4 Intra-Network Elements and Component-Centric Standards CHAPTER 17 INTRA-NETWORK ELEMENTS COMMUNICATION 17.1. Introduction 17.2. Requirement Placed on the Network Elements by the Network 17.3. Network Element Design and Interface Architecture 17.3.1 Packet Based Network Elements 17.3.2 TDM Based Network Elements 17.3.3 Hybrid (TDM + Cell/Packet Based) Network Element Architecture 17.4. 2.5 Gbits/s Systems 17.4.1 SPI-3 Signal Descriptions 17.5. 10 Gbits/s Systems 17.5.1 System Framer Interface-4 Phase 1 (SFI~4 Phase 1) 17.5.2 SPI-4 Phase 1 (Oc-192 System Packet Interface) 17.5.3 System Framer Interface-4 Phase 2 (SFI-4 Phase 2) 17.6. SPI-4 Phase 2 (Oc-192 System Packet Interface) 17.7. 40 Gbits/s Systems 17.7.1 Serdes Framer Interface-5 (Sfi-5) 17.7.2 SPI-5 (Oc-768 System Packet Interface) 17.7.3 TFI-5 (TDM Fabric to Framer Interface)
615 619 621 626 627 628 630 631 633 637 63 7 639 640 640 643 643 644 648 649 651 652 653 655 655
659
661 661 662 664 665 666 667 668 669 672 672 674 677 679 681 682 685 687
Contents 17.8. Acknowledgements 17.9. References
xvii 688 688
CHAPTER 18 ITU OPTICAL INTERFACE STANDARDS 18.1. Introduction 18.2. ITU Optical Interface Standards 18.2.1 Historical Perspective 18.2.2 Transverse versus Longitudinal Compatibility 18.2.3 Overview of Optical Fiber Types and Associated Recommendations 18.2.4 Overview of Optical Interface Recommendations 18.2.5 Application Code Terminology Related To Distance 18.2.6 Power Budget Design Considerations and Limitations 18.3. Optical Interface Implementations 18.3.1 General 18.3.2 140 Mbit/s - 2.5 Gbit/s Technology 18.3.3 10 Gbit/s Technology 18.3.4 40 Gbit/s Technology 18.4. Considerations on Optical Fault and Degradation Detection 18.4.1 General 18.4.2 Faults in Conventional Transmitters and Receivers 18.4.3 Faults in Optically Amplified Systems 18.5. Notes 18.6. Acknowledgments 18.7. References
703 706 709 710 712 712 713 721 729 729 729 729 731 732 733 733
CHAPTER 19 HIGH-SPEED SERIAL INTERCONNECT 19.1. Introduction 19.1.1 Chip-Chip Interconnect 19.1.2 Backplane Interconnect 19.2. High-Speed Interconnect System Architecture 19.2.1 Topologies 19.2.2 Printed Circuit Board (PCB) Interconnects 19.3. Compliance Test Methodology 19.3.1 Eye Mask 19.3.2 Jitter modeling conventions for high-speed interfaces 19.3.3 Bathtub curve analysis ofjitter 19.4. Interconnect Extension Using De-Emphasis and Equalization 19.4.1 De-emphasis at the Transmitter 19.4.2 Equalization at the Receiver 19.4.3 Usage Models 19.5. Standards-Based High-Speed Interconnect 19.5.1 OIF Sxl-5 19.5.2 OIF TFI-5 19.5.3 IEEE® 802.3ae™ Clause 47, XAUI 19.5.4 Backplane Ethernet
735 735 736 736 737 737 738 742 742 744 746 748 749 754 756 758 758 759 759 760
691 691 692 692 700
XVIU
19.5.5 Summary of Standards-Based High-Speed Interconnect 19.6. Higher and Higher Speeds 19.7. Summary 19.8. Notes 19.9. References
PARTS Standards Development Process
760 762 764 764 764
765
CHAPTER 20 STANDARDS DEVELOPMENT PROCESS 20.1. Introduction 20.2. The International Telecommunication Union (ITU) 20.2.1 Hierarchy 20.2.2 Membership 20.2.3 Standards Development 20.3. Technology-Specific Industry Forums 20.3.1 Message 20.3.2 What is involved? Election/hierarchy 20.3.3 The History behind Standards Groups: Why join? 20.3.4 Membership 20.3.5 Reality of human nature 20.3.6 Teamwork 20.4. Conclusion
767 767 768 768 772 772 776 776 777 779 780 781 782 783
INDEX
785
FOREWORD
Khurram Kazi SMSC
''O mankind! We have created you from a single (pair) of a male and female, and have made you into nations and tribes, so that you may know each other,..'' [Quran 49.13]. When one ponders over how we get to know each other; certain thoughts come to mind. As we venture outside our own region or domain, we tend to follow certain protocols that allow us to communicate with each other. Those protocols have diverse flavors; for example, the first thing we try is to communicate in a common language that both parties understand. If that fails, we use gestures or sign language or even resort to drawing pictures to get our message across. In short we find a common ground or similar footing which to build our communication platform on even though we may come from such diverse cultures and background. Just as we have diversity in mankind, we have disparate, ever-evolving communications networks. These networks are evolving towards providing seamless connectivity between different platforms and applications so that they cater to our insatiable need to communicate with each other in many different ways. Evolutionary technologies, including Dense Wavelength Division Multiplexing (DWDM), advances in optics/optoelectronics, highly versatile electronic integrated circuits, and control and management software have provided an excellent foundation for present-day networks to emerge into robust and scalable networks with ever-increasing intrinsic intelligence. These advances have been enabled by the relentless activities taking place within scores of technical standards committees, industry fora and consortia across the globe. In this comprehensive volume, we seek to give an overview of the converged multiservice optical transport networking development activities occurring within standards development
XX
organizations and industry fora including the International Telecommunication Union, ITU-T, Internet Engineering Task Force (IETF), Institute of Electrical and Electronics Engineers (IEEE), Metro Ethernet Forum (MEF) and Optical Internetworking Forum (OIF). Some of the issues these bodies are addressing are: • Multiservice and data-optimized SONET/SDH and OTN transport infrastructure • Ethernet and MPLS in converged transport networks spanning the enterprise, access, and core network realms • Flexible and efficient support for a diverse set of services over existing and emerging next-generation transport network architectures • Enhanced service provisioning, enabling more dynamic and responsive connection services, via automatically switched transport networks • Equipment functional block specifications that enable multivendor interoperability without constraining equipment implementation • Physical-layer specifications that enable multi-carrier network deployments and interconnection of equipments among multiple vendors • Network and equipment management specifications encompassing FCAPS (fault, connection, administration, performance, security management) that assure common behavior and minimize the need for human intervention, reducing operational and management expenses • Timing and synchronization in global transport networks • Backplane and component specifications encompassing optical, electrical, and mechanical characteristics that impact, e.g., optoelectronic modules. Very Large Scale Integrated devices, and backplanes utilized in existing and next-generation equipment
PREFACE
In the late 1980s and 1990s I was exposed to ANSI, ITU-T, IEEE and ATM forum standards and implementation agreements while developing ASICs and systems for Tl, SONET/SDH, ATM, and Ethernet applications. During the architecture, design, and verification, I had to go through the standards documents to ensure that my designs were standards compliant. While designing I was always on the lookout for a comprehensive source that could give me a broad prospective on all the relevant standards dealing with optical networking. Suffice it to say I did not find a single book that comprehensively covered the work being done at the major standards bodies and I ended up going through quite a few books, standards documents and technical papers. The development of the bigger picture proved to be quite useful in my design process as I started to understand which components my ASICs would be interfacing with, what systems and services features these ASICs were going to be providing etc. In short, I started to understand the design partitioning and hierarchical abstractions; from ASICs, standard VLSI products, and optoelectronic components to systems and networks architecture. With the desire to share these thoughts with the rest of the networking community, I embarked upon this project. With the help of Eve Varma, I was able to assemble a world-renowned team of over twentyfive leading contributors and editors of the standards from networking powerhouses such as Tellabs, PMC-Sierra, Nortel, Marconi, Lucent Technologies, Cisco, Ciena, British Telecom, Atrica, AMCC, and Agere Systems, as well as independent consultants, who have come together to make this work a reality. From our collective efforts we have put together Optical Networking Standards: A Comprehensive Guide, which provides a single-source reference work for the specifications of networks at all levels: from components (optics, optoelectronics, and VLSI
XXll
devices) through systems to global transport networks infrastructure, their management, and the services they offer. While going through the standards documents, especially the designers and implementers who ensure standards-compliant products should keep in mind that generally standards documents are not easy to read. There are several reasons behind the statement. Typically, the process of defining the requirements for specific sets of functionalities kickstarts the development of a particular standard or suite of standards. During the early phases of the development of standards technologies or services, the norm is to define a generic architecture. Details are subsequently added either to the same document or to different ones to get into specifics. Generally speaking, every effort is made to ensure that the standards are written in such a way that they are technology and implementation independent. This approach results in careful usage of the language that at times makes it difficult to read. From my personal experiences as a designer, I felt anguish while going through these documents. However, persistent reading made things clearer. One lesson that I learned is that one needs to spend the time going through the documents with patience and full concentration, along with having discussion with the colleagues, to fully appreciate the subtleties of the recommendations. It is always helpful if one develops some background information base prior to going through standards documents. Every effort is made in this book to give a reader some background information so that going through the respective recommendations is not as painful as when one starts to read them cold. The chapters are written such that they can be read as standalone chapters or can be combined to get a better understanding of the different aspects of optical networking standards. It should be kept in mind that the reader should always use the actual standards documents, implementation agreements, or RFCs as the definitive source of information.
Acknowledgements
I would like to thank ITU-T, Metro Ethernet Forum and Optical Internetworking Forum for allowing us to use appropriate information from their respective standards and the implementation agreements.
Contributing Authors
Ghani Abbas has spent over fifteen years in the SDH and Optical Networks business, initially with GPT and later with Marconi Communications, U.K. He is currently international standards manager in the Network Engineering and Technology department. He previously held various engineering development and management posts. He is currently the rapporteur for ITUT SGI5 Q9, which develops standards for transport equipment and network protection and restoration. He is an active member of OIF, ETSI, ITU SGI 3 and SGI5. Ghani received a B.Sc (Honour) degree from Manchester University in Electrical Engineering and a Ph.D degree in Electronics from Southampton University, U.K. P. Stephan Bedrosian is a Distinguished Member of Technical Staff in the Standards and Advanced Technology organization at Agere Systems. He has worked in the research, design, and development of synchronization systems, networks, and devices spanning the last two decades. At Bell Laboratories, his focus was on telecommunications synchronization systems, including the design and development of building integrated timing supplies (BITS). At Lucent Technologies, he was involved in the design and development of both telecom and datacom synchronizations systems and subsystems for use in SONET/SDH, xDSL and ATM networks. At Agere Systems, he is very involved with the development of computer timing devices as well as standardization of packet timing protocols. He has published several articles, including "Timing Synchronization Speeds Network Access," and holds several synchronization-related patents and patents pending. Mr. Bedrosian holds a Bachelor of Science in Electrical
XXVI
Engineering from Worcester Polytechnic Institute and a Master of Science in Electrical Engineering from Georgia Institute of Technology. Nan Chen Nan Chen is the Vice President of Marketing at Strix Systems (www.StrixSystems.com), a leading provider of mesh wireless Ethernet solutions enabling rapid networking without wires. Mr. Chen is also the President of the Metro Ethernet Forum (www.MetroEthernetForum.org), a worldwide standards organization for Carrier-class Ethernet networks and services. Before Strix, Nan Chen was the Vice President of Marketing at Atrica Inc. (www.Atrica.com), where he successfully drove Ethernet's metro vision in the industry and its wide adoption in carriers networks worldwide. Prior to joining Atrica, Mr. Chen was the Director of Product Management and Product Marketing at Force 10 Networks while serving as a founding member of the Board of Directors of the 10 Gigabit Ethernet Alliance (10 GEA). Mr. Chen also spent four years at Nortel/Bay Networks/SynOptics. While serving as a Director of Technology at Nortel Technology Center, Mr. Chen drove Nortel 10 Gigabit Ethernet strategy and served as a founding member of the IEEE 802.3ae Task Force for development of 10 Gigabit Ethernet standards. Mr. Chen holds two MS degrees from the University of Arizona and a B.S. degree from Beijing University, China where he also was a record holder in pole vault. Carmine Daloia (
[email protected]) is a senior communications engineer and consultant in Washington Group International. He holds an M.S. degree in Electrical Engineering from Columbia University and a B.S. degree in Electrical Engineering from The Cooper Union, New York. He has expertise on transport and data network architecture, planning, and design covering a wide range of technologies, including SONET/SDH, OTN, ATM, MPLS, and IP. Beginning in 1995, he worked at Telcordia Technologies as a senior communication engineer, where he was responsible for SONET and ATM network design and planning projects and led the development of various Generic Requirements (GR) documents, including the SONET UPSR, SONET BLSR, and DWDM OADM GRs. While at Telcordia he represented both Telcordia and the Regional Bell Operating Companies within national and global standards. He joined Lucent's Optical Networking Group in June 2000, where he continued his standards activities by contributing to the development of the OTN architecture, equipment, and protection specifications as well as ASON specifications, and was editor of G.7712 "Architecture and Specification of the Data Communications Network." He joined Metro Tech Consulting Services in September 2003, where he provided network planning consultation to New York City Transit
Contributing Authors
xxvii
(NYCT) for the future Second Avenue Subway line communications network. Mimi Dannhardt is a Consultant who received her M.S. degree in Electrical Engineering from Virgina Tech. In her career, she has designed numerous networking and telecommunications chips for ATM, SDH, PDH and Ethernet over Sonet applications. Tracy Dupree is a public relations professional who has worked in the telecom and networking industries for over a decade. Ms. Dupree operated her own consulting agency for several years, where she worked with the Metro Ethernet Forum, among other clients. She has been employed with a variety of communications companies including Tekelec, Nortel Networks and currently is employed at Alcatel. Geoffrey Garner received an S.B. degree in Physics from M.I.T. in 1976, S.M. degrees in Nuclear Engineering and Mechanical Engineering from M.I.T. in 1978, and a Ph.D. in Mechanical Engineering from M.I.T. in 1985. He is currently a consultant in telecommunications, specializing in network timing, jitter, and synchronization; network performance and quality of service; systems engineering; and standards development. Since 2003 he has worked on a variety of projects, including simulation of network level jitter and wander performance, development of a simulator for Optical Burst Switching Network performance, and development of new standards for carrying time-sensitive traffic over Residential Ethernet. Prior to his work as a consultant, he was a Distinguished Member of Technical Staff in the Transport Network Architecture Department of Lucent Technologies. Beginning in 1992, his work at AT&T and then Lucent included the development of international and national standards for jitter and synchronization performance and transmission error performance of OTN and SONET/SDH networks, and for Quality of Service of ATM networks. He was the Rapporteur of the Transmission Error Performance Question in ITU-T SG 13 from 2001 to 2004, and the Editor for the ITU-T Recommendation specifying jitter and wander in the Optical Transport Network (G.8251) in SG 15. He joined AT&T in 1985, went with Lucent Technologies upon its divestiture from AT&T in 1996, and became a consultant in 2003. Steven Scott Gorshe is a Principal Engineer with PMC-Sierra's Product Research Group. He received his B.S.E.E. (University of Idaho) and M.S.E.E. and Ph.D. (Oregon State University) in 1979, 1982, and 2002, respectively. He has been involved in applied research and the development
XXVlll
of transmission and access system architectures and ASICs since 1982, including over five years at GTE and over 12 years with NEC America, where he became Chief Architect for NEC Eluminant Technologies. His current work at PMC-Sierra involves technology development for applications-specific standard product ICs, including those for Ethernet WAN transport over telecommunications networks. Dr. Gorshe is a Senior Member of the IEEE and Co-Editor for the regular Broadband Access series and guest editor for multiple Feature Topics in the IEEE Communications Magazine. He has also been involved in telecommunications network standards continuously since 1985 and serves as Senior Editor for OPTSX (formerly TlXl, responsible for North American SONET and optical network interface standards); technical editor for multiple standards within the SONET series; and a technical editor for multiple ITU-T Recommendations including G.7041 (GFP), G.8011.1 (Ethernet Private Line Service), and G.7043 (Virtual Concatenation of PDH Signals). Areas in which he has made key contributions include architectures for multiple generations of SONET/SDH equipment and much of the transparent GFP protocol. He is a recipient of the Committee Tl Alvin Lai Outstanding Achievement Award for his standards contributions. He has 27 patents issued or pending and multiple published papers. Adam Healey is a Distinguished Member of Technical Staff at Agere Systems and is responsible for the definition of subsystems and components required for access and enterprise networks. Adam joined Lucent Microelectronics / Agere Systems in 2000. Prior to joining Agere Systems, he worked for seven years at the Interoperability Lab at University of New Hampshire where he developed many of the test procedures and systems used to verify interoperability, performance, and comphance to standards of 10, 100, and 1000 Mb/s electrical and optical links. Adam is a member of IEEE and contributes to the development of international standards as a member of the IEEE 802.3 working group. He currently serves as chair of the IEEE P802.3ap Backplane Ethernet Task Force. He received a B.S. and M.S. in Electrical Engineering from the University of New Hampshire. Huub van Helvoort is a Standards Consultant at Huawei Technologies Co., Ltd. In 1977 he received his MSEE degree at the Technical University in Eindhoven, the Netherlands. In his 26-year career he has collected extensive experience in public switching systems and ISDN, PDH, and SDH technology. He represents Huawei Technologies in the standards bodies: ITU-T (SG15) and ANSI (T1X1.5) and is the editor of several ITU-T recommendations. He is a senior member of the IEEE. He can be contacted at tel: +31 36 5315076; e-mail:
[email protected] Contributing Authors
xxix
Enrique Hernandez-Valencia is a Consulting Member of the Technical Staff at Lucent Technologies' Bell Laboratories. He received his B.Sc. degree in Electrical Engineering from the Universidad Simon Bolivar, Caracas, Venezuela, and his M.Sc. and Ph.D. degrees in Electrical Engineering from the California Institute of Technology, Pasadena, California. He has over 15 years of experience in the design and development of systems architectures and protocols for high-speed communications networks. Dr. Hernandez-Valencia is a Bell Labs Fellow and a member of the Institute of Electrical and Electronics Engineers, Association for Computing Machinery, and Sigma Xi societies. Iftekhar Hussain is a technical leader with the Internet Technologies Division at Cisco Systems. For the past several years, Iftekhar has been involved in the design of high availability related aspects of IP/MPLS networks. He brings extensive industry experience to the subject of networking and telecommunication, including switching, traffic management, and voice delivery over packet switched networks. Dr. Hussain's current interests are in the area of IP/MPLS networks, network security, and mobile wireless architectures. He holds a Ph.D. degree in electrical and computer engineering from the University of California, Davis. Nevin Jones is a Consulting Member of Technical Staff (CMTS) with the Advanced Technology and Standards Development Group of Agere Systems (formerly Lucent Microelectronics). He has worked for approximately 20 years in the field of communications engineering at AT&T Bell Laboratories, Lucent Technologies and Agere Systems. He continues to work in a multidisciplinary communications engineering capacity and encompassing switching and transport networks modeling and planning, systems engineering, and software and hardware development of integrated circuits for PDH and SONET/SDH systems. His primary applied research activities currently include optical networking systems and architectures, client signal adaptation protocols, and integrated circuits physical-layer interface specifications for backplanes and chip-to-chip interconnects. He is an active contributor and member at ATIS OPTXS, PTSC, Optical Internetworking Forum (OIF), ITU-T SG-15 & SGI-3, IETF, and several other industry standards fora. He holds a B.S.E.E. (SUNY), MS (CUNY), and Ph.D. (CUNY). Khurram Kazi has over 19 years of industrial hands-on expertise in the computing, data and telecommunication networking field. He is a senior systems architect at SMSC working on trusted computing platforms. Prior to
XXX
SMSC, he concentrated on the architectural studies and designs of 40+-Gbps Next Generation Secure Transport Network, where he studyed the detailed trade-off analyses of crucial optical networking methodologies, devising new techniques, and recommending implementation methods within the intended architecture of the global network, including implementations of network elements and custom ASICs. Prior to this, he developed numerous ASICs for IP switching, SONET, Ethernet, ATM, and PDH applications. His extensive ASICs and systems work experience ranges from mid-size to venture-backed startup companies (Safenet-Mykotronx, General DataComm, TranSwitch, and Zagros Networks) and world-class research organizations like Bell Laboratories, Lucent Technologies. His work has resulted in over a dozen published papers and conference tutorials on optical components to ASICs to Optical Networks. Khurram received his B.S. from University of Bridgeport, M.S. and Ph.D. from the department of Electrical and Systems Engineering at the University of Connecticut. He can be reached at
[email protected]. Bob Klessig is a Director of Engineering at Cisco Systems. He is the Vice President of the Metro Ethernet Forum, where he is also the Co-Chair of the Technical Committee and a member of the Board of Directors. Before joining Cisco, Dr. Klessig was a founder of Telseon, an early competitive metro Ethernet service provider in North America. Before Telseon he was with 3Com, where he developed and helped execute the corporate ATM strategy. At 3Com he was the lead representative to the ATM Forum Technical Committee, where he focused on standards for data networking with ATM. He has held lead positions at Bellcore and Bell Laboratories. While at Bellcore he led the conception, design, and specification of Switched Multi-megabit Data Service (SMDS), the first high-speed metropolitan area data service. His Bellcore responsibilities also included leading RBOC participation and serving as Vice Chair of the IEEE 802.6 committee that wrote the IEEE Standard for Metropolitan Area Networks. Dr Klessig has a Ph.D. in Electrical Engineering and Computer Sciences from the University of California at Berkeley and is a co-author of the book SMDS: Wide Area Data Networking with Switched Multi-Megabit Data Service. Gert Manhoudt received a Masters Degree in Electrical Engineering from Delft University of Technology in 1986 in the area of Integrated Optics. He then worked for 17 years for Lucent Technologies and its predecessors and has a broad experience in optical transport networking as a hardware designer and systems engineer and in technical marketing. He has been active in the development and marketing of SDH/SONET equipment, specializing in optics, high-speed electronics, synchronization, and network performance aspects. He represented Lucent Technologies in ITU-T and
Contributing Authors
xxxi
ETSI in the synchronization working groups; in this capacity he was editor of two ETSI documents, namely, ETS 300462 parts 3 and 5. He has been one of the pioneers involved with the packet over SDH/SONET technology, as a responsible system engineer for the implementation of Ethernet transport and protocols over SDH/SONET networks. He has contributed to papers and studies on the evolution of packet-based transport in today's public networks. Since 2003 he worked as a network consultant for AimSys, www.aimsys.nl, a startup company that designs and manufactures equipment for metro optical networks. Alan McGuire is a Principal Engineer in the Network Technology Centre of BT. He leads a multidisciplinary team working on next generation transport networks. Alan is also active in the standards arena, where he has made numerous contributions and acted as editor of numerous ITU Recommendations concerned with network architecture, control and management, and optical networking. He graduated from the University of St. Andrews in 1987 with a first in Physics and received an M.Sc. in Medical Physics one year later from the University of Aberdeen. Alan is a member of the IEEE and the Institute of Physics and is a Chartered Physicist. George W. Newsome is currently a Systems Engineering Consultant whose primary work includes Control Plane management, architecture, and global standards. In previous assignments, George was a significant contributor to the ASON architecture standards, and has both created and managed the development of Network Element software. He has been involved with functional modeling since its inception in the ITU and has also worked on information modeling for network management. Mr. Newsome is a Chartered Engineer, Member of the lEE, and Senior Member of the IEEE, and holds a B.Sc. degree in Electrical Engineering from University College, London. Lyndon Ong is currently Director of Network Control Architecture in the CTO organization of Ciena Corporation, a supplier of intelligent optical and data transport equipment. Dr. Ong joined Ciena in 2001 after working at Nortel Networks, Bay Networks, and Bellcore/Telcordia. He received his doctoral degree in Electrical Engineering from Columbia University in 1991. He has had a long career in the area of control protocols, starting with the original team defining Signaling System 7 standards for North America, then working on ATM networking, IP QoS and transport protocols, and finally working on the optical control plane. Dr. Ong has chaired groups in ITU-T Standards, currently chairs the Signaling Transport WG in IETF, and is the editor of the OIF E-NNI Signaling Implementation Agreement.
XXXll
Richard Orgias currently works as a product marketing manager in the Broadband Networks business at Nortel. Mr. Orgias has worked in a number of different business units in various roles spanning operations, finance, and marketing since joining Nortel in 1992. Prior to his current role, in which he has marketing responsibility for Nortel's broadband access solutions, Mr. Orgias had responsibility for marketing Nortel's optical storage connectivity solutions, which included DWDM-based solutions as well as solutions based on SONET and Ethernet. Mr. Orgias received a B.Sc. degree from McMaster University in 1985 and also holds Master of Science and MBA degrees from McMaster. Mr. Orgias resides in Alpharetta, Georgia, with his wife and two children. Jonathan Sadler is a Staff Engineer in the Advanced Technologies group at Tellabs. With over 20 years of data communications experience as a protocol implementer, network element designer, carrier network operations manager, and carrier network planner, Jonathan brings a broad set of knowledge and experiences to the design and analysis of carrier network technology. Currently, he is involved in the development of technologies to provide the efficient transport of packet oriented services in Carrier Networks. He is the Chairman of the Optical Internetworking Fomm's Architecture and Signaling Working Group and an active participant in the IETF and ITU. Jonathan studied Computer Science at the University of Wisconsin - Madison. Stephen Shew is an Architect in the Optical Networks group at Nortel Networks. In his career at Nortel, Stephen has participated in the development and specification of distributed routing protocols, traffic engineering optimization tools, ATM PNNI, and MPLS signaling. His standards involvement has included the ATM Forum and IETF. He is currently participating in ITU-T Study Group 15 and OIF, and contributes to the architecture and protocols for the Automatic Switched Optical Network (ASON). Stephen received his Bachelor of Computer Science from Carleton University and M.Sc. from the University of Toronto. Peter J. J. Stassar holds a Masters Degree in Electrical Engineering from the Technical University in Eindhoven, the Netherlands. Between 1980 and 2003 he has been employed at Lucent Technologies Bell Labs, Hilversum, the Netherlands, lastly as senior technical consultant for optical technology and strategy in the R&D organization of Lucent's Optical Networking Group. He has well over 20 years of working experience in virtually all aspects of optical transmission, ranging from research to development, manufacturing, and deployment, in particular on SDH/SONET and FTTH
Contributing Authors
xxxiii
optical technologies. Since 1989 he played a key role in ITU SG15s activities on optical interface specifications. He is currently engaged as Product Manager for FTTH products at Genexis BV, Eindhoven, the Netherlands, and furthermore he is representing the interests of Finisar Corporation in ITU SO 15 on the field of optical interface technologies. Stephen J. Trowbridge received his Ph.D. in Computer Science from the University of Colorado at Boulder. He has worked for Bell Laboratories since 1977, and is currently a member of the Bell Laboratories Standards and Intellectual Property Department. He is a vice-chairman of ITU-T Study Group 15 (Optical and other Transport Network Infrastructures), where he chairs Working Party 3 of Study Group 15 (Optical transport network structure), which is responsible for standards related to PDH, SDH, and OTN Transport, Transport Equipment, Frame Formats, Network Synchronization, Equipment Management, and Automatically Switched Optical Networks (ASON). He chairs Working Party 3 of the ITU-T Telecommunication Standards Advisory Group (TSAG) on Electronic Working Methods and Publication Policy. He is also vice-chairman of the Optical Heirarchal Interfaces (OHI) subcommittee of the ATIS Optical Transport and Synchronization Committee (OPTXS). Eve L. Varma is a Technical Manager, Lucent Technologies, part of Lucent's Optical Networking Group. Ms. Varma has 26 years of research experience within the telecommunications industry. Her primary research areas are currently focused upon the automatically switched transport network (ASON/GMPLS) and converged multiservice transport networks. She is actively engaged in supporting the development of the associated specifications within global standards and industry fora spanning ITU-T, ATIS, and OIF. From 1995 to 1997, she led the team responsible for designing and prototyping a distributed optical network management system as part of the Multiwavelength Optical NETworking (MONET) Consortium (partially supported by DARPA). Previous research experience includes characterization, analysis, and development of transmission jitter requirements; systems engineering and standards for SDH/SONET and OTN transport and network management applications; as well as associated enabling technology and methodology development/assessment. Ms. Varma has been an active contributor to global standards since 1984 and has coauthored two books. Achieving Global Information Networking, Artech House (1999), and Jitter in Digital Transmission Systems, Artech House (1989). She holds an M.A. degree in Physics from the City University of New York. Ms. Varma is a 2004 Bell Labs fellow.
XXXIV
Tim Walker received his BS EE from Rensselaer Polytechnic Institute and his MS EE from University of Illinois at Urbana-Champaign. He is a member of IEEE, Tau Beta Pi, and Eta Kappa Nu. Mr. Walker is currently a Systems Engineer at Applied Micro Circuits Corporation (AMCC) in Andover, Massachusetts. Prior to AMCC he spent 16 years at Bell Labs/Lucent in various Hardware and Software design positions. Before that, he was an RF Engineer for four years at Teradyne. His main areas of expertise are OTN (G.709), SONET/SDH, and PON. He has presented numerous proposals to Standards bodies (ITU SG15 and TlXl),
Chapter 1 OVERVIEW
Khurram Kazi SMSC
The late 1990s heralded the need for optical transport networks to make a transition from catering to mostly voice traffic to converged voice and multiservice data-centric traffic. This transition led to several innovative standardized solutions, developed primarily within the International Telecommunication Union, (ITU-T) to develop and more efficiently leverage new and existing transport infrastructures to support the delivery of conventional and emerging services. Associated with this trend has been the cross-fertilization of concepts and technologies between traditionally data-oriented standards organizations, such as the Institute of Electrical and Electronics Engineers (IEEE) and Internet Engineering Task Force (IETF), and the ITU-T. Further coupled with this cross-fertilization has been an industry focus upon defining the multitude of services that such networks can offer, as evidenced by diligent work efforts in industry forums such as the Metro Ethernet Forum (MEF). Industry forums, including the MEF, Optical Internetworking Forum (OIF), and TeleManagement Forum (TMF), currently play important roles related to the realization and deployment of new technologies. Last but not least, due to the large number of component vendors whose standard products are used in the design of the network elements that provide these diverse set of services, the need for standardized backplane and component interfaces has never been greater. For example, the OIF and IEEE facilitate development and deployment of optical and electrical component/backplane technologies. The book is organized into five categories: 1. Optical Transport Network infrastructure 2. Services offered over Transport Networks
Chapter 1 3. Control and management of Transport Networks 4. Intra-Network Elements and component-centric standards 5. Standards development process The chapter distribution is illustrated in Figure 1-1.
f
Chapters * coverage of the Standards related to the respective categories Optical Transport Network Infrastructure: Chapters 2-8
Services offered over public and private Transport Networks: Chapters 9-15 L J
Control and Management of the Transport Networks: Chapter 16
Network Elements and components: Chapters 17-19
Standards development process: Chapter 20
\
/ Figure l-l. Categorical distribution of chapters
1.1.
OPTICAL TRANSPORT NETWORK INFRASTRUCTURE
1.1.1
Functional Modeling Specification Technique
Optical transport networks have evolved into intelligent and complex networks that provide global connectivity and increasingly diversified services. Such networks need to interoperate between numerous carriers and service providers to ensure seamless connectivity across the globe. This requirement leads to the daunting task of representing and specifying equipment and network functionality and behavior for transport networks in a coherent and implementation-independent manner. ITU-T took the lead in defining a functional modeling specification technique that can be used as the requirements' capture and analysis tool. Chapter 2 describes the fundamental concepts of the functional modeling approach used in multiservice optical transport networks. In reviewing the basics, it describes how the complexity of the network functions can be reduced by a "divide and conquer" approach using the concepts of layers and partitions. The simplicity and versatility of the functional modeling scheme is illustrated by demonstrating how a handful of symbols can be used to represent various networking functions, be they for the network level or for detailed descriptions of functions within the networking gear (even down to the ASIC level). To illustrate its usage, several examples are provided. For
Overview
3
example, functions like the mapping of a Plesiochronous Digital Hierarchy (PDH) client signal onto a Synchronous Optical Networks (SONETySynchronous Digital Hierarchy (SDH) server signal or Add Drop Multiplexing (ADM) equipment characteristics are shown in simple diagrams. Numerous other examples are given in illustrating the usage of the functional modeling techniques. The fundamental concepts developed in this chapter are also used in subsequent chapters where services, management, and control of the multiservice transport networks are described. For the digital design engineer, this platform can be compared to the US Department of Defense's Very High Speed Integrated Circuit (VHSIC) project that resulted in the development of VHSIC Hardware Description Language (VHDL). The intent in creating VHDL was to use it for writing the specifications of electronic devices and systems in a standard format. However, since then the scope of VHDL has expanded significantly, it is now used for designing, simulating and synthesis of Application Specific Integrated Circuits (ASICs). Similarly, the functional modeling techniques developed by ITU-T may be utilized in the design and development process of hardware and software for multiservice transport networks.
1.1.2
Multiservice Optical Transport Network Infrastructure
Since the wide deployment of the Internet, the transport networks that once catered to low bandwidth Time Division Multiplexing (TDM) centric services required evolutionary features to simultaneously support TDM and multiservice data-centric traffic (variable length packets or frames) that had "best effort delivery" or "time and jitter sensitive" characteristics. In the late 1990s, based upon the tremendous growth in data traffic, ITU-T experts determined that there was a need to come up with a new set of standards that was optimized for this ultra-high-growth and data-driven capacity demand. Based upon a set of requirements predicated upon carrier globalization, support for gigabit-level bandwidth granularity for scaling and managing multiterabit networks, and leverage of dense wavelength-division multiple (DWDM) technology, work started on a next-generation optical transport network. This infrastructure was intended to complement the SONET/SDH infrastructure, which was designed around a mux structure starting from VT1.5/VC12 that filled the payload with voice-centric 64 Kb/s traffic. Leveraging lessons learned in the establishment of SONET/SDH standards were also developed.
4 1.1.2.1
Chapter 1 Optical Transport Hierarchy
Chapter 3 describes in detail two key ITU-T standards, G.709 and G.798, that describe the implementation of Optical Transport Hierarchy (OTH). It goes through the rationales and requirements behind the development of a suite of standards. For example, it covers topics including its role as an efficient transport networking layer that supports very high rate services at 2.5, 10, and 40 Gb/s; strong Forward Error Correction (FEC); support of multiple nested and overlapping Tandem Connection Monitoring (TCM) layers; the management of frequency slots Optical Channels, (OChs); single or multiple A,s) instead of time slots (STS-ls, etc.). Furthermore, it extensively covers the details of the G.709 frame structure, how various client signals can be mapped onto it, and the maintenance and management of networked DWDM signals. Prior to the bursting of the telecom bubble, it was widely anticipated that the SONET/SDH signals would be become clients of the OTN. However, in the time frame during which the OTN standardization effort came to fmition, the market need for support of Gbitlevel networking did not materialize, and OTN deployment has been slower than anticipated. Currently, one of the major driving factors in its deployment is the availability of strong Forward Error Correction (FEC) functionality at high speeds. This factor will become even more pervasive as we see the deployment of 40 Gb/s line rates due to the power savings and lower Bit Error Rate (BER) features of the strong FEC. 1.1.2.2
Data and TDM-Friendly Next-Generation SONET/SDH
Leveraging the worldwide investment in SONET/SDH network infrastructure and equipment to support the delivery of new services continues to be an important consideration for carriers. The advantages of this leveraging include incurring only incremental investments for deploying new services and enabling generation of revenues from delivery of new services via standardized mappings into SONET/SDH (e.g., transport of non-SONET/SDH bit-rate payloads). As the saying goes, "Necessity is the mother of all inventions" and this truth led to simple and elegant solutions that changed the status of "legacy SONET/SDH" to "the next big thing." Recent ITU-T standards added the efficient multiservice data-centric transport capabilities to the Time Division Multiplexed voice-centric SONET/SDH networks without requiring a "forklift" upgrade. There were two main issues that needed to be addressed in achieving the desired features: 1) efficient utilization of bandwidth in transporting data traffic and 2) seamless encapsulation of any data centric traffic into SONET/SDH pipes.
Overview
5
Chapters 4 and 5 provide extensive details of the underlying technologies that breathed new life into SONET/SDH. From the networking point of view, a majority of the data-centric traffic across the globe originates in the form of Ethernet frames. Almost everyone who uses a networked computer knows something about Ethernet and feels comfortable with it. This situation led to the huge momentum behind the evolution of the Ethernet that resulted in its emerging from the enclosing scope of local area networks along with high-speed Internet, IP Virtual Path Networks, IP VPN, video distribution, and varied other services. This emergence created a requirement for the efficient transport of Ethernet services over the SONET/SDH and OTN transport network infrastructures. Chapter 4 describes the details of the ITU-T's work on Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) to ensure that future networking needs are met by adding data-centric capabilities into the existing Time Division Multiplexed, TDM, transport structures. The concept behind VCAT is that the primitive payload containers that carry the client data can be virtually "glued" or concatenated to build the desired bandwidth pipe. This outcome is achieved by using pointers in the overhead field of the containers. Theoretically speaking, bandwidth can be added or deleted when desired with the lowest granularity of approximately 1.5 Mb/s (VT 1.5 or VC-11). However, there are no restrictions on changing the desired bandwidth by any container size (e.g., VT-x, VC-n, STS-n, or STM-n). The Link Capacity Adjustment Scheme defines the protocol of how bandwidth can dynamically be changed. In essence, one can say that VCAT in conjunction with LCAS allows networks operators to provide bandwidth on demand without disrupting service while effectively utilizing the SONET/SDH pipes. A nimble and efficient encapsulation protocol known as Generic Framing Procedure (GFP) that supports fixed and variable-length frames/packets over transport networks was also recently standardized within the ITU-T (post2000). Chapter 5 describes how diverse set of protocols can be efficiently mapped into a single transport protocol (GFP) without having to go through multiple layers of encapsulation before being transported over TDM-based core networks. As an example, native IP traffic, Ethernet, Fibre Channel, and Storage Area Networking (SAN) protocols, along with others, can be mapped into GFP with minimal overhead. In GFP there are three main modes of the client frames/packets adaptation: Frame Mapped, Transparent Mapped, and Asynchronous Transparent Mapped. The Frame Mapped adaptation mode is mostly utilized in encapsulating data traffic like Ethernet, IP, MPLS etc. In this mode, the entire client data frame/packet has to be buffered locally first, prior to the encapsulation. This process causes delay
6
Chapter 1
and may not be suitable for time-sensitive traffic. Transparent Mapped modes of the GFP provide low jitter and delay by encapsulating the client signal in fixed-length encoded GFP frames without having to wait for the entire client frame/packet to be buffered.
1.1.3
Global Optical Transport Network Timing
As the saying goes, "Timing is everything." This phrase is an exact fit for transport networking, since we know that timing and synchronization, among the network elements that make up the global transport network infrastructure play a very critical role in ensuring the proper operation and performance of these networks. Chapter 6 gives a comprehensive overview of the timing and synchronization techniques utilized within optical transport network infrastructures. It covers the fundamental concepts of jitter and wander and their relationship with network synchronization. These basic topics lead into the jitter, wander, and synchronization requirements for SONET/SDH networks and the differences between these requirements and those for OTN infrastructures. Moreover, topics including client signal mapping into SONET/SDH or OTN signals, and the accommodation of timing variation to ensure seamless operation, are extensively covered. The architectural solutions to accommodate effects due to jitter and wander within the components/blocks, may these be Clock and Data Recovery (CDR) or SONET/SDH or OTN framers, are provided. The fundamental concepts covered in Chapter 6 have to some extent a high degree of abstraction, since they are described in mathematical terms. To illustrate those points explicitly, it is prudent to follow the discussion with some technology specific concepts and examples. Chapter 7 complements the content of Chapter 6 by adressing the issues within the SONET/SDH systems and networks. It starts out by reviewing why synchronization is needed, how it is administered, and why tracing the timing source is important. Numerous methods of timing extraction mechanisms utilized by the network elements are shown. Chapter 6 also reviews the hierarchical timing distribution across the network. Several architectural examples of timing distribution within the various types of network elements are also presented. 1.1.3.1
Transport Network Survivability
A very important aspect of providing uninterrupted networking services is to ensure connectivity, while maintaining an acceptable level of service quality, under conditions of natural or man-made disasters. This topic is extensively addressed in Chapter 8 under the category of network
Overview
7
survivability. There are two predominant techniques utiHzed for achieving survivable networks: (1) network protection and (2) network restoration. Network protection imphes that there are dedicated resourses that have already been deployed as backups and that "take over" when the primary resources have failed. Network restoration refers to the use of backup resources from a pool of resources, as opposed to dedicated backup resources. Chapter 8 starts by providing the objectives of the protection schemes and covers the details of the major five protection architectures namely, (1) 1+1, (2) l:n, (3) m:n, (4) (1:1)", and (5) rings. Protection switching parameters, protection switching classes, protection switching trigger criteria, automatic protection switching protocol, and examples are discussed. Topics in survivability through restoration implemented by either preplanned or on-the-fly routing with centralized route-calculation techniques and distributed techniques are also covered.
1,2.
CARRIAGE OF SERVICES OVER TRANSPORT NETWORKS
The MEF, ITU-T, and IETF have taken the lead in defining technical specifications, standards and RFCs for extending the reach of Ethernet from its traditional LAN environment to metro- and wide-area networks. The intent of the effort by these standards and industry forums is to ensure that enhanced Ethernet-based services can be deployed reliably and are scalable at lower capital and operating expenses.
1.2.1
Ethernet Services Architecture and Definitions
In describing Ethernet services, it is prudent to describe reference models that can be used in defining terms and services. Chapter 9 lays the foundation for describing the reference models used in defining Ethernet services over metro area networks. These services are defined in such a way that they can be carried over any of the prevailing transport technologies like IEEE 802.3 PHY, IEEE 802.1 bridged networks, SDH VC-nA^C-n-Xc, SONET STS-n/STS-4n-Xc, ATM VC, OTN ODUk, PDH DSl/El, MPLS, dark fiber, etc., or possibly different future networks. 1.2.1.1
Ethernet Services over Metro Networks
Traditionally, services are defined in observable terms, with clear demarcation points between the subscriber and the service provider's
8
Chapter 1
equipment. The subscriber equipment is referred to as the Customer Edge (CE) at which observable service-level parameters are defined that become the basis for a Service Level Agreement (SLA) between the subscriber and the service provider. The physical demarcation point between the Service Provider and a single subscriber is termed a User to Network Interface {UNI) across which such SLAs are made. Beyond the UNI, the types of technology and the architecture inside the metro and wide-area networks are invisible to the subscriber. This transparency allows the services to be defined and observed from UNI to UNI. Moreover, the definition of the services allows the service providers to offer metro- and wide-area Ethernet services to over 100 million existing devices capable of using the services. Chapter 10 describes the service definitions and characteristics of Ethernet Virtual Connection (EVC) as defined by MEF. Details of point-topoint, point-to-multipoint, and multipoint-to-multipoint EVCs enabled by VLAN tags are provided, along with details of how these can be used in offering E-Line and E-LAN services. Traffic and performance management is an integral part of ensuring that the SLAs are met for such services. Traffic policing becomes essential in monitoring compliance with the SLAs and is based on parameters like Committed Information Rate (CIR), Committed Burst Rate Size (CBS), Excess Information Rate (EIR), and Coupling Flag (CF). The performance-monitoring parameters such as frame delay, frame delay variation, frame loss can be used in defining different classes of service. The means whereby these parameters are used in service delivery and performance monitoring/assurance are also covered. 1.2.1.2
Ethernet Services over Public Wide-Area Networks
In Chapter 11, we see that ITU-T has taken its lead from the work done by the MEF and extended the scope by defining the Ethernet services over public wide-area transport networks. ITU-T uses traffic management and performance parameters consistent and complementary with MEF in defining its services standards. In addition to the services description, it covers the transport network models that support the Ethernet connectivity. These include Ethernet private line services that leverage the existing connection-oriented, circuit-switched TDM networks. Several service scenarios that provide diverse sets of applications are provided. Chapter 11 goes on to describe the Ethernet-based user-to-network interfaces (UNIs) and Network-to-Network interfaces (NNIs). To facilitate reliable Ethernet services, Ethernet operations, administration and management, and survivability are also discussed. It should be noted that the ITU-T's datacentric transport technologies like Virtual Concatenation (VCAT), Generic Framing Procedure (GFP), and Link Capacity Adjustment Scheme, (LCAS)
Overview
9
have become the enablers of Ethernet services over SONET/SDH and OTN networks. 1.2.1.3
Ethernet Services over MPLS Networks
Leveraging the extensive work done on Muhiprotocol Label Switching (MPLS) networks, along with its expertise on packet-based networks, IETF has developed RFCs that are the enablers for providing Ethernet services by using MPLS networks. Chapter 12 details Ethernet services over MPLS networks. It starts by describing the fundamental concepts and architectures of layer 2 virtual private networks (VPN) over an MPLS backbone as it sets the stage for the Ethernet services over MPLS. E-Line and E-LAN functions are subsequently discussed, as well as how virtual private wire and virtual private LAN services can be offered. A walk-through example of E-Line emulation over MPLS is given to clarify the concepts and outline the steps needed to provide the service. 1.2.1.4
Circuit Emulation over Metro Ethernet
Traditional voice and other TDM services have been the core of our communication needs and over time have been offered on different technology platforms as these evolve. Ethernet as a service platform has gained significant momentum over the past couple of years. Carriers worldwide are deploying metro Ethernet networks to cater to the everdemanding business customers' requirements for faster and cheaper data and voice transport. Moreover, these carriers are finding increased demand for their existing lucrative TDM traffic, may it be PBX trunks or private line services. Chapter 13 describes the details of MEF's recommendations regarding Ethernet circuit emulation services, such as N x 64 kbit/s, Tl, El, T3, E3, OC-3, and OC-12, across a Metropolitan Ethernet Network. It provides numerous service reference models that can be used in implementing TDM services. 1.2.1.5
Metro Ethernet Network Resiliency
We are seeing tremendous momentum behind Ethernet services that are being offered by carriers to businesses. The availability of the network services to the business is very critical, as is the Quality of Service (QoS). The combination of service availability and QoS has become a crucial aspect of the Service Level Agreement (SLA) between the user and the service provider. Service availability is tightly coupled with network resiliency.
10
Chapter 1
Chapter 14 covers the metro Ethernet network resiliency as recommended by the MEF. Topics like protection types, failure types, resource selection, and event timings are covered. Chapter 14 also discusses timing issues along with service-level specification commitments. Protection reference models are described such that consistent descriptions of protection capabilities are applied on these services across various transmission technologies, network topologies, and policies. This approach enables the description of protection of services in the ETH layer (Ethernet Line Service, Ethernet LAN service, etc.). The models lend themselves nicely to a definition of requirements for the Ethernet services protection mechanism. This definition subsequently provides the framework for the protection in the metro Ethernet and the implementation of the protection schemes.
1.2.2
Storage Area Services over SONET
The data-centric upgrades to SONET/SDH networks and key developments in the Fibre Channel, the widely used protocol for storage-area networks, have provided a strong platform for connecting storage-area networks across town or across the globe. Chapter 15 provides an overview of the trends for tremendous data growth across the globe and the need to access stored data at remote sites. It briefly covers the basics of the storagearea networks and the different technologies that are used therein. It reviews the stringent requirements that storage networks place on wide-area networks when they are connected over wider distances, as well as the need for network resiliency, scalability, and performance. It gives various options for how storage data can be moved across various sites using WDM, storage over IP, Fibre Channel over IP, and SONET/SDH. It makes a strong case for why SONET/SDH (using VCAT and GFP), along with the work being done at the ANSI Technical Committee on Fibre Channel Back Bone (FC-BB-3), provides a good, strong platform for extending the storage-area networks across long distances.
1.3.
CONTROL AND MANAGEMENT OF OPTICAL TRANSPORT NETWORKS
Chapter 16 provides a treatise on the activities of the ITU-T in specifying the architecture and requirements for automatic switched optical networks (ASON), concentrating on defining the critical functions and the required components for the optical control plane. Since the 2000 time frame, the ITU-T has been engaged in developing a suite of Recommendations
Overview
11
encompassing control plane architecture, auto-discovery, signaling, routing, and control plane management requirements and specifications related to optical transport networks. The optical control plane enables rapid establishment of connection services across heterogeneous networks by supporting intelligence that enables transport networks to be dynamically managed for traffic engineering and bandwidth-on-demand applications, particularly in the areas of QoS, connection management, and traffic restoration after network failures. To achieve this goal, it was considered essential to first establish the general networking requirements related to the service control and management functions that are essential elements of the solution. These requirements included the fundamental concepts of separation of call and connection control; relationships among the management, control, and transport planes; and establishment of a flexible control-plane component architecture. One of the goals of this work is to assure that the optical control plane may be gracefully deployed into existing and new transport network infrastructures, and varied network management environments, in an evolutionary manner. This process would allow networks operators to harness the advances in optical transport networking technologies while ensuring that the existing deployed infrastructure is not rendered obsolete. The ultimate goal of the ASON suite of Recommendations is to enable automated cross-domain connection management supporting multivendor and multicarrier interoperability on a global scale. The methodology for the development of the ASON suite of Recommendations involves a foundation of protocol-neutral specifications that facilitate common requirements and behaviors for various technology and implementation options, hence lending themselves nicely to future growth. Chapter 16 also describes the relationships among the various standards and industry forums involved in the development of control plane specifications (IETF, ITU-T, OIF, ATM Forum), including utilization of associated protocol specifications (GMPLS, PNNI).
1.4.
INTRA-NETWORK ELEMENT COMMUNICATION AND COMPONENTCENTRIC STANDARDS
1.4.1
Intra-Network Element Communication
As we have seen in the earlier chapters, we review diverse sets of networking functions and multinetworking services that are presently being
12
Chapter 1
offered or will be offered in the near future. In building the networks and offering such services, numerous different types of network elements are used. Functions within network elements are primarily implemented on optoelectronic modules and ASICs. Chapter 17 starts with architectural examples of packet- and TDM-based network elements that can be used in providing multiservices. Architectural blocks described in the network element architectures can be mapped to ASICs or standard VLSI offered by semiconductor firms or developed in-house by the system vendor. OIF developed a number of implementation agreements that allowed the ASICs or standard VLSI products from different firms to communicate and interoperate with each other. Agreements such as serializer/deserializer (SERDES) to Framer interface or system packet interface operating at different rates are covered.
1.4.2
Optical Interfaces
Chapter 18 covers the diverse sets of topics on the optical interface standards developed by ITU-T. It starts by giving a history and rationale behind the evolution of optical interface standards relating to PDH, SONET/SDH, DWDM, OTN, CWDM, and all optical networks (AON). This chapter covers the general concepts and reference models, along with illustrative examples, so that the reader can subsequently get further details from the relevant standards documents. This approach was deemed necessary due to the large number of standards and the intricate details each respective standard provides. Chapter 18 gives an overview of optical fiber types and optical interface recommendations. It reviews the power budget design considerations and the limitations to overcome worst-case scenarios. Uses of certain coding schemes to achieve the required bit error rates are also covered. Subsequently, examples of discrete and integrated optoelectronic solutions related to operating speeds of 140 Mb/s - 10 Gb/s are highlighted. Finally, the chapter covers the illusive topic (from the standardization point of view) of faults and degradation detection in the optical transmitters, detectors, and amplifiers.
1.4.3
High-speed serial interconnects
In highly integrated network elements with ever-increasing port speeds and port card densities, the pressure is on to reduce printed circuit board (PCB) traces, layer count, and routing complexity. This situation has lead to the usage of serial interconnects using serializer/deserializer devices commonly know as SERDES. The high-speed interconnects operating at
Overview
13
Gb/s rates pose some interesting challenges. Chapter 19 discusses the highspeed serial interconnects that are used in the communication between devices within the same card along with card-to-card communication using the backplane architecture. It reviews the architectural considerations and signal-integrity design challenges. The discussion on topologies and the effects of material loss, layer connection, and the environment lead into the topic of de-emphasis and equalization—a powerful method in achieving highly reliable and robust chip-to-chip interconnects solution. The chapter subsequently gives an overview of the work of OIF, IEEE, and PCI Industrial Computer Manufacturers Group (PICMG) on interconnect standards. Finally, it considers some challenges and possible solutions for 6 Gb/s and 10 Gb/s applications that are anticipated in the near term.
1.5.
STANDARDS DEVELOPMENT PROCESS
The standards development process within the networking field has a long progressive history where innovative technologies are shaped in providing value-added products and services. Over the course of many decades, numerous standards organizations and fora have been working diligently to provide innovative standards and recommendations that have shaped the ever-evolving networking field. To appreciate this work, one needs to understand the behind-the-scene dynamics of what makes these standards bodies and fora "tick." Chapter 20 provides a snapshot of the practices and procedures that are used within ITU-T in developing global networking standards. In this chapter, practices in ITU-T and fora such as MEF and OIF are discussed. It is interesting to note that how the cultures in these organizations develop based on the policies and practices. For example, in the ITU-T, the approval of Recommendations requires unanimous agreements. This very fundamental premise developed a culture at ITU-T where civility and a spirit of cooperation prevail even against a background of fierce competition in the marketplace. However, within industry fora, the culture is quite different, since majority vote (of a certain percentage) governs who "wins." This chapter highlights some interesting insights into the whole recommendations/standards development process that are useful in understanding the "systems." It also highlights the "behind the scenes" hard work of personnel who make such venues possible so that we can appreciate their efforts in making such meetings and gatherings successful.
This page intentionally blank
PARTI Optical Transport Network Infrastructure
This page intentionally blank
Chapter 2 ARCHITECTURE OF TRANSPORT NETWORKS The Functional Modeling Approach^ Eve Varma* and Carmine Daloia** "^Lucent Technologies, "^"^Washington Group International
2.1.
INTRODUCTION
Transport networking has steadily grown more complex as a consequence of more sophisticated customer needs, the convergence of data and transport networking, and conditions imposed by external market and regulatory forces. In the evolution of embedded core transport infrastructures or in building new core transport networks, efficient cost-effective transport capacity expansion, network reliability, flexible and dynamic bandwidth management, and quality-assured service management are of paramount importance to service providers. Given the wide range of technology choices, there is a trend for networks to employ heterogeneous technology equipment. Whereas in the past, transport networks only supported plesiochronous digital hierarchy (PDH) equipment, current networks may utilize equipment employing various technologies, including SONET/SDH, DWDM/OTN, IP/MPLS, Ethernet, and ATM. Current technologies and hierarchies are being designed to facilitate interoperation of equipment produced by different manufacturers, a process that further widens the competitive aspects of equipment purchase. Equipment suppliers may support a number of operators, possibly within a single nation, and may be presented with a number of different equipment specifications. At best, this situation leads to duplication of effort, with several, often very comprehensive, specifications relating to the same piece of equipment. In many cases, especially in a period of standards evolution, the specifications each require slightly different functionality, which may reduce competition and increase the price an operator must pay.
18
Chapter 2
From an operator's perspective, the necessity to fully specify particular equipment in order to avoid confusion and misinterpretation by a number of different manufacturers has led to increased specification complexity, which can make it difficult to judge among competing suppliers. Adoption of a common methodology for describing such equipment is therefore intended to simplify the specification process, to prevent misunderstanding, and to ensure fair competition. It should also present a set of common basic equipment requirements, facilitating inter-operation of multivendor equipment and driving down costs to both the operator and the end user [1]. Spurred by the above factors, motivation arose for establishment of standardized model-based approaches to • Enable description of the generic characteristics of networks, using a common language, at a level that can transcend technology and physical architecture choices; • Provide a view of functions or entities that may be distributed among many types of equipment; and • Concurrently specify transport and management functionality. Accomplishing the above allows us to • Design and plan networks prior to investments, including selection of the most appropriate types of equipment, to support telecommunications services; and • Facilitate development of new transport services and their associated management. As discussed above, the transport network is a large, complex network with various components, and a network model with well-defined functional entities is essential for its design and management. Within this chapter, we introduce and describe transport functional modeling standards, which provide the foundation for equipment control and management.
2.2.
TRANSPORT FUNCTIONAL MODELING
Transport functional modeling can be thought of as a requirements capture and analysis tool. Its objective is to describe the information transfer capability of transport networks in a manner that is independent of networking technology and to provide a set of "tools" for describing, in a common, consistent manner, the technology-specific transport functionality contained within a complex network. It enables • A flexible description of transport network and equipment functional architectures; • A means to identify functional similarities and differences in heterogeneous technology architectures;
A rch itecture of Transport Networks
19
•
A means to derive equipment functional architectures that are traceable to and reflective of the transport network requirements; and • Formation of the basis for a rigorous and consistent relationship between these functional architectures and their associated management specifications. ITU-T Recommendation G.805 [2] was the first transport functional modeling specification developed, and was specifically designed to address the connection-related characteristics of transport networks and equipment. It has been used to provide the methodology and basic concepts that are the foundation for other ITU-T Recommendations for technology-specific network architectures, including: • Synchronous Digital Hierarchy - G.803 [3], the functional architecture of SDH networks - G.783 [4], the functional architecture of SDH equipment - G.841 [5], the SDH network protection functional architecture - G.842 [6], SDH protection architecture interworking • Optical Transport Networking - G.872 [7], the functional architecture of Optical Transport Networks (OTN) - G.798 [8], the functional architecture of OTN equipment - G.873.1 [9], OTN Linear protection The above specifications address connection-oriented networks. In connection-oriented networks, a connection must be set up within the data plane by either the management plane or the control plane prior to the transfer of information across the network. The connection setup process includes the routing process, which determines an appropriate path through the network, and a resource allocation process, which assigns network resources along the calculated path to support the connection. The focus of this chapter is on connection-oriented networks. In addition to connection-oriented networks, connectionless networks are also being deployed in service provider networks. In connectionless networks, data grams are transferred through the network without any prior negotiation of routes or resources. The data gram itself contains sufficient address information for network nodes to route the data gram from its source to its destination. As connectionless networks such as IP and Ethernet have become more heavily deployed within service provider networks in conjunction with the increase in IP and Ethernet service offerings, service providers and equipment suppliers within the ITU-T saw a need to develop a functional modeling specification, namely. Recommendation G.809 [10], designed to address connectionless networks much in the same way Recommendation
20
Chapter 2
G.805 addressed connection-oriented networks. It has been used to provide the methodology and basic concepts that are the foundation for other ITU-T Recommendations for technology-specific connectionless network architectures, including G.8010 [11], the functional architecture of Ethernet networks,
2.2.1
Basic Concepts
The G.805-based modeling approach has allowed us to analyze the transport network and to identify generic functionality that is independent of implementation technology. This outcome has provided a means to describe network functionality in an abstract way in terms of a small number of architectural components, which include topological components, transport entities, transport processing functions, and reference points. These are typically defined by the function they perform in terms of transformations applied to the signal or by the relationships they describe between other architectural components. In general, these functions act on a signal presented at one or more inputs and present processed signals (i.e., transformed signals) at one or more outputs, and are defined and characterized by the information processed between their inputs and outputs. Architectural components may also be associated together in particular ways to form the equipment from which real networks are constmcted. Patterns and structure in the network can be rapidly obscured in a cloud of complex relationships. From a connection perspective, two separate concepts are involved: topology and function. The topology of a network is essentially the set of relationships between nodes (which will later be seen as subnetworks), and it defines the available connectivity. Application of this concept simplifies network description by keeping logical connections distinct from their actual routing in the network and the resources that physically support them. Thus, the logical pattern of interconnection of elements in the network is established without concern for the associated signal processing functions, and this outcome allows an operator to easily establish connections as required. On the other hand, the concept of function refers to how signals are transformed during their passage through the network versus how elements of the network are interconnected. Recommendation G.805 provides elements that support the modeling of both topological and functional concepts. Within the topology domain, the two fundamental concepts that relate to the organization of the network are layering 2inA partitioning.
A rch itecture of Transport Networks 2.2.1.1
21
Layering
We have already introduced the concept of topology, which allows us to separate logical connections from the physical routes and resources used in their carriage. This logical separation is well represented by the client/server paradigm, where the client refers to the signal being carried and the server refers to the entity providing its carriage; i.e., client signals are transported by servers. To utilize this paradigm, we consider the client and server to be two layers, where the client layer is supported by the server layer. The client/server paradigm is recursive, in that any particular server layer could itself be considered a client of another server layer. If we elaborate this paradigm, a network can be represented in terms of a stack of client/server relationships (a stack of layers). It's also useful to note that server layers are relatively more permanent than their clients. This outcome follows from the observation that a server connection must exist both before and after a client connection carried by that server. Layering therefore enables decomposition of a transport network into a number of independent transport layer networks, and this independence provides the required separation between its logical topology and physical routes and resources. In particular, the process for setting up connections becomes layer independent. Network management may also be simplified because each layer's properties can be handled in the same way (e.g., each layer can be assigned a quality of service, monitored for its performance independent of the other layers, and assigned an identification to help in fault isolation). A layer is defined (characterized) in terms of its set of signal properties, which form what is called the characteristic information of the layer (e.g., 2.048 Mb/s and its format). These properties are chosen in such a way that any access points having the same characteristic information can be interconnected. This term emphasizes the abstract properties of the stream in order to avoid the connotations of a physical signal in a medium, though the properties most often chosen tend to be related to the way a particular stream is represented, e.g., the rate and format at which information is transported. Conventionally, lower-order client layer networks use transport services provided by underlying higher-order server layer networks. The notion of higher- and lower-order layers follows the assumption that a server has a higher capacity than its client does, but this terminology is sometimes confusing because higher order layers are conventionally drawn at the bottom of the page. The complete set of access points in the layer that can be associated for the purpose of transferring information defines the boundary of a layer network.
22
Chapter 2
For purposes of clarification, we provide an example of layering utilizing PDH (e.g., a DS3 client) and SONET/SDH. The SONET [12] and SDH [13] standards define a hierarchy of signal layer networks (see Figure 2-1), as do the PDH and FDM standards that preceded them. Each layer network requires the services of a higher-order layer network to perform the required transport functions. We will discuss the exact location of the layer boundaries in more detail later in this chapter. For this example, we describe the primary signal layer networks below: • The logical client signal layer represents the logical DS3 signal, i.e., the DS3 signal rate and format, irrespective of physical media characteristics (e.g., line coding, etc.). • The logical SONET STS-1 / SDH VC-3 path layer network deals with the transport of the DS3 client signal (which may be considered as a "service"). The main function of the path layer network is to provide endto-end supervision capabilities for the signal, which traverses a series of SDH Multiplex Sections. Additionally, the layer maps its client into the format required by the SONET Line layer network, on whose services it relies. • The logical SONET Line or SDH Multiplex Section layer network deals with the reliable transport of path layer network payload and its overhead across the physical medium. The main functions of this layer network are to provide alignment (e.g., frequency or phase) and multiplexing for the path layer network. It relies on the services provided by the SONET Section/SDH Regenerator Section layer network. • The logical SONET Section/SDH Regenerator Section layer network deals with the transport of an STS-N/STM-N frame across the physical medium, and uses the services of the physical layer network to form the physical transport. Functions in this layer network include framing, scrambling, section error monitoring, etc. • The Physical Media Layer network (photonic or electrical), identified as either the STM-N Optical Section (OSn) or STM-1 Electrical Section (ESI), deals with the transport of bits across the physical medium. For example, in the case of photonic media, issues dealt with at this layer network might include optical pulse shape, power levels, and wavelength. This layer is required whenever equipment is to be represented; i.e., physical equipment description is incomplete without provision of physical interfaces. Thus, using the client/server model recursively, a logical DS3 signal would act as the client layer network while being transported by a server logical STS-1 A^C-3 path layer network, the logical STS-1/VC-3 path layer network would be the client layer network to the server logical SONET Line/SDH Multiplex Section layer network, etc.
23
Architecture of Transport Networks Lower-Order Layers ."f Logical DS3 Signal
DS3 payload mapping
Logical Line Layer
STS-1 Path overhead insertion
Alignment of STS-1 Path payload
Logical DS3 Signal
Logical STS Path Layer
DS? payload mapping
Mapping and multiplexing into logical STS-N frame
Logical Section Layer
Line overhead generation
Section overhead generation for STS-N frame
Physical Media Layer
Higher-Order layers
Logical DS3 Client Layer
Conversion into OC-N Physical Interlace
Logical Multiplex Section Layer
Logical DS3 Client Layer
VC-3 Path overhead insertion
Alignment of VC-3 Path payload
Logical Regenerator Section Laver Physical Media Laver
Logical VC-3 Path Layer
Mapping and multiplexing into logical STM-N frame
Line overhead generation
Section overhead generation for STM-N frame
Conversion into STM-N Physical Intertace
5
Figure 2-1. SONET/SDH signal hierarchy examples: DS3 client carried on an OC-N/STM-N signal
The architecture of the Optical Transport Network (OTN), specified within G.872, has layering characteristics analogous to those for SDH. This similarity should not be surprising, as the OTN was similarly developed to provide fully featured transport networking functionality optimized for highcapacity path networking in a multidomain environment. The defined OTN layers are • Optical Channel (OCh) layer that supports end-to-end networking of optical channels for transparently conveying digital client information • Optical Multiplex Section (OMS) layer that provides functionality for networking of a multiwavelength optical signal • Optical Transmission Section (OTS) layer that provides functionality for transmission of optical signals on optical media Recommendation G.872 specifies maintenance requirements for each of the defined OTN layers listed above. During the development of G.709 [14], it was realized that only digital techniques were available to meet the continuity, connectivity, and signal-quality supervision requirements specified in G.872 for the OCh layer. The use of digital techniques within the OTN was not considered to be a serious limitation for the following reasons: • The scope of G.872 is limited to the support of digital client signals.
24
Chapter 2
•
Due to limitations in the current optical technology, it is not possible to build a worldwide optical network (i.e., 3R regeneration of the optical channel is required after a certain distance). • 3R regeneration will be used at domain boundaries to decouple the domains with respect to optical signal impairments. Therefore, G.709 specifies an implementation of the OCh utilizing a digital framed signal with digital overhead. The use of a digital framed signal to implement the OCh allowed for the use of Forward Error Correction to enhance performance within the OTN. Recommendation G.709 therefore defines two additional digital layer networks, the Optical Channel Data Unit (ODU) layer network, and the Optical Channel Transport Unit (OTU) layer network. Characteristics of the OTN will be elaborated in Chapter 3. 2.2.1.2
Partitioning
As discussed earlier, the concept of layering helps us manage the complexity created by the presence of different types of characteristic information in current networks, which utilize multiple technologies supporting a wide range of bandwidths. However, even within a single layer, complexity is introduced by the presence of many different network nodes and the connections between them. In order to manage this complexity, we introduce the partitioning concept, which also uses the principle of recursion to tailor the amount of detail that needs to be understood at any particular time according to the need of the viewer. Partitioning refers to the division of layer networks into separate subnetworks that are interconnected by links representing the available transport capacity between them. The role of the subnetwork is to describe flexibility of connection, with no notion of distance being traversed, where traversal of distance is the role of the link. Subnetworks may be delimited according to a wide range of criteria, including those related to network infrastructure, network services, administrative and/or management responsibility, or even geography. Just as a layer network is bounded by access points that can be associated with each other, a subnetwork is bounded by ports that can be associated with each other. (It is important to note that while an access point can only be associated with one layer network, a port may be a member of one or more subnetworks.) Just as layers enable the management of each layer to be similar, so does partitioning allow the management of each partition to be similar. If we consider that a layer network is actually the largest possible subnetwork bounded by access points, it should not be surprising that subnetworks themselves can also be recursively partitioned into sets of still
Architecture of Transport Networks
25
smaller subnetworks and interconnecting links until the last level of recursion is reached (i.e., a fabric in an equipment). Figure 2-2 below illustrates recursive partitioning of a layer network, focusing upon illustrating the principle of partitioning versus the reasons for creating each partition. As each level of partition is created, it is important to understand that the original set of ports around the largest subnetwork neither increases nor decreases in number. The inner subnetworks are intentionally drawn touching the outer subnetworks to indicate that the ports are members of all the touching subnetworks. As more partitions are created, the inner links that become exposed have their own ports on the inner subnetworks. An interesting concept is that at any particular level of partitioning, subnetworks can be considered as a graph whose vertices are the subnetworks and whose edges are the links. In this view, subnetworks provide for flexible connectivity, while links bridge physical distance.
Figure 2-2. Recursive partitioning of a layer network
As might be expected, the rationale for employing a recursive description of subnetworks also applies to links. Recalling that a link can represent available transport capacity between a pair of subnetworks, link connections have been defined within G.805 as representing the smallest granularity capacity (supported on a server layer) that can be allocated on a link. Thus, a link may be considered as composed of (partitioned into) a bundle of link connections. However, the concept of link partitioning can be further
Chapter 2
26
extended; specifically, we can consider partitioning a link into a set of links of equivalent aggregate capacity (illustrated in Figure 2-3 below).
Links with capacities of x1, x2, x3... respectivelvj
Link with a capacity of y (y>x1+x2+x3...)
Figure 2-3. Partitioning a link into a set of links
This type of link partitioning allows us to assign server capacity to several links, rather than to just one. It thus allows us to assign server capacity to several subnetworks, which is necessary for modeling the sharing of a common server layer by several networks. This link-partitioning concept is particularly relevant to the modeling of variable capacity technology networks. From a terminology perspective, links that have been partitioned into a bundle of smaller links in parallel may be considered as compound and component links, respectively (Figure 2-4).
Figure 2-4. Parallel partitioning of link into links
Links may also be serially partitioned into an arrangement of linksubnetwork-link, illustrated in Figure 2-5; such links may be designated as serial compound and component links, respectively.
11
Architecture of Transport Networks
Serial-compound link
Figure 2-5. Serial partitioning of a link
The concepts of layering and partitioning are brought together in Figure 2-6, which illustrates a "vertical" arrangement of the layering example described earlier. As illustrated, each layer may be thought of in terms of a layer network, which can be "horizontally" partitioned into subnetworks to reflect infrastructure or equipment organization, such as self-healing rings, or to reflect convenient management or administrative boundaries. As mentioned earlier, the same network can be partitioned differently for different purposes. For example, the partitioning for connection management of various services, network administration, and maintenance may all be different.
Logical DS3 Client Layer Logical f STS-1 \^ Path Layer
tvc-3 y Logical (
Line
)^ Layer
^' Multiplex Section ^ Logical I
Section
| Layer
Regen, Section Physical Media Layer Layering View
Partitioning View
Figure 2-6. Illustration of layering and partitioning
We will close this section with an example of how partitioning enables a network management application to abstract the topology of a layer network (Figure 2-7), which is particularly relevant to the connection management
28
Chapter 2
domain. This builds off the example provided in Figure 2-2, and provides a more detailed view of the final stage of partitioning of this particular network to set up a connection from access point A to access point B.
Network connection Layer network
A-
-^B
I, Link
Access point
Subnetwork
Figure 2-7. Enabling abstraction of the topology of a layer network
The topology of the layer network is modeled as an interconnected set of links and subnetworks. The connection management domain utilizes the abstraction of the layer network topology to determine the appropriate set of links and subnetworks required to support a connection between two points. Once the set of links and subnetworks is selected, the transport resources (i.e., the link connections and subnetwork connections) are reserved to support the connection. This description of connection management is applicable to a single layer network, and the processes described are applied one layer at a time, which correctly models the connection management in real networks. As discussed previously, the complexity due to the presence of different types of characteristic information and technologies in current networks is managed using the concept of layering. Real networks are therefore modeled as multiple layer networks, each layer network defined by its characteristic information. The general process for setting up connections is similar for each layer network. As noted before, server layers are relatively more permanent than their clients, since a server connection must exist both before and after a client connection carried by that server. As a consequence, the connection management process must be completed first within the server layer to ensure that a server layer trail exists and is ready to support the client layer connection. The creation of the server layer trail results in new transport
Architecture of Transport Networks
29
resources becoming available within the client layer to support the client layer connection requests.
2.2.2
Functionality
While we have discussed the network topology dimension, and seen how complexity can be reduced by introducing the concepts of layers and partitions, we have not yet said anything about the functionality needed to actually transport a signal across a network. We have shown how network layers represent client/server relationships; we may consider the functionality involved in transporting signals to be the implementation of these client/server relationships. This functionality is provided by the same three transport processing functions in each layer, namely, adaptation, termination, and connection functions. The fundamental components of transport processing functionally are known as "atomic" or "elementary" functions, and are related to a single layer of the signal hierarchy (or layer network). We will later see that "atomic" does not mean that the function could not be further decomposed, but that we choose not to decompose the function at this particular time (e.g., it is not necessary from the particular layer perspective). There are, however, rules for composition (and decomposition) of atomic functions. Transport processing functions have been identified and grouped into classes corresponding to adaptation and termination. As signal transport is directional, these functions have a source, which originates the signal, and a sink, which receives the signal. Source functions apply a transformation to the signal, and sink functions remove that transformation. Source and sink functions thus occur in pairs within a layer, and are bounded by ports, which represent the function inputs and outputs. These ports are actually the same ports that we have described as bounding subnetworks and link connections in our partitioning topology model. Transport processing functions are described in more detail below: • Adaptation Function: An atomic function that passes a collection of information between layer networks by changing the way in which the collection of information is represented into a form that is suitable for the server layer. The adaptation source function is responsible for several key processes: - Client encoding: The adaptation source adapts a data stream to the server characteristics. - Client labeling: The adaptation source "labels" each client so that the corresponding adaptation sink can correctly identify it. This process enables clients to be multiplexed; however, the means by which this is done is very technology specific.
Chapter 2
30
-
Client alignment: Adaptation sources align the client signal with capacity in the server layer, while adaptation sinks remove the effects of alignment. While the actual process is technology dependent, in time division multiplexed (TDM) systems the buffering of the signal is commonly required. • Trail Termination Function: An atomic function within a layer network where information concerning the integrity and supervision of adapted information may be generated and added or extracted and analyzed. While this function's full title is trail termination function, a common abbreviation is just termination function. The termination source is concerned with transforming signals so that they can be monitored for signal quality. This frequently involves the addition of components to the signal for the purposes of monitoring, frequently called overhead. The termination sink monitors the signal quality and removes any overhead. It is this overhead removal function that gives the function its name, i.e., overhead termination. Overhead can be provided via insertion of additional capacity or, alternatively, via usage of already available, but unused, capacity. While not a transport processing function, there is a third function in common use, known as the connection function. • Connection Function: An atomic function within a layer, which, if connectivity exists, relays a collection of items of information between groups of atomic functions. It does not modify the members of this collection of items of information, although it may terminate any switching protocol information and act upon it. Any connectivity restrictions between inputs and outputs are defined. We note that the connection function is actually the same topological component as the subnetwork and has the same properties. These atomic functions are represented using a set of symbols, shown in Figure 2-8, which constitute part of a shorthand diagrammatic notation that will be used for specification purposes. The intent is to simplify technical descriptions via a common set of symbols and naming conventions.
Connection Function Adaptation Function
°
Ports
Figure 2-8. Graphical representation of "atomic" functions
Architecture of Transport Networks
2.23
31
Connections and Points
In Section 2.2.2 we have seen that network layer functionality, including the client/server relationship, may be described in terms of a set of elementary functions. The client/server relationship itself is most precisely defined as the association between layer networks that is performed by an adaptation function. In fact, these elementary functions can be connected to describe the complete layer behavior, with associated rules describing allowable combinations. Functions are interconnected by considering their ports to be bound together, where a binding between two ports is called a reference point (or just point). This convention makes it possible to illustrate relationships between functions without having to explicitly cite which port is involved. Subnetworks allow flexible bindings between their ports, and the binding of two such ports is called a subnetwork connection. The most commonly used bindings and reference points are described below and are illustrated in Figure 2-9:
Sink
Source k / Layer Y/Z Adaptation Source
Layer Y/Z \ Adaptation Sinl
/ \TT/ Y STM-N TCP 0 •^•5..NC...,
STM-N RSNC
Figure 2-14. DS3 client conveyed on an SDH VC-3/STM-N server signal
DS3 Path Link Connection
VC-3/DS3 Adaptation
DS3 aient Signal
—^
VC-3 Trail AP
VC-3 Termination TCP
VC-3 Network Connection
(J) TCP
Figure 2-15. DS3 client conveyed on an SDH VC-3 server signal
We will next examine how to model the carriage of an STM-N client signal on an OTM-n.m server signal (Figure 2-16). The STM-N client signal is treated as a constant bit rate (CBR) signal within a certain bit rate range. Here, the logical CBR client signal is adapted for transport onto an ODUkP trail via the ODUkP/CBRx-a adaptation function. The CBR client signal may be either asynchronously or synchronously mapped into the ODUkP server signal. In this example, an asynchronous mapping is supported. The ODUkP path overhead is provided by the ODUkP trail termination function. The ODUkP client signal is then adapted into an OTUk server trail via the OTUk/ODUk adaptation function (synchronous mapping of the ODUk frame signal into the OTUk frame signal). The OTUk section overhead is provided by the OTUk trail termination function. The OTUk client signal is then adapted into an OCh server trail (forward error correction, scrambling, and clock recovery) via the OCh/OTUk adaptation function. The adapted
Chapter 2
38
signal is then conditioned for transport across the optical medium, and the OCh path nonassociated overhead is provided by the OCh trail termination function. The OCh signal is adapted into an OMS server trail (wavelength assignment and wavelength division multiplexing) via the OMS/OCh adaptation function. The OMS nonassociated overhead is provided by the OMS trail termination function. The OMS signal is adapted into an OTS server trail via the OTS/OMS adaptation function. The OTS nonassociated overhead is provided by the OTS trail termination function. The OTS trail termination function also maps the logical OTM Overhead Signal supporting the nonassociated overhead into the Optical Supervisory Channel and combines the OSC with the OTS payload signal to form the OTSn characteristic information.
CBRx Client Signal ODUkP/CBRx-a Adaptation
CBRx Client Signal
CBRx Path Link Connection
o\
—e
A PPiiH-I'^y
AP ODUkP Trail Termination
ODUk Network Connection
\rp/ TCP
\n/
m
OTUk/ODUk Adaptation
OTUk Trail Termination TCP OCh/OTUk Adaptation OCh Trail Termination TCP OMS/OCh Adaptation
OMS Trail Termination TCP OTS/OMS Adaptation
OTS Trail Termination
Vt^
T
VA-7 OTMmn \ n /
..°I?££ I
\ n /
I--
Figure 2-16. STM-N client conveyed on an OTM-n.m server signal
A rch itecture of Transport Networks
2.2.7
39
Equipment Packaging
We have seen that the topological model of layers and partitions, as well as the interlayer functions, do not specify the packaging of functions into telecommunications equipment. Equipment packaging is the realm where layers, partitions, and functions all come together. We have already seen how partitions can be forced by some physical boundary. Equipment provides such a boundary; therefore, equipment content is either driven by partitioning decisions or certain partitioning decisions are forced by equipment content decisions. Unlike the network model, which can support logical reference points at any layer, equipment is obviously constrained to provide only physical interfaces. Equipment therefore encapsulates some common element of the layer, partition, and functional models. It is clear that larger partitions, which are of interest from a network-level perspective, are not usually wholly contained in equipment. However, as we have discussed earlier, all partitions are bounded by ports and, since adaptation and termination functions are present only in source/sink pairs, it is clear that any network layer can usually have only one end terminating in any particular equipment. Layer functions also present ports to both client and server layers. Thus, the modeling component that is common from both a network- and equipment-level perspective is the port. The intersection of the network partition and network layers inside an individual equipment takes place at these ports; i.e., the equipment encapsulates the ports of a partition and one end of one or more layers. (As a corollary, layers and partitions that are fully contained in an individual equipment are internal matters and are generally not of interest to a network. When the equipment allows some flexibility of internal connections, as is generally the case in current equipment, the equipment may be considered to contain an internal flexible subnetwork, which is defined by the ports available for connection (represented as logical resources). Because equipment only provides physical interfaces, all reference points are located inside equipment and are therefore inaccessible. This property allows the functional description of the equipment to be independent of the implementation chosen. Returning to our example of a DS3 client conveyed on an SDH STM-N signal, we see that Figure 2-14 describes the complete set of functional associations between the client DS3 signal and the logical STM-N signal without ever once referring to any physical equipment. Figure 2-17 below shows a possible equipment functional partitioning, i.e., a typical organization of functions into equipment, to support transport of the DS3 client signal across an STM-N transport network. Specifically, what is shown is a DS3 connection supported by a VC-3 trail that is terminated by STM-N multiplexers and traverses an intervening cross-connect system with
Chapter 2
40
STM-N interfaces and an internal VC-3 matrix. Due to the restriction that equipment can only present physical interfaces, we first complete the model by adding DS3 physical interfaces and ensuring that the STM-N section layers are physical layers. DS3 Client Signal
DS3 Client Signal
""^ \^
\
V
.^ pain Linx L oiinecnon
< ,
K
1.,, v '
y
VC-3SN(: VC-3 LC
VC-3 LC
..
MS/S4
;X"
cp ^MS
RS/MS
RS/MS
OS/RS
CP OS
• / ^
^ ^
OS/RS
^x-^
.OS
STM-N optical signal
Figure 2-24. ADM equipment characteristics
If we consider the direction from ingress to egress of the ring, illustrated previously in Figure 2-19, we can model the protection scheme in a straightforward manner. The specific application example for a 1+1 SNCP ring is illustrated in Figure 2-25. The selector connection function is flexible and is driven by trail signal fail (TSF) signals derived from the S12m_TT_Sk termination points that are reading the S12 layer characteristic information. This arrangement is known as nonintrusive monitoring because, while the layer overhead is read to provide signal quality information, the layer is not in fact terminated. We note that these connection functions model the "bridge" and "selector" previously depicted in Figure 2-19. In this example we illustrated how the model can be used to represent a SONET/SDH ring architecture as well as SDH ring ADM equipment. This example shows how such a model provides a language that links service description, equipment functionality, and equipment management.
45
Architecture of Transport Networks Uni-directional representation
Protected sub-network connection Bridge
Selector
;TSF
u^tvv.Qrki;piiDectiQ.a___
(Q^
Figure 2-25. Subnetwork connection protection using nonintrusive monitoring
In the next example, we illustrate a service provider offering STM-64 switched connection services via an OTN mesh network, focusing our attention on the transport plane as opposed to the control plane, which supports the signaling necessary to automatically setup the connections within the transport plane. The STM-64 service provides flexible connectivity of STM-64 Regenerator Section (RS64) connections. In this example, the term STM-64 is used to refer to the STM-64 RS64 layer network. We illustrate how such a network can be modeled from several perspectives, specifically: • Topological architecture from the STM-64 RS64 network level perspective; • Topological architecture from the 0DU2 network level perspective; and • Associated transport functions from an equipment-level perspective. The customer connects to the service provider's network within the transport plane via an STM-64 physical interface (see Figure 2-26). The service provider provides an STM-64 switched connection service via the combination of a transport plane that supports the flexible connectivity of STM-64 connections and a control plane that provides dynamic routing and signaling capabilities to determine a path for the STM-64 connection and assign resources within the network to support the connection.
Chapter 2
46
Service Provider Network
SDH
xc
SDH XC
UNI
L Nl SDH XC
STM-64 Physical Interface
Figure 2-26. STM-64 switched connection service
The customer, via UNI signaling within the control plane, requests STM64 connections between a set of endpoints across the service provider's STM-64 network. The customer is not aware of, nor does it care about, the technologies and architecture used by the service provider to support such a service. From the customer's perspective, the topological architecture of the service provider's network can be modeled as an STM-64 subnetwork and multiple STM-64 access links (see Figure 2-27). The STM-64 subnetwork provides the flexible connectivity within the transport plane, and the STM64 access links provide the fixed connectivity between the customer and the service provider's network. In using the model to describe the topological architecture, we can clearly see that such signaling provides coordination for connection management between two partitions of the STM-64 layer network.
STM-64 Link
!
[1 | ( ( \
UNI
STM-64 Subnetwork
\^^^
fUNI
STM-64 Link End
Figure 2-27. Topological architecture of the STM-64 layer network
The customer requests an STM-64 connection originating and terminating at specific link ends. The connection is subsequently setup across the STM-64 access links and the STM-64 subnetwork (see Figure 2-
Architecture of Transport Networks
47
28). The connection is partitioned into two STM-64 link connections and one STM-64 subnetwork connection.
STM-64 Link Connection
STM-64 Link Connection
Ai
Figure 2-28. Partitioning of the STM-64 connection
Across the access hnks, the STM-64 hnk connections are supported via the Optical Section 64 (OS64) server trail, as described in Section 2.2.1.1, thus supporting an STM-64 physical interface between the customer and service provider. Within the service provider's network, there is a need to monitor the quality of the STM-64 subnetwork connection as it is transported across the network. Therefore the service provider must transport the STM-64 subnetwork connection via a server layer that can provide the necessary monitoring capabilities. In this example, the service provider supports the STM-64 connection via an OTN. The STM-64 subnetwork connection is supported via an ODU2 server trail. The 0DU2 server trail allows the service provider to monitor the STM64 client as it is transported across its network. The topological architecture from the 0DU2 network level perspective can be modeled as an 0DU2 subnetwork associated with various access groups (see Figure 2-29).
0DU2 Link
a
^ ^
0DU2 Subnetwork
1) 1
1 ^^ 0DU2 Access Group
Figure 2-29. Topological architecture of ODU2 layer network
Chapter 2
48
The ODU2 subnetwork can be further partitioned into four smaller 0DU2 subnetworks corresponding to four OTN cross-connect fabrics, connected via ODU2 links (see Figure 2-30).
/ JL
ODU2LJnk
/
y "^
y^
0DU2 Subnetwork
\ 1^
0 D U 2 Link
\ ^ (K OOU2 H i l l Subnetwork
A\ III
(k 111
ODU2 m Subnetwork l l j
m •
1 V>
C/D
T3
,^H
T3 O
>»
^
c^ T^
o
">, cd
a. ^H
cd
«4H
F/^wr^ ^-5. STS-1 SPEA^C-3^ structure
The Virtual Container overhead bytes are as follows: Jl — trail trace, a 16- or 64-byte information field that can be used to uniquely identify the SDH/SONET signal B3 — BIP-8 bit interleaved parity for path error monitoring C2 — signal label, indicating the use of the payload area Gl — path status: path RDI, path REI F2 — user communication channel, 64 kbit/s H4 — position and sequence indicator F3 — user communication channel, 64 kbit/s K3 — APS (bl.. .b4) + data channel (b7, b8) Nl — network operator octet, used in tandem connection monitoring Z3/Z4 — octets defined only in SONET for future growth 4.2,1 A.
Substructuring
The payload area of the VC-n structures can again be used to transport containers of smaller structure sizes: • The VC-4 payload area can contain three Tributary Unit Groups of order 3 (TUG-3). A TUG-3 structure is 9 rows by 86 columns; they are byte interleaved in columns 4.. .261 of the VC-4; columns 2 and 3 of the VC-4 contain fixed stuff. • A TUG-3 (STS-1) can contain a TU-3, i.e. a VC-3 (STS-1 SPE) and its associated pointer, or it can contain seven TUG-2s. • A TUG-2 can contain a TU-2 (VT6), i.e. a VC-2 (VT6 SPE) and its associated pointer, or it can contain two VT3s, three TU-12s, or fourTU-lls.
Multiplex Structures of the Optical Transport Network • • • •
4.3.
127
A TU-12 (VT2) consists of a VC-12 (VT2 SPE) and its associated pointer. A TU-11 (VT1.5) consists of a VC-11 (VT1.5 SPE) and its associated pointer. A VT3 consists of a VT3 SPE and its associated pointer. The VC-3 pay load area can contain seven TUG-2s. A TUG-2 structure is 9 rows by 12 columns; they are byte interleaved in columns 2... 85 of the VC-3.
THE EVOLUTION OF THE BANDWIDTH
To be able to satisfy the demand for transport of more information on the same optical link, higher-order multiplexers were defined. These multiplexers increased the bandwidth in steps of 4, i.e. the STM-N (N = 4, 16, 64, 256) were defined and similarly OCn (n = 3N). For super-rate signals requiring the full payload area of these new multiplexers, contiguous concatenated (CCAT) containers are defined that provide a contiguous payload area that also increases in steps of 4. These are referred to as VC-4-Xc, with X = 4, 16, 64, and 256. The STM-N structure consists of 9 rows by (N x 270) columns. The overhead is located in the first (N x 9) columns, followed by the payload area of (N x 261) columns. The shaded area in Figure 4-9 represents an AUG-N and it has a fixed phase relation with the STM-N frame. 1
(Nx9) 1
(Nx261)
1 RS-OHarea 1 pointer area MS-OHarea
Figure 4-9. STM-N/OCn structure, N = 1, 4, 16, 64, 256; n = 3N
•
An AUG-(4M) can contain one VC-4-(4M)c or four AUG-Ms (M = 1,4, 16,64).
The structure of the STM-N overhead has also been extended to provide room for all the extra pointers required to allow all possible combinations of transported containers. The B2 size has been increased as well to match the
128
Chapter 4
required accuracy of performance monitoring. The STM-N overhead structure is shown in Figure 4-10. 1 1 IAI RS-OH
2 3 pointers 4 5 6 MS-OH 7
Bl
pi HI B2
p4 p? pio
1 SI
2...3N Al R R HI B2 R R R Zl
3N+1 3N+1...6N 6N+1 6N+1...9N A2 A2 JO NU/ZO 1 El R Fl NU D2 R R D3 H2 H2 H3 H3 Kl R K2 R D5 R D6 R R R D8 D9 DU D12 R R Z2 Ml E2 NU 1
Figure 4-10- STM-N/OCn OH, N=l, 4, 16, 64, 256; n = 3N
Note — for the highest rates (N = 64, 256), this overhead structure is slightly modified, e.g. some of the Reserved octets are used for Forward Error Correction (FEC) or an additional communications channel DDDMX (9216kbit/s). The special H1/H2 value Y/Z "1001 x;cll 1111 1111" mentioned in Figure 4-5 is in fact the contiguous concatenation indicator and shall not be used as a pointer value. The structure of the VC-4~Xc is shown in Figure 4-11. The first column contains the same path overhead as a VC-4. The next (X-1) columns contain fixed stuff and the concatenated payload area is X times that of a VC-4. 1 1|jl B3 C2 Gl F2 H4 F3 K3 9 |NI
X 1
fixed stuff
(X X 260)
payload area
Figure 4-11. VC-4/STS-3c structure
Figure 4-12 provides an overview of the SDH multiplex structures that are currently defined.
Multiplex Structures of the Optical Transport Network
129
1 STM-1 1 1 STIVI-4 ||STM-16||STM-64||STM-256|| 1x1 1 x1 x1 x1 x1 |AUG-256| 1 1 I
|AUG-64|
'^'^
..} 1 AUG-16 1 "" 1
1 AUG-4 1 '^^ higher order multiplexes 1 1"'
1 AUG-1 1 1 1 xN f f
pointer processing muitiplexinq aligning nnapping
AH
x1
1x1 1 AU-4 |
•
|[_VC-4 1
x1
|AU-4-4C|
xl
|AU-4-16C|
xl
1
|AU-4-64C||AU-4-256C||
^ ^ 4 4 |VC-4-4c| |VC-4-16c| |VC-4-64c| |VC-4"256c|
r ; |TUG-3r1
f""^ -^ 1 TUG-2 1 -
Xl. COntinii^ii*^ nnnrs^kfans^kfinn
x4| X3, ' 1 x1 |TU-11||TU-12|| TU-2 II TU-3 |
+ .-*^4
t
t
|VC-11||VC-12|| VC-2 II VC-3 |
•
•
Tlfc
1 C-11 I I C-12| 1 C
i» • •3 1 1 C-4 1
» 1
(> 1) f < 1 C-4-4C 1 1 C-4-16c 1 1 C-4-64C | | C-4-256c | __.„.„:
•
,
,
'
1
Figure 4-12. SDH multiplexing structures
The initial SONET multiplex structure was based on STS-1 (AU-3), but to provide interoperability with SDH, the AU-4 based structure is used for the higher-order multiplex, as shown in Figure 4-13. Emerging client applications, with their specific payload sizes requiring transport over an SDH/SONET network with its own specific structure, are faced with the problem of a relatively limited choice of bandwidth, i.e. concatenation levels. In addition to limited choice, there is also the problem of transport bandwidth inefficiency because the contiguously concatenated containers provide more bandwidth but not necessarily the "right-size" bandwidth.
130
Chapter 4 I QC-3 irOC-12 II OC-48 || OC-192 || OC-768 JxT x1 x1 x1 x1 |AUG-256|
OC-1 x1
I AUG-64 x4 3 AUG-16| x4 AUG-4 AUG-1
I I pointer processing xN multiplexing f aligning f
x3 AU-3
3=
x1
_r x4
x4 higher order multiplexes
x1
x1
x1
x1
AU-4 I [717-4-40 I |AU>4-16C| |AU-4>64C] |AU-4>256C|
mapping SPE rsTsTl
| S T S - 3 c | fsTS-12c I [STS-48C | |STS-192^ |STS^768c|
1
,,,,,,111, -^'"7
1 TUG.2 '1
1 X4|
AO|
*
f
t
T
•
•
•
X2|
r
Xl
contiguous concatenation
\VT^.5\\ VT2 II VT3 || VT6 |
f
| V r i . 5 | | VT2II W 3 | l VT6ISP E |C-11||C-12||
•
00
0^
1 1
1 1
>
ON
>
.2 CO
135
H
O
a o
U
o
00
o
o
^ ^
CO
1^
en U
>
> p
§2
00
C/5
^.1
^ Is o S to
O
PL,
^
^
o
•S
t
§
o^- 1
Table 4-4, SDH/SONET virtual concatenation efficiencies
136
Chapter 4
It is worth noting that if even a single VC12 of an STM-1 is used in an access situation, then a 100 Mbit/s data service cannot be carried unless it is transported in a VC-3-2v. Moreover, with the rapid expansion to carry data over SDH, the need for virtual concatenation at all VC-n levels has become increasingly desirable by operators whose transport equipment cannot handle contiguous concatenation. This is especially true for interworking between global SDH networks and American SONET networks.
4.5.3.
Additional Benefits
The main objective of virtual concatenation is to flexibly provide multiple right-sized channels over an SDH ring or network. Virtual concatenation uses the SDH VC-n payload area directly and therefore does not have the inefficiency of mapping into an asynchronous payload first. In addition, since VCAT is a byte-level inverse multiplexing technique, it has the characteristics of a right-sized bandwidth, with an improved granularity, a low delay, low jitter, efficient reuse of the protection bandwidth, and a high efficiency payload mapping. Virtual concatenation is not restricted to the situation where all the individual VC-n's are transported in a single multiplex section (i.e. within a single SDH signal structure). In fact, the real potential flexibility offered by virtual concatenation occurs when the individual VC-ns forming the logical group are diversely routed over a number of different SDH signals. The diverse routing capability enables the transport of client signals in situations where a single link does not have enough resources to transport the client signal as a contiguous payload. In addition, virtual concatenation provides the network operator with the ability to implement channels in an SDH network that are more appropriate for the new, increasingly router-based applications. The advantages of these channels are bandwidth granularity, right-sized capacity, efficient mapping into VC-n, traffic scalability, and channelized high-capacity SDH interfaces. Finally, virtual concatenated payload transport is transparent to intermediate SDH Network Elements (NEs) on the path between two ends of a channel. Therefore it can be cost-effectively deployed into an existing SDH network without the need to upgrade all the NEs.
4.5.4.
Restrictions
Even though there are many benefits to using VCAT, there are also some restrictions. The size of the transported bandwidth of a VCG is fixed and, if one or more of the virtual containers fail, the full payload is discarded. Once
Multiplex Structures of the Optical Transport Network
137
the operator has provisioned the size of a VCG, it cannot be changed without interrupting the carried signal. Data transport can have a variable requirement for bandwidth regarding the time of the day, or the day of the week. Both these issue are addressed by the extension of the Virtual concatenation standard, know as Link Capacity Adjustment Scheme (LCAS).
4.5-5.
VCAT Details
A distinction has to be made between VC-n-Xv (n=3,4) and VC-m-Xv (m= 11,12,2), VC-n-Xv uses the H4 byte for the Path Overhead (POH), and VC-m-Xv uses K5 bit 2 for the POH. To reserve enough room for future expansion, both H4 and K5 comprise a multiframe. For the VCAT POH, an MFI field and an SQ field are allocated in this multiframe. Figure 4-16 shows the higher-order VCAT multiframe using the H4 byte. The higher-order VCAT multiframe uses the MFI-1 in H4 bits [5...8] for alignment. Figure 4-17 shows the lower-order VCAT multiframe utilizing the K4/Z7 byte bit 2. The lower-order VCAT multiframe uses the Multi-Frame Alignment Signal (MFAS) in K4/Z7 byte bit 1 for alignment.
Chapter 4
138 H4 byte Bitl
Bit 2 Bit 3 Bit 4 Bits
Bit 6
Bit?
1st 2nd multimultiframe frame number number
Bits
MFLl (bits 1-4) SQ LSB (bits 5-8)
"^
1
1
1
1
P T5
1 ^
II
MFI-2 MSB (bits 1-4)
0
0
0
0 1
1
MFI-2 LSB (bits 5-8)
0
0
0
1
II
Reserved ("0000")
0
0
1
0
II
Reserved ("0000")
0
0
1
II
Reserved ("0000")
0
1
0
0
4
II
Reserved ("0000")
0 1
1
0
1
5
II
Reserved ("0000")
0
1
1
0
6
II
Reserved ("0000")
0
1
1
II
Reserved ("0000")
0
0
0
8
II
Reserved ("0000")
0
0
11
9
II
Reserved ("0000")
0
1
II
Reserved ("0000")
0
1
II
Reserved ("0000")
1
0
II
Reserved ("0000")
1
0
II
SQ MSB (bits 1-4)
1
1
1
SQ LSB (bits 5-8)
1
1
1 ^^ 1 11 ^ ^ 0 11 ^ ^ 13 11 0 11 ^ ^ 1 15
1
MFL2 MSB (bits 1-4)
0
0
0
~
n
11
1 11
1 11
2
^ ^
0
1I
0
Figure 4-16. Higher-order VCAT Overhead in the H4 byte
n+1
Multiplex Structures of the Optical Transport Network MFAS in K4/Z7 bit 1 Function
Value
VCAT OH in K4/Z7 bit 2 Function
139
Bitnumber
Value
lilii jll^^^^^^
jljjlljlj^^^^
iiliii
jljl^^^^^^^^^^^^^^^^
IB^^^^^^
111
Extended signal label Not used by VCAT
Fixed Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved
^B
B li^^^^^^^^^^
iill Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved
Figure 4-17. Lower-order VCAT Overhead in the K4/Z7 bit 2
10 11 12 13 14 15 16 17 19 20
21 22 23 24
25 26 27
28 29 30
31 32
140
4.6.
Chapter 4
LINK CAPACITY ADJUSTMENT SCHEME (LC AS)
LCAS provides a mechanism for a hitless increase or decrease of the payload area of a VCG that is transported through an SDH network. In addition, the scheme will automatically decrease the payload capacity if a member experiences a failure in the network, and will increase the payload capacity when the network fault is repaired. The scheme is applicable to every member of the virtual concatenation group. The LCAS standard, i.e. ITU-T recommendation G.7042/Y.1305 [5], defines the required states at the source side and the sink side of the VCG path as well as the control information exchanged between both the source side and the sink side of the VCG path to enable the flexible and hitless resizing of the virtual concatenated signal. The feature characteristic of VCAT links using LCAS is the capability to reduce the transported payload bandwidth in the event of a path failure. This is a good match for data traffic with a mixture of priority levels. The reason for this is that the loss of bandwidth will affect the lower-priority traffic first and should allow the higher-priority traffic to continue passing over the link. The change in payload bandwidth takes place within a few milliseconds, depending on the physical distance between the two ends of the link.
4.6.1.
Link Capacity Increase
To increase the available virtually concatenated payload bandwidth, an additional path has to be set up through the network via the TMN. Once this path has been established, the VC-n can be added to the virtually concatenated signal.
4.6.2.
Link Capacity Decrease (Planned)
In a manner similar to the case of an increase in virtually concatenated bandwidth, decreasing the available virtually concatenated bandwidth requires the VC-n to be deleted from the virtual concatenated signal. Once the VC-n has been taken off the virtual concatenated signal, the path through the network can be deleted via the TMN. Note that in both cases of increasing or decreasing the virtually concatenated signal, a mechanism for the source node and sink node to notify each other about a request for path size changes and the status of the constituent signal is required. This has been accomplished by using a control field embedded in the overhead (OH) that is allocated for the implementation of virtual concatenation.
Multiplex Structures of the Optical Transport Network
141
In addition to the above signaling mechanism, the requirement of "hitless" path resizing (increase/decrease) created a further need for the development of a synchronization protocol between the source and sink nodes,
4.6.3.
Temporary Link Capacity Decrease
A temporary link capacity decrease can also be used if one or more VCn's belonging to a virtually concatenated signal fail. This failure is reported to the source node, which, upon reception and validation of this failure, will proceed by not using the payload area of the failed VC-n for transport of user data. Until the signal failure clears, the available bandwidth for the user is decreased by the size of the payload area of the failed signal. If the failure clears, the sink node notifies the source node, and the recovered VC-n will hitlessly be added to the virtual concatenated signal. First proposed in June 2000, the generic definition of LCAS is now in the new ITU-T recommendation G.7042/Y.1305 [5]. The actual information fields used to convey the control information through the transport network are defined in their respective Recommendations, namely, G.707 [1] and G.783 [2] for SDH and G.709 [3] and G.798 [4] for OTN. ETSI and ANSI refer to ITU-T.
4.6.4.
LCAS Details
Because the LCAS process is an extension of VCAT, it reuses the VCAT path overhead (light shading in Figures 4-18 and 4-19), i.e. the MFI and SQ numbering, and uses reserved bytes and bits for the additional LCAS POH (dark shading in Figures 4-18 and 4-19). The VCAT multiframe is referred to as a control packet because it contains the information needed by the LCAS protocol to control the use of the payload of each member in the VCG. The additional LCAS POH consists of the following: • A four-bit CTRL field, used to convey the operational state, i.e. IDLE, ADD, NORM/ EOS (normal operation with End Of Sequence indicator), or DNU (Do Not Use), of the member from the transmit side to the receive side. The state FIXED indicates that the member does not utilize the LCAS protocol. • An eight-bit MST field, to report the status of each member at the receive side back to the transmit side. • The RS-Ack bit, to acknowledge that the receive side has detected a change in the sequence numbering of the VCG.
142
Chapter 4 •
The GID bit, which can be utilized to verify the connectivity of the VCG through the network. • The CRC bits (eight bits in H4, three bits in K4/Z7), calculated over the total control packet, used for immediate validation of the control packet. Figure 4-18 shows the allocation of the higher-order LCAS POH in the control packet utilizing the H4 byte multiframe. H4 byte
Bitl
Jcs
1st 2nd multi- multiBit 2 Bits Bit 4 Bits Bit 6 Bit? Bits frame frame number number MFI-1 (bits 1-4) 7
C6
C7
Cs
0
1
1
IIM, IM5
M2
M3
M4
1
0
0
Mfi
M7
Ms
1
0
0
11
1 0
0
0
1
0
1
0
1
0
1
1
1
0
0
1
1
0
11
13
1
1
1
0
14
1
1
1
II II II 1 1
^
8 9 10
k Reserved ("0000") Reserved ("0000") Reserved ("0000") SQ MSB (bits 1-4) SQ LSB (bits 58)
II MFI-2 MSB (bits 14) 1 Mn-2 LSB (bits 58) |cTi CTz CT3 CT4 II Reserved ("0000") 0 0 GID II Reserved ("0000")
1 ^ c,
1
1 11
^^
1 12
0
0
0
0
0
0
0
0
1
0
0
1
0
1
0
0
1
0
1 11 15 0 11 ^ 1 11 1 0 1 2 11 3 0 1 "1 1 11 5
Ci
C3
C4
0
1
1
0
||C5
Ce
C7
Cg
0
1
1
11
6 7
]MI
M2
M3
M4
1
0
0
0
8
n+1
Figure 4-18. Higher-order VCAT + LCAS Overhead in the H4 byte. Light Shading: reuse of the VCAT path overhead. Dark shading: use of reserved bytes and bits for the additional LCAS POH.
Figure 4-19 shows the allocation of the lower-order LCAS POH in the control packet utilizing the K4/Z7 byte bit 2 multiframe.
Multiplex Structures of the Optical Transport Network MFAS in K4/Z7 bit 1 Function
Value
VCAT + LCAS OH in K4/Z7 bit 2 Function
MFI (bits 15) LSB MSB
Multiframe alignment signal SQ (bits 16)
0 CTRL (bits 14)
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
GID Reserved Reserved Reserved Reserved RS-Ack
LSB CTi CTa CT3 CT4
0 0 0 0 , Ml M2
MST(bitsl8)
M3 M4 M5 M6 M7
CRC(bitsl3)
Bit number
Value MSB
0
143
Ms Ci C2 C3
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 3J
32
Figure 4-19. Lower-order VCAT + LCAS Overhead in the K4/Z7 byte bit 2. Light Shading: reuse of the VCAT path overhead. Dark shading: use of reserved bytes and bits for the additional LCAS POH.
1
144
4.7.
Chapter 4
ADVANTAGES OF USING VCAT LCAS AND GFP
Both GFP mapping modes GFP-F and GFP-T may use the Virtual concatenation techniques described above. Virtual concatenation allows matching of the transport bandwidth as closely as possible to the bandwidth required by the client signal. The actual bandwidth required by the client signal may be a fraction of the standard LAN bit rate and may not be constant. LCAS provides the flexibility of changing on demand the size of the transported payload. LCAS also provides the capability to adjust the required protection bandwidth to the availability requirements in steps of (1/Xy^ of the working bandwidth. One of the applications that may use GFP mapping is DP. One of the technologies that uses DP as a means of transport is Voice over IP (VoIP).
4.8.
IMFLEMENTERS GUIDE FOR VCAT AND LCAS
The VCAT functionality can be implemented in part by reusing existing devices that provide the individual VC-n termination points and access to the VC-n payload signal, and the H4 or K4/Z7 overhead bytes at the network or server-layer side and devices that provide access to the payload signal of the client signal to be transported by the VCG at the customer or client-layer side. The VCAT implementation is then required for the distribution and reconstruction of the transported payload and the VCAT specific overhead. Part of the reconstruction of the transported payload is the compensation of the differential delay. For the actual delay buffer, commercially available memory devices can be used, thereby providing the possibility of matching the memory size with the required or acceptable maximum differential delay. The LCAS protocol is described in ITU-T recommendation G.7042 [5] by using state machines specified in SDL diagrams. SDL is the Specification and Description Language described in ITU-T recommendation Z.IOO. While the individual state machines for each member are not complex, the interworking may be complicated.
4.8.1.
Detection of Differential Delay
The differential delay can be detected by comparing the value of the MFI fields in the VCAT overhead among all the members within the group. For VC-4-Xv and VC-3-Xv, the MFI is the combination of the MFI-2 field and the MFI-1 field into a 12-bit number. The differential delay is calculated (in frames) by subtracting the MFI of one member from another member using 2's complement math. The result
Multiplex Structures of the Optical Transport Network
145
is interpreted as a 2's complement number. When the process of differential delay detection is initiated, there is no a priori knowledge of the delays, and thus the result of this calculation may be either positive or negative. A positive result indicates that member 1 leads (has less delay than) member 2 while a negative result indicates that member 1 lags (has more delay than) member 2. With a 12-bit number and a frame rate of 125 |as, the maximum differential delay could be 512 ms. However, due to aliasing, this value cannot be used. For example, an actual differential delay of 384 ms between two members will be calculated as a difference of -128 ms using the 2's complement math. Thus the leading delay of 384 ms aliases to a lagging delay of 128 ms. To avoid aliasing, the maximum differential delay is defined to be less than half the maximum detection range. For VC-11/12/2, the MFI field is only 5 bits, but with a frame rate of 16 ms, the maximum detectable differential delay is also 512 ms. While the standard allows for a maximum of 256 ms of differential delay to be detected, most implementations will not support the maximum. With a fiber propagation delay of 5 ms per 1000 km, a signal sent around the earth (40,000 km) will experience a delay of 200 ms. Supporting a differential delay less than the maximum will also decrease the probability of aliasing. By using the MFI to determine the differential delay, the accuracy of the delay is related to the frame rate, e.g. 500 |us for VC-12 VCAT. The accuracy of the calculation can be improved when the byte number within the frame is tracked as well. Now the differential delay can be determined down to the byte level if desired, e.g. 3.6 |as for VC-12 VCAT. Another aspect of differential delay detection is to determine whether the differential delay exceeds the available buffer space. If the actual differential delay goes beyond the implemented buffer range, this error condition will be detected and reported, since the data will be corrupted if the delay buffers cannot be aligned properly,
4.8.2.
Compensation of Differential Delay
Realignment of the received VCs can only be accomplished by buffering the incoming data from the time the least-delayed VC arrives until the mostdelayed VC arrives. The required buffer size, i.e. the physical amount of memory, depends on the bit rate of the payload data, the maximum number of members in the VCG, the acceptable differential delay, and the buffer management scheme. The implemented maximum acceptable differential delay can be negotiated between the vendor and the operator and may depend on the network topology and/or the cost of the required buffer
146
Chapter 4
memory. The acceptable differential delay may be further limited by provisioning based on operator policy. Examples of the amount of memory required to compensate for the experienced differential delay are calculated as follows: •
VC-12 The VC-12 pay load container structure consists of 4 rows x 34 columns or 136 bytes repeated every 500 |us. The amount of buffer memory required is 272 bytes per ms per VC12. Example: 10 Mbit/s Ethernet transported in a VC-12-5v: The buffer memory required is 5 x 272 = 1360 bytes per ms differential delay.
•
VC-3 The VC-3 payload container structure consists of 9 rows x 85 columns or 765 bytes repeated every 125 ps. The amount of buffer memory required is 6120 bytes per ms per VC-3. Example: 100 Mbit/s Fast Ethernet transported in a VC-3-2v: The buffer memory required is 2 x 6120 = 12,240 bytes per ms differential delay.
•
VC-4 The VC-4 payload container structure consists of 9 rows x 260 columns or 2340 bytes repeated every 125 |LIS. The amount of buffer required is 18,720 bytes per ms per VC-4. Example: 1 Gbit/s Gigabit Ethernet transported in a VC-4-7v: The buffer memory required is 7 x 18720 = 131040 bytes per ms differential delay.
4.8.3.
Structure and Management of Differential Delay Buffers
The features that have to be supported and the flexibility of the implementation will determine the structure and management of the differential delay buffers. If the implementation is required to support VCAT without LCAS, there are simplifications from an implementation that must support LCAS. Table 4-5 below illustrates some of the delay buffer
Multiplex Structures of the Optical Transport Network
147
management differences between non-LCAS and LCAS implementations. That is, LCAS requires more dynamic and flexible buffer management than a non-LCAS implementation.
Feature Alignment required
Non-LCAS - at startup - after error recovery
Differential delay range determination
" at startup
Sequence number allocation
Fixed - at startup
LCAS - at startup - after error recovery - at member addition - at startup - after error recovery - at member addition - at member removal Variable - at startup - at member addition - at member removal
Table 4-5. Delay buffer management differences
4.8.4.
Differential Delay Buffer Overview
While the differential delay buffers can be conceptually thought of as FIFOs, they are generally implemented as circular buffers with read pointers and write pointers. As the member data arrives, it is written at the write pointer location. Once the differential delay is determined, the read pointer is set for each member link and the reconstruction of client data can begin. Depending upon the implementation, either the read pointers or the write pointers are synchronized across all members of the group. This synchronization step across the multiple delay buffers in the group favors the circular buffer architecture over a strict FIFO implementation. Once aligned to the MFI, the depth of the buffer, or the difference between the read pointer and write pointer, generally stays constant. There will normally be some jitter caused by pointer adjustments in the transport network and the presence of the SDH/SONET overhead bytes. Typically, the pointer adjustments will not occur at the same time and the overhead bytes will not be aligned. However, since all the member signals of a VCG are generated with the same clock, the long-term clock rate of the members will not diverge.
148
4.8.5.
Chapter 4
Alignment within a VCG
For VCAT, alignment of the members is required when the group is created. Realignment will be required after an error condition, since the routing through the network of one or more members in the group may have changed. Since the (re-) alignment occurs when data is not valid, the effect of the alignment process on the data transport is not critical. For VCAT with LCAS enabled, the alignment process is also active each time a member is added to the group. The alignment process should then check whether the calculated differential delay of the additional member is within the implemented boundaries (i.e. the available buffer size). The alignment process can start as soon as the control packet with the CTRL word ADD is received. The process should be ready when the control packet with the CTRL word NORM/EOS arrives and consequently can hitless increase the bandwidth. When adding a new member to an existing VCG, there are three possible scenarios: the new link may have similar delay, less delay, or more delay than the existing members in the group. If the new member experiences similar delay through the network, the delay of all the members of the VCG remains the same, and the new member and its associated delay buffer are added to the VCG. In this scenario, neither the differential delay range nor the propagation delay of the group will be modified. If the new member experiences less transport delay than the existing members in the VCG and the available delay buffer is large enough to accommodate the required delay compensation, the member is simply added to the group. This outcome increases the differential delay range of the group but not the propagation delay. If the new member experiences more propagation delay than the existing members in the VCG, then, to align the new member, delay has to be added to all the other members in the group (by increasing the size of each member's individual delay buffers). This addition increases both the differential delay range and the propagation delay of the group. These scenarios bring up bring up many interesting design points concerning propagation delay or latency. Depending upon the type of client traffic transported, there are trade-offs between latency and flexibility. Some applications are more sensitive to changes in the latency than to the latency itself. In this case, changing the latency of the group to accommodate a new member with more propagation delay that the existing members in the VCG may not be desired, and the new member may be refused by maintaining the fail condition, i.e. MST=FAIL. If fixed latency is a desired
Multiplex Structures of the Optical Transport Network
149
feature, the operator has to calculate and provision the worst-case latency that shall be used from the moment the group is initiated. Other applications are insensitive to changes in the latency; the implementation can even try to minimize the group latency. Change in the latency of a group, can either be slow, by increasing or decreasing the data playout rate slowly, or instantaneous, by stopping the data playout until the desired delay buffer depth is reached.
4.8.6.
Sizing the Delay Buffers
Depending upon the type of memory used, implementation can trade off simplicity for size of memory. If the memory chosen is very expensive, like ASIC internal memory or SRAM memory, the buffer sizes should be minimized. To achieve this result each member in the group will have a different amount of memory dedicated to its delay buffer. While this setup results in an optimal use of memory and a minimal memory size, the management of the delay buffers will become very complex and may limit the flexibility of LCAS groups. The simplest buffer structures are based on the maximum allowable propagation delay (determined by the vendor or buyer of the equipment). These buffers allow indexing based upon MFI and byte location within the member frame. The simplest buffer structures, however, are probably the least memory efficient, since memory efficiency is traded for simplicity and cheaper external DRAM could be used to support these simple structures.
4.8.7.
Processing Time
One feature of LCAS is that the source process controls the exact multiplexing order and timing of member additions and removals. This feature requires the sink process to react to the contents of the control packets at the very next multiframe boundary. The next multiframe boundary is located approximately 42 |Lis after the last (H4) byte of the HO VCAT control packet and approximately 125 |Lis after the last (K4) bit of the LO VCAT control packet. Although at first glance this may seem to be a lot of time, issues can arise if the implementation should have the capability of supporting very large VCAT groups and/or a large numbers of VCAT groups simultaneously. The major task that has to be performed within this time frame is to determine changes in the multiplexing order and to configure the data path accordingly to be able to switch to the new order at the beginning of the next multiframe. Because the CRC validates the content of a control packet, it is not useful to start interpreting MFI and SQ values before the CRC arrives. The standard
150
Chapter 4
requires that control packets with CRC failures be ignored. The CRC validation gives a faster response than the more common 3 or 5 times exact match validation. Ignoring a control packet that contains a change because it is erroneous could cause data corruption; however, the frequency of change within an LCAS group is fairly low, and the probability of data loss is even less. The implementation must resolve any inconsistencies within the VCAT group, such as duplicated or missing SQ numbers and duplicated or missing EOS control words. Since the probability of bit errors within the SDH/SONET network is low, the number of erroneous control packets is also low. The amount of processing time required to handle erroneous control packets is implementation dependent. Since the acceptable member state changes are limited and there are rules governing sequence number reassignments, some erroneous control packets may be reconstructed by analyzing the control information of the remaining members of the group. The question is, as always, whether the results justify the effort. A more common scenario is the total failure of a member trail. In this case, the member trail termination reports a signal fail (TSF) and the member is moved to the DNU state according to the LCAS procedure. The member remains in this DNU state until the trail failure is repaired. Since communication is lost with that member at the sink side, removal of the member from the group by the source process cannot be detected except by correlating the SQs of the remaining members.
4.8.8.
Controlling Distribution/Reconstruction Order
In the VCAT process, the client payload is distributed at the source side over all the individual member payload areas, octet by octet, in a round robin fashion. At the sink side, the client signal is reconstructed by interleaving the octets from all the member payload areas. It is essential that the order of distribution is also used for the reconstruction. That is the reason the source assigns sequence numbers to the members. Each member transports its assigned sequence number to the sink for the sink to use in the reconstruction process. A special case is introduced for the VCAT application with LCAS enabled. Here, only active members carry the distributed payload, i.e. members in the NORM/EOS state. A member can also be in the DNU state. While in the DNU state, the member retains its sequence number but will be skipped in the distribution/reconstruction process. When implementing LCAS, the DNU state could be handled by implementing an interleave sequence number. The interleave sequence
Multiplex Structures of the Optical Transport Network
151
number controls the distribution/reconstruction process. The interleave sequence number is assigned to a member based exclusively on the member status NORM/EOS. Table 4-6 contains an example. Member
1^
b
State NORM NORM Assigned SQ nr 0 1 1 Interleave SQ nr 0
c
d
e
f
DNU 2 n/a
NORM 3 2
DNU 4 n/a
EOS 5 3
g DNU 6 n/a
Table 4-6. Example of the interleave sequence number
4.8.9.
Member Status
The member status is the parameter to communicate the health and usability of the members from the sink side back to the source side of the VCG. The MST protocol uses one bit for each sequence number to indicate whether the member status is OK=0 or FAIL=1. The MST bits are transferred in an MST multiframe; its size is determined by the maximum of SQ numbers and is technology specific (e.g. 256 for HO SDH LCAS). Since not enough bits are present in a single control packet, the member status is serialized over multiple control packets. All members of the VCG transfer the MST multiframe. This ensures correct operation with just a single member in the reverse direction. Since all information is carried on every member, implementations that monitor just a single return member are allowed. The renumbering of the members when members are added or removed from the VCG complicates this simple protocol. Whenever a member is added to the group, the new member receives the next available higher sequence number. When a member is removed from the group, all members with a higher sequence number must be renumbered (decremented by one). Note that a member may have one sequence number while in the ADD state and a different sequence number when it transitions to the NORM/EOS state. When the sequence numbers of the members change due to member addition or removal, there exists a period of uncertainty during which it is not known whether the reported MST is for the old numbering or the new numbering. This period is caused by transmission propagation delays and processing delays. To control this period of uncertainty, the source will stop interpreting the received MST until the sink acknowledges that it detected a change in sequence numbering by toggling the RS-Ack bit. Once the toggling is detected by the source, it will assume that the received MSTs match the current numbering again.
152
Chapter 4
In certain situations, the sink side may not detect a resequence operation and consequently may never toggle the RS-Ack bit. One of these cases where the resequence may not be seen by the sink side is with the removal of a member in the DNU state that has the highest SQ number of the VCG. This is resolved in the standard by the definition of an RS-Ack timeout timer that is started when the source stops processing the MST due to a resequence. When the timer expires, the source will continue to process the MST and assumes the RS-Ack was lost or not sent.
4.9. REFERENCES [1] [2] [3] [4] [5] [6]
ITU-T Recommendation G.707/Y1322, Network Node Interface for the Synchronous Digital Hierarchy SDH, 2003. ITU-T Recommendation G.783, Characteristics of Synchronous Digital Hierarchy (SDH) Equipment functional blocks, 2003. ITU-T Recommendation G.709, Interfaces for the optical transport network (OTN), February 2001. ITU-T Recommendation G.798, Characteristics of OTN equipment functional blocks, November 2001. ITU-T Recommendation G.7042/Y. 1305, Link Capacity Adjustment Scheme (LCAS) for Virtual Concatenated Signals, 2003. ANSI American National Standard T1.105, Synchronous optical network (SONET) — Basic Description including Multiplex Structure, Rates and Formats.
Chapter 5 GENERIC FRAMING PROCEDURE (GFP) Enrique J. Hernandez-Valencia Lucent Technologies
5.1.
INTRODUCTION
The Generic Framing Procedure (GFP) is a new protocol recently standardized under ITU-T G.7041/Y.1303 [1] and ANSI Tl.105.02 [2] and designed to support variable- and fixed-length packet transport modes over a general-purpose bit or byte synchronous high-speed communications channel. GFP extends the HEC-based packet delineation mechanism used by other broadband applications such as ATM [3] to variable-length data transport applications. GFP exploits the ability of modern point-to-point transmission links to deliver the incoming information stream in a sequential and orderly fashion to greatly simplify data link layer synchronization and frame boundary delineation operations. Unlike packet delineation mechanisms based on the HDLC framing procedure [4, 5], GFP requires no special line encoding for the framed protocol data units (PDU), which substantially reduces processing logic requirements for the data link mapper/demappers. Unlike ATM, GFP delegates high-touch QoS management functions to the client layers, which further reduces operational overhead. The lower implementation complexity makes GFP particularly suitable for high-speed transmission links such as SONET/SDH [6, 7] pointto-point links, wavelength channels in an optical transport network [8], or even dark fiber applications [9]. For high data rate environments, GFP is a very attractive alternative to solutions such as ATM, Frame Relay [10], PPP/HDLC [11], PPP-over-SONET (PCS) [12], or X.85/X.86 [13, 14].
154
Chapters
TDM
PHY
PHY
PHY
PHY
STS/VTJJross-Connect Matrix
X
Virtual Concatenation/ LCAS
GFP Encapsulation/Framing
Packet Swjlch
Ports
PHY
PHY
PHY
PHY
Figure 5-1. High-level functional model of a hybrid Ethernet/TDM transport system
From a hybrid Packet/TDM system perspective, as illustrated in Figure 51, two aspects are of key relevance when discussing transport mechanisms for packet-oriented traffic over a TDM-based telecommunications infrastructure: (1) the data-link "adaptation" mechanism to transform the packet-based data flow into a bit/byte stream that preserves the native packet structure, and (2) the rate adaptation mechanism to map the resulting bit/byte stream into the SONET/SDH payload. For Ethernet transport, for instance, all solutions of practical interest (ATM, FR, POS, X.85/X.86, and GFP) perform data-link adaptation by reencapsulating the original protocol data unit (PDU) and then reframing the resulting PDU into a TDM-friendly cell/packet flow. It is this PDU "framing procedure" that largely differentiates the various solutions. The final rate-adaptation step is fairly similar across technologies. For constant-bit-rate-oriented traffic, the adaptation models over TDM-based telecommunications are based on the
Generic Framing Procedure (GFP)
155
principle of quantization of the incoming flow, with options for line code compression, if feasible. Rate adaptation typically requires fine-grained mapping of the adapted client signal into its new constant-bit-rate container to minimize additional signal jitter and wander. This chapter provides an overview of GFP. The chapter begins with a review of background information, related work associated with packet transport over public networks, and design factors influencing its development. Next follows a brief summary of current formats, procedures, and implementation considerations. The chapter closes with a discussion on performance and a sample look at applications.
5.2,
BACKGROUND
The immense popularity of the Internet and Internet Protocol- (IP-) based networks has created an explosion in the number of IP-based end systems, and consequently, in the aggregated IP traffic being carried over the public circuit-switched infrastructure. Most of this traffic originates in corporate LANs, which are today over 90% Ethernet based. While voice and private line traffic still account for a majority of traffic in most public network backbones today, it is widely expected that packet-oriented traffic, originating from IP end systems or native Ethernet transport applications, will dominate the public backbone traffic in the not-so-distant future. (Indeed, this is already the case for IP-centric Internet Service Providers [ISPs]). This increase in IP and native Ethernet traffic demands much higher access link rates than those in use today. It also demands data transport approaches that are compatible with future data-aware value-added services.
5,2,1
Packet Transport on Public Networks
Figure 5-2 illustrates various transport options for packet traffic over the public network infrastructure. A significant portion of IP traffic today is encapsulated in Frame Relay, PPP/HDLC, or POS, or isadapted to ATM for transport across a TDM-based core network. Currently, most Frame Relay and PPP line interfaces operate at DSl/El, DS3/E3, or 0C-3c/STM-l rates or less. The same is true of most line interfaces for IP edge routers, although OC-48C/STM-16 and OC-192c/STM-64 SONET/SDH interfaces are being deployed at an increasing rate, particularly in the core of metropolitan and wide-area networks. Ethernet and Storage Area Networking (SAN) protocols such as Fibre Channel, ESCON, and FICON have traditionally been transported over the public network infrastructure by means of proprietary (vendor-specific) solutions. Given the widespread availability of
156
Chapter 5
inexpensive 10/100/1000 Mbps Ethernet interfaces for CPE switches/routers, the growing need to improve data center/SAN interconnectivity, and the recent additions of Virtual LAN-based Virtual Private Networking (VPN) and QoS capabilities via IEEE 802.1Q/P, there is a renewed interest in a QoS-friendly, standard-based mechanism to transport Ethernet and SAN traffic directly over TDM networks. Voice (Applications)
Data (IP, IPX, MPLS, etc.)
SANs (Applications)
Video (Applications)
Ethernet* (MACS & PHYs)
Private Lines (Circuits)
RPR (MACS & PHYs)
o:
PPP (Services)
(Services)
ATM (Setvices)
HDLC I (Encapsulation) |
GFP (Encapsulation)
SONET/SDH (Physical Channels)
OTN (Physical Channels)
Fiber or WDM (Physical Channels) ' May also run directly on fiber
Figure 5-2. Transport options for voice, data, storage, and video traffic over a SONET/SDH network and Optical Channels via ATM, FR, HDLC, or GFP
5,2.2
Other Traffic Adaptation Approaches
While flag-based PDU delineation has been common in various framing and payload mapping standards, alternative approaches have been in use as well. For packet/cell delineation, ATM relies on implicit information about the packet length (fixed at 53 bytes) and the header CRC, rather than a flag, for the purpose of packet delineation. The header CRC match is used for initial link synchronization. The fixed packet (cell) size and the header CRC are used to verify link synchronization after initial link synchronization has been established. The fixed-length ATM PDUs significantly simplify processing at the data link receiver. There are also more recent examples of PDU delineation using implicit and explicit PDU length indicators. ATM Adaptation Layer, Type 2 (AAL-2) [15], packs variable-length PDUs into fixed-length ATM cells. A PDU length indicator is used to provide self-delineation once the packet boundary is identified. At the
Generic Framing Procedure (GFP)
157
beginning of each ATM cell, the length pointer helps regain frame delineation quickly. A similar mix of a PDU length indicator and boundary pointer is used for the downstream communication channel in Hybrid Fiber Coax (HFC) links using ADAPt+ [16]. In ATM, AAL-2, and HFC, the basic lower-layer framing exploits the fixed-length format of the PDUs at that protocol layer (ATM cells, downstream frames for HFC). The pointers and length indicators are then used to provide delineation of variable-length PDUs within the payloads of the lower-layer protocol. In absence of a lowerlayer framing with fixed-length frames, a delineation mechanism applicable to the variable length PDUs directly is needed.
5,2.3
Other Design Considerations
Although it would seem straightforward to extend the frame delineation and synchronization procedures used for ATM and other fixed-length PDUs to variable-length PDUs, that is not the case. Some of the issues that need to be addressed [17-18] are as follows: • For fixed-length PDUs, it is important to allow an efficient format for accessing and buffering the adapted PDUs. A header CRC could be used to identify a potential PDU boundary and then invoke the fixed PDU length to jump to the next frame boundary, and to verify that frame synchronization has been achieved. When the second header CRC check fails, because of the false start, the real PDU boundary may have been lost among the many bits/bytes jumped over. In ATM, the small cell size guarantees that, at most, 53 bytes are lost. Large variable-length PDUs make this test more difficult. A false match of the header CRC and a subsequent invocation of the wrong length indicator could waste a large number of opportunities to identify the true PDU boundary. Thus, straightforward extension of the procedure used for ATM may result in a much longer resynchronization interval for variable-length PDUs. • For small, fixed-length PDUs, a failed header CRC need not cause immediate loss of synchronization because the PDU length is specified implicitly. With variable-length PDUs, a failure in the header CRC makes the PDU length indicator itself suspect and causes immediate loss of synchronization. The error correction capability becomes very important for variable-length PDUs. • Small PDUs also imply that a single user can gain control over the link payload only for a very short period of time. PDU interleaving from multiple sources decreases the probability of successful attacks from malicious users trying to induce low bit transition density on the link. In large, variable-length PDUs, a single user gets access to the link for a
158
Chapter 5
much longer time period. Mechanisms to counter attacks aimed at creating very low bit transition density over the data link become critical. • Variable-length PDUs tend to have loose maximum size bounds (up to 64 Kbytes in IP), which make the resynchronization phase. The above protocol design issues are carefully addressed in GFP. The next sections presents the design choices made in the specification of the formats and procedures for GFP.
5,3.
FORMATS AND PROCEDURES
A high-level functional overview of GFP is presented in Figure 5-3. GFP consists of both client-independent and client-specific aspects. Common aspects of GFP apply to all GFP-adapted traffic and cover issues such as PDU delineation, data link synchronization, payload scrambling, client and control PDU multiplexing, and client-independent performance monitoring. Client-specific aspects of GFP cover issues such as mapping of the client PDU into the GFP payload and client-specific performance monitoring and OA&M.
Ethernet
1
HDLC/ PPP
RPR
IP/ MPLS
other Client Signals
ESCON
Framed Mapped
FICON
Fibre Channel
DVB ASI
Transparent Mapped
GFP Clu3nt-Specific Asf)ects GFP Common Aspects PDH Path
SONET/SDH Path
OTN ODUk Path
Figure 5-3, High-level functional model
Generic Framing Procedure (GFP)
5,3,1
159
GFP Frame Formats
The GFP frame format is designed to support both the multiplexing of multiprotocol PDUs as well as the multiplexing of a number of logical virtual links within the data link. Logical virtual links can be used to support different traffic streams with potentially different higher-layer protocols and with different QoS requirements. Two basic GFP frame formats are defined: GFP client frames and GFP control frames, as illustrated in Figure 5-4. GFP also supports a flexible (payload) header extension mechanism to facilitate the adaptation of diverse data clients. The GFP client and control frame formats are shown in Figure 5-5.
GFP Frames
Client Frames
Client Data Frames
Client Payload Transfer
Con irai Frames
Client Management Frames Client Resource Management
kJie
FnhiHh^i
Idle Time Fills
')A.iUyi F fatness
Unk OA&M
Figure 5-4. GFP frame types
5.3.1.1
GFP Client Data Frames
Client data frames provide the basic payload transport mechanism in GFP. As illustrated in Figure 5-5, client data frames are octet aligned and consist of a GFP Core Header and a GFP Payload Area.
160
Chapter 5
Client Data Frames 1
Core Header
// /
/
/
/
Payload Length LSB Core HEC MSB
/
Core HEC LSB
^''>^^ Payload Area
^' Order
^^''^
Payload Type LSB Type HEC MSB Type HEC LSB
CAI
^^^^'^ ^^—•^"'
CID
0-60 Bytes of
Spare
Extension Headers (Optional)
Extension HEC MSB
\\
Vari«ibl« UrHptN Packets \
PFI UP!
Payload Header
\
3\\ Transmission Byte
1
f
/ /
^^^^^
PTI
Payload Type MSB
t
Payload Inforitiation FfjHMlUfigth
^ ^\
f
1
// // / // // /
Payfoad Length MSB
Extension HEC LSB
^^---^'^
Header shown (others may apply)
Payload FCS MSB
Payload PCS
Payload FCS
\ Payload FCS
\\
\
\
Payload FCS LSB
0x00
(0xB6)
0x00
(OxAB)
0x00
(0x31)
Figure 5-5, GFP frame formats
5.3.1,1.1 GFP Core Header The Core Header supports the datalink management procedures in GFP. The Core Header length is fixed at four octets and consists of a PDU Length Indicator field and a Core Header Error Check field. The Core Header is always scrambled upon transmission (via an exclusive OR operation) with a well-known Barker-like pattern BAB31B0. PDU Length Indicator (PLI) Field: a two-octet field indicating the number of octets in the GFP Payload Area. It is used to extract the encapsulated PDU and to look for the next GFP frame boundary. Core HEC (cHEC) Field: a two-octet field containing an ISO CRC-16 to protect the integrity of the Core Header via single-bit error correction and multibit error detection. The cHEC sequence is calculated over the remaining octets of the Core Header. 5.3.1.1.2 GFP Payload Area The GFP Payload Area consists of all octets in the GFP frame after the GFP Core Header. This variable length area may include from 4 to 65,535 octets. It is intended to convey client layer specific protocol information. The GFP Payload Area consists of two common components: a Payload Header and a Payload Information field. A third optional component, the Payload FCS field, is also provided to protect the contents of the Payload Information field (Payload Headers are protected separately). The Payload Area is always scrambled upon transmission and descrambled upon reception via an ATM-like self-synchronous scrambler.
Generic Framing Procedure (GFP)
161
5.3.1.1.2.1 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 higherlayer client signal. The Payload Header contains two mandatory fields, namely, the Type field and the accompanying Type HEC (tHEC) field. The tHEC protects the integrity of the Type field. Optionally, the Payload Header may include an additional variable number of subfields, referred to as a group as the Extension Header. The Type field specifies the presence and format of the Extension Header. GFP Type Field: a mandatory two-octet field of the Payload Header that indicates the content and format of the GFP Payload Information. The Type field distinguishes between services in a multiservice environment. The Type field consists of a Payload Type Identifier (PTI), a Payload PCS Indicator (PFI), an Extension Header Identifier (EXI), and a User Payload Identifier (UPI), as shown in the top right corner of Figure 5-5. For Ethernet transport, for instance, PTI=0 (User Data), no Payload FCS (PFI=0), and the default Null Extension Header (EXI=0) are used. Type HEC (tHEC) Field: a two-octet field that contains an ISO CRC-16 sequence to protect the integrity of the Type field via single-bit error correction and multibit error detection. The Payload Header in GFP allows the support of multiple transport modes that may coexist within the same transport channel. Three adaptation modes are currently defined. The first mode, referred to as Frame-Mapped GFP (GFP-F), is optimized for packet switching environments where resource management functions are delegated to the native data clients. The Client-specific adaptation sublayer is fairly thin, supporting basic Layer 2 PDU encapsulation functions. This is the transport mode used for native IP, PPP, and Ethernet traffic. The second mode, referred to as Transparent GFP (GFP-T), is intended for delay-sensitive 8B/10B coded applications, where the goal is transport efficiency and transparency of the logical line code data. The Client-specific adaptation sublayer performs 8B/10B codeword recoding for data compression. This is the transport mode used for Fibre Channel, ESCON, and FICON traffic. The transport mode is indicated in the UPI field. The third adaptation mode. Asynchronous Transparent mapping, is a variation of GFP-T that supports selective client character removal to facilitate rate adaptation into a lower rate (compared with the native) transport channel. 5.3.1.1.2.2 GFP Extension Header The GFP Extension Header is a O-to-60-octet set of fields intended to support technology-specific data link information such as virtual link identifiers, source/destination addresses, port numbers. Class of Service, or
162
Chapter 5
extended header error control information. The type of Extension Header is indicated by the content of the EXI bits in the Type field. Three Extension Header Types are currently defined: Null Extension Header: the default extension header when the entire GPP payload is dedicated to a single service (as indicated by the UPI field). Linear Extension Header: a two-octet extension header that supports sharing of the GFP payload across multiple clients in a point-to-point configuration. Ring Extension Header: an 18-octet extension header (currently under study) that supports sharing of the GFP payload across multiple clients in a ring configuration. Extension HEC (eHEC) Field: a mandatory two-octet field that contains an ISO CRC-16 check sequence to protect the integrity of the contents of the Extension Header via single-bit error correction (optional) and multibit error detection. 5.3.1.1.2.3 Payload Information The Payload Information field contains the framed PDU. This variablelength field may include from 0 to 65,535 - X octets, where X is the size of the Payload Header. It may include an optional Payload PCS field. The client user/control PDU is always transferred into the GFP Payload Information field as an octet-aligned packet stream. The payload may be a single layer-2 MAC frame, via the frame-mapped GFP adaptation mode, or multiple layer-1 line codes, via the transparent-mapped GFP adaptation mode. 5.3.1.1.2.4 Payload Frame Check Sequence (FCS) The Payload Frame Check Sequence (FCS) is an optional, four-octet long, frame check sequence. It contains an HDLC-like CRC-32 check sequence that protects the contents of the GFP Payload Information field. A value of 1 in the PFI bit within the Type field indicates the presence of the Payload FCS field. Unless otherwise stated, corrupted GFP frames are passed to a client adaptation process for local handling according to clientspecific rules. 5.3.1.2
Client Management Frames
GFP provides a generic mechanism to propagate client-specific source adaptation information, such as performance monitoring and OA&M information, to end-systems. Currently, the only client-specific facility defined is a Client Signal Fail (CSF).
Generic Framing Procedure (GFP)
163
5.3.1.2.1 Client Signal Fail (CSF) CSF is a message that may be sent from the GFP source-adaptation process to the far-end GFP sink-adaptation process upon failure detection in the ingress client signal. Detection rules for client signal failure events are by definition client-specific. Figure 5-6 illustrates the use of CSF messages.
GFP Link
nana ^ ^ ^ --.^ I • Loss of Signal (LOS) ; f • Loss of Client Character Sync (LCS) S
Client Signal Fail: .LOS . LCS
- Loss of clock/frame - Running disparity violations
Figure 5-6. Example of Client Signal Fail usage in GFP
The CSF indication is a special type of GFP Client Frame consisting only of a Payload Header and no Payload Information field. The Payload Header consists of a Type field with its accompanying tHEC, and an Extension Header, if applicable to the encapsulated client signal. In the Type field, the PTI subfield is coded as Client Management, the PFI subfield is set to 0 (no Payload FCS), and the EXI subfield is set to the applicable Extension Header type. The UPI subfield is used to indicate the type of client signal failure. Two generic types of failure defects can be reported: • Loss of client signal (UPI=0) • Loss of client character synchronization (UPI=1) Upon failure detection, the GFP client-specific source adaptation process may send periodic far-end CSF indications. The GFP client-specific sink adaptation process should clear the defect condition either 1. after failing to receive a number of consecutive CSF indications (value of 3 is suggested), or 2. after receiving a valid GFP User Frame. The handling of incomplete GFP frames at the onset of a CSF event should be consistent with the GFP error-handling procedures.
164
5.3.2
Chapter 5
GFP Control Frames
GFP Control frames provide in-line link control mechanisms for GFP. This information is indicated via the lower values of the PLI field (0-3). Currently, only the GFP Idle Frame function is specified. The remaining PLI values are under consideration for dark fiber extensions. It is expected that such an in-band channel would use very small payload areas to minimize interactions with life FP Data frames. Note that it is not expected that such GFC control will have the same format as the GFP user frames, but at the very least they should incorporate a CRC-16 for the control message payload using the same generation procedure as for the cHEC computation. 5.3.2.1
GFP Idle Frame
The GFP Idle frame is a special four-octet GFP Control frame. It consists of only a GFP Core Header with the PLI and cHEC fields set to 0. The GFP Idle frame does not contain a Payload Area. It is intended as a filler frame for the GFP transmitter to facilitate the adaptation of the GFP octet stream to any given transport medium. The GFP Idle frame format is shown in the bottom right corner of Figure 5-5.
5.3.3
Client-Independent Procedures
5.3.3.1
GFP Frame Delineation
One important function in GFP is to identify the PDU boundary at the time of link initialization and also after packet delineation loss. The GFP receiver state machine is shown in Figure 5-7. Under normal conditions, the GFP receiver would be operating in the Sync state. The receiver examines the PLI field, validates the incoming HEC field, extracts the framed higher-layer PDU, and then rolls over to the next GFP Header. As soon as an uncorrectable error occurs in the GFP Header (that is, the HEC fails and more than a single bit error is detected), the receiver enters a Hunt state. It starts looking for the boundary to the next GFP PDU by moving one bit/byte at a time. Assuming that this bit/byte starts a new frame, the receiver checks the first four octets to see if they form a valid GFP Header (that is, a GFP Header where the HEC field checks out against the content of the PLI field). If the check succeeds, the receiver tentatively assumes that it has identified the frame boundary; otherwise, it shifts forward by one bit/byte and checks again. Boundary acquisition, and hence link resynchronization, is declared after the GFP receiver detects N consecutively correct GFP Headers. The GFP receiver can then return back
Generic Framing Procedure (GFP)
165
to the Sync state. The GFP frame delineation procedures are based on selfdelineation/self-synchronization principles illustrated in Figure 5-8.
Frame-by-Frame Core Header Correction Disabled
Frame-by-Frame Core Header Correction Enabled
2ndcHEC match
O
Pre-Sync State
Sync I State c:^
Noncorrectable Core Header Error
Correctable Core Header Error
NocHEC match
Figure 5-7. GFP state machine
rr Hun! Stale
Octet or Bit synchronous stream
CL
X
[_
Q-
O LU X o
o j
LU X o
Payload Area
•••
cHFrPnilJ '^' l'**'^ cHEC Fail I '^' '"*•='
i
PLI [c*CC
cn c
Valid
PLI Bytes
P U Bytes c i E C Matc^
1 t^
Paytoad Area
1
fcHECFaii' ""^ i****^!
J
Payfoad Area
3
Pre-Sync State
PLI Byies c HEC Mote b
Sync state
1•
Figure 5-8. Link synchronization and frame acquisition
The HEC-based frame delineation procedure permits sophisticated traffic engineering, flexible QoS aware routing, better partitioning of SONET/SDH bandwidth, and multiservice integration, either at the GFP layer (via Header Extension options with the GFP Payload Header) or via native Layer 2 (e.g., Ethernet) or Layer 3 (e.g., IP) mechanisms. Commercial component interconnect interfaces such as MII/GMII (IEEE 802.3) for the Ethernetrelated layers and SPI-3/SPI-4 (OIF) for the optical layer are readily available to facilitate the integration of system components, promote feature interoperability and decrease system development costs.
166 5.3.3.2
Chapter 5 Frame multiplexing
GFP Client and Control frames from multiple ports and multiple client types are multiplexed on a frame-by-frame basis. GFP does not impose any constraints on the choice of scheduling algorithms, since traffic-handling aspects tend to be client specific. In general, when there are no other GFP frames available for transmission, GFP Idle frames shall be inserted, thus providing a continuous stream of frames for mapping into an octet aligned physical layer. CMF, other than CSF, are to be sent opportunistically to minimize contention with client data frames. 5.3.3.3
Link Scrambler
Link-level scrambling is required to achieve adequate link transparency and bit density when data is mapped directly over the SONET-SPE or SDHAUG. Equivalent requirements are also anticipated for WDM-based solutions. A self-synchronous scrambler with generating polynomial 1 -I- x"^^ is specified. This scrambler is applied only to the GFP Payload Area in a manner similar to the link scrambler application for ATM over SONET/SDH.
5*3.4
Client-Dependent Procedures
The first step for a transport integration mechanism is a common signal convergence mechanism to map any native bit-stream into the transport channel and provide for signal rate adaptation and minimal OAM&P functions. The native adaptation mechanism provided by GFP is frame based and allows the segmentation of the physical channel into fixed- or variablesize containers or GFP frames. Three modes of client signal adaptation are provided with GFP: Frame Mapped, (Synchronous) Transparent Mapped, and Asynchronous Transparent Mapped modes. Table 5-1 summarizes the major client signals supported by each mode. Table 5-1. Summary of client signals supported by GFP Transparent Mapped Frame Mapped Ethernet MAC Gb Ethernet Fibre Channel HDLC-like/PPP FICON MAPOS ESCON RPR MAC FC-BBW2 AVB DSI MPLS
Async Transparent Mapped FC-BBW3
Generic Framing Procedure (GFP) 5.3.4.1
167
Frame-Mapped Mode (GFP-F)
The Frame-Mapped adaptation mode is a more flexible adaptation mode that is suitable for either full/subrate point-to-point or multipoint packetbased applications. Adaptation is accomplished by mapping upper-level PDUs (such as HDLC-like/PPP frames, IP/MPLS packets, or IEEE 802.3 MAC frames) into the variable-size GFP frames. The frame structure for mapping an Ethernet/IEEE 802.3 frame onto a GFP frame (assuming a Null Extension Header) is illustrated in Figure 5-9. Linear and Ring extension headers that support client-multiplexing functions in point-to-point or ring topologies are also defined. 1^
^1
ijihK-h i-rame
L r
Core ^ ^ Header ^ ^
Pavload Area
m
PCS
i|:|i:||iE||||
1
/Optional
|jj|:;|2i||t|||:|:; ||j|;i|i|i|||y;|i
4B\/tes
jl
Figure 5-9, Frame-Mapped adaptation mode
For applications where both the transport and bridging capabilities of Ethernet are integrated into the transport NEs, the Frame-Mapped mode is the preferred mode of adaptation, since the physical-layer aspects of both the SONET/SDH and Ethernet interfaces (layer 1) are segregated from the media access control (layer 2) aspects. Since the same mode of adaptation is applied to either point-to-point or multipoint configurations, service providers can deal with these two styles of application with the same provisioning and management procedures. Thus, for instance, if a customer wishes to migrate from a point-to-point transport service to a multipoint transport service, both these services can be delivered from the same service interface without further reconfiguration of the preexisting end-points. 5.3.4.2
Transparent-Mapped Mode (GFF-T)
The Transparent-Mapped adaptation mode (currently defined for 8B/10B encoded signals only) is particularly suitable for full-rate point-to-point applications requiring very low delay and delay jitter. Full-rate means that the entire capacity of the local physical interface is supported across the end-
Chapter 5
168
to-end path. Client adaptation is accomplished by preprocessing the incoming signal to remove the native link-layer codewords, postprocessing this raw data to the characteristics of the new transport media, and mapping the postprocessed data into fixed-size GFP frames, as illustrated in Figure 510. The detailed processing steps for 8B/10B encoded signals are discussed in Section 5.3.4.4. This mode is intended for applications that seek to emulate a native physical interface with very strict packet delay, loss, and throughput requirements (e.g.. Fibre Channel, FICON, and ESCON).
GFP-T Frame Payload Area
Core Header " ^ PU 2 Bytes
cHEC 2 Bytes
Payload Header
PCS
8X64B/65B + 16 Superblocks
4 Bytes
(Optional 4 Bytes
64B/65B # 1 1 64B/65B # 2 |
64B/65B Superblock (Flag bits carried in last octet of the super-block)
^ w
64B/65B # N - l [ 64B/65B # M | r l 1 72 ...| F8 1
^\.^^^ ^\.^
CRC-1$ MSB
1
CRC-16 I^B
1
1
CCL#1
1 CCI#1
1
N
CCL#n 1 CCI#n
1
DCI#1
1
64B/65B block (minus Flag bit)
DCI#8-a
Figure 5-10. Transparent-Mapped adaptation mode (GFP-T)
5.3.4.3
Asynchronous -Transparent Mapped Mode
The Asynchronous-Transparent adaptation mode (currently only defined for 8B/10B encoded signals) is a variant of GFP-T that is particularly suitable for full-rate point-to-point applications requiring a trade-off between low-to-medium delay and delay jitter versus bandwidth efficiency. As with GFP-T, signal adaptation is accomplished by mapping link-layer codewords into fixed-size GFP frames, as illustrated in Figure 5-7. But unlike GFP-T, this process requires that all signal components are adapted into a GFP frame. Thus, codewords associated with interframe fills may be removed, or entire codeword sequences related to link-control functions may be extracted, processed, and modified prior to their mapping to GFP. As such, GFP-A requires a certain level of client signal awareness but not complete processing of the native L2/L3 PDUs. This mode is intended for applications
Generic Framing Procedure (GFP)
169
that seek to emulate a native physical interface with packet delay, loss, and throughput requirements but that can take some level of delay, such as asynchronous Fibre Channel applications. 5.3,4.4
8B/10B Client Processing in GFP-T
GFP provides either full-rate or subrate adaptation for 8B/10B line coded signals, which is the prevalent line code in local area networks. These signals consist of a 10-bit character encoding either 8-bit data or control information. In GFP-T, an 8B/10B data codeword is decoded into its original 8-bit value, and an 8B/10B control codeword is decoded into special GFP-T control characters. The 8B/10B control codewords are mapped into one of the 16 possible 4-bit Control Code Indicators for the 8-bit control characters available in transparent GFP. r> Leadi Leading Bit 8 byte block 8 X 65B blocks = 520 bits
I I i I I
rr
O
Group 8 X 65B blocks
A
Rearrange Leading Bits at end of the block
^ ^ Generate & append CRG-16 ® check bits to form [536,520] superblock. ^ ^ n||| I 0 ™*-'/-^ Payload FCS (4 bytes) M-'
N X [536,520] Superblocks
Form GFP Payloads with N X [536,520] Superblocks. Append GFP Payload Header and (optional) pQg
0 Append Core Header and Scramble Payload Area with x43+i SSS (Core header not scrambled.)
Core Header (4 bytes)
Figure 5-11. GFP-T adaptation process
5.3.4.4.1 Generating GFP-T 64B/65B codes The decoded 8B/10B characters are mapped into a 64-bit/65-bit (64B/65B) block code. The components of the 64B/65B block code are illustrated in Figure 5-12. The leading bit of the 65-bit block, the Flag bit, indicates whether that block contains only 64B/65B 8-bit data characters or whether client control characters are also present in that block. (Flag bit = 0 indicates data octets only, and Flag bit = 1 indicates at least one control octet in the block). Client control characters, which are mapped into 8-bit
170
Chapter 5
64B/65B control characters, are located at the beginning of the 64-bit block payload if they are present in that block. The first bit of the 64B/65B control character contains a Last Control Character (LCC) flag bit, which indicates whether this control character is the last one in this block (LCC = 0) or whether there is another control character in the next octet (LCC = 1). The next three bits contain the Control Code Locator, which indicates the original location of the 8B/10B control code character within the sequence of the eight client characters contained in the block. The last four bits, the Control Code Indicator, give the four-bit representation of the 8B/10B control code character.
_D2_
_Da_
JM_
_Q5_
Dfi
n?
jQa_
_D4_
_D5_
JIL. _Qg_
_Da-.
-XLL n,hhh,C;
_Qi.
_D2_
J22_
JM-
Si5-
-DQ-
_Di-
_D2_
_Da_
_[M_
_D5_
Ql
_D2_
_Da_
_D±_
_Di_
_D2_
_xia_
O.fff.Ofi
_m_
_D2^
1 .hhh.C; n.nno.c:
1 hhh nd 1 nnn.C:^ n.ridd.Ci
1 hhh C. 1 -r.nr.,C?\ 1 dridc4 n.fififiCi
l.aaa.CI l.hhh.Ca
tcm.ca^ 1.rldd.C4l.RRR.Cf^
1,afiri,C1 Lhhh.O: i.GcaCa 1.rJf1fl,C4l.ftfiR.Cfl Lfff.Cfi n.fiflfl.C'
-D2-
_Di.
1,aaa,C1 l.hhh.ca 1 ,nnn,0/ 1,fif1ri,c4l,ftftR,0fl 1,fff,Cfi l.flfln.C -bit representation of the Ist control code's original position • bit representation of the 2nd control code's original position hhh s 3 CI s 4 Dl = 8
- bit representation of the 8th control code's original position 'bit representation of the Ah control code -bit representation of the /th data value In order of transmission
Figure 5-12. GFP-T 65B/64B code components
5.3.4.4,2 Adapting 64B/65B code blocks into GFP Superblocks To preserve the octet alignment of the GFP-T signal with the transport channel, the first step in the adaptation process is to group eight 64B/65B codes into a Superblock (Step 2 in Figure 5-11). The leading (Flag) bits of each of the eight 64B/65B codes are grouped together into a first trailing octet. The sixteen bits of the last two trailing octets are used for a CRC-16 error check over the bits of this Superblock (Step 3 in Figure 5-11). N 65B/64B codes (and associated CRC) are packed into a single GFP frame. Assuming no Payload FCS and a Null Extension header, the resulting GFP frame is [(A/^x ((65 x 8) + 16) + (8 x 8)] bits long, where N is the number of superblocks in the GFP frame. The value of A^ depends on the base rate of the client signal and on the transport channel capacity.
Generic Framing Procedure (GFP)
171
5.3.4.4.3 Error control with Transparent GFP The 16 error control bits in a Superblock contain a CRC-16 error check code over the 536 bits in that Superblock. If the GFP-T demapper detects an error, it should output either a lOB Error control character(s) or a 1 OB Unrecognized control character(s) in place of all the client characters contained in that Superblock. The generator polynomial for the CRC-16 is G(x) = x^^+ x^^ + x^^ + x^^ + x"^ + x^ + x^ + X + 1 with an initialization value of zero, where x^^ corresponds to the MSB and x^ to the LSB specially selected for this application.
5,4.
IMPLEMENTATION CONSIDERATIONS
All the procedures in the GFP state machine may be performed either on a bit-by-bit or byte-by-byte basis, making the equally suitable to bit and byte synchronous channels. If either 4-byte or 8-byte parallel processing is deemed necessary, then all the operations described here, including CRC computations, can be performed in parallel. The standard is open as to design choices for certain design parameters of the virtual framer and options for link scrambling.
5,4.1
Virtual Framer Management
The procedures described so far do not explicitly constrain the potential ways framers may be handled when returned to the Hunt state (after failing to produce A^-7 consecutive HEC matches), or when all the available framers are in use and a new potential GFP header is detected while in the Hunt state. There are a few implementation options available depending on the amount of link configuration information available to the receiver, the link synchronization performance objective, and the implementation complexity. Below we identify three simple implementation options that do not exploit the information conveyed in the assumed PLI fields. One design objective may be to maximize the chance to synchronize the link at the first available opportunity. The implementation (Option 1) could then allocate enough framers to guarantee, with a reasonably high probability, that one of the M framers will succeed in capturing the first incoming GFP frame boundary. For implementation simplicity, framers that fail to yield the proper GFP frame boundary would not be reused, and any further HEC field matches (beyond M) while in the Hunt state would be ignored. If all the framers fail to yield the proper GFP frame boundary in the first pass, then the resynchronization procedure must be restarted from scratch, A drawback in this approach is that the time to frame delineation
172
Chapters
could be large if the incoming GFP frame is missed, particularly in scenarios where the BER is high, since each of the failed framers may have been pointing up to 64 Kbytes into the incoming byte stream. When the receiver knows the Maximum Transmission Unit (MTU) for the link, the synchronization time can be further improved (valid PLI fields can only point up to MTU bytes into the incoming byte stream) at the expense of further implementation complexity. Reuse of failed framers can be exploited to further improve the link synchronization performance. Given the size of the HEC field and typical Internet traffic profiles, the chances of a large number of random HEC field matches in a PDU may be deemed rather unlikely. An alternative design philosophy (Option 2) may assume that a large number of active framers is indeed an indication that the GFP receiver is facing such an unlikely event. Thus, the receiver may just reset the ''oldest" of the framer when all available framers are in use and a new HEC field match is detected while the receiver is in the Hunt state. This approach has the advantage of decreasing the probability of "flushing" the GFP frame boundary with a hard reset of all framers. Alternatively, the framer with the farthest time to frame may also be a good candidate for reset. Yet this approach requires sorting according to the expected time to frame. We evaluate both approaches in Section 5.6.
5.4.2
Scrambler Options
The need for pay load scrambling was identified as an afterthought in the original POS specification. For expediency, the technical community selected an ATM-like self-synchronous scrambler with generating polynomial 1 + x'^^. Below are some considerations concerning the choice of a self-synchronous scrambler: The l+x"^^ scrambler is known to exhibit the poorest bit randomization property among all degree-43 polynomials [18]. The state self-synchronous scrambler is affected by the input data. It is relatively easy to generate input packets that yield a periodic bit pattern (with a period of 43 bits) on the link, even after applying the SONET/SDH scrambler. Although today's PDUs often contain as many as 1536 bytes, they can be as large as 64 Kbytes. The periodicity increases the probability of low bit transition density to 10% to 20% instead of the desired 50%. While the situation is not as serious as the one without the additional scrambler (where a zero transition density can be created relatively easily, as shown in Table 5-2), some transmission equipment may be sensitive to even this low transition density. The self-synchronous nature of the scrambler multiplies errors. In particular, the receiver perceives every bit error on the link as two bit errors (separated by 43 bits). Similar multiplication of errors occurs when there are
Generic Framing Procedure (GFP)
173
two or more errors on the link. Error multiplication interferes with the error correction in the header as well as in the payload. In some environments, the link payload may require a much more powerful FEC that would be required in the absence of error multiplication in order to achieve a given level of burst error protection. Error multiplication also affects the error detection capability of the PCS. In particular, the CRC-16 polynomial is inadequate in the presence of error multiplication, even with the maximum PDU size of 1536 bytes. Table 5-2. Probability distribution of bit transition density
TRANSITION DENSITY 0/43 2/43 4/43 6/43 8/43 8/43
EVENT PROBABILITY 2.0x10" 2.0x10'° 2.8 X 10"^ 1.0 xlO"^ 4.0x10"^ 4.3x10"'*
AVERAGE TIME PER EVENT AT 0C-12C 322 Years 177 Days 20 Hours 33 Minutes 1.2 Minutes 4.8 Seconds
Thus, one is driven to consider an alternative scrambler for GFP. Below we discuss a new independent set-reset scrambler, its operation, and the method for synchronizing the descrambler with the scrambler. All bits in every GFP PDU following the GFP header are scrambled using an independent scrambler with polynomial 1 + x + x^'' + x^^ + x'^^ The transmit scrambler and receive descrambler can be implemented using shift registers with 48 stages that are set to all-ones when the link is initialized. Each is refilled with all-one bits if the value in the shift register ever becomes all zeros. This scrambler, shown in Figure 5-13, is not reset at the beginning of each frame, as is the SONET/SDH x^+x^-i-1 scrambler, nor is it modified by the transmitted data, as is the ATM self-synchronous scrambler. Instead, the two ends are kept in synchronization using special GFP messages.
^
1 1
o
M
k=M
ViX-q)'-'-'
(5.4)
V ^ y
The computation of the frame unavailability probability so far ignores the impact of the links' BER. With the header CRC operating only in detection mode while in the Hunt state, the next GFP PDU boundary will also be missed whenever the next GFP header is in error. Assuming independent random bit errors, then PFU(BER) = P,,, + P{FUA){\ - P,,,)
(5.5)
where P^er is the uncorrected header error probability, P/^^^ =l-(l- p)^ , and P(FUA) is given by Eq. (5.3) in the case of Option 1, or Eq. (5.4) in the case of Option 2.
178
Chapter 5
Figure 5-14 and Figure 5-15 show P(FUA) as a function of the GFP PDU size and the number of framers over octet- and bit-synchronous channels, respectively. In these figures, Ml refers to P(FUA2) under Option 1, while M2 refers to Option 2. As expected. Option 2 gives slightly higher values for P(FUA), particularly for larger PDU sizes. P(FUA) values for bitsynchronous links are necessarily higher, as a larger number of events must be examined in between consecutive GFP PDUs.
64
128
256 384
512 1024 2048 3072 4096 8192 16384 32768 65535
GFP PDU (octet)
Figure 5-14. Probability of next frame unavailability as a function of the GFP PDU size and number of framers (octet-synchronous channel)
?5 1-E-04
128
256 384 512 1024 2048 3072 4096 8192 16384 32768 65535 GFP PDU size (octets)
Figure 5-15. Probability of next frame unavailability as a function of the GFP PDU size and number of framers (bit-synchronous channel)
Generic Framing Procedure (GFP) 5.5,4
179
Frame Acquisition Delay
For any given receiver implementation, the frame acquisition delay is a function of the packet size, the link BER, the number of framers, and the required number of consecutive HEC field matches. The most relevant measure of this impairment is the mean time to frame (MTTF), that is, the average time it takes to regain synchronization when a certain number, M, of framers is used in the Pre-Sync state. When M false matches create M checkers, the link resynchronization process is reinitiated. The process will start again after losing at least one GFP PDU for link-synchronization purposes. It is also possible that the true GFP frame boundary will be missed because of an error in the header. A checker with a true frame boundary may also revert to the Hunt state when an error occurs in one of the subsequent N-1 GFP headers. Therefore, the MTTF is a function of the probabilities calculated above and the BER. Assuming that the boundary search is initiated at a random point in the current GFP PDU, there are three main components to the boundary acquisition delay: 1. The time (tj) spent examining the subsequent bytes/bits after the initial HEC field failure, from the beginning of the current GFP payload to all but one byte/bit of the next candidate frame header. This event is a uniformly distributed event over the length of the GFP PDU. 2. The time (^2) spent examining the last complete GFP PDU prior to declaring link (re)-synchronization. This event is uniformly distributed over the length of the GFP PDU. 3. The time (tjhf) spent chasing after the false HEC field matches and restarting the link resynchronization process. This is essentially a geometrically distributed event with rate PFU2. Thus, for our receiver implementations, the MTTF can be expressed as MTTF={E{t,hE{t2)il-Pfui)+flE{t,hn4 = E{t^) + kh) + PpfAtfhM-Pfu2) For either Option 1 or 2, either E(t])=E(l)/2 or E(t])=E(l) depending on whether it relates to an initial synchronization or a resynchronization event, while E(t2)=E(l). E(tjhf) is just the mean value of the (uniformly) randomly matched PLI field, or E(tjhf)=L/2, where L is the largest possible GFP PDU. Figure 5-16 and Figure 5-17 show the MTTF as a function of the GFP PDU size and the number of framers over octet= and bit-synchronous channels, respectively. Option 2 yields lower MTTF values for GFP PDU
180
Chapter 5
sizes up to 4K octets as compared with Option 1, which reflects the impact of the missed frame acquisition opportunities once the framer state machine becomes unavailable. For larger GFP PDU sizes, the lower PFU values from Option 1 exhibit better MTTF performance.
•
2.00
I
t
•
Z) Q
1.75
1.50
t
T
f
64
128
256
1 I 7 384 512
T f T
1024 2048 3072 4096 8192 16384 32768 65535
GFP PDU size (octets)
Figure 5-16. MTTF as a function of the GFP PDU size and number of framers (octetsynchronous link)
2.00
3 Q Q_
1.75
1.50 384
512 1024 2048
3072 4096 8192 16384 32768 63536
GFP PDU size (octets)
Figure 5-17. MTTF as a function of the GFP PDU size and number of framers (bitsynchronous Hnk)
Generic Framing Procedure (GFP)
^^ s^ ^^ ^^^ ^O ^"^ /
181
Z' /
^v^\.^^'/
/
GFP PDU Size (Octets) Figure 5-18. MTTF as a function of the GFP PDU size and BER for M=2 (octet-synchronous links)
Figure 5-18 shows the impact of the links' BER on the MTTF for an octet-synchronous link. Our calculation shows that for Option 2 the MTTF is sensitive to the BER above 10""^ and becomes virtually insensitive to the BER below that range. For core networks, the expected BER is much below this threshold. For this scenario, one can assume insensitivity to the BER and use the resulting MTTF in an initial determination of good values for M and A^ >2. Option 1 again shows the impact of the lost frame acquisition opportunities when the working frame sizes are relatively small compared with the maximum GFP PDU size. Although not shown, the MTTF is still an increasing function of the GFP PDU size in octets. Similar observations apply to bit-synchronous links. For common packet sizes in today's Internet, two parallel framers, using links with a BER of 10"^ or better, provide an MTTF of about 1.5 GFP PDUs. Each framer (checker) needs to check at least two consecutive HEC field matches before declaring proper GFP PDU delineation. This is also the optimal time, since initial synchronization is typically initiated halfway into one GFP PDU, and the subsequent GFP PDU must also be checked and judged correctly framed. The MTTF analysis suggests that even for very large packets (64 Kbytes), M=2 or M=3 seems adequate. Since such large packets are not common in current data networks and since the introduction of real-time services in the IP networks make it more unlikely that such large packets will become more prevalent in future IP networks, M=2 should suffice for most practical scenarios. Note also that, although not shown, the synchronization performance can be further improved both by taking into account the actual contents of the
182
Chapter 5
assumed PLI fields, particularly when the working MTU is less than the maximum possible GFP PDU, and by reusing previously released framers shown to have pointed to a false GFP PDU.
5.5.5
Scrambler Resynchronization Delay
For the independent scrambler, both the transmitter scrambler and the receiver descrambler need to be synchronized for the receiver to be able to send valid PDUs to higher layers. If the scrambler state is transmitted every k GFP PDUs, then it will take an additional k/2 frames for the scrambler states to be synchronized. Of course, if the loss of synchronization is communicated to the transmitter, then the transmitter can suspend the transmission of all user traffic and continuously send only the scrambler state messages. These messages are short (12 bytes long). In this case, the resynchronization will be achieved within the transmission time of 1.5 (short) frames after the transmitter is informed of the loss of synchronization. When random errors occur, the header CRC corrects single bit errors in the GFP header. If the header CRC detects errors in the GFP Header that cannot be corrected, it will send the receiver to the Hunt state. Burst errors will almost always cause the GFP receiver to enter the Hunt state. Generally, burst errors in fiber systems appear to last between 20 and 40 ms. Once the error burst is over, an additional time interval of either 2 frames (for selfsynchronous scramblers) or 2 + k/2 frames (for the independent scrambler) will elapse before link resynchronization is achieved. This interval is insignificant at OC-3c transmission speeds and above.
5.5.6
Link Efficiency
Figure 5-19 compares the datalink transport efficiency between GFP and PPP over HDLC-like framing as defined in RFC-1662 [10]. From the viewpoint of the data link layer, one can readily identify two sources of transmission inefficiencies: framing overhead and payload encoding overhead. Framing overhead is typically associated with protocol control information. Payload encoding deals with transparency issues encountered during data transport, such as avoiding the receiver misinterpreting user data as control information, guarding against malicious attacks, or maintaining bit transparency. GFP introduces a fixed amount of framing overhead — either 8 bytes without an FCS field or 12 bytes with an FCS field. In comparison, PPP in HDLC-like framing requires a minimum of 79 bytes of framing overhead, depending on the size of the FCS field. The HDLC encoding overhead is
183
Generic Framing Procedure (GFP)
variable and loosely bounded. In the best-case scenario, there are no occurrences of the Flag and Escape Control bytes in the data packet and, no encoding overhead is added at all. In the worst case, the packet consists exclusively of Flag and Control Escape bytes, and the encoding overhead is 100%. For purely random data, it is easy to show that the average encoding overhead is about 0.78%. Yet it is not uncommon to find video and compressed voice data traces in which the flag or escape patterns account for 30% to 40% of the bytes. Such large payload size variations can strongly interfere with most QoS management mechanisms, demand looser engineering rules, and hence, decrease overall link efficiency for HDLCencapsulated PDUs.
100
90
^
80
1^ W
70
-•-GFP HP PPP Best -^K- PPP Random "»- PPP Worst
60
50
40
1
40
1
64
1
128
1
256
1
512
1
1024
1
4048
1
8096
16192
GFPPDUSize (Octets)
Figure 5-19, GFP and PPP/HDLC bandwidth efficiency as a function of the PDU size
184
Chapter 5
Other encoding algorithm may be used in place of HDLC byte stuffing. For instance, the Consistent Overhead Byte Stuffing (COBS) algorithm [19] encodes input data into variable-length code blocks by eliminating a target byte from the data stream. Each code block begins with a code byte indicating the length of the code block followed by up to 254 bytes of data. For purely random data, COBS efficiency is about 0.23%. Yet, COBS overhead is also variable, with a best-case overhead of 1 byte for packets without the Flag byte and a worst-case overhead of 1 additional byte for each 254 data bytes.
5.6,
APPLICATIONS
Most of this traffic originates in corporate LANs, which are today over 90% based on Ethernet technology. This situation makes a compelling case for Ethernet as the service interface towards the end users. Public networks, however, are larger SONET/SDH based. This situation makes a compelling case for SONET/SDH as the interface to the public transport network. Below we describe common GFP applications for Ethernet-oriented services. Further applications can also be found elsewhere [20, 21].
5.6.1
Ethernet Private Lines
The simplest GFP application is as a flow mapper/demapper into a TDM channel, such as a SONET/SDH path or an Ethernet segment, for an Ethernet Private Line (EPL) service. Service interfaces to the end-users are standard Ethernet PHYs, while the transport over the TDM network is GFP based. There, GFP provides a mechanism to extend the native datalink protocol (such as PPP or the IEEE 802.3 MAC [22]) over an existing transport infrastructure. This scenario is depicted in Figure 5-20. Note that this approach only requires enhancements to the edge of the transport network as opposed to a brand new data transport infrastructure.
Generic Framing Procedure (GFP) Hybrid Network Element KVlOOMbps 1 GbE
185 Dedicated VCG Per Client
Client A Client BClient C Ethernet MAC Frames
Figure 5-20. TDM-based Private Line Services via GFP & Virtual Concatenation
GFP in combination with SONET/SDH Virtual Concatenation and the Link Capacity Adjustment Scheme (LCAS) [23] provides a simple mechanism not only to adapt the user traffic very tightly to the actual bandwidth demand (e.g., a 1 Gig Ethernet client can be mapped into 21 STSIs or 7 STS-3cs as part of a virtual concatenation group -[VCG], as opposed to burning a single OC-48c -48 STS-ls- lines). VCGs provide a simple mechanism for service providers to offer subrate Ethernet transport services in increments of STS-ls. LCAS provides a flexible mechanism for service bandwidth modifications and failure management in a hitless manner. Note that the same traffic adaptation model can be used to create a wide variety of similar private line services for SANs and broadcast video applications.
5,6,2
Virtual Leased Lines
An application for the GFP Linear Extension Header format allows even finer granular subrate transport services, as illustrated in Figure 5-21. In that scenario, GFP itself is used to create multiple subchannels within the GFP payload rather than relying on the SONET/SDH layer. Each GFP channel can be allocated an arbitrary fraction of the transport bandwidth. Each channel behaves as a Virtual Ethernet Private Line. This approach is particularly attractive for newer multichannel component interconnect interfaces such as SPI-4/SP5. It does require a packet-level scheduler at the GFP layer.
186
Chapter 5 Hybrid Network Element lQ/100Mbps 1GbE
^0 P orts
Client A -I
^
VCG ABC VC-n-xv
Client B — f Client
C^ Ethernet MAC Frames
Packet Fabric
GFP-F Mapper
^
Shared VCG among Clients
TDM Fabric
Figure 5-21. Packet-based Virtual Private Line Services via GFP Linear Headers or VLAN tags
5.6,3
Packet Rings
A third application uses the GFP Linear Extension Header in conjunction with Ethernet Bridging functions to create a packet-based logical ring over a TDM infrastructure, as illustrated in Figure 5-22. In this scenario, there is a point-to-point path between the neighboring network elements. On each link, the entire SONET/SDH link is dedicated to the packet ring. The GFP payload can be shared in any arbitrary fashion among the clients using the ring transport services of GFP. A similar capability could be constructed via the proposed Ring Extension Header. Although the ring procedures are currently under study, it is also possible to reuse alternative ring procedures such as the one currently being developed under the IEEE 802.17 [24] working group.
10/100 Mbps lGt)E
I/O Perls Ethernet MAC Frames
W\
^k-k JU t l A ^ =1^9
\>acket
Fabric_
13
GFP-F f Mapper
Hybrid TDM/Ethernet Network Element
TLS: 1-to-l mapping of access ports to VLANs
10/100
i
IEEE 802. ID/W
I
or IEEE 802.17 Over ~ SONET/SDH Path Patti
\
IP/MPLS to VLAN mapping
VCGs/a/ed
^"^^''e'
/
S---H"--'ir m
;°£g^
rZ
III
Edge Router/:
• • •
ServirP?; .qwit(
Figure 5-22. Packet-based Ring Services via GFP Linear Headers or VLAN tags
Generic Framing Procedure (GFP)
5.7,
187
FUTURE DIRECTIONS
Most of the work on developing GFP so far has been focused on defining client-specific adaptation procedures for a variety of constant bit-rate (Layer 1) or packet-oriented (Layer 2+) client signals. In this regard, it is expected that the direct mappings for other client signals will be enhanced to include the most commonly used Layer 2+ protocols, including IPv4/IPv6, MPLS, and the OSI protocols, among others. Work is also under way to complete the work on a subrate mode for Fibre Channel signals. There has also been much discussion about the need for a new native packet transport mode specially optimized for SONET/SDH and OTN transport networks and the potential use of GFP for this purpose. GFP already provides the means to propagate label-switching information for statistical multiplexing of any number of client signal (via the Extension Headers) as well as the means to support separate in-band or out-of-band management and control channels for client- and server-layer resource management via the GFP Type field. These tools afford the means of defining a lightweight packet transport protocol as an alternative to more established approaches such as ATM or MPLS.
5.8. [1] [2] [3] [4]
[5]
[5] [6] [7] [8]
REFERENCES ITU-T Recommendation G.7041/Y.1303, The Generic Framing Procedure (GFP), 2003. American National Standard for Telecommunications, Synchronous Optical Network (SONET) PayloadMappings, ANSI Tl. 105.02, 2002. ITU-T Recommendation 1.432, B-ISDN UserNetwork Interface — Physical Layer Specification, 1993. ISO/EIC 3309:1991(E), Information Technology — Telecommunications and information exchange between systems — High-level Data Link Control (HDLC) Procedures — Frame Structure, 4th Edition. International Organization for Standardization., 1991. ISO/EIC 4435:1991(E), Information Technology — Telecommunications and Information Exchange Between Systems — High-level Data Link Control (HDLC) Procedures — Elements of Procedures, 4^^ Edition. International Organization for Standardization, 1991. American National Standard For Telecommunications, Synchronous Optical Network (SONET): Physical Interfaces Specifications, ANSI Tl. 105.06, 2000. ITU-T Recommendation G.707, Network Node Interface for the Synchronous Digital Hierarchy (SDH), 1996. ITU-T Recommendation G.709, Interfaces for the Optical Transport Network (OTN), 2001. J. Carlson, P. Langner, J. Manchester, and E. Hernandez-Valencia, "The Simple Data Link (SDL) Protocol," RFC 2823, May 2000.
188 [9]
[10] [11] [12] [13] [15]
[16]
[17] [18]
[19] [20] [21] [22]
[23] [24]
Chapters American National Standard For Telecommunications, Integrated Services Digital Network — Core Aspects of Frame Protocol for Use with Frame Relay Bearer Service, ANSI Tl.618-1991, June 1991. W. Simpson (Ed.), PPP in HDLC-like Framing, RFC 1662, July 1994. A. Malis and W. Simpson, PPP over SONET/SDH, RFC 2615, June 1999. ITU-T Recommendation X.85, IP over SDH using LAPS, 20Q\. ITU-T Recommendation X.86, Ethernet over LAPS, 200\, J. Baldwin, B. Bharucha, B Doshi, S. Dravida, and S. Nanda, "AAL2 — A new ATM adaptation layer for small packet encapsulation and multiplexing," Bell Labs Technical Journal, AprilJune 1997. B. Doshi, S. Dravida, P. Magill, C. Siller, and K. Sriram, "A broadband multiple access protocol for STM, ATM, and variable length data services on hybrid fiber-coax networks," Bell Labs Technical JourndX, JulySeptember 1996. D. Fiorini, M. Chiani, V. Tralli, and C. Salati. "Can we trust in HDLC?" ACM Computer Communication Review, pp. 61-80. 1994. I.Fair, V. Bhagava and Q. Wang, "On the power spectral density of self-synchronous scrambled sequences," IEEE Transactions on Information Theory, Vol. 44, No. 4, pp. 16871692, July 1998. S. Cheshire and M. Baker, "Consistent overhead byte stuffing," Proceedings of SIGCOM'97, September 1997. E. Hernandez-Valencia, "Hybrid Transport Solutions for TDM/DATA Networking Services," IEEE Comm, Magazine, Vol. 40, No. 5, pp. 104112, May 2002. M. Scholten, Z. Zhu, and E. Hernandez-Valencia, "Data Transport Applications Using GFP," IEEE Comm. Magazine, Vol. 40, No. 5, pp. 96103. May 2002. IEEE 802. ID, (ISO/IEC 15802-3:1998), IEEE Standard for Information TechnologyTelecommunications and Information Exchange Between Systems—IEEE Standard for Local and Metropolitan Area Networks—Common Specifications—Media Access Control (MAC) Bridges, 2002 Edition. ITU-T Recommendation G.7042/Y.1304, The Link Capacity Adjustment Scheme (LCAS ),200\. IEEE P802.17, Resilient Packet Rings (RPR), Draft version 2.2, April 2003.
Chapter 6 SYNCHRONIZATION OF OPTICAL NETWORKS An overview of network-level synchronization ^Geoffrey M. Garner, ** Gert H. Manhoudt "^Consultant, ** AimSys BV
6.1.
THE FIELD OF NETWORK SYNCHRONIZATION ENGINEERING
6.1.1
Introduction
The branch of network engineering that studies the distribution and quality of clock signals that are used in the public telecommunications network calls itself synchronization network engineering. In today's telecommunications networks, the clocks in transmission and switching equipment are often required to operate at equal or almost equal frequencies in order to transport signals between them that carry digital information and to do so without introducing single bit errors or bursts of errors. Synchronous operation of equipment that is spread out over a large geographic area requires a distribution network for synchronization information. The effects that cause degradation of this synchronization information can be divided in two categories. First, there is continuous degradation of these signals due to the accumulation of phase noise, caused by imperfect components and designs. This causes jitter and wander on the digital signals that are transported over the network. Too high levels of jitter and wander can cause bit errors, loss of frame, or controlled slips. Second, there may occasionally be a complete failure of a synchronization link, leaving network elements or entire network parts without synchronization information. The design of the synchronization network tries to minimize the effect of both the continuous phase noise accumulation and the effect of incidental
190
Chapter 6
loss of synchronization. Sections 6.2 through 6.4 of this chapter describe the theory and practice of phase noise, while Section 6.5 concentrates on the protection against loss of synchronization reference due to link failures. 6.1.1.1
Short History
The history of the specification of network synchronization, jitter, and wander is closely coupled to the history of digital transmission. Only when transmission became digital did the timing of the symbols on the line become important. The earliest problems to tackle involved jitter. Initially, digital transmission systems were used for point-to-point transmission to replace the Frequency Domain Multiplexed (FDM) systems in use at the time. The advances in integrated electronics made it possible to build the more complex digital Time Domain Multiplexed (TDM) systems. These allowed, in principle, the building of transmission paths that had no degradation, irrespective of the length of the path, as long as the "bits" on the line were recovered in each regenerator without error. To allow TDM systems to operate error free, the bits had to be sent on the line at very regular, equidistant, points in time. Deviation from this ideal was called jitter, and limits were set on its magnitude so as to control the number of bit errors made in the receiver. The next step in the evolution of digital systems was the concatenation of multiple digital systems, by directly patching through the 64 kbit/s DSO digital signals themselves on channel banks. This practice required the clocks of these systems to be equal, because the applied (primary) TDM multiplex method required the timing of the tributary signals to be coupled to the aggregate clock. This system of interconnected TDM systems became a nationwide network when digital switching was introduced. This required all switches and all 64 kbit/s signals to be synchronous. To make sure that this synchronicity was, under all conditions, guaranteed, a specific clock distribution network was deployed. It required the specification clock accuracies, reference switching, and holdover behavior to limit impairment due to wander and frame slip. This was the situation when SDH and SONET were introduced. The SDH/SONET multiplexing system required that the clock distribution network of PDH would no longer be carried over El or DSl trunk signals, but would be shifted to the OC-M/STM-N carriers of SONET/SDH. Moreover, the SDH/SONET network itself needed to be synchronized to avoid accumulation of large amount of wander in its payload signals.
Synchronization of Optical Networks
191
The last step was the introduction of OTN, This network is basically again an analog (FDM) network, but instead of multiplexing RF frequencies, optical wavelengths are multiplexed. But similar to the PDH network, the OTN network itself can operate asynchronously and still transport a synchronous STM-N/OC-M payload.
6,2.
BACKGROUND ON TIMING, SYNCHRONIZATION, AND JITTER
This section provides background on timing, synchronization, and jitter, and their importance in digital networks, A more detailed overview of this subject, with an emphasis on SONET/SDH networks, is given in [1].
6.2.1
Basics of Digital Transmission, Timing Jitter, and Alignment Jitter
At a fundamental level, a network transports client information from an ingress to an egress point over a number of links and nodes. In the case of a digital network, the information is transported as successive bits at a rate that may be constant or variable. Whatever the rate is at the ingress, each bit has associated with it an instant of time at which the bit is transmitted. If the client signal is constant bit rate (CBR), which is the case for Plesiochronous Digital Hierarchy (PDH), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Optical Transport Network (OTN) signals, and if the client itself has no timing impairments, then the client bit times at the ingress are equally spaced with period T equal to the reciprocal of the bit rate. This is illustrated in Figure 6-1. At a low layer, a bit may be transported over a single link as an analog pulse, with different pulses representing 1 and 0. The specific forms of the pulses are determined by the line coding. For example, a non-return-to-zero (NRZ) line coding represents 1 by a particular voltage or optical power level (depending on whether the link is electrical or optical, respectively) and 0 by a different voltage or optical power level. For simplicity in the examples given here, the levels may be taken as 1 Y or 0 dBm for binary 1 and 0 V or -10 dBm for binary 0.^ Then a stream of NRZ-encoded bits with constant rate and no impairments is represented mathematically as a train of such pulses [2]
^(0- Y.''n8(t-nT)
(6.1)
192
Chapter 6
where ^(0 = rectangular pulse of height 1, extending from t = 0 to t = T a, =n'^ hit (an e {0,1}) T= size of unit interval in units of time (seconds) = l/(bit rate in bits/s) xit) = amplitude function for pulse train at transmitter. An NRZ-encoded bit stream is illustrated in Figure 6-2. In this example, the bit time (sometimes referred to as the significant instant) is associated with the leading edge of the pulse/ The train of pulses, Eq. (6.1), may be represented by an actual signal (baseband signal) or may be used to modulate a higher-frequency carrier. The latter is normally the case in an optical transmission system, where the signal modulates an optical carrier of a given wavelength. At the receiver end of the link, the pulses will be distorted due to impairments in the transmission process. There also are, in practice, timing impairments, which shift the pulses in time relative to the equally spaced ideal time instants. Finally, noise is present due to various sources in the link. The resulting amplitude function for the pulse train at the receiver is [2] y(0= f^aMt-nT-e[nT]-T,)-h?j(t)
(6.2)
where (square brackets denote a discrete-time function) h(t) = distorted pulse due to transmission impairments e[nT] = shift in timing of pulse due to timing impairments 7 = size of unit interval in units of time (seconds) = l/(bit rate in bits/s) y(t) = amplitude function for pulse train at receiver T](t) = noise due to all sources TQ = average propagation delay between transmitter and receiver. An NRZ-encoded bit stream with distortion and timing impairments, and with the average propagation delay TQ removed, is illustrated in Figures 6-3 and 6-4. Figure 6-3 shows the signal with only timing impairments, while Figure 6-4 shows it with both timing impairments and distortion. The function e[nT] is the phase-error function (also referred to as the phase).
Synchronization of Optical Networks
T
2T
193
3T
4T
5T Time
Figure 6-7. Bit times for CBR signal with no timing impairments
Pulse Height 1
1
1
0
1
0
1
(vj
... ol
1r
3T
2T
4T
5T Time
Figure 6-2. Example NRZ-encoded bit stream, with no distortion (amplitude) or timing impairments, and no noise
e[3T] ^
e[2T]—> Pulse Height
1
1
e[5T]—> 1
0
0
1
(V)
• •• 0
T
2T
3T
4T
5T
Time
Figure 6-3. Example NRZ-encoded bit stream, with timing impairments but no distortion
194
Chapter 6
0
T
2T
3T
4T
5T
Time
Figure 6-4. Example NRZ-encoded bit stream, with timing impairments and distortion
recovered data
received data Decision Circuit i i
C*lock Recovery
Figure 6-5. Schematic of sampling and decision process for data recovery
e(s)
eXs)
Figure 6-6. Functional block for clock recovery low-pass filter
To determine whether a received pulse is a 1 or a 0, it must be sampled as close to the shifted pulse time nT + e[nT] as possible.^ A decision circuit compares the sampled value with a threshold. The sampling and decision process is illustrated in Figure 6-5. The mathematical theory of this process is described in detail in a number of references (see, for example, [2]-[5]) and will not be repeated here. However, we note that, in general, a larger magnitude of any impairment or noise source results in higher probability of a bit error. In particular, a larger offset between the ideal sampling time nT + e[nT] and the recovered sampling time nT + er[nT] results in higher
Synchronization of Optical Networks
195
probability of a bit error. The offset between the ideal sampling time and the recovered sampling time, CainT] = e[nT] - eXnT], is referred to as the alignment jitter. The determination of the recovered sampling instant is done with a clock recovery circuit. These circuits are often implemented using phase-locked loops (PLLs). Clock recovery circuits are described in more detail in [2], [6], and [7]. Functionally, the clock recovery circuit acts as a low-pass filter on the actual phase error e[nT\ to produce a recovered phase error eXnT] that is as close to e[nT\ as possible. This process is illustrated in Figure 6-6, where the actual and recovered phase error are related by e^{s) = H{s)e{s) with H{s) the transfer function of a suitable low-pass filter. alignment jitter is related to the actual phase error by e, is) = [1 - H{s)]e{s) s H^ {s)e{s)
(6.3) Then, the
(6.4)
Since H{s) is a low-pass filter, H^is) - 1 - H{s) is a high-pass filter. Therefore, the alignment jitter is equal to the phase-error filtered by a suitable high-pass filter; alternatively, it is equal to the short-term variations in the phase error. Eq. (6.4) also illustrates that, since He{s) is a high-pass filter, sufficiently slow variations in the phase error e{s) will result in very small alignment jitter, i.e., the variations will be tracked. However, fast variations in e{s) above the bandwidth, or corner frequency, of the clock recovery circuit will not be tracked, and will result in larger alignment jitter. Higher-frequency variation in the phase error is referred to as timing jitter. If Figure 6-5 represents the clock and data recovery process at a receiver, the data may be retransmitted on the next link (unless this is the final link), with possibly some buffering at the receiver node. There are two possibilities for the timing of the retransmitted data. First, the data may be transmitted with a clock that is independent of the timing of the received data (and therefore independent of the clock timing the data at the upstream node). In this case, the data buffer in the receiver node will eventually overflow or underflow, resulting in a slip."^ This mechanism is used in Public Switched Telephone Network (PSTN) switches; however, it is not used in the SONET, SDH, and OTN physical layers. Second, the transmit clock may be derived from (or be the same as) the recovered timing from the received data. This mechanism is used in OTN 3R regenerators and in SDH/SONET and PDH regenerators. Because OTN 3R^ and SDH regenerators also must process some overhead, the data must be buffered. In this case, it is advantageous (and, in the case of OTN, required) to filter the
196
Chapter 6
recovered clock in Figure 6-5 with a second, narrower-bandwidth phaselocked loop to further reduce any jitter. This second PLL can help control jitter accumulation over multiple 3R regenerators. However, the data buffer must be sufficiently large to accommodate momentary timing differences between the input data (clock) to the receiver and the filtered clock output of this second PLL. In general, the buffer must be made larger as the bandwidth of the second PLL is made smaller. The second, narrowerbandwidth PLL is sometimes referred to as a dejitterizer,
6,2.2
Jitter Tolerance, Transfer, Generation, and Network Limit
The ability of equipment to accommodate input jitter is referred to as jitter tolerance. As mentioned above, higher-frequency input phase error, or timing jitter, results in alignment jitter, or a difference between the ideal and actual sampling instants; larger alignment jitter means larger bit error probability or bit error ratio (BER). More precisely, a larger alignment jitter means that the actual sampling point is further from the center of the pulse; since real pulses are not exactly square, the actual sampling point is more likely to be on a portion of the pulse that is rising or falling and therefore closer to the decision threshold.^ There is then a greater probability of noise causing the sample to fall on the wrong side of the decision threshold, resulting in a bit error. The effect of jitter on BER can be mitigated by increasing the average signal power relative to the noise level. This approach is used in defining and specifying jitter tolerance. Jitter tolerance for an optical receiver is defined as the minimum level (i.e., minimum peakto-peak amplitude) of sinusoidal jitter of a given frequency that must be accommodated, which results in a 1 dB power penalty.^ Specifically, the average signal power is increased by 1 dB relative to the noise, which results in a drop in BER. Jitter is then added, and its level is increased until the BER is equal to its level prior to increasing the power. This is the level of jitter that the equipment can tolerate, and it must not be smaller than the specified jitter tolerance. Sinusoidal jitter, i.e., sinusoidally varying input phase error, is used in specifying jitter tolerance. This is conservative, because sinusoidal jitter is closer to its positive and negative peak values for a greater fraction of time compared with more realistic jitter distributions (e.g., Gaussian). Since input jitter above the clock recovery PLL bandwidth is not tracked, the jitter tolerance is approximately the same for frequencies above this corner frequency. For lower frequencies, the fact that the alignment jitter is equal to the input jitter filtered by a low-pass filter means that, for a given level of alignment jitter, the input jitter that results in this outcome as a
Synchronization of Optical Networks
197
function of frequency has a -20 dB/decade slope (assuming the PLL has a 20 dB/decade roll-off). To show this, assume the clock recovery PLL has a first-order^ closed-loop response with transfer function H(s) = - ^ ^
(6.5)
where CO] = 27if\ is the PLL corner frequency. Then H^{s)^\-H{s) = -^—
(6.6)
S + CO^
\HX27gf)\ is illustrated schematically in Figure 6-7 (this is an asymptotic approximation; the actual log-magnitude transfer function is 3 dB lower at the corner frequency/i). Let the input signal have sinusoidal phase error with amplitude Ao(f) (the amplitude can depend on frequency). Since the magnitude of the phase error transfer function relates the amplitude of the input phase error to the amplitude of the output phase error (specifically, it is the ratio of the latter to the former), the amplitude of the alignment jitter, A«(/), may be written \(f)
= \H^ {27gf)\\ if) = - 1 ^ =
Then I f2 _^ f2
(6.8)
198
Chapter 6
(log scale)
/, = PLL corner frequency
frequency (log scale)
Figure 6-7. Schematic of log-magnitude transfer function of clock recovery PLL
Now set Aaif) equal to the alignment jitter amplitude that corresponds to a 1 dB power penalty, i.e., the value of alignment jitter amplitude that would result in unchanged BER if the power were increased 1 dB. This value of Aaif) is independent of frequency, and therefore A^if) does depend on frequency. Ao(/) is the jitter tolerance and is illustrated schematically in Figure 6-8. Ao(/) has a slope of -20 dB/decade for frequencies that are small compared with the PLL corner frequency, / j , and is equal to A« for frequencies that are large compared with f\. In practice, jitter is often specified in terms of peak-to-peak values rather than amplitude (i.e., zero-topeak values); this corresponds to multiplying both sides of Eq. (6.9) by 2. The full jitter tolerance mask is illustrated in Figure 6-9 (adapted from Figure L2 of [8] and Figure L2 of [9]), where the frequencies f\ and fi represent the band widths of the dejitterizer PLL and clock recovery circuit, respectively. Similar arguments apply to the dejitterizer PLL, except here the jitter tolerance is determined by the data buffer size. A more detailed discussion of this is given in Appendix I of [8] and Appendix I of [9]. A jitter tolerance mask of the form in Figure 6-9 represents the minimum level of jitter that equipment must tolerate. Therefore, it may be used to define the network limit, i.e., the maximum level of jitter allowed in the network. Since the actual jitter in a network is generally not sinusoidal, the network limit is defined using high-pass filters. The wide-band jitter is defined as the peak-to-peak value of the phase error signal filtered by a highpass filter with corner frequency/i. The high-band jiiitY is defined as the peak-to-peak value of the phase error signal filtered by a high-pass filter with corner frequency fi. The high-band and wide-band jitter must not exceed Ai and A2 (given in Figure 6-9), respectively. The PDH, SDH/SONET, and OTN specifications also define low-pass filters to be
Synchronization of Optical Networks
199
applied when measuring the jitter network limits; these have bandwidths that are more than an order of magnitude greater than the high-band jitter highpass measurement filter, and are intended to represent an upper practical limit to the spectral content of the jitter that can arise in the network.^
(log scale)
20 dB/decade
frequency (log scale)
Figure 6-8. Schematic of jitter tolerance of clock recovery PLL
peak-to-peak amplitude (log scale)
20 dB/decade
A, = dejitterizer PLL jitter tolerance
A2 = clock recovery PLL jitter tolerance
/, = dejitterizer PLL bandwidth
f, = clock recovery PLL bandwidth
frequency (1»8 ^^^1^)
Figure 6-9. Relation between jitter tolerance mask and dejitterizer and clock recovery PLL bandwidths (adapted from Figure 1.2 of Reference [8] and Figure 1.2 of Reference [9])
Clock recovery circuits and dejitterizer filters, in practice, produce some amount of jitter, and this must be limited to prevent excessive jitter accumulation. The jitter generation of a piece of equipment is defined as the peak-to-peak jitter of the output when the input is jitter-free. Jitter
200
Chapter 6
measurement filters must be specified. For OTN [8] and Option 1 SDH [10], high-band jitter generation and wide-band jitter generation are defined, with measurement filters consistent with the jitter tolerance masks and network limits. For Option 2 SDH (SONET) [10], [11], the jitter generation measurement filters for OC-48/STM-16 and lower rates are not consistent with the network limits and jitter tolerance masks; however, the jitter generation and measurement filters are consistent with the network limits and jitter tolerance for OC-192/STM-64. The lack of consistency for SONET OC-48 and lower rates is mainly historical. Finally, timing jitter can accumulate over a chain of regenerators. Early studies of jitter accumulation, based on first-order filter regenerator models, are given in [12]. Later studies using second-order filter models that accounted for gain-peaking are given in [13]. Both types of results are described in [2]. The results show that limiting the regenerator bandwidth limits the jitter accumulation. In addition, the second-order filter results show that gain peaking can cause jitter accumulation to increase sharply after some number of regenerators. More recently, jitter accumulation studies were performed for OTN 3R regenerators using a model that explicitly accounts for noise in the PLL phase detector (PD), voltagecontrolled oscillator (VCO), and input. The model studies are documented in Appendix IV of [8], and the results were used to derive the 3R regenerator jitter requirements in [8]. Some of these results are used in examples in Section 6.4.2.
6.2.3
Mapping and Multiplexing
Often, a client signal is mapped into a server layer where the timing of the server is independent of the timing of the client. This is necessarily true when a number of client signals, each with timing independent of the others, are multiplexed into a higher-rate server layer; in this case, the server timing cannot be simultaneously traceable to all the client timings because the latter are all different. However, there are cases where a single client signal is mapped into a server layer (of slightly higher rate to account for server layer overhead), with the client and server timing independent of each other. Note that even if the multiple client signal clocks are specified to have the same nominal rate, the actual signal rates will not be the same if they are provided by different clocks because the frequency of a clock is never specified exactly; rather, a nominal rate plus a tolerance is specified (frequency tolerance and frequency offset are described in Section 6.2.5). A mapping of a client signal into a server layer with the client and server timings independent of each other is referred to as an asynchronous mapping. A mapping of a client signal into a server layer with the server timing traceable
Synchronization of Optical Networks
201
to the client timing (and no other relation between client and server byte or frame boundaries) is referred to as a bit-synchronous mapping. In PDH, asynchronous multiplexing of lower-rate signals into higher-rate signals is defined. In SONET and SDH, asynchronous, bit-synchronous, and bytesynchronous mappings of PDH clients are defined; however, in the vast majority of cases only the asynchronous mappings are used. In OTN, asynchronous and bit-synchronous mappings of CBR clients are defined. In bit-synchronous mapping, the server timing can be obtained from the client timing using a PLL that multiplies the client clock by the ratio of server to client nominal rate. The effect on jitter is similar to that of a regenerator. However, if the client signal is lost, the server timing will also be lost unless there is an alternative source of timing. One way of providing this alternative is for the PLL to be part of a clock that can enter free-run condition when its input is lost; another way is to have a separate clock whose timing is used when the client input is lost. In either case, requirements would be necessary to limit the phase and frequency transient when the client is lost and server timing switches to another source. In asynchronous mapping, the server timing is independent of the client timing. The client rate must be adapted to the server rate. The most common schemes for rate adaptation use a form of stuffing at the mapper coupled with destuffing and filtering at the demapper (the mapper is sometimes referred to as a synchronizer, the filter plus destuffer are collectively referred to as a desynchronizer). The client signal is buffered at the mapper; the client bits enter the buffer at the client rate and leave the buffer at the average rate of the server payload area (this rate is less than the server rate due to the presence of server layer overhead). In general, these two rates differ; therefore, if this process continues indefinitely, the buffer will eventually overflow or underflow. To prevent this, the buffer fill is monitored and, based on an algorithm whose input is the buffer fill, either extra or less payload information may be transmitted. The extra payload information is transmitted in designated server overhead known as negative stuff or negative justification. If less payload information is transmitted, designated bits or bytes in the payload area of the server frame are filled with dummy information rather than client information; this is known as positive stuff or positive justification. Server layer overhead known as stuff control or justification control indicates in each server layer frame whether a stuff has been done and, if so, whether it is positive or negative; this information is needed by the demapper. The delivery of client bits to the demapper is not uniform. Most of the time the bits are delivered at the actual server rate. However, there are regular gaps due to server layer overhead. In addition, there are either gaps due to negative stuff or extra bits due to positive stuff. The timing
202
Chapter 6
information embedded in this irregular bit stream is referred to as a gapped clock. This gapped clock is filtered by a desynchronizer (usually a PLL) to produce a clock with uniform rate (a regular clock). However, the resulting regular clock does contain some jitter and phase error due to the stuffs and overhead. Typically, requirements are placed on the desynchronizer to ensure that its jitter and wander (i.e., low-frequency phase error) generation (output jitter/wander in the absence of any jitter/wander on the client input at the mapper, and no additional sources of jitter or phase error in the server layer) are acceptable. In most cases, the regular gaps due to fixed overhead are easy to filter because they are of sufficiently high frequency; alternatively, if it is possible to buffer some data, a regular clock that runs at the rate with the fixed overhead removed can be derived from a clock that runs at the rate with the fixed overhead present using a PLL. However, the phase error waveform for the gapped clock that contains stuffs will tend to have a low-frequency envelope that is more difficult to filter. The jitter due to this envelope is referred to as waiting time jitter, and may be more difficult to filter if its frequency is sufficiently low relative to the desynchronizer bandwidth. In almost all cases of interest, the stuff unit is either 1 bit, 1 byte (8 bits), or an integral number of bytes. The number of stuff units per server layer frame is related to the nominal server and client rates and range of client and server frequency offset that must be accommodated. For example, if the nominal server payload area average rate is higher than the nominal client rate (this is the case for multiplexing PDH signals into higher-rate PDH signals and for mapping PDH signals into SDH Virtual Containers (VCs)), there will be a constant nominal positive stuff rate if the client and server frequencies are exactly nominal. The maximum server and minimum client rates (based on their frequency tolerances) determine the required maximum stuff opportunity rate. The minimum server and maximum client rates determine the required minimum stuff opportunity rate (which may be negative indicating negative stuffing). The relation among rate of stuffing, nominal client and server rates, and client and server frequency offsets is quantified for OTN in Appendix I of ITU-T Recommendation G.709 [14]. This is done for both mapping of CBR (e.g., SDH) clients into ODUk and multiplexing of ODUk into ODUm (m > k). The OTN CBR client mappings allow positive and negative byte justification (this is referred to as positive/negative/zero or +7/0/-7 byte justification). In addition, the multiplexing of ODUk into ODUm (m > k) allow positive justification of 2 bytes or 1 byte, and negative justification of 1 byte (this is referred to as +2/+//(9/-7 justification). The mappings used for PDH multiplexing allow positive bit justification (the rates and tolerances are such that negative bit justification would never be needed).
Synchronization of Optical Networks
203
The most straightforward algorithm for determining when to do a stuff is to monitor the mapper buffer and do a positive stuff if the buffer empties below a negative threshold and a negative stuff if the buffer fills above a positive threshold. This scheme is used for PDH multiplexing, with the simplification that only positive (bit) stuffing is needed because the minimum server payload area rate is greater than the maximum client rate; therefore, only one threshold must be considered. When the stuff ratio (the fraction of stuff opportunities for which a stuff is done) is close to a number that is the ratio of small integers, the phase waveform tends to have the low frequency envelope referred to above, and the jitter tends to be larger. The straightforward algorithm is used for OTN CBR client mappings defined in [14]. The CBR client demapper (desynchronizer) requirements of [8] provide for acceptable jitter and wander performance for the CBR clients. The OTN CBR client desynchronizer bandwidth is sufficiently narrow compared to the jitter measurement filters for the STM-N clients. It is possible to consider other more advanced justification algorithms where, for example, client phase information is explicitly carried in the server overhead or where threshold modulation is employed. Such schemes can result in reduced jitter or wander. However, they are not discussed here because the conventional scheme is found to produce acceptable jitter and wander accumulation for OTN. In the case of SDH, the asynchronous mapping of some PDH clients, e.g., DS3 and E4, use purely positive bit stuffing with the conventional algorithm. However, some mappings, e.g., DSl, El, and E3, use +1/0/-1 bit stuffing; i.e., there are two stuff bits per frame and, if the VC~11, VC-12, or VC-3 and DSl, El, or E3 frequencies (respectively) were exactly nominal, one stuff bit would contain data and the other would contain stuff.
6,2.4
Pointer Adjustments
In addition to mapping a client signal into a server layer, it is also often desired to cross-connect client signals at an intermediate switching node. Specifically, the client signals multiplexed within incoming server layer signals may not all have the same destination; it may be necessary to switch them to different outgoing server layer signals. In addition, it may be desired to drop one of the multiplexed client signals at a node and replace it with another client signal of the same type that originates at this node (i.e., perform add/drop). In principle, the cross-connect and add/drop functions could be accomplished by completely demultiplexing and demapping the client signals from each incoming server layer signal at a node, switching the client signals to the appropriate output ports, and remultiplexing them into new server layer signals. In PDH networks and OTN, this is the procedure
204
Chapter 6
that is used. However, in SONET and SDH networks, the cross-connect and add/drop functions are performed with the aid of the pointer mechanism. The SONET and SDH frame formats and multiplexing hierarchies are specified in [15] and [16]. Schematics of the SONET and SDH multiplexing structures are given in Chapter 4 of the present book. SONET and SDH clients are mapped into containers, shown at the bottom of Figures 4-1 and 4-2 of Chapter 4, For example, DSl, El, E3, DS3, and E4 clients can be mapped into C-11, C-12, C-3, C-3, and C-4 containers, respectively. Overhead (the nature of which is unimportant for the discussion here) is added to create a VT1.5 Synchronous Payload Envelope (SPE) (SONET) or VC-11 (SDH), VT-2 SPE (SONET) or VC-12 (SDH), STS-1 SPE (SONET) or VC-3 (SDH), or STS-3c SPE (SONET) or VC-4 (SDH), respectively. The SONET VT and STS SPEs and SDH VCs float in their respective frames. For example, the SONET STS-1 SPE may start anywhere in columns 4 through 90 of the OC-1 frame, and the starting point is indicated by a pointer (specifically, by the HI and H2 bytes in row 4, columns 1 and 2, respectively). The timing for the outgoing SONET or SDH signals (OC-N or STM-N) from a Network Element (NE) where cross-connect or add/drop functions are performed (i.e., where the SONET Line or SDH Multiplex Section (MS) is terminated) is, in general, independent of the timing of the incoming signals. The bytes of each incoming STS-N SPE/VC-N are buffered and then placed in the respective outgoing OC-N/STM-N, with the starting position indicated by the pointer. Since the outgoing timing is independent of the incoming client timing, the buffer fill for each STS-N SPE/VC-N will change over time. In addition, since the long-term average frequencies of the incoming and outgoing signals may be different, the buffer will eventually overflow or underflow and result in data loss if nothing is done. To prevent this, the buffer fill is constantly compared with upper and lower thresholds. If the upper threshold is exceeded, a negative pointer adjustment is performed. Specifically, in the next frame, extra data bytes (e.g., 1 byte for STS-1 and 3 bytes for VC-4) are written to the H3 overhead byte(s). In addition, the starting point of the STS-N SPEA^C-N shifts towards the beginning of the OC-N/STM-N by the number of extra data bytes written. This process is referred to as a negative pointer adjustment. Conversely, if the lower threshold is exceeded, a positive pointer adjustment is performed. Specifically, in the next frame, data bytes adjacent to the H3 byte(s) (e.g., 1 byte for STS-1 and 3 bytes for VC-4) are filled with stuff. In addition, the starting point of the STS-N SPE/VC-N shifts towards the end of the OCN/STM-N by the number of extra data bytes written. This process is referred to as a positive pointer adjustment.
Synchronization of Optical Networks
205
From the standpoint of timing, a pointer adjustment is equivalent to a justification of the same magnitude and sign. A positive or negative pointer adjustment of M bytes results in M fewer or extra client layer bytes being transmitted; this is equivalent to +M/0/-M byte justification (note that here, i.e., in SONET or SDH, the client layer is the VT/STS SPE or VC). The result of a pointer adjustment is a phase step of +M or -M bytes. One main difference between the pointer and justification mechanisms is that the pointer indicates where in the OC-N/STM-N the client (VT/STS SPE or VC) begins. In a justification mechanism, the client framing must be determined separately. However, this has no impact on timing, jitter, and wander. If a client signal traverses a number of SONET/SDH NEs, pointer processor buffer fill variations and pointer adjustments may occur at each NE. The phase difference over a time interval between the client signal at the network egress (i.e., where the client is demapped) and network ingress (i.e., where the client is mapped) is equal to the net change in total fill of all the buffers over that time interval. During normal operation, SONET and SDH networks are synchronized, i.e., the timing for the NEs is specified to be within a certain frequency tolerance of nominal, and phase variation (jitter and wander) is constrained (timing signal imperfections and the characterization of timing performance are described in Sections 6.2.5 and 6.2.6). Under these conditions, the buffer fill variations tend to be relatively slow, and the phase variation is wander (i.e., its frequency content is below 10 Hz; see Section 6.2.5). In addition, a pointer adjustment at the egress node, where the client signal is demapped, results in a phase step equal to the size of the pointer adjustment. This phase step results in both jitter and wander. The jitter can be controlled by filtering the pointer adjustment with an appropriate desynchronizer (in the same manner that jitter due to justifications is controlled, as described in the previous subsection). The long-term wander for an isolated pointer adjustment (isolated means that the time between successive pointer adjustments is long compared with the desynchronizer time constant) is equal to the magnitude of the pointer adjustment; this cannot be reduced as long as the pointer adjustment is isolated. The short-term wander (e.g., the phase variation over various time intervals) can be controlled with an appropriate desynchronizer. Note that pointer adjustments at intermediate nodes impact jitter and wander only to the extent that they result in buffer fill variations (this impacts wander) and pointer adjustments at the final node where the signal is demapped (this impacts jitter and wander).
206
Chapter 6
6.2.5
Timing Signal Imperfections
All timing signals are imperfect, i.e., the phase or frequency as a function of time differs from the desired phase or frequency. First, the frequency of a timing signal may differ from the desired, or nominal, frequency, by a fixed amount. This is referred to as frequency offset. The fractional frequency offset, y, is defined as y = ' - ^
,6.,0)
where V = actual frequency Vo = desired, or nominal, frequency. In Eq. (6.10), y is a pure fraction; it is also often expressed in parts per million (ppm). The frequency tolerance of a clock or timing signal is the specified maximum allowable absolute value for y. Second, the frequency of a timing signal may change with time. The rate of change is the frequency drift rate, which is often expressed in ppm/s. Often, the maximum frequency drift rate is specified for a transient event. Third, a timing signal may contain random phase noise, i.e., the phase error as a function of time is a random process. This can be characterized by power spectral density (PSD, described below in Section 6.2.5.1); additional, more convenient measures are given in Section 6.2.6. Fourth, it was indicated in previous sections that jitter, or the result of passing the phase error process through a high-pass filter, is useful in specifying the performance of clock recovery circuits and 3R regenerators. The specified high-pass filter is typically first order; its corner frequency depends on the signal in question (i.e., it is part of the specification), but is always greater than 10 Hz. Finally, wander is phase variation whose frequency components are less than 10 Hz. It is of interest when considering slip performance and synchronization distribution. The total instantaneous phase error of a timing signal at time t may be written [17]
Synchronization of Optical Networks
207
where 0(0 = instantaneous phase error at time t (UI) D = frequency drift rate (s'^) Oo = initial phase error (UI) (p(t) = instantaneous phase noise random process (UI). The instantaneous phase error may be expressed in radians by multiplying Eq. (6,11) by 2;r, and in units of time (e.g., s) by dividing Eq. (6,11) by VQ. When the phase is expressed in units of time, often the symbol x is used, rather than , i.e., x{t) = XQ + yt'^-Dt^+^
(6.12)
Note that x(t) is sometimes used to represent just the random component of phase error expressed in units of time (i.e., the final term in Eq. (6,12) [17], whereas in Eq. (6.12) it represents the total phase error. Both conventions are used in this chapter, with the definition clearly indicated for each use. 6.2.5.1
Phase Noise'^
The phase noise random process, gj(t) in Eq. (6.12), may be characterized by its Power Spectral Density. In the remainder of this subsection, the phase noise will be expressed in units of time and represented by .^(0- The twosided PSD, Sjc(co), is defined by
2^-^°°
(6.13)
where R^i f) is the autocorrelation function. /?^( f) is defined by R^(T) = E[x{t)x(t + T)]
(6.14)
where E[] denotes expectation (ensemble average). In characterizing clock noise, usually the one-sided PSD is used; this is related to the autocorrelation function by
208
Chapter 6 S^{f)
=
4rR^(T)cos27fTdT ^
(6.15)
R^{T)=
^S^{f)COS27tfTdT
Eqs. (6.13)-(6.15) assume that the random phase process x(t) is widesense stationary, i.e., that the autocorrelation function depends only on the difference between the times of the two samples (or that Eq. (6.14) is independent of 0-'^ However, it will be seen shortly that many of the stochastic models used to characterize phase noise have power law PSDs, and some of these models are nonstationary. This problem is addressed by realizing that, in real systems, high- and low-frequency cutoffs exist. For example, a theoretical high-frequency limit is provided by the fact that it makes no sense to sample faster than the bit rate of the signal; a tighter limit may be imposed by the measurement system. A low-frequency cutoff is provided by the fact that measurements are made over finite time intervals. These issues are described in detail in Appendix I of [18]. As is stated in [18], results of measurements and calculations are most meaningful if they are independent of the low-frequency cutoff as this frequency approaches zero. In any case, the following points hold when using nonstationary models: 1. When making measurements, one should use statistics that converge. This was one consideration that led to the TVAR and TDEV parameters described in the next subsection, as well as to the related parameters Allan Variance and Modified Allan Variance (see [19], [20], [18], and various references given in those documents for more details on these parameters). 2. When performing analytical calculations, one must ensure that mathematical operations (e.g., summations, integrals) converge. Measurement of phase noise in clocks and oscillators has shown that the form of the power spectral density is generally a linear combination of power law terms [19]:
fi=oJ
k
(6.16) h^
h.
" f f
f
K
r
Each term is considered to represent a different noise type. The first term in Eq. (6.16) represents familiar white noise (white phase modulation, or
Synchronization of Optical Networks
209
WPM) that has a flat power spectral density. The third term in Eq. (6.16) represents white frequency modulation (WFM). Since phase is the integral of frequency, this white frequency noise results in a random walk in phase. The second and fourth terms in Eq. (6.16) represent flicker phase modulation (FPM) and flicker frequency modulation (FFM), respectively. The fifth term represents random walk frequency modulation (RWFM). Mathematical models have been developed in which the flicker noise terms may be considered as half (i.e., fractional order) integrals of white noise terms [21], [22], [23]. The fundamental physical processes that give rise to flicker noise are not nearly as well understood as those that give rise to white noise (e.g., the latter can arise from thermal motion of atoms and molecules). However, this particular lack of knowledge has not prevented the characterization of noise in clocks and oscillators. Eq. (6.16) can be generalized, if desired, to include power law dependences involving fractional exponents. In this case, P would take on any value (real number) between 0 and 4. In addition, there could, in principle, be an arbitrary number of terms. It can be shown that Gaussian noise with power spectral density of the form h/^J^ is wide-sense stationary (i.e., the autocorrelation function, as given by Eq. (6.14), depends only on r and not on 0 if 0 < P < 1 and nonstationary if J3> \ (see [24] for details).
6,2.6
Characterization of Timing Performance
This section describes several useful measures of jitter and wander performance. These measures include peak-to-peak jitter, root-mean-square (RMS) jitter, maximum time interval error (MTIE), time variance (TVAR), and square-root of time variance, or time deviation (TDEV). These measures, along with other terminology for network timing, jitter, and synchronization, are defined in [17] and described in more detail there. 6.2.6.1
Peak-to-Peak and RMS Jitter
Let CalnT] be the jitter process, i.e., the result of passing the phase error process through an appropriate jitter measurement filter (7 is the bit period). The RMS jitter, JRMS^ is defined as J,^,=^E[el(nT)]
(6.17)
where £"[•] denotes expected value, Eq. (6.17) assumes the jitter process is stationary; this assumption is valid because of the high-pass filtering. In
210
Chapter 6
practice, the jitter process is ergodic and RMS jitter may be estimated by replacing the ensemble average with a time average. Peak-to-peak jitter over a specified time interval is the difference between the maximum jitter value over that time interval and the minimum jitter value over that time interval (in defining the minimum value here, the sign of the jitter must be accounted for; the minimum value is algebraically the smallest value). In a rigorous definition, the maximum and minimum values should be defined as specified quantiles of the jitter distribution. However, in practice, the maximum and minimum values of a single sample of the jitter process are used. The time interval must be long compared with the time constant of the jitter measurement filter. For SDH/SONET and OTN line jitter, a 60-second interval is used. 6.2.6.2
Maximum Time Interval Error (MTIE)
MTIE is the peak-to-peak phase error of a timing signal for a specified observation interval, expressed as a function of observation interval. For a given timing signal of duration r^ax and observation interval S < r^ax^ the peak-to-peak phase error is computed for all subintervals of the total duration that are of length S, MTIE for observation interval S is the largest of these peak-to-peak values. MTIE is defined in this manner for 0 < 5 < r^ax- As with peak-to-peak jitter, MTIE should be defined as a specified quantile of a random variable defined by the above operation. However, in practice only a single phase history sample is generally used, and MTIE is estimated as the value of that sample (for each observation interval). MTIE may be defined rigorously as follows [17]. Define the random variable X (which is a function of the observation interval S, and may therefore also be thought of as a random process indexed by the parameter
sy X(5)=
max
max [x{t)\-
min [x{t)\\
(6.18)
Then MTIE(5) is defined as a specified percentile, p, of X(5). For a sampled data set obtained from a single measurement, MTIE can be estimated as
MTIE(nTo)= max (max x(i)ls'
• ^ AIS/FDI
AIS/FDI I I Selectors
I Selectors Figure 8-3. m : n protection architecture
Chapter 8
302
Normal (1)
"
Working (1)
Normal (1)
V^ I
Protection (1) I I —1-
Normal (2)
I I
Working (2)
Normal (2)
•T !•I I
Normal (n) M
Protection (2)
^
I I I I ^-1
Working (n)
A*-
1v Protection (n) |
I
V
I I
Extra Traffic (n+1)
^
I
Protection (0)
-I-
Normal (n)
T I I I I I I I ^ !-••
Extra Traffic (n+1) M—
l#-
Bridge
Selector
I Bridge
AIS/FDI
Selector
AIS/FDI
Figure 8-4, (1:1)" protection architecture
8.3.2.5
Ring Protection Architecture
Currently, the ITU is developing a new recommendation, G.808.2, which will provide an overview of generic aspects of ring protection. One simple application of ring protection is the self-healing ring, where a failure of one of the links between the ring nodes results in the ring reconfiguring itself and looping the traffic at the nodes nearest to the failure away from it. Another
Network Survivability
303
form of ring protection is shown in Figure 8-5, which is described in ITU Recommendation G.841 and is referred to as SDH Multiplex Section Shared Protection Rings (MS-SPRING). G.841 provides SDH equipment-level specifications to implement this type of protection.
8.3.3
Protection Switching Parameters
8.3.3.1
Switching Types
There are two types of protection switching, namely, unidirectional and bidirectional. a. Unidirectional switching : Switching, in this case, is completed when the normal traffic signal is selected from the protection channel at the end detecting the fault. For 1+1 architecture, the sink-end selector is activated only, and no communication with the source end is required. For other protection switching architectures, the sink-end selector and the source-end bridge are activated. This requires a communication channel between the two ends of the protected domain, which is referred to as the Automatic Protection Switching (APS) channel. The APS channel is terminated at the connection functions at both ends of the protected domain. The unidirectional protection switching is a simple scheme to implement, and under multiple failure conditions there is a greater chance of restoring traffic faster than with bidirectional switching.
STM-M Working Path
Zl. STM-M/ Au-4 Source—
[MTRAN Access Link ^
A
ETHfrtfeui
^^^^^t^i TRAN Trunk Link ^ ^
^
•i ^
1
• P
TRAN Access Link
MEN 2
Figure 9-9. MEN Reference Link Model (example)
ACKNOWLEDGMENTS Metro Ethernet Forum Enrique Hernandez-Valencia
9.4. [1] [2] [3] [4] [5]
REFERENCES
Metro Ethernet Forum, www. metroethemetforum.org. Technical Specification, MEF 4, Metro Ethernet Network Architecture: Framework, Part 1: Generic Framework. ITU-T Recommendation G.805, Generic functional architecture of transport networks, March 2000. ITU-T Recommendation G.809, Functional Architecture of Connectionless Layer Networks, March 2003. ITU-T Recommendation G.806, Characteristics of Transport Equipment — Description Methodology and Generic Functionality, February 2004.
This page intentionally blank
Chapter 10 ETHERNET SERVICES OVER METRO ETHERNET NETWORKS
Bob Klessig Cisco Systems,, Metro Ethernet Forum Member of the Board and Co-Chair of the Technical Committee
10.1.
INTRODUCTION
One of the highest priorities for the Metro Ethernet Forum has been the estabhshment of standards for Ethernet services. These standards will allow Subscribers to successfully plan and integrate Ethernet services into their overall networks and also to be able to do such integration with services from more than one service provider. These standards will also allow equipment vendors to implement capabilities in both service provider equipment and subscriber equipment such that the Ethernet services can be efficiently provided by the service providers and accessed by the subscribers. To accomplish these goals, Ethernet services must be described in precise technical details. The descriptions of the fundamental constructs for Ethernet services are presented in Section 10.2. Service features are described in Section 10.3. The material in this chapter is based on [1].
10.2.
SERVICES MODEL
The services model for Ethernet services is portrayed in Figure 10-1 and is further described in the following subsections.
Chapter 10
344
Customer Edge (e.g., router) (CE)
User Network
Customer
Service Attributes Figure 10-1. Ethernet services model
10.2.1 Customer Edge View The MEF Ethernet services are described from the point of view of the subscriber equipment, referred to as the Customer Edge (CE). Thus the services are defined only in terms that are observable to the CE. The types of technology and the architecture inside the Metro Ethernet Network (MEN) are invisible. By defining services in this manner, the MEN can evolve independently of the evolution of the subscriber's network without disruption of the service that the subscriber is given.
10.2.2 User Network Interface The User Network Interface (UNI) is the physical demarcation point between the responsibility of the service provider and the responsibility of a single subscriber. A UNI must be dedicated to a single subscriber. A UNI is frequently an RJ-45 socket on a service provider-owned Ethernet switch that is placed on the subscriber's premises. Another typical example is an RJ-45 socket on a service provider-owned patch panel. As implied in Figure 10-1, another way of viewing the UNI is that it is located where the CE begins and the MEN ends when looking outward from the MEN. It follows that the MEF services are described as the UNI-to-UNI behavior. For example, frame loss performance is defined in terms of frames received by the MEN at a UNI and frames delivered by the MEN to one or more other UNIs. A key goal in the development of the MEF Ethernet services is that existing, Standard Ethernet devices should be able to attach to an MEN (at a UNI) and successfully work with the service. This makes MEF Ethernet
Ethernet Services Over Metro Ethernet Networks
345
services the first wide-area services, with over 100 miUion existing devices capable of using the services. It follows that the protocols operating across the UNI between the CE and the MEN must be Standard Ethernet [3]. (See Appendix A for background material regarding Standard Ethernet.)
10.2.3 Service Frame There are several physical layers defined in [3], and it is that expected that the different UNIs will have different physical layers. For example, an enterprise might have a Gigabit Ethernet physical layer UNI at headquarters and Fast Ethernet physical layer UNIs at branch offices. However, all UNIs have the same Layer 2 protocol, as defined in [3]. Service frames are Ethernet frames that are exchanged between the MEN and the CE across the UNI. A service frame sent from the MEN to the CE at a UNI is called an egress service frame. A service frame sent from the CE to the MEN at a UNI is called an ingress service frame. 10.2.3.1
Format
The service frame is just a regular Ethernet frame beginning with the first bit of the Destination address through the last bit of the Frame Check Sequence (FCS). As per [3], a service frame that contains an IEEE 802.IQ tag can be up to 1522 bytes in length, and a service frame that does not contain an IEEE 802. IQ tag can be up to 1518 bytes.^ 10.2.3.2
Delivery Transparency
When an ingress service frame is delivered by the MEN to one or more UNIs, the fields of the egress service frame are identical to those of the ingress service except as follows: • The egress service frame may have an IEEE 802.IQ tag when the corresponding ingress service frame does not. • The egress service frame may not have an IEEE 802.IQ tag when the corresponding ingress service frame does have such a tag. • The egress service frame may have an IEEE 802.IQ tag that has a different value from the IEEE 802.IQ tag in the corresponding ingress service frame. In all three cases, the FCS will be recalculated and thus will probably be changed from ingress to egress.
346 10.2.3.3
Chapter 10 Error Detection
If an ingress service frame has an invalid FCS, it will be discarded by the MEN. This is a consequence of the fact that with MEF Ethernet services, the disposition of an ingress service frame is based on the content of the frame header. If a frame header contains bit errors, then the service frame could be delivered to the wrong destination. Discarding service frames with errors avoids this undesirable result.
10.2.4 Ethernet Virtual Connection In theory, an MEN could behave just like an Ethernet shared medium segment where each ingress service frame is replicated and delivered to all other UNIs. This LAN-like behavior can be acceptable within a single organization but is clearly not acceptable for a public network. In an MEN there must be some way to limit communication between UNIs. In MEF Ethernet services, this mechanism is called an Ethernet Virtual Connection (EVC). Each instance of an MEF Ethernet service is based on an EVC. 10.2.4.1
Definition of EVC
An EVC is defined as an association of two or more UNIs. Such UNIs are said to be in the EVC. An ingress service frame sent into an EVC can be delivered to one or more of the other UNIs in the EVC. It cannot be delivered to a UNI that is not in the EVC or back to the originating UNI. Service frames cannot leak into or out of an EVC. An EVC can be thought of as a form of Layer 2 VPN. The UNIs in the EVC seem to be in their own Layer 2 network. However, it is possible for a given UNI to be in multiple EVCs, which means that an EVC is more than a simple Layer 2 VPN. The basic EVC concept is illustrated in Figure 10-2. Two service instances are shown in the figure. The first service instance, based on EVC 1, allows headquarters to communicate with the backup data center. The second service instance, based on EVC 2, allows headquarters and the branches to communicate among themselves. The UNI at headquarters is in both of the EVCs. The router at headquarters would typically be configured with two sub-interfaces on the port attached to the UNI. Communications between the branches and the backup data center must go via the router at headquarters that would route between the two sub-interfaces.
Ethernet Services Over Metro Ethernet NetM^orks
347
Backup Data Center
Branch 2
Headquarters
Branch 1
Figure 10-2. Example of two service instances
There are two types of EVCs, as detailed in the following two subsections. 10.2.4.2
Point-to-Point EVC
A point-to-point EVC associates exactly two UNIs. EVC 1 in Figure 10-2 is an example of a point-to-point EVC. For a point-to-point EVC, all ingress service frames at one UNI, with the possible exception of Layer 2 control protocol messages (see Section 10.3.8.1), will typically be delivered to the other UNI. 10.2.4.3
Multipoint-to-Multipoint EVC
A multipoint-to-multipoint EVC associates two or more UNIs. EVC 2 in Figure 10-2 is an example of a multipoint-to-multipoint EVC. At first glance, it might appear that a multipoint-to-multipoint EVC with two UNIs is the same as a point-to-point EVC. However they are different because additional UNIs can be added to the multipoint-to-multipoint EVC. There are more options for delivery of ingress service frames (that are not Layer 2 control protocol messages) for a multipoint-to-multipoint EVC than for a point-to-point EVC. Broadcast service frames (all ones Destination MAC address) and multicast service frames (multicast Destination MAC address) are replicated and delivered to all other UNIs in the EVC. Unicast service frames (unicast Destination MAC address) can be handled in one of two ways:
348
Chapter 10
•
They can be replicated and delivered to all other UNIs in the EVC. This makes the EVC behave like a shared media Ethernet. • The MEN can learn which MAC addresses are "behind" which UNIs by observing the Source MAC addresses in service frames and deliver a service frame to only the appropriate UNI when the Destination MAC address has been learned. When the Destination MAC address has not been learned, the service frame is replicated and delivered to all other UNIs in the EVC. This makes the MEN behave like a learning bridge. It is important to know which technique is being used on a multipoint-tomultipoint EVC, since the behavior can impact the bandwidth consumed at each UNI and the compatibility with higher layer protocols.
10.2.5
Identifying an EVC at a UNI
In general, there can be more than one service instance, i.e., EVC, at a given UNI, as shown at the UNI at Headquarters in Figure 10-2. This means that for each service frame at the UNI, there must be a way to determine the EVC with which it is associated. This function is accomplished with the Customer Edge VLAN Identifier (CE-VLAN ID) and the CE-VLAN ID/EVC map, as described in the following two subsections. 10.2.5.1
CE-VLAN ID
There are 4095 CE-VLAN IDs, numbered 1, 2, ..., 4095. The CE-VLAN ID is derived from the content of the service frame as follows: • For a service frame that has an IEEE 802.IQ Tag, and for which the 12bit VLAN ID in the tag is not zero, the CE-VLAN ID is equal to the VLAN ID in the Tag. • Untagged and priority tagged^ service frames have the same CE-VLAN ID, and the CE-VLAN ID value is configurable to any value in the range 1, ...,4094 at each UNI. The special treatment of untagged and priority-tagged service frames is consistent with IEEE 802.1Q [4]. An IEEE 802.1Q-compliant Ethernet switch will treat untagged and priority tagged frames as belonging to a default VLAN, and the default VLAN is configurable on each port of the switch. 10.2.5.2
CE-VLAN ID/EVC Map
The CE-VLAN ID/EVC map associates each EVC at the UNI with one or more CE-VLAN IDs.
Ethernet Services Over Metro Ethernet Networks Service Frame Format
CE-VLAN IP
349 EVC
Untagged Priority Tagged Tagged, VID = 1 Tagged, VID = 2 Tagged, VID = 3
Tagged, VID = 4094 Tagged, VID = 4095
> 4094"^ > 4095
^ Blue
CE-VLAN ID/EVC Map Figure 10-3. Example of a CE-VLAN ID/EVC map
Figure 10-3 shows an example of CE-VLAN ID/EVC map. In this case, CE-VLAN ID 1 is mapped to the blue EVC, CE-VLAN ID 2 is mapped to the red EVC, and CE-VLAN ID 4094 is mapped to the green EVC. A tagged ingress service frame with VLAN ID 2 will be delivered by the MEN according to the properties of the red EVC. An untagged ingress service frame will also be delivered by the MEN according to the properties of the red EVC. A tagged ingress service frame with VLAN ID 1 will be delivered by the MEN according to the properties of the blue EVC. In this example, an ingress service frame with VLAN ID not equal to 1,2, or 4094 will be discarded because the associated CE-VLAN ID is not mapped to an EVC. An egress service frame from the blue EVC will be tagged with VLAN ID 1. An egress service frame from the red EVC could apparently have three formats, namely, tagged with VLAN ID 2, untagged, or priority tagged. If CE-VLAN ID Preservation (see Section 10.3.1) is not in force, the egress service frame is untagged. Section 10.3.1 describes the format when CEVLAN ID preservation is in force.
10.3.
SERVICE FEATURES
The basic constructs of the service model described in Section 10.2 provide a flexible foundation for the definition of a number of services. The details of these various services are determined by the service features that are described in this section.
350
10.3.1
Chapter 10
CE-VLAN ID Preservation
If a subscriber attaches IEEE 802.IQ bridges as CEs to the UNIs in an EVC, it is possible that the subscriber will want to maintain his or her VLAN structure among the sites at the UNIs. In this case, the CE will generate tagged service frames with VLAN IDs that correspond to the subscriber's VLANs. It would be very inconvenient if the MEN changed those VLAN IDs, since the subscriber would be forced to use different VLAN ID values for the same VLAN and coordinate with the service provider in setting those values. To address these issues, the service provider could offer CE-VLAN ID preservation. When an EVC has this feature, the relationships between ingress and egress service frames shown in Table 10-1 are maintained by the MEN. Table 10-L CE-VLAN ID preservation Ingress Service Frame Untagged J
Egress Service Frame Untagged Tagged with VLAN ID equal to that of the Ingress Service Frame
Clearly, CE-VLAN ID preservation is useful in situations like that above. However, as we shall see in Section 10.3.3, there are other scenarios where it is valuable to not have this feature.
10.3.2
AU-to-One Bundling Map
For many subscribers, all that is required is a single service per UNI needing minimal configuration of the CE. This has been the typical configuration for the Transparent LAN services that have been offered by service providers since the early 1990s. The All-to-One Bundling Map is the way to achieve this scenario. With the All-to-One Bundling Map, the CE-VLAN ID/EVC map is configured such that all CE-VLAN IDs map to a single EVC at the UNI. In addition, the EVC must have the CE-VLAN ID preservation feature enabled. Since all CE-VLAN IDs are mapped to a single EVC, it follows that there can only be one EVC at the UNI. Figure 10-4 shows an example of an All-to-One Bundling Map. As can be seen in the figure, any ingress service, no matter what the format, is mapped to the red EVC. In addition, CE-VLAN ID preservation means that the format and VLAN ID, if tagged, will not be changed by the MEN. Note that there is no need for the subscriber and service provider to coordinate the use of the VLAN ID values in tagged service frames.^
Ethernet Services Over Metro Ethernet Networks
Untagged Priority Tagged Tagged, VID = 1 Tagged, VJD = 2
Tagged, VID = 4094 Tagged, VID = 4095
351
CE-VLAN IP
-4095 CE-VLAN ID/EVC Map
Figure 10-4. Example of All-to-One Bundling Map
The high degree of transparency with the All-to-One Bundling Map makes the resulting service much like a dedicated private Ethernet. When the EVC is Point-to-Point, the result is easily substituted for an existing private line such as a DS3. When the EVC is multipoint-to-multipoint, the result is much like the classical Transparent LAN service. Figure 10-5 illustrates an example of how these two configurations could be used by an enterprise to connect headquarters to the branches and to connect headquarters to a disaster recovery service provider. The multipointto-multipoint EVC service can be thought of as a backbone LAN connecting the sites of an enterprise and is frequently called LAN Extension. Disaster Recovery Service Provider
Branch
Branch Bridge or Router
Private Line Replacement
Figure J 0-5. Examples of the use of All-to-One Bundling
LAN Extension
352
Chapter 10
103.3 Service Multiplexing In the example of Figure 10-5, a separate port on the CE is required for each EVC at the headquarters. In many cases, this setup is acceptable and even desirable. But when many EVCs need to be accessed at a given location, consuming a port on the CE for each can both be costly in equipment and yield complex physical arrangements. The way to avoid these disadvantages is to enable multiple EVCs on a UNI. Service multiplexing is the term used to describe the case where multiple EVCs can be made available at a UNI. The two approaches to service Multiplexing are described in the following subsections. 10.3.3.1
One-to-One Map
When the CE-VLAN ID/EVC map is such that at most one CE-VLAN ID is mapped to an EVC, it is called a One-to-One Map."^ Untagged Priority Tagged Tagged, VID = 1 Tagged, VID = 2 Tagged, VID = 3
Tagged, VID = 4094 Tagged, VID = 4095
• 4095 CE-VLAN ID/EVC Map
Figure 10-6. Example of a One-to-One Map
Figure 10-6 shows an example of a One-to-One Map. At this UNI, only ingress tagged service frames with VLAN ID 3 and 4094 will be delivered to the destination UNI(s). Egress service frames at this UNI will be tagged with only VLAN ID values 3 and 4094. When the EVCs are point-to-point, the resulting service is analogous to the Frame Relay. Figure 10-7 shows an example of the use of point-to-point maps that illustrates this analogy. The ISP router is able to use a single port, e.g., Gigabit Ethernet, to reach several ISP customers with a point-to-point EVC to each. The CE-VLAN ID/EVC map for each UNI is shown in the figure, and it can be seen that the CE-VLAN ID is different at each UNI in an EVC. In particular, each ISP customer uses CE-VLAN ID 2000 to identify the EVC to the ISP, while the CE-VLAN IDs used at the ISP UNI are 178, 179, and 180. In this case, not using CE-VLAN ID preservation is
Ethernet Services Over Metro Ethernet Networks
353
valuable. It makes it simple for the ISP customers to configure their routers by using a well-known VLAN ID value (2000) and still makes it possible for the ISP router to identify the EVC for each ISP customer. This setup is analogous to the Frame Relay where the DLCI that identifies the Permanent Virtual Connection (PVC) can be different at each UNI. Internet Service Provider 178 ^ E V C ^ 179^EVC2 180EVC 2000 ^ EVC^ ISP Customer 3 2000 / V'
10.3.5 E-Line and E-LAN Service The MEF in [2] has defined two general service types, namely, Ethernet Line service (E-Line) and Ethernet LAN service (E-LAN). An E-Line service is any service based on a point-to-point EVC, while an E-LAN service is any service based on a multipoint-to-multipoint EVC. Table 10-3 shows how ELine and E-LAN relate to the service features described so far and how the various combinations can be used. Table 10-3. E-Line and E-LAN service types CE-VLANID/EVC Map EVC Type Characteristic Point-to-Point Mii!tipoint4o-MiiMpoint All-to-One Private Line Replacement LAN Extension One-to-One Frame Relay Replacement Redtindant access to semces Bundling VLAN Extension VLAM Extension E-Line E-LAN
10.3.6 Class of Service In the last few years, data networks based on IP have become a platform for both classical data applications such as email and also real-time applications such as Voice over IP. The integration of real-time applications has generated a requirement that data networks be able to differentiate packets from different applications and provide differentiated performance according to the needs of each application. In MEF Ethernet services, this differentiation is referred to as Class of Service. The following subsections describe the method of identifying different instances of Class of Service and the different performance for each class. 10.3.6.1
Identifying Class of Service
A service provider is likely to offer several Classes of Service. For example, three classes might be offered: • One intended for non-time-critical data such as electronic mail, • One intended for time-critical data such as nuclear reactor sensor data, and
Ethernet Services Over Metro Ethernet Networks
357
•
One intended for real-time applications such as Voice over IP. However, the number of instances of Classes of Service for a given subscriber could be much larger. For example, pricing considerations might cause a service provider to charge differently for a given Class of Service between different end points. New York to Boston may well be priced less than New York to London. To accommodate this flexibility, MEF services allow identification of a Class of Service instance for a service frame by either the EVC or by the combination of the EVC and the userjpriority field in tagged service frames. In the latter case, a set of user__priority field values can identify the Class of Service instance. The EVC or combination of EVC and set of user_priority field values is called a Class of Service Identifier. As an example, consider the CE-VLAN ID/EVC map shown in Figure 10-6 and suppose that the red EVC has just the Standard Class of Service while the blue EVC has both the Standard and the Premium Classes of Service. Then the Class of Service for tagged service frames could be as shown in Table 10-4. Table 10-4. Example of Identifying Class of Service CE VLAN ID userpriority 3 0,1,...,7 4094 0,1,2,3 4094 4, 5, 6, 7
10.3.6.2
Class of Service Standard Standard Premium
Performance Parameters
The point of having different Classes of Service is to provide different performance to service frames according to each frame's Class of Service. The MEF [1] specifies three types of performance parameter: • Frame Delay: The length of time it takes a service frame to go from the ingress UNI to the egress UNI. • Frame Delay Variation: The variation in frame delay for service frames with the same Class of Service instance. • Frame Loss: The success or failure of delivery of a service frame to the egress UNI. The precise definitions of these parameters for a point-to-point EVC are contained in [1]. Performance for a multipoint-to-multipoint EVC will be addressed by the MEF in the future. The MEF is not planning on specifying values for these parameters that service providers should meet. Rather, by standardizing the definition of the parameters, they can be used as a basis for service-level specifications that will allow a subscriber to compare service offerings and negotiate a meaningful service level agreement with a service provider.
Chapter 10
358
10.3.6.2.1 Frame Delay Performance Objective for a Point-to-Point EVC The frame delay for a service frame is defined as the time elapsed from reception at the ingress UNI of the first bit of the ingress service frame until the transmission of the last bit of the service frame at the egress UNI. Figure 10-11 illustrates this definition. Of course, this definition is only meaningful for a service frame that is delivered.
Service Frame Direction
Time
First bit in
Last bit out
Figure 10-11. Frame delay for a service frame The frame delay performance Objective is defined by the three parameters in Table 10-5. A point-to-point EVC meets the frame delay performance Objective for the interval T if at least P percent of the service frames that arrive at an ingress UNI during the interval that have a green bandwidth profile compliance level (see section 10.3.7) and that are delivered, have delay less than or equal to d. Table 10-5. Parameter T P _d_
Parameters used to define frame delay performance objective Description Time interval during which service frames arrive at an ingress UNI (time units) Percentage Delay objective (time units)
Ethernet Services Over Metro Ethernet Networks
359
10.3.6.2.2 Frame Delay Variation Performance Objective for a Point-toPoint EVC Frame delay variation is defined for pairs of delivered service frames as the delay of the first service frame minus the delay of the second service frame. The Frame delay variation performance objective is defined by the four parameters in Table 10-6. A point-to-point EVC meets the frame delay variation performance objective for the interval T if at least P percent of the pairs of service frames that arrive at an ingress UNI during the interval, that have a green bandwidth profile compliance level (see 10.3.7), that arrive / time units apart, and that are delivered, have a frame delay variation of less than or equal to v. Table 10-6. Parameter T P / _v;
Parameters used to define frame delay variation performance objective Description Time interval during which service frames arrive at an ingress UNI (time units) Percentage Time between arrival of two service frames at an ingress UNI (time units) Delay variation objective (time units)
10.3.6.2.3 Frame Loss Performance Objective for a Point-to-Point EVC A service frame is defined as lost if it should have been delivered but was not.^ The frame loss performance objective is defined by the two parameters in Table 10-7. A point-to-point EVC meets the frame loss performance objective for the interval T if no more than L percent of the service frames that arrive at an ingress UNI during the interval and that have a green bandwidth profile compliance level (see 10.3.7) are lost. Table 10-7. Parameter T J^
Parameters used to define frame loss performance objective Description Time interval during which Servicefi-amesarrive at an ingress UNI (time units) Loss objective (percentage)
10.3.7 Bandwidth Profiles Most UNIs will have a line rate of at least 100 Mbps. Yet many subscribers will not need and will not want to pay for that much bandwidth. The vehicle for letting subscribers pay for the bandwidth they need is the bandwidth profile.
Chapter 10
360
The bandwidth profile is a characterization of the lengths and arrival times for ingress service frames at a UNI. When a bandwidth profile is applied to a sequence of service frames, each service frame is classified according to its level of compliance with the bandwidth profile. The bandwidth profile also includes how the MEN should treat a service frame depending on its level of compliance. 10.3.7.1 Parameters and Algorithm The bandwidth profile is the Ethernet version of the Frame Relay committed information rate or the ATM sustained cell rate. It defines longterm average bandwidths as well as limits on the amount of data in back-toback service frames. Reference [1] defines the service frame size and arrival time characterization with six parameters: 1. Committed Information Rate (CIR): a nonnegative number expressed as bits per second. 2. Committed Burst Size (CBS): a nonnegative number expressed as bytes. When CIR > 0, CBS must be at least as large as the maximum length of a service frame. 3. Excess Information Rate (EIR): a nonnegative number expressed as bits per second. 4. Excess Burst Size (EBS): a nonnegative number expressed as bytes. When EIR > 0, EBS must be at least as large as the maximum length of a service frame. 5. Coupling Flag (CF): a binary variable with value either 0 or 1. 6. Color Mode (CM): a binary variable with value either "color blind" or "color aware." The description of the level of compliance determination is via two token bucket algorithms, as shown in Figure 10-12. Committed Information Rate Tokens Overflow Commrttecl Burst Size
Excess ^ Information ^ Rate Tokens Overflow
Excess Burst Size C-Bucket
E-Bucket
Figure 10-12. Graphical depiction of bandwidth profile
Ethernet Services Over Metro Ethernet Networks
361
Each bucket holds up to CBS and EBS tokens, respectively, with one token representing one byte. Tokens are added to each bucket at the rate of CIR/8 and EIR/8 respectively. When the bucket becomes full, additional tokens overflow and are lost. Since each token is a sort of permission to the CE to send one byte of data, this loss of a token is a "use it or lose it" mechanism for bandwidth use. When an ingress service frame is classified, its length is compared with the tokens in the C-bucket. If the number of tokens is at least equal to the length of the service frame, the frame is declared "green," and tokens equal to the frame length are removed from the bucket. If there are not sufficient tokens in the C-bucket, the service frame length is compared with the tokens in the E-bucket and the process is repeated. If there are sufficient tokens in the E-bucket, the frame is declared "yellow"; otherwise, it is declared "red." The precise algorithm is shown in Figure 10-13. Here the Service frames have lengths {/,}, and arrival times {/,} fory = 0, 1, .... The number of tokens in each token bucket is denoted by Bc(tj) and Be(tj), respectively. Finally, Bc(to) = CBS and Be(to) = EBS. When CF = 1, it is possible that unused tokens from the C-bucket can be put into the E-bucket. This could happen if EIR is smaller than CIR and a long burst of service frames is followed by a period of no traffic. At the end of the burst, both token buckets would be essentially empty. During the quiet period, the C-bucket could completely fill before the E-bucket, resulting in the "overflow" tokens (represented by 0{tj) in Figure 10-13) being placed in the E-bucket. When CF = 0, the two token buckets operate independently. Service Frame of length Ij arrives at tj
B/tj) = min{CBS, B/tj_j)+CIRx(tf-tj_j)/8} 0(tj) = max[0, B/tj_j)+CIRx(tj-tfJ/8-CBS\ B/tj) = mm{EBS, B/tjJ+EIRxftj-tjJ/S+CFxOdj)} JilL.
Ij^B/tj)
I
Ij^B/tj) Yes
Yes Declare frame green B/tj)=^B/tj)^lj
No Declare frame red
Declare frame yellow B/tj)-B/tj)^lj
Figure 10-13. Bandwidth profile algorithm
362
Chapter 10
The algorithm defined in Figure 10-13 is referred to as color blind because it does not take into account a color that might be associated with each service frame as it crosses the UNI. Reference [1] also specifies a color aware version of the algorithm, and this is where the Color Mode parameter is used. This is done in anticipation of the specification of a standard way to indicate the color in a service frame at the UNI. Such a standard does not yet exist. 10.3.7.2
Disposition of Service Frames
The classification of each service frame governs how the MEN will handle the frame. Reference [1] specifies the following MEN actions: 1. Green: Deliver the service frame according to the service attributes of the service instance and the service level specification performance objectives (see Section 10.3.6.2). 2. Yellow: Deliver the service frame according to the service attributes of the service instance, but service level specification performance objectives do not apply. 3. Red: Discard the service frame. An example will help to understand the implications of the above points. Consider an enterprise connecting two locations together with a point-topoint EVC using an All-to-One Map at both UNIs, and further suppose that both UNIs are 100 Mbps. The enterprise has determined that the average bandwidth needed is 20 Mbps and that less than 0.1% service frame loss is needed for adequate performance. In this case, the parameter values shown in Table 10-8 could be used along with an SLA that guarantees less than 0.1% service frame loss. CIR is set equal to 20 Mbps and CBS is large enough to handle more than seven maximum-sized service frames. Given the bandwidth needs of the enterprise, most of the Service frames will be declared green and should have less than .1% service frame loss. Table 10-8. Example bandwidth profile parameter values Parameter Value CIR 20 Megabits/sec CBS 15,000 bytes EIR 20 Megabits/sec EBS 6,000 bytes CF 0
Ethernet Services Over Metro Ethernet Networks 10.3.7.3
363
Application of Bandwidth Profiles
There are three ways that a bandwidth profile can be appUed to ingress service frames. These are described in the following subsections. 10.3.7.3.1 Per Ingress UNI In this case, a single bandwidth profile applies to all ingress service frames at the UNI. Figure 10-14 illustrates this approach. A single bandwidth profile is applied to all service frames irrespective of the EVC or Class of Service identifier.
n> EVCi
UNi
/( CE-VLAN Cos 0,1,2.3 (
CE-VLANCOS4.5
\{
CE'VLAN Cos 6 J
Bandwidth Profile
EVCo
Figure 10-14, Example of bandwidth profile per ingress UNI
10.3.7.3.2 Per EVC In this case, a single bandwidth profile applies to all ingress service frames on a given EVC. Figure 10-15 shows two bandwidth profiles, one for each of the two EVCs.
364
Chapter 10 f'\'^'M'-^P^/
D EVC,
um 1I ,1 EVC^
IJ
%$itB-^
1
E-VLAN Cos 0.1^.3 CE«VLAN Cos 4,5 CE-VUANC0S6J
\
3) 1
! Bandwidth Profile 1
i
1 Banciwicith Profile 2
[]
i
Figure 10-15. Example of bandwidth profile per EVC
10.3.7.3.3 Per Class of Service Identifier The most granular application of bandwidth profiles is per Class of Service Identifier. This apphcation is illustrated in Figure 10-16.
CE^VLAN Cos 0.1.211) CE-VLAN Cos 4.5 (
CE-VLANCOS6.7
T Bandwidth Profile 1 f Bandwidth Profile 2 " y Bandwidth Profile 3
Bandwidth Profile 4
Figure 10-16. Example of bandwidth profile per Class of Service ID
10.3.7.3.4 Constraints on Bandwidth Profiles As we will see in Section 10.3.7.4, when a bandwidth profile is used, it is important to configure the CE to smooth the traffic in a way that complements the bandwidth profile. Most routers have the capability to do this for a single bandwidth profile. However, few routers can smooth to complement the case when multiple bandwidth profiles are applied. Therefore, to be consistent with existing CEs and to simplify implementations, the application of bandwidth profiles is constrained. At most one bandwidth profile can be applied to an ingress service frame.
Ethernet Services Over Metro Ethernet Networks
365
This constraint on the application of bandwidth profiles leads to the following rules at a UNI: 1. If there is a per-UNI bandwidth profile, then there cannot be any other bandwidth profiles. 2. If there is a per EVC bandwidth profile on an EVC, then there cannot be any per CoS bandwidth profiles for instances of Class of Service on the EVC. Figure 10-14, Figure 10-15, and Figure 10-16 show examples of bandwidth profiles that are applied according to these rules. 103.7.4
Configuring CE
It has been well known since the rise in popularity of Frame Relay that the use of a bandwidth profile type of bandwidth constraint can lead to excessive frame loss and poor performance for an application using the service. For example, consider a host in an enterprise network well removed from the UNI that is carrying out a file transfer. The source host can send a TCP window of packets back-to-back. When the corresponding frames reach the UNI, if they cause the token bucket to exhaust, service frames will be discarded. The resulting lost packets will be detected by TCP in the host and retransmitted. However, TCP also slows down when loss is detected and the net result is throughput degradation. There are two ways to suppress this behavior. The first is to make CBS large. The second is to implement smoothing in the CE at the UNI. Smoothing buffers a service frame that would be declared yellow or red until tokens have accumulated to allow the service frame to be declared green. Such smoothing has been common in routers since the early days of Frame Relay. It is important to properly configure the smoothing in the CE to align with the bandwidth profile parameters so as to allow the most effective use of an Ethernet service.
10.3.8 Layer 2 Control Protocols A significant number of protocols have been standardized for use by bridges within an enterprise network. These are referred to as Layer 2 control protocols. When a CE is a bridge, it is likely to generate some of these protocols. It is important to know how the Ethernet service handles a service frame that is carrying a Layer 2 control protocol. As an example, consider the configuration of Figure 10-17.
366
Chapter 10
Bridge |
Bridge^
MBridge
Figure 10-17. Example of the need for Spanning Tree Protocol tunneling
In Figure 10-17, a loop is formed by the three EVCs, and there is a danger that a broadcast frame sent into an EVC on one of the UNIs would circulate forever, with dire consequences for the subscriber. To prevent this behavior, the subscriber would typically configure the bridges to run the Spanning Tree Protocol. This protocol would block some of the ports on the bridges to break the loop. But what happens in the case of Figure 10-17? If the service frames carrying the Spanning Tree Protocol are discarded by the MEN, each bridge will conclude that the ports attached to the MEN are not attached to other bridges and all ports would be in forwarding state creating a loop. On the other hand, if the Service frames carrying Spanning Tree Protocol are delivered from one UNI to the other, the bridges would break the loop by blocking the appropriate ports. 10.3.8.1
Handling Layer 2 Control Protocols
There are three ways that an MEN can deal with a Layer 2 control protocol: 1. Discard services frames carrying the protocol, 2. Participate as a peer of the CE, or 3. Deliver unchanged (called tunneling) to appropriate UNIs. When there is more than one EVC at a UNI, tunneling becomes complicated by the question of which EVC to use to carry the tunneled service frames. A recommendation on how to handle various Layer 2 control protocols can be found in [2].
Ethernet Services Over Metro Ethernet Networks 10.3.8.2
367
Bridges versus Routers as CE
When bridges are used as the CEs, it is important to tunnel most of the Layer 2 control protocols. In view of the complexity of tunneling when multiple EVCs are at a UNI, it is the author's recommendation that AU-toOne Bundling be used at all UNIs when bridges are used as CEs. In this case, protocols such as Spanning Tree should be tunneled When it is desirable to have multiple EVCs at a UNI, it is the author's recommendation that routers be used as CEs and Layer 2 control protocols be discarded by the MEN. There are many configurations that will work well and are not consistent with the above recommendations. However, for most uses of Ethernet services, the above recommendations provide easy-to-understand guidelines and will enable the subscriber to realize the full value of Ethernet services.
10.4.
CONCLUSION AND FUTURE WORK
The services specified in [1] establish a solid foundation upon which valuable Ethernet services can be deployed by service providers and used by subscribers. Such services are currently being offered and planned in all parts of the world. However, the MEF realizes that this is just the starting point (which explains the use of "Phase 1" in the title of [1]). Consequently the MEF has embarked on "Phase 2" services. As of this writing, the scope of Phase 2 has not been finalized, but it is likely to include: • Definition of performance parameters for multipoint-to-multipoint EVCs, • Specification of a point-to-multipoint EVC, which can be useful for supporting Internet access for a large number of small customers, • Additional ways to identify CoS, such as by a set of CE-VLAN IDs, and the IP DSCP field, • Egress bandwidth profiles, and • Alignment with the emerging IEEE 802.lad, Provider Bridges standard.
10.5. APPENDIX A: ETHERNET BASICS This Appendix provides a quick tutorial on the basics of Ethernet. Ethernet emerged as a way for multiple computers to connect to a single cable segment (called a shared medium) and to exchange information amongst themselves at high speeds, e.g., 10 Mbps. The protocol that each computer had to execute is referred to as CSMA/CD and can be thought of as
Chapter 10
368
being modeled on a meeting of polite, extroverted, fast talkers. Any computer can send but refrains from doing so if energy is detected on the cable (Carrier Sense Multiple Access). If two computers happen to start sending at the same time, each detects the collision and stops sending for a random period of time (Collision Detection). Each computer receives all frames transmitted and discards them if the destination MAC address in the frame does not match the computer's MAC address and is not a broadcast/multicast address. Of course, Ethernet networking has evolved greatly since these early days. Today, the vast majority of Ethernet networks are composed of computers and routers attached directly to Ethernet bridges (also known as switches). The links are usually full duplex so both the devices on the link can transmit and receive simultaneously. The bridges forward the Ethernet frames to the proper destination(s). From the point of view of Ethernet services, then, the CE connects to the UNI via a point-to-point cable and exchanges Ethernet frames with the service provider network. In the following, we dig a bit deeper into Ethernet as seen by the CE.
10.5.1 Ethernet Physical Layers There are a large number of Ethernet physical layers defined in [3]. Several have fallen into disuse in the market. Others are unlikely to be supported at the UNI by service providers. Table 10-9 summarizes the physical layers that are most likely to be supported at the UNI.^ Table 10-9. Physical layers likely to be used at the UNI Name Media Type Speed lOBASE-T 2 pair Category 3 UTP 10 Mbps lOBASE-FL 62.5 ^m MMF 10 Mbps 100BASE-TX 2 pair Category 5 UTP 100 Mbps lOOOBASE-T 4 pair Category 5 UTP 1000 Mbps lOOOBASE-SX 50 and 62.5 |iim MMF 1000 Mbps lOOOBASE-LX 50 and 62.5 |Lim MMF 1000 Mbps lOOOBASE-LX lO^mSMF 1000 Mbps
Maximum Length 100 meters 2km 100 meters 25 meters 220 - 550 meters 550 meters 5km
UTP — Unshielded Twisted Pair; MMF — Multimode Fiber; SMF — Single-Mode Fiber
10.5.2 Ethernet Media Access Control Layer The frame format for Ethernet is part of the media access control layer because it contains the information that is needed for the operation of CSMA/CD. Figure 10-18 shows the format.
Ethernet Services Over Metro Ethernet Networks
b^
b^
7 octets 1 octet 6 octets 6 octets 2 octets 46-1500 octets 4 octets
b^
b^ b^ b^ Preamble Start Frame Delimiter Destination MAC Address Source MAC Address Length/Type
369
b^
Data and Pad Frame Check Sequence
Figure 10-18. Ethernet media access control frame format
The bits of each octet are transmitted left to right (least significant to most significant) and the octets are transmitted top to bottom. Each field is briefly described below. 10.5.2.1
Preamble Field
This field allows a receiver to synchronize a receive clock. This synchronization is necessary in a shared media network where there can be periods with no transmissions and multiple transmit clocks, one for each other device on the LAN. 10.5.2.2
Start Frame Delimiter Field
This special bit pattern allows the receiver to find the start of the frame. 10.5.2.3
Destination Address Field
This field specifies the destination device or devices. The first bit indicates whether the address is an individual address or a group (multicast) address. The second bit indicates whether the address is globally or locally administered. Globally administered addresses are allocated to manufacturers and are usually "burned into" devices during manufacturing. The all ones address indicates a broadcast to all devices on the LAN. 10.5.2.4
Source Address Field
This field identifies the source of the frame.
370 10.5.2.5
Chapter 10 Length/Type Field
Depending on the value, this field can either indicate the number of data octets or the type of protocol running above the MAC layer. Today, most implementations use this field for protocol identification. 10.5.2.6
Data and PAD Field
This field contains the data that is being carried. If there are less than 46 octets of data, PAD bits are added to extend the field to be 46 octets. 10.5.2.7
Frame Check Sequence Field
This field is a CRC calculation that covers from the beginning of the Destination Address field through the end of the Data and PAD field. It is used to detect transmission errors.
10.5.3 Ethernet VLANs IEEE 802. IQ [4] added two new concepts to Ethernet, namely the virtual LAN and priority. The virtual VLAN concept allows an Ethernet to be logically divided into multiple LANs. For example, a large LAN or complex of LANs bridged together can be divided up into multiple (smaller) VLANs and a separate IP subnet assigned to each. In this case, from the point of view of a router, each VLAN operates just like a separate physical LAN. A broadcast frame sent on a given VLAN will only be propagated to and received by the devices assigned the VLAN. In addition, [4] defines up to eight levels of priority. Bridges compliant with IEEE 802. IQ can buffer and forward frames according to the different levels of priority. Figure 10-19 shows the Ethernet MAC frame format with the IEEE 802.IQ Tag Control Information. Four octets are inserted between the Source Address field and the Data field. The 802.IQ TagType field indicates that the Tag Control Information field follows, as opposed to the Data field.
Ethernet Services Over Metro Ethernet Networks
b^
b^ b^ b^ Preamble Start Frame Delimiter Destination MAC Address Source MAC Address 802.1QTagType Tag Control Information Length/Type
7 octets 1 octet 6 octets 6 octets 2 octets 2 octets 2 octets
46-1500
371
b^
Data and Pad
octets 4 octets
Frame Check Sequence
Figure 10-19. Ethernet media access control frame with tag control information
Figure 10-20 shows the details of the 802.IQ TagType field and Tag Control Information field. The 802. IQ TagType field always has the value 8100 Hex. The VLAN Identifier has 12 bits. The value 0 has a special meaning. It does not identify a VLAN but is used as a way to assign a priority to the frame. When the value is 0, the frame is called a priority tagged frame. The value FFF Hex (all ones) is reserved. Thus 4094 VLANs can be identified. The user_priority field contains the priority of the frame and has eight possible values. The Canonical Format Indicator (CFI) field is intended for use with Token Ring networks.
2 octets
1 0
2 octets
b^ 0 0 0 0 VLAN
b' 0 0
0 0 0 11 0 0 0 01 1 CFI 1 user priority Identifier (12 bits)
Figure 10-20. Tag type and tag control information
10.6.
NOTES
1. The reader may have heard about "double tagged" Ethernet frames in Metro Ethernet Networks. Such double tagging is frequently used internally in MENs. But double tagging is not standard and thus is not to be done at a UNI. 2. An Ethernet frame with an IEEE 802.IQ tag that has zero as the VLAN ID is called priority tagged.
372
Chapter 10
3. [4] specifies that the VLAN ID value 4095 is reserved, and thus an IEEE 802. IQcompHant CE should not generate a tagged service frame with this VLAN ID value. However, there seems to be no advantage in the service provider enforcing this constraint, and thus 4095 is allowed. Note, however, that the only mandate for the service provider to deliver such service frames is when CE-VLAN ID preservation is in force. 5. The One-to-One terminology is not used in [1], but it is a typical and important case for the CE-VLAN ID/EVC map. 6. Not all ingress service frames should be delivered. For example, ingress Pause frames should probably not be delivered. See Section 10.3.8. 7. 10 Gbps Ethemet standards exist, but we don't expect them to be supported at the UNI in the near term.
10.7.
REFERENCES
[1] Metro Ethemet Forum, Technical Specification MEF 10, Ethernet Services Attributes, Phase 1, 10 November 2003, http://www.metroethemetforum.org. [2] Metro Ethemet Forum, Technical Specification MEF 6, Ethernet Services Definitions Phase I, June 2004, http://www.metroethemetforum.org. [3] IEEE Project 802.3 — 2002, Information technology — Telecommunications and information exchange between systems —Local and metropolitan area networh Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, 8 March 2002. [4] IEEE Project 802. IQ — 1998, IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks, 8 December 1998.
Chapter 11 ETHERNET SERVICES OVER PUBLIC WAN
*Steven S. Gorshe, Ph.D and **Nevin R. Jones, Ph.D * PMC-Sierra, Inc., **Agere Systems, Inc.
11.1.
INTRODUCTION
11.1.1 Why Ethernet over the public WAN? A convergence of technology and applications has created an increased desire for Ethernet WAN connectivity. On the enterprise side, Ethernet is the dominant technology. Enterprise network administrators' familiarity and comfort with Ethernet creates a natural desire that their WAN technology also be based on Ethernet. A number of applications, including voice and video, are already being encapsulated into Ethernet and rim over their LANs. Another trend is for companies to have a number of remote offices that need to exchange data with the headquarters office or with each other. There can be significant advantages to placing data on common servers that can be accessed by all sites. The increased importance of the Internet for business applications has created an increasing desire for incrementally higher WAN interface rates. It is also common to want a single Internet firewall at one site that is accessed on the enterprise network by all sites. Most enterprise WAN data access today uses Frame Relay connections at rates of fractional DSl, full-rate DSl, fractional DS3, and full-rate DS3. In some cases, the data services use ATM instead of Frame Relay either for the customer connection or as a method of transporting the data through the core network. The Frame Relay-based services suffer from a lack of scalability in
374
Chapter 11
terms of both high-speed connections and ubiquitous multipoint networks. ATM suffers from being somewhat provisioning-intensive in large networks and bandwidth inefficiency. At the other end of the spectrum, some customers use WDM or dark fiber for their WAN or MAN connections with native Gigabit Ethernet, 10 Gbit Ethernet, or Fibre Channel. However, WDM equipment is expensive and not ubiquitously deployed, and dark fiber is not universally available, which limits the applications for these approaches. Another drawback of WDM and dark fiber applications is that unless they use the new G.709 [1] Optical Transport Network standard, there is no embedded overhead for the carrier to monitor the quality of the connection or to provide protection switching in order to guarantee their service level agreements (SLAs). Some larger customers use high-speed SONET OC-N / SDH STM-N connections that have typically terminated the Ethernet frames and re-encapsulated the data into PPP and use Packet over SONET/SDH (PoS) for transmission through the SONET/SDH pipe. On the carrier (network operator) side, the situation is somewhat complicated. In the wake of the bursting of the telecom "bubble" in the year 2000, the carriers face two clear drivers. First, they must deploy any new services on their existing SONET/SDH networks. Throughout the 1990s, carriers invested heavily in building SONET/SDH-based fiber optic networks, including developing the OAM&P systems to run them. The enormous capital investment required to build an overlay network for data transport, be it native Ethernet or DWDM based, makes overlay networks unrealistic. Fortunately, SONET/SDH has proven flexible enough to handle the challenge. As discussed in earlier chapters, recent developments that extend the useful life of SONET/SDH include virtual concatenation (VCAT) [2, 3] to create more flexible data channel sizes, Link Capacity Adjustment Scheme (LCAS) [4] to increase the flexibility and functionality of VCAT, Generic Framing Procedure (GFP) [5, 6] to encapsulate data frames for robust and bandwidth-deterministic transport, and the Resilient Packet Ring (RPR) that provides a very flexible technology for data access onto SONET/SDH access and metro rings. The second driver for the carriers is the desire to generate new, revenuebearing services. With data traffic continuing to grow faster than voice, offering WAN connectivity with higher bandwidth and enhanced service capabilities appears to be a natural direction for new services. Equipment and device manufacturers, who are also interested in building new products, have also seen WAN connectivity as a natural direction. Ethernet is in many ways an obvious technology choice for WAN connectivity. The job of enterprise network administration is simplified if all their sites can be treated as part of the same Ethernet network. Also, Ethernet interfaces are relatively inexpensive and are ubiquitous on
Ethernet Services Over Public WAN
31S
enterprise equipment. The development of VCAT and GFP allow efficient transport of Ethernet frames through SONET/SDH networks. Also, Ethernet bridge and router technology requires less provisioning and administration than technologies such as ATM. As some carriers begin a migration to using packet switching technology such as MPLS in their core networks rather than traditional circuit switching, Ethernet again looks like an excellent fit as an access technology. The relatively low cost of Ethernet enterprise equipment, however, has created a customer expectation that Ethernet WAN interfaces should be less expensive than DS1/DS3 Frame Relay interfaces. For the carriers, even if the Ethernet connectivity is provided through their SONET/SDH backbone network, they still have to develop new OAM&P procedures and tools to provide the service. In fact, although it is being actively addressed by multiple standards bodies, Ethernet currently lacks some of the OAM capabilities that will be required to monitor and guarantee the SLAs. So, even though customers and carriers agree that Ethernet (over SONET/SDH for the carriers) is the most attractive technology for highspeed WAN connectivity, carriers will still have to invest in equipment and management system upgrades while the customers demand and expect to pay less for the Ethernet-based services.
11.1.2 Organization of the chapter The information in this chapter primarily focuses on the output of the Ethernet transport work in ITU-T Study Group 15 (SGI5) and its series of new standards. SGI5 is the ITU-T body responsible, among other things, for standards related to public transport networks. Ethernet services in metro networks are the topic of Chapter 10. The status of standards that are currently approved or are in progress is summarized in Section 11.1.3. The chapter begins with a discussion and description of the Ethernet services that are being considered over public WANs. This description includes an examination of the different service characteristics and attributes that must be defined in order to provide the services. The next section explores different transport network models that can be used to support Ethernet services. Next comes a description of the Ethernet-based user network interfaces (UNIs) followed by a discussion of the network-tonetwork interface (NNI) that will be required for transport network equipment carrying Ethernet services. OAM is the topic of the following section. As already noted, some amount of OAM capability comes inherently from deploying Ethernet services over SONET/SDH (server) networks. Additional OAM capabilities will be required at the Ethernet client layer. The final section summarizes some of the protection and
376
Chapter 11
restoration technologies that can be used to guarantee carrier-grade service rehabihty for Ethernet WAN services. Table 11-1. Summar>f of related standards activities
Organization IEEE
Activities
Status
802.3ae
10 Gbit Ethernet, which included a WAN PHY interface to simplify interfacing to a SONET/SDH or G.709 OTN network Resilient Packet Rings: Working on a ring-based network for access and metro applications Ethernet in the First Mile, where work includes 0AM aspects for Ethernet Links, especially access links Provider Bridge specification - This is the Q-in-Q standard.
Approved
802.17 802.3ah (EFM) 802.1 ad
802. lag 802. lae ITU-T SG15 G.8011.1 (Q12) G.8012 (Qll) G.8010 (Q12)
1
Connectivity Fault Management, or Ethernet Service OAM MAC Security (MacSec), including authentication, authorization, and encryption (With input from ANSI TlXl) Ethernet Private line service
Approved Approved In progress
In progress In progress | Approved
Ethernet UNI and Ethernet Transport NNI
Approved Approved
G.8021[7] (Q9)
Ethernet Layer Network Architecture, which is largely to translate the IEEE 802 network material into ITU-T transport network terminology and models Ethernet over Transport — Ethemet Service Characteristics Ethemet over Transport—Ethemet Service Multiplexing, which will cover the multiplexing protocol(s) required to implement EVPL and EVPLAN Characteristics of Ethemet transport network equipment functional blocks
Q2
Studying Ethemet OAM aspects relating to access
G.8011 (012) G.esm (Q12)
Approved In progress
Approved 2004 (focus onEPL portion) In progress
1 ITU-T SG13 Y.1730 Y.ethoam (Q3) Y.ethps |(Q3)
Requirements for OAM functions in Ethemet-based networks and Ethemet services End-to-end and edge-to-edge aspects of Ethemet OAM including PM Ethemet protection switching
Approved In progress In progress
Ethernet Services Over Public WAN Table 11-1 - continued Metro Ethernet Forum (MEF) MEF is studying various aspects of Ethernet MANs, including Ethernet architecture, service model, service definition, traffic management, UNI and NNI definition, and 0AM. MEF work is covering all possible OAM flows, such as end-to-end, edge-toedge, access, interprovider, intraprovider, etc. MEFl Ethernet Services Model, Phase 1 MEF2 Requirements and Framework for Ethernet Service Protection in Metro Ethernet Networks MEF3 Circuit Emulation Service Definitions, Framework and Requirements in Metro Ethernet Networks MEF4 Metro Ethernet Network Architecture Framework — Part 1: Generic Framework MEF5 ^ • Traffic Management Specification: Phase I UNI Type 1 Specification of UNI, data-plane aspects UNI Type 2 Specification of UNI, control-plane aspects (ELMI) EMS-NMS MIBS for Ethernet and network management MEF Specifies functional elements of Ethernet trail, such Architecture, part as adaptation, conditioning, etc. 2 CESPDH Implementation agreement of PDH CES over Ethemet. Includes both AALl and Raw method Internet Engineering Task Force (IETF) Working on defining an Ethemet transport over PWE3 WG IP/MPLS using Martini drafts. This is mainly EVPL service using UDP, L2TP, or MPLS as multiplexing layer Requirements for Virtual Private LAN Services PPVPNWG (VPLS) Working on framework and service requirements of L2VPNWG Ethernet-based VPN, and defining EVPLAN service using IP/MPLS.
111
Approved Approved Approved Approved Approved In progress In progress In progress In progress
In progress
In progress
In progress In progress
11.1.3 Related standards activity The current amount of standards activity is a good indication of how many companies and organizations see Ethemet WAN as the next key step both for Ethemet and for the pubhc transport network providers (i.e., carriers). The major standards activities are summarized in Table 11-1. Each standards organization has its own areas of expertise. The majority of the standards that will be required for the public transport network are being developed in the Q12 and Ql 1 groups of ITU-T SGI5. This work was partitioned not only logically by topic but also in a manner that allowed for
378
Chapter 11
the earliest possible approval of useful standards/recommendations. The initial set of standards was approved in mid-2004 (see Table 11-1). Those recommendations that will require more study and debate prior to consensus are targeted near the time of the publication of this volume. ITU-T SGI5 has established liaison contact with the other standards organizations and forums where their input is required or desired. For example, the G.ethsrv work is expected to use a considerable amount of input from the MEF regarding the definition of services. Multiple organizations are working on operation, administration, and maintenance (0AM) aspects of Ethernet MANs/WANs. 0AM is critical once Ethernet is extended beyond the customer premises, especially when multiple transport service providers carry the traffic. In a multiple carrier environment, for example, the 0AM is crucial for determining the locations of problems and degradations when they occur. From a transport network provider standpoint, this OAM requirement is an area where SONET/SDH really shines. The OAM capabilities inherent in the SONET/SDH backbone allow full monitoring and protection of the transmission facilities and transport path through the SONET/SDH network.
11.1.4 DeHnition of some technical terms in this chapter The sources of these definitions are the appropriate ITU-T Recommendations, as indicted at the end of the definition. 1. Access group: A group of co-locatedyZow termination functions that are attached to the same^/ow domain ox flow point pool link. (G.809) [8] 2. Characteristic Information (CI): A signal with a specific format, which is transferred onflows. The specific formats are defined in technologyspecific standards. (G.809) 3. Flow: An aggregation of one or more traffic units with an element of common routing. (G.809) 4. Flow domain: A topological component used to effect forwarding of specific characteristic information. (G.809) 5. Flow point: A reference point that represents a point of transfer for traffic units between topological components. (G.809) 6. Flow point pool: A group of co-located flow points that have a common routing. (G.809) 7. Flow point pool link: A topological component that describes a fixed relationship between a flow domain or access group and another flow domain or access group. (G.809) 8. Flow termination: A transport processing function. There are two types of flow termination, namely, a flow termination sink and a flow termination source. (G.809)
Ethernet Services Over Public WAN
379
9. Link flow: A transport entity that transfers information between ports across a flow point pool link. (G.809) 10. Topological component: An architectural component, used to describe the transport network in terms of the topological relationships between sets of points within the same layer network. (G.809)
11.2.
SERVICE TYPES AND CHARACTERISTICS
The description of Ethernet transport services varies depending on one's vantage point. This chapter approaches Ethernet transport from the perspective of the transport network or service provider, while the customer view of Ethernet transport services is presented in Chapter 9. This chapter follows the approach of ITU-T Rec. G.8011 [9] in its discussion of the Ethernet service types and characteristics of Ethernet from the transport network / service provider viewpoint. The G.8011.X series covers specific services within the framework of G.8011. One can think of the goal of the network provider as making the Ethernet service look like an extension of the customer's Ethernet LAN. In order to provide this transparency, the network provider view must take into account a number of items that are not necessarily directly visible to the customer. These items are presented in this section in terms of Ethernet connection attributes and their associated parameters. As described in Chapter 10, an Ethernet Virtual Connection (EVC) provides the connection between two or more customer UNIs such that Ethernet frames (service frames) associated with that EVC can be transferred between these UNIs and not to any UNIs that are not associated with that EVC. Consistent with ITU-T G.8011, this chapter uses the more generic term EC (Ethernet Connection) rather than EVC. Figure 11-1 illustrates an Ethernet connection with its different reference points from the standpoint of both the Ethernet MAC layer network (ETH) and the Ethernet physical layer network (ETY). Figure 11-1 also illustrates the different Ethernet service areas in a multicarrier Ethernet connection. These three service areas are the access (UNI-C to UNI-N), end-to-end/customer-to-customer (UNI-C to UNI-C), and edge-to-edge/intracarrier (UNI-N to UNI-N).
Chapter 11
380
ETH
ETY
FD = Flow domain Figure 11-1. Illustration of Ethernet service areas (from ITU-T Rec. G.8011)
From a customer's perspective, the EC connectivity can be one of two types: • •
Line connectivity (point-to-point) LAN connectivity (point-to-multipoint or multipoint-to-multipoint)
From a transport network viewpoint, these line and LAN connections can be provided either through dedicated transport channels (including router bandwidth) or through a shared medium. The former is referred to ^s private service, and the latter as virtual private service. The difference between a private line connection and a virtual private line connection is illustrated in Figure 11-2. The service type variations are summarized in Table 11-2.
Ethernet Services Over Public WAN
381
Customer A Equipment
Customer B Equipment
Carrier Equipment
Carrier Equipment
Customer B Equipment
a) EPL for two customers, each with his or her own TDM channel
Ethernet
Ethernet
Customer A Equipment
Customer B Equipment
Carrier Equipment
Carrier Equipment
Customer B Equipment
b) EVPL for two customers where they share a TD!\/I channel for increased efficiency Figure 11-2. Illustration of private and virtual private connections
Table 11-2. Summary of the types of Ethernet services Resource sharing Connectivity Service type Point-to-point Dedicated EPL (Ethernet Private Line) Shared EVPL (Ethernet Virtual Private Line) Multipoint Dedicated EPLAN (Ethernet Private LAN) Shared EVPLAN (Ethernet Virtual Private LAN) Note : The MEF (see Chapter 9) refers to EPL and EVPL as E-Line services and EPLAN and EVPLAN as E-LAN services.
11.2.1 Ethernet connection (EC) attributes The Ethernet connection service attributes that must be taken into account in a transport or service provider network are summarized in Table 11-3 and described in more detail in the following text.
Chapter 11
382
Table 11-3. Ethernet connection service attributes (derived from ITU-T Rec. G.8011)
Service attribute parameters and values
EC service attribute Network connectivity Transfer characteristics
Separation Link type Connectivity monitoring Bandwidth profile UNI Hst Preservation Survivability
Point-to-point, point-to-multipoint, multipoint-to-multipoint Address (deliver conditionally or unconditionally) Drop Precedence (drop randomly, drop conditionally, or not applicable) Class of Service Customer Spatial or logical Service instance Dedicated or shared Sublayer monitoring: On demand, proactive, none Inherent monitoring: Proactive Specified An arbitrary text string to uniquely identify the UNIs associated with the EC VLAN ID (yes or no) Class of Service (yes or no) None, or server-specific
11.2.1.1 Network connectivity As noted, one way in which Ethernet services can be characterized is by the type of desired customer connectivity. The types of connectivity are • • •
Point-to-point Point-to-multipoint Multipoint-to-multipoint
Figure 11-3 shows examples of these different connectivity types. Figure 11-3(a) shows a basic point-to-point connection between customers through a transport network. Figure 11-3(b) shows a popular point-to-multipoint topology known as hub-and-spoke. Figures ll-3(c)-(e) show examples of various multipoint-to-multipoint topologies. Care must be taken to avoid confusing the customer connectivity (logical topology) with the physical topology of the underlying network providing that connectivity. For example, Figures 11-3(b) and 11-3(d) use the same physical topology. The difference between a hub-and-spoke and a star network is that a star network provides arbitrary multipoint-to-multipoint connectivity among all the customer nodes while a hub-and-spoke network connects the hub customer node to each of the spoke customer nodes (pointto-multipoint). Any connectivity between spoke nodes would have to be provided by a router at the customer's hub node. A logical hub-and-spoke
Ethernet Services Over Public WAN
383
network could be provided over the physical topology of any of the networks in Figures ll-3(b)-(e). Figures ll-3(c)-(e) illustrate common transport network topologies. In reality, a transport network will often consist of a combination of star, ring, and more arbitrary mesh subnetworks.
a) Point-to-point
b) Hub and spoke
c) Ring
d) Star CE
CE
CE = Customer Edge e) Aribtrary Figure 11-3. Network connectivity examples
Section 11.3 discusses transport network models.
Chapter 11
384 ETH UNI
PQR network entity
XYZ network entity'
THFD ETHFD
7 ETH UNI
ETH UNI t Customer M
ABC network entity
Customer N
ABC, PQR, XYZ are server layer networks (can all be the same or different); they may be CO-CS, CO-PS, CLPS Figure 11-4. Network portion of the multipoint-to-multipoint topology (from ITU-T Rec. G.8011)
When discussing multipoint-to-multipoint connectivity, it is common to refer to the network topological component that provides the desired forwarding of information between source and destination UNIs as a flow domain} In the example of Figure 11-4, if customers M and N are exchanging data, each is connected to a flow domain (FD), with the flow domains being connected through an Ethernet link flow (LF) over the ABC network entity. A point-to-point connection can be characterized as either not having a flow domain or as having a flow domain with only two flow points (i.e., the two endpoints of the network connection). The point-topoint connection is typically described as not having a flow domain, since a flow domain implies a layer network with inherent switching/routing and other layer network capabilities. A flow domain with only two points is really the degenerate case of a multipoint network and leaves open the potential of adding additional flow points (UNIs here) to the network.
Ethernet Services Over Public WAN
385
11.2.1.2 Transfer characteristics The transfer characteristics of a network relate to what frames are to be dehvered to the destination unconditionally, are to be delivered conditionally, or may be dropped. In the case of Ethernet, the three parameters that determine the disposition of a frame are address. Drop Precedence (DP), and Class of Service (CoS). For the address, a frame can either be delivered unconditionally, regardless of its destination address, or be delivered for only some destination addresses. The DP indicates the relative priority of the frame if it encounters a congestion situation in which frame dropping must occur. If dropping is based on the DP, frames are said to be dropped conditionally. Another option would be dropping randomly (i.e., drop the overflow frames from a full queue). For some services, frames cannot be dropped and hence DP is not applicable. The CoS parameter, which is based on the DP and indicates the frame's class queuing, is not fully defined at this time. 11.2.1.3 Separation (customer and service instance) Separation refers to how the traffic of each customer or service instance is kept separate from the traffic of others. In the case of customer separation, it is the traffic from different customers that is separated. In the case of service instance separation, it is the different service instances that are separated, even for the same customer. A spatial separation implies a circuit switched network (e.g., a TDM network in which each customer has its own TDM channel or facility, or a virtual circuit such as in an ATM network). Logical separation implies that customer or service instance traffic is separated at the packet level (i.e., based on per-packet information such as address or tag values). 11.2.1.4 Link type A link can either be dedicated to a single customer service instance or shared among multiple service instances. For a dedicated link, a single customer service instance has a one-to-one mapping to a set of one or more Ethernet links and the associated server layer trail (i.e., a spatial separation from other service instances). As such, the service instance does not compete for bandwidth/resources (transport and switch fabric bandwidth) with other service instances, and does not allow multiplexing on the access link. (See Figure 11-2(a).) On the other hand, a shared link allows more than one service instance to share that link, (i.e., logical separation) which
386
Chapter 11
means that the service instances can compete for the hnk resources. (See Figure 11-2(b).) 11.2.1.5 Connectivity monitoring Connectivity monitoring is the mechanism by which network nodes determine their ongoing connectivity to their neighbor nodes in that layer network. See Section 11.6 for a discussion of this and other 0AM topics. 11.2.1.6 Bandwidth profile A bandwidth profile specifies the parameters that a traffic flow must meet at a UNI or NNI. Policing of the bandwidth profile is typically done at the edge of the transport network. See Chapter 10 for a more detailed discussion of bandwidth profiles. 11.2.1.7 UNI list For the purposes of management and control, a service provider assigns an arbitrary string to uniquely identify each UNI. 11.2.1.8 Preservation Preservation refers to whether a customer's Ethernet frame VLAN ID and/or CoS are preserved through the transport network. If the value is preserved, it will have the same value at the egress UNI that it had at the ingress UNI of the transport network. In some circumstances, however, it may be necessary or desirable to change these values within the transport network. For example, the service provider may perform a translation between the VLAN ID values that a customer uses on the customer side of the network to a different set of VLAN IDs that are used within the service provider network. Another example is that if a frame fails to meet the specified bandwidth profile, the ingress node may choose to let it pass into the transport network but will set its DP value to a higher value so that it is prioritized for dropping if it encounters congestion. 11.2.1.9 Survivability Survivability pertains to the ability of the network to continue to provide service under situations in which a fault(s) exists in the network. See section 11-7 for more details.
Ethernet Services Over Public WAN
387
11.2.2 Ethernet Private Line (EPL) service EPL, as illustrated in Figures 11-5 and 11-2, consists of point-to-point Ethernet connections using reserved, dedicated bandwidth. With EPL, the transport network effectively looks like a "piece of wire" from the Ethernet client perspective. From the transport network provider standpoint, however, the transport network (server layer) provides the performance monitoring and protection capabilities required for guaranteeing the service level agreement (SLA) with the customer.
Customer
Equipment
^
^-\
Carrier Network /
Carrier x ^ Equipment
^xX^
^
^
Carrier Equipment
Customer
Equipment
Figure 11-5. EPL service illustration
The primary advantages of EPL are the simplicity of setting up a dedicated circuit, and the security for the traffic that is inherent when it is isolated in its own TDM channel.^ Sharing bandwidth can lead to greater bandwidth efficiency in the transport network due to statistical multiplexing gains. However, it is more difficult to administer, since it requires additional effort (e.g., traffic engineering and monitoring) in order to guarantee the customer SLA. EPL service is described in ITU-T G.8011.1 [10]. The EPL connection characteristics are summarized in Table 11-4. ITU-T G.8011.1 defines two types of EPL services. For Type 1 EPL, the CI transferred between the UNIs is the Ethernet MAC frames. As described in Section 11.3, the Ethernet preamble, start of frame delimiters, and interframe characters are discarded, and the Ethernet MAC frames are then encapsulated (e.g., into GFP-F) and mapped into the transport channel. Type 2 EPL, which is only defined for IGbit/s Ethernet, treats the 8B/10B line code information as the CI to be transferred between the UNIs. As discussed in Chapter 5, the data and control code information from the Ethernet signal's 8B/10B line code characters are translated into a more bandwidthefficient 64B/65B block code, and multiple 64B/65B codes are then mapped into a GFP frame (GFP-T). The primary advantages of Type 2 EPL are the preservation of control codes (primitive sequences of special line code
Chapter 11
388
characters) and lower mapping latency. While is possible to also define Type 2 EPL for 4B/5B-encoded 100 Mbit/s Ethernet, there has been no formal request for this service so far. Table 11-4. EPL connection characteristics (derived from ITU-T Rec. G.8011.1)
EC service attribute Network connectivity Transfer characteristics
Separation Link type Connectivity monitoring Bandwidth profile
UNI list Preservation Survivability
Service attribute parameters and values Point-to-point Address — deliver unconditionally Drop Precedence — not applicable Class of Service Customer Spatial or logical (always connection oriented) Service instance Dedicated None, on-demand, or proactive Committed information rate (CIR) and committee burst size (CBS) An arbitrary text string to uniquely identify the UNIs associated with the EC VLAN ID is preserved Class of Service is preserved None, or server-specific
11.2.3 Ethernet virtual private line service (EVPL) EVPL is also a line service; however, the line can be derived from a flow domain and allows sharing network resources among multiple customers or service instances in order to achieve more efficient use of those resources. EVPL is illustrated in Figure 11-2(b). In addition to allowing more efficient use of transport network resources, another potential advantage of EVPL is to reduce the number of UNIs required at the customer edge. This is illustrated in Figure 11-16 in Section 11.4.1. For the customer edge node on the left to connect to four other nodes would require four different UNIs and their associated ports. Service multiplexing is the packet multiplexing of multiple ECs onto a single UNI. While EVPL is still under study in ITU-T SGI5, its expected connection characteristics are summarized in Table 11-5. For virtual connections, the separation is logical (i.e., at the packet level). Due to the sharing of network resources, it is possible that frames may be dropped due to congestion. Also, as discussed above, a service provider may wish to perform VLAN ID translation at the boundaries of the transport network.
Ethernet Services Over Public WAN
389
Table 11-5. Expected EVPL connection characteristics
EC service attribute Network connectivity Transfer characteristics
Separation Link type Connectivity monitoring Bandwidth profile UNI Hst Preservation Survivability
Service attribute parameters and values Point-to-point Address (deliver conditionally or unconditionally) Drop Precedence (drop randomly, drop conditionally, or not applicable) Class of Service Customer Logical Service instance Shared None, on-demand, or proactive Specified An arbitrary text string to uniquely identify the UNIs associated with the EC VLAN ID (yes or no) Class of Service (yes or no) None, or server-specific
11.2.4 Ethernet private LAN (EPLAN) service An EPLAN provides LAN-type connectivity between multiple customer sites through dedicated channels. Figure 11-6 illustrates some of the different basic transport network topologies that can support this service. From the customer viewpoint, these topologies are equivalent (i.e., the carrier network architecture is transparent to the customer). In Options 1 and 3, the carrier does the switching at the edge of the network. Option 3 does the switching at one end of the network rather than at each end. In Option 2, the traffic is brought to a centralized switch (or a number of centralized switch points) in a star connection. Since the switching is performed at Layer 2 in these examples, an MSPP can be used to implement Options 1 and 3. Open issues to be resolved for an EPLAN standard include the following: • How do the customer and carrier specify the bandwidth requirements? For example, if the traffic was evenly distributed among the different customer nodes, the bandwidth between nodes could be specified on the basis of CIR. The more realistic scenario, however, is that multiple customer nodes will want to simultaneously communicate with a single node (e.g., remote sites communicating with a headquarters office). A safe policy would be to reserve enough bandwidth for each node to simultaneously receive data at full rate from each other node; however, this would be too inefficient to be practical. • Closely related to the above issue, how much buffering must the carrier provide to handle congestion, and what will the discard policy be?
390 •
Chapter 11
Is protection handled at Layer 1 (e.g., SONET APS) or Layer 2?
Ethernet PHY Ethernet PHY Customer Equipment Customer Equipment
a) Mesh-type connectivity
Customer Equipment
b) Traffic hauled to a centralized switch point(s)
Ethernet PHY
Customer Equipment Customer Equipment
c) Edge node serves as a bridge or router Figure 11-6. EPLAN illustrations
Ethernet Services Over Public WAN
391
While EPLAN is still under study, its expected connection characteristics are summarized in Table 11-6. Table J1-6. EPLAN expected connection characteristics
EC service attribute Network connectivity Transfer characteristics
Separation Link type Connectivity monitoring Bandwidth profile
UNI list Preservation Survivability
Service attribute parameters and values Multipoint-to-multipoint (and probably point-to-multipoint) Address — deliver unconditionally Drop Precedence — (for further study) Class of Service Customer Spatial or logical (always connection oriented) Service instance Dedicated None, on-demand, or proactive Committed information rate (CIR) and committed burst size (CBS) An arbitrary text string to uniquely identify the UNIs associated with the EC VLAN ID is preserved Class of Service is preserved None, or server-specific
11.2.5 Ethernet virtual private LAN service EVPLAN is a combination of EVPL and EPLAN. The transport channel bandwidth is shared among different customers, as are the routers in the carrier network. Ultimately, the sharing of bandwidth in the transmission channels and switch fabrics give EVPLAN the potential for very costeffective carrier network resource utilization. Clearly, however, EVPLAN is the most complicated network architecture to administer. The open issues regarding EVPLAN transport architectures include all of those already discussed for EVPL and EPLAN; however, the magnitude of some of these issues is greatly increased for EVPLAN, which in turn restricts some of the potential solution space. For example, the tagging mechanism to differentiate the data from different customers, and the different data flows within each customer data stream, must have an adequately large address space. (E.g., the 4K address space of VLAN tags makes them impractical for large EVPLANs. Also, their applicability to only Ethernet frames further lessens their appeal for a generic data network.) While EPLAN is still under study, its expected connection characteristics are summarized in Table 11-7.
Chapter 11
392 Table 11-7. EVPLAN expected connection characteristics
EC service attribute Network connectivity Transfer characteristics
Separation Link type Connectivity monitoring Bandwidth profile UNI Hst Preservation Survivability
11.3.
Service attribute parameters and values Multipoint-to-multipoint (and probably point-to-multipoint) Address (deliver conditionally or unconditionally) Drop Precedence (drop randomly, drop conditionally, or not applicable) Class of Service Customer Logical Service instance Shared None, on-demand, or proactive Specified An arbitrary text string to uniquely identify the UNIs associated with the EC VLAN ID (yes or no) Class of Service (yes or no) None, or server-specific
TRANSPORT NETWORK MODELS IN SUPPORT OF ETHERNET CONNECTIVITY SERVICES
The preceding sections provided a discussion about the service types and characteristics associated with Ethernet WAN connectivity services. This section will provide a discussion of the issue of transport models and architectures as well as a functional description of their underlying client signal adaptation and termination processes. As the demand for Ethernet managed connectivity services increases, transport and service providers are finding that over the near- to mediumterm time frames, economic optimality is best secured and customer demand best served by implementing a connection-oriented packet-switched (COPS) transport infrastructure by leveraging the existing connection-oriented circuit switched (CO-CS) TDM networks. Within this framework, and of vital importance to this emerging CO-PS transport model, there is a need for a multiplexing scheme that enables efficient, payload-transparent transport of multiservice packets and Ethernet MAC frames over optical networks. To better understand the variety of applications being pursued and addressed by this emerging transport model, we provide a set of representative service scenarios in Figures 11-7 through 11-10. In Figure 11-7, we depict the aggregation of a single customer's multiple flows over the access portion of the network, where those multiple flows may be differentiated based on class of service (high-priority guaranteed
Ethernet Services Over Public WAN
393
bandwidth such as voice, video, etc. vs. best-effort services such as e-mail, Internet access, etc.), quahty of service (error performance, latency, delay variation), or type of traffic (voice, video, Ethernet data access. Fibre Channel Storage Area Networking, etc.). Enterprise HQ
® 1
Multiple flows aggregation ^
'•
„.^2=^J
LilP****4 IL—*•
"
.
.MMUUj-^
llj 1 [/
'
''
FE/FX
/ " T L
I r^TI Mill! !.ir?M 5 ^ - - ^ -n j I K ^ 1 K «.^ svMi
,^.
Q
'='^P
FE/FX
m i
FE/FX
Interoffice f ^ Packet Ring
/I
Feeder
f ^
Distribution
Packet
A
Adaptation
Figure 11-12. Packet switching sublayer overlay for EoS
The diagrammatic representations and discussion in this section have addressed examples of the layered architectures for CO-PS-based support for EoS. Several paragraphs ago, we also outlined the functional attributes that would be necessary for the effective transformation of the current SONET/SDH transport infrastructure into one that provides a CO-PS basis for EoS. With this background in hand, we shall now begin a discussion of the details of the packet mechanism that would be necessary for the implementation of this new network paradigm. A CO-PS network can realistically be realized on the basis of leveraging two existing technologies (MPLS and GFP). To effectively support the COPS infrastructure, both technologies would require (varying levels of) enhancement and modification. In the remaining paragraphs of this section, we shall summarize the basic frame formats and identify, where possible, the necessary modifications to properly support CO-PS.
Ethernet Services Over Public WAN
399
p-t-p Connectivity Services SLS»BE SLS=15Mb/$
Broadbond Access Service
'•;,Vc4nv;','-'V-'V
.''..'ii*<W'»»'
'/', ;-'- -- ; - ' - ''^^V'«'**'*'f!r''/':
ISP
i Interoffice Packet Ring
Packet , Aggregation
4
Adaptot ton
gjjjj^ Service Port
Figure 11-13. Layered architecture for EPL services
We begin with a brief examination of MPLS as a CO-PS candidate. MPLS is a complex series of protocols encompassing traffic engineering (TE), packet forwarding (i.e., data plane), and label switched path (LSP) setup. For our purposes at hand, the aspect of MPLS that is most relevant for CO-PS is the data plane (MDP). Figure 11-14 provides the essence of MDP. One unfortunate aspect of MDP is that it does not appear to unambiguously provide for CoS and DP (drop precedence) in the shim header.'* In fact, there are two different approaches to support CoS and DP. One way is via L-LSP (Label-inferred LSP), and the other is by way of E-LSP (EXP-inferred LSP).^ In addition, L-LSP maps the CoS information into the label value. The drop probability is mapped into the EXP bits in the MPLS shim header (e.g., like the CLP bit in ATM). E-LSP maps both the CoS and the DP information into the EXP bits in the MPLS shim header. An alternative approach has been suggested^ in which the CoS and DP information is encoded in an extended GFP header (eGFP). There is a substantial similarity between eGFP and the L-LSP approach taken by RFC 3270. The approach that was, however, proposed for adoption by eGFP has the advantage of being able to leverage the eHEC mechanism that natively
Chapter 11
400
protects the extension header of the GFP frame. Figure 11-15 gives a visual depiction of the eGFP frame format.
L-LSP
Forwarding + CoS
Label (20 bits)
EXP (3b) S(1b)
Forwarding
E-LSP
DP
TTL(8b)
CoS+DP
Figure 11-14. MPLS Data Plane (MDP)
Both MDP and eGFP would require some modification in order to effectively support (in the short to medium term) the emerging CO-PS network. The modifications required in both cases are depicted in Table 11-8 and Table 11-9.^ In summary, the emerging CO-PS network can be made realizable in the short to medium term by leveraging the existing SONET/SDH network infrastructure and enhancing it with a generalized packet multiplexing capabihty. This approach would allow the service and transport provider to efficiently deploy EPL and EVPL services (with the necessary customer traffic isolation and protection) and benefit from optimizing their network resources through statistical gain with guaranteed performance (delay, jitter, loss). An architectural approach that is based upon either an MDP or a eGFP (or a combination of these technologies) could be the basis for a scalable, efficient, and simple CO-PS path layer network. Moreover, given its hybrid TDM/Packet nature, it would be competitively capable of cost-effectively supporting legacy transport services relative to full packet switching infrastructures.
TBD
Label (16 bits)
COS (3b)
DP (3b) S(1b)
Reserved (9b)
Figure 11-15. Extended GFP (eGFP) fFrame format
Ethernet Services Over Public WAN
401
Table 11-8. MDP frame format-required modification for CO-PS Tributary Slot ID 1 20-bit label CoS/DP 3-bit EXP Hierarchy | Infinite tunneling capability Tunnel Connection MPLS 0AM Monitoring Nested Connection MPLS 0AM Monitoring Pro-active FM/PM 1 MPLS 0AM (CV, FFD, FDI, BDI) On-demand fault location MPLS 0AM (ping) SNCP MPLS protection switching; further enhancements/extensions are required SPRing To be developed Mapping IP mapping is available; ATM, FR, ETH mappings are under development in IETF PWE3 Layer Network Interworking MPLS/ATM, MPLS/FR are under development in Q.5/13
Table 11-9. Extended GFP (eGFP) frame format-required modifications for CO-PS network Tributary Slot 1 Proposed 16/20-bit Flow ID. CoS/DP Proposed 3-bit Priority and DP fields Hierarchy Proposed accommodation for stacking in the extension header Tunnel Connection To be developed Monitoring Nested Connection To be developed Monitoring Pro-active FM/PM To be developed On-demand fault location To be developed SNCP To be developed SPRing To be developed Mapping To be developed Layer Network IW To be developed Switching 1 Development of connection-oriented GFP switching
11.4.
ETHERNET CLIENT INTERFACES
The client interface (i.e., the UNI) for Ethernet services will typically be an Ethernet physical interface. In the past, the UNI for WAN data
Chapter 11
402
connections was typically based on telecom signals (e.g., DSl, DS3, fractional-DSl, etc.), which required either special customer equipment (e.g., a Tl multiplexer) or special WAN port cards on customer routers. Being able to use an Ethernet interface is a significant advantage for enterprise customers. Ethernet interfaces are typically less expensive than telecom WAN interfaces, especially for higher bit rates, and are supported by relatively inexpensive Ethernet LAN routers. Using an Ethernet interface also allows the enterprise network administrators to keep their OAM in the Ethernet domain and allows the carriers to handle the telecom signal domain. The Ethernet UNI service attributes that are common for all services are shown in Table 11-10, and the attributes that are service dependent are shown in Table 11-11. Table J J-I O.Vm serviceattributes common to all services
Layer ETH ETY
UNI Service Attribute
Service Attribute Parameters and Values
MAC service UNI ID UNI EC ID PHY speed PHY medium
IEEE 802.3 frame format Arbitrary text string to identify each UNI instance Arbitrary text string to identify each EC instance 10 Mbit/s, 100 Mbit/s, 1 Gbit/s, or 10 Gbit/s IEEE 802.3 physical interface
Table IJ-I I. Service-dependent UNI service attributes
Layer
ETH
ETY
UNI Service Attribute
Service Attribute Parameters and Values
Multiplexed access VLAN mapping Bundling Bandwidth profile Layer 2 control protocol processing PHY mode
Yes, no Specify Yes, no, all-to-one For further study for most services Block, process, or pass per protocol on ingress Generate, or none per protocol on egress Full duplex, half duplex, or auto-negotiation
The UNI service attributes common to all services are reasonably selfexplanatory. The service-dependent attributes are explained as follows.
11.4.1 Multiplexed access The multiplexed access aspect of the UNI relates to whether a customer edge node has an individual UNI associated with each of the far-end UNIs to which it is connected, or whether a UNI is shared for the connections to multiple other customer UNIs. These cases are illustrated in Figure 11-16.
Ethernet Services Over Public WAN
4xUNI
a) Multiple point-to-point EPL (one EVC per UNI)
b) Service multiplexed UNI (e.g., for multiple EVPL) Figure 11-16. Service multiplexing example
403
404
Chapter 11
11.4.2 VLAN mapping Ethernet (per IEEE 802.IQ) allows the insertion of tags into Ethernet MAC frames in order to create virtual LANs (VLANs). When a customer desires to preserve this VLAN segregation of traffic through the WAN, the carrier may simply preserve the entire MAC frame, including the VLAN tag. It is possible that both the customer and service provider desire to use VLAN technology. (More will be said about this topic in Section 11.5.) If the service provider also wishes to use VLAN technology, then it must either insert a second ("stacked") VLAN tag into the MAC frame or perform a translation of the customer VLAN tag at the ingress in order to conform to the service provider's VLAN tag assignments, and then restore the customer VLAN value at egress. See Chapter 10 for a more detailed discussion of this topic.
11.4.3 Bundling Bundling refers to whether multiple customer VLAN IDs can be mapped into a single EC at a UNI. The case where all VLAN IDs are mapped to a single EC is called all-to-one bundling. See Chapter 9 for an extended discussion on bundling. It should be noted that all-to-one bundling and multiplexed access are mutually exclusive. This is because multiplexed access is the multiplexing of multiple ECs into a UNI, and mapping all VLAN IDs into a single EC means that there is a single EC at that UNI rather than multiple ECs.
11.4.4 Bandwidth profile The bandwidth profile refers to the characteristics of the traffic that a customer presents to the network at the UNI. The parameters include such things as guaranteed committed information rate (CIR), peak information rate (PIR), burst sizes, and what is done with excessive traffic. See Chapter 10 for an extended discussion on bandwidth profiles and their policing algorithms.
11.4.5 Layer 2 Control Protocol processing Layer 2 Control Protocols are used by enterprise network bridges for a variety of functions. Depending on the protocol application and the WAN service, these protocols can either be passed transparently through the WAN, processed (with the network provider equipment acting as a peer to the
Ethernet Services Over Public WAN
405
customer equipment), or discarded at the UNI. See Chapter 10 for a detailed discussion of carrying these protocols through metro networks, which also applies to transport networks.
11.4.6 Summary of UNI Service Attributes for Different Services The UNI service attributes are currently only defined for EPL service (ITU-T G.8011.1). These attributes are summarized in Table 11-12. EVPL and EVPLAN (especially EVPL AN) will typically make use of bundling and multiplexed access and have more complex bandwidth profiles. Table 11-12. Summary of UNI service attributes for different services UNI Service Attribute Service Attribute Parameters and Values Layer
ETH
ETY
11.5.
Multiplexed access VLAN mapping Bundling Bandwidth profile Layer 2 control protocol processing PHY mode
EPL No No All-to-one CIR, Committed Burst Size (CBS) All are passed except PAUSE frames, which are discarded. (The network equipment providing the UNI-N may generate PAUSE frames.) Full duplex
ETHERNET TRANSPORT NETWOIOC TO NETWORK INTERFACE (NNI)
We see from the depiction in Figure 11-24 in Section 11.6 that there are typically different client server functions involved in a communications network relationship. Graphically depicted in that figure are the separate functions of customer, service provider, and transport provider. These different functions imply not only a difference in the client server interface relationship models but also a difference in the information entities that are actually passed between each client server pair. In a typical communications network based upon client server architecture, customers would usually connect to the service provider network for service over a user network interface (UNI).^ In a similar manner, the service provider would connect for transport service to the network of a transport provider over a network-to-network interface (NNI). This interface is deployable in a couple of different configurations. One way is to interconnect the separate administrative network domains of the same
406
Chapter 11
service or transport provider. This is often described technically as an Intra Domain Interface (laDI). Another method is to interconnect two or more network domains of different service or transport providers. This is technically described as an Inter Domain Interface (IrDI). We will dedicate the remainder of this section to discussing the specifics of the different NNI approaches that are likely to be adopted for the support of Ethernet managed connectivity services. In Figure 11-17, we provide a graphical depiction of an laDI for a generic Ethernet over Transport (EoT) service.^ In this example, we see that there are two separate administrative domains for the same service provider. ^^ Note also the fact that the same NNI is used both internally to the administrative domain and externally for the same provider network.
Service Provider A Administrative Domain A
Service Provider A Administrative Domain B
Figure 11-17. laDI NNI for Ethernet over Transport Service (adapted from ITU-T Draft Rec. G.8012[ll])
Turning to the IrDI, we note that (as depicted in Figure 11-18) this case is architecturally indistinguishable from the laDI case except for the fact that the network infrastructure is independently owned. The NNI inside the individual administrative domain is exactly the same in terms of features and functionalities as the NNI connecting the two networks.
Ethernet Services Over Public WAN
407
31
Ety-UN»
t
j
•'fl"'"''''-"''"'flim I |Ety4JNr
J Service Provider B Administrative Domain B
Service Provider A Administrative Domain A
Figure 11-18. IrDI NNI for Ethernet over transport service (adapted from ITU-T Draft Rec. G.8012)
As was mentioned above, there are several transport technologies (represented by different layer network models) that are capable of supporting Ethernet connectivity services. Figure 11-19 provides a graphic depiction of the different layer networks and their NNI relationships that are available to the service and transport operators for supporting Ethernet connectivity services. In Figure 11-19, we note that there is an NNI defined at the MAC level for connecting two laDI or IrDI network elements (NEs). Note also that no specific identity has been given to the server transport technologies. What is of importance in this case is the fact that the client Ethernet physical interface (ETY) could be just as easily transported over server transport technology A, B, or C as long as the appropriate laDI or IrDI NNIs are in place in the different NEs.
ETH
ETH UNI 11 II
ETY
ETY UNI II II
ETH NNI II II
ETH
SrvA NNI ETY
SrvA
II
ETH SrvA NNI II SrvA SrvA II
ETY
ETH UNI II II
ETH
ETY UNI II II
ETY
SrvB NNI SrvB NNI SrvB NNI II II II SrvB SrvB SrvB SrvB II II 11 SrvC
SrvC NNI SrvC NNI SrvC NNI II II II SrvC SrvC SrvC II II II
Figure 11-19. EoT server layer networks (from ITU-T Draft Rec. G.8012)
Chapter 11
408
The discussion above has estabhshed that NNIs are based on either laDI or IrDI relationships. These latter entities are also typically defined in NEs situated at the boundary points of the network. To proceed with developing our understanding of the role of the NNI in supporting Ethernet connectivity services, we will now explore some of the details of the functional elements of the NNI. In this regard, Figure 11-20 will be useful in helping us with our understanding of these details. From Figure 11-20, we see that the typical NNI functionality provides support for the structured transfer of information associated with the following functions: 1. Management plane "^e.g., plane management and resource management functions 2. Control plane ^ call control, connection control, and signaling functions 3. User/Data plane -^ user information flow transfer and the associated inband flow and error management controls
UNI/ NNI
TNE
Figure 11-20. Three planes of Ethernet UNI and NNI (from ITU-T Draft Rec. G.8012)
In a manner similar to the structure in Figure 11-20, the NNI function is further decomposed into plane-specific functions corresponding to the management, control, and user/data planes (i.e., NNIM, NNIC, and NNID, respectively). In the remainder of this section, we will provide greater details
Ethernet Services Over Public WAN
409
on the N N I D for EoT. Figure 11-21'' provides an illustration of the basic signal structure for the NNID. In Figure 11-21, several transport server technologies for the transport of the Ethernet client signal are identified. For the CO-PS-based case that we have been discussing, SONET/SDH and PDH would be the most directly relevant transport technologies. Although not entirely visible in Figure 11-21 (but nevertheless there), the N N I D function associated with the aforementioned technologies would provide for such functions as client signal adaptation and mapping, error management, link state signaling, flow control, and connection monitoring. From the graphics in Figure 11-21, we can see that the methodology for mapping and adaptation of the Ethernet MAC client signal is dependent upon the underlying transport server technology. Since GFP is the preferred method for such mappings for PDH, SDH/SONET and OTH transport server technologies, we will limit our discussion to GFP.'^ To repeat in summary some of the information from Chapter 5, the GFP ingress source mapping process accepts the Ethernet MAC client signal and performs an octet-aligned insertion into the payload area of the GFP-F frame. It then follows this by attaching a core header, which includes a payload length indicator (PLI) and core header error check (cHEC) fields. Added also is a payload header with support for discriminators for payload type (PTI), presence of GFP payload field FCS (PFI), and extension header (EXI), as well as an indicator of user payload (UPI) and an error check over the type field.'^ A graphic of the preceding described process is depicted in Figure 11-22. The intent of Figure 11-22 is to provide the reader with a graphic understanding of the encapsulation process and how the Ethernet client signal format is mapped into the GFP-F frame format for subsequent transport across the WAN. Figure 11-23 continues this analysis from a more functional architectural perspective. Our purpose here is to provide a more comprehensive architectural modeling view of the manner in which the Ethernet WAN transport service via the N N I D is actually implemented.
Chapter 11
410
Clients (e.g., IP, MPLS, PDH) _SNAR-
_ J
LLC
\
ETHP
Era.
ETHS -GFPflLAPB ETYn
GFPflikpb-
64B/Md-
PDH Pqe, Pq^ Pqe-X Pqs-Kvl
SDH VC VC-n Xv VC-4| •Xc
SDH VC-44d4c
OTH ODwt ODUk-Xv
ATM VC
MPLS
EoP
EoS
EoS
EoO
EoA
EoM
Native Etliernet
RPR
_E^
Etiiernet-over-Transport
Figure 11-21. ETH interface signal structure (from ITU-T Draft Rec. G.8012)
2< CO
Link Header
M_SDU
]\1\}~T RQQommQnd2ii\or\ Gm\()IY A2>()6, Ethernet Layer Network Architecture,2()QA. [14] ITU-T Recommendation G.808.1, Generic Protection Switching —Linear Trail and Subnetwork Protection, 2003. [15] ITU-T Recommendation 1.630, ATM Protection Switching, 2000.
Chapter 12 ETHERNET SERVICES OVER MPLS NETWORKS
Iftekhar Hussain Cisco Systems, Inc.
12.1.
VIRTUAL PRIVATE NETWORKS
For corporations and enterprises with geographically distributed sites, network connectivity between different sites is essential to meet increasing demands for voice, video, and data communication. Initially, corporate networks were interconnected using dedicated transport facilities such as DSl/El and DS3/E3. Service Providers (SPs) leased transport facilities as a service to their customers. A network in which sites are interconnected using dedicated transport facilities is called a private network. Using this type of network connectivity, the cost of offering a private network services was very high for the SPs and their customers. Additionally, the provisioning of new services was a slow and laborious task.
12.1.1 Traditional Layer 2 Virtual Private Networks A network in which sites are interconnected using circuits over a shared network infrastructure is called Virtual Private Network (VPN). When all sites in a VPN belong to the same organization, a VPN can be viewed as providing intranet connectivity. On the other hand, when various sites in a VPN belong to different organizations, the VPN can be thought of as providing the extranet connectivity. The fact that multiple VPN customers share the network infrastructure is what sets a VPN apart from a private network. The shared network infrastructure is known as the VPN backbone.
426
Chapter 12
The sharing of the VPN backbone allows SPs to offer VPN services to their customers at lower costs. A VPN that interconnects a set of customer sites over a shared network infrastructure and allows them to communicate based on Layer 2 frames is known as Layer 2 VPN (L2VPN). In contrast, a VPN that interconnects a set of customer sites over a shared network infrastructure and allows them to communicate based on Layer 3 addresses (e.g., IP addresses) is known as Layer 3 VPN (L3VPN), Thus the distinguishing characteristic of an L2VPN, in comparison to an L3VPN, is that in L2VPNs packet forwarding is carried out at L2 such as ATM, FR, and Ethernet. Figure 12-1 shows an example of a L2VPN using ATM Virtual Connections (VCs).
Customer Hcigc (F'F.) Dc\ ice
Provider Edge (PE) Device
Shared VPN Backbone
Figure 12-1. Traditional Layer 2 Virtual Private Networks
12.1.2
Classification of VPNs
Generally, VPN services may be provisioned and managed by SPs or customers. A VPN for which the SP participates in management and provisioning of the VPN service is termed a Provider Provisioned VPN (PPVPN). There are many ways in which an SP can participate in the management and provisioning of a VPN service. Correspondingly, there is a wide spectrum of VPN types. The following attributes are useful for classifying VPNs: • Service Layer (e.g., L2 versus L3): the layer at which VPN service is offered by the SP • VPN Edge Device (e.g., CE-based versus PE-based): the device where VPN-specific functions are performed • Service Connectivity (e.g., point-to-point versus point-to-multipoint): the type of connectivity the VPN service offers
Ethernet Services Over MPLS Networks
All
One such taxonomy of PPVPN technologies is depicted in Figure 12-2. PPVPN
Point-to-Multipoint
Point-to-Point
CE-based
RFC2547 Style
Multicast
Virtual Router Style
Unicast
Figure 12-2. Taxonomy of PPVPN technologies [1]
12.1.3
Multiservice Converged Packet Switched Backbone
Although L2VPNS based on ATM VCs and FR Data Link Connection Identifiers (DLCIs) were easier to provision and had a lower cost than dedicated leased lines, they still had some drawbacks. For example, this type of L2VPN approach restricted the SP's backbone to a single transport technology such as ATM/FR links, which made it burdensome to share the same physical transport facilities for Internet and VPN traffic. Even when Internet and VPN infrastructures could share the backbone transport facilities, they needed separate administration and maintenance. Although provisioning of ATM VCs and FR DLCIs was easier and relatively less cumbersome than dedicated lines, it was still tedious. For example, adding a new customer site to an existing VPN required provisioning an ATM VC to every other site in the VPN. Traditional L2VPNs work well from the customer's point of view; however, the costs of maintaining separate network infrastructures and the administrative burden of provisioning these VPNs have led SPs to migrate their legacy L2 and emerging L3 services onto a common multiservice IP/MPLS packet switched network (PSN). The following discussion assumes some basic familiarity with the MPLS (refer to Appendix A for a quick overview of MPLS technology).
428
n.l.
Chapter 12
L2VPNS OVER MPLS BACKBONE
There are two main types of L2VPN services that an SP can offer to its customers, namely, Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) [2]. A VPWS is a point-to-point L2VPN service. In contrast, a VPLS is a point-to-multipoint L2VPN. A VPLS emulates Local Area Network (LAN) service over the Wide Area Network (WAN), which allows interconnecting LAN segments on geographically dispersed customer sites, as if they were connected to the same LAN. In both VPWS and VPLS, L2 frames are transported across the IP/MPLS backbone. In both types of L2VPN, a CE (e.g., CEl) transmits a frame to a PE (e.g., PEl); PEl encapsulates the frame in one or more additional headers and transports the frame to another PE (e.g., PE2). The PE2 in turn removes the encapsulation header and sends the frame to another CE (e.g., CE2). With the exception of some specific services such as point-to-point versus point-to-multipoint, both VPWS and VPLS employ a number of functional components such as header encapsulations. Therefore, to avoid repetition of common functions, it is more efficient to decompose L2VPN functional components into service independent (common) and servicespecific components.
12.2.1 L2VPNs Architecture Generic Components This section describes generic components that are common in all L2VPNs. The service-specific components and architectures are described later in the pertinent sections. 12.2.1.1 Attachment Circuit (AC) In all types of L2VPNs, a CE device (a router or a switch) attaches to a PE device via a physical connection (e.g., Ethernet port) or logical connection (e.g., VLAN port) termed an Attachment Circuit (AC). An AC may be an Ethernet port, a VLAN port, a FR DLCI, or an ATM VPI/VCI, and so forth. An AC carries L2 frames between a pair of CE and PE devices. 12.2.1.2 Pseudowire (PW) In all types of L2VPNs, a L2 frame between two PE devices is carried over another logical connection termed a Pseudowire (PW). Thus any given L2 frame first travels on an AC from a CE to a PE, then on a PW from a PE to another PE, and finally on another AC from a PE to a CE.
Ethernet Services Over MPLS Networks
429
A PW is a mechanism that emulates the essential attributes of a telecommunications service such as FR, ATM, Ethernet, Time Division Multiplexing (TDM), and SONET/SDH over IP and/or MPLS PSN [3]. A protocol data unit (PDU) that contains all the data and control information necessary to emulate the desired service is known as a PW-PDU. Figure 123 shows the logical protocol layering of a generic PW for different types of services. It is worth mentioning that each type of service is emulated using a separate PW. For a given emulated service, to a CE device, the PW appears as an unshared dedicated circuit. The PW protocol layers are discussed in the following sections. ^l n.lriulurrtP Klhrriic(, KK, Ccll(AIM) Ar.MAAl.5) V. J K. )
DSI, DSV Kl,
Packet (r.R., SONKI/SDII SI'K, \'r, N\l)SO)J
('rll(AT.M) ATMAAL5)
l)SI,l)SV Kl, K3) ^
SONK.I SDH
Service PayloaJ (such a.s packet, cell, ilMrcain. and stnicliircd bilslrc:ini)
PayioLid liming nw y been rr using Rc:»l TimeProtocol (R'lT)
Pavload Convcrccncc TiminK SetiuciK'ing PWlXmulliplcxer PSN Convergence PSN n:U:i Ijnk V ^J
Pliy.Mcal
SucilasPackcI(>^cI SONI: ! "snilurl-lhcmcWAcrlilKT
Pnckot Switched Network (PSN)
Figure 12-3. Protocol Stack Model for PW Emulation Edge to Edge (PWE3)
12.2.1.2.1
Encapsulation Layer
The PW encapsulation layer contains three sublayers, namely, Payload Convergence, Sequencing, and Timing. 12.2.1.2.1.1 Payload Convergence The primary function of the Payload Convergence Layer is to encapsulate the incoming (CE to PE direction) payload in PW-PDUs. In the outgoing direction (PE to CE direction), the Convergence Layer replays the native data units on the physical interface attached to the destination CE.
430 Xl.lA.lA.l
Chapter 12 Timing
Delivery of native services such as structured and unstructured bistreams requires availability of an accurate timing recovery mechanism depending upon the characteristics of the transport network. For example, the clocks used to synchronize SONET equipment are stratum 3 (or better accuracy) clocks that are normally traceable to a primary reference source (a clock source that provides a timing signal with long-term accuracy at 10"'' or better with verification to the Universal Time Coordinated (UTC)). Therefore, the emulated service must also duplicate the timing characteristics as closely as possible to that expected of a native service. The Timing Sublayer provides two synchronization-related functions, namely, clock recovery (the extraction of output transmission bit timing information from the delivered packet stream) and timed payload delivery (the playing out of noncontiguous PW PDUs to the PW output interface with a constant phase relative to the input interface). Generally, timing signal can be distributed through external mechanisms such as Building Integrated Timing System (BITS), Stand Alone Synchronization Equipment (SASE), and Global Positioning System (GPS) or extracted from the bitstream using an adaptive clock recovery mechanism. To facilitate extraction of timing information from the packet stream at the receiver, the timing information from the sender can be carried using the Timestamp field of the Real Time Protocol (RTP) [4]. 12.2.1.2.1.3 Sequencing Functions In an IP/MPLS network, the packets carrying PW-PDUs may arrive out of order, may arrive duplicated, or may never arrive at the destination PE. The Sequencing Layer provides services that enable in-order and unduplicated frame delivery to the CE and additionally enable detection of frame loss. 12.2.1.2.2
Demultiplexer Layer
A PSN tunnel is a logical link that provides a data path across the backbone. The main function of the PW Demultiplexer Layer is to provide a demultiplexer field to allow multiple PWs to be carried in a PSN tunnel. The demultiplexer field allows the receiving PE device to distinguish one PW from others. In general, depending on the tunnel protocols, the demultiplexer field may have a different format. For example, when PWs are being carried in an MPLS tunnel, the PW demultiplexer field contains an MPLS label. To summarize, the PW Demultiplexer Layer provides the
Ethernet Services Over MPLS Networks
431
ability to carry multiple PWs within a PSN tunnel transparently across the backbone. Other than PE devices that must perform functions related to PWPDUs (such as encapsulation, decapsulation, and sequencing), PWs are invisible to the other backbone devices (e.g., P routers). 12.2.1.2.2.1 Fragmentation and Reassembly After accounting for the PW and the packet switched network headers (such as IP or MPLS headers) if the combined size of the payload and the associated network headers exceeds the path Maximum Transmission Unit (MTU) of the network, fragmentation and reassembly at the PE devices is required in order for the packet to be delivered across the PSN. In theory, CEs should be able to adapt the packet size according to the path MTU to avoid fragmentation in the network. In practice, there may be situations when a CE lacks this capability. If the CE cannot adhere to an acceptable MTU size, the PE should be able to perform PW fragmentation and reassembly. 12.2.1.2.3 Service-Specific PW Preprocessing In general, at the PE some form of service-specific preprocessing (such as Ethernet bridging, ATM VPIA^CI header translation, SONET Virtual Tributary (VT) cross-connection) on the native data units received from the CE is needed before PW PDUs can be transmitted on the PW. The PW preprocessing can be divided into two components, namely. Native Service Processor and Forwarder.
12.2.1.2.3.1 Native Service Processing (NSP) The purpose of the NSP is to perform service-specific operations based on the semantics of the payload. In the case of Ethernet service, for example, the NSP function includes frame processing and may include additional functions such as stripping, overwriting, or adding VLAN tags, physical port multiplexing and demultiplexing, PW-PW bridging, L2 encapsulation, and so forth. 12.2.1.2.3.2 Forwarders A forwarder is a logical module in the PE that that selects the PW to use to transmit a payload received on an AC. The selection of a particular PW may be based on incoming AC, the contents of the payload (e.g., packet
432
Chapter 12
header), or some statically/dynamically configured forwarding information. Based on the type of service (e.g., point-to-point or point-to-multipoint), the forwarder may selectively forward payload from one AC to exactly one PW or one or more ACs to multiple PWs (Figure 12-4 and Figure 12-5 depict a point-to-and point-to-multipoint forwarder, respectively).
AC
Forwarder
PW
Forwarder
MPLS Network Figure 12-4. Forwarder for a point-to-point service.
MPLS Network Figure 12-5. Forwarder for a point-to-multipoint service.
AC
Ethernet Services Over MPLS Networks
433
12.2.1.3 VPN Tunnels In all type of L2VPNs, data traffic between PE devices is transported over VPN tunnels. A VPN tunnel is a logical link between two PE (or CE) entities that is used to carry VPN traffic across the backbone. In general, a tunnel is implemented by encapsulating packets within another header that are transmitted between those two entities. For example, in PE-based VPNs, a PE-PE tunnel provides connectivity between two PE devices. 12.2.1.3.1 Motivations for Tunnels One of the main motivations for the use of tunneling in VPN applications is to be able to transport customer packets with nonunique addressing information between the VPN edge devices. For example, customer networks often use private or nonunique IP addresses. However, in many VPN applications (as, for example, in L3VPNs [5]), a single VPN edge device such as a PE router can provide VPN service to multiple customers even if those customer networks have overlapping addresses. The fact that the customer addresses are not globally unique means that IP packets from a customer cannot be transmitted to the correct destinations over the shared VPN backbone in their native form. In other words, some form of additional header encapsulation (tunneling) must be utilized to forward packets to their correct destinations. Thus, a tunneling protocol attaches an extra encapsulating header (which, in the case of MPLS, corresponds to one or more labels) to a VPN packet, and this additional header information is then used for forwarding the packet between the VPN edge devices. There are other important reasons for using tunnels in VPN applications, such as the need to isolate traffic from different customers and to provide different quality of service (QoS) and security characteristics. For example, QoS and security requirements of different VPN customers may differ and can be satisfied by using different tunnels with the appropriate characteristics. 12.2.1.3.2 Hierarchical Tunnels If you were to form VPN tunnels across the backbone for each instance of VPN, devices in the backbone such as P routers would need to be VPNaware and to maintain state for each VPN tunnel, which from a network scalability point of view is highly undesirable. A better solution is to establish one tunnel between each pair of VPN edge devices and then multiplex multiple VPN-specific tunnels through the single outer tunnel. With this approach, the amount of state depends only on the number of VPN
434
Chapter 12
edge devices, not on the number of VPNs. A tunnel that encapsulates one tunnel within another is known as a hierarchical tunnel, 12.2.1.3.3 Tunneling Protocols Several protocols can be used to establish and maintain VPN tunnels, including Generic Routing Encapsulation (GRE) [6,7], IP-in-IP [8,9], IPsec [10-13], and MPLS [14,15]. Each tunneling protocol can be characterized in terms of a common set of characteristics such as the format of the encapsulation header and the overhead introduced by the encapsulation, how the VPN-related information is inferred from the packet's encapsulation header, whether an explicit signaling protocol is required for setting up the tunnel, whether the tunneling protocol allows hierarchical tunneling, and whether the tunneling protocol supports mechanisms to detect tunnel failures and to respond appropriately to restore service. This chapter focuses mainly on the use of MPLS based tunnels. 12.2.1.3.4 MPLS Tunnels This section briefly describes distinguishing characteristics of MPLS tunneling protocols for VPN applications. A detailed survey of other tunneling techniques can be found in [16]. In MPLS networks, routers are known as label switching routers (LSRs) that forward packets based on labels. A label is a short, fixed-length, physically contiguous identifier, which is used to forward a packet instead of an IP address and usually has a local significance. The sequence of LSRs that a labeled packet traverses, starting at ingress LSR and terminating at the egress LSR, is called label switched path (LSP) (see Appendix A for an overview of MPLS). In the PPVPN terminology, an LSP corresponds to a VPN tunnel. In general, MPLS tunnels have following characteristics: • Tunnel encapsulation is based on label stack, and the label value is used as multiplexing field • Tunnels can be multiplexed within other tunnels. For example, in the MPLS backbone, P routers only need to maintain state for the topmost label in the label stack. This means that the VPN-specific state of the nested tunnels is not visible to the P routers. • Tunnels are set up and maintained using signaling protocols such as Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP).
Ethernet Services Over MPLS Networks
435
12.2.1.3.5 Carrying PWs over MPLS Tunnels The protocol layering to carry PW emulated services (e.g., Ethernet) over MPLS networks is depicted in Figure 12-6. Each packet header carries two labels, namely, a bottom label and a top label. The bottom label represents a particular PW within the tunnel and provides the PW demultiplexing function to distinguish one PW from another. The top label represents a route (an LSP) across the backbone to the egress PE. The bottom label is invisible to the devices in the backbone until the packet arrives at the PE. In other words, the bottom label is meaningful only to the PE devices. In the remainder of this chapter, the term tunnel label refers to the top label and the term PW label refers to the bottom label.
Slrip-ofTprcaFTihic an J frame check sum (FCS)
Attach the daia link iivcr hcadci —^
Attach the physical !a\cr hcadt
Paytoad (LthcrnciFraiix)
'C:^
Control Pa>!oaJ (Ethernet Framed WurJ
FW Ubfl
Tunnel j [.abd
Tunnel Label
PIT Header
SON FT Header
Payload (r.lhL-nicl Frank)
Conlrol Word
Uhtl
Tunnel Label
Header
Attach data link (PPP) and _ ph>$icall3>ei{S0NRl) headers Packet is lahcl.su itched _ inthcMPl.^neiuork
Figure 12-6. Protocol layering for carrying Ethernet PWs over MPLS tunnels
|
Header
436
12.3.
Chapter 12
METRO ETHERNET SERVICES
This section briefly describes Ethernet services with the goal of motivating ensuing discussions relating to the delivery of Ethernet services over MPLS using VPWS and VPLS L2VPNs. For complete details on various Ethernet service features and attributes, refer to Chapter 10, "Metro Ethernet Services".
12.3.1 Ethernet Virtual Connection (EVC) To visualize and characterize Ethernet connections like other L2 circuits such as FR DLCI and ATM VCs, the notion of Ethernet Virtual Connection (EVC) is very useful. An EVC is an association between one or more User Network Interfaces (UNIs) for exchanging an Ethernet frame among the associated entities. An EVC can refer to point-to-point or multipoint-tomultipoint connectivity. A point-to-point EVC is associated with exactly two UNIs. A multipoint-to-multipoint EVC is associated with two or more UNIs. A point-to-multipoint EVC is a special case of the multipoint-to-multipoint EVC in which one UNI is designated as the root node and the remaining UNIs as the leaf node such that a frame received at the root UNI is transmitted to all leaf nodes. Based on the notion of EVC, there are two types of Ethernet services that can be defined, namely, Ethernet Line (ELine) Service and Ethernet LAN (E-LAN) Service.
12.3.2 E-Line Service E-Line Service uses point-to-point EVC and thus can be used to offer point-to-point Ethernet Virtual Leased Lines between two CE devices (refer to Figure 12-7). From the previous discussion, recall that E-Line Service is analogous to traditional L2VPN services based on ATM or Frame Relay virtual circuits. Later on, we will discuss how E-Line Service can be offered over an MPLS backbone using VPWS.
12.3.3 E-LAN Service E-LAN Service is based on multipoint-to-multipoint EVC and thus can be used to connect geographically dispersed customer sites in a Metro area and make them appear as if they were on the same LAN (refer to Figure 128). In the following section, we will discuss how E-Line Service can be offered over an MPLS backbone (WAN) using VPLS.
437
Ethernet Services Over MPLS Networks
T^^^"SP•fff ^ '^ '^ ^n\ In t^^'
Metro Ethernet Network (MEN)
^=3
CH
Figure 12-7. An example of Ethernet Line (E-Line) service
UT'i-r^
Metro Ethernet Network (MEN)
\^ ^^• • • • S T n In Cli
Figure 12-8. An example of Ethernet LAN (E-LAN) service
12.4.
METRO ETHERNET SERVICES OVER MPLS
This section describes the VPWS and VPLS architecture framework, which can be used to provide E-LINE and E-LAN services over an MPLS backbone.
438
Chapter 12
12.4.1 Emulation of E-Line Services using VPWS As discussed previously, a VPWS is an L2VPN that provides L2 pointto-point services. In VPSW, PE devices behave as MPLS-capable L2 switches and provide a logical interconnect of L2 circuits such that pair of CE devices appear to be connected by an L2 virtual circuit. When a CE device transmits a frame on such an L2 virtual circuit, the CE device at the other endpoint of the virtual circuit receives the frame. In the VPWS case, the forwarding of frames from one CE device to another is completely determined by the virtual circuit on which the frame is transmitted. In other words, the forwarding of frames is not affected by the contents of the frame header, and the PE acts as a virtual circuit switch.
12.4.1.1 VPWS Reference Model An Ethernet PW allows Ethemet/802.3 PDUs to be transported across an IP or an MPLS network. A point-to-point Ethernet PW emulates a single Ethernet link (an EVC) between exactly two endpoints. Figure 12-9 shows the VPWS reference model for emulation of point-to-point Ethernet services over MPLS. The protocol stack for VPSW over SONET-based MPLS transport is also depicted in Figure 12-9. Most of the entities in this reference model such as AC, PW, CE, and PE have already been described in the previous section. In general, VPSW can be used to offer a variety of L2 point-to-point services such as Ethernet, ATM, FR, TDM, and so forth (for example, refer to Figure 12-3). This is accomplished by using service-specific encapsulation methods to carry L2 frames across IP or MPLS networks. For this purpose, different encapsulation methods have been specified [17-21]. This section specifically describes the use of the encapsulation method defined in [17] to transport Ethernet frames over MPLS networks (to see protocol layering for Ethernet over SONET-based MPLS network, refer to Figure 12-6) and the use of the LDP extension defined in [22] for setting up Ethernet PWs.
Ethernet Services Over MPLS Networks
439
Ijmilalcd SciAJce
AUachniciit Circuit • r* AlU
PR-PI' Pscuclowirc
-V AUachinciit Circuit-
— lM-;-PI- Tunnel
I-thcrnc( I'ramcs Cl-2
MPLS Network
MPLS tunnel is setuj"'. usin-LDPorRSVP-T!-:
Figure 12-9. VPWS Reference Model for emulation of E-Line service over MPLS network
12.4.1.2 Ethernet Modes (Raw versus Tag) There are two modes in which an Ethernet can operate, namely, raw mode or tag mode. When operating in the tag mode, each frame carries an 802. IQ VLAN tag and the Native Service Processing (NSP) component at the two PW endpoints processes the tag. By contrast, in the raw mode, the NSPs do not process the tag (i.e., the VLAN tag passes transparently through the NSP). Depending on whether the tag is service delimiting or nonservice delimiting, the NSF may need to handle it differently in the tag mode and the raw mode. 12.4.1.3 VLAN Tag Processing The VLAN tag is said to be service delimiting if the tag is placed in the frame by the service provider equipment and the tag is meaningful to that equipment only. For example, consider a deployment scenario where the service provider has employed a LAN switch to aggregate traffic from multiple customers. In this case, the LAN switch may apply VLAN tags to distinguish streams of customer traffic from one another, and then forward the frames to the PE. The tag is said to be nonservice delimiting if the CE placed it in the frame and the tag is meaningless to the PE. Whether a tag is service or nonservice delimiting has an important implication for the processing of frames at the Ethernet PW endpoints. For example, in the raw mode, the service-delimiting tag is not transmitted over the PW. In this case, if the service delimiting tag is present in the frame
440
Chapter 12
received from the CE, the PE strips it off before transmitting on the PW. In the tag mode, the service-dehmiting tag must be transmitted. In this case, if the service-dehmiting tag is not present in the frame received from the CE, the PE must prepend the frame with a dummy VLAN tag before sending the frame on the PW. 12.4.1.4 Establishing Ethernet PWs via LDP As discussed previously, to transport L2 PDUs from ingress PEl to egress PE2 across an MPLS network over a tunnel, PEl pushes two labels (a tunnel label as the top label and a PW label as the bottom label). The distribution of tunnel labels is accomplished using LDP [23] or RSVPTE[24]. This section describes how LDP is used to signal PW labels. A bidirectional PW consists of two LSPs between PEl and PE2 (refer to Figure 12-9). The first step toward setting up a PW involves establishment of LDP session between PEl and PE2. To establish an LDP session between them, the PEs must know each other's address. A PE may learn a remote PE address through configuration or autodiscovery procedures (for example, using BGP [25]). PEl and PE2 then establish an LDP session in downstream-unsolicited mode. Before a PE can begin signaling PW labels to a remote PE, the PE must know the Target Attachment Identifier (TAI) of the remote PE. In VPWS, a PW can be thought of as connecting exactly two forwarders. To identify a particular forwarder, through configuration or based on some algorithm, each forwarder is associated with an Attachment Identifier (AI) that is unique in the context of the PE router in which the Forwarder resides. The combination of can identify a globally unique forwarder. To identify a set of forwarders that is part of the same group, an AI is defined to contain an Attachment Group Identifier (AGI) plus an Attachment Individual Identifier (All). We may think of an AGI as a VPN-id or a VLAN identifier. For example, if a bidirectional PW connects PEl with PE2, the LSP in the PEl to PE2 direction can be identified as « P E 1 , , PE2,
Transport Plane '.
-NE;'-^- - NE
NE
ME - ^ . ' t
Switched Connections
'
X
/
I
Soft Permanent Connection Service
Figure J 6-3. Example of soft permanent connection service
Regardless of the approach, a critical requirement is that failures in the control or management plane should not affect the connection (we note that the same applies to software upgrades). In other words, in the event that signaling connectivity is lost, the transport network must maintain existing connections. Furthermore, when the control plane recovers, it should recover connection state information without affecting the live connections. This requirement is typically referred to as the separation of control and transport
Architecting the Automatically Switched Transport Network
557
planes and reflects the criticality of the transport plane maintaining an extremely high level of reliability. We note that the persistence of a connection itself is actually a function of the type of service-level specifications supported within a transport network. The majority of connections will have a persistency requirement (e.g., protected connections, or connections with some guaranteed level of availability). However, operators might decide to offer a "best effort" service-level specification for connections that are automatically released when a defect occurs on the connection. A call can be considered as a service provided to user endpoints, where multiple calls may exist between any two endpoints and each call may have multiple connections. The call concept provides an abstract relationship between users, where this relationship describes (or verifies) the extent to which the users are willing to offer (or accept) service to (from) each other. A call does not provide the actual connectivity for transmitting user traffic but only builds a relationship by which future connections may be made. Call control is therefore defined as a signaling association between one or more user applications and the network to control the setup, release, modifications, and maintenance of sets of connections. The concept of call control grew out of the vision of the intelligent switching network (IN), which was enabled by the concept that service control could be logically separated from connection control. This meant that new services could be offered, unconstrained by assumptions about the resources of the underlying network. This allowed the introduction of new value-added services in addition to the basic PSTN (Public Switched Telephony Network). Thus, a service request could still be made from a phone terminal, but the request would be delivered to a service manager control function rather than being directly delivered to the connection control fimction. The service manager is now a client of the original connection service and can employ that connection service as needed to carry out the service request. The service interface can now address resources that are completely unknown to the original connection service, enabling a wide range of new services to be created without affecting the underlying transport network. We can also consider call control itself to be a service that can be logically separated from connection control, allowing call control to be processed (and if necessary located) separately from connection control in the underlying transport network. The notion of considering calls and call control to be a kind of service is a reflection of the idea that the ability to set up connections in the network may be offered to others [16]. While call control functions were not explicitly discussed within G.807, there was an implicit assumption of their existence (e.g., discussion of call arrival rates and the need for associated congestion control mechanisms).
Chapter 16
558
In the PSTN world, examples of call control capabilities include features such as ringback, call divert, etc. In the transport world, a fundamental call property is its ability to be supported by multiple connections, where each connection may be of a different type and where each connection may exist independently of other connections within the call. The concept of the call allows for a better flexibility in how users set up connections and how the network offers services to users. In essence, a call allows: • Verification and authentication of a call prior to connection, which may result in less wasted resources • Support for virtual concatenation where each connection can travel on different diverse paths (e.g., taking an ESCON payload of 160 Mbit/s, adapting it using GFP [17], and mapping into a virtual concatenation group composed of 4 VC-3s, each at 48.384 Mbit/s) • General treatment of multiple connections that may be associated for the purpose of recovery; for example, a pair of primary and backup connections may belong to the same call • Use of a public and private addressing space (hosts using a public space, with the network using only an internal private addressing space) • Better upgrading strategy for service provider control plane operation, where call control (service provisioning) may be separated from switches and connections (where connection control may reside) An example of a single call with multiple connections for recovery purposes is illustrated in Figure 16-4. In this example, a single call exists between two users, and the network provides a highly available service. It accomplishes this by instantiating two connections between the users' points of attachment to the network, where user traffic is replicated on both connections. Should one of the connections fail in the network, the network can bridge traffic (at the egress) from the remaining connection such that the users do not perceive any change.
User 1 Q | -— • • ^
Call
^
3 ^ —4 ^
Connections
V ^ ***»» ^x^
**^
User 2
\
w
Figure 16-4. Example of call with two connections for availability purposes
Architecting the Automatically Switched Transport Network
559
Connections associated with a call may also vary over time. A call may exist with one connection and then at, a later time, another connection may be added. Another example is when a call with a single connection experiences loss of data transfer on that connection due to a failure. The call can still remain alive while a restoration action is initiated to create a second connection that, once active, will allow data transfer to continue. Another concept originating from the PSTN world is that of supplementary services in addition to mandatory services. Supplementary services provide more information regarding an existing service that may not be needed at all times but may be signaled when desired. The service access point for supplementary services (i.e., the service interface on the component that is offering the service) does not necessarily coincide with that for other mandatory services. This implies that different protocols may be used to support the service. Possible supplementary services that might be considered for control plane application include: • Customer management of Virtual Private Networks (Closed User Groups) • Route-Query • Route fragment caching operation (Route-Recording) • Directory services/client reachability Implicit in the discussion of requirements related to call and connection control are business and operational aspects, described in Section 16.2.3 below.
16.2.3 Business and Operational Aspects Control plane deployment will ultimately be set within the context of an operator's business model, and must support the business aspects of commercial operation. Deployment will also take place in the context of the heterogeneity of transport networks, which must also be accommodated in any control plane solution. In this section, we examine control plane requirements and implications arising from support for existing business models and transport network infrastructure options. Currently existing business models, one or more of which might be used by various organizations of the same network operator [18], include: 1. An Internet Service Provider (ISP) that owns all of its own infrastructure (i.e., including fiber and duct to the customer premises) and only delivers IP-based services 2. An ISP that leases some of its fiber or transport capability from a third party, and only delivers IP-based services on that infrastructure
560
Chapter 16
3. A service provider owning, for example, an SDH infrastructure, who offers SDH, ATM, and IP services, and who sells services to customers who may themselves resell to others 4. A Bandwidth Broker (or carrier's carrier) providing optical networking services (a subtle difference between this case and the previous case is that the bandwidth broker may not own any transport infrastructure(s) that support those services, and the connection is actually carried over third party networks) The above business models introduce requirements involving operational aspects that must be supportable by the control plane. Two of the primary areas relate to trust/security boundaries and billing considerations. We note that billing also means that there has to be a commercial agreement before purchasing bandwidth. This is true for a wholesaler even when selling in the same organization. Hence, a client platform requires financial authority to buy lower layer capacity, and service management needs to be aware of it. It is clear that policy and security needs vary among service providers, and that internal network service provider choices must be respected. For business model 1, since the infrastructure is fully owned by the ISP (an unusual scenario), there are no tmst issues as the infrastructure and service providers are one and the same. This is not the case for business model 2, where some of the infrastmcture is leased, and there is a trust boundary between the infrastructure provider and the ISP. A similar situation exists for business model 3, where there is a trust boundary between the service provider business and the client businesses (e.g., regarding the degree of visibility of internal service provider network routable addresses). For business model 4, there are clearly trust boundaries among all of the involved networks [18]. In addition to trust aspects, the different billing models employed among these business models must be accommodated. For example, ISP billing tends to be flat rate for a given access bandwidth. ISP billing mechanisms are not fine-grained, are not sensitive to distance, and do not track the number of different destinations {called parties). However, for business models 3 and 4, service providers would typically be interested in assuring not only that they can bill for any value added services they provide but also that they have the ability to consider various factors/parameters in their billing policies. Additional service provider requirements that impact control plane requirements include aspects that appear to be fairly obvious from a transport network infrastructure perspective, though not necessarily so from a data-oriented perspective. Examples of these include assuring that a carrier has the ability to control usage of its own network resources, i.e., that a carrier controls what network resources are available to individual services
Architecting the Automatically Switched Transport Network
561
or users. This ability allows the carrier to ensure that critical and priority services get capacity in the event of capacity shortages [19]. It also allows carriers to deploy their resources to support Service Level Agreements (SLAs) as they best see fit, supporting carrier-differentiated SLA realization. Another example is that the control plane solution should avoid inherent assumptions regarding optimizations for, or dependencies on, particular supported client services. This is evident from consideration of the aforementioned business models, where the first two only require support of IP services and the latter two require support for a range of client services. Aside from commercial business aspects, carrier choices related to the underlying transport network infrastructure also have implications for control plane requirements. The transport infrastructure has steadily evolved to include a wide range of bearer technologies, infrastructure granularity options, flexible capacity adjustment schemes, and survivability mechanisms. Network operators and service providers have deployed a range of bearer technologies, have chosen differing infrastructure evolution strategies, and have to cope with various considerations and constraints related to their operational support system (OSS) environments. It should similarly be expected that heterogeneity would occur in the deployment of the optical control plane, involving differing control plane signaling and routing protocol options and versioning, as well as management/control plane evolution scenarios. On top of this, it will be necessary to handle multivendor and multicarrier scenarios. Thus, from a pragmatic perspective, the requirements for control plane solutions must be developed with heterogeneous environments in mind so that they are able to coexist with the existing network. In other words, there should be no assumption that such solutions will be deployed in a green field and/or homogenous environment. In summary, examination of business and operational aspects results in an understanding that • Commercial "businesses" require a strong abstraction barrier to protect their operating practices and the resources of the business from external scrutiny or control • Provided value added services must be "verifiable" and "billable" in a value-preserving way • The transport network is segmented into portions belonging to different businesses • Transport networks are inherently heterogeneous (including the means by which they are controlled and managed) • Even within a specific business, further segmentation of the network can take place due to policy considerations (e.g., choice of survivability mechanism)
562
Chapter 16
There are a number of implications arising from these statements. For example, a control plane solution that satisfies commercial business requirements would allow a carrier to provide services without exposing the internal details of its network to their customers (as in the traditional PSTN). This leads to the concept of service demarcation points. The fundamental understanding that transport networks are inherently segmented into portions (or domains, as will be more fully articulated in the next section) drives the realization that the scope of connection control would not generally be on an end-to-end network connection basis. In the context of business and operational requirements, the goal of the control plane may be stated as supporting services through the automatic provisioning of network connections across one or more managerial/administrative domains. This involves both a service and connection perspective: • The service (call) perspective is to support the provisioning of end-to-end services while preserving the independent nature of the various businesses involved • The connection perspective is to automatically provision network connections (in support of a service) that span one or more managerial/administrative domains Indeed, the desire to provide and obtain services across an interface probably colors the ASON requirements more strongly than any other aspect of switched service, and leads directly to the recognition that a network of any size automatically has several business interests taking part.
16.2.4 Reference Points and Domains Recommendation G.807 identified three substantially different interfaces between • Service requester and service provider control plane entities (UNI), • Control plane entities belonging to different domains (E-NNI), and • Control plane entities belonging to one or more domains having a trusted relationship (I-NNI) During the development of subsequent Recommendations, it became apparent that the term interface was a misnomer, as interfaces tend to suggest physical connections. In particular, while working on G.8080, it was recognized that the UNI, E-NNI, and I-NNI interfaces from G.807 are in fact reference points, in that they are logical and are described by the information flows across the points. The flows themselves were characterized in terms of network details that were exposed or hidden from an information user. Each information flow supports a service (transport, signaling, routing, discovery).
Architecting the Automatically Switched Transport Network
563
and each service may have different endpoints. (The components responsible for routing are different from those involved in signaling, and are not necessarily co-located.) However, the reference point comprises all these services. Thus, it is essential to distinguish logical reference points from the physical interfaces supported by signaling and routing protocols that are carried over a communications network. The concept of domain, which was used in a conversational sense within G.807, has evolved over time as ASON requirements and architecture specifications have matured. Initially, it was considered useful from a requirements standpoint that all the equipment operated by a single carrier had its own group name, and the term domain was typically used. As work progressed on ASON architecture and routing requirements, the concept of a control domain was introduced, and more precisely described as an architectural construct that provides for encapsulation and information hiding. The characteristics of the control domain are the same as those of its constituent set of distributed architectural components. It was understood that control domains are generally derived from architectural component types that serve a particular purpose, e.g., signaling control domains, routing control domains, etc. The nature of the information exchanged between control domains across the E-NNI reference point, for example, captures the common semantics of the information exchanged among its constituent components, while allowing for different representations inside each control domain. Continued discussion of call and connection control led to further insights regarding the relationship between operator policy and establishment of domains. In summary, the domain notion embodied in the G.805 definition of administrative and management domains, and the Internet administrative regions (e.g., Autonomous Systems), has been generalized in the control plane architecture to express differing administrative and/or managerial responsibilities, trust relationships, addressing schemes, infrastructure capabilities, survivability techniques, distributions of control functionality, etc. Thus, a domain represents, and is characterized by, a collection of entities that are grouped for a particular purpose; hence, there are different types of domains. Domains are established by operator policies and have a range of membership criteria [4]. As domains are established via operator policies, it was further recognized that interdomain reference points (i.e., UNI and E-NNI) are actually service demarcation points, i.e., points where call control is provided. With this understanding, we can speak of reference points between a user and a provider domain (UNI), between domains (E-NNI), and within a domain (I-NNI), where the • UNI is a user-provider service demarcation point,
564
Chapter 16
•
E-NNI is a service demarcation point supporting multidomain connection establishment, and • I-NNI is a connection point supporting intradomain connection establishment. The fact that domains are created by policy, and have a range of membership criteria, should not be surprising. For example, when we introduced the concept of a subnetwork in Chapter 2, we indicated that subnetworks might be delimited according to a wide range of criteria, including such factors as administrative and/or management responsibility. Just as subnetworks are characterized by the points at their edge, with little regard to the equipment inside, so domains are characterized by the policies applied to the physical interfaces at their boundaries. The rationale for creating domains and subnetworks has everything to do with considerations that make sense to network operators, without the need for standardized rules for constructing them. It cannot be overly stressed, however, that reference points and domain boundaries are essential when the supported services are instantiated on some physical interface.
16.2.5 Architecture Principles Summarizing the discussions of the preceding sections, and referring to Figure 16-5 below, the ASON architecture framework reflects the policy boundaries that exist in transport networks [20]. • Calls are end-to-end service associations. While call state is maintained at network access points, it may also be required at key network transit points where it is necessary or desirable to apply policy. • When a call spans multiple domains, and hence E-NNIs, it is composed of call segments. Each call segment runs between a pair of call-state aware points, and the concatenation of call segments creates the call. • One or more connections are established in support of individual call segments. In general, the scope of connection control is limited to a single call segment, i.e., it does not typically span multiple call segments. The collection and concatenation of subnetwork connections and link connections provides end-to-end connectivity (i.e., the network connection). Some examples of multidomain scenarios that require the scope of connection control be limited to a single call segment include the following: [20] • The service is realized in different ways within each domain (e.g., technology, QoS). • Separate address spaces are used within each domain, especially when separately administered.
565
Architecting the Automatically Switched Transport Network • •
There is independence of survivability (protection/restoration) for each domain. There is a trust boundary.
Domain 3
Domain 1
User1
User 2
End-to-end call Call segments Connections LC
SNG
-•HLC%
SNCs
LC
SNCs
LC
Figure 16-5. Example of call with multiple call segments and connections
It is clear that a generic connection setup service exists that can be implemented with either management or signaling protocols. Further, the underlying protocols need not be from the telecommunications environment, since all that is needed is verification that they can support established telecommunications needs [16]. When we consider solutions from the Internet environment, it should be recognized that these bring along underlying principles and architectural aspects. Thus, it is important to understand Internet architectural principles and implications. The influences of the Internet "end-to-end" principle, and how it compares with the use of the call/connection model found in ASON and other connection-oriented services [20], is particularly interesting. The Internet "end-to-end" principle was described in a 1984 paper coauthored by J. H. Saltzer, D. P. Reed, and D. D. Clark [21]. Arguing that certain required end-to-end functions can only be performed correctly by the end-systems themselves, in RFC 3724 it "was articulated as a question of where best to put functions in a communication system" [22]. Again referring to RFC 3724 [22], "As the Internet developed, the end-to-end principle gradually widened to concerns about where best to put the state associated with applications in the Internet: in the network or at end nodes." As described in RFC 1958 [23] and in its update, RFC 3439 [24], "An endto-end protocol design should not rely on the maintenance of state (i.e., information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoint, in such a way that the state can only be destroyed when the endpoint itself breaks." In
566
Chapter 16
particular, "Hard state, state upon which the proper functioning of the apphcation depends, is only maintained in the end nodes" [22]. Thus, the preferred architectural principle of the Internet has been that connection control should be end-to-end and that no service state should be maintained at transit points within the network. It should be observed that the desire to avoid holding some call state information at transit nodes differs from the fundamental ASON requirement to facilitate service handoff between domains. The desire to make the scope of connection control end-to-end also differs from the ASON architecture framework, where we have seen that for most cases it is necessary that connection control be scoped to a single call segment. It is important to understand these classical Internet architectural principles when considering requirements and candidate protocol solutions. However, it is equally important to understand that the Internet architecture is itself evolving. The increasing commercialization of the Internet has stimulated some rethinking of its underlying architecture [25-28]. Quoting from [25], "An architecture of tomorrow must take into account the needs and concerns of commercial providers if it is to be accepted and thus to be able to influence overall direction". Several cited examples included the need for a framework for policy controls on interprovider routing, as well support for a variety of payment models for network usage. In moving from the purely technical considerations, which are of paramount importance for a community of users with shared goals and mutual trust, to a world in which the various stakeholders that are part of the Internet may have differing and sometimes conflicting objectives, a "tussle" [27] emerges. This "tussle" requires accommodation in the evolution of the Internet architecture and results in additional design principles that are organized around such concepts as separation of concerns, enabling choice, supporting the ability to bill for value-added services, and trust issues. For example, quoting from [22], "...prior to designing the protocol, the trust relationships between the network elements involved in the protocol must be defined, and boundaries must be drawn between those network elements that share a trust relationship." In particular, some key principles that have been introduced include the following: • "Modularize the design along tussle boundaries, even if there is no compelling technical reason to do so" [27]. • "Global communication with local trust"; "transparency modulated by trust" [28] • "The [New Internet] architecture should include a general notion of regions, to express differing interconnection policies, trust relationships, multiplexing mechanisms, etc. Regions may also support distinct
Architecting the Automatically Switched Transport Network
567
addressing regimes, performing any necessary address mapping as data crosses region boundaries" [28]. • "A future Internet should be designed without the requirement of a global address space" [28]. • "The Internet design should incorporate mechanisms that make it easy for a host to change addresses and to have and use multiple addresses. Addresses should reflect connectivity, not identity, to modularize tussle" [27]. The overall conclusions about the Internet end-to-end principle have been that "the end-to-end arguments are still valid and powerful, but need a more complex articulation in today's world". An illustrative example is where "the partitioning of functioning is done so that services provided in the network operate with the explicit knowledge and involvement of endpoints, when such knowledge and involvement is necessary for the proper functioning of the service. The result becomes a distributed application, in which the end-to-end principle applies to each connection involved in implementing the application" [22]. Restating, "a distributed approach in which the end-to-end principle applies to interactions between the individual pieces of the application, while the unbundled consequences, protection of innovation, reliability, and robustness, apply to the entire application." [22] Examination of the principles articulated in next generation architecture studies, and the ASON architecture, shows a striking level of consistency.
16.2.6 Supporting Functions and Requirements In this section we provide a summary of functions and requirements described in G.807. 16.2.6.1 Connection Management In general, connections in a transport network are expected to be bidirectional and symmetric. This differs from packet networking where the path in one direction is often independent of the path in the other, and must be set up separately. However, the capability to handle unidirectional or asymmetric connections should be supportable, if desired. Thus, a fundamental control plane requirement is to support the following connection capability types (for either SC or SPC): • Uni-directional point-to-point connection; • Bidirectional point-to-point connection; and • Uni-directional point-to-multipoint connection. It is also required that the control plane provide support for multihoming, which involves support for more than one link between the end users and the
568
Chapter 16
network. This can be subdivided into multihoming to a single network operator (e.g., for the purpose of resihence or load balancing) and multihoming to multiple network operators. Control plane signaling and routing capabilities must then also permit a user to request diversely routed connections from a carrier that supports this functionality. 16.2.6.2 Routing and Signaling To support connection management, G.807 identifies a routing function, which enables paths to be selected for the establishment of a connection through one or more operator networks. The routing function operates by ensuring that each element needing to select a path through the network has sufficient knowledge of network topology and resource utilization. In general, this is done by disseminating routing information throughout the network, creating several important trade-offs, which will be dealt with in later sections of this chapter. Routing brings requirements related to structuring the network for scalability, usually performed by hierarchical schemes that reduce the volume of data needing to be transferred or stored by removing detail as one moves up the routing hierarchy. This aspect is closely coupled to addressing schemes, which should allow for address summarization and which frequently achieve this by using the routing hierarchy to create an addressing scheme. Recommendation G.807 also introduced the primary connection management processes for signaling, including basic features for the UNI and NNI reference points at source and destination, as well as introducing additional procedures that may also be supported. These processes, features, and procedures provided an outline for specific behaviors and abstract messages in G.7713. 16.2.6.3 Naming and Addressing Coupled with the previous discussion on addressing, and considering our earlier observation of the need for a strong abstraction barrier between user and provider, G.807 also states that service provider addresses should not be communicated to users. It must be observed that, in general, an address is a concatenation of names, and a name only needs to be unique within a prescribed context. In many cases these distinctions are unimportant, and the term identifier is used. An implicit ASON requirement is that identifiers be unique within a single plane, so transport, management, and control planes are not constrained to use different identifier values. Indeed, it is also an implicit
Architecting the Automatically Switched Transport Network
569
requirement that a single plane may have several disjoint identifier spaces. This comes from the G.805 modeling techniques, which describe each network layer in isolation, leading to the usefulness of separate identifiers for each network layer. Further descriptions of identifier spaces are contained within G.8080 and G.7715.1 and are provided in Section 16.3.7. Some examples of drivers for separate user and provider identifier spaces include: • Enabling customers to take their identifier with them should they relocate (number portability) and/or avoiding a need to change their identifier if an operator altered their internal network structure • Avoiding client caching of provider addresses, (security/privacy considerations aside), potentially hindering network ability to evolve to larger/different address spaces or reallocate internal addresses • Ensuring a true multiclient server network (e.g., IP/MPLS, Ethernet, ATM, TDM). This does not imply that the same type of addressing could not be used in both user control planes and provider transport control planes as long as the semantics of the two identifier spaces are separate and distinct. (This would also be in conformance to RFC 1958 [23], which mandates exactly the same principle by requiring that "the internet level protocol must be independent of the hardware medium and hardware addressing" and that "this approach allows the internet to decouple its addressing mechanisms from the hardware".) • Assuring that identifier schemes are flexible enough to allow operators to use their existing routable addresses, when they so desire 16.2.6.4 Transport Resource Management Before an ASON control plane can be used to set up connections, it is clear that transport resources must be available for it to do so, which is a planning and provisioning exercise. This is especially true when ASON is being added to an existing network, as those resources are already under the control of management systems. An important provisioning requirement is to allow for variable resource partitioning between control and management, and to assure that operations that move resources between management or control responsibility do not affect the state of the resource. This requirement allows changes to be made to the network composition or responsibilities while the network is operating. 16.2.6.5 Admission Control Both calls and connections require support functions to decide whether the network should admit a particular call/connection. Call admission control
570
Chapter 16
is performed before any connections are requested and may include checking the customers' privilege to make the call as well as checking the called parties' willingness to receive the call. The latter can be done at various times depending on later design decisions. Connection admission control in general has to do with the availability of network resources to provide the connection. As mentioned earlier, G.807 does not explicitly discuss call control functions.
16.2.7 Signaling Communications Network Requirements Any distributed control system requires communications among the elements implementing the system, and the ASON control plane is no exception. The Signaling Communications Network (SCN) is an integral, yet independent, part of the overall control plane. To maintain the integrity of control message delivery, the SCN must meet several important requirements, including the need for control message reliability to be guaranteed in almost all situations, even during what might be considered catastrophic failure scenarios. There are significant differences between packet-switched and circuitswitched networks impacting the SCN. For example, in MPLS, the control plane messages and the data plane packets share the same transmission medium and hence the same reliability (i.e., the topologies are congruent). A failure affecting data packet forwarding also affects control packet forwarding and vice versa [29]. In contrast, within transport networks it cannot be assumed that the topology of the controlled network is identical to the topology of the network supporting control plane communications. Perhaps the most obvious example for this is to consider the ASON control plane controlling a WDM transport network in which control plane signaling is carried on an Optical Supervisory Channel (OSC). As laser and receiver failures on different wavelengths are generally independent, if the OSC fails, it cannot be assumed that the traffic has failed. Furthermore, in an OSC failure scenario, it is necessary to find another route for the signaling traffic in order to get to the next node via some disjoint path. This separation allows the SCN to be independently designed, and allows for optimum use of resources to achieve the desired control plane performance. The communications network designer is able, but is no longer forced, to use the embedded channels provided by some, but not all, transport technologies. In particular, if adequately secured, a LAN or WAN could also be used. This flexibility is of particular interest when designing communications to support Switched Connections (SCs).
Architecting the Automatically Switched Transport Network
571
16.2.8 Support for Transport Network Survivability Recommendation G.807 specifies that ASON must be able to support transport network survivability. Transport network survivability may be handled by classical protection approaches (i.e., via autonomous actions within the transport plane) or by ASON control plane actions. ASON can offer new mechanisms for survivability by using signaling mechanisms to reroute a failed connection. The discussion in G.807 distinguishes between protection and restoration based upon the usage of dedicated or shared resources. In later ASON work, the distinguishing characteristic for survivability is whether or not the control plane is involved. I.e., protection is described as a mechanism for enhancing availability of a connection through the use of additional, assigned capacity, whereas restoration is described as involving the replacement of a failed connection by rerouting using spare capacity [4]. (We note that an implicit requirement is that the control plane itself be survivable.) Perhaps most important, G.807 states that user requests for explicit survivability mechanisms in a carrier network are not supported because users should not have visibility into the internal details of the carrier network. However, the user is permitted to request diverse connections—that is, a group of connections with limited common routing.
16.3.
ARCHITECTURE (G.8080)
In this section we consider the architecture of the control plane as described in G.8080. Before doing so, however, it is useful to take a short diversion to understand the transport networking and management landscape before the development of G.8080 and how this factors into new developments in control plane technology. In essence, it is the need to interwork with legacy environments while providing a framework for future developments that dictated the nature of the tools and methods employed in the G.8080 architecture. The centralized management systems developed in the last ten years or so normally contain a database of the network (for the technology of concern) that can be used for a variety of purposes, including route calculation, circuit visualization, "plan and build" processes, inventory management, and capacity management. This database can also be related to other systems that provide features such as service management, fault management (within and between technologies), trouble ticket management, fiber and cable records, and so forth. It should be noted that network management capabilities vary considerably not only between operators but also within an operator's
572
Chapter 16
network among technologies and platforms. To some extent, this is a reflection on the size of the network, decisions regarding what to automate, and the maturity of the technology. In such management systems, the centralized route calculation drives the connection setup process by means of management protocols that communicate with management agents (in the form of element managers) in network elements. The communication with the network elements is generally by means of a data communications network (DCN), which is a router network dedicated to network management functions. This architecture can also be made hierarchical. A criticism often leveled at such an architecture is that there is a single point of failure. In reality, large network management centers have duplicated systems at a fallback center and have more than one connection to a DCN. The DCN also provides resiliency so that there is generally more than one way to reach a network element to allow communication via network management protocols. For many applications, such systems are perfectly capable of managing large networks. In many ways, these systems already provide all the functionality that is often associated with a control plane, including route calculation and signaling. Their major limitations come in two distinct forms: • The connection control is too slow for switched circuits (rather than soft permanent connections). Management protocols, which are multipurpose vehicles, are simply too slow for this purpose. It is much better suited to a specialized signaling protocol. • Centralized control does not necessarily provide optimal response times for the purposes of restoration survivability mechanisms. At the other extreme, sometimes depicted (mistakenly) as the control plane, are control systems located on every network element and communicating with one another via a communications network. The centralized network management system plays no part in real-time activities such as route calculation processes, though network element static configuration parameters are still under network management control. The control systems carry out a routing information exchange process operating asynchronously in the background, and a connection setup process acts in real time between cooperating nodes. Here, each network element contains a routing table providing a set of alternative routes from itself to every other network element that shares routing information. These routing tables have the same information as the route search in the centralized architecture. However, the tables are computed using information obtained from a routing protocol whereby each network element exchanges the routing tables of its neighbors. As such, a network element can update its own routing table to provide more
Architecting the Automatically Switched Transport Network
573
current information regarding network topology. This aids the connection setup process and speeds up restoration that does not use pre-calculated routes. In the development of a control plane architecture, it could be assumed that the fully distributed model is all that is required. However, this model does not reflect the way in which control plane technology will be used in many networks or the fact that control plane functionality can also be provided by network management protocols. This situation can be easily understood by consideration of the following scenario. A network operator with a large installed base of outer core network elements that are controlled using network management protocols wants to introduce control plane technology on a new generation of network elements deployed into the inner core. In such a case, the network operator is not going to "rip out" all the existing outer core network elements and replace them and it may not be possible (or cost-effective) to upgrade them, to provide control plane functionality. In such circumstances, the problem is how to provide the end-to-end configuration of circuits in such an environment. One way of solving this problem is illustrated in Figure 16-6. The end-toend configuration and route calculation are directed by the network management system. For those parts of the connection that can be set up using management protocols, the management system calculates the route and sets up the connection. For the control plane controlled portions of the network connection, the management system delegates functionality to the control plane. In effect, the control plane network elements are collectively seen as a virtual network element by the management system. The management system provides the input and output points for the connection(s) that traverses the control plane-enabled network elements and then leaves the actual route calculation and setup to the control plane. In this scenario, it is clear that we have both central route calculation and distributed route calculation working in partnership and two different sets of connection control protocols (one network management based, one signaling based) that interact with network elements in different ways. During the initial development of the control plane architecture in the ITU-T, it became evident that what was required was an architecture that allowed the control plane functionality to be distributed in any allowable fashion, e.g., to every network element, shared by a group of network elements, or centralized. Furthermore, depending on the set of functions that are required, some functions may be centralized and others distributed in a single instance of the architecture. As an example, signaling can be combined with centralized or distributed routing. This situation led to an architecture that has as its main tool the concept of a component, borrowed
Chapter 16
574
and slightly modified, from object-oriented analysis and programming. The use of components also allows all the power of the Unified Modeling Language [30] (UML), and the software tools associated with it, to be applied.
OSS Connect messages from OSS
^'^
^•,.
Subnetwork connections created by a management protocol in this part of network Routing under control of OSS Subnetwork connections created by control plane in this part of network End points defined by the OSS, routing between these points uses control plane Network element
Figure 16-6. End-to-end configuration using a combination of network management and control plane functionality
Recommendation G.8080 is intended to provide a comprehensive model that takes into account various commercial relationships, organizational structures, and operational practices. The goal of the G.8080 architecture is to identify the external interfaces that must have protocols defined, while maintaining the ability to verify the architecture against operations scenarios and functional distributions that are required by the various requirements documents. Historically, the Telecommunication Management Network (TMN) Recommendations approached the problem from the point of view of objects viewed through an interface. This led to an equipment centric, rather coarse interface, which did not allow an easy distribution of the necessary functionality to the most appropriate network element. An attempt was made to improve upon this approach by using the techniques of Reference Model for Open Distributed Processing (RM-ODP), which constitutes a framework of abstractions for the specification of open distributed systems. By enabling a separation of concerns, it provided a means for separating the logical specification of required behaviors from the specifications of physical architectures implemented to realize them [16].
Architecting the Automatically Switched Transport Network
575
The application of RM-ODP to telecommunications has been specified in ITU-T Recommendations G.851-01 [31], G.852-01 [32], G.853-01 [33], and G.854-01 [34]. These techniques take the approach of viewing the desired system from the point of view of the Enterprise, Information, Computation, and Engineering decisions that have to be made. The end result is a more fine-grained collection of interfaces, each providing a simple service that can be assigned to network elements to provide a wide range of solutions, each meeting different needs. However, this end result did not lend itself very well to constructing scenarios to verify that the interfaces specified were necessary and sufficient, since a tremendous amount of system behavior actually occurs within a network element, and internal implementations are not subject to standardization. In order to avoid the verification problems of the earlier work, G.8080 created a component architecture to facilitate the construction of reasonable scenarios. In UML, a component is defined as "a physical and replaceable part of a system that conforms to and provides the realisation of a set of interfaces" [30]. A component in this sense typically represents the physical packaging of otherwise logical elements, including classes and interfaces. In the context of G.8080, a component is defined as "an element that is a replaceable part of a system that conforms to and provides the realization of a set of interfaces". The subtle difference is that a component in G.8080 represents an abstract entity rather than a piece of implementation code. Thus, in this context, components represent logical functions rather than physical implementations. With this in mind, UML can be used in describing the G.8080 architecture. The means of deciding upon interfaces used the same analysis and design techniques from the RM-ODP application to telecommunications. Components were created by considering the lifetime of the objects in the system and the span of control of the resulting component. The result is a small set of components that support a wide range of implementation choices and allow scenarios to be constructed to validate the architecture against requirements. It is important to realize that the G.8080 architecture specifies components and interfaces on a per G.805 layer network basis. In what follows, we first consider how the control plane views network resources and then consider the components that make up the control plane. We note that the architecture described in G.8080 not only applies to connection-oriented networks but also could be employed, with some modifications, in connectionless networks. This outcome could be achieved by describing the transport network using G.809, which is a flow-based version of G.805. To give a hint as to how this might be accomplished, consider a flow in the limit which consists of a single packet. This packet
576
Chapter 16
can be considered as a self-describing short-lived connection that simply uses and releases transport resources as it moves through the network. Alternatively, consider the connection setup and release process operating at a faster and faster rate. Aside from some minor changes to accommodate terminology differences between G.805 and G.809, the only major change to the G.8080 architecture would be the removal of the concept of a call, which simply becomes a null function in the architecture. With this in mind, G.8080, with appropriate modifications, can be used to describe existing and future connection-oriented and connectionless control planes. We can therefore conclude that G.8080 can be used as the basis of a control plane architecture for any transport technology.
16.3.1 The Control Plane View of the Transport Network The description of G.805 transport network functions makes no reference to the control and management of these functions. Depending upon the desired control or management view (e.g., connection, fault, performance management), not all aspects of transport network functionality are of relevance. Thus, it is necessary to abstract the particular aspects of transport network functions that contain information relevant to the specific view. From the perspective of control, the relevant view is concerned with the management of connections. Some key abstractions that are relevant to the control plane are illustrated in Figure 16-7 and enumerated below: • The subnetwork points (SNPs) that need to be associated to form a connection (these are simply an abstraction of the connection points (CPs) in G.805) • The subnetwork connection (SNC) that represents the dynamic relationship between SNPs on a subnetwork • The link connection (LC) that represents a static relationship between SNPs in different subnetworks • A set of SNPs that can be grouped for the purpose of routing, thereby forming a subnetwork point pool (SNPP) • An SNPP link, which is a link associated with SNPPs in different subnetworks. The link contains LCs formed by the association of SNPs.
Architecting the Automatically Switched Transport Network
577
y Subnetwork ,
-§MC . r ^ .
SNP Link Connection / ^
SNC
Figure 16-7. The relationship between entities in the transport plane, the management plane, and the control plane [4]
Another key abstraction that is required for the purposes of routing is the routing area (RA). An RA is defined as being composed of a set of subnetworks, their interconnecting SNPP, links and the SNPPs that represent the ends of SNPP hnks exiting the RA (ilhistrated in Figure 16-8). This setup allows links to be addressable within the RA, hence allowing for step-bystep routing. In contrast, for a subnetwork, only the ends of the link connections are visible from within the subnetwork. We note that the critical distinction of link end visibility is only important to an observer inside the routing area. From the outside, subnetworks and RAs are identical, and this causes the terms subnetwork and RA to be used almost synonymously. The distinction between the two is usually obvious from the context. In the context of routing discussions in G.7715 and G.7715.1, the term node was adopted to denote either a subnetwork or an RA. This decision was based upon the earlier definition of RA within G.8080, where the lowest limit of recursion of an RA was two subnetworks interconnected by a link. In fact, with the updated definition provided in G.8080 Amendment 2 (i.e., the lowest limit of recursion of an RA is a subnetwork), a node and an RA are considered synonymous. As a result, RAs also have the property of recursive containment similar to subnetworks. This property enables support for hierarchical routing schemes. Recommendation G.7715 defines how successive sets of contained RAs form a routing hierarchy. Routing areas are thus the key concept that matches the organization of the control plane to the organization of the transport plane. We note that the scope of the management abstractions for the CTP and TTP objects is different from those in the control plane, reflecting their
Chapter 16
578
different roles and areas of responsibility. This distinction is also immediately apparent by describing the resources that the control plane manipulates in terms of G.805 architecture constructs. Partitioning
Routing area Subnetwork SNPP SNP
•
CTP(M.310O)
9
SNPP Link
SNP Link Connedion
^
N: c>
Unk Connection .
rt
Figure 16-8. Routing Areas, subnetworks, SNPs and SNPPs [4]
Now that we have introduced the abstractions that the control plane needs in order to manipulate resources in the transport plane, we can turn our attention to the manner in which this outcome is achieved.
16.3.2 Identifying Components The RM-ODP-based methods used to construct the G.8080 architecture focus on a single aspect (called a viewpoint) of the problem and solution space at a time. The ODP viewpoints are as follows: 1. Enterprise viewpoint, which is concerned with the purpose, scope, and policies that govern the activities of the specified system 2. Information viewpoint, which is concerned with the types of information handled by the system, together with applicable constraints 5. Computational viewpoint, which is concerned with the functional decomposition of the system solution into a set of objects that interact at interfaces, thus enabling system distribution 4. Engineering and Technology viewpoints, which are concerned with the infrastructure and choice of technology used to support the system As the intent of standards is to allow interworking, rather than to proscribe implementations, G.8080 makes the most use of the Information
Architecting the Automatically Switched Transport Network
579
and Computational viewpoints and limits itself to component interfaces that are essential to distribution. The Computational viewpoint is concerned with objects (in this context, G.8080 components) and interfaces. One may wonder how the objects/components in G.8080 were identified, as every Object-Oriented design method has its own description of how to find objects. Recommendation G.8080 built on existing work from the space of distributed transport management applications, which provided a basic set of objects that support network topological aspects, and then some more general principles were applied to identify additional components. This work is further described below. Work prior to G.8080, involving centralized control via management interfaces, assigned a subnetwork performer computational object [16] to manage the subnetwork and the link. The subnetwork performer embodies all the information there is to know about the subnetwork, with the most important information being the internal structure of the subnetwork (its internal subnetworks and links), which is essential to be able to route a connection across the subnetwork. Similarly, one can consider a link performer computational object that embodies all that can be known about the link—in particular, its composition in terms of sublinks and individual link connections. This performer would also be responsible for preventing the same link connection from being allocated to more than one connection request. Recommendation G.8080 takes many of the ideas associated with these performers, rather than the performers themselves, as axiomatic. In a distributed system, there is no single platform that can support these performers as single objects. Further, it was recognized that not all aspects of a performer need to be available at the same location or at the same time. This leads to a different distribution of routing information from signaling control (and hence a different collection of components and interfaces). Recommendation G.8080 components (i.e., RC and CC, and LRM, respectively, as described in Section 3.4) reflect the distribution of performer operations, factoring in the above considerations. The services these performers offer are realised by the collaborative interactions among their associated components. A final critical consideration involves component lifetime and degree of coupling with other components (and coupling with the transport infrastructure). This consideration has led to only one component being directly involved in any aspect of the underlying transport hardware (i.e., TAP, as described in Section 16.3.4).
580
Chapter 16
163.3 General Component Properties and Special Components The component and its interfaces are illustrated in Figure 16-9. The interfaces are defined based on the operations that the component is intended to carry out and are, therefore, component specific. Recommendation G.8080 also defines some component properties, expressed as special interfaces that every component can be assumed to have, though these are not mandatory. These special interfaces allow monitoring of the component operation and dynamically set internal policies and behavior. In addition, a special class of component {Port Controller) is provided to deal with external policies such as security. For example, one role of the Port Controller component is to validate that an incoming user connection is sending traffic according to the parameters that have been agreed upon in the service-level agreement.
1.
Messages
•
Interfaces
1
< name>
Figure 16-9. The component and its interfaces
The general component model describes protocol-neutral interfaces, which exchange primitives between components. There is one exception to this in the form of the Protocol Controller component class. This class combines several primitive streams into external protocols, which enable various distributions of the components among physical platforms.
16.3.4 Component Overview The control plane architecture can be described by means of a library of components that are illustrated in Figure 16-10.
Architecting the Automatically Switched Transport Network RC
CC
PC
(a) Routing Controller
(b)Connection Controller
(c) Protocol ContioUer
"^CaSkg ^PCC
Calkd PCC
J Netwofk CaBC
(d) Calling Party Call Controller
581
(e) Called party Call Controller
(f) Network CaU Controller
^LRMA
(g) Link Resource Manager A end
(h) Link Resource Manager Z end
0A
TAP
(i) Discovery Agent
(j) Termination & Adaptation Performer
Figure 16-10. The control plane component library
The components are summarized below. 1. Routing Controller (RC) The Routing Controller component is derived by distributing some functionality of a more abstract object called the Subnetwork Performer, which has complete information about all the contained nodes and links within its RA. Routing Controllers belonging to the same RA cooperate to ensure that each RC has a complete view of the internal RA topology. This cooperation takes place via a Routing Protocol and the results are made available to other components via the routing table. 2. Connection Controller (CC) The Connection Controller component is also derived from the Subnetwork Performer. Connection Controller components cooperate to set up connections. This is done by consulting the path computation function in the RC, which then returns the set of nodes and links to be traversed in order to reach the specified endpoint. 3. Link Resource Manager (LRM) The LRM is derived from the Link Performer, which knows all there is to know about a link, by distributing functions to both link ends (LRMA and LRMZ). LRMs are responsible for managing the resources available to the link and allocating a specific link connection when requested. LRMs also cooperate to avoid two connections being allocated to the
582
Chapter 16
same link connection when the connections are being set up from each end of the link. 4. Calling/Called Party Call and Network Call Controllers (CCC, NCC) Call Controller components cooperate to control the setup, release, and modification of calls. They are relevant to service demarcation points (i.e., UNI, E-NNI). As discussed earlier, these service demarcation points are established via inter- and intraoperator policies. Such policies can be applied in several different ways; i.e., either centrally or on each switch or at signaling aggregation points. (The first and the last imply a different distribution of function from either Connection Controllers or Link Resource Managers; this differing distribution dictates that call controllers are different components from either CCs or LRMs.) Network Call Controllers (NCCs) are relevant at the E-NNI and UNI (on the network side) service demarcation points. It is the NCC that makes the choice of technology to support the service by translating service requests into technology choices. This setup meets the domain boundary opacity requirements and allows the network to be most flexible. The NCC also handles other aspects of calls, such as restoration. The restoration architecture, to be described in Section 16.3.9, supports restoration between domain edges. The need for restoration, or lack thereof, is a call property, and the activation of restoration is within the lifetime of a call. Thus, there is no need for an additional component to support restoration. The case of the end user of the network is special, and because of this two additional call controllers have been defined. The Calling and Called Party Call Controllers (CCC) are relevant to the user-provider service demarcation points and are the components that access the network on behalf of the end user of the service. 5. Protocol Controller (PC) ASON components are defined on a per-layer network (G.805) basis and, where appropriate, at a single level in the routing hierachy. They communicate over abstract interfaces using primitives, so called to distinguish logical communications between component interfaces and the communication via an implemented protocol over physical interfaces. Protocol Controllers shield the components from any protocol details that are irrelevant to the component. (An example would be reliable message transport; the component assumes it, and a protocol controller provides it. Another excellent example is related to providing a layered security architecture. Security and authentication are provided by Protocol Controllers, not by the components themselves.) Protocol Controllers also allow primitives from several components to be merged into a single
Architecting the Automatically Switched Transport Network
583
message stream, thereby allowing implementations that handle as many layers and levels as is useful. 6. Discovery Agent (DA) The Discovery Agent deals with network resources that have not yet been assigned to a layer network. (An example could be cross-connects that can switch a wide range of signal types). The DA is derived by distribution of an abstract object that knows about all the uncommitted resources and learns, or verifies, how they are interconnected. After this learning/verification, the resources can be assigned to the desired layer network or link. 7. Termination and Adaptation Performer (TAP) All networks are ultimately supported by physical equipment, which needs to be controlled at some point in its lifetime. However, it is not necessary for ASON components to know anything about the hardware supporting the network, as ASON operations are hardware independent. The TAP is the only ASON component that understands hardware and must therefore be collocated with that hardware. The role of the TAP is to hide the details of physical equipment operation from ASON. Examples of hidden operations include the adjustment of the adaptation function when hardware capable of supporting several signal types is used, and the suppression of alarms when a link connection is left intentionally unused. We note that there is also a Traffic Policing component (TP), which is a subclass of the Port Controller component described in Section 16.3.3. When an incoming user connection sends traffic that violates the agreed parameters, the TP may instigate measures to correct the situation. Traffic policing is important when dealing with packet switched networks, and is included in ASON for completeness. However, it has no function in conventional circuit switched networks.
16.3.5
Interlayer Modeling
As discussed earlier, the G.8080 architecture specifies components and interfaces on a per-G.805 layer network basis. For a transport network that supports multiple adaptations, an ASON instantiation could logically contain multiple ASON control planes, one for each layer network. A client with a UNI interface could request different layer services from the same UNI implementation. In such a scenario, there is no dependence between calls requesting connection services at different layers. On the other hand, transport services exist where the client layer has no resources in the network except at the edges. An important example of this scenario is when
584
Chapter 16
Ethernet traffic is carried across a SONET/SDH network, in which there are no Ethernet switches or Ethernet Hnks, on behalf of a cHent that has requested Ethernet service. In addition to the Ethernet/SDH chent/server example, the interlayer model also applies to the relationship between a layer network that supports virtual concatenation and its server layers. Thus, it is important to be able to model the associated interlayer interactions that must be supported in such scenarios. The above scenarios have been addressed in recent G.8080 developments related to the extension to the Network Call Controller (NCC) component to include an interlayer interface that enables it to have a relationship with that server layer call. This relationship is recursive so that a set of related adaptations are formed. In other words, the NCCs display a recursive G.805 client/server layering relationship. This characteristic is analogous to the stack of adaptations represented by the TMF 814 PTP (Physical Topological Link Termination Point) construct [35]. This setup may be viewed as creating a "stack" of NCCs at different G.805 layers. Wherever an adaptation occurs in a stack of adaptations, an NCC at that layer is created. The decision to use an interlayer NCC interface is driven by policy, as there may be choice regarding which server layers to use. Figure 16-11 illustrates a two-layer example. In this example. Layer A does not have a connection between its NCCs because that transport layer is not present between them. Instead, an adaptation to a server layer (layer B) exists. Associations (labeled 1 and 2) between NCCs at the two layers exist to correlate the service at layer B being used by the client layer A. The model can be generalized to supporting multiple client NCCs with a single server NCC.
Layer B call segment ^ - ^ connection Figure 16-11. Layered Network Call Controllers
The interlayer interface to the NCC enables a client NCC to initiate the relationship with a server NCC or vice versa. When a server NCC initiates
Architecting the Automatically Switched Transport Network
585
the relationship, it presents a pair of SNPs (ends of a network connection) that can be used by the cUent layer for transferring client CI. The connection presented is able to transfer client CI, and no call action at the server layer is initiated. This process is used for an operation where a server layer has already established a call and this connection is presented to the client layer at a later point in time. The client layer may accept or reject the use of the offered SNP pair (connection). This model accommodates the business scenario where the adaptations occur in a single administrative domain as well as in multidomain scenarios (e.g., a scenario in which each layer network is operated by a different carrier). In the latter case, the NCCs may be on different platforms, and the interface between them may need to be exposed. In both cases, the instantiation of the NCCs is still independent on a per-layer basis. For example, a server layer may have a centralized NCC, whereas the client layer may have distributed NCCs. Other components do not require interlayer interactions because once an NCC determines that resources from its layer are to be used to support the call, subsequent actions are taken only within that layer (especially connection control and routing control). This setup confines interlayer knowledge and actions to the NCC. Note that this process differs from sending information about multiple layers in a protocol controller that serves multiple layers (e.g., routing) because the interlayer call model maintains a client/server layer relationship, whereas sending multiple layer information over an interface does not imply that the information between layers is correlated in any way.
16.3.6 Distribution models The G.8080 component architecture identifies components in such a way that the most commonly used distributions of functionality are supported. However, before discussing actual distributions, it is useful to discuss architectural principles that result in some components being fixed. These components are called anchored components (or anchored objects in other contexts). As G.8080 provides the foundation for specification of external interfaces needing standardization, an important principle is that of reducing the number of different interfaces, as well as simplifying those interfaces. For example, we see that the CC provides the same interfaces regardless of the size of subnetwork being controlled. Thus, rather than creating a completely new interface to a switching element, we simply note that the lowest level CC is anchored to the switch, i.e., it is fixed in the switching equipment. All other connection controllers can be freely distributed anywhere in the network. Similar arguments apply to the DA and TAP
586
Chapter 16
components, which are similarly anchored to the equipment they are responsible for. These decisions reduce interface variation and complexity. The architecture is designed to support the independent distribution of routing, switch operation, link control, and call control. A wide range of system designs, ranging from almost all functions being centralized to almost all functions being fully distributed, is possible using the same architectural components and standard interfaces.
16.3.7 An Example of Components in Action So far we have limited our discussion to the stmctural modeling of the control plane by identifying the types of component that are of interest and their interfaces. Describing the associations between components can identify further structure. This modeling of the static aspects of a system allows us to describe and specify the things that make up the control plane. UML provides tools for achieving this by means of class diagrams and object diagrams. However, what is really of interest in the G.8080 architecture is the interaction of control plane components with one another. This interaction occurs as a result of messages being exchanged between a group of components to achieve some defined purpose. An interaction and messages can be formally defined as follows [30]: "An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose. A message is a specification of a communication between objects that conveys information with the expectation that activity will ensue". UML allows the dynamic aspects of the system to be described using interaction diagrams. This form of diagram allows several forms of action to be modelled as indicated in Table 16-1. Message Type Call Return Send Create Destroy
Table 16-1. Messages and actions Action Invoking an operation on a component. A component may send a message in the form of a call to itself. Returns a value to the requestor Sends a signal to a component. A signal is a named object that is sent asynchronously, e.g., an exception Creates a component Removes a component
(Note that the meaning of call in UML is in the context of UML as a modeling language and not as described in the network context.)
Architecting the Automatically Switched Transport Network
587
Interactions may simply be between two components. Alternatively, a message transmitted from a component to a second component may result in the second component generating a message that interacts with a third component and so forth. In this case, it is often useful to include information regarding the sequence of the messages. Such interaction diagrams in UML are referred to as sequence diagrams. An interaction may be between components of the same type or a set of components that contains different types of components. An example of the former in the control plane is the exchange of routing information between Routing Controllers. This is illustrated in Figure 16-12. Messages are exchanged via the Network Topology interface on each RC, and this information is used to configure routing tables with network topology information and network topology update information. An example of different components interacting is in the setting up of a connection. A simplified example is illustrated in Figure 16-13. The reason why we simplified the discussion is that connection setup behavior actually depends on the means of routing, e.g., hierarchical routing, step-by-step or source-based routing. G.8080 describes these interactions in detail. In our simplified example, the role of the RC is different from that of the previous example, and the interaction with the component is by means of a different interface.
r~ r~n ^^
\^
P>
RC
'v ' — T — '
>k
>k^ Broadcast local route table to nearest neighbors
>f
^VK >f "v ^—T—'
i n
Hr
^^
^ ^
RC
Figure 16-12. Exchange of routing information
The sequence of events is as follows: 1. A connection request arrives at connection controller a (CCa). 2. The CCa component queries the routing component (RC) by means of a Route Query request. The RC returns the outgoing link to be used.
Chapter 16
588
3. The CCa component then interacts with the Link Resource Manager to allocate SNP link connections. The LRM responds with acceptance or rejection of the request. 4. Once the CCa component receives confirmation from an LRM that the connection request has been accepted, a subnetwork connection can be established across the subnetwork controlled by the connection controller. The remaining parts of the sequence show the flow of confirmations that the connection has been set up. This continues until the confirmation is returned to the original user. The above is, as stated above, a much simplified version of an interaction provided for illustrative purposes. Recommendation G.8080 provides more detailed interaction diagrams for connection setup and call control. However, G.8080 does not describe all possible interactions between components. This is intentional, as more detailed interactions are protocol specific and can be described in recommendations derived from G.8080.
RC
2. Route Table Query]
. Connection Request 4. Connection Request N+1. Connection Confirmation
3a. SNP Link Connection Request
N. Connection Confirmation
CCb
3b. SNP Link Connection Request
LRM
Figure 16-13. Setting up a connection
16.3.8 Identifier Spaces When working with a distributed control plane, a consistent set of identifiers needs to be developed for use in the configuration and operation
Architecting the Automatically Switched Transport Network
589
of the signaling and routing protocols. Recommendation G.8080 has recognized four categories of identifier spaces that are used in the ASON architecture, specifically: • Identifiers for transport resources used by the control plane • Identifiers for control plane components • Identifiers locating control plane components in the DCN • Identifiers for transport resources used by the management plane Before discussing these identifiers and their use, it is necessary to define the two types of identifiers that exist, specifically names and addresses. Names are identifiers used to reference an instance. It should be understood that more than one name may exist for an instance, and a particular name may be only valid within a specific scope. Moreover, names for an instance are allowed to change. However, since names do not imply any specific structure of a set of instances, they are not required to be summarizeable. Addresses are identifiers that locate an instance in a topology. While addresses may be composed of names, whenever a name used as a component in an address changes, the location in the topology does not. Since addresses are defined in terms of locations in a topology, they are inherently summarizeable. This means that there is a common prefix for all instances located within the common part of the topology. Two examples of a name are the number for a mobile phone and freephone (or "1-800") numbers. In each case, a mapping is required from the name to an address. This can be accomplished with a directory function. Addresses and names have a scope associated with them, and the larger the scope, the more elements are needed in the identifier itself. At the highest scope (i.e., global), the identifier is complete in the sense that no further information is needed. Within a smaller scope, the identifier is relative to that scope and does not have the same meaning outside of that scope. For example, global telephony numbers include country codes whereas within a city, shorter numbers may be used but are relative only to that city. We observe that the terms name and address were not cleanly distinguished in standards documents through 2004, and consequently there is inconsistent usage of these terms. In the text below, we will use the term identifier unless the distinction is critical to the understanding of the discussion. It should also be emphasized that the syntax of an identifier format does not imply that the identifier is a name or address. For example, usage of an IPv4 syntax for a particular identifier does not imply that it represents an IP address. For example, when such syntax is used to identify transport resources, these identifiers are clearly not IP addresses. The various identifier spaces, and their relationships, are illustrated in Figure 16-14. Here, the transport plane resources are multiply identified by
590
Chapter 16
name spaces in other planes. The 0AM identifiers in the management plane include equipment names and CTP names. Within the control plane, both UNI/E-NNI Transport Resource and SNPP identifiers are also applied to transport resources. DCN (Data Commimications Network)
Views of transport plane resources
Transport Plane Resources
Figure 16-14. Identifier spaces and relationships [14]
16.3.8.1 Transport Resource Identifiers Transport resource identifiers are used by ASON control components to refer to G.805 transport plane resources. Two such identifiers are used [4, 36, 37]: UNI/E-NNI Transport Resource and SNPP. UNI Transport Resource identifiers are used to identify transport resources at a UNI reference point if they exist. Similarly, E-NNI Transport Resource identifiers are applied to transport resources at an E-NNI reference point. They represent the resources between the client and network (or between networks), not the transport network endpoints. These identifiers were referred to as UNI Transport Resource addresses in the 2001 version of G.8080, and as Transport Network Assigned (TNA) addresses in OIF UNI 1.0 [36]. However, the context of their usage indicates that they are, in fact, names that the calling party call controller and network call controller use to specify destinations in making a call (see Section 16.8). This was recognized and reflected within OIF E-NNI 1.0 [37] and G.8080 Amendment 2, i.e., the term UNI Transport Resource name is used in this context.
Architecting the Automatically Switched Transport Network
591
SNPP identifiers provide a link context for SNPs and are used by the control plane to identify transport plane resources. It is important to note that control plane component identifiers cannot be used as SNPP identifiers because they are from the wrong space. The G.8080 architecture allows for multiple SNPP identifier spaces to exist for the same transport resources. An SNPP address must be unique within the RA terminating the SNPP hnk. In general, an SNPP address is the concatenation of the names of any enclosing RAs, the lowest subnetwork, and any additional link context. This scheme allows SNPs to be located at any routing level. The SNP address is derived from the SNPP address concatenated with a locally significant SNP index. Depending on the scope of an SNPP, not all elements of the address are needed. For example, an SNPP address within the scope of a matrix (i.e., the smallest subnetwork) may have just the matrix identifier and a link identifier. An SNPP address at the top of the routing hierarchy may have just an RA identifier, and an SNPP address in the middle of the routing hierarchy may have a sequence of enclosing RAs plus a link identifier. UNI/E-NNI Transport Resource names are distinct from SNPP addresses because of the G.807 constraint that users should not be given internal network addresses. UNI Transport Resource names must be bound to SNPP addresses in order to enable routing across "the network" between transport resource names at the A-end and Z-end of a call. This binding may be changed without changing service aspects. In order for connection management to establish a connection to a destination UNI Transport resource name, an address resolution function is needed to map it to a corresponding far-end SNPP address (or addresses). The relationship between UNI/E-NNI Transport Resource names and SNPP addresses may be any of the following: • 1 :n — One UNI/E-NNI Transport Resource name may map to multiple SNNP addresses at the same reference point. • n:l — Many UNI/E-NNI Transport Resource names may refer to one SNPP address at the same reference point. • m:n — Many UNI/E-NNI Transport Resource names may refer to multiple SNPP addresses at the same reference point. The first two cases are illustrated in Figure 16-15.
Chapter 16
592 UN I Transport
AGC
SNPP1 Resouice 1
m
UNI-C
MatTK 1 (NeVrork Element)
SNPP2
a) Multiple SNPPs to one UNI Transport Resource
Anr.
UNI Transport Resources 1, 2
UNI-C
*
Matrki (Network Element)
SNPP1 b) Multiple UNI Transport Resources to one SNPP
Figure 16-15. SNPP and UNI Transport Resource relationships
16.3.8.2 Control Plane Component Identifiers Control plane components also require separate identifier spaces, since they may be instantiated differently from each other for a given ASON network. For example, one can have a centralized NCC with distributed CCs. Thus, separate identifiers are needed for RCs, NCCs, and CCs. Additionally, the PCs that are used for protocol-specific communication also require a separate identifier space. For example, the identifiers for the Signaling PCs must be unique in order to unambiguously specify a particular signaling channel [37]. 16.3.8.3 Data Communications Network Identifiers To enable control plane components to communicate with each other, a Data Communications Network (DCN) is used (described in Section 16.4). DCN addresses identify the points of attachment for the signaling and routing PCs that instantiate control plane communication functions (generating and processing messages in protocol specific formats). We note that several PCs may share a DCN point of attachment, and any given network element may have multiple points of attachment. For example, the signaling PC DCN address refers to the point where the signaling PC attaches to the DCN. Thus, the signaling PC DCN address is based on the topology of the DCN carrying signaling messages, rather than the topology of the transport plane or control plane components.
Architecting the Automatically Switched Transport Network
593
16.3.8.4 Management Plane Identifiers These identifiers are used by management entities that are located in Element Management Systems (EMSs) and Network Management Systems (NMSs). Identifiers used for OAM purposes include those defined for the TTP (Trail Termination Point) and CTP (Connection Termination Point) [38], illustrated in Figure 16-7. TTPs represent the signal state as a signal leaves a layer network and are associated with the G.805 termination function, while CTPs represent the signal state as it enters a layer network and are associated with the G.805 adaptation function. Existing operations, administration, and maintenance (OAM) address spaces generally describe a physical locality that supports maintenance and fault correlation activities.
16.3.9 Restoration Architecture There are several techniques available to enhance connection availability, which refers to the ability of the connection to provide service even though there is a fault in the network. Recommendation G.805 describes transport network availability enhancement techniques. The terms protection (replacement of a failed resource with a preassigned standby) and restoration (replacement of a failed resource by rerouting using dynamically allocated spare capacity) are used to classify these techniques. In general, protection actions complete in the tens of milliseconds range, while restoration actions normally complete in times ranging from hundreds of milliseconds to up to a few seconds. For G.8080, however, the mechanisms supporting the technique by which the connection is restored are far less interesting than whether the control plane is engaged in restoring it. Recommendation G.8080 therefore extends classical protection and restoration definitions to classify protection as any mechanism that is autonomous and requires no control plane intervention (no rerouting). Similarly, restoration is classified as any mechanism that is operated by control plane actions since these operations always involve rerouting the connection. In principle, rerouting can occur over any portion of the network, and it intuitively feels best to only replace the failed component (link or node). However, it is not always easy to determine which component has failed in a timely manner; neither is it easy to determine which points should switch in response to the failure. It is also advantageous to subdivide a large network into a number of independent recovery domains. Different mechanisms, which are appropriate to the topology and capabilities of the equipment deployed, may then be used in each domain. In this manner, a clean separation is provided between the networks of different operators or
Chapter 16
594
between work forces within a single network, and the availabihty is improved when the size of a restoration domain is Hmited. G.8080 has adopted the ATM Forum approach [39] towards domainbased rerouting. The G.8080 rerouting domain model is illustrated in Figure 16-16.
Rerouting Domain
Destination Node
Rerouting Domain or /
(DA)W
(LKUT
rrApV-"^
Figure 16-23. Components of discovery architecture
The involved components and their roles are as follows: Discovery Agent (DA). The DA provides the necessary coordination for the discovery process. This includes collection of hints from the necessary components and coordinating with the DA on equipment matrices that may be controlled during the discovery process. Note that fully transparent switches cannot be bound to a particular layer network until discovery is complete. (This is because the characteristic information is determined by the trail supporting the discovered link connection). Because DAs may interact with other DAs in the network, it is important to recognize that DAs need identifiers having global scope. Termination/Adaptation Performer (TAP). The TAP provides a view of the status of the physical resources, e.g., link connections and trails (CTP and TTP). Since the TAP is associated with the G.805 termination/adaptation compound function (described in Chapter 2), it can be used to provide hints from the test-signals (the test set, CTP/TTP information) and from nonintrusive monitors (e.g., nonintrusive SNC monitors). We note that discovery operates on transport resources before control plane aliases (SNPs) have been allocated, so it uses CP and TCP names to discover CTP-CTP LCs. Link Resource Manager (LRM). The LRM provides the status of the link in terms of the allocated and available number of LCs. After the discovery
Architecting the Automatically Switched Transport Network
607
phase, SNPs are assigned to the discovered CPs and the LRM is configured with the SNP connections. This assignment is considered to be a management operation that may be delegated to the network element. This allows for "plug and play" operation as a specific management policy. The LRM may also provide hints related to link discovery (e.g., link name). Protocol Controller (PC). The PC provides for the protocolencapsulation of the primitives that constitute the DA-DA interaction. The protocol controller attaches to the signaling network point of attachment, which can be thought of as the DA signaling address.
16.6.3 Types of Discovery Recommendation G.7714, as first published in 2001, defines three general types of discovery functions that can be performed: (1) Layer Adjacency Discovery, (2) Control Entity Logical Adjacency Establishment, and (3) Service Capability Exchange discovery. In the years that followed, further architectural foundation was laid for auto-discovery within G.8080, which had implications on G.7714 concepts. At the time of going to press, G.7714 had just undergone revision and restructuring. Revised G.7714 (2005) provides clearer requirements for the discovery process, refines the terminology used for the transport entities being discovered, extends the use of discovery to the management plane, and provides more detail on the behavior of the Capability Exchange process (renamed Transport Entity Capability Exchange). The Capability Exchange processes in support of the control plane will be provided in a new Recommendation under development, G.7716, which addresses the initialization and restoration of the control plane. 16.6.3.1 Layer Adjacency Discovery Layer Adjacency Discovery (LAD) describes the process of discovering transport network connection and link connection endpoint relationships and verifying their connectivity. In the most basic terms, determining "who a network element's neighbor is at a given layer" is what layer adjacency discovery is about. Not all equipment will necessarily terminate/interpret/alter the characteristic information at all the layers. For example, in Figure 16-24 we show a simplified functional block view of an SDH/optical network comprising eleven network elements (NEs). Two of these network elements are optical amplifiers (NE #3 and #9), and two are WDM multiplexers/demultiplexers, all of which only understand and act upon the physical layer. Two of the elements are SDH HOVC O-E-O switches (NE #4
608
Chapter 16
and NE #8), which act upon the SDH physical, RS, MS, and HOVC layers. The end-user equipment, shown as routers in this example, is also assumed to act upon all the layers, i.e. physical, RS, MS and HOVC. 1^
^
NE#1
NE#3
Routei
X
OC-3 1
OC-3
AMP
X
oxc
OC-48 I X OC-48
oxc
NE#4
NE#6
NE#8
AMP NE#9
Rou^d NE#11
Router
L : : ' ••'• '• "•'.:J
NE#7
NE#5
NE#2
NE#10
Figure 16-24. Example SDH network scenario
Looking at Figure 16-24, for example, we can see that NE #1 has a physical layer adjacency with NE #3, as illustrated in Figure 16-25. PHY (physical) layer adjacency
MS
yw— NE#1
w
NE#3
./NE#4
MS
"^ 'V'
\oi^ V'
'^pY 'V'
NE#5
NE#6
NE#7
MS
""^
\PH7
v..
NE#9
V
NE#11
NE#as MS
NE#2
NE#10
Figure 16-25. Illustration of physical adjacency
Examining Figure 16-26, we can see NE #1*8 and NE #2's RS layer adjacencies with NE #4 (and NE #8's with NE #10 and NE #11).
w
w NE#1
V
NE #>••'''
NE^
NE#5
NE#6
w
MS
RS layer adjacency
NE#7
f: NE#8
/
V "'ME^ "••••••••., \
MS
NE#11 w MS
V w
w NE#2
NE#10
Figure 16-26. Illustration of RS layer adjacency
Architecting the Automatically Switched Transport Network
609
Similarly, Figure 16-27 illustrates NE # r s and NE #2's MS layer adjacencies with NE#4, and NE #8's MS layer adjacency with NE #10 and NE#11.
V
-M^^: •••••
NE#1
jSfE#3
'
V
MS layer adjacency
^MS
^
NE#4
^?W
W ^
^fW
NE#5
NE#6
NE#7
NE#8
'•"•MS""
NE#^
NE#n
•••MS-'
NE#2
NE#10
Figure 16-27. Illustration of MS layer adjacency
Finally, Figure 16-28 illustrates similar HOVC layer adjacency relationships. Different discovery message sets would have to be used to discover adjacencies at the various layers (e.g., RS, MS, or HOVC). The exact LAD methods and protocols are described in greater detail in Section 16.11.1. HOVC layer adjacency \iir»/
XHQ/
/W"
•'MS'
.•••*
NE#1
.•••NE#3
••-MS-''
• MS-
NE#4
^^^
^^^&
^5PW
N E #5
NE #6
N E #7
T NE#8
1^
NE #9 •••.,_ N E # 1 1
\M§--'
••••••MS--
T NE#10
NE#2
Figure 16-28. Illustration of HOVC layer adjacency
We note that G.7714 defines another level of adjacency, termed physical media adjacency (PMAD), which is conceptually no different from any other layer adjacency since the layer that is represented is the physical media layer, e.g., fiber layer. The mechanisms for providing PMAD for optical networks have not been standardized. This is in large part because such
610
Chapter 16
mechanisms would require the use of optical processing techniques at the wavelength and fiber level, areas that are not yet sufficiently mature. 16.6.3.2 Control Entity Logical Adjacency Establishment The 2001 version of G.7714 included discussion of Control Entity Logical Adjacency, or CELA. This was previously defined as the association that existed between two discovery processes to facilitate communication between a pair of control entities across the SCN. The term CELA was utilized prior to the development of the G.8080 discovery architecture, and prior to consideration that the management plane could benefit from the automatic discovery process. As mentioned earlier, the revised (2005) version of G.7714 allows the discovery process to be used by the management plane as well as the control plane, making the term CELA inappropriate. Since the appropriate G.8080 architectural construct is the DA (Discovery Agent), it was considered to replace CELA with the appropriate term, namely Discovery Agent adjacency. However, a DA adjacency does not need to be preestablished and may be created dynamically while other discovery subprocesses (e.g., LAD) are being executed. Furthermore, the communications that occurred across the adjacency were not in any way scoped by the adjacency, removing any functional distinction from the messaging services provided by the DCN. Thus, discussion of the Discovery Agent adjacency was not included in the revised Recommendation. 16.6.3.3 Service Capability Exchange The term Service Capability Exchange (SCE) was used in the first version of G.7714 as defining a process for capability information exchange. This process was used to allow information regarding the ends of the discovered facility to be exchanged, "bootstrapping" the control plane. However, since the term service is often used to describe end-user communication services, the term SCE introduced ambiguity. To avoid this ambiguity, in the 2005 version of G.7714 the term SCE was changed to Transport Capability Exchange (TCE), which more accurately expresses the intent of the process. Again, with the extension of the discovery process to the Management Plane, the scope of TCE has been limited to the exchange of Transport Plane Capability information, and the exchange of control plane or management plane specific information will be moved to other Recommendations. It has been recognized that the exchange of control plane or management plane information has the same requirements as the exchange of transport
Architecting the Automatically Switched Transport Network
611
plane capability information. As a result, the 2005 version of G.7714 includes the specification of a generic mechanism to perform capability exchange. It is expected that this mechanism will be reused by Recommendations that address the specific encodings for the exchange of control plane and management plane information.
16.6.4 Discovery Considerations across Administrative Boundaries Auto-discovery across user-provider interfaces is unique, largely driven by the fact that service provider proprietary information is not exchanged with the user. In that sense, user-provider discovery is a "single ended" discovery process. From the point of view of the provider, it is a mapping of user endpoint names to network addresses that are used for routing, and from the user's perspective, it is an acknowledgment of the availability of the user-to-network connections. Capability exchange is quite limited given that service level information is exchanged and agreed upon during the contract negotiation phase. Discovery over intercarrier interfaces, which are service demarcation boundaries, may also involve tmst boundaries (e.g., between different carrier networks). To this end, the discovery processes offer a provider a significant amount of control over the information that can be exchanged. Each capability that could be exchanged may be, by provider policy, excluded from the exchange process. Furthermore, the exchange process allows providers the ability to restrict the behavior of the entity on the other end of the link.
16.7.
ROUTING (G.7715 AND G.7715.1)
Recommendation G.7715 contains the architecture and requirements for routing in ASON, expanding on the routing function concept in G.807 and G.8080. Recommendation G.7715.1 contains more detailed requirements aimed specifically at link state routing instantiation of ASON routing. The basic principles are presented in this section.
16.7.1 Requirements The routing requirements described in G.7715 encompass architectural, protocol, and path computation aspects. Some key examples of architecture and protocol requirements are described within this section.
Chapter 16
612 16.7.1.1 Architectural
The routing architecture requirements specified in G.7715 reinforce and build upon G.807 and G.8080 requirements. One key requirement with fundamental implications is that the routing adjacency topology and transport network topology shall not be assumed to be congruent [11]. This separation between the transport topology and the routing control topology, and also between the latter and the DCN, means that their topologies may all be different from one another in any given ASON network. Figure 16-29 illustrates a routing area (RA) where the routing control topology forms a tree including all the nodes in the transport plane. (We stress that this tree, used by the RCs to forward routing messages, does not need to be congruent with the transport plane topology.) Separation allows, for example, a single RC to support multiple network elements, and to be addressed separately from the network elements.
— Transport Link - - Routing Adjacency ® - Transport Node 0 = Routing Controller
Figure 16-29. Example of directed topology message Flow [37] [11]
Route computation is achieved using information advertised by the routing protocol and is often subject to a set of optimization constraints. After the route is determined, connection management processes (i.e., signaling) are used to allocate network resources (i.e., subnet connections and link connections) before user traffic is carried on those paths. After signaling has been used to establish a connection, the routing functions are no longer needed. Hence routing protocols in transport networks are not involved in "data-plane forwarding" and therefore have no impact on established services, which is not the case in, for example, IP networks where the forwarding function is continually dependent on the availability and integrity of the routing function. This has important implications for the performance required from the routing control plane; for example, transport plane connections remain active and data can continue to be transported even when the routing control plane is unavailable. This setup is illustrated in Figure 16-30.
Architecting the Automatically Switched Transport Network OSPF )
^
613
IP router Peers
Routing Controllers
.'"Signeling"' I
Control Plant IP packet Data R an e
Cross Connect
I
|lPaddr[
IP prefix next hqj
SDH path ^ n p Forwarding^
A. Transport Routing a n d Forwarding
B. I P Routing a n d Forwarding
Figure J 6-30. Routing and forwarding examples
• •
•
Other G.7715 requirements include the following [11]: The routing information exchanged between routing control domains is independent of intradomain protocol choices. The routing information exchanged between routing control domains is independent of intradomain control distribution choices, e.g., centralized or fully distributed routing functions. The routing information shall support an abstracted view of individual domains, i.e., the topology advertised externally in the routing protocol may be an abstracted view of the actual internal domain topology. The level of abstraction is subject to operator policy.
Recommendation G.7715 also provides requirements addressing the need to provide for unique identification of RAs within a carrier network, as well as avoiding protocol dependencies between hierarchical routing levels. 16.7.1.2
Protocol
Along with requirements related to protocol robustness, scalability, and security aspects, key requirements for the routing protocol itself are defined below [11]: • The routing protocol shall be capable of supporting multiple hierarchical levels. • The routing protocol shall support hierarchical routing information dissemination including summarized routing information. • The routing protocol shall include support for multiple links between nodes and shall allow for link and node diversity.
Chapter 16
614 •
The routing protocol shall be capable of supporting architectural evolution in terms of the number of levels of hierarchies, and aggregation and segmentation of RAs.
Note that the term level is used specifically to refer to the use of hierarchy to support subdivision of transport network resources into RAs, which is analogous to partitioning of a transport layer network into subnetworks as described in Chapter 2. This should not be surprising, as the only distinction between a subnetwork and a RA is the visibility of the link ends. A simple example of hierarchical routing levels is illustrated in Figure 16-31.
Level n+1
Level n
dUlRA
Level n-1
Figure 16-31. Simple example of hierarchical routing levels
Using the drawing convention for partitioning from Chapter 2, Figure 1631 can be redrawn as Figure 16-32. We again stress the difference between transport network layering and partitioning, as described in Chapter 2.
Architecting the Automatically Switched Transport Network
615
O' Figure 16-32. Hierarchical routing levels illustrated using partitioning notation
16.7.2 Architecture The ASON routing architecture of G.7715 supports the various routing paradigms hsted in G.8080, i.e., hierarchical, step-by-step, and source based. The routing architecture apphes after the network has been subdivided into Routing Areas and the necessary network resources have been accordingly assigned [11]. In this section, we will build upon the discussion of Routing Areas (RAs) from Section 16.3.2.1. Associated with each RA is a Routing Performer (RP), which is an abstract entity that provides path computation services for the RA. Signaling to create connections in the transport plane uses path computation. Whatever path computation style an RA supports, the RP will have the necessary topology information to support it. An RP is realized in the form of RCs, as described in Section 16.3.3, which are distributed entities with partial or complete (via duplication and synchronization) routing information for that RA. This architectural arrangement is shown in Figure 16-33. Routing Controllers distribute topology information with each other, and when two RCs communicate, this is known as forming a routing adjacency. The set of routing adjacencies form a routing control topology. Routing adjacencies are communicated/instantiated over the SCN. The RCs communicate via Protocol Controllers (PCs) that support a particular routing protocol. Separation of the RC and PC components allows great flexibility; for example, a single PC (and the routing protocol it implements) may support RCs from different transport layer networks and multiple
616
Chapter 16
hierarchical routing levels. This capability is important for protocol efficiency since it enables carriage of information pertaining to multiple layer networks (and hierarchical routing levels) in one PDU, instead of having to run separate instances for each layer network.
m
••iiii Service offered by RP
\ Computational View
y
RPy
Realized by RCs
* Engineering View
\ RG
Figure 16-33. Relationship between RA, RP, RC
Creation of RAs is related to the scope of routing information flooding (scalability), which impacts both transport resource assignment to Level 0 RAs and routing hierarchy decisions.
Architecting the Automatically Switched Transport Network
617
Transport resources (physical transport network)
Figure 16-34. Possible assignment of resources to RAs — example 1
Some illustrative examples are provided in Figures 16-34 (above) and 1635 (below), respectively.
Possttile allocation of transport resources to Level 0 RAs
Scenarb (b)
Transport resources (physical transport network)
—«^^"^«——^^^ Figure 16-35. Possible assignment of resources to RAs — example 2
As discussed earlier, the RA is the key concept that matches the organization of the control plane to the organization of the transport plane. We stress that the existence of E-NNIs (bounding control domains) should not be inferred
Chapter 16
618
to create RAs. Several examples of potential RA and control domain scenarios are shown below that illustrate this point. Figure 16-36 illustrates several alternative configurations of routing control domains, ranging from multiple RAs in a given routing control domain, as in scenario (a), to complete congruency, as in scenario (b). One example of the former scenario might correspond to the situation in which, for example, there is a single vendor homogeneous solution, but scalability considerations warrant more than one RA.
(a)
RA(Level n) Control Domain
(b)
Figure 16-36. Possible configurations of routing control domains
Correspondingly, there are also alternative configurations of routing control domains ranging from complete congruency to multiple control domains within an RA, the latter of which is illustrated in Figure 16-37.
[C3 RA(Le\eln) ') Cortrol Domain
Figure 16-37. Possible configuration of routing control domains
The configuration in Figure 16-37 might correspond, for example, to a scenario in which two vendors with heterogeneous control plane routing protocol implementations were deployed within the same RA. It should be noted that we would not expect routing control domains to be configured in a manner such that they would intersect RAs. Specifically,
Architecting the Automatically Switched Transport Network
619
while the raison d'etre for creation of these constructs derives from different factors, it would generally be expected that a network planner would consider decisions relating to these aspects in a coherent manner.
16.7.3 Hierarchy in Routing The routing architecture of G.8080 and G.7715 allows for different implementations of the routing functions. That is, the various routing functions can be instantiated in a variety of ways including using distributed, co-located, and centralized mechanisms. A G.7715.1 compliant link state routing protocol can be instantiated as a set of RCs, each one performing topology distribution for the RA it is associated with. Each RC has a replicated topology database representing the transport plane topology where database consistency is maintained by exchanging database synchronization messages between every pair of RCs. This information exchange occurs via the protocol controllers for each RC. Each protocol controller runs an instance of the link state protocol. Using the topology information advertised via the link state routing protocol, a source can calculate routes through the network along which connections may be established. The choice of source routing for path computation has some advantages for supporting connection management in transport networks. It is similar to the manner in which many transport network management systems select paths today. Also, it can be powerful when diverse path computation is needed or for implementing fast restoration, among other things. Figure 16-38 illustrates an example of a network with two levels of routing hierarchy, where the lowest level routing area is tied to the transport network's physical topology. Four routing areas (RAl, RA2, RA3 and RAIO) are defined, with the first three at Level 0 and the parent at Level 1. Internally, each of these RAs manages its own network topology and available resources; i.e., there exists some method for obtaining a path across the RA that can be established via signaling.
Chapter 16
620
Level 0 RAs
Figure 16-38. Simple network with two levels of routing hierarchy
As described earlier, each RA has one or more associated RCs. It should not be assumed that there is a one-to-one relationship between transport resources and RCs, as a single RC may support multiple network elements. An example of a possible RC distribution including this scenario is illustrated in Figure 16-39.
Figure 16-39. Possible distribution of RCs
As we have discussed earlier, an architectural requirement of Section 16.7.1.1 is that "routing information exchanged between routing control domains must be independent of intradomain protocol and distribution choices". From an RC perspective, this means the RC distribution within a routing control domain is not externally visible. Thus, an RC can "act on behalf of a routing control domain; we note that one or more RCs can assume this role. Each RC is described by an RC Identifier (RC ID) and is uniquely defined within its containing RA, which, in turn, is identified using a RA Identifier (RA ID). Again, as noted earlier, a single RC supporting multiple network elements may have its own RC ID. The grouping of RCs in RAs at different hierarchical levels is defined in a flexible manner. For example, there does not exist any association or set of rules between the RA ID and the RC ID or the identifier of any RC
Architecting the Automatically Switched Transport Network
621
belonging to that RA. Additionally, the term level only has a relative sense, since it is not fixed in value; thus, a new RA may be added as needed as the first hierarchical level, at the top of the current hierarchy, or even between two existing hierarchical levels. This flexibility yields great convenience in managing carrier's networks as they develop and grow. The routing architecture described in G.7715 is applicable to multilevel routing hierarchies and is very powerful for scaling networks while providing sufficient routing information to efficiently compute routes across multiple separately managed physical networks. Recommendation G.7715 does not specify the detailed routing protocol to be used but leaves it as an implementation decision. Recommendation G.7715.1 further defines requirements for link state routing protocols in a protocol-independent manner.
16.7.4 Routing Information Exchange The following section discusses the routing information that is available at the various routing levels. From the point of view of architecture, links are wholly contained within a routing area, so a link only exists in the lowest level RA that contains both link ends. Connection Controllers have identical scope. In this model, there is no notion of exchanging routing information up and down the levels of the routing hierarchy via RCs. However, implementations invariably handle all layers and levels within a single component, and in this case it is convenient to consider links to be attached to the physical switch, and to discuss the visibility of links in terms of information flow up and down the levels. While the rest of this section is in terms of information flows, it is important not to lose sight of the architectural separation that is still maintained. Routing information may be exchanged across different levels of the routing hierarchy (between an RC, its parent, and its child RCs), and the information flows between levels are not specific to any particular paradigm (e.g., centralized or link state). The transport plane topology is advertised as a set of nodes and links. Nodes may correspond to abstract or physical entities within the child RA, and no distinction is made between them in the advertisement. For example, referring to Figure 16-38, there is no distinction in the advertisement between the (abstract) nodes in the Level 10 RA, and the physical nodes in the Level 0 RAs. Recommendation G.7715.1 indicates that the type of information flowing upwards (i.e., level N to level N+1) and downwards (i.e., level N+1 to level N) both involve the exchange of reachability information and may include summarized topology information—in other words, the transformation of
622
Chapter 16
one RA topology as a virtual RA topology (in terms of nodes and links) for the purposes of summarizing routing information for advertisement in its parent RA. The transformation mechanism is not intended for standardization. Recent insight clarifies that this transformation of RA topology is concerned with calculating the cost of crossing a RA, and not with presenting a different view of the RA internal topology. The cost has been expressed in terms of a set of nodes and links because that is what today's routing protocols handle. The reader should be aware that the discussion is about cost; it is not about revealing RA internal details. It should be noted that G.8080 requires the topology exchanged to be specific to a layer of the transport hierarchy. Consequently, links will only be reported in a specific layer's topology if the link supports the signal type of that layer. As noted earlier, multiple layer topologies can be carried by one routing protocol as long as the link and node information exchanged is identified as being specific to a layer. Finally, to route a connection to a given customer, we must know through which RA the customer can be reached. The routing protocol must thus advertise client reachability information in the form of UNI~N SNPP addresses. A UNI-N SNPP address associated with a given RA is advertised by the RC(s) that represent that RA, so that other RCs will learn of the reachability of that UNI Transport Resource and pass this information onto their associated RAs. Note that the network must contain a directory that maps UNI-C Transport Resource names onto the local UNI-N SNPP addresses. Also note that the advertised SNPP address may be different from the internal SNPP address, with address resolution occurring at the RA boundary. There are two options for propagation of routing information at a given hierarchical level. The first is uploading the information to a centralized route server, such as a management station, where the information can be integrated and used for computing routes. This option is sometimes referred to as the path computation server approach. The second option involves propagating the information throughout the entire routing hierarchy, which requires that the information is disseminated among all the hierarchical routing levels. The routing information of an RA at the hierarchical level A^ (RAN) can be disseminated to the RA at the level N+1 (RAN+J). The information communicated among the cooperating RCs usually includes the set of reachable UNI Transport Resource identifiers, inter-RA links (from the perspective of RAN+I), and nodes. Nodes with internal detail (abstract nodes) may have a cost associated with them, which may be expressed in terms of a summarized/transformed topology of nodes and links. After the information is communicated to level N+1, the RCs in RAN+I will cooperate to advertise
Architecting the Automatically Switched Transport Network
623
the information so that the routing information associated with a small set of RAs will be learnt by others. Recommendation G.7715.1 describes two approaches by which the routing information of RAN+I can be provided to RAN. In the first approach, the RP in the containing RA at level N+1 provides the level N RP with the reachability and topology information visible at level N+1. The information visible at level N+l includes the information visible at consecutive upper levels. This information may then be used by the level N RP to compute a path that leaves the RA. In the second approach, recursive requests are made from the level N RP to the level N+1 RP upward towards the root of the routing hierarchy. The result of each request is analyzed by the requesting RP to determine the exit point utilized by the level N+1 RP. The RP will then update the path including the path computed through the level N RA, and return it to the requester. This approach is loop free as the routing hierarchy defined in G.8080 has strict containment (preventing a contained RA from containing a containing RA). 16.7.4.1
General Attributes
Recommendation G.7715.1 focuses in more detail on the attributes associated with usage of ASON compliant link state routing protocol to advertise transport plane topology between RAs. We divide the information disseminated via a routing protocol into node attributes (using the definition of node as described earlier) and link attributes, since these are the basic topological elements. Link attributes may be further classified as those that are layer independent, such as identification, and those that are layer specific, such as adaptation support. The way that these attributes are used by the routing protocol is normally dependent on the operator's policy (e.g., the operator may decide to advertise a restricted set of reachability information). We consider the different attributes below. 16.7.4.2 Node Attributes All nodes in a graph representation of a network belong to an RA; hence the RA ID is an attribute of all nodes. As discussed earlier, no distinction is made between abstract nodes and those that cannot be decomposed any further; the same attributes are used for their advertisement [12]. The following node attributes are defined [12]: • Node Identification (ID): The Node ID is the subnetwork ID that exists in an SNPP name. All node IDs advertised within an RA are allocated from a common name space for that RA.
Chapter 16
624 •
Reachability Information: Reachability information describes the set of endpoints that are reachable by the associated node. It may be advertised either as a set of UNI Transport Resource identifiers or a set of associated SNPP identifiers, the selection of which must be consistent within the applicable scope. For implementation purposes, it is important to identify when attributes are required to be supported in a protocol realization and must be present in advertisements, and when attributes are required to be supported but may not be present in an advertisement based on operator policy. Table 8-1, from G.7715.1 [12], provides this information, where capability refers to level of support required in the realization of a link state routing protocol, whereas usage refers to the degree of operational and implementation flexibility, i.e., the ability of the operator to define the use or non-use of the attribute by policy. Mandatory usage attributes are those that are needed as a minimum to support path computation.
Attribute Node ID Reachability
Table 16-2. Node attributes [12] Usage Capability Mandatory Mandatory Mandatory Optional
16.7.4.3 Link Attributes Recommendation G.7715.1 defines the following set of link attributes to be supported in link state routing protocols for ASON [12]: • Local SNPP Name: identifying the transport plane resource at the local SNPP link end • Remote SNPP Name: identifying the transport plane resource at the remote SNPP link end Table 16-3 provides implementation requirements for general link attributes.
Link Attribute Local SNPP Name Remote SNPP Name Layer specific characteristics
Table 16-3. Link attributes [12] Capability Mandatory Mandatory (refer to Section 16.7.4.4)
Usage Mandatory Mandatory
Note: When the remote end of a link is located outside of the RA, usage of the remote SNPP Name is optional.
Architecting the Automatically Switched Transport Network
625
16.7.4.4 Layer-Specific Characteristics Recommendation G.7715.1 defines the following set of layer-specific characteristics as attributes of a link [12]: •
Signal Type: This attribute identifies the characteristic information of the layer network. Since advertisements are layer specific, this information identifies the layer network being advertised. If advertisements for multiple layer networks are combined in a single protocol instance, this attribute allows advertised information to be forwarded to the RC for that layer network. • Link Weight: This attribute represents a vector of one or more metrics, each of which indicates the relative desirability of a particular link over another during path selection. • Resource Class: This attribute corresponds to a set of administrative groups assigned by the operator to this link. A link may belong to zero, one, or more administrative groups. • Local Connection Type: This attribute identifies whether the local SNP represents a TCP, or a CP or can be flexibly configured as either a TCP or a CP. Some links may, for example, support termination of connections but not transit of connections as a result, and should only be used if the connection terminates at the remote node. • Link Capacity: This attribute provides the sum of the available and potential link connections for a particular network transport layer. Other types of capacity information have not been precluded and are for further study in G.7715.1. Providing such information on a layer-specific basis allows more accurate connection routing, since it takes into account the potential for connections at one layer impacting the availability of a link for connections at another layer due to factors such as placement within the frame, which are not obvious from a simple measurement of capacity in total available bits per second. • Link Availability: This attribute represents a vector of one or more availability factors for the link or link end. Availability may be represented in different ways between domains and within domains. Within domains, it may be used to represent a survivability capability of the link or link end. In addition, the availability factor may be used to represent a node survivability characteristic. Link availability may be a constraint used in routing of paths supporting connections with higher class of service. • Diversity Support: This attribute represents diversity information with respect to links, nodes, and Shared Risk Groups (SRGs) that may be used
Chapter 16
626
during path computation. Such information can then be used in computation of paths for protection/restoration purposes. • Local Client Adaptations Supported: This attribute represents the set of cHent layer adaptations supported by the TCP associated with the Local SNPP. This is only applicable when the local SNP represents a TCP or can be flexibly configured as either a TCP or a CP. This type of information may be used when calculating paths requiring a specific adaptation when support may differ on a link-by-link basis. In Table 16-4, implementation requirements are specified for layerspecific link attributes. Table 16-4, Layer-specific characteristics [12] Capability Layer-Specific Characteristics Signal Type Mandatory Mandatory Link Weight Mandatory Resource Class Local Connection Type Mandatory Mandatory Link Capacity Link Availability Optional Diversity Support Optional Local Client Adaptations Supported Optional
16.8.
Usage Optional Optional Optional Optional Optional Optional Optional Optional
SIGNALING (G.7713)
Recommendations G.7713 and G.7713 Amendment 1 provide protocolneutral specifications for distributed call and connection management in ASON, which are thus applicable to multiple signaling protocols. In addition to the processes related to signaling communication, several other important issues are addressed, including: • Rainy-day scenarios that need to be covered to support the unlikely event of defects impacting the control plane. These may include defects of the signaling channel, or defects of the control plane itself. • The operation and communications between the call and connection control components in setting up and tearing down connections. These include specification of the messages and the information content of the messages, as well as the behaviors of the signaling mechanism. • Issues that need to be resolved to handle alarm suppression in the transport plane when connections are setup and removed. We note that ASON signaling components (especially the NCC) may be centrally instantiated. While G.7713 does not preclude this, it focuses upon protocol requirements for the case in which signaling components are
Architecting the Automatically Switched Transport Network
627
distributed. Information passed by the distributed signaling components and messages are defined in G.7713 in an abstract manner. If different signaling protocols are used in a common ASON network, they may interwork across various reference points by transferring equivalent messages and information elements between their protocol-specific encodings.
16.8.1 Call and Connection Management Operations This section describes call and connection management operations after the contract between the user and the provider has been established. Figure 16-40 (based upon Figure 6-Aml-l /G.77ISA". 1704 [5]) provides a simple high-level illustration of the interactions between end user (calling and called party), call controllers (CCC), and network call controllers (NCC) in a two-domain network. The Calling Party Call Controller (CCC-a) interacts with a Called Party Call Controller (CCC-z) by means of one or more intermediate network call controllers (NCCs) at service demarcation points (i.e., UNI, E-NNI). The Call Controllers perform the following actions: • The NCC correlates the SNCs to the call. • NCC-la and NCC-2z work with CCC-a and CCC-z, respectively, to correlate Link Connections(s), LC(s), to the call access segments. • NCC-1 works with its peer NCC-2 at domain boundaries to correlate LC(s) to the interdomain call segment. • The NCCs correlate the LCs and Subnetwork Connections (SNCs) that are associated with each call segment within their respective domains.
Domain 2
Domain 1
^ ^pia
ccc^
AGO
End-to-end call Call segments Connections
..^^»y...ErNNJ....tt NCC-1) r
A—
^ ^^ LC ^
~— P SNC
^ W
• ^
LC
^
9
^
w. SNCs
^
^-~~-»» ^ w^ ^ LC
Figure 16-40. Interaction among Call Controllers in two domain example [5]
628
Chapter 16
Connection controllers (CCs) establish the connections associated with each call segment.
that
are
16.8.2 Basic Call and Connection Control Sequences Call and connection setup in transport networks uses a three-message sequence consisting of the SetupRequest message, which initiates the call and specifies the desired traffic characteristics for the connection; the Setuplndication message, which acknowledges establishment of the connection across the network, and the optional SetupConfirm message, which confirms end-to-end to the destination node that the connection has been made. 16.8.2.1
Call and Connection Setup
Referring to the example of call setup request processing in Figure 16-41 (based upon Figure 6-Aml-l IG.llUIYAlOA [5]), the Calling Party Call Controller, CCC-a, requests call setup, and the ingress NCC-la initiates processes to check the call request. These may include checking for authentication and integrity of the request, as well as constraints placed by policy decisions (described in Section 16.5). The request is also sent to NCC-2z and NCC-2 (at the service demarcation points). Processes included in the egress NCC-2z may include verifying that the call request is accepted end-to-end [5]. Upon successful checking, CCC-a continues the call setup request by initiating a connection setup request to its associated Connection Controller, CC-a. The connection request performs the coordination among respective CCs to set up and release connections. When a connection is required for the call, the call is not considered complete until the connection is in place [5].
Architecting the Automatically Switched Transport Network
ACC-1
TCC-1
629
ZCC-1
Connection setup CC-a: A-end Connection Controller CC-z Z-end Connection Controller ACC-n: A-end Connection Controller at Domain n ZCC-n: Z-end Connection Controller at Domain n TCC-n: Transit Connection Controller in Domain n
Figure 16-41. Example of call setup request processing [5]
Upon successful indication by the connection setup request process (across all call segments) the call setup request is successfully completed, and transfer of user characteristic information may begin. If the connection setup request process was unsuccessful, a call-denied notification is sent to the user [5]. 16.8.2.2 Call/Connection Release Call and connection release in transport networks, in its basic form, uses a two-message sequence consisting of the ReleaseRequest message, which initiates release of the connection and triggers release at the next hop of the connection, and the Releaselndication message, which is an acknowledgment of completion of the release of the local channel. Optionally, a Notify message may be sent to the remote end prior to the initiation of connection release, in order to prevent alarming due to in band performance monitoring that might be triggered by the connection release in the data plane. 16.8.2.3
Query
Finally, the ability to query the status of a connection or call is included through the QueryRequest message and the associated response through a Querylndication message so that it is possible to audit the state of the connection at a neighboring node and initiate a connection release or state resynchronization in case of a conflict.
630
Chapter 16
16.8.3 Signaling Attributes Distributed call and connection management attributes may be separated into attributes associated with the call and those associated with connections. In both cases, the scope of the attribute could be local, constrained to one reference point, versus global, which is carried across the network. Recommendation G.7713 Amendment 1 provides these attributes for UNI, E-NNI, and I-NNI signaling processing [5]. • UNI signaling processing includes call attributes as well as connection attributes for setting up LC(s) on user-to-network domain access links. Examples of call attributes include Calling and Called UNI Transport Resource Names, Call name, and policy attributes. It should be noted that call identity attributes have end-to-end scope. For example, the value of the UNI Transport Resource Name must be globally unique, and is assigned by the service provider. Examples of connection attributes include Initiating/Terminating Connection Controller Names and Connection Name. • E-NNI signaling processing includes call attributes as well as connection attributes for setting up LC(s) on interdomain access links. The call attributes are the same as for the UNI, though the Calling/Called UNI Transport Resource name may be carried transparently. Connection attributes include SNP and SNPP IDs, as well as Called/Calling Access Group Container(AGC) SNPP ID. An AGC is a single layer entity that can terminate multiple SNPP links and contains access groups, LRMs, and TAPs. - I-NNI signaling processing includes connection attributes. If call communications traverse I-NNIs, call parameters must be carried transparently. Abstract attributes at the E-NNI are provided in Table 16-5 (Table 7 3/G.7713A^.1704[5]):
Architecting the Automatically Switched Transport Network
631
Table 16-5. E-NNI Call and Connection attributes :5] Call vs. Connection Scope Attributes Call Calling UNI Transport End-to-end Resource name Call Called UNI Transport End-to-end Resource name Identity Connection Initiating CC/CallC Local attributes name Connection Terminating CC/CallC Local name Connection Connection name Local Call Call name End-to-end Connection SNPID Local SNPP ID Connection Local Service Connection Called AGC SNP ID End-to-end attributes Connection Called AGC SNPP ID End-to-end Directionality Call/connection Local Call Cos End-to-end GoS End-to-end Call ! Policy attributes Call/connection j Security Local Explicit resource list Connection Local Recovery Connection Local
16.8.4 Signaling Application Example An interesting signaling applications example is that for dual homing. Dual homing [40] refers to the scenario in which an individual user interacts with a provider network via more than one UNL Another form of dual homing is where a user interacts with two different provider networks via different UNIs. This configuration is commonly used to increase the reliability of a user's access to the network. If the transport link(s) to the network associated with one UNI fail, the other UNI can be used. This concept could also be applied over an E-NNI for multidomain connection reliability. Aside from increased access reliability, additional services can be supported for dual homed users: • Simple path diversity: In this scenario, illustrated in Figure 16-42, dual homed user 1 places two calls to a dual homed destination user 2, via each of its two UNIs over a provider network domain. The connections associated with each of the two calls could be established such that they
Chapter 16
632
do not share transport resources in the provider network. This is a feature being considered in the OIF for the UNI 2.0 Implementation Agreement.
umJ P ^ ^ Gb/s) that are used within the carriers' multiservice networks or at the enterprise edge that provide metro or wide area network connectivity.
17.2. REQUIREMENT PLACED ON THE NETWORK ELEMENTS BY THE NETWORK Today's multiservice heterogeneous landline networks can be fuzzily categorized into different network demarcation segments as depicted in Figure 17-1. The segments are: 1. Premise or Enterprise 2. Metro edge 3. Metro core/backbone 4. Long haul core/backbone
Figure 17-1. Fuzzy Networking Demarcation Points
Heuristically we have seen that as the diverse data centric traffic along with traditional TDM traffic, traverses from the enterprise networks towards the core network, the traffic keeps getting aggregated or bundled into bigger pipes (illustrated in the lower portion of Figure 17-1). Depending on the application, the traffic aggregation takes place at the transport layer as the
Intra-Network Elements Communication
663
traffic is mapped onto one of the standardized transport protocols like SONET/SDH, G.709, 1/10 gigabit Ethernet, Fibre Channel (1, 2, 4, or 10 Gb/s data rates). This traffic aggregation ensures efficient utilization of the network bandwidth while enabling efficient traffic control and management. Therefore, by the time the traffic reaches the network core, it has been well shaped and smoothed. This relieves the core network from managing fine granular traffic pipes such that it can concentrate on the management of higher bandwidth pipes and A.s traversing across the country or continents. The network elements used in building ever-evolving diverse networks have to process data with effective throughput typically dictated by transport layer protocol (SONET/SDH, Ethernet etc.) line rates. Presently, the throughput requirements placed on the individual line cards within the network elements depend on where they are used. For example, within the access network, the line rates are typically less than or equal to 2.5 Gb/s, at the metro edge they could be up to lOGb/s, at the metro core the rates can be 10-40 Gb/s, and long haul core the rates are heading towards 40+ Gb/s. The above-mentioned line rates place minimum effective throughput rates for chip-to-chip and card-to-card (via that backplane) communication within the network element. During these interesting and dynamic times for the networking industry major operators worldwide are moving beyond simple next-generation SONET/SDH, offering more ambitious services. These services are offered based on the network elements that provide full layer-2 aggregation and switching (carrier grade Ethernet switching), support MPLS pseudowire, and end-to-end control plane to create truly packet-aware transport gear [1]. These functions within the network element mandate the processing of the data at different hierarchical layers of the OSI model. Such processing is typically performed by several VLSI devices that are optimized for handling specific networking functions. Some of the requirements placed on these devices are to handle hierarchical protocol traversal, processing and conversion, flow control between devices, in addition to switching/routing of data. The data processing requirements subsequently translate into payload processing at the line rate along with processing of management and control plane data for chip-to-chip communications within the network element. Numerous new services carried over the transport networks require that network elements handle diverse data centric protocols that are carried over legacy as well as newly developed physical interfaces. These requirements fundamentally translate into the network elements (especially customer edge or provider's edge network elements) to terminate the mix of physical layer interfaces and protocols and map them onto a unified transport protocol like SONET/SDH, G.709, Ethernet etc. These types of network elements are typically know as Multiservices Provisioning Platforms (MSPPs). For
Chapter 17
664
example, the MSPPs may have a mix of 1/10 GbE, Fibre Channel interfaces on the customer side and a SONET/SDH interface on the service provider side.
17.3-
NETWORK ELEMENT DESIGN AND INTERFACE ARCHITECTURE
The majority of the high speed data traffic traversing over fiber (over public networks or private/leased fiber) is transported either on SONET/SDH, G.709, 1/10 gigabit Ethernet or Fibre Channel (1, 2, 4, or 10 Gb/s data rates) based transport protocols. At present, the native Ethernet and Fibre Channel transport is primarily restricted to the same metropolitan area whereas SONET/SDH transport spans from the customer premise to the metropolitan and wide area networks. G.709 is slowly gaining momentum where strong Forward Error Correction (FEC) is used to extend the link span (e.g., intercity or undersea links). Modern network elements, (primarily switches, routers, digital cross-connects etc.) although may have different physical layer interfaces, share very similar architectural features. The design of the network elements logically separates two major processing paths: a fast data/packet/frame processing path and a slow packet/frame processing path. Figure 17-2 illustrates some of the processing functions of the fast and the slow paths. The fast path is traditionally referred to the data path where the incoming packet/frame is operated upon/processed at the line
o
Opuratton. Admtnistratton. Maiiagcmcnt and Provisioning (OAM&P) (Less time cntical applications to bo pcrfonnc'd at much slo\vi;r rates than the line rate)
cmciit (segmentation rcasscniblv. qucuin^j. policing etc)
Data plane processing: (Tunc sensitive data to be processed at line rate)
Protocol Translations Classification (filtering, fonvarding, lookup etc) Data Header Parsing (e.g. for addmss/proiocol information) MACWAN Franicr (eg. Ethernet or SONET/SDH frame processing)
\7
Phvsical Laver
Figure 17-2. Conceptual data processing partitioning within a Network Element
Intra-Network Elements Communication
665
rate. The slow path typically performs processing of Operations, Administration, Management and Provisioning (OAM&P) data. For example, such data can consist of information pertaining to the routing tables that need updating, modification to the existing configuration, gathering of statistical information etc.
17.3.1 Packet Based Network Elements Switch Fabric Card
n; Hosl Processor
Figure 17-3. Line card using packet/cell switch fabric
Figure 17-3 illustrates architectural blocks of a packet data line card which is connected to switch fabric module via a proprietary or standardized backplane [2,3] (Chapter 19 discusses standardization efforts on backplanes). The network element routes/switches variable or fixed length packet/cell based data. (The terms switching and routing are used interchangeably since the functionality they represent within the network elements context, is the same). Within this architecture, the switching/routing can take place at the Ethernet, MPLS, ATM, IP, Fibre Channel or some other packet based protocol. There are seven major fastpath processing functional blocks that make up the generic architecture of network element. With present state-of-the-art VLSI technology, these architectural blocks also represent discrete VLSI components. The components consist of Serializer/Deserializer (SERDES), FEC Device, Multiservice Framer (SONET or G.709), Network Processor (NP), Traffic Manager (TM), switch fabric interface device and switch fabric/crossbar module. Optional components like security processors for line rate data encryption/decryption can also be added within the data path. Elaborate
Chapter 17
666
features and architectural concepts with vendor specific implementations of NP and TM functions can be found in [4] and switch fabrics in [5]. The highly complex and integrated networking VLSI components used within the network elements are supplied by several different vendors. Therefore, for these devices to interoperate, standardized chip-to-chip implementation agreements were developed by the Optical Internetworking Forum (OIF) and are discussed extensively in Section 17.4-17.7.
17.3.2 TDM Based Network Elements In the late 1990s and early 2000s, efforts were made in emulating TDM switching within packet based switch fabrics. However, the proposed solutions did not gain traction due to several limitations of packet-based switching. One of the major disadvantages of the packet-based solution was the need to buffer TDM data over possibly multiple SONET/SDH frames to form fixed-length packets before they can be switched. This introduced unnecessary latency, jitter, and overhead processing. The need for a standardized TDM-based backplane was identified within the OIF community and subsequently specified. The implementations agreement allowed TDM switch fabrics (digital cross-connects, add-drop muxes, grooming switches, and time slot interchange ICs etc.) to interface with a multiservice framer in a standardized format. Figure 17.4 illustrates an architectural design of a typical TDM based network element design. Line Card
_o. fe>l
Switch Fabric Card
Multi-Servlce
Transponder/1 (Optics ^ SERDES)
la
7T .. XZ
iz
n
Host Processor Interface (e.g PCI 2.2 compliant 66 MHz, 64 bit host interface)
Host Processor
Figure 17-4. Line card using TDM switch fabric
TDM Switch Fabric
X
Intra-Network Elements Communication
667
17.3.3 Hybrid (TDM + Cell/Packet based) Network Element Architecture With a centralized control and management platform based on ASON which allows rapid deployment of network resources, it is easy to architect a hybrid network element that utilizes the enhanced properties of both TDM and packet-based networking. For example, TDM service allows users to reserve guaranteed fixed bandwidth for end-to-end connections. These preprovisioned connections have fixed latency and minimum jitter. In highspeed applications' (greater than 1 Gb/s line rate) market place, SONET/SDH is the transport technology of choice. As we have seen in chapters 4 and 5, SONET/SDH has been optimized to support both TDM and packet traffic. From the previous section we have seen that emulating the TDM switching within the packet-based environment adds unnecessary processing resources, latency, and to some extent unpredictability (under adverse conditions). There are applications for which network paths are established such that fixed bandwidths are allocated with bound latencies and jitter. For such applications TDM centric services are optimally suitable. At times, there are applications were packet based designs that utilize the network resources efficiently and provide ease of manageability are needed. To have the best of both worlds, a hybrid solution provides an optimized platform that allows true TDM and packet/cell based switching in an integrated environment. Figure 17-5 illustrates the architecture of a hybrid network element. Line Card
_ci
Transponder/ (Optic. • SERDES)
\^.
ia
"vl
Switch Fabric Card(s)
Nrvi
7T L/l [' |\|
I Network { / l _ J \ ; Traffic J / L K t ProcMtor if )t Managw < )i t (Optional) r \ | i X ! (Optional) S \ j \/\
XZ
iii Host Processor
Figure 17-5. Integrated TDM/Packet based line card with different switch fabrics
668
Chapter 17
In the architecture depicted in Figure 17-5, the multiservice framer separates the TDM traffic from the packet traffic and presents it on two separate buses. The TDM traffic is carried on the TFI and the packet/cell traffic is carried on the SPI-x (TFI and SPI-x buses are discussed in sections 17.4-17.7).
17.4. 2.5 GBITS/S SYSTEMS In the 1990s numerous chip vendors started offering products that catered to the burgeoning transport of IP centric data over SONET/SDH transport networks. Promoting multi-vendor chip-to-chip and module-to-module interoperability became the charter of the Physical and Link Layer (PLL) group within the Optical Networking Forum (OIF). In June 2000 the System Packet Interface level 3 (SPI-3) implementation agreement [6] was released. It defines the interface between a SONET/SDH framer and rest of the system. Originally the SPI-3 was intended for Packet over SONET (POS) applications; however, over time it has been used for different applications. SPI-3 provides a versatile bus interface for exchanging packets between various VLSI devices within the network elements supporting line-rates of OC-48 (approximately 2.5 Gb/s) or lower. Specifically the SPI-3 acts as the demarcation point between the physical layer and the link layer device. SPI3 provides isolation between the synchronous physical layer and the asynchronous packet-based, higher-layer processing units (e.g. between a SONET/SDH framer and a network processor). The SPI-3 implementation agreement defines: • The SPI-3 bus • The signaling protocol used to communicate data between devices • The data structure used to store data in First-in, First-Out (FIFOs) buffers. The SPI-3 compliant devices have independent transmit and receive data paths, which can be either 8 or 32 bits wide. The maximum standardized clock rate at which these data transfers occur is 104 MHz, allowing a maximum data throughput of 3.228 Gb/s across the bus. The bus transmit and receive clocks are independent of the line clocks and operate at different rates. To support the rate mismatch between the line clock and the internal system operating clock, decoupling FIFOs are used. To ensure the integrity of data transmission, a parity check is performed on both transmit and receive data buses. In order to support multiple PHY devices, an in-band PHY port address is inserted with the packet data that is transferred on the data bus. In SPI-3, up to 256 ports are supported. Discrete control/status signals are used to indicate start of packet, end of packet, start of transfer.
Intra-Network Elements Communication
669
error indications etc. Figure 17-6 illustrates typical usage of SPI-3 interface, where the concepts developed in [6,14] are merged. Transmit Clock
\A
hJ
Optical Transceiver
O.
L/l Nj
NJ Optical j / l Transceiver
O.
M |\|
hsj Optical j / 1 Transceiver
o.
M |\j
M Optical j / 1 Transceiver
o.
Transmit Data Bus (8 or 32 bits) Transmit I>dta Bus Parity
Multiport Physical Layer Device
Link Layer Device
Receive Data Bus (8 or 32 bits) Receive Data Bus Parity
Z ^
5^ ^
W^
Figure 17-6. Typical usage of SPI-3 interface
17-4.1
SPI-3 signal descriptions
A brief overview of the signals used in the SPI-3 interface is given below. For the complete definitions of the signals please refer to [6]. Transmit Direction (from link layer device to the PHY) Clock and Data signals TFCLK Transmit FIFO write clock is used to synchronize data transfer between the link layer device and the PHY. TDAT[31:0] Transmit Packet Data Bus; a 32 bit wide bus used to transport the packet/cell octets to be written to the selected transmit FIFO, and the in-band port address used in selecting the desired transmit FIFO. Discrete control/Status signals TENB Transmit Write Enable (TENB) signal controls the flow of data to the transmit FIFOs. The PHY device processes signals like TDAT, TMOD, TSOP, TEOP
670
TPRTY
TERR
TSOP
TEOP TMOD[1:0]
TSX
TADRfJ
DTPAfJ
STPA
PTPA
Chapter 17 and TERR when TENB is low. The TSX signal is processed when TENB is high. Transmit bus parity (TPRTY) signal, when asserted, indicates that the calculated transmit parity is being transported over the TDAT. Transmit Error Indicator (TERR) signal flags that there is an error in the current packet/cell. The error could be caused by conditions like FIFO overflow. Frame Check Sequence error, or any other user defined error condition. Transmit Start of Packet (TSOP) indicator is used to delineate the packet boundaries on the TDAT bus. TSOP being high indicates the start of the presence of a packet/cell on the TDAT bus. Transmit End of Packet signal flags the termination of the packet/cell being transmitted over the TDAT bus. Transmit Word Modulo (TMOD[1:0]) is primarily used during the transmission of the last word of the packet/cell. Since the number of octets within a packet/cell do no have to be a multiple of 32 bits, TMOD[l :0] indicates the number of valid octets in the last word being carried by the TDAT[31:0] bus. Transmit Start of Transfer (TSX) signal indicates the presence of the in-band port address on the TDAT bus. When TSX along with TENB is high, the value of TDAT[7:0] represents the address of the selected transmit FIFO. Transmit PHY Address (TADR[]) bus is used in conjunction with the PTPA signal to poll availability of the respective transmit FIFO. Direct Transmit Packet Available (DTPA[]) bus indicates the status of the FIFO (whether it is available to accept data or not), corresponding to the respective ports in the PHY device. Selected-PHY Transmit Packet Available (STPA) signal indicates whether the addressed transmit FIFO (that is addressed by the content on the TDAT bus) is full or not. This signal is primarily used when in ByteLevel mode Polled-PHY Transmit Packet Available (PTPA) signal is used when in Packet-level mode. It indicates whether the polled transmit FIFO is full or not. The
Intra-Network Elements Communication
671
selected polled PHY is addressed by the contents of the TADR address bus. Receive Direction (from the PHY to the link layer device) Clock and Data signals RFCLK Receive FIFO Write Clock (RFCLK). RDAT[31:0] Receive Packet Data Bus (RDAT[31:0]) a 32-bit wide bus used to transport the packet/cell octets to be written to the selected receive FIFO, and the in-band port address used in selecting the desired receive FIFO. Discrete control/Status signals RVAL Receive Data Valid (RVAL) signal, when high, indicates the validity of the receive data signals; RDAT[31:0], RMOD[1:0], RSOP, REOP, and RERR. RENB Receive Read Enable (RENB) signal is used for controlling the flow of data from the receive FIFOs. During data transfer, RVAL must be monitored as it indicates the validity of the RDAT[31:0], RPRTY, RMOD[1:0], RSOP, REOP, RERR, and RSX signals. RPRTY Receive Parity (RPRTY) signal, when asserted, indicates that the calculated receive parity is being transported over the RDAT bus. RMOD[1:0] Receive Word Modulo (RMOD) signal is primarily used during the transmission of the last word of the packet/cell. Since the number of octets within a packet/cell do no have to be a multiple of 32 bits, RMOD[1:0] indicates the number of valid octets in the last word being carried by RDAT[31:0]. RSOP Receive Start of Packet (RSOP) flag is used to delineate the packet boundaries on the RDAT bus. RSOP being high indicates the start of the presence of a packet/cell on the RDAT bus. REOP Receive End of Packet (REOP) signal flags the termination of the packet/cell being transmitted over the RDAT bus. RERR Receive error indicator (RERR) signal flags that there is an error in the current received packet/cell. The error could be caused by conditions like FIFO overflow. Frame Check Sequence error, abort sequence or any other user defined error condition.
672 RSX
17.5.
Chapter 17 Receive Start of Transfer (RSX) signal indicates the presence of the in-band port address on the RDAT bus. When RSX is high, the value of RDAT[7:0] represents the address of the selected receive FIFO from which the subsequent data on the RDAT bus will be transferred.
10 GBITS/S SYSTEMS
As a natural progression to the systems operating at 2.5 Gb/s line rate, OIF generated 10 Gb/s systems implementation agreements in two phases. In the first phase the System Framer Intererface-4 Phase I (SFI-4 Phase 1) [7] and System Packet Interface-4 Phase 1 (SPI-4 Phase 1) [8] were released in September 2000. In phase 2, a reduced signal count based, 10 Gb/s recommendations for both the SFI-4 and SPI-4 were introduced. SFI-4 phase 2 [9] was introduced in September 2002 and SPI-4 phase 2 [10] in October 2003. Subsequent sections give an overview of the implementation agreements. For exact details, it is highly recommended that the reader refer to the implementation agreement documents released by OIF.
17.5.1 System Framer Interface-4 Phase 1 (SFI-4 Phase 1) SFI-4 phase 1 is a relatively simple interface that primarily defines the clocking scheme and the data signals between the STS-192/STM-64 SERDES and SONET/Framer. SFI-4 can also be extended to the OTN applications. It consists of two independent sixteen bit data buses, one in the receive direction and the other in the transmit direction. In the receive direction, the SERDES recovers the clock from the received line data and provides the receive clock to the framer. In the transmit direction, the SERDES uses the reference clock and provides a source clock to the framer. The framer subsequently uses the transmit clock source to generate the transmit clock and the associated data signals to the SERDES. The SERDES, in the receive direction, takes the serial line data and converts it into raw sixteen bit wide parallel data. It is the framer that extracts the framing from the incoming data stream and establishes the byte boundaries for further processing. In the transmit direction the SERDES takes in sixteen-bit wide data and converts it into serial stream for transmission over the physical link. Figure 17-7 depicts the typical usage of the SFI-4 phase 1 interface. In the STS-192/STM-64 applications an aggregated throughput of 9.9532 Gb/s is transported in each direction. This throughput is achieved by sixteen 622.08 Mb/s differential data lines in both
Intra-Network Elements Communication
673
transmit and receive directions. The SFI-4 phase 1 is defined to support up to speeds of 10.66 Gb/s. System to Optics Transmit Direction
_P
REFCLK
1 TXDATA[15.0]
< ^
Transmit Clock
•
Transmit
• ^Transmit Clock Source
Serializer/ Deserializer (SERDES)
FRAMER (e.g. SONET/5>DH or OTN)
Electro/Optic Module
IOCpATA|15:0] ^
Receive Clock
^ Receive Sync Error
,
^
Receive
Optic 5 to System Receix^e Direction
Figure 17-7. Typical usage of SFI-4 Phase 1 interface
A brief overview of the signals used in the SPI-4 phase 1 interface is given below. For the complete definitions of the signals please refer to [7]. Transmit direction (framer to SERDES) TXData[15:0] A 16 bit transmit data bus that is used to transport the data from the framer to the SERDES. Each bit lane is transporting data at a rate of 622.08 Mb/s. TXCLKJPN 622.08/311 MHz transmit clock used by the TXData bus. TXCLK_SRC__PN 622.08 MHz transmit reference clock that is provided by the SERDES to the framer. Receive direction (framer to SERDES) RXData[15:0] A 16 bit receive data bus that used to transport the data from the SERDES to the framer. Each bit lane is transporting data at a rate of 622.08 Mb/s. RXCLKJPN 622.08/311 MHz receive clock used by the RXData bus.
674
Chapter 17
Miscellaneous Signals REFCLKPN 622.08 MHz board reference clock used by the SERDES. SYNCJERR This signal indicates that RXCLK and RXData are not derived from the received optical signal. PHASEJNIT This is used to reset the SERDES clocking interface. PHASEERR This signal, when asserted, flags that the phase of the TXCLK with respect to the SERDES internal clock is out of specification.
17.5.2
SPI-4 Phase 1 (OC-192 System Packet Interface)
The SPI-4 phase 1 interface supports the transfer of packets or cells at STS-192/STM64 rates with the maximum throughput capacity of 12.8 Gb/s. It is used to transfer information between physical layer and the link layer device (framer to network processor), or between peer devices (network processor and traffic manager, traffic manager and switch fabric, or network processor and security processor, etc.). Figure 17-8 illustrates the typical usage of the SPI-4 phase 1 interface [8]. During the development of the SPI4 phase 1, the specification developers, to mitigate the risk and shorten the time-to-market, took a conservative approach and recommended a wide and relatively slower rate interface. Some of the key features of the interface are [8,14]: 1. Supports transfer of variable length packets and fixed length cells 2. Independent 64-bit wide receive and transmit buses operating with a clock rate of 200 MHz, thereby, allowing a throughput of 12.8 Gb/s 3. Parity checking to ensure data integrity 4. Discrete address bus to support out-of-band addressing and multiple PHY devices 5. Discrete control signals that indicate start of packet, end of packet, error indications etc. 6. Synchronous continual transmission of FIFO (receive and transmit) information for flow control purposes. A brief overview of the signals used in the SPI-4 phase 1 interface is given below. For the complete definitions of the signals please refer to [8]. Transmit Direction (from the system to the PHY) Clock and Data signals TxData[63:0] A 64-bit transmit data bus that is used to transport the data from the system side to the PHY. The data on this bus is valid when TxValid is asserted.
Intra-Network Elements Communication
675
TxClk
Transmit clock has a nominal frequency of 200 MHz and is used by the PHY device to sample the Tx signals. Discrete control/Status signals TxValid Transmit data valid when asserted is used by TxData[63:0], TxAddr[n-l:0], TxSOCP, TxEOP and TxSize at the respective times. TxSOCP Transmit start of cell or packet flags the beginning of packet or cell available on the TxData bus. TxEOP Transmit end of packet indicates the end of packet or cell on the TxData bus.
Transmit Clock Transmit Address Bus (n bits) Transmit Data Bus (64 bits) Transmit Data Bus Parity
^
Z^
^H^
i^
^ Receive Flow Control (5 bits)
Link Layer Device Transmit Flow Control (5 bits)
Physical Layer Device (PHY)
Receive Address Bus (n
Figure J 7-8. Typical usage of SPI-4 phase 1 interface
TxAddr[n-l:0]
Transmit PHY port or channel address, n bits of address supports up to 2" ports or channels. The TxAddr signals are only sampled when TxValid is asserted, and are ignored when TxValid is deasserted.
676
Chapter 17
These signals determine the port or channel associated with the TxData, TxSOCP, TxEOP, TxError, TxSize, and TxValid signals. TxPrtyf3:0] Transmit data parity bus represents the parity bits calculated over the TxData bus. TxPrty[0] provides parity over TxData[15:0] portion of the TxData bus. Likewise TxPrty[l], TxPrty[2], and TxPrty[3] provide parity over TxData[31:16], TxData[47:32], and TxData[63:48] respectively. TxError Transmit data error flags that there is an error in the current transmit packet/cell. The error could be caused due to conditions like FIFO overflow, abort sequence or any other user defined error condition. It is processed only when TxValid and TxEOP signals are asserted. TxSize[2:0] Transmit octet count signal is primarily used during the transmission of the last word of the packet/cell. It indicates the number of valid octets during the transmission of the last word. Values from 1-7 represent the respective number of octets present, while a value of a 0 indicates 8 valid octets present in the last word. TxStart Transmit flow control frame start is sourced by the PHY device to flow control the link layer device. TxFull[3:0] Transmit flow control full indication is sourced by the PHY layer to inform the link layer about its buffers being full. The complete status of the channels is time multiplexed onto these four signals. Receive Direction (from the PHY to the system) Clock and Data signals RxData[63:0] A 64-bit receive data bus that is used to transport the data from the PHY to the system side. The data on this bus is valid when RxValid is asserted. RxClk Receive clock has a nominal frequency of 200 MHz and is used by the link layer device to sample the Rx signals. Discrete control/Status signals RxValid Receive data valid when asserted is used by RxData[63:0], RxAddr[n-l:0], RxSOCP, RxEOP and RxSize at the respective times. RxSOCP Receive start of cell or packet flags the beginning of packet or cell available on the RxData bus.
Intra-Network Elements Communication RxEOP RxAddr[n-l:0]
RxPrty[3:0]
RxError
RxSize[2:0]
RxStart RxFull[3:0]
17.5.3
611
Receive end of packet indicates the end of the packet or ceil on the RxData bus. Receive PHY port or channel address, n bits of address supports up to 2"^ ports or channels. The Rx address signals are only sampled when RxValid is asserted and are ignored when RxValid is deasserted. These signals determine the port or channel associated with the RxData, RxSOCP, RxEOP, RxError, RxSize, and RxValid signals. Receive data parity bus represents the parity bits calculated over the RxData bus. Rxprty[0] provides parity over RxData[15:0] portion of the RxData bus. Likewise RxPrty[l], RxPrty[2] and RxPrty[3] provide parity over RxData[31:16], RxData[47:32] and RxData[63:48] respectively. Receive data error flags that there is an error in the current transmit packet/cell. The error could be caused due to conditions like FIFO overflow, abort sequence or any other user-defined error condition. It is processed only when RxValid and RxEOP signals are asserted. Receive octet count signal is primarily used during the transport of the last word of the packet/cell on the RxData bus. It indicates the number of valid received octets during the last word. Values from 1-7 represent the respective number of octets present, while a 0 indicates 8 valid octets present in the last word. Receive flow control frame start is sourced by the link layer device to flow control the PHY. Receive flow control full indication is sourced by the link layer to inform the PHY about its buffers being full. The complete status of the channels is time multiplexed onto these four signals.
System Framer Interface-4 Phase 2 (SFI-4 Phase 2)
With the desire to fit more and more components on the same Printed Circuit Board (PCB), the developers of SFI-4 phase 2 project capitalized on the ability to specify high speed signal paths. They developed a narrower 4bit independent transmit and receive data paths. The introduction of the high-speed signals posed the challenge of ensuring very low bit-error rates. It is a well known fact, that with the high speed transmission of signals, the
678
Chapter 17
probability of transmission errors increases. To reduce the transmission error probability SFI-2 phase 2 [9] incorporated FEC mechanism between the SERDES and the framer. Moreover, in the SFI-4 phase 2, the byte and lane alignment processing along with clock encoding within the data stream is performed by using a 64b/66b encoding scheme. Figure 17-9 illustrated the reference model used in defining the SFI-4 phase 2 recommendation. The reference points A, B, C and D are used in defining the parameters associated with the interface. As we have seen in the earlier chapters, there is no one particular transport technology that is ideally suitable for a diverse set of traffic types. Therefore, from the outset, it was realized that this interface should be protocol agnostic that supports popular transport technologies such as 10 Gigabit Ethernet, STS-192/STM-64, G.709, 10 Gigabit Fibre Channel, and proprietary data streams. Some of the key features of the SFI-4 phase 2 are [9,14]: 1. Independent 4 bit wide data bus in the transmit and receive direction 2. Embedded clock within the data stream 3. Each bus lane operating at a minimum of 2.488 Gb/s with an aggregated throughput of 9.95328 Gb/s. Under certain circumstances the specification allows the interface to operate at 12.5 Gb/s. System to Optics Transmit Direction REFCK
REFCK
C
REFCK
C
P TXDATA[3:0]
P
I TXDATA[3:01
J^L^
Transmit ^ [ TXCKSRC I FRAMER (e.g. SONET/SDH orOTN)
Serializer/ Deserializer (SERDES)
FEC Processor
^ I RXDATA[3:01 |
RXDATA[3:0]
^-CL Receive
Optics to System Receive Direction
Figure 17-9. Reference model of SFI-4 phase 2
A brief overview of the signals used in the SFI-4 phase 2 interface is given below. For the complete definitions of the signals please refer to [9].
Intra-Network Elements Communication
679
Transmit direction (framer to SERDES) TXData[3:0] A 4-bit transmit data bus that used to transport the data from the framer to the SERDES. Each bit lane transports 64b/66b encoded data at a rate of 2.566 Gb/s to 3.125 Gb/s. TXCKSRC Transmit clock has a nominal frequency of 622.08 MHz with 50% duty cycle. It is used by the TxData bus. Receive direction (framer to SERDES) RXData[3:0] A 4-bit receive data bus that used to transport the data from the SERDES to the framer. Each bit lane transports 64b/66b encoded data at a rate of 2.566 Gb/s to 3.125 Gb/s. Reference Clock REFCK The Reference Clock is a reference used for transmit data path timing. It has a nominal frequency of 622.08 MHz.
17.6.
SPI-4 PHASE 2 (OC-192 SYSTEM PACKET INTERFACE)
SPI-4 Phase 2 [10] is a nimble interface with a significantly lower number of signals than phase 1. Phase 2 took advantage of the advances in the high-speed electronics by defining a faster interface that is narrower than the SPI-4 Phase 1. This resulted in the reduction of the number of traces required on a PCB and the pins on the VLSI devices. It provides isolation between transmit and receive directions by making them completely separate and independent of each other. Similar to its predecessors, SPI-4 phase 2 interface is also protocol agnostic. It can be used in the transport of Packet over SONET, any packet centric Generic Framing Procedure (GFP) mapped data (which could include the encapsulation of Ethernet or Fibre Channel, ATM, constant bit-rate traffic over GFP) or any proprietary data scheme. Figure 17-10 [14] illustrates a typical application of the SPI-4 phase 2 interface. Since the physical layer device, e.g., a framer, and the link layer device operate at different clock frequencies, FIFOs are used in both transmit and receive directions to accommodate the clock mismatches. Sending the FIFOs status over out-of-band control channels (via the respective FIFO status signals) provides isolation between transmit and receive paths. The variable length control and the payload data is transferred between the devices in bursts as illustrated in Figure 17-11. The packets can be of variable sizes
Chapter 17
680
with upper and lower limits. The transferred packets have to be multiples of sixteen bytes except when terminated with an asserted End ofPacket signal.
Transmit Clock Transmit Data Bus (16 bits)
Transmit Direction
Transmit Control Transmit FIFO Status (2 bits)
^ Link Layer Device Receive Direction
Transmit FIFO Status Clock
Receive Clock
^• ^^^ w
Physical Layer Device (PHY)
\^^ ^ ^ R ^ c e i v ^ a t ^ u ^ l ^ i t s ) v^T
^
Receive Control Receive FIFO Status (2 bits) Receive FIFO Status Clock
Figure 17-10. SPI-4 phase 2 system reference diagram
Payload Control
Payload Data (ATM Cell)
Payload Control
Payload Data (Packet)
Payload Control
Payload Data (ATM Cell)
Payload Control
Payload Data 1
(Packet) J
Figure 17-11. Transferred data stream consisting of interleaved control and payload data.
A brief overview of the signals used in the SPI-4 phase 2 is given below. For complete definitions of the signals please refer to [10]. Transmit Direction (from the system to the PHY) Clock and Data signals TDCLK Transmit Clock has a nominal frequency of 311 Mhz. It is used as the timing source by the transmit data and control signals. TDAT[15:0] Transmit data bus used for transporting the payload data and in-band control words from the link layer device to the PHY device. Minimum data rate on each line is 622 Mb/s. TSCLK Transmit status clock is used in sampling TSTAT signals.
Intra-Network Elements Communication
681
Discrete control/Status signals TCTL Transmit Control, when asserted indicates the presence of control words on the TDAT bus. TSTAT[1:0] Transmit FIFO Status is used to carry FIFO status information in a round robin scheme. It also carries associated errors detected or framing information. Receive Direction (from the PHY to the system) Clock and Data signals RDCLK Receive Clock has a nominal frequency of 311 Mhz. It is used as the timing source by the receive data and control signals. RDAT[15:0] Receive data bus used for transporting the pay load data and in-band control words from the PHY device and the link layer device. Minimum data rate on each line is 622 Mb/s. RSCLK Receive status clock is used in sampling RSTAT signals. Discrete control/Status signals RCTL Receive Control, when asserted indicates the presence of control words on the RDAT bus. RSTATfL'OJ Receive FIFO Status is used to carry FIFO status information in a round robin scheme. It also carries associated detected errors or framing information.
17.7.
40 GBITS/S SYSTEMS
As we can see from Figures 17-3 and 17-5, the data centric line cards consist of Optical transceivers, Serializer/Deserializer, Forward Error Correction processor, Framer, Network Processor, Traffic Manager and Switch Fabric Interface Device. OIF, true to its form, once again took the lead in defining implementation agreements of several chip-to-chip communication interfaces that allow the networking gear manufacturers to use VLSI devices with standardized interfaces. It allowed them to use VLSI devices from different IC vendors, operating at 40 Gb/s throughputs. At the 40Gb/s rates, there are three types of interfaces that have been defined by OIF's Physical and Link Layer (PLL) working group. They are • SFI-5 Serdes Framer Interface-5 • SPI-5 System Packet Interface-5 • TFI-5 TDM Fabric to Framer Interface-5 The electrical characteristics of SFI-5 and SPI-5 are defined in [13].
682
11.1A
Chapter 17
SERDES Framer Interface-S (SFI-5)
SFI-5 [11] defines the communication between SERDES, FEC processor, and a framer (typically a SONET/SDH or G.709 framer) device. Figure 1712 depicts a system model illustrating the interconnecting electrical signals between the devices. In the receive direction, the serial data operating at approximately 40 Gb/s from the optics is converted into parallel data by the SERDES. The parallel data signals are relatively lower speed signals (each data channel of the data bus operating at 3.125 Gb/s). The SERDES is typically connected to either an FEC processor or a framer. At these higher operating speeds, one of the interesting challenges is to accommodate the data skew between the data channels of the respective data bus. This skew is primarily caused by the trace length mismatches that can be quite significant. SFI-5 incorporates a separate deskew channel in both transmit and receive directions that continuously provides data samples to the deskewing algorithm. The deskewing takes place at the sink of the respective signals. System to Optics Transmit Direction TXREFCK
1,
TXDATA[15:0J
(:TXDATA[15:0] I) TXDSC =#
r4
TXDSC TXDCK
y
** ^B
Serializer/ Deserializer (SERDES)
IRXDATA11S:0J|
RXDSC
kn
RXDCK
^
RXS
^
I
FEC Processor
RXDATA[1S:0]
.
Transmit
TXCKSRC
^
I3
(^
TXDCK
TXCKSRC
FRAMER (e.g. SONET/SDH or OTN)
\
A
RXDSC RXDCK
B ^
"^-
. | Framer + TF\-5 K .
V\
Mapper
TFI-SLink
N
^J . yi
\/\
Figure 17-14. TFI-5 System reference model
17.8.
ACKNOWLEDGEMENTS
The author would hke to acknowledge review comments and input provided by Alan Reynolds, Andrew Reynolds and Osman Ahmad.
17.9. [1] [2] [3]
REFERENCES Lightreading Webinar , "Packet Aware Transport", www.lightreading.com, February 10,2005. http://www.asi-sig.org Gary Lee, "Advanced Switching in Communication Systems", http://www.asisig.org/education/whitepapers/AS_in_Communication_Systems_-_fmal.pdf.
Intra-Network Elements Communication [4] [5] [6] [7]
[8]
[9]
[10]
[11]
[12]
[13] [ 14] [15]
689
Panos C. Lekkas, "Network Processors: Architecture, Protocols and Platforms", McGraw-Hill, 2003. H. Jonathan Chao, Cheuk H. Lam and Eiji Oki, "Broadband Packet Switching Technologies: A Practical Guide to ATM Switches and IP Routers", Wiley, 2001. OIF Implementation Agreement OIF-SPI3-01.0, "System Packet Level 3 (SPI-3): OC48 System Interface for Physical and Link Layer Devices", June 2000. OIF Implementation Agreement OIF-SFI4-01.0, "SFI-4 (OC-192 Serdes-Framer interface) OIF-PLL-02.0 - Proposal for a common electrical interface between SONET framer and serializer/deserializer parts for OC-192 interfaces", September 2000. OIF Implementation Agreement OIF-SPI4-01.0, "System Physical Interface Level 4 (SPI-4) Phase 1: A System Interface for Interconnection Between Physical and Link Layer, or Peer-to-Peer Entities Operating at an OC-192 Rate (10 Gb/s)", September 2000. OIF Implementation Agreement OIF-SFI4-02.0, "SERDES Framer Interface Level 4 (SFI-4) Phase 2: Implementation Agreement for lOGb/s Interface for Physical Layer Devices", September 2002. OIF Implementation Agreement OIF-SPI4-02.1, "System Packet Interface Level 4 (SPI-4) Phase 2 Revision 1: OC-192 System Interface for Physical and Link Layer Devices", October 2003. OIF Implementation Agreement OIF-SFI5-01.0, "Serdes Framer Interface Level 5 (SFI-5): Implementation Agreement for 40Gb/s Interface for Physical Layer Devices", January 2002. OIF Implementation Agreement OIF-SPI5-01.1, "System Packet Interface Level 5 (SPI-5): OC-768 System Interface for Physical and Link Layer Devices", September 2002. Optical Internetworking Forum OIF2001.149, "SxI-5: Electrical Characteristics for 2.488 - 3.125 Gbps parallel interfaces," October 2002. Tom Palkert, "OIF OC-48, OC-192 & OC-768 Electrical Interfaces", http://www.oiforum.com/public/documents/Electrical_InterfacesWP.pdf Optical Internetworking Forum OIF-TFI-5-01.0, "TFI-5: TDM Fabric to Framer Interface Implementation Agreement," September 16, 2003.
This page intentionally blank
Chapter 18 ITU OPTICAL INTERFACE STANDARDS Evolution and its Impact on Implementations Peter J.J. Stassar Networking Consultant
18.1. INTRODUCTION Over the past 20 years, optical transmission systems have evolved from fairly simple, single span, point-to-point configurations, operated at a single wavelength, to rather complex multiwavelength, multispan, point-to-multipoint architectures. Within the context of this evolution, the International Telecommunication Union (ITU) has developed a wide range of optical interface recommendations, beginning with PDH applications and later addressing SDH/SONET, DWDM, and OTN applications. An historical perspective of the various ITU recommendations is provided in this chapter, addressing not only the maturation of the industry but also the intent to use standards to modify the application space from low-volume and high cost conditions to cost-efficient and high-volume conditions. Towards that end, a description of the migration from proprietary optical solutions with custom and discrete components towards standardized integrated solutions supported by Multi-Source-Agreements (MSAs) is discussed. The intent of this chapter is to provide the reader with a basic understanding of ITU's objectives, terminology, and typical content found within the various optical interface recommendations. Moreover, the impact that the recommendations have on practical applications and designs is also
692
Chapter 18
addressed. In this chapter, detailed specifications are not discussed, as a complete treatment of optical parameters, mechanisms, and designs is beyond the scope of this text. References to various standards documents are cited as appropriate. Finally, some information is provided on the use and implementation of optical alarms and degradation monitors. Despite the fact that the latter topic is not directly related to optical interface implementations, it is a thoroughly studied item within ITU, and as such its treatment in this chapter will prove very useful to gain a better understanding of the challenges and sensitivities surrounding the optical standards process.
18.2.
ITU OPTICAL INTERFACE STANDARDS
18.2.1 Historical perspective 18.2.1.1 PDH Between 1980 and 1988, the ITU developed two recommendations for specifying Plesiochronous Digital Hierarchy (PDH) optical line systems. Recommendation G.955 [1] contained specifications for PDH line systems for the 1.544 kbit/s hierarchy (24-channel market, mainly deployed in the USA and Canada), and Recommendation G.956 addressed PDH line systems for the 2048 kbit/s hierarchy (32-channel market). In the 1990s, both recommendations were "collapsed" into a single recommendation, namely G.955, and G.956 was subsequently withdrawn. These recommendations are no longer relevant for today's market; however, they laid the foundation for how optical interfaces are specified within the ITU, a process that has been followed in subsequent ITU recommendations. In this approach to specifying optical interfaces, only the characteristics of the fiber optic plant,^ principally the attenuation and the dispersion, are specified. This approach to specifying optical interfaces, where the performance properties of the transmitter and receiver are not addressed, is called longitudinal compatibility. Longitudinal compatibility implies that on a certain link, with standardized characteristics, the equipment on both sides of the link must be from the same vendor. In this case, the transmitter and receiver performance properties and characteristics were proprietary. In the case of PDH apphcations, it was also not uncommon to use proprietary balanced coding techniques, e.g., 5B/6B, to provide stable link performance. In this way, 140 Mbit/s or 4*140 Mbit/s equipment.
ITU Optical Interface Standards
693
employing 5B/6B coding, actually operated with a line rate of 168 and 672 Mbit/s, respectively. In the 1980s, optical components were a significant contributor to the cost of an optical transmission system. As such, Recommendation G.955 focussed only on long-haul systems, where the cost of the optical devices could be balanced by maximizing the transmission distances. The principle of longitudinal compatibility is discussed further in Section 18.2.2. 18.2.1.2 SDH/SONET In 1988, the revolutionary concept of developing optical links with interoperable equipment from different manufacturers was introduced to ITU by Bellcore (currently called Telcordia). For a truly interoperable link, more parameters beyond just the fiber plant had to be specified. This new set of specifications was titled SDH/SONET for the global/North American markets, respectively. Initially, this interworking concept was called midspan-meet, implying that at a certain point on the fiber link between two pieces of optical equipment, the interoperability had to be guaranteed through a specified set of parameters and associated values. Because this point was not at a fixed location, but rather at an unknown "floating" location, it was not considered appropriate for a specification principle. A floating approach lends itself to specifying formulas instead of values and is, as such, cumbersome to implement. Instead the complete optical configuration was split into three parts: transmitter equipment, the actual outside plant, and receiver equipment. These three parts were separated by two fixed reference points, namely. Point S, located between the transmitter and the outside plant; and Point R, located between the outside plant and the receiver. At these reference points, a complete and detailed set of transmitter and receiver parameters and associated values were specified. This principle of specification was called transverse compatibility, where the intent was to achieve interoperability between different manufacturers' equipment so long as the specifications were met at Points S and R. Note that the previous term, mid-span-meet, is commonly used as an alternative expression to transverse compatibility, although that usage of the term is not strictly correct. Within transverse compatibility, it is important to note that the optical path or outside fiber plant is not specified by distance but rather by parameters like attenuation range, maximum (and sometimes minimum) chromatic dispersion, Differential Group Delay (DGD), etc. Distance is not a specification and is only used for the purpose of classification. A specific transmission distance can never be guaranteed, since it fully depends on local conditions associated with the fiber link, e.g., number of splices, loss/splice, presence of patching panel connectors, etc. Transverse
694
Chapter 18
compatibility has become the standardization method of choice for all modem ITU recommendations for optical interfaces. The details of transverse compatibility are further discussed in Section 18.2.2, where a reference diagram is shown. The first relevant ITU recommendation for SDH optical interfaces was G.957 [2], in which optical parameter values for STM-1 (OC-3), STM-4 (OC-12), and STM-16 (OC-48) applications were specified for distances up to 80 km. Note, that the transmission distance of 80 km is a point of classification, not a guarantee of transmission reach. Recommendation G.957 has become a template for all subsequent ITU optical interface recommendations. During the development of G.957, the extensive experience with PDH implementations for 140 Mbit/s and 4*140 Mbit/s was reused to define the STM-1 and STM-4 parameter values. Because of the maturity of the technology for these applications, the associated parameter values have hardly been modified since the first agreements in 1990. This is, however, not true for the STM-16 parameter values. The first set of values, agreed upon in 1990, was based on the limited availability of initial test results from prototype systems. Nevertheless, the availability of an early version of an STM-16 optical interface specification appeared to be a major market driver for next generation optical applications. The wide-scale deployment of STM-16 optical interfaces resulted in a strong enough knowledge base that ITU was able to readdress the initial STM-16 specification with an update based on a "mature" set of parameter values several years later. Around 1990, a market need for a higher transmission capacity of 10 Gbit/s in SDH/SONET transmission systems was foreseen, and the ITU started to work on a new set of optical interface recommendations to accommodate that need. At the same time the new Erbium Doped Fiber Amplifier (EDFA) technology became available, enabling longer transmission distances and multiwavelength operation on a single fiber. Optical amplifiers were being used to increase transmitter output powers (booster configuration) and to improve receiver sensitivities (optical preamplifier configuration). They were also deployed as line amplifiers by positioning them at intermediate positions on very long fiber links (multispan configuration). In this way, the physical distance between transmitting and receiving equipment could be substantially increased to multiples of the original distances specified in G.957. Because optical amplifiers were also operating over a wide optical bandwidth, well over 30 nm, they were capable of simultaneously amplifying the power levels of multiple, narrowly spaced signals (also called channels) over a single transmission fiber. The latter application, also called Dense Wavelength
ITU Optical Interface Standards
695
Division Multiplexing {DWDM), will be further discussed in Section 18.2.1.3. Because of the availability of this new optical amplifier technology, ITU decided to specify the new SDH/SONET rate of STM-64/OC-192 (--10 Gbit/s) along with multiwavelength (multichannel) configurations operating at 2.5 Gbit/s/channel, each with its own characteristic wavelength, as an alternative to the single-wavelength (single-channel) application at the STM64/OC-192 rate. The multichannel application is further discussed under Section 18.2.1.3. In order to maintain the stability of Recommendation G.957, the ITU decided to put the new sets of parameter values for STM-4 and STM-16 applications with extended distances (longer than 80 km) via OA (Optical Amplifier) technology, and the new STM-64 (OC-192) applications, into a new recommendation called G.691. Initially, it was the intent to define transversely compatible parameter value sets for both single and multiple spans. Due to a variety of reasons, the ITU discontinued the attempt to include specifications for multiple spans. It appeared to be a too significant challenge to define an unambiguous set of optical parameter values for multispan configurations incorporating line optical amplifiers. Furthermore, the ITU was unable to agree on the specification for a standard Optical Supervisory Channel (OSC), necessary for maintenance of the inline optical amplifiers. The relevant optical parameter values for SONET applications OC-3 to OC-192 can be found in Telcordia's GR-253-CORE [3], which in most cases are consistent with the ITU specifications. Originally, the OC-192 specifications were put into a separate Telcordia specification, GR-1377, but these were incorporated into GR-253-CORE at a later stage. 18.2.1.3
DWDM
As discussed in Section 18.2.1.2, the early 1990s presented a market need for SDH/SONET transmission systems that could operate at per-channel data rates greater than 2.5 Gbit/s. Because of initial concerns about the cost of 10 Gbit/s optics (including the necessity to use optical amplifiers) and possible limitations due to Polarization Mode Dispersion (PMD) on the installed fiber base, it was decided to prepare a second recommendation, namely G.692 [4], for multichannel SDH STM-4 and STM-16 applications. In general, these applications with closely spaced channels are referred to as Dense Wavelength Division Multiplexing {DWDM) applications. Initially, it was the ITU's objective to define a transversely compatible specification for these multichannel DWDM applications, but ultimately it was unable to agree on a channel plan (unique set of wavelengths) for these
696
Chapter 18
applications. Naturally, to guarantee interoperability, it is essential that different manufacturer's equipment transmit on exactly the same set of wavelengths and follow the same sequence for "lighting up" new wavelengths. However, some network operators felt that the channel plan would restrict their ability to optimize the usage of their installed outside plant. Additionally, the market pressure on equipment vendors to increase performance by adding channels to the fiber (requiring that the channel-tochannel spacing becomes narrower) and increasing transmission distances necessitated that optical technology advance at a rampant pace. This pace gave the impression that there was little stability in the solution and that any attempt to standardize this solution within G.692 would be promptly outdated. The market conditions mandated that equipment vendors constantly design their equipment at the edge of available technology. Furthermore, because of the usage of optical amplifiers, the fibers operated in a nonlinear regime, making the matter even more complex from a standardization perspective. Therefore, the published version of G.692 contains the statement that it was aimed towards a fiature realization of transverse compatible multichannel systems. It contains listings of parameters that would be required in the case that a transversely compatible specification was ever developed for a multichannel system. Specific values were not included in this specification. The resulting Recommendation G.692 is actually a longitudinally compatible specification. One of the main achievements of Recommendation G.692 was agreement on a frequency grid for DWDM applications, a grid that is followed even today. Because G.692 was an SDH-related recommendation, the ITU ultimately decided to put the grid definition and specification in a separate Recommendation G.694.1 [5] for generic DWDM applications. In G.694.1, the actual channel frequencies are not specified. Instead, G.694.1 provides a ruler or formula, anchored to 193.1 THz, with which to calculate the channel frequencies for a variety of channel spacings, ranging from 12.5 GHz to 100 GHz. Within the context of grid definitions, it is important to note that the ITU decided to maintain a wavelength-based signal spectral specification for widely spaced signals and a frequency specification for narrowly spaced signals. At first pass, this appears to be a confusing way to specify wavelengths. The reason for this choice is the fact that a frequency specification is exact and unambiguous, whereas a wavelength specification depends on the medium in which the wavelength is measured (air, vacuum and glass all have different values for the speed of light, which is used to calculate wavelength from frequency^. As an indication for the demarcation point between the two specification methods, it can be noted that in G.692, the frequency-based specification is used up to a channel spacing of 1000
ITU Optical Interface Standards
697
GHz (equivalent to approximately 8 nm), above which a wavelength-based specification is used. Very recently the ITU established two new recommendations for DWDM applications intended for use within the Optical Transport Network, described in Section 18.2.1.4. In Recommendation G.696.1 [26] physical layer specifications are given for point-to-point multispan DWDM applications within a single administrative domain with bitrates up to 40 Gbit/s. Because of the technical complexity of these systems, the specifications given in G.696.1 are longitudinally compatible, thus with equipment from a single vendor. As in the case of Recommendation G.692, this means that specifications are provided only for the outside plant. G.696.1 further contains some extensive information on theoretical limits and design considerations for DWDM systems. In Recommendation G.698.1 [27] optical interface specifications are given for transversely compatible point-to-point DWDM systems in a metro environment. By using the black-link specification method, as described for CWDM applications in Section 18.2.1.5, interworking is enabled at the single-channel points, i.e. at the inputs of the multiplexer and at the outputs of the demultiplexer. The realization of this transversely compatible DWDM recommendation has been a ground-breaking achievement, enabling operators to mix and match equipment from different vendors at the singlechannel level. G.698.1 contains specifications for applications with a channel spacing of 100 GHz, bitrates up to 10 Gbit/s, covering transmission distances in the range of 30 to 80 km. For further details, see Recommendation G.698.1. In a similar way as for CWDM applications, G.698.1 is relevant to the new hot-pluggable SFP and XFP packaging technologies described in Sections 18.3.2.2 and 18.3.3.2. Future versions of G.698.1 are intended to address the inclusion of optical amplifiers in order to achieve transmission distances longer than 80 km, further widening the application space for network operators to deploy multi-vendor DWDM systems. 18.2.1.4 OTN In 1996, the potential use of DWDM technologies was recognized as having the opportunity to extend beyond relatively straightforward point-topoint applications. ITU embarked on a new generation of recommendations intended to support the Optical Transport Network (OTN), which would include formats beyond SDH/SONET. As an example, the new OTN would address Forward Error Correcting (FEC) codes (which were once proprietary to the equipment vendor) and enhanced optical network architectures, which
698
Chapter 18
included new optical network elements like Optical Add Drop Multiplexers (OADMs) and Optical Cross Connects (OXCs). Details on OTN architecture and the associated rates and formats specifications are contained in a variety of ITU recommendations, including G.872 [6] and G.709 [7]. The ITU decided to make a distinction in optical interfaces for IntraDomain Interfaces (laDI) and Inter-Domain Interfaces (IrDI). As is clarified in Recommendation G.872, the laDI refers to a physical interface that lies within an administrative domain and the IrDI to a physical interface representing the boundary between two administrative domains. In general an IrDI will be bound by 3R regeneration at both sides of the interface. 3R regeneration requires that the signal is re-amplified, reshaped and retimed. Currently, transversely compatible optical interface specifications are only required for the IrDI. The IrDI configurations are relatively simple in that they are limited to a single span and are either single-channel (singlewavelength) or 16-channel configurations. The required technology for these IrDI applications was considered sufficiently mature to create a basis for agreement on complete sets of transversely compatible parameter values. Because the laDI involved more complex optical architectures, like very long distance multi-span configurations with high numbers of closely spaced channels, possibly including OADM configurations, it was decided to specify the laDI optical interfaces in a longitudinally compatible form. This kind of specification provides the highest level of freedom and flexibility for designing systems for the laDI. To illustrate, it is quite common to use proprietary Forward Error Correction (FEC) techniques within the laDI to further optimize the optical performance. Refer to Section 18.2.2 for a more detailed description on transverse versus longitudinal compatibility. The ITU established two new optical interface recommendations, namely, G.959.1 [8] and G.693 [9], originally intended to address the new OTN applications having rates as specified in Recommendation G.709. Before being completed, these two recommendations were transformed into a more generic form, permitting usage across a variety of applications, including the originally intended OTN applications in G.709, along with SDH/SONET and even Gigabit Ethernet. The introduction of optical tributary signal classes, which addressed a range of data rates rather than a specific data rate, made this possible. As a consequence of this choice for generic specifications over a range of data rates, the previous optical interface Recommendation G.691 [10], which previously addressed only SDH/SONET applications, was updated with appropriate references to either G.693 or G.959.1. Recommendation G.959.1 was intended to be a general specification for single-span, unidirectional, point-to-point optical links, which addressed
ITU Optical Interface Standards
699
single and multichannel line systems. This recommendation was generated in conformation with the approach in the earlier G.957 and G.691 recommendations, but was generalized to apply over ranges of data rates rather than specific data rates. G.693, however, introduced new optical links beyond what was previously addressed in Recommendation G.691. Recommendation G.693 targeted Very Short Reach (VSR) applications, with link distances up to 2 km and potentially higher-than-"normal" losses, at nominal lOGbit/s and 40 Gbit/s aggregate bit rates. G.693 specifically included the possibility of inserting optical cross-connects in the optical link (which at the time had very high insertion losses). As a result, a wide range of link-loss categories is included, ranging from 4 dB to 16 dB. Even higher link losses are foreseen as next-generation network elements are added to the optical link. 18.2.1.5
CWDM
Because of a market need for relatively low-cost point-to-point multichannel systems, the ITU decided to work on a new set of recommendations supporting Coarse WDM (CWDM) applications with channel spacing of 20 nm. Note that a wavelength specification is used instead of a frequency specification. The requirements for coarsely spaced channels permitted the use of low-cost uncooled lasers and low-cost WDM filter technologies. In Recommendation G.694.2 [1], the 20 nm grid has been specified with 1551 nm as one of the grid wavelengths. Recommendation G.695 [12] provides optical interface parameter values for CWDM applications with up to 16 channels and up to 2.5 Gbit/s. Recommendation G.695 contains two general specification methods: the black-box method and the black-link method. In the case of the black-box method, sets of parameter values for the aggregate multichannel reference points (after the optical multiplexer and prior to the optical demultiplexer) are given, implying that the parameters for the individual channels, which lie within the black box, are not specified. Alternatively, in the black-link approach, optical interface parameter values are only specified at the individual tributary single-channel interfaces. In this approach, interworking is enabled only at the single-channel points and not at the aggregate multichannel points. In this case, the combination of optical multiplexer and demultiplexer is treated as a single set of devices. This means that in the specified per-channel losses, the partitioning between on one hand the actual fiber losses and on the other hand the losses of the optical multiplexer and demultiplexer is not specified. The same is valid for other per-channel link parameters like chromatic dispersion and polarization
700
Chapter 18
mode dispersion. In particular, this black-link approach is relevant to the new hot-pluggable SFP packaging technologies described in Section 18.3.2.2. For further details, see Recommendation G.695. In the most recent version of G.695 OADM network elements have been included in the treated CWDM architectures. 18.2.1.6
All Optical Networks (AON)
Recently the ITU began studying the physical characteristics of Optical Network Elements (ONE) and optical interfaces for All Optical Networks (AON). One of the major challenges the ITU faces is whether it is possible to generate transversely compatible interface specifications for these networks or whether a new method of specification is required. One of the key considerations is to not drive the optical performance specifications to their physical or state-of-the-art limits, and as such be able to specify mutually compatible network elements and to more easily build and configure interoperable AONs. A similar challenge was addressed when ITU evolved from specifying proprietary PDH equipment to specifying interoperable SDH/SONET equipment.
18.2.2 Transverse versus longitudinal compatibility 18.2.2.1
Introduction
In the previous section, a brief explanation for the differences between longitudinally and transversely compatible specifications was given. In this section, a more detailed explanation is given. An excellent overview of the two principles is provided in ITU G.Sup39 [13], "Optical System Design and Engineering Considerations", which is a very important reference document for many of the design considerations used in defining the various ITU optical interface recommendations. 18.2.2.2
Physical layer longitudinal compatibility
The first definition for longitudinally compatible optical interfaces was developed for PDH applications and can be found in Recommendation G.955. In this case, only the optical path (optical fiber or outside plant) characteristics are specified. Other optical interface parameters, like transmitter output power, source spectral characteristics, receiver sensitivity and overload, are not specified. Furthermore, the actual line rate and data transmission format are also not specified. This principle simply implies that
ITU Optical Interface Standards
701
operators can use "standardized" outside-plant characteristics for tendering purposes, permitting almost total implementation freedom to equipment manufacturers. For obvious reasons, the transmitting and receiving equipment must be from the same manufacturer. Initially, only the outside-plant maximum attenuation and chromatic dispersion were specified. Later, when bit rates of 2.5 Gbit/s and higher were introduced, the maximum Differential Group Delay (DGD) and optical line reflection characteristics were added. It should be noted that the maximum path characteristics are based upon End of Life (EOL) specifications, indicating that they should include appropriate margins for temperature and aging variations and for repair splicing. For further details on longitudinal compatibility, see G.sup39. 18.2.2.3
Physical layer transverse compatibility
To achieve complete interworking between equipment from different manufacturers on a single optical section, additional requirements beyond just the optical physical layer must be specified. In other words, the pieces of equipment at both sides of the optical link should be able to "talk to" and "understand" each other. Essential to a transversely compatible specification is the definition of appropriate reference points in the fiber path at which optical parameters can be both specified and measured. Two reference points were chosen to reflect where the transmit signal enters the outside plant (S-type reference point) and where the signal leaves the outside plant and is received by an optical receiver (R-type reference point). At these reference points, a full set of optical parameters and associated (verifiable) values is necessary to enable interoperability at the optical level. The first definition of this partitioning and associated parameter definition and specification is found in Recommendation G.957. Examples of parameters at Point S are transmitter output power (min and max) and the spectral characteristics of the transmitter, and at Point R the minimum receiver sensitivity, receiver overload, and maximum optical path penalty. The optical path penalty describes the apparent reduction of receiver sensitivity due to distortion of the signal waveform (generated by the transmitter) during its transmission over the optical path. A complete overview of the relevant parameters can be found in the various ITU optical interface recommendations. Some further details on optical power budget design considerations and limitations are given in Section 18.2.6. G.Sup39 gives a complete overview of levels of transverse compatibility, with the single-span configuration being the most straightforward.
Chapter 18
702
See Figure 18-1 for a generic single-span transversely compatible configuration.
Supplier A
Supplier B
m.
Transmitter
R Receiver
Outside fiber plant Figure 18-1. Generic single-span transversely compatible configuration
When adding line optical amplifiers into the middle of an optical link configuration, a transversely compatible specification reaches an increased level of complexity, because some parameters apply to a single section (e.g., attenuation), whereas others apply to the complete end-to-end section (e.g., chromatic dispersion and differential group delay). In such a multispan configuration, additional reference points are required to differentiate between end-to-end and per-section parameter specifications. One example configuration is shown in Figure 18-2, where a single-line Optical Amplifier (OA) has been inserted. In this case, slightly different reference points are used—MPI-S and MPI-R—^to indicate Main Path Interfaces, relevant for end-to-end performance. Also OA reference points R' and S' are used to indicate the parameters at the input and output of the Optical Amplifier. In general, different reference point nomenclatures are used across the various optical interface Recommendations.
Supplier A
m.
MPI-S Transmitter
Supplier B R'h. S'
Supplier C MPI-R Receiver
Figure 18-2. Example of multispan configuration
It should be obvious that when adding Optical Network Elements (ONEs) like optical add-drop multiplexers or optical cross-connects, the complexity
ITU Optical Interface Standards
703
of defining transversely compatible specification reaches an even higher level.
18.2.3 Overview of optical fiber types and associated recommendations In parallel with the development of a range of optical interface recommendations, the ITU has also developed a variety of recommendations for optical fiber cables. The evolution of the various fiber types had a significant impact on the development of optical interface recommendations, described later in Section 18.2.4. In the early 1980s, most optical fiber systems were deployed on multimode fiber. Many fiber types were developed, all with different characteristics and dimensions. In Europe the so-called 50/125 |im gradedindex type (with a 50 )im fiber core diameter and a 125 jLim cladding diameter) was mostly used, whereas in the USA 62.5/125 jim fibers were mostly deployed. ITU has only specified the properties of 50/125 jam graded-index multimode fiber types, found in Recommendation G.651 [14]. In general, multimode fibers are used in the 850 nm and 1310 nm wavelength windows. Because of a variety of technical issues with multimode fibers, e.g., limitations on transmission distance in relation to system speed, single-mode fibers became available and were generally deployed. Single-mode fiber was and is still used today for laser-based telecom applications. In the late 1990s, there was an interest in transmitting 10 Gbit/s Ethernet-based data rates over multimode fibers. A significant amount of work was done to improve the properties of the multimode fiber, resulting in the ability to transmit multimoded lasers over a distance of 300 m at 10 Gbit/s. Because applications using multimode fibers are not specified in a majority of the ITU optical interface recommendations, they are not further discussed in this chapter. The first single-mode fiber type is commonly referred to as Standard Single-Mode Fiber (SMF or SSMF). The ITU has developed Recommendation G.652 [15] in order to specify the properties of cables that utilize this fiber type. Initially, this fiber was only used in the 1310 nm wavelength window, where the chromatic dispersion is near-zero, theoretically providing unlimited transmission bandwidth. Around 1990, the SSMF fiber was additionally used in the 1550 nm window, due to the combination of a market drive for longer distances (at 1550 nm, the fiber loss is about half the value in the 1310 nm window) and the availability of 1550 nm laser sources. Because of the subsequent need to transmit at higher data rates (10 Gbit/s) and the need to utilize more of the wavelength range
704
Chapter 18
between 1360 nm and 1530 nm, additional specification details were necessary for Recommendation G.652. For this purpose, three subcategories have been defined within G.652: • Subcategory A, for the base G.652; • Subcategory B, having additional requirements on Polarization Mode Dispersion (PMD) for 10 Gbit/s applications; and • Subcategory C, having additional requirements for operation in the wavelength range between 1360 nm and 1530 nm, relevant to wideband CWDM applications. PMD occurs when the cross-section of the fiber core is not perfectly circular and tends to be more elliptical in shape. This results in the fiber effectively transmitting in a dual-mode instead of a single-mode condition. Because both modes have different group delays, additional pulse broadening beyond the traditional broadening, caused by chromatic dispersion, will occur. PMD is typically significant for transmission speeds of 10 Gbit/s or higher. In certain cases, however, it is known to affect the performance of 2.5 Gbit/s systems. Further information on PMD can be found in G.Sup39 or Recommendation G.650 [16]. Despite the huge advantage of a low fiber loss in the 1550 nm region, G.652 fiber exhibits a fairly high chromatic dispersion of around 17ps/nm*km at 1550 nm, severely limiting the transmission distance of systems operating at 2.5 Gbit/s or higher. Therefore a new fiber, called Dispersion Shifted Fiber (DSF) was developed, which is specified by ITU Recommendation G.653 [17]. This fiber was specifically designed to give low losses around 1550 nm and to provide near-zero chromatic dispersion in the 1550 nm wavelength window. At the same time, the ITU developed Recommendation G.654 [18] to address fiber types for submarine applications operating in the 1550 nm window. Because this fiber type is not used in terrestrial applications, further details are not provided here. An overview of ITU's single-mode fiber recommendations is provided in Table 18-1. When DWDM systems with closely spaced optical signals were being introduced, it appeared that the near-zero chromatic dispersion in G.653 fibers was the cause for the occurrence of the nonlinear Four-Wave-Mixing (FWM) effect. FWM, also called four-photon mixing, occurs when additional optical signals are generated by the interaction of two or three adjacent channel optical signals operating at closely spaced wavelengths at equivalent speeds. These additional signals, which transmit at wavelengths other than their parent wavelengths, are called mixing products.
ITU Optical Interface Standards
705
Table 18-1. Overview of ITU single-mode fiber recommendations ITU Recommendation G.652 G.653 G.654 G.655 G.656
Recommendation title Characteristics of a (standard) single-mode optical fibre cable Characteristics of a dispersion-shifted single-mode optical fibre cable Characteristics of a cut-off shifted single-mode optical fibre and cable Characteristics of a nonzero dispersion-shifted single-mode optical fibre cable Characteristics of a fibre and cable with nonzero dispersion for wideband optical transport
Because of FWM, a new fiber generation was developed that had nonzero dispersion and would generally prevent FWM fi'om occurring in the optical line. These new fibers are specified in Recommendation G.655 [19]. A complete variety of these fibers has since become available, all with very different characteristics for actual zero-dispersion wavelength and chromatic dispersion slope. No further details are given here, because that would entail a detailed theoretical treatment of DWDM systems and is beyond the scope of this chapter. More details on nonlinear effects can be found in Recommendation G.663 [20]. The first DWDM systems were operated with wavelengths around 1550 nm, coinciding with the transmission bandwidth of the first generation of optical fiber amplifiers. Subsequent deployments of DWDM equipment utilized wavelengths above and below the 1550 nm region. To simplify discussion of these wavelengths, the ITU defined a range of wavelength bands in G.Sup39, reproduced in Table 18-2. Most recently, the usage of DWDM and CWDM systems have extended a large range of bands, including S-, C-, and L-bands. ITU has created a new fiber Recommendation G.656 [21], which addresses the optimal performance of the fiber in wide-band applications. Full details of key parameters and associated values can be found in the relevant ITU Fiber recommendations. Table 18-2. Overview of wavelength bands Band O-band E-band S-band C-band L-band U-band
Description Original Extended Short wavelength Conventional Long wavelength Ultralong wavelength
Range (nm) 1260 to 1360 1360 to 1460 1460 to 1530 1530 to 1565 1565 to 1625 1625 to 1675
706
Chapter 18
18.2.4 Overview of optical interface recommendations It has been clarified in the previous sections that over time the ITU has developed a whole range of recommendations related to optical interface specifications. In retrospect, it might not seem logical how the ITU recommendations are organized and where to look for a certain specification. In this chapter, an attempt is made to guide the user/designer of optical interface technologies. Table 18-3 provides an overview of ITU's various optical interface recommendations existing to date. As stated previously, the ITU decided to use its latest Recommendations G.693 and G.959.1, to serve as generic documents for most optical interface specifications. The basis for this generic specification was the definition of signal classes in Recommendation G.959.1, covering a range of data rates for which sets of optical parameter values are specified. Presently, the following signal classes are addressed: NRZ 1.25G, NRZ 2.5G, NRZ lOG, NRZ 40G, and RZ 40G ( see the Table 18-4 for details). The parameter values for the older STM-1 and STM-4 interfaces remain within G.957 along with most of the STM-16 interfaces. For the NRZ lOG data rate class, ITU put almost all the sets of parameter values into either G.693 or G.959.1, except some of the applications that use optical amplifiers for 80 km or 120 km distances, which remain in G.691. One of the blocking issues that prevented the generic recommendations (G.959.1 and G.693) from covering the STM-1, STM-4, and STM-16 data rates was the fact that the reference BER applicable to G.957 differed from that of G.959.1 or G.693. At the time that G.957 was originally drafted, the parameter values were specified relative to an optical section design objective of a Bit Error Ratio (BER) not worse than 1 x 10"*^, whereas for all of the more recent Recommendations (G.691, G.692, G.693, and G.959.1), the BER design objective is 1 x 10"^^. The more stringent BER objective was derived from error performance requirements specified in Recommendation G.826 [22]. At the time of drafting and agreement of the first version of G.957, G.826 was not in existence yet, and as such, a BER design objective of 10"^^ was considered appropriate. Because of the wide deployment of SDH interfaces based upon this early version of G.957, the ITU decided to maintain the parameter value sets within G.957. Had ITU decided to adopt the more stringent BER requirement for STM-1 to STM-16 interfaces, substantial changes to some of the parameter values like maximum optical path attenuation and/or minimum receiver sensitivity would have been necessary. This could have resulted in inoperability issues between new and installed systems. Further discussion is provided in Section 18.2.6.
ITU Optical Interface Standards
107
Table 18-3. Overview of relevant ITU optical interface recommendations 1 Recommendation Application area Description G.691 SDH (SONET) Transversely compatible specification for single1 channel SDH STM-64 in general and STM-4 and STM-16 interfaces with optical amplifiers for distances longer than 80 km; design objective BER < 10'^^ G.692 SDH-DWDM "Limited" transverse compatible specification for multichannel SDH systems; actual parameter values "for further study"; design objective BER < 10"^^ G.693 Transversely compatible specification for singleGeneric VSR channel signal classes NRZ lOG and NRZ 40G for link distances up to 2 km with potentially high losses up to 16 dB; design objective BER < 10"'^ G.694.1 Grid for DWDM DWDM grid specification with spacing ranging from 12.5 GHz to 100 GHz G.694.2 Grid for CWDM CWDM grid specification with 20 nm grid spacing G.695 CWDM Transversely compatible specification for up to 16 channels, up to 2.5 Gbit/s per channel; design objective BER < 10'^^ G.696.1 OTN-DWDM Longitudinally compatible specification for multispan, multichannel OTN systems; design objective BER < 10"*^ G.698.1 OTN-DWDM Transversely compatible specification for 100 GHz spaced channels, up to 10 Gbit/s per channel; design objective BER < 10"'^ G.955 PDH Longitudinal compatible specification singlechannel, single-span up to 4* 140 Mbit/s; design objective BER < 10"'^ G.957 SDH (SONET) Transversely compatible specification for STM-1, STM-4, and STM-16 interfaces for link distances up to 80 km; design objective BER < 10"'^ G.959.1 1 Transversely compatible specifications for singleGeneric IrDI channel signal classes, NRZ 1.25G, NRZ 2.5G, NRZ lOG, NRZ 40G, and RZ 40G, and 16-channel signal classes NRZ 2.5G and NRZ 1OG; design objective BER < 10'^ | Table 18-4. Overview of signal classes Signal class NRZ1.25G NRZ 2.5 G NRZIOG NRZ40G RZ40G
Range of nominal bitrate [Gbit/s] 0.622-1.25 0.622 -2.67 2.4-10.71 9.9-43.02 9.9 - 43.02
Chapter 18
708
Table 18-5. Overview of optical interfaces and the related optical interface recommendations
1 Bit rate STM-1 (OC-3) STM-4(OC-12) STM-4 (OC-12) + optical amplifiers
STM-16(OC-48) STM-16 (OC-48) + optical amplifiers Signal Class NRZ 2.5G STM-64(OC-192) +optical amplifiers Signal Class NRZ lOG (incl. STM-64 /OC-192) Signal Class NRZ lOG (incl. STM-64 /OC-192) Signal Class NRZ 40G (incl. STM256 / OC-768) Signal Class NRZ 40G (incl. STM256 / OC-768) Signal Class RZ 40G (incl. STM-256 / OC-768) 1 NRZ 0TU3 with FEC
Distance
r
Administrative team
Editors
Figure 20-3. Organizational chart
The following is an example of how a forum might structure its leadership, but this example is not exclusive to any one organization. In a typical voting process, directors are nominated by members and then voted upon by the member companies, with each company receiving one vote. Elections are held once a year, and the directors hold their positions for a 12month term. The exception is when the elected official at some time during his or her term is no longer with his or her sponsoring company. In some cases in the industry, companies have shut their doors due to a decline in the economy or other reasons, whereby they are no longer a member of the forum. When this happens, an elected forum director/official who had been working for one of these defunct companies is removed from the post, and
778
Chapter 20
an interim director/official is nominated to fill that seat until proper elections can take place. Finally, each director can be renominated at the end of the term to run again for the position. This hierarchy sets the framework for the process of standards work and implementation. Technical standards and agreements are suggested and brought forth for nomination. Upon acceptance and submission of the specification, the organization as a whole votes on the acceptance of the specs, makes suggestions for further draft development or votes to take the document to ballot phases when near final agreement. As letter ballots are approved, the process is typically interactive, seeking comments on draft proposals from members within the committees. The next step after gathering comments is to address and resolve each and every comment. This process may result in additional comments, and so on, until the implementation agreement addresses all the concerns. This description may help those outside the consortium understand why the standards process is a time-intensive procedure. Digging deeper into the process of managing the resolution for moving motions forward is the editor of the initiative. The editor's role in creating the defined implementation agreement is to act as impartially as possible to resolve the discussion slated around the review process. In this entire process, the editor on the basis of the charter of the working group and the scope of the implementation agreement, needs to keep the group focused in getting consensus on the agreement to help move it forward. In cases where an item is deadlocked within the review process, the committee and those involved in the review must work to find a compromise. At times like these that the true neutral and cooperative nature of a consortium comes to light as the most important trait for achieving these goals. Only through collective agreement and cooperation can a deadlock be resolved. One oversight of many hopefuls within the industry, including media and analysts, is that technology development can come to common ground almost overnight. The fact is that, as mentioned, the men and women behind the specification development are volunteers, and as with most consortia, the technical groups often meet on a quarterly cycle, with details going into the specifications during these cycles. At quarterly meetings, the technical group—the group responsible for specification development, which is made up of subgroups focused on exact capabilities within the technology, i.e., service level agreements (SLAs), and performance monitoring,— discuss, debate and determine the movement of specifications over 3—4-day meeting sessions. It's within the scope of these quarterly meetings that the review process of agreements and standards movement is voted upon. Through these time frames, members collaborate, disagree, and come to focus on the common goal of furthering the technology at hand. Moreover,
Standards Development Process
779
countless hours are spent between meetings by each working group member in conference calls and through email exploders in discussing new ideas, debating proposals and subsequently coming to some resolution on issues. The full process of creating these standards can in certain scenarios take 12-18 months, or even longer. The subelements within these standards can be further developed as an ongoing process. When technology has matured to where the industry accepts the standards and incorporates them into products, networks, and documentation, consortia realize that their goal has been achieved and disassemble. But history shows that the evolution of technology perpetuates further developments based on new, more advanced technology that seems to bring the same players back to the group in order to advance the industry and technology.
20.3.3 The History Behind Standards Groups: Why join? The telecommunications industry has evolved to the point where global markets exist only through support of global standards. Innovations in technology have drawn companies to a common interest, and it is standards that provide the basis for cooperation among industry vendors, i.e., standards create the means to ensure interoperability among products. The technology boom of the late 1980s and early 1990s led industry vendors to form consortia as an environment for rapid standards creation. The idea was to have an alternative to the existing standards development organizations, whose processes were thought to be too slow and cumbersome to facilitate timely delivery of technology standards (or products to market). In part for this reason, industry forum organizations were created to further the cooperation of technology use across the communications industry. Early standards consortia were very simple, functioning with almost no formal processes in place. Today, standards consortia are evolving into sophisticated, nonprofit corporations with well-defined legal structures and formal policies and procedures necessary to ensure responsible operations along with success. It can be said that the underlying reason telecommunications product vendors join a forum is to ensure that their company goals are part of the standards development process. Another main reason for vendor companies to become involved in standards development organizations is to ensure that the products they are creating interoperate with others throughout the industry. Customers and carriers in this day and age require that products interoperate for the sake of advancing technology. All other equipment manufacturers cooperate in this effort. The employees of member companies that become representatives to the forum do their best to see that
780
Chapter 20
the direction of standards development closely follows the capabilities and specifications built into their company's existing products. This isn't the case for each and every company representative. Many do, however, bring their technological expertise and contribute in a neutral manner. In either case, the forum can bring a member company further validation and credibility for their efforts to advance the technology of interest. In the evolving telecommunications industry, many industry forums have seen the opportunity to work together and complement each other's groups. Typically, the representative members of a consortium benefit from the many partnerships and networking opportunities offered when multiple companies come together. Uncovered possibilities, strategic alliances, and simple knowledge sharing almost always are a plus to membership when such a group a company joins.
20.3.4 Membership Membership is a key element in the accomplishments of a consortium. As a consortium grows and becomes well established, companies can be lured to join in order to reap the benefits of the consortium's influence. There are also companies that may reconsider membership renewal after participating for a term or two and base this reconsideration on the direction of the group: Is the group moving forward? What are the cost of dues- is it affordable? How much time is the employee putting into this that might otherwise be put into his/her day job? What effects of success (or delays) is the consortium creating for the industry? In short, members who choose to be involved by putting forth time and effort can become influencers and only gain from these efforts. These are the he realities of a consortium. As with any organization where there is a constituency and more than two heads running the show, things can go so right and so wrong. The reality of a consortium is that the group of volunteers who have come together for a common goal can come, sometimes, with their own agendas that inadvertently may rise above the goal of the group. Again, nothing in life is perfect, but when companies join together in a seemingly neutral fashion, there are often leaders who emerge — be it due to the strength of their company or their personal technological knowledge — and divisions that evolve, exposing one-sided agendas. It's the smart member who realizes this and knows when to speak up and knows when to take a detour in a matter. A tip to the naive is to ask oneself. Will this issue matter in six months? Let that be a gauge of its importance. Another reality that member companies should realize in working with a consortium is that a well-operated group will have a strong marketing outreach plan. And any member company wanting to validate its
Standards Development Process
781
involvement, even if that involvement is largely from a technology perspective, should try to leverage that outreach. The branding opportunities that go along with involvement in an industry standards group can validate a member company's place in the market. With that in mind, the efforts of a consortium to evangelize its story to the industry span an array of programs from the technical and the marketing side. Regarding the latter, press and analyst outreach, speaking engagements at industry events, white papers, and more make up a well-rounded marketing plan. These plans are generally drawn up by an internal marketing committee, which is often supported by an outside agency. In choosing the events in which the organization paticipates, audience is a key consideration, as is location and size of the event. The next consideration is cost. Ideally, exposure without cost is the best form of evangelism. Having said that, there are a variety of avenues to consider — industry conferences, trade shows (often times cohosted with conferences), webinars (often hosted in conjunction with a leading media outlet), and educational seminars or tutorials. Months of planning go into the organization of a full-scale event — i.e., a full-day tutorial or interoperability product demo. The planning typically begins with interest from the marketing team in being involved with an industry event or tied to a campaign initiative of the organization. The next step is to collaborate with the technical team. It's their support, from a demonstration and content perspective, that makes the event a success. All in all, planning for a large-scale event truly brings out the team effort of a consortium. Committee members should be prepared to compromise and work above their typical role of involvement to bring about success for such events. The payoff is well recognized.
20.3.5 Reality of human nature Marketing and engineering are two groups within any organization where it is hard to assure that there will be any camaraderie. This is true in industry consortia, as well. History has shown that the two groups can work civilly together but also face challenges along the way. The aggressive nature of a marketing group to want to communicate success as soon as possible (and even sometimes sooner), and the automatically conservative nature of engineers to want to assure full functionality, even weeks after testing, can cause friction between decision makers within a consortium. Reaching a compromise proves to be a key trait in situations like this, and usually it is the marketing group that concedes a bit more than the engineering team, and usually with good reason.
782
Chapter 20
However, it's typical in these situations that individual agendas surface. Power plays associated with passing a particular standards agreement, or having such specifications passed in a timely manner, can hurt the development of the standard, and resistance can come from adversaries who hold higher positions within the consortium. It's not unthinkable to consider that human nature might cause the actions of one representative to delay a suggested specification from a competitor. In this type of scenario, it's possible that the members will split between those who agree with the legitimacy of the delay and those who think the person suggesting the delay is creating a roadblock without much recourse. Human nature is a piece of the organizational structure, but hope exists for finding positive experiences that can defeat these issues. And that one word of hope is teamwork.
20-3.6 Teamwork Without a doubt, teamwork is the most positive experience that comes from the relationships created within an industry forum. The relationships that are built between colleagues and the achievements that a group can make to advance communication are significant. It's teamwork that is the greatest conduit to advancing the telecommunications industry. When colleagues from competitor companies can put aside their rivalries to put forward a specification agreement together, or when a colleague suffers the loss of a job and those within the industry forum do all they can to get the colleague interviews or opportunities to stay involved, lies the signs of therein positive human nature that can come from an industry forum. All this teamwork is further facilitated by the people who are most involved with the support and success of the consortium - the administrative team. In most cases today, industry forums are supported by an outsourced administration group. The delicate nature of operating a consortium as a nonprofit entity and keeping committees, leaders, and officers focused and on course for success is often driven by the guidance of the administrative team. Behind the scenes, the administrative team brings together all the details for quarterly meetings, for the conference calls that take place in between, and for the logistics of it all, while assuring the committee members of their neutral standing and promoting a clear understanding of the goals ahead. There are some things that rise above the control of the administrative team, such as four-hour implementation agreement meetings that run well into late hours of the night. But the administrative team is on hand to document the direction and note the minutes of meetings so that members have disclosed information on the proceedings of the meetings. The members look to the administrative team as a neutral body, which it is. And often, the
Standards Development Process
783
administrative team is praised for all the efforts for which, it seems at times, the organization would not function without.
20.4.
CONCLUSION
Standards Development Organizations and Industry Forums are no more immune than a typical vendor company is to the typical challenges of personality, views, achievements, and goals. Network Operators, System Vendors, Device Manufacturers, and Governments may all bring their own unique perspectives to the table. Member organizations may be marketplace competitors or maybe in customer/supplier relationships with other Member organizations. Member organizations are motivated to come together to reach common objectives in order to create and develop new markets whose evolution depends on the interoperability of the systems produced by different vendors and the interconnection of the networks of different operators. It is the drive of this common goal to move technology forward and create demand for the products or services in the market. High-quality standards reduce the cost of deploying new technologies by preventing interoperability problems that might otherwise occur. Managing the diversity of the representatives in this type of organization is a dynamic that is ever constant. The officers, the administrative team and other key members with leadership positions or responsibilities must exercise neutrality and promote consensus. Any perception of bias among the leadership or unfairness in the process can damage the confidence and support of the members that is so important for a successful standard.
This page intentionally blank
INDEX + 1/0/-1 byte justification, 202 1:1 cold standby protection, 511 1:1 hot standby protection, 511 (1:1)° protection, 300, 302f 1+1 Optical Subnetwork Connection (OSNC) protection, 313, 314f 1+1 protection, 298, 298f, 499 inMEF, 511 1:1 protection, 500 l:n protection, 298-299, 299f, 500 1x9,716 1 x 9 transceivers, 716 +2/+1/0/-1 justification, 202 2.5 Gbit/s interface, 714-715 2.5 Gbit/s interface standards, 760-761 receiver specifications in, 760, 762t summary of, 760, 761t transmitter specifications in, 760, 761t 2.5 Gbit/s technology and systems, 668-672 SPI-3 signal descriptions in, 669-672 receive direction, clock and data signals, 671 receive direction, discrete control/status signals, 671-672 transmit direction, clock and data signals, 669 transmit direction, discrete control/status signals, 669-671 typical usage of, 669, 669f 3Rpoints, 65, 65f 4 X ODUl to ODU2 justification structure, 109, 109f, 109t 4 X ODUl to ODU2 multiplexing, 107-112. See also ODUK multiplexing 4 X ODUl to ODU2 justification structure in, 109, 109f, 109t frequency justification in, 111-112, 112t OPU 2 multiplex structure identifier (MSI)in, 110-111, llOf, 11 If OPU2 payload structure identifier (PSI) in, 110 structure in, 107, 108f
8B/10B client processing, in GFP-T, 169 10 Gbit/s technology and systems, 672-677, 721-728 discrete solutions in, 721-722 integrated solutions in, 722-728 200-pin transponder in, 724-725 300-pin transponder in, 722-724, 723f X2, XGP, and XPAK in, 726, 727f XENPAK in, 725-726, 725f XFP in, 727-728, 728f Media-Independent Interface (XGMII) in, 759 SPI-4 Phase 1 (OC-192 System Packet Interface) in, 674-677, 675f System Framer Interface-4 phase 1 (SFI-4 Phase 1) in, 672-674, 673f 40 Gbit/s technology and systems, 681-688, 728 background on, 681 SERDES Framer hiterface-5 (SFI-5) in, 682-685 signals, receive direction, 682-685 signals, transmit direction, 682-685 SPI-5 (OC-768 System Packet hiterface) in, 685-687, 685f TFI-5 (TDM Fabric to Framer Interface) in, 687-688, 688f 64B/65B code blocks, adaptation into GFP superb locks of, 169f, 170 140 Mbit/s to 2.5 Gbit/s technology, 713-721 2.5 Gbit/s, 714-715 140 Mbit/s to 622 Mbit/s, 713-714 integrated solutions for, 716-721 1 x 9 device (transceivers) in, 716 2.5 Gbit/s transponders in, 720-721 GigaBit Interface Converter (GBIC) in, 719-720, 721f initial versions of, 716 Small Form-Factor Pluggable (SFP) devices in, 718-719, 719f
786 Small Form Factor (SFF) devices in, 717-718, 717f 140 Mbit/s to 622 Mbit/s optical interfaces, 713-714 200-pin transponder, 724-725 300-pin transponder, 722-724, 723f A Access group, 31, 378 in MEN, 335 Access link, in MEN, 340, 341f Access point (AP), 31 in MEN, 336 Adaptation fimction, 29-30, 30f, 32, 32f in Ethernet connectivity services, 396 expansion of, 35, 35f in MEN, 336 Adapted information (AI), 51, 52f Add Drop Multiplexing (ADM), 3, 40, 41f transport function implemented on, 4If, 4 3 ^ 4 , 44f, 45f Additional Review, 775 Address and addressing, 589 in ASTN, 568-569 client, in GMPLS RSVP-TE (G.7713.2) signaling, 648 Address Prefix FEC, 451 ADM. See Add Drop Multiplexing (ADM) Administrative Unit (AU), 121 Administrative Unit Group (AUG), in SDH frame, 121, 121f Admission control, in ASTN, 569-570 Advanced Telecom Computing Architecture (ATCA) backplane, 760 Agere Systems, TSWC01622 and, 272-273, 274f Aggregated line and node protection (ALNP) in MEF protection, 508-509, 508f in MEN, 522 Aggregation DSLAM uplink in, 394, 394f in Ethernet connectivity services, 392, 394 flow definition and, 378 multiple customer flow, 393, 393f single-customer flow, 392, 393f Alarm, 55 Alarm, in MEN CES, 487-489 for buffer underflow and overflow, 488-489 for structured service, 488 for unstructured service, 488 Alarm/status monitoring, 54 Alignment jitter, 195, 196-198, 198f
Index All Optical Networks (AON), standards for, 700 All-to-one bundling map example of use of, 350, 351f feature constraints in, 355 in layer 2 control protocols, 350-351 private line and, 351 Alternative Approval Process (AAP), 775 Anchored components, 585 Anchored objects, 585 Anomaly, 55 check to identify defects in, 55-56 AON (All Optical Networks), standards for, 700 Application code terminology, related to distance, 709, 710t Application protection constraint policy (APCP), 516 Application services layer (APP layer), 329 in MEN, 329 Application Specific Integrated Circuits (ASICs), 3 APP link, in MEN, 340, 341f Approved, 774 Architecture of automated discovery (G.7714), 606-607, 606f of Automatically Switched Transport Network (ASTN), 551-655 {See also Automatically Switched Transport Network (ASTN) architecture) component, in G.8080, 575 control plane (G.8080), 571-595 {See also Control plane architecture (G.8080)) for EPL services, layered, 397, 399f of Ethernet services, 7-10 of high-speed serial interconnects, 737-742 Printed Circuit Board (PCB) interconnects in, 738-742 {See also Printed Circuit Board (PCB) interconnects) topologies in, Til-Ti^ Network Element (NE), 268-279, 664-668 {See also Network Element (NE) architecture) hybrid (TDM + cell/packet based), 667-668 of Optical Transport Network (OTN), 23 of protection switching, 297-303 {See also Protection switching, architectures of)
Index restoration, in G.8080, 593-595, 594f ring protection, 302-303, 303f Signaling Communications Network (SCN) (G.7712), 595-603 {See also Signaling Communications Network (SCN) architecture (G.7712)) synchronization, for SONET/SDH, 257-293 {See also Synchronization architectures, for SONET/SDH) of transport networks, 17-61 introduction to, 17-18 transport fianctional modeling in, 18-61 {See also Functional modeling, transport) ASICs. See Application Specific Integrated Circuits (ASICs) ASON (Automatic Switched Optical Networks), 10-11 routing in {See Routing, in ASON (G.7715andG.7715.1)) Assignment, manual synchronization of status messages (SSM) in, 245 ASTN. See Automatically Switched Transport Network (ASTN) Asynchronous interworking fianction (IWF) asynchronous tributaries and, 477^78 in MEN CES, 477-478 synchronous tributaries and, 478 in MEN CES, 478 Asynchronous mapping, 200-203 Asynchronous network operation, 238-239, 239t Asynchronous-transparent mapped mode, in GFP, 165f, 168-169 ATCA backplane, 760 ATM Adaptation Layer, Type 2 (AAL-2), 156-157 ATM protocol data units, 156 Atomic fianction information points, 51, 52f Atomic fianction inputs and outputs, 51, 52f Attachment circuit (AC), in L2VPNs, 428 Autodiscovery. See Discovery, automated (G.7714) Automated discovery. See Discovery, automated (G.7714) Automatically Switched Transport Network (ASTN) architecture, 551-655 background on, 551-553, 553f control plane architecture (G.8080) in, 571-595 {See also Control plane architecture (G.8080)) control plane management in, 633-635, 636f
1^1 control plane technology in, 552-553, 553f discovery (G.7714) in, 604-611 {See also Discovery, automated (G.7714)) methods and protocols for, 640-643 {See also Discovery, automated (G.7714)) future of, 653-655 network requirements (G.807) in, 553-571 admission control in, 569-570 architectural context in, 554-555 architecture principles in, 564-567, 565f background on, 553-554 business and operational aspects in, 559-562 call and connection control in, 555-559, 556f, 558f connection management in, 567-568 naming and addressing in, 568-569 reference points and domains in, 562-564 routing and signaling in, 568 for signaling communications network, 570 support for transport network survivability in, 571 supporting fianctions and requirements in, 567-570 transport resource management in, 569 protocol analysis in, 637-640 approach to, 637-639, 638t requirements implications on protocol solutions in, 639-640 routing in (G.7715 and G.7715.1), 611-626 {See also Routing, in ASON (G.7715 and G.7715.1)) methods and protocols in, 651-652 service activation process elements in, 603-604 in signaling communications network (G.7712), 595-603 {See also Signaling Communications Network (SCN) architecture (G.7712)) mechanisms of, 652-653, 653f signaling (G.7713) in, 626-633 {See also Signaling (G.7713), in ASON) methods and protocols for, 643-651 {See also Signaling (G.7713), in ASON, methods and protocols for) Automatic Protection Switching (APS) channel, 303 Automatic Protection Switching (APS) protocol, 310-312
788 APS signal in, 310-311 external commands in, 311 priority in, 312 process states in, 311 in protection switching, 304-305 Automatic Switched Optical Networks (ASON), 10-11 routing in {See Routing, in ASON (G.7715andG.7715.1)) Availability. See Storage Area Networks (SANs), SONET for; Storage networking Avalanche Photo-Diode (APD), 714 B Backplane Ethernet, 760, 762 Backplane interconnect, 736 Backplane topologies, 737-738 Backup. See Storage Area Networks (SANs); Storage networking Backward compatibility requirements, in MEN protection, 519 Backward Defect hidication (BDI), 92-93 in OTUK, 102-103 Backward error indication and backward incoming alignment error (BEI/BIAE) in ODUk overhead and processing, 93, 94t inOTUK, 103, 103t in tandem connection monitoring (TCM), 96, 96t Bands, wavelength, 705, 705t Bandwidth allocation, at 100 kbits/s granularity, for T-line over MEN, 462 Bandwidth broker, 560 Bandwidth evolution, in multiplex structures, 127-129, 127f-130f Bandwidth profiles application of, 363-365 Ethernet Connection (EC) attributes and, 386 in Ethernet services over MEN, 359-365 algorithm of, 360-362, 360f, 361f application of, 363-365, 364f configuring Customer Edge (CE) and, 365 disposition of service frames in, 362, 362t graphical depiction of, 360, 360t parameters of, 360-362, 362, 362t in Ethernet services over public WAN, Class of Service Identifier in, 364, 364f green, 361-362, 361f
Index in MEN, 525-526 red, 361-362, 361f yellow, 361-362, 361f Bandwidth provisioning, for T-line over MEN, 461-462, 463f bandwidth allocation at 100 kbits/s granularity in, 462 Ethernet multiplexing in, 462, 463f TDM multiplexing in, 462 Bathtub curve analysis of jitter, 746-748, 747f Beginning-Of-Life (BOL), 711 Bell System, frequency traceability and, 266 Bidirectional Line Switching Redundancy (BLSR), 509 Bidirectional switching, 304 in MEN protection, 519 BIP-8. See Bit hiterleaved Parity (BIP-8) Bit errors, in MEN CES, 490 Bit Interleaved Parity (BIP-8), 92 in G.709 overhead bytes, 88, 88f inOTUK, 83f, 101 Bit recovery, in synchronization architectures for SONET/SDH, 258 Bit-synchronous mapping, 201 Black-box method, 699 Black-link method, 699 Bridged-source timing method DSl and, 281-282, 281f in SONET/SDH, 281-282, 281f Broadcast service frame, 347-348 Buffer credit. See Storage Area Networks (SANs), SONET for; Storage networking Buffer underflow and overflow alarm, in MEN CES, 488^89 Building Integrated Timing Supply (BITS), 215,260 Bundling, Ethernet client interfaces and, 404 Bundling Map, 354-355, 354f Business continuity. See Storage Area Networks (SANs); Storage networking C Call steady-state, 645 in UML, 586 Call/connection release, 629 Call control, in ASTN, 555-559, 556f, 558f Call disconnects, 604 Called parties, 560 Call identifier, 645
Index Calling/Called Party Call Controller (CCC), 581f, 582, 627, 627f Call objects, new, in GMPLS RSVP-TE (G.7713.2) signaling, 647 Call perspective, 562 Call requests, 604 Call segments, 564, 565f Call separation support, in GMPLS RSVP-TE (G.7713.2) signaling, 645-646 Call setup, 628 Capability, 624, 624t Capacity consumers, 33 Card-card communication, over backplanes, 736 Carriage of services, over transport networks, 7-10 Ethernet services architecture and definitions, 7-10 storage area services over SONET, 10 Carrier grade in fiber channel SANs, 537-538 of SONET/SDH infrastructure, 546 Carrier's carrier, 560 CBS. See Committed Burst Rate Size (CBS); Committed Burst Size (CBS) CE. See Customer Edge (CE) CE-bound IWF, 472 Centralized management systems, in G.8080, 571-573 CES. See Circuit Emulation Service (CES) CE VLAN ID, 348-350 for Ethernet services over MEN, 350 preservation of, 350, 350t, 352 CE VLAN ID/EVC map, 348-349, 349f broken, example of, 355, 355f CE-VLAN ID preservation, 350 CF. See Coupling Flag (CF) Channels, 694 Characteristic Information (CI), 51, 52f, 334, 378 Chip-chip interconnect, 736 Chip-to-chip communications standards, 661. See also Intra-Network Elements communications CIR. See Committed Information Rate (CIR) Circuit Emulation Service (CES) definition of, 457 over MEN {See Metro Ethernet Network Circuit Emulation Services (MEN CES)) PDH, 468t, 469, 470t
789 Circuit Emulation Service Interworking Function (CES IWF), 469 in MEN CES, 469 synchronization description of, 475-477, 475f, 475t Class of Service (CoS), 356-359, 385, 389 Drop Precedence (DP) and, 385, 399 frame delay performance objective, point-to-point, 358, 358f, 358t frame delay variation, point-to-point, 359, 359t frame loss performance, point to point, 359, 359t identifying, 356-357 Layer 2 control protocols in, 365-367 {See also Layer 2 control protocols) performance parameters in, 357 Class of Service (CoS) Identifier, 357, 525 bandwidth profile and, 364, 364f Client addressing. See also Address and addressing in GMPLS RSVP-TE (G.7713.2) signaling, 648 Client alignment, 30 Client data frames, GFP, 159, 160f Client-dependent procedures, GFP, 166-171 8B/10B client processing in GFP-T in, 169 adaptation into 64B/65B code blocks into GFP superblocks of, 169f, 170 asynchronous-transparent mapped mode in, 165f, 168-169 client signals supported by GFP and, 166, 166t frame-mapped mode (GFP-F) in, 167, 167f generating GFP-T 64B/65B codes in, 169-170, 170f transparent-mapped mode (GFP-T) in, 167-168, 168f Client encoding, 29 Client-independent procedures, GFP, 164-166, 165f frame multiplexing in, 166 GFP frame delineation in, 164-165, 165f link scrambler in, 166 Client interfaces, for Ethernet services over public WAN, 401^05 bandwidth profile in, 404 bundling in, 404 Layer 2 control protocol processing in, 404-405 multiplexed access in, 402, 403f
790 UNI service attributes, common in, 402, 402t UNI service attributes, service-dependent in, 402, 402t VLAN mapping in, 404 Client labeling, 29 Client management frames, GFP, 162 Client/server relationship, 31, 33 Client signal, supported by GFP, 166, 166t Client signal fail (CSF), GFP, 163, 163f Clock gapped, 202 regular, 202 Clock backup modes, in synchronization fijr SONET/SDH, 286-292, 289t. See also Holdover mode Clock fast mode, 292. See also Holdover mode Clock hierarchy, 249-250 Clock modes, SDH Equipment Clock (SEC) and ODUk Clock (ODC), 218-219 Clock noise, 207-208 Clock recovery, timing engine (TE) fimctions and, 270 CM. See Color Mode (CM) Coarse Wavelength Division Multiplexing (CWDM), standards for, 699 CO-CS. See Connection-oriented circuit-switched (CO-CS) network Coding gain, 70-73, 71f-73f measured via EJN^, 71, 72f measured via OSNR, 72-73, 73f measured via Q factor, 70-71, 7If, 72f Cold-pluggable device, 723 Colorblind, 362 Color Mode (CM), 360 Comment Resolution, 775 Committed Burst Rate Size (CBS), 8 Committed Burst Size (CBS), 391t bandwidth profiles and, 360 Committed Information Rate (CIR), 8, 360 Communications, intra-Network Element, 11-12 Compatibility longitudinal, 692 physical layer, 700-701 transverse, 693-694 physical layer, 701-703, 702f Compatibility, transverse vs. longitudinal, 700-712 application code terminology related to distancein, 709, 710t background on, 700
Index optical fiber types and recommendations for, 703-705, 705t optical interface recommendations for, 706-709, 707t, 708t optical interfaces in, 708, 708t physical layer, 700-703, 702f power budget design in optical path penalty modeling and verification in, 711-712 worst-case design approach to, 710-711 signal classes and, 706, 707t Compliance test methodology, for high-speed serial interconnects, 742-748 bathtub curve analysis of jitter in, 746-748, 747f eye mask in, 742-744, 743f jitter modeling conventions in, 744-746 {See also Jitter) Component architecture, in G.8080, 575 Computational viewpoint, 578-579 Conceptual data processing partitioning, within Network Element, 664-665, 664f Congruent topology, 600, 600f DCN, 600, 600f Connection, 31-32, 3If degenerate subnetwork, 33 end-to-end, 555 E-NNI, 630, 631t Ethernet, 381-386 in Ethernet Private LAN (EPLAN) service, 391, 391t in Ethernet Private Line (EPL) service, 387, 388t in Ethernet Virtual Private LAN (EVPLAN) service, 391, 392t in Ethernet Virtual Private Line service (EVPL), 388, 389t layer, in Printed Circuit Board (PCB) interconnects, 739-740, 740f link, 33, 34f local type of, 625 in MEN, 335 network, 33, 34f permanent, 555 selector, 44 soft permanent, 556, 556f subnetwork, 31, 33, 34f protection of, 307-308, 308f, 309f switched, 552, 555, 556f termination, 32 timing, UltramapperTM vs. TSWC01622, 273,274f
Index virtual, 426, 426f Connection control, in ASTN, 555-559, 556f, 558f Connection Controller (CC), 581, 581f, 628 Connection dimension model, 32-35, 34f Connection fimction, 30, 30f in MEN, 337 Connection Identifier Information Element (CUE), 644 Connectionless layer networks, modeling, 60-61 Connectionless networks, 19 in G.8080, 575-576 Connectionless Trail, 335 Connection management, 28-29 in ASTN, 567-568 Connection-oriented circuit-switched (CO-CS) network, 392 Connection-oriented networks, 19 Connection-oriented packet-switched (CO-PS) network, 392, 394 emerging, 400 fimctional characteristics of, 396 necessary modifications to support, 398-400,401t Connection perspective, 562 Connection Point (CP), 32 in MEN, 335 termination, 32 Connection separation support, in GMPLS RSVP-TE (G.7713.2) signaling, 645-646 Connection service, 552 Connection setup, 628 Connectivity monitoring, Ethernet Connection (EC) attributes and, 386 Connectivity restoration instant, in MEN, 502, 503f Connectivity restoration time, in MEN, 502, 503f Connectivity verification, discovery and, 605 Consent, 775 Consequent action, 55 Constant bit rate (CBR), 191 Consumer Edge VLAN Identifier (CE VLAN ID). See CE VLAN ID Containers, 120 Contiguous concatenated (CCAT) containers, 127 Continuous Wave (CW) laser, 715 Contributions, to study groups, 773-774 Control, of optical transport networks, 10-11 Control domains, signaling, 646
791 Control Entity Logical Adjacency (CELA), establishment of, 610 Control frames, GFP, 164 client-dependent procedures in, error control in, 171 client-independent procedures in, 164-166 {See also Client-independent procedures, GFP) idle frame, 164 Controlled octet slip, 234 Controlled slip, 212 Control packet, 141 Control plane, 337, 552-553, 553f MPLS, 453-454 signal communications network message delivery in, 597-599, 598f Control plane architecture (G.8080), 571-595 background on, 571-576, 574f centralized management systems in, 571-573 component architecture in, 575 in connectionless networks, 575-576 end-to-end configuration using network management and control plane functionality in, 573-574, 574f fiiUy distributed model for, 573 goal in, 574 Reference Model for Open Distributed Processing (RM-ODP) and, 574-575 component overview in, 580-583, 581f {See also specific components) control plane view of transport network in, 576-578, 577f, 578f distribution models in, 585-586 example of components in action in, 586-588, 586t, 587f, 588f general component properties and special components in, 580, 580f identifier spaces in, 588-593, 590f, 592f {See also Identifier spaces) identifying components in, 578-579 interlayer modeling in, 583-585, 584f restoration architecture in, 593-595, 594f Control plane component identifiers, 590f, 592 Control plane management, 633-635, 636f Control plane technology, 552-553, 553f Control plane view, of transport network, 576-578, 577f, 578f Coordinated Universal Time (UTC) frequency of, 217
792 timing traceability and, 267 CO-PS. See Connection-oriented packet-switched (CO-PS) network Core header, GFP, 160 Core HEC (cHEC) field, 160 Correlated, bounded, high-probability jitter (CBHPJ), 745 Correlated, bounded Gaussian jitter (CBGJ), 746 Coupling Flag (CF), 8, 360 Cross-fertilization, of concepts and ideas, 1 Crosstalk far-end (FEXT), 738 near-end (NEXT), 738 CSMA/CD, 367 C-types, new, in GMPLS RSVP-TE (G.7713.2) signaling, 647 Current synchronization network, 249 Customer-controlled loopbacks, 492-493, 492f Customer Edge (CE), 8, 344, 524-525, 525f See also CE entries Customer Edge VLAN Identifier (CE VLAN ID). See CE VLAN ID CWDM. See Coarse Wavelength Division Multiplexing (CWDM) D Data. See Storage Area Networks (SANs), SONET for Data and PAD field, 370 Data Communications Network. See DCN (Data Communications Network) Data (database) grovrth of, 527-528 organization of, 527 storage of, 528 Data dependent jitter (DDJ), 745, 746 Data field, in Ethernet services over MEN, 370 Data-friendly next-generation SONET/SDH, 4-6 Data Link Connection Identifiers (DLCIs), 427 Data Plane, 337 Data replication, 533 Data starvation, 488 DCN (Data Communications Network), 597 reliability considerations in, 602-603 security considerations in, 603 topologies of, 599-602 congruent, 600, 600f focused (hub and spoke), 600-601, 60If
Index fullmesh, 599, 599f hybrid (multitier), 601-602, 602f DCN identifiers, 590f, 592 Decision-feedback equalization (DFE), 757 De-emphasis, at transmitter, 749-753, 750f, 751f,753f Defect, 55 Degenerate subnetwork, 33 Degenerate subnetwork connections, 33 Degradation detection, 728-732 Degrade condition, 500 Degrade condition threshold, in MEN protection, 517-518 Delayed contributions, 773-774 Delivery, in fiber channel SANs in-order, 536 lossless, 537 Demultiplexer layer, in L2VPNs, 430-431 Dense Wavelength-Division Multiple (DWDM), 3, 216, 694-695 inOTN, 313 Dense Wavelength Division Multiplexer Optical Add-Drop Multiplexer (DWDM-OADM), 63 Dense Wavelength Division Multiplexing (DWDM), standards for, 695-697 Department of Defense (DOD), in synchronization architectures for SONET/SDH, 267 Destination address field, 369 of Ethernet media access control layer, 369 Desynchronizer, 201 Detection, in network protection, 498 Detection time, in MEN, 502 Detection time Tl, 305, 306f Deterministic jitter (DJ), 744-745 Differential delay, in VCAT and LCAS, 131-132, 132f compensation of, 145-146 detection of, 144-145 Differential delay buffers, in VCAT and LCAS overview of, 147 sizing of, 149 structure and management of, 146-147, 147t Differential Group Delay (DGD), 693, 701 Digital information, growth of, 527-528 Direct Attached Storage (DAS), 528, 529, 530f Direct-source timing method, in SONET/SDH, 280, 280f
Index Disaster recovery. See Storage Area Networks (SANs); Storage networking Disconnect/hang-up request, 604 Discover Agent adjacency, 610 Discovery, automated (G.7714), 604-611 across administrative boundaries, 611 architecture of, 606-607, 606f background on, 604-605 connectivity verification and, 605 Layer Adjacency Discovery Methods in, 640-643, 641f methods and protocols for, 640-643, 641f types of, 607-611 control entity logical adjacency establishment in, 610 layer adjacency discovery in, 607-610, 608f, 609f service capability exchange in, 610-611 Discovery Agent (DA), 581f, 583, 606 Dispersion Shifted Fiber (DSF), 704 Distance, application code terminology related to, 709, 710t Distance extension alternatives, in SANs, 538-541 legacy private line in, 539, 542t SONET/SDH, 539, 541-542, 542t storage over IP in, 539, 540-541, 540f, 542t WDM in, 539-540, 542t Distance extension requirements, in Storage Area Networks (SANs), 536-538. See also under Storage Area Networks (SANs) Distributed Feedback (DFB), 713 Distribution models, in control plane architecture in G.8080, 585-586 Diversity support, 625-626 Domains, 563-564 in ASTN, 562-564 Do Not Revert (DNR), 311 Downstream node, 81, 82f Droop, 545 Drop Precedence (DP), 385 DS1,261 bridged-source timing method and, 281-282,281f extended super frame (ESF) of, 261 line/external timing method and, 282 super frame (SF) of, 261 threshold AIS generation and, 283 DSl interfaces stratum 2 holdover transient vs. seconds at, 288, 289t
793 stratum 3/3E holdover transient vs. seconds at, 288, 289t DS-3 client signal, PDH, on STM-N server, 36, 37f, 39-40 DSLAM, 394, 394f Dual-Dirac distribution, 746-747 Dual-In-Line(DIL),713 Dual protected services, in MEN CES, 494, 494f Dual-star topology, 737 Dual unprotected services, in MEN CES, 493-494, 493f DUK multiplexing, 104-116 Duplication. See Storage Area Networks (SANs); Storage networking DWDM. See Dense Wavelength-Division Multiple (DWDM) DWDM-OADM. See Dense Wavelength Division Multiplexer Optical Add-Drop Multiplexer (DWDM-OADM) El,261.&eafaoDSl EJNQ, measuring coding gain with, 71, 72f Ebrium Doped Fiber Amplifier (EDFA), 694 EBS. See Excess Burst Size (EBS) EBSCON (Enterprise Systems Connection), 529, 531t Edge LSR, 453 Editor, 771-772, 771f eGFP. See Extended GFP (eGFP) frame format Egress service frame, 345 EIR. See Excess Information Rate (EIR) E-LAN. See Ethernet LAN Service (E-LAN) Electro-absorption Modulated Lasers (EMLs), 721-722 Element-level processing, 53 Element Management Function (EMF), 54 fault management process in, 56-57, 57f Element Management Systems (EMSs), 593 E-Line. See Ethernet Line Service (E-Line) Embedded clock, 258-259 Embedded Communications Channels (ECCs), 597-598, 598f EMLs (electro-absorption/extemally modulated lasers), 715, 721-722 Emphasis, 749-750 Emulated Circuit Demultiplexing Function (ECDX), 471 in MEN CES, 471 Emulation mode structured, 459, 460
794 unstructured, 459, 460 Encapsulation layer, in L2VPNs, 429 End Of Life (EOL), 710-711 End Of Life (EOL) specifications, 701 End-to-end configuration, 573-574, 574f End-to-end connection, 555 End-to-end delay, in MEN CES, 489 End-to-End Path Protection (EEPP) in MEF protection, 509-511, 51 Of OA&M-based, in MEN, 522 packet 1+1, in MEN, 523 End-to-end principle, 564-567, 565f End-to-end service associations, calls as, 564-566,565f Engineering and technology viewpoint, 578 E-NNI call and connection attributes, 630, 631t Enterprise Systems Connection (EBSCON), 529, 531t Enterprise viewpoint, 578 Environmental effects, of Printed Circuit Board (PCB) interconnects, 740-742, 741f Environmental variation, 742 EPL. See Ethernet Private Line (EPL) service EPLAN. See Ethernet Private LAN (EPLAN) service Epsilon model, 711 Equalization for backplane channel, 757 decision-feedback, 757 on eye opening, 756, 757f at receiver, 754-756, 755f, 756f Equipment control, 50-52 Equipment packaging, 39-40, 40f Equipment supervisory process, 53-60 application example of, 58-59, 60f basic concepts of, 53-54, 54f terminology and constructs of, 55-56 utilization of concepts of, 56-58, 56f, 57f Equivalent protection path, 504 ESCON, transport over OTN in. See Multiplex structures, of OTN Ethernet (Services). See also Metro Ethernet architecture and definitions of, 7-10 Backplane, 760, 762 basic tutorial of, 367-371 physical layers in, 368, 368t media access control layer in, 368-370 over metro networks, 7-8 over MPLS networks, 9, 425^55 (See also Ethernet (Services), over MPLS networks)
Index over public wide-area networks, 8-9 SONET services for Storage Area Networks in {See Storage Area Networks (SANs), SONET for) Ethernet (Services), over Metro Ethernet Networks (MEN) background on, 343 Ethernet basic tutorial and, 367-371 media access control layer in, 368-370 {See also Ethernet media access control layer) physical layers in, 368, 368t VLAN ID in, 370-371, 371f future work of, 367 model of, 343, 344f service features for {See also Layer 2 control protocols) all-to-one bundling map in, 350-351, 351f bandwidth profiles in, 359-365 {See also Bandwidth profiles, in Ethernet services over MEN) CE-VLAN ID preservation in, 350 Class of Service in, 356-359 {See also Class of Service (CoS)) Ethernet LAN Service (E-LAN) and, 356 Ethernet Line Service (E-Line) and, 356 feature constraints of, 355-356 maps at UNIs in an EVC in, 355, 355f Layer 2 control protocols in, 365-367 service multiplexing in, 352-367 {See also Service multiplexing) services model for, 343-349 customer edge (CE) and, 344 Ethernet Virtual Connection (EVC) identification at UNI in, 348 Ethernet Virtual Connection (EVC) in, 346 {See also Ethernet Virtual Connection (EVC)) service frame in, 345 {See also Service frame) User Network Interface (UNI) and, 344-345 Ethernet (Services), over MPLS networks, 9, 425-450 E-LAN Service in, 436, 437f E-Line Service in, 436 Ethernet Virtual Connection (EVC) in, 436 L2VPNS over MPLS backbone in, 428-435 {See also Layer 2 Virtual
Index Private Networks (L2VPNs), over MPLS backbone) Metro Ethernet services in, 436, 437-449, 437f {See also Metro Ethernet services over MPLS) Virtual Private Networks (VPNs) in, 425-427 classification of, 426^27, 427f multiservice converged packet switched backbone in, 427 traditional layer 2 (L2VPNs), 425-426, 426f VPLS for Metro Ethernet in, 449^50, 450f Ethernet (Services), over public WAN, 373^22 client interfaces in, 401-405, 402t (See also Client interfaces, for Ethernet services over public WAN) emerging technology for, 421^22 Ethernet client interfaces in, 401^05, 402t bandwidth profile of, 404 bundling in, 404 Layer 2 control protocol processing in, 404^05 multiplexed access in, 402, 403f UNI service attributes in, 405 VLAN mapping in, 404 network-to-network interface (NNI), Ethernet transport and, 405-411, 406f-408f, 410f,411f OAM and, 411-419 domain service vs. network and, 413, 414f generic message format of, 418, 419f mapping maintenance entities to, 417, 418t point-to-point Ethernet flow reference modelin, 414, 415f, 416f protection and restoration for, 419^21 Layer 2 and service restoration in, 421 service provided by transport network in, 420 reason for use of, 373-374 services for, 375-377, 376-377t service types and characteristics of, 379-391, 380f,381f Ethernet Connection (EC) in, attributes of, 381-386 (See also Ethernet Connection (EC)) Ethernet Private LAN (EPLAN) service in, 389-391, 390f, 391t
795 Ethernet Private Line (EPL) service in, 387-388, 387f, 388t Ethernet Virtual Private LAN service in, 391,392t Ethernet Virtual Private Line Service (EVPL) in, 388, 389f standards activity for, 377-378 terms for, 378-379 transport network models supporting Ethernet connectivity services in, 392-401 {See also Ethernet connectivity services) Ethernet bridges, 368 Ethernet client interfaces, 405, 405t Ethernet Connect Functions (ECFs), 507 Ethernet Connection (EC), 379, 381-386 bandwidth profile in, 386 connectivity monitoring in, 386 vs. Ethernet Virtual Connection (EVC), 379 link type in, 385-386 network connectivity in, 382-384, 383f, 384f preservation in, 386 separation, customer and service instance in, 385 summary of, 381, 382t survivability in, 386 transfer characteristics in, 385 UNI hst in, 386 Ethernet connectivity services, transport models supporting, 392-401 DSLAM uplink aggregation in, 394, 394f EoS/PoS/DoS aggregation in, 394, 395f extended GFP (eGFP) frame format in, 400, 400f extended GFP (eGFP) frame format-required modifications for CO-PS network in, 400, 401t layered architecture for EPL services in, 397,399f MDP frame format-required modification ofCO-PSin, 400, 401t MPLS data plane (MDP) in, 399, 400f multiple-customer flow aggregation in, 393,393f packet switching overlay for EoS in, 397, 398f single customer flow aggregation and, 392,393f SONET/SDH physical layer transport for EoS in, 397, 397f Ethernet flow, 327
796 Ethernet Flow Termination Function (EFT), 472 in MEN CES, 472 Ethernet LAN Service (E-LAN), 356, 356t, 436, 437f, 512. See also Ethernet Line Service layer (ETH layer) Ethernet Line Service (E-Line), 356t, 436 in layer 2 control protocols, 356 Ethernet Line Service (E-Line) emulation, walk-through example of, 435f, 441-443, 443f Ethernet Line Service layer (ETH layer), 10, 328 in MEN, 328 Ethernet Line timing, 475f, 475t Ethernet MAC frame, GFP-F encapsulation of, 409, 410f Ethernet mapping. Generic Framing Procedure (GFP) and, 271 Ethernet media access control layer, 369f data and PAD field in, 370 destination address field in, 369 frame check sequence field in, 370 length/type field in, 370 preamble field in, 369 source address field in, 369 start frame delimiter field in, 369 with tag control information, 370, 371f Ethernet modes, raw vs. tag, in E-Line services, 439 Ethernet multiplexing, for T-line over MEN, 462,463f Ethernet over SDH/SONET (EoS), fionctional model of, 410, 41 If Ethernet over Transport (EoT) service, 406 laDI NNI for, 406, 406f frDI NNI for, 406, 407f server layer networks of, 407, 407f Ethernet physical interface (ETY), 407 Ethernet physical layer network (ETY), 379 Ethernet Private LAN (EPLAN) service expected connection characteristics of, 391,391t illustration of, 389, 390f Ethernet Private Line (EPL) service, 387-388 connection characteristics of, 387, 388t GFPin, 184-185, 185f illustration of, 387, 387f layered architecture for, 397, 399f Ethernet pseudowires (PWs), via LDP, in E-Line services, 440^41, 441f
Index Ethernet/TDM transport system, hybrid, 154-155, 154f Ethernet Virtual Connection (EVC), 8, 327, 346, 436, 498^99 bandwidth profile in, 363, 364f vs. Ethernet Connection (EC), 379 identification at UNI of, 350 in T-Line over MEN, 458 Ethernet Virtual Private LAN (EVPLAN) service, 391 expected connection characteristics of, 391,392t Ethernet virtual private line service (EVPL), expected connection characteristics of, 388, 389t Ethernet Wide Area Network (E-WAN), in MEN, 329 ETH interface signal structure, 409, 41 Of ETH layer. See Ethernet Line Service layer (ETH layer) ETH link, in MEN, 340, 34If ETY (Ethernet physical interface), 407 ETY (Ethernet physical layer network), 379 EVC. See Ethernet Virtual Connection (EVC) Events, 501 Event timing, in MEN, 501-503, 503f Excess Burst Size (EBS), 360 Excess Information Rate (EIR), 8, 360 Explicitly routed LSP, 454 Extended attachment unit interface (XAUI), 759 Extended GFP (eGFP) frame format, 399, 400,400f Extended super frame (ESF), 261 DSland,261 Extension header, GFP, 161-162 Extension HEC (eHEC) field, 162 External/line timing. See Line/external timing method Externally Modulated Laser (EML), 715 External Network-to-Network Interface (E-NNI), in MEN, 329, 332 External timing, in MEN CES, 476 External timing configurations, in SONET/SDH, 279-286, 284t. See also Timing configurations, external, in SONET/SDH External timing mode, in SONET/SDH, 259f, 260 External timing option, 475f, 475t Eye mask, 742-744, 743f Eye opening (diagram), 750-752, 752f, 753f
Index equalization on, 756, 757f Fabry Perot, 713 Facility Data Link (FDL), in MEN CES, 487^88 Fail condition, 500 Failure, 55 Failure types, in MEN, 500-501 degrade condition (soft link failure), 500 fail condition (hard link failure), 500 node failure, 501 False frame synchronization, in GFP, 175-176 Fan-out, of timing distributor (TD) functions, 271 Far-end crosstalk (FEXT), 738 Fault, 55 Fault, optical in conventional transmitters and receivers, 728-731 in optically amplified systems, 731-732 Fault cause, 55 Fault detection instant, in MEN, 501, 503f Fault management process Element Management Function (EMF), 56-57,57f Trail Termination Function, 56, 56f Fault monitoring, 54 FCIP, 541, 541f, 542t FEC. See Forward Error Correction (FEC) Fiber Channel (FC), 10, 530, 53It, 534-535, 534f, 535f over IP, 539, 540-541, 540f, 542t Fiber Channel IP (FCIP), 541, 541f, 542t Fiber Channel Storage Area Networks (SANs), distance extension requirements in, 536-538. See also under Storage Area Networks (SANs) Fiber Connectivity (FICON), 530, 53It Fibre Channel. See Fiber Channel (FC) FICON (Fiber Connectivity), 530, 53It Fixed infrastructure, 34 Flexibility, network, 33-34 in fiber channel SANs, 537 Flicker frequency modulation (FFM), 209 Flicker phase modulation (FPM), 209 Flow, 335, 378 Flow control, in SONET, 545 Flow Domain (FD), 335, 378 definition of, 378 multipoint-to-multipoint connectivity and, 384
797 Flow Domain Function, 337 Flow point definition of, 378 OAMand,417 Flow Point/Flow Point Pool, 335 Flow Point Link, 335 Flow Point Pool Link, 335, 378 Flow termination, 378 Flow Termination Point, 336 Focused topologies, 600-601, 601f Forced switch, in MEN, 501 Forward Error Correction (FEC), 4, 67-73, 664 coding gain in, 70-73, 71f-73f measured via EJN^, 71, 72f measured via OSNR, 72-73, 73f measured via Q factor, 70-71, 7If, 72f in interfaces for OTNs, 67-73 {See also Forward Error Correction (FEC)) theoretical description of, 68-70, 69f use of, 67-68 Forwarders, in L2VPNs, 431^32, 432f Forwarding, in synchronization of status messages (SSM), 244 Forwarding Equivalence Class (FEC), in MPLS networks, 451 Forwarding information base (FIB), 453-454 Forwarding plane, MPLS, 454 Four-photon mixing, 704 Four-Wave-Mixing (FWM) effect, 704-705 Fragmentation, in L2VPNs, 431 Frame acquisition delay, in GFP, 179-182, 180f, 181f Frame alignment overhead, in OTUK, 100, lOOf, lOlf Frame alignment signal (FAS), in OTUK, 100, lOOf Frame check sequence (FCS), 345 Frame check sequence field, 370 Frame delay, 357, 358f in MEN CES, 489^90 Frame delay performance objective, for point-to-point EVC, 358, 358f, 358t Frame delay variation, 357 Frame delay variation performance objective, for point-to-point EVC, 359 Frame delineation, in GFP, 164-165, 165f Frame delineation loss (FLD), in GFP, 174-175, 175t Frame Error Ratio (FER), 490 Frame formats, GFP, 159-163. See also GFP frame formats Frame jitter, in MEN CES, 489-490
798 Frame loss, 357 Frame loss performance objective, for point-to-point EVC, 359 Frame-mapped mode, in GFP (GFP-F), 167, 167f Frame multiplexing, in GFP, 166 Frame relay, 365 Frame unavailability (FUA), in GFP, 176-178, 178f Free-run, in MEN CES, 476 Free-run mode, internal timing in, 261 Frequency accuracy, SDH Equipment Clock (SEC) and ODUk Clock (ODC), 218-219 Frequency Domain Multiplexed (FDM) systems, 190-191 Frequency drift rate, 206 Frequency justification in 4 X ODUl to ODU2 multiplexing, 111-112, 112t in ODU1/ODU2 to ODU3 multiplexing, 115, 116t Frequency offset, 206 Frequency tolerance, 206 Frequency traceability, 262-264, 263f, 264f Bell System and, 266 SONET/SDH, clock distribution and, 267, 267f time interval error (TIE) and, 264 timing loops in, 265 Full mesh topology, 599, 599f, 737 Full restoration time, 504 Function, 20 Functional elements, generic MEN, 336-337 Functionality, 29-30, 30f Functional modeling, transport, 18-61 application examples of, 40-50 OTN equipment for ODU2 links and subnetworks in, 49-50, 49f, 50f ring topology in SONET/SDH in, 40-43, 41f-43f STM-64 switched connection services via OTN mesh network in, 45-49, 46f-48f transport fianction characteristics implemented on ADM in, 4If, 43-44, 44f, 45f basic concepts of, 20-29 G.805-based modeling approach in, 20, 60 layering in, 21-24, 23f partitioning in, 24-29, 25f, 26t(See also Partitioning)
Index topology and function in, 20 connection dimension model in, 32-35, 34f connections and points in, 31-32, 3If equipment control in, 50-52 equipment packaging in, 3 9 ^ 0 , 40f equipment supervisory process in, 53-60 {See also Equipment supervisory process) examples of, 36-38, 37f, 38f functionality of, 29-30, 30f ITU-T Recommendation G.805 for, 18-20,60 ITU-T Recommendation G.809 for, 19, 60 ITU-T Recommendation G.8010 for, 20 modeling connectionless layer networks in, 60-61 objective of, 18 sublayers and function decomposition in, 35, 35f, 36f use of, 18-19 Functional modeling specification technique, 2-3 Functions, 31 Fuzzy networking demarcation points, 662, 662f G.709 frame structure, 78f, 79, 80t G.709 overhead bytes, 81-98. See also G.709 overhead bytes directionality of information flow in, 81 ODUk overhead and processing in, 90-94 backward error identification and backward incoming alignment error (BEI/BIAE) in, 93, 94t ODUk frame structure in, 90, 90f ODUk overhead in, 90, 91f path monitoring (PM) byte descriptions in, 92-93, 92f path monitoring status (STAT) in, 94, 94t OPUk overhead bytes and client mapping structure in, 82-87, 83f frequency justification in, 84-86, 85t, 86t mapping CBR2G5 signal onto OPUl in, 86, 87f mapping CBRIOG signal onto OPU2 in, 86, 87f mapping CBR40G signal onto OPU3 in, 86, 87f OPUk overhead in, 83, 84t
Index similarly valued/formatted fields within G.709 frame in BIP-8, 88, 88f trail trace identifier (TTI), 89, 89t tandem connection monitoring (TCM) in, 95-98 automatic protection switching and protection communication channel (APS/PCC) in, 97-98, 98t backward error indication and backward incoming alignment error (BEI/BIAE) in, 96, 96t fault type and fault location reporting communication channel (FTFL) in, 98 general communication channels (GCCa, GCC2) in, 97 tandem connection monitoring ACTivation/deactivation (TCM-ACT) in, 97 TCM monitoring status (STAT) in, 96, 97t use of, 81 G.7713.1 PNNI signaling, 643-644 G.7713.3 GMPLS CR-LDP, 648-649 G.8080 rerouting domain model, 594, 594f Gapped clock, 202 Gaussian jitter, 745 correlated, bounded, 746 uncorrelated, unbounded, 745, 746 General communication channel 0 (GCCO), in OTN interfaces, 104 General Secretariat, ITU, 769, 769f Generic Framing Procedure (GFP), 5-6, 8, 153-187,679 applications of, 184-186 in Ethernet private lines, 184-185, 185f in packet rings, 186, 186f in virtual leased lines, 185, 186f background on, 155-158 for fixed-length PDUs, 157 other traffic adaptation approaches in, 156-157 packet transport on public networks in, 155-156, 156f for small, fixed-length PDUs, 157 for small PDUs, 157-158 for variable-length PDUs, 158 Ethernet mapping and, 271 in Ethernet services over public WAN, 374 formats and procedures in, 158-171
799 client-dependent procedures in, 166-171 {See also Client-dependent procedures, GFP) client-independent procedures in, 16A-I66,l65f {See also Client-independent procedures, GFP) control frames in, 164 frame formats in, 159-163 {See also GFP frame formats) future directions in, 187 high-level fianctional overview of, 158, 158f implementation considerations in, 171-174 scrambler options in, 172-174, 173f, 173t virtual framer management in, 171-172 overview of, 153-155, 154f performance of, 174-184 false frame synchronization in, probability of, 175-176 frame acquisition delay in, 179-182, 180f, 181f frame unavailability (FUA) in, probability of, 176-178, 178f GFP frame delineation loss (FLD) in, probability of, 174-175, 175t link efficiency in, 182-184, 183f scrambler resynchronization delay in, 182 in SONET, 544 VCAT, advantages of, 144 Generic Routing Encapsulation (GRE), 434 GFP. See Generic Framing Procedure (GFP) GFP frame formats, 159-163 basic, 159, 159f client data frames in, 159, 160f client management frames in, 162 chent signal fail (CSF) in, 163, 163f core header in, 160 extension header in, 161-162 payload area in, 160 payload frame check sequence (FCS) in, 162 payload header in, 161 payload information in, 162 GFP-T 64B/65B codes, generating, 169-170, 170f GFP type field, 161 Gigabit Ethernet, 530, 531t GigaBit Interface Converter (GBIC), 719-720, 721f
800 Global optical transport network timing, 6-7 Global Positioning System (GPS) accuracy of, 267 external timing mode and, 260 Global Positioning System (GPS) timing, in synchronization of optical networks, 248 GMPLS CR-LDP (G.7713.3), 648-649 GMPLS RSVP-TE (G.7713.2) signaling, 644-648 background on, 644 call and connection separation support in, 645-646 client addressing in, 648 G.77132 extensions in, 646-647 messages and procedures (ResvTear/RevErr) in, 647 new call objects in, 647 new C-types in, 647 session paradigm in, 648 signaling control domains in, 646 Golden PLL, 744 Governance, of ITU, 769, 769f Green bandwidth profile, 361-362, 361f G.Sup39, 700-712. See also Compatibility, transverse vs. longitudinal H Hard link failure, 500 Hard state, 648 Hierarchical tunnels, VPN, 433^34 Hierarchy clock, 249-250 of International Telecommunication Union (ITU), 768-772, 769f, 77If Optical Transport (OTH), 4, 64 Plesiochronous Digital (PDH), 3, 63 standards for, 692-693 in routing in ASON (G.7715 and G.7715.1), 619-621, 620f in standards development process, 777-779, 777f of stratum levels, 257 Higher-Order Virtual Container (HOVC), 470 High-speed serial interconnects, 12-13, 735-764. See also Serial interconnects, high-speed Hold-in range, 218 SEC and ODC, 218 Hold-off instant, in MEN, 502, 503f Hold-off time, 296 in MEN, 502
Index Hold-off timer, 309-310 Hold-off time T2, 305, 306f Holdover, in MEN CES, 476-477 Holdover mode clock fast mode in, 292 exit from input reference switch and, 292 input signal qualification in, 291 lock-on time stabilization in, 292 phase offset calculation in, 291 internal timing in, 261, 287-289, 292 clock fast mode in, 292 exit from, 291-292 initiation of, 287 maintenance of, 289-290, 289t ovenization in, 290 stratum 3/3E holdover transient vs. seconds at DSl interface in, 288, 289t temperature compensation and, 290 lock fast mode in, 292 ovenization in, 288 Holdover value, calculation of, 288 Hop-by-hop routed LSP, 454 Hub and spoke topologies, 382, 600-601, 601f hybrid (two-tier), 602, 602f Hybrid Ethernet/TDM transport system, 154-155, 154f Hybrid Fiber Coax (HFC) links, 157 Hybrid (multitier) topologies, 601-602, 602f Hybrid (TDM + cell/packet based) Network Element architecture, 667-668 I Identifiers, 568, 589 Subnetwork Point Pool (SNPP), 590-591 Identifier spaces, 588-593 categories and types of, 589-590, 590f control plane component, 590f, 592 data communications network, 590f, 592 management plane, 590f, 593 name and address and, 589 relationships of, 589-590, 590f transport resource, 590-591, 590f, 592f use of, 588-589 Idle frame, GFP, 164 IEEE 802.IQ, 348 IEEE 802.1Qad, in fiiture of Ethernet services, 367 IEEE 802.1Q tag, 345 IEEE® 802.3aeTM Clause 47,XAUI, 759-760
Index iFCP, 541, 542t Impairment instant, in MEN, 501, 503f In-band approaches, 596 Incoming alignment error (lAE), in OTNs, 104 Incoming label, 451 In Force, 774 Information flow, directionality of, 81 Information viewpoint, 578 Infrastructure, fixed, 34 Infrastructure, optical transport network, 2-7 fianctional modeling specification technique in, 2-3 global optical transport network timing in, 6-7 multiservice, 3-6 data and TDM-friendly next-generation SONET/SDH, 4-6 optical transport hierarchy, 4 Ingress service frame, 345, 363, 363f bandwidth profile in, per UNI, 363, 363f In-order delivery, in fiber channel SANs, 536 Input reference switch, in holdover mode, 292 Input signal, qualification of, in holdover mode, 291 Instantaneous phase error, 207 Integrated solutions, for optical interfacing, 716-721. &e also under 140 Mbit/s to 2.5 Gbit/s technology Intelligent switching network (IN), 557 Inter Domain Interface (IrDI), 66-67, 67f, 406 NNI for EoT service in, 407f Interfaces, for Optical Transport Networks, 12, 63-117. See also Optical interfaces background on, 63-64 definition of, 562 forward error correction in, Gl-Ti {See also Forward Error Correction (FEC)) G.709 frame structure in, 78f, 79, 80t G.709 overhead bytes in, 81-98 {See also G.709 overhead bytes) general communication channel 0 (GCCO) in, 104 ODUK multiplexing in, 104-116 {See also ODUK multiplexing) OTN hierarchy overview in, 76-78, 76f-78f OTN standards in, 64-66, 65f OTUK overhead and processing in, 98-101
801 frame alignment overhead in, 100, lOOf, lOlf frame alignment signal (FAS) in, 100, lOOf multiframe alignment signal (MFAS) in, 100, lOlf OTUK frame structure in, 98-99, 99f scrambling in, 99-100, 99f section monitoring byte descriptions in, 101-104 backward defect indication (BDI) in, 102-103 backward error indication and backward incoming alignment error (BEI/BIAE) in, 103, 103t Bit hiterleaved Parity (BIP-8) in, 83f, 101 incoming alignment error (lAE) in, 104 Trail Trace Identifier (TTI) in, 77f, 101,102f standardized, 66-67, 67f tandem connection monitoring in, 73-75, 74f, 75f Interlayer modeling, in control plane architecture in G.8080, 583-585, 584f Intermediate-reach, 709, 710t Internal Network-to-Network Interface (I-NNI), in MEN, 329, 332 Internal timing, in holdover mode, 261, 287-289, 292. See also Holdover mode, internal timing in Internal timing mode, free-run in, 261 Internal timing reference, 475f, 475t International Telecommunication Union (ITU), 768-775, 769f, 770 founding of, 1 hierarchy of, 768-772, 769f, 771f membership in, 772 recommendations of {See ITU-T recommendations) standardization sector of, 64 standards development by, lll-l^T) {See also Standards development process) standards of {See ITU-T standards, optical interface) Internet Service Provider (ISP), 559 Internet Small Computer Systems Interface (iSCSI), 530, 53It, 540, 540f, 542t Interoperability in network restoration, 316-317, 317f in signaling (G.7713) in ASON, 649-651 Interworking, in signaling (G.7713) in ASON, 649-651
802 Interworking Function (IWF), 457 asynchronous and asynchronous tributaries, 477^78 and synchronous tributaries, 478 CE-bound, 472 Circuit Emulation Interworking Function (CES IWF), 469 MEN-bound, 472 synchronous and asynchronous tributaries, 477 and synchronous tributaries, 477 Interworking Function (IWF) processor, 475f, 475t Intra Domain Interface (laDI), 66-67, 67f, 406 NNI for EoT service, 406f Intra-Network Elements communications, 11-12,661-688 2.5 Gbit/s systems in, 668-672 {See also 2.5 Gbit/s technology and systems) 10 Gbit/s systems in, 672-677 {See also 10 Gbit/s technology and systems) 40 Gbit/s systems in, 681-688 {See also 40 Gbit/s technology and systems) background on, 661-662 Metro Ethernet Network (MEN), 326-341 {See also Metro Ethernet Network (MEN) architecture) Network Element design and interface architecture in, 664-668 {See also Network Element (NE)) conceptual data processing partitioning within Network Element in, 664-665,664f hybrid (TDM + cell/packet based) Network Element architecture in, 667-668 packet based Network Elements in, 665-666,665f TDM based Network Elements in, 666, 666f requirements placed on Network Elements by network in, 662-664, 662f SPI-4 Phase 2 (OC-192 System Packet hiterface) in, 679-681, 680f System Framer Interface-4 Phase 2 (SFI-4 Phase 2) in, 677-679, 678f iSCSI (Internet Small Computer Systems hiterface), 530, 53It, 540, 540f, 542t Isolated pointer adjustment, 205 ITU Council, 769, 769f ITU-D, 769f, 770
Index ITU G.Sup39, 700-712. See also Compatibility, transverse vs. longitudinal ITU-T. See International Telecommunication Union (ITU) ITU-T recommendations, 771 approval of, IIA-IIS G.651,703 G.652, 703-704, 705t G.653, 704, 705t G.654, 704, 705t G.655, 705, 705t G.656, 705, 705t G.691,707t,708, 708t, 721 G.692, 696-697, 707t G.693, 707t, 708, 708t, 709 G.694.1,707t G.694.2, 699, 707t G.695, 699-700, 707t, 709 G.696.1,697, 707t G.698.1,697, 707t G.699.1,709 G.709, 24 G.709 FEC, 68-69 G.805, 18-20, 25, 60, 336 G.807, 553-571 {See also under Automatically Switched Transport Network (ASTN) architecture) G.808.1, 296 {See also Protection switching) G.809, 19-20, 60, 336 G.811,213,214,215 G.813,214 G.825,214 G.841,303, 312 G.851-01,575 G.872, 23-24, 64 G.873.1,312 G.955, 692-693, 707t G.957, 694-695, 707t, 708, 708t G.959.1,707t, 708,708t G.7042/Y.1305, 140, 141 G.7712, 595-603 {See also Signaling Communications Network (SCN) architecture (G.7712)) G.7713, 626-633 {See also Signaling (G.7713),inASON) G.7714, 604-611 {See also Discovery, automated (G.7714)) methods and protocols for, 640-643 {See also Discovery, automated (G.7714); Discovery, automated
803
Index (G.7714), methods and protocols for) G.7715, 611-626 {See also Routing, in ASON (G.7715 and G.7715.1)) G.7715.1, 611-626 {See also Routing, in ASON (G.7715 and G.7715.1)) G.7715 and G.7715.1, 611-626 {See also Routing, in ASON (G.7715 and G.7715.1)) G.8010, 20 G.8080, 314-315 1.630,312-313 Y.1720, 312 ITU-T standards, optical interface, 691-733 background on, 691 development process for, 767-783 {See also Standards development process) historical perspective on, 691-700 All Optical Networks (AON) in, 700 Coarse Wavelength Division Multiplexing (CWDM) in, 699-700 Dense Wavelength Division Multiplexing (DWDM) in, 695-697 Optical Transport Network (OTN) in, 697-699 Plesiochronous Digital Hierarchy (PDH) in, 692-693 SDH/SONET in, 693-695 implementation of, 712-728 10 Gbit/s technology in, 721-728 {See also 10 Gbit/s technology) 40 Gbit/s technology in, 728 140 Mbit/s to 2.5 Gbit/s technology in, 713-721 {See also 140 Mbit/s to 2.5 Gbit/s technology) background on, 712-713 optical fault and degradation detection in, 728-732 conventional transmitter and receiver faults in, 728-731 optically amplified system faults in, 731-732 recommendations in, overview of, 706-709, 707t, 708t transverse vs. longitudinal compatibility in, 700-712 {See also Compatibility, transverse vs. longitudinal) IWF processor, 475f, 475t
Jeditterizer, 196
Jitter, 744-746 alignment, 195, 196-198, 198f bathtub curve analysis of, 746-748, 747f correlated, bounded, high-probability, 745 data dependent, 745, 746 defmition of, 259, 744 deterministic, 744-745 Gaussian, 745 correlated, bounded, 746 uncorrelated, unbounded, 745, 746 ITU-T recommendations on, for OTN, SDH, and PDH and, 214-216, 215t in loop/line timing mode, 260 modeling conventions for, 744-746 {See also Jitter) peak-to-peak, 209-210 periodic, 745, 746 random, 745 RMS, 209-210 sinusoidal, 196 timing, 195,200 in timing signal imperfections, 206 uncorrelated, bounded, high-probability, 745 waiting time, 202 Jitter accumulation for PDH clients of SONET/SDH networks, 227-231 for SDH clients of OTN, 231-233 STM-N and OTUk, 219-227, 222f-225f Jitter buffer, 490 Jitter generation, 199-200 Jitter generation and transfer, ODCr, 219-227 Jitter network limit and tolerance, STM-N and OTUk, 219-227 Jitter tolerance, 196-198, 198f Justification + 1/0/-1 byte, 202 +2/+l/0/-l,202 negative, 201 positive, 201 Justification control, 201 Justification structure in 4 X ODUl to ODU2, 109, 109f, 109t in ODU1/ODU2 to ODU3 multiplexing, 114, 114t L2VPNs. See Layer 2 Virtual Private Networks (L2VPNs) Label, 451 in MPLS networks, 451-452, 452f
804 Label disposition, 453 Label Distribution Protocol (LDP), 434 establishing Ethernet PWs via, 440-441, 441f Label encoding, in MPLS networks, 452, 453f Label imposition, 453 Label stack, MPLS, 451, 452f, 453f Label stack operations, in MPLS networks, 453 Label swapping, 453 Label switched path (LSP), 434 in MPLS networks, 454, 455f Label switched router (LSR), 434 in MPLS networks, 453 Label-to-FEC binding, 451 LAN extension, 351 Lasers, 713-714 Last all, 775 Latency, 536 low, in fiber channel SANs, 536 Layer(s), 21-24, 23f atomic functions in, 32, 32f collapsing, 35, 36f expanding, 35, 35f Layer 2 control protocols bridges vs. routers as CE in, 367 in Class of Service (CoS), 365-367 for Ethernet services over MEN, 365-367 handling of, 366 service features for, 365-367 Spanning Tree Protocol and, 421 Layer 2 Virtual Private Networks (L2VPNs), 425-426, 426f Layer 2 Virtual Private Networks (L2VPNs), over MPLS backbone, 428-435 attachment circuit (AC) in, 428 demultiplexer layer in, 430-431 encapsulation layer in, 429 forwarders in, 431-432, 432f fragmentation and reassembly in, 431 MPLS tunnels in, 434 MPLS tunnels in, carrying PWs over, 435,435f native service processing (NSP) in, 431 payload convergence in, 429 pseudowire (PW) in, 428-429, 429f pseudowire (PW) preprocessing in, service-specific, 431 sequencing fianctions in, 430 timing in, 430 VPN tunnels in, 433
Index hierarchical, 433-434 motivation for, 433 protocols for, 434 Layer 3 Virtual Private Networks (L3VPNs), 426 Layer Adjacency Discovery (LAD), 607-610, 608f, 609f Layer Adjacency Discovery Methods, 640-643, 641f protocol for (G.7714.1), 642-643 type 1 in, overhead in server layer, 641 type 2 in, test-signal method in, 641 Layer connection, in Printed Circuit Board (PCB) interconnects, 739-740, 740f Layer network connectionless, modeling, 60-61 in MEN, 334 Layer network model, in MEN, 327-329 application services layer (APP layer) in, 329 Ethernet Services Layer (ETH layer) in, 328 transport services layer (TRAN layer) in, 328-329 Layer planes, MEN, 337 Layer-specific characteristics, 625-626, 626t LCAS. See Link Capacity Adjustment Scheme (LCAS) LDP. See Label Distribution Protocol (LDP) Leased lines, virtual, GFP in, 185, 186f Least mean square (LMS) adaptation, 757 Legacy private line, 539, 542t Length/type field, of Ethernet media access control layer, 370 Limited protection path, 504 Linear extension header, 162 Line card integrated TDM/Packet, with different switch fabrics, 667, 667f using packet/cell switch fabric, 665, 665f using TDM switch fabric, 666, 666f Line/external timing method, 282 SONET/SDH and, 282-285, 283f threshold AIS generation and, 283 Line/external timing mode, SONET/SDH and, 259f, 260-261 Line terminating element (LTE), SONET/SDH and, 260-261, 263 Line timing, 474 from CE, 475f, 475t, 476 from MEN, 475f, 475t, 476 Link, 33 in MEN, 335, 340
Index Link aggregation, link protection based on, inMEF, 514-515, 515f Link Aggregation Control Protocol (LACP), 515 Link Aggregation Group (LAG), 514-515 Link attributes, 624, 624t Link availability, 625 Link capacity, 625 Link Capacity Adjustment Scheme (LCAS), 5, 8, 137, 317, 318f in Ethernet services over public WAN, 420 ITU-T recommendation G.7042A^.1305, 140, 141 Link Capacity Adjustment Scheme (LCAS), in multiplex structures, 140-143 details of, 141-142, 142f, 143f implementers guide for, 144-152 {See also under Multiplex structures, of OTN) link capacity decrease in planned, 140-141 temporary, 141 link capacity increase in, 140 Link Connection (LC), 33, 34f Link efficiency, in GFP, 182-184, 183f Link flow, 379 Link performer, 579 Link protection based on link aggregation, inMEF, 514-515, 515f Link redundancy, 514, 514f Link Resource Manager (LRM), 581-582, 581f, 606-607 Links, 28, 34, 507 Link scrambler, in GFP, 166 Link type, Ethernet Connection (EC) attributes and, 385-386 Link weight, 625 Local Area Network (LAN), transport over OTN in. See Multiplex structures, of OTN Local Area Network (LAN)-based VPN, virtual, 156 Local Area Network (LAN) storage, 529 Local client adaptations supported, 626 Local connection type, 625 Lock fast mode, 292 Lock-on time stabilization, 292 Lockout, in MEN, 501 Long-haul, 709, 710t Long haul core/backbone, 662, 662f Long-haul/long-reach, 709, 710t Longitudinal compatibility, 692
805 physical layer, 700-701 vs. transverse compatibility, 700-712 {See also Compatibility, transverse vs. longitudinal) Long-reach, 709, 7lot Loopbacks, 491-493, 493f customer-controlled, 492^93, 492f provider-controlled, 491, 492f Looping, in synchronization of status messages (SSM), 244-245 Loop/line timing mode, SONET/SDH and, 259f, 260 Loop timing mode, SONET/SDH and, 259f, 260 Lossless delivery, in fiber channel SANs, 537 Lower-Order Virtual Container (LOVC), 470 LSP switching, 646 M Mach Zehnder (MZ) modulators, 721 Main Path hiterfaces (MPI), 702, 702f Maintenance entity (ME), 416^17 Management, of optical transport networks, 10-11 Management plane, 337, 554 Management plane identifiers, 590f, 593 Management-related interfaces naming conventions for, 59 in termination sink fianction, 58-59, 60f Mandatory usage, 624, 624t Manual switch, in MEN, 501 Manufacturing variation, 739 Mapping. See also specific types asynchronous, 200-203 bit-synchronous, 201 in synchronization, 200-203 atUNI, 355, 356t Material loss, in Printed Circuit Board (PCB) interconnects, 739 Maximum Time Interval Error (MTIE), 210-211,213 definition of, 262 time-delay and, 262 Maximum Transmission Unit (MTU), 431 ME. See Maintenance entity (ME) Mean Time To Frame (MTTF), in GFP, 179-182, 180f, 181f Media access control layer, of Ethernet, 368-370. See also Ethernet media access control layer Media-Independent hiterface (XGMII), 759 MEF. See Metro Ethernet Forum (MEF)
806 MEF protection schemes, 521 Membership, ITU, 772 MEN. See Metro Ethernet Network (MEN) MEN-bound IWF, 472 MEN CES. See Metro Ethernet Network Circuit Emulation Services (MEN CES) Messages, in GMPLS RSVP-TE (G.7713.2) signaling, 647 Message set, in synchronization of status messages (SSM), 243-244, 243t Metro Area Network (Metro Core), 662, 662f transport over OTN in {See Multiplex structures, of OTN) Metro core/backbone, 662, 662f Metro Edge, 662, 662f Metro Ethernet Forum (MEF), 1 charter of, 325, 326f circuit emulation over, 9 network resiliency of, 9-10 Metro Ethernet Network (MEN), 323-325, 344 circuit emulation services in, 324-325 Ethernet services over, 7-8 network resiliency in, 323-324 traffic and performance management in, 324, 524-526, 525f transport services layer (TRAN layer) in, 328-329 VPLS for, importance of, 449-450, 450f Metro Ethernet Network (MEN) architecture, 326-341 components of, 334-337 processing, 336-337 topological, 334-335 transport, 335-336 layer network model for, 327-329 application services layer (AFP layer) in, 329 Ethernet Services Layer (ETH layer) in, 328 transport services layer (TRAN layer) in, 328-329 MEN layer relationship to architecture model components in, 337-341 MEN network reference model and topological components in, 338-339, 338f, 339f MEN reference link model in, 340, 34If operational planes and MEN layer networks in, 337 reference model for, 326-327, 326f reference points in, 329-333
Index definition and uses of, 329-330, 330f Ethernet Wide Area Network (E-WAN) in, 329 External Network-to-Network Interface (E-NNI) in, 329, 332 Internal Network-to-Network Interface (I-NNI) in, 329, 332 Network Interworking Network-to-Network Interface (NI-NNI) in, 329, 332-333 other access arrangements in, 333 Service Interworking Network-to-Network Interface (SI-NNI) in, 329, 333 Service Node Interface (SNI) in, 333, 334f User-Network Interface (UNI), 330-331, 331f Metro Ethernet Network (MEN)-bound Interworking Function (IWF), 472 Metro Ethernet Network Circuit Emulation Services (MEN CES), 9, 324-325, 457^96, 466-496. See also Metro Ethernet Network Circuit Emulation Services (MEN CES) alarms in for buffer underflow and overflow, 488-489 for structured service, 488 for unstructured service, 488 asynchronous IWF and asynchronous tributaries in, 477^78 asynchronous IWF and synchronous tributaries in, 478 CES Interworking Function in, synchronization description of, 475-477, 475f, 475t Circuit Emulation Interworking Function (CES IWF) in, 469 customer-operated, 465, 465f customer-operated CES in, 465, 465f definition of, 457 direction terminology of, 472 efficiency of, 496 Emulated Circuit Demultiplexing Function (ECDX) in, 471 end-to-end delay in, 489 Ethernet Flow Termination Function (EFT) in, 472 Facility Data Link (FDL) in, 487-488 general principles of, 466^67 loopbacks in, 491^93, 493f customer-controlled, 492-493, 492f
Index provider-controlled, 491, 492f mixed-mode, 465-466, 466f mixed-mode CES in, 465-466, 466f PDH Circuit Emulation Service in, 468t, 469, 470t protection in, 493-496 scenario 1: dual unprotected services, 493^94, 493f scenario 2: dual protected services, 494,494f scenario 3: single protected service, 494^95, 495f scenario 4: single-to-dual interface service, 495-496, 495f service impairment in, 489^90 bit errors in, 490 frame delay andframejitter in, 489^90 Frame Error Ratio and IWF behavior in, 490 frame loss in, 489 TDM, errors within MEN causing, 489^90 service interface types in, 467, 467f service quality in, 496 SONET/SDH Circuit Emulation Service in, 469-471, 470t,471f synchronization in, 472-475, 473f, 473t, 474t synchronized administration in, 478^87, 479t multi service-provider-owned network in, 480, 480t, 483-487, 483f, 484t separate and diverse, 479 service clock preservation in, 479 service timing-private network in, 480, 480t, 486t, 487 single service-provider-owned network in, 480-483, 480t, 481f, 481t synchronization traceability in, 479-480 synchronization trail in, 479 transport timing-private network in, 480, 480t, 486t, 487 synchronous IWF and asynchronous tributaries in, 477 synchronous IWF and synchronous tributaries in, 477 TDM Access Line Service (TALS) in, 463, 464f operational modes of, 464, 464f TDM line service (T-Line) in, 458^63 {See also TDM line service (T-Line)) TDM service interface examples in, 467-468, 468t
807 TDM Service Processor (TSP) in, 468-469 TDM signaling in, 490-491 Metro Ethernet Network (MEN) resiliency, 497-524 background on, 497-499 event timing in, 501-503, 503f failure types in, 500-501 framework for protection in, 521-524 aggregated line and node protection (ALNP) in, 522 background on, 521 MEF protection schemes in, 521 OA&M-based End-to-End Path Protection (EEPP) in, 522 packet 1+1 End-to-End Path Protection (EEPP) in, 523 shared mesh protection in, 523-524 Protection Reference Model (PRM) in, 505-516, 505f (&e also Protection Reference Model (PRM)) protection types in, 499-500 requirements for protection mechanisms in, 516-520 network-related, 517-520 {See also Network-related requirements, for MEN protection) service-related, 516-517 resource selection in, 501 shared-risk link group (SRLG) in, 503 SLS commitments in, 504 timing issues in, 504 Metro Ethernet services, 436, 437f VPLS importance in, 449^50, 450f Metro Ethernet services over MPLS, 437^49 E-LAN service emulation walk-through example in, 448-449, 448f emulation of E-LAN services using VPLS in, 443-447 avoiding VPLS forwarding loops in, 446 VPLS PW encapsulation in, 447 VPLS PW setup in, 447 VPLS reference model in, 443-446, 444f, 445f emulation of E-Line Services using VPWS in, 438-441 E-Line service emulation walk-through example in, 435f, 441-443, 443f Ethernet modes (raw vs. tag) in, 439 Ethernet PWs via LDP in, establishing, 440-441, 44If
Index VLAN tag processing in, 439-440 VPWS reference model in, 429f, 435f, 438, 439f Mid-span-meet, 693 Mixed mode service, 465 Mixing products, 704 m:n protection architecture, 300, 30If m:n protection type, 500 Monitoring, nonintrusive, 44 MP2MP protection, in MEF, 512-514, 512f, 514f MPLS. See Multiprotocol Label Switching (MPLS) MPLS control plane, 453-454 MPLS data plane (MDP), 399, 400f MPLS forwarding plane, 454 MPLS label stack, 451, 452f, 453f MPLS networks. See Multiprotocol Label Switching (MPLS) networks MPLS signaling protocols, 451 MPLS tunnels, 434 carrying PWs over, 435, 435f MTIE. See Maximum Time Interval Error (MTIE) Multicast service frame, 347-348 Multidomain path diversity, 632, 632f Multi-Frame Ahgnment Signal (MFAS) inOTUK, 100, lOlf in VCAT multiframe, 137, 139f Multi-Frame Indicator (MFI), 132 Multilayer survivability, 318-319 Multi-Longitudinal-Mode (MLM), 713 Multiplexed access, in Ethernet client interfaces, 402, 403f Multiplexing, in synchronization, 200-203 Multiplexing mode, 459, 460-461, 461f Multiplex Section (MS), SDH, 214 Multiplex Section overhead (MS-OH) overhead bytes in, 122f, 123 inSDHframe, 120, 121f Multiplex Structure Identifier (MSI) OPU 2, in 4 X ODUl to ODU2 multiplexing, 110-111, llOf, l l l f OPU3, in ODU1/ODU2 to ODU3 multiplexing, 115, 116f Multiplex structures, of OTN, 119-152 applications of, 119-120 bandwidth evolution in, 127-129, 127f-130f implementers guide for VCAT and LCAS in, 144-152 alignment within VCG in, 148-149
differential delay buffers in, overview of, 147 differential delay buffers in, sizing of, 149 differential delay buffers in, structure and management of, 146-147, 147t differential delay in, compensation of, 145-146 differential delay in, detection of, 144-145 distribution/reconstruction order in, controlling, 150-151, 151t member status in, 151-152 processing time in, 149-150 Link Capacity Adjustment Scheme (LCAS) in, 137, 140-143 details of, 141-142, 142f, 143f link capacity decrease in, planned, 140-141 link capacity decrease in, temporary, 141 link capacity increase in, 140 new clients in, 130-131, 130t Synchronous Digital Hierarchy (SDH) structure in, 120-127 overhead bytes in, 122-123, 122f overview of, 120-121, 121f pointers in, 123-125, 124f sub structuring in, 126-127 VC-n structure in, 125-126, 125f, 126f Virtual Concatenation (VCAT) in, 131-139 additional benefits of, 136 detailsof, 137, 138t, 139t differential delay in, 131-132, 132f origins and value of, 131 payload distribution and reconstruction in, 133-134, 133f, 134t, 135t restrictions of, 136-137 VCAT LCAS and GFP advantages in, 144 Multipoint-to-multipoint Ethernet services and, 382, 384f topology of network portion for, 384, 384f Multipoint-to-multipoint EVC, 351 Multiprotocol, 452 Multiprotocol Label Switching (MPLS) as CO-PS candidate, 399 data plane (MDP), 400, 400f, 40 It Multiprotocol Label Switching (MPLS) networks, 451-455 benefits of, 455
Index Ethernet services over, 9, 425-455 {See also Ethernet (Services), over MPLS networks) forwarding equivalence class in, 451 L2VPNs over {See Layer 2 Virtual Private Networks (L2VPNs), over MPLS backbone) label encoding in, 452, 453f label in, 451^52, 452f label stack operations in, 453 label switched path (LSP) in, 454, 455f label switched router (LSR) in, 453 Metro Ethernet services over {See Metro Ethernet services over MPLS) MPLS control plane in, 453-454 MPLS forwarding plane in, 454 Multiprotocol Label Switching (MPLS) tunnels, 434 carrying PWs over, 435, 435f Multiservice converged packet switched backbone, in VPN, 427 Multiservice optical transport network infrastructure, 3-6 data and TDM-friendly next-generation SONET/SDH in, 4-6 optical transport hierarchy in, 4 Multiservice platforms packet over SONET in, 273 timing distributor example of, 272, 272f TSWC01622 and, 272-273 Multi service-provider-owned network, in MEN CES, 480, 480t, 483-487, 483f, 484t service timing in, 483-485, 486t transport timing in, 485-487, 486f, 486t Multiservices Provisioning Platforms (MSPPs), 663-664 Multi-Source Agreement (MSA), 717 Multispan configuration, 702, 702f Multitier topologies, 601-602, 602f Mult timing method, 285-286, 285f N n: 1 protection type, 500 Name, 589, 590 Naming, in ASTN, 568-569 Narrowly spaced signals, 694 Native Service Processing (NSP), 431, 439 Near-end crosstalk (NEXT), 738 Negative justification, 201 Negative pointer adjustment, 204 Negative stuff, 201 Net coding gain (NCG). See Coding gain
809 Network. See also specific networks flexibility of, 33-34 Network Attached Storage (NAS), 529, 530f Network CaU Controller (NCC), 58If, 582, 584-585, 584f Network Call Correlation Information Element, 643 Network connection, 33, 34f Network connectivity, Ethernet Connection (EC) attributes and, 382-384, 383f, 384f Network Element (NE), 204, 507. See also Intra-Network Elements communications design and interface architecture in, 664-668 conceptual data processing partitioning within, 664-665, 664f hybrid (TDM + cell/packet based) architecture of, 667-668 packet based, 665-666, 665f TDM based, 666, 666f in MEN, 329 in SDH network, 136 Network Element (NE) architecture, 268-279 example of, 268-269, 268f large, 278-279, 279f medium, 277-278, 278f smaU, 276-277, 277f system architecture of, 275-276, 276f timing distributor (TD) fianctions in, 270-275, 272f, 274f application example of, 271, 272f fan-out in, 271 synchronization selection of, 271 synthesis in, 271 system block architecture of TSWC01622 and, 272, 272f timing engine (TE) fianctions in, 269-270 Network engineering, synchronization, 249-250 Networking. See also specific networks on processing efficiency with CPU cycles supporting backup and defragmentation, 529 on storage resource use, 528-529 Network Interworking Network-to-Network Interface (NI-NNI), in MEN, 329, 332-333 Network Management Systems (NMSs), 593 Network Processor (NP), 665
no Network protection, 295-296. See also Protection switching Network-related requirements, for MEN protection, 517-520 backward compatibility requirements in, 519 bidirectional switching in, 519 degrade condition threshold in, 517-518 effect on user traffic in, 520 network topology in, 520 protected failures in, 517 protection control requirements in, 518-519 protection schemes in, management requirements for, 520 QoS in, 520 robustness in, 519 transport layer protection mechanism interactions in, 518 Network resiliency in fiber channel SANs, 537 in MEN, 323-324 Network restoration. See Restoration, network Network survivability. See Survivability, network Network synchronization. See Synchronization Network-to-Network Interface (NNI), 8, 316, 317f, 375 Ethernet transport and, 405-411, 406f, 407f, 408f, 410f, 411f Network topology, in MEN protection, 520 New Data Flag (NDF), 123 Node, 507, 577. See also Network Element (NE) Node attributes, 623-624, 624t Node clock, 215 Node failure, 501 Node identification (node ID), 623 Noise clock, 207-208 phase, 207-209 Noise enhancement, 754, 755f Noise power (N), 738 Nonintrusive monitoring, 44 Non-retum-to-zero (NRZ), 191-192. See also NRZ entries Nonrevertive operation, 304 Nonservice delimiting, 439 No Request (NR), 311 Normal contributions, 773 Notify message, 629
Index NRZ1.25G, 706, 707t NRZ 2.5G, 706, 707t, 708 NRZ lOG, 706, 707t, 708t NRZ 40G, 706, 707t, 708t NRZ OTU3, 708t Null extension header, 162 Null signal, in protection switching, 310 O OAM. See Operations, Administration, and Management (OAM) OA&M-based End-to-End Path Protection (EEPP), in MEN, 522 OAM&P, 665 Observation time, in source traceability, 262 OC-192 System Packet Interface SPI-4 Phase 1, 674-677, 675f SPI-4 Phase 2, 679-681, 680f OC-768 System Packet hiterface, SPI-5, 685-687, 685f OChs. See Optical Channels (OChs) Octet slip, 234 ODCr jitter generation and transfer, 219-227 ODU. See Optical Channel Data Unit (ODU) layer network ODU1/ODU2 to ODU3 multiplexing, 112-116 structure in, 112, 113f ODUl to ODU2 justification rate, 105 ODUl to ODU 3 justification rate, 106-107 ODU2 links and subnetworks, OTN equipment for, 49-50, 49f, 50f ODU2 server trail, 47 ODU2 subnetwork, 4 7 ^ 9 , 47f-48f ODU2 to ODU 3 justification rate, 105-106 ODUk Clock (ODC), 214, 219 ODUK multiplexing, 104-116 4 X ODUl to ODU2 multiplexing in, 107-112 (&eafao ODUK multiplexing) 4 X ODUl to ODU2 justification structure in, 109, 109f, 109t frequency justification in, 111-112, 112t OPU 2 multiplex structure identifier (MSI) in, 110-111, 110f,lllf OPU2 payload structure identifier (PSI) in, 110 structure in, 107, 108f multiplexing data rates in ODUl to ODU2 justification rate in, 105
Index ODUl to ODU 3 justification rate in, 106-107 ODU2 to ODU 3 justification rate in, 105-106 ODU1/ODU2 to ODU3 multiplexing in, 112-116 frequency justification in, 115, 116t justification structure in, 114, 114t OPU3 multiplex structure identifier (MSI)in, 115, 116f OPU3 payload structure identifier (PSI) in, 114 structure in, 112, 113f OIF. See Optical Internetworking Forum (OIF) OIF SxI-5, 758 OIF TFI-5, 759 OMS. See Optical Multiplex Section (OMS) layer One-to-One Map, 352-354, 352f, 353f On-the-fiy restoration, 315 Open Shortest Path First (OSPF), 454 Operational aspects, of ASTN architecture, 559-562 Operational planes, MEN, 337 Operational Support System (OSS), 561 Operations, Administration, and Management (OAM) definition of, 378 domain service vs. network and, 413, 414f generic message format of, 418, 419f mapping maintenance entities to, 417, 418t point-to-point, Ethernet fiow reference modeland,414,415f,416f Operations, Administration, Management and Provisioning (OAM&P), 665 Operation types, in protection switching, 304 Optical Amplifier (OA), 695, 702, 702f Optical Channel Data Unit (ODU) layer network, 24 Optical Channels (OChs), 4, 23 Optical Channel Transport Unit (OTU) layer network, 24 Optical Cross-Connects (OXCs), 63 Optical faults, 728-732 in conventional transmitters and receivers, 728-731 faults in optically amplified systems, 731-732 Optical fibers, types and recommendations for, 703-705, 705t Optical interfaces, 12, 708, 708t
Ul Optical interface specification. See ITU-T standards, optical interface Optical interface standards, ITU-T. See ITU-T standards, optical interface Optical Internetworking Forum (OIF), 1, 317 Optical laser transmitter. See also ITU-T standards, optical interface Continuous Wave (CW), 715 electro-absorption/extemally modulated (EMLs), 715,721-722 Optical Multiplex Section (OMS) layer, 23, 77, 77f Optical Network Elements (ONEs), in physical layer transverse compatibility, 702-703 Optical path penalty, modeling and verification of, 711-712 Optical receiver. See ITU-T standards, optical interface Optical Signal-to-Noise Ratio (OSNR), 72-73, 73f, 732 measuring coding gain with, ll-Ti, 73f, 732 Optical Supervisory Channel (OSC), 570 Optical Transmission Section (OTS) layer, 23, 77, 77f Optical Transport Hierarchy (OTH), 4, 64 Optical Transport Network (OTN), 63 3R points in, 65, 65f architecture of, 23 hierarchy overview in, 64-66, 65f, 76-78, 76f-78f infrastructure of {See Infrastructure, optical transport network) layer network trails in, 76, 77f layers and containment relationships in, 76 in Recommendation G.805, ITU-T, 19 standards for, 64-66, 65f, 697-699 survivability of, 313, 314f Optimal path, 632 Option 1 networks, 217 Option 2 networks, 217 OPU 2 multiplex structure identifier (MSI), in 4 X ODUl to ODU2 multiplexing, 110-111, 110f,lllf OPU2 payload structure identifier (PSI), in 4 X ODUl to ODU2 multiplexing, 110 OPU3 multiplex structure identifier (MSI), in ODU1/ODU2 to ODU3 multiplexing, 115, 116f OPU3 payload structure identifier (PSI), in ODU1/ODU2 to ODU3 multiplexing, 114
\n OPUk frame structure, 82, 83f OPUk overhead, 83, 84t OSNR (Optical Signal-to-Noise Ratio), 72-73, 73f, 732 measuring coding gain with, 72-73, 73f, 732 OTH. See Optical Transport Hierarchy (OTH) OTM-n.m. server signal, STM-N client signal on, 37-38, 38f OTN. See Optical Transport Netvi^ork (OTN) OTN equipment, fijr ODU2 links and subnetworks, 49-50, 49f, 50f OTN mesh network, STM-64 switched connection services via, 45-49, 46f-48f OTS. See Optical Transmission Section (OTS) layer OTU. See Optical Channel Transport Unit (OTU) layer network OTUK frame structure, 98-99, 99f OTUk jitter accumulation, 219-227, 222f-225f OTUk jitter network limit and tolerance, 219-227 OTUK overhead and processing, 98-101 frame alignment overhead in, 100, lOOf, lOlf frame alignment signal (FAS) in, 100, lOOf multiframe alignment signal (MFAS) in, 100, lOlf OTUK frame structure in, 98-99, 99f scrambling in, 99-100, 99f Outgoing label, 451 Out-of-band approaches, 596-597 Ovenization, in holdover mode, 290 holdover value calculation and, 288 phase offset computation and, 288 Overhead, 120 Overhead area, in SDH frame, 120, 121f Overhead bytes, in SDH structure, 122-123, 122f OXCs. See Optical Cross-Connects (OXCs) Packet 1+1 End-to-End Path Protection (EEPP), in MEN, 523 Packet based Network Element, 665-666, 665f Packet/cell switch fabric, line card using, 665,665f Packet over SONET, 273 Packet rings, GFP in, 186, 186f
Index Packet switched network (PSN), 439 Packet switching overlay, for EoS, 397, 398f Packet transport, on public networks, GFP in, 155-156, 156f PAD field, of Ethernet media access control layer, 370 Parties, 560 Partitioning, 24-29, 25f, 26f See also Partitioning layering and, 27 link, 25-26, 26f parallel, 26, 26f recursive, 25, 25f serial and component, 26-27, 27f topology abstraction with, 27-29, 28f Path computation service approach, 622 Path diversity multidomain, 632, 632f simple, 631-632, 632f Payload area GFP, 160 inSDHframe, 120, 121f Payload convergence, in L2VPNs, 429 Payload distribution and reconstruction, in VCAT, 133-134, 133f, 134t, 135t Payload frame check sequence (FCS), GFP, 162 Payload header, GFP, 161 Payload information, GFP, 162 Payload Structure Identifier (PSI), 83, 120 OPU2, in 4 X ODUl to ODU2 multiplexing, 110 OPU3, in ODU1/ODU2 to ODU3 multiplexing, 114 Payload Type (PT), 83 PCB. See Printed circuit board (PCB) PDH. See Plesiochronous Digital Hierarchy (PDH) PDH Circuit Emulation Service, 468t, 469, 470t in MEN, 468t, 469, 470t PDH DS-3 client signal, on STM-N server, 36, 37f, 39-40 PDH generation networks, 551 PDU Length Indicator (PLI) field, 160 Peak-to-peak jitter, 209-210 Per Class of Service Identifier bandwidth profile, application of, 364, 364f Per EVC bandwidth profile, application of, 363, 364f Performance, in fiber channel SANs, 538 Performance management, in MEN, 324, 524-526, 525f
Index Performance monitoring, in MEN CES, 487^89 end-to-end delay in, 489 Facility Data Link (FDL) in, 487-488 Performance parameters, 53-54 Per ingress UNI bandwidth profile, 363-365 Periodic jitter (PJ), 745, 746 Permanent connection (PC), 555 Permanent Virtual Circuit (PVC), 395 Phase, 192 Phase error, instantaneous, 207 Phase-error fianction, 192 Phase noise, in synchronization, 207-209 Phase offset computation, in holdover mode, 288,291 Physical layer longitudinal compatibility, 700-701 Physical layer standards (PHYs), Ethernet, 760 Physical layer transverse compatibility, 701-703, 702f PICMG, 760 Plane, 552, 554 control and transport, separation of, 556-557 management, 554 transport, 554 Plenipotentiary Conference, ITU, 769 Plesiochronous Digital Hierarchy (PDH), 3, 63 standards for, 692-693 Plesiochronous operation, 238-239, 239t Plesiochronous timing, 267 PNNI signaling, G.7713.1, 643-644 Pointer, in SDH structure, 123-125, 124f Pointer adjustments, 203-205 isolated, 205 negative and positive, 204 Points, 31-32, 31f Point-to-multipoint, Ethernet services and, 382 Point-to-multipoint EVC, 367 Point-to-point Ethernet services and, 384 OAMand, 414,415f Point-to-point EVC frame delay performance objective and, 358-359 frame loss performance objective and, 359 Point-to-Point protocol (PPP), 452 Polarization Mode Dispersion (PMD), 704 Policy, in network protection, 498 Port controller, 580
U3 Positive justification, 201 Positive/negative/zero, 202 Positive pointer adjustment, 204 Positive stuff, 201 Power budget design optical path penalty modeling and verification in, 711-712 worst-case design approach to, 710-711 Power Spectral Density (PSD), 206, 207 PRC/PRS autonomy, 240-241, 240f Preamble field, 369 Pre-emphasis, 749 Premise (enterprise networks), 662, 662f Premium SLA, 465 Primary Reference Clock (PRC), 213, 215-216,217 Primary Reference Source (PRS), 217 Primary site. See Storage Area Networks (SANs); Storage networking Primitives, 580 Printed Circuit Board (PCB), 677 Printed Circuit Board (PCB) interconnects, 736, 738-742 environmental effects in, 740-742, 74If layer connection in, 739-740, 740f material loss in, 739 Printed Circuit Board (PCB) traces, 12 Priority-based switching, 241 Priority tagged, 349 Priority tagged frame, 371 Priority tagged service frame, 348 Private line, 380, 381f, 381t in all-to-one bundling map, 351 in Ethernet services over public WAN, 380 legacy, 539, 542t Private service, 380 Processing components, in MEN, 336-337 Propagation delay, 132, 132f Protected failures, in MEN, 517 Protection, network, 295-296 definition of, 593 in MEN, 497-599 {See also Metro Ethernet Network (MEN) resiliency) in MEN CES, 493^96 scenario 1: dual unprotected services, 493-494, 493f scenario 2: dual protected services, 494,494f scenario 3: single protected service, 494-495, 495f scenario 4: single-to-dual interface service, 495^96, 495f
U4 vs. restoration, 314 Protection control requirements, in MEN, 518-519 Protection path, 132, 132f Protection Reference Model (PRM), 505-516 MEF protection mechanism in, 507-516 aggregated line and node protection (ALNP) in, 508-509, 508f application protection constraint policy (APCP)in, 516 end-to-end path protection (EEPP) in, 509-511, 510f link protection based on link aggregation in, 514-515, 515f MP2MP protection in, 512-514, 512f, 514f topology in, 507 transport in, 506 use and structure of, 505, 505f Protection switching, 295-313, 420 architectures of, 297-303 1+1,298, 298f (1:1)°, 300, 302f l:n, 298-299, 299f m:n, 300, 301f ring, 302-303, 303f Automatic Protection Switching Protocol (APS) in, 310-312 APS signal in, 310-311 external commands in, 311 priority in, 312 process states in, 311 classes of, 306-309 subnetwork connection protection (SNC-P) in, 307-308, 308f, 309f trail protection in, 306, 307f unidirectional path switch ring (UPSR) in, 309 definition of, 295-296 examples of, 312-313 hold-off timer in, 309-310 network objectives in, 297 null signal in, 310 parameters of, 303-305 operation types in, 304 protocol types in, 304-305 switching types in, 303-304 temporal model in, 305, 306f Protection types, MEN, 499-500 1+1,499 1:1,500 l:n, 500
Index m:n, 500 n: 1,500 Protocol analysis, in ASTN, 637-640 approach to, 637-639, 638t requirements implications on protocol solutions in, 639-640 Protocol Controller (PC), 580, 581f, 582-583, 607 Protocol data unit (PDU), 154 Generic Framing Procedure (GFP) for with fixed-length PDUS, 157 with small, fixed-length PDUs, 157 with small PDUs, 157-158 with variable-length PDUs, 158 Protocol neutral, 634 Protocol rules, in synchronization of status messages (SSM), 244 Protocol types, in protection switching, 304-305 Provide Bridges, in future of Ethernet services, 367 Provider-controlled loopbacks, 491, 492f Provider Edge (PE), 525, 525f See also Ethernet (Services), over public WAN Provider provisioner VPN (PPVPN), 426^27, 427f Pseudowire (PW) establishing Ethernet, via LDP, 440^41, 441f in L2VPNS, 428-429, 429f over MPLS tunnels, 435, 435f VPLS PW encapsulation in MEN and, 447 VPLS PW setup in MENs and, 447 Pseudowire (PW) preprocessing, service-specific, 431 Public Switched Telephony Network (PSTN), 557-559 Public wide-area networks, Ethernet services over, 8-9 Pull-in range, 218 SEC and ODC, 218 Pull-out/hold-in ranges, SDH Equipment Clock (SEC) and ODUk Clock (ODC), 218 Pull-out range, 218 PW. See Pseudowire (PW) PW label, 435 PW-PDU, 429, 429f Q Q factor, 732 measuring coding gain with, 70-71, 7If, 72f
Index Quality, in synchronization areas, 237t, 239-240 Quality-based switching, 242 Quality of Service (QoS), 9, 11 in MEN protection, 520 VPN tunnels on, 433 Quasi-static, 218 Query, 629 Querylndication, 629 QueryRequest, 629 Questions, 771, 77If R R-1,516 R-2, 516 R-3, 516 R-4, 516-517 R-5, 517 R-6, 517 R-7, 517-518 R-8, 518 R-9, 519 R-10, 519 R-11,519 R-12, 519 R-13, 519 R-14, 520 R-15, 520 R-16, 520 R-17, 520 R-18, 520 R-19, 520 Radiocommunication Advisory Group (RAG), 769f, 770 Radiocommunication Assembly (RA), 769f, 770 Radiocommunication Sector (ITU-T), 769f, 770 Radiocommunication Standardization Bureau (BR), 769f, 770 Radio Regulations Board (RRB), 769, 769f, 770 RA identifier (RA ID), 620 Random jitter (RJ), 745 Random walk frequency modulation (RWFM), 209 Rapid spanning tree protocol (RSTP), 323-324 Rapporteur, 771-772, 771f RC identifier (RC ID), 620 Reachability information, 624 Reassembly, in L2VPNs, 431
U5 Receiver, equalization at, 754-756, 755f, 756f Recommendations. See ITU-T recommendations Recovery-point objective (RPO), 538-539 Recovery time, 504 Recovery-time objective (RTO), 538-539 Recovery time T5, 305, 306f Red bandwidth profile, 361-362, 361f Redundant Array of Independent Disks (RAID), in storage, 529, 530f Redundant service access, example of, 353f, 354 Reed-Solomon code, 68-70 Reference acceptance, 242 Reference duplication, 241-242 Reference link model, MEN, 340, 341f Reference Model for Open Distributed Processing (RM-ODP), 574-575 Reference points, 31 in ASTN, 562-564 in MEN, 329-333 definition and uses of, 329-330, 330f Ethernet Wide Area Network (E-WAN) in, 329 External Network-to-Network Interface (E-NNI) in, 329, 332 Internal Network-to-Network Interface (I-NNI) in, 329, 332 Network Interworking Network-to-Network Interface (NI-NNI) in, 329, 332-333 other access arrangements in, 333 Service Interworking Network-to-Network Interface (SI-NNI) in, 329, 333 Service Node Interface (SNI) in, 333, 334f User-Network Interface (UNI) in, 326-327, 330-331, 33If Reference selection, 241-242 Regenerator Section overhead (RS-OH) overhead bytes in, 122f, 123 inSDHfi-ame, 120, 121f Regenerator section (RS), 214 Regular clock, 202 Releaselndication message, 629 ReleaseRequest message, 629 Rerouting, 571 Rerouting domain model, G.8080, 594, 594f Resilience, network in fiber channel SANs, 537 in MEN, 323-324
U6 Resource class, 625 Resource Reservation Protocol (RSVP), 434 Resource selection, in MEN, 501 Restoration, network, 296, 314-317 advantages of, 314 definition of, 296, 593 interoperability in, 316-317 ITU recommendations on, 314-315 in network protection, 498 on-the-fly, 315 preplanned routing with centralized route calculations in, 315 vs. protection, 314 restoration time in, 315-316 techniques of, 315 Restoration architecture, in G.8080, 593-595,594f Restoration time categories, for Ethernet services protection, 516-517 ResvTear/RevErr, in GMPLS RSVP-TE (G.7713.2) signaling, 647 Retiming, in synchronization architectures for SONET/SDH, 270 Reversion, in MEN, 503 Reversion instant, in MEN, 502 Revertive mode, in MEN, 501 Revertive operation, 304 Ring extension header, 162 Ring network, SSM-based restoration in, 245-246, 246f, 247f Ring protection architecture, 302-303, 303f Ring protection schemes, SONET/SDH, 41-42,41f, 42f Ring topology, in SONET/SDH, 4 0 ^ 3 , 41f-43f RMS jitter, 209-210 Robustness, in MEN protection, 519 Routing, in ASON (G.7715 and G.7715.1), 611-626 architecture of, 615-619, 616f-618f hierarchy in, 619-621, 620f information exchange in, 621-626 {See also Routing information exchange) methods and protocols of, 651-652 requirements for, 611-614 architectural, 612-613, 612f, 613f protocol in, 613-614, 614f, 615f Routing, in ASTN, 568 Routing adjacency, 615, 616f Routing Area (RA), 577, 615-618, 616f-618f Routing Controller (RC), 581, 581f Routing control topology, 615
Index Routing information exchange, 621-626 fiandamentals of, 621-623 general attributes of, 623 layer-specific characteristics in, 625-626, 626t link attributes of, 624, 624t node attributes of, 623-624, 624t Routing performer (RP), 615, 616f 3R points, 65, 65f RSVP session, 646 RZ 40G, 706, 707t, 708t
SI and ESF SSMs, translation between, 284t, 285 SAN. See Storage Area Networks (SANs) SAN islands, 532-534 SAN protocol. See Storage Area Networks (SANs) Satellite timing, in synchronization of optical networks, 248-249 Scalability, network, in fiber channel SANs, 538 Scrambler options, in GFP, 172-174, 173f, 173t Scrambler resynchronization delay, in GFP, 182 Scrambling inOTUK, 99-100, 99f of SDH/SONET frame, 122 SCSI (Small Computer Systems Interface), 530, 531t SDH, 3, 63 in Recommendation G.805, ITU-T, 19 SDH Equipment Clock (SEC), 214 SDH Equipment Clock (SEC) and ODUk Clock (ODC) frequency accuracy and clock modes, 218-219 SDH Equipment Clock (SEC) and ODUk Clock (ODC) puU-in and pull-out/hold-in ranges, 218 SDH generation networks, 551 SDH Multiplex Section Shared Protection Rings (MS-SPRING), 303, 303f SDH structures, 120-127 multiplex, 128-129, 129f overhead bytes in, 122-123, 122f overview of, 120-121, 121f pointers in, 123-125, 124f sub structuring in, 126-127 VC-n structure in, 125-126, 125f, 126f Secondary site. See Storage Area Networks (SANs); Storage networking
Index Section monitoring byte descriptions, in OTNs, 101-104 backward defect indication (BDI) in, 102-103 backward error indication and backward incoming alignment error (BEI/BIAE) in, 103, 103t Bit Interleaved Parity (BIP-8) in, 83f, 101 incoming alignment error (lAE) in, 104 Trail Trace Identifier (TTI) in, 77f, 101, 102f Selection, in synchronization of status messages (SSM), 244 Selector connection fionction, 44 Separation, of control and transport planes, 556-557 Sequence diagrams, 587 Sequence Number (SQ), 133 Sequencing functions, in L2VPN over MPLS backbone, 430 SERDES (Serializer/Deserializer), 12, 76-77, 665,735 SERDES Framer Interface-5 (SFI-5), 682-685 signals in, receive direction, 682-684 signals in, transmit direction, 682-685 SERDES-Framer interface (SFI-5), 758 SERDES integrated circuits, in 300-pin transponder, 722 Serial interconnects, high-speed, 12-13, 735-764 architecture of, 737-742 Printed Circuit Board (PCB) interconnects in, 738-742 {See also Printed Circuit Board (PCB) interconnects) topologies of, Til-IT)^ background on, 735 backplane interconnect in, 736 chip-chip interconnect in, 736 compliance test methodology for, l'M-l'\^ bathtub curve analysis of jitter in, 746-748, 747f eye mask in, 742-744, 743f jitter modeling conventions in, 744-746 (See also Jitter) higher and higher speeds for, 762-764 interconnect extension using de-emphasis and equalization in, 748-757 de-emphasis at transmitter in, 749-753, 750f, 751f,753f equalization at receiver in, 754-756, 755f, 756f
111 usage models in, 756-757 standards-based, 758-762 Backplane Ethernet in, 760 IEEE® 802.3aeTM Clause 47,XAUI in, 759-760 OIF SxI-5 in, 758 OIF TFI-5 in, 759 summary of, 760-761, 76 It, 762t Serializer/Deserializer (SERDES). See SERDES Service activation process elements, in ASTN, 603-604 Service (call) perspective, 562 Service Capability Exchange (SCE), 610-611 Service clock, 258-259 Service clock preservation, in MEN CES, 479 Service configuration requirements, for Ethernet services protection, 516 Service Connectivity, in VPNs, 426 Service delimiting, 439 Service frame broadcast, 347-348 delivery transparency in, 345 egress, 345 error detection in, 346 in Ethernet over MEN, 345 format of, 345-346 ingress, 345, 363, 363f in MEN, 526 multicast, 347-348 priority tagged, 348 unicast, 346-349 (See also Unicast service frame) untagged, 348 Service impairment, in MEN CES, 489-490 bit errors in, 490 frame delay and frame jitter in, 489^90 Frame Error Ratio and IWF behavior in, 490 frame loss in, 489 TDM, from errors within MEN, 489-490 Service interface types, in MEN CES, 467, 467f Service Interworking Network-to-Network hiterface (SI-NNI), in MEN, 329, 333 Service Layer, in VPNs, 426 Service Level Agreement (SLA), 8, 9, 374, 561 in Ethernet Private Line (EPL) service, 387 network protection in, 497
U8 of storage network extension, 546, 547t Service Level Specification (SLS), 324 network protection in, 497-498 Service multiplexing, 352-355 bundling map in, 354-355, 354f in Ethernet services MEN, 352-367 one-to one map in, 352-354, 352f, 353f Service Node Interface (SNI), in MEN, 333, 334f Service provider networks, connectionless networks, 19 Service quality, in MEN CES, 496 Service-related requirements, for MEN protection, 516-517 Services model, for EVC identification at UNI. See Ethernet Virtual Connection (EVC), identification at UNI of Service-specific PW preprocessing, 431 Service timing in multi service-provider-owned network, 483^85, 486t in private network, 480, 480t, 486t, 487 in single service network, 482 Session paradigm, in GMPLS RSVP-TE (G.7713.2) signaling, 648 SetupConfirm message, 628 Setuplndication message, 628 Severely Errored Seconds (SES), 304 SF14 specification, 722 SFI-5 (SERDES Framer hiterface-5), 682-685, 758 signals in, receive direction, 682-684 signals in, transmit direction, 684-685 Shared medium, 367 Shared mesh protection, MEN, 523-524 Shared redundancy, in MEF protection, 511 Shared-risk link group (SRLG), in MEN, 503 Short-haul, 709, 7lot Short-haul/intermediate-reach, 709, 710t Signal, 738 in links, 625 narrowly spaced, 694 widely spaced, 696 Signal classes, overview of, 706, 707t Signal class NRZ 1.25G, 706, 707t Signal class NRZ 2.5G, 706, 707t, 708 Signal class NRZ lOG, 706, 707t, 708t Signal class NRZ 40G, 706, 707t, 708t Signal class NRZ OTU3, 708t Signal class RZ 40G, 706, 707t, 708t Signal Degrade (SD), 304, 310 SignalFail(SF), 304, 310 Signaling, in ASTN, 568
Index Signaling attributes, 630, 63 It Signaling Communications Network (SCN) architecture (G.7712), 595-603 background on, 595-596 control plane message delivery in, 597-599, 598f DCN reliability considerations in, 602-603 DCN security considerations in, 603 DCN topologies in, 599-602 congruent, 600, 600f focused (hub and spoke), 600-601, 601f fuUmesh, 599, 599f hybrid (multitier), 601-602, 602f mechanisms of, 652-653, 653f signaling methods in in-band, 596 out-of-band, 596-597 Signaling control domains, in GMPLS RSVP-TE (G.7713.2) signaling, 646 Signaling (G.7713), in ASON, 626-633 application example of, 631-633, 632f attributesof, 630, 631t background on, 626-627 call and connection control sequences in, basic, 628-629, 629f call and connection management operations in, 627-628, 627f methods and protocols for, 643-651 G.7713.1 PNNI signaling in, 643-644 G.7713.2 GMPLS RSVP-TE signaling in, 644-648 {See also GMPLS RSVP-TE (G.7713.2) signaling) G.7713.3 GMPLS CR-LDP in, 648-649 interoperability and interworking in, 649-651 Signaling methods, in Signal Communications Network architecture (G.7712) in-band, 596 out-of-band, 596-597 Significant instant, 192 Simple path diversity, 631-632, 632f Single protected service, in MEN CES, 494^95, 495f Single service-provider-owned network, in MEN CES, 480-483, 480t, 481f, 481t service timing in, 482 transport timing in, 487^88 Single-to-dual interface service, in MEN CES, 495-496, 495f Sinusoidal jitter, 196 SLA. See Service Level Agreement (SLA)
Index Slip, 212 (controlled) octet, 234 controlled vi. uncontrolled, 212 SLS commitments, in MEN, 504 SLS restoration instant, in MEN, 502, 503f SLS restoration time, in MEN, 503, 503f Small Computer Systems Interface (SCSI), 530, 531t Small Form-Factor Pluggable (SFP) devices, 718-719, 719f Small Form Factor (SFF) devices, 717-718, 717f SNPP identifiers, 590-591 Soft link failure, 500 Soft Permanent Connection (SPC), 556, 556f SONET, 3, 63 capabilities of, 542-543 data growth and, 527-528 as ideal distance extension protocol, 542-547, 542t, 543f for Storage Area Networks (SANs), 531-548, 532f (&e also Storage Area Networks (SANs), SONET for) storage area services over, 10 storage networking and, 528-531, 530f, 53It {See also Storage networking) for voice communication, 542 SONET, as distance extension protocol, 542-547, 542t, 543f additional benefits of, 546-547, 547t capabilities of, 542-543 in SAN extension application, 543, 543f Service Level Agreement (SLA) for, 546, 547t standards in, 544-547 flow control in, 545 Generic Framing Procedure (GFP) in, 544 Virtual Concatenation (VC) in, 544-545 SONET Minimum Clock (SMC), 214, 272 SONET multiplex structures, 129 SONET/SDH data- and TDM-friendly next-generation, 4-6 Inter-Data-Center connectivity based on, 543,543f physical layer transport for EoS and, 397, 397f ring topology in, 40-43, 41f-43f standards for, 693-695 for Storage Area Networks (SANs), 539, 541-542,542t storage over, 541-542, 542t
U9 SONET/SDH Circuit Emulation Service, 469-471, 470t,471f in MEN, 469^71, 470t, 471f SONET/SDH frequency traceable clock distribution, 267, 267f Source address field, of Ethernet media access control layer, 369 Source traceability, 262-265, 262f, 263f clock distribution of, 266, 266f frequency relationship in, 263, 263f timing loop and, 264, 264f observation time and, 262 timing loops in, 264, 264f wander region in, 262 Spanning Tree Protocol (STP), 323, 366, 366f in Ethernet services over public WAN, 421 Layer 2 control protocol and, 421 Spanning Tree Protocol (STP)-BDUs, 513 Spanning tree topology, 249 Specification, optical interface. See ITU-T standards, optical interface SPI-3 signal descriptions, 669-672 receive direction in clock and data signals, 671 discrete control/status signals, 671-672 transmit direction in clock and data signals, 669 discrete control/status signals, 669-671 SPI-4 Phase 1, 674-677, 675f SPI-4 Phase 2, 679-681, 680f SPI-5, 758 OC-768 System Packet Interface, 685-687, 685f Split-horizon bridging, 512-513, 512f SSM (Synchronization Status Message), 218,261 Standardized interfaces, 66-67, 67f ITU-T, optical interface, 691-733 {See also ITU-T standards, optical interface) Standards ITU-T, 64 {See also ITU-T recommendations; ITU-T standards, optical interface) layer 1, 64-66, 65f optical network, 64-66, 65f Standards development process, 13, IGl-l^Ti approval of recommendations in, IIA-IIS background on, 161-16^ contributions and other input documents in, 773-774
820 history of, 119-1W industry forums in, 776-783 elections/hierarchy in, 111-119, llli human nature and, 781-782 membership in, 780-781 message in, 776 reasons for joining, 779-780 teamwork in, 782-783 International Telecommunication Union (ITU) in, 768-775 {See also International Telecommunication Union (ITU)) meetings in, 112-11?) Standard Single-Mode Fiber (SMF, SSMF), 703-704 Start frame delimiter field, of Ethernet media access control layer, 369 Star topology, 737 Steady-state call, 645 STM-1, 708t STM-4, 708t STM-16, 708t STM-64, 708t STM-64 switched connection services, via OTN mesh network, 4 5 ^ 9 , 46f-48f STM-N client signal, on OTM-n.m. server signal, 37, 38f STM-N jitter accumulation, 219-227, 222f-225f STM-N jitter network limit and tolerance, 219-227 STM-N regeneration, 219-227 STM-N server, PDH DS-3 chent signal on, 36, 37f, 39-40 STM-N structure, 127-128, 127f Storage, over IP, 539, 540-541, 540f, 542t Storage Area Networks (SANs), 5, 661 transport over OTN in {See Multiplex structures, of OTN) Storage Area Networks (SANs), SONET for, 10, 531-548, 532f distance extension alternatives in, 538-541 legacy private line in, 539, 542t SONET/SDH, 541-542, 542t storage over IP in, 540-541, 540f, 542t WDM in, 539-540, 542t as distance extension protocol, 542-547, 542t, 543f additional benefits of, 546-547, 547t capabilities of, 542-543 in SAN extension application, 543, 543f Service Level Agreement (SLA) for, 546, 547t
Index standards in, 544-547 flow control in, 545 Generic Framing Procedure (GFP) in, 544 Virtual Concatenation (VC) in, 544-545 distance extension requirements in, 536-538 carrier grade in, 537-538 in-order delivery in, 536 lossless delivery in, 537 low latency in, 536 network flexibility and resilience in, 537 scalability and performance in, 538 throughput in, 537 ERP and CRM applications in, 531-532 factors driving extension of, 532-534 fiber channels in, 534-535, 534f, 535f structure of, 532, 532f use of, 531 Storage arrays, 528 Storage networking, 528-531. See also specific types approaches to, 529-531, 530f, 531t benefits of, 528 example of, 528-529 processing efficiency with, 529 Stratum 2 holdover transient vs. seconds, at DSl interfaces, 288, 289t Stratum 3/3E holdover transient vs. seconds, at DSl interfaces, 288, 289t Stratum levels, hierarchy of, 257 Structure-agnostic emulation, 459 Structure-aware emulation, 459 Structured emulation mode, 459, 460 Structured service, alarm for, in MEN CES, 488 Study groups, 771, 77If contributions and other input documents for, 773-774 meetings of, 772-773 Stuff control, 201 Subnetwork, 24-25, 28, 31, 33, 335, 564 in MEN, 335 RA and, 577 Subnetwork connection protection (SNC-P), 307-308, 308f, 309f Subnetwork connection (SNC), 31, 33, 34f Subnetwork performer, 579 Subnetwork Point Pool (SNPP), 590-591 Subscriber/customer equipment, 327
Index Substructuring, in SDH VC-n structures, 126-127 Superblock, 169f, 170 Super frame (SF), 261 Super-rate signals, 127 Survivability, network, 295-319 definition of, 295 Link Capacity Adjustment Scheme (LCAS)in, 317, 318f multilayer, 318-319 network protection in, 295-313 {See also Protection switching) network restoration in, 314-317 advantages of, 314 definition of, 296 interoperability in, 316-317, 317f ITU recommendations on, 314-315 vs. protection, 314 restoration time in, 315-316 techniques of, 315 in optical transport networks, 313, 314f in transport networks, 6-7 Survivability, transport network, support for, in ASTN architecture, 571 Switched connection service, 552, 555, 556f Switched Connections (SCs), 570 Switch fabrics different, 667, 667f packet/cell, 665, 665f TDM, 666, 666f TDM/Packet, 667, 667f Switching bidirectional, 304 priority-based, 241 protection {See Protection switching) quality-based, 242 unidirectional, 303 Switching operation time T3, 305, 306f Switching time, 296 Switching transfer time T4, 305, 306f Switching types, in protection switching, 303-304 Switch initiation, 296 SxI-5, 758 Synchronization, 189-252 alignment jitter in, 195 closing remarks on, 251-252 digital transmission in, 191-194, 193f, 194f ITU-T recommendations on timing and jitter for OTN, SDH, and PDH and, 214-216, 215t jeditterizer in, 196
821 jitter generation in, 199-200 jitter tolerance in, 196-198, 198f mapping and multiplexing in, 200-203 in MEN CES, 472-475, 473f, 473t, 474t network engineering in, 249-250 pointer adjustments in, 203-205 priority-based switching in, 241 quality-based switching in, 242 reference acceptance in, 242 reference duplication and reference selection in, 241-242 reliable distribution of, 233-250 need in, 234-235, 234t synchronization areas in, 235-241 {See also Synchronization areas) satellite timing in, 248-249 sinusoidal jitter in, 196 synchronization network engineering and, 189-191 Synchronization Status Messages (SSM) in, 243-247 manual SSM assignment in, 245 message set in, 243-244, 243t SSM based restoration applied in a ring network in, 245-246, 246f, 247f SSM forwarding in, 244 SSM looping in, 244-245 SSM protocol rules in, 244 SSM selection in, 244 timing and jitter requirements for SONET/SDH and OTN in, 216-233 history and background on, 216-218 jitter and wander accumulation for PDH clients of SONET/SDH networks in, 227-231 jitter and wander accumulation for SDH clients of OTN in, 231-233 SEC and ODC frequency accuracy and clock modes in, 218-219 SEC and ODC pull-in and pull-out/hold-in ranges for, 218 STM-N and OTUk jitter accumulation in, 219-227, 222f-225f STM-N and OTUk jitter network limit and tolerance in, 219-227 STM-N regeneration and ODCr jitter generation and transfer in, 219-227 timing jitter in, 195, 200 timing performance characterization in, 209-212 Maximum Time Interval Error (MTIE) in, 210-211,213
822 peak-to-peak and RMS jitter in, 209-210 time variance (TVAR) and time deviation (TDEV) in, 211-212, 213 timing signal imperfections in, 206-209 fimdamentals of, 206-207 phase noise in, 207-209 transfer, generation, and network limit in, 196-200,198f, 199f wander network limits and wander performance in, 212-213 Synchronization architectures, for SONET/SDH, 257-293 bit recovery in, 258 clock backup modes, implications of, 286-292, 289t {See also Holdover mode) clock recovery in, 270 concepts of, 257-261, 258f, 259f Department of Defense (DOD) and, 267 distribution in, 266-268, 266f, 267f, 270 plesiochronous timing and, 267 external timing configurations in, 279-286, 284t bridged-source timing method and, 281-282,281f direct-source timing method and, 280, 280f line/external timing method and, 282-285,283f mult timing method and, 285-286, 285f external timing mode in. Global Positioning System (GPS) and, 260 guidelines for, 292-293 network element (NE) architecture in, 268-279, 268f, 216f{See also Network element (NE) architecture) clock routing in, 275, 276f example of, 268-269, 268f large, 278-279, 279f medium, 277-278, 278f small, 276-277, 277f system architecture of, 275-276, 276f timing distributor (TD) fianctions in, 270-275, 272f, 274f (&e also Timing distributor (TD) functions) timing engine (TE) fianctions in, 269-270 retiming and, 270 timing loops in, 258 timing recovery and, 258, 258f timing traceability in, 261-265
Index definition of, 261 source traceability in, 262-265 TSWC01622in, 272, 272f Synchronization areas, 235-241 definitions of, 235, 238 PRC/PRS autonomy in, 240-241, 240f synchronization reference chains in, 235-238, 237t synchronous and plesiochronous operation in, 238-239, 239t traceability and quality in, 237t, 239-240 Synchronization domain (SD), 475f, 475t Synchronization network, current, 249 Synchronization network engineering, 189-191 short history of, 190-191 Synchronization plan, 250 Synchronization protection, requirements for, 249 Synchronization reference chain, 235-238, 237t Synchronization Status Message (SSM), 218,261 Synchronization Supply Unit (SSU), 215, 260 Synchronization traceability, in MEN CES, 479-480 Synchronization trail, in MEN CES, 479 Synchronized administration, in MEN CES, 478^87, 479t multi service-provider-owned network in, 480, 480t, 483^87, 483f, 484t separate and diverse, 479 service clock preservation in, 479 service timing-private network in, 480, 480t, 486t, 487 single service-provider-owned network in, 480^83, 480t, 481f, 481t synchronization traceability in, 479-480 synchronization trail in, 479 transport timing-private network in, 480, 480t, 486t, 487 Synchronizer, 201 Synchronous Digital Hierarchy (SDH). See SDH synchronization in {See Synchronization architectures, for SONET/SDH) Synchronous IWF asynchronous tributaries and, 477 synchronous tributaries and, 477 Synchronous operation, 238-239, 239t Synchronous Optical Network (SONET). See SONET
Index synchronization in {See Synchronization architectures, for SONET/SDH) Synchronous Payload Envelope (SPE), 470 inSDHframe, 120, 121f System Framer Interface-4 phase 1 (SFI-4 Phase 1), 672-674, 673f phase 2 (SFI-4 Phase 2), 677-679, 678f System Packet hiterface (SPI), OC-192 SPI-4 Phase 1, 674-677, 675f SPI-4 Phase 2, 679-681, 680f System Packet Interface-3 (SPI-3) signal descriptions, 669-672. See also SPI-3 signal descriptions System Packet Interface-5 (SPI-5), 758
Tag, for CO-PS network, 396 Tandem Connection Monitoring (TCM), 4, 73-75, 74f, 75f in OTNs, 73-75, 74f, 75f TDEV. See Time deviation (TDEV) TDM, 3 for T-line over MEN, 462 TDM Access Line Service (TALS), 463, 464f operational modes of, 464, 464f TDM based Network Element, 666, 666f TDM Fabric to Framer Interface, 687-688, 688f TDM-friendly next-generation SONET/SDH, 4-6 TDM line service (T-Line), over Metro Ethernet Networks, 458^63, 458f bandwidth provisioning for, 461-462, 463f bandwidth allocation at 100 kbits/s granularity in, 462 Ethernet multiplexing in, 462, 463f TDM multiplexing in, 462 definition and use of, 458 operational modes of, 459^61, 459f multiplexing, 459, 460-461, 461f structured emulation in, 459, 460 unstructured emulation in, 459, 460 TDM Line timing, 475f, 475t TDM service interface examples, in MEN CES, 467-468, 468t TDM Service Processor (TSP), in MEN CES, 468^69 TDM Service Processor (TSP) block, 458 TDM signaling, in MEN CES, 490^91 TDM switch fabric, line card using, 666, 666f
823 TDM systems, 190 Telecommunication Development Advisory Group (TDAG), 769f, 771 Telecommunication Development Bureau (BDT), 769f, 770 Telecommunication Development Sector (ITU-D), 769f, 770 Telecommunication Management Network (TMN) Recommendations, 574 Telecommunication Standardization Advisory Group (TSAG), 769f, 770-771 Telecommunication Standardization Bureau (TSB), 769f, 770 Telecommunication Standardization Sector (ITU-T), 769f, 770 TeleManagement Forum (TMF), 1 Temperature compensation, in holdover mode, 290 Temporal model, protection switching in, 305, 306f Temporary Document, 774 Termination and Adaptation Performer (TAP), 581f, 583, 606 Termination connection point (TCP), 32 Termination flow point (TFP), for Ethernet service, 414^15 Termination fionction, 30, 30f, 32, 32f. See also Ethernet (Services), over public WAN expansion of, 35, 35f in MEN, 336-337 Termination sink fionction, management-related interfaces in, 58-59,60f TFI-5 (TDM Fabric to Framer Interface), 687-688, 688f Thermo-Electric Cooler (TEC), 713-714 Threshold AIS generation, 283 DSland,283 line/external timing method and, 283 Throughput, in fiber channel SANs, 537 Through timing mode, SONET/SDH and, 259f, 260 Time-delay, Maximum Time Interval Error (MTIE) and, 262 Time deviation (TDEV), 211-212, 213 traceability and, 262 Time Division Multiplexing (TDM). See TDM Time interval error (TIE), frequency traceability and, 264 Timer, hold-off, 309-310
824 Times, 501 Time variance (TVAR), 211-212 Timing in global optical transport network, 6-7 ITU-T recommendations on, for OTN, SDH, and PDH, 214-216, 215t in L2VPN over MPLS backbone, 430 in MEN issues with, 504 relationships in, 503, 503f of performance characterization, 209-212 Maximum Time Interval Error (MTIE) in, 210-211 peak-to-peak and RMS jitter in, 209-210 time variance (TVAR) and time deviation (TDEV) in, 211-212 satellite, in synchronization of optical networks, 248-249 service in multi service-provider-owned network, 483^85, 486t in private network, 480, 480t, 486t, 487 in single service network, 482 sources for, 259-261, 259f transport in multi service-provider-owned network, 485^87, 486f, 486t in private network, 480, 480t, 486t, 487 in single service network, 487-488 Timing configurations, external, in SONET/SDH, 279-286, 284t bridged-source timing method and, 281-282, 281f direct-source timing method and, 280, 280f line/external timing method and, 282-285,283f mult timing method and, 285-286, 285f Timing connections, Ultramapper^M vs. TSWC01622,273, 274f Timing distributor (TD) functions, 270-275, 272f, 274f application example of, 271, 272f fan-out of, 271 synchronization selection of, 271 synthesis of, 271 system block architecture of TSWC01622 and, 272, 272f Timing engine (TE) fianctions synchronization distribution and, 270 timing reference and, 270 clock recovery and, 270
Index Timing jitter, 195,200 Timing loops, 249 in frequency traceability, 265 in source traceability, 264, 264f in synchronization architectures for SONET/SDH, 258 Timing modes, SONET/SDH Network Element (NE) and, 259, 259f Timing recovery, synchronization and, 258, 25 8f Timing traceability, 261-265 definition of, 261 source traceability in, 262-265 TMF. See TeleManagement Forum (TMF) Topological components definition of, 379 in MEN, 334-335, 338-339, 338f, 339f Topology, 20, 382, 382f. See also specific topologies backplane, 737-738 EPLAN and, 389, 390f of network portion, multipoint-to-multipoint, 384, 384f Total cost of ownership (TCO), 533 Traceability frequency, 261-265 {See also Frequency traceability) observation time and, 262 source, 262-265 {See also Source traceability) synchronization, in MEN CES, 479-480 in synchronization areas, 239 time deviation (TDEV) and, 262 timing, 261-265 {See also Timing traceability) Traditional Approval Process (TAP), 774 Traffic Descriptors Information Element, 644 Traffic engineered LSP, 454 Traffic management, in MEN, 324, 524-526, 525f Traffic Manager (TM), 665 Traffic Pohcing (TP), 583 Trail, 33, 34f in MEN, 335 Trail protection, 306, 307f Trail signal fail (TSF) signals, 44 Trail Termination Function (TTF), 30, 30f fault and performance processes in, 56, 56f in MP2MP protection, 512-514, 514f Trail Termination Point, in MEN, 335-336 Trail Trace Identifier (TTI), 92 in G.709 overhead bytes, 89, 89t
Index inOTUK, 77f, 101,102f TRAN layer, 328-329 in MEN, 328-329 TRAN link, in MEN, 340, 341f Transceiver transponder. See Transponders Transient behavior, 645 Transmission control protocol (TCP), 540, 540f Transmission delay, 296 Transmitter, de-emphasis at, 749-753, 750f, 751f, 753f Transparent LAN service, 350 Transparent-mapped mode (GFP-T), in GFP, 167-168, 168f Transponders 2.5 Gbit/s, 720-721 200-pin, 724-725 300-pin, 722-724, 723f in SERDES integrated circuits, 722 Very Short Reach (VSR), 724 Transport, 498 Transport capabilities. See Multiplex structures, of OTN Transport Capability Exchange (TCE), 610 Transport component (transport entity), in MEN, 335-336 Transport Connection Functions (TCFs), 507 Transported payload capabilities. See Multiplex structures, of OTN Transport fionctional modeling. See Functional modeling, transport Transport layer protection mechanisms interactions, in MEN, 518 Transport network models, supporting Ethernet connectivity services. See Ethernet connectivity services, transport models supporting Transport networks, 498 automatically switched {See Automatically Switched Transport Network (ASTN) architecture) Transport network survivability, 6-7 Transport plane, 554 Transport resource identifiers, 590-591, 590f, 592f Transport resource management, in ASTN, 569 Transport services layer (TRAN layer), 328-329 in MEN, 328-329 Transport timing in multi service-provider-owned network, 485-487, 486f, 486t
825 in private network, 480, 480t, 486t, 487 in single service network, 487-488 Transverse compatibility, 693-694 vs. longitudinal compatibility, 700-712 {See also Compatibility, transverse vs. longitudinal) physical layer, 701-703, 702f Tributary Unit Groups (TUG), in SDH VC-n structures, 126-127 Tributary Unit (TU), 127 Trunk link, in MEN, 340, 341f TSWCO1622, 272-273 of Agere Systems, 272 in synchronization architectures for SONET/SDH, 272-273, 272f, 275 in timing distributor (TD) fionctions, 272, 272f vs. Ultramapper™, 273, 274f Tunnel label, 435 Tunnels and tunneling, 366, 366f MPLS, 434 carrying PWs over, 435, 435f VPN, 433 hierarchical, 433-434 motivation for, 433 protocols for, 434 Tussle, 566 Type HEC (tHEC) field, 161 U UltramapperTM, 273, 274f, 275 vs. TSWCO 1622, 273, 274f Uncontrolled slip, 212 Uncorrelated, bounded, high-probability jitter (UBHPJ), 745 Uncorrelated, unbounded Gaussian jitter (UUGJ), 745, 746 UNI. See User Network Interface (UNI) Unicast service frame, 346-349 basic concept of, 347, 347f definition of, 346 identification at UNI of, 348-349 CE-VLANID/EVC map for, 348-349, 349f CE-VLAN ID for, 348 intensifying at UNI in, 348 multipoint-to-mutipoint, 347-348, 347f point-to-point, 347, 347f UNI client (UNI-C), 331, 331f Unidirectional path switch ring (UPSR), 309 Unidirectional switching, 303 UNI/E-NNI Transport Resource names, 591, 592f
826 UNI list, Ethernet Connection (EC) attributes and, 386 UNI network (UNI-N), 331, 331f UNI reference point, in MEN, 326-327 UNI Transport Resource name, 590 Universal Time (UTC) frequency, 217 Unstructured emulation mode, 459, 460 Unstructured service, alarm for, in MEN CES, 488 Untagged service frame, 348 Upstream node, 81, 82f Usage, 624, 624t User access failure, restoration from, 632, 632f User Network Interface (UNI), 8, 316, 317f in Ethernet, 8 in Ethernet services over MEN, 344-345 in Ethernet services over public WAN, 379 in MEN, 326-327, 330-331, 331f service attributes of, 402, 402t User Network Interface (UNI) reference point, in MEN, 326-327 Userjriority field, 357 User traffic, MEN protection of, 520 User/transport/forwarding plane, 337 V VC-4-Xc structure, 128, 128f VC-12 client traffic, carried on VC-4 server trails, 4 2 ^ 3 , 42f, 43f VCAT. See Virtual Concatenation (VCAT) VC-n structure, in SDH, 125-126, 125f, 126f Very High Speed Integrated Circuit (VHSIC), 3 Very Short Reach (VSR), 699, 729 Very Short Reach (VSR) transponders, 724 VHDL. See VHSIC Hardware Description Language (VHDL) VHSIC. See Very High Speed hitegrated Circuit (VHSIC) VHSIC Hardware Description Language (VHDL), 3 Virtual Concatenation Group (VCG), 131. See also Virtual Concatenation (VCAT) alignment within, 148-149 Virtual Concatenation (VCAT), 5, 8, 131-139 additional benefits of, 136 advantages of LCAS and GFP in, 144 detailsof, 137, 138t, 139t differential delay in, 131-132, 132f
Index in Ethernet services over WAN, 374-375, 420 implementers guide for, 144-152 {See also under Multiplex structures, of OTN) origins and value of, 131 payload distribution and reconstruction in, 133-134, 133f, 134t, 135t restrictions of, 136-137 in SONET, 544-545 Virtual connections (VCs), 426, 426f. See also Ethernet (Services), over public WAN Virtual container, 120 Virtual container overhead bytes, in SDH VC-n structures, 126 Virtual framer management, in GFP, 171-172 Virtual LAN-based VPN, 156 Virtual LAN Service (VPLS), 428 Virtual LAN Service (VPLS) forwarding loops, avoiding, 446 Virtual LAN Service (VPLS) PW encapsulation, 447 Virtual LAN Service (VPLS) PW setup, 447 Virtual LAN Service (VPLS) reference model, 443-446, 444f, 445f Virtual leased lines, GFP in, 185, 186f Virtual Private Network (VPN), 425-427 classification of, 426^27, 427f multiservice converged packet switched backbone in, 427 traditional layer 2 (L2VPNs), 425-426, 426f virtual LAN-based, 156 Virtual Private Network (VPN) backbone, 425-426 Virtual Private Network (VPN) Edge Device, 426 Virtual Private Network (VPN) tunnels, 433 hierarchical, 433-434 motivations for, 433 protocols for, 434 Virtual Private Service, 380, 381f, 381t in Ethernet services over public WAN, 380 Virtual Private Wire Service (VPWS), 428 Virtual Private Wire Service (VPWS) reference model, 429f, 435f, 438, 439f Virtual Tributary (VT), 470 Virtual wire, 457 VLAN ID, 370-371, 37If
827
Index in Ethernet services over public WAN, 386 VLAN mapping, 404 VLAN tag processing, 439^40 VPLS. See Virtual LAN Service (VPLS) VPN. See Virtual Private Netvi^ork (VPN) W Waiting time jitter, 202 Wait-to-restore period, 304 Wait-To-Restore (WrT), 311 Wait to restore (WTR) time, in MEN, 503 WAN. See Ethernet (Services), over public WAN; Wide Area Network (WAN) Wander, 206, 212 source traceability and, 262 Wander accumulation for PDH clients of SONET/SDH networks, 227-231 for SDH clients of OTN, 231-233 Wander network limits, 212-213 Wander performance, 212-213 WAN flow control system, 545 Wave Division Multiplexing (WDM), 539-540, 542t Wavelength bands, 705, 705t White contributions, 773
White frequency modulation (WFM), 209 White phase modulation (WPM), 208-209 Wide Area Network (WAN), 662, 662f Ethernet connectivity and, 373-375 transport over OTN in {See Multiplex structures, of OTN) Widely spaced signals, 696 Working Documents, 774 Working parties, 771-772, 77If World Telecommunication Development Conference (WTDC), 769f, 770 World Telecommunication Standardization Assembly (WTSA), 769f, 770 X X2 device, 726, 727f XAUI, 725-726, 759-760 XENPAK, 725-726, 725f XENPAK-MSA, 725 XFP device, 727-728, 728f XGMII, 759 XGP device, 726 XPAK device, 726 Y Yellow bandwidth profile, 361-362, 361f
