idnits 2.17.1 draft-zhang-ccamp-ecomp-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 183: '...P. A Controller MUST send RRU Feature...' RFC 2119 keyword, line 197: '...P. A Controller MUST send TN Feature ...' RFC 2119 keyword, line 212: '...s. A Controller MAY send lightpath re...' RFC 2119 keyword, line 230: '...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 1766 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 Z. Liu, Ed. 3 Internet-Draft J. Zhang, Ed. 4 Intended status: Standards Track S. Liu, Ed. 5 Expires: December 18, 2019 Y. Ji, Ed. 6 bupt 7 June 16, 2019 9 eCoMP:a usecase of the unified radio and optical control architecture 10 draft-zhang-ccamp-ecomp-00 12 Abstract 14 This document specifies a usecase, called enhanced coordinated multi- 15 point (eCoMP), for integreting radio and optical networks. It focus 16 on the fronthaul flexibility that allows "any-RRH_A to any-BBU_A" 17 connection to improve the eCoMP service performance. The procedure 18 of the usecase is based on the unified radio and optical control 19 archtecture, and an extended OpenFlow protocol is introduced to 20 realize the procedure. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 18, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Overview of eCoMP . . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 4 63 5.3. Normal Communication Procedure . . . . . . . . . . . . . 6 64 5.3.1. Initialization Phase . . . . . . . . . . . . . . . . 6 65 5.3.2. Lightpath Reconfiguration Request Sent by a 66 Controller to a BBU_A . . . . . . . . . . . . . . . . 8 67 5.3.3. Lightpath Reconfiguration Request Sent by a 68 Controller to a TN_A . . . . . . . . . . . . . . . . 8 69 5.3.4. Lightpath Reconfiguration Reply Sent by a BBU_A to a 70 Controller . . . . . . . . . . . . . . . . . . . . . 9 71 5.3.5. Lightpath Reconfiguration Reply Sent by a TN_A to a 72 Controller . . . . . . . . . . . . . . . . . . . . . 10 73 6. the communication protocol Messages for eCoMP . . . . . . . . 11 74 6.1. The RRU_Feature_Req message . . . . . . . . . . . . . . . 11 75 6.2. The RRU_Feature_Rep message . . . . . . . . . . . . . . . 11 76 6.3. The TN_Feature_Req message . . . . . . . . . . . . . . . 12 77 6.4. The TN_Feature_Rep message . . . . . . . . . . . . . . . 12 78 6.5. The BBU_Feature_Req message . . . . . . . . . . . . . . . 12 79 6.6. The BBU_Feature_Rep message . . . . . . . . . . . . . . . 13 80 6.7. The RRU_A_Mod message . . . . . . . . . . . . . . . . . . 13 81 6.8. The RRU_A_Rep message . . . . . . . . . . . . . . . . . . 13 82 6.9. The TN_A_Mod message . . . . . . . . . . . . . . . . . . 13 83 6.10. The TN_A_Rep message . . . . . . . . . . . . . . . . . . 14 84 6.11. The BBU_A_Mod message . . . . . . . . . . . . . . . . . . 14 85 6.12. The BBU_A_Rep message . . . . . . . . . . . . . . . . . . 14 86 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.1. Initialization Phase Object . . . . . . . . . . . . . . . 15 88 7.1.1. RRU feature request TLV . . . . . . . . . . . . . . . 15 89 7.1.2. TN feature request TLV . . . . . . . . . . . . . . . 15 90 7.1.3. BBU feature request TLV . . . . . . . . . . . . . . . 16 91 7.1.4. RRU feature reply TLV . . . . . . . . . . . . . . . . 16 92 7.1.5. TN feature reply TLV . . . . . . . . . . . . . . . . 17 93 7.2. BBU feature reply TLV . . . . . . . . . . . . . . . . . . 18 94 7.3. Lightpath Reconfiguration Phase Object . . . . . . . . . 19 95 7.3.1. RRU modification request TLV . . . . . . . . . . . . 19 96 7.3.2. TN modification request TLV . . . . . . . . . . . . . 20 97 7.3.3. BBU modification request TLV . . . . . . . . . . . . 21 98 7.3.4. RRU modification reply TLV . . . . . . . . . . . . . 21 99 7.3.5. TN modification reply TLV . . . . . . . . . . . . . . 22 100 7.3.6. BBU modification reply TLV . . . . . . . . . . . . . 22 101 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 102 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 105 1. Introduction 107 The eCoMP exploits the fronthaul flexibility by dynamically 108 reconfiguring the lightpath, which is to reassociate coordinated 109 RRH_As (connected to different BBU_As) with a single BBU_A. With the 110 benefits of flexibility, an RRH_A can choose a proper BBU_A for a 111 specific purpose. In order to achieve agile RRU_A and BBU_A mapping, 112 a flexible optical fronthaul network is required, in which the 113 lightpath between the BBU_A and RRU_As can be reconfigured. 115 To realize the eCoMP service, radio and optical resources should be 116 jointly allocated, and radio and optical network devises should to be 117 simutaneusly controlled. This memo introduces a mechanism to achieve 118 agile RRU_A and BBU_A mapping in a SDN-enabled radio and optical 119 control architecture. The procedure of eCoMP contains the following 120 steps: 1) Radio controller(Radio-C) obtains the current radio 121 resource information via an extended OFP message, and calculate new 122 RRH_A and BBU_A mappings for maximizing the intra-BBU eCoMP ratio. 2) 123 Transport controller (Transport-C) obtains the current transport 124 resource information via an extended OFP message, and calculate the 125 corresponding lightpaths for the new RRH_A and BBU_A mappings. 3) 126 eCoMP reconfigures the BBU_A according to the result of new RRH_A and 127 BBU_A mappings. 4) eCoMP reconfigures lightpath between the new RRU_A 128 and BBU_A pairs. 130 2. Requirements Language 132 The key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 133 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". 135 3. Terminology 137 This memo uses the following terms :RRU_A, BBU_A, TN_A, Radio-C, 138 Transport-C. 140 4. Motivation 142 The RAN architecture towards mobile 5G and beyond is undergoing a 143 fundamental evolution, which brings optics into the radio world. 144 Fronthaul is a new segment that leverages on the advantages of 145 optical communication for RAN transport. However, the current 146 fronthaul architecture shows a fixed connection between an RRH_A and 147 a BBU_A, which leads to inefficient resource utilization. 149 To solve these problem, the "any-to-any" correspondence between 150 RRU_As and BBU_As is becomming more and more important. The agile 151 RRU_A and BBU_A mapping can be reached through lightpath 152 reconfiguration. However, it is hard to realize dynamic RRU-BBU 153 reassociation because of the independent control of radio and optical 154 networks. 156 Therefore, this memo give a usecase to realize the eCoMP by joint 157 allocation radio and optical resources in an unified control plane. 159 5. Overview of eCoMP 161 5.1. Problem 163 Because the eCoMP service is realized by the lightpath 164 reconfiguration, a communication protocol between BBU_A and RRU_A is 165 needed. The communication protocol is designed specifically for 166 communications between a BBU_A and a controller.A controller may use 167 the communication protocol to send a lightpath reconfiguration 168 request to a BBU_A, and the BBU_A may reply with a set of 169 reconfigured lightpaths if the lightpaths satisfying the set of 170 constraints. 172 5.2. New Messages 174 The communication protocol operates over TCP, which fulfills the 175 requirements for reliable messaging and flow control without further 176 protocol work. 178 This memo define the following new communication protocol messages 179 for eCoMP: 181 Controller Request Message for RRU Feature (RRU_Feature_Req): A 182 message sent by a Controller to a RRU to request RRU Feature which 183 contains RRU_ID and RRU_IP. A Controller MUST send RRU Feature 184 request message to a RRU at initialization phase to get the 185 information about traffic load,wavelength and corresponding BBUs. 186 The details of RRU_Feature_Req message is described in Section 6.1. 188 RRU Reply Message for RRU Feature (RRU_Feature_Rep): A message sent 189 by a RRU to a Controller to reply specific RRU_Feature_Req message, 190 which contains the features of the RRUs, such as traffic load and 191 corresponding BBUs. A RRU sends RRU Feature reply message if and 192 only if it received related RRU_Feature_Req message. The details of 193 RRU_Feature_Rep message is described in Section 6.2. 195 Controller Request Message for TN Feature (TN_Feature_Req): A message 196 sent by a Controller to a TN to request TN Feature which contains 197 node_ID and node_IP. A Controller MUST send TN Feature request 198 message to a TN at initialization phase to get the information about 199 port ,wavelength and switch status. The details of TN_Feature_Req 200 message is described in Section 6.3. 202 TN Reply Message for RRU Feature (TN_Feature_Rep): A message sent by 203 a TN to a Controller to reply specific TN_Feature_Req message, which 204 contains the features of the TNs, such as port ,wavelength and switch 205 status. A TN sends TN Feature reply message if and only if it 206 received related TN_Feature_Req message. The details of 207 TN_Feature_Rep message is described in Section 6.4. 209 Controller Request Message to BBU_A for Lightpath Reconfiguration 210 (BBU_A_Mod): A message sent by a Controller to a BBU_A to request 211 lightpath reconfiguration which contains BBU_ID, node_IP and BBU 212 status. A Controller MAY send lightpath reconfiguration request 213 message to a BBU_A at any time as long as it consideres this 214 operation necessary. The details of BBU_A_Mod message is described 215 in Section 6.11. 217 BBU_A Reply Message for Lightpath Reconfiguration (BBU_A_Rep): A 218 message sent by a BBU_A to a Controller to reply specific BBU_A_Mod 219 message, which contains the configuration results of BBU_As. A BBU_A 220 sends lightpath reconfiguration reply message if and only if it 221 received related BBU_A_Mod message. A BBU_A_Rep message can contain 222 either a set of reconfigurated lightpaths if the request can be 223 satisfied, or a negative reply if not. The negative reply may 224 indicate the reason why the lightpaths can not be reconfigurated. 225 The details of BBU_A_Rep message is described in Section 6.12. 227 Controller Request Message to TN_A for Lightpath Reconfiguration 228 (TN_A_Mod): A message sent by a Controller to a TN_A to request 229 lightpath reconfiguration which contains BBU_ID, node_IP , port, 230 wavelength and switch status. A Controller MAY send lightpath 231 reconfiguration request message to a TN_A at any time as long as it 232 consideres this operation necessary. The details of TN_A_Mod message 233 is described in Section 6.9. 235 TN_A Reply Message for Lightpath Reconfiguration (TN_A_Rep): A 236 message sent by a TN_A to a Controller to reply specific TN_A_Mod 237 message, which contains the configuration results of TN_As. A TN_A 238 sends lightpath reconfiguration reply message if and only if it 239 received related TN_A_Mod message. A TN_A_Rep message can contain 240 either a set of reconfigurated lightpaths if the request can be 241 satisfied, or a negative reply if not. The negative reply may 242 indicate the reason why the lightpaths can not be reconfigurated. 243 The details of TN_A_Rep message is described in Section 6.10. 245 5.3. Normal Communication Procedure 247 5.3.1. Initialization Phase 249 The initialization phase consists of two subphases and each subphase 250 two successive steps. 252 In the first subphase, the two steps are (described in a schematic 253 form in Figure 1: 255 1) Establishment of a TCP connection (3-way handshake) between the 256 RRU_A and the Controller. 258 2) Establishment of a session over the TCP connection. 260 +-+-+-+ +-+-+-+-+-+ 261 |RRU_A| |Controller| 262 +-+-+-+ +-+-+-+-+-+ 263 | | 264 | | 265 |-------------------->| 266 (Initialize | | 267 Scop of | RRU_Feature_Req | 268 Attributes) |<--------------------| 269 | | 270 | RRU_Feature_Rep | 271 |-------------------->| 272 | | 274 Figure 1: Initialization Phase between the RRU_A and the Controller 276 Once the TCP connection is established, the Controller and the RRU_A 277 initiate session establishment during which various session 278 parameters are negotiated. The Controller sends a RRU_A Feature 279 request to the RRU(RRU_Feature_Req message). 281 Details about the RRU_Feature_Req message can be found in 282 Section 6.1. 284 After received the RRU_Feature_Req message, the RRU send a 285 RRU_Feature_Rep message including the features of the RRUs, such as 286 traffic load, corresponding BBU_As and potentially other detailed 287 capabilities and policy rules that specify the conditions under which 288 path computation requests may be sent to the Controller. 290 Details about the RRU_Feature_Rep message can be found in 291 Section 6.2. 293 Similarly, in the second subphase, the two steps are (described in a 294 schematic form in Figure 2: 296 1) Establishment of a TCP connection (3-way handshake) between the 297 TN_A and the Controller. 299 2) Establishment of a session over the TCP connection. 301 +-+-+-+ +-+-+-+-+-+ 302 | TN_A| |Controller| 303 +-+-+-+ +-+-+-+-+-+ 304 | | 305 | | 306 |-------------------->| 307 (Initialize | | 308 Scop of | TN_Feature_Req | 309 Attributes) |<--------------------| 310 | | 311 | TN_Feature_Rep | 312 |-------------------->| 313 | | 315 Figure 2: Initialization Phasebetween the TN_A and the Controller 317 Once the TCP connection is established, the Controller and the TN_A 318 initiate session establishment during which various session 319 parameters are negotiated. The Controller sends a RRU Feature 320 request to the TN_A (TN_Feature_Req message). 322 Details about the TN_Feature_Req message can be found in Section 6.3. 324 After received the TN_Feature_Req message, the TN_A send a 325 TN_Feature_Rep message including the features of the TN_As, such as 326 traffic load, corresponding TN_A and potentially other detailed 327 capabilities and policy rules that specify the conditions under which 328 path computation requests may be sent to the Controller. 330 Details about the TN_Feature_Rep message can be found in Section 6.4. 332 5.3.2. Lightpath Reconfiguration Request Sent by a Controller to a 333 BBU_A 335 Once a Controller has sucessfully established a session with one or 336 more BBU_As, if a lightpath reconfiguration event is triggered that 337 requires the reconfiguration of a set of lightpaths, the controller 338 first selects one or more BBU_As. 340 Once the Controller has selected a BBU_A, it sends a BBU_A_Mod 341 message to the BBU_A. Each request is uniquely identified by a tp-id 342 number and Controller-BBU_A address pair. The process is shown in 343 Figure 3. 345 Details about the BBU_A_Mod message can be found in Section 6.11. 347 +-+-+-+ +-+-+-+-+-+ 348 |BBU_A| |Controller| 349 +-+-+-+ +-+-+-+-+-+ 350 | | 1)Lightpath Reconfiguration Event 351 | | 2)Lightpath Reconfiguration Request 352 | | Sent to the BBU_A 353 |<------BBU_A_Mod------| 354 | | 355 | | 357 Figure 3: Lightpath Reconfiguration Request to BBU_A 359 5.3.3. Lightpath Reconfiguration Request Sent by a Controller to a TN_A 361 Once a Controller has sucessfully established a session with one or 362 more TN_As, if a lightpath reconfiguration event is triggered that 363 requires the reconfiguration of a set of lightpaths, the controller 364 first selects one or more TNs. 366 Once the Controller has selected a BBU_A, it sends a TN_Mod message 367 to the TN_A. Each request is uniquely identified by a tp-id number 368 and Controller-TN address pair. The process is shown in Figure 4. 370 Details about the TN_Mod message can be found in Section 6.9. 372 +-+-+-+ +-+-+-+-+-+ 373 |TN_A | |Controller| 374 +-+-+-+ +-+-+-+-+-+ 375 | | 1)Lightpath Reconfiguration Event 376 | | 2)Lightpath Reconfiguration Request 377 | | Sent to the TN_A 378 |<------ TN_Mod -------| 379 | | 380 | | 382 Figure 4: Lightpath Reconfiguration Request to TN_A 384 5.3.4. Lightpath Reconfiguration Reply Sent by a BBU_A to a Controller 386 After receiving a lightpath reconfiguration request from a 387 Controller, the BBU_A triggers a lightpath reconfiguration, If the 388 BBU_A manages to reconfigure a lightpath satisfies the set of 389 required constraints, the BBU_A returns the result to the requesting 390 Controller. The process is shown in Figure 5. 392 +-+-+-+ +-+-+-+-+-+ 393 |BBU_A| |Controller| 394 +-+-+-+ +-+-+-+-+-+ 395 | | 396 | | 397 | | 398 |<------BBU_A_Mod------| 399 1) Lightpath Reconfiguration | | 400 Request Received | | 401 2) Reconfiguration Succefully | | 402 3) Reconfiguration Result | | 403 Sent to the Controller | | 404 |------BBU_A_Rep------>| 406 Figure 5: Lightpath Reconfiguration Reply (Success) from BBU_A 408 However, if no lightpath could be found that satisfies the set of 409 constraints. In this case, a BBU_A may provide the set of 410 constraints that led to the lightpath reconfiguration failure. Upon 411 receiving a negative reply, a Controller may decide to resend a 412 modified request or take any other appropriate action. The process 413 is shown in Figure 6. 415 +-+-+-+ +-+-+-+-+-+ 416 |BBU_A| |Controller| 417 +-+-+-+ +-+-+-+-+-+ 418 | | 419 | | 420 | | 421 |<-----BBU_A_Mod-------| 422 1) Lightpath Reconfiguration | | 423 Request Received | | 424 2) econfiguration Unsuccefully| | 425 3) Cause of Failure | | 426 Sent to the Controller | | 427 |------BBU_A_Rep------>| 429 Figure 6: Lightpath Reconfiguration Reply (Failure) from BBU_A 431 Details about the BBU_A_Rep message can be found in Section 6.12. 433 5.3.5. Lightpath Reconfiguration Reply Sent by a TN_A to a Controller 435 After receiving a lightpath reconfiguration request from a 436 Controller, the TN_A triggers a lightpath reconfiguration, If the 437 TN_A manages to reconfigure a lightpath satisfies the set of required 438 constraints, the TN_A returns the result to the requesting 439 Controller. The process is shown in Figure 7. 441 +-+-+-+ +-+-+-+-+-+ 442 |TN_A | |Controller| 443 +-+-+-+ +-+-+-+-+-+ 444 | | 445 | | 446 | | 447 |<---- TN_A_Mod -------| 448 1) Lightpath Reconfiguration | | 449 Request Received | | 450 2) Reconfiguration Succefully | | 451 3) Reconfiguration Result | | 452 Sent to the Controller | | 453 |----- TN_A_Rep ------>| 455 Figure 7: Lightpath Reconfiguration Reply (Success) from TN_A 457 However, if no lightpath could be found that satisfies the set of 458 constraints. In this case, a TN_A may provide the set of constraints 459 that led to the lightpath reconfiguration failure. Upon receiving a 460 negative reply, a Controller may decide to resend a modified request 461 or take any other appropriate action.' The process is shown in 462 Figure 8 463 +-+-+-+ +-+-+-+-+-+ 464 |TN_A | |Controller| 465 +-+-+-+ +-+-+-+-+-+ 466 | | 467 | | 468 | | 469 |<----- TN_A_Mod ------| 470 1) Lightpath Reconfiguration | | 471 Request Received | | 472 2) econfiguration Unsuccefully| | 473 3) Cause of Failure | | 474 Sent to the Controller | | 475 |------ TN_A_Rep ----->| 477 Figure 8: Lightpath Reconfiguration Reply (Failure) from TN_A 479 Details about the TN_A_Rep message can be found in Section 6.10. 481 6. the communication protocol Messages for eCoMP 483 The communication protocol Messages for eCoMP consists of a common 484 header followed by a variable-length body made of a set of objects. 485 For each message type, rules are defined that specify the set of 486 objects that the message can carry. 488 6.1. The RRU_Feature_Req message 490 ::= 491 492 Where: 494 ::= 495 497 6.2. The RRU_Feature_Rep message 498 ::= 499 500 Where: 502 ::= 503 505 ::= 506 508 ::= 509 510 511 512 514 6.3. The TN_Feature_Req message 516 ::= 517 518 Where: 520 ::= 521 523 6.4. The TN_Feature_Rep message 525 ::= 526 527 Where: 529 ::= 530 532 ::= 533 535 ::= 536 537 539 6.5. The BBU_Feature_Req message 540 ::= 541 542 Where: 544 ::= 545 547 6.6. The BBU_Feature_Rep message 549 ::= 550 551 Where: 553 ::= 554 556 ::= 557 559 ::= 560 561 563 6.7. The RRU_A_Mod message 565 ::= 566 567 Where: 568 ::= 569 570 572 6.8. The RRU_A_Rep message 574 ::= 575 576 Where: 577 ::= 578 579 581 6.9. The TN_A_Mod message 582 ::= 583 584 Where: 585 ::= 586 587 589 ::= 590 591 593 6.10. The TN_A_Rep message 595 ::= 596 597 Where: 598 ::= 599 600 602 6.11. The BBU_A_Mod message 604 ::= 605 606 Where: 607 ::= 608 609 611 6.12. The BBU_A_Rep message 613 ::= 614 615 Where: 616 ::= 617 618 620 7. Object Formats 622 A object carried within a communication protocol messages for eCoMP, 623 which consists of one or more 32-bit words with a common header. 625 7.1. Initialization Phase Object 627 7.1.1. RRU feature request TLV 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | version | type=40 | Message Length | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | xid | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | RRU_ID | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | RRU_IP | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 Figure 9: RRU feature request TLV format 643 The common header consists of version, type and message length. 645 Version (8 bits): The version number. Current version is version 1. 647 Type (8 bits): A number indicates the message type. The 648 "RRU_Feature_Req" message is the type 40. 650 Message Length (16 bits): Total length of the message including the 651 common header, expressed in bytes. 653 The RRU_Feature_Req object body consists of the hardware id (xid), 654 RRU id(RRU_ID) and RRU ip (RRU_IP). 656 7.1.2. TN feature request TLV 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | version | type=41 | Message Length | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | xid | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | node_ID | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | node_IP | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Figure 10: TN feature request TLV format 672 The common header is similar with the RRU feature request object. 673 The "TN_Feature_Req" message is the type 41. 675 The TN_Feature_Req object body consists of the hardware id (xid), 676 node id(node_ID) and node ip (node_IP). 678 7.1.3. BBU feature request TLV 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | version | type=42 | Message Length | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | xid | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | BBU_ID | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | BBU_IP | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 Figure 11: BBU feature request TLV format 694 The common header is similar with the BBU feature request object. 695 The "BBU_Feature_Req" message is the type 42. 697 The TN_Feature_Req object body consists of the hardware id (xid), BBU 698 id(BBU_ID) and BBU ip (BBU_IP). 700 7.1.4. RRU feature reply TLV 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | version | type=43 | Message Length | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | xid | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | RRU_ID | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | RRU_IP | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | target_BBU_ID | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | eCoMP_status | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | eCoMP_flow | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | total_flow | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | wavelength | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Figure 12: RRU feature reply TLV format 725 The common header is similar with the RRU feature request object. 726 The "RRU_Feature_Rep" message is the type 43. 728 The RRU_Feature_Rep object body consists of the hardware id (xid), 729 RRU id(RRU_ID), RRU ip (RRU_IP),target BBU ID, eCoMP status, 730 eCoMP_flow, total flow, wavelength. 732 The eCoMP_status is used to report the status of eCoMP. Two values 733 are currently defined: "1" is a intra-BBU eCoMP state while "0" is a 734 inter-BBU eCoMP state. 736 7.1.5. TN feature reply TLV 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | version | type=44 | Message Length | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | xid | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | node_ID | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | node_IP | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | port | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | switch_status | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | wavelength | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Figure 13: TN feature reply TLV format 757 The common header is similar with the RRU feature request object. 758 The "TN_Feature_Rep" message is the type 44. 760 The TN_Feature_Rep object body consists of the hardware id (xid), 761 node id(node_ID), node ip (node_IP),port, switch_status and 762 wavelength. 764 7.2. BBU feature reply TLV 765 0 1 2 3 766 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 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | version | type=45 | Message Length | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | xid | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | BBU_ID | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | BBU_IP | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | load_status | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | wavelength | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | eCoMP_status | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 Figure 14: BBU feature reply TLV format 785 The common header is similar with the RRU feature request object. 786 The "RRU_Feature_Rep" message is the type 45. 788 The RRU_Feature_Rep object body consists of the hardware id (xid), 789 BBU id(BBU_ID), BBU ip (BBU_IP), load status, wavelength, eCoMP 790 status. 792 The eCoMP_status is used to report the status of eCoMP. Two values 793 are currently defined: "1" is a intra-BBU eCoMP state while "0" is a 794 inter-BBU eCoMP state. 796 7.3. Lightpath Reconfiguration Phase Object 798 7.3.1. RRU modification request TLV 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | version | type=46 | Message Length | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | xid | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | RRU_ID | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | node_IP | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | eCoMP_status | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Figure 15: RRU modification request TLV format 815 The common header is similar with the RRU feature request object. 816 The "RRU_A_Mod" message is the type 44. 818 The RRU_A_Mod object body consists of the hardware id (xid), RRU 819 id(RRU_ID), RRU ip (node_IP) and eCoMP status(eCoMP_status). 821 7.3.2. TN modification request TLV 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | version | type=47 | Message Length | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | xid | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | TN_ID | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | node_IP | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | port | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | switch_status | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | wavelength | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 Figure 16: TN modification request TLV format 843 The common header is similar with the RRU feature request object. 844 The "TN_A_Mod" message is the type 47. 846 The TN_A_Mod object body consists of the hardware id (xid), TN 847 id(TN_ID), node ip (node_IP), port, switch_status and wavelength. 849 7.3.3. BBU 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=48 | Message Length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | xid | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | BBU_ID | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | node_IP | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | eCoMP_status | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Figure 17: BBU modification request TLV format 867 The common header is similar with the RRU feature request object. 868 The "BBU_A_Mod" message is the type 48. 870 The BBU_A_Mod object body consists of the hardware id (xid), BBU 871 id(BBU_ID), node ip (node_IP) and eCoMP status(eCoMP_status). 873 7.3.4. RRU modification reply TLV 875 0 1 2 3 876 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 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | version | type=49 | Message Length | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | xid | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | RRU_ID | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | node_IP | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | RRU_config_reply | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 Figure 18: RRU modification reply TLV format 891 The common header is similar with the RRU feature request object. 892 The "RRU_A_Rep" message is the type 49. 894 The BBU_A_Mod object body consists of the hardware id (xid), RRU 895 id(RRU_ID), node ip (node_IP) and BBU configuration 896 reply(RRU_config_reply). 898 The RRU_config_reply is used to report the result of RRU 899 configuration. Two values are currently defined: "1" is a successful 900 state while "0" is a failure state. 902 7.3.5. TN modification reply TLV 904 0 1 2 3 905 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 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | version | type=50 | Message Length | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | xid | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | TN_ID | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | node_IP | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | TN_config_reply | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 Figure 19: TN modification reply TLV format 920 The common header is similar with the RRU feature request object. 921 The "TN_A_Rep" message is the type 50. 923 The TN_A_Mod object body consists of the hardware id (xid), TN 924 id(TN_ID), node ip (node_IP) and TN configuration 925 reply(TN_config_reply). 927 The TN_config_reply is used to report the result of TN configuration. 928 Two values are currently defined: "1" is a successful state while "0" 929 is a failure state. 931 7.3.6. BBU modification reply TLV 932 0 1 2 3 933 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 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | version | type=51 | Message Length | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | xid | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | BBU_ID | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | node_IP | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | BBU_config_reply | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 Figure 20: BBU modification reply TLV format 948 The common header is similar with the RRU feature request object. 949 The "BBU_A_Rep" message is the type 51. 951 The BBU_A_Mod object body consists of the hardware id (xid), BBU 952 id(BBU_ID), node ip (node_IP) and BBU configuration 953 reply(BBU_config_reply). 955 The BBU_config_reply is used to report the result of BBU 956 configuration. Two values are currently defined: "1" is a successful 957 state while "0" is a failure state. 959 8. Acknowledgments 961 9. Contributors 963 Authors' Addresses 965 Zhen Liu (editor) 966 Beijing University of Posts and Telecommunications 967 Xitucheng Road 968 Beijing, Haidian Dist 100876 969 China 971 Phone: +86-15832040790 972 Email: liuzhen207@bupt.edu.cn 973 Jiawei Zhang (editor) 974 Beijing University of Posts and Telecommunications 975 Xitucheng Road 976 Beijing, Haidian Dist 100876 977 China 979 Phone: +86-18600582335 980 Email: zjw@bupt.edu.cn 982 Sainan Liu (editor) 983 Beijing University of Posts and Telecommunications 984 Xitucheng Road 985 Beijing, Haidian Dist 100876 986 China 988 Phone: +86-010-61198422 989 Email: lsn0429@bupt.edu.cn 991 Yuefeng Ji (editor) 992 Beijing University of Posts and Telecommunications 993 Xitucheng Road 994 Beijing, Haidian Dist 100876 995 China 997 Phone: +86-13701131345 998 Email: jyf@bupt.edu.cn