All of lore.kernel.org
 help / color / mirror / Atom feed
From: Othman, Ossama <ossama.othman at intel.com>
To: mptcp at lists.01.org
Subject: [MPTCP] [RFC] MPTCP Path Management Generic Netlink API
Date: Thu, 08 Mar 2018 12:48:40 -0800	[thread overview]
Message-ID: <CAPyD+=CnxCpvN+h7zeUx-LRcn-jFfziEqpW8KuJjBcDy59m+ow@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 5276 bytes --]

Hi,

Following up on on a brief exchange between Matthieu and Mat regarding
a MPTCP path manager netlink API, I'd like to share to our own
proposed generic netlink API developed in parallel.

Please find the high level description below.  It'll be great to
compare the two netlink based APIs to determine if either can be
improved by leveraging different aspects from each one.

Thanks!

--
Ossama Othman
Intel OTC

==============================================
RFC: MPTCP Path Management Generic Netlink API
==============================================

A generic netlink socket is used to facilitate communication between
the kernel and a user space daemon that handles MPTCP path management
related operations, from here on in called the path manager.  Several
multicast groups, attributes and operations are exposed by the "mptcp"
generic netlink family, e.g.:

$ genl ctrl list
...
Name: mptcp
       ID: 0x1d  Version: 0x1  header size: 0  max attribs: 7
       commands supported:
               #1:  ID-0x0
               #2:  ID-0x1
               #3:  ID-0x2
               #4:  ID-0x3
               #5:  ID-0x4


       multicast groups:
               #1:  ID-0xa  name: new_connection
               #2:  ID-0xb  name: new_addr
               #3:  ID-0xc  name: join_attempt
               #4:  ID-0xd  name: new_subflow
               #5:  ID-0xe  name: subflow_closed
               #6:  ID-0xf  name: conn_closed

Each of the multicast groups corresponds to MPTCP path manager events
supported by the kernel MPTCP stack.

Kernel Initiated Events
-----------------------
* new_connection
   * Called upon completion of new MPTCP-capable connection.
     Information for initial subflow is made available to the path
     manager.
   * Payload
      * Connection ID (globally unique for host)
      * Local address
      * Local port
      * Remote address
      * Remote port
      * Priority
* new_addr
   * Triggered when the host receives an ADD_ADDR MPTCP option, i.e. a
     new address is advertised by the remote side.
   * Payload
      * Connection ID
      * Remote address ID
      * Remote address
      * Remote port
* join_attempt
   * Called when a MP_JOIN has been ACKed.  The path manager is
     expected to respond with an allow_join event containing its
     decision based on the configured policy.
   * Payload
      * Connection ID
      * Local address ID
      * Local address
      * Local port
      * Remote address ID
      * Remote address
      * Remote port
* new_subflow
   * Called when final MP_JOIN ACK has been ACKed.
   * Payload
      * Connection ID
      * Subflow ID
* subflow_closed
   * Called when a subflow has been closed.  Allows path manager to
     clean up subflow related resources.
   * Payload
      * Connection ID
      * Subflow ID
* conn_closed
   * Call when an MPTCP connection as a whole, as opposed to a single
     subflow, has been closed.  This is the case when close(2) has
     been called on an MPTCP connection.
   * Payload
      * Connection ID

Path Manager Initiated Events (Commands)
----------------------------------------
* send_addr
   * Notify the kernel of the availability of new address for use in
     MPTCP connections.  Triggers an ADD_ADDR to be sent to the peer.
   * Payload
      * Connection ID
      * Address ID
      * Local address
      * Local port (optional, use same port as initial subflow if not
        specified)
* add_subflow
   * Add new subflow to the MPTCP connection.  This triggers an
     MP_JOIN to be sent to the peer.
   * Payload
      * Connection ID
      * Local address ID
      * Local address (optional, required if send_addr not previously
        sent to establish the local address ID)
      * Local port (optional, use same port as initial subflow if not
        specified)
      * Remote address ID (e.g. from a previously received new_addr or
        join_attempt event)
      * Backup priority flag (optional, use default priority if not
        specified)
      * Subflow ID
* allow_join
   * Allow MP_JOIN attempt from peer.
   * Payload
      * Connection ID
      * Remote address ID (e.g from a previously received join_attempt
        event).
      * Local address
      * Local port
      * Allow indication (optional, do not allow join if not
        specified)
      * Backup priority flag (optional, use default priority if not
        specified)
      * Subflow ID
* set_backup
   * Set subflow priority to backup priority.
   * Payload
      * Connection ID
      * Subflow ID
      * Backup priority flag (optional, use default priority if not
        specified)
* remove_subflow
   * Triggers a REMOVE_ADDR MPTCP option to be sent, ultimately
     resulting in subflows routed through that invalidated address to
     be closed.
   * Payload
      * Connection ID
      * Subflow ID

Security
--------
For security reasons, path management operations may only be performed
by privileged processes due to the GENL_ADMIN_PERM generic netlink
flag being set.  In particular, access to the MPTCP generic netlink
interface will require CAP_NET_ADMIN privileges.

             reply	other threads:[~2018-03-08 20:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08 20:48 Othman, Ossama [this message]
2018-03-08 23:46 [MPTCP] [RFC] MPTCP Path Management Generic Netlink API Stephen Brennan
2018-03-12  3:25 Christoph Paasch
2018-03-12  3:27 Christoph Paasch
2018-03-12 17:27 Othman, Ossama
2018-03-12 20:55 Stephen Brennan
2018-03-12 21:10 Stephen Brennan
2018-03-13 18:24 Christoph Paasch
2018-03-13 18:26 'Christoph Paasch'

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPyD+=CnxCpvN+h7zeUx-LRcn-jFfziEqpW8KuJjBcDy59m+ow@mail.gmail.com' \
    --to=unknown@example.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.