VxLAN Extension Requirement for Signaling Exchange Between Control and User Plane of vBras

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 .

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 | | | +---------+ 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.

As mentioned in Network Service Header and Generic Protocol Extension for VXLAN, 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.