idnits 2.17.1 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2016) is 2848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T G.694.1' is mentioned on line 170, but not defined == Missing Reference: 'G.805' is mentioned on line 180, but not defined == Missing Reference: 'G.872' is mentioned on line 189, but not defined == Missing Reference: 'G.8081' is mentioned on line 200, but not defined == Missing Reference: 'ITU-T G.957' is mentioned on line 287, but not defined == Missing Reference: 'ITU-T G.691' is mentioned on line 287, but not defined == Missing Reference: 'ITU-T G.693' is mentioned on line 288, but not defined == Missing Reference: 'ITU-T G.959.1' is mentioned on line 288, but not defined == Missing Reference: 'YANG' is mentioned on line 488, but not defined == Missing Reference: 'LMP' is mentioned on line 589, but not defined == Missing Reference: 'LMP-WDM' is mentioned on line 589, but not defined == Missing Reference: 'RFC4208' is mentioned on line 614, but not defined == Unused Reference: 'RFC2863' is defined on line 1086, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 1106, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.691' is defined on line 1151, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.693' is defined on line 1156, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.957' is defined on line 1160, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.959.1' is defined on line 1170, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.8081' is defined on line 1174, but no explicit reference was found in the text -- No information found for draft-galimkunze-ccamp-dwdm-if-snmp-mib - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 25 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Kunze, Ed. 3 Internet-Draft Deutsche Telekom 4 Intended status: Informational G. Grammel, Ed. 5 Expires: January 9, 2017 Juniper 6 D. Beller, Ed. 7 Nokia 8 G. Galimberti, Ed. 9 Cisco 10 July 8, 2016 12 A framework for Management and Control of DWDM optical interface 13 parameters 14 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 16 Abstract 18 To ensure an efficient data transport, meeting the requirements 19 requested by today's IP-services the control and management of DWDM 20 interfaces is a precondition for enhanced multilayer networking and 21 for an further automation of network provisioning and operation. 22 This document describes use cases and requirements for the control 23 and management of optical interfaces parameters according to 24 different types of single channel DWDM interfaces. The focus is on 25 automating the network provisioning process irrespective on how it is 26 triggered i.e. by EMS, NMS or GMPLS. This document covers management 27 as well as control plane considerations in different management cases 28 of a single channel DWDM interface. The purpose is to identify the 29 necessary information elements and processes to be used by control or 30 management systems for further processing. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 9, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 69 3. Solution Space Client DWDM interface . . . . . . . . . . . . 5 70 3.1. Comparison of approaches for transverse compatibility . . 6 71 3.1.1. Multivendor DWDM line system with transponders . . . 6 72 3.1.2. Integrated single channel DWDM deployments on the 73 client site . . . . . . . . . . . . . . . . . . . . . 8 74 4. Solutions for managing and controlling the optical interface 9 75 4.1. Separate Operation and Management Approaches . . . . . . 10 76 4.1.1. Direct connection to the management system . . . . . 10 77 4.1.2. Direct connection to the DWDM management system . . . 12 78 4.2. Control Plane Considerations . . . . . . . . . . . . . . 14 79 4.2.1. Considerations using GMPLS UNI . . . . . . . . . . . 15 80 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 16 82 5.2. Link monitoring Use Cases . . . . . . . . . . . . . . . . 17 83 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19 84 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 22 85 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 24 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 89 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 92 11.2. Informative References . . . . . . . . . . . . . . . . . 28 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 95 1. Introduction 97 The usage of the single channel DWDM interfaces in client nodes (e.g. 98 routers) connected to a DWDM Network (which include ROADMs and 99 optical amplifiers) adds a further networking option for operators 100 opening to new scenarios and requiring more control/management plane 101 integration. 103 Carriers deploy their networks today as a combination of transport 104 and packet infrastructures to ensure high availability and flexible 105 data transport. Both network technologies are usually managed by 106 different operational units using different management concepts. 107 This is the status quo in many carrier networks today. In the case 108 of deployments, where the optical transport interface moves into the 109 client device (e.g. , router), it is necessary to coordinate the 110 management of the optical interface at the client domain with the 111 optical transport domain. There are different levels of 112 coordination, which are specified in this framework. 114 The objective of this document is to provide a framework that 115 describes the solution space for the control and management of single 116 channel interfaces and give use cases on how to manage the solutions. 117 In particular, it examines topological elements and related network 118 management measures. From an architectural point of view, the 119 network can be considered as a set of pre- configured/qualified 120 unidirectional, single-fiber, network connections between reference 121 points S and R shown in figure 2. The optical transport network is 122 managed and controlled in order to provide optical connections at the 123 intended centre frequencies and the optical interfaces are managed 124 and controlled to generate signals of the intended centre frequencies 125 and further parameters as specified for example in ITU-T 126 Recommendations G.698.2 and G.798. The management or control plane 127 of the client and DWDM network be aware of the parameters of the 128 interfaces to properly set up the optical link. This knowledge can 129 be used furthermore, to support fast fault detection. 131 Optical routing and wavelength assignment based on WSON is out of 132 scope although can benefit of the way the optical parameters are 133 exchanged between the Client and the DWDM Network. 135 Additionally, the wavelength ordering process and the process how to 136 determine the demand for a new wavelength from A to Z is out of 137 scope. 139 Note that the Control and Management Planes are two separate entities 140 that are handling the same information in different ways. This 141 document covers management as well as control plane considerations in 142 different management cases of single channel DWDM interfaces. 144 1.1. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 2. Terminology and Definitions 152 Current generation WDM netwoks are single vendor networks where the 153 optical line system and the transponders are tightly integrated. The 154 DWDM interfaces migration from the Transponders to the Client 155 interfaces changes this scenario, by introducing a standardized 156 interface at the level of OCh between the Client DWDM interface and 157 the DWDM network. 159 Black Link: The Black Link [ITU.G698.2] allows supporting an optical 160 transmitter/receiver pair of a single vendor or from different 161 vendors to provide a single optical channel interface and transport 162 it over an optical network composed of amplifiers, filters, add-drop 163 multiplexers which may be from a different vendor. Therefore the 164 standard defines the ingress and egress parameters for the optical 165 interfaces at the reference points Ss and Rs. 167 Single Channel DWDM Interface: The single channel interfaces to DWDM 168 systems defined in G.698.2, which currently include the following 169 features: channel frequency spacing: 50 GHz and wider (defined in 170 [ITU-T G.694.1]); bit rate of single channel: Up to 10 Gbit/s. 171 Future revisions are expected to include application codes for bit 172 rates up to 40 Gb/s. 174 Forward error correction (FEC): FEC is a way of improving the 175 performance of high-capacity optical transmission systems. Employing 176 FEC in optical transmission systems yields system designs that can 177 accept relatively large BER (much more than 10-12) in the optical 178 transmission line (before decoding). 180 Administrative domain [G.805]: For the purposes of this 181 Recommendation an administrative domain represents the extent of 182 resources which belong to a single player such as a network operator, 183 a service provider or an end-user. Administrative domains of 184 different players do not overlap amongst themselves. 186 Intra-domain interface (IaDI) [G.872]: A physical interface within an 187 administrative domain. 189 Inter-domain interface (IrDI) [G.872]: A physical interface that 190 represents the boundary between two administrative domains. 192 Management Plane [G.8081]: The management plane performs management 193 functions for the transport plane, the control plane and the system 194 as a whole. It also provides coordination between all the planes. 195 The following management functional areas are performed in the 196 management plane: performance management; fault management; 197 configuration management; accounting management and security 198 management. 200 Control Plane[G.8081]: The control plane performs neighbour 201 discovery, call control and connection control functions. Through 202 signalling, the control plane sets up and releases connections, and 203 may restore a connection in case of a failure. The control plane 204 also performs other functions in support of call and connection 205 control, such as neighbour discovery and routing information 206 dissemination. 208 Transponder: A Transponder is a network element that performs O/E/O 209 (Optical /Electrical/Optical) conversion. In this document it is 210 referred only transponders with 3R (rather than 2R or 1R 211 regeneration) as defined in [ITU.G.872]. 213 Client DWDM interface: A Transceiver element that performs E/O 214 (Electrical/Optical) conversion. In this document it is referred as 215 the DWDM side of a transponder as defined in [ITU.G.872]. 217 3. Solution Space Client DWDM interface 219 The management of optical interfaces using the Black Link approach 220 deals with aspects related to the management of single-channel 221 optical interface parameters of physical point-to-point and ring DWDM 222 applications on single-mode optical fibres. 224 The solution allows the direct connection of a wide variety of 225 equipments using a DWDM link, for example: 227 1. A digital cross-connect with multiple optical interfaces, 228 supplied by a different vendor from the line system 230 2. Multiple optical client devices, each from a different vendor, 231 supplying one channel each 233 3. A combination of the above 235 Table 1 provides a list of management tasks regarding the 236 configuration of optical parameters. 238 +---------------------------------------+---------+----+----+---+---+ 239 | Task | Domain | a | b | c | d | 240 +---------------------------------------+---------+----+----+---+---+ 241 | determination of centre frequency | optical | R | R | R | R | 242 | configuration of centre frequency at | client | NR | NR | R | R | 243 | optical IF | | | | | | 244 | path computation of wavelength | optical | NR | NR | R | R | 245 | routing of wavelength | optical | NR | NR | R | R | 246 | wavelength setup across optical | optical | ? | ? | R | R | 247 | network | | | | | | 248 | detection of wavelength fault | client | R | R | R | R | 249 | fault isolation, identification of | optical | NR | R | R | R | 250 | root failure | | | | | | 251 | repair actions within optical network | optical | R | R | R | R | 252 | protection switching of wavelength | optical | NR | NR | R | R | 253 | restoration of wavelength | optical | NR | NR | R | R | 254 +---------------------------------------+---------+----+----+---+---+ 256 Note: R = relevant, NR = not relevant 258 Table 1: List of tasks related to Client - Network interconnection 259 management 261 Furthermore the following deployment cases will be considered: 263 a. Passive WDM 265 b. P2P WDM systems 267 c. WDM systems with OADMs 269 d. Transparent optical networks supporting specific functions, 270 nterfaces, protocols etc. 272 Case a) is added for illustration only, since passive WDM is 273 specified in ITU-T Recommendations G.695 and G.698.1. 275 Case b) and case c)are motivated by the usage of legacy equipment 276 using the traditional connection as described in Figure 1 DWDM 277 interface integration on the client side. 279 3.1. Comparison of approaches for transverse compatibility 281 3.1.1. Multivendor DWDM line system with transponders 283 As illustrated in Figure 1, for this approach interoperability is 284 achieved via the use of optical transponders providing OEO (allowing 285 conversion to appropriate parameters). The optical interfaces can 286 then be any short reach standardized optical interface that both 287 vendors support, such as those found in [ITU-T G.957] [ITU-T G.691], 288 [ITU-T G.693], [ITU-T G.959.1], etc. 290 IrDI IaDI 291 | | 292 . . 293 | +----------------------------|----+ 294 . | + WDM Domain + . | 295 | | |\ /| | | 296 +------+ . | | \ |\ / | . | +------+ 297 | TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T-+---->--| RX/ | 298 | RX |--<--+---+--T/-| |----- /|-----| |--.-\T-+----<--| TX | 299 +------+ | | | / \| \ | | | +------+ 300 . | |/ \| . | 301 | | + + | | 302 . +----------------------------.----+ 303 | | 305 TX/RX = Single channel non-DWDM interfaces 306 T/ = Transponder 307 OM = Optical Mux 308 OD = Optical Demux 310 Figure 1: Inter and Intra-Domain Interface Identification 312 In the scenario of Figure 1 the administrative domain is defined by 313 the Interdomain Interface (IrDI). This interface terminates the DWDM 314 domain. The line side is characterized by the IaDI. This interface 315 specifies the internal parameter set of the optical administrative 316 domain. In the case of a client DWDM interface deployment this 317 interface moves into the client device and extends the optical and 318 administrative domain towards the client node. ITU-T G.698.2 for 319 example specifies the parameter set for a certain set of 320 applications. 322 This document elaborates only the IaDI Interface as shown in Figure 1 323 as transversely compatible and multi-vendor interface within one 324 administrative domain controlled by the network operator. 326 3.1.2. Integrated single channel DWDM deployments on the client site 328 In case of a deployment as shown in Figure 2, through the use of 329 single channel DWDM interfaces, multi-vendor interconnection can also 330 be achieved while removing the need for one short reach transmitter 331 and receiver pair per channel (eliminating the transponders). 333 Figure 2 shows a set of reference points, for single-channel 334 connection (Ss and Rs) between transmitters (Tx) and receivers (Rx). 335 Here the DWDM network elements include an optical multiplexer (OM) 336 and an optical demultiplexer (OD) (which are used as a pair with the 337 peer element), one or more optical amplifiers and may also include 338 one or more OADMs. 340 |==================== Black Link =======================| 342 +-------------------------------------------------+ 343 Ss | | DWDM Network Elements | | Rs 344 +---+ | | | \ / | | | +---+ 345 Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1 346 +---+ | | | | | +------+ | | | | | +---+ 347 +---+ | | | | | | | | | | | | +---+ 348 Tx L2---|->| OM |-|>|------|->| OADM |--|------|->| OD |--|-->Rx L2 349 +---+ | | | | | | | | | | | | +---+ 350 +---+ | | | | | +------+ | | | | | +---+ 351 Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 352 +---+ | | / | Link +----|--|----+ Link | \ | | +---+ 353 +-----------+ | | +----------+ 354 +--+ +--+ 355 | | 356 v | 357 +---+ +---+ 358 RxLx TxLx 359 +---+ +---+ 361 Ss = Reference point at the DWDM network element tributary output 362 Rs = Reference point at the DWDM network element tributary input 363 Lx = Lambda x 364 OM = Optical Mux 365 OD = Optical Demux 366 OADM = Optical Add Drop Mux 368 Linear DWDM network as per ITU-T G.698.2 370 Figure 2: Linear Black Link 372 As shown in Figure 2, the administrative domain may consists of 373 several vendor domains. Even a in that case a common north bound 374 management interface is required to ensure a consistent management of 375 the entire connection. 377 The following documents[DWDM-interface-MIB], [YANG], [LMP] define 378 such a protocol- FIX-THE-REFERENCE specific information using SNMP/ 379 SMI, Yang models and LMP TLV to support the direct exchange of 380 information between the client and the network control plane. 382 4. Solutions for managing and controlling the optical interface 384 Operation and management of WDM systems is traditionally seen as a 385 homogenous group of tasks that could be carried out best when a 386 single management system or an umbrella management system is used. 387 Currently each WDM vendor provides an Element Management System (EMS) 388 that also administers the wavelengths. 390 Therefore from the operational point of view the following approaches 391 will be considered to manage and operate optical interfaces. 393 : 395 1. Separate operation and management of client device and the 396 transport network whereas the single channel interface of the 397 client belongs to the administrative domain of the transport 398 network and will be managed by the transport group. This results 399 in two different approaches to send information to the management 400 system 402 a.Direct connection from the client to the management 403 system,ensuring a management of the single channel of the optical 404 network (e.g. EMS, NMS) 406 b.Indirect connection to the management system of the optical 407 network using a protocol (LMP) between the client device and the 408 directly connected WDM system node to exchange management 409 information with the optical domain 411 2. Common operation and management of client device including the 412 single channel DWDM part and the Transport network 414 The first option keeps the status quo in large carrier networks as 415 mentioned above. In that case it must be ensured that the full FCAPS 416 Management (Fault, Configuration, Accounting, Performance and 417 Security) capabilities are supported. This means from the management 418 staff point of view nothing changes. The transceiver/receiver 419 optical interface will be part of the optical management domain and 420 will be managed from the transport management staff. 422 The second solution addresses the case where underlying WDM transport 423 network is mainly used to interconnect a homogeneous set of client 424 nodes (e.g. IP routers or digital crossconnects). Since the service 425 creation and restoration could be done by the higher layers (e.g. 426 IP), this may lead to an efficient network operation and a higher 427 level of integration. 429 4.1. Separate Operation and Management Approaches 431 4.1.1. Direct connection to the management system 432 As depicted in Figure 3 (case 1a) one possibility to manage the 433 optical interface within the client domain is a direct connection to 434 the management system of the optical domain. This ensures 435 manageability as usual. 437 +-----+ 438 | NMS | 439 |_____| 440 /_____/ 441 | 442 | 443 | 444 +---+---+ 445 +----->+ EMS | 446 / | | 447 / +-------+ 448 / | MI SNMP or Yang 449 SNMP / or Yang | DCN Network 450 --------------------+------------------------------- 451 / +------+-----------------------+ 452 / | +| WDM Domain + | 453 / | |\ /| | 454 +---+--+ | | \ |\ / | | +------+ 455 | CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL | 456 | |-/C------+-----| |----- /|-----| |----+-------/C-| | 457 +------+ | | / \| \ | | +------+ 458 | |/ \| | 459 | + + | 460 +------------------------------+ 462 CL = Client Device 463 /C = Single Channel Optical Interface 464 OM = Optical Mux 465 OD = Optical Demux 466 EMS = Element Management System 467 MI= Management Interface 469 Figure 3: Connecting Single Channel optical interfaces to the 470 Transport Management system 472 The exchange of management information between client device and the 473 management system assumes that some form of a direct management 474 communication link exists between the client device and the DWDM 475 management system (e.g. EMS). This may be an Ethernet Link or a DCN 476 connection (management communication channel MCC). 478 It must be ensured that the optical network interface can be managed 479 in a standardised way to enable interoperable solutions between 480 different optical interface vendors and vendors of the optical 481 network management application. RFC 3591 [RFC3591] defines managed 482 objects for the optical interface type but needs further extension to 483 cover the optical parameters required by this framework document. 484 Therefore an extension to this MIB for the optical interface has been 485 drafted in [DWDM-interface-MIB]. SNMP is used to read parameters and 486 get notifications and alarms, netconf and Yang models are needed to 487 easily provision the interface with the right parameter set as 488 described in [YANG] 490 Note that a software update of the optical interface components of 491 the client nodes must not lead obligatory to an update of the 492 software of the EMS and vice versa. 494 4.1.2. Direct connection to the DWDM management system 495 An alternative as shown in Figure 4 can be used in cases where a more 496 integrated relationship between transport node (e.g. OM or OD) and 497 client device is aspired. In that case a combination of control 498 plane features and manual management will be used. 500 +-----+ 501 | NMS | 502 |_____| 503 /_____/ 504 | 505 | 506 +---+---+ 507 | EMS | 508 | | 509 +-------+ 510 | MI SNMP or Yang 511 | 512 LMP +------+-----------------------+ 513 +------------+---+ +| + | 514 | | | |\ /| | 515 +---+--+ | +-+ \ |\ / | | +------+ 516 | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | 517 | |-/C------+--- -| |----- /|-----| |----+-------/C-| | 518 +------+ | | / \| \ | | +------+ 519 | |/ \| | 520 | + + | 521 +------------------------------+ 523 CL = Client Device 524 /C = Single Channel optical Interface 525 OM = Optical Mux 526 OD = Optical Demux 527 EMS= Element Management System 528 MI= Management Interface 530 Figure 4: Direct connection between peer node and first optical 531 network node 533 For information exchange between the client node and the direct 534 connected node of the optical transport network LMP as specified in 535 RFC 4209 [RFC4209] should be used. This extension of LMP may be used 536 between a peer node and an adjacent optical network node as depicted 537 in Figure 4. 539 The LMP based on RFC 4209 does not yet support the transmission of 540 configuration data (information). This functionality must be added 541 to the existing extensions of the protocol. The use of LMP-WDM 542 assumes that some form of a control channel exists between the client 543 node and the WDM equipment. This may be a dedicated lambda, an 544 Ethernet Link, or other signalling communication channel (SCC or 545 IPCC). 547 4.2. Control Plane Considerations 549 The concept of integrated single channel DWDM interfaces equally 550 applies to management and control plane mechanisms. The general 551 GMPLS control plane for wavelength switched optical networks is work 552 under definition in the scope of WSON. One important aspect of the 553 BL is the fact that it includes the wavelength that is supported by 554 the given link. Thus a BL can logically be considered as a fiber 555 that is transparent only for a single wavelength. In other words, 556 the wavelength becomes a characteristic of the link itself. 557 Nevertheless the procedure to light up the fiber may vary depending 558 on the implementation. Since the implementation is unknown a priori, 559 different sequences to light up a wavelength need to be considered: 561 1. Interface first, interface tuning: The transmitter is switched on 562 and the link is immediately transparent to its wavelength. This 563 requires the transmitter to carefully tune power and frequency 564 not overload the line system or to create transients. 566 2. Interface first, OLS tuning: The transmitter is switched on first 567 and can immediately go to the max power allowed since the OLS 568 performs the power tuning. This leads to an intermediate state 569 where the receiver does not receive a valid signal while the 570 transmitter is sending out one. Alarm suppression mechanisms 571 shall be employed to overcome that condition. 573 3. OLS first, interface tuning: At first the OLS is tuned to be 574 transparent for a given wavelength, then transponders need to be 575 tuned up. Since the OLS in general requires the presence of a 576 wavelength to fine-tune it is internal facilities there may be a 577 period of time where a valid signal is transmitted but the 578 receiver is unable to detect it. This equally need to be covered 579 by alarm suppression mechanisms. 581 4. OLS first, OLS tuning: The OLS is programmed to be transparent 582 for a given wavelength, then the interfaces need to be switched 583 on and further power tuning takes place. The sequencing of 584 enabling the link needs to be covered as well. 586 The preferred way to address these in a Control Plane enabled network 587 is neighbour discovery including exchange of link characteristics and 588 link property correlation. The general mechanisms are covered in 589 RFC4209 [LMP-WDM] and RFC 4204[LMP] which provides the necessary 590 protocol framework to exchange those characteristics between client 591 and black link. LMP-WDM is not intended for exchanging routing or 592 signalling information but covers: 594 1. Control channel management 596 2. Link property correlation 598 3. Link verification 600 4. Fault management 602 Extensions to LMP/LMP-WDM covering the code points of the BL 603 definition are needed. Additionally when client and server side are 604 managed by different operational entities, Link state exchange is 605 required to align the management systems. 607 4.2.1. Considerations using GMPLS UNI 609 The deployment of single channel optical interfaces is leading to 610 some functional changes related to the control plane models and has 611 therefore some impact on the existing interfaces especially in the 612 case of an overlay model where the edge node requests resources from 613 the core node and the edges node do not participate in the routing 614 protocol instance that runs among the core nodes. RFC 4208 [RFC4208] 615 defines the GMPLS UNI that will be used between edge and core node. 616 In case of integrated interfaces deployment additional 617 functionalities are needed to setup a connection. 619 It is necessary to differentiate between topology/signalling 620 information and configuration parameters that are needed to setup a 621 wavelength path. RSVP-TE could be used for the signalling and the 622 reservation of the wavelength path. But there are additional 623 information needed before RSVP-TE can start the signalling process. 624 There are three possibilities to proceed: 626 a. Using RSVP-TE only for the signalling and LMP as described above 627 to exchange information to configure the optical interface within 628 the edge node or 630 b. RSVP-TE will be used to transport additional information 632 c. Leaking IGP information instead of exchanging this information 633 needed from the optical network to the edge node (overlay will be 634 transformed to a border-peer model) 636 Furthermore following issues should be addressed: 638 a) The Communication between peering edge nodes using an out of band 639 control channel. The two nodes have to exchange their optical 640 capabilities. An extended version of LMP is needed to exchange FEC 641 Modulation scheme, etc. that must be the same. It would be helpful 642 to define some common profiles that will be supported. Only if the 643 profiles match with both interface capabilities it is possible start 644 signalling. 646 b) Due to the bidirectional wavelength path that must be setup it is 647 obligatory that the upstream edge node inserts a wavelength value 648 into the path message for the wavelength path towards the upstream 649 node itself. But in the case of an overlay model the client device 650 may not have full information which wavelength must/should be 651 selectedand this information must be exchanged between the edge and 652 the core node. 654 5. Use cases 656 A Comparison with the traditional operation scenarios provides an 657 insight of similarities and distinctions in operation and management 658 of single channel optical interfaces. The following use cases 659 provide an overview about operation and maintenance processes. 661 5.1. Service Setup 663 It is necessary to differentiate between two operational issues for 664 setting up a light path (a DWDM connection is specific in having 665 defined maximum impairments) within an operational network. The 666 first step is the preparation of the connection if no optical signal 667 is applied. Therefore it is necessary to define the path of the 668 connection. 670 The second step is to setup the connection between the client DWDM 671 interface and the ROADM port. This is done using the NMS of the 672 optical transport network. From the operation point of view the task 673 is similar in a Black Link scenario and in a traditional WDM 674 environment. The Black Link connection is measured by using BER 675 tester which use optical interfaces according to G.698.2. These 676 measurements are carried out in accordance with [ITU-TG.692]. When 677 needed further connections for resilience are brought into service in 678 the same way. 680 In addition some other parameters like the transmit optical power, 681 the received optical power, the frequency, etc. must be considered. 683 If the optical interface moves into a client device some of changes 684 from the operational point of view have to be considered. The centre 685 frequency of the Optical Channel was determined by the setup process. 687 The optical interfaces at both terminals are set to the centre 688 frequency before interconnected with the dedicated ports of the WDM 689 network. Optical monitoring is activated in the WDM network after 690 the terminals are interconnected with the dedicated ports in order to 691 monitor the status of the connection. The monitor functions of the 692 optical interfaces at the terminals are also activated in order to 693 monitor the end to end connection. 695 Furthermore it should be possible to automate this last step. After 696 connecting the client device towards the first control plane managed 697 transport node a control connection may e.g. be automatically 698 established using LMP to exchange configuration information. 700 If tunable interfaces are used in the scenario it would be possible 701 to define a series of backup wavelength routes for restoration that 702 could be tested and stored in backup profile. In fault cases this 703 wavelength routes can be used to recover the service. 705 5.2. Link monitoring Use Cases 707 The use cases described below are assuming that power monitoring 708 functions are available in the ingress and egress network element of 709 the DWDM network, respectively. By performing link property 710 correlation it would be beneficial to include the current transmit 711 power value at reference point Ss and the current received power 712 value at reference point Rs. For example if the Client transmitter 713 power (OXC1) has a value of 0dBm and the ROADM interface measured 714 power (at OLS1) is -6dBm the fiber patch cord connecting the two 715 nodes may be pinched or the connectors are dirty. More, the 716 interface characteristics can be used by the OLS network Control 717 Plane in order to check the Optical Channels feasibility. Finally 718 the OXC1 transceivers parameters (Application Code) can be shared 719 with OXC2 using the LMP protocol to verify the transceivers 720 compatibility. The actual route selection of a specific wavelength 721 within the allowed set is outside the scope of LMP. In GMPLS, the 722 parameter selection (e.g. central frequency) is performed by RSVP-TE. 724 G.698.2 defines a single channel optical interface for DWDM systems 725 that allows interconnecting network-external optical transponders 726 across a DWDM network. The optical transponders are considered to be 727 external to the DWDM network. This so-called 'black link' approach 728 illustrated in Figure 5-1 of G.698.2 and a copy of this figure is 729 provided below. The single channel fiber link between the Ss/Rs 730 reference points and the ingress/egress port of the network element 731 on the domain boundary of the DWDM network (DWDM border NE) is called 732 access link in this contribution. Based on the definition in G.698.2 733 it is considered to be part of the DWDM network. The access link 734 typically is realized as a passive fiber link that has a specific 735 optical attenuation (insertion loss). As the access link is an 736 integral part of the DWDM network, it is desirable to monitor its 737 attenuation. Therefore, it is useful to detect an increase of the 738 access link attenuation, for example, when the access link fiber has 739 been disconnected and reconnected (maintenance) and a bad patch panel 740 connection (connector) resulted in a significantly higher access link 741 attenuation (loss of signal in the extreme case of an open connector 742 or a fiber cut). In the following section, two use cases are 743 presented and discussed: 745 1) pure access link monitoring 746 2) access link monitoring with a power control loop 748 These use cases require a power monitor as described in G.697 (see 749 section 6.1.2), that is capable to measure the optical power of the 750 incoming or outgoing single channel signal. The use case where a 751 power control loop is in place could even be used to compensate an 752 increased attenuation as long as the optical transmitter can still be 753 operated within its output power range defined by its application 754 code. 756 Figure 5 Access Link Power Monitoring 758 +--------------------------+ 759 | P(in) = P(Tx) - a(Tx) | 760 | ___ | 761 +----------+ | \ / Power Monitor | 762 | | P(Tx) | V P(in) | 763 | +----+ | Ss //\\ | | |\ | 764 | | TX |----|-----\\//------------------->| \ | 765 | +----+ | Access Link (AL-T) | . | | | 766 | | attenuation a(Tx) | . | |==============> 767 | | | . | | | 768 | External | | --->| / | 769 | Optical | | |/ | 770 |Transpond.| | P(out) | 771 | | | ___ | 772 | | | \ / Power Monitor | 773 | | P(Rx) | V P(out) | 774 | +----+ | Rs //\\ | | |\ | 775 | | RX |<---|-----\\//--------------------| \ | 776 | +----+ | Access Link (AL-R) | . | | | 777 | | Attenuation a(Rx) | . | |<============== 778 +----------+ | . | | | 779 | <---| / | 780 P(Rx) = P(out) - a(Rx) | |/ | 781 | | 782 | ROADM | 783 +--------------------------+ 785 - For AL-T monitoring: P(Tx) and a(Tx) must be known 786 - For AL-R monitoring: P(RX) and a(Rx) must be known 788 An alarm shall be raised if P(in) or P(Rx) drops below a 789 configured threshold (t [dB]): 790 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 791 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 792 - a(Tx) =| a(Rx) 794 Figure 5: Extended LMP Model 796 5.2.1. Pure Access Link (AL) Monitoring Use Case 797 Figure 6 illustrates the access link monitoring use case and the 798 different physical properties involved that are defined below: 800 - Ss, Rs: Single Channel reference points 801 - P(Tx): current optical output power of transmitter Tx 802 - a(Tx): access link attenuation in Tx direction (external 803 transponder point of view) 804 - P(in): measured current optical input power at the input port 805 of border DWDM NE 806 - t: user defined threshold (tolerance) 807 - P(out): measured current optical output power at the output port 808 of border DWDM NE 809 - a(Rx): access link attenuation in Rx direction (external 810 transponder point of view) 811 - P(Rx): current optical input power of receiver Rx 813 Description: 814 - The access link attenuation in both directions (a(Tx), a(Rx)) 815 is known or can be determined as part of the commissioning 816 process. Typically, both values are the same. 817 - A threshold value t has been configured by the operator. This 818 should also be done during commissioning. 819 - A control plane protocol (e.g. this draft) is in place that allows 820 to periodically send the optical power values P(Tx) and P(Rx) 821 to the control plane protocol instance on the DWDM border NE. 822 This is llustrated in Figure 3. 823 - The DWDM border NE is capable to periodically measure the optical 824 power Pin and Pout as defined in G.697 by power monitoring points 825 depicted as yellow triangles in the figures below. 827 Access Link monitoring process: 828 - Tx direction: the measured optical input power Pin is compared 829 with the expected optical input power P(Tx) - a(Tx). If the 830 measured optical input power P(in) drops below the value 831 (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating 832 that the access link attenuation has exceeded a(Tx) + t. 833 - Rx direction: the measured optical input power P(Rx) is 834 compared with the expected optical input power P(out) - a(Rx). 835 If the measured optical input power P(Rx) drops below the value 836 (P(out) - a(Rx) - t) a 837 low power alarm shall be raised indicating that the access link 838 attenuation has exceeded a(Rx) + t. 839 -to avoid toggling errors, the low power alarm threshold shall be 840 lower than the alarm clear threshold. 842 Figure 6 Use case 1: Access Link monitoring 844 +----------+ +--------------------------+ 845 | +------+ | P(Tx), P(Rx) | +-------+ | 846 | | | | =================> | | | | 847 | | LMP | | P(in), P(out) | | LMP | | 848 | | | | <================= | | | | 849 | +------+ | | +-------+ | 850 | | | | 851 | | | P(in) - P(Tx) - a(Tx) | 852 | | | ___ | 853 | | | \ / Power Monitor | 854 | | P(Tx) | V | 855 | +----+ | Ss //\\ | | |\ | 856 | | TX |----|-----\\//------------------->| \ | 857 | +----+ | Access Link (AL-T) | . | | | 858 | | attenuation a(Tx) | . | |==============> 859 | | | . | | | 860 | External | | --->| / | 861 | Optical | | |/ | 862 |Transpond.| | P(out) | 863 | | | ___ | 864 | | | \ / Power Monitor | 865 | | P(Rx) | V | 866 | +----+ | Rs //\\ | | |\ | 867 | | RX |<---|-----\\//--------------------| \ | 868 | +----+ | Access Link (AL-R) | . | | | 869 | | Attenuation a(Rx) | . | |<============== 870 +----------+ | . | | | 871 | <---| / | 872 P(Rx) = P(out) - a(Rx) | |/ | 873 | | 874 | ROADM | 875 +--------------------------+ 877 - For AL-T monitoring: P(Tx) and a(Tx) must be known 878 - For AL-R monitoring: P(RX) and a(Rx) must be known 879 An alarm shall be raised if P(in) or P(Rx) drops below a 880 configured threshold (t [dB]): 881 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 882 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 883 - a(Tx) = a(Rx) 885 Figure 6: Extended LMP Model 887 5.2.2. Power Control Loop Use Case 889 This use case is based on the access link monitoring use case as 890 described above. In addition, the border NE is running a power 891 control application that is capable to control the optical output 892 power of the single channel tributary signal at the output port 893 of the border DWDM NE (towards the external receiver Rx) and the 894 optical output power of the single channel tributary signal at 895 the external transmitter Tx within their known operating range. 896 The time scale of this control loop is typically relatively slow 897 (e.g. some 10s or minutes) because the access link attenuation 898 is not expected to vary much over time (the attenuation only 899 changes when re-cabling occurs). 900 From a data plane perspective, this use case does not require 901 additional data plane extensions. It does only require a protocol 902 extension in the control plane (e.g. this LMP draft) that allows 903 the power control application residing in the DWDM border NE to 904 modify the optical output power of the DWDM domain-external 905 transmitter Tx within the range of the currently used application 906 code. Figure 5 below illustrates this use case utilizing the LMP 907 protocol with extensions defined in this draft. 909 Figure 7 Use case 2: Power Control Loop 911 +----------+ +--------------------------+ 912 | +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ | 913 | | | | ====================> | | | | Power | | 914 | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | | 915 | | | | <==================== | | | | Loop | | 916 | +------+ | | +-------+ +--------+ | 917 | | | | | 918 | +------+ | | P(in) = P(Tx) - a(Tx) | 919 | |C.Loop| | | ___ | 920 | +------+ | | \ / Power Monitor | 921 | | | P(Tx) | V | 922 | +------+ | Ss //\\ | | |\ | 923 | | TX |>----|-----\\//---------------------->| \ | 924 | +------+ | Access Link (AL-T) | . | | | 925 | VOA(Tx) | attenuation a(Tx) | . | |==============> 926 | | | . | | | 927 | External | | --->| / | 928 | Optical | | |/ | 929 |Transpond.| | P(out) | 930 | | | ___ | 931 | | | \ / Power Monitor | 932 | | P(Rx) | V | 933 | +----+ | Rs //\\ | | VOA(out) |\ | 934 | | RX |<---|-----\\//---------------------<|-------| \ | 935 | +----+ | Access Link (AL-R) | . | | | 936 | | attenuation a(Rx) | . | |<======= 937 +----------+ | VOA(out) | | | 938 | <--<|-------| / | 939 P(Rx) = P(out) - a(Rx) | |/ | 940 | | 941 | ROADM | 942 +--------------------------+ 944 Figure 7: Power control loop 946 - The Power Control Loops in Transponder and ROADM controls 947 the Variable Optical Attenuators (VOA) to adjust the proper 948 power in base of the ROADM and Receiver caracteristics and 949 the Access Link attenuation 951 6. Requirements 953 Even if network architectures becomes more complex the management and 954 operation as well as the provisioning process should have a higher 955 degree of automation or should be fully automated. Simplifying and 956 automating the entire management and provisioning process of the 957 network in combination with a higher link utilization and faster 958 restoration times will be the major requirements that has been 959 addressed in this section. 961 Data Plane interoperability as defined for example in [ITU.G698.2] is 962 a precondition to ensure plain solutions and allow the usage of 963 standardized interfaces between network and control/management plane. 965 The following requirements are focusing on the usage of standardised 966 integrated single channel interfaces but also valid in other 967 environments. 969 1 To ensure a lean management and provisioning process of single 970 channel interfaces management and control plane of the client 971 and DWDM network must be aware of the parameters of the 972 interfaces and the optical network to properly setup the optical 973 connection. 975 2 A standardized northbound API (to network management system)must 976 be supported based on SNMP and Netconf. 978 3 A standardized data model for single channel interfaces must be 979 supported to exchange optical parameters with control/ management 980 plane. 981 4..Netconf should be used also for configuration of the single 982 channel interfaces including the setting of the power. 984 5 LMP should be extended and used in cases where optical 985 parameters need to be exchanged between peer nodes to correlate 986 link characteristics and adopt the working mode of the single 987 channel interface. 989 6 Legacy operational models should be supported (parameters must 990 be exchanged with the DWDM transport EMS to manage the 991 configuration and the transmission of alarms and other FCAPS 992 messages. 994 7 LMP should be used to adjust the output power of the single 995 channel DWDM interface to ensure that the interface works in 996 the right range defined by the application code. 998 8 Parameters e.g. PRE-FEC BER could be used to trigger a FRR 999 mechanism on the IP control plane to reroute traffic before 1000 the link breaks. 1002 9 LMP should be used to automate the end to end connection 1003 setup of the optical connection. 1005 10 Power monitoring functions at both ends of the DWDM connection 1006 should be implemented to further automate the setup and 1007 shoutdown process of the optical interfaces. 1009 11 A standardized procedure to setup an optical connection must be 1010 defined and implemented in DWDM and client devices (containing 1011 the single channel optical interface).LMP should be used to 1012 ensure that the process follows the right order. 1014 12 Pre-tested and configured backup paths should be stored in so 1015 called backup profiles. In fault cases this wavelength routes 1016 can be used to recover the service. 1018 13 LMP should be used to monitor and observe the access link. 1020 7. Acknowledgements 1022 The authors would like to thank all who supported the work with 1023 fruitful discussions and contributions. 1025 8. IANA Considerations 1027 This memo includes no request to IANA. 1029 9. Security Considerations 1031 The architecture and solution space in scope of this framework 1032 imposes no additional requirements to the security models already 1033 defined in RFC5920 for packet/optical networks using GMPLS, covering 1034 also Control Plane and Management interfaces. Respective security 1035 mechanisms of the components and protocols, e.g. LMP security 1036 models, can be applied unchanged. 1038 As this framework is focusing on the single operator use case, the 1039 security concerns can be relaxed to a subset compared to a setup 1040 where information is exchanged between external parties and over 1041 external interfaces. 1043 Concerning the access control to Management interfaces, security 1044 issues can be generally addressed by authentication techniques 1045 providing origin verification, integrity and confidentiality. 1047 Additionally, access to Management interfaces can be physically or 1048 logically isolated, by configuring them to be only accessible out-of- 1049 band, through a system that is physically or logically separated from 1050 the rest of the network infrastructure. In case where management 1051 interfaces are accessible in-band at the client device or within the 1052 optical transport netork domain, filtering or firewalling techniques 1053 can be used to restrict unauthorized in-band traffic. Authentication 1054 techniques may be additionally used in all cases. 1056 10. Contributors 1058 Arnold Mattheus 1059 Deutsche Telekom 1060 Darmstadt 1061 Germany 1062 email arnold.Mattheus@telekom.de 1064 Manuel Paul 1065 Deutsche Telekom 1066 Berlin 1067 Germany 1068 email Manuel.Paul@telekom.de 1070 Josef Roese 1071 Deutsche Telekom 1072 Darmstadt 1073 Germany 1074 email j.roese@telekom.de 1076 Frank Luennemann 1077 Deutsche Telekom 1078 Muenster 1079 Germany 1080 email Frank.Luennemann@telekom.de 1082 11. References 1084 11.1. Normative References 1086 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1087 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 1088 . 1090 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1091 Requirement Levels", BCP 14, RFC 2119, 1092 DOI 10.17487/RFC2119, March 1997, 1093 . 1095 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1096 Schoenwaelder, Ed., "Structure of Management Information 1097 Version 2 (SMIv2)", STD 58, RFC 2578, 1098 DOI 10.17487/RFC2578, April 1999, 1099 . 1101 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1102 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1103 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 1104 . 1106 [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1107 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 1108 STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, 1109 . 1111 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 1112 Managed Objects for the Optical Interface Type", RFC 3591, 1113 DOI 10.17487/RFC3591, September 2003, 1114 . 1116 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 1117 Lambda-Switch-Capable (LSC) Label Switching Routers", 1118 RFC 6205, DOI 10.17487/RFC6205, March 2011, 1119 . 1121 [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management 1122 Protocol (LMP) for Dense Wavelength Division Multiplexing 1123 (DWDM) Optical Line Systems", RFC 4209, 1124 DOI 10.17487/RFC4209, October 2005, 1125 . 1127 [ITU.G698.2] 1128 International Telecommunications Union, "Amplified 1129 multichannel dense wavelength division multiplexing 1130 applications with single channel optical interfaces", 1131 ITU-T Recommendation G.698.2, November 2009. 1133 [ITU.G709] 1134 International Telecommunications Union, "Interface for the 1135 Optical Transport Network (OTN)", ITU-T Recommendation 1136 G.709, March 2003. 1138 [ITU.G.872] 1139 International Telecommunications Union, "Architecture of 1140 optical transport networks", ITU-T Recommendation G.872, 1141 November 2001. 1143 11.2. Informative References 1145 [DWDM-interface-MIB] 1146 Internet Engineering Task Force, "A SNMP MIB to manage the 1147 DWDM optical interface parameters of DWDM applications", 1148 draft-galimkunze-ccamp-dwdm-if-snmp-mib draft-galimkunze- 1149 ccamp-dwdm-if-snmp-mib, July 2011. 1151 [ITU-TG.691] 1152 ITU-T, "Optical interfaces for single channel STM-64 and 1153 other SDH systems with optical amplifiers", 1154 ITU-T Recommendation ITU-T G.691, 2008. 1156 [ITU-TG.693] 1157 ITU-T, "Optical interfaces for intra-office systems", 1158 ITU-T Recommendation ITU-T G.693, 2009. 1160 [ITU-TG.957] 1161 ITU-T, "Optical interfaces for equipments and systems 1162 relating to the synchronous digital hierarchy", 1163 ITU-T Recommendation ITU-T G.957, 2006. 1165 [ITU-TG.692] 1166 ITU-T, "Transmission media characteristics - 1167 Characteristics of optical components and sub-systems", 1168 ITU-T Recommendation ITU-T G.692, 1998. 1170 [ITU-TG.959.1] 1171 ITU-T, "Optical transport network physical layer 1172 interfaces", ITU-T Recommendation ITU-T G.959.1, 2009. 1174 [ITU-TG.8081] 1175 ITU-T, "Terms and definitions for Automatically Switched 1176 Optical Networks (ASON)", ITU-T Recommendation G.8081", 1177 ITU-T Recommendation ITU-T G.8081, September 2010. 1179 Authors' Addresses 1180 Ruediger Kunze (editor) 1181 Deutsche Telekom 1182 Winterfeldtstr. 21-27 1183 10781 Berlin 1184 Germany 1186 Phone: +491702275321 1187 Email: RKunze@telekom.de 1189 Gert Grammel (editor) 1190 Juniper 1191 Oskar-Schlemmer Str. 15 1192 80807 Muenchen 1193 Germany 1195 Phone: +49 1725186386 1196 Email: ggrammel@juniper.net 1198 Dieter Beller (editor) 1199 Nokia 1200 Lorenzstrasse, 10 1201 70435 Stuttgart 1202 Germany 1204 Phone: +4971182143125 1205 Email: Dieter.Beller@nokia.com 1207 Gabriele Galimberti (editor) 1208 Cisco 1209 Via S. Maria Molgora, 48 1210 20871 - Vimercate 1211 Italy 1213 Phone: +390392091462 1214 Email: ggalimbe@cisco.com