srv6-mobile: Cherry-pick the update document from stable/2001

Updating the document of srv6-mobile plugin code.
This commit also fixes the following issues:

- Doxygen build structure
- No binary file included

Type: docs

Signed-off-by: Satoru Matsushima <satoru.matsushima@gmail.com>
Change-Id: I376386ef6fc9584ab945db7358e3c4a698471e9b
Signed-off-by: Satoru Matsushima <satoru.matsushima@gmail.com>

10 files changed, 248 insertions, 351 deletions

diff --git a/src/plugins/srv6-mobile/README.md b/src/plugins/srv6-mobile/README.md
deleted file mode 100644
index 18628806cbc..00000000000
--- a/src/plugins/srv6-mobile/README.md
+++ /dev/null
@@ -1,178 +0,0 @@
-SRv6 Mobile User Plane Plugin for VPP
-========================
-
-## Introduction
-
-This plugin module can provide the stateless mobile user plane protocols translation between GTP-U and SRv6.
-The functions of the translation take advantage of SRv6 network programmability.
-[SRv6 Mobile User Plane](https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane) defines the user plane protocol using SRv6
-including following stateless translation functions:
-
-- **T.M.GTP4.D:**  
-   GTP-U over UDP/IPv4 -> SRv6
-- **End.M.GTP4.E:**  
-   SRv6 -> GTP-U over UDP/IPv4
-- **End.M.GTP6.D:**   
-   GTP-U over UDP/IPv6 -> SRv6
-- **End.M.GTP6.E:**  
-   SRv6 -> GTP-U over UDP/IPv6
-
-These functions benefit user plane(overlay) to be able to utilize data plane(underlay) networks properly. And also it benefits
-data plane to be able to handle user plane in routing paradigm.
-
-## Getting started
-To play with SRv6 Mobile User Plane on VPP, you need to install following packages:
-
-	docker
-	python3
-	pip3
-
-	Python packages (use pip):
-	docker
-	scapy
-	jinja2
-
-
-### Quick-start
-
-1. Build up the docker container image as following:
-
-```
-$ git clone https://github.com/filvarga/srv6-mobile.git
-$ cd ./srv6-mobile/extras/ietf105
-$ ./runner.py infra build
-
-$ docker images
-REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
-ietf105-image       latest              577e786b7ec6        2 days ago          5.57GB
-ubuntu              18.04               4c108a37151f        4 weeks ago         64.2MB
-
-```
-
-The runner script [runner.py](test/runner.py) has features to automate configurations and procedures for the test.
-
-2. Instantiate test Scenario
-
-Let's try following command to instantiate a topology:
-
-```
-$ ./runner.py infra start
-```
-
-This command instantiates 4 VPP containers with following topology:
-
-![Topology Diagram](test/topo-init.png)
-
-You can check the instantiated docker instances with "docker ps".
-
-
-```
-$ docker ps
-CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS               NAMES
-44cb98994500        ietf105-image       "/bin/sh -c 'vpp -c …"   About a minute ago   Up About a minute                       hck-vpp-4
-6d65fff8aee9        ietf105-image       "/bin/sh -c 'vpp -c …"   About a minute ago   Up About a minute                       hck-vpp-3
-ad123b516b24        ietf105-image       "/bin/sh -c 'vpp -c …"   About a minute ago   Up About a minute                       hck-vpp-2
-5efed405b96a        ietf105-image       "/bin/sh -c 'vpp -c …"   About a minute ago   Up About a minute                       hck-vpp-1
-
-```
-
-You can login to and configure each instantiated container.
-
-```
-$ ./runner.py cmd vppctl 0
-
-Verified image: None
-connecting to: hck-vpp-1
-    _______    _        _   _____  ___
- __/ __/ _ \  (_)__    | | / / _ \/ _ \
- _/ _// // / / / _ \   | |/ / ___/ ___/
- /_/ /____(_)_/\___/   |___/_/  /_/    
-
-vpp#
-```
-
-## Test Scenarios
-### SRv6 Drop-in between GTP-U tunnel
-
-This test scenario introduces SRv6 path between GTP-U tunnel transparently. A GTP-U packet sent out from one end to another is translated to SRv6 and then back to GTP-U. All GTP-U tunnel identifiers are preserved in IPv6 header and SRH.
-
-
-#### GTP-U over UDP/IPv4 case
-
-This case uses SRv6 end functions, T.M.GTP4.D and End.M.GTP4.E.
-
-![Topology Diagram](test/topo-test_gtp4d.png)
-
-VPP1 is configured with "T.M.GTP4.D", and VPP4 is configured with "End.M.GTP4.E". Others are configured with "End". The packet generator sends a GTP-U packet over UDP/IPv4 toward the packet capture. VPP1 translates it to SRv6 toward D4::TEID with SR policy <D2::, D3::> in SRH. VPP4 translates the SRv6 packet to the original GTP-U packet and send out to the packet capture.
-
-To start this case with IPv4 payload over GTP-U, you can run:
-
-```
-$ ./runner.py test tmap
-```
-
-If you want to use IPv6 payload instead of IPv4, you can run:
-
-```
-$ ./runner.py test tmap_ipv6
-```
-
-
-#### GTP-U over UDP/IPv6 case
-
-This case uses SRv6 end functions, End.M.GTP6.D.Di and End.M.GTP6.E.
-
-![Topology Diagram](test/topo-test_gtp6d.png)
-
-VPP1 is configured with "End.M.GTP6.D.Di", and VPP4 is configured with "End.M.GTP4.E". Others are configured with "End". The packet generator sends a GTP-U packet over UDP/IPv6 toward D:: of the packet capture. VPP1 translates it to SRv6 toward D:: with SR policy <D2::, D3::, D4::TEID> in SRH. VPP4 translates the SRv6 packet to the original GTP-U packet and send out to the packet capture.
-
-To start this case with IPv4 payload over GTP-U, you can run:
-
-```
-$ ./runner.py test gtp6_drop_in
-```
-
-If you want to use IPv6 payload instead of IPv4, you can run:
-
-```
-$ ./runner.py test gtp6_drop_in_ipv6
-```
-
-
-### GTP-U to SRv6
-
-This test scenario demonstrates GTP-U to SRv6 translation. A GTP-U packet sent out from one end to another is translated to SRv6.
-
-#### GTP-U over UDP/IPv6 case
-
-##### IPv4 payload
-
-This case uses SRv6 end functions, End.M.GTP6.D and End.DT4.
-
-![Topology Diagram](test/topo-test_gtp6.png)
-
-VPP1 is configured with "End.M.GTP6.D", and VPP4 is configured with "End.DT4". Others are configured with "End". The packet generator sends a GTP-U packet over UDP/IPv6 toward D::2. VPP1 translates it to SRv6 toward the IPv6 destination consists of D4:: and TEID of GTP-U with SR policy <D2::, D3::> in SRH. VPP4 decapsulates the SRv6 packet and lookup the table for the inner IPv4 packet and send out to the packet capture.
-
-To start this case, you can run:
-
-```
-$ ./runner.py test gtp6
-```
-
-##### IPv6 payload
-
-This case uses SRv6 end functions, End.M.GTP6.D and End.DT6.
-
-
-![Topology Diagram](test/topo-test_gtp6ip6.png)
-
-The configurations are same with IPv4 payload case, except D4:: is configured as "End.DT6" in VPP4. VPP4 decapsulates the SRv6 packet and lookup the table for the inner IPv6 packet and send out to the packet capture.
-
-If you want to use IPv6 payload instead of IPv4, you can run:
-
-```
-$ ./runner.py test gtp6_ipv6
-```
-
-## More information
-TBD
diff --git a/src/plugins/srv6-mobile/extra/README.md b/src/plugins/srv6-mobile/extra/README.md
deleted file mode 100644
index 3b24dea6fd6..00000000000
--- a/src/plugins/srv6-mobile/extra/README.md
+++ /dev/null
@@ -1,173 +0,0 @@
-# What's `runner.py` doing?
-
-## Common configurations
-
-### VPP1
-```
-create host-interface name eth1
-set int ip addr host-eth1 A1::1/120
-set int state host-eth1 up
-ip route add ::/0 via host-eth1 A1::2
-```
-
-
-### VPP2
-
-```
-create host-interface name eth1
-set int ip addr host-eth1 A1::2/120
-create host-interface name eth2
-set int ip addr host-eth2 A2::1/120
-set int state host-eth1 up
-set int state host-eth2 up
-ip route add ::/0 via host-eth2 A2::2
-```
-
-
-### VPP3
-
-```
-create host-interface name eth1
-set int ip addr host-eth1 A2::2/120
-create host-interface name eth2
-set int ip addr host-eth2 A3::1/120
-set int state host-eth1 up
-set int state host-eth2 up
-ip route add ::/0 via host-eth1 A2::1
-```
-
-### VPP4
-
-```
-create host-interface name eth1
-set int ip addr host-eth1 A3::2/120
-set int state host-eth1 up
-ip route add ::/0 via host-eth1 A3::1
-```
-
-
-## Drop-in for GTP-U over IPv4
-
-What's happened when you run `test tmap`:
-
-    $ ./runner.py test tmap
-
-
-Setting up a virtual interface of packet generator:
-
-#### VPP1
-
-```
-create packet-generator interface pg0
-set int mac address pg0 aa:bb:cc:dd:ee:01
-set int ip addr pg0 172.16.0.1/30
-set ip arp pg0 172.16.0.2/30 aa:bb:cc:dd:ee:02
-```
-
-#### VPP4
-
-```
-create packet-generator interface pg0
-set int mac address pg0 aa:bb:cc:dd:ee:11
-set int ip addr pg0 1.0.0.2/30
-set ip arp pg0 1.0.0.1 aa:bb:cc:dd:ee:22
-```
-
-SRv6 and IP routing settings:
-
-#### VPP1
-
-```
-sr policy add bsid D1:: next D2:: next D3:: gtp4_removal sr_prefix D4::/32 v6src_prefix C1::/64
-sr steer l3 172.20.0.1/32 via bsid D1::
-
-```
-
-#### VPP2
-
-```
-sr localsid address D2:: behavior end
-ip route add D3::/128 via host-eth2 A2::2
-```
-
-#### VPP3
-
-```
-sr localsid address D3:: behavior end
-ip route add D4::/32 via host-eth2 A3::2
-```
-
-#### VPP4
-
-```
-sr localsid prefix D4::/32 behavior end.m.gtp4.e v4src_position 64
-ip route add 172.20.0.1/32 via pg0 1.0.0.1
-```
-
-
-
-
-## Packet generator and testing
-
-    Example how to build custom SRv6 packet in scapy and ipaddress pkgs
-
-    s = '\x11' * 4 + IPv4Address(u"192.168.192.10").packed + '\x11' * 8
-    ip6 = IPv6Address(s)
-    IPv6(dst=ip6, src=ip6)
-
-
-## end.m.gtp4.e
-
-    First set behavior so our localsid node is called with the packet
-    matching C1::1 in fib table
-    sr localsid address C1::1 behavior end.m.gtp4.ess
-
-    show sr localsids behaviors
-    show sr localsid
-
-    We should send a well formated packet to C::1 destination address
-    that contains the correct spec as for end.m.gtp4.e with encapsulated
-    ipv4 src and dst address and teid with port for the conversion to
-    GTPU IPv4 packet
-
-
-## additional commands
-
-    gdb - breakpoint
-
-    break sr_policy_rewrite.c:1620
-
-    break src/plugins/srv6-end/node.c:84
-
-    TMAP
-    Linux:
-
-    ip link add tmp1 type veth peer name tmp2
-    ip link set dev tmp1 up
-    ip link set dev tmp2 up
-    ip addr add 172.20.0.2/24 dev tmp2
-
-    create host-interface name tmp1
-    set int mac address host-tmp1 02:fe:98:c6:c8:7b
-    set interface ip address host-tmp1 172.20.0.1/24
-    set interface state host-tmp1 up
-
-    VPP
-    set sr encaps source addr C1::
-    sr policy add bsid D1::999:2 next D2:: next D3:: gtp4_removal sr-prefix fc34:5678::/64 local-prefix C1::/64
-    sr steer l3 172.21.0.0/24 via bsid d1::999:2
-
-    END
-    Linux
-    create host-interface name tmp1
-    set int mac address host-tmp1 02:fe:98:c6:c8:7b
-    set interface ip address host-tmp1 A1::1/64
-    set interface state host-tmp1 up
-
-    VPP
-    sr localsid address 1111:1111:c0a8:c00a:1122:1111:1111:1111 behavior end.m.gtp4.e
-
-    trace add af-packet-input 10
-
-    sr localsid address C3:: behavior end.m.gtp4.e
-    sr localsid address 2001:200:0:1ce1:3000:757f:0:2 behavior end.m.gtp4.e
diff --git a/src/plugins/srv6-mobile/extra/runner_doc.md b/src/plugins/srv6-mobile/extra/runner_doc.md
new file mode 100644
index 00000000000..64f06d77299
--- /dev/null
+++ b/src/plugins/srv6-mobile/extra/runner_doc.md
@@ -0,0 +1,105 @@
+# What's `runner.py` doing? {#srv6_mobile_runner_doc}
+
+## Common configurations
+
+### VPP1
+```
+create host-interface name eth1
+set int ip addr host-eth1 A1::1/120
+set int state host-eth1 up
+ip route add ::/0 via host-eth1 A1::2
+```
+
+
+### VPP2
+
+```
+create host-interface name eth1
+set int ip addr host-eth1 A1::2/120
+create host-interface name eth2
+set int ip addr host-eth2 A2::1/120
+set int state host-eth1 up
+set int state host-eth2 up
+ip route add ::/0 via host-eth2 A2::2
+```
+
+
+### VPP3
+
+```
+create host-interface name eth1
+set int ip addr host-eth1 A2::2/120
+create host-interface name eth2
+set int ip addr host-eth2 A3::1/120
+set int state host-eth1 up
+set int state host-eth2 up
+ip route add ::/0 via host-eth1 A2::1
+```
+
+### VPP4
+
+```
+create host-interface name eth1
+set int ip addr host-eth1 A3::2/120
+set int state host-eth1 up
+ip route add ::/0 via host-eth1 A3::1
+```
+
+
+## Drop-in for GTP-U over IPv4
+
+Drop-in mode is handy to test both GTP-U-to-SRv6 and SRv6-to-GTP-U functions at same time. Let's see what's happened when you run `test gtp4`:
+
+    $ ./runner.py test gtp4
+
+
+Setting up a virtual interface of packet generator:
+
+#### VPP1
+
+```
+create packet-generator interface pg0
+set int mac address pg0 aa:bb:cc:dd:ee:01
+set int ip addr pg0 172.16.0.1/30
+set ip arp pg0 172.16.0.2/30 aa:bb:cc:dd:ee:02
+```
+
+#### VPP4
+
+```
+create packet-generator interface pg0
+set int mac address pg0 aa:bb:cc:dd:ee:11
+set int ip addr pg0 1.0.0.2/30
+set ip arp pg0 1.0.0.1 aa:bb:cc:dd:ee:22
+```
+
+SRv6 and IP routing settings:
+
+#### VPP1
+
+```
+sr policy add bsid D4:: next D2:: next D3::
+sr policy add bsid D5:: behavior t.m.gtp4.d D4::/32 v6src_prefix C1::/64 nhtype ipv4
+sr steer l3 172.20.0.1/32 via bsid D5::
+```
+
+#### VPP2
+
+```
+sr localsid address D2:: behavior end
+ip route add D3::/128 via host-eth2 A2::2
+```
+
+#### VPP3
+
+```
+sr localsid address D3:: behavior end
+ip route add D4::/32 via host-eth2 A3::2
+```
+
+#### VPP4
+
+```
+sr localsid prefix D4::/32 behavior end.m.gtp4.e v4src_position 64
+ip route add 172.20.0.1/32 via pg0 1.0.0.1
+```
diff --git a/src/plugins/srv6-mobile/extra/topo-init.png b/src/plugins/srv6-mobile/extra/topo-init.png
deleted file mode 100644
index e69de29bb2d..00000000000
--- a/src/plugins/srv6-mobile/extra/topo-init.png
+++ /dev/null
diff --git a/src/plugins/srv6-mobile/extra/topo-test_gtp4d.png b/src/plugins/srv6-mobile/extra/topo-test_gtp4d.png
deleted file mode 100644
index e69de29bb2d..00000000000
--- a/src/plugins/srv6-mobile/extra/topo-test_gtp4d.png
+++ /dev/null
diff --git a/src/plugins/srv6-mobile/extra/topo-test_gtp6.png b/src/plugins/srv6-mobile/extra/topo-test_gtp6.png
deleted file mode 100644
index e69de29bb2d..00000000000
--- a/src/plugins/srv6-mobile/extra/topo-test_gtp6.png
+++ /dev/null
diff --git a/src/plugins/srv6-mobile/extra/topo-test_gtp6d.png b/src/plugins/srv6-mobile/extra/topo-test_gtp6d.png
deleted file mode 100644
index e69de29bb2d..00000000000
--- a/src/plugins/srv6-mobile/extra/topo-test_gtp6d.png
+++ /dev/null
diff --git a/src/plugins/srv6-mobile/extra/topo-test_gtp6ip6.png b/src/plugins/srv6-mobile/extra/topo-test_gtp6ip6.png
deleted file mode 100644
index e69de29bb2d..00000000000
--- a/src/plugins/srv6-mobile/extra/topo-test_gtp6ip6.png
+++ /dev/null
diff --git a/src/plugins/srv6-mobile/mobile_plugin_doc.md b/src/plugins/srv6-mobile/mobile_plugin_doc.md
new file mode 100644
index 00000000000..df8af19280b
--- /dev/null
+++ b/src/plugins/srv6-mobile/mobile_plugin_doc.md
@@ -0,0 +1,142 @@
+SRv6 Mobile User Plane Plugins {#srv6_mobile_plugin_doc}
+========================
+
+# Introduction
+
+This plugin module can provide the stateless mobile user plane protocols translation between GTP-U and SRv6. The functions of the translation take advantage of SRv6 network programmability.
+
+[SRv6 Mobile User Plane](https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane) defines the user plane protocol using SRv6
+including following stateless translation functions:
+
+- **T.M.GTP4.D:**  
+   GTP-U over UDP/IPv4 -> SRv6
+- **End.M.GTP4.E:**  
+   SRv6 -> GTP-U over UDP/IPv4
+- **End.M.GTP6.D:**   
+   GTP-U over UDP/IPv6 -> SRv6
+- **End.M.GTP6.E:**  
+   SRv6 -> GTP-U over UDP/IPv6
+
+These functions benefit user plane(overlay) to be able to utilize data plane(underlay) networks properly. And also it benefits data plane to be able to handle user plane in routing paradigm.
+
+Noted that the prefix of function names follow naming convention of SRv6 network programming. "T" means transit function, "End" means end function, "M" means Mobility specific function. The suffix "D" and "E" mean that "decapsulation" and "encapsulation" respectively.
+
+
+# Implementation
+
+All SRv6 mobile functions are implemented as VPP plugin modules. The plugin modules leverage the sr_policy and sr_localsid mechanisms.
+
+# Configurations
+
+## GTP-U to SRv6
+
+The GTP-U tunnel and flow identifiers of a receiving packet are mapped to a Segment Identifier(SID) of sending SRv6 packets.
+
+### IPv4 infrastructure case
+
+In case that **IPv4** networks are the infrastructure of GTP-U, T.M.GTP4.D function translates the receiving GTP-U packets to SRv6 packets.
+
+A T.M.GTP4.D function is associated with the following mandatory parameters:
+
+- SID: A SRv6 SID to represents the function
+- DST-PREFIX: Prefix of remote SRv6 segment. The destination address or last SID of out packets consists of the prefix followed by dst IPv4 address, QFI and TEID of the receiving packets.
+- SRC-PREFIX: Prefix for src address of sending packets. The src IPv6 address consists of the prefix followed by the src IPv4 address of the receiving packets.
+
+The following command instantiates a new T.M.GTP4.D function.
+
+```
+sr policy add bsid SID behavior t.m.gtp4.d DST-PREFIX v6src_prefix SRC-PREFIX [nhtype {ipv4|ipv6|non-ip}]
+```
+
+For example, the below command configures the SID 2001:db8::1 with `t.m.gtp4.d` behavior for translating receiving GTP-U over IPv4 packets to SRv6 packets with next-header type is IPv4.
+
+```
+sr policy add bsid 2001:db8::1 behavior t.m.gtp4.d D1::/32 v6src_prefix A1::/64 nhtype ipv4
+```
+
+It should be interesting how a SRv6 BSID works to decapsulate the receiving GTP-U packets over IPv4 header. To utilize ```t.m.gtp4.d``` function, you need to configure some SR steering policy like:
+
+```
+sr steer l3 172.20.0.1/32 via bsid 2001:db8::1
+```
+
+The above steering policy with the BSID of `t.m.gtp4.d` would work properly for the GTP-U packets destined to 172.20.0.1.
+
+If you have a SID(s) list of SR policy which the configured gtp4.d function to be applied, the SR Policy can be configured as following:
+
+```
+sr policy add bsid D1:: next A1:: next B1:: next C1::
+```
+
+### IPv6 infrastructure case
+
+In case that GTP-U is deployed over **IPv6** infrastructure, you don't need to configure T.M.GTP4.D function and associated SR steering policy.  Instead of that, you just need to configure a localsid of End.M.GTP6.D segment.
+
+An End.M.GTP6.D segment is associated with the following mandatory parameters:
+
+- SID-PREFIX: SRv6 SID prefix to represent the function. In this function, it should be the dst address of receiving GTP-U packets.
+- DST-PREFIX: Prefix of remote SRv6 Segment. The destination address or last SID of output packets consists of the prefix followed by QFI and TEID of the receiving packets.
+
+The following command instantiates a new End.M.GTP6.D function.
+
+```
+sr localsid prefix SID-PREFIX behavior end.m.gtp6.d DST-PREFIX [nhtype {ipv4|ipv6|non-ip}]
+```
+For example, the below command configures the SID prefix 2001:db8::/64 with `end.m.gtp6.d` behavior for translating receiving GTP-U over IPv6 packets which have IPv6 destination addresses within 2001:db8::/64 to SRv6 packets. The dst IPv6 address of the outgoing packets consists of D4::/64 followed by QFI and TEID.
+
+```
+sr localsid prefix 2001:db8::/64 behavior end.m.gtp6.d D4::/64
+```
+
+In another case, the translated packets from GTP-U over IPv6 to SRv6 will be re-translated back to GTP-U, which is so called 'Drop-In' mode.
+
+In Drop-In mode, an additional IPv6 specific end segment is required, named End.M.GTP6.D.Di. It is because that unlike `end.m.gtp6.d`, it needs to preserve original IPv6 dst address as the last SID in the SRH.
+
+Regardless of that difference exists, the required configuration parameters are same as `end.m.gtp6.d`.
+
+The following command instantiates a new End.M.GTP6.D.Di function.
+
+```
+sr localsid prefix 2001:db8::/64 behavior end.m.gtp6.d.di D4::/64
+```
+
+
+## SRv6 to GTP-U
+
+The SRv6 Mobile functions on SRv6 to GTP-U direction are End.M.GTP4.E and End.M.GTP6.D.
+
+In this direction with GTP-U over IPv4 infrastructure, an End.M.GTP4.E segment is associated with the following mandatory parameters:
+
+- SID-PREFIX: SRv6 SID prefix to represent the function.
+- V4SRC-ADDR-POSITION: Integer number indicates bit position where IPv4 src address embedded.
+
+The following command instantiates a new End.M.GTP4.E function.
+
+```
+sr localsid prefix SID-PREFIX behavior end.m.gtp4.e v4src_position V4SRC-ADDR-POSITION
+```
+
+For example, the below command configures the SID prefix 2001:db8::/32 with `end.m.gtp4.e` behavior for translating the receiving SRv6 packets to GTP-U packets encapsulated with UDP/IPv4 header. All the GTP-U tunnel and flow identifiers are extracted from the active SID in the receiving packets. The src IPv4 address of sending GTP-U packets is extracted from the configured bit position in the src IPv6 address.
+
+```
+sr localsid prefix 2001:db8::/32 behavior end.m.gtp4.e v4src_position 64
+```
+
+In IPv6 infrastructure case, an End.M.GTP6.E segment is associated with the following mandatory parameters:
+
+- SID-PREFIX: SRv6 SID prefix to represent the function.
+
+The following command instantiates a new End.M.GTP6.E function.
+
+```
+sr localsid prefix SID-PREFIX behavior end.m.gtp6.e
+```
+
+For example, the below command configures the SID prefix 2001:db8::/64 with `end.m.gtp6.e` behavior for translating the receiving SRv6 packets to GTP-U packets encapsulated with UDP/IPv6 header. While the last SID indicates GTP-U dst IPv6 address, 32-bits GTP-U TEID and 6-bits QFI are extracted from the active SID in the receiving packets.
+
+```
+sr localsid prefix 2001:db8::/64 behavior end.m.gtp6.e
+```
+
+To run some demo setup please refer to: @subpage srv6_mobile_runner_doc
+
diff --git a/src/vnet/srv6/sr_doc.md b/src/vnet/srv6/sr_doc.md
index cf9c72911eb..c80a0fc18f7 100644
--- a/src/vnet/srv6/sr_doc.md
+++ b/src/vnet/srv6/sr_doc.md
@@ -59,4 +59,5 @@ Available SRv6 plugins include:
 - @subpage srv6_as_plugin_doc
 - @subpage srv6_ad_plugin_doc
 - @subpage srv6_am_plugin_doc
+- @subpage srv6_mobile_plugin_doc