GMPLS Routing and Signaling Framework for Flexible Ethernet (FlexE)
draft-izh-ccamp-flexe-fwk-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Iftekhar Hussain , Radha Valiveti , Qilei Wang , Loa Andersson , Mach Chen , Haomian Zheng | ||
| Last updated | 2017-06-27 (Latest revision 2017-03-13) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-izh-ccamp-flexe-fwk-03
Common Control and Measurment Plane I. Hussain
Internet-Draft R. Valiveti
Intended status: Informational Infinera Corp
Expires: December 29, 2017 Q. Wang
ZTE
L. Andersson
M. Chen
H. Zheng
Huawei
June 27, 2017
GMPLS Routing and Signaling Framework for Flexible Ethernet (FlexE)
draft-izh-ccamp-flexe-fwk-03
Abstract
As different from earlier Ethernet data planes FlexE allows for
decoupling of the Ethernet Physical layer (PHY) and Media Access
Control layer (MAC) rates.
Study Group 15 (SG15) of the ITU-T has endorsed the FlexE
Implementation Agreement from Optical Internetworking Forum (OIF) and
included it, by reference, in some of their Recomendations.
This document specifies the use cases of FlexE technology, GMPLS
control plane requirements, framework, and architecture.
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 December 29, 2017.
Hussain, et al. Expires December 29, 2017 [Page 1]
Internet-Draft FlexE Extensions June 2017
Copyright Notice
Copyright (c) 2017 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Back-to-Back FLexE . . . . . . . . . . . . . . . . . . . 6
3.2. Unaware Transport . . . . . . . . . . . . . . . . . . . . 8
3.3. Aware Transport . . . . . . . . . . . . . . . . . . . . . 8
3.4. FleE Termination in Transport . . . . . . . . . . . . . . 9
3.5. FlexE Client BW Resizing . . . . . . . . . . . . . . . . 10
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Framework and Architecture . . . . . . . . . . . . . . . . . 13
5.1. FlexE Framework . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. FlexE Reference Model . . . . . . . . . . . . . . . . 13
5.1.2. FlexE Services . . . . . . . . . . . . . . . . . . . 14
5.2. FlexE Architecture . . . . . . . . . . . . . . . . . . . 14
5.2.1. Architecture Components . . . . . . . . . . . . . . . 14
5.2.2. FlexE Layer Model . . . . . . . . . . . . . . . . . . 15
5.2.2.1. FlexE Group structure . . . . . . . . . . . . . . 15
5.2.2.2. FlexE Client mapping . . . . . . . . . . . . . . 15
6. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. GMPLS Routing . . . . . . . . . . . . . . . . . . . . . . 16
6.2. GMPLS Signaling . . . . . . . . . . . . . . . . . . . . . 17
6.3. FlexE Packet Label Switching Data Plane . . . . . . . . . 19
7. Operations, Administration, and Maintenance (OAM) . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Hussain, et al. Expires December 29, 2017 [Page 2]
Internet-Draft FlexE Extensions June 2017
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
Ethernet MAC rates were until recently constrained to match the rates
of the Ethernet PHY(s). Work within the OIF allows MAC rates to be
different from PHY rates. An OIF implementation agreement
[OIFFLEXE1] allows for complete decoupling of the MAC and PHY rates.
SG15 in ITU-T has endorsed the OIF FlexE data plane and parts of
[G.872], [G.709], [G.798] and [G.8021] depends on or are based on the
FlexE data plane.
This includes support for
a. MAC rates which are greater than the rate of a single PHY;
multiple PHYs are bonded to achieve this
b. MAC rates which are less than the rate of a PHY (sub-rate)
c. support of multiple FlexE CLients carried over a single PHY, or
over a collection of bonded PHYs.
The capabilities supported by the first version of the FlexE data
plane are:
a. Support a large rate Ethernet MAC over bonded Ethernet PHYs, e.g.
supporting a 200G MAC over 2 bonded 100GBASE-R PHY(s)
b. Support a sub-rate Ethernet MAC over a single Ethernet PHY, e.g.
supporting a 50G MAC over a 100GBASE-R PHY
c. Support a collection of flexible Ethernet clients over a single
Ethernet PHY, e.g. supporting two MACs with the rates 25G, and
one with rate 50G over a single 100GBASE-R PHY
d. Support a sub-rate Ethernet MAC over bonded PHYs, e.g. supporting
a 150G Ethernet client over 2 bonded 100GBASE-R PHY(s)
e. Support a collection of Ethernet MAC clients over bonded Ethernet
PHYs, e.g. supporting a 50G, and 150G MAC over 2 bonded Ethernet
PHY(s)
Networks which support FlexE Ethernet interfaces include a basic
building block, this is true also when the interfaces are bonded.
This building block consists of two FlexE Shim functions, located at
opposite ends of a link, and the logical point to point links that
carry the Ethernet PHY signals between the two FlexE Shim Functions.
Hussain, et al. Expires December 29, 2017 [Page 3]
Internet-Draft FlexE Extensions June 2017
These logical point-to-point PHY links may be realized in a variety
of ways:
a. direct point-to-point links with no intervening transport
network.
b. Ethernet PHY(s) may be transparently transported via an Optical
Transport Network (OTN), as defined by ITU-T in [G.709] and
[G.798]. The OTN set of client mappings has been extended to
support the use cases identified in the OIF FlexE implementation
agreement.
This document examines the use cases that arise when the logical
links between FlexE capable devices are
(a) point-to-point links without any intervening network
(b) realized via Optical transport networks.
This draft considers the variants in which the two peer FlexE devices
are both customer-edge devices, or when one is s customer-edge and
the other is provider edge devices. This list of use cases will help
identify the Control Plane (i.e. Routing and Signalling) extensions
that may be required.
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. Terminology
a. AC (Attachment Circuit) - the connectivity between a client/
customer network and a provider network.
b. CE (Customer Edge) - the group of functions that support the
termination/origination of data received from or sent to the
network
c. Crunching: The process of compressing an Ethernet PHY signal by
eliminating the unavailable FlexE calendar slots at the ingress
to the transport network; these discarded unavailable FlexE
calendar slots are re-inserted (with fixed content) at the
transport network egress.
d. Ethernet PHY: an entity representing Physical Coding Sublayer
(PCS), Physical Media Attachment (PMA), and Physical Media
Dependent (PMD) layers.
Hussain, et al. Expires December 29, 2017 [Page 4]
Internet-Draft FlexE Extensions June 2017
e. FlexE Calendar: The total capacity of a FlexE Group is
represented as a collection of slots which have a granularity of
5G. The calendar for a FlexE Group composed of n 100G PHYs is
represented as an array of 20n slots (each representing 5G of
bandwidth). This calendar is partitioned into sub-calendars,
with 20 slots per 100G PHY. Each FlexE client is mapped into one
or more calendar slots (based on the bandwidth the FlexE client
flow will need).
Note this description of the FlexE Calendar is based on the first
version of FlexE, for future version changes in the granularity
and PHY rates are under study.
f. FlexE Client: An Ethernet flow based on a MAC data rate that may
or may not correspond to any Ethernet PHY rate.
g. FlexE Group: A FlexE Group is composed of from 1 to n Ethernet
PHYs. In the first version of FlexE each PHY is identified by a
number in the range {1-254}.
h. FlexE Interface: A logical interface that is composed of from 1
to n Ethernet interfaces.
i. FlexE Link: A logical link that connects two FexE interfaces
residing in two adjacent nodes.
j. FlexE Shim: the layer that maps or demaps the FlexE client flows
carried over a x Group.
k. FlexE Sub-Interface: A channelized logical sub-interface that is
allocated specific slots from a FlexE interface, the number of
slots depend on the rate of the FlexE client flow that will be
transmitted through this sub-interface.
l. FlexE Sub-Link: A logical link that connects two FlexE sub-
interfaces that residing in two adjacent nodes.
m. LMP: Link Management Protocol
n. LSP: Label Switched Path
o. OTN: Optical Transport Network
p. PW: Pseudowire
q. SG15: ITU-T Study Group 15 (Transport, Access and Home).
r. TE: Traffic Engineering
Hussain, et al. Expires December 29, 2017 [Page 5]
Internet-Draft FlexE Extensions June 2017
s. TED: Traffic Engineering Database
t. TN: Transport Network
3. Use Cases
This section describes 5 major use cases as a background to the
requirements in Section 4. The use cases are Back-to-Back FlexE,
FlexE Unware transport, FlexE Aware transport, FleE Termination in
Transport, and FlexE client BW Resizing.
FlexE aware routers and OTN equipment have a functionality (FlexE
Shim) that handles FlexE connectivity and termination. In the first
generation of FlexE the PHYs are 100 Gbit/s and are structured into 5
Gbit/s slots. In the simplest case a FlexE Group and a PHY are
identical, PHYs can also be combined to form larger FlexE Froups.
FlexE MACs can be built through combining one or more 5 Gbits slots.
The slots does not need to come from the same PHY, but need to be
part of the same FlexE Group
3.1. Back-to-Back FLexE
This section describes a FlexE scenario in which routers are
interconnected back-to-back through FlexE Groups without an
intermediate transport network, see Figure 1 below.
The scenarios describe in Section 3.1 assumes the first generation of
FlexE.
Hussain, et al. Expires December 29, 2017 [Page 6]
Internet-Draft FlexE Extensions June 2017
n x PHY
+-----+-----+ | +-----+-----+
| R | F | | | F | R |
| o | l | | | l | o |
| u | e | | | e | u |
| t | x | | | x | t |
| e | E | v | E | e |
| r | +--------------------------+ | r |
| | S | | S | |
| A | h | | h | B |
| | i | | i | |
| | m | | m | |
+-----+-----+ +-----+-----+
Figure 1: FlexE back-to-back Use Case
In this case we assume that we want to establish an x Gbit/s FlexE
LSP between router A and B, using y 5 Gbit/s slots from z PHYs.
o For the first version of FlexE, x can be 10, 40, or a multiple of
25 Gbit/s;
o y is equal to x/5;
o z can be any figure between 1 and n;
The GMPLS peers are the FlexE aware routers (routers A and B), and
GMPLS signaling and exchange of traffic engineering information takes
place between the peers.
To set up this FlexE LSP by an GMPLS control plane the OSPF-TE
[RFC4203] and ISIS-TE [RFC5305] needs to be extended to keep FlexE
traffic engineering information, e.g. the number of used and
available of 5 Git/s slots between a pair of routers. RSVP-TE needs
to be extended to set up right size LSP between the pair of routers.
The LSP creates a set of FlexE sub-interfaces on the routers and
concatenate them (by means of MPLS labels) to form an end-2-end path.
The action to establish the LSP, involves coordinating a number of 5
Gbit/s slots from the FlexE group to create the MAC layer and the
FlexE sub-interface.
Hussain, et al. Expires December 29, 2017 [Page 7]
Internet-Draft FlexE Extensions June 2017
3.2. Unaware Transport
In this use case the routers that originates and terminates the FlexE
PHYs and MACs are interconnected by an OTN network. The OTN network
is unaware what type of traffic is carried over the OTN network.
n x PHY
+-----+-----+ | +-----+-----+
| R | F | | | F | R |
| o | l | | | l | o |
| u | e | v | e | u |
| t | x | ---------- | x | t |
| e | E | / \ | E | e |
| r | +----+ OTN +------+ | r |
| | S | \ / | S | |
| A | h | ---------- | h | B |
| | i | | i | |
| | m | | m | |
+-----+-----+ +-----+-----+
Figure 2: FlexE Unaware Transport
This use case is from a GMPLS control plane point of view identical
to Figure 1.
The GMPLS peers are the FlexE aware routers, and GMPLS signaling and
exchange of traffic engineering information takes place between the
peers, e.g. router A and B. The OTN is FlexE unaware and is not
involved in the exchange of traffic engineering information and
signaling.
3.3. Aware Transport
In this use case the OTN edge nodes (PE) and the routers (CE) that
are connected to the OTN network are aware of that the connections
carry FlexE traffic. The Attachment Circuit (AC) carries the full
PHY bandwidth, while the OTN FlexE Aware PEs has a function called
"crunching" that removes unavailable slots.
Hussain, et al. Expires December 29, 2017 [Page 8]
Internet-Draft FlexE Extensions June 2017
...................................
n x PHY . n x crunched PHYs .
. .
+----+ . +-----+ .
| CE +--------------+ PE1 +--------------------+ .
+----+ . +-----+ | .
. | .
. +--+--+ .
. OTN Network | P | .
. +--+--+ .
. | .
+----+ . +-----+ | .
| CE +--------------+ PE2 +--------------------+ .
+----+ . +-----+ .
....................................
Figure 3: FlexE Aware Transport
Between PE1 and PE2 there is a mechanism ("crunching") that can
remove PHY slots that are not carrying traffic, this mechanism will
decrease the bandwidth necessary to carry by the OTN network.
The mapping between PHY(s) and MAC are called "calendar", the
calendar indicates which slots that carry traffic.
The active calendar is managed by the data plane, and will be changed
to match the intended calendar to complete the bandwidth resizing.
Apart from the requirements listed in Section 4 the GMPLS control
plane may be used to distrubute traffic engineering and control
information, e.g. distributing the intended calendar, when bandwidth
resizing is requested.
3.4. FleE Termination in Transport
The figure need to be added.
This use case does not generate any new requirements for a GMPLS
control plane as compared to Section 3.1, Section 3.2, and
Section 3.3.
Hussain, et al. Expires December 29, 2017 [Page 9]
Internet-Draft FlexE Extensions June 2017
3.5. FlexE Client BW Resizing
The table below show where FlexE resixing is supported.
***
+------+---------+-----------+------------------------------------+
| end- | use | TN | Resizing supported |
|points| case | Function | |
+------+---------+-----------+------------------------------------+
|CE/CE | Sec 3.2 | FlexE | Yes, by CEs. |
| | | unaware | The OTN pipes are configured for |
| | | TN | the maximum number of calendar |
| | | | slots across each PHY in the FlexE |
| | | | group, no resizing required in the |
| | | | OTN Layer. |
+------+---------+-----------+------------------------------------+
|CE/CE | Sec 3.3 | FlexE | Limited support. |
| | | aware | Supported at the endpoints only if |
| | | TN | the set of available/unavailable |
| | | | calendar slots is constant. Not |
| | | | supported otherwise, see notes at |
| | | | the end of Sec 3.2. |
+------+---------+-----------+------------------------------------+
|CE/PE | Sec 3.4 | FlexE | No. |
| | |termination| Resizing not supported due to lack |
| | | within | of a general hitless resizing |
| | | TN | mechanism in OTN, |
+------+---------+-----------+------------------------------------+
|CE/CE | Sec 3.1 | No TN | Yes, by CEs. |
| | | | The resizing of FlexE connections |
| | | | that transit multiple FlexE Groups |
| | | | (as in Figure 6) can be |
| | | | accomplished by coordinating the |
| | | | resize operations across each of |
| | | | the hops. |
+------+---------+-----------+------------------------------------+
***
Figure 4: FlexE Client Resizing
This use case does not generate any new requirements for a GMPLS
control plane as compared to Section 3.1, Section 3.2, and
Section 3.3.
Hussain, et al. Expires December 29, 2017 [Page 10]
Internet-Draft FlexE Extensions June 2017
4. Requirements
This section summarizes the requirements for FlexE Group and FlexE
client signaling and routing. The requirements are derived from the
usecases described in Section 3 of this document. Data plane
requirements (and/or solutions) (e.g. crunching of tributary slots,
adding unavailable tributary slots etc.) are not explicitly mentioned
in the following text. Given that the control plane sets up circuits
that transport client streams, there are no implications for the
control plane in matters of delay, jitter tolerance etc. The
requirements listed in this section will be used to identify the
Control Plane (i.e. Routing and Signaling) extensions that will be
required to support FlexE services in an OTN.
Req-1 The solution SHALL support the creation of a FlexE Group,
consisting of one or more (i.e., in the 1 to 254 range) 100GE
Ethernet PHY(s).
There are several alternatives that can meet this
requirement, e.g. routing and signaling protocols, or a
centralized controller/management system with network access
to the FlexE mux/demux at each FlexE Group termination point.
Req-2 The solution SHOULD be able to verify that the collection of
Ethernet PHY(s) included in a FlexE Group have the same
characteristics (e.g. number of PHYs, rate of PHYs, etc.) at
the peer FlexE shims.
Req-3 The solution SHALL support the ability to delete a FlexE
Group.
Req-4 The solution SHALL support the ability to administratively
lock/unlock a FlexE Group.
Req-5 It SHALL be possible to add/remove PHY(s) to/from an
operational FlexE group while the group has been
administratively locked.
[Note: Since the addition/removal of Ethernet PHY(s) is done
only when the group has been locked, this dataplane operation
of the FlexE Group ceases until it is placed in an unlocked
state.]
Req-6 The solution SHALL support the ability to advertise (and
discover) the information about FlexE capable nodes, and the
FlexE interfaces/sub-interfaces they are supporting.
Hussain, et al. Expires December 29, 2017 [Page 11]
Internet-Draft FlexE Extensions June 2017
Req-7 It SHALL be possible to assign the transport network
treatment for a FlexE Group to one the following choices:
(a) FlexE unaware transport
(b) FlexE aware transport
(c) FlexE termination in Transport.
Req-8 For the FlexE unaware case, each of the Ethernet PHY(s) in
the FlexE group SHALL be mapped independently to the
appropriately sized ODU container (as per [G.709], and
switched across the transport network [OIFFLEXE1]. The
control plane SHALL be capable of co-routing the ODU signals
that are transporting the member PHY(s) between the two FlexE
Shim functions.
Note: Insert applicable references to ITU, OIF spec for hard
skew tolerances]
Req-9 In the FlexE aware mode, the OTN SHALL crunch the PHY(s), and
map them to one or more ODUflex connections as per [G.709].
When two or more ODUflex connections are used to transport
the collection of FlexE PHY(s) in a FlexE Group, the system
SHALL support the ability to constrain the routes for these
ODUflex connections (e.g. co-route them) so that the end-to-
end skew is kept to a minimum (and within the range supported
by the FlexE Shims).
Req-10 The system SHALL allow the addition (or removal) of one or
more FlexE clients against the FlexE Group which is being
terminated. The addition (or removal) of a FlexE client flow
SHALL NOT affect the services for the other FlexE client
signals.
Req-11 The system SHALL allow the FlexE client signals to flexibly
span the set of Ethernet PHY(s) which comprise the FlexE
Group. In other words, it SHALL be possible to distribute
any FlexE client flow over an arbitrary combination of
calendar slots (whose total capacity matches the client
bitrate) chosen from a subset of the PHY(s).
Req-12 When the FlexE Group is terminated on the Transport edge
node, this node SHOULD be capable of resizing one or more
FlexE client flow (using the "A/B" calendar signaling defined
by OIF) (see Figure 4). It is acceptable that this resizing
Hussain, et al. Expires December 29, 2017 [Page 12]
Internet-Draft FlexE Extensions June 2017
is not hitless, and the client signal incurs a glitch during
the resizing operation.
There is no requirement for the OTN network to support the
hitless resizing of the ODUFlex connection which is
transporting the FlexE client signal.
Req-13 The solution SHALL support FlexE client flow resizing without
affecting any existing FlexE clients within the same FlexE
Group.
Req-14 The solution SHALL support establishment of single- and
multihop end-2-end LSPs.
5. Framework and Architecture
This section discusses FlexE framework and archtecture. Framework is
taken to mean how FlexE interoperates with other parts of the data
communication system. Architecture is taken to mean how funtional
groups and elements within FlexE work together to deliver the
expected FlexE services. Framework is taken to mean how FlexE
interacts with it environment.
5.1. FlexE Framework
The service of offered by Flexible Ethernet is a transport service
very similar (or even identical) to the service offered by Ethernet.
There are two major additions supported by FlexE:
o FlexE is intended to support high bandwidth and FlexE can offer
granular bandwidth from 5Gbits/s and a bandwidth as high as the
FlexE Group allows.
o As FlexE groups and clients are set up as a configuration
activity, by a centralized controller or by a GMPLS control plane
the service is connection oriented.
5.1.1. FlexE Reference Model
The figure below gives a simplified FlexE reference model.
Hussain, et al. Expires December 29, 2017 [Page 13]
Internet-Draft FlexE Extensions June 2017
...................................
n x PHY . n x crunched PHYs .
. .
+----+ . +-----+ +-----+ +-----+ . +----+
| CE +--------------+ PE1 +----+ P +----+ PE2 +--------+ CE |
+----+ . +-----+ +-----+ +-----+ . +----+
. .
+----+ m x PHY . . +----+
| CE +---------------------------------------------------+ CE |
+----+ . . +----+
. OTN Network .
. .
....................................
+----+ p x PHY +----+
| CE +---------------------------------------------------+ CE |
+----+ +----+
Figure 5: FlexE Reference Model
5.1.2. FlexE Services
The services offered by Flexible Ethernet are essentially the same as
for traditional Ethernet, connection less Ethernet transport.
However, when the relationship between the PHY and MAC layer are set
up by a GMPLS control plane there is a strong connection oriented
aspect.
5.2. FlexE Architecture
5.2.1. Architecture Components
Editors Note (to be removed): this section needs some serious
polishing and also add the missing text.
This section discusses the different parts of FlexE signaling and
routing and how these parts interoperate.
The FlexE routing mechanism is used to provide resource available
information for set up of FlexE LSP, like Ethernet PHYs' information,
partial-rate support information. Based on the resource available
information advertised by routing protocol, an end-to-end FlexE
connection is computed, and then the signaling protocol is used to
set up the end-to-end connection.
Hussain, et al. Expires December 29, 2017 [Page 14]
Internet-Draft FlexE Extensions June 2017
FlexE signaling mechanism is used to set up a FlexE LSPs.
5.2.2. FlexE Layer Model
The FLexE layer model is similar Ethernet model, the Ethernet PHY
layer corresponds to the "FlexE Group", and the MAC layer corresponds
to the "FlexE Client".
As different from earlier Ethernet the combination of Flexe Group and
Client allows for a huge freedom when it comes to define the
bandwidth of an Ethernet connectivity.
5.2.2.1. FlexE Group structure
The FlexE Group might be supported by vitually any transport network,
including the Ethernet PHY. While the Ethernet PHY offers a fixed
bandwidth the FlexE Group has been structured into 5 Gbit/s slots.
This means that the Flexe Group can support FlexE clients of a
variety of bandwidths.
The first version is defined for 20 slots of 5 Git/s over a 100 Gbit/
s PHY. The 100 Gbit/s PHYs can be bonded to give higher bandwidth.
5.2.2.2. FlexE Client mapping
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 Shim is
the layer that maps or demaps the FlexE client flows carried over a
FlexE group. As defined in [OIFFLEXE1], MAC rates of 10, 40, and any
multiple of 25 Gbit/s are supported. This means that if there is a
100 Gbit/s FlexE Group between A and B, a FlexE client of 10, 25, 40,
50, 75 and 100 Gbit/s can be created.
However, by bonding, for example 5 PHYs of 100 Git/s to a single
FlexE group, FlexE clients of 500 Gbit/s can be supported.
6. Control Plane
This section discusses the procedures and extensions needed to the
GMPLS Control Plane to establish FlexE LSPs.
There are several ways to establish FlexE groups, allocate slots for
FlexE clients, and set up single-hop and multi-hop end to end FlexE
LSPs. A configuration tool, a centralized controller or the GMPLS
control plane can all be used.
To create the FleE GMPLS control plane extensions to the following
protocols may be needed:
Hussain, et al. Expires December 29, 2017 [Page 15]
Internet-Draft FlexE Extensions June 2017
o "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RSVP-TE) [RFC3209]
o "Link Management Protocol" (LMP) [RFC4204]
o "Path Computation Element (PCE) Communication Protocol" (PCEP)
[RFC5440]
o IS-IS Extensions for Traffic Engineering (ISIS-TE) [RFC5305]
o "OSPF Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)" (OSPF-TE) [RFC4203]
o "North-Bound Distribution of Link-State and Traffic Engineering
(TE) Information Using BGP" (BGP-LS) [RFC7752]
A FlexE control plane YANG model will also be needed.
Section 6.2 and Section 6.1 discusses the role of the GMPLS control
plane when primarily setting up multi-hop LSPs.
When discussing the signaling and routing procedures and information
we assume that the the FlexE group has been established prior to
executing the procedures needed to establish a FlexE LSP.
Technically it is possible to establish FlexE group, allocate FlexE
client slots and FlexE LSP with a single exchange of GMPLS signaling
messages.
6.1. GMPLS Routing
To establish a FlexE LSP the Traffic Engineering (TE) information is
themost critical information, e.g. resource utitlisation on
interfaces and link, including the availability of slots on the FlexE
groups. The GPMPLS routing protocols needs to be extended to handle
this information. The Traffic Engineering Database (TED) will keep
an updated version of this information.
The FlexE capable nodes will be identified by IP-addresses, and the
routing and traffic engineering information will be flooded to all
nodes within the routing domain using TCP/IP.
When a FlexE LSP is about to be set up, e.g. R1 - R2 - R3 in
Figure 6 the information in the TED is used verify that resources are
available. When it is conformed that the FlexE LSP is establsihed
the TED is updated, marking the resources used for the new LSP as
used. Similarily when a LSP is taken down the resources are marked
as free.
Hussain, et al. Expires December 29, 2017 [Page 16]
Internet-Draft FlexE Extensions June 2017
6.2. GMPLS Signaling
In Figure 6 node R1 - R3 and R3 - R4, and R2 - R4 are connected by
100 Gbit/s FlexE groups. R2 - R4 are connected by 2 FlexE groups
each 100 Gbit/s. In this example we will go through the procedures
to set up two FlexE LSPs, the first (40 Git/s) R1 - R3 - R4, and the
second (80 Gbit/s) R2 - R3 - R4.
The slots of the FlexE group between two nodes is controlled by the
upstream node, while the assigment of a label for an LSP is
controlled by the downstream node.
In Figure 6 the four nodes may be interconnected by the FlexE back-
to-back or the Flex aware.
+----+
| R1 +---------------------+
+----+ |
|
+----+ +--+--+ +----+
| R2 +------------------+ R3 +-------------------------+ R4 |
+----+ +--+--+ +----+
|
+----+ |
| R5 +---------------------+
+----+
Figure 6: FlexE LSP Example
When an LSP is set up (e.g. R1 - R3 - R4) the following signaling
steps takes place:
1. Node R1 identify the resources needed for the LSP, in this case
we assume that a 40 Gbit/s LSP will be set up.
2. Node R1 identifies the next hop, in this case node R3.
3. Node R1 identifies the the slots to be used, we assume that slot
1, 3, 5, 7, 9, 11, 13 and 15 will be used. These slots will
carry a FlexE client flow beteween R1 and R3.
Hussain, et al. Expires December 29, 2017 [Page 17]
Internet-Draft FlexE Extensions June 2017
4. Node R1 informs node R3 about the intention to set up the 40
Gbit/s LSP and allocation of slots for the FlexE client.
5. When R3 receives the message from R1 it verifies that the
resources that R1 requests are available on the sub-link between
R1 and R3. If they are R3 will send a message to R4 requesting
a 20 Git/s FlexE LSP to be set up using for example slots 2, 4,
6, 8, 10 12, 14, and 16.
6. R4 verifies the availability of the resources, and if they are,
R4 will also identify that it is the termination point of the
intended LSP.
7. Being the termination point R4 will assigm a label for the FlexE
LSP. The label has the same format as MPLS Label specified in
RFC 3032 [RFC3032].
8. Node R4 respoond to the message requesting the set up of the
LSP, by a message indicating that the requested slots are
accepted used and the MPLS Label that shall be used.
9. When node R3 gets the response from R4, it respond to R1
indicating that the requested slots slots are accepted and the
MPLS label to be used.
10. Once R1 gets the response from R3 the LSP is ready to carry
traffic.
When the second LSP of 80 Gbit/s is set up (R2 - R3 - R4) is set up,
the procedures are the same, the only difference is that between R3
and R4 the second LSP needs to be allocated to the second FlexE group
between R3 and R4, since there is not enough bandwidth available on
the FlexE Group where the first LSP were allocated.
It should also be noted that if we want to set up a third 80 Gbit/s
LSP R5 - R3 - R4, this set up will fail. The reason is that even
though the total free bandwidth between R3 and R4 is 80 Git/s,
neither of the existing FlexE Groups has enough bandwidth to support
an 80 Gbit/s LSP. Bonding of FlexE Groups that carry traffic is not
possible.
It would be a good strategy for an operator to define a 200 Gbit/s
FlexE group from the start if it is anticipated that thre might be
situations where some FlexE client flows will use slots from both
PHYs.
Hussain, et al. Expires December 29, 2017 [Page 18]
Internet-Draft FlexE Extensions June 2017
6.3. FlexE Packet Label Switching Data Plane
This section discusses how the FlexE LSP data plane works. In
general it can be said that the interface offered by the FlexE Shim
and the FlexE client is equivalent to the interface offeredd by the
Ethernet MAC.
Figure 7 below illustrates the FlexE packet switching data plane
procedures.
R1 R3 R4
............. ...................... ...........
. +-------+ . . +----------------+ . . +-----+ .
. | LSP | . . | LSP \ / LSP | . . | LSP | .
. | a | . . | a \/ b | . . | b | .
. +-------+ . . +----------------+ . . +-----+ .
. | ETH | . . | ETH | | ETH | . . | ETH | .
. | i/f | . . | i/f | | i/f | . . | i/f | .
. +-------+ . . +-----+ +-----+ . . +-----+ .
. | FlexE | . . |FlexE| |FlexE| . . |FlexE| .
. | trsp | . . |trsp | |trsp | . . |trsp | .
. +---+---+ . . +--+--+ +--+--+ . . +--+--+ .
......|...... .....^..........|..... .....^.....
| | | |
+--------------------+ +--------------------+
Figure 7: FlexE LSP Data Plane
Note to reviewers: I'm not certain about the terminology for this
figure suggestions would be appreciated.
FlexE packet switching data plane processes packets like this:
o The LSP encapsulating and forwrding function in node R1 receives a
pack that needs to be encapsulated in an MPLS packet with the
label "a". The label "a" is used to figure out with FlexE
emulated Ethernet interfaces the label encapsulated packet need to
be forwarded over.
o The Ethernet interfaces, by means of FlexE transport, forwards the
packet to node R3. Node R3 swaps the label "a" to label "b" and
uses "b" to decide over which interface to send the packet.
o Node R3 forwards the packet to node R, which terminates the LSP.
Hussain, et al. Expires December 29, 2017 [Page 19]
Internet-Draft FlexE Extensions June 2017
Sending MPLS encapsulated packets over a FlexE sub-interface is
similar to send them over an Ethernet 802.1 interface. The critical
differences are:
o FlexE channelized sub-interfaces guarantee a deterministic
bandwidth for an LSP.
o FlexE allows for creating very large end to end bandwidth
7. Operations, Administration, and Maintenance (OAM)
To be added in a later version.
8. Acknowledgements
9. IANA Considerations
This memo includes no request to IANA.
Note to the RFC Editor: This section should be removed before
publishing.
10. Security Considerations
To be added in a later version.
11. Contributors
Khuzema Pithewan, Infinera Corp, kpithewan@infinera.com
Fatai Zhang, Huawei, zhangfatai@huawei.com
Jie Dong, Huawei, jie.dong@huawei.com
Zongpeng Du, Huawei, duzongpeng@huawei.com
Xian Zhang, Huawei, zhang.xian@huawei.com
James Huang, Huawei, james.huang@huawei.com
Qiwen Zhong, Huawei, zhongqiwen@huawei.com
Yongqing Zhu China Telecom zhuyq@gsta.com
Huanan Chen China Telecom chenhuanan@gsta.com
Hussain, et al. Expires December 29, 2017 [Page 20]
Internet-Draft FlexE Extensions June 2017
12. References
12.1. Normative References
[G.709] ITU, "Optical Transport Network Interfaces
(http://www.itu.int/rec/T-REC-G.709-201606-P/en)", July
2016.
[G.798] ITU, "Characteristics of optical transport network
hierarchy equipment functional blocks
(http://www.itu.int/rec/T-REC-G.798-201212-I/en)",
February 2014.
[G.8021] ITU, "Characteristics of Ethernet transport network
equipment functional blocks", November 2016.
[G.872] ITU, "Architecture of optical transport networks", January
2017.
[OIFFLEXE1]
OIF, "FLex Ethernet Implementation Agreement Version 1.0
(OIF-FLEXE-01.0)", 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>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>.
12.2. Informative References
[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,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<http://www.rfc-editor.org/info/rfc4203>.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
DOI 10.17487/RFC4204, October 2005,
<http://www.rfc-editor.org/info/rfc4204>.
Hussain, et al. Expires December 29, 2017 [Page 21]
Internet-Draft FlexE Extensions June 2017
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>.
Authors' Addresses
Iftekhar Hussain
Infinera Corp
169 Java Drive
Sunnyvale, CA 94089
USA
Email: IHussain@infinera.com
Radha Valiveti
Infinera Corp
169 Java Drive
Sunnyvale, CA 94089
USA
Email: rvaliveti@infinera.com
Qilei Wang
ZTE
Nanjing
CN
Email: wang.qilei@zte.com.cn
Hussain, et al. Expires December 29, 2017 [Page 22]
Internet-Draft FlexE Extensions June 2017
Loa Andersson
Huawei
Stockholm
Sweden
Email: loa@pi.nu
Mach Chen
Huawei
CN
Email: mach.chen@huawei.com
Haomian Zheng
Huawei
CN
Email: zhenghaomian@huawei.com
Hussain, et al. Expires December 29, 2017 [Page 23]