Internet Engineering Task Force Q. Wang, Ed. Internet-Draft X. Niu, Ed. Intended status: Informational ZTE Corporation Expires: September 12, 2019 Y. Xu CAICT March 11, 2019 Analysis for FlexE control model draft-wang-ccamp-flexe-control-analysis-00 Abstract This document gives some analysis about the control of FlexE. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 12, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Wang, et al. Expires September 12, 2019 [Page 1] Internet-Draft FlexE control March 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General Introduction of FlexE . . . . . . . . . . . . . . 3 3.1.1. FlexE Group . . . . . . . . . . . . . . . . . . . . . 3 3.1.2. FlexE Client . . . . . . . . . . . . . . . . . . . . 3 3.1.3. Adaptation function between FlexE Client and FlexE Group . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.4. MAC Frame . . . . . . . . . . . . . . . . . . . . . . 5 3.1.5. Adaptation between MAC frames and FlexE Client . . . 5 3.2. General requirements . . . . . . . . . . . . . . . . . . 5 3.2.1. Configuration of FlexE group . . . . . . . . . . . . 5 3.2.2. Allocate Resources for Client MAC flows . . . . . . . 6 3.3. FlexE Client Configuration Procedures . . . . . . . . . . 6 3.4. Control Requirements Derived . . . . . . . . . . . . . . 8 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction OIF published the first version of FlexE Implementation Agreement in March 2016, aiming to provide a generic mechanism for supporting a variety of Ethernet MAC rates that may or may not correspond to any existing Ethernet PHY rate. SG15 in ITU-T has endorsed the OIF FlexE data plane and parts of [ITU-T G.872], [ITU-T G.709], [ITU-T G.798] and [ITU-T G.8023]. The Recommendations depend on or are based on the FlexE data plane. This draft is intended to trigger discussion of the FlexE control architecture according to the analysis in section 2. What kind of architecture should we employed when configuring FlexE equipments, how to configure the FlexE group and FlexE client, and what kind of parameters do we need to take into consideration? The analysis is mainly based on the description in section 7 and 8 of [ITU-T G.8023], which is "Characteristics of equipment functional blocks supporting Flex Ethernet interfaces". Wang, et al. Expires September 12, 2019 [Page 2] Internet-Draft FlexE control March 2019 2. Terminology 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Analysis 3.1. General Introduction of FlexE The FlexE shim is built into the Ethernet PCS (physical coding sublayer). If a FlexE group is set up, a corresponding n*100G (or n*200G, n*400G) PCS module is created as well. The difference between the FlexE and the traditional 100G Ethernet is that the traditional Ethernet PCS has a 1:1 relationship with the client MAC flow, while with FlexE one bonded huge PCS module can be used to transport more than one client MAC flow i.e., the relationship is 1:n. 3.1.1. FlexE Group A FlexE Group is consisted of 1 to m bonded Ethernet PHYs. The rate of the Ethernet PHY could be 100G, 200G or 400G. All PHYs in the group must operate at the same rate. FlexE group is consisted of a number of PHYs, and each PHY is consisted of 66B blocks stream. Section monitoring overhead is added/extracted as one 66B block at the FlexE group source and destination (i.e., trail termination) to determine the status of the FlexE group (i.e., FlexE trail). Currently, only RPF (Remote PHY Fault) indication is used to report the state of FlexE group. One FlexE group exists between two FlexE shim, there is no switching defined in FlexE. In addition, only one fault indication is defined, there is no other OAM function developed yet. Based on these analysis, we may understand FlexE is just an interface technology, and once a FlexE group is configured, it only functions as one Ethernet link, same as Ethernet PHY. 3.1.2. FlexE Client A FlexE Client is an Ethernet flow based on a MAC data rate that may or may not correspond to any Ethernet PHY rate. The FlexE Client MAC rates supported by a FlexE Groups could be 10, 40, and m*25 Gb/s. The FlexE Client MAC rates supported by FlexE Groups may support all, Wang, et al. Expires September 12, 2019 [Page 3] Internet-Draft FlexE control March 2019 or only a subset of these FlexE Client rates, e.g., m*25 Gb/s. Each FlexE Client is presented to the FlexE Shim as a 64B/66B encoded bit- stream according to clause 82 of [IEEE 802.3]. According to the description in clause 8.1 of [ITU-T G.8023], there is no overhead defined for monitoring a FlexE client, so the trail for FlexE client in the equipment does not exist. The FlexE client trail termination function is a null function. Therefore, there is no need to model FlexE client as a layer. 3.1.3. Adaptation function between FlexE Client and FlexE Group In order to distribute the FlexE client over PHYs of one FlexE group, a number of management information command should be sent to the adaptation function which performs the mapping of FlexE client over FlexE group. According to the description in clause 7.2 of [ITU-T G.8023], the external management information command sent to the source adaptation function is listed below: TxCC, TxCCA, TxCCB, TxCR, TxCA TxGID, TxPHYMAP The TxCC, TxCCA and TxCCB are used to configure the calendar for use, which could be type A or type B calendar configuration, and FlexE client number. TxCR and TxCA are used to coordinate the switch of calendar configuration between the FlexE source and destination node. The TxGID is used to configure the FlexE group identifier. The TxPHYMAP is used to configure the set of PHYs in the FlexE group. The built-in function multiplexer performs the action of assigning the individual FlexE Client to specific calendar slots of the FlexE group. At the destination side, the overhead should be extracted first to compare the GID and PID. The Demultiplexer function activates the FlexE Client and assigns the calendar slots of the FlexE group payload area to the individual FlexE client as defined by the client calendar information carried in the overhead. Wang, et al. Expires September 12, 2019 [Page 4] Internet-Draft FlexE control March 2019 3.1.4. MAC Frame Defined in IEEE. 3.1.5. Adaptation between MAC frames and FlexE Client It can be seen from the Figure 8-6 of [ITU-T G.8023] that the external management information commands used as input to the adaptation function are defined by [IEEE 802.3]. The [IEEE 802.3] process mainly includes the 64B/66B encoding, as well as MAC frame check sequence generation and frame counting. The FlexE client stream is generated at the determined FlexE Client MAC rate and 64B/66B encoded. 3.2. General requirements It can be inferred from section 2.1.2 and section 2.1.5 that process mainly involved when producing the FlexE Client from MAC frames is 64b/66b encoding, and this encoding has already been defined by [IEEE 802.3]. No extra overhead is added. Therefore, configuration for FlexE client layer is needed. Based on the above analysis, two general requirements for control/management of FlexE are considered in this draft. Configuration of FlexE group Allocation of one or more FlexE group calendar slot resources to a client MAC flow. 3.2.1. Configuration of FlexE group It can be concluded from the above analysis that external configuration tools should be involved to bring one FlexE group into service. The initial configuration commands can come from external management system, SDN controller etc. A FlexE group must be configured first before any client signals are carried over it. When a new FlexE Group is brought into service, the initial configuration must be provisioned from both ends, and the initial configuration must be the same. The group is configured to consist of from 1 to n 100G FlexE Instances carried over from 1 to m PHYs of the same rate (100GBASE-R, 200GBASE-R, or 400GBASE-R). Each PHY tunnel may consist of multiple hops. Wang, et al. Expires September 12, 2019 [Page 5] Internet-Draft FlexE control March 2019 3.2.2. Allocate Resources for Client MAC flows The FlexE client MAC flows are encapsulated in one or more FlexE calendar slots. Questions that may be raised when considering whether external control/management tools are needed. How is the bandwidth (number of calendar slots) allocated to a MAC client? How are the calendar slots assigned to each FlexE clients? Does the external management/control system need to be involved? According to the analysis in section 2.1.3, it can be inferred that the built-in multiplexer and demultiplexer function can work together to insert/extract FlexE Client stream from some calendar slots correctly, as well as the trail termination function for FlexE client is a null function. Therefore, only the bandwidth information of the FlexE Client is needed, the number of calendar slots required can be derived from the bandwidth information. The FlexE client physical port is an internal port which only perform the function of encapsulating upper layer packets into MAC frames, 64b/66b encoding. The bandwidth capability of these internal ports should be known by external management/control tools in order to multiplex and demultiplex the upper layer flow correctly. 3.3. FlexE Client Configuration Procedures Example below is depicted to set up a 25G MPLS-TP P2P path (from MPLS-TP-1 to MPLS-TP-2) over one FlexE link[two FlexE Groups] between Route-1 and Router-2. This is to help understand why control of FlexE client is not needed. FlexE group is assumed configured in this case. Wang, et al. Expires September 12, 2019 [Page 6] Internet-Draft FlexE control March 2019 ================================================================== MPLS-TP-1 +-----+ MPLS-TP-2 | | +-----+ | | XXXXXX | | +-----+ XXXX XXXXXX | | | X XXXX +-----+ | OTN X XX OTN | +-+-----+ +-----+X X+-----+ +-----+-+ | +---+ +----------------------+ +----+ | | +---+ +----------------------+ +----+ | +-----+ +-----+ XX X +-----+ +-----+ Router-1 XXX XXX Router-2 XXXXXX XXXX XX ================================================================== Figure 1: Network Scenario Configuration needed for each node when setting up MPLS-TP path: Outgoing MPLS label and output port, 25G --> MPLS-TP-1; Incoming MPLS label and input port, 25G --> Router-1; MPLS traffic over FlexE link, from Router-1 to Router-2; Outgoing MPLS label and outgoing port, 25G --> Routing-2; Incoming label and input port, 25G --> MPLS-TP-2 What else would be done by Router-1 and Router-2 if we want to put MPLS packets over FlexE link? Router-1, perform the generally used data link (i.e., MAC) encapsulation procedures to transmit the packet to next hop Router-2, which includes: encapsulation of the packets into MAC frames. The source and destination MAC address can be derived by searching Router-1's internal mapping table, i.e., (outgoing label, outgoing port, MAC address) table, then do the 64b/66b encoding for these MAC frames. Wang, et al. Expires September 12, 2019 [Page 7] Internet-Draft FlexE control March 2019 in addition, Router-1 would announce the required bandwidth required from Router-1 to Router-2 to local FlexE multiplexer, the local FlexE multiplexer then allocates 5*5G calendar slots to the MPLS-TP client signal, and insert FlexE overhead onto each PHY. Router-1's configuration is finished. Router-2's configuration would be different, as its function is to extract the FlexE client signal from the calendar slots according to the information carried in the FlexE overhead and route the packets based on the MPLS label. As there is no switching of calendar slots in FlexE, the calendar slots allocated to certain client signal would not change. It can be inferred from the above procedures that the configuration of a MPLS client is not impacted by the use of FlexE comparing to traditional Ethernet. 3.4. Control Requirements Derived a. Using control plane method to configure FlexE group, which may include the configuration of group number, PHY number and correlation between logical PHY number and physical port number. b. Configuration of "logical" PHY, which includes initial configuration of bandwidth (number of calendar slots); change of bandwidth while in service. c. External control command should be provide to trigger the switch of calendar slots. d. Interworking between 5G slot granularity capable node and 25G slot granularity node. e. Configuration of aware case. As calendar slots is not visible to external management/control tools. Bandwidth information of the Ethernet PHYs selected can be used to infer the unavailable slot information, as the unavailable slots are placed at the end of each relevant sub-calendar (the highest numbered slots). [RFC6002] defines a new switching type DCSC (Data Channel Switching Capable) to describe the switching of whole digital channel presented on single channel interface, which can describe the Ethernet terminated at the physical (port) level and all traffic received on a port is switched to a physical port at the LSP egress. The FlexE digital channel presented at each PHY interface can be described with DCSC switching type. However, FlexE aware case may not be depicted with DCSC, as described in section 17.12 of [ITU-T G.709], each FlexE (sub) groups (i.e., Wang, et al. Expires September 12, 2019 [Page 8] Internet-Draft FlexE control March 2019 each 100G FlexE signals) are crunched, padded and interleaved in FlexE, the bandwidth of digital channel links presented in one tunnel may varies. Therefore, a new switching type DCSC-flexe is needed in aware case to depict the end-to-end tunnel with bandwidth varies at each digital channel links. The configuration of FlexE instance and unavailable slot information can be derived through the bandwidth of each hop. Different kinds of alarms should be taken into consideration when modelling FlexE technology, which may include PHY failed, skew exceed threshold, inconsistent configuration between two ends. 4. Summary According to the analysis in section 2, the main control/management requirement for FlexE technology is to configure the FlexE group. Once a FlexE group is configured and the capability information of the internal FlexE client ports associated with this FlexE group is known, use of the FlexE technology is the same as that in traditional Ethernet. 5. Acknowledgements 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations None. 8. References 8.1. Normative References [ITU-T_G709] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 07/2016", http://www.itu.int/rec/T-REC- G..709-201606-P/en, July 2016. [ITU-T_G798] ITU-T, "ITU-T G.798: Characteristics of optical transport network hierarchy equipment functional blocks", August 2018. Wang, et al. Expires September 12, 2019 [Page 9] Internet-Draft FlexE control March 2019 [ITU-T_G8023] ITU-T, "ITU-T G.8023: Characteristics of equipment functional blocks supporting Ethernet physical layer and Flex Ethernet interfaces", , 2016. [ITU-T_G872] ITU-T, "ITU-T G.872: The Architecture of Optical Transport Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en, January 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [I-D.izh-ccamp-flexe-fwk] Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. Zhong, "GMPLS Routing and Signaling Framework for Flexible Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in progress), October 2016. Authors' Addresses Qilei Wang (editor) ZTE Corporation Nanjing CN Email: wang.qilei@zte.com.cn Xiaobing Niu (editor) ZTE Corporation Beijing CN Email: niu.xiaobing@zte.com.cn Wang, et al. Expires September 12, 2019 [Page 10] Internet-Draft FlexE control March 2019 Yunbin Xu CAICT Beijing CN Email: xuyunbin@caict.ac.cn Wang, et al. Expires September 12, 2019 [Page 11]