man
8 IP-MPTCP
IP-MPTCP(8) Linux IP-MPTCP(8)
NAME
ip-mptcp - MPTCP path manager configuration
SYNOPSIS
ip [ OPTIONS ] mptcp { endpoint | limits | help }
ip mptcp endpoint add IFADDR [ port PORT ] [ dev IFNAME ] [ id ID ] [
FLAG-LIST ]
ip mptcp endpoint delete id ID [ IFADDR ]
ip mptcp endpoint change [ id ID ] [ IFADDR ] [ port PORT ] CHANGE-OPT
ip mptcp endpoint show [ id ID ]
ip mptcp endpoint flush
FLAG-LIST := [ FLAG-LIST ] FLAG
FLAG := [ signal | subflow | backup | fullmesh ]
CHANGE-OPT := [ backup | nobackup | fullmesh | nofullmesh ]
ip mptcp limits set [ subflow SUBFLOW_NR ] [ add_addr_accepted
ADD_ADDR_ACCEPTED_NR ]
ip mptcp limits show
ip mptcp monitor
DESCRIPTION
MPTCP is a transport protocol built on top of TCP that allows TCP con-
nections to use multiple paths to maximize resource usage and increase
redundancy. The ip-mptcp sub-commands allow configuring several aspects
of the MPTCP path manager, which is in charge of subflows creation:
The endpoint object specifies the IP addresses that will be used and/or
announced for additional subflows:
ip mptcp endpoint add add new MPTCP endpoint
ip mptcp endpoint delete delete existing MPTCP endpoint
ip mptcp endpoint show get existing MPTCP endpoint
ip mptcp endpoint flush flush all existing MPTCP endpoints
IFADDR An IPv4 or IPv6 address. When used with the delete id operation,
an IFADDR is only included when the ID is 0.
PORT When a port number is specified, incoming MPTCP subflows for al-
ready established MPTCP sockets will be accepted on the speci-
fied port, regardless the original listener port accepting the
first MPTCP subflow and/or this peer being actually on the
client side. This option has to be used in combination with the
signal flag.
IFNAME is the network interface name attached to the endpoint. It is
important to specify this device name linked to the address to
make sure the system knows how to route packets from the speci-
fied IP address to the correct network interface. Without this,
it might be required to add IP rules and routes to have the ex-
pected behavior.
ID is a unique numeric identifier, between 0 and 255, for the given
endpoint. It is not possible to add endpoints with ID 0, because
this special ID is reserved for the initial subflow. For rules
linked to the initial subflow, the path-manager will look at
endpoints matching the same address, and port if set, ignoring
the ID.
signal The endpoint will be announced/signaled to each peer via an
MPTCP ADD_ADDR sub-option. Typically, a server would be respon-
sible for this. Upon reception of an ADD_ADDR sub-option, the
other peer, typically the client side, can try to create addi-
tional subflows, see ADD_ADDR_ACCEPTED_NR.
subflow
If additional subflow creation is allowed by the MPTCP limits,
the MPTCP path manager will try to create an additional subflow
using this endpoint as the source address after the MPTCP con-
nection is established. A client would typically do this.
backup If this is a subflow endpoint, the subflows created using this
endpoint will have the backup flag set during the connection
process. This flag instructs the remote peer to only send data
on a given subflow when all non-backup subflows are unavailable.
When using the default packet scheduler with a 'backup' end-
point, outgoing data from the local peer is also affected: pack-
ets will only be sent from this endpoint when all non-backup
subflows are unavailable.
fullmesh
If this is a subflow endpoint and additional subflow creation is
allowed by the MPTCP limits, the MPTCP path manager will try to
create an additional subflow for each known peer address, using
this endpoint as the source address. This will occur after the
MPTCP connection is established. If the peer did not announce
any additional addresses using the MPTCP ADD_ADDR sub-option,
this will behave the same as a plain subflow endpoint. When the
peer does announce addresses, each received ADD_ADDR sub-option
will trigger creation of an additional subflow to generate a
full mesh topology. This fullmesh flag should always be used in
combination with the subflow one to be useful, except for the
address used by the initial subflow, where subflow is then op-
tional.
implicit
In some scenarios, an MPTCP subflow can use a local address
mapped by a implicit endpoint created by the in-kernel path man-
ager. Once set, the implicit flag cannot be removed, but other
flags can be added to the endpoint. Implicit endpoints cannot be
created from user-space.
The limits object specifies the constraints for subflow creations:
ip mptcp limits show get current MPTCP subflow creation limits
ip mptcp limits set change the MPTCP subflow creation limits
SUBFLOW_NR
specifies the maximum number of additional subflows allowed for
each MPTCP connection. Additional subflows can be created due
to: incoming accepted ADD_ADDR sub-option, local subflow end-
points, additional subflows started by the peer.
ADD_ADDR_ACCEPTED_NR
specifies the maximum number of incoming ADD_ADDR sub-options
accepted for each MPTCP connection. After receiving the speci-
fied number of ADD_ADDR sub-options, any other incoming one will
be ignored for the MPTCP connection lifetime. When an ADD_ADDR
sub-option is accepted and there are no local fullmesh end-
points, the MPTCP path manager will try to create a new subflow
using the address in the ADD_ADDR sub-option as the destination
address and a source address determined using local routing res-
olution When fullmesh endpoints are available, the MPTCP path
manager will try to create new subflows using each fullmesh end-
point as a source address and the peer's ADD_ADDR address as the
destination. In both cases the SUBFLOW_NR limit is enforced.
monitor displays creation and deletion of MPTCP connections as well as
addition or removal of remote addresses and subflows.
AUTHOR
Original Manpage by Paolo Abeni <pabeni@redhat.com>
iproute2 4 Apr 2020 IP-MPTCP(8)