idnits 2.17.1 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-08.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 date (December 13, 2017) is 2327 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T G.694.1' is mentioned on line 162, but not defined == Missing Reference: 'G.805' is mentioned on line 172, but not defined == Missing Reference: 'G.872' is mentioned on line 180, but not defined == Missing Reference: 'G.8081' is mentioned on line 191, but not defined == Missing Reference: 'ITU-T G.957' is mentioned on line 238, but not defined == Missing Reference: 'ITU-T G.691' is mentioned on line 238, but not defined == Missing Reference: 'ITU-T G.693' is mentioned on line 239, but not defined == Missing Reference: 'ITU-T G.959.1' is mentioned on line 239, but not defined == Missing Reference: 'RFC7689' is mentioned on line 504, but not defined == Missing Reference: 'RFC7792' is mentioned on line 505, but not defined == Missing Reference: 'G.698.2' is mentioned on line 506, but not defined == Missing Reference: 'RFC4208' is mentioned on line 571, but not defined == Unused Reference: 'ITU.G709' is defined on line 1053, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 1069, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 1074, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 1098, but no explicit reference was found in the text == Unused Reference: 'DWDM-interface-MIB' is defined on line 1105, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.691' is defined on line 1111, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.692' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.693' is defined on line 1121, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.8081' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.957' is defined on line 1130, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.959.1' is defined on line 1135, 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 (~~), 26 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: June 16, 2018 Juniper 6 D. Beller 7 Nokia 8 G. Galimberti, Ed. 9 Cisco 10 J. Meuric 11 Orange 12 December 13, 2017 14 A framework for Management and Control of DWDM optical interface 15 parameters 16 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-08 18 Abstract 20 The control and management of DWDM interfaces are a precondition for 21 enhanced multilayer networking. They are needed to ensure an 22 efficient data transport, to meet the requirements requested by 23 today's IP-services and to provide a further automation of network 24 provisioning and operations. This document describes use cases, 25 requirements and solutions for the control and management of optical 26 interface parameters according to different types of single channel 27 DWDM interfaces. The focus is on automating the network provisioning 28 process irrespective on how it is triggered i.e. by EMS, NMS or 29 GMPLS. This document covers management and control considerations in 30 different scenarios of single channel DWDM interfaces. The purpose 31 is to identify the necessary information and processes to be used by 32 control or management systems to properly and efficiently drive the 33 network. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on June 16, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 71 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Comparison of Approaches for Transverse Compatibility . . 5 73 3.1.1. Multivendor DWDM Line System with Transponders . . . 5 74 3.1.2. Integrated Single Channel DWDM Deployments on the 75 Client Site . . . . . . . . . . . . . . . . . . . . . 7 76 4. Solutions for Managing and Controlling Single Channel Optical 77 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.1. Separate Operation and Management Approaches . . . . . . 10 79 4.1.1. Direct Connection to the Management System . . . . . 10 80 4.1.2. Indirect Connection to the DWDM Management System 81 (First Optical Node) . . . . . . . . . . . . . . . . 11 82 4.2. Control Plane Considerations . . . . . . . . . . . . . . 13 83 4.2.1. Considerations Using GMPLS Signaling . . . . . . . . 14 84 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15 86 5.2. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 16 87 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19 88 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21 89 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 96 11.2. Informative References . . . . . . . . . . . . . . . . . 28 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 100 1. Introduction 102 The usage of external single channel DWDM interfaces (e.g. in 103 routers) connected to a DWDM Network (e.g. router connected to a 104 network of ROADMs and optical amplifiers) adds a further networking 105 option for operators but requires an harmonised control and 106 management plane interaction between the different network domains. 108 Carriers deploy their networks today based on transport and packet 109 network infrastructures as domains to ensure high availability and a 110 high level of redundancy combining the Packet and Transport 111 restoration. Both network domains were operated and managed 112 separately. This is the status quo in many carrier networks today. 113 In the case of deployments where the optical transport interface 114 moves into the client device (e.g. router) an interaction between 115 those domains becomes necessary (e.g. Lambda reprovisioning due to 116 an optical restoration). 118 This framework specifies different levels of control and management 119 plane interaction to support the usage of single channel optical 120 interfaces in carrier networks in an efficient manner. The 121 interfaces between the two layers can be wither gray or coloured. 123 Although Optical routing and wavelength assignment based on WSON is 124 out of scope, they can benefit from the optical parameters that are 125 exchanged between the Client and the DWDM Network. Also, the 126 wavelength ordering process and determining the demand for a new 127 wavelength path through the network are out of scope. 129 Note that the Control and Management Planes are two separate entities 130 that may handle the same information in different ways. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 While [RFC2119] describes interpretations of these key words in terms 139 of protocol specifications and implementations, they are used in this 140 document to describe design requirements for protocol extensions. 142 2. Terminology and Definitions 144 The current generation of WDM netwoks are single vendor networks 145 where the optical line system and the transponders are tightly 146 integrated. The DWDM interface migration from integrated 147 transponders to third party transponders or colored interfaces change 148 this scenario and introduces a standardized interface at the level of 149 OCh between the DWDM interface and the DWDM network. 151 Black Link: The Black Link [ITU.G698.2] allows supporting an optical 152 transmitter/receiver pair (of a single vendor or from different 153 vendors) to provide a single optical channel interface and transport 154 it over an optical network composed of amplifiers, filters, add-drop 155 multiplexers these being possibly from different vendors. Therefore 156 the standard defines the ingress and egress parameters for the 157 optical interfaces at the reference points Ss and Rs. 159 Single Channel DWDM Interface: The single channel interfaces to DWDM 160 systems defined in G.698.2, which currently include the following 161 features: channel frequency spacing: 50 GHz and wider (defined in 162 [ITU-T G.694.1]); bit rate of single channel: Up to 10 Gbit/s. 163 Future revisions are expected to include application codes for bit 164 rates up to 40 Gb/s. 166 Forward Error Correction (FEC): FEC is a way of improving the 167 performance of high-capacity optical transmission systems. Employing 168 FEC in optical transmission systems yields system designs that can 169 accept relatively large BER (much more than 10^-12) in the optical 170 transmission line (before decoding). 172 Administrative domain [G.805]: the extent of resources which belong 173 to a single player such as a network operator, a service provider or 174 an end-user. Administrative domains of different players do not 175 overlap amongst themselves. 177 Intra-domain interface (IaDI) [G.872]: A physical interface within an 178 administrative domain. 180 Inter-domain interface (IrDI) [G.872]: A physical interface that 181 represents the boundary between two administrative domains. 183 Management Plane [G.8081]: The management plane performs management 184 functions for the transport plane, the control plane and the system 185 as a whole. It also provides coordination between all the planes. 186 The following management functional areas are performed in the 187 management plane: performance management, fault management, 188 configuration management, accounting management and security 189 management. 191 Control Plane [G.8081]: Through signaling, the control plane sets up 192 and releases connections, may restore a connection in case of a 193 failure, and also performs other functions (e.g., neighbor discovery, 194 topology distribution) in support of those. 196 Transponder: A Transponder is a network element that performs O/E/O 197 (Optical /Electrical/Optical) conversion. In this document it is 198 referred only transponders with 3R (rather than 2R or 1R 199 regeneration) as defined in [ITU.G.872]. 201 Line System: A Line System is a portion of the network including Add 202 Drop Multiplexers (ROADM) Line Amplifiers and the the fibers 203 connecting them. 205 Client DWDM interface: A Transceiver element that performs E/O 206 (Electrical/Optical) conversion. In this document it is referred as 207 the DWDM side of a transponder as defined in [ITU.G.872]. 209 3. Solution Space 211 The solution space of this document is focusing on aspects related to 212 the management and control of single-channel optical interface 213 parameters of physical point-to-point and ring DWDM applications on 214 single-mode optical fibres and allows the direct connection of a wide 215 variety of equipment using a DWDM link, for example 217 1. A digital cross-connect with multiple optical interfaces, 218 supplied by a different vendor from the line system 220 2. Devices as routing, switching or compute nodes, each from a 221 different vendor, providing optical line interfaces 223 3. A combination of the above 225 3.1. Comparison of Approaches for Transverse Compatibility 227 This section describes two ways to achieve transverse compatibility. 228 Section 3.1.1 describes the classic model based on well defined 229 inter-domain interfaces. Section 3.1.2 defines a model ensuring 230 interoperability on the line side of the optical network. 232 3.1.1. Multivendor DWDM Line System with Transponders 234 As illustrated in Figure 1, for this approach interoperability is 235 achieved via the use of optical transponders providing OEO (allowing 236 conversion to appropriate parameters). The optical interfaces can 237 then be any short reach standardized optical interface that both 238 vendors support, such as those found in [ITU-T G.957] [ITU-T G.691], 239 [ITU-T G.693], [ITU-T G.959.1], etc. 241 IrDI IaDI 242 | | 243 . . 244 | +----------------------------|----+ 245 . | + WDM Domain + . | 246 | | |\ /| | | 247 +------+ . | | \ |\ / | . | +------+ 248 | TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T-+---->--| RX/ | 249 | RX |--<--+---+--T/-| |----- /|-----| |--.-\T-+----<--| TX | 250 +------+ | | | / \| \ | | | +------+ 251 . | |/ \| . | 252 | | + + | | 253 . +----------------------------.----+ 254 | | 256 TX/RX = Single channel non-DWDM interfaces 257 T/ = Transponder 258 OM = Optical Mux 259 OD = Optical Demux 261 Figure 1: Inter and Intra-Domain Interface Identification 263 In the scenario of Figure 1 the administrative domain is defined by 264 the Interdomain Interface (IrDI). This interface terminates the DWDM 265 domain. The line side is characterized by the IaDI. This interface 266 specifies the internal parameter set of the optical administrative 267 domain. In the case of a client DWDM interface deployment this 268 interface moves into the client device and extends the optical and 269 administrative domain towards the client node. ITU-T G.698.2 for 270 example specifies a set of parameter set for a certain set of 271 applications. 273 This document elaborates only the IaDI Interface as shown in Figure 1 274 as transversely compatible and multi-vendor interface within one 275 administrative domain controlled by the network operator. 277 SNMP/SMI, Yang models and LMP TLV to support the direct exchange of 278 information between the client and the network management and control 279 plane will be specified in further documents. 281 3.1.2. Integrated Single Channel DWDM Deployments on the Client Site 283 In case of a deployment as shown in Figure 2, through the use of DWDM 284 interfaces, multi-vendor interconnection can also be achieved. Among 285 the possible use cases, it may be used to remove the need for one 286 short reach transmitter and receiver pair per channel (eliminating 287 the transponders). 289 Figure 2 shows a set of reference points, for single-channel 290 connection (Ss and Rs) between transmitters (Tx) and receivers (Rx). 291 Here the DWDM network elements include an optical multiplexer (OM) 292 and an optical demultiplexer (OD) (which are used as a pair with the 293 peer element), one or more optical amplifiers and may also include 294 one or more OADMs. 296 |==================== Black Link =======================| 298 +-------------------------------------------------+ 299 Ss | | DWDM Network Elements | | Rs 300 +---+ | | | \ / | | | +---+ 301 Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1 302 +---+ | | | | | +------+ | | | | | +---+ 303 +---+ | | | | | | | | | | | | +---+ 304 Tx L2---|->| OM |-|>|------|->| ROADM|--|------|->| OD |--|-->Rx L2 305 +---+ | | | | | | | | | | | | +---+ 306 +---+ | | | | | +------+ | | | | | +---+ 307 Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 308 +---+ | | / | Link +----|--|----+ Link | \ | | +---+ 309 +-----------+ | | +----------+ 310 +--+ +--+ 311 |==== Black Link ====| | | 312 v | 313 +-----+ +-----+ 314 |RxLx | |TxLx | 315 +-----+ +-----+ 317 Ss = Reference point at the DWDM network element tributary output 318 Rs = Reference point at the DWDM network element tributary input 319 Lx = Lambda x 320 OM = Optical Mux 321 OD = Optical Demux 322 ROADM = Reconfigurable Optical Add Drop Mux 324 Linear DWDM network as per ITU-T G.698.2 326 Figure 2: Linear Black Link 328 The single administrative domain may consist of several vendor 329 domains. Even in that case a common network management and control 330 is required to ensure a consistent operation and provisioning of the 331 entire connection. 333 SNMP/SMI, Yang models and LMP TLV to support the direct exchange of 334 information between the client and the network management and control 335 plane will be specified in further documents. 337 4. Solutions for Managing and Controlling Single Channel Optical 338 Interface 340 Operation and management of WDM systems is traditionally seen as a 341 homogenous group of tasks that could be carried out best when a 342 single management system or a hierarchical management system is used. 343 Currently each WDM vendor provides an Element Management System (EMS) 344 that also provisions the wavelengths. In a multi-vendor line system, 345 such single-vendor EMS requirement is no more effective. New methods 346 of managing and controlling line systems need to be looked at. 348 Therefore from the operational point of view the following approaches 349 will be considered to manage and operate optical interfaces. 351 1. Separate operation and management of client device and the 352 transport network whereas the interface of the client belongs to 353 the administrative domain of the transport network and will be 354 managed by the transport group. This results in two different 355 approaches to send information to the management system 357 a. Direct connection from the client node to the transport 358 management system, ensuring a management of the DWDM interface of 359 the optical network (e.g. EMS, NMS) 361 b. Indirect connection to the management system of the optical 362 network using a protocol (e.g. LMP) between the client device 363 and the directly connected WDM system node to exchange management 364 information with the optical domain 366 2. Common operation and management of client device including the 367 single channel DWDM part and the Transport network 369 The first option keeps the status quo in large carrier networks as 370 mentioned above. In that case it must be ensured that the full FCAPS 371 Management (Fault, Configuration, Accounting, Performance and 372 Security) capabilities are supported. This means from the management 373 staff point of view nothing changes. The transceiver/receiver 374 optical interface will be part of the optical management domain and 375 will be managed from the transport management staff. 377 The second solution addresses the case where underlying WDM transport 378 network is mainly used to interconnect a homogeneous set of client 379 nodes (e.g. IP routers or digital crossconnects). Since the service 380 creation and restoration could be done by the higher layers (e.g. 382 IP), this may lead to an efficient network operation and a higher 383 level of integration. 385 4.1. Separate Operation and Management Approaches 387 4.1.1. Direct Connection to the Management System 389 As depicted in Figure 3 (case 1a) one possibility to manage the 390 optical interface within the client domain is a direct connection to 391 the management system of the optical domain. This ensures 392 manageability as usual. 394 +-----+ 395 | NMS | 396 |_____| 397 /_____/ 398 | 399 | 400 | 401 +---+---+ 402 +----->+ EMS | 403 / | | 404 / +-------+ 405 / | MI SNMP or Yang 406 SNMP / or Yang | DCN Network 407 --------------------+------------------------------- 408 / +------+-----------------------+ 409 / | +| WDM Domain + | 410 / | |\ /| | 411 +---+--+ | | \ |\ / | | +------+ 412 | CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL | 413 | |-/C------+-----| |----- /|-----| |----+-------/C-| | 414 +------+ | | / \| \ | | +------+ 415 | |/ \| | 416 | + + | 417 +------------------------------+ 419 CL = Client Device 420 /C = Single Channel Optical Interface 421 OM = Optical Mux 422 OD = Optical Demux 423 EMS = Element Management System 424 MI = Management Interface 425 DCN = Data Control Network 427 Figure 3: Connecting Single Channel optical interfaces to the 428 Transport Management system 430 The exchange of management information between client device and the 431 management system assumes that some form of a direct management 432 communication link exists between the client device and the DWDM 433 management system (e.g. EMS). This may be an Ethernet Link or a DCN 434 connection (management communication channel MCC). 436 It must be ensured that the optical network interface can be managed 437 in a standardized way to enable interoperable solutions between 438 different optical interface vendors and vendors of the optical 439 network management application. [RFC3591] defines managed objects 440 for the optical interface type but needs further extension to cover 441 the optical parameters required by this framework document. 443 Note that a software update of the optical interface components of 444 the client nodes must not lead obligatory to an update of the 445 software of the EMS and vice versa. 447 4.1.2. Indirect Connection to the DWDM Management System (First Optical 448 Node) 450 An alternative as shown in Figure 4 should be used in cases where a 451 more integrated relationship between transport node (e.g. OM or OD 452 or ROADM) and client device is aspired. In that case a combination 453 of control plane features and manual management will be used. 455 +-----+ 456 | NMS | 457 |_____| 458 /_____/ 459 | 460 | 461 +---+---+ 462 | EMS | 463 | | 464 +-------+ 465 | MI SNMP or Yang 466 | 467 LMP +------+-----------------------+ 468 +------------+---+ +| + | 469 | | | |\ /| | 470 +---+--+ | +-+ \ |\ / | | +------+ 471 | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | 472 | |-/C------+--- -| |----- /|-----| |----+-------/C-| | 473 +------+ | | / \| \ | | +------+ 474 | |/ \| | 475 | + + | 476 +------------------------------+ 478 CL = Client Device 479 /C = Single Channel optical Interface 480 OM = Optical Mux 481 OD = Optical Demux 482 EMS= Element Management System 483 MI= Management Interface 485 Figure 4: Direct connection between peer node and first optical 486 network node 488 For information exchange between the client node and the direct 489 connected node of the optical transport network LMP as specified in 490 [RFC4209] should be used. This extension of LMP may be used between 491 a peer node and an adjacent optical network node as depicted in 492 Figure 4. 494 At the time of writing this document, LMP does not yet support the 495 transmission of configuration data (information). This functionality 496 must be added to the protocol. The use of LMP assumes that some form 497 of a control channel exists between the client node and the WDM 498 equipment. This may be a dedicated lambda or an Ethernet Link. 500 4.2. Control Plane Considerations 502 The concept of integrated single channel DWDM interfaces equally 503 applies to management and control plane mechanisms. GMPLS control 504 plane protocols have been extended for WSON, e.g. [RFC7689] for 505 fixed grid signal and for flexi-grid [RFC7792]. One important aspect 506 of the Black Link [G.698.2] is the fact that it includes the 507 wavelength that is supported by the given link. Therefore, the link 508 can logically be considered as a fiber that is transparent only for a 509 single wavelength. In other words, the wavelength becomes a 510 characteristic of the link itself. 512 Nevertheless the procedure to light up the fiber may vary depending 513 on the implementation. Since the implementation is unknown a priori, 514 different sequences to light up a wavelength need to be considered: 516 1. Interface first, interface tuning: The transmitter is switched on 517 and the link is immediately transparent to its wavelength. This 518 requires the transmitter to carefully tune power and frequency 519 not overload the line system or to create transients. 521 2. Interface first, OLS tuning: The transmitter is switched on first 522 and can immediately go to the max power allowed since the OLS 523 performs the power tuning. This leads to an intermediate state 524 where the receiver does not receive a valid signal while the 525 transmitter is sending out one. Alarm suppression mechanisms 526 shall be employed to overcome that condition. 528 3. OLS first, interface tuning: At first the OLS is tuned to be 529 transparent for a given wavelength, then transponders need to be 530 tuned up. Since the OLS in general requires the presence of a 531 wavelength to fine-tune its internal facilities there may be a 532 period where a valid signal is transmitted but the receiver is 533 unable to detect it. This equally need to be covered by alarm 534 suppression mechanisms. 536 4. OLS first, OLS tuning: The OLS is programmed to be transparent 537 for a given wavelength, then the interfaces need to be switched 538 on and further power tuning takes place. The sequencing of 539 enabling the link needs to be covered as well. 541 The preferred way to address these in a Control Plane enabled network 542 is neighbour discovery including exchange of link characteristics and 543 link property correlation. The general mechanisms are covered in 544 [RFC4209] and [RFC4204] which provides the necessary protocol 545 framework to exchange those characteristics between client and Black 546 Link. LMP-WDM is not intended for exchanging routing or signaling 547 information nor to provision the lambda in the transceiver but 548 covers: 550 1. Control channel management 552 2. Link property correlation 554 3. Link verification 556 4. Fault management 558 Extensions to LMP covering the parameter sets (e.g. application 559 codes) are needed. Additionally, when client and server side are 560 managed by different operational entities, the link state may be 561 useful to help the management system to do troubleshooting or alarm 562 correlation. 564 4.2.1. Considerations Using GMPLS Signaling 566 The deployment of single channel optical interfaces is leading to 567 some functional changes related to the control plane models and has 568 therefore some impact on the existing interfaces especially in the 569 case of a model where the edge node requests resources from the core 570 node and the edge node do not participate in the routing protocol 571 instance that runs among the core nodes. [RFC4208] defines the GMPLS 572 UNI that can be used between edge and core node. In case of 573 integrated interfaces deployment additional functionalities are 574 needed to setup a connection. 576 It is necessary to differentiate between topology/signalling 577 information and configuration parameters that are needed to setup a 578 wavelength path. Using RSVP-TE could be used for the signalling and 579 the reservation of the wavelength path. But there are additional 580 information needed before RSVP-TE can start the signalling process. 581 There are three possibilities to proceed: 583 a. Using RSVP-TE only for the signalling and LMP as described above 584 to exchange information on the configured optical interface 585 within the edge node 587 b. RSVP-TE (typically with loose ERO) to transport additional 588 information 590 c. Leaking IGP information instead of exchanging this information 591 needed from the optical network to the edge node (UNI will be 592 transformed to a border-peer model, see [RFC5146] ) 594 Furthermore following issues should be addressed: 596 a) The transceivers of peering edge nodes must be compatible. For 597 example, it may be required to know about FEC, modulation scheme, 598 etc. Depending on where the information is available, compatibility 599 check may either happen before signaling, when the signaling reaches 600 the optical network (e.g. at path computation time), or in the tail 601 end node. An extended version of LMP is needed to exchange this 602 information in case a. above, and to RSVP-TE as well in b. It would 603 be helpful to define some common profiles that will be supported 604 (e.g. the "application identifier") to summarize interface 605 capabilities: if both profiles match, signaling can succeed and 606 provisioning be achieved. 608 b) Due to the bidirectional wavelength path that must be setup, the 609 upstream edge node must include a wavelength value into the RSVP-TE 610 Path message. But in the case of a UNI model the client device may 611 not have full information about which wavelength must/should be 612 selected, whereas this information must be exchanged between the edge 613 and the core node. The special value defined in 614 [Network-Assigned-Upstream-Label] allows the optical network to 615 assign the actual wavelength to be used by the upstream transponder, 616 which is a simple and efficient solution to this issue. 618 5. Use Cases 620 A comparison with the traditional operation scenarios provides an 621 insight of similarities and distinctions in operation and management 622 of DWDM interfaces. The following use cases provide an overview 623 about operation and maintenance processes. 625 5.1. Service Setup 627 It is necessary to differentiate between different operational issues 628 for setting up a light path (a DWDM connection is specific in having 629 defined maximum impairments) within an operational network. 631 The first step is to determine if transceivers located at different 632 end-points are interoperable, i.e. support a common set of 633 operational parameters. In this step it is required to determine 634 transceiver capabilities in a way to be able to correlate them for 635 interoperability purposes. Such parameters include modulation 636 scheme, modulation parameters, FEC to name a few. If both 637 transceivers are controlled by the same NMS or CP, such data is 638 readily available. However in cases like Figure 4, a protocol needs 639 to be used to inform the controlling instance (NMS or CP) about 640 transceiver parameters. It is suggested to extend LMP for that 641 purpose. 643 The second step is to determine the feasibility of a lightpath 644 between two transceivers without applying an optical signal. 645 Understanding the limitations of the transceiver pair, a path through 646 tho optical network has to be found, whereby each path has an 647 individual set of impairments deteriorating a wavelength traveling 648 along that path. Since a single transceiver can support multiple 649 parameter sets, the selection of a path may limit the permissible 650 parameter sets determined in previous steps. 652 The third step is then to setup the connection itself and to 653 determine the Wavelength. This is done using the NMS of the optical 654 transport network or by means of a control plane interaction such as 655 signaling and includes the path information as well as the parameter 656 set information necessary to enable communication. 658 In a fourth step, optical monitoring is activated in the WDM network 659 in order to monitor the status of the connection. The monitor 660 functions of the optical interfaces at the terminals are also 661 activated in order to monitor the end to end connection. 663 Furthermore it should be possible to automate this step. After 664 connecting the client device to the neighbor control plane-enabled 665 transport node, a control adjacency may be automatically established, 666 e.g. using LMP. 668 5.2. Link Monitoring Use Cases 670 The use cases described below are assuming that power monitoring 671 functions are available in the ingress and egress network element of 672 the DWDM network, respectively. By performing link property 673 correlation it would be beneficial to include the current transmit 674 power value at reference point Ss and the current received power 675 value at reference point Rs. For example if the Client transmitter 676 power has a value of 0dBm and the ROADM interface measured power is 677 -6dBm the fiber patch cord connecting the two nodes may be pinched or 678 the connectors are dirty. As discussed before, the actual path or 679 selection of a specific wavelength within the allowed set is outside 680 the scope of LMP. The computing entities (e.g. the first optical 681 node originating the circuit) can rely on GMPLS IGP (OSPF) to 682 retrieve all the information related to the network, calculate the 683 path to reach the endpoint and signal the path implementation through 684 the network via RSVP-TE. 686 G.698.2 defines a single channel optical interface for DWDM systems 687 that allows interconnecting network-external optical transponders 688 across a DWDM network. The optical transponders are external to the 689 DWDM network. This so-called 'Black Link' approach illustrated in 690 Fig. 5-1 of G.698.2 and a copy of this figure is provided below in 691 Figure 5. The single channel fiber link between the Ss/Rs reference 692 points and the ingress/egress port of the network element on the 693 domain boundary of the DWDM network (DWDM border NE) is called access 694 link. Based on the definition in G.698.2 it is part of the DWDM 695 network. The access link is typically realized as a passive fiber 696 link that has a specific optical attenuation (insertion loss). As 697 the access link is an integral part of the DWDM network, it is 698 desirable to monitor its attenuation. Therefore, it is useful to 699 detect an increase of the access link attenuation, for example, when 700 the access link fiber has been disconnected and reconnected 701 (maintenance) and a bad patch panel connection (connector) resulted 702 in a significantly higher access link attenuation (loss of signal in 703 the extreme case of an open connector or a fiber cut). In the 704 following section, two use cases are presented and discussed: 706 1) pure access link monitoring 707 2) access link monitoring with a power control loop 709 These use cases require a power monitor as described in G.697 (see 710 section 6.1.2), that is capable to measure the optical power of the 711 incoming or outgoing single channel signal. The use case where a 712 power control loop is in place could even be used to compensate an 713 increased attenuation if the optical transmitter can still be 714 operated within its output power range defined by its application 715 code. 717 Use case 1: Access Link monitoring 719 +--------------------------+ 720 | P(in) = P(Tx) - a(Tx) | 721 | ___ | 722 +----------+ | \ / Power Monitor | 723 | | P(Tx) | V P(in) | 724 | +----+ | Ss //\\ | | |\ | 725 | | TX |----|-----\\//------------------->| \ | 726 | +----+ | Access Link (AL-T) | . | | | 727 | | attenuation a(Tx) | . | |==============> 728 | | | . | | | 729 | External | | --->| / | 730 | Optical | | |/ | 731 |Transpond.| | P(out) | 732 | | | ___ | 733 | | | \ / Power Monitor | 734 | | P(Rx) | V P(out) | 735 | +----+ | Rs //\\ | | |\ | 736 | | RX |<---|-----\\//--------------------| \ | 737 | +----+ | Access Link (AL-R) | . | | | 738 | | Attenuation a(Rx) | . | |<============== 739 +----------+ | . | | | 740 | <---| / | 741 P(Rx) = P(out) - a(Rx) | |/ | 742 | | 743 | ROADM | 744 +--------------------------+ 746 - For AL-T monitoring: P(Tx) and a(Tx) must be known 747 - For AL-R monitoring: P(RX) and a(Rx) must be known 749 An alarm shall be raised if P(in) or P(Rx) drops below a 750 configured threshold (t [dB]): 751 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 752 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 753 - a(Tx) =| a(Rx) 755 Alarms and events can be shared between Client and Network 756 via LMP. 758 Figure 5: Access Link Power Monitoring 760 5.2.1. Pure Access Link (AL) Monitoring Use Case 762 Figure 6 illustrates the access link monitoring use case and the 763 different physical properties involved that are defined below: 765 - Ss, Rs: Single Channel reference points 766 - P(Tx): current optical output power of transmitter Tx 767 - a(Tx): access link attenuation in Tx direction (external 768 transponder point of view) 769 - P(in): measured current optical input power at the input port 770 of border DWDM NE 771 - t: user defined threshold (tolerance) 772 - P(out): measured current optical output power at the output port 773 of border DWDM NE 774 - a(Rx): access link attenuation in Rx direction (external 775 transponder point of view) 776 - P(Rx): current optical input power of receiver Rx 778 Description: 779 - The access link attenuation in both directions (a(Tx), a(Rx)) 780 is known or can be determined as part of the commissioning 781 process. Typically, both values are very similar. 782 - A threshold value t has been configured by the operator. This 783 should also be done during commissioning. 784 - A control plane protocol is in place that allows 785 to periodically send the optical power values P(Tx) and P(Rx) 786 to the control plane protocol instance on the DWDM border NE. 787 This is illustrated in Figure 3. 788 - The DWDM border NE is capable to periodically measure the optical 789 power Pin and Pout as defined in G.697 by power monitoring points 790 depicted as yellow triangles in the figures below. 792 Access Link monitoring process: 793 - Tx direction: the measured optical input power Pin is compared 794 with the expected optical input power P(Tx) - a(Tx). If the 795 measured optical input power P(in) drops below the value 796 (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating 797 that the access link attenuation has exceeded a(Tx) + t. 798 - Rx direction: the measured optical input power P(Rx) is 799 compared with the expected optical input power P(out) - a(Rx). 800 If the measured optical input power P(Rx) drops below the value 801 (P(out) - a(Rx) - t) a low power alarm shall be raised indicating 802 that the access link attenuation has exceeded a(Rx) + t. 803 - to avoid toggling errors, the low power alarm threshold shall be 804 lower than the alarm clear threshold. 806 Use case 1: Access Link monitoring 808 +----------+ +--------------------------+ 809 | +------+ | P(Tx), P(Rx) | +-------+ | 810 | | | | =================> | | | | 811 | | LMP | | P(in), P(out) | | LMP | | 812 | | Agent| | <================= | | Agent | | 813 | +------+ | | +-------+ | 814 | | | | 815 | | | P(in) - P(Tx) - a(Tx) | 816 | | | ___ | 817 | | | \ / Power Monitor | 818 | | P(Tx) | V | 819 | +----+ | Ss //\\ | | |\ | 820 | | TX |----|-----\\//------------------->| \ | 821 | +----+ | Access Link (AL-T) | . | | | 822 | | attenuation a(Tx) | . | |==============> 823 | | | . | | | 824 | External | | --->| / | 825 | Optical | | |/ | 826 |Transpond.| | P(out) | 827 | | | ___ | 828 | | | \ / Power Monitor | 829 | | P(Rx) | V | 830 | +----+ | Rs //\\ | | |\ | 831 | | RX |<---|-----\\//--------------------| \ | 832 | +----+ | Access Link (AL-R) | . | | | 833 | | Attenuation a(Rx) | . | |<============== 834 +----------+ | . | | | 835 | <---| / | 836 P(Rx) = P(out) - a(Rx) | |/ | 837 | | 838 | ROADM | 839 +--------------------------+ 841 - For AL-T monitoring: P(Tx) and a(Tx) must be known 842 - For AL-R monitoring: P(RX) and a(Rx) must be known 843 An alarm shall be raised if P(in) or P(Rx) drops below a 844 configured threshold (t [dB]): 845 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 846 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 847 - a(Tx) = a(Rx) 849 Alarms and events can be shared between Client and Network 850 via LMP according to [RFC4204] and [RFC4209] 851 Figure 6: Extended LMP Model 853 5.2.2. Power Control Loop Use Case 855 This use case is based on the access link monitoring as 856 described above. In addition, the border NE is running a power 857 control application that is capable to control the optical output 858 power of the single channel tributary signal at the output port 859 of the border DWDM NE (towards the external receiver Rx) and the 860 optical output power of the single channel tributary signal at 861 the external transmitter Tx within their known operating range. 862 The time scale of this control loop is typically relatively slow 863 (e.g. some 10s or minutes) because the access link attenuation 864 is not expected to vary much over time (the attenuation only 865 changes when re-cabling occurs). 866 From a data plane perspective, this use case does not require 867 additional data plane extensions. It does only require a protocol 868 extension in the control plane (e.g. this LMP draft) that allows 869 the power control application residing in the DWDM border NE to 870 modify the optical output power of the DWDM domain-external 871 transmitter Tx within the range of the currently used application 872 code. Figure 7 below illustrates this use case utilizing 873 LMP with the extensions identified in this document. 875 Use case 2: Power Control Loop 877 +----------+ +--------------------------+ 878 | +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ | 879 | | | | ====================> | | | | Power | | 880 | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | | 881 | | | | <==================== | | | | Loop | | 882 | +------+ | | +-------+ +--------+ | 883 | | | | | 884 | +------+ | | P(in) = P(Tx) - a(Tx) | 885 | |C.Loop| | | ___ | 886 | +------+ | | \ / Power Monitor | 887 | | | P(Tx) | V | 888 | +------+ | Ss //\\ | | |\ | 889 | | TX |>----|-----\\//---------------------->| \ | 890 | +------+ | Access Link (AL-T) | . | | | 891 | VOA(Tx) | attenuation a(Tx) | . | |==============> 892 | | | . | | | 893 | External | | --->| / | 894 | Optical | | |/ | 895 |Transpond.| | P(out) | 896 | | | ___ | 897 | | | \ / Power Monitor | 898 | | P(Rx) | V | 899 | +----+ | Rs //\\ | | VOA(out) |\ | 900 | | RX |<---|-----\\//---------------------<|-------| \ | 901 | +----+ | Access Link (AL-R) | . | | | 902 | | attenuation a(Rx) | . | |<======= 903 +----------+ | VOA(out) | | | 904 | <--<|-------| / | 905 P(Rx) = P(out) - a(Rx) | |/ | 906 | | 907 | ROADM | 908 +--------------------------+ 910 Figure 7: Power control loop 912 - The power control loop in transponders and ROADMs controls 913 the Variable Optical Attenuators (VOA) to adjust the proper 914 power in base of the ROADM and Receiver caracteristics and 915 the Access Link attenuation 917 6. Requirements 919 Even if network architectures becomes more complex, management and 920 operation as well as the provisioning process should have a higher 921 degree of automation or should be fully automated. Simplifying and 922 automating the entire management and provisioning process of the 923 network in combination with a higher link utilization and faster 924 restoration times will be the major requirements that have been 925 addressed in this section. 927 Data plane interoperability as defined for example in [ITU.G698.2] is 928 a precondition to take full benefit from standardized interfaces 929 between network and control/management plane. 931 The following requirements are focusing on the usage of DWDM 932 interfaces. 934 1 A standardized procedure to setup an optical connection MUST 935 be defined and implemented in DWDM and client devices 936 (containing the single channel optical interface). 938 2 In order to ensure a lean management and provisioning of single 939 channel interfaces, the management and control plane of both the 940 client and DWDM network MUST be aware of the right set of 941 parameters. Such parameters define the interfaces and the optical 942 network and are needed to properly setup the optical connection. 944 3 A standard-based northbound API (to network management system) 945 based on Netconf SHOULD be supported, alternatively SNMP MAY 946 be supported too. 948 4 A standard-based data model for single channel interfaces MUST be 949 supported to exchange optical parameters with control/management 950 plane. 952 5 Netconf SHOULD be used also for configuration of the single 953 channel interfaces including the power setting 955 6 LMP SHOULD be extended and used in cases where optical 956 parameters need to be exchanged between two nodes to correlate 957 link characteristics and adopt the working mode of the single 958 channel interface. 960 7 LMP MAY be used to adjust the output power of the single 961 channel DWDM interface to ensure that the interface works in 962 the right range. 964 8 RSVP-TE SHOULD be used to exchange some relevant parameters 965 between the client and the optical node (e.g. the label value), 966 without preventing the network to remain in charge of the optical 967 path computation 969 9 Power monitoring functions at both ends of the DWDM connection 970 MAY be used to further automate the setup and shoutdown 971 process of the optical interfaces. 973 10 In fault cases, the network SHOULD be able to recover wavelengths, 974 either using pre-defined paths or dynamic re-routing. 976 11 LMP MAY be used to monitor and observe the access link. 978 7. Acknowledgements 980 The authors would like to thank all who supported the work with 981 fruitful discussions and contributions. 983 8. IANA Considerations 985 This memo includes no request to IANA. 987 9. Security Considerations 989 The architecture and solution space in scope of this framework 990 imposes no additional requirements to the security models already 991 defined in RFC5920 for packet/optical networks using GMPLS, covering 992 also Control Plane and Management interfaces. Respective security 993 mechanisms of the components and protocols, e.g. LMP security 994 models, can be applied unchanged. 996 As this framework is focusing on the single operator use case, the 997 security concerns can be relaxed to a subset compared to a setup 998 where information is exchanged between external parties and over 999 external interfaces. 1001 Concerning the access control to Management interfaces, security 1002 issues can be generally addressed by authentication techniques 1003 providing origin verification, integrity and confidentiality. 1004 Additionally, access to Management interfaces can be physically or 1005 logically isolated, by configuring them to be only accessible out-of- 1006 band, through a system that is physically or logically separated from 1007 the rest of the network infrastructure. In case where management 1008 interfaces are accessible in-band at the client device or within the 1009 optical transport netork domain, filtering or firewalling techniques 1010 can be used to restrict unauthorized in-band traffic. Authentication 1011 techniques may be additionally used in all cases. 1013 10. Contributors 1014 Arnold Mattheus 1015 Deutsche Telekom 1016 Darmstadt 1017 Germany 1018 email arnold.Mattheus@telekom.de 1020 Manuel Paul 1021 Deutsche Telekom 1022 Berlin 1023 Germany 1024 email Manuel.Paul@telekom.de 1026 Josef Roese 1027 Deutsche Telekom 1028 Darmstadt 1029 Germany 1030 email j.roese@telekom.de 1032 Frank Luennemann 1033 Deutsche Telekom 1034 Muenster 1035 Germany 1036 email Frank.Luennemann@telekom.de 1038 11. References 1040 11.1. Normative References 1042 [ITU.G.872] 1043 International Telecommunications Union, "Architecture of 1044 optical transport networks", ITU-T Recommendation G.872, 1045 November 2001. 1047 [ITU.G698.2] 1048 International Telecommunications Union, "Amplified 1049 multichannel dense wavelength division multiplexing 1050 applications with single channel optical interfaces", 1051 ITU-T Recommendation G.698.2, November 2009. 1053 [ITU.G709] 1054 International Telecommunications Union, "Interface for the 1055 Optical Transport Network (OTN)", ITU-T Recommendation 1056 G.709, March 2003. 1058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1059 Requirement Levels", BCP 14, RFC 2119, 1060 DOI 10.17487/RFC2119, March 1997, 1061 . 1063 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1064 Schoenwaelder, Ed., "Structure of Management Information 1065 Version 2 (SMIv2)", STD 58, RFC 2578, 1066 DOI 10.17487/RFC2578, April 1999, 1067 . 1069 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1070 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1071 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 1072 . 1074 [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1075 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 1076 STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, 1077 . 1079 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1080 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 1081 . 1083 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 1084 Managed Objects for the Optical Interface Type", RFC 3591, 1085 DOI 10.17487/RFC3591, September 2003, 1086 . 1088 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 1089 DOI 10.17487/RFC4204, October 2005, 1090 . 1092 [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management 1093 Protocol (LMP) for Dense Wavelength Division Multiplexing 1094 (DWDM) Optical Line Systems", RFC 4209, 1095 DOI 10.17487/RFC4209, October 2005, 1096 . 1098 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 1099 Lambda-Switch-Capable (LSC) Label Switching Routers", 1100 RFC 6205, DOI 10.17487/RFC6205, March 2011, 1101 . 1103 11.2. Informative References 1105 [DWDM-interface-MIB] 1106 Internet Engineering Task Force, "A SNMP MIB to manage the 1107 DWDM optical interface parameters of DWDM applications", 1108 draft-galimkunze-ccamp-dwdm-if-snmp-mib draft-galimkunze- 1109 ccamp-dwdm-if-snmp-mib, July 2011. 1111 [ITU-TG.691] 1112 ITU-T, "Optical interfaces for single channel STM-64 and 1113 other SDH systems with optical amplifiers", 1114 ITU-T Recommendation ITU-T G.691, 2008. 1116 [ITU-TG.692] 1117 ITU-T, "Transmission media characteristics - 1118 Characteristics of optical components and sub-systems", 1119 ITU-T Recommendation ITU-T G.692, 1998. 1121 [ITU-TG.693] 1122 ITU-T, "Optical interfaces for intra-office systems", 1123 ITU-T Recommendation ITU-T G.693, 2009. 1125 [ITU-TG.8081] 1126 ITU-T, "Terms and definitions for Automatically Switched 1127 Optical Networks (ASON)", ITU-T Recommendation G.8081", 1128 ITU-T Recommendation ITU-T G.8081, September 2010. 1130 [ITU-TG.957] 1131 ITU-T, "Optical interfaces for equipments and systems 1132 relating to the synchronous digital hierarchy", 1133 ITU-T Recommendation ITU-T G.957, 2006. 1135 [ITU-TG.959.1] 1136 ITU-T, "Optical transport network physical layer 1137 interfaces", ITU-T Recommendation ITU-T G.959.1, 2009. 1139 [Network-Assigned-Upstream-Label] 1140 Internet Engineering Task Force, "Generalized Multi- 1141 Protocol Label Switching (GMPLS) Resource reSerVation 1142 Protocol with Traffic Engineering (RSVP- TE) mechanism 1143 that enables the network to assign an upstream label for a 1144 bidirectional LSP", draft-ietf-teas-network-assigned- 1145 upstream-label draft-ietf-teas-network-assigned-upstream- 1146 label, June 2017. 1148 [RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support 1149 Operation of MPLS-TE over GMPLS Networks", RFC 5146, 1150 DOI 10.17487/RFC5146, March 2008, 1151 . 1153 Authors' Addresses 1155 Ruediger Kunze (editor) 1156 Deutsche Telekom 1157 Winterfeldtstr. 21-27 1158 10781 Berlin 1159 Germany 1161 Phone: +491702275321 1162 Email: RKunze@telekom.de 1164 Gert Grammel (editor) 1165 Juniper 1166 Oskar-Schlemmer Str. 15 1167 80807 Muenchen 1168 Germany 1170 Phone: +49 1725186386 1171 Email: ggrammel@juniper.net 1173 Dieter Beller 1174 Nokia 1175 Lorenzstrasse, 10 1176 70435 Stuttgart 1177 Germany 1179 Phone: +4971182143125 1180 Email: Dieter.Beller@nokia.com 1182 Gabriele Galimberti (editor) 1183 Cisco 1184 Via S. Maria Molgora, 48c 1185 20871 - Vimercate 1186 Italy 1188 Phone: +390392091462 1189 Email: ggalimbe@cisco.com 1190 Julien Meuric 1191 Orange 1192 2, Avenue Pierre Marzin 1193 22307 Lannion Cedex 1194 France 1196 Phone: +33 1197 Email: julien.meuric@orange.com