Internet DRAFT - draft-jiang-ccamp-flexe-ifmps
draft-jiang-ccamp-flexe-ifmps
Network Working Group Y. Jiang
Internet Draft F. Yang
Intended status: Informational I. Busi
Huawei
J. Wang
Fiberhome
Expires: May 2020 November 4, 2019
Problem Statements of FlexE Interface Management
draft-jiang-ccamp-flexe-ifmps-00
Abstract
This document outlines the problem statements for FlexE interface
management; it also gives an analysis of configuration requirements
for Flex Ethernet (FlexE) interface management. Requirements on FlexE
interface management are summarized in the end.
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 April 4, 2020.
Copyright Notice
Copyright (c) 2019 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
Jiang, et al Expires May 4, 2020 [Page 1]
Internet-Draft FlexE Management PS November 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ........................................ 2
1.1. Conventions used in this document ................ 3
1.2. Terminology ...................................... 4
2. Problem statements .................................. 4
2.1. Overview of FlexE management ..................... 4
2.2. Considerations on parameters in FlexE Overhead ... 5
2.2.1. Static or configurable .......................... 6
2.2.2. Negotiation enable or not ....................... 7
2.2.3. Management of FlexE clients ..................... 7
2.3. Considerations on bidirectional transport ........ 8
3. Requirements ........................................ 9
4. Security Considerations ............................ 10
5. IANA Considerations ................................ 10
6. References ......................................... 10
6.1. Normative References ............................ 10
6.2. Informative References .......................... 10
7. Acknowledgments .................................... 10
1. Introduction
The Flex Ethernet (FlexE) 2.0 Implementation Agreement
[FLEXE] defined by the OIF provides the support of a
variety of Ethernet MAC rates that may or may not
correspond to any existing Ethernet PHY rate. This
includes MAC rates that are both greater than (through
bonding) and less than (through sub-rate and
channelization) the Ethernet PHY rates used to carry
FlexE.
Besides 100GBASE-R PHYs as supported in FlexE 1.0, FlexE
2.0 supports the bonding of 200GBASE-R PHYs or 400GBASE-R
PHYs respectively. FlexE 2.1 further supports the bonding
of 50GBASE-R PHYs.
According to [FLEXE], FlexE supports the following
features:
- Bonding of multiple ETH PHYs (1~254)
Jiang, et al Expires May 4, 2020 [Page 2]
Internet-Draft FlexE Management PS November 2019
- Sub-rates of ETH PHY (minimum of 5G to maximum capacity
of bandwidth in a PHY)
- Channelization within a PHY or a group of bonded PHYs
(5G ~ k*5G, combination of multiple slots, where each
slot can be allocated from any PHY)
In the FlexE, multiple Ethernet PHYs (each PHY can
further consist of one or more FlexE Instances) are
bonded into a FlexE Group, and the total capacity of the
FlexE Group is represented as a collection of slots (e.g.,
each slot has a granularity of 5Gbps or 25Gbps). Based
on their bandwidth needs, FlexE Clients are each
allocated with one or more slots in a FlexE group. The
FlexE mechanism operates by using a calendar consisting
of these slots.
This calendar is partitioned into sub-calendars for each
PHY (earlier than FlexE 2.0) or sub-calendars for each
FlexE instance (FlexE 2.0 and above). For example, the
calendar for a FlexE Group composed of n 100G PHYs is
partitioned into 20n slots (each slot representing 5Gbps
of bandwidth when the slot granularity is 5Gbps).
Some FlexE use cases are introduced in details in [flexe-
usecases].
This document describes the problem statements for FlexE
interface management to support the transport of FlexE
clients over a FlexE Group between two FlexE nodes. The
equipment can be routers or optical transport products,
which can support FlexE interfaces. Multiple hops of
FlexE aware transport in OTN or MTN is out of the scope
of this document.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.
Jiang, et al Expires May 4, 2020 [Page 3]
Internet-Draft FlexE Management PS November 2019
1.2. Terminology
Terminologies used in this document are extracted from
[FLEXE].
FlexE: Flex Ethernet.
FlexE Client: An Ethernet flow based on a MAC data rate
that may or may not correspond to any Ethernet PHY rate,
the format of the FlexE Client is simply a logically
serial stream of 66B blocks at a given rate.
FlexE Group: A FlexE Group is composed of from 1 to n
Ethernet PHYs.
FlexE Instance: A FlexE Instance is a unit of information
consisting of 100G of capacity able to carry FlexE Client
data, together with its associated overhead.
Ethernet PHY: an entity representing Ethernet Physical
Coding Sublayer (PCS), Physical Media Attachment (PMA),
and Physical Media Dependent (PMD) layers. Each PHY is
consisted of one or more FlexE Instance (e.g., a
400GBASE-R PHY has four FlexE Instances).
FlexE Calendar: The total capacity of a FlexE Group is
represented as a collection of slots. The calendar for a
FlexE Group composed of n PHYs is represented in each PHY
as an array of slots (e.g., each representing 5Gbps of
bandwidth), i.e., calendar-slot-list.
CCA: Calendar Configuration A
CCB: Calendar Configuration B
2. Problem statements
2.1. Overview of FlexE management
Figure 1 depicts the overview diagram of FlexE management
for a FlexE Group between PE1 and PE2, where PE1 and PE2
are network equipments such as routers or OTN products.
SDN/NMS may control or manage the FlexE Group between PE1
and PE2 by interactions with PE1 and PE2 separately (by
using Netconf or Restconf to connect with a management or
control agent on each PE node).
Jiang, et al Expires May 4, 2020 [Page 4]
Internet-Draft FlexE Management PS November 2019
+-----------+
| |
| SDN/NMS |
| |
+-----------+
// \\
// \
// \\
// \
// \\
+-----------* FlexE Group *-----------+
| | -- PHY1 | |
| PE1 +----/--\----------------+ PE2 |
| | | | PHY2 | |
| +---+----+---------------+ |
| | | | PHYn | |
| +---+----+---------------+ |
| | \ / | |
| | -- | |
| | | |
+-----------+ +-----------+
Figure 1: FlexE management overview
2.2. Considerations on parameters in FlexE Overhead
The OIF specifies how the configuration and verification
of a FlexE Group can be realized in Section 7.3 of
[FLEXE]. A FlexE Overhead Frame is defined in [FLEXE] to
convey FlexE group specific information from PE1 to PE2,
including configuration information (FlexE Group Number,
FlexE Map, FlexE PHY/Instance Number, CCA and CCB),
status information (RPF) and signaling information (CC,
CR and CA).
The configuration information in the overhead frame is
used by the receiving side to verify that both ends are
properly configured with the same set of values in a
FlexE Group. If PE2 finds out that the configuration
Jiang, et al Expires May 4, 2020 [Page 5]
Internet-Draft FlexE Management PS November 2019
information in the overhead sent from PE1 does not match
its own configuration, a mismatch alarm should be raised.
Note: Two calendar configurations are used in the FlexE
data plane to facilitate reconfiguration, i.e., CCA and
CCB. They are actually two lists (e.g., each list is
20*2Bytes for a PHY of 100GBASE-R; or 4*20*2Bytes for a
PHY of 400GBASE-R) wherein each list item indicates the
client number carried in a calendar slot. At any given
time, only one of the calendar configurations is active
and used for mapping the FlexE Clients into the FlexE
Group and demapping the FlexE Clients from the FlexE
Group. When a switch of calendar configurations
adds/removes/resizes FlexE Clients in a FlexE Group, the
switching does not affect existing clients whose size and
calendar slot assignments are not changed.
Status information indicates status of the bonded PHYs,
currently only RPF (Remote PHY Fault) is defined in
[FLEXE], which informs the far-end of a locally detected
failure of the PHY if set to one.
The signaling information can be used to coordinate the
switching from the active calendar configuration (e.g.,
CCA) to the backup calendar configuration (e.g., CCB)
between PE1 and PE2. As described in 7.3.4 of [FLEXE], CC,
CR and CA are used to coordinate the switching of
calendar A to calendar B or vice versa between the FlexE
mux and FlexE demux (i.e., the source and the sink of a
FlexE group). The protocol is optional to implement.
2.2.1. Static or configurable
If the FlexE is static, a FlexE Group is composed of a
fixed number of FlexE PHYs, e.g., simple bonding for a
single fixed client; fixed calendar configuration. That
means, there is no need to configure a device or it is
impossible to configure the device. Some simple
implementations only support static configuration.
If the FlexE is configurable, the FlexE parameters can be
controlled by a SDN controller or be configured by a
network management system (NMS).
A FlexE static PE usually interconnect with another PE in
FlexE static (it is required that both PEs implement a
FlexE group with exact the same set of fixed parameter
Jiang, et al Expires May 4, 2020 [Page 6]
Internet-Draft FlexE Management PS November 2019
values). However, sometimes there is a need to
interconnect one FlexE static PE with another PE in FlexE
configurable if the latter is properly configured with
the same set of fixed parameter values.
2.2.2. Negotiation enable or not
[FLEXE] uses two calendar configurations (i.e., CCA and
CCB) to facilitate client reconfiguration. Furthermore,
Section 7.3 of [FLEXE] specifies a dynamic negotiation
protocol (by signaling in the FlexE overhead) for the
automatic switching of calendars in a FlexE Group. If
this negotiation protocol is enabled (if one PE enables
negotiation, the other PE MUST enable negotiation too), a
receiving PE (i.e., slave) can further extract the
configuration information (particularly CCA and CCB) from
the FlexE overhead and multi-frame sent from a sending PE
(i.e., master).
It seems that the slave does not need to configure any
FlexE parameters if negotiation protocol is enabled.
However, from the viewpoint of bidirectional transport, a
receiving PE in one direction is also acting as a sending
PE in the other direction. Furthermore, FlexE group and
its bonding PHYs must be configured firstly so that FlexE
overhead channel can be set up for the signaling protocol
to work properly. Therefore, FlexE configuration is
needed on both side of PEs even if negotiation is enabled.
Since the dynamic signaling of CC, CR and CA is done
automatically in the data plane (especially, CR and CA
are request and acknowledgement exchanged dynamically
over the FlexE overhead, CC decides whether CCA or CCB is
active), the mechanism works on the FlexE data plane
independent from the management plane. Exposing all these
signaling information to the management plane is not only
unnecessary, but also greatly complicates the operations
of FlexE. Thus, it is not needed to configure or retrieve
these ephemeral signaling states.
2.2.3. Management of FlexE clients
The following management of FlexE clients needs to be
supported:
-Add a client or clients
Jiang, et al Expires May 4, 2020 [Page 7]
Internet-Draft FlexE Management PS November 2019
-Delete a client or clients
-resize a client or clients
-adjust slot locations for a client or clients
If the negotiation protocol is not enabled, management of
FlexE clients (add/delete/resize/adjust) usually is a
sequential action to the current calendar of each FlexE
PE, and retrieval of the calendar configuration values is
also based on the active calendar. Thus, synchronous
switching from the active calendar configuration to the
backup calendar configuration is not needed. However,
some client traffic may be lost during the
reconfiguration.
If the negotiation protocol is enabled, management of
FlexE clients (add/delete/resize/adjust) usually is a
sequential action to the backup calendar of each FlexE PE.
Then dynamic negotiation as described in Section 2.2.2
controls peer PEs to switch the backup calendar
configuration into the active calendar configuration
synchronously. The switching is hitless since the client
traffic is not lost during the reconfiguration, thus it
is recommended to be the default working mode. Moreover,
retrieval of the calendar configuration values SHOULD be
based on the new active calendar after protocol
convergence (the convergence time is expected to be
around 10ms calculated according to [FLEXE]).
In either cases, the management plane only needs to deal
with a single calendar, and there is no need to monitor
whether the calendar is CCA or CCB from the SDN/NMS point
of view.
2.3. Considerations on bidirectional transport
OIF only discusses the configuration of a unidirectional
client.
In fact, the overhead signaling of CR and CA relies on a
bidirectional channel in the same FlexE Group.
Furthermore, the FlexE links (including each of the
bonding PHYs) are always bidirectional, and FlexE clients
Jiang, et al Expires May 4, 2020 [Page 8]
Internet-Draft FlexE Management PS November 2019
are usually reserved with the same number of slots (or
bandwidth) in both directions over the same FlexE link.
For a FlexE client, the expected value of FlexE
parameters to be received will be the same as the values
of those parameters configured in the transmit direction
on the same PE, thus the expected parameters are not
needed to be configured explicitly. If the received
parameters are not the same values as those parameters
configured locally, a PE should report the mismatch to
the SDN controller/NMS. Examples of mismatch may include:
FlexE group number mismatch, FlexE PHY number mismatch,
Calendar configuration Mismatch, and etc.).
3. Requirements
This section summarizes the management requirements of
FlexE interfaces.
a). Support of a flexible FlexE group bonding with one to
254 Ethernet PHYs, the Ethernet PHY types may include 50
GBASE-R, 100GBASE-R, 200GBASE-R and 400GBASE-R.
b). Support add/remove Ethernet PHYs to/from a FlexE
group, the range of FlexE PHY number still follows a).
c). Support of flexible FlexE client management in a
FlexE group, and the total clients number can be in a
range of from 0 to a value equal to the maximum number of
slots in the FlexE group (that is, each client is
allocated a single slot).
d). Support add/delete/resize FlexE clients in a FlexE
group without impacts on the traffic of any existing
FlexE clients in the same FlexE group, the range of FlexE
client number still follows c).
e). Support FlexE static or FlexE configurable operations.
f). Support coordination of calendar updates and
switchover by enabling FlexE negotiation between peer
FlexE PEs.
g). Support a client with bidirectional slot allocation
while its bandwidth can be inferred from the allocated
slot number and slot granularity.
Jiang, et al Expires May 4, 2020 [Page 9]
Internet-Draft FlexE Management PS November 2019
h). Support retrieval status of a FlexE group, a FlexE
PHY, or a FlexE client.
i). Management shall be compatible as much as possible
with all OIF FlexE versions, including 1.0, 1.1, 2.0 and
2.1.
4. Security Considerations
This document gives the problem statements for FlexE
management, and summarizes the requirements. As no
solution is discussed in this document, no security
concerns are raised.
5. IANA Considerations
There are no IANA actions required by this document.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase
in RFC 2119 Key Words", BCP 14, RFC 8174, May
2017
6.2. Informative References
[FLEXE] OIF, "Flex Ethernet 2.0 Implementation
Agreement", FlexE 2.0, June 2018
[flexe-usecases] Hussain, I., Valiveti, R., Pithewan, K.,
"FlexE Usecases", draft-hussain-ccamp-flexe-
usecases-01, work in progress
7. Acknowledgments
The authors would like to thank Jinfeng Chen and Yalei
Han for their contribution to this document.
Jiang, et al Expires May 4, 2020 [Page 10]
Internet-Draft FlexE Management PS November 2019
Authors' Addresses
Yuanlong Jiang
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129, China
Email: jiangyuanlong@huawei.com
Fan Yang
Huawei Technologies Co., Ltd.
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
Email: shirley.yangfan@huawei.com
Italo Busi
Huawei Technologies Co., Ltd.
HUAWEI TECHNOLOGIES ITALIA Srl Centro Direzionale Milano 2
Milan, Milan 20090, Italy
Email: Italo.Busi@huawei.com
Junfang Wang
Fiberhome
Email: wjf@fiberhome.com
Jiang, et al Expires May 4, 2020 [Page 11]
