Network Working Group Z. Du Internet-Draft M. Chen Intended status: Standards Track J. Dong Expires: January 9, 2017 Huawei July 8, 2016 Framework and GMPLS Extensions of Flexible Ethernet Channel draft-du-ccamp-flexe-channel-00 Abstract This document describes the use case of Flexible Ethernet (FlexE) in packet transport networks, especially using the end-to-end FlexE channel for the mobile transport scenario. The necessary GMPLS extensions for the end to end FlexE Channel are also specified. 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]. 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 http://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 January 9, 2017. Copyright Notice Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of Du, et al. Expires January 9, 2017 [Page 1] Internet-Draft FlexE Channel July 2016 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. FlexE Channel . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Ethernet Frame based Switching . . . . . . . . . . . . . 4 2.2. Time Slot based Switching . . . . . . . . . . . . . . . . 4 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. GMPLS Extensions for FlexE Channel . . . . . . . . . . . . . 5 4.1. Generalized Label Request . . . . . . . . . . . . . . . . 5 4.1.1. LSP Encoding Type . . . . . . . . . . . . . . . . . . 5 4.1.2. Switching Type . . . . . . . . . . . . . . . . . . . 5 4.1.3. Generalized-PID (G-PID) . . . . . . . . . . . . . . . 5 4.2. Traffic Parameters . . . . . . . . . . . . . . . . . . . 6 4.3. FlexE Channel Label . . . . . . . . . . . . . . . . . . . 6 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Routing Extensions for FlexE Channel . . . . . . . . . . . . 8 6.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Flexible Ethernet (FlexE) as defined in [FlexE] can provide complete decoupling of the MAC data rates and the rates of Ethernet PHY(s). FlexE defines Mux and Demux functions to transport traffic of FlexE clients over shared physical links. The FlexE Mux creates a logically serial stream of 66B blocks by interleaving FlexE clients according to a calendar of length 20n slots for a FlexE group composed of n 100 GBASE-R PHYs. Each slot corresponds to 5G of bandwidth. A FlexE client is assigned a number of slots according to its bandwidth divided by 5G. The FlexE Demux operates on a sequence of 66B blocks received from each PHY of the FlexE group. The PHYs of the FlexE group are re-interleaved so that FlexE clients can be recovered. FlexE has three main capabilities: Du, et al. Expires January 9, 2017 [Page 2] Internet-Draft FlexE Channel July 2016 o Bonding Ethernet PHYs: FlexE allows bonding multiple Ethernet PHYs as a larger pipe to carry a FlexE data flow. o Sub-rating of Ethernet PHYs. o Channelization. FlexE allows several data flows be carried over a single Ethernet PHY or a group of bonded PHYs, with the MAC rate of each flow be mapped to a FlexE channel. With the above capabilities, FlexE can be used to provide different services with guaranteed bandwidth, deterministic performance and security on the common physical interfaces. Currently FlexE is used as a link layer technology, while in some cases, such as mobile transport network and enterprise VPN network which have high bandwidth and Quality of Service (QoS) requirements, it is desirable that such capability could be extended to the network level. This document describes the use case of FlexE in packet transport network. The necessary GMPLS extensions for the end to end FlexE connection/path are also specified. 2. FlexE Channel FlexE as defined in [FlexE] is essentially a link layer technology which can provide the features like PHY bonding, sub-rating and channelization on one hop link between two FlexE capable nodes. In order to extend the applicability of FlexE to more scenarios such as mobile transport and enterprise leased line, there is a proposal in OIF to define FlexE 2.0 [FlexE2.0], which could provide multi-hop FlexE connections in the network. Such connection is called a FlexE channel. A FlexE channel is composed of a series of time slots of consecutive FlexE capable links. FlexE channel can provide end-to-end guaranteed bandwidth, deterministic performance and security for a particular service through the network shared by various services. FlexE Channel ........................................ +-----+ +-----+ +-----+ +-----+ +-----+ | N1 +===+ N2 +===+ N3 +===+ N4 +===+ N5 | +-----+ +-----+ +-----+ +-----+ +-----+ === FlexE Group ... FlexE Channel Figure 1: FlexE Channel Du, et al. Expires January 9, 2017 [Page 3] Internet-Draft FlexE Channel July 2016 This document introduces two alternative FlexE channel switching modes: Ethernet Frame based Switching and Time Slot based Switching. 2.1. Ethernet Frame based Switching In this mode, each node will perform FlexE Mux and Demux operations. It means a serial stream of FlexE 66B blocks will be recovered to Ethernet frames on receipt, and if the Ethernet Frames need to be transmitted over another FlexE group, the Ethernet frames will be cut into a serial stream of 66B blocks again and the blocks are muxed according to the calendar of the FlexE group, then sent to the next hop. 2.2. Time Slot based Switching In this mode, the intermediate nodes do not need to recover the received FlexE blocks to Ethernet frames, the blocks will be switched according to the mapping between the inbound and outbound calendars directly. With this mode, the overhead of Mux and Demux can be reduced, the processing latency of intermediate nodes could be reduced accordingly. 3. Use Case This section describes a typical use case of FlexE channel. <---------------FlexE Channel----------> ........................................ +-----+ +-----+ +-----+ +-----+ +-----+ | AN1 +===+ EN1 +===+ N1 +===+ EN2 +===+ AN2 | +-----+ +--\--+ +-----+ +--/--+ +-----+ \ / \\ +-----+ // \=+ N2 +=/ +-----+ Figure 2. FlexE Channel Use Case As shown in Figure 2, the AN nodes, EN nodes and N nodes constitute a mobile transport network, which provides various services with different bandwidth and QoS requirements. If the links along the path from AN1 to AN2 are all FlexE capable, an end-to-end FlexE channel can be established between AN1 and AN2, which could provide guaranteed bandwidth, deterministic latency and other QoS for a particular service through the network. Du, et al. Expires January 9, 2017 [Page 4] Internet-Draft FlexE Channel July 2016 Since each FlexE channel has its own dedicated resources and can provide deterministic performance, it can be a good candidate of implementing network slicing in packet transport network. 4. GMPLS Extensions for FlexE Channel In order to establish an end-to-end FlexE channel, some extensions to GMPLS protocols are needed. This section specifies the necessary extensions for FlexE channel. 4.1. Generalized Label Request 4.1.1. LSP Encoding Type LSP Encoding Type [RFC3471] indicates the encoding of the LSP being requested. An additional LSP Encoding Type code-point for the FlexE is defined in this document. Value Type ----- ----- TBD1 FlexE 4.1.2. Switching Type The Switching Type indicates the type of switching that should be performed at the termination of a particular link. As described in Section 2, FlexE channel can support two switching modes. For the Ethernet Frame based switching, existing switching type L2SC as defined in [RFC4202] can be reused. To support FlexE Time Slot based switching, a new switching type is defined in this document. Value Type ----- -------------------------- TBD2 FlexE Time Slot Switching 4.1.3. Generalized-PID (G-PID) The G-PID, as defined in [RFC3471], identifies the payload carried by an LSP. This document defines a new G-PID to indicate the payload carried by a FlexE Channel. Value Type Technology ----- ---------------- ---------- TBD3 64B/66B FlexE FlexE Du, et al. Expires January 9, 2017 [Page 5] Internet-Draft FlexE Channel July 2016 4.2. Traffic Parameters To carry the traffic parameters for FlexE switching type, two new objects are defined as follows: FLEXE SENDER_TSPEC object : Class = 12, C-Type = TBD4; FLEXE FLOWSPEC object : Class = 9, C-Type = TBD4; The FLEXE SENDER_TSPEC object is carried in the Path message, and the FLEXE FLOWSPEC object is carried in the Resv message. The FLEXE SENDER_TSPEC object and the FLEXE FLOWSPEC object have the same format. The format of the FlexE traffic parameters is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Number of Slots | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Traffic Parameters for FlexE The Signal Type (8 bits) indicates the type of FlexE signal. Currently, only one type "5G slot" is defined according to [FlexE]: Value Type ----- ------- TBD5 5G slot The Number of Slots field (16 bits) indicates how many slots are requested for the FlexE channel. 4.3. FlexE Channel Label This section describes the Generalized Label value space for FlexE Channel. The Generalized Label is defined in [RFC3471]. The format of the corresponding RSVP-TE GENERALIZED_LABEL object is specified in [RFC3473]. The FlexE label has the following format: Du, et al. Expires January 9, 2017 [Page 6] Internet-Draft FlexE Channel July 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlexE Group number | Number of PHY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHY Number1 | Bit Map Length| Bitmap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Bit Map (continued) ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+ | .... | Padding Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHY Number2 | Bit Map Length| Bitmap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Bit Map (continued) ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+ | .... | Padding Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ....... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: FlexE Label The FlexE Group number (20 bits) defined in [FlexE] is a unique identifier of a FlexE Group on a FlexE node. The Number of PHY (12 bits) indicates the number of physical links in the FlexE Group. Length (16 bits) indicates the total length of the whole FlexE label. PHY Number (8 bits) is an identifier of a specific physical link, it is unique on a FlexE node. Bitmap length (8 bits) indicates the length of the followed bitmap field. Bitmap (variable) indicates which slots in the physical link are allocated to a FlexE channel. When a bit is set, it means that the corresponding slot is used by the FlexE channel. Padding Bits are added after the bitmap to make the whole label a multiple of four bytes if necessary. Padding bits MUST be set to 0 when sending and MUST be ignored on receipt. Du, et al. Expires January 9, 2017 [Page 7] Internet-Draft FlexE Channel July 2016 5. Procedures The ingress node MUST generate a Path message and specify the Encoding type, Switching Type, and corresponding G-PID of a FlexE channel in the GENERALIZED_LABEL_REQUEST object, which MUST be processed as defined in [RFC3473]. When a downstream node or egress node receives a Path message containing a GENERALIZED_LABEL_REQUEST object for setting up a FlexE channel from its upstream neighbor node, the node MUST generate a FlexE label according to the traffic parameters of the requested channel and the available resources (i.e., available slots of the FlexE Group) that will be reserved for the channel and send the label to its upstream neighbor node. 6. Routing Extensions for FlexE Channel In order to establish a multi-hop FlexE channel, the FlexE capability and the related resources of the nodes and links in the network need to be collected. Basically, the needed information for FlexE channel is: o FlexE switching capability o FlexE switching modes o FlexE switching granularity (e.g., 5G per slot) o The total/allocated/available time slots of each FlexE Group o Node/Interface Latency o The subsequent sections specifies the IGP and BGP-LS extensions respectively for the collection of FlexE related information. 6.1. IGP TBD. 6.2. BGP-LS TBD. Du, et al. Expires January 9, 2017 [Page 8] Internet-Draft FlexE Channel July 2016 7. IANA Considerations TBD. 8. Security Considerations TBD. 9. Normative References [FlexE] OIF, "Flex Ethernet Implementation Agreement Version 1.0 (OIF-FLEXE-01.0)", March 2016. [FlexE2.0] Huawei, "Next Generation FlexE 2.0 Considerations", March 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, . [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, . [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, . Authors' Addresses Zongpeng Du Huawei Email: duzongpeng@huawei.com Du, et al. Expires January 9, 2017 [Page 9] Internet-Draft FlexE Channel July 2016 Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Jie Dong Huawei Email: jie.dong@huawei.com Du, et al. Expires January 9, 2017 [Page 10]