| NVO3 | L. Huang, Ed. |
| Internet-Draft | S. Hu |
| Intended status: Informational | China Mobile |
| Expires: September 3, 2017 | March 2, 2017 |
VxLAN Extension Requirement for Signaling Exchange Between Control and User Plane of vBras
draft-huang-nvo3-vxlan-extension-for-vbras-00
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.
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 3, 2017.
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.
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.
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].
The architecture of C/U separated BRAS is shown as the following figure.
+----------------------------------+
| |
| 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 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.
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.
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
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.
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.
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.
None.
None.
| [I-D.ietf-nvo3-vxlan-gpe] | Maino, F., Kreeger, L. and U. Elzur, "Generic Protocol Extension for VXLAN", Internet-Draft draft-ietf-nvo3-vxlan-gpe-03, October 2016. |
| [I-D.ietf-sfc-nsh] | Quinn, P. and U. Elzur, "Network Service Header", Internet-Draft draft-ietf-sfc-nsh-12, 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. |
| [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. |