Bcause Workgroup T. Yu
Internet-Draft March 8, 2019
Intended status: Informational
Expires: September 9, 2019

Requirements for BNG Control-plane And User-plane Separation


This document aims to abstract reqruriment of an extensible and flexible Control Plane (CP) and User Plane (UP) Separated BNG Architecture.

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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://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 9, 2019.

Copyright Notice

Copyright (c) 2019 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 (https://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

The architecture aims to decouple CP and UP.

CP focus on protocol signaling processing, service info management, and communication with external servers (e.g. Radius, DHCP servers).

Up focus on packet forwarding based on forwarding instructions from CP.

CUPS architecture brings significant benefits below:

2. Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. CU Seperation Basic Model

To support communication between the Control Plane and User Plane, several interfaces are involved. Figure 1 illustrates the three communication interfaces between CP and UP BNG.

   |                                  |
   |               BNG-CP             |
   |                                  |
      |              |             |
1.PIR |         2.GSF|   3.Magment |
      |              |             |
      |              |             |
   |                                  |
   |               BNG-UP             |
   |                                  |

Figure 1: Interfaces between the BNG-CP and the BNG-UP

4. Protocol Independent Relay (PIR)

To archieve a dis-aggregated system, a protocol independent Relay channel is required. PIP allows BNG to relay signaling protocols to the remote CP instead of processing and maintain status locally.

5. Generic-Service Flow Protocol (GSF)

GSF protocol is the interface for CP to deliver service based forwarding entries. Also UP will use this interface to notify whether the forwarding entries successfully delivered.

GSF SHOULD be highly flexible and extendable considering the variety, complexity of BNG services and possibility of the future service. To achieve this, a "generic-service" is abstracted with requirement below:

GSF is designed to be service oriented instead of instruction oriented. GSF defines service module precisely and UP adopts the service to the pipeline itself.

Below diagrams give some examples of using GS to compose BNG service flows:

   GSA                                              GSB            
|-------------|                                 |---------|    
|  GSI2       |                                 |  GSI3   |    
|-------------|                                 |---------|    
|  GSB1       |                                 |  GSB3   |    
|-------------|                                 |---------|    
|  GSA:       |                                 |  GSA:   |  
| type=subs   |                                 |type=pool|    
| S-ID=1      |                                 |         |    
|-------------|                                 |---------|    

|  GSI1'      |
|  GSB1       |
|  GSA:       |
| type=subs   |
| S-ID=2      |

Subs GS table                                 IP Pool GS table

Figure 2: Basic BNG Service Flow

Figure 2 shows how to use GS to form basic service flow for IPOE subscribers.

Traffic user->network: Search "Subs GS table" based on sMAC and sIP, traffic match GSA entry and get fowarding behavior is normal route recursive. UP will forward traffic based on FIB entries of dIP of the packet, which are learned from internet core.

Traffic network->user: Search FIB entries based on dIP will match the IP pool GS table, which is a sub-set of FIB table. The forwarding behavior (GSB3) is to search Subs GS table. UP will search Subs GS table and get the match entry, forward traffic to the interface and vlans of the curresponding subscriber.

|-----------|   |-----------|   |-----------|    |-----------|
| GS1 Table |   | GS2 Table |   | GS3 Table |    | GS4 Table |
|-----------|   |-----------|   |-----------|    |-----------|


Figure 3: BNG service flow with service channing

GS1 table is services of subscribers table, the format example of service in GS1 is as below:



GSI1-1: dIP =, dPort = 520

GSB1-1: GSI2-1 and SR-policy with color = gold

GSA1-1: service-type: service of subcriber

subscriber id = any

qos type: ef (inherit)

qos speed: cir = 128k (independent)



GSI1-2: match any

GSB1-2: GSI2-1

GSA1-2: service-type: service of subcriber

subscriber id = any

qos type: be (inherit)

qos speed: no limit(inherit)


GS2 table is subscriber table, the format example is as below:


GSI2-1: intf = 1/0/2, VLAN = 10, sMAC = 00-20-56-C0-00-0B, sIP =

GSB2-1: GSI3-1

GSA2-1: service-type: subcriber

subscriber id = 1000

qos type: be

qos speed: CIR = 10M, PIR = 20M (independent)


GS3 table is CGN NAT table, the format example is as below:


GSI3-1: sIP =

GSB3-1: Route recursive

GSA3-1: service-type: CGN NAT


The service flow above defines a subscriber with 2 services (VoIP and Internet), with subscriber based QOS (CIR = 10M, PIR = 20M) and service based QOS (VoIP, ef, cir = 128k), VoIP services goes into a gold SR-policy and internet traffic does best effort foewarding with CGN NAT translation.

6. Management Interface

For CUPS architecture, the CP MUST provide a single point for management of entire "CUPS" BNG.

Management interface for the CUPS system MUST provide support for both configuration of UPs, and state retrieval.

Management interface is used to report status, statistics, events from UP to CP. And also CP can use interface to query status of UP. This interface uses NETCONF protocol.

Netconf working group has already (or almost) standardized couple of mechanism can be used in CPUS architecture:

[I-D.ietf-netconf-subscribed-notifications] provides the mechanism of notifing any status changes of subscribers, resource utilisation etc..

[I-D.ietf-netconf-yang-push] provides the mechanism of a continuous, customized stream of updates from a YANG datastore.

UP Should have YANG datastores and subscribed by CP below:

[RFC5539] provides security mechanism for management interface.

7. Resiliency

8. Security Considerations


9. IANA Considerations


10. Normative References

[I-D.ietf-netconf-subscribed-notifications] Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E. and A. Tripathy, "Subscription to YANG Event Notifications", Internet-Draft draft-ietf-netconf-subscribed-notifications-23, February 2019.
[I-D.ietf-netconf-yang-push] Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen-Nygaard, E., Bierman, A. and B. Lengyel, "Subscription to YANG Datastores", Internet-Draft draft-ietf-netconf-yang-push-22, February 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, DOI 10.17487/RFC5539, May 2009.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

Author's Address

Tianpeng Yu EMail: yutianpeng.ietf@gmail.com