support gtp-u-in-ip forwarding table

[dliu2223]

we are using gribi and aft to forward 5G GTP-U packets, the data plane destination look-up sequence uses the following network header fields:

• port (RAN facing)
• L2 (VSI & VLAN)
• IP-UDP tunnel (UDP port + outer IP source + destination) to identify a gNB-UPF tunnel
• GTP-U subscriber tunnel (TEID)
• Inner-IP routing (source + destination IP)

Using AFT model, each FT is logically separated and entry is added as oneof entry {...}; therefore grouping multiple FT as another FT is not feasible. The current implementation augments the gribi-aft.yang to support a gtp-u table as:
| +--ro afts
| | +--ro gtp-u
| | +--ro gtp-u-entry* [outer-ip-source outer-ip-destination teid]
| | +--ro outer-ip-source // -> ../state/outer-ip-source
| | +--ro outer-ip-destination // -> ../state/outer-ip-destination
| | +--ro teid // -> ../state/teid
| | +--ro state
| | | +--ro outer-ip-source? // -> ../../gtp-u-in-ip/state/outer-ip/ipv4/source-address
| | | +--ro outer-ip-destination? // -> ../../gtp-u-in-ip/state/outer-ip/ipv4/destination-address
| | | +--ro teid? // -> ../../gtp-u-in-ip/state/tunnel/teid
| | | +--ro traffic-class-mapping-profile? // -> ../../../../../../../qos/traffic-class-mapping-profiles/traffic-class-mapping-profile/config/name
| | | +--ro next-hop-group? // -> /oc-ni:network-instances/network-instance/afts/next-hop-groups/next-hop-group/state/id
| | | +--ro next-hop-group-network-instance? oc-ni:network-instance-ref
| | +--ro gtp-u-in-ip
| | | +--ro state
| | | +--ro l2
| | | | +--ro vlan? uint16
| | | +--ro outer-ip
| | | | +--ro ipv4
| | | | +--ro source-address? oc-inet:ipv4-prefix
| | | | +--ro destination-address? oc-inet:ipv4-prefix
| | | +--ro udp
| | | | +--ro port? oc-inet:port-number
| | | +--ro tunnel
| | | | +--ro teid? uint64
| | | | +--ro qfi? uint8
| | | +--ro inner-ip
| | | +--ro ip-address-set? ip-address-set. // enum for v4 or v6 ip
| | | +--ro ipv4
| | | | +--ro source-address? oc-inet:ipv4-prefix
| | | | +--ro destination-address? oc-inet:ipv4-prefix
| | | | +--ro dscp? oc-inet:dscp
| | | +--ro ipv6
| | | +--ro source-address? oc-inet:ipv6-prefix
| | | +--ro source-flow-label? oc-inet:ipv6-flow-label
| | | +--ro destination-address? oc-inet:ipv6-prefix
| | | +--ro destination-flow-label? oc-inet:ipv6-flow-label
| | | +--ro dscp? oc-inet:dscp

There are other augmentations like traffic-class-mapping-profile included here to enable per flow QoS, but ignore for now,, we will create a thread in QoS.

Looking forward to getting your feedback. Thanks

David

[robshakir]

It looks like this might be something that overlaps with the reworked structure in #93 -- could you PTAL, it might allow you to remove the augment that you have specified.

Thanks!
r.