idnits 2.17.1 draft-du-ccamp-flexe-channel-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 : ---------------------------------------------------------------------------- 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 date (July 8, 2016) is 2847 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FlexE' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Du 3 Internet-Draft M. Chen 4 Intended status: Standards Track J. Dong 5 Expires: January 9, 2017 Huawei 6 July 8, 2016 8 Framework and GMPLS Extensions of Flexible Ethernet Channel 9 draft-du-ccamp-flexe-channel-00 11 Abstract 13 This document describes the use case of Flexible Ethernet (FlexE) in 14 packet transport networks, especially using the end-to-end FlexE 15 channel for the mobile transport scenario. The necessary GMPLS 16 extensions for the end to end FlexE Channel are also specified. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 9, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. FlexE Channel . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Ethernet Frame based Switching . . . . . . . . . . . . . 4 61 2.2. Time Slot based Switching . . . . . . . . . . . . . . . . 4 62 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. GMPLS Extensions for FlexE Channel . . . . . . . . . . . . . 5 64 4.1. Generalized Label Request . . . . . . . . . . . . . . . . 5 65 4.1.1. LSP Encoding Type . . . . . . . . . . . . . . . . . . 5 66 4.1.2. Switching Type . . . . . . . . . . . . . . . . . . . 5 67 4.1.3. Generalized-PID (G-PID) . . . . . . . . . . . . . . . 5 68 4.2. Traffic Parameters . . . . . . . . . . . . . . . . . . . 6 69 4.3. FlexE Channel Label . . . . . . . . . . . . . . . . . . . 6 70 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Routing Extensions for FlexE Channel . . . . . . . . . . . . 8 72 6.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Flexible Ethernet (FlexE) as defined in [FlexE] can provide complete 82 decoupling of the MAC data rates and the rates of Ethernet PHY(s). 84 FlexE defines Mux and Demux functions to transport traffic of FlexE 85 clients over shared physical links. The FlexE Mux creates a 86 logically serial stream of 66B blocks by interleaving FlexE clients 87 according to a calendar of length 20n slots for a FlexE group 88 composed of n 100 GBASE-R PHYs. Each slot corresponds to 5G of 89 bandwidth. A FlexE client is assigned a number of slots according to 90 its bandwidth divided by 5G. The FlexE Demux operates on a sequence 91 of 66B blocks received from each PHY of the FlexE group. The PHYs of 92 the FlexE group are re-interleaved so that FlexE clients can be 93 recovered. 95 FlexE has three main capabilities: 97 o Bonding Ethernet PHYs: FlexE allows bonding multiple Ethernet PHYs 98 as a larger pipe to carry a FlexE data flow. 100 o Sub-rating of Ethernet PHYs. 102 o Channelization. FlexE allows several data flows be carried over a 103 single Ethernet PHY or a group of bonded PHYs, with the MAC rate 104 of each flow be mapped to a FlexE channel. 106 With the above capabilities, FlexE can be used to provide different 107 services with guaranteed bandwidth, deterministic performance and 108 security on the common physical interfaces. Currently FlexE is used 109 as a link layer technology, while in some cases, such as mobile 110 transport network and enterprise VPN network which have high 111 bandwidth and Quality of Service (QoS) requirements, it is desirable 112 that such capability could be extended to the network level. 114 This document describes the use case of FlexE in packet transport 115 network. The necessary GMPLS extensions for the end to end FlexE 116 connection/path are also specified. 118 2. FlexE Channel 120 FlexE as defined in [FlexE] is essentially a link layer technology 121 which can provide the features like PHY bonding, sub-rating and 122 channelization on one hop link between two FlexE capable nodes. In 123 order to extend the applicability of FlexE to more scenarios such as 124 mobile transport and enterprise leased line, there is a proposal in 125 OIF to define FlexE 2.0 [FlexE2.0], which could provide multi-hop 126 FlexE connections in the network. Such connection is called a FlexE 127 channel. 129 A FlexE channel is composed of a series of time slots of consecutive 130 FlexE capable links. FlexE channel can provide end-to-end guaranteed 131 bandwidth, deterministic performance and security for a particular 132 service through the network shared by various services. 134 FlexE Channel 135 ........................................ 136 +-----+ +-----+ +-----+ +-----+ +-----+ 137 | N1 +===+ N2 +===+ N3 +===+ N4 +===+ N5 | 138 +-----+ +-----+ +-----+ +-----+ +-----+ 140 === FlexE Group 141 ... FlexE Channel 143 Figure 1: FlexE Channel 145 This document introduces two alternative FlexE channel switching 146 modes: Ethernet Frame based Switching and Time Slot based Switching. 148 2.1. Ethernet Frame based Switching 150 In this mode, each node will perform FlexE Mux and Demux operations. 151 It means a serial stream of FlexE 66B blocks will be recovered to 152 Ethernet frames on receipt, and if the Ethernet Frames need to be 153 transmitted over another FlexE group, the Ethernet frames will be cut 154 into a serial stream of 66B blocks again and the blocks are muxed 155 according to the calendar of the FlexE group, then sent to the next 156 hop. 158 2.2. Time Slot based Switching 160 In this mode, the intermediate nodes do not need to recover the 161 received FlexE blocks to Ethernet frames, the blocks will be switched 162 according to the mapping between the inbound and outbound calendars 163 directly. With this mode, the overhead of Mux and Demux can be 164 reduced, the processing latency of intermediate nodes could be 165 reduced accordingly. 167 3. Use Case 169 This section describes a typical use case of FlexE channel. 171 <---------------FlexE Channel----------> 172 ........................................ 173 +-----+ +-----+ +-----+ +-----+ +-----+ 174 | AN1 +===+ EN1 +===+ N1 +===+ EN2 +===+ AN2 | 175 +-----+ +--\--+ +-----+ +--/--+ +-----+ 176 \ / 177 \\ +-----+ // 178 \=+ N2 +=/ 179 +-----+ 181 Figure 2. FlexE Channel Use Case 183 As shown in Figure 2, the AN nodes, EN nodes and N nodes constitute a 184 mobile transport network, which provides various services with 185 different bandwidth and QoS requirements. If the links along the 186 path from AN1 to AN2 are all FlexE capable, an end-to-end FlexE 187 channel can be established between AN1 and AN2, which could provide 188 guaranteed bandwidth, deterministic latency and other QoS for a 189 particular service through the network. 191 Since each FlexE channel has its own dedicated resources and can 192 provide deterministic performance, it can be a good candidate of 193 implementing network slicing in packet transport network. 195 4. GMPLS Extensions for FlexE Channel 197 In order to establish an end-to-end FlexE channel, some extensions to 198 GMPLS protocols are needed. This section specifies the necessary 199 extensions for FlexE channel. 201 4.1. Generalized Label Request 203 4.1.1. LSP Encoding Type 205 LSP Encoding Type [RFC3471] indicates the encoding of the LSP being 206 requested. An additional LSP Encoding Type code-point for the FlexE 207 is defined in this document. 209 Value Type 210 ----- ----- 211 TBD1 FlexE 213 4.1.2. Switching Type 215 The Switching Type indicates the type of switching that should be 216 performed at the termination of a particular link. 218 As described in Section 2, FlexE channel can support two switching 219 modes. For the Ethernet Frame based switching, existing switching 220 type L2SC as defined in [RFC4202] can be reused. 222 To support FlexE Time Slot based switching, a new switching type is 223 defined in this document. 225 Value Type 226 ----- -------------------------- 227 TBD2 FlexE Time Slot Switching 229 4.1.3. Generalized-PID (G-PID) 231 The G-PID, as defined in [RFC3471], identifies the payload carried by 232 an LSP. This document defines a new G-PID to indicate the payload 233 carried by a FlexE Channel. 235 Value Type Technology 236 ----- ---------------- ---------- 237 TBD3 64B/66B FlexE FlexE 239 4.2. Traffic Parameters 241 To carry the traffic parameters for FlexE switching type, two new 242 objects are defined as follows: 244 FLEXE SENDER_TSPEC object : Class = 12, C-Type = TBD4; 246 FLEXE FLOWSPEC object : Class = 9, C-Type = TBD4; 248 The FLEXE SENDER_TSPEC object is carried in the Path message, and the 249 FLEXE FLOWSPEC object is carried in the Resv message. 251 The FLEXE SENDER_TSPEC object and the FLEXE FLOWSPEC object have the 252 same format. The format of the FlexE traffic parameters is defined 253 as follows: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Signal Type | Number of Slots | Reserved | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 3: Traffic Parameters for FlexE 262 The Signal Type (8 bits) indicates the type of FlexE signal. 263 Currently, only one type "5G slot" is defined according to [FlexE]: 265 Value Type 266 ----- ------- 267 TBD5 5G slot 269 The Number of Slots field (16 bits) indicates how many slots are 270 requested for the FlexE channel. 272 4.3. FlexE Channel Label 274 This section describes the Generalized Label value space for FlexE 275 Channel. The Generalized Label is defined in [RFC3471]. The format 276 of the corresponding RSVP-TE GENERALIZED_LABEL object is specified in 277 [RFC3473]. 279 The FlexE label has the following format: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | FlexE Group number | Number of PHY | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Length | Reserved | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | PHY Number1 | Bit Map Length| Bitmap | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 ~ Bit Map (continued) ~ 291 ~ +-+-+-+-+-+-+-+-+-+-+-+-+ 292 | .... | Padding Bits | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | PHY Number2 | Bit Map Length| Bitmap | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 ~ Bit Map (continued) ~ 297 ~ +-+-+-+-+-+-+-+-+-+-+-+-+ 298 | .... | Padding Bits | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 ~ ....... ~ 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 4: FlexE Label 305 The FlexE Group number (20 bits) defined in [FlexE] is a unique 306 identifier of a FlexE Group on a FlexE node. 308 The Number of PHY (12 bits) indicates the number of physical links in 309 the FlexE Group. 311 Length (16 bits) indicates the total length of the whole FlexE label. 313 PHY Number (8 bits) is an identifier of a specific physical link, it 314 is unique on a FlexE node. 316 Bitmap length (8 bits) indicates the length of the followed bitmap 317 field. 319 Bitmap (variable) indicates which slots in the physical link are 320 allocated to a FlexE channel. When a bit is set, it means that the 321 corresponding slot is used by the FlexE channel. 323 Padding Bits are added after the bitmap to make the whole label a 324 multiple of four bytes if necessary. Padding bits MUST be set to 0 325 when sending and MUST be ignored on receipt. 327 5. Procedures 329 The ingress node MUST generate a Path message and specify the 330 Encoding type, Switching Type, and corresponding G-PID of a FlexE 331 channel in the GENERALIZED_LABEL_REQUEST object, which MUST be 332 processed as defined in [RFC3473]. 334 When a downstream node or egress node receives a Path message 335 containing a GENERALIZED_LABEL_REQUEST object for setting up a FlexE 336 channel from its upstream neighbor node, the node MUST generate a 337 FlexE label according to the traffic parameters of the requested 338 channel and the available resources (i.e., available slots of the 339 FlexE Group) that will be reserved for the channel and send the label 340 to its upstream neighbor node. 342 6. Routing Extensions for FlexE Channel 344 In order to establish a multi-hop FlexE channel, the FlexE capability 345 and the related resources of the nodes and links in the network need 346 to be collected. Basically, the needed information for FlexE channel 347 is: 349 o FlexE switching capability 351 o FlexE switching modes 353 o FlexE switching granularity (e.g., 5G per slot) 355 o The total/allocated/available time slots of each FlexE Group 357 o Node/Interface Latency 359 o 361 The subsequent sections specifies the IGP and BGP-LS extensions 362 respectively for the collection of FlexE related information. 364 6.1. IGP 366 TBD. 368 6.2. BGP-LS 370 TBD. 372 7. IANA Considerations 374 TBD. 376 8. Security Considerations 378 TBD. 380 9. Normative References 382 [FlexE] OIF, "Flex Ethernet Implementation Agreement Version 1.0 383 (OIF-FLEXE-01.0)", March 2016. 385 [FlexE2.0] 386 Huawei, "Next Generation FlexE 2.0 Considerations", March 387 2016. 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, 392 . 394 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 395 Switching (GMPLS) Signaling Functional Description", 396 RFC 3471, DOI 10.17487/RFC3471, January 2003, 397 . 399 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 400 Switching (GMPLS) Signaling Resource ReserVation Protocol- 401 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 402 DOI 10.17487/RFC3473, January 2003, 403 . 405 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 406 in Support of Generalized Multi-Protocol Label Switching 407 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 408 . 410 Authors' Addresses 412 Zongpeng Du 413 Huawei 415 Email: duzongpeng@huawei.com 416 Mach(Guoyi) Chen 417 Huawei 419 Email: mach.chen@huawei.com 421 Jie Dong 422 Huawei 424 Email: jie.dong@huawei.com