idnits 2.17.1 draft-wang-ccamp-flexe-control-analysis-01.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 (May 22, 2019) is 1798 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 206, but not defined == Unused Reference: 'I-D.izh-ccamp-flexe-fwk' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'I-D.xiaobn-ccamp-flexe-yang-mod' is defined on line 390, 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: November 23, 2019 Y. Xu 6 CAICT 7 May 22, 2019 9 Analysis for FlexE control 10 draft-wang-ccamp-flexe-control-analysis-01 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 November 23, 2019. 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 . . . . . . . . . . . . . . . . . 5 63 3.2.2. Configuration of FlexE group . . . . . . . . . . . . 6 64 3.2.3. Allocate Resources for Client MAC flows . . . . . . . 6 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 architecture according to the analysis in section 2. What kind of 87 model should we employed when configuring FlexE capable equipments, 88 how to 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], which is about 92 "Characteristics of equipment functional blocks supporting Flex 93 Ethernet interfaces". 95 2. Terminology 97 2.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 3. Analysis 105 3.1. General Introduction of FlexE 107 The FlexE shim is built into the Ethernet PCS (physical coding 108 sublayer). If a FlexE group is set up, a corresponding n*100G (or 109 n*200G, n*400G) PCS module with multiple FlexE client ports could be 110 created as well. 112 The difference between the FlexE and the traditional 100G Ethernet is 113 that the traditional Ethernet PCS has a 1:1 relationship with the 114 client MAC flow, while with FlexE one bonded huge PCS module can be 115 used to transport more than one client MAC flow i.e., the 116 relationship is 1:n, with each MAC flow mapped into one FlexE client. 118 3.1.1. FlexE Group 120 A FlexE Group is consisted of from 1 to n 100G FlexE instances, which 121 are carried over from 1 to m 100G, 200G or 400G Ethernet PHYs. All 122 PHYs in the group must operate at the same rate. 124 FlexE group is consisted of a number of FlexE instances, and each 125 instance is consisted of 66B blocks stream. Section monitoring 126 overhead is added/extracted as one 66B block at the FlexE group 127 source and destination (i.e., trail termination) to determine the 128 status of the FlexE group (i.e., FlexE trail in ITU-T terminology). 129 Currently, only RPF (Remote PHY Fault) indication is used to report 130 the state of FlexE group. 132 One FlexE group exists between two FlexE shim, there is no slot 133 switching defined in FlexE. In addition, only one fault indication 134 is defined, there is no other OAM function developed yet. Based on 135 these analysis, we should be able to understand that FlexE is just an 136 interface technology, and once a FlexE group is configured, it only 137 functions as one Ethernet link, similar to Ethernet PHY. 139 3.1.2. FlexE Client 141 A FlexE Client is an Ethernet flow based on a MAC data rate that may 142 or may not correspond to any Ethernet PHY rate. The FlexE Client MAC 143 rates supported by a FlexE Groups could be 10Gb/s, 40Gb/s, or m*25Gb/ 144 s. The FlexE Client MAC rates supported by FlexE Groups may support 145 all, or only a subset of these FlexE Client rates. Each FlexE Client 146 is presented to the FlexE Shim as a 64B/66B encoded bit stream 147 according to clause 82 of [IEEE 802.3]. FlexE clients have the 148 semantics of an Ethernet PHY. There is no new layer network. Both 149 FlexE group and FlexE client are processed at Ethernet PHY layer. 150 From the network management perspective, the FlexE client is able to 151 see the calendar slots information. The FlexE client could be 152 generated internally within a system, or created from a traditional 153 Ethernet PHY. What kind of FlexE clients will be created depends on 154 the operator's needs. 156 According to the description in clause 8.1 of [ITU-T G.8023], there 157 is no overhead defined for monitoring a FlexE client, so the trail 158 for FlexE client in the equipment does not exist. The FlexE client 159 trail termination function is a null function. Therefore, modelling 160 FlexE client as a network layer is not correct. 162 3.1.3. Adaptation function between FlexE Client and FlexE Group 164 In order to distribute the FlexE client over PHYs of one FlexE group, 165 a number of management information command should be sent to the 166 adaptation function which performs the mapping of FlexE client over 167 FlexE group. 169 According to the description in clause 7.2 of [ITU-T G.8023], the 170 external management information command sent to the source adaptation 171 function is listed below: 173 TxCC, TxCCA, TxCCB, TxCR, TxCA 175 TxGID, TxPHYMAP 177 The TxCC, TxCCA and TxCCB are used to configure the calendar for use, 178 which could be type A or type B calendar configuration, slots 179 allocated for a specific FlexE client and FlexE client number. 181 TxCR and TxCA are used to coordinate the switch of calendar 182 configuration between the FlexE source and destination node. 184 The TxGID is used to configure the FlexE group identifier. The 185 TxPHYMAP is used to configure the set of PHYs in the FlexE group. If 186 200G and 400G are used, the 100G FlexE instance should be used in the 187 case of PHYMAP, as current version of [ITU-T G.8023] only cover the 188 scope of 100G PHY. 190 The built-in function multiplexer performs the action of assigning 191 the individual FlexE Client to specific calendar slots of the FlexE 192 group according to the input management information. 194 At the destination side, the Demultiplexer function could use 195 activate the FlexE Client and assigns the calendar slots of the FlexE 196 group payload area to the individual FlexE client accordng to 197 external configuration or the client calendar information carried in 198 the overhead. 200 3.1.4. MAC Frame 202 Defined in IEEE. 204 3.1.5. Adaptation between MAC frames and FlexE Client 206 It can be seen from the Figure 8-6 of [ITU-T G.8023] that the 207 external management information commands used as input to the 208 adaptation function are defined by [IEEE 802.3]. The [IEEE 802.3] 209 process mainly includes the 64B/66B encoding, as well as MAC frame 210 check sequence generation and frame counting. The FlexE client 211 stream is generated at the determined FlexE Client MAC rate and 212 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 as 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. Based on the above analysis, two 222 high-level requirements for control/management of FlexE are 223 considered in this draft. 225 Configuration of FlexE group 227 Allocation of one or more FlexE group calendar slot resources to a 228 client MAC flow. 230 3.2.1. Configuration Mode 232 There are two different configuration modes for bring one FlexE link 233 into service. The first one is static model, which is to use 234 external management system to configure the source and destination 235 FlexE shims. There is no need for the FlexE source and destination 236 to coordinate through the FlexE overhead as all the configuration 237 work mentioned above is finished by the external management system. 238 In this case, the CR/CA mechanism does not work; the other one is 239 MASTER/SLAVE mode, which is to use the FlexE overhead to coordinate 240 the resource configuration between FlexE source and destination, the 241 external resource configuration information is only sent the source 242 node. 244 3.2.2. Configuration of FlexE group 246 It can be concluded from the above analysis that external 247 configuration tools should be involved to bring one FlexE group into 248 service. The initial configuration commands could be from external 249 management system, SDN controller etc. 251 A FlexE group must be configured first before any client signals are 252 carried over it. When a new FlexE Group is brought into service, the 253 initial configuration must be provisioned for both ends, and the 254 initial configuration must be the same. The group is configured to 255 be consist of from 1 to n 100G FlexE Instances carried over from 1 to 256 m PHYs of the same rate (100GBASE-R, 200GBASE-R, or 400GBASE-R). A 257 PHY number may correspond to the physical port ordering on equipment, 258 but the FlexE Shim at each end of the group must identify each PHY in 259 the group using the same PHY number, and each 100G FlexE Instance 260 with the same 100G FlexE Instance number. In certain cases, it may 261 be desirable not to populate all 100G FlexE instances on a 200G or 262 400G PHY, and these so-called unequipped FlexE instance should also 263 be configured. Unequipped instances must always be the highest 264 numbered instance(s) on a PHY of the FlexE Group, and there must 265 always be at least one equipped 100G FlexE Instance on every PHY. 267 If aware case is needed to be considered, unavailable slot 268 information should be configured at FlexE aware node to discard 269 unavailable slot first, so as to put the rest of available slots onto 270 the lower rate physical port. 272 3.2.3. Allocate Resources for Client MAC flows 274 The FlexE client MAC flows are encapsulated in one or more FlexE 275 calendar slots. 277 According to the analysis in section 3.2.1, there are two different 278 configuration modes. For the first one, static mode, the FlexE group 279 bonding information and resource allocation information are sent both 280 to FlexE souce and destination to help enable the FlexE link. 281 Information sent is described in section 3.3.1, 3.3.2 and 3.3.3, 282 which can also be found in [draft-xiaobn-ccamp-flexe-yang-mod]. A 283 FlexE group and a number of FlexE clients are created according to 284 the configuration information. For the Master/slave mode, the FlexE 285 group bonding information and resource allocation information are 286 only sent to the FlexE source site. The FlexE source site first 287 create the corresponding FlexE group and FlexE clients, and then the 288 built-in multiplexer at the FlexE source site allocates the calendar 289 slots to a specific FlexE client according to the input from external 290 management system, and insert these configuration information into 291 the FlexE overhead. When these overheads arrives at the destination 292 site, the demultiplexer function at the destination site extracts 293 FlexE overhead first and get the information of calendar slot 294 allocation information. Based on these information, the FlexE 295 destination site finish the configuration of FlexE group and FlexE 296 clients. In order to verify the correctness of the resource 297 configuration, the expected FlexE group ID, PHY number and instance 298 number information, FlexE client number and slot allocation 299 information for a specific FlexE client should also be configured to 300 FlexE destination site. 302 The FlexE client port is an internal port which only perform the 303 function of encapsulating upper layer packets into MAC frames, 304 64b/66b encoding. The bandwidth capability of these internal ports 305 should be known by external management/control tools in order to be 306 used by the upper layer (e.g., MPLS-TP) flow correctly. 308 3.3. Control Requirements Derived 310 a. Using external control/management system to configure FlexE 311 group, which may include the configuration of group number, PHY 312 number and instance number, as well as correlation between 313 logical PHY number and physical port number. 315 b. Using eternal control/management system to configure the FlexE 316 client, which include the FlexE client number, FlexE client type 317 and slots allocation information. 319 c. External control command could be provide to trigger the switch 320 of calendar slots. 322 d. Interworking between 5G slot granularity capable node and 25G 323 slot granularity node. 325 e. Configuration of unequipped instance, unavailable slots, which 326 include the number of unequipped instance and number of 327 unavailable slots on each instances 329 Different kinds of alarms should be taken into consideration when 330 modelling FlexE technology, which may include PHY failed, skew exceed 331 threshold, inconsistent configuration between two ends. 333 4. Summary 335 According to the analysis in section 2, the main control/management 336 requirement for FlexE technology is to configure the FlexE group and 337 FlexE client. Once a FlexE group is configured and the FlexE client 338 ports is created, slots allocation is configured, use of the FlexE 339 technology is the same as that in traditional Ethernet. 341 5. Acknowledgements 343 6. IANA Considerations 345 This memo includes no request to IANA. 347 7. Security Considerations 349 None. 351 8. References 353 8.1. Normative References 355 [ITU-T_G709] 356 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 357 07/2016", http://www.itu.int/rec/T-REC- 358 G..709-201606-P/en, July 2016. 360 [ITU-T_G798] 361 ITU-T, "ITU-T G.798: Characteristics of optical transport 362 network hierarchy equipment functional blocks", August 363 2018. 365 [ITU-T_G8023] 366 ITU-T, "ITU-T G.8023: Characteristics of equipment 367 functional blocks supporting Ethernet physical layer and 368 Flex Ethernet interfaces", , 2016. 370 [ITU-T_G872] 371 ITU-T, "ITU-T G.872: The Architecture of Optical Transport 372 Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en, 373 January 2017. 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, 377 DOI 10.17487/RFC2119, March 1997, 378 . 380 8.2. Informative References 382 [I-D.izh-ccamp-flexe-fwk] 383 Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., 384 Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., 385 zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. 386 Zhong, "GMPLS Routing and Signaling Framework for Flexible 387 Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in 388 progress), October 2016. 390 [I-D.xiaobn-ccamp-flexe-yang-mod] 391 NIU, X., Wang, Q., Xu, Y., and S. Munagapati, "A YANG Data 392 Model for Flex Ethernet(FlexE)", draft-xiaobn-ccamp-flexe- 393 yang-mod-01 (work in progress), May 2019. 395 Authors' Addresses 397 Qilei Wang (editor) 398 ZTE Corporation 399 Nanjing 400 CN 402 Email: wang.qilei@zte.com.cn 404 Xiaobing Niu (editor) 405 ZTE Corporation 406 Beijing 407 CN 409 Email: niu.xiaobing@zte.com.cn 411 Yunbin Xu 412 CAICT 413 Beijing 414 CN 416 Email: xuyunbin@caict.ac.cn