Internet Engineering Task Force J. Huang, Ed. Internet-Draft Q. Zhong Intended status: Informational Huawei Expires: March 4, 2017 August 31, 2016 Framework and Requirements for GMPLS-based Control of Flexible Ethernet Network draft-huang-flexe-framework-00 Abstract This memo provides some background information of Flexible Ethernet (FlexE), and explain some terminologies and use cases, further derives the requirements to the GMPLS based control plane. 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 March 4, 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 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. Huang & Zhong Expires March 4, 2017 [Page 1] Internet-Draft FlexE Framework August 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Concept and Terminology . . . . . . . . . . . . . . . . . . . 2 2.1. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. FlexE Related Network Use cases . . . . . . . . . . . . . . . 5 3.1. Brief . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. FlexE Unaware Transport . . . . . . . . . . . . . . . . . 7 3.3. FlexE Aware Transport . . . . . . . . . . . . . . . . . . 8 3.4. FlexE Client Transport . . . . . . . . . . . . . . . . . 10 3.5. FlexE Client Routing and Transport . . . . . . . . . . . 11 4. GMPLS Extension Requirements . . . . . . . . . . . . . . . . 13 4.1. Generic . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. FlexE Unaware Transport . . . . . . . . . . . . . . . . . 14 4.3. FlexE Aware Transport . . . . . . . . . . . . . . . . . . 15 4.4. FlexE Client Transport . . . . . . . . . . . . . . . . . 15 4.5. FlexE Client Routing and Transport . . . . . . . . . . . 16 5. Routing Extension Requirements . . . . . . . . . . . . . . . 16 6. Signaling Extension Requirements . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction 1.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] . 2. Concept and Terminology 2.1. Concept Ethernet starts from 10M, then evolves to 100M, 1000M, 10G, etc. As the line rate goes higher, it is more and more difficult for manufacturing technology to support this 10-times-based evolution, and also it takes more time to develop new standard. For example, IEEE started standardization work on 100G Ethernet in December, 2007, and actually the initial discussion on this started about two year earlier, finished the first part of 100G standard in 802.3ba in June, Huang & Zhong Expires March 4, 2017 [Page 2] Internet-Draft FlexE Framework August 2016 2010. As of today, it is almost 10 years since the beginning, the work on 100G for more models is still ongoing. The work on 400G Ethernet started from March, 2013, and it is expected to be finished by the end of 2017 which can covver a distance of 10km. It will take some more years before the 400G module is commonly available at a reasonable price in the market. There is no consensus yet what is going to be the next beyond, 800G or 1T. If operators want to use the next generation higher speed Ethernet interface, e.g. for Inter-DC connections where high speed interfaces are desired due to large traffic volume and rapid increase of traffic, they will need to wait for some years for the new interface modules . A possible mitigation is to use some bonding technology, such as 802.1AX link aggregation, but with the hash issue -- traffic may not be evenly distributed over multiple links. FlexE is a good solution for this problem, traffic is distributed over multiple physical links by 64/66B blocks in a round-robin manner. This is one of the key reasons that FlexE is invented. Besides bonding, FlexE also provides sub rate and channelization capability. In FlexE, a 100G physical link can be divided into 20 slots, and each slot is 5G. A subset of these 20 slots can be grouped together and provide a virtual link with bandwidth of 5G*N. FlexE also allows slots over multiple physical links be grouped together and provide bandwidth which is not integral multiple of a physical link, such as 150G bandwidth over two 100G physical links. This is called as channelization. 2.2. Terminology o FlexE Group FlexE Group is a set of physical links which can be bonded together between two network devices. A FlexE group can have minimally one, and up to 254 physical links. .The links may be between two adjacent network devices, or be connected over transport network. If links are connected by transport network, for the purpose of skew control, FlexE traffic over different physical links should traverse through same route in the transport network. In some cases, links between two adjacent network devices cannot be added into a same FlexE group due to some constraints, such as the links spread across multiple line cards where skew may be a problem. FlexE group may be created automatically via signaling, which is not yet covered by the FlexE specification. The maintenance of FlexE Group, add / remove PHYs, may also be automated which requires further study. Huang & Zhong Expires March 4, 2017 [Page 3] Internet-Draft FlexE Framework August 2016 o FlexE Group ID There can be multiple FlexE groups in a network device. In order to distinguish these groups, a FlexE Group ID, 20bits in length in [FlexE1.0], is assigned for each FlexE group. FlexE Group ID is carried in the overhead over each physical link in the FlexE Group, and the two end points of a FlexE connection should be using a same FlexE Group Number in each direction. The assignment and auto negotiation of FlexE Group ID may be performed via signaling, which needs further study. o FlexE Group Member PHY Each Physical Link in the FlexE Group is a member PHY. The current FlexE specification [FlexE1.0] only supports bonding of physical links of a same rate. In the future, FlexE may support links with rates other than 100G, such as 400G which is being standardized by IEEE. o PHY Number Each PHY in a FlexE group is assigned with a PHY number, and a PHY number will be carried in the FlexE overhead over each PHY. FlexE specification requires that each end of the FlexE Group should assigned a same PHY number to a PHY. The PHY Number will also be used for FlexE mux and demux, FlexE traffic will be distributed to FlexE slots which may span over multiple PHYs in a round robin manner, which means traffic is distributed to PHYs with PHY number in ascending sequence. o FlexE Calendar FlexE calendar is the representation of FlexE slot resource of a FlexE group. It is the combination of sub calendar of each physical link in a FlexE group. o FlexE Sub Calendar FlexE sub calendar is the representation of the 20 slots of a physical link. Each FlexE sub calendar is carried in the FlexE overhead over the corresponding physical link when communicating with the other end. o FlexE Client A FlexE client can be Ethernet packet flow, with the rates of 10G, 40G, 100G, and in the future 25G, 50G, 200G and 400G, according to section 7.2.2 of [FlexE1.0]. It can also be some type of traffic Huang & Zhong Expires March 4, 2017 [Page 4] Internet-Draft FlexE Framework August 2016 other than Ethernet, CBR or VBR, such as fiber channel traffic. If FlexE is intended for network virtualization and network slicing in the future, or to support traffic with rates not listed above, it is better to support any N*5G rate. o FlexE Client Channel The channel supporting a FlexE client between FlexE shim layer of two nodes is a FlexE client channel. This channel can be a group FlexE slots between two adjacent nodes; an OTN OCh, a WDM wavelength or a fiber in the FlexE unaware case; an ODUk or ODUflex; or the combination of above, etc. The forwarding method used in the channel maybe L0, L1, L2 or above. o FlexE Client ID FlexE client ID is a 16bit integer, carried in the FlexE calendar in the overhead, representing the owner of a FlexE slot; each slot in use is related to a FlexE client ID. Receiver end of a FlexE group need to parse the FlexE calendar to find out which slots belongs to a FlexE client based on the mapping of FlexE client ID and slots, and then perform traffic mux. o FlexE Shim The FlexE shim is the layer maps or demaps FlexE client to or from a set FlexE slots over a FlexE group. According to [FlexE1.0] , the FlexE shim layer is within the 802.3 PCS layer, right below the 64/66B encode / decode module. 3. FlexE Related Network Use cases 3.1. Brief According to section 82, 83 of [IEEE802.3] and [FlexE1.0], Ethernet and FlexE layering is shown in the figure below. Huang & Zhong Expires March 4, 2017 [Page 5] Internet-Draft FlexE Framework August 2016 +------------------+ | L2 & Above | +------------------+ | RECONCILIATION | +------------------+ | | MII +-------------------------+ | PCS | | +---------------------+ | | | 64/66B En/Decode | | / +------------------+ | +---------------------+ |/ | Idle Add/Remove | | | FlexE Shim | | +------------------+ | +---------------------+ |\ | FlexE Calendar | | | De/scramble | | \ +------------------+ | +---------------------+ | | | AM Add / Remove | | | | block Distribution | | /+------------------+ | +---------------------+ | / | PMA | +-------------------------+/ +------------------+ | PMA | | RS-FEC(Optional) | +-------------------------+\ +------------------+ | PMD | \ | PMA | +-------------------------+ \+------------------+ | | MDI +--------------------+ | MEDIUM | +--------------------+ Figure 1: Standard Ethernet and FlexE There are three typical FlexE transport use cases as depicted in [FlexE1.0], and correspondingly there are several network layering and mapping options. Huang & Zhong Expires March 4, 2017 [Page 6] Internet-Draft FlexE Framework August 2016 +-----------------+ +-----------------+ +-----------------+ | L2 & Above | | L2 & Above | | L2 & Above | +-----------------+ +-----------------+ +-----------------+ | PCS (Upper) | | PCS (Upper) | | PCS (Upper) | +-----------------+ +-----------------+ +-----------------+ | 64/66B | | 64/66B | | 64/66B | | Encode/Decode | | Encode/Decode | | Encode/Decode | +-----------------+ +-----------------+ +-----------------+ | Idle Add/Remove | | Idle Add/Remove | | | +-----------------+ +-----------------+ | | | FlexE Calendar | | FlexE Calendar | | | +-----------------+ +-----------------+ | | | PCS (Lower) | | | | | +-----------------+ | | | | | | | | | | | | | | | | | | | | | | +-----------------+ +-----------------+ +-----------------+ | OTN G.709 | | OTN G.709 | | OTN G.709 | +-----------------+ +-----------------+ +-----------------+ FlexE Unaware FlexE Aware Flex Termination Figure 2: FlexE Transport Mappings 3.2. FlexE Unaware Transport In this mode, the FlexE traffic will be treated as bit stream on physical link basis, rather than at FlexE group or FlexE client basis. FlexE encapsulation and signaling is transparent to the transport network, The transport network will not try to interpret the bit stream. If the transport network covers a very long distance, skew might be a problem for FlexE, a large skew value should be considered. If there are multiple physical links in a FlexE group, it may be necessary to consider carrying the traffic of the various link along the same transport network path so as to mitigate skew issue. Huang & Zhong Expires March 4, 2017 [Page 7] Internet-Draft FlexE Framework August 2016 +------------------+ | L2 & Above | +------------------+ | RECONCILIATION | +------------------+ | | MII +-------------------------+ | PCS | | +---------------------+ | | | 64/66B En/Decode | | | +---------------------+ | | | FlexE Shim | | | +---------------------+ | | | De/scramble | | | +---------------------+ | | | AM Add / Remove | | | | block Distribution | | +-------------------------+ | +---------------------+ | L1 | PCS Layer & Above | +-------------------------+ <-----> +-------------------------+ | PMA | | | +-------------------------+ | | | PMD | | | +-------------------------+ | | | | MDI | | +--------------------+ +-------------------------+ | MEDIUM | | OTN G.709 | +--------------------+ +-------------------------+ Figure 3: L1 Connectivity According to section 17.7.5.1 and Annex E of [G.709], the data stream at the interface between PCS and PMA should be carried over OTN, as shown in the above figure. There is an efficiency problem in this mode. Because the transport network will not be able to know which FlexE slots are in use and which are not, then the transport network will have to carry all the traffic in a FlexE group. For example, if a FlexE group consists of two 100G links, and the configured FlexE bandwidth is 150G: 100G over one link and 50G over the other. But the transport network has to carry the total 200G traffic, unable to remove the unused 50G slots. 3.3. FlexE Aware Transport The transport network can understand the FlexE protocol, and will remove the unused slots before carrying FlexE traffic over the transport network. At the egress point of transport network, FlexE traffic will be mapped to the same number slots, while leaving some Huang & Zhong Expires March 4, 2017 [Page 8] Internet-Draft FlexE Framework August 2016 slots in the FlexE Group unused if necessary. This will save some bandwidth of the transport network. In this mode, the transport network interwork with FlexE below the FlexE layer, assuming FlexE is L1.5, most of the FlexE overhead will be transported over the transport network. The session management channel in the FlexE overhead will be terminated and replaced with idle control block, as specified in section 8.3 of [FlexE1.0]. The data stream to be transported is above L1 and below FlexE shim (L1.5), which is called as L1.25 data stream. +------------------+ | L2 & Above | +------------------+ | RECONCILIATION | +------------------+ | | MII +-------------------------+ | PCS | | +---------------------+ | | | 64/66B En/Decode | | | +---------------------+ | +---------------------+ | | FlexE Shim | | L1.25 | FlexE Shim & Above | | +---------------------+ | <-------> +---------------------+ | | De/scramble | | | | | +---------------------+ | | | | | AM Add / Remove | | | | | | block Distribution | | | | | +---------------------+ | | | +-------------------------+ | | | PMA | | | +-------------------------+ | | | PMD | | | +-------------------------+ | | | | MDI | | +--------------------+ +-------------------------+ | MEDIUM | | OTN G.709 | +--------------------+ +-------------------------+ Figure 4: L1.25 Connectivity The FlexE traffic is interleaved before transporting, so there will be no skew issue; and OTN will use BGMP algorithm to map FlexE traffic into ODUk or ODUflex, as specified in section 17.11 of [G.709]. Huang & Zhong Expires March 4, 2017 [Page 9] Internet-Draft FlexE Framework August 2016 [Note: The case when FlexE traffic is greater than the rate of a single link or a WMD wavelength is not yet considered by [G.709] for the time being. This mode is usually used for a point to point path, rather than a P2MP or MP2MP case. The traffic stream is the valid traffic of a whole FlexE group. 3.4. FlexE Client Transport This is also called FlexE termination transport. The FlexE traffic over multiple slot will be aggregated into a 64/66B stream, and the FlexE overhead will be removed before FlexE traffic is carried over the transport network. At the egress of the transport network, FlexE overhead will be added when the traffic is converted back into FlexE mode. +------------------+ | L2 & Above | +------------------+ | RECONCILIATION | +------------------+ | | MII +-------------------------+ | PCS | | +---------------------+ | +--------------------------+ | | 64/66B En/Decode | | L1.5 | 64/66B En/Decode & Above | | +---------------------+ | <------> +--------------------------+ | | FlexE Shim | | | | | +---------------------+ | | | | | De/scramble | | | | | +---------------------+ | | | | | AM Add / Remove | | | | | | block Distribution | | | | | +---------------------+ | | | +-------------------------+ | | | PMA | | | +-------------------------+ | | | PMD | | | +-------------------------+ | | | | MDI | | +--------------------+ +--------------------------+ | MEDIUM | | OTN G.709 | +--------------------+ +--------------------------+ Figure 5: L1.5 Connectivity Huang & Zhong Expires March 4, 2017 [Page 10] Internet-Draft FlexE Framework August 2016 This mode does not have the skew issue because the FlexE overhead is removed and the concept of FlexE slots does not exist when the traffic is in the transport network, alignment between slot is not necessary. The traffic in a FlexE group can be divided into multiple flows in the transport network, each can be identified by FlexE client ID, or FlexE client ID plus FlexE group number. These different flows can be routed through different ODUk or ODUflex and consequently may traverse over different link path to different end station. As shown in Figure 5, the FlexE overhead is removed from the FlexE traffic and the same number of 64/66B idle blocks are inserted at the IPG position between Ethernet frames when FlexE payload is Ethernet. It may be a different case if the FlexE payload is not Ethernet. Then the traffic is in the form of 64/66B block stream on a per FlexE client basis, and it is CBR stream. The mapping of this CBR stream over OTN uses IMP algorithm as specified in section 17.11 of [G.709]. 3.5. FlexE Client Routing and Transport This is another type of FlexE termination transport, FlexE overhead will be terminated and traffic will be converted into L2/L2.5/L3 packets streams on a per FlexE client basis, which is VBR stream, rather than 64/66B blocks in the above case. This will enable some new application scenario, such as transport network may be used to provide VPLS-like VPN service, or to support network virtualization and network slicing. A FlexE client can be modeled in a system as a virtual interface, a set of virtual interfaces can construct a L2 or L3 forwarding instance. Huang & Zhong Expires March 4, 2017 [Page 11] Internet-Draft FlexE Framework August 2016 +------------------+ +--------------------------+ | L2 & Above | | L2 & Above | +------------------+ <---------> +--------------------------+ | RECONCILIATION | | | +------------------+ | | | | MII | | +-------------------------+ | | | PCS | | | | +---------------------+ | +--------------------------+ | | 64/66B En/Decode | | | 64/66B Encode / Decode | | +---------------------+ | +--------------------------+ | | FlexE Shim | | | Idle Add / Remove | | +---------------------+ | +--------------------------+ | | De/scramble | | | | | +---------------------+ | | | | | AM Add / Remove | | | | | | block Distribution | | | | | +---------------------+ | | | +-------------------------+ | | | PMA | | | +-------------------------+ | | | PMD | | | +-------------------------+ | | | | MDI | | +--------------------+ +--------------------------+ | MEDIUM | | OTN G.709 | +--------------------+ +--------------------------+ Figure 6: L2-L2.5-L3 Connectivity Option1 Huang & Zhong Expires March 4, 2017 [Page 12] Internet-Draft FlexE Framework August 2016 +------------------+ +--------------------------+ | L2 & Above | | L2 & Above | +------------------+ <---------> +--------------------------+ | RECONCILIATION | | | +------------------+ | | | | MII | | +-------------------------+ +--------------------------+ | PCS | | GFP-F | | +---------------------+ | +--------------------------+ | | 64/66B En/Decode | | | | | +---------------------+ | | | | | FlexE Shim | | | | | +---------------------+ | | | | | De/scramble | | | | | +---------------------+ | | | | | AM Add / Remove | | | | | | block Distribution | | | | | +---------------------+ | | | +-------------------------+ | | | PMA | | | +-------------------------+ | | | PMD | | | +-------------------------+ | | | | MDI | | +--------------------+ +--------------------------+ | MEDIUM | | OTN G.709 | +--------------------+ +--------------------------+ Figure 7: L2-L2.5-L3 Connectivity Option2 [G.709] provides two methods to map packet client signal into OPUk as specified in section 17.10 and 17.11 of [G.709], firs map packet flow into GFP-F encapsulation then into OPUk or OPUflex, or map packet flow into FlexE client signal in the form of 64/66B block, then into OPUflex using Idle Mapping Procedure (IMP) as specified in section 17.11 of [G.709]. 4. GMPLS Extension Requirements 4.1. Generic The following parameters are applicable to FlexE Aware L1.25 Relay, FlexE Termination L1.5 Relay, and FlexE Termination L2/L2.5/L3 Relay. SENDER_TSPEC object: Class = 12 [RFC2205], C-Type = TBD. FLOWSPEC object: Class = 9, [RFC2205], C-Type = TBD. Huang & Zhong Expires March 4, 2017 [Page 13] Internet-Draft FlexE Framework August 2016 Traffic Parameters will be carried in the SENDER_TSPEC and FLOWSPEC object in Path Message to specify the traffic characteristics of a flow. section 4.2 of [I-D.du-ccamp-flexe-channel] already provides a traffic parameter definition. Switching Type Value Type ----- ---- TBD1 FlexE Generalized Label Object is carried in Resv Message. [RFC3209]. Section 3.1 of [I-D.hussain-ccamp-flexe-signaling-extensions] proivdes a label definition for FlexE which can support future links other than 100G and possible new granularities, also provides support to heterogeneous links in a FlexE group. If a simplified version is desired, the one in section 3.2 of [I-D.wang-ccamp-flexe-signaling] can be considered. 4.2. FlexE Unaware Transport This is actually a traditional mode, listed here for the purpose of completeness only. [Note: to consider carrying traffic of multiple links in a FlexE group along a same transport network path? TBD] LSP Encoding Type, Switching Type, G-PID will be carried in the Generalized Label Request Object. [RFC3473]. LSP Encoding Type [RFC3471] Value Type ----- ---- 9 Fiber Switching Type [RFC3471] Value Type ----- ---- 200 Fiber-Switch Capable (FSC) Generalized PID (G-PID) Value G-PID Type LSP Encoding Type ----- ---------- ------------------------ TBD2 100GE PCS Fiber, G.709 OCh, Lambda Huang & Zhong Expires March 4, 2017 [Page 14] Internet-Draft FlexE Framework August 2016 A new G-PID type is required, although this is not FlexE related. Label Format [RFC3471] will be carried in the Generalized Label Object. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Port Label Format (RFC3471) A new traffic parameter definition for FlexE unaware mode may not be necessary since the transport network is not supposed to know FlexE. A possible option is to reuse the traffic parameter definition in section 3.2.2 of [RFC2210]. 4.3. FlexE Aware Transport LSP Encoding Type Value Type ----- ---- TBD3 FlexE Aware Group Generalized PID (G-PID) Value G-PID Type LSP Encoding Type ----- -------------- ------------------ TBD4 FlexE Aware FlexE Aware Group OTN will use BGMP algorithm to map the FlexE signal over transport network. 4.4. FlexE Client Transport LSP Encoding Type Value Type ----- ------------ TBD5 FlexE Client Generalized PID (G-PID) Value G-PID Type LSP Encoding Type ----- -------------- ------------------ TBD6 FlexE Client FlexE Client Huang & Zhong Expires March 4, 2017 [Page 15] Internet-Draft FlexE Framework August 2016 4.5. FlexE Client Routing and Transport LSP Encoding Type for FlexE client (packet). Value Type ----- ------------------- TBD7 FlexE Client Packet Generalized PID (G-PID) Value G-PID Type LSP Encoding Type ----- -------------------- ------------------- TBD8 FlexE Client Packet FlexE Client Packet 5. Routing Extension Requirements TBD. 6. Signaling Extension Requirements TBD. 7. Acknowledgements 8. IANA Considerations SENDER_TSPEC object: Class = 12 [RFC2205], C-Type = TBD. FLOWSPEC object: Class = 9 [RFC2205], C-Type = TBD. LSP Encoding Type for FlexE aware group Value Type ----- ---- TBD FlexE Aware Group LSP Encoding Type for FlexE client (L1.5). Value Type ----- ------------ TBD FlexE Client LSP Encoding Type for FlexE client (packet). Value Type ----- ------------------- TBD FlexE Client Packet Huang & Zhong Expires March 4, 2017 [Page 16] Internet-Draft FlexE Framework August 2016 Switching Type for FlexE. Value Type ----- ---- TBD FlexE Generalized PID (G-PID) for 100GE PCS Value G-PID Type LSP Encoding Type ----- ---------- ------------------------ TBD 100GE PCS Fiber, G.709 OCh, Lambda Generalized PID (G-PID) for FlexE aware transport. Value G-PID Type LSP Encoding Type ----- -------------- ------------------ TBD FlexE Aware FlexE Aware Group Generalized PID (G-PID) for FlexE Client (L1.5). Value G-PID Type LSP Encoding Type ----- -------------- ------------------ TBD FlexE Client FlexE Client Generalized PID (G-PID) for FlexE client (packet). Value G-PID Type LSP Encoding Type ----- -------------------- ------------------- TBD FlexE Client Packet FlexE Client Packet 9. Security Considerations TBD. 10. References 10.1. Normative References [FlexE1.0] OIF, "Flex Ethernet Implementation Agreement 1.0", 2016. [G.709] ITU, "Interfaces for the optical transport network", 2016. [I-D.du-ccamp-flexe-channel] Du, Z., Chen, M., and J. Dong, "Framework and GMPLS Extensions of Flexible Ethernet Channel", draft-du-ccamp- flexe-channel-00 (work in progress), July 2016. Huang & Zhong Expires March 4, 2017 [Page 17] Internet-Draft FlexE Framework August 2016 [I-D.hussain-ccamp-flexe-signaling-extensions] Hussain, I., Valiveti, R., and K. Pithewan, "FlexE GMPLS Signaling Extensions", draft-hussain-ccamp-flexe- signaling-extensions-00 (work in progress), July 2016. [I-D.wang-ccamp-flexe-signaling] Wang, Q., "RSVP-TE Signaling Extensions in support of Flexible Ethernet networks", draft-wang-ccamp-flexe- signaling-02 (work in progress), July 2016. [IEEE802.3] IEEE, "IEEE Standard for Ethernet", 2015. [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, . [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, DOI 10.17487/RFC4328, January 2006, . 10.2. Informative References [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, DOI 10.17487/RFC2210, September 1997, . Huang & Zhong Expires March 4, 2017 [Page 18] Internet-Draft FlexE Framework August 2016 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . Authors' Addresses James Huang (editor) Huawei Shenzhen China Email: james.huang@huawei.com Qiwen Zhong Huawei Shenzhen China Email: zhongqiwen@huawei.com Huang & Zhong Expires March 4, 2017 [Page 19]