idnits 2.17.1 draft-ietf-ccamp-wson-impairments-10.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 (January 5, 2012) is 4489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.sup39' is mentioned on line 382, but not defined == Unused Reference: 'G.Sup39' is defined on line 1196, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Lee 2 Huawei 3 G. Bernstein 4 Grotto Networking 5 D. Li 6 Huawei 7 G. Martinelli 8 Cisco 10 Internet Draft 11 Intended status: Informational January 5, 2012 12 Expires: July 2012 14 A Framework for the Control of Wavelength Switched Optical Networks 15 (WSON) with Impairments 16 draft-ietf-ccamp-wson-impairments-10.txt 18 Abstract 20 As an optical signal progresses along its path, it may be altered by 21 the various physical processes in the optical fibers and devices it 22 encounters. When such alterations result in signal degradation, 23 these processes are usually referred to as "impairments". These 24 physical characteristics may be important constraints to consider 25 when using a GMPLS control plane to support path setup and 26 maintenance in wavelength switched optical networks. 28 This document provides a framework for applying GMPLS protocols and 29 the PCE architecture to support Impairment Aware Routing and 30 Wavelength Assignment (IA-RWA) in wavelength switched optical 31 networks. Specifically, this document discusses key computing 32 constraints, scenarios and architectural processes: Routing, 33 Wavelength Assignment, and Impairment Validation. This document does 34 not define optical data plane aspects; impairment parameters, 35 measurement of, or assessment and qualification of a route, but 36 rather it describes the architectural and information components for 37 protocol solutions. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF), its areas, and its working groups. Note that 46 other groups may also distribute working documents as Internet- 47 Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six 50 months and may be updated, replaced, or obsoleted by other documents 51 at any time. It is inappropriate to use Internet-Drafts as 52 reference material or to cite them other than as "work in progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/ietf/1id-abstracts.txt 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html 60 This Internet-Draft will expire on July 5, 2012. 62 Copyright Notice 64 Copyright (c) 2012 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with 72 respect to this document. Code Components extracted from this 73 document must include Simplified BSD License text as described in 74 Section 4.e of the Trust Legal Provisions and are provided without 75 warranty as described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction...................................................3 80 2. Terminology....................................................4 81 3. Applicability..................................................6 82 4. Impairment Aware Optical Path Computation......................7 83 4.1. Optical Network Requirements and Constraints..............8 84 4.1.1. Impairment Aware Computation Scenarios...............8 85 4.1.2. Impairment Computation and Information Sharing 86 Constraints.................................................9 87 4.1.3. Impairment Estimation Process.......................11 88 4.2. IA-RWA Computation and Control Plane Architectures.......12 89 4.2.1. Combined Routing, WA, and IV........................14 90 4.2.2. Separate Routing, WA, or IV.........................14 91 4.2.3. Distributed WA and/or IV............................15 92 4.3. Mapping Network Requirements to Architectures............16 93 5. Protocol Implications.........................................18 94 5.1. Information Model for Impairments........................19 95 5.2. Routing..................................................20 96 5.3. Signaling................................................20 97 5.4. PCE......................................................21 98 5.4.1. Combined IV & RWA...................................21 99 5.4.2. IV-Candidates + RWA.................................21 100 5.4.3. Approximate IA-RWA + Separate Detailed IV...........23 101 6. Manageability and Operations..................................25 102 7. Security Considerations.......................................26 103 8. IANA Considerations...........................................27 104 9. References....................................................27 105 9.1. Normative References.....................................27 106 9.2. Informative References...................................27 107 10. Acknowledgments..............................................28 109 1. Introduction 111 Wavelength Switched Optical Networks (WSONs) are constructed from 112 subsystems that may include Wavelength Division Multiplexed (WDM) 113 links, tunable transmitters and receivers, Reconfigurable Optical 114 Add/Drop Multiplexers (ROADM), wavelength converters, and electro- 115 optical network elements. A WSON is a wavelength division 116 multiplexed (WDM)-based optical network in which switching is 117 performed selectively based on the center wavelength of an optical 118 signal. 120 As an optical signal progresses along its path, it may be altered by 121 the various physical processes in the optical fibers and devices it 122 encounters. When such alterations result in signal degradation, 123 these processes are usually referred to as "impairments". Optical 124 impairments accumulate along the path (without 3R regeneration) 125 traversed by the signal. They are influenced by the type of fiber 126 used, the types and placement of various optical devices, and the 127 presence of other optical signals that may share a fiber segment 128 along the signal's path. The degradation of the optical signals due 129 to impairments can result in unacceptable bit error rates or even a 130 complete failure to demodulate and/or detect the received signal. 132 In order to provision an optical connection (an optical path) 133 through a WSON, a combination of path continuity, resource 134 availability, and impairments constraints must be met to determine 135 viable and optimal paths through the network. The determination of 136 appropriate paths is known as Impairment Aware Routing and 137 Wavelength Assignment (IA-RWA). 139 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] 140 provides a set of control plane protocols that can be used to 141 operate networks ranging from packet switch capable networks, 142 through those networks that use time division multiplexing and WDM. 143 The Path Computation Element (PCE) architecture [RFC4655] defines 144 functional computation components that can be used in cooperation 145 with the GMPLS control plane to compute and suggest appropriate 146 paths. [RFC4054] provides an overview of optical impairments and 147 their routing (path selection) implications for GMPLS. This document 148 uses as reference [G.680] and other ITU-T Recommendations for the 149 optical data plane aspects. 151 This document provides a framework for applying GMPLS protocols and 152 the PCE architecture to the control and operation of IA-RWA for 153 WSONs. To aid in this evaluation, this document provides an 154 overview of the subsystems and processes that comprise WSONs and 155 describes IA-RWA models based on the corresponding ITU-T 156 Recommendations, so that the information requirements for use by 157 GMPLS and PCE systems can be identified. This work will facilitate 158 the development of protocol extensions in support of IA-RWA within 159 the GMPLS and PCE protocol families. 161 2. Terminology 163 ADM: Add/Drop Multiplexers - An optical device used in WDM networks 164 composed of one or more line side ports and typically many tributary 165 ports. 167 Black links: Black links refer to tributary interfaces where only 168 link characteristics are defined. This approach enables transverse 169 compatibility at the single-channel point using a direct wavelength- 170 multiplexing configuration. 172 CWDM: Coarse Wavelength Division Multiplexing 174 DGD: Differential Group Delay 176 DWDM: Dense Wavelength Division Multiplexing 178 FOADM: Fixed Optical Add/Drop Multiplexer 179 GMPLS: Generalized Multi-Protocol Label Switching 181 IA-RWA: Impairment Aware Routing and Wavelength Assignment 183 Line side: In WDM system line side ports and links typically can 184 carry the full multiplex of wavelength signals, as compared to 185 tributary (add or drop ports) that typically carry a few (typically 186 one) wavelength signals. 188 NEs: Network Elements 190 OADMs: Optical Add Drop Multiplexers 192 OSNR: Optical Signal to Noise Ratio 194 OXC: Optical cross connect - An optical switching element in which a 195 signal on any input port can reach any output port. 197 PCC: Path Computation Client - Any client application requesting a 198 path computation to be performed by the Path Computation Element. 200 PCE: Path Computation Element - An entity (component, application, 201 or network node) that is capable of computing a network path or 202 route based on a network graph and applying computational 203 constraints. 205 PCEP: PCE Communication Protocol - The communication protocol 206 between a Path Computation Client and Path Computation Element. 208 PXC: Photonic Cross Connects 210 Q-factor: The Q-factor provides a qualitative description of the 211 receiver performance. It is a function of the signal to optical 212 noise ratio. The Q-factor suggests the minimum SNR (Signal Noise 213 Ratio) required to obtain a specific BER for a given signal. 215 ROADM: Reconfigurable Optical Add/Drop Multiplexer - A wavelength 216 selective switching element featuring input and output line side 217 ports as well as add/drop tributary ports. 219 RWA: Routing and Wavelength Assignment 221 Transparent Network: A wavelength switched optical network that does 222 not contain regenerators or wavelength converters. 224 Translucent Network: A wavelength switched optical network that is 225 predominantly transparent but may also contain limited numbers of 226 regenerators and/or wavelength converters. 228 Tributary: A link or port on a WDM system that can carry 229 significantly less than the full multiplex of wavelength signals 230 found on the line side links/ports. Typical tributary ports are the 231 add and drop ports on an ADM and these support only a single 232 wavelength channel. 234 Wavelength Conversion/Converters: The process of converting 235 information bearing optical signal centered at a given wavelength to 236 one with "equivalent" content centered at a different wavelength. 237 Wavelength conversion can be implemented via an optical-electronic- 238 optical (OEO) process or via a strictly optical process. 240 WDM: Wavelength Division Multiplexing 242 Wavelength Switched Optical Networks (WSONs): WDM based optical 243 networks in which switching is performed selectively based on the 244 center wavelength of an optical signal. 246 3. Applicability 248 There are deployment scenarios for WSON networks where not all 249 possible paths will yield suitable signal quality. There are 250 multiple reasons; below is a non-exhaustive list of examples: 252 o WSON is evolving using multi-degree optical cross connects in a 253 way that network topologies are changing from rings (and 254 interconnected rings) to general mesh. Adding network equipment 255 such as amplifiers or regenerators, to ensure all paths are 256 feasible, leads to an over-provisioned network. Indeed, even with 257 over provisioning, the network could still have some infeasible 258 paths. 260 o Within a given network, the optical physical interface may change 261 over the network life, e.g., the optical interfaces might be 262 upgraded to higher bit-rates. Such changes could result in paths 263 being unsuitable for the optical signal. Moreover, the optical 264 physical interfaces are typically provisioned at various stages 265 of the network's life span as needed by traffic demands. 267 o There are cases where a network is upgraded by adding new optical 268 cross connects to increase network flexibility. In such cases, 269 existing paths will have their feasibility modified while new 270 paths will need to have their feasibility assessed. 272 o With the recent bit rate increases from 10G to 40G and 100G over 273 a single wavelength, WSON networks will likely be operated with a 274 mix of wavelengths at different bit rates. This operational 275 scenario will impose impairment constraints due to different 276 physical behavior of different bit rates and associated 277 modulation formats. 279 Not having an impairment aware control plane for such networks will 280 require a more complex network design phase that needs to take into 281 account the evolving network status in term of equipments and 282 traffic at the beginning stage. In addition, network operations such 283 as path establishment, will require significant pre-design via non- 284 control plane processes resulting in significantly slower network 285 provisioning. 287 It should be highlighted that the impact of impairments and use in 288 determination of path viability is not sufficiently well established 289 for general applicability [G.680]; it will depend on network 290 implementations. The use of an impairment aware control plane and 291 set of information distributed will need to be evaluated on a case 292 by case scenario. 294 4. Impairment Aware Optical Path Computation 296 The basic criteria for path selection is whether one can 297 successfully transmit the signal from a transmitter to a receiver 298 within a prescribed error tolerance, usually specified as a maximum 299 permissible bit error ratio (BER). This generally depends on the 300 nature of the signal transmitted between the sender and receiver and 301 the nature of the communications channel between the sender and 302 receiver. The optical path utilized (along with the wavelength) 303 determines the communications channel. 305 The optical impairments incurred by the signal along the fiber and 306 at each optical network element along the path determine whether the 307 BER performance or any other measure of signal quality can be met 308 for a signal on a particular end-to-end path. 310 Impairment-aware path calculation also needs to take into account 311 when regeneration is used along the path. [RFC6163] provides 312 background on the concept of optical translucent networks which 313 contains transparent elements and electro-optical elements such as 314 OEO regenerations. In such networks, a generic light path can go 315 through a number of regeneration points. 317 Regeneration points could happen for two reasons: 319 (i) Due to wavelength conversion to assist RWA to avoid wavelength 320 blocking. This is the impairment free case covered by [RFC6163]. 322 (ii) The optical signal without regeneration would be too degraded 323 to meet end to end BER requirements. This is the case when RWA 324 takes into consideration impairment estimation covered by this 325 document. 327 In the latter case, an optical path can be seen as a set of 328 transparent segments. The optical impairments calculation needs to 329 be reset at each regeneration point so each transparent segment will 330 have its own impairment evaluation. 332 +---+ +----+ +----+ +-----+ +----+ +---+ 333 | I |----| N1 |---| N2 |-----| REG |-----| N3 |----| E | 334 +---+ +----+ +----+ +-----+ +----+ +---+ 336 |<----------------------------->|<-------------------->| 337 Segment 1 Segment 2 339 Figure 1 Optical path as a set of transparent segments 341 For example, Figure 1 represents an optical path from node I to node 342 E with a regeneration point REG in between. It is feasible from an 343 impairment validation perspective if both segments (I, N1, N2, REG) 344 and (REG, N3, E) are feasible. 346 4.1. Optical Network Requirements and Constraints 348 This section examines the various optical network requirements and 349 constraints under which an impairment aware optical control plane 350 may have to operate under. These requirements and constraints 351 motivate the IA-RWA architectural alternatives to be presented in 352 the following section. Different optical networks contexts can be 353 broken into two main criteria: (a) the accuracy required in the 354 estimation of impairment effects, and (b) the constraints on the 355 impairment estimation computation and/or sharing of impairment 356 information. 358 4.1.1. Impairment Aware Computation Scenarios 360 A. No concern for impairments or Wavelength Continuity Constraints 362 This situation is covered by existing GMPLS with local wavelength 363 (label) assignment. 365 B. No concern for impairments but Wavelength Continuity Constraints 366 This situation is applicable to networks designed such that every 367 possible path is valid for the signal types permitted on the 368 network. In this case, impairments are only taken into account 369 during network design and after that, for example during optical 370 path computation, they can be ignored. This is the case discussed in 371 [RFC6163] where impairments may be ignored by the control plane and 372 only optical parameters related to signal compatibility are 373 considered. 375 C. Approximated Impairment Estimation 377 This situation is applicable to networks in which impairment effects 378 need to be considered but there is sufficient margin such that they 379 can be estimated via approximation techniques such as link budgets 380 and dispersion [G.680],[G.sup39]. The viability of optical paths for 381 a particular class of signals can be estimated using well defined 382 approximation techniques [G.680], [G.sup39]. This is the generally 383 known as linear case where only linear effects are taken into 384 account. Note that adding or removing an optical signal on the path 385 should not render any of the existing signals in the network as non- 386 viable. For example, one form of non-viability is the occurrence of 387 transients in existing links of sufficient magnitude to impact the 388 BER of existing signals. 390 Much work at ITU-T has gone into developing impairment models at 391 this and more detailed levels. Impairment characterization of 392 network elements may be used to calculate which paths are conformant 393 with a specified BER for a particular signal type. In such a case, 394 the impairment aware (IA) path computation can be combined with the 395 RWA process to permit more optimal IA-RWA computations. Note that 396 the IA path computation may also take place in a separate entity, 397 i.e., a PCE. 399 D. Accurate Impairment Computation 401 This situation is applicable to networks in which impairment effects 402 must be more accurately computed. For these networks, a full 403 computation and evaluation of the impact to any existing paths needs 404 to be performed prior to the addition of a new path. Currently no 405 impairment models are available from ITU-T and this scenario is 406 outside the scope of this document. 408 4.1.2. Impairment Computation and Information Sharing Constraints 410 In GMPLS, information used for path computation is standardized for 411 distribution amongst the elements participating in the control plane 412 and any appropriately equipped PCE can perform path computation. For 413 optical systems this may not be possible. This is typically due to 414 only portions of an optical system being subject to standardization. 415 In ITU-T recommendations [G.698.1] and [G.698.2] which specify 416 single channel interfaces to multi-channel DWDM systems, only the 417 single channel interfaces (transmit and receive) are specified while 418 the multi-channel links are not standardized. These DWDM links are 419 referred to as "black links" since their details are not generally 420 available. However, note that the overall impact of a black link at 421 the single channel interface points is limited by [G.698.1] and 422 [G.698.2]. 424 Typically a vendor might use proprietary impairment models for DWDM 425 spans in order to estimate the validity of optical paths. For 426 example, models of optical nonlinearities are not currently 427 standardized. Vendors may also choose not to publish impairment 428 details for links or a set of network elements in order not to 429 divulge their optical system designs. 431 In general, the impairment estimation/validation of an optical path 432 for optical networks with "black links" in the path could not be 433 performed by a general purpose impairment aware (IA) computation 434 entity since it would not have access to or understand the "black 435 link" impairment parameters. However, impairment estimation (optical 436 path validation) could be performed by a vendor specific impairment 437 aware computation entity. Such a vendor specific IA computation 438 could utilize standardized impairment information imported from 439 other network elements in these proprietary computations. 441 In the following, the term "black links" will be used to describe 442 these computation and information sharing constraints in optical 443 networks. From the control plane perspective the following options 444 are considered: 446 1. The authority in control of the "black links" can furnish a list 447 of all viable paths between all viable node pairs to a 448 computational entity. This information would be particularly 449 useful as an input to RWA optimization to be performed by another 450 computation entity. The difficulty here is that such a list of 451 paths along with any wavelength constraints could get 452 unmanageably large as the size of the network increases. 454 2. The authority in control of the "black links" could provide a 455 PCE-like entity a list of viable paths/wavelengths between two 456 requested nodes. This is useful as an input to RWA optimizations 457 and can reduce the scaling issue previously mentioned. Such a 458 PCE-like entity would not need to perform a full RWA computation, 459 i.e., it would not need to take into account current wavelength 460 availability on links. Such an approach may require PCEP 461 extensions for both the request and response information. 463 3. The authority in control of the "black links" provides a PCE that 464 performs full IA-RWA services. The difficulty is this requires 465 the one authority to also become the sole source of all RWA 466 optimization algorithms. 468 In all the above cases it would be the responsibility of the 469 authority in control of the "black links" to import the shared 470 impairment information from the other NEs via the control plane or 471 other means as necessary. 473 4.1.3. Impairment Estimation Process 475 The Impairment Estimation Process can be modeled through the 476 following functional blocks. These blocks are independent of any 477 Control Plane architecture, that is, they can be implemented by the 478 same or by different control plane functions as detailed in 479 following sections. 481 +-----------------+ 482 +------------+ +-----------+ | +------------+ | 483 | | | | | | | | 484 | Optical | | Optical | | | Optical | | 485 | Interface |------->| Impairment|--->| | Channel | | 486 | (Transmit/ | | Path | | | Estimation | | 487 | Receive) | | | | | | | 488 +------------+ +-----------+ | +------------+ | 489 | || | 490 | || | 491 | Estimation | 492 | || | 493 | \/ | 494 | +------------+ | 495 | | BER / | | 496 | | Q Factor | | 497 | +------------+ | 498 +-----------------+ 500 Starting from functional block on the left, the Optical Interface 501 represents where the optical signal is transmitted or received and 502 defines the properties at the path end points. Even the impairment- 503 free case, like scenario B in section 4.1.1, needs to consider a 504 minimum set of interface characteristics. In such case, only a few 505 parameters used to assess the signal compatibility will be taken 506 into account (see [RFC6163]). For the impairment-aware case, these 507 parameters may be sufficient or not depending on the accepted level 508 of approximation (scenarios C and D). This functional block 509 highlights the need to consider a set of interface parameters during 510 the Impairment Validation Process. 512 The block "Optical Impairment Path" represents the types of 513 impairments affecting a wavelength as it traverses the networks 514 through links and nodes. In the case of a network where there are no 515 impairments (Scenario A), this block will not be present. Otherwise, 516 this function must be implemented in some way via the control plane. 517 Architectural alternatives to accomplish this are provided in 518 section 4.2. This block implementation (e.g., through routing, 519 signaling, or PCE) may influence the way the control plane 520 distributes impairment information within the network. 522 The last block implements the decision function for path 523 feasibility. Depending on the IA level of approximation, this 524 function can be more or less complex. For example in case of no IA 525 only the signal class compatibility will be verified. In addition to 526 feasible/not-feasible result, it may be worthwhile for decision 527 functions to consider the case in which paths can be likely-to-be- 528 feasible within some degree of confidence. The optical impairments 529 are usually not fixed values as they may vary within ranges of 530 values according to the approach taken in the physical modeling 531 (worst-case, statistical, or based on typical values). For example, 532 the utilization of the worst-case value for each parameter within 533 impairment validation process may lead to marking some paths as not- 534 feasible while they are very likely to be, in reality, feasible. 536 4.2. IA-RWA Computation and Control Plane Architectures 538 From a control plane point of view, optical impairments are 539 additional constraints to the impairment-free RWA process described 540 in [RFC6163]. In impairment aware routing and wavelength assignment 541 (IA-RWA), there are conceptually three general classes of processes 542 to be considered: Routing (R), Wavelength Assignment (WA), and 543 Impairment Validation (IV), i.e., estimation. 545 Impairment validation may come in many forms, and may be invoked at 546 different levels of detail in the IA-RWA process. All the variations 547 of impairment validation discussed in this section is based on 548 Scenario C (Approximated Impairment Estimation) as discussed in 549 Section 4.1.1. From a process point of view, the following three 550 forms of impairment validation will be considered: 552 o IV-Candidates 554 In this case, an Impairment Validation (IV) process furnishes a set 555 of paths between two nodes along with any wavelength restrictions 556 such that the paths are valid with respect to optical impairments. 557 These paths and wavelengths may not be actually available in the 558 network due to its current usage state. This set of paths could be 559 returned in response to a request for a set of at most K valid paths 560 between two specified nodes. Note that such a process never directly 561 discloses optical impairment information. Note that that this case 562 includes any paths between source and destination that may have been 563 "pre-validated". 565 In this case, the control plane simply makes use of candidate paths 566 but does not know any optical impairment information. Another option 567 is when the path validity is assessed within the control plane. The 568 following cases highlight this situation. 570 o IV-Approximate Verification 572 Here approximation methods are used to estimate the impairments 573 experienced by a signal. Impairments are typically approximated by 574 linear and/or statistical characteristics of individual or combined 575 components and fibers along the signal path. 577 o IV-Detailed Verification 579 In this case, an IV process is given a particular path and 580 wavelength through an optical network and is asked to verify whether 581 the overall quality objectives for the signal over this path can be 582 met. Note that such a process never directly discloses optical 583 impairment information. 585 The next two cases refer to the way an impairment validation 586 computation can be performed. 588 o IV-Centralized 590 In this case, impairments to a path are computed at a single entity. 591 The information concerning impairments, however, may still be 592 gathered from network elements. Depending how information is 593 gathered, this may put additional requirements on routing protocols. 594 This will be detailed in later sections. 596 o IV-Distributed 598 In the distributed IV process, approximate degradation measures such 599 as OSNR, dispersion, DGD, etc., may be accumulated along the path 600 via signaling. Each node on the path may already perform some part 601 of the impairment computation (i.e. distributed). When the 602 accumulated measures reach the destination node, a decision on the 603 impairment validity of the path can be made. Note that such a 604 process would entail revealing an individual network element's 605 impairment information but it does not generally require 606 distributing optical parameters to the entire network. 608 The Control Plane must not preclude the possibility to concurrently 609 perform one or all the above cases in the same network. For example, 610 there could be cases where a certain number of paths are already 611 pre-validated (IV-Candidates) so the control plane may setup one of 612 those paths without requesting any impairment validation procedure. 613 On the same network, however, the control plane may compute a path 614 outside the set of IV-Candidates for which an impairment evaluation 615 can be necessary. 617 The following subsections present three major classes of IA-RWA path 618 computation architectures and reviews some of their respective 619 advantages and disadvantages. 621 4.2.1. Combined Routing, WA, and IV 623 From the point of view of optimality, reasonably good IA-RWA 624 solutions can be achieved if the path computation entity (PCE) can 625 conceptually/algorithmically combine the processes of routing, 626 wavelength assignment and impairment validation. 628 Such a combination can take place if the PCE is given: (a) the 629 impairment-free WSON network information as discussed in [RFC6163] 630 and (b) impairment information to validate potential paths. 632 4.2.2. Separate Routing, WA, or IV 634 Separating the processes of routing, WA, and/or IV can reduce the 635 need for sharing of different types of information used in path 636 computation. This was discussed for routing separate from WA in 637 [RFC6163]. In addition, as was discussed, some impairment 638 information may not be shared and this may lead to the need to 639 separate IV from RWA. In addition, if IV needs to be done at a high 640 level of precision, it may be advantageous to offload this 641 computation to a specialized server. 643 The following conceptual architectures belong in this general 644 category: 646 o R+WA+IV -- separate routing, wavelength assignment, and 647 impairment validation. 649 o R + (WA & IV) -- routing separate from a combined wavelength 650 assignment and impairment validation process. Note that 651 impairment validation is typically wavelength dependent. Hence 652 combining WA with IV can lead to efficiencies. 654 o (RWA)+IV - combined routing and wavelength assignment with a 655 separate impairment validation process. 657 Note that the IV process may come before or after the RWA processes. 658 If RWA comes first, then IV is just rendering a yes/no decision on 659 the selected path and wavelength. If IV comes first it would need to 660 furnish a list of possible (valid with respect to impairments) 661 routes and wavelengths to the RWA processes. 663 4.2.3. Distributed WA and/or IV 665 In the non-impairment RWA situation [RFC6163], it was shown that a 666 distributed wavelength assignment (WA) process carried out via 667 signaling can eliminate the need to distribute wavelength 668 availability information via an interior gateway protocol (IGP). A 669 similar approach can allow for the distributed computation of 670 impairment effects and avoid the need to distribute impairment 671 characteristics of network elements and links by routing protocols 672 or by other means. So the following conceptual options belong to 673 this category: 675 o RWA + D(IV) - Combined routing and wavelength assignment and 676 distributed impairment validation. 678 o R + D(WA & IV) -- routing separate from a distributed wavelength 679 assignment and impairment validation process. 681 Distributed impairment validation for a prescribed network path 682 requires that the effects of impairments be calculated by 683 approximate models with cumulative quality measures such as those 684 given in [G.680]. The protocol encoding of the impairment related 685 information from [G.680] would need to be agreed upon. 687 If distributed WA is being done at the same time as distributed IV 688 then it is necessary to accumulate impairment related information 689 for all wavelengths that could be used. The amount of information is 690 reduced somewhat as potential wavelengths are discovered to be in 691 use, but could be a significant burden for lightly loaded high 692 channel count networks. 694 4.3. Mapping Network Requirements to Architectures 696 Figure 2 shows process flows for the three main architectural 697 alternatives to IA-RWA when approximate impairment validation is 698 sufficient. Figure 3 shows process flows for the two main 699 architectural alternatives when detailed impairment verification is 700 required. 702 +-----------------------------------+ 703 | +--+ +-------+ +--+ | 704 | |IV| |Routing| |WA| | 705 | +--+ +-------+ +--+ | 706 | | 707 | Combined Processes | 708 +-----------------------------------+ 709 (a) 711 +--------------+ +----------------------+ 712 | +----------+ | | +-------+ +--+ | 713 | | IV | | | |Routing| |WA| | 714 | |candidates| |----->| +-------+ +--+ | 715 | +----------+ | | Combined Processes | 716 +--------------+ +----------------------+ 717 (b) 719 +-----------+ +----------------------+ 720 | +-------+ | | +--+ +--+ | 721 | |Routing| |------->| |WA| |IV| | 722 | +-------+ | | +--+ +--+ | 723 +-----------+ | Distributed Processes| 724 +----------------------+ 725 (c) 726 Figure 2 Process flows for the three main approximate impairment 727 architectural alternatives. 729 The advantages, requirements, and suitability of these options are 730 as follows: 732 o Combined IV & RWA process 733 This alternative combines RWA and IV within a single computation 734 entity enabling highest potential optimality and efficiency in IA- 735 RWA. This alternative requires that the computational entity knows 736 impairment information as well as non-impairment RWA information. 737 This alternative can be used with "black links", but would then need 738 to be provided by the authority controlling the "black links". 740 o IV-Candidates + RWA process 742 This alternative allows separation of impairment information into 743 two computational entities while still maintaining a high degree of 744 potential optimality and efficiency in IA-RWA. The candidates IV 745 process needs to know impairment information from all optical 746 network elements, while the RWA process needs to know non-impairment 747 RWA information from the network elements. This alternative can be 748 used with "black links", but the authority in control of the "black 749 links" would need to provide the functionality of the IV-candidates 750 process. Note that this is still very useful since the algorithmic 751 areas of IV and RWA are very different and conducive to 752 specialization. 754 o Routing + Distributed WA and IV 756 In this alternative, a signaling protocol may be extended and 757 leveraged in the wavelength assignment and impairment validation 758 processes. Although this doesn't enable as high a potential degree 759 of optimality as (a) or (b), it does not require distribution of 760 either link wavelength usage or link/node impairment information. 761 Note that this is most likely not suitable for "black links". 763 +-----------------------------------+ +------------+ 764 | +-----------+ +-------+ +--+ | | +--------+ | 765 | | IV | |Routing| |WA| | | | IV | | 766 | |approximate| +-------+ +--+ |---->| |Detailed| | 767 | +-----------+ | | +--------+ | 768 | Combined Processes | | | 769 +-----------------------------------+ +------------+ 770 (a) 772 +--------------+ +----------------------+ +------------+ 773 | +----------+ | | +-------+ +--+ | | +--------+ | 774 | | IV | | | |Routing| |WA| |---->| | IV | | 775 | |candidates| |----->| +-------+ +--+ | | |Detailed| | 776 | +----------+ | | Combined Processes | | +--------+ | 777 +--------------+ +----------------------+ | | 778 (b) +------------+ 779 Figure 3 Process flows for the two main detailed impairment 780 validation architectural options. 782 The advantages, requirements, and suitability of these detailed 783 validation options are as follows: 785 o Combined Approximate IV & RWA + Detailed-IV 787 This alternative combines RWA and approximate IV within a single 788 computation entity enabling the highest potential optimality and 789 efficiency in IA-RWA while keeping a separate entity performing 790 detailed impairment validation. In the case of "black links" the 791 authority controlling the "black links" would need to provide all 792 functionality. 794 o Candidates-IV + RWA + Detailed-IV 796 This alternative allows separation of approximate impairment 797 information into a computational entity while still maintaining a 798 high degree of potential optimality and efficiency in IA-RWA; then a 799 separate computation entity performs detailed impairment validation. 800 Note that detailed impairment estimation is not standardized. 802 5. Protocol Implications 804 The previous IA-RWA architectural alternatives and process flows 805 make differing demands on a GMPLS/PCE based control plane. This 806 section discusses the use of (a) an impairment information model, 807 (b) PCE as computational entity assuming the various process roles 808 and consequences for PCEP, (c) possible extensions to signaling, and 809 (d) possible extensions to routing. This document is providing this 810 evaluation to aid protocol solutions work. The protocol 811 specifications may deviate from this assessment. The assessment of 812 the impacts to the control plane for IA-RWA is summarized in Figure 813 4. 815 +-------------------+----+----+----------+--------+ 816 | IA-RWA Option |PCE |Sig |Info Model| Routing| 817 +-------------------+----+----+----------+--------+ 818 | Combined |Yes | No | Yes | Yes | 819 | IV & RWA | | | | | 820 +-------------------+----+----+----------+--------+- 821 | IV-Candidates |Yes | No | Yes | Yes | 822 | + RWA | | | | | 823 +-------------------+----+----+----------+--------+ 824 | Routing + |No | Yes| Yes | No | 825 |Distributed IV, RWA| | | | | 826 +-------------------+----+----+----------+--------+ 828 Figure 4 IA-RWA architectural options and control plane impacts. 830 5.1. Information Model for Impairments 832 As previously discussed, most IA-RWA scenarios rely, to a greater or 833 lesser extent, on a common impairment information model. A number of 834 ITU-T recommendations cover detailed, as well as, approximate 835 impairment characteristics of fibers, and a variety of devices, and 836 subsystems. An impairment model which can be used as a guideline for 837 optical network elements and assessment of path viability is given 838 in [G.680]. 840 It should be noted that the current version of [G.680] is limited to 841 networks composed of a single WDM line system vendor combined with 842 OADMs and/or PXCs from potentially multiple other vendors. This is 843 known as situation 1 and is shown in Figure 1-1 of [G.680]. It is 844 planned in the future that [G.680] will include networks 845 incorporating line systems from multiple vendors, as well as, OADMs 846 and/or PXCs from potentially multiple other vendors. This is known 847 as situation 2 and is shown in Figure 1-2 of [G.680]. 849 For the case of distributed impairment validation (distributed IV), 850 this would require more than an impairment information model. It 851 would need a common impairment "computation" model. In the 852 distributed IV case, one needs to standardize the accumulated 853 impairment measures that will be conveyed and updated at each node. 854 Section 9 of [G.680] provides guidance in this area with specific 855 formulas given for OSNR, residual dispersion, polarization mode 856 dispersion/polarization dependent loss, and effects of channel 857 uniformity. However, specifics of what intermediate results are kept 858 and in what form would need to be standardized for interoperability. 859 As noted in [G.680], this information may possibly not be 860 sufficient, and in such case the applicability would be network 861 dependent. 863 5.2. Routing 865 Different approaches to path/wavelength impairment validation give 866 rise to different demands placed on GMPLS routing protocols. In the 867 case where approximate impairment information is used to validate 868 paths, GMPLS routing may be used to distribute the impairment 869 characteristics of the network elements and links based on the 870 impairment information model previously discussed. 872 Depending on the computational alternative, the routing protocol may 873 need to advertise information necessary to the impairment validation 874 process. This can potentially cause scalability issues due to the 875 high volume of data that need to be advertised. Such issue can be 876 addressed separating data that need to be advertised rarely from 877 data that need to be advertised more frequently or adopting other 878 form of awareness solutions described in previous sections (e.g., 879 centralized and/or external IV entity). 881 In term of approximated scenario (see Section 4.1.1.), the model 882 defined by [G.680] will apply and the routing protocol will need to 883 gather information required for such computation. 885 In the case of distributed-IV, no new demands would be placed on the 886 routing protocol. 888 5.3. Signaling 890 The largest impacts on signaling occur in the cases where 891 distributed impairment validation is performed. In this case, it is 892 necessary to accumulate impairment information as previously 893 discussed. In addition, since the characteristics of the signal 894 itself, such as modulation type, can play a major role in the 895 tolerance of impairments, this type of information will need to be 896 implicitly or explicitly signaled so that an impairment validation 897 decision can be made at the destination node. 899 It remains for further study if it may be beneficial to include 900 additional information to a connection request such as desired 901 egress signal quality (defined in some appropriate sense) in non- 902 distributed IV scenarios. 904 5.4. PCE 906 In section 4.3. a number of computation architectural alternatives 907 were given that could be used to meet the various requirements and 908 constraints of section 4.1. Here the focus is how these 909 alternatives could be implemented via either a single PCE or a set 910 of two or more cooperating PCEs, and the impacts on the PCEP. This 911 document provides this evaluation to aid solutions work. The 912 protocol specifications may deviate from this assessment. 914 5.4.1. Combined IV & RWA 916 In this situation, shown in Figure 2(a), a single PCE performs all 917 the computations needed for IA-RWA. 919 o TE Database Requirements: WSON Topology and switching 920 capabilities, WSON WDM link wavelength utilization, and WSON 921 impairment information 923 o PCC to PCE Request Information: Signal characteristics/type, 924 required quality, source node, destination node 926 o PCE to PCC Reply Information: If the computations completed 927 successfully then the PCE returns the path and its assigned 928 wavelength. If the computations could not complete successfully, 929 it would be potentially useful to know the reason why. At a 930 minimum, it is of interest to know if this was due to lack of 931 wavelength availability, impairment considerations, or both. The 932 information to be conveyed is for further study. 934 5.4.2. IV-Candidates + RWA 936 In this situation, as shown in Figure 2(b), two separate processes 937 are involved in the IA-RWA computation. This requires two 938 cooperating path computation entities: one for the Candidates-IV 939 process and another for the RWA process. In addition, the overall 940 process needs to be coordinated. This could be done with yet another 941 PCE or this functionality could be added to one of previously 942 defined entities. This later option requires the RWA entity to also 943 act as the overall process coordinator. The roles, responsibilities, 944 and information requirements for these two entities when 945 instantiated as PCEs are given below. 947 RWA and Coordinator PCE (RWA-Coord-PCE): 949 Responsible for interacting with PCC and for utilizing Candidates- 950 PCE as needed during RWA computations. In particular, it needs to 951 know to use the Candidates-PCE to obtain potential set of routes and 952 wavelengths. 954 o TE Database Requirements: WSON Topology and switching 955 capabilities and WSON WDM link wavelength utilization (no 956 impairment information). 958 o PCC to RWA-PCE request: same as in the combined case. 960 o RWA-PCE to PCC reply: same as in the combined case. 962 o RWA-PCE to IV-Candidates-PCE request: The RWA-PCE asks for a set 963 of at most K routes along with acceptable wavelengths between 964 nodes specified in the original PCC request. 966 o IV-Candidates-PCE reply to RWA-PCE: The Candidates-PCE returns a 967 set of at most K routes along with acceptable wavelengths between 968 nodes specified in the RWA-PCE request. 970 IV-Candidates-PCE: 972 The IV-Candidates PCE is responsible for impairment aware path 973 computation. It need not take into account current link wavelength 974 utilization, but this is not prohibited. The Candidates-PCE is only 975 required to interact with the RWA-PCE as indicated above and not the 976 initiating PCC. Note: RWA-Coord PCE is also a PCC with respect to 977 the IV-Candidate. 979 o TE Database Requirements: WSON Topology and switching 980 capabilities and WSON impairment information (no information link 981 wavelength utilization required). 983 Figure 5 shows a sequence diagram for the possible interactions 984 between the PCC, RWA-Coord PCE, and IV-Candidates PCE. 986 +---+ +-------------+ +-----------------+ 987 |PCC| |RWA-Coord PCE| |IV-Candidates PCE| 988 +-+-+ +------+------+ +---------+-------+ 989 ...___ (a) | | 990 | ````---...____ | | 991 | ```-->| | 992 | | | 993 | |--..___ (b) | 994 | | ```---...___ | 995 | | ```---->| 996 | | | 997 | | | 998 | | (c) ___...| 999 | | ___....---'''' | 1000 | |<--'''' | 1001 | | | 1002 | | | 1003 | (d) ___...| | 1004 | ___....---''' | | 1005 |<--''' | | 1006 | | | 1007 | | | 1009 Figure 5 Sequence diagram for the interactions between PCC, RWA- 1010 Coordinating-PCE, and the IV-Candidates-PCE. 1012 In step (a), the PCC requests a path meeting specified quality 1013 constraints between two nodes (A and Z) for a given signal 1014 represented either by a specific type or a general class with 1015 associated parameters. In step (b), the RWA-Coordinating-PCE 1016 requests up to K candidate paths between nodes A and Z and 1017 associated acceptable wavelengths. The term "K candidate paths" is 1018 associated with K-shortest path algorithm. It refers to an algorithm 1019 that finds multiple K short paths connecting the source and the 1020 destination in a graph allowing repeated vertices and edges in the 1021 paths. See details in [Eppstein]. 1023 In step (c), The IV-Candidates PCE returns this list to the RWA- 1024 Coordinating PCE which then uses this set of paths and wavelengths 1025 as input (e.g., a constraint) to its RWA computation. In step (d) 1026 the RWA-Coordinating PCE returns the overall IA-RWA computation 1027 results to the PCC. 1029 5.4.3. Approximate IA-RWA + Separate Detailed IV 1031 Previously, Figure 3 showed two cases where a separate detailed 1032 impairment validation process could be utilized. It is possible to 1033 place the detailed validation process into a separate PCE. Assuming 1034 that a different PCE assumes a coordinating role and interacts with 1035 the PCC, it is possible to keep the interactions with this separate 1036 IV-Detailed-PCE very simple. Please note that there is some 1037 inefficiency by separating the IV-Candidates-PCE from the IV- 1038 Detailed-PCE from a message flow perspective in order to achieve a 1039 high degree of potential optimality. 1041 IV-Detailed-PCE: 1043 o TE Database Requirements: The IV-Detailed-PCE will need optical 1044 impairment information, WSON topology, and possibly WDM link 1045 wavelength usage information. This document puts no restrictions 1046 on the type of information that may be used in these 1047 computations. 1049 o Coordinating-PCE to IV-Detailed-PCE request: The coordinating-PCE 1050 will furnish signal characteristics, quality requirements, path, 1051 and wavelength to the IV-Detailed-PCE. 1053 o IV-Detailed-PCE to Coordinating-PCE reply: The reply is 1054 essentially a yes/no decision as to whether the requirements 1055 could actually be met. In the case where the impairment 1056 validation fails, it would be helpful to convey information 1057 related to cause or quantify the failure, e.g., so that a 1058 judgment can be made whether to try a different signal or adjust 1059 signal parameters. 1061 Figure 6 shows a sequence diagram for the interactions corresponding 1062 to the process shown in Figure 3(b). This involves interactions 1063 between the PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE, 1064 and the IV-Detailed-PCE. 1066 In step (a), the PCC requests a path meeting specified quality 1067 constraints between two nodes (A and Z) for a given signal 1068 represented either by a specific type or a general class with 1069 associated parameters. In step (b), the RWA-Coordinating-PCE 1070 requests up to K candidate paths between nodes A and Z and 1071 associated acceptable wavelengths. In step (c), The IV-Candidates- 1072 PCE returns this list to the RWA-Coordinating PCE which then uses 1073 this set of paths and wavelengths as input (e.g., a constraint) to 1074 its RWA computation. In step (d), the RWA-Coordinating-PCE request a 1075 detailed verification of the path and wavelength that it has 1076 computed. In step (e), the IV-Detailed-PCE returns the results of 1077 the validation to the RWA-Coordinating-PCE. Finally in step (f), the 1078 IA-RWA-Coordinating PCE returns the final results (either a path and 1079 wavelength or cause for the failure to compute a path and 1080 wavelength) to the PCC. 1082 +----------+ +--------------+ +------------+ 1083 +---+ |RWA-Coord | |IV-Candidates | |IV-Detailed | 1084 |PCC| | PCE | | PCE | | PCE | 1085 +-+-+ +----+-----+ +------+-------+ +-----+------+ 1086 |.._ (a) | | | 1087 | ``--.__ | | | 1088 | `-->| | | 1089 | | (b) | | 1090 | |--....____ | | 1091 | | ````---.>| | 1092 | | | | 1093 | | (c) __..-| | 1094 | | __..---'' | | 1095 | |<--'' | | 1096 | | | 1097 | |...._____ (d) | 1098 | | `````-----....._____ | 1099 | | `````----->| 1100 | | | 1101 | | (e) _____.....+ 1102 | | _____.....-----''''' | 1103 | |<----''''' | 1104 | (f) __.| | 1105 | __.--'' | 1106 |<-'' | 1107 | | 1109 Figure 6 Sequence diagram for the interactions between PCC, RWA- 1110 Coordinating-PCE, IV-Candidates-PCE, and IV-Detailed-PCE. 1112 6. Manageability and Operations 1114 The issues concerning manageability and operations are beyond the 1115 scope of this document. The details of manageability and operational 1116 issues will have to be deferred to future protocol implementation. 1118 On a high-level, the GMPLS-routing based architecture discussed in 1119 Section 5.2. may have to deal with how to resolve potential scaling 1120 issues associated with disseminating a large amount of impairment 1121 characteristics of the network elements and links. 1123 From a scaling point of view, the GMPLS-signaling based architecture 1124 discussed in Section 5.3. would be more scalable than other 1125 alternatives as this architecture would avoid the dissemination of a 1126 large amount of data to the networks. This benefit may come, 1127 however, at the expense of potentially inefficient use of network 1128 resources. 1130 The PCE-based architectures discussed in Section 5.4. would have to 1131 consider operational complexity when implementing options that 1132 require the use of multiple PCE servers. The most serious case is 1133 the option discussed in Section 5.4.3., namely, "Approximate IA-RWA 1134 + Separate Detailed IV". The combined IV & RWA option (which was 1135 discussed on Section 5.4.1.), on the other hand, is simpler than 1136 other alternatives to operate as one PCE server handles all 1137 functionality; however, this option may suffer from a heavy 1138 computation and processing burden compared to other alternatives. 1140 Interoperability may be a hurdle to overcome when trying to agree on 1141 some impairment parameters especially those which are associated 1142 with the black links. This work has been in progress in ITU-T and 1143 needs some more time to mature. 1145 7. Security Considerations 1147 This document discusses a number of control plane architectures that 1148 incorporate knowledge of impairments in optical networks. If such 1149 architecture is put into use within a network, it will by its nature 1150 contain details of the physical characteristics of an optical 1151 network. Such information would need to be protected from 1152 intentional or unintentional disclosure similar to other network 1153 information used within intra-domain protocols. 1155 This document does not require changes to the security models within 1156 GMPLS and associated protocols. That is, the OSPF-TE, RSVP-TE, and 1157 PCEP security models could be operated unchanged. However, 1158 satisfying the requirements for impairment information dissemination 1159 using the existing protocols may significantly affect the loading of 1160 those protocols. 1162 This may make the operation of the network more vulnerable to active 1163 attacks such as injections, impersonation, and MITMs. Therefore, 1164 additional care may be required to ensure that the protocols are 1165 secure in the impairment-aware WSON environment. 1167 Furthermore, the additional information distributed in order to 1168 address impairment information represents a disclosure of network 1169 capabilities that an operator may wish to keep private. 1170 Consideration should be given to securing this information. For a 1171 general discussion on MPLS- and GMPLS-related security issues, see 1172 the MPLS/GMPLS security framework [RFC5920] and, in particular, text 1173 detailing security issues when Control Plane is physically separated 1174 from Data Plane. 1176 8. IANA Considerations 1178 This draft does not currently require any consideration from IANA. 1180 9. References 1182 9.1. Normative References 1184 [G.680] ITU-T Recommendation G.680, Physical transfer functions of 1185 optical network elements, July 2007. 1187 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 1188 Switching (GMPLS) Architecture", RFC 3945, October 2004. 1190 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1191 Computation Element (PCE)-Based Architecture", RFC 4655, 1192 August 2006. 1194 9.2. Informative References 1196 [G.Sup39] ITU-T Series G Supplement 39, Optical system design and 1197 engineering considerations, February 2006. 1199 [G.698.1] ITU-T Recommendation G.698.1, Multichannel DWDM 1200 applications with Single-Channel optical interface, 1201 December 2006. 1203 [G.698.2] ITU-T Recommendation G.698.2, Amplified multichannel DWDM 1204 applications with Single-Channel optical interface, July 1205 2007. 1207 [RFC4054] Strand, J., Ed., and A. Chiu, Ed., "Impairments and Other 1208 Constraints on Optical Layer Routing", RFC 4054, May 2005. 1210 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1211 Networks", RFC 5920, July 2010. 1213 [RFC6163] Lee, Y., Ed., G. Bernstein, Ed., and W. Imajuku, 1214 "Framework for GMPLS and PCE Control of Wavelength 1215 Switched Optical Networks", RFC 6163, April 2011. 1217 [Eppstein] Eppstein, D., "Finding the k shortest paths", 35th IEEE 1218 Symp. Foundations of Comp. Sci., Santa Fe, pp. 154-165, 1219 1994. 1221 10. Acknowledgments 1223 This document was prepared using 2-Word-v2.0.template.dot. 1225 Copyright (c) 2012 IETF Trust and the persons identified as authors 1226 of the code. All rights reserved. 1228 Redistribution and use in source and binary forms, with or without 1229 modification, are permitted provided that the following conditions 1230 are met: 1232 o Redistributions of source code must retain the above copyright 1233 notice, this list of conditions and the following disclaimer. 1235 o Redistributions in binary form must reproduce the above copyright 1236 notice, this list of conditions and the following disclaimer in 1237 the documentation and/or other materials provided with the 1238 distribution. 1240 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1241 names of specific contributors, may be used to endorse or promote 1242 products derived from this software without specific prior 1243 written permission. 1245 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1246 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1247 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 1248 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 1249 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 1250 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 1251 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 1252 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 1253 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 1254 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 1255 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 1256 POSSIBILITY OF SUCH DAMAGE. 1258 Authors' Addresses 1260 Young Lee (ed.) 1261 Huawei Technologies 1262 1700 Alma Drive, Suite 100 1263 Plano, TX 75075 1264 USA 1266 Phone: (972) 509-5599 (x2240) 1267 Email: ylee@huawei.com 1269 Greg M. Bernstein (ed.) 1270 Grotto Networking 1271 Fremont California, USA 1273 Phone: (510) 573-2237 1274 Email: gregb@grotto-networking.com 1276 Dan Li 1277 Huawei Technologies Co., Ltd. 1278 F3-5-B R&D Center, Huawei Base, 1279 Bantian, Longgang District 1280 Shenzhen 518129 P.R.China 1282 Phone: +86-755-28973237 1283 Email: danli@huawei.com 1285 Giovanni Martinelli 1286 Cisco 1287 Via Philips 12 1288 20052 Monza, Italy 1290 Phone: +39 039 2092044 1291 Email: giomarti@cisco.com 1293 Contributor's Addresses 1295 Ming Chen 1296 Huawei Technologies Co., Ltd. 1297 F3-5-B R&D Center, Huawei Base, 1298 Bantian, Longgang District 1299 Shenzhen 518129 P.R.China 1300 Phone: +86-755-28973237 1301 Email: mchen@huawei.com 1303 Rebecca Han 1304 Huawei Technologies Co., Ltd. 1305 F3-5-B R&D Center, Huawei Base, 1306 Bantian, Longgang District 1307 Shenzhen 518129 P.R.China 1309 Phone: +86-755-28973237 1310 Email: hanjianrui@huawei.com 1312 Gabriele Galimberti 1313 Cisco 1314 Via Philips 12, 1315 20052 Monza, Italy 1317 Phone: +39 039 2091462 1318 Email: ggalimbe@cisco.com 1320 Alberto Tanzi 1321 Cisco 1322 Via Philips 12, 1323 20052 Monza, Italy 1325 Phone: +39 039 2091469 1326 Email: altanzi@cisco.com 1328 David Bianchi 1329 Cisco 1330 Via Philips 12, 1331 20052 Monza, Italy 1333 Email: davbianc@cisco.com 1335 Moustafa Kattan 1336 Cisco 1337 Dubai 500321 1338 United Arab Emirates 1340 Email: mkattan@cisco.com 1342 Dirk Schroetter 1343 Cisco 1345 Email: dschroet@cisco.com 1346 Daniele Ceccarelli 1347 Ericsson 1348 Via A. Negrone 1/A 1349 Genova - Sestri Ponente 1350 Italy 1352 Email: daniele.ceccarelli@ericsson.com 1354 Elisa Bellagamba 1355 Ericsson 1356 Farogatan 6, 1357 Kista 164 40 1358 Sweeden 1360 Email: elisa.bellagamba@ericcson.com 1362 Diego Caviglia 1363 Ericsson 1364 Via A. negrone 1/A 1365 Genova - Sestri Ponente 1366 Italy 1368 Email: diego.caviglia@ericcson.com