# ip-mptcp

## 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.
    


* * *