Note: Some edits to the text and flow diagrams are still expected in the next few days. These edits are the result of meetings and decision taken regarding the use case in the past 2-3 weeks. Most of the work-impacting modifications have already been communicated and reviewed with the relevant projects; those that haven't yet are expected to have minor impact, and will be reviewed during the week of Aug 21st.

Name of Use Case:       

Residential Broadband vCPE

Use Case Authors:

Amdocs, AT&T, Intel, Orange, Wind River

Description:

Technical Report 317 (TR-317) from the Broadband Forum specifies a "Network Enhanced Residential Gateway" (NERG) that can be used by service providers (SP) to deploy residential broadband services including High Speed Internet access, IPTV and VoIP services. A new device type named BRG (Bridged Residential Gateway) is defined, as well as a functionality split between what it would run and what a virtual function instantiated in the SP's cloud, called vG, will run. This functionality split allows for the introduction of new services not possible with the existing whole-physical residential gateway. It also saves operational cost with less changes / truck roll in and to the customer residence would be needed. 

Key for this use case is:

• ONAP will be used to instantiate, configure and manage the vCPE service as a cloud service that may be collocated with other subscriber services such as vSTB, cloud DVR and VoD-streaming vCDN.
• SDN is used to configure the connectivity with the first mile network, the IP subscriber management and service edge networking. Potentially in the future, dynamic service chaining to value-add services (e.g. security, parental control, home automation IoT).

The full details for this this new residential gateway can be found in the BBF report. For ONAP Release 1 (Dec 2017) a subset of the full functionality of TR-317 will be included in the VNFs implementing the vCPE use case; but the ONAP behavior for the use case will be mostly what will be expected from ONAP in a production network.

Image Removed

The diagram above depicts the R1 vCPE use case (with the exception of the home networks on the left which will not be part of the tested use case). The IP addresses and VLAN numbers are for illustration purposes, the actual values may be different in the final set up. In particular, IPv6 addresses may be used in place of IPv4 10.x.x.x in the above.

Users and Benefit:

• • • Residential users benefit from subscriber specific cloud services and automation that does not need truck roll installation, local configuration and management of LAN/NAT/WAN/VPN networking.
    • Authenticated subscribers may access similar broadband services outside the home residence using other wireline or wireless access networks.
    • SPs benefit from a more flexible platform to evolve residential broadband services that do not depend on the lifecycles of provided home devices (e.g. STB, WiFi access router, modem etc…)

Scope

To be added

R1 Use Case Flows

Basic flow for establishment of the LSL (Logical Subscriber Link):

...

Name of Use Case:       

Residential Broadband vCPE

Use Case Authors:

Amdocs, AT&T, Huawei, Intel, Orange, Wind River

Description:

Technical Report 317 (TR-317) from the Broadband Forum specifies a "Network Enhanced Residential Gateway" (NERG) that can be used by service providers (SP) to deploy residential broadband services including High Speed Internet access, IPTV and VoIP services. A new device type named BRG (Bridged Residential Gateway) is defined, as well as a functionality split between what it would run and what a virtual function instantiated in the SP's cloud, called vG, will run. This functionality split allows for the introduction of new services not possible with the existing whole-physical residential gateway. It also saves operational cost with less changes / truck roll in and to the customer residence would be needed. 

Key for this use case is:

• ONAP will be used to instantiate, configure and manage the vCPE service as a cloud service that may be collocated with other subscriber services such as vSTB, cloud DVR and VoD-streaming vCDN.
• SDN is used to configure the connectivity with the first mile network, the IP subscriber management and service edge networking. Potentially in the future, dynamic service chaining to value-add services (e.g. security, parental control, home automation IoT).

The full details for this this new residential gateway can be found in the BBF report. For ONAP Amsterdam Release (Nov 2017) a subset of the full functionality of TR-317 will be included in the VNFs implementing the vCPE use case; but the ONAP behavior for the use case will be mostly what will be expected from ONAP in a production network.

Image Added

The diagram above depicts the R1 vCPE use case (with the exception of the home networks on the left which will not be part of the tested use case). The IP addresses and VLAN numbers are for illustration purposes, the actual values may be different in the final set up. In particular, IPv6 addresses may be used in place of IPv4 10.x.x.x in the above.

Users and Benefit:

• • • Residential users benefit from subscriber specific cloud services and automation that does not need truck roll installation, local configuration and management of LAN/NAT/WAN/VPN networking.
    • Authenticated subscribers may access similar broadband services outside the home residence using other wireline or wireless access networks.
    • SPs benefit from a more flexible platform to evolve residential broadband services that do not depend on the lifecycles of provided home devices (e.g. STB, WiFi access router, modem etc…)

Virtual Network Functions:

NFVI+VIM:

Use Case Order of Activation

The assumed order of operations for the run time use case experience is as follows:

1. 1. Via VID, user (Robot) will request ONAP to create an instance of the GenInfra Service
   2. Via VID, user (Robot) will request ONAP to create an instance of the BNG_MUX Service (a network only service).
   3. Via VID, user (Robot) will request ONAP to create an instance of the vGMuxInfra Service.
   4. Via VID, user (Robot) will request ONAP to create an instance of the vBngInfra Service.
      
      At this point all required infrastructure is in place to accept a customer service request. In real life such a request will come to the BSS portal, and one of the things done there is initiation of a shipment order of a physical BRG to the customer. In the use case we emulate the physical box with a VNF called BRG_EMU.
      
      
   5. Via Robot, request ONAP to create an instance of the BRG emulator, the BRG_EMU Service. What happens behind the scenes is the following:
      1. BRG Emulator comes up and issues a DHCP Discover request for its WAP i/f
      • • The request contains option 125 (BBF) with sub-option NERG Device Type (24) with string "BRG"
        • For the demo - the request will include option 82 as if entered by an AN
      1. vBNG intercepts the DHCP request, stores it, and issues a Radius Access-Request with the DHCP request options to vAAA
      2. vAAA sends  the Access-Accept back to vBNG
      3. Upon receiving the accept vBNG restores the DHCP request and relays it to vDHCP
      4. vDHCP sends a DHCP Offer with the BRG WAN IP
      5. BRG Emulator sends a DHCP rquest with its WAN IP address
      6. vBNG snoops the request and relays it to vDHCP
      7. vDHCP sends a DHCP Ack to BRG

...

The newly created tunnel i/f will be used for all communications between BRG Emulator and its pair vG. Below is the frame format of packets sent inside this tunnel:

VXLAN Packet Format

...

Fields description going from right to left in the figure above:

• • • Original L2 Frame consists of the whole packet that should eventually arrive in vG, starting from the original MAC header. 
    • VXLAN Header: This is an 8-byte (64-bit) field that includes the following fields:
      
      • Flags: 8 bits in length, where the 5th bit (I flag) is set to 1 to indicate a valid VNI. The remaining 7 bits (R bits) are reserved fields and are set to zero
      • Reserved fields must all be set to 0 when sending and ignored when receiving. 
      • VNI: 24-bit value that provides a unique identifier for the individual VXLAN segment. 
    • Outer UDP Header: The source port in the outer UDP header is dynamically assigned by the originating VTEP (BRG Emulator or vG_MUX) and the destination port is the well-known UDP port 4789.
    • Outer IP Header: The outer IP header has a source IP address of the source VTEP (when sent by BRG Emulator - its WAN IP) . The outer destination IP address is the IP address of the destination VTEP (when sent by BRG Emulator - the vG_MUX IP).
    • Outer MAC Header: The outer Ethernet header has a source MAC address of the VTEP (when sent by BRG Emulator - its MAC addr on its WAN i/f). The destination MAC address is the MAC address of the routing next-hop to reach the destination VTEP (when sent by BRG Emulator - the MAC addr of vBNG on its interface facing BRG Emulator)

The role of vG_MUX is to terminate VXLAN tunnels (typically utilizing public IP addresses) and relay packet to/from local vGs. In the vCPE use case VLAN IDs are used to distinguish between different vGs connecting to vG_MUX. To this end vG_MUX maintains a XC tabel of the following format: <Remote VTEP IP, VNI VNI, VNI VLAN ID>. vG_MUX uses this table as follows:

BRG Emulator → vG direction:

...

1. 1. 1. , and issues an event on DMaaP that a new address has been provided to a BRG
      2. SDNC consumes this event and creates a PNF object in A&AI with the MAC and IP addresses of the BRG
      3. A&AI issues an even on DMaaP announcing that a new PNF has been created
      4. A BSS emulator implemented in Robot consumes this event
   2. Robot, now acting as a BSS emulator, requests ONAP to create an instance of the vCpeResCust Service.
      1. As part of the ONAP flow of this request (appears further below), SDNC looks up in A&AI the PNF object that was created in step viii above, from which it learns the WAN IP address of BRG_EMU
      2. SDNC creates a new TunnelXC entry in vG_MUX 
      3. SDNC configures BRG_EMU (using its WAN IP address) with the address of vG_MUX and the VNI value for tunneling (SDNC knows this address because SDNC assigned it prior to vG_MUX stand up).
   3. BRG Emulator creates a new VxLAN tunnel interface over its WAN interface using its WAN IP as the local address and the configured vG_MUX IP as the remote address.

The newly created tunnel i/f will be used for all communications between BRG Emulator and its pair vG. Below is the frame format of packets sent inside this tunnel:

VXLAN Packet Format

Image Added

Fields description going from right to left in the figure above:

• • • Original L2 Frame consists of the whole packet that should eventually arrive in vG, starting from the original MAC header. 
    • VXLAN Header: This is an 8-byte (64-bit) field that includes the following fields:
      
      • Flags: 8 bits in length, where the 5th bit (I flag) is set to 1 to indicate a valid VNI. The remaining 7 bits (R bits) are reserved fields and are set to zero
      • Reserved fields must all be set to 0 when sending and ignored when receiving. 
      • VNI: 24-bit value that provides a unique identifier for the individual VXLAN segment. 
    • Outer UDP Header: The source port in the outer UDP header is dynamically assigned by the originating VTEP (BRG Emulator or vG_MUX) and the destination port is the well-known UDP port 4789.
    • Outer IP Header: The outer IP header has a source IP address of the source VTEP (when sent by BRG Emulator - its WAN IP) . The outer destination IP address is the IP address of the destination VTEP (when sent by BRG Emulator - the vG_MUX IP).
    • Outer MAC Header: The outer Ethernet header has a source MAC address of the VTEP (when sent by BRG Emulator - its MAC addr on its WAN i/f). The destination MAC address is the MAC address of the routing next-hop to reach the destination VTEP (when sent by BRG Emulator - the MAC addr of vBNG on its interface facing BRG Emulator)

The role of vG_MUX is to terminate VXLAN tunnels (typically utilizing public IP addresses) and relay packet to/from local vGs over newly created VxLAN tunnels. To this end vG_MUX maintains a XC tabel of the following format: <Remote VTEP IP, VNI>. vG_MUX uses this table as follows:

BRG Emulator → vG direction:

• • • When a packet arrives, vG_MUX looks up in its XC table an entry in which the arriving 2-tupple: <src_VTEP, VNI> matches < BRG_WAN_IP_ADDRESS, VNI>
    • If found, vG_MUX replaces the <dst_VTEP> filed in the packet with the <vG_IP_ADDRESS> field in the found entry, the <src_VTEP> with its own "right" ip address, leaves all other fields intact, and sends the packet to the vG.
    • If not found ( normally should not happen), the packet is discarded, and a counter counting such events is incremented. In future releases we may consider issuing an SNMP trap in such situations.
      
      

vG → BRG Emulator direction:

• • • When a packet arrives, vG_MUX looks up an entry in which the arriving 2-tupple: <VMI, src_VTEP> matches <VNI, vG_IP_ADDRESS>. 
    • If found, vG_MUX replaces the <dst_VTEP> filed in the packet with the <BRG_WAN_IP_ADDRESS> field in the found entry, the <src_VTEP> with its own "left" ip address, leaves all other fields intact, and sends the packet to the BRG.
    • If not found ( normally should not happen), the packet is discarded, and a counter counting such events is incremented. In future releases we may consider issuing an SNMP trap in such situations.
      
      

The first transaction that uses the VxLAN tunnel is the BRG Emulator's request to get its own IP address for its LAN interface, as follows:

• • • BRG Emulator sends a DHCP Discover packet for its LAN i/f to its pair vG (inside the VxLAN tunnel).
    • vG_MUX gets the packet and tries to find the corresponding entry in its XC table. Since this is the very first packet of this kind such entry is not found; vG_MUX creates a corresponding entry (see above) and forwards the packet to vG
    • vG sends a DHCP Offer with an address its DHCP server assigns to BRG Emulator's LAN i/f (from 192.168.1.0/24)
    • vG_MUX encapsulates the packet properly, and sends it over the corresponding VxLAN tunnel.
    • BRG Emulator sends a DHCP request with the offered address to vG (inside the tunnel)
    • vG_MUX forwards the packet to vG
    • vG sends a DHCP ACK 
    • vG_MUX encapsulates the packet properly, and sends it over the corresponding VxLAN tunnel.

Once BRG Emulator gets the ACK it is ready to start serving the home network.

Image Added

...

vG → BRG Emulator direction:

...

The first transaction that uses the VxLAN tunnel is the BRG Emulator's request to get its own IP address for its LAN interface, as follows:

• • • BRG Emulator sends a DHCP Discover packet for its LAN i/f to its pair vG (inside the VxLAN tunnel).
    • vG_MUX gets the packet and tries to find the corresponding entry in its XC table. Since this is the very first packet of this kind such entry is not found; vG_MUX creates a corresponding entry (see above) and forwards the packet to vG
    • vG sends a DHCP Offer with an address its DHCP server assigns to BRG Emulator's LAN i/f (from 192.168.1.0/24)
    • vG_MUX encapsulates the packet properly, and sends it over the corresponding VxLAN tunnel.
    • BRG Emulator sends a DHCP request with the offered address to vG (inside the tunnel)
    • vG_MUX forwards the packet to vG
    • vG sends a DHCP ACK 
    • vG_MUX encapsulates the packet properly, and sends it over the corresponding VxLAN tunnel.

Once BRG Emulator gets the ACK it is ready to start serving the home network.

Image Removed

Network Function:

...

Location

...

VNF

...

Code / Vendor

...

Comments

...

DC1

...

BRG Emulator

Goal: Release 1

...

VPP + modification by Intel

...

VPP based software used as the BRG emulator for the use case

Aspiration goal:

Monitoring of metrics and alarms of the BRG and automated action. Example policy based on monitoring:

-       Automatic reboot of the BRG because of high load (CPU).

Virtual Network Function / VNF:

...

Location

...

VNFs

...

Code / Vendor

...

Comments

DC1

...

vBNG

Goal: Release 1

...

Open Source:

• • • VPP + modification by Intel

...

BNG: Broadband Network Gateway

Includes suscriber session management, traffic aggregation and routing, and policy / QoS.

...

vG_MUX

Goal: Release 1

...

Open Source:

• • • VPP + modification by Intel

...

vG, including DHCP

Goal: Release 1

...

Open Source:

• • • VPP + modification by Intel

DHCP Server source: TBD

...

Provides basic routing capabilities and service selection for residential services.

...

vAAA

Goal: Release 1

...

• • • Open Source:
      • FreeRADIUS

...

vDHCP

Goal: Release 1

...

• • • OpenSource:
      
      • ISC

...

Instance 1: BRG WAN IP address assignment

Instance 2: vG WAN IP address assignment

...

vDNS

Goal: Release 1

...

• • • OpenSource:
      
      • BIND

...

NFVI+VIM:

...

Location

...

NFVI+VIMs

...

Code / Vendor

...

NFVI+VIM requirement

...

• • • Vendor:
      • Wind River (Titanium Cloud)

...

ONAP Flows:

Modeling vCPE Residential Broadband Services 

...

The run time functionality of these generic flows is as follows:

Generic Service Instantiation Flow

Image Removed

Generic Resource Level flow for Networks

Image Removed

Generic Resource Level Flow for VNFs

Image Removed

Use Case Order of Operations

The assumed order of operations for the run time use case experience is as follows:

...

The run time functionality of these generic flows is as follows:

Generic Service Instantiation Flow

Image Added

Generic Resource Level flow for Networks

Image Added

Generic Resource Level Flow for VNFs

Image Added

...

The diagram below shows more detail of step 5 in the above sequenceof the Use Case Order of Operation.  Note that only the "No BRG PNF Object" alternative flow is in scope for Release 1.  (I.e., in Release 1 the assumption is that the BRG PNF (emulated) will always be "plugged in" prior to the "customer service request" being released to ONAP.) 

...