idnits 2.17.1 draft-martinelli-ccamp-wson-iv-info-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2013) is 3939 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.sup47' is mentioned on line 149, but not defined == Unused Reference: 'RFC2119' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 593, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-general-constraint-encode-11 == Outdated reference: A later version (-24) exists of draft-ietf-ccamp-rwa-info-18 == Outdated reference: A later version (-09) exists of draft-martinelli-ccamp-wson-iv-encode-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP G. Martinelli, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational X. Zhang, Ed. 5 Expires: January 14, 2014 Huawei Technologies 6 G. Galimberti 7 Cisco 8 A. Zanardi 9 D. Siracusa 10 CREATE-NET 11 July 13, 2013 13 Information Model for Wavelength Switched Optical Networks (WSONs) with 14 Impairments Validation 15 draft-martinelli-ccamp-wson-iv-info-02 17 Abstract 19 This document defines an information model to support Impairment- 20 Aware (IA) Routing and Wavelength Assignment (RWA) function. This 21 operation might be required in Wavelength Switched Optical Networks 22 (WSON) that already support RWA and the information model defined 23 here goes in addition and it is fully compatible with the already 24 defined information model for impairment-free RWA process in WSON. 26 This information model shall support all control plane architectural 27 options defined for WSON with impairment validation. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 14, 2014. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Properties of an Impairment Information Model . . . . . . . . 3 65 3. Background from WSON Information Model . . . . . . . . . . . 5 66 4. Optical Impairment Information Model . . . . . . . . . . . . 6 67 4.1. The Optical Impairment Vector . . . . . . . . . . . . . . 7 68 4.2. Node Information . . . . . . . . . . . . . . . . . . . . 7 69 4.3. Link Information . . . . . . . . . . . . . . . . . . . . 9 70 4.4. Path Information . . . . . . . . . . . . . . . . . . . . 9 71 5. Encoding Considerations . . . . . . . . . . . . . . . . . . . 10 72 6. Control Plane Architectures . . . . . . . . . . . . . . . . . 10 73 6.1. IV-Centralized . . . . . . . . . . . . . . . . . . . . . 11 74 6.2. IV-Distributed . . . . . . . . . . . . . . . . . . . . . 11 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 11 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 11.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Appendix A. G.680 Essential information . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 In the context of Wavelength Switched Optical Network (WSON), 88 [RFC6163] describes the basic framework for a GMPLS and PCE-based 89 Routing and Wavelength Assignment (RWA) control plane. The 90 associated information model [I-D.ietf-ccamp-rwa-info] defines all 91 information/parameters required by an RWA process. 93 There are cases of WSON where optical impairments plays a significant 94 role and are considered as important constraints. The framework 95 document [RFC6566] defines problem scope and related control plane 96 architectural options for the Impairment Aware Routing and Wavelength 97 Assignment (IA-RWA) operation. Options include different 98 combinations of Impairment Validation (IV) and RWA functions in term 99 of different combination of control plane functions (i.e., PCE, 100 Routing, Signaling). 102 This document provides an information model for the impairment aware 103 case to allow the impairment validation function implemented in the 104 control plane or enabled by control plane available information. 105 This model goes in addition to [I-D.ietf-ccamp-rwa-info] and it shall 106 support any control plane architectural option described by the 107 framework document (see sections 4.2 and 4.3 of [RFC6566]) where a 108 set of control plane combinations of control plane functions vs. IV 109 functions is provided. 111 1.1. Applicability 113 This document targets at Scenario C defined in [RFC6566] section 114 4.1.1., i.e., approximate impairment estimation. The usage of 115 "Approximate" concept helps to clarify that a path resulting from a 116 IV-RWA process are not guaranteed to work from an optical perspective 117 however, has better chance to be feasible than other(s). Setting up 118 the ligth-path, there is still a possibility to fail but this is an 119 acceptable in term of GMPLS control plane. 121 The information model defined in this document strictly relates to a 122 control plane information model hence it does not define any new 123 Optical Computational Model. Optical Computational Models are 124 defined by ITU-T, [ITU.G680] defines transfer functions for some 125 linear optical parameters while there's no general optical 126 computational model for non-linear effects. This information model 127 uses the available optical computational model as a reference, and 128 identify GMPLS WSON control plane extensions to allow IV functions to 129 perform its task. 131 Following here above considerations, scope of this information model 132 is to provide a generic mechanism so will easily support additional 133 impairment parameters and/or additional optical computational models. 135 2. Properties of an Impairment Information Model 136 An information model may have several attributes or properties that 137 need to be defined for each optical parameter made available to the 138 control plane. The properties will help to determine how the control 139 plane can deal with a specific impairment parameter, depending on 140 architectural options chosen within the overall impairment framework 141 [RFC6566]. In some case, properties value will help to identify the 142 level of approximation supported by the IV process. 144 o Time Dependency 145 This identifies how an impairment parameter may vary with time. 146 There could be cases where there is no time dependency, while in 147 other cases there may be need of re-evaluation after a certain 148 time. In this category, variations in impairments due to 149 environmental factors such as those discussed in [G.sup47] are 150 considered. In some cases, an impairment parameter that has time 151 dependency may be considered as a constant for approximation. In 152 this information model, we do neglect this property. 154 o Wavelength Dependency 155 This property identifies if an impairment parameter can be 156 considered as constant over all the wavelength spectrum of 157 interest or not. Also in this case a detailed impairment 158 evaluation might lead to consider the exact value while an 159 approximation IV might take a constant value for all wavelengths. 160 In this information model, we consider both case: dependency / no 161 dependency on a specific wavelength. This property appears 162 directly in the information model definitions and related 163 encoding. 165 o Linearity 166 As impairments are representation of physical effects, there are 167 some that have a linear behavior while other are non-linear. 168 Linear approximation is in scope of Scenario C of [RFC6566]. 169 During the impairment validation process, this property implies 170 that the optical effect (or quantity) satisfies the superposition 171 principle, thus a final result can be calculated by the sum of 172 each component. The linearity implies the additivity of optical 173 quantities considered during an impairment validation process. 174 The non-linear effects in general does not satisfy this property. 175 The information model presented in this document however, easily 176 allow introduction of non-linear optical effects with a linear 177 approximated contribution to the linear ones. 179 o Multi-Channel 180 There are cases where a channel's impairments take different 181 values depending on the aside wavelengths already in place, this 182 is mostly due to non-linear impairments. The result would be a 183 dependency among different LSPs sharing the same path. This 184 information model do not cosider this kind of property. 186 The following table summarize the above considerations where in the 187 first column reports the list of properties to be considered for each 188 optical parameter, while the second column states if this property is 189 taken into account or not by this information model. 191 +-----------------------+----------------------+ 192 | Property | Info Model Awareness | 193 +-----------------------+----------------------+ 194 | Time Dependency | no | 195 | Wavelength Dependency | yes | 196 | Linearity | yes | 197 | Multi-channel | no | 198 +-----------------------+----------------------+ 200 Table 1: Optical Impairment Properties 202 3. Background from WSON Information Model 204 In this section we report terms already defined for the WSON-RWA 205 (impairment free) as in [I-D.ietf-ccamp-rwa-info] and 206 [I-D.ietf-ccamp-general-constraint-encode]. The purpose is to 207 provide essential information that will be reused or extended for the 208 impairment case. 210 In particular [I-D.ietf-ccamp-rwa-info] defines the connectivity 211 matrix as the following: 213 ConnectivityMatrix ::= 215 According to [I-D.ietf-ccamp-general-constraint-encode], this 216 definition is further detailed as: 218 ConnectivityMatrix ::= 219 (( ) ...) 221 This second formula highlights how the connectivity matrix is built 222 by pairs of LinkSet objects identifying the internal connectivity 223 capability due to internal optical node constraint(s). It's 224 essentially binary information and tell if a wavelength or a set of 225 wavelengths can go from an input port to an output port. 227 As an additional note, connectivity matrix belongs to node 228 information and is purely static. Dynamic information related to the 229 actual usage of the connections is available through specific 230 extension to link information. 232 4. Optical Impairment Information Model 234 The idea behind this information model is to categorize the 235 impairment parameters into three types and extend the information 236 model already defined for impairment-free WSONs. The three 237 categories are: 239 o Node Information. The concept of connectivity matrix is reused 240 and extended to introduce an impairment matrix. 242 o Link Information representing impairment information related to a 243 specific link or hop. 245 o Path Information representing the impairment information related 246 to the whole path. 248 All the above three categories will make use of a generic container, 249 the Impairment Vector, to transport optical impairment information. 251 In term of optical parameters, this document is not to rephrase 252 content from [ITU.G680] but only provide necessary building blocks 253 that allow the IA-RWA process to apply the specific Optical 254 Computational Model (i.e. transfer functions). Section 9 of 255 [ITU.G680] defines the optical computational models and provides 256 information to calculate the following optical parameters: 258 o OSNR. Section 9.1 260 o Optical Power. As per Section 9.1, required by Optical 261 Computation Model for OSNR calculation. 263 o Chromatic Dispersion (CD). Section 9.2 265 o Polarization Mode Dispersion (PMD). Section 9.3 267 o Polarization Dependent Loss (PDL). Section 9.3 268 This information model however will allow however to add additional 269 parameters beyond the one defined by [ITU.G680] in order to support 270 additional computational models. This mechanism could eventually 271 applicable to both linear and non-linear parameters. 273 This information model makes the assumption that the each optical 274 node in the network is able to provide the control plane protocols 275 with its own parameter values however, no assumption is made on how 276 the optical node gets those value information (e.g. internally 277 computed, provisioned by a network management system, etc.). To this 278 extent, the information model intentionally ignores all internal 279 detailed parameters that are used by the formulas of the Optical 280 Computational Model (i.e., "transfer function") and simply provides 281 the object containers to carry results of the formulas. 283 4.1. The Optical Impairment Vector 285 Optical Impairment Vector (OIV) is defined as a list of optical 286 parameters to be associated to a WSON node or a WSON link. It is 287 defined as: 289 ::= ([] ) ... 291 The optional LabelSet object enables wavelength dependency property 292 as per Table 1. LabelSet has its definition in 293 [I-D.ietf-ccamp-general-constraint-encode]. 295 OPTICAL_PARAM. This object represents an optical parameter. The 296 Impairment vector can contain a set of parameters as identified by 297 [ITU.G697] since those parameters match the terms of the linear 298 impairments computational models provided by [ITU.G680]. This 299 information model does not speculate about the set of parameters 300 (since defined elsewhere, e.g. ITU-T), however it does not preclude 301 extentions by adding new parameters. 303 4.2. Node Information 305 Impairment matrix describes a list of the optical parameters that 306 applies to a network element as a whole or ingress/egress port pairs 307 of a network element. Wavelength dependency property of optical 308 paramters is also considered. 310 ImpairmentMatrix ::= 311 (( ) ...) 313 Where: 315 MatrixID. This ID is a unique identifier for the matrix. It 316 shall be unique in scope among connectivity matrices defined in 317 [I-D.ietf-ccamp-rwa-info] and impairment matrices defined here. 319 ConnType. This number identifies the type of matrix and it shall 320 be unique in scope with other values defined by impairment-free 321 WSON documents. 323 LinkSet. Same object definition and usage as 324 [I-D.ietf-ccamp-general-constraint-encode]. The pairs of LinkSet 325 identify one or more internal node constrain. 327 OIV. The Optical Impairment Vector defined above. 329 The model can be represented as a multidimensional matrix shown in 330 the following picture 332 _________________________________________ 333 / / / / / /| 334 / / / / / / | 335 /________/_______/_______/_______/_______/ | 336 / / / / / /| /| 337 / / / / / / | | 338 /________/_______/_______/_______/_______/ | /| 339 / / / / / /| /| | 340 / / / / / / | | /| 341 /________/_______/_______/_______/_______/ | /| | 342 / / / / / /| /| | /| 343 / / / / / / | | /| | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| | / PDL 345 | - | | | | | /| | /|/ 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| / 347 | | - | | | | /| | / PND 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /|/ 349 | | | - | | | /| / 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / Chr.Disp. 351 | | | | - | | /|/ 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 353 | | | | | - | / OSNR 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 357 The connectivity matrix from 358 [I-D.ietf-ccamp-general-constraint-encode] is only a two dimensional 359 matrix, containing only binary information, through the LinkSet 360 pairs. In this model, a third dimension is added by generalizing the 361 binary information through the Optical Impairment Vector associated 362 with each LinkSet pair. Optical parameters in the picture are 363 reported just as examples while details go into specific encoding 364 draft [I-D.martinelli-ccamp-wson-iv-encode]. 366 This representation shows the most general case however, the total 367 amount of information transported by control plane protocols can be 368 greatly reduced by proper encoding when the same set of values apply 369 to all LinkSet pairs. 371 [EDITOR NODE: first run of the information model does looks for 372 generality not for optimizing the quantity of information. We'll 373 deal with optimization in a further step.] 375 4.3. Link Information 377 For the list of optical parameters associated to the link, the same 378 approach used for the node-specific impairment information can be 379 applied. The link-specific impairment information is extended from 380 [I-D.ietf-ccamp-rwa-info] as the following: 382 ::= 383 [] [] 385 DynamicLinkInfo is already defined in [I-D.ietf-ccamp-rwa-info] while 386 OIV is the Optical Impairment Vector is defined in the previous 387 section. 389 4.4. Path Information 391 There are cases where the optical impariments can only be described 392 as a contrains on the overall end to end path. In such case, the 393 optical impariment and/or parameter, cannot be derived (using a 394 simple function) from the set of node / link contributions. 396 An equivalent case is the option reported by [RFC6566] on IV- 397 Candidate paths where, the control plane knows a list of optically 398 feasible paths so a new path setup can be selected among that list. 399 Independent from the protocols and functions combination (i.e. RWA 400 vs. Routing vs. PCE), the IV-Candidates imply a path property stating 401 that a path is optically feasible. 403 ::= 405 [EDITOR NOTE: section to be completed, especially to evaluate 406 protocol implications. Likely resemble to RSVP ADSPEC]. 408 5. Encoding Considerations 410 Details about encoding will be defined in a separate document 411 [I-D.martinelli-ccamp-wson-iv-encode] however worth remembering that, 412 within [ITU.G697] Appending V, ITU already provides a guideline for 413 encoding some optical parameters. 415 In particular [ITU.G697] indicates that each parameter shall be 416 represented by a 32 bit floating point number. 418 As an additional consideration, actual values for each optical 419 parameter are provided by each optical node and it could provide by 420 direct measurement or from some internal computation starting from 421 indirect measurement. In any case the encoding shall provide the 422 possibility to associate a variance with the parameter. This 423 information will enable the function implementing IA-RWA process to 424 make some additional considerations on wavelength feasibility. 425 [RFC6566] Section 4.1.3 reports some considerations regarding this 426 degree of confidence during the impairment validation process. 428 6. Control Plane Architectures 430 This section briefly describes how the defintions contained in this 431 information model will match the architectural options described by 432 [RFC6566]. 434 The first assumption is that the WSON GMPLS extentions are available 435 and operational. To such extent, the WSON-RWA will provide the 436 following information through its path computation (and RWA process): 438 o The wavelengths connectivity, considering also the connectivity 439 constraints limited by reconfigurable optics, and wavelengths 440 availability. 442 o The interface compatibility at the physical level. 444 o The Optical-Elettro-Optical (OEO) availability within the network 445 (and related physical interface compatibility). As already stated 446 by the framework this information it's very important for 447 impairment validation: 449 a. If the IV functions fail (path optically infeasible), the path 450 computation function may use an available OEO point to find a 451 feasible path. In normally operated networks OEO are mainly 452 uses to support optically unfeasible path than mere wavelength 453 conversion. 455 b. The OEO points reset the optical impairment information since 456 a new light is generated. 458 6.1. IV-Centralized 460 Centralized IV process is performed by a single entity (e.g., a PCE). 461 Given sufficient impairment information, it can either be used to 462 provide a list of paths between two nodes, which are valid in terms 463 of optical impairments. Alternatively, it can help validate whether 464 a particular selected path and wavelength is feasiable or not. This 465 requires distribution of impairment information to the entity 466 performing the IV process. 468 [EDITOR NOTE: to be completed] 470 6.2. IV-Distributed 472 For the distributed IV process, common computational models are 473 needed together with the information model defined in this document. 474 Computational models for the optical impairments are defined by ITU 475 standard body. The currently available computation models are 476 reported in [ITU.G680] and only cover the linear impairment case. 477 This does not require the distribution of impairment information 478 since they can be collected hop-by-hop using a control plane 479 signaling protocol. 481 [EDITOR NOTE: to be completed] 483 7. Acknowledgements 485 TBD 487 8. Contributing Authors 489 This document was the collective work of several authors. The text 490 and content of this document was contributed by the editors and the 491 co-authors listed below (the contact information for the editors 492 appears in appropriate section and is not repeated below): 494 Moustafa Kattan 495 Cisco 496 DUBAI, 500321 497 UNITED ARAB EMIRATES 499 Email: mkattan@cisco.com 501 Tim Gibbon 502 Department of Physics 503 Nelson Mandela Metropolitan University 504 SOUTH AFRICA 506 Email: Tim.Gibbon@nmmu.ac.za 508 Young Lee 509 Huawei 510 1700 Alma Drive, Suite 100 511 Plano, TX 75075 512 USA 514 Greg M. Bernstein 515 Grotto Networking 516 Fremont, CA 517 USA 519 Phone: +1 510 573 2237 520 Email: gregb@grotto-networking.com 522 Phone: +1 972 509 5599 x2240 523 Fax: +1 469 229 5397 524 Email: ylee@huawei.com 526 Fatai Zhang 527 Huawei 528 F3-5-B R&D Center, Huawei Base 529 Bantian, Longgang District 530 P.R. China 532 Phone: +86-755-28972912 533 Email: zhangfatai@huawei.com 535 9. IANA Considerations 537 This document does not contain any IANA requirement. 539 10. Security Considerations 541 This document defines an information model for impairments in optical 542 networks. If such a model is put into use within a network it will 543 by its nature contain details of the physical characteristics of an 544 optical network. Such information would need to be protected from 545 intentional or unintentional disclosure. 547 11. References 549 11.1. Normative References 551 [ITU.G680] 552 International Telecommunications Union, "Physical transfer 553 functions of optical network elements ", ITU-T 554 Recommendation G.680, July 2007. 556 [ITU.G697] 557 International Telecommunications Union, "Optical 558 monitoring for dense wavelength division multiplexing 559 systems ", ITU-T Recommendation G.697, February 2012. 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, March 1997. 564 11.2. Informative References 566 [I-D.ietf-ccamp-general-constraint-encode] 567 Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "General 568 Network Element Constraint Encoding for GMPLS Controlled 569 Networks", draft-ietf-ccamp-general-constraint-encode-11 570 (work in progress), May 2013. 572 [I-D.ietf-ccamp-rwa-info] 573 Lee, Y., Bernstein, G., Li, D., and W. Imajuku, "Routing 574 and Wavelength Assignment Information Model for Wavelength 575 Switched Optical Networks", draft-ietf-ccamp-rwa-info-18 576 (work in progress), May 2013. 578 [I-D.martinelli-ccamp-wson-iv-encode] 579 Martinelli, G., Kattan, M., Galimberti, G., and A. 580 Zanardi, "Encoding for WSON Information Model with 581 Impairments Validation.", draft-martinelli-ccamp-wson-iv- 582 encode-01 (work in progress), February 2013. 584 [I-D.narten-iana-considerations-rfc2434bis] 585 Narten, T. and H. Alvestrand, "Guidelines for Writing an 586 IANA Considerations Section in RFCs", draft-narten-iana- 587 considerations-rfc2434bis-09 (work in progress), March 588 2008. 590 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 591 June 1999. 593 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 594 Text on Security Considerations", BCP 72, RFC 3552, July 595 2003. 597 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 598 GMPLS and Path Computation Element (PCE) Control of 599 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 600 April 2011. 602 [RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A 603 Framework for the Control of Wavelength Switched Optical 604 Networks (WSONs) with Impairments", RFC 6566, March 2012. 606 Appendix A. G.680 Essential information 608 TBD if we need some info instead of reading [ITU.G680] 610 [Xian's note]: I thought about listing paramters to show different 611 categories. but it seems to contradict to the idea of providing a 612 general enough information model. Any suggestions? 614 Authors' Addresses 616 Giovanni Martinelli (editor) 617 Cisco 618 via Philips 12 619 Monza 20900 620 Italy 622 Phone: +39 039 2092044 623 Email: giomarti@cisco.com 624 Xian Zhang (editor) 625 Huawei Technologies 626 F3-5-B R&D Center, Huawei Base 627 Bantian, Longgang District 628 Shenzen 518129 629 P.R. China 631 Phone: +86 755 28972913 632 Email: zhang.xian@huawei.com 634 Gabriele M. Galimberti 635 Cisco 636 Via Philips,12 637 Monza 20900 638 Italy 640 Phone: +39 039 2091462 641 Email: ggalimbe@cisco.com 643 Andrea Zanardi 644 CREATE-NET 645 via alla Cascata 56 C, Povo 646 Trento 38100 647 Italy 649 Email: andrea.zanardi@create-net.org 651 Domenico Siracusa 652 CREATE-NET 653 via alla Cascata 56 C, Povo 654 Trento 38100 655 Italy 657 Email: domenico.siracusa@create-net.org