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