dwww Home | Manual pages | Find package

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 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 im-
              portant 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 be-
              havior.

       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 end-
              points  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 connec-
              tion 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  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  endpoints,
              additional subflows started by the peer.

       ADD_ADDR_ACCEPTED_NR
              specifies the maximum number of incoming ADD_ADDR sub-options ac-
              cepted  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 ad-
              dress 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)

Generated by dwww version 1.16 on Tue Dec 16 04:41:01 CET 2025.