Common Control and Measurment Plane I. Hussain
Internet-Draft R. Valiveti
Intended status: Informational Infinera Corp
Expires: May 11, 2019 Q. Wang
ZTE
L. Andersson
M. Chen
H. Zheng
Huawei
November 7, 2018
GMPLS Routing and Signaling Framework for Flexible Ethernet (FlexE)
draft-izh-ccamp-flexe-fwk-06
Abstract
This document specifies GMPLS control plane requirements, framework,
and architecture for FlexE technology.
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 Recommendations.
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 https://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 May 11, 2019.
Hussain, et al. Expires May 11, 2019 [Page 1]
Internet-Draft FlexE Extensions November 2018
Copyright Notice
Copyright (c) 2018 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
(https://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. FlexE Reference Model . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. GMPLS Controlled FlexE . . . . . . . . . . . . . . . . . . . 7
5.1. Types of LSPs in a FlexE capable network . . . . . . . . 8
5.2. Signaling Channel . . . . . . . . . . . . . . . . . . . . 8
5.3. MPLS LSP in the FlexE Data Plane . . . . . . . . . . . . 8
5.4. Configuring the data plane in FlexE capable nodes . . . . 10
5.4.1. Configure/Establish a FlexE Group/Link . . . . . . . 10
5.4.2. Configure/Establish a FlexE Client . . . . . . . . . 11
5.4.3. Advertise FlexE Groups and FlexE lts . . . . . . . . 11
5.5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 11
5.5.1. Multi Layer Control Plane Typ-1 (MLCP-1) . . . . . . 12
5.5.2. Multi Layer Control Plane Typ-2 (MLCP-2) . . . . . . 12
5.5.3. Multi Layer Control Plane Typ-12 (MLCP-12) . . . . . 12
5.5.4. Multi Layer Control Plane Typ-3 (MLCP-3) . . . . . . 13
6. Framework and Architecture . . . . . . . . . . . . . . . . . 13
6.1. FlexE Framework . . . . . . . . . . . . . . . . . . . . . 13
6.2. FlexE Architecture . . . . . . . . . . . . . . . . . . . 13
6.2.1. Architecture Components . . . . . . . . . . . . . . . 13
6.2.2. FlexE Layer Model . . . . . . . . . . . . . . . . . . 14
6.2.2.1. FlexE Group structure . . . . . . . . . . . . . . 14
6.2.2.2. FlexE Client mapping . . . . . . . . . . . . . . 14
7. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. GMPLS Routing . . . . . . . . . . . . . . . . . . . . . . 15
7.2. GMPLS Signaling . . . . . . . . . . . . . . . . . . . . . 16
7.2.1. LSP setup with pre-configured FlexE infrastructure . 17
7.2.2. LSP setup with partially configured FlexE
infrastructure . . . . . . . . . . . . . . . . . . . 17
Hussain, et al. Expires May 11, 2019 [Page 2]
Internet-Draft FlexE Extensions November 2018
7.2.3. LSP setup with non-configured FlexE infrastructure . 18
7.2.4. Packet Label Switching Data Plane . . . . . . . . . . 18
8. Operations, Administration, and Maintenance (OAM) . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 21
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 for channelization within a single PHY, or over a group
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)
Hussain, et al. Expires May 11, 2019 [Page 3]
Internet-Draft FlexE Extensions November 2018
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.
These logical point-to-point 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 draft considers the variants in which the two peer FlexE devices
are both customer-edge devices, or when one is a customer-edge and
the other is provider edge devices. This list of use cases will help
identify the Control Plane (i.e. Routing and Signaling) 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. CE (Customer Edge) - the group of functions that support the
termination/origination of data received from or sent to the
network
b. Ethernet PHY: an entity representing Physical Coding Sublayer
(PCS), Physical Media Attachment (PMA), and Physical Media
Dependent (PMD) layers.
c. 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
Hussain, et al. Expires May 11, 2019 [Page 4]
Internet-Draft FlexE Extensions November 2018
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).
d. FlexE Client: An Ethernet flow based on a MAC data rate that may
or may not correspond to any Ethernet PHY rate.
e. 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}.
f. FlexE Shim: the layer that maps or demaps the FlexE client flows
carried over a FlexE Group.
g. LMP: Link Management Protocol
h. LSP: Label Switched Path
i. OTN: Optical Transport Network
j. SG15: ITU-T Study Group 15 (Transport, Access and Home).
k. TE: Traffic Engineering
l. TED: Traffic Engineering Database
3. FlexE Reference Model
The figure below gives a simplified FlexE reference model.
Hussain, et al. Expires May 11, 2019 [Page 5]
Internet-Draft FlexE Extensions November 2018
...................................
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 1: FlexE Reference Model
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
setup by a GMPLS control plane there is a strong connection oriented
aspect.
4. Requirements
This section summarizes the control plane requirements for FlexE
Group and FlexE Client signaling and routing.
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.
Hussain, et al. Expires May 11, 2019 [Page 6]
Internet-Draft FlexE Extensions November 2018
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.
Req-6 The solution SHALL support the ability to advertise and
discover information about FlexE capable nodes, and the FlexE
Groups and FlexE Clients they support.
Req-7 The system SHALL allow the addition (or removal) of one or
more FlexE clients on aFlexE Group. The addition (or
removal) of a FlexE client flow SHALL NOT affect the services
for the other FlexE client signals.
Req-8 The system SHALL allow the FlexE client signals to flexibly
span the set of Ethernet PHY(s) which comprise the FlexE
Group.
Req-9 The solution SHALL support FlexE client flow resizing without
affecting any existing FlexE clients within the same FlexE
Group.
Req-10 The solution SHALL support establishment of MPLS LSPs that
requires the support of a FlexE infrastructure.
5. GMPLS Controlled FlexE
The high level goals for using a GMPLS control plane for FlexE can be
summarized as:
o Set up a FlexE Group
o Set up a FlexE Client
o Advertise FlexE Groups and FlexE Clients
o Set up of a higher layer LSP that requires to be run over a FlexE
infrastructure.
Hussain, et al. Expires May 11, 2019 [Page 7]
Internet-Draft FlexE Extensions November 2018
5.1. Types of LSPs in a FlexE capable network
The FlexE infrastructure may be established in three different ways
o The FlexE Groups and FlexE Client may be pre-configured
o Only the FlexE groups may be pre-configured, while the setup of
the FlexE client is triggered by the request to setup a MPLS LSP
o The setup of both FlexE Group and FlexE Client may be triggered by
the request to setup an MPLS LSP.
5.2. Signaling Channel
In the type of equipment for which FlexE was first specified an out
of band signaling channel is not commonly available. If that is the
case, and the GMPLS FlexE control plane will be used, the FlexE Group
will have to setup by e.g. a management system and a FlexE Client on
that FlexE Group (also configured) will have to allocated as a
signaling channel.
Further details of the setup of the FlexE Groups, FlexE Clients and
MPLS LSPs over a FlexE infrastructure will be found in Section 7.2.
5.3. MPLS LSP in the FlexE Data Plane
FlexE is a true link layer technology, i.e. it is not switched, this
means that the FlexE Groups and FlexE Clients are terminated on the
next-hop node, and that the switching needs to take place on a higher
layer.
The FlexE technology can be used to establish link layer connectivity
with high and deterministic bandwidth. However, there is no way to,
in a deterministic way, allocate certain traffic to a specific FlexE
Client. A GMPLS control plane can do this.
A GMPLS controlled FlexE capable node may be thought of using the
traditional model of a node with a separation between control and
data plane.
Hussain, et al. Expires May 11, 2019 [Page 8]
Internet-Draft FlexE Extensions November 2018
+------------------+
| +------------+ |
| | GMPLS | |
| | Control | |
| | Plane | |
| +------------+ |
| ^ |
| | |
| v |
| +------------+ |
| | FlexE | |
| | Data | | ^
| | Plane | |
| +------------+ |
+------------------+
Figure 2: GMPLS controlled FlexE Node
The GMPLS control plane will speak extended standard GMPLS protocols
with its neighbours and peers.
Node A Node B Node Z
+--CP
+-|-----------+ |------------------+ ~ +---------+
| | | | | | |
| | +------+ | | +--------------+ | | +-----+ |
LSP | +->| v | | | | ....x..... | | | | ^ | |
| | | . | | | | . . | | | | . | |
| | +--.---+ | | +--.--------.--+ | | +--.--+ |
FlexE | +->| o | | | | o | | o | | | | o | |
Client | | | o | | | | o | | o | | | | o | |
| | +--o---| | | +--o--+ +--o--+ | | +--o--| |
FlexE | +->| U | | | | U | | U | | | | U | |
Group | | U | | | | U | | U | | | | U | |
| +--U---| | | +--U--+ +--U--+ | | +--U--+ |
|-------U-----+ +----U--------U----+ +----U----+
U U U U
UUUUUUUUUUUUUUUUUUUUU UUUUUUU ~ UUUUUUUU
Legend ... = LSP
ooo = FlexE Client
UUU = FlexE Group
Figure 3: GMPLS controlled network with FlexE infrastructure
Hussain, et al. Expires May 11, 2019 [Page 9]
Internet-Draft FlexE Extensions November 2018
Figure 3 describes how an MPLS LSP is mapped over a FlexE Client and
FlexE Group.
5.4. Configuring the data plane in FlexE capable nodes
In Figure 3 we show an LSP, a FlexE Client and a FlexE Group, the LSP
is there because while the FlexE Channel and Group are not switched,
switching in our example takes place on the LSP level. This section
will discuss establishment of FlexE Clients and Groups, and mapping
of the LSP onto a FlexE Client.
The establishment of a LSP over a FlexE system is very similar to how
this is done in any other system. Building on information gathered
through the routing system and using the GMPLS signaling to establish
the LSP.
5.4.1. Configure/Establish a FlexE Group/Link
Consider the setup of a FlexE Group between node A and B,
corresponding to the row of U's from node A to B in Figure 3. The
FlexE group is considered to consist of n PHYs, but does not have any
FlexE Clients defined from start.
When this is done by the GMPLS control plane, two conditions need to
be fulfilled (1) there need to be a data channel defined between node
A and B; and (2) a FlexE capable IGP-TE protocol needs to be running
in the network.
Node A will send an RSVP-TE message to node be with the information
describing the FlexE Group to be setup. This information might be
thought of as the "FlexE Group Label" (or part of the FlexE label).
It will contain at least the following information:
o A FlexE Group Identifier (FGid).
o The number of active FlexE Channels (numFC), where 0 indicates
that zero clients are active.
o Number of PHYs that the FlexE Group is composed of, for each PHY
* PHY identifier
* PHY bandwidth
* slot granularity/number of slots
* available and unavailable slots
Hussain, et al. Expires May 11, 2019 [Page 10]
Internet-Draft FlexE Extensions November 2018
When node B receives the RSVP-TE message it checks that it can setup
the requested FlexE Group. If the check turns positive, node send an
acknowledgment to node A and the FlexE Group is setup.
A more detailed description of how to setup a FlexE Group, will be
included in the draft dealing with signaling in detail.
5.4.2. Configure/Establish a FlexE Client
Consider the situation where a FlexE Group is already established (as
described in Section 5.4.1) and an m G FlexE Client is needed.
Similar to the establishment of the FlexE Group, node A will send a
RSV-TE message to node B.
This RSVP-TE message include at least the following information:
o FlexE Group Identifier
o FlexE Client Identifier
o from which PHYs the slots will allocated, i.e. slots might come
from more than one PHY.
o Information per PHY
* PHY bandwidth
* slot granularity
* available/unavailable slots
* allocated slots
A more detailed description of how to setup a FlexE Channel, will be
included in the draft dealing with signaling in detail.
5.4.3. Advertise FlexE Groups and FlexE lts
Once the FlexE Group and FlexE CLielts are configured they can be
advertised into the routing system as normal routing adjacencies,
including the FlexE specific TE information.
5.5. Open Issues
Note: This section is intended to be removed and the results of the
discussion are supposed to brought into the relevant sections of this
document.
The intention is to trigger this discussion.
Hussain, et al. Expires May 11, 2019 [Page 11]
Internet-Draft FlexE Extensions November 2018
While working on the FlexE Control Plane, questions around the
relationship of entities as "control plane / multi-layer control
plane", RSVP-TE session and the information relating to a layer
network. The table below summarizxes the possibilities we see.
+-----------+---------------------+---------------------------------+
| Control | Session | Network layer info |
| Plane | | |
+-----------+---------------------+---------------------------------+
| MLCP-1 | One session | Info for all network layers |
| MLCP-2 | Sesion for each | Each session have info for one |
| | network layer | network layer |
| MLCP-12 | More than one | info for each network layer |
| | sesion | included in the session |
| MLCP-3 | One sesion | info for a single network layer |
+-----------+---------------------+---------------------------------+
Table 1: Multi-layer CP types
Sections Section 5.5.1 to Section 5.5.4 shortly describes the
different types of control plane identified.
5.5.1. Multi Layer Control Plane Typ-1 (MLCP-1)
A multi layer control plane type 1 (MLCP-1) has one single control
plane that that controls all layer networks that two nodes interact
over. The control plane sets up one single RSVP-TE session and all
layer networks are controlled over that single session. For each
layer network there is a set of information that the control plane
manages over that session.
5.5.2. Multi Layer Control Plane Typ-2 (MLCP-2)
A multi layer control plane type 2 (MLCP-2) has one single control
plane that that controls all layer networks that two nodes interact
over. The control plane sets up one RSVP-TE session for each layer
network and the layer networks are controlled over a dedicated
session. For each layer network there is a set of information that
the control plane manages over the dedicated session.
5.5.3. Multi Layer Control Plane Typ-12 (MLCP-12)
A multi layer control plane type 12 (MLCP-12) is a mix between MLCP-1
and MLCP-2, the control plane still controls all layer networks that
two nodes interact over. However, for some layer networks it set up
a RSVP-TE session the may control more than one layer network. For
other layer network an RSCP-TE session is used to control a single
Hussain, et al. Expires May 11, 2019 [Page 12]
Internet-Draft FlexE Extensions November 2018
layer network. For each layer network there is a set of information
that the control plane manages over dedicated sessions.
5.5.4. Multi Layer Control Plane Typ-3 (MLCP-3)
A multi layer control plane type 3 (MLCP-3) may be viewed as a set of
confederated control plsnes, where each control plane controls one
layer network, via a RSVP-TE session. For each layer network there
is a set of information that the control plane manages over the
dedicated session. For the case that there are more than one layer
network between two nodes that needs to controlled, there is one
dedicated control plane for each layer network.
6. Framework and Architecture
This section discusses FlexE framework and architecture. Framework
is taken to mean how FlexE interoperates with other parts of the data
communication system. Architecture is taken to mean how functional
groups and elements within FlexE work together to deliver the
expected FlexE services. Framework is taken to mean how FlexE
interacts with it environment.
6.1. FlexE Framework
The service 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 setup as a configuration activity,
by a centralized controller or by a GMPLS control plane the
service is connection oriented.
6.2. FlexE Architecture
6.2.1. Architecture Components
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 setup of higher layer LSPs, like Ethernet PHYs'
information, partial-rate support information. Based on the resource
available information advertised by routing protocol, an end-to-end
Hussain, et al. Expires May 11, 2019 [Page 13]
Internet-Draft FlexE Extensions November 2018
FlexE connection is computed, and then the signaling protocol is used
to set up the end-to-end connection.
FlexE signaling mechanism is used to setup LSPs.
MPLS forwarding over a FlexE infrastructure is different from
forwarding over other infrastructures. When MPLS runs over a FlexE
infrastructure it is possible that there are more than FlexE Client
that meet the next-hop requirements, often it is possible to use any
suitable FlexE Clientfor a hop between two nodes. If the mapping
between a MPLS encapsulated packet and the FlexE Client, this mapping
need to be explicit when the LSP is set up, and the MPLS label will
be used to find the correct FlexE Client.
6.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.
6.2.2.1. FlexE Group structure
The FlexE Group might be supported by virtually 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.
6.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.
Hussain, et al. Expires May 11, 2019 [Page 14]
Internet-Draft FlexE Extensions November 2018
7. 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 setup higher layer LSPs. A configuration tool, a
centralized controller or the GMPLS control plane can all be used.
To create the FlexE GMPLS control plane Groups, FlexE Clients and
higher layer LSPs, extensions to the following protocols may be
needed:
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 7.2 and Section 7.1 discusses the role of the GMPLS control
plane when primarily setting up LSPs.
When discussing the signaling and routing procedures we assume that
the FlexE group has been established prior to executing the
procedures needed to establish an LSP. Technically it is possible to
establish FlexE group, allocate FlexE client slots and LSP with a
single exchange of GMPLS signaling messages.
7.1. GMPLS Routing
To establish an LSP the Traffic Engineering (TE) information is the
most critical information, e.g. resource utilization 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.
Hussain, et al. Expires May 11, 2019 [Page 15]
Internet-Draft FlexE Extensions November 2018
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 an LSP over the FlexE infrastructure is about to be setup, e.g.
R1 - R4 - R5 in Figure 4 the information in the TED is used verify
that resources are available. When it is conformed that the LSP is
established the TED is updated, marking the resources used for the
new LSP as used. Similarly when a LSP is taken down the resources
are marked as free.
7.2. GMPLS Signaling
As described in Section 5 the state of the FlexE infrastructure may
effect the actions needed to setup an LSPin a FlexE capable network.
The FlexE infrastructure maybe be:
1. fully pre-configured
2. partially pre-configured, i.e. the FlexE Group may be pre-
configured, but not the FlexE Clients
3. not pre-configured, i.e. the setup of FlexE Group and FlexE
Client will be triggered because of the request to setup an LSP.
Figure 4 will be used to illustrate the different cases.
+----+
| R1 +---------------------+
+----+ |
|
+----+ +--+--+ +----+
| R2 +------------------+ R4 +-------------------------+ R5 |
+----+ +--+--+ +----+
|
+----+ |
| R3 +---------------------+ PHY R1 to R4 100 Gbit(s
+----+ PHY R2 to R4 100 Gbit(s
PHY R3 to R4 100 Gbit(s
PHY R4 to R5 200 Gbit(s
Figure 4: FlexE LSP Example
Hussain, et al. Expires May 11, 2019 [Page 16]
Internet-Draft FlexE Extensions November 2018
The text in Section 7.2 is not a specification of the GMPLS signaling
extensions for FlexE capable network, it is a description to
illustrate the expected features of such a protocol. Nor do we
discuss failure scenarios.
7.2.1. LSP setup with pre-configured FlexE infrastructure
In this first example, referencing Figure 4, one 100 Gbit/s FlexE
group is configured between R1 and R4, between R2 and R4, and between
R3 and R4. Between R4 and R5 there is a 200 Gbit/s FlexE Group.
Over each 100 Gbit/s FlexE Group there are four 5 Gbit/s, two 20
Gbit/s and one 40 Gbit/s FlrxE Clients configured. Over the 200 Git/
s FlexE Group there are eoght 5 Gbit/s, four 20 Gbit/s and tow 40
Gbit/s FlrxE Clients configured.
One of the 5 Gbit/s FlexE Clients on each FlexE Groups are used as
signaling channel.
To establish the for example a 200 Mbit/s MPLS LSP the normal GMPLS
request/response procedures are followed. R1 sends the request to
R4, R4 allocate resources on one of the FlexE Ckients, forward the
request to R5. R5 responds to R4 indicating the label and the FlexE
Client the traffic should be sent over, R4 does the same for R1.
The only difference between the standard signaling and what happens
here is that there the assigned label will be used to find the right
FlexE Client.
7.2.2. LSP setup with partially configured FlexE infrastructure
In the second example, also referencing Figure 4, the FlexE Groups
are set up in the same way as in the first example, however only one
5 Gbit/s FlexE Client per FlexE Group are established by
configuration. This FlexE Client will be used for signaling.
When preparing to send the request that a 5 Gbit/s MPLS LSP shall be
set up R1 discovers that there are no feasible FlexE Client between
R1 aand R4. R1 therefore sends the request to establish such a FlexE
Client, when receiving the request R4 allocates resources for the
FlexE Client on the FlexE Group. There may be different strategies
for allocating the bandwidth for this FlexE client. Such strategies
are out of scope for this document. R1 then sends the information
about the FlexE Client to R1, and both ends establish the FlexE
Client.
When the FlexE Client between R1 and R4 is established, R1 proceeds
to send the request for an MPLS LSP to R4. R4 will discover that a
Hussain, et al. Expires May 11, 2019 [Page 17]
Internet-Draft FlexE Extensions November 2018
feasible FlexE Client is missing between R4 and R5. The same
procedure s for setting up the FlexE Client between R1 and R4 is
repeated for R4 and R5. When there is a feasible FlexE Client
available the signaling to set up the MPLS LSP continues as normal.
The label allocated for the MPLS LSP will be used to find the correct
FlexE Client.
When a FlexE Clients is set up in this way they can be announced into
the routing system in two different ways. First, they can be made
generally available, i.e. it will be free to use for anyone that want
to set up LSPs over the FlexE Group between R1 and R4 and between R4
and R5. Second, the use of the FlexE Clients may be restricted to
the application that initially did set up the FlexE Client.
7.2.3. LSP setup with non-configured FlexE infrastructure
This example also refers to Figure 4 as different from the earlier
example no FlexE Group or FlexE Client configuration is done prior to
the first request for an MPLS LSP over the FlexE infrastructure.
To make the set up of LSPs in a FlexE network where no FlexE Groups
or FlexE Clients have been configured two conditions need to be
fulfilled. First an out of band signaling channel must be available.
Second the FlexE Capabilities must be announced in to the IGP and/or
centralized controller.
If these two conditions are fulfilled, the set up of an MPLS LSP
progress pretty much as in the partially configured network. The
difference is that the set up of both the FlexE Group and FlexE
Client are triggered by the request to set up an MPLS LSP.
As in the partially configured case FlexE Clients can be announced
into the routing system in two different modes, either they are
generally availble. It or they are reserved for the applications
that first established them.
7.2.4. 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 offered by the
Ethernet MAC.
Figure 5 below illustrates the FlexE packet switching data plane
procedures.
Hussain, et al. Expires May 11, 2019 [Page 18]
Internet-Draft FlexE Extensions November 2018
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 5: LSP over FlexE Data Plane
The data plane processes packets like this:
o The LSP encapsulating and forawrding function in node R1 receives
a packet that needs to be encapsulated as an MPLS packet with the
label "a". The label "a" is used to figure out which 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.
Sending MPLS encapsulated packets over a FlexE Client 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 When a application that originally establish a FlexE Client
reserve it for use by that application only, it is possible to
create uninfringeable bandwidth end-to-end for an MPLS LSP.
o FlexE infrastructure allows for creating very large end to end
bandwidth
Hussain, et al. Expires May 11, 2019 [Page 19]
Internet-Draft FlexE Extensions November 2018
8. Operations, Administration, and Maintenance (OAM)
To be added in a later version.
9. Acknowledgements
10. IANA Considerations
This memo includes no request to IANA.
Note to the RFC Editor: This section should be removed before
publishing.
11. Security Considerations
To be added in a later version.
12. 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
13. References
13.1. Normative References
[G.709] ITU, "Optical Transport Network Interfaces
(http://www.itu.int/rec/T-REC-G.709-201606-P/en)", July
2016.
Hussain, et al. Expires May 11, 2019 [Page 20]
Internet-Draft FlexE Extensions November 2018
[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,
<https://www.rfc-editor.org/info/rfc2119>.
13.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,
<https://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,
<https://www.rfc-editor.org/info/rfc4203>.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
DOI 10.17487/RFC4204, October 2005,
<https://www.rfc-editor.org/info/rfc4204>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://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,
<https://www.rfc-editor.org/info/rfc5440>.
Hussain, et al. Expires May 11, 2019 [Page 21]
Internet-Draft FlexE Extensions November 2018
[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,
<https://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
Loa Andersson
Huawei
Stockholm
Sweden
Email: loa@pi.nu
Mach Chen
Huawei
CN
Email: mach.chen@huawei.com
Hussain, et al. Expires May 11, 2019 [Page 22]
Internet-Draft FlexE Extensions November 2018
Haomian Zheng
Huawei
CN
Email: zhenghaomian@huawei.com
Hussain, et al. Expires May 11, 2019 [Page 23]