idnits 2.17.1 draft-fuxh-ccamp-multi-stage-multiplex-config-ospf-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([MULTI-STAGES-MULTIPLEXING-CONFIG-REQ], [MULTI-STAGES-MULTIPLEXING-CONFIG-FRW]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 26, 2010) is 5111 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MULTI-STAGES-MULTIPLEXING-CONFIG-REQ' is mentioned on line 17, but not defined == Missing Reference: 'MULTI-STAGES-MULTIPLEXING-CONFIG-FRW' is mentioned on line 18, but not defined == Missing Reference: 'RFC3630' is mentioned on line 143, but not defined == Missing Reference: 'RFC4202' is mentioned on line 133, but not defined == Missing Reference: 'RFC4203' is mentioned on line 400, but not defined == Missing Reference: 'RFC3473' is mentioned on line 400, but not defined == Missing Reference: 'RFC4205' is mentioned on line 400, but not defined ** Obsolete undefined reference: RFC 4205 (Obsoleted by RFC 5307) == Missing Reference: 'RFC4204' is mentioned on line 401, but not defined == Missing Reference: 'RFC5440' is mentioned on line 401, but not defined == Missing Reference: 'GMPLS-SEC' is mentioned on line 401, but not defined == Unused Reference: 'I-D.ietf-ccamp-gmpls-g709-framework' is defined on line 416, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-ccamp-gmpls-g709-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-gmpls-g709-framework (ref. 'I-D.ietf-ccamp-gmpls-g709-framework') Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft M. Betts 4 Intended status: Standards Track ZTE Corporation 5 Expires: October 28, 2010 R. Jing 6 X. Huo 7 China Telecom 8 April 26, 2010 10 OSPF-TE Extension for Multi Stages Multiplexing Configuration in G.709 11 Optical Transport Network 12 draft-fuxh-ccamp-multi-stage-multiplex-config-ospf-00 14 Abstract 16 Multi stages multiplexing configuration requirement is defined in 17 [MULTI-STAGES-MULTIPLEXING-CONFIG-REQ] document. Multi stages 18 multiplexing configuration framework is diefined in [MULTI-STAGES- 19 MULTIPLEXING-CONFIG-FRW] document. They describe some scenarios for 20 the interworking between regions with 1.25G TS and 2.5G TS and the 21 multi-domain OTN applications based on the tunnel design. Multi 22 stages multiplexing is desirable to facilitate the introduction of 23 new ODU0 and ODUflex signals to an existing network without having to 24 upgrade every node in the network. So ODU0/ODUflex can be mapped 25 into ODU1/ODU2/ODU3 and transit across the 2.5G TS region. Multi 26 stages multiplexing/demultiplexing are also used to support the 27 multi-domain OTN applications based on the tunnel design. From the 28 perspective of Management Plane and Control Plane, they must get 29 multi stages multiplexing/demultiplexing capability of each gateway 30 nodes for path computation. This document describes the OSPF-TE 31 extension for multi stages multiplexing configuration in G.709 32 Optical Transport Network. 34 Conventions Used In This Document 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on October 28, 2010. 57 Copyright Notice 59 Copyright (c) 2010 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. OSPF-TE Extension for Multi Stages Multiplexing 76 Configuration . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2.1. Multi Stages Multiplexing Capability Constraint Sub-TLV . 5 78 2.2. Multi Stages Multiplexing Capability OSPF-TE Extension 79 Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 2.3. Routing Procedure . . . . . . . . . . . . . . . . . . . . 10 81 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 5.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 G.709 has supported a single stage of ODU multiplexing. The 91 practical consequence of this in OTN v1 is an ODU1 can be mapped 92 directly to a tributary slot of an ODU3, without having to be first 93 mapped into an ODU2. The motivation for this architecture is 94 reducing complexity. In the normal progression of things, new 95 additions to the OTN were expected to be at faster bit rates, and 96 thus the single stage concept could be easily maintained going 97 forward. 99 The introduction of ODU0 and ODUflex to the OTN hierarchy creates a 100 situation where the newly added ODUk signals have a bit rate that is 101 lower than any of the existing signals, which presents some different 102 challenges because the new signals can be clients of the existing 103 signals. As a result, there are clear applications where multi 104 stages of multiplexing would be desirable to facilitate the 105 introduction of these new ODU0 and ODUflex signals to an existing 106 network without having to upgrade every node in the network. Using 107 multi stages of multiplexing allows the operator to confine the new 108 rates to only those nodes that need to support them. 110 A second potential application for multi stages outside of an upgrade 111 scenario would be a network design based on tunnels. Multi stages 112 multiplexing are used to support the multi-domain OTN applications 113 based on the tunnel design. 115 From the perspective of Control Plane, path computation entity must 116 get multi stages multiplexing/demultiplexing capability of each 117 gateway nodes for path computation. This document describes the 118 OSPF-TE extension in order for multi stages multiplexing 119 configuration in G.709 Optical Transport Network. 121 2. OSPF-TE Extension for Multi Stages Multiplexing Configuration 123 Multi stages multiplexing/demultiplexing capability information must 124 be flooded into the path computation entity and the routing domain by 125 gateway nodes with the IGP protocol. LSAs which are advertised by 126 gateway nodes must carry multi stages multiplexing/demultiplexing 127 capability information. Multi stages multiplexing/demultiplexing 128 capability should be configured by Management Plane (e.g., Network 129 Planning Tool) or discovered by the gateway node based on the 130 switching and adaptation capability of switching fabrics and cards. 132 This document defines extensions to the OSPF routing protocol which 133 is defined in [RFC3630], [RFC4202], and [RFC4203] in order for multi 134 stages multiplexing configuration. The TE LSA, which is an opaque 135 LSA with area flooding scope [RFC3630], has only one top-level Type/ 136 Length/Value (TLV) triplet and has one or more nested sub-TLVs. One 137 of the top-level TLVs is Link [RFC3630] value. This document 138 enhances the sub-TLVs for the Link TLV to support Multi Stages 139 Multiplexing Configuration. 141 2.1. Multi Stages Multiplexing Capability Constraint Sub-TLV 143 The Link top-level TLV is defined in [RFC3630], [RFC4203]. Link ID, 144 Administrative Group, Interface Switching Capability 145 Descriptor(ISCD), Link Protection Type, Shared Risk Link Group 146 Information (SRLG), and Traffic Engineering Metric are among the 147 typical link sub-TLVs. In order to make path computation entity get 148 the multi stages multiplexing capability information of gateway node, 149 this document add an additional sub-TLV to the Link-TLV. If there is 150 no any multi stages multiplexing configuration for operator, This 151 sub-TLV is optional for OTN application. Single stage multiplexing 152 capability don't need to be indicated by this sub-TLV. 154 Multi Stages Multiplexing Capability Constraint is a sub-TLV of the 155 Link TLV. The type of this sub-TLV will be assigned by IANA, and 156 length is eight octets. The value field of this sub-TLV contains 157 multi stages multiplexing capability information which is supported 158 by link port. 160 0 1 2 3 161 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Type (TBD) (IANA) | Length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Number | Reserve |MSMH 1 | ...MSMC 1... | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |MSMH 1 | ...MSMC 2... | ... | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 |MSMH M | ...MSMC M... | padding | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 o Number (8 bits): Indicates the total nunmber of multi stages 173 multiplexing capability which is supported by the link port. 175 o Reserve (8 bits): for future use. 177 o (MSMH 1, MSMC 1), (MSMH 2, MSMC 2), ... ,(MSMH M, MSMC M): 178 Indicates each multi stages multiplexing capability detailed 179 information. 181 * MSMH 1, MSMH2, ... , MSMH M (4 bits): Indicates the Multi 182 Stages Multiplexing Hierarchies (MSMH). 184 * MSMC 1, MSMC 2, ... ,MSMC M: Indicates the multi stages 185 multiplexing capability. The length of Multi Stages 186 Multiplexing Capability (MSMC) information depends on the multi 187 stages multiplexing hierarchies (MSMH). The length of MSMC is 188 (MSMH+1) * 4. Each ODUk (k=1, 2, 3, 4, 2e, flex) is indicated 189 by 4 bits. Following is the Signal Type for G.709 Amendment 3. 191 Value Type 192 ----- ---- 193 0000 ODU0 194 0001 ODU1 195 0010 ODU2 196 0011 ODU3 197 0100 ODU4 198 0101 ODU2e 199 0110 ODUflex 200 7-15 Reserved (for future use) 202 o The padding is used to make the Multi Stages Multiplexing 203 Capability sub-TLV 32-bits aligned. 205 2.2. Multi Stages Multiplexing Capability OSPF-TE Extension Example 207 In the following figure, different gateway nodes support different 208 multi stages multiplexing/demultiplexing capability. From the 209 perspective of Control Plane, it must get multi stages multiplexing/ 210 demultiplexing capability of each gateway nodes for path computation. 211 So the path computation entity can select a proper kind of multi 212 stages multiplexing/demultiplexing of gateway nodes along a specific 213 E2E connection. 215 Gateway 2 provides demultiplexing to recover the ODU2 from ODU4 and 216 an additional multiplexing of the ODU2 to ODU3 and vice versa. 218 -- 219 /|12|\ 220 / -- \ 221 / \ 222 -- / ODU2 \-- 223 |11| Network 4 |13| 224 -- \ / -- 225 \ / 226 \ - / 227 \| |/ 228 - Gateway4 229 | 230 | 231 - - - 232 /|2|\ /|5|\ /|8|\ 233 / - \ / - \ / - \ 234 / \ / \ / \ 235 - / ODU2 \ - - / ODU3 \ - - / ODU2 \ -- 236 |1| Network 1 | |----|4| Network 2 |7|---- | | Network 3 |10| 237 - \ / - - \ / - - \ / -- 238 \ /Gateway1 \ / Gateway3\ / 239 \ - / \ - / \ - / 240 \|3|/ \|6|/ \|9|/ 241 - - - 242 | 243 - 244 | |Gateway2 245 - 246 | 247 -- -- -- 248 /|15|\ /|18|\ /|21|\ 249 / -- \ / -- \ / -- \ 250 / \ / \ / \ 251 -- / ODU2 \ -- -- / ODU4 \-- -- / ODU3 \ -- 252 |14| Network 5 | |----|17| Network 6 |20|----| | Network 7 |23| 253 -- \ / -- -- \ /-- -- \ / -- 254 \ /Gateway5 \ / Gateway7\ / 255 \ -- / \ -- / \ -- / 256 \|16|/ \|19|/ \|22|/ 257 -- -- -- 259 Gateway 1 supports the following multi stages multiplexing/ 260 demultiplexing capability. 262 o ODU0-ODU1-ODU3 263 o ODU0-ODU2-ODU3 265 o ODU1-ODU2-ODU3 267 o ODUflex-ODU2-ODU3 269 The value of Multi Stages Multiplexing Capability Constraint Sub-TLV 270 is as followings: 272 0 1 2 3 273 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type (TBD) | Length(12) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | 4 | Reserve |0 1 0|0 0 0 0|0 0 0 1|0 0 1 1|0| 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |1 0|0 0 0 0|0 0 1 0|0 0 1 1|0 1 0|0 0 0 1|0 0 1 0|0 0 1 1|0 1 0| 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |0 1 1 0|0 0 1 0|0 0 1 1| padding | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Gateway 3 supports the following multi stages multiplexing/ 285 demultiplexing capability. 287 o ODU0-ODU2-ODU3 289 o ODUflex-ODU2-ODU3 291 The value of Multi Stages Multiplexing Capability Constraint Sub-TLV 292 is as followings: 294 0 1 2 3 295 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type (TBD) | Length(8) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | 2 | Reserve |0 1 0|0 0 0 0|0 0 1 0|0 0 1 1|0| 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |1 0|0 1 1 0|0 0 1 0|0 0 1 1| padding | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Gateway 4 supports the following multi stages multiplexing/ 305 demultiplexing capability. It doesn't support the ODUflex-ODU2-ODU3 306 multiplexing. The operator limits the ODUflex application to the 307 local network. There is no any multi-domain ODUflex application 308 which goes into ODU2 Network 4. 310 o ODU0-ODU1-ODU3 312 o ODU0-ODU2-ODU3 314 The value of Multi Stages Multiplexing Capability Constraint Sub-TLV 315 is as followings: 317 0 1 2 3 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type (TBD) | Length(8) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | 2 | Reserve |0 1 0|0 0 0 0|0 0 0 1|0 0 1 1|0| 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 |1 0|0 0 0 0|0 0 1 0|0 0 1 1| padding | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Gateway 5 supports the following multi stages multiplexing/ 328 demultiplexing capability. 330 o ODU0-ODU2-ODU4 332 o ODU0-ODU3-ODU4 334 o ODU1-ODU2-ODU4 336 o ODU1-ODU3-ODU4 338 o ODUflex-ODU2-ODU4 340 o ODUflex-ODU3-ODU4 342 The value of Multi Stages Multiplexing Capability Constraint Sub-TLV 343 is as followings: 345 0 1 2 3 346 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type (TBD) | Length(16) | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | 6 | Reserve |0 1 0|0 0 0 0|0 0 1 0|0 1 0 0|0| 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |1 0|0 0 0 0|0 0 1 1|0 1 0 0|0 1 0|0 0 0 1|0 0 1 0|0 1 0 0|0 1 0| 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 |0 0 0 1|0 0 1 1|0 1 0 0|0 1 0|0 1 1 0|0 0 1 0|0 1 0 0|0 1 0|0 1| 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 |1 0|0 0 1 1|0 1 0 0| padding | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Gateway 7 supports the following multi stages multiplexing/ 360 demultiplexing capability. It doesn't support the ODU1-ODU2-ODU4 and 361 ODU1-ODU3-ODU4 multiplexing. The operator limits the ODU1 362 application to the local network. There is no any multi-domain ODU1 363 application which goes into ODU3 Network 7. 365 o ODU0-ODU2-ODU4 367 o ODU0-ODU3-ODU4 369 o ODUflex-ODU2-ODU4 371 o ODUflex-ODU3-ODU4 373 The value of Multi Stages Multiplexing Capability Constraint Sub-TLV 374 is as followings: 376 0 1 2 3 377 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type (TBD) | Length(12) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | 4 | Reserve |0 1 0|0 0 0 0|0 0 1 0|0 1 0 0|0| 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 |1 0|0 0 0 0|0 0 1 1|0 1 0 0|0 1 0|0 1 1 0|0 0 1 0|0 1 0 0|0 1 0| 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |0 1 1 0|0 0 1 1|0 1 0 0| padding | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 2.3. Routing Procedure 390 TBD 392 3. Security Considerations 394 The use of control plane protocols for signaling, routing, and path 395 computation opens an OTN to security threats through attacks on those 396 protocols. The data plane technology for an OTN does not introduce 397 any specific vulnerabilities, and so the control plane may be secured 398 using the mechanisms defined for the protocols discussed. For 399 further details of the specific security measures refer to the 400 documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], 401 [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of 402 security vulnerabilities and protection mechanisms for the GMPLS 403 control plane. 405 4. IANA Considerations 407 TBD 409 5. References 411 5.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [I-D.ietf-ccamp-gmpls-g709-framework] 417 Zhang, F., Li, D., Li, H., Belotti, S., Han, J., Betts, 418 M., Grandi, P., and E. Varma, "Framework for GMPLS and PCE 419 Control of G.709 Optical Transport Networks", 420 draft-ietf-ccamp-gmpls-g709-framework-00 (work in 421 progress), April 2010. 423 5.2. Informative References 425 Authors' Addresses 427 Xihua Fu 428 ZTE Corporation 430 Email: fu.xihua@zte.com.cn 432 Malcolm Betts 433 ZTE Corporation 435 Email: malcolm.betts@zte.com.cn 437 Ruiquan Jing 438 China Telecom 440 Email: jingrq@ctbri.com.cn 441 Xiaoli Huo 442 China Telecom 444 Email: huoxl@ctbri.com.cn