Multi-Service Virtualization Using Virtual Line Cards
draft-wang-msv-using-virtual-line-card-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 | Wang Danhua , Qin Wu | ||
| Last updated | 2013-10-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| 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-msv-using-virtual-line-card-00
Network Working Group D. Wang
Internet-Draft Q. Wu
Intended status: Standards Track Huawei
Expires: April 24, 2014 October 21, 2013
Multi-Service Virtualization Using Virtual Line Cards
draft-wang-msv-using-virtual-line-card-00
Abstract
There are many example procedures in our mind which can benefit from
the service virtualization and the service pooling. Therefore, we
come up with this idea of multi-service virtualization, not only
supports service resource pooling to realize intelligent resource
sharing, but also makes the service much more flexible and reliable.
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 http://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 24, 2014.
Copyright Notice
Copyright (c) 2013 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.
Wang & Wu Expires April 24, 2014 [Page 1]
Internet-Draft MSV using virtual line cards October 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 2
3. Overview of Multi-Service Virtualization . . . . . . . . . . 3
3.1. Virtual Line Cards Registration . . . . . . . . . . . . . 4
3.2. Tunnel Setup . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Policy Configuration . . . . . . . . . . . . . . . . . . 4
3.4. Heartbeat Monitoring and Service Reliability . . . . . . 5
3.5. Service Virtualization and Service Pooling . . . . . . . 6
4. Example Procedures . . . . . . . . . . . . . . . . . . . . . 7
4.1. Virtual line card selection procedure . . . . . . . . . . 7
4.2. Procedure of physical slot failover using virtual line
card . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
A growing tendency is that serious kinds of services such as security
(e.g., FW, AV) have to be deployed simultaneously. Both the inline
and bypass disposition pattern of traditional network pose great
challenges in this situation, e.g., difficulty with planning safety
path, fragmentation in security employment, complexity of bypass
deployment, and so on. At the same time, physical line cards expose
significant shortcomings in practical use, such as scalability issue,
lack of flexibility and reliability, et., al. In this context, we
introduce an idea of multi-service virtualization, not only supports
service resource pooling to realize intelligent resource sharing, but
also makes the service much more flexible and reliable.
2. Conventions used in this document
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 RFC2119 [RFC2119].
MSV: Multi-service Virtualization
pSlot: Physical Slot
vSlot: Virtual Slot
Line Card ID: Identity number of line card
Wang & Wu Expires April 24, 2014 [Page 2]
Internet-Draft MSV using virtual line cards October 2013
3. Overview of Multi-Service Virtualization
The idea of Multi-Service Virtualization (MSV) we propose includes
physical line card virtualization, service pooling, and service
chaining. In our proposal, physical line cards are virtualized into
virtual line cards and can be attached to LAN switches (either
integrated switch or core switch) optionally. Accordingly, physical
slots on LAN switches are virtualized into virtual slots as well.
Then Virtual line cards can be attached to certain virtual slots on
the LAN Switches. Those virtualized line cards form a service pool
which can be shared to provide service, which may introduce service
resilience. Through policy configuration, different service-chains
can be distinguished for different users according to their
identities, authority and service type, et.al.
Figure 1 shows an applicable framework of the MSV system in our mind.
It is just used to facilitate our description of the example
procedures we present in Section 4 and is not intend to invent any
scheme.
+----------+
|Controller|
+----------+
^ ^
| |
---- | Service Pool
| |
+------------+ |( ----------- )
| Core |______(|___+-----+ )
| Switch |\ ( | | IPS | )
+------------+ \ ( | +-----+ )
/\ \ | )
/ \ ( \ | )
/ \ ( \+----+ )
/ \ ( | FW | )
/ \ ( +----+ )
/ \ ( _ _ _ _ _ _ )
/ \
+------------+ +------------+
| Integrated O vSlot1 | Integrated O vSlot3
| Switch O vSlot2 | Switch O vSlot4
+------------+ +------------+
Figure 1 Framework of MSV
In this framework, there're multiple virtual line cards in the
service pool, each representing a certain service it can provide,
such as IPS, FW, and so on. They register to the core switch and
Wang & Wu Expires April 24, 2014 [Page 3]
Internet-Draft MSV using virtual line cards October 2013
provide service as a service pool. Both vSlot1 and vSlot2 in the
service pool are attached to these two integrated switches
simultaneously. They conduct safety detection for the attached
integrated switch. GRE channels are created by which LAN switches
can communicate with the vSlot. Policy configurations are performed
by the controller and virtual line cards are grouped together and
provide service chains to users.
The controller in this framework plays the role of administrator,
holding necessary information of virtual line cards in the service
pool.
3.1. Virtual Line Cards Registration
The administrator chooses appropriate virtual line cards based on the
topology information and virtual line cards' capabilities, and then
bond them with certain LSW. In this way, a MSV group is formed,
which consists of the LAN Switch and those chosen virtual line cards.
As shown in Figure 1, the integrated switch 1, the virtual FW as well
as vSlot1 and the virtual IPS as well as vSlot2 are grouped as a MSV
group. For simplicity, the LAN Switch in the MSV group is named as
MSV-LSW, and MSV-SEC represents the virtual line card in MSV group in
this context. Each virtual line card register itself to the
administrator. Through registration, service types as well as
remaining throughput of the virtual line cards are registered onto
the administrator.
3.2. Tunnel Setup
In the framework described before, two GRE channels, the transmit
channel (TX) and the receive channel (RX), are created between the
LAN switch and each attached virtual line card, as shown in Figure 2.
Through these channels, registration information, heart beat
messages, and service flow are all transmitted between MSV-LSW and
MSV-SEC.
LAN
+------------+ RX +-------------+
| Lan Switch |----------------| Firewall |
| (MSV-LSW) |----------------| (MSV-SEC) |
+------------+ TX +-------------+
Figure 2 Tunnel Setup
3.3. Policy Configuration
We've pre-defined a set of policy templates, as shown in Figure 3.
By configuring policies, different service-chains are defined and
Wang & Wu Expires April 24, 2014 [Page 4]
Internet-Draft MSV using virtual line cards October 2013
provided to users. The controller is in charge of policy
configuration. For example, the "DATA_SEC" template defined in
Figure 3 implies you can choose either "permit" or "deny" to employ
this template as you wish, also you can choose random combinations of
these services provided in the "Service-chain" list. In this way,
different service-chains are defined.
Policy Template Service-chain
DLP AUTH
DATA_SEC Permit AV VLAN
Deny IPS PRI
DPI Bandwidth
SIP WAAS
Figure 3 Policy Template
3.4. Heartbeat Monitoring and Service Reliability
While a virtual line card is bond with the certain LAN switch, both
the transmit channel and the receive channel are created
automatically. The link availability can be detected from heartbeat
messages through these two GRE channels. As shown in Figure 4, once
a virtual line card (e.g., virtual FW) fails, the following traffic
will bypass the failed virtual line card. In this way, the service
will not be interrupted and the service reliability is improved.
^ ^
| |
+--|----------|--+
___________________|__| | |
| | | |
+----------+ Heartbeat | | |
|virtual FW|--------------->O vSLot | |
+----------+ | LAN Switch | |
| __________________|__ | |
Fail | | | |
+--|----------|--+
| |
| |
| |
Security Failure
Detection ---->
Process Bypass
Figure 4 Heartbeat Monitoring Process
Wang & Wu Expires April 24, 2014 [Page 5]
Internet-Draft MSV using virtual line cards October 2013
As shown in Figure 4, while a vSlot (e.g., FW vSlot) fails, the
following traffic will bypass the failed vSlot. In this way, the
service will not be interrupted.
3.5. Service Virtualization and Service Pooling
A network device such as security devices can be virtualized into a
set of virtual line cards. A group of virtual line cards with
various kinds of functions forms a service pool, providing
distinguished service chains for users. These virtual line cards can
be shared by access/integrated/core switches with high-level
security.
In Figure 5, there're three blocks (Block0, Block1, Block2). The
service pool consists of various kinds of virtual line card which can
be shared among these three blocks. GRE channels are created among
these blocks, and the flow among them can be controlled through
policy configuration via GRE channels.
Wang & Wu Expires April 24, 2014 [Page 6]
Internet-Draft MSV using virtual line cards October 2013
____________________ Service Pool
Block0 | |
| +------------+ | ( ----------- )
| | Core |___|__(____+-----+ )
| | Switch |\ |( | IPS | )
| +------------+ \ |( +-----+ )
|________ /\ _______\|( )
/ \ ( \ )
/ \ ( \+----+ )
/ \ ( | FW | )
/ \ ( +----+ )
Block1 / \ ( _ _ _ _ _ _ )
________________/____ ____\__________________
| +------------+ | | +------------+ | Block2
| | Integrated O vSlot1 | Integrated O vSlot3|
| | Switch O vSlot2 | Switch O vSlot4|
| +------------+ | | +------------+ |
| /\ | | /\ |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
| +------+ +------+| |+------+ +------+ |
| |Access| |Access|| ||Access| |Access| |
| |Switch| |Switch|| ||Switch| |Switch| |
| +------+ +------+| |+------+ +------+ |
|_____________________| |_______________________|
Figure 5 Service Virtualization and Service Pooling
4. Example Procedures
4.1. Virtual line card selection procedure
Figure 6 presents one of the representative scenarios of our
proposal, virtual line card selection procedure. In this use case,
the PM (Procedure Manager) plays the role of a centralized control
point, which is responsible of updating the switch information and
creating bindings between the LAN Switch and the line card ID. It
also can calculate and choose the appropriate virtual line cards for
the users due to their requirements. Security devices such as FWs
are replaced by virtualized line cards attached to the LAN Switch.
The virtual line cards register themselves to the PM, carrying
corresponding information with them, such as virtual line card ID,
service type and bandwidth capability. And then PM collects and
maintains the virtual line cards' information as well as enable query
of certain line cards which can satisfy user's requirements.
Virtualized line cards can either be local or remote to the LAN
Wang & Wu Expires April 24, 2014 [Page 7]
Internet-Draft MSV using virtual line cards October 2013
Switch which they are attached to. They provide services as a
service pool together. The LAN Switch talks with its attached
virtual line cards through GRE channels and monitors their state
through heartbeat messages.
+------+ +----+
| ALTO | | PM |
|Server| +----+ Service Pool
+------+ ^
^ ^ | 6 (~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~)
| | |_____( +----------+ +----------+ )
| |_____________ ( | virtual | | virtual | )
3| 1 ( |line card1| |line card2| )
| ( | (FW) | | (IPS) | )
| ( +----------+ +----------+ )
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------+ +---------+ +------+ | ^
| User |-------->| NMS/OSS | | Core | | |
+------+ 2 | (PU) | |Switch|<--------------- |
| +---------+ +------+ 5 |
| /\ |
| / \ |
| / \ |
| / \ |
| +------------+ +------------+ |
| vSlot1 O Integrated | | Integrated O vSlot3|
| vSlot2 O Switch | | Switch O vSlot4|
| +------------+ +------------+ |
|____________________________________________________|
4
Figure 6 Virtual Line Card Selection Procedure
The basic process flow of this example procedure is as following.
1. The virtual line cards (virtual FW, virtual IPS) register and
tell its certain information to the PM separately.
2. The user sends a service request to the NMS/OSS, which can
specify the certain tenant, location or a certain area, as well as
configure the policies.
3. The NMS/OSS queries appropriate virtual line cards from PM
according to the user's service request.
4. The policies are configured to the specified tenant.
Wang & Wu Expires April 24, 2014 [Page 8]
Internet-Draft MSV using virtual line cards October 2013
5. The virtual line cards register their location to the switch
fabric. Then the virtual line card is attached to the switch fabric.
6. The service pool updates the switch location to the PM. And the
switch is bond with the virtual line card ID.
4.2. Procedure of physical slot failover using virtual line card
Figure 7 presents another example procedure. It is known that in
many cases, the physical line cards are insufficient and the
scalability issue is an obvious bottleneck. Also, once the physical
line cards break down, the service will be interrupted which may lead
to poor user experience. In order to overcome these shortcomings,
the idea of virtualized line cards comes up to us. The function and
the performance of the virtualized line cards are close to or even
the same as the physical line cards. A group of virtual line cards
with various functions can be assembled together as a package and
attached to certain LAN switches providing services to certain users.
They can be assembled in various ways with much more flexibility.
Also, in the case of virtual line cards' breaking down, other virtual
line cards of the same functions can replace it and the service will
be recovered in a short period that the user cannot even notice.
Likewise, while a physical line card breaks down, it can be replaced
by one or a set of virtual line cards of the same functions.
Service Pool
+------------+ ( ----------- )
| Core |______(____+-----+ )
| Switch |\ ( | IPS | )
+------------+ \ ( +-----+ )
/\ \ )
/ \ ( \ )
/ \ ( \+----+ )
/ \ ( | FW | )
/ \ ( +----+ )
/ \ ( _ _ _ _ _ _ )
/ \
+------------+ +------------+
| Integrated O pSlot1 | Integrated O pSlot3
| Switch O vSlot2 | Switch O vSlot4
+------------+ +------------+
Figure 7 Procedure of pSlot Failover Using vSlot
The basic flow process of this example procedure is described as
following.
Wang & Wu Expires April 24, 2014 [Page 9]
Internet-Draft MSV using virtual line cards October 2013
1. The virtual line card registers to and thus binds with a certain
LAN switch.
2. Each virtual slotreports its breakdown and the load condition to
the switch fabric through heartbeat messages.
3. Once the virtual/physical line card breaks down, the PM will
recalculate and choose a new line card that can satisfy the
requirements for it.
4. The new assigned virtual/physical line card is registered to the
switch fabric and bond with it. The virtual line card breaking down
is replaced.
5. Conclusions
There are many example procedures in our mind which can benefit from
the service virtualization and the service pooling. Therefore, we
come up with this idea of multi-service virtualization. In this
framework, the physical line cards are virtualized and serve together
as a service pool. According to different requirements, certain
virtual line cards will be picked up and grouped together to provide
services. Two GRE channels are created for each LAN switch and
virtual line card pair, which can be used to register virtual line
card's information to LAN Switch as well as configure specific
polices to the virtual line card. Heartbeat monitoring messages sent
from virtual line card to LAN Switch can help detect virtual line
cards' breakdown.
Therefore, the idea of multi-service virtualization can benefit a lot
to many example procedures and brings a series of advantages. First
of all, the service pool can provide a service chain to the user.
Secondly, heartbeat monitoring messages between LAN Switch and
virtual line card can lead to service reliability. Thirdly, virtual
line card can replace fail physical line card in a short period which
may avoid service interruption and improve user service experience.
Also, in some particular situations, service pooling based
authentications can reduce the chance of duplicate identity
certification.
6. Security Considerations
7. IANA Considerations
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
Wang & Wu Expires April 24, 2014 [Page 10]
Internet-Draft MSV using virtual line cards October 2013
Authors' Addresses
Danhua Wang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: wangdanhua@huawei.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: sunseawq@huawei.com
Wang & Wu Expires April 24, 2014 [Page 11]