Internet DRAFT - draft-xie-i2nsf-demo-outline-design
draft-xie-i2nsf-demo-outline-design
I2NSF
Internet Draft Y. Xie
Intended status: Informational L. Xia
J. Wu
Huawei
Expires: October 29 2015 April 29, 2015
Interface to Network Security Functions Demo Outline Design
draft-xie-i2nsf-demo-outline-design-00.txt
Abstract
This document describes the outline design of an Interface to
network Security Functions (I2NSF) demo, aim to enhance
understanding of the I2NSF architecture and justify its feasibility.
The I2NSF demo enables the interaction between I2NSF client, I2NSF
controller and NSF/vNSF by using NETCONF protocol and YANG model.
The advantage of it is to ensure that such demo outline design will
be able to share and reuse consensually designed functions, thereby
increasing interoperability.
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 October 29, 2015.
Xie, et al. Expires October 29, 2015 [Page 1]
Internet-Draft I2NSF Demo Outline Design April 2015
`Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document ........................... 3
2.1. Terminology ............................................ 3
3. Design of the I2NSF Demo .................................... 4
3.1. Overall architecture description ....................... 4
3.1.1. I2NSF Workflow .................................... 6
3.2. I2NSF Client ........................................... 8
3.2.1. I2NSF Service API Format .......................... 9
3.2.2. I2NSF Client Sub-module Design .................... 9
3.3. I2NSF Controller ....................................... 11
3.3.1. Service-oriented I2NSF Agent ...................... 11
3.3.2. Service2Functional Translator ..................... 12
3.3.2.1. Data in the database ......................... 12
3.3.2.2. Service2Functional KEY Mapping ............... 13
3.3.2.3. Service2Functional Value Mapping ............. 13
3.3.3. Functional-oriented I2NSF Client .................. 13
3.4. NSF/vNSF ............................................... 15
3.4.1. Functional-oriented I2NSF Agent ................... 15
3.4.2. Functional2Vendor Translator ...................... 16
3.4.3. Vendor Specific Command ........................... 18
4. Transport Protocol .......................................... 18
4.1. Protocol between Client, Controller, and NSF/vNSF ...... 18
5. YANG model .................................................. 18
6. Security Considerations ..................................... 18
7. IANA Considerations ......................................... 18
8. References .................................................. 19
8.1. Normative References ................................... 19
8.2. Informative References ................................. 19
9. Acknowledgments ............................................. 20
Xie, et al. Expires October 29 2015 [Page 2]
Internet-Draft I2NSF Demo Outline Design April 2015
1. Introduction
A standard interface to express, monitor, and manage security
policies for physical and virtual distributed security functions
that may be running on different premises is increasingly demanded
by Enterprises, residential, and mobile customers. The Interface to
Network Security Functions (I2NSF) whose ultimate goal is to
establish how to communicate with vNSF and how to get performance
data or report out of vNSF well satisfies the demands.
Derived from [I-D.dunbar-i2nsf-problem-statement], it should have
two types of I2NSF interface to consider: first, interface between
I2NSF user/client and network controller (Service-oriented API),
second, north-bound interface (Functional-oriented API) provided by
the network security functions (NSFs) [I-D.xia-i2nsf-capability-
interface-im].
This draft is focused on the outline design of an I2NSF demo
including the design of I2NSF client, I2NSF controller and NSF/vNSF.
NETCONF protocol and YANG model are used for the I2NSF demo
realization. The demo aims to enhance understanding of the I2NSF
architecture and justify its feasibility. Section 3 describes
outline design of I2NSF demo. Section 4 describes protocol between
Client, Controller, and NSF/vNSF. Section 5 gives an example
definition of the Service-oriented API and Functional-oriented API
by YANG model.
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 RFC-2119 [RFC2119].
2.1. Terminology
I2NSF - Interface to Network Security Functions
NETCONF - Network Configuration Protocol
YANG - a data modeling language for the NETCONF network
configuration protocol
RPC - Remote Procedure Control
SSH - Secure Shell
NSF - Network Security Function
Xie, et al. Expires October 29 2015 [Page 3]
Internet-Draft I2NSF Demo Outline Design April 2015
vNSF - virtual Network Security Function
DB - Database
FW - Firewall
Shorewall - It is an open source firewall tool for Linux that builds
upon the Netfilter (iptables / ipchains) system built into the Linux
kernel
UFW - Uncomplicated Firewall
VM - Virtual Machine
3. Design of the I2NSF Demo
This section describes the design of the I2NSF demo. It first
provides an architectural overview of the demo. Then, specific
design of Client, Controller and NSF/vNSF is presented.
3.1. Overall architecture description
+-----------------------+
| |
| I2NSF Client |
| |
+-----------------------+
| Service-Oriented
| interface
|
NETCONF |
+-------------------------+
|I2NSF Controller |
|+---------------+ |
||Service-oriente| |
|| d I2NSF Agent | |
|| | |
|+---------------+ |
|+---------------+ +--+|
||Service2Functio| | ||
||nal Translator |<-->|DB||
|| | | ||
|+---------------+ +--+|
|+---------------+ |
||Functional-orie| |
|| nted I2NSF | |
|| Client | |
|+---------------+ |
Xie, et al. Expires October 29 2015 [Page 4]
Internet-Draft I2NSF Demo Outline Design April 2015
| |
+-------------------------+
|
|
|
----------------------------------------
|Functional- |Functional-
| Oriented | Oriented
| interface | interface
NETCONF | NETCONF |
+---------------------------+ +---------------------------+
|Uncomplicated FW | |Shorewall |
|+---------------+ | |+---------------+ |
||Functional-orie| | ||Functional-orie| |
|| nted I2NSF | | || nted I2NSF | |
|| Agent | | || Agent | |
|+---------------+ | |+---------------+ |
|+---------------+ +----+| |+---------------+ +----+|
||Functional2Vend| | || ||Functional2Vend| | ||
|| or Translator |<-->|Dict|| || or Translator |<-->|Dict||
|| | | || || | | ||
|+---------------+ +----+| |+---------------+ +----+|
|+---------------+ | |+---------------+ |
||Vendor Specific| | ||Vendor Specific| |
|| Command | | || Command | |
|| | | || | |
|+---------------+ | |+---------------+ |
| | | |
+---------------------------+ +---------------------------+
Figure 1. Overall Architecture
The I2NSF demo architecture and its basic functions are as follows:
1) Input configuration policy in the command line module of I2NSF
Client;
2) I2NSF Service API parameters are composed according to YANG model;
3) Represent the composed I2NSF Service API parameters by XML;
4) Reliable and ordered data transmission supported by NETCONF
protocol;
5) Receive data in NETCONF module of I2NSF Controller;
6) Transform Service API into Functional API in adapter module of
I2NSF Controller;
Xie, et al. Expires October 29 2015 [Page 5]
Internet-Draft I2NSF Demo Outline Design April 2015
7) Construct YANG model with Functional API parameters, and transmit
the data by NETCONF protocol;
8) Receive data in NETCONF module of NSF/vNSF;
9) Fetch I2NSF Functional API parameter values in YANG model deposed
module of NSF/vNSF;
10) Match API KEY with different vendor FW KEY in KEY mapping module
(aka Dict) of NSF/vNSF;
11) IP address mapping and MAC address mapping in Value mapping
module of NSF/vNSF;
12) Different vendor FW parameters are assembled into command line
form in command assembling module of NSF/vNSF;
13) Send Vendor specific command in sequence in command send module
of NSF/vNSF;
3.1.1. I2NSF Workflow
+
Client + Controller
+
+
+
Terminal Command Encapsulate + YANG model
send parsing into YANG + parsing
message model +
+
| | | + |
| | | + |
| | | + |
|------------->| | + |
| | | + |
| | | + |
| |------------->| + |
| | | + |
| | | By netconf |
| | |------------->|
| | | + |
| | | + |
| | | + |
| | | + |
| | | + |
+
Xie, et al. Expires October 29 2015 [Page 6]
Internet-Draft I2NSF Demo Outline Design April 2015
+
Controller + NSF/vNSF
+
+
+
YANG Semantics Parameters YANG model + YANG model
model reading mapping encapsulating + parsing
parsing +
+
| | | | + |
| | | | + |
| | | | + |
|------------->| | | + |
| | | | + |
| | | | + |
| |------------->| | + |
| | | | + |
| | | | + |
| | |------------->| + |
| | | | + |
| | | | By netconf |
| | | |------------->|
| | | | + |
| | | | + |
+
NSF/vNSF
YANG Semantics Parameter FW command FW command
model reading transforming assembling sending
parsing
| | | | |
| | | | |
| | | | |
|------------->| | | |
| | | | |
| | | | |
| |------------->| | |
| | | | |
| | | | |
| | |------------->| |
| | | | |
| | | | |
| | | |------------->|
| | | | |
| | | | |
Figure 2. I2NSF Workflow
Xie, et al. Expires October 29 2015 [Page 7]
Internet-Draft I2NSF Demo Outline Design April 2015
3.2. I2NSF Client
+--------------------------------------+
| I2NSF Client |
| |
| +-------------+ +-------------+ |
| |Command line | |Command line | |
| | input | | display | |
| +-------------+ +-------------+ |
| | | |
| +-------------+ +-------------+ |
| | Semantics | | Contents | |
| | reading | | translation | |
| +-------------+ +-------------+ |
| | | |
| +-------------+ +-------------+ |
| |YANG modeling| |YANG modeling| |
| | language | | language | |
| | composed | | decomposed | |
| +-------------+ +-------------+ |
| | | |
| +----------------+ |
| | NETCONF | |
| +----------------+ |
| | |
+------------------|-------------------+
| NETCONF
Figure 3. I2NSF Client Modules
I2NSF Client consists of seven modules:
1) Command line input module;
2) Semantics reading module;
3) YANG modeling language composed module;
4) YANG modeling language decomposed module;
5) Contents translation module;
6) Command line display module;
7) NETCONF module;
Xie, et al. Expires October 29 2015 [Page 8]
Internet-Draft I2NSF Demo Outline Design April 2015
3.2.1. I2NSF Service API Format
A policy rule can be described as:
<tenant> <user_group> <role> <object> <action> <condition>.
<tenant> is used to uniquely identify tenant that has parameters
such as tenant_name and tenant_ID. The default value is NULL
<user_group> has parameters such as Device(s), Place(s), User(s).
<role> is the role of user.
<object> are selected traffics that network behaviors enforced on.
<action> are network behaviors enforced on selected traffic.
<condition> means condition for action, with parameters such as Rate,
Time, Timeout, Throughput, State.
Therein,
Example 1: John_0001 is allowed to access rtsp://video-
server/mrbean.ts.
<tenant> = NULL
<user_group> = John_0001
<role> = marketing
<object> = rtsp://video-server/mrbean.ts
<action> = allow
<condition> = NULL
3.2.2. I2NSF Client Sub-module Design
1) Command line input module is responsible for receiving input
command.
Input: John_0001 is allowed to access rtsp://video-server/mrbean.ts
2) Semantics reading module is responsible for analyzing commands
and fetching I2NSF Service API parameter values.
Xie, et al. Expires October 29 2015 [Page 9]
Internet-Draft I2NSF Demo Outline Design April 2015
Output:
<tenant> = NULL
user_group.user.user_name= John_0001
role = marketing
object.url_group.url = rtsp://video-server/mrbean.ts
action = allow
condition = NULL
3) YANG modeling language composed module is responsible for
encapsulating I2NSF Service API parameter types and values into YANG
model.
Input:
<tenant> = NULL
user_group.user.user_name= John_0001
role = marketing
object.url_group.url = rtsp://video-server/mrbean.ts
action = allow
condition = NULL
Output:
<tenant></tenant>
<user_group>
<user>
<user_name>John_0001</user_name>
</user>
</user_group>
<role>marketing</role>
<object>
<url_group>
Xie, et al. Expires October 29 2015 [Page 10]
Internet-Draft I2NSF Demo Outline Design April 2015
<url>rtsp://video-server/mrbean.ts <http://video-server/MrBean.ts></url>
</url_group>
</object>
<action>allow</action>
<condition></condition>
......
4) YANG modeling language decomposed module is responsible for
parsing YANG model and fetching I2NSF Service API parameter types
and values.
5) Contents translation module is responsible for translating I2NSF
Service API parameter types and values into readable contents to
display.
6) Command line display module is responsible for displaying data
information from I2NSF Controller.
7) NETCONF module is responsible for communicating between Client
and Controller.
3.3. I2NSF Controller
I2NSF Controller consists of Service-oriented I2NSF Agent,
Service2Functional Translator, Functional-oriented I2NSF Client.
3.3.1. Service-oriented I2NSF Agent
Service-oriented I2NSF Agent consists of NETCONF module, YANG model
decomposed and composed modules.
NETCONF module is responsible for communicating with I2NSF Client.
YANG modeling language decomposed module parse YANG model into <key,
value> pairs. It can map YANG model into Service2Functional KEY.
Input:
<tenant></tenant>
<user_group>
<user>
<user_name>John_0001</user_name>
</user>
Xie, et al. Expires October 29 2015 [Page 11]
Internet-Draft I2NSF Demo Outline Design April 2015
</user_group>
<role>marketing</role>
<object>
<url_group>
<url>rtsp://video-server/mrbean.ts <http://video-server/MrBean.ts></url>
</url_group>
</object>
<action>allow</action>
<condition></condition>
......
Output:
<tenant> = NULL
user_group.user.user_name= John_0001
role = marketing
object.url_group.url = rtsp://video-server/mrbean.ts
action = allow
condition = NULL
YANG modeling language composed module encapsulate <key, value>
pairs into YANG model. It maps Service2Functional KEY into YANG
model.
3.3.2. Service2Functional Translator
Service2Functional Translator does the mapping between YANG model
and Functional API according to the database, which means the
mapping between Client command and Functional API. It consists of
Service2Functional KEY mapping and Service2Functional Value mapping.
3.3.2.1. Data in the database
SRC_DB: "John_0001"---"192.168.1.100"
ACT_DB: "allow"---"permit", "deny"---"deny"
Xie, et al. Expires October 29 2015 [Page 12]
Internet-Draft I2NSF Demo Outline Design April 2015
PROTO_DB: "rtsp://video-server/mrbean.ts"---"tcp", "rtsp://video-
server/france24.ts"---"tcp", "rtsp://video-
server/mrbean.ts,rtsp://video-server/france24.ts"---"tcp"
PORT_DB: "rtsp://video-server/mrbean.ts"---"554", "rtsp://video-
server/france24.ts"---"8554", "rtsp://video-
server/mrbean.ts,rtsp://video-server/france24.ts"---"554","8554"
DEST_DB: "rtsp://video-server/mrbean.ts"---"100.1.1.100",
"rtsp://video-server/france24.ts"---"100.1.1.100", "rtsp://video-
server/mrbean.ts,rtsp://video-server/france24.ts"---"100.1.1.100"
3.3.2.2. Service2Functional KEY Mapping
KEY lexicon deposits the correspondence between Service API and
Functional API.
Example 1:
<Key in Service API> <Key in Functional API>
user_group.user.user_name objects.address_group.address.src.src_ip_addr
object.url_group.url objects.address_group.address.dst.dst_ip_addr
objects.service.protocol
objects.service.port
action actions
3.3.2.3. Service2Functional Value Mapping
ValueDB deposit actual value in the network corresponding to value
in Service API, such as IP/MAC/URL address, protocol+ port number
and so on.
For example:
objects.address_group.address.src.src_ip_addr =192.168.1.1
3.3.3. Functional-oriented I2NSF Client
Functional-oriented I2NSF Client consists of YANG modeling language
composed module, NETCONF module, and YANG modeling language
decomposed module.
Xie, et al. Expires October 29 2015 [Page 13]
Internet-Draft I2NSF Demo Outline Design April 2015
YANG modeling language composed module encapsulates actual value in
the network into YANG model, and then transports it to NSF/vNSF by
NETCONF.
Input
objects.address_group.address.src.src_ip_addr=192.168.1.1
objects.address_group.address.dst.dst_ip_addr=100.1.1.100
objects.service.protocol=tcp
objects.service.port=554
actions=permit
Output
<objects>
<address_group>
<address>
<src>
<src_ip_addr>192.168.1.1</src_ip_addr>
</src>
<dst>
<dst_ip_addr>100.1.1.100</dst_ip_addr>
</dst>
</address>
</address_group>
<service>
<protocol>tcp</protocol>
<port>554</port>
</service>
</objects>
<actions>permit</actions>
......
NETCONF module is responsible for communicating with NSF/vNSF.
Xie, et al. Expires October 29 2015 [Page 14]
Internet-Draft I2NSF Demo Outline Design April 2015
3.4. NSF/vNSF
NSF/vNSF consists of Functional-oriented I2NSF Agent,
Functional2Vendor Translator and Vendor Specific Command.
3.4.1. Functional-oriented I2NSF Agent
Functional-oriented I2NSF Agent is responsible for communicating
with I2NSF Controller and the protocol used is NETCONF. It consists
of NETCONF module, YANG modeling language decomposed and composed
modules.
YANG modeling language decomposed module parses YANG model into <key,
value> pairs.
Input:
<objects>
<address_group>
<address>
<src>
<src_ip_addr>192.168.1.1</src_ip_addr>
</src>
<dst>
<dst_ip_addr>100.1.1.100</dst_ip_addr>
</dst>
</address>
</address_group>
<service>
<protocol>tcp</protocol>
<port>554</port>
</service>
</objects>
<actions>permit</actions>
......
Output:
<key= objects.address_group.address.src.src_ip_addr ,
value=192.168.1.100>
Xie, et al. Expires October 29 2015 [Page 15]
Internet-Draft I2NSF Demo Outline Design April 2015
......
YANG modeling language composed module encapsulates the <key value>
pairs into YANG model.
3.4.2. Functional2Vendor Translator
As the core part of the NSF/vNSF, Functional2Vendor Translator
comprises a) lexicon module, b) key mapping module, c) value mapping
module, d) command assembling module and e) message parsing module.
Lexicon module deposits the correspondence between the keys of YANG
model and the keys ruled by the specific FW syntax.
Example 1: Shorewall lexicon
<Key in Functional API> <Key in the FW>
objects.address_group.address.src.src_ip_addr SOURCE
objects.address_group.address.dst.dst_ip_addr DEST
Example 2: UFW lexicon
<Key in Functional API> <Key in the FW>
objects.address_group.address.src.src_ip_addr from
objects.address_group.address.dst.dst_ip_addr to
Key mapping module is responsible for the translation between the
keys of YANG model and the keys ruled by the FW according to the
lexicon module.
Input:
<key= objects.address_group.address.src.src_ip_addr,
value=192.168.1.100>
......
Output:
Xie, et al. Expires October 29 2015 [Page 16]
Internet-Draft I2NSF Demo Outline Design April 2015
<key= SOURCE, value=192.168.1.100>
......
Value mapping module is responsible for the translation between the
values of YANG model and the values ruled by the FW.
For example: (Shorewall)
Input:
<key= SOURCE, value=192.168.1.100>
......
Output
<key= SOURCE, value=cli:192.168.1.100>
......
Command assembling module assembles different vendors FW values into
command line form.
Shorewall command assembling format:
#ACTION SOURCE DEST PROTO DEST PORT(S)
Input
<key= SOURCE, value=cli:192.168.1.100>
......
Output (Shorewall)
ACCEPT cli:192.168.1.100 ser:100.1.1.100 tcp 554
UFW command assembling format:
ufw allow|deny|reject|logging|show [proto protocol] [from ADDRESS
[port PORT]] [to ADDRESS [port PORT]]
Output (UFW):
Xie, et al. Expires October 29 2015 [Page 17]
Internet-Draft I2NSF Demo Outline Design April 2015
ufw route allow in on eth1 out on eth2 from 192.168.1.100 to
100.1.1.100 port 554 proto tcp
Message parsing module parses the upward report commands of
different vendors FW into <key, value> pairs.
3.4.3. Vendor Specific Command
Vendor Specific Command is responsible for communicating with FW
configuration policy executive layer, including the sending down
commands and upward report commands.
4. Transport Protocol
4.1. Protocol between Client, Controller, and NSF/vNSF
As shown in Figure 1, Service-oriented API connects I2NSF Client
with I2NSF Controller Functional-oriented API connects I2NSF
Controller with NSF/vNSF.
The protocol used in Service-oriented API and Functional-oriented
API is NETCONF whose protocol stack has four layers: Content,
Operations, RPC, and Transport [RFC4741]. The set of operations
includes <get>, <get-config>, <edit-config>, etc. The configuration
data and state data are separated and both of them are expressed by
XML. NETCONF protocol is connection-oriented and the connection
should provide reliable, ordered transmission. NETCONF provides the
fundamental programming features for comfortable and robust
automation of network services.
5. YANG model
YANG is a full, formal contract language with rich syntax and
semantics to build applications on. YANG is a NETCONF data modeling
language which is able to model configuration data, state data,
operations, and notifications. YANG definitions can directly map to
XML content.
6. Security Considerations
TBD
7. IANA Considerations
TBD
Xie, et al. Expires October 29 2015 [Page 18]
Internet-Draft I2NSF Demo Outline Design April 2015
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications",
RFC 5277, July 2008.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
8.2. Informative References
[INCITS359 RBAC] NIST/INCITS, "American National Standard for
Information Technology - Role Based Access Control",
INCITS 359, April, 2003
[I-D.zarny-i2nsf-data-center-use-cases] Zarny, M., et.al., "I2NSF
Data Center Use Cases", Work in Progress, October 2014.
[I-D.qi-i2nsf-access-network-usecase] Qi, M., et.al., "Integrated
Security with Access Network Use Case", Work in Progress,
October, 2014.
[I-D.pastor-i2nsf-access-usecases] Pastor, A., et.al., "Access Use
Cases for an Open OAM Interface to Virtualized Security
Services", Work in Progress, October, 2014.
[I-D.dunbar-i2nsf-problem-statement] Dunbar, L., et.al., "Interface
to Network Security Functions Problem Statement", Work in
Progress, September, 2014.
[I-D.xia-i2nsf-capability-interface-im] Liang Xia, "Information
Model of Interface to Network Security Functions
Capability Interface", Work in Progress, January, 2015.
[I-D.strassner-i2nfs-info-model] Strassner, et.al., "Interface to
Network Security Functions Information Model", February,
2015.
Xie, et al. Expires October 29 2015 [Page 19]
Internet-Draft I2NSF Demo Outline Design April 2015
[I-D.xia-i2nsf-service-interface-dm] Liang Xia, et.al., "Data Model
of Interface to Network Security Functions Service
Interface", February, 2015.
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Yuming Xie
Huawei Technologies
Email: yuming.xie@huawei.com
Liang Xia (Frank)
Huawei Technologies
Email: Frank.xialiang@huawei.com
Jun Wu
Huawei Technologies
Email: junwu.wu@huawei.com
Xie, et al. Expires October 29 2015 [Page 20]
