idnits 2.17.1 draft-li-idr-congestion-status-extended-community-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4360, but the abstract doesn't seem to directly say this. It does mention RFC4360 though, so this could be OK. -- The draft header indicates that this document updates RFC7153, but the abstract doesn't seem to directly say this. It does mention RFC7153 though, so this could be OK. -- The draft header indicates that this document updates RFC4271, but the abstract doesn't seem to directly say this. It does mention RFC4271 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4271, updated by this document, for RFC5378 checks: 2006-01-13) (Using the creation date from RFC4360, updated by this document, for RFC5378 checks: 2001-07-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2018) is 2240 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: 'IEEE.754.1985' is mentioned on line 309, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-04 == Outdated reference: A later version (-15) exists of draft-gredler-idr-bgplu-epe-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Z. Li 3 Internet-Draft China Mobile 4 Updates: 4271, 4360, 7153 (if approved) J. Dong 5 Intended status: Standards Track Huawei Technologies 6 Expires: September 4, 2018 March 3, 2018 8 Carry congestion status in BGP community 9 draft-li-idr-congestion-status-extended-community-07 11 Abstract 13 To aid BGP receiver to steer the AS-outgoing traffic among the exit 14 links, this document introduces a new BGP community, congestion 15 status community, to carry the link bandwidth and utilization 16 information, especially for the exit links of one AS. If accepted, 17 this document will update RFC4271, RFC4360 and RFC7153. 19 The introducd congestion status community is not used to impact the 20 decision process of BGP specified in section 9.1 of RFC4271, but can 21 be used by route policy to impact the data forwarding behavior. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 4, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 3. Previous Work . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Solution Alternative 1: Extended Community . . . . . . . . . 4 61 5. Solution Alternative 2: Large Community . . . . . . . . . . . 6 62 6. Solution Alternative 3: Community Container . . . . . . . . . 6 63 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 11.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Appendix A. Bandwidth Values . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 Knowing the congestion status (bandwidth and utilization) of the AS 76 exit links is useful for traffic steering, especially for steering 77 the AS outgoing traffic among the exit links. Section 7 of 78 [I-D.gredler-idr-bgplu-epe] explicitly specifies this kind of 79 requirement, which is also needed in our field network. 81 The following figure is used to illustrate the benefits of knowing 82 the congestion status of the AS exit links. AS A has multiple exit 83 links connected to AS B. Both AS A and B has exit link to AS C, and 84 AS B provides transit service for AS A. Due to cost or some other 85 reasons, AS A prefers using AS B to transmit its' traffic to AS C, 86 not the directly connected link between AS A and C. If the exit 87 routers, Router 7 and 8, in AS A tell their iBGP peers the congestion 88 status of the exit links, the peers in turn can steer some outgoing 89 traffic toward the less loaded exit link. If AS A knows the link 90 between AS B and AS C is congested, it can steer some traffic towards 91 AS C from AS B to the directly connected link by applying some route 92 policies. 94 +-------------------------------------------+ 95 | AS C | 96 | +----------+ +----------+ | 97 +--| Router 1 |---------------| Router 2 |--+ 98 +----------+ +----------+ 99 | | 100 | | 101 | +----------+ 102 | +--------| Router 3 |----------+ 103 | | +----------+ | 104 | | AS B | 105 | | +----------+ +----------+ | 106 | +-| Router 4 |----| Router 5 |-+ 107 | +----------+ +----------+ 108 | | | 109 | | | 110 +----------+ +----------+ +----------+ 111 +--| Router 6 |--------| Router 7 |----| Router 8 |-+ 112 | +----------+ +----------+ +----------+ | 113 | AS A | 114 +---------------------------------------------------+ 116 This document introduces new BGP extensions to deliver the congestion 117 status of the exit link to other BGP speakers. The BGP receiver can 118 then use this community to deploy route policy, thus steer AS 119 outgoing traffic according to the congestion status of the exit 120 links. This mechanisum can be used by both iBGP and eBGP. 122 In this verion, we provide three solution alternatives according to 123 the discussion in the face to face meetings and mail list. After 124 adoption, one solution will be selected as the final solution based 125 on the working group consensus. 127 In a network deployed SDN (Software Defined Network) controller, 128 congestion status extended community can be used by the controller to 129 steer the AS outgoing traffic among all the exit links from the 130 perspective of the whole network. 132 For the network with Route Reflectors (RRs) [RFC4456], RRs by default 133 only advertise the best route for a specific prefix to their clients. 134 Thus RR clients has no opportunity to compare the congestion status 135 among all the exit links. In this situation, to allow RR clients 136 learning all the routes for a specific prefix from all the exit 137 links, RRs are RECOMMENDED to enable add-path functionality 138 [RFC7911]. 140 To emphasize, the introduced new BGP extensions have no impact on the 141 decision process of BGP specified in section 9.1 of [RFC4271], but 142 can be used by route policy to impact the data forwarding behavior. 144 2. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. Previous Work 152 In [constrained-multiple-path], authors from France Telecom also 153 specified the requirement to know the congestion status of a link. 155 To aid a router to perform unequal cost load balancing, experts from 156 Cisco introduced Link Bandwidth Extended Community in 157 [link-bandwidth-community] to carry the cost to reach the external 158 BGP neighbor. The cost can be either configured per neighbor or 159 derived from the bandwidth of the link that connects the router to a 160 directly connected external neighbor. This document was accepted by 161 the IDR working group, but expired in 2013. 163 Link Bandwidth Extended Community only carries the link bandwidth of 164 the exit link. The method provided in our document can carry the 165 link bandwidth together with the link utilization information. What 166 the BGP receiver needs to impact its traffic steering policy is the 167 up-to-date unused link bandwith, which can be derived from the link 168 bandwith and link utilization. Since Link Bandwidth Extended 169 Community is expired, the BGP speaker who receives update message 170 with both Link Bandwidth Extended Community and Congestion Status 171 Community SHOULD ignore the Link Bandwidth Extended Community and use 172 the Congestion Status Community. 174 4. Solution Alternative 1: Extended Community 176 As described in [RFC4360], the extended community attribute is an 177 8-octet value with the first one or two octets to indicate the type 178 of this attribute. Since congestion status community needs to be 179 delivered from on AS to other ASes, and used by the BGP speakers both 180 in other ASes and within the same AS as the sender, it MUST be a 181 transitive extended community, i.e. the T bit in the first octet MUST 182 be zero. 184 We only define the congestion status community for four-octet AS 185 number [RFC6793], since all the BGP speakers can handle four-octet AS 186 number now and the two-octet AS numbers can be mapped to four-octet 187 AS numbers by setting the two high-order octets of the four-octet 188 field to zero, as per [RFC6793]. 190 Congestion status community is a sub-type allocated from Transitive 191 Four-Octet AS-Specific Extended Community Sub-Types defined in 192 section 5.2.4 of [RFC7153]. Its format is as Figure 1. 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type =0x02 | Sub-Type | Sender AS Number | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Sender AS Number (cont.) | Bandwidth | Utilization | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 1: Congestion status extended community 204 Type: 1 octet. This field MUST be 0x02 to indicate this is a 205 Transitive Four-Octet AS-Specific Extended Community. 207 Sub-Type: 1 octet. It is used to indicate this is a Congestion 208 Status Extended Community. Its value is to be assigned by IANA. 210 Sender AS Number: 4 octets. Its value is the AS number of the BGP 211 speaker who generates this congestion status extended community. 212 If the generator has 2-octct AS number, it MUST encode its AS 213 number in the last (low order) two bytes and set the first (high 214 order) two bytes to zero, as per [RFC6793]. 216 Bandwidth: 1 octet. Its value is the bandwidth of the exit link 217 in unit of 10 gbps (gigabits per second). The link with bandwidth 218 less than 10 gbps is not suitable to use this feature. To reflect 219 the practice that sometimes the traffic is rate limited to a 220 capacity smaller than the physical link, the value of the 221 bandwidth can be the configured capacity of the link. The 222 available configured capacity can be calculated from this field 223 together with Utilization field. Zero means the bandwidth is 224 unknown or is not advertised to other peers. 226 Utilization: 1 octet. Its value is the utilization of the exit 227 link in unit of percent. A value bigger than 100 means the 228 incoming traffic is higher than the link capacity. We can use the 229 "Utilization" field together with the "Bandwidth" field to 230 calculate the traffic load that we can further steer to this exit 231 link. 233 5. Solution Alternative 2: Large Community 235 As described in [RFC8092], the BGP large community attribute is an 236 optional transitive path attribute of variable length, consisting of 237 12-octet values. The BGP large community attribute is mainly used to 238 extend the size of BGP Community [RFC1997] and Extened Community 239 [RFC4360], thus to accommodate at least two four-octet ASNs 240 [RFC6793]. As shown in the following figure, the format of the 241 12-octet BGP Large Community value is not suitable to be used to 242 define new type for congestion status community. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Global Administrator | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Local Data Part 1 | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Local Data Part 2 | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 2 256 Global Administrator: A four-octet namespace identifier. 258 Local Data Part 1: A four-octet operator-defined value. 260 Local Data Part 2: A four-octet operator-defined value. 262 6. Solution Alternative 3: Community Container 264 As described in [I-D.ietf-idr-wide-bgp-communities], the BGP 265 Community Container has flexible encoding format, which we can use to 266 define the congestion status community. 268 A new type of the BGP Community Container is defined for the 269 congestion status community, which has the same common header as the 270 BGP Community Container with the following encoding format. 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 | Flags |C|T| Reserved | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Length | Sender AS Number | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Sender AS Number (cont.) | Bandwidth | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Bandwidth (cont.) | Utilization | Reserved | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 3 286 Type: 2 octets. Its value is to be assigned by IANA from the 287 registry "BGP Community Container Types" to indicate this is the 288 Congestion Status Community. 290 Flags: 1 octet. C and T bits MUST be set to indicate the 291 Congestion Status Community is transitive across confederation and 292 AS boundaries. The other bits in Flags field MUST be set to zero 293 when originated and SHOULD be ignored upon receipt. 295 Reserved: Reserved fields are reserved for future definition, 296 which MUST be set to zero when originated and SHOULD be ignored 297 upon receipt. 299 Length: 2 octets. This field represents the total length of a 300 given container's contents in octets. 302 Sender AS Number: 4 octets. Its value is the AS number of the BGP 303 speaker who generates this congestion status community. If the 304 generator has 2-octct AS number, it MUST encode its AS number in 305 the last (low order) two bytes and set the first (high order) two 306 bytes to zero, as per [RFC6793]. 308 Bandwidth: 4 octets. Its value is the bandwidth of the exit link 309 in IEEE floating point format (see [IEEE.754.1985]), expressed in 310 bytes per second. Zero means the bandwidth is unknown or is not 311 advertised to other peers. Appendix A lists some typical 312 bandwidth values, most of which are extracted from Section 3.1.2 313 of [RFC3471]. 315 To reflect the practice that sometimes the traffic is rate limited 316 to a capacity smaller than the physical link, the value of the 317 bandwidth can be the configured capacity of the link. The 318 available configured capacity can be calculated from this field 319 together with Utilization field. 321 Utilization: 1 octet. Its value is the utilization of the exit 322 link in unit of percent. A value bigger than 100 means the 323 incoming traffic is higher than the link capacity. We can use the 324 "Utilization" field together with the "Bandwidth" field to 325 calculate the traffic load that we can further steer to this exit 326 link. 328 7. Deployment Considerations 330 o To avoid route oscillation 332 The exit router SHOULD set a threshold. When the utilization 333 change reaches the threshold, the exit router SHOULD generate a 334 BGP update message with congestion status community. 336 Implementations SHOULD further reduce the BGP update messages 337 trigered by link utilization change using the method similar to 338 BGP Route Flap Damping [RFC2439]. When link utilization change 339 by small amounts that fall under thresholds that would cause 340 the announcement of BGP update message, implementations SHOULD 341 suppress the announcement and set the penalty value 342 accordingly. 344 To reduce the update churn introduced, when one BGP router 345 needs to re-advertise a BGP path due to attribute changes, it 346 SHOULD update its Congestion Status Community at the same time. 347 Supposing there are N ASes on the way from the far end egress 348 BGP speaker to the final ingress BGP speaker, this allows 349 reducing the update churn as the final ingress BGP speaker will 350 receive a single UPDATE refreshing the N communities, rather 351 than N UPDATEs, each refreshing one community. 353 o To avoid traffic oscillation 355 Traffic oscillation means more traffic than expected is 356 attracted to the low utilized link, and some traffic has to be 357 steered back to other links. 359 Route policy is RECOMMENDED to be set at the exit router. 360 Congestion status community is only conveyed for some specific 361 routes or only for some specific BGP peers. 363 Congestion status community can also be used in a SDN network. 364 The SDN controller uses the exit link utilization information 365 to steer the Internet access traffic among all the exit links 366 from the perspective of the whole network. 368 o Other Conserns 369 To avoid forwarding loops incremental deployment issues, 370 complications in error handling, the reception of such 371 community over IBGP session SHOULD NOT influence routing 372 decision unless tunneling is used to reach the BGP Next-Hop. 374 8. Security Considerations 376 This document defines a new BGP community to carry the congestion 377 status of the exit link. It is up to the BGP receiver to trust the 378 congestion status communities or not. Following deployment models 379 can be considered. 381 The BGP receiver may choose to only trust the congestion status 382 communities generated by some specific ASes or containing 383 bandwidth greater than a specific value. 385 You can filter the congestion status communities at the border of 386 your trust/administrative domain. Hence all the ones you receive 387 are trusted. 389 You can record the communities received over time, monitor the 390 congestion e.g. via probing, detect inconsistency and choose to 391 not trust anymore the ASes which advertise fake news. 393 9. IANA Considerations 395 For solution alternative 1, one sub-type is solicited to be assigned 396 from Transitive Four-Octet AS-Specific Extended Community Sub-Types 397 registry to indicate the Congestion Status Community defined in this 398 document. 400 For solution alternative 3, one community value is solicited to be 401 assigned from the registry "Registered Type 1 BGP Wide Community 402 Community Types" to indicate the Congestion Status Community defined 403 in this document. 405 10. Acknowledgments 407 We appreciate the constructive suggestions received from Bruno 408 Decraene. Many thanks to Rudiger Volk, Susan Hares, John Scudder, 409 Randy Bush for their review and comments to improve this document. 411 11. References 412 11.1. Normative References 414 [I-D.ietf-idr-wide-bgp-communities] 415 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 416 and P. Jakma, "BGP Community Container Attribute", draft- 417 ietf-idr-wide-bgp-communities-04 (work in progress), March 418 2017. 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 426 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 427 DOI 10.17487/RFC4271, January 2006, 428 . 430 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 431 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 432 February 2006, . 434 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 435 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 436 March 2014, . 438 [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, 439 I., and N. Hilliard, "BGP Large Communities Attribute", 440 RFC 8092, DOI 10.17487/RFC8092, February 2017, 441 . 443 11.2. Informative References 445 [constrained-multiple-path] 446 Boucadair, M. and C. Jacquenet, "Constrained Multiple BGP 447 Paths", October 2010, . 450 [I-D.gredler-idr-bgplu-epe] 451 Gredler, H., Vairavakkalai, K., R, C., Rajagopalan, B., 452 Aries, E., and L. Fang, "Egress Peer Engineering using 453 BGP-LU", draft-gredler-idr-bgplu-epe-11 (work in 454 progress), October 2017. 456 [link-bandwidth-community] 457 Mohapatra, P. and R. Fernando, "BGP Link Bandwidth 458 Extended Community", January 2013, 459 . 462 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 463 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 464 . 466 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 467 Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November 468 1998, . 470 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 471 Switching (GMPLS) Signaling Functional Description", 472 RFC 3471, DOI 10.17487/RFC3471, January 2003, 473 . 475 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 476 Reflection: An Alternative to Full Mesh Internal BGP 477 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 478 . 480 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 481 Autonomous System (AS) Number Space", RFC 6793, 482 DOI 10.17487/RFC6793, December 2012, 483 . 485 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 486 "Advertisement of Multiple Paths in BGP", RFC 7911, 487 DOI 10.17487/RFC7911, July 2016, 488 . 490 Appendix A. Bandwidth Values 492 Some typical bandwidth values encoded in 32-bit IEEE floating point 493 format are enumerated below. 495 Link Type Bit-rate Bandwidth Value (Bytes/Sec) 496 (Mbps) (32-bit IEEE Floating point) 497 --------------- --------------- --------------------------------- 498 E1 2.048 0x487A0000 499 Ethernet 10.00 0x49989680 500 Fast Ethernet 100.00 0x4B3EBC20 501 OC-3/STM-1 155.52 0x4B9450C0 502 OC-12/STM-4 622.08 0x4C9450C0 503 GigE 1000.00 0x4CEE6B28 504 OC-48/STM-16 2488.32 0x4D9450C0 505 OC-192/STM-64 9953.28 0x4E9450C0 506 10GigE 10000.00 0x4E9502F9 507 OC-768/STM-256 39813.12 0x4F9450C0 508 100GigE 100000.00 0x503A43B7 510 Authors' Addresses 512 Zhenqiang Li 513 China Mobile 514 No.32 Xuanwumenxi Ave., Xicheng District 515 Beijing 100032 516 P.R. China 518 Email: li_zhenqiang@hotmail.com 520 Jie Dong 521 Huawei Technologies 522 Huawei Campus, No.156 Beiqing Rd. 523 Beijing 100095 524 P.R. China 526 Email: jie.dong@huawei.com