One document matched: draft-du-ccamp-flexe-channel-00.txt
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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, DOI 10.17487/RFC3471, January 2003,
<http://www.rfc-editor.org/info/rfc3471>.
[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,
<http://www.rfc-editor.org/info/rfc3473>.
[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,
<http://www.rfc-editor.org/info/rfc4202>.
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]
| PAFTECH AB 2003-2026 | 2026-04-23 09:10:52 |