Analysis for FlexE control model
draft-wang-ccamp-flexe-control-analysis-00
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 | Qilei Wang , xiaobingNIU , Yunbin Xu | ||
| Last updated | 2019-03-11 | ||
| 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-wang-ccamp-flexe-control-analysis-00
Internet Engineering Task Force Q. Wang, Ed.
Internet-Draft X. Niu, Ed.
Intended status: Informational ZTE Corporation
Expires: September 12, 2019 Y. Xu
CAICT
March 11, 2019
Analysis for FlexE control model
draft-wang-ccamp-flexe-control-analysis-00
Abstract
This document gives some analysis about the control of FlexE.
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 September 12, 2019.
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
(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.
Wang, et al. Expires September 12, 2019 [Page 1]
Internet-Draft FlexE control March 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. General Introduction of FlexE . . . . . . . . . . . . . . 3
3.1.1. FlexE Group . . . . . . . . . . . . . . . . . . . . . 3
3.1.2. FlexE Client . . . . . . . . . . . . . . . . . . . . 3
3.1.3. Adaptation function between FlexE Client and FlexE
Group . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.4. MAC Frame . . . . . . . . . . . . . . . . . . . . . . 5
3.1.5. Adaptation between MAC frames and FlexE Client . . . 5
3.2. General requirements . . . . . . . . . . . . . . . . . . 5
3.2.1. Configuration of FlexE group . . . . . . . . . . . . 5
3.2.2. Allocate Resources for Client MAC flows . . . . . . . 6
3.3. FlexE Client Configuration Procedures . . . . . . . . . . 6
3.4. Control Requirements Derived . . . . . . . . . . . . . . 8
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
OIF published the first version of FlexE Implementation Agreement in
March 2016, aiming to provide a generic mechanism for supporting a
variety of Ethernet MAC rates that may or may not correspond to any
existing Ethernet PHY rate. SG15 in ITU-T has endorsed the OIF FlexE
data plane and parts of [ITU-T G.872], [ITU-T G.709], [ITU-T G.798]
and [ITU-T G.8023]. The Recommendations depend on or are based on
the FlexE data plane.
This draft is intended to trigger discussion of the FlexE control
architecture according to the analysis in section 2. What kind of
architecture should we employed when configuring FlexE equipments,
how to configure the FlexE group and FlexE client, and what kind of
parameters do we need to take into consideration? The analysis is
mainly based on the description in section 7 and 8 of [ITU-T G.8023],
which is "Characteristics of equipment functional blocks supporting
Flex Ethernet interfaces".
Wang, et al. Expires September 12, 2019 [Page 2]
Internet-Draft FlexE control March 2019
2. Terminology
2.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].
3. Analysis
3.1. General Introduction of FlexE
The FlexE shim is built into the Ethernet PCS (physical coding
sublayer). If a FlexE group is set up, a corresponding n*100G (or
n*200G, n*400G) PCS module is created as well.
The difference between the FlexE and the traditional 100G Ethernet is
that the traditional Ethernet PCS has a 1:1 relationship with the
client MAC flow, while with FlexE one bonded huge PCS module can be
used to transport more than one client MAC flow i.e., the
relationship is 1:n.
3.1.1. FlexE Group
A FlexE Group is consisted of 1 to m bonded Ethernet PHYs. The rate
of the Ethernet PHY could be 100G, 200G or 400G. All PHYs in the
group must operate at the same rate.
FlexE group is consisted of a number of PHYs, and each PHY is
consisted of 66B blocks stream. Section monitoring overhead is
added/extracted as one 66B block at the FlexE group source and
destination (i.e., trail termination) to determine the status of the
FlexE group (i.e., FlexE trail). Currently, only RPF (Remote PHY
Fault) indication is used to report the state of FlexE group.
One FlexE group exists between two FlexE shim, there is no switching
defined in FlexE. In addition, only one fault indication is defined,
there is no other OAM function developed yet. Based on these
analysis, we may understand FlexE is just an interface technology,
and once a FlexE group is configured, it only functions as one
Ethernet link, same as Ethernet PHY.
3.1.2. FlexE Client
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 Client MAC
rates supported by a FlexE Groups could be 10, 40, and m*25 Gb/s.
The FlexE Client MAC rates supported by FlexE Groups may support all,
Wang, et al. Expires September 12, 2019 [Page 3]
Internet-Draft FlexE control March 2019
or only a subset of these FlexE Client rates, e.g., m*25 Gb/s. Each
FlexE Client is presented to the FlexE Shim as a 64B/66B encoded bit-
stream according to clause 82 of [IEEE 802.3].
According to the description in clause 8.1 of [ITU-T G.8023], there
is no overhead defined for monitoring a FlexE client, so the trail
for FlexE client in the equipment does not exist. The FlexE client
trail termination function is a null function. Therefore, there is
no need to model FlexE client as a layer.
3.1.3. Adaptation function between FlexE Client and FlexE Group
In order to distribute the FlexE client over PHYs of one FlexE group,
a number of management information command should be sent to the
adaptation function which performs the mapping of FlexE client over
FlexE group.
According to the description in clause 7.2 of [ITU-T G.8023], the
external management information command sent to the source adaptation
function is listed below:
TxCC, TxCCA, TxCCB, TxCR, TxCA
TxGID, TxPHYMAP
The TxCC, TxCCA and TxCCB are used to configure the calendar for use,
which could be type A or type B calendar configuration, and FlexE
client number.
TxCR and TxCA are used to coordinate the switch of calendar
configuration between the FlexE source and destination node.
The TxGID is used to configure the FlexE group identifier. The
TxPHYMAP is used to configure the set of PHYs in the FlexE group.
The built-in function multiplexer performs the action of assigning
the individual FlexE Client to specific calendar slots of the FlexE
group.
At the destination side, the overhead should be extracted first to
compare the GID and PID. The Demultiplexer function activates the
FlexE Client and assigns the calendar slots of the FlexE group
payload area to the individual FlexE client as defined by the client
calendar information carried in the overhead.
Wang, et al. Expires September 12, 2019 [Page 4]
Internet-Draft FlexE control March 2019
3.1.4. MAC Frame
Defined in IEEE.
3.1.5. Adaptation between MAC frames and FlexE Client
It can be seen from the Figure 8-6 of [ITU-T G.8023] that the
external management information commands used as input to the
adaptation function are defined by [IEEE 802.3]. The [IEEE 802.3]
process mainly includes the 64B/66B encoding, as well as MAC frame
check sequence generation and frame counting. The FlexE client
stream is generated at the determined FlexE Client MAC rate and
64B/66B encoded.
3.2. General requirements
It can be inferred from section 2.1.2 and section 2.1.5 that process
mainly involved when producing the FlexE Client from MAC frames is
64b/66b encoding, and this encoding has already been defined by [IEEE
802.3]. No extra overhead is added. Therefore, configuration for
FlexE client layer is needed. Based on the above analysis, two
general requirements for control/management of FlexE are considered
in this draft.
Configuration of FlexE group
Allocation of one or more FlexE group calendar slot resources to a
client MAC flow.
3.2.1. Configuration of FlexE group
It can be concluded from the above analysis that external
configuration tools should be involved to bring one FlexE group into
service. The initial configuration commands can come from external
management system, SDN controller etc.
A FlexE group must be configured first before any client signals are
carried over it. When a new FlexE Group is brought into service, the
initial configuration must be provisioned from both ends, and the
initial configuration must be the same. The group is configured to
consist of from 1 to n 100G FlexE Instances carried over from 1 to m
PHYs of the same rate (100GBASE-R, 200GBASE-R, or 400GBASE-R). Each
PHY tunnel may consist of multiple hops.
Wang, et al. Expires September 12, 2019 [Page 5]
Internet-Draft FlexE control March 2019
3.2.2. Allocate Resources for Client MAC flows
The FlexE client MAC flows are encapsulated in one or more FlexE
calendar slots. Questions that may be raised when considering
whether external control/management tools are needed.
How is the bandwidth (number of calendar slots) allocated to a MAC
client?
How are the calendar slots assigned to each FlexE clients?
Does the external management/control system need to be involved?
According to the analysis in section 2.1.3, it can be inferred that
the built-in multiplexer and demultiplexer function can work together
to insert/extract FlexE Client stream from some calendar slots
correctly, as well as the trail termination function for FlexE client
is a null function. Therefore, only the bandwidth information of the
FlexE Client is needed, the number of calendar slots required can be
derived from the bandwidth information.
The FlexE client physical port is an internal port which only perform
the function of encapsulating upper layer packets into MAC frames,
64b/66b encoding. The bandwidth capability of these internal ports
should be known by external management/control tools in order to
multiplex and demultiplex the upper layer flow correctly.
3.3. FlexE Client Configuration Procedures
Example below is depicted to set up a 25G MPLS-TP P2P path (from
MPLS-TP-1 to MPLS-TP-2) over one FlexE link[two FlexE Groups] between
Route-1 and Router-2. This is to help understand why control of
FlexE client is not needed. FlexE group is assumed configured in
this case.
Wang, et al. Expires September 12, 2019 [Page 6]
Internet-Draft FlexE control March 2019
==================================================================
MPLS-TP-1
+-----+ MPLS-TP-2
| | +-----+
| | XXXXXX | |
+-----+ XXXX XXXXXX | |
| X XXXX +-----+
| OTN X XX OTN |
+-+-----+ +-----+X X+-----+ +-----+-+
| +---+ +----------------------+ +----+ |
| +---+ +----------------------+ +----+ |
+-----+ +-----+ XX X +-----+ +-----+
Router-1 XXX XXX Router-2
XXXXXX XXXX XX
==================================================================
Figure 1: Network Scenario
Configuration needed for each node when setting up MPLS-TP path:
Outgoing MPLS label and output port, 25G --> MPLS-TP-1;
Incoming MPLS label and input port, 25G --> Router-1;
MPLS traffic over FlexE link, from Router-1 to Router-2;
Outgoing MPLS label and outgoing port, 25G --> Routing-2;
Incoming label and input port, 25G --> MPLS-TP-2
What else would be done by Router-1 and Router-2 if we want to put
MPLS packets over FlexE link?
Router-1, perform the generally used data link (i.e., MAC)
encapsulation procedures to transmit the packet to next hop Router-2,
which includes:
encapsulation of the packets into MAC frames. The source and
destination MAC address can be derived by searching Router-1's
internal mapping table, i.e., (outgoing label, outgoing port, MAC
address) table, then do the 64b/66b encoding for these MAC frames.
Wang, et al. Expires September 12, 2019 [Page 7]
Internet-Draft FlexE control March 2019
in addition, Router-1 would announce the required bandwidth
required from Router-1 to Router-2 to local FlexE multiplexer, the
local FlexE multiplexer then allocates 5*5G calendar slots to the
MPLS-TP client signal, and insert FlexE overhead onto each PHY.
Router-1's configuration is finished.
Router-2's configuration would be different, as its function is to
extract the FlexE client signal from the calendar slots according to
the information carried in the FlexE overhead and route the packets
based on the MPLS label. As there is no switching of calendar slots
in FlexE, the calendar slots allocated to certain client signal would
not change.
It can be inferred from the above procedures that the configuration
of a MPLS client is not impacted by the use of FlexE comparing to
traditional Ethernet.
3.4. Control Requirements Derived
a. Using control plane method to configure FlexE group, which may
include the configuration of group number, PHY number and
correlation between logical PHY number and physical port number.
b. Configuration of "logical" PHY, which includes initial
configuration of bandwidth (number of calendar slots); change of
bandwidth while in service.
c. External control command should be provide to trigger the switch
of calendar slots.
d. Interworking between 5G slot granularity capable node and 25G
slot granularity node.
e. Configuration of aware case. As calendar slots is not visible to
external management/control tools. Bandwidth information of the
Ethernet PHYs selected can be used to infer the unavailable slot
information, as the unavailable slots are placed at the end of
each relevant sub-calendar (the highest numbered slots).
[RFC6002] defines a new switching type DCSC (Data Channel
Switching Capable) to describe the switching of whole digital
channel presented on single channel interface, which can describe
the Ethernet terminated at the physical (port) level and all
traffic received on a port is switched to a physical port at the
LSP egress. The FlexE digital channel presented at each PHY
interface can be described with DCSC switching type. However,
FlexE aware case may not be depicted with DCSC, as described in
section 17.12 of [ITU-T G.709], each FlexE (sub) groups (i.e.,
Wang, et al. Expires September 12, 2019 [Page 8]
Internet-Draft FlexE control March 2019
each 100G FlexE signals) are crunched, padded and interleaved in
FlexE, the bandwidth of digital channel links presented in one
tunnel may varies. Therefore, a new switching type DCSC-flexe is
needed in aware case to depict the end-to-end tunnel with
bandwidth varies at each digital channel links. The
configuration of FlexE instance and unavailable slot information
can be derived through the bandwidth of each hop.
Different kinds of alarms should be taken into consideration when
modelling FlexE technology, which may include PHY failed, skew exceed
threshold, inconsistent configuration between two ends.
4. Summary
According to the analysis in section 2, the main control/management
requirement for FlexE technology is to configure the FlexE group.
Once a FlexE group is configured and the capability information of
the internal FlexE client ports associated with this FlexE group is
known, use of the FlexE technology is the same as that in traditional
Ethernet.
5. Acknowledgements
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
None.
8. References
8.1. Normative References
[ITU-T_G709]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
07/2016", http://www.itu.int/rec/T-REC-
G..709-201606-P/en, July 2016.
[ITU-T_G798]
ITU-T, "ITU-T G.798: Characteristics of optical transport
network hierarchy equipment functional blocks", August
2018.
Wang, et al. Expires September 12, 2019 [Page 9]
Internet-Draft FlexE control March 2019
[ITU-T_G8023]
ITU-T, "ITU-T G.8023: Characteristics of equipment
functional blocks supporting Ethernet physical layer and
Flex Ethernet interfaces", , 2016.
[ITU-T_G872]
ITU-T, "ITU-T G.872: The Architecture of Optical Transport
Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en,
January 2017.
[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>.
8.2. Informative References
[I-D.izh-ccamp-flexe-fwk]
Hussain, I., Valiveti, R., Pithewan, K., Wang, Q.,
Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z.,
zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q.
Zhong, "GMPLS Routing and Signaling Framework for Flexible
Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in
progress), October 2016.
Authors' Addresses
Qilei Wang (editor)
ZTE Corporation
Nanjing
CN
Email: wang.qilei@zte.com.cn
Xiaobing Niu (editor)
ZTE Corporation
Beijing
CN
Email: niu.xiaobing@zte.com.cn
Wang, et al. Expires September 12, 2019 [Page 10]
Internet-Draft FlexE control March 2019
Yunbin Xu
CAICT
Beijing
CN
Email: xuyunbin@caict.ac.cn
Wang, et al. Expires September 12, 2019 [Page 11]