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
       connections 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
	      already established MPTCP sockets will be accepted on the
	      specified 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
	      specified IP address to the correct network interface.  Without
	      this, it might be required to add IP rules and routes to have
	      the expected 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
	      responsible for this. Upon reception of an ADD_ADDR sub-option,
	      the other peer, typically the client side, can try to create
	      additional 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
	      connection 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'
	      endpoint, outgoing data from the local peer is also affected:
	      packets 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
	      optional.


       implicit
	      In some scenarios, an MPTCP subflow can use a local address
	      mapped by a implicit endpoint created by the in-kernel path
	      manager. 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
	      endpoints, 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
	      specified 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
	      endpoints, 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 resolution When fullmesh endpoints are available, the
	      MPTCP path manager will try to create new subflows using each
	      fullmesh endpoint 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)