idnits 2.17.1 draft-wang-ccamp-flexe-control-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2019) is 1747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T G.872' is mentioned on line 81, but not defined == Missing Reference: 'ITU-T G.709' is mentioned on line 81, but not defined == Missing Reference: 'ITU-T G.798' is mentioned on line 81, but not defined == Missing Reference: 'ITU-T G.8023' is mentioned on line 209, but not defined == Unused Reference: 'I-D.izh-ccamp-flexe-fwk' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'I-D.xiaobn-ccamp-flexe-yang-mod' is defined on line 396, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-izh-ccamp-flexe-fwk-00 == Outdated reference: A later version (-03) exists of draft-xiaobn-ccamp-flexe-yang-mod-01 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Q. Wang, Ed. 3 Internet-Draft X. Niu, Ed. 4 Intended status: Informational ZTE Corporation 5 Expires: January 9, 2020 Y. Xu 6 CAICT 7 July 8, 2019 9 Analysis for FlexE control 10 draft-wang-ccamp-flexe-control-analysis-02 12 Abstract 14 This document gives some analysis about the control of FlexE. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 9, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. General Introduction of FlexE . . . . . . . . . . . . . . 3 55 3.1.1. FlexE Group . . . . . . . . . . . . . . . . . . . . . 3 56 3.1.2. FlexE Client . . . . . . . . . . . . . . . . . . . . 4 57 3.1.3. Adaptation function between FlexE Client and FlexE 58 Group . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1.4. MAC Frame . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1.5. Adaptation between MAC frames and FlexE Client . . . 5 61 3.2. General requirements . . . . . . . . . . . . . . . . . . 5 62 3.2.1. Configuration Mode for FlexE client . . . . . . . . . 6 63 3.2.2. Configuration of FlexE group . . . . . . . . . . . . 6 64 3.2.3. Allocate Resources for FlexE Client . . . . . . . . . 7 65 3.3. Control Requirements Derived . . . . . . . . . . . . . . 7 66 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 OIF published the first version of FlexE Implementation Agreement in 78 March 2016, aiming to provide a generic mechanism for supporting a 79 variety of Ethernet MAC rates that may or may not correspond to any 80 existing Ethernet PHY rate. SG15 in ITU-T has endorsed the OIF FlexE 81 data plane and parts of [ITU-T G.872], [ITU-T G.709], [ITU-T G.798] 82 and [ITU-T G.8023]. The Recommendations depend on or are based on 83 the FlexE data plane. 85 This draft is intended to trigger discussion of the FlexE control 86 requirements, which can be found in section 2. What kind of model 87 should we employed when configuring FlexE capable equipments, how to 88 configure the FlexE group and FlexE client, and what kind of 89 parameters do we need to take into consideration when configuring 90 FlexE group and FlexE client. The analysis is based on the 91 description in section 7 and 8 of [ITU-T G.8023] and FlexE IA 2.0. 93 2. Terminology 95 2.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 3. Analysis 103 3.1. General Introduction of FlexE 105 The FlexE shim is built into the Ethernet PCS (physical coding 106 sublayer). If a FlexE group is set up, a corresponding n*100G (or 107 n*200G, n*400G) PCS module with multiple FlexE client ports could be 108 created as well. 110 The difference between the FlexE and the traditional 100G Ethernet is 111 that the traditional Ethernet PCS has a 1:1 relationship with the 112 client MAC flow, while with FlexE one bonded huge PCS module can be 113 used to transport more than one client MAC flow i.e., the 114 relationship is 1:n, with each MAC flow mapped into one FlexE client. 116 3.1.1. FlexE Group 118 A FlexE Group is consisted of from 1 to n 100G FlexE instances, which 119 are carried over from 1 to m 100G, 200G or 400G Ethernet PHYs. All 120 PHYs in the group must operate at the same rate. 122 FlexE group is consisted of a number of FlexE instances, and each 123 instance is consisted of 66B blocks stream. Section monitoring 124 overhead is added/extracted as one 66B block at the FlexE group 125 source and destination (i.e., trail termination) to determine the 126 status of the FlexE group (i.e., FlexE trail in ITU-T terminology). 127 Currently, only RPF (Remote PHY Fault) indication is used to report 128 the state of FlexE group. 130 The FlexE group exists between two FlexE shim, there is no slot 131 switching defined in FlexE. Only one fault indication is defined, 132 there is no other OAM function developed yet. Based on these 133 analysis, we should be able to understand that FlexE is just an 134 interface technology, and once a FlexE group is configured, it only 135 functions as one Ethernet link, similar to Ethernet PHY. 137 3.1.2. FlexE Client 139 A FlexE Client is an Ethernet flow based on a MAC data rate that may 140 or may not correspond to any Ethernet PHY rate. The FlexE Client MAC 141 rates supported by a FlexE Groups could be 10Gb/s, 40Gb/s, or m*25Gb/ 142 s. The FlexE Client MAC rates supported by FlexE Groups may support 143 all, or only a subset of these FlexE Client rates. Each FlexE Client 144 is presented to the FlexE Shim as a 64B/66B encoded bit stream 145 according to clause 82 of [IEEE 802.3]. FlexE clients have the 146 semantics of an Ethernet PHY. There is no new layer network. Both 147 FlexE group and FlexE client are processed at Ethernet PHY layer. 148 From the network management perspective, the FlexE client can be 149 created and the calendar slots information of one FlexE group can be 150 allocated to one FlexE client. The FlexE client could be generated 151 internally within a system, or created from a traditional Ethernet 152 PHY. What kind of FlexE clients will be created depends on the 153 operator's needs. 155 According to the description in clause 8.1 of [ITU-T G.8023], there 156 is no overhead defined for monitoring a FlexE client, so the trail 157 for FlexE client in the equipment does not exist. The FlexE client 158 trail termination function is a null function. Therefore, modelling 159 FlexE client as a network layer is not correct. 161 3.1.3. Adaptation function between FlexE Client and FlexE Group 163 In order to distribute the FlexE client over PHYs of one FlexE group, 164 a number of management information command should be sent to the 165 adaptation function which performs the mapping of FlexE client over 166 FlexE group. 168 According to the description in clause 7.2 of [ITU-T G.8023], the 169 external management information command sent to the source adaptation 170 function is listed below: 172 TxCC, TxCCA, TxCCB, TxCR, TxCA 174 TxGID, TxPHYMAP 176 The TxCC, TxCCA and TxCCB are used to configure the calendar for use, 177 which could be type A or type B calendar configuration, slots 178 allocated for a specific FlexE client and FlexE client number. 180 TxCR and TxCA are used to coordinate the switch of calendar 181 configuration between the FlexE source and destination node. 183 The TxGID is used to configure the FlexE group identifier. The 184 TxPHYMAP is used to configure the set of PHYs in the FlexE group. If 185 200G and 400G are used, the 100G FlexE instance should be used in the 186 case of PHYMAP, as current version of [ITU-T G.8023] only cover the 187 scope of 100G PHY. 189 The built-in function multiplexer performs the action of assigning 190 the individual FlexE Client to specific calendar slots of the FlexE 191 group according to the input management information. 193 At the destination side, the Demultiplexer function could use 194 activate the FlexE Client and assigns the calendar slots of the FlexE 195 group payload area to the individual FlexE client accordng to 196 external configuration or the client calendar information carried in 197 the overhead. Expected group ID, PHYMAP and calendar allocation 198 information are needed sometimes to help verify the correctness of 199 FlexE configuration. 201 3.1.4. MAC Frame 203 Defined in IEEE. 205 3.1.5. Adaptation between MAC frames and FlexE Client 207 The external management information commands used as input to the 208 adaptation function are defined by [IEEE 802.3], according to the 209 description in [ITU-T G.8023]. The [IEEE 802.3] process mainly 210 includes the 64B/66B encoding, as well as MAC frame check sequence 211 generation and frame counting. The FlexE client stream is generated 212 at the determined FlexE Client MAC rate and 64B/66B encoded. 214 3.2. General requirements 216 It can be inferred from section 2.1.2 and section 2.1.5 that process 217 involved when producing the FlexE Client from MAC frames is 64b/66b 218 encoding, and this encoding has already been defined by [IEEE 802.3], 219 no extra overhead is added during this process. Therefore, 220 configuration for mapping MAC frames into FlexE client from external 221 management system is not needed. 223 Based on the above analysis, two high-level requirements for control/ 224 management of FlexE are considered in this draft. 226 Configuration mode 228 Configuration of FlexE group 230 Creation of FlexE client and allocation of one or more FlexE group 231 calendar slot resources to a FlexE client. 233 3.2.1. Configuration Mode for FlexE client 235 There are two different configuration modes for bring one FlexE 236 client into service. The first one is static model, which is to use 237 external management system to configure the FlexE client and 238 resources allocated for the FlexE client at source and destination 239 FlexE shims. In this case, the CR/CA mechanism does not work. 240 Verification of configuration consistensy at FlexE source and 241 destination site by comparing the inband FlexE overhead with the 242 configuration at FlexE destination are needed; The other one is 243 MASTER/SLAVE mode, which is to use the FlexE overhead to coordinate 244 the resource configuration between FlexE source and destination, the 245 external resource configuration information is only sent the source 246 node. 248 3.2.2. Configuration of FlexE group 250 It can be concluded from the above analysis that external 251 configuration tools should be involved to bring one FlexE group into 252 service. The initial configuration commands could be from external 253 management system, SDN controller etc. 255 A FlexE group must be configured first before any client signals are 256 carried over it. When a new FlexE Group is brought into service, the 257 initial configuration must be provisioned for both ends, and the 258 initial configuration must be the same for both direction. The group 259 is configured to be consist of from 1 to n 100G FlexE Instances 260 carried over from 1 to m PHYs of the same rate (100GBASE-R, 200GBASE- 261 R, or 400GBASE-R). A PHY number may correspond to the physical port 262 ordering on equipment, but the FlexE Shim at each end of the group 263 must identify each PHY in the group using the same PHY number, and 264 each 100G FlexE Instance with the same 100G FlexE Instance number. 265 In certain cases, it may be desirable not to populate all 100G FlexE 266 instances on a 200G or 400G PHY, and these so-called unequipped FlexE 267 instance should also be configured. Unequipped instances must always 268 be the highest numbered instance(s) on a PHY of the FlexE Group, and 269 there must always be at least one equipped 100G FlexE Instance on 270 every PHY. 272 If aware case is needed to be considered, unavailable slot 273 information should be configured at FlexE aware node to discard 274 unavailable slot first, so as to put the rest of available slots onto 275 the lower rate physical port. 277 3.2.3. Allocate Resources for FlexE Client 279 The FlexE client MAC flows are encapsulated in one or more FlexE 280 calendar slots. 282 According to the analysis in section 3.2.1, there are two different 283 configuration modes. For the first one, static mode, after the FlexE 284 group is configured, the FlexE client resource allocation information 285 are sent both to FlexE souce and destination to help create the FlexE 286 client. A number of expected configuration parameters are sent to 287 FlexE destination to help verify the correctness of configuration at 288 both sides. Information sent can be found in [draft-xiaobn-ccamp- 289 flexe-yang-mod]. For the Master/slave mode, the FlexE client 290 resource allocation information are only sent to the FlexE source 291 site. The FlexE source site first create the FlexE clients, and then 292 the built-in multiplexer at the FlexE source site allocates the 293 calendar slots to a specific FlexE client according to the input from 294 external management system, and insert these configuration 295 information into the FlexE overhead. When these overheads arrives at 296 the destination site, the demultiplexer function at the destination 297 site extracts FlexE overhead first and get the information of 298 calendar slot allocation information. Based on these information, 299 the FlexE destination site finish the configuration of FlexE clients. 300 In order to verify the correctness of the resource configuration, the 301 expected FlexE group ID, PHY number and instance number information, 302 FlexE client number and slot allocation information for a specific 303 FlexE client should also be configured to FlexE destination site. 305 The FlexE client port is an internal port which only perform the 306 function of encapsulating upper layer packets into MAC frames, 307 64b/66b encoding. The bandwidth capability of these internal ports 308 should be known by external management/control tools in order to be 309 used by the upper layer (e.g., MPLS-TP) flow correctly. 311 3.3. Control Requirements Derived 313 a. Using external control/management system to configure FlexE 314 group, which may include the configuration of group number, PHY 315 number and instance number, as well as correlation between 316 logical PHY number and physical port number. A number of 317 expected configuration parameters are also needed to help verify 318 the consisten between FlexE source and destination. 320 b. Using eternal control/management system to create the FlexE 321 client, which include the FlexE client number, FlexE client type 322 and slots allocation information. Different configuration mode 323 for FlexE client are needed. 325 c. External control command could be provide to trigger the switch 326 of calendar slots. 328 d. Interworking between 5G slot granularity capable node and 25G 329 slot granularity node. 331 e. Configuration of unequipped instance, unavailable slots, which 332 include the number of unequipped instance and number of 333 unavailable slots on each instances 335 Different kinds of alarms should be taken into consideration when 336 modelling FlexE technology, which may include PHY failed, skew exceed 337 threshold, inconsistent configuration between two ends. 339 4. Summary 341 According to the analysis in section 2, the main control/management 342 requirement for FlexE technology is to configure the FlexE group and 343 FlexE client. Once a FlexE group is configured and the FlexE client 344 ports is created, slots allocation is configured, use of the FlexE 345 technology is the same as that in traditional Ethernet. 347 5. Acknowledgements 349 6. IANA Considerations 351 This memo includes no request to IANA. 353 7. Security Considerations 355 None. 357 8. References 359 8.1. Normative References 361 [ITU-T_G709] 362 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 363 07/2016", http://www.itu.int/rec/T-REC- 364 G..709-201606-P/en, July 2016. 366 [ITU-T_G798] 367 ITU-T, "ITU-T G.798: Characteristics of optical transport 368 network hierarchy equipment functional blocks", August 369 2018. 371 [ITU-T_G8023] 372 ITU-T, "ITU-T G.8023: Characteristics of equipment 373 functional blocks supporting Ethernet physical layer and 374 Flex Ethernet interfaces", , 2016. 376 [ITU-T_G872] 377 ITU-T, "ITU-T G.872: The Architecture of Optical Transport 378 Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en, 379 January 2017. 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, 383 DOI 10.17487/RFC2119, March 1997, 384 . 386 8.2. Informative References 388 [I-D.izh-ccamp-flexe-fwk] 389 Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., 390 Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., 391 zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. 392 Zhong, "GMPLS Routing and Signaling Framework for Flexible 393 Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in 394 progress), October 2016. 396 [I-D.xiaobn-ccamp-flexe-yang-mod] 397 NIU, X., Wang, Q., Xu, Y., and S. Munagapati, "A YANG Data 398 Model for Flex Ethernet(FlexE)", draft-xiaobn-ccamp-flexe- 399 yang-mod-01 (work in progress), May 2019. 401 Authors' Addresses 403 Qilei Wang (editor) 404 ZTE Corporation 405 Nanjing 406 CN 408 Email: wang.qilei@zte.com.cn 410 Xiaobing Niu (editor) 411 ZTE Corporation 412 Beijing 413 CN 415 Email: niu.xiaobing@zte.com.cn 416 Yunbin Xu 417 CAICT 418 Beijing 419 CN 421 Email: xuyunbin@caict.ac.cn