Internet DRAFT - draft-zeng-forces-interfe-consistent-control
draft-zeng-forces-interfe-consistent-control
Forwarding and Control Element Separation L. Zeng
Internet Draft Tsinghua University
Intended status: Informational May 18, 2014
Expires: November 2014
ForCES inter-FE Consistent Control Scheme
draft-zeng-forces-interfe-consistent-control-00.txt
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 18, 2014.
Copyright Notice
Copyright (c) 2014 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.
Zeng Expires November 18, 2014 [Page 1]
Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014
Abstract
This document addresses the inter-FE consistent control problem for
ForCES in software-defined network (SDN), and proposes an inter-FE
consistent control scheme through dynamic match-field selection. In
detail, the control element (CE) analyzes the similarities and
differences between both the old and rules. Then, CE dynamically
determines appropriate match fields and, correspondingly, generates a
set of transitional flow entries. After that, it deletes the old flow
entries and writes the new ones. Finally, the consistent control is
achieved after deleting the transitional flow entries. This scheme
guarantees the inter-FE consistent control.
Table of Contents
1. Introduction ................................................ 2
2. Conventions used in this document............................ 3
2.1. Requirements Language................................... 3
2.2. Definitions ............................................ 3
3. Software Defined Network Based ForCES Framework ..............4
4. Inter-FE Consistent Control Problem ..........................5
5. Inter-FE Consistent Control Scheme Frame .....................5
6. Preprocessing Phase (PP)..................................... 6
7. Transitional phase (TP)...................................... 7
8. Update phase (UP) ........................................... 7
9. Timing Diagram .............................................. 8
10. Security Considerations..................................... 9
11. IANA Considerations......................................... 9
12. Conclusions ................................................ 9
13. References ................................................. 9
13.1. Normative References................................... 9
14. Acknowledgments ........................................... 10
1. Introduction
Forwarding and control element separation (ForCES) defines the
architecture and corresponding protocols, interfaces, and other key
technologies to standardize the separation between control plane and
forwarding plane in network element, called ForCES NE. The control
functions of ForCES NE are centralized in the control elements (CEs),
while the forwarding elements are controlled by the CEs. The
requirements and framework of ForCES are described in RFC 3654 and
RFC 3746 respectively [RFC3654][RFC3746].
Software-defined network (SDN), just in its birth, is a promising
technology consisting with ForCES. SDN makes it convenient and
Zeng Expires November 18, 2014 [Page 2]
Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014
possible to achieve ForCES by introducing a centralized controller
who makes the data processing rules of forwarding devices.
ForCES method may result in a specific issue that different FEs may
not update multiple flow entries simultaneously due to the different
latency, which leads to a series of incorrect and uncontrollable
problem. This issue is called as inter-FE consistent control problem.
This document addresses this problem and proposes an inter-FE
consistent control scheme.
2. Conventions used in this document
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
2.2. Definitions
This document follows the terminology defined by the ForCES protocol
in [RFC5810]. The definitions below are repeated for clarity.
Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs on how to process
packets. CEs handle functionality such as the execution of
control and signaling protocols.
Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed/controlled by one or
more CEs via the ForCES protocol.
ForCES Protocol - While there may be multiple protocols used within
the overall ForCES architecture, the terms "ForCES protocol" and
"protocol" refer to the Fp reference points in the ForCES framework
in [RFC3746]. This protocol does not apply to CE-to-CE communication,
FE-to-FE communication, or communication between FE and CE managers.
Basically, the ForCES protocol works in a master-slave mode in which
FEs are slaves and CEs are masters.
ForCES Network Element (NE) - An entity composed of one or more CEs
and one or more FEs. To entities outside an NE, the NE represents a
Zeng Expires November 18, 2014 [Page 3]
Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014
single point of management. Similarly, an NE usually hides its
internal organization from external entities.
3. Software Defined Network Based ForCES Framework
A logical view of the SDN based ForCES architecture is shown in
Figure 1, which consists of three layers: infrastructure layer,
control layer and application layer.
+--------------------------------------------------------------+
| +--------------------------------------------------------+ |
| | +---------------------+ | |
| | | | | |
| | Application +--+------------------+--+ | |
| | | | | |
| | Layer +--+------------------+--+ | |
| | |Business Applications| | |
| | +---*------*------*---+ | |
| +------------------------|------|------|-----------------+ |
| |API |API |API |
| +------------------------|------|------|-----------------+ |
| | +----------*------*------*---------------+ | |
| | | +----------------+ | | |
| | | SDN | | | | |
| | | Control +--+-------------+--+ | | |
| | Control | Software | | | | |
| | Layer | +--+-------------+--+ | | |
| | (CE) | |Network Services| | | |
| | | +----------------+ | | |
| | +------------**--------------------------+ | |
| +--------------------------||-------------------------+ | |
| ||Control Data Plane Interface| |
| || (ForCES Protocol) | |
| +--------------------------||----------------------------+ |
| | Infrastructure || | |
| | Layer || | |
| | +--------------+ +-----**-------+ +--------------+ | |
| | | FE | | FE | | FE | | |
| | +--------------+ +--------------+ +--------------+ | |
| | +--------------+ +--------------+ | |
| | | FE | | FE | | |
| | +--------------+ +--------------+ | |
| +--------------------------------------------------------+ |
+--------------------------------------------------------------+
Figure 1 Software-Defined Network Architecture
Zeng Expires November 18, 2014 [Page 4]
Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014
The infrastructure layer is composed of multiple FEs that is only in
charge of executing the forwarding functions. Network control
intelligence is logically centralized in control layer, i.e. CE. In
particular, a centralized SDN based CE, named controller, is in
charge of controlling function. In the controller, different network
control functions can be developed as customized. As to application
layer, different kinds of business applications are deployed. Between
application layer and control layer, a set of APIs (Application
Programming Interfaces) are designed, which allows business
applications to use network control services in control layer. Also,
control data plane interface is designed between control layer and
infrastructure layer, which is used to interchange control and
forwarding information between the controller and network devices.
In the SDN architecture, the controller uses flow entry to control
multiple FEs, where the forwarding function is executed. In each
network service, there exists a flow table to store flow entries sent
by the controller. The controller can add/delete/modify flow entries
to each FE.
4. Inter-FE Consistent Control Problem
In SDN based ForCES framework, the CE uses flow entries to control
forwarding behavior of different FEs. In particular, there are
special security channel between the CE and FEs to transform flow
entry information.
Since multiple FEs make up a distributed system, control problem
exists in SDN framework. In detail, it is difficult for the CE to
update multiple flow entries simultaneously, due to different latency
of different special security channels. If these flow entries are
written into FEs at different time, data packets may follow the wrong
control instruction and be incorrectly deal with, leading to system
chaos, packets loss, service deteriorate, and etc.
Due to this control problem, it is necessary to study consistent flow
control mechanism for ForCES based on SDN framework. The consistent
flow control problem is defined as follows: when the CE updates flow
table in multiple FEs, each data packet flowing through the network
must be processed according to a single network control configuration,
either the old control configuration or the new control configuration,
but not a mixture of both configurations, or other uncertain rules.
5. Inter-FE Consistent Control Scheme Frame
To address the inter-FE consistent control problem, this section
introduces the frame of dynamic match-field selection based inter-FE
Zeng Expires November 18, 2014 [Page 5]
Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014
consistent control scheme. This scheme can be divided into three
stages: preprocessing phase, transitional phase, and update phase.
o Preprocessing Phase (PP)
In the preprocessing phase, CE analyzes both the old and the new
rules. According to the analytical result as well as the global flow
table information, CE dynamically selects one (e.g. A0) or more match
fields (e.g. A01+A02), and then dynamically selects one specific (Z)
or more special addresses (a01+a02).
o Transitional phase (TP)
In the transitional phase, based on the preprocessing results from PP,
CE generates a set of transitional flow entries by utilizing the
selected special addresses. It is notable that the transitional flow
entries act the same data processing functions with the new rules.
After that, CE deletes the old flow entries belonging to the old
rules.
o Update phase (UP)
In the update phase, CE writes the new flow entries belong to the new
rules into the corresponding FEs, and then deletes the transitional
flow entries generated in TP.
After these three phases are finished, the inter-FE consistent
control will be achieved. The next three sections depict these three
phases respectively.
6. Preprocessing Phase (PP)
This section details the processing procedure in the preprocessing
Phase. It contains four steps.
o Step PP-1
CE starts the inter-FE consistent control process. In the beginning,
CE analyzes both the old and new rules.
o Step PP-2
CE divides the FEs which needs to be written flow entries belonging
to new rules into three groups: ingress FEs (FE-1), intermediate FEs
(FE-2), egress FEs (FE-3).
o Step PP-3
Zeng Expires November 18, 2014 [Page 6]
Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014
CE calculates the available value of each match field belonging to
the new rules, and then dynamically selects one specific match field,
denoted by A0. These specific match fields are named as available
match fields.
o Step PP-4
CE dynamically determines one specific address, denoted by Z from the
unoccupied address in the available match field.
7. Transitional phase (TP)
Without loss of generality, it is assumed that the flow entries
belonging to the new rules adopt the match fields {A1,A2}, and the
corresponding addresses are {a1,a2}. During PP, CE has determined
that A0=A1, and the corresponding address is {Z,a2}. Then, the
transitional phase consists of three steps.
o Step TP-1
CE writes the transitional flow entries with Z+a2 as the match
information. Then, CE writes the following flow entries into FE-3: IF
packet header matches Z+a2, THEN change Z+a2--->a1+a2, and let FEs in
FE-3 execute the corresponding data process. It is notable that the
transitional flow entries correspond one-to-one with the new rules.
o Step TP-2
CE writes the following flow entries into FE-1: IF packet header
matches a1+a2, THEN change a1+a2--->Z+a2. Importantly, this kind of
flow entries MUST possess the higher priority than a1+a2. In this
case, FEs in FE-1 will process the packets by the transitional rules,
and the old rules will no longer be used.
o Step TP-3
CE waits an end-to-end latency in order to guarantee all the packets
processed by the old rules have been processed completely. After that,
CE deletes all the old flow entries in FE-1, FE-2, and FE-3.
After the above steps, the transitional phase is finished.
8. Update phase (UP)
The update phase replaces the transitional flow entries by the new
rules. It contains three steps.
Zeng Expires November 18, 2014 [Page 7]
Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014
o Step UP-1
CE writes the flow entries belonging to the new rules into FE-1, FE-2,
and FE-3, i.e. a1+a2 as the match information. Importantly, this kind
of flow entries MUST possess lower priority than the transitional
flow entries: Z+a2.
o Step UP-2
After all the flow entries in UP-1 have been written completely, CE
deletes the all the transitional flow entries (Z+a2) in FE-1. After
that, the packets will be processed by the new rules.
o Step UP-3
CE waits an end-to-end latency in order to guarantee all the packets
processed by the transitional rules have been processed completely.
After that, CE deletes all the transitional flow entries in FE-1, FE-
2, and FE-3.
After the above steps, the update phase is finished. Meanwhile, the
inter-FE consistent control has been achieved.
9. Timing Diagram
This section depicts the timing diagram of proposed inter-FE
consistent control scheme, as shown in Figure 2.
Zeng Expires November 18, 2014 [Page 8]
Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014
+---------------------------------------------------+
| |
| |
|Preprocessing Transitional Update phase |
| Phase Phase Phase |
| |<------>| |<------------>||<------------->| |
| |
| PP start TP-2 TP-3 UP-2 UP-3 |
| * * * * * |
| | | | | | |
| | | | | | |
| | t1 | t3 | t4 | t6 | |
| ---*-----*---*---*---*-----*---*---*---*-------- |
| t0 | t2 | t4 | t5 | t7 |
| | | | | |
| | | | | |
| * * * * |
| TP-1 end-to-end UP-1 end-to-end |
| latency latency |
| |
| |
+---------------------------------------------------+
Figure 2 Timing Diagram
10. Security Considerations
This requirements document does not raise in itself any specific
security issues.
11. IANA Considerations
IANA does not need to take any action for this draft.
12. Conclusions
Addressing the inter-FE consistent control problem for ForCES in SDN,
this document introduces an inter-FE consistent control scheme
through dynamic match-field selection. This scheme contains three
phases, and guarantees the inter-FE consistent control.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Zeng Expires November 18, 2014 [Page 9]
Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H.,
Wang, W., Dong, L., Gopal, R., and J. Halpern,
"Forwarding and Control Element Separation (ForCES)
Protocol Specification", RFC 5810, March 2010.
14. Acknowledgments
This work is supported by Chinese National Major Scientific and
Technological Specialized Project (No.~2013ZX03002001), National
Basic Research Program of China (973 Program Grant No.~2013CB329105),
China's Next Generation Internet (No.~CNGI-12-03-007), and ZTE
Corporation.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Lieguang Zeng
Department of Electronic Engineering, Tsinghua University
Department of Electronic Engineering, Tsinghua University, Beijing,
China
Email: zenglg@mail.tsinghua.edu.cn
Ye Zhou
Department of Electronic Engineering, Tsinghua University
Department of Electronic Engineering, Tsinghua University, Beijing,
China
Email: yepiero@gmail.com
Mao Yang
Department of Electronic Engineering, Tsinghua University
Department of Electronic Engineering, Tsinghua University, Beijing,
China
Email: yangmao210@163.com
Zeng Expires November 18, 2014 [Page 10]
Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014
Yong Li
Department of Electronic Engineering, Tsinghua University
Department of Electronic Engineering, Tsinghua University, Beijing,
China
Email: liyong07@tsinghua.edu.cn
Depeng Jin
Department of Electronic Engineering, Tsinghua University
Department of Electronic Engineering, Tsinghua University, Beijing,
China
Email: jindp@mail.tsinghua.edu.cn
Li Su
Department of Electronic Engineering, Tsinghua University
Department of Electronic Engineering, Tsinghua University, Beijing,
China
Email: lisu@tsinghua.edu.cn
Zeng Expires November 18, 2014 [Page 11]
