idnits 2.17.1 draft-wang-ccamp-flexe-control-analysis-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (March 11, 2019) is 1872 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 357, 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 193, but not defined == Missing Reference: 'RFC6002' is mentioned on line 349, but not defined == Unused Reference: 'I-D.izh-ccamp-flexe-fwk' is defined on line 420, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-izh-ccamp-flexe-fwk-00 Summary: 1 error (**), 0 flaws (~~), 9 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: September 12, 2019 Y. Xu 6 CAICT 7 March 11, 2019 9 Analysis for FlexE control model 10 draft-wang-ccamp-flexe-control-analysis-00 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 September 12, 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 . . . . . . . . . . . . . . . . . . . . 3 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 of FlexE group . . . . . . . . . . . . 5 63 3.2.2. Allocate Resources for Client MAC flows . . . . . . . 6 64 3.3. FlexE Client Configuration Procedures . . . . . . . . . . 6 65 3.4. Control Requirements Derived . . . . . . . . . . . . . . 8 66 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 8.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 architecture should we employed when configuring FlexE equipments, 88 how to configure the FlexE group and FlexE client, and what kind of 89 parameters do we need to take into consideration? The analysis is 90 mainly based on the description in section 7 and 8 of [ITU-T G.8023], 91 which is "Characteristics of equipment functional blocks supporting 92 Flex Ethernet interfaces". 94 2. Terminology 96 2.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 3. Analysis 104 3.1. General Introduction of FlexE 106 The FlexE shim is built into the Ethernet PCS (physical coding 107 sublayer). If a FlexE group is set up, a corresponding n*100G (or 108 n*200G, n*400G) PCS module is 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. 116 3.1.1. FlexE Group 118 A FlexE Group is consisted of 1 to m bonded Ethernet PHYs. The rate 119 of the Ethernet PHY could be 100G, 200G or 400G. All PHYs in the 120 group must operate at the same rate. 122 FlexE group is consisted of a number of PHYs, and each PHY is 123 consisted of 66B blocks stream. Section monitoring overhead is 124 added/extracted as one 66B block at the FlexE group source and 125 destination (i.e., trail termination) to determine the status of the 126 FlexE group (i.e., FlexE trail). Currently, only RPF (Remote PHY 127 Fault) indication is used to report the state of FlexE group. 129 One FlexE group exists between two FlexE shim, there is no switching 130 defined in FlexE. In addition, only one fault indication is defined, 131 there is no other OAM function developed yet. Based on these 132 analysis, we may understand FlexE is just an interface technology, 133 and once a FlexE group is configured, it only functions as one 134 Ethernet link, same as Ethernet PHY. 136 3.1.2. FlexE Client 138 A FlexE Client is an Ethernet flow based on a MAC data rate that may 139 or may not correspond to any Ethernet PHY rate. The FlexE Client MAC 140 rates supported by a FlexE Groups could be 10, 40, and m*25 Gb/s. 141 The FlexE Client MAC rates supported by FlexE Groups may support all, 142 or only a subset of these FlexE Client rates, e.g., m*25 Gb/s. Each 143 FlexE Client is presented to the FlexE Shim as a 64B/66B encoded bit- 144 stream according to clause 82 of [IEEE 802.3]. 146 According to the description in clause 8.1 of [ITU-T G.8023], there 147 is no overhead defined for monitoring a FlexE client, so the trail 148 for FlexE client in the equipment does not exist. The FlexE client 149 trail termination function is a null function. Therefore, there is 150 no need to model FlexE client as a layer. 152 3.1.3. Adaptation function between FlexE Client and FlexE Group 154 In order to distribute the FlexE client over PHYs of one FlexE group, 155 a number of management information command should be sent to the 156 adaptation function which performs the mapping of FlexE client over 157 FlexE group. 159 According to the description in clause 7.2 of [ITU-T G.8023], the 160 external management information command sent to the source adaptation 161 function is listed below: 163 TxCC, TxCCA, TxCCB, TxCR, TxCA 165 TxGID, TxPHYMAP 167 The TxCC, TxCCA and TxCCB are used to configure the calendar for use, 168 which could be type A or type B calendar configuration, and FlexE 169 client number. 171 TxCR and TxCA are used to coordinate the switch of calendar 172 configuration between the FlexE source and destination node. 174 The TxGID is used to configure the FlexE group identifier. The 175 TxPHYMAP is used to configure the set of PHYs in the FlexE group. 177 The built-in function multiplexer performs the action of assigning 178 the individual FlexE Client to specific calendar slots of the FlexE 179 group. 181 At the destination side, the overhead should be extracted first to 182 compare the GID and PID. The Demultiplexer function activates the 183 FlexE Client and assigns the calendar slots of the FlexE group 184 payload area to the individual FlexE client as defined by the client 185 calendar information carried in the overhead. 187 3.1.4. MAC Frame 189 Defined in IEEE. 191 3.1.5. Adaptation between MAC frames and FlexE Client 193 It can be seen from the Figure 8-6 of [ITU-T G.8023] that the 194 external management information commands used as input to the 195 adaptation function are defined by [IEEE 802.3]. The [IEEE 802.3] 196 process mainly includes the 64B/66B encoding, as well as MAC frame 197 check sequence generation and frame counting. The FlexE client 198 stream is generated at the determined FlexE Client MAC rate and 199 64B/66B encoded. 201 3.2. General requirements 203 It can be inferred from section 2.1.2 and section 2.1.5 that process 204 mainly involved when producing the FlexE Client from MAC frames is 205 64b/66b encoding, and this encoding has already been defined by [IEEE 206 802.3]. No extra overhead is added. Therefore, configuration for 207 FlexE client layer is needed. Based on the above analysis, two 208 general requirements for control/management of FlexE are considered 209 in this draft. 211 Configuration of FlexE group 213 Allocation of one or more FlexE group calendar slot resources to a 214 client MAC flow. 216 3.2.1. Configuration of FlexE group 218 It can be concluded from the above analysis that external 219 configuration tools should be involved to bring one FlexE group into 220 service. The initial configuration commands can come from external 221 management system, SDN controller etc. 223 A FlexE group must be configured first before any client signals are 224 carried over it. When a new FlexE Group is brought into service, the 225 initial configuration must be provisioned from both ends, and the 226 initial configuration must be the same. The group is configured to 227 consist of from 1 to n 100G FlexE Instances carried over from 1 to m 228 PHYs of the same rate (100GBASE-R, 200GBASE-R, or 400GBASE-R). Each 229 PHY tunnel may consist of multiple hops. 231 3.2.2. Allocate Resources for Client MAC flows 233 The FlexE client MAC flows are encapsulated in one or more FlexE 234 calendar slots. Questions that may be raised when considering 235 whether external control/management tools are needed. 237 How is the bandwidth (number of calendar slots) allocated to a MAC 238 client? 240 How are the calendar slots assigned to each FlexE clients? 242 Does the external management/control system need to be involved? 244 According to the analysis in section 2.1.3, it can be inferred that 245 the built-in multiplexer and demultiplexer function can work together 246 to insert/extract FlexE Client stream from some calendar slots 247 correctly, as well as the trail termination function for FlexE client 248 is a null function. Therefore, only the bandwidth information of the 249 FlexE Client is needed, the number of calendar slots required can be 250 derived from the bandwidth information. 252 The FlexE client physical port is an internal port which only perform 253 the function of encapsulating upper layer packets into MAC frames, 254 64b/66b encoding. The bandwidth capability of these internal ports 255 should be known by external management/control tools in order to 256 multiplex and demultiplex the upper layer flow correctly. 258 3.3. FlexE Client Configuration Procedures 260 Example below is depicted to set up a 25G MPLS-TP P2P path (from 261 MPLS-TP-1 to MPLS-TP-2) over one FlexE link[two FlexE Groups] between 262 Route-1 and Router-2. This is to help understand why control of 263 FlexE client is not needed. FlexE group is assumed configured in 264 this case. 266 ================================================================== 268 MPLS-TP-1 269 +-----+ MPLS-TP-2 270 | | +-----+ 271 | | XXXXXX | | 272 +-----+ XXXX XXXXXX | | 273 | X XXXX +-----+ 274 | OTN X XX OTN | 275 +-+-----+ +-----+X X+-----+ +-----+-+ 276 | +---+ +----------------------+ +----+ | 277 | +---+ +----------------------+ +----+ | 278 +-----+ +-----+ XX X +-----+ +-----+ 279 Router-1 XXX XXX Router-2 280 XXXXXX XXXX XX 282 ================================================================== 284 Figure 1: Network Scenario 286 Configuration needed for each node when setting up MPLS-TP path: 288 Outgoing MPLS label and output port, 25G --> MPLS-TP-1; 290 Incoming MPLS label and input port, 25G --> Router-1; 292 MPLS traffic over FlexE link, from Router-1 to Router-2; 294 Outgoing MPLS label and outgoing port, 25G --> Routing-2; 296 Incoming label and input port, 25G --> MPLS-TP-2 298 What else would be done by Router-1 and Router-2 if we want to put 299 MPLS packets over FlexE link? 301 Router-1, perform the generally used data link (i.e., MAC) 302 encapsulation procedures to transmit the packet to next hop Router-2, 303 which includes: 305 encapsulation of the packets into MAC frames. The source and 306 destination MAC address can be derived by searching Router-1's 307 internal mapping table, i.e., (outgoing label, outgoing port, MAC 308 address) table, then do the 64b/66b encoding for these MAC frames. 310 in addition, Router-1 would announce the required bandwidth 311 required from Router-1 to Router-2 to local FlexE multiplexer, the 312 local FlexE multiplexer then allocates 5*5G calendar slots to the 313 MPLS-TP client signal, and insert FlexE overhead onto each PHY. 315 Router-1's configuration is finished. 317 Router-2's configuration would be different, as its function is to 318 extract the FlexE client signal from the calendar slots according to 319 the information carried in the FlexE overhead and route the packets 320 based on the MPLS label. As there is no switching of calendar slots 321 in FlexE, the calendar slots allocated to certain client signal would 322 not change. 324 It can be inferred from the above procedures that the configuration 325 of a MPLS client is not impacted by the use of FlexE comparing to 326 traditional Ethernet. 328 3.4. Control Requirements Derived 330 a. Using control plane method to configure FlexE group, which may 331 include the configuration of group number, PHY number and 332 correlation between logical PHY number and physical port number. 334 b. Configuration of "logical" PHY, which includes initial 335 configuration of bandwidth (number of calendar slots); change of 336 bandwidth while in service. 338 c. External control command should be provide to trigger the switch 339 of calendar slots. 341 d. Interworking between 5G slot granularity capable node and 25G 342 slot granularity node. 344 e. Configuration of aware case. As calendar slots is not visible to 345 external management/control tools. Bandwidth information of the 346 Ethernet PHYs selected can be used to infer the unavailable slot 347 information, as the unavailable slots are placed at the end of 348 each relevant sub-calendar (the highest numbered slots). 349 [RFC6002] defines a new switching type DCSC (Data Channel 350 Switching Capable) to describe the switching of whole digital 351 channel presented on single channel interface, which can describe 352 the Ethernet terminated at the physical (port) level and all 353 traffic received on a port is switched to a physical port at the 354 LSP egress. The FlexE digital channel presented at each PHY 355 interface can be described with DCSC switching type. However, 356 FlexE aware case may not be depicted with DCSC, as described in 357 section 17.12 of [ITU-T G.709], each FlexE (sub) groups (i.e., 358 each 100G FlexE signals) are crunched, padded and interleaved in 359 FlexE, the bandwidth of digital channel links presented in one 360 tunnel may varies. Therefore, a new switching type DCSC-flexe is 361 needed in aware case to depict the end-to-end tunnel with 362 bandwidth varies at each digital channel links. The 363 configuration of FlexE instance and unavailable slot information 364 can be derived through the bandwidth of each hop. 366 Different kinds of alarms should be taken into consideration when 367 modelling FlexE technology, which may include PHY failed, skew exceed 368 threshold, inconsistent configuration between two ends. 370 4. Summary 372 According to the analysis in section 2, the main control/management 373 requirement for FlexE technology is to configure the FlexE group. 374 Once a FlexE group is configured and the capability information of 375 the internal FlexE client ports associated with this FlexE group is 376 known, use of the FlexE technology is the same as that in traditional 377 Ethernet. 379 5. Acknowledgements 381 6. IANA Considerations 383 This memo includes no request to IANA. 385 7. Security Considerations 387 None. 389 8. References 391 8.1. Normative References 393 [ITU-T_G709] 394 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 395 07/2016", http://www.itu.int/rec/T-REC- 396 G..709-201606-P/en, July 2016. 398 [ITU-T_G798] 399 ITU-T, "ITU-T G.798: Characteristics of optical transport 400 network hierarchy equipment functional blocks", August 401 2018. 403 [ITU-T_G8023] 404 ITU-T, "ITU-T G.8023: Characteristics of equipment 405 functional blocks supporting Ethernet physical layer and 406 Flex Ethernet interfaces", , 2016. 408 [ITU-T_G872] 409 ITU-T, "ITU-T G.872: The Architecture of Optical Transport 410 Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en, 411 January 2017. 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 8.2. Informative References 420 [I-D.izh-ccamp-flexe-fwk] 421 Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., 422 Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., 423 zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. 424 Zhong, "GMPLS Routing and Signaling Framework for Flexible 425 Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in 426 progress), October 2016. 428 Authors' Addresses 430 Qilei Wang (editor) 431 ZTE Corporation 432 Nanjing 433 CN 435 Email: wang.qilei@zte.com.cn 437 Xiaobing Niu (editor) 438 ZTE Corporation 439 Beijing 440 CN 442 Email: niu.xiaobing@zte.com.cn 443 Yunbin Xu 444 CAICT 445 Beijing 446 CN 448 Email: xuyunbin@caict.ac.cn