文章目录

VPP_UPF_CONFIG_GENERATION.md
- VPP UPF Configuration Generation
- Environment variables
- Interfaces
- Interface Configuration Examples
- - Central UPF
  - A-UPF
  - I-UPF
  - UL CL
FEATURE_SET.md
VPP_UPG_CLI
参考文献

VPP_UPF_CONFIG_GENERATION.md

VPP UPF Configuration Generation

这个文章比较关键

init.conf

startup_debug.conf

upf_profile.json

create_configuration.py

The VPP-UPF configuration for different UPF deployment options (A-UPF, I-UPF, ULCL) are not compatible with each other.
The example described in VPP_UPF_CONFIG shows a central UPF node with one N3 and one N6
interface.

To ease the deployment, the UPF configuration can be auto-generated using the create_configuration.py script. It is
located in scripts/upf_conf/create_configuration.py. If you choose to use the official OAI docker images (from v1.5.0), this script is
executed upon start of the containers.

It takes three positional arguments:

usage: create_configuration.py
       [-h]
       [--rename]
       init_path
       profile_path
       startup_path

The init_path is the path to the init file that will be generated. A json file is written to the profile_path which
contains the UPF profile which is sent to the NRF.

The startup_path requires an existing VPP startup_debug.conf file with placeholders (@value@). These will be
overwritten with the corresponding environment variables.

If you choose to rename using the --rename option, the host interfaces are renamed from e.g. eth1 to n6-3.
Which interface is renamed depends on the configured subnet.

Environment variables

The UPF configuration is built entirely from environment variables. There are static variables, which always have to be
present:

Environment Variable	Description	Used in
NAME	Used to build the UPF FQDN	init.conf, profile.json
MNC	Used to build the UPF FQDN	init.conf, profile.json
MCC	Used to build the UPF FQDN	init.conf, profile.json
REALM	Used to build the UPF FQDN	init.conf, profile.json
VPP_MAIN_CORE	Which CPU core ID to use for the main thread	startup_debug.conf
VPP_CORE_WORKER	Which CPU core ID to use for the worker thread *	startup_debug.conf
SNSSAI_SD	SD from the SNSSAI	profile.json
SNSSAI_SST	SST from the SNSSAI	profile.json
DNN	DNN	profile.json
VPP_PLUGIN_PATH	Path where the UPG VPP plugin is installed	startup_debug.conf

* This config from VPP allows to configure more than one worker thread, e.g. 1-4, but it is not recommended in the
VPP-UPF, as there are race conditions.

The UPF FQDN is built as follows:

<name>.node.5gcn.mnc<mnc>.mcc<mcc>.<realm>

The NAME variable is translated to lower-case.

Then, there are support features which you also have to configure:

Environment Variable	Description
REGISTER_NRF	If the UPF should register to NRF
NRF_IP_ADDR	The NRF IP address
NRF_PORT	The NRF Port
HTTP_VERSION	HTTP version towards NRF (1/2)

Apart from this global configuration, you can dynamically configure your interfaces.
The syntax to configure an interface is as follows:

IF_<Index>_<Value>

Each interface can have multiple values, whereas the index describes the interface.
The following values are available:

Value	Description	Mandatory
IP	IP address of the interface**	yes
TYPE	Either N3, N4, N6 or N9	yes
NWI	Network Instance of the interface	yes (not for N4)
DNAI	Data Network Access Identifier	no
IP_REMOTE	Next hop IP, optional when using `--rename`	yes/no

** Should belong to subnet of existing host interface

An example of a UPF configuration is as follows (see also the docker-compose file):

- IF_1_IP=192.168.70.201
- IF_1_TYPE=N4
- IF_2_IP=192.168.72.201
- IF_2_TYPE=N3
- IF_2_NWI=access.oai.org
- IF_3_IP=192.168.73.201
- IF_3_TYPE=N6
- IF_3_IP_REMOTE=192.168.73.135 # EXT-DN IP Address
- IF_3_NWI=internet.oai.org
- NAME=VPP-UPF
- MNC=95
- MCC=208
- REALM=3gppnetwork.org
- VPP_MAIN_CORE=0
- VPP_CORE_WORKER=1
- VPP_PLUGIN_PATH=/usr/lib/x86_64-linux-gnu/vpp_plugins/ # Ubntu18.04
- SNSSAI_SD=123
- SNSSAI_SST=222
- DNN=default
- REGISTER_NRF=yes
- NRF_IP_ADDR=192.168.70.130
- NRF_PORT=80
- HTTP_VERSION=1

Interfaces

We use veth pairs to configure the UPF interfaces. Each UPF interface (e.g. N3) has a host interface IP and the IP address
used for signaling. You need one subnet for each UPF interface. In a typical deployment, you need at least three subnets:

Signaling (N4)
Access (N3)
Core/Internet (N6).

The IP value should belong to the same subnet as the host interface, but must not be the same.

The IP_REMOTE value also needs to be in the same subnet and is used to setup the routes accordingly.
When you use the --rename option, the IP_REMOTE is automatically calculated from the subnet from the IP value.
The remote IP is always the first host in the subnet, e.g. for the IP 192.168.70.201 in the subnet 192.168.70.0/24,
the remote IP is 192.168.70.1.

The value you provide overrides the default value. When you do not rename the interfaces, you need to manually specify
the remote IP address.

Interface Configuration Examples

The dynamic creation allows you to configure different UPF types.

Central UPF

This UPF has one N3, one N4 and one N6 interface:

- IF_1_IP=192.168.70.201
- IF_1_TYPE=N4
- IF_2_IP=192.168.72.201
- IF_2_TYPE=N3
- IF_2_NWI=access.oai.org
- IF_3_IP=192.168.73.201
- IF_3_TYPE=N6
- IF_3_NWI=internet.oai.org

A-UPF

This UPF has one N9, one N4 and one N6 interface:

- IF_1_IP=192.168.70.202
- IF_1_TYPE=N4
- IF_2_IP=192.168.74.202
- IF_2_TYPE=N9
- IF_2_NWI=iupf.node.5gcn.mnc98.mcc208.3gppnetwork.org
- IF_2_DNAI=iupf
- IF_3_IP=192.168.75.202
- IF_3_TYPE=N6
- IF_3_NWI=internet.oai.org
- IF_3_DNAI=internet

When you want to use multiple UPFs which should be chained or form a graph, you need to ensure that the NWI of the
configuration matches the FQDN of the other UPF. In this case, IUPF should have the following FQDN config:

- NAME=IUPF
- MNC=98
- MCC=208
- REALM=3gppnetwork.org

I-UPF

This UPF has one N3, one N4 and one N9 interface:

- IF_1_IP=192.168.70.203
- IF_1_TYPE=N4
- IF_2_IP=192.168.72.203
- IF_2_TYPE=N3
- IF_2_NWI=access.oai.org
- IF_2_DNAI=access
- IF_3_IP=192.168.74.203
- IF_3_TYPE=N9
- IF_3_NWI=aupf.node.5gcn.mnc98.mcc208.3gppnetwork.org
- IF_3_DNAI=aupf

As you can see, the N9 interface is in the same subnet as the N9 interface of the I-UPF example. This means
that the SMF will create an edge between these two nodes (as long as the FQDN/NWI configuration matches).
Also, the DNAI is configured for these examples to enable SMF in selecting a specific UPF for a PDU session.

UL CL

This UPF has one N3, one N4 and two N9 interfaces:

- IF_1_IP=192.168.70.204
- IF_1_TYPE=N4
- IF_2_IP=192.168.72.204
- IF_2_TYPE=N3
- IF_2_NWI=access.oai.org
- IF_2_DNAI=access
- IF_3_IP=192.168.74.204
- IF_3_TYPE=N9
- IF_3_NWI=aupf1.node.5gcn.mnc98.mcc208.3gppnetwork.org
- IF_3_DNAI=aupf1
- IF_4_IP=192.168.76.204
- IF_3_TYPE=N9
- IF_3_NWI=aupf2.node.5gcn.mnc98.mcc208.3gppnetwork.org
- IF_4_DNAI=aupf2

FEATURE_SET.md

FEATURE_SET.md
在这里插入图片描述

VPP_UPG_CLI

VPP-UPF 可以进行的一些操作

$ docker exec -it vpp-upf ./bin/vppctl show upf help
  adf                            show upf adf commands
  application                    show upf application <name>
  applications                   show upf applications [verbose]
  association                    show upf association
  bihash                         show upf bihash <v4-tunnel-by-key | v6-tunnel-by-key | qer-by-id | peer-index-by-ip> [detail|verbose]
  flows                          show upf flows
  flow                           show upf flow commands
  gtpu                           show upf gtpu commands
  node-id                        show upf node-id
  nwi                            show upf nwi
  pfcp                           show upf pfcp commands
  policy                         show upf policy
  proxy                          show upf proxy
  session                        show upf session
  specification                  show upf specification commands
  tdf                            show upf tdf commands

Show PFCP session at UPF

$ docker exec -it vpp-upf ./bin/vppctl show upf session
CP F-SEID: 0x0000000000000001 (1) @ 192.168.70.133
UP F-SEID: 0x0000000000000001 (1) @ 192.168.70.202
  PFCP Association: 0
  TEID assignment per choose ID
PDR: 1 @ 0x7f6cef01cd00
  Precedence: 0
  PDI:
    Fields: 0000000d
    Source Interface: Access
    Network Instance: access.oai.org
    Local F-TEID: 218138074 (0x0d0085da)
            IPv4: 192.168.72.202
    UE IP address (source):
      IPv4 address: 12.1.1.2
    SDF Filter [1]:
      permit out ip from any to assigned 
  Outer Header Removal: GTP-U/UDP/IPv4
  FAR Id: 1
  URR Ids: [1] @ 0x7f6ceefde850
  QER Ids: [] @ 0x0
PDR: 2 @ 0x7f6cef01cd80
  Precedence: 0
  PDI:
    Fields: 0000000c
    Source Interface: Core
    Network Instance: core.oai.org
    UE IP address (destination):
      IPv4 address: 12.1.1.2
    SDF Filter [1]:
      permit out ip from any to assigned 
  Outer Header Removal: no
  FAR Id: 2
  URR Ids: [1] @ 0x7f6ceefde8e0
  QER Ids: [] @ 0x0
FAR: 1
  Apply Action: 00000002 == [FORWARD]
  Forward:
    Network Instance: core.oai.org
    Destination Interface: 1
FAR: 2
  Apply Action: 00000002 == [FORWARD]
  Forward:
    Network Instance: access.oai.org
    Destination Interface: 0
    Outer Header Creation: [GTP-U/UDP/IPv4],TEID:9acb0442,IP:192.168.72.141
URR: 1
  Measurement Method: 0002 == [VOLUME]
  Reporting Triggers: 0001 == [PERIODIC REPORTING]
  Status: 0 == []
  Start Time: 2022/09/02 07:29:30:476
  vTime of First Usage:       0.0000 
  vTime of Last Usage:        0.0000 
  Volume
    Up:    Measured:                    0, Theshold:                    0, Pkts:          0
           Consumed:                    0, Quota:                       0
    Down:  Measured:                    0, Theshold:                    0, Pkts:          0
           Consumed:                    0, Quota:                       0
    Total: Measured:                    0, Theshold:                    0, Pkts:          0
           Consumed:                    0, Quota:                       0
  Measurement Period:                   10 secs @ 2022/09/02 07:29:40:476, in     5.597 secs, handle 0x00000c01