[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/