Page History

...

...

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

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 (see flow diagram further below):
   1. BRG Emulator comes up and issues a DHCP Discover request for its WAN 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
   2. vBNG intercepts the DHCP request, stores it, and issues a Radius Access-Request with the DHCP request options to vAAA
   3. vAAA sends  the Access-Accept back to vBNG
   4. Upon receiving the accept vBNG restores the DHCP request and relays it to vDHCP
   5. vDHCP sends a DHCP Offer with the BRG WAN IP
   6. BRG Emulator sends a DHCP rquest with its WAN IP address
   7. vBNG snoops the request and relays it to vDHCP
   8. vDHCP sends a DHCP Ack to BRG, and issues an event on DMaaP that a new address has been provided to a BRG
   9. SDNC consumes this event and creates a PNF object in A&AI with the MAC and IP addresses of the BRG
   10. A&AI issues an event on DMaaP announcing that a new PNF has been created
   11. A BSS emulator implemented in Robot consumes this event
6. 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
7. 1. h 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).
8. 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:

...

• A BRG, which will be a physical device (PNF) dedicated to the customer's service instance.
• A vG, which is a virtual network function that is dedicated to the customer's service instance.
• A "slice" of functionality of the vGMUX, which provides a "cross connect" function between the BRG and vG.  We use the term "slideslice" informally to convey the sense that something (capacity) is consumed and dedicated (configuration record) in the vGMUX for this customer's service instance.  The way in which SDC models a "slice" of functionality of a VNF is through the "Allotted Resource" construct, because what is being consumed by the customer's service instance is an "allotment" of capacity and configuration from the underlying vGMUX.  We will refer to this as the TunnelXConn Allotted Resource.

...