idnits 2.17.1 draft-wang-ccamp-flexe-control-analysis-03.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 (November 4, 2019) is 1635 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T G.872' is mentioned on line 80, but not defined == Missing Reference: 'ITU-T G.709' is mentioned on line 80, but not defined == Missing Reference: 'ITU-T G.798' is mentioned on line 80, but not defined == Missing Reference: 'ITU-T G.8023' is mentioned on line 223, but not defined == Unused Reference: 'I-D.izh-ccamp-flexe-fwk' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'I-D.xiaobn-ccamp-flexe-yang-mod' is defined on line 424, 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: May 7, 2020 Y. Xu 6 CAICT 7 November 4, 2019 9 Analysis for FlexE control 10 draft-wang-ccamp-flexe-control-analysis-03 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 May 7, 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. Encapsulation of FlexE Client into FlexE Group . . . 4 58 3.1.4. MAC Frame . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1.5. Encapsulation of MAC frames into FlexE Client . . . . 5 60 3.2. General requirements . . . . . . . . . . . . . . . . . . 5 61 3.2.1. Configuration Mode for FlexE client . . . . . . . . . 6 62 3.2.2. Configuration of FlexE group . . . . . . . . . . . . 6 63 3.2.3. Allocate Resources for FlexE Client . . . . . . . . . 7 64 3.3. Control Requirements Derived . . . . . . . . . . . . . . 8 65 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 8.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 OIF published the first version of FlexE Implementation Agreement in 77 March 2016, aiming to provide a generic mechanism for supporting a 78 variety of Ethernet MAC rates that may or may not correspond to any 79 existing Ethernet PHY rate. ITU-T SG15 has endorsed the OIF FlexE 80 data plane as parts of [ITU-T G.872], [ITU-T G.709], [ITU-T G.798] 81 and [ITU-T G.8023]. The Recommendations depend on or are based on 82 the FlexE data plane. 84 This draft is intended to trigger discussion of the FlexE control 85 requirements. What kind of models should we use when configuring 86 FlexE capable equipment, how to configure the FlexE group and FlexE 87 client, and what kind of parameters do we need to take into 88 consideration when configuring FlexE group and FlexE client. The 89 analysis is based on the description in section 7 and 8 of [ITU-T 90 G.8023] and FlexE IA 2.0. 92 2. Terminology 94 2.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 3. Analysis 102 3.1. General Introduction of FlexE 104 The FlexE shim is built into the Ethernet PCS (physical coding 105 sublayer). If a FlexE group is configured, a corresponding n*100G 106 (or n*50G, n*200G, n*400G) PCS module which may support multiple 107 FlexE clients is created as well. 109 The difference between the FlexE and the traditional Ethernet is that 110 the traditional Ethernet PCS has a 1:1 relationship with the client 111 MAC flow, while with FlexE one bonded huge PCS module can be used to 112 transport more than one FlexE client i.e., the relationship is 1:n. 114 3.1.1. FlexE Group 116 A FlexE Group is consisted of from 1 to n 100G FlexE instances, which 117 are carried over from 1 to m 100G, 200G or 400G Ethernet PHYs. A 118 FlexE group can also consisted of from 1 to n 50G FlexE instances, 119 which are carried over from 1 to m 50G Ethernet PHYs. All PHYs in 120 the group must operate at the same rate. 122 A FlexE Instance is a unit of information consisting of 50G or 100G 123 of capacity, which is able to carry FlexE Client data, together with 124 its associated overhead. Section monitoring overhead is added/ 125 extracted as one 66B block at the FlexE group source and destination 126 (i.e., trail termination) to determine the status of the FlexE group. 127 Currently, only RPF (Remote PHY Fault) indication is used to report 128 the status of one FlexE group. 130 The set of FlexE Instances in the FlexE Group (not necessarily 131 consecutive FlexE Instance numbers) are indicated in the "FlexE Map" 132 field of the FlexE overhead. The full FlexE map is sent on all FlexE 133 Instances of the FlexE Group so that it is possible for the FlexE 134 demux to verify that the same FlexE Instance numbers are configured 135 at the FlexE mux as at the FlexE demux, and can tell whether all 136 expected FlexE Instances are being received. 138 3.1.2. FlexE Client 140 A FlexE Client is an Ethernet flow based on a MAC data rate that may 141 or may not correspond to any Ethernet PHY rate. The FlexE Client MAC 142 rates supported by a FlexE Groups could be 10Gb/s, 40Gb/s, or m*25Gb/ 143 s. The FlexE Client MAC rates supported by FlexE Groups may support 144 all, or only a subset of these FlexE Client rates. Each FlexE Client 145 is presented to the FlexE Shim as a 64B/66B encoded bit stream 146 according to clause 82 of [IEEE 802.3]. The FlexE client has the 147 semantics of an Ethernet PHY and there is no new layer network 148 defined for FlexE client, as both FlexE group and FlexE client are 149 processed in Ethernet PHY layer. From the network management point 150 of view, the FlexE client can be created accordingly and the 151 corresponding calendar slots of one FlexE group are allocated to one 152 FlexE client. The FlexE client could be generated internally within 153 a system, or created from a traditional Ethernet PHY. What kind of 154 FlexE clients will be created depends on 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 concept 158 of network connection for FlexE client in the equipment does not 159 exist. It is not correct to treat FlexE client as a network layer. 161 One FlexE client can be generated internally within one system, it 162 can also be formed by converting from the standard Ethernet signal, 163 e.g, a 10GBASE-R signal could be converted to a 10G FlexE Client 164 format by performing idle insertion/deletion. FlexE Clients do not 165 need to be produced or received in the same manner at both ends of 166 the connection. 168 3.1.3. Encapsulation of FlexE Client into FlexE Group 170 In order to distribute the FlexE client over PHYs of one FlexE group, 171 a number of management information command should be sent to the 172 processing function which performs the encapsulation of FlexE client 173 over FlexE group. 175 [ITU-T G.8023] specifies the equipment function blocks for Flex 176 Ethernet interface, which are between equipment management function 177 and atomic function within one network element. According to the 178 description in clause 7.2 of [ITU-T G.8023], the management 179 information commands sent to the source adaptation function from 180 equipment management function are listed below: 182 TxCC, TxCCA, TxCCB, TxCR, TxCA 184 TxGID, TxPHYMAP 186 The TxCC, TxCCA and TxCCB are used to configure the calendar for use, 187 which could be type A or type B calendar configuration, slots 188 allocated for a specific FlexE client and FlexE client number. 190 TxCR and TxCA are used to coordinate the switch of calendar 191 configuration between the FlexE source and destination node. 193 The TxGID is used to configure the FlexE group identifier. The 194 TxPHYMAP is used to configure the set of PHYs in the FlexE group. If 195 200G and 400G are used, the 100G FlexE instance should be used in the 196 case of PHYMAP. 198 The built-in function multiplexer performs the action of assigning 199 the individual FlexE Client to specific calendar slots of the FlexE 200 group according to the input management information. 202 At the destination side, the Demultiplexer function could use 203 activate the FlexE Client and assigns the calendar slots of the FlexE 204 group payload area to the individual FlexE client accordng to 205 external configuration or the client calendar information carried in 206 the overhead. Expected group ID, PHYMAP and calendar allocation 207 information are needed sometimes to help verify the correctness of 208 FlexE configuration. 210 However, not all of the management information listed in [ITU-T 211 G.8023] need to be exposed to the external management system, as some 212 of them may be inferred, e.g., Calendar configuration(CC), which 213 could be inferred by comparing the original and new configuration. 215 3.1.4. MAC Frame 217 Defined in IEEE. 219 3.1.5. Encapsulation of MAC frames into FlexE Client 221 The external management information commands used as input to the 222 encapsulation/adaptation function are defined by [IEEE 802.3], 223 according to the description in [ITU-T G.8023]. The [IEEE 802.3] 224 process mainly includes the 64B/66B encoding, as well as MAC frame 225 check sequence generation and frame counting. The FlexE client 226 stream is generated at the determined FlexE Client MAC rate and 227 64B/66B encoded. 229 3.2. General requirements 231 It can be derived from section 2.1.2 and section 2.1.5 that process 232 involved when producing the FlexE Client from MAC frames is 64b/66b 233 encoding, and this encoding has already been defined by [IEEE 802.3]. 235 as no extra overhead is added during this process. Therefore, 236 configuration for mapping MAC frames into FlexE client from external 237 management system is not needed. In addition to the above analysis, 238 this draft also consider other aspects of requirements for FlexE 239 control/management. 241 Configuration mode for FlexE 243 Configuration of FlexE group 245 Creation of FlexE client and allocation of one or more FlexE group 246 calendar slot resources to a FlexE client. 248 3.2.1. Configuration Mode for FlexE client 250 There are two different configuration modes for bring one FlexE 251 client into service. The first one is static model, which is to use 252 external management system to configure the FlexE client and 253 resources allocated for the FlexE client at source and destination 254 FlexE shims. In this case, the CR/CA mechanism does not work. 255 Verification of configuration consistency at FlexE source and 256 destination site by comparing the in-band FlexE overhead with the 257 configuration at FlexE destination are needed; The other one is 258 MASTER/SLAVE mode, which is to use the FlexE overhead to coordinate 259 the resource configuration between FlexE source and destination, the 260 external resource configuration information is only sent the source 261 node. 263 3.2.2. Configuration of FlexE group 265 It can be concluded from the above analysis that external 266 configuration tools should be involved to bring one FlexE group into 267 service. The initial configuration commands could be from external 268 management system, SDN controller etc. 270 A FlexE group must be configured first before any client signals are 271 carried over it. When a new FlexE Group is brought into service, the 272 initial configuration must be provisioned for both ends, and the 273 initial configuration must be the same for both direction. The group 274 is configured to be consist of from 1 to n 100G FlexE Instances 275 carried over from 1 to m PHYs of the same rate (100GBASE-R, 200GBASE- 276 R, or 400GBASE-R). The group could also be configured to be consist 277 of from 1 to n 50G FlexE Instances carried over from 1 to m PHYs of 278 the same rate (50GBASE-R). A PHY number may correspond to the 279 physical port ordering on equipment, but the FlexE Shim at each end 280 of the group must identify each PHY in the group using the same PHY 281 number, and each FlexE Instance with the same FlexE Instance number. 282 In certain cases, it may be desirable not to populate all 100G FlexE 283 instances on a 200G or 400G PHY, and these so-called unequipped FlexE 284 instance should also be configured. Unequipped instances must always 285 be the highest numbered instance(s) on a PHY of the FlexE Group, and 286 there must always be at least one equipped 100G FlexE Instance on 287 every PHY. 289 If aware case is needed to be considered, unavailable slot 290 information should be configured at FlexE aware node to discard 291 unavailable slot first, so as to put the rest of available slots onto 292 the lower rate physical port. Unavailable slots are placed at the 293 end of each relevant sub-calendar (the highest numbered slots). 295 3.2.3. Allocate Resources for FlexE Client 297 The FlexE client MAC flows are encapsulated in one or more FlexE 298 calendar slots. 300 According to the analysis in section 3.2.1, there are two different 301 configuration modes. For the first one, static mode, after the FlexE 302 group is configured, the FlexE client resource allocation information 303 are sent both to FlexE souce and destination to help create the FlexE 304 client. A number of expected configuration parameters are sent to 305 FlexE destination to help verify the correctness of configuration at 306 both sides. Information sent can be found in [draft-xiaobn-ccamp- 307 flexe-yang-mod]. For the Master/slave mode, the FlexE client 308 resource allocation information are only sent to the FlexE source 309 site. The FlexE source site first create the FlexE clients, and then 310 the built-in multiplexer at the FlexE source site allocates the 311 calendar slots to a specific FlexE client according to the input from 312 external management system, and insert these configuration 313 information into the FlexE overhead. When these overheads arrives at 314 the destination site, the demultiplexer function at the destination 315 site extracts FlexE overhead first and get the information of 316 calendar slot allocation information. Based on these information, 317 the FlexE destination site finish the configuration of FlexE clients. 318 In order to verify the correctness of the resource configuration, the 319 expected FlexE group ID, PHY number and instance number information, 320 FlexE client number and slot allocation information for a specific 321 FlexE client should also be configured to FlexE destination site. 323 The FlexE client port is an internal port which only perform the 324 function of encapsulating upper layer packets into MAC frames, 325 64b/66b encoding. The bandwidth capability of these internal ports 326 should be known by external management/control tools in order to be 327 used by the upper layer (e.g., MPLS-TP) flow correctly. 329 3.3. Control Requirements Derived 331 a. Using external control/management system to configure FlexE 332 group, which may include the configuration of group number, PHY 333 number and instance number, as well as correlation between 334 logical PHY number and physical port number. A number of 335 expected configuration parameters are also needed to help verify 336 the consistency between FlexE source and destination. 338 b. Using external control/management system to create the FlexE 339 client, which include the FlexE client number, FlexE client type 340 and slots allocation information. Different configuration mode 341 for FlexE client are needed. 343 c. External control command could be provide to trigger the switch 344 of calendar slots. 346 d. Interworking between 5G slot granularity capable node and 25G 347 slot granularity node. 349 e. Configuration of unequipped instance, unavailable slots, which 350 include the number of unequipped instance and number of 351 unavailable slots on each instances 353 f. An interface needs to be defined for a FlexE client in the case 354 that an Ethernet PHY signal (e.g., 40GBASE-R) is directed towards 355 a FlexE client interface or delivered from one FlexE shim to 356 another in the case of equipment which terminates the FlexE 357 group. This interface is used to indicate the conversion of 358 Ethernet PHY signal to FlexE client signal, as only idle 359 insertion/deletion is performed during this process in the former 360 case, while in the latter case, this interface is used to 361 indicate the "switch" of FlexE client. 363 g. Different kinds of alarms should be taken into consideration when 364 modelling FlexE technology, which may include PHY failed, skew 365 exceed threshold, inconsistent configuration between two ends. 367 4. Summary 369 According to the analysis in section 2, the main control/management 370 requirement for FlexE technology is to configure the FlexE group and 371 FlexE client. Once a FlexE group is configured and the FlexE client 372 ports is created, slots allocation is configured, use of the FlexE 373 technology is the same as that in traditional Ethernet. 375 5. Acknowledgements 377 6. IANA Considerations 379 This memo includes no request to IANA. 381 7. Security Considerations 383 None. 385 8. References 387 8.1. Normative References 389 [ITU-T_G709] 390 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 391 07/2016", http://www.itu.int/rec/T-REC- 392 G..709-201606-P/en, July 2016. 394 [ITU-T_G798] 395 ITU-T, "ITU-T G.798: Characteristics of optical transport 396 network hierarchy equipment functional blocks", August 397 2018. 399 [ITU-T_G8023] 400 ITU-T, "ITU-T G.8023: Characteristics of equipment 401 functional blocks supporting Ethernet physical layer and 402 Flex Ethernet interfaces", , 2016. 404 [ITU-T_G872] 405 ITU-T, "ITU-T G.872: The Architecture of Optical Transport 406 Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en, 407 January 2017. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, 411 DOI 10.17487/RFC2119, March 1997, 412 . 414 8.2. Informative References 416 [I-D.izh-ccamp-flexe-fwk] 417 Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., 418 Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., 419 zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. 420 Zhong, "GMPLS Routing and Signaling Framework for Flexible 421 Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in 422 progress), October 2016. 424 [I-D.xiaobn-ccamp-flexe-yang-mod] 425 NIU, X., Wang, Q., Xu, Y., and S. Munagapati, "A YANG Data 426 Model for Flex Ethernet(FlexE)", draft-xiaobn-ccamp-flexe- 427 yang-mod-01 (work in progress), May 2019. 429 Authors' Addresses 431 Qilei Wang (editor) 432 ZTE Corporation 433 Nanjing 434 CN 436 Email: wang.qilei@zte.com.cn 438 Xiaobing Niu (editor) 439 ZTE Corporation 440 Beijing 441 CN 443 Email: niu.xiaobing@zte.com.cn 445 Yunbin Xu 446 CAICT 447 Beijing 448 CN 450 Email: xuyunbin@caict.ac.cn