idnits 2.17.1 draft-zhang-ccamp-bbu-aggregation-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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 185: '...P. A Controller MUST send RRU Feature...' RFC 2119 keyword, line 199: '...P. A Controller MUST send RRU Feature...' RFC 2119 keyword, line 213: '...P. A Controller MUST send TN Feature ...' RFC 2119 keyword, line 228: '...s. A Controller MAY send lightpath re...' RFC 2119 keyword, line 246: '...atus. A Controller MAY send lightpath...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2019) is 1769 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group J. Zhang, Ed. 3 Internet-Draft S. Liu, Ed. 4 Intended status: Standards Track Z. Liu, Ed. 5 Expires: December 18, 2019 Y. Ji, Ed. 6 bupt 7 June 16, 2019 9 BBU Agregation: a usecase of the unified radio and optical control 10 architecture 11 draft-zhang-ccamp-bbu-aggregation-00 13 Abstract 15 This document specifies a usecase, called BBU aggregation, for 16 integreting radio and optical networks. It aims to compact several 17 low-utilized BBU cards into one BBU to improve the BBU utilization. 18 A flexible optical fronthaul network is connecting BBU and RRU to 19 enable BBU aggregation by recongfiguring the lightpath between BBU 20 and RRU. The procedure of the usecase is based on the unified radio 21 and optical control archtecture, and an extended OpenFlow protocol is 22 introduced to realize the procedure. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 18, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Overview of BBU aggregation . . . . . . . . . . . . . . . . . 4 63 5.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 4 65 5.3. Normal Communication Procedure . . . . . . . . . . . . . 6 66 5.3.1. Initialization Phase . . . . . . . . . . . . . . . . 6 67 5.3.2. Lightpath Reconfiguration Request Sent by a 68 Controller to a BBU_A . . . . . . . . . . . . . . . . 9 69 5.3.3. Lightpath Reconfiguration Request Sent by a 70 Controller to a TN_A . . . . . . . . . . . . . . . . 10 71 5.3.4. Lightpath Reconfiguration Reply Sent by a BBU_A to a 72 Controller . . . . . . . . . . . . . . . . . . . . . 10 73 5.3.5. Lightpath Reconfiguration Reply Sent by a TN_A to a 74 Controller . . . . . . . . . . . . . . . . . . . . . 11 75 6. the communication protocol Messages for BBU aggregation . . . 12 76 6.1. The RRU_Feature_Req message . . . . . . . . . . . . . . . 13 77 6.2. The RRU_Feature_Rep message . . . . . . . . . . . . . . . 13 78 6.3. The BBU_Feature_Req message . . . . . . . . . . . . . . . 13 79 6.4. The BBU_Feature_Rep message . . . . . . . . . . . . . . . 13 80 6.5. The TN_Feature_Req message . . . . . . . . . . . . . . . 14 81 6.6. The TN_Feature_Rep message . . . . . . . . . . . . . . . 14 82 6.7. The BBU_A_Mod message . . . . . . . . . . . . . . . . . . 14 83 6.8. The BBU_A_Rep message . . . . . . . . . . . . . . . . . . 15 84 6.9. The TN_A_Mod message . . . . . . . . . . . . . . . . . . 15 85 6.10. The TN_A_Rep message . . . . . . . . . . . . . . . . . . 15 86 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 15 87 7.1. Initialization Phase Object . . . . . . . . . . . . . . . 15 88 7.1.1. RRU feature request TLV . . . . . . . . . . . . . . . 15 89 7.1.2. BBU feature request TLV . . . . . . . . . . . . . . . 16 90 7.1.3. TN feature request TLV . . . . . . . . . . . . . . . 17 91 7.1.4. RRU feature reply TLV . . . . . . . . . . . . . . . . 17 92 7.1.5. BBU feature reply TLV . . . . . . . . . . . . . . . . 18 93 7.1.6. TN feature reply TLV . . . . . . . . . . . . . . . . 18 94 7.2. Lightpath Reconfiguration Phase Object . . . . . . . . . 19 95 7.2.1. BBU modification request TLV . . . . . . . . . . . . 19 96 7.2.2. TN modification request TLV . . . . . . . . . . . . . 20 97 7.2.3. BBU modification reply TLV . . . . . . . . . . . . . 20 98 7.2.4. TN modification reply TLV . . . . . . . . . . . . . . 21 99 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 100 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 BBU aggregation is to compact some low-utilized BBUs into one BBU to 106 improve the BBU utilization.In order to do that, it changes the 107 connections of current RRU-BBU pairs, which is to reassociate the 108 RRUs of low-utilized BBUs with one BBU, and shut down the low- 109 utilized BBUs to save the cost. This requires a flexible optical 110 fronthaul network, in which the lightpath between the BBU and RRUs 111 can be reconfigured. 113 To realize the BBU aggregation, radio and optical resources should be 114 jointly allocated, and radio and optical network devises should to be 115 simutaneusly controlled. This memo introduces a mechanism to 116 aggregate low-utilized BBUs in a SDN-enabled radio and optical 117 control architecture. The procedure of BBU aggregation contains the 118 following steps: 1) radio controller (Radio-C) sends OF messages to 119 RRU_A and BBU-A to inquire the current physical properties of radio 120 networks, such as taffic load and BBU utilization. 2) RRU_A and BBU_A 121 reply the requested information to the Radio-C. 3) after obtaining 122 the reply message, the control plane will run BBU aggregation scheme 123 to get new RRU-BBU pairs with the corresponding lightpath between 124 them. 4) transport controller (Transport-C) sends OF messages to 125 TN_As to establish the lightpaths between the new RRU-BBU pairs. 127 2. Requirements Language 129 The key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 130 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 131 this document. 133 3. Terminology 135 This memo uses the following terms: BBU_A, RRU_A, TN_A, Radio-C, 136 Transport-C. 138 4. Motivation 140 For real operational wireless networks, mobile subscribers have shown 141 a strong time-geometry pattern, causing the base station utilization 142 to fluctuate over time and area. For example, when users are moving 143 to other areas, the BBU just stays in idle with a large amount of its 144 processing power wasted.In addition, with the emerging of massive 145 small cells, dynamic RRU association is gaining more and more 146 attention to improve the energy saving and coordination efficiency. 148 To solve these problem, turning off the low-utilized BBUs and 149 migrating their RRUs to other active BBUs is an efficient method. 150 However, it is hard to realize dynamic RRU-BBU reassociation because 151 of the independent control of radio and optical networks. 153 Therefore, this memo give a usecase to realize the BBU aggregation by 154 joint allocation radio and optical resources in an unified control 155 plane. 157 5. Overview of BBU aggregation 159 An architectural protocol overview (the big picture of the protocol) 160 is provided in this section. Protocol details can be found in 161 further sections. 163 5.1. Problem 165 Because the BBU aggregation is realized by the lightpath 166 reconfiguration, a communication protocol between the BBU_A and RRU_A 167 is needed. The communication protocol is designed specifically for 168 communications between a BBU_A and a controller. A controller may 169 use the communication protocol to send a lightpath reconfiguration 170 request to a BBU_A, and the BBU_A may reply with a set of 171 reconfigured lightpaths if the lightpaths satisfying the set of 172 constraints. 174 5.2. New Messages 176 The communication protocol operates over TCP, which fulfills the 177 requirements for reliable messaging and flow control without further 178 protocol work. 180 This memo define the following new communication protocol messages 181 for BBU aggregation: 183 Controller Request Message for RRU Feature (RRU_Feature_Req): A 184 message sent by a Controller to a RRU to request RRU Feature which 185 contains RRU_ID and RRU_IP. A Controller MUST send RRU Feature 186 request message to a RRU at initialization phase to get the 187 information about traffic load,wavelength and corresponding BBUs. 188 The details of RRU_Feature_Req message is described in Section 6.1. 190 RRU Reply Message for RRU Feature (RRU_Feature_Rep): A message sent 191 by a RRU to a Controller to reply specific RRU_Feature_Req message, 192 which contains the features of the RRUs, such as traffic load and 193 corresponding BBUs. A RRU sends RRU Feature reply message if and 194 only if it received related RRU_Feature_Req message. The details of 195 RRU_Feature_Rep message is described in Section 6.2. 197 Controller Request Message for BBU Feature (BBU_Feature_Req): A 198 message sent by a Controller to a BBU_A to request BBU Feature which 199 contains BBU_ID and BBU_IP. A Controller MUST send RRU Feature 200 request message to a BBU_A at initialization phase to get the 201 information about traffic load,wavelength and BBU status. The 202 details of BBU_Feature_Req message is described in Section 6.3. 204 BBU Reply Message for BBU Feature (RRU_Feature_Rep): A message sent 205 by a BBU_A to a Controller to reply specific BBU_Feature_Req message, 206 which contains the features of the BBUs, such as traffic load and BBU 207 status. A BBU sends BBU Feature reply message if and only if it 208 received related BBU_Feature_Req message. The details of 209 BBU_Feature_Rep message is described in Section 6.4. 211 Controller Request Message for TN Feature (TN_Feature_Req): A message 212 sent by a Controller to a TN to request TN Feature which contains 213 node_ID and node_IP. A Controller MUST send TN Feature request 214 message to a TN at initialization phase to get the information about 215 port ,wavelength and switch status. The details of TN_Feature_Req 216 message is described in Section 6.5. 218 TN Reply Message for RRU Feature (TN_Feature_Rep): A message sent by 219 a TN to a Controller to reply specific TN_Feature_Req message, which 220 contains the features of the TNs, such as port ,wavelength and switch 221 status. A TN sends TN Feature reply message if and only if it 222 received related TN_Feature_Req message. The details of 223 TN_Feature_Rep message is described in Section 6.6. 225 Controller Request Message to BBU_A for Lightpath Reconfiguration 226 (BBU_A_Mod): A message sent by a Controller to a BBU_A to request 227 lightpath reconfiguration which contains BBU_ID, node_IP and BBU 228 status. A Controller MAY send lightpath reconfiguration request 229 message to a BBU_A at any time as long as it consideres this 230 operation necessary. The details of BBU_A_Mod message is described 231 in Section 6.7. 233 BBU_A Reply Message for Lightpath Reconfiguration (BBU_A_Rep): A 234 message sent by a BBU_A to a Controller to reply specific BBU_A_Mod 235 message, which contains the configuration results of BBU_As. A BBU_A 236 sends lightpath reconfiguration reply message if and only if it 237 received related BBU_A_Mod message. A BBU_A_Rep message can contain 238 either a set of reconfigurated lightpaths if the request can be 239 satisfied, or a negative reply if not. The negative reply may 240 indicate the reason why the lightpaths can not be reconfigurated. 241 The details of BBU_A_Rep message is described in Section 6.8. 243 Controller Request Message to TN_A for Lightpath Reconfiguration 244 (TN_A_Mod): A message sent by a Controller to a TN_A to request 245 lightpath reconfiguration which contains node_ID, node_IP , port, 246 wavelength and switch status. A Controller MAY send lightpath 247 reconfiguration request message to a TN_A at any time as long as it 248 consideres this operation necessary. The details of TN_A_Mod message 249 is described in Section 6.9. 251 TN_A Reply Message for Lightpath Reconfiguration (TN_A_Rep): A 252 message sent by a TN_A to a Controller to reply specific TN_A_Mod 253 message, which contains the configuration results of TN_As. A TN_A 254 sends lightpath reconfiguration reply message if and only if it 255 received related TN_A_Mod message. A TN_A_Rep message can contain 256 either a set of reconfigurated lightpaths if the request can be 257 satisfied, or a negative reply if not. The negative reply may 258 indicate the reason why the lightpaths can not be reconfigurated. 259 The details of TN_A_Rep message is described in Section 6.10. 261 5.3. Normal Communication Procedure 263 5.3.1. Initialization Phase 265 The initialization phase consists of three subphases and each 266 subphase two successive steps. 268 In the first subphase, the two steps are (described in a schematic 269 form in Figure 1: 271 1) Establishment of a TCP connection (3-way handshake) between the 272 RRU_A and the Controller. 274 2) Establishment of a session over the TCP connection. 276 +-+-+-+ +-+-+-+-+-+ 277 |RRU_A| |Controller| 278 +-+-+-+ +-+-+-+-+-+ 279 | | 280 | | 281 |-------------------->| 282 (Initialize | | 283 Scop of | RRU_Feature_Req | 284 Attributes) |<--------------------| 285 | | 286 | RRU_Feature_Rep | 287 |-------------------->| 288 | | 290 Figure 1: Initialization Phase between the RRU_A and the Controller 292 Once the TCP connection is established, the Controller and the RRU_A 293 initiate session establishment during which various session 294 parameters are negotiated. The Controller sends a RRU Feature 295 request to the RRU (RRU_Feature_Req message). 297 Details about the RRU_Feature_Req message can be found in 298 Section 6.1. 300 After received the RRU_Feature_Req message, the RRU send a 301 RRU_Feature_Rep message including the features of the RRUs, such as 302 traffic load, corresponding BBUs and potentially other detailed 303 capabilities and policy rules that specify the conditions under which 304 path computation requests may be sent to the Controller. 306 Details about the RRU_Feature_Rep message can be found in 307 Section 6.2. 309 Similarly, in the second subphase, the two steps are (described in a 310 schematic form in Figure 2: 312 1) Establishment of a TCP connection (3-way handshake) between the 313 BBU_A and the Controller. 315 2) Establishment of a session over the TCP connection. 317 +-+-+-+ +-+-+-+-+-+ 318 |BBU_A| |Controller| 319 +-+-+-+ +-+-+-+-+-+ 320 | | 321 | | 322 |-------------------->| 323 (Initialize | | 324 Scop of | BBU_Feature_Req | 325 Attributes) |<--------------------| 326 | | 327 | BBU_Feature_Rep | 328 |-------------------->| 329 | | 331 Figure 2: Initialization Phase between the BBU_A and the Controller 333 Once the TCP connection is established, the Controller and the BBU_A 334 initiate session establishment during which various session 335 parameters are negotiated. The Controller sends a BBU_A Feature 336 request to the BBU_A (BBU_Feature_Req message). 338 Details about the BBU_Feature_Req message can be found in 339 Section 6.3. 341 After received the BBU_Feature_Req message, the BBU send a 342 BBU_Feature_Rep message including the features of the BBU_as, such as 343 traffic load, BBU_A status and potentially other detailed 344 capabilities and policy rules that specify the conditions under which 345 path computation requests may be sent to the Controller. 347 Details about the BBU_Feature_Rep message can be found in 348 Section 6.4. 350 Similarly, in the third subphase, the two steps are (described in a 351 schematic form in Figure 3: 353 1) Establishment of a TCP connection (3-way handshake) between the 354 TN_A and the Controller. 356 2) Establishment of a session over the TCP connection. 358 +-+-+-+ +-+-+-+-+-+ 359 | TN_A| |Controller| 360 +-+-+-+ +-+-+-+-+-+ 361 | | 362 | | 363 |-------------------->| 364 (Initialize | | 365 Scop of | TN_Feature_Req | 366 Attributes) |<--------------------| 367 | | 368 | TN_Feature_Rep | 369 |-------------------->| 370 | | 372 Figure 3: Initialization Phasebetween the TN_A and the Controller 374 Once the TCP connection is established, the Controller and the TN_A 375 initiate session establishment during which various session 376 parameters are negotiated. The Controller sends a RRU Feature 377 request to the TN_A (TN_Feature_Req message). 379 Details about the TN_Feature_Req message can be found in Section 6.5. 381 After received the TN_Feature_Req message, the TN send a 382 TN_Feature_Rep message including the features of the TNs, such as 383 traffic load, corresponding TNs and potentially other detailed 384 capabilities and policy rules that specify the conditions under which 385 path computation requests may be sent to the Controller. 387 Details about the TN_Feature_Rep message can be found in Section 6.6. 389 5.3.2. Lightpath Reconfiguration Request Sent by a Controller to a 390 BBU_A 392 Once a Controller has sucessfully established a session with one or 393 more BBU_As, if a lightpath reconfiguration event is triggered that 394 requires the reconfiguration of a set of lightpaths, the controller 395 first selects one or more BBU_As. 397 Once the Controller has selected a BBU_A, it sends a BBU_A_Mod 398 message to the BBU_A. The process is shown in Figure 4. 400 Details about the BBU_A_Mod message can be found in Section 6.7. 402 +-+-+-+ +-+-+-+-+-+ 403 |BBU_A| |Controller| 404 +-+-+-+ +-+-+-+-+-+ 405 | | 1)Lightpath Reconfiguration Event 406 | | 2)Lightpath Reconfiguration Request 407 | | Sent to the BBU_A 408 |<------BBU_A_Mod------| 409 | | 410 | | 412 Figure 4: Lightpath Reconfiguration Request to BBU_A 414 5.3.3. Lightpath Reconfiguration Request Sent by a Controller to a TN_A 416 Once a Controller has sucessfully established a session with one or 417 more TN_As, if a lightpath reconfiguration event is triggered that 418 requires the reconfiguration of a set of lightpaths, the controller 419 first selects one or more TN_As. 421 Once the Controller has selected a BBU_A, it sends a TN_Mod message 422 to the TN_A. The process is shown in Figure 5. 424 Details about the TN_Mod message can be found in Section 6.9. 426 +-+-+-+ +-+-+-+-+-+ 427 |TN_A | |Controller| 428 +-+-+-+ +-+-+-+-+-+ 429 | | 1)Lightpath Reconfiguration Event 430 | | 2)Lightpath Reconfiguration Request 431 | | Sent to the TN_A 432 |<------ TN_Mod -------| 433 | | 434 | | 436 Figure 5: Lightpath Reconfiguration Request to TN_A 438 5.3.4. Lightpath Reconfiguration Reply Sent by a BBU_A to a Controller 440 After receiving a lightpath reconfiguration request from a 441 Controller, the BBU_A triggers a lightpath reconfiguration, If the 442 BBU_A manages to reconfigure a lightpath satisfies the set of 443 required constraints, the BBU_A returns the result to the requesting 444 Controller. The process is shown in Figure 6. 446 +-+-+-+ +-+-+-+-+-+ 447 |BBU_A| |Controller| 448 +-+-+-+ +-+-+-+-+-+ 449 | | 450 | | 451 | | 452 |<------BBU_A_Mod------| 453 1) Lightpath Reconfiguration | | 454 Request Received | | 455 2) Reconfiguration Succefully | | 456 3) Reconfiguration Result | | 457 Sent to the Controller | | 458 |------BBU_A_Rep------>| 460 Figure 6: Lightpath Reconfiguration Reply (Success) from BBU_A 462 However, if no lightpath could be found that satisfies the set of 463 constraints. In this case, a BBU_A may provide the set of 464 constraints that led to the lightpath reconfiguration failure. Upon 465 receiving a negative reply, a Controller may decide to resend a 466 modified request or take any other appropriate action. The process 467 is shown in Figure 7. 469 +-+-+-+ +-+-+-+-+-+ 470 |BBU_A| |Controller| 471 +-+-+-+ +-+-+-+-+-+ 472 | | 473 | | 474 | | 475 |<-----BBU_A_Mod-------| 476 1) Lightpath Reconfiguration | | 477 Request Received | | 478 2) econfiguration Unsuccefully| | 479 3) Cause of Failure | | 480 Sent to the Controller | | 481 |------BBU_A_Rep------>| 483 Figure 7: Lightpath Reconfiguration Reply (Failure) from BBU_A 485 Details about the BBU_A_Rep message can be found in Section 6.8. 487 5.3.5. Lightpath Reconfiguration Reply Sent by a TN_A to a Controller 489 After receiving a lightpath reconfiguration request from a 490 Controller, the TN_A triggers a lightpath reconfiguration, If the 491 TN_A manages to reconfigure a lightpath satisfies the set of required 492 constraints, the TN_A returns the result to the requesting 493 Controller. The process is shown in Figure 8. 495 +-+-+-+ +-+-+-+-+-+ 496 |TN_A | |Controller| 497 +-+-+-+ +-+-+-+-+-+ 498 | | 499 | | 500 | | 501 |<---- TN_A_Mod -------| 502 1) Lightpath Reconfiguration | | 503 Request Received | | 504 2) Reconfiguration Succefully | | 505 3) Reconfiguration Result | | 506 Sent to the Controller | | 507 |----- TN_A_Rep ------>| 509 Figure 8: Lightpath Reconfiguration Reply (Success) from TN_A 511 However, if no lightpath could be found that satisfies the set of 512 constraints. In this case, a TN_A may provide the set of constraints 513 that led to the lightpath reconfiguration failure. Upon receiving a 514 negative reply, a Controller may decide to resend a modified request 515 or take any other appropriate action.' The process is shown in 516 Figure 9 518 +-+-+-+ +-+-+-+-+-+ 519 |TN_A | |Controller| 520 +-+-+-+ +-+-+-+-+-+ 521 | | 522 | | 523 | | 524 |<----- TN_A_Mod ------| 525 1) Lightpath Reconfiguration | | 526 Request Received | | 527 2) econfiguration Unsuccefully| | 528 3) Cause of Failure | | 529 Sent to the Controller | | 530 |------ TN_A_Rep ----->| 532 Figure 9: Lightpath Reconfiguration Reply (Failure) from TN_A 534 Details about the TN_A_Rep message can be found in Section 6.10. 536 6. the communication protocol Messages for BBU aggregation 538 The communication protocol Messages for BBU aggregation consists of a 539 common header followed by a variable-length body made of a set of 540 objects. For each message type, rules are defined that specify the 541 set of objects that the message can carry. 543 6.1. The RRU_Feature_Req message 545 ::= 546 547 Where: 549 ::= 550 552 6.2. The RRU_Feature_Rep message 554 ::= 555 556 Where: 558 ::= 559 561 ::= 562 564 ::= 565 566 568 6.3. The BBU_Feature_Req message 570 ::= 571 572 Where: 574 ::= 575 577 6.4. The BBU_Feature_Rep message 578 ::= 579 580 Where: 582 ::= 583 585 ::= 586 588 ::= 589 590 592 6.5. The TN_Feature_Req message 594 ::= 595 596 Where: 598 ::= 599 601 6.6. The TN_Feature_Rep message 603 ::= 604 605 Where: 607 ::= 608 610 ::= 611 613 ::= 614 615 617 6.7. The BBU_A_Mod message 619 ::= 620 621 Where: 622 ::= 623 624 626 6.8. The BBU_A_Rep message 628 ::= 629 630 Where: 631 ::= 632 633 635 6.9. The TN_A_Mod message 637 ::= 638 639 Where: 640 ::= 641 642 644 ::= 645 646 648 6.10. The TN_A_Rep message 650 ::= 651 652 Where: 653 ::= 654 655 657 7. Object Formats 659 A object carried within a communication protocol messages for BBU 660 aggregation, which consists of one or more 32-bit words with a common 661 header. 663 7.1. Initialization Phase Object 665 7.1.1. RRU feature request TLV 666 0 1 2 3 667 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | version | type=40 | Message Length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | xid | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | RRU_ID | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | RRU_IP | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 Figure 10: RRU feature request TLV format 680 The common header consists of version, type and message length. 682 Version (8 bits): The version number. Current version is version 1. 684 Type (8 bits): A number indicates the message type. The 685 "RRU_Feature_Req" message is the type 40. 687 Message Length (16 bits): Total length of the message including the 688 common header, expressed in bytes. 690 The RRU_Feature_Req object body consists of the hardware id (xid), 691 RRU id(RRU_ID) and RRU ip (RRU_IP). 693 7.1.2. BBU feature request TLV 695 0 1 2 3 696 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | version | type=48 | Message Length | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | xid | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | BBU_ID | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | BBU_IP | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Figure 11: BBU feature request TLV format 709 The common header is similar with the RRU feature request object. 710 The "BBU_Feature_Req" message is the type 48. 712 The BBU_Feature_Req object body consists of the hardware id (xid), 713 BBU id(BBU_ID) and BBU ip (BBU_IP). 715 7.1.3. TN feature request TLV 717 0 1 2 3 718 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | version | type=41 | Message Length | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | xid | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | node_ID | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | node_IP | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Figure 12: TN feature request TLV format 731 The common header is similar with the RRU feature request object. 732 The "TN_Feature_Req" message is the type 41. 734 The TN_Feature_Req object body consists of the hardware id (xid), 735 node id(node_ID) and node ip (node_IP). 737 7.1.4. RRU feature reply TLV 739 0 1 2 3 740 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | version | type=42 | Message Length | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | xid | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | RRU_ID | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | RRU_IP | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | target_BBU_ID | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | traffic load | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | wavelength | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 Figure 13: RRU feature reply TLV format 759 The common header is similar with the RRU feature request object. 760 The "RRU_Feature_Rep" message is the type 42. 762 The RRU_Feature_Rep object body consists of the hardware id (xid), 763 RRU id(RRU_ID), RRU ip (RRU_IP),corresponding BBUs, traffic load and 764 wavelength. 766 7.1.5. BBU feature reply TLV 768 0 1 2 3 769 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | version | type=49 | Message Length | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | xid | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | BBU_ID | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | BBU_IP | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | BBU_Status | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | traffic load | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | wavelength | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Figure 14: BBU feature reply TLV format 788 The common header is similar with the BBU feature request object. 789 The "BBU_Feature_Rep" message is the type 49. 791 The BBU_Feature_Rep object body consists of the hardware id (xid), 792 BBU id(BBU_ID), BBU ip (BBU_IP),BBU Status, traffic load and 793 wavelength. 795 7.1.6. TN feature reply TLV 796 0 1 2 3 797 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | version | type=43 | Message Length | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | xid | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | node_ID | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | node_IP | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | port | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | switch_status | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | wavelength | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 Figure 15: TN feature reply TLV format 816 The common header is similar with the RRU feature request object. 817 The "TN_Feature_Rep" message is the type 43. 819 The TN_Feature_Rep object body consists of the hardware id (xid), 820 node id(node_ID), node ip (node_IP),port, switch_status and 821 wavelength. 823 7.2. Lightpath Reconfiguration Phase Object 825 7.2.1. BBU modification request TLV 827 0 1 2 3 828 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | version | type=44 | Message Length | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | xid | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | BBU_ID | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | node_IP | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | BBU_status | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 Figure 16: BBU modification request TLV format 843 The common header is similar with the RRU feature request object. 844 The "BBU_A_Mod" message is the type 44. 846 The BBU_A_Mod object body consists of the hardware id (xid), BBU 847 id(BBU_ID), node ip (node_IP) and BBU status(BBU_status). 849 7.2.2. TN modification request TLV 851 0 1 2 3 852 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | version | type=45 | Message Length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | xid | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | node_ID | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | node_IP | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | port | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | switch_status | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | wavelength | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 Figure 17: TN modification request TLV format 871 The common header is similar with the RRU feature request object. 872 The "TN_A_Mod" message is the type 45. 874 The TN_A_Mod object body consists of the hardware id (xid), node 875 id(node_ID), node ip (node_IP), port, switch_status and wavelength. 877 7.2.3. BBU modification reply TLV 878 0 1 2 3 879 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | version | type=46 | Message Length | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | xid | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | BBU_ID | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | node_IP | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | BBU_config_reply | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 Figure 18: BBU modification reply TLV format 894 The common header is similar with the RRU feature request object. 895 The "BBU_A_Rep" message is the type 46. 897 The BBU_A_Mod object body consists of the hardware id (xid), BBU 898 id(BBU_ID), node ip (node_IP) and BBU configuration 899 reply(BBU_config_reply). 901 The BBU_config_reply is used to report the result of BBU 902 configuration. Two values are currently defined: "1" is a successful 903 state while "0" is a failure state. 905 7.2.4. TN modification reply TLV 907 0 1 2 3 908 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | version | type=47 | Message Length | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | xid | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | node_ID | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | node_IP | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | TN_config_reply | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 Figure 19: TN modification reply TLV format 923 The common header is similar with the RRU feature request object. 924 The "TN_A_Rep" message is the type 47. 926 The TN_A_Mod object body consists of the hardware id (xid), node 927 id(node_ID), node ip (node_IP) and TN configuration 928 reply(TN_config_reply). 930 The TN_config_reply is used to report the result of TN configuration. 931 Two values are currently defined: "1" is a successful state while "0" 932 is a failure state. 934 8. Acknowledgments 936 9. Contributors 938 Authors' Addresses 940 Jiawei Zhang (editor) 941 Beijing University of Posts and Telecommunications 942 Xitucheng Road 943 Beijing, Haidian Dist 100876 944 China 946 Phone: +86-010-61198422 947 Email: zjw@bupt.edu.cn 949 Sainan Liu (editor) 950 Beijing University of Posts and Telecommunications 951 Xitucheng Road 952 Beijing, Haidian Dist 100876 953 China 955 Phone: +86-010-61198422 956 Email: lsn0429@bupt.edu.cn 958 Zhen Liu (editor) 959 Beijing University of Posts and Telecommunications 960 Xitucheng Road 961 Beijing, Haidian Dist 100876 962 China 964 Phone: +86-010-61198422 965 Email: liuzhen207@bupt.edu.cn 966 Yuefeng Ji (editor) 967 Beijing University of Posts and Telecommunications 968 Xitucheng Road 969 Beijing, Haidian Dist 100876 970 China 972 Phone: +86-010-61198422 973 Email: jyf@bupt.edu.cn