...

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

• At stand-up time SDNC configures BRG Emulator with the address of vG_MUX for tunneling. SDNC knows this address because SDNC assigned it prior to vG_MUX stand up.
• 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
• vBNG intercepts the DHCP request, stores it, and issues a Radius Access-Request with the DHCP request options to vAAA
• vAAA sends  the Access-Accept back to vBNG
• Upon receiving the accept vBNG restores the DHCP request and relays it to vDHCP
• vDHCP sends a DHCP Offer with the BRG WAN IP
• BRG Emulator sends a DHCP rquest with its WAN IP address
• vBNG snoops the request and relays it to vDHCP|
• vDHCP sends a DHCP Ack to BRGONAP configured BRG Emulator with the address of vG-MUX for tunneling at stand-up time
• BRG Emulator creates a new VxLAN tunnel interface over it 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. For vCPE the VNI field is further divided to two inner fields:
    • VNI VNI: 12-bit value that provides a unique identifier for the VXLAN segment in which this particular vBNG and this particular vG_MUX are involved.
    • VNI VLAN ID: 12-bit value consisting of the VLAN ID that is assigned by SDNC on a per-customer basis and configured to BRG Emulator and vG at stand up time.
• 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 WANT 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:

• When a packet arrives, a corresponding entry is looked up using all 3 fields from the incoming packet. 
• If not found, an entry with these 3 fields is created, and processing is continued. 
• The packet is decapsulated, the original L2 frame is tagged with VNI VLAN ID and is forwarded to the destination vG.

vG → BRG Emulator direction:

• When a packet arrives, a corresponding entry is looked up using the incoming vlan id of the packet trying to match it with the VNI VLAN ID field of table entries. 
• If found, the vlan tag of the packet is removed, the packet is encapsulated with the fields in the entry, and is sent over the vG_MUX tunnels interface.
• 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.

Network Function:

...