Optical Network Control Protocols

Transcription

1 Optical Network Control Protocols Jorge M. Finochietto Córdoba 2012 LCD EFN UNC Laboratorio de Comunicaciones Digitales Facultad de Ciencias Exactas, Físicas y Naturales Universidad Nacional de Córdoba, Argentina

2 Optical Layer Overview Protocols 2 / 40

3 Outline 1 Control and Management Basics 2 Optical Transport Network (OTN) Protocols 3 / 40

4 Outline 1 Control and Management Basics Configuration Management Performance and Fault Management 2 Optical Transport Network (OTN) Protocols Control and Management Basics 4 / 40

5 Optical Layer Lightpath as a Service Provides lightpaths to upper layers (SONET, IP, ATM) Behaves as a server layer which provides services to client layers Protocols Control and Management Basics 5 / 40

6 Optical Layer Requirements Lightpaths need to be setup and taken down as required by the client layer provide the amount of bandwidth required by the client layer implement adaptation functions on the client layer to make it compatible with optical layer guarantee a level of preformance (e.g., BER ) offer some level of protection meet jitter requirements to offer transparency to the client layer support fault management to address failures and report root-cause alarms A management and control interface between the optical layer and the client layer is required allows to setup or tear down lightpaths with configuration parameters provides performance and fault management information to the client layer Protocols Control and Management Basics 6 / 40

7 Optical Layer Management and Control Today lightpaths are set up fairly infrequently and remained nailed down for longs periods of time In the future, lightpaths could be provisioned dynamically To this end, there is no need of a signaling interface between the optical layer and the client one A network management system (NMS) is used to communicate with the optical layer network elements (NE) NEs (e.g., OLT/TLE, ROADM, OXC) are managed by element management system (EMS) EMS connect to the managed NEs using a data communication network (DCN) Besides, NEs can communicate each other through a fast signaling channel (FSC) to exchange real-time control information EMSs communicate with a NMS through a management network Besides EMS, a local management system is usually provided to enable craftpeople to manage individual NEs Protocols Control and Management Basics 7 / 40

8 Optical Layer Management System Protocols Control and Management Basics 8 / 40

9 Optical Layer Data Communication Network (DCN) EMS communicates with NEs through the DCN DCN can be realized in several ways Out-of-band separate network outside the optical layer (e.g., existing TCP/IP network) In-band same network as the optical layer In-band implies associating a control overhead to a line (multiple wavelengths) optical domain a path (one lightpath) electronic domain Protocols Control and Management Basics 9 / 40

10 Optical Layer Optical Supervisory Channel (OSC) Available for optical equipment that process multiple wavelengths Makes use of a separate (dedicated) wavelength from where data are being transported Optical amplifiers (i.e., EDFAs) and ROADMs can be managed this way For WDM systems in the C-band, the popular choices for the OSC wavelength include 1310nm, 1480nm, 1510nm, or 1620nm. ITU-T has adopted the 1510nm as the preferred choice Protocols Control and Management Basics 10 / 40

11 Optical Layer Rate-Preserving Overhead Available for optical equipment that processes lightpaths Uses the same wavelengths where data are being transported OLT/LTE and OXC with regeneration can be managed this way Overhead is already required by protocols for other purposes which include forward error correction (FEC) overhead In this context, overhead can be processed at each regeneration stage (endpoints of a lightpath) Protocols Control and Management Basics 11 / 40

12 Outline 1 Control and Management Basics Configuration Management Performance and Fault Management 2 Optical Transport Network (OTN) Protocols Control and Management Basics Configuration Management 12 / 40

13 Configuration Management Overview Equipment Management Keep track of actual equipment on the network and its capabilities Connection Management Set up lightpaths. keep track of them and tear them down Adaptation Management Converts clients signals to a form that can be used inside the optical layer Protocols Control and Management Basics Configuration Management 13 / 40

14 Configuration Management Connection Management Lightpaths pass through multiple nodes Each lightpath has an unique end-to-end identifier: section trace Additional identifiers can be used to identify concatenated lighpaths through 3R regeneration tandem trace user-defined set of consecutive lighpaths path trace end-to-end connection where client signal travels These identifiers enables the NMS to identify, verify and manage lightpaths Protocols Control and Management Basics Configuration Management 14 / 40

15 Configuration Management Adaptation Management Client signals may need adaptation to enter the optical layer Wavelength conversion signal conversion from one wavelength to another one Encapsulation add/remove overhead to manage the signal inside the optical layer Justification add/remove stuffing to compensate bit rate mismatches Multiplexing subrate multiplexing of lower-speed client streams Adaptation is done at transponders / muxponders Protocols Control and Management Basics Configuration Management 15 / 40

16 Outline 1 Control and Management Basics Configuration Management Performance and Fault Management 2 Optical Transport Network (OTN) Protocols Control and Management Basics Performance and Fault Management 16 / 40

17 Performance and Fault Management Overview Performance Management Measures the performance of the network Monitors quality-of-service (QoS) provided to client layer Ensures client layer complies with requirements Provides input to detect anomalous conditions Fault Management Detects failures when they happen Reports root-cause alarm to supress other correlated alarms Isolate faults by replacing faulty signals with special ones Protocols Control and Management Basics Performance and Fault Management 17 / 40

18 Performance and Fault Management Definitions anomaly (n) discrepancy between desired and actual value defect (d) density of anomalies cause (c) root-cause behind multiple defects action (a) response to fault cause failure (f) persistent fault cause performance (p) value representing ability to function performance filter px statistics gathering anomaly nx defect correlation cx persistent monitoring fx defect filter dx consequent action ax Protocols Control and Management Basics Performance and Fault Management 18 / 40

19 Performance Management performance filter px statistics gathering anomaly nx defect correlation cx persistent monitoring fx defect filter dx consequent action ax Protocols Control and Management Basics Performance and Fault Management 19 / 40

20 Performance Management BER Measurement Bit error rate (BER) is the key perfromance attribute associated to a lightpath Difficult to measure BER accurately on the optical domain (i.e., based on the SNR) BER can be computed when signal is available in the electrical domain Lightpaths use framing protocols which include overhead bytes which can be used for BER estimation Errored Blocks: verifies whether a data block contains errors or not by means of parity checks Corrected Errors: counts the corrected errors by the Forward Error Correction (FEC) code Protocols Control and Management Basics Performance and Fault Management 20 / 40

21 Performance Management Alignement and Connectivity Alignment Lightpaths transport both data and overhead in a structure known as frame An alignment signal is inserted to delineates these frame and extract overhead bytes from the signal Connectivity Lighpaths are identified by traces at different levels It is possibe then to detect incorrect connections (i.e., trace mismatch) Protocols Control and Management Basics Performance and Fault Management 21 / 40

22 Fault Management performance filter px statistics gathering anomaly nx defect correlation cx persistent monitoring fx defect filter dx consequent action ax Protocols Control and Management Basics Performance and Fault Management 22 / 40

23 Fault Management Alarm Management A signal failure may cause multiple alarms all over the network When a link (fiber) fails, all lightpaths on that link fail Besides the nodes at the end of the failed link, all nodes through which these lightpaths traverse could detect the failure and issue alarms Alarm supression is acomplished by using forward defect indication (FDI) backward defect indication (BDI) Protocols Control and Management Basics Performance and Fault Management 23 / 40

24 Fault Management Alarm Supression When a link fails, the node downstream of the failed link detects it and generates a defect condition. A defect condition could be generated because of a high bit error rate on the incoming signal or an outright loss of light on the incoming signal. If the defect persists for a certain time period (typically a few seconds), the node generates an alarm and inserts an FDI signal downstream to the next node The FDI is also referred to as the alarm indication signal (AIS) A node detecting a defect also sends a BDI signal upstream to the previous node, to notify that node of the failure If this previous node did not send out an FDI, it then knows that the link to the next node downstream has failed. Protocols Control and Management Basics Performance and Fault Management 24 / 40

25 Outline 1 Control and Management Basics 2 Optical Transport Network (OTN) Protocols Optical Transport Network (OTN) 25 / 40

26 Optical Transport Network Overview A set of NEs connected by optical fiber links, able to provide functionality of transport, multiplexing, switching, management, supervision and survivability of optical channels carrying client signals Standarized mainly in ITU-T G.709 OTN was designed to provide support for WDM unlike its predecessor SONET/SDH as well as to carry much more FEC overhead to provide monitoring of user-defined segments (tandem connections) to support protocol transparency (CBR service) for asynchronous timing (i.e., frames can be generated using free-running oscillators) Protocols Optical Transport Network (OTN) 26 / 40

27 Optical Transport Network Optical Layers + Electronic Layers Protocols Optical Transport Network (OTN) 27 / 40

28 Optical Transport Network Optical Transmission Section (OTS) Manages fiber segments between optical components such as between optical amplifiers, or optical amplifiers and WDM muxes. To this end, it uses an optical supervisory channel (OSC) Protocols Optical Transport Network (OTN) 28 / 40

29 Optical Transport Network Optical Multiplex Section (OMS) Each link between OLTs or (R)OADMs represents an OMS Consists of several OTS segements carrying multiple wavelengths Has access to the optical supervisory channel (OSC) Protocols Optical Transport Network (OTN) 29 / 40

30 Optical Transport Network Optical Channel (Och) Takes care of end-to-end routing of the lightpaths A lightpath traverses many fiber links, wherein it is multiplexed with many other wavelengths carrying other lightpaths Manages optical connections between 3R regeneration (i.e., transponders) Protocols Optical Transport Network (OTN) 30 / 40

31 Optical Transport Network Och Transport Unit (OTU) Manages lightpaths provided by the optical layer (OCh) in the electronic domain Delineates frames, provides identification of the lightpath, monitors its BER performance, carries alarm indicators, and provides a communication channel between the end points Adds the FEC to frames and scrambles them before transmission Protocols Optical Transport Network (OTN) 31 / 40

32 Optical Transport Network Frame Structure Protocols Optical Transport Network (OTN) 32 / 40

33 Optical Transport Network Control Overhead Protocols Optical Transport Network (OTN) 33 / 40

34 Control Overhead Frame Alignment Frame Alignment Signal (FAS) A fixed patter consisting of 6 bytes are used to delineate each frame Multiframe Alignment Signal (MFAS) Some of the overhead fields carry information that is dispersed over multiple frames, referred to as multiframes. The MFAS byte is incremented every frame providing 256 values indicating the number of the frame within a multiframe. Protocols Optical Transport Network (OTN) 34 / 40

35 Control Overhead Section Monitoring Section Monitoring (SM) 3 bytes containing: Trail Trace Identifier (TTI) 64 bytes for lighpath identification distributed over 64 frames (1 byte on each frame), where 16 bytes are used for endpoint ids and the remaining 32 bytes are operator specific BIP-8 Parity checksum to detect errored frames (i.e., blocks) Protocols Optical Transport Network (OTN) 35 / 40

36 Control Overhead Section Monitoring Section Monitoring (SM) 3 bytes containing: Alarm signals BEI/BIAE (backward error indicator and backward incoming alignment error) indicates to upstream node the number of errored blocks (BIP-8 fails) or if there is an incoming alignment error BDI (backward defect indication (BDI) indicates to upstream node whether there is a signal defect IAE (incoming alignment error) indicates to downstream node that it has detected an alignment error Protocols Optical Transport Network (OTN) 36 / 40

37 Control Overhead Communication Channel General Communications Channel (GCC0) 2-byte field that provides a clear channel connection between OTU termination points for use as DCN Protocols Optical Transport Network (OTN) 37 / 40

38 Optical Transport Network Och Data Unit (ODU) Manages connections resulting from one or more consecutive lightpaths (i.e., includes 3R regeneration) End-to-end paths (electropaths) or just ODU path Intermediate connections (tandem connections) or just ODU TC Supports path and up to 6 TC monitoring (i.e, connections identification, BER performance, alarm indicators, etc.) Protocols Optical Transport Network (OTN) 38 / 40

39 Optical Transport Network Och Paylod Unit (OPU) Adapts client signals to the OTN frames Protocols Optical Transport Network (OTN) 39 / 40

40 Optical Network Control Protocols Jorge M. Finochietto Córdoba 2012 LCD EFN UNC Laboratorio de Comunicaciones Digitales Facultad de Ciencias Exactas, Físicas y Naturales Universidad Nacional de Córdoba, Argentina