Internet DRAFT - draft-zeng-ccamp-joint-control-mid-fwd
draft-zeng-ccamp-joint-control-mid-fwd
Common Control and Measurement Plane L. Zeng
Internet Draft Tsinghua University
Intended status: Informational June 10, 2014
Expires: December 2014
Common Joint Control of Middleboxes and Forwarding Elements
draft-zeng-ccamp-joint-control-mid-fwd-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 10, 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 December 10, 2014 [Page 1]
Internet-Draft Common Joint Control of Middleboxes and Forwarding
Elements June 2014
Abstract
Network services become increasingly multifarious. To efficiently
guarantee the quality of services and fully utilize the network
resources, network operators need to process the traffic flows
through more fine-grained way. It is a promising way to deploy a
series of middleboxes integrating various functions. However, this
results in two challenges: 1) how to control such increasingly
different middleboxes; 2) how can networks provide a common joint
control scheme for both the middleboxes and forwarding elements. This
document proposes a common joint scheme for middleboxes and
forwarding elements. This scheme adopts logically centralized control
method and utilizes standard control interfaces, which makes it
flexible and efficient for the networks to determine the most
optimizing path and the most appropriate functions in the middleboxes
for traffic flows. It guarantees the quality of services and
significantly improves resource utilization.
Table of Contents
1. Introduction ................................................ 2
2. Conventions used in this document............................ 3
2.1. Requirements Language................................... 3
2.2. Definitions ............................................ 3
3. Joint Control Architecture................................... 4
4. Joint Control Strategy and Protocol.......................... 5
4.1. Protocol Frame ......................................... 5
4.2. FEs Control Protocol.................................... 6
4.3. G-Mids Control Protocol................................. 6
5. Flow Control ................................................ 7
6. Security Considerations...................................... 7
7. IANA Considerations ......................................... 7
8. Conclusions ................................................. 7
9. References .................................................. 8
9.1. Normative References.................................... 8
9.2. Informative References.................................. 8
10. Acknowledgments ............................................ 8
1. Introduction
Network services become increasingly multifarious. To efficiently
guarantee the quality of services and fully utilize the network
resources, network operators need to process the traffic flows
through more fine-grained way. It is a promising way to deploy a
series of middleboxes integrating various functions, such as firewall,
Zeng Expires December 10, 2014 [Page 2]
Internet-Draft Common Joint Control of Middleboxes and Forwarding
Elements June 2014
IDS, and proxy. In current networks, one middlebox always implements
just one specific function. Given that different network services
call for quite different data process functions middleboxes deployed
in the networks are extremely heterogeneous, makes it inflexible to
control. Therefore, two solutions emerge and have captured increasing
attentions: 1) integrate multiple functions in one middlebox, named
general middlebox (G-Mid); 2) G-Mid is controlled and configured by a
centralized monitor through software defining. This document
introduces the fundamental problem of G-Mid: how to achieve joint
control of G-Mid and forwarding elements.
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
The definitions of this document are summarized as follows:
General Middlebox (G-Mid) - A type of middlebox that implements
multiple network functions based on one general architecture. The
specific function is controlled and configured by one centralized
control element through software defining.
Forwarding Element (FE) - A logical entity that implements the
control protocols. FEs use the underlying hardware to provide per-
packet processing and handling as directed/controlled by the
centralized control element through software defining.
Joint Control Element (JCE) - A network element that takes charge of
joint controlling and configuring both FEs and G-Mids via software
defining. On one hand, JCE configures the function and the parameters
of both FEs and G-Mid; On the other hand, it possesses the global
information, which makes it possible to dynamically optimize the
whole network via software-defined centralized control.
Zeng Expires December 10, 2014 [Page 3]
Internet-Draft Common Joint Control of Middleboxes and Forwarding
Elements June 2014
Joint Control Protocol (JCP) - Joint control protocol indicates the
detailed control strategy which is implemented via software and
followed by JCE, FEs and G-Mids.
3. Joint Control Architecture
A logical view of the joint control architecture is shown in Figure 1,
which consists of three types of elements: joint control element
(JCE), general middleboxes (G-Mids) and forwarding elements (FEs).
+--------------------------------------------------------------+
| |
| +---------------------------------------------------------+ |
| | +--------------------------------------+ | |
| | Joint +--+ Optimizing and Determination Layer +--+ | |
| | Control | +------+------------------------+------+ | | |
| | Element | | | | | |
| | (JCE) | |Global Information Layer| | | |
| | | +------+----------+ +---------+------+ | | |
| | | |Function Database| |Network Database| | | |
| | | +------+----------+ +--------+-------+ | | |
| | | | | | | |
| | | | Control Ability Layer | | | |
| | | +------+----------+ +--------+-------+ | | |
| | +--+ G-Mid Control | | FE Control +--+ | |
| | ++-----+------+---+ +----+-----+----++ | |
| +--------------|-----|------|------------|-----|----|-----+ |
| | | |Joint Contrl|Protocol | |
| | | | | | | |
| +--------+-+ | +----+-----+ +--+---+ | +-+----+ |
| |Function A| | |Function B| | FE ****** FE | |
| +----------+ | +----------+ +---*--+ | +--*---+ |
| G-Mid | G-Mid * | * |
| | * | * |
| +----*-----+ +*-+--*+ |
| |Function C| | FE | |
| +----------+ +------+ |
| G-Mid |
| |
+--------------------------------------------------------------+
Figure 1 Joint Control Architecture
JCE contains three layer: control ability layer, global information
layer, and the optimizing and determination layer. The control
ability layer is comprised of G-Mid control module and FE control
Zeng Expires December 10, 2014 [Page 4]
Internet-Draft Common Joint Control of Middleboxes and Forwarding
Elements June 2014
module. They provide lots of control functions. For example, the G-
Mid control module may offer functions such as setting the function
of one G-Mid, configuring the parameters of one G-Mid, and etc. While,
the FE control module may possess the functions such as setting the
forwarding rules, adjusting the priority of rules, and etc. The
control ability layer is the cornerstones of JCE since all the
optimization and the determination are implemented by these abilities.
The global information layer consists of two databases: the function
database and the network database. The information in function
database includes the function sets of each G-Mid, the current
function running in each G-Mid, the parameter of each G-Mid, and etc.
The network database reflects the network features, e.g. network
topology, the forwarding rules of each FE, the priorities of
forwarding rules in each FE, and etc. Without this global information,
it is impossible for the optimizing and determination layer to make
the most appropriate determination.
The optimizing and determination layer is the control center of JCE.
Normally, after accessing two databases in the global information
layer, the optimizing and determination layer optimizes and makes the
determination from the global perspective, and then it sends the
corresponding rules to the G-Mids and FEs via control ability layer.
This joint control architecture provides a centralized method to
jointly control both of the G-Mids and FEs. Therefore, it is
convenient to optimize the network and significantly improves
resource utilization.
4. Joint Control Strategy and Protocol
This section addresses the problem that how to efficiently control
both the G-Mids and FEs.
4.1. Protocol Frame
The joint control protocol in this architecture follows match-action
strategy. After optimizing and determining, the JCE makes the rules
of G-Mids and FEs and sends these rules to them via standard
interfaces. In each network element, including G-Mid and FE, there
exists a flow table to store flow entries sent by the controller.
After receiving the rules, G-Mids and FEs will generate or update
their flow tables. When data packets arrive at any G-Mid or FE,
match-field in the packet headers will be checked. If match-field
matches the flow entries, the data packets will be processed
according to the corresponding rules and actions. Otherwise, these
Zeng Expires December 10, 2014 [Page 5]
Internet-Draft Common Joint Control of Middleboxes and Forwarding
Elements June 2014
packets SHOULD be dropped or sent to the JCE. This match-action
strategy based protocol applies to both of G-Mid and FE. But, given
that the functions of G-Mid and FE are quite different, the next two
subsections illustrate them respectively.
4.2. FEs Control Protocol
The proposed architecture directly adopts the SDN (Software-defined
Network) protocol, e.g. OpenFlow, to control FEs. The JCE uses flow
entries to control multiple FEs, where the forwarding function is
executed. The controller can add/delete/modify flow entries to each
FE. Reference [CCAMP-SDN] depicts the detailed SDN protocol.
4.3. G-Mids Control Protocol
The G-Mids control abstraction is shown in Figure 2.
+------------------------------------------------------+
| |
| +-----------+-------------+---------+---------+ |
| |MID-FUNC-ID|MID-FUNC-NAME|CTRL-LIST|PAPA-LIST| |
| |-----------+-------------+---------+---------+ |
| |
+------------------------------------------------------+
Figure 2 G-MID Control Abstract
The MID-FUNC-ID field refers to the function ID in each middlebox.
MID-FUNC-ID is the unique identification being used to distinguish
different functions. For example, firewall, IDS, and Proxy functions
MUST have different MID-FUNC-ID. It is notable that one G-MID may
integrate several functions, and the JCE may guide different data
packets to be processed by different functions.
The MID-FUNC-NAME field depicts the function, which corresponds to
MID-FUNC-ID.
The CTRL-LIST field refers to the current state of each function such
as active, available, sleep, deleted, and etc. Active means this
function is configured as a part of process for at least one table
entry; Available means this function is available but not used now,
but it may turn to active state immediately by easily sending some
control message; Sleep means this function can be used only after
installing; Deleted means this function ever emerged but no longer
exists.
Zeng Expires December 10, 2014 [Page 6]
Internet-Draft Common Joint Control of Middleboxes and Forwarding
Elements June 2014
The PAPA-LIST field contains a series of parameters required by
different functions. Different functions may have quite different
parameters.
Similar as FE control, G-Mid control also utilizes the math-action
strategy. All the actions in FEs are related to forwarding features,
while the actions in G-Mids are different network functions by
calling functions through G-MID control abstract in Figure 2.
5. Flow Control
This section introduces the network flow control process.
o Stage 1: Calculate the path
When one network flow comes, the JCE SHOULD calculate and optimizing
the path of this flow. It contains two items: 1) calculate the
forwarding path that the flow goes through; 2) optimize the functions
of G-Mids which are necessary along the path.
o Stage 2: Configure the G-Mids
In this stage, the JCE SHOULD configure the functions in each G-Mid.
o Stage 3: Configure the G-Mids and send rules&action
In this stage, the JCE SHOULD configure FEs and send the rules and
actions to each G-Mid and FE.
After these three phases are finished, the network is able to deploy
this network flow.
6. Security Considerations
This requirements document does not raise in itself any specific
security issues.
7. IANA Considerations
IANA does not need to take any action for this draft.
8. Conclusions
This document proposes a common joint scheme for middleboxes and
forwarding elements. This scheme adopts logically centralized control
method and utilizes standard control interfaces, which makes it
Zeng Expires December 10, 2014 [Page 7]
Internet-Draft Common Joint Control of Middleboxes and Forwarding
Elements June 2014
flexible and efficient for the networks to determine the most
optimizing path and the most appropriate functions in the middleboxes
for traffic flows. It guarantees the quality of services and
significantly improves resource utilization.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[CCAMP-SDN] McKeown N, Anderson T, Balakrishnan H, et al, "OpenFlow:
enabling innovation in campus networks", ACM SIGCOMM
Computer Communication Review, 2008, 38(2): 69-74.
10. 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.
Zeng Expires December 10, 2014 [Page 8]
Internet-Draft Common Joint Control of Middleboxes and Forwarding
Elements June 2014
Authors' Addresses
Lieguang Zeng
Department of Electronic Engineering, Tsinghua University
Department of Electronic Engineering, Tsinghua University, Beijing,
China
Email: zenglg@mail.tsinghua.edu.cn
Jiaqiang Liu
Department of Electronic Engineering, Tsinghua University
Department of Electronic Engineering, Tsinghua University, Beijing,
China
Email: nxjql@126.com
Mao Yang
Department of Electronic Engineering, Tsinghua University
Department of Electronic Engineering, Tsinghua University, Beijing,
China
Email: yangmao210@163.com
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 December 10, 2014 [Page 9]
