Internet DRAFT - draft-huang-nvo3-vxlan-extension-for-vbras
draft-huang-nvo3-vxlan-extension-for-vbras
NVO3 L. Huang, Ed.
Internet-Draft S. Hu
Intended status: Informational China Mobile
Expires: September 2, 2017 March 1, 2017
VxLAN Extension Requirement for Signaling Exchange Between Control and
User Plane of vBras
draft-huang-nvo3-vxlan-extension-for-vbras-00
Abstract
This document briefly describes the architecture of control plane and
user plane separated BRAS and the VxLAN extension requirement for
Signaling Exchange between control plane and user plane. It also
describes some possible solutions.
Status of This Memo
This Internet-Draft is submitted to IETF 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 September 2, 2017.
Copyright Notice
Copyright (c) 2017 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.
Huang & Hu Expires September 2, 2017 [Page 1]
Internet-Draft vxlan-extension-for-vbras-00 March 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Analysis on solutions . . . . . . . . . . . . . . . . . . . . 4
4.1. VxLAN header solution . . . . . . . . . . . . . . . . . . 4
4.2. Combination of VxLAN and NSH . . . . . . . . . . . . . . 5
4.3. Assign VNIs for every port . . . . . . . . . . . . . . . 5
4.4. Summury of these soluitlons . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
For migration of vBRAS, one way is separating the control and user
plane of traditional BRAS. Control plane is deployed in centrolized
cloud DC and user plane is fulfilled by high performance hardware
device, e.g. router, switch, etc. VxLAN is used to transfer some of
signaling packets between CP and user UP. For carrying information
of access user VxLAN need to be extended or combined with other
protocols/mechanisms.
2. Terminology
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].
3. Requirement
The architecture of C/U separated BRAS is shown as the following
figure.
Huang & Hu Expires September 2, 2017 [Page 2]
Internet-Draft vxlan-extension-for-vbras-00 March 2017
+----------------------------------+
| |
| BRAS-CP |
| |
+--+--------------+--------------+-+
| | |
Signaling | Management | Configuration|
Interface | Interface | Interface |
| | | | | |
VxLAN | OpenFlow | NETCONF |
| | |
+--+--------------+--------------+-+
| |
| BRAS-UP |
| |
+-----------------+----------------+
|
|
+--------+--------+
| |
| Access Network |
| |
+--------+--------+
|
+----+----+
| |
| User |
| |
+---------+
Figure 1: Architecture of C/U separated vBRAS
In this architecture, control plane (CP) is responsible for user
access authentication and setting forwarding entries of user plane if
authentication is successful. User plane (UP) need to relay PPPoE/
IPoE signaling packets between users and CP and forward PPPoE/IPoE
data packets to Internet based on the forwarding entries set by CP.
CP should do some basic configurations on UP, e.g. service
configuration.
There are three interfaces between CP and UP. Configuration
interface is used by CP to carry out basic configurations of user
plane through NETCONF. Management interface is used for seting
forwarding entries of user plane through OpenFlow. Signaling
interface is used to transfering PPPoE/IPoE signaling packets between
user plane and control plane. VxLAN is chosen for signaling
interface since it's a relatively mature technology and can carry L2
Huang & Hu Expires September 2, 2017 [Page 3]
Internet-Draft vxlan-extension-for-vbras-00 March 2017
packets through L3 network. For user access authentication, CP need
to know which port of UP the user is connected to for the
authentication of access location because a specfic user is only
permitted on specific port. Usually the following information is
necessary: device ID, slot ID, subcard ID and port ID, which need
about 16 to 32 bits totally. The access port information should be
carried in VxLAN packets encapsulated by UP. So an entension on
VxLAN or some other mechanism is necessary for this requirement.
4. Analysis on solutions
4.1. VxLAN header solution
In VxLAN header, two possible fields can carry the required
information.
One is VNI field in which 16 bits is used for carrying port
information and 8 bits for the real VxLAN ID. The advantage is no
amendment on VxLAN header is required and most of current devices can
work as UP based on standard VxLAN, e.g. routers, switches. The
disadvantage is too many VxLAN tunnels must be built and it's hard
for CP to build VxLAN tunnel with UP since it doesn't know VNI before
receiving VxLAN packets from UP.
Another is the reserved 32 bits in VxLAN header. The advantage is
the VNI and port info could be arranged separately and no further
field is introduce in. The disadvantage is the available reserved
bits is limited and the usage of reserved bits might conflict with
other draft. In addition, current devices need to upgrade to support
this new field.
At last, maybe we can extended VxLAN header. For example, we can
define a extension sign in current reverved bits and extend more
fielded beyond current format of VxLAN. The advantagethe is VNI and
port info could be arranged flexibly. The disadvantage is VxLAN
header should be amended and current devices need to upgrade to
support the amendment. The following figure is an example.
Huang & Hu Expires September 2, 2017 [Page 4]
Internet-Draft vxlan-extension-for-vbras-00 March 2017
Please view in a fixed-width font such as Courier.
+------------+-----------+-----------+------------+
| | | |Extension |
| | | |Sign |
|Flag |Reserved |VNI |= |
| | | |True |
+------------+-----------+-----------+------------+
| | | |
|Type= |Length |Port Information |
|PortInfo | | |
| | | |
+------------+-----------+------------------------+
Figure 2: Example of extension of VxLAN header
4.2. Combination of VxLAN and NSH
As mentioned in Network Service Header [I-D.ietf-sfc-nsh] and Generic
Protocol Extension for VXLAN [I-D.ietf-nvo3-vxlan-gpe], the field of
"Context Headers" in NSH can be used for carrying the required
information. The advantage is VNI and port info could be arranged
flexibly. The disadvantage is that introducing NSH in is a little
heavier than required and more functional requirements are put on UP
device. Furthermore, VxLAN-GPE and NSH are still in draft status.
4.3. Assign VNIs for every port
This method is also based on VNI. When UP is connected to CP, CP
will assign different VNI for every port. Both CP and UP should keep
a mapping table of VNI and port. Then CP can encapsulate PPPoE/IPoE
signaling packets with a specific VNI based on receiving port. CP
can get the port information through VNI and the mapping table. The
advantage is no amendment on VxLAN header is required and most of
current devices can work as UP based on standard VxLAN. The
disadvantage is too many VxLAN tunnels must be built and extra
complex mechanisms should be included in for VNI assignment and the
storage of mapping table.
4.4. Summury of these soluitlons
By comparison of the above solutions, we prefer to extend VxLAN
header to meet the requirement. Because it seems leverage the
flexibility and complexity. So some kind of extension on VxLAN
header need to be standardized.
Huang & Hu Expires September 2, 2017 [Page 5]
Internet-Draft vxlan-extension-for-vbras-00 March 2017
5. Security Considerations
None.
6. IANA Considerations
None.
7. Normative References
[I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-03 (work
in progress), October 2016.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-12 (work in progress), February 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>.
Authors' Addresses
Lu Huang (editor)
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing 100053
China
Email: hlisname@yahoo.com
Huang & Hu Expires September 2, 2017 [Page 6]
Internet-Draft vxlan-extension-for-vbras-00 March 2017
Shujun Hu
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing 100053
China
Email: 13488683482@139.com
Huang & Hu Expires September 2, 2017 [Page 7]
