[tcpm] New version of TCP Option for Transparent Middlebox Discovery available
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[tcpm] New version of TCP Option for Transparent Middlebox Discovery available
A new version of the Transparent Middlebox Discovery option draft is
available at
<http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-02.txt>.
The following changes have been made:
- The security section has been updated.
- An API section has been added.
- Simultaneous open is addressed.
- The "device type" field has been renamed "device capability",
since a single device may respond to several kinds of discovery
requests.
- Miscellaneous cleanup and clarifications.
Several changes were not made:
- Specific uses of the option, such as discovery for management
purposes, are not addressed. This information belongs in
the specs for the individual device capabilities.
- This does need to be a TCP option, since it must follow the
same path as the TCP connection handshake. This is already
addressed in the draft.
- Performance is a requirement for this option. If an extra roundtrip is
required, the option will not be used. This is also already addressed in
the draft.
In addition, we made a couple more changes which I wasn't able to post
before the
pre-meeting deadline. They include:
- Options with length < 4 are addressed. The following text is included:
Options with length less than 4 MUST be ignored.
- The issue of limited option space is addressed. The following text is
included:
There may be situations where other options are required in the SYN
packet which do not leave enough room for all of the target data
necessary for the desired device capability to be advertised. In
these cases, a shorter alternate device capability may be defined
which signals the request to further negotiate the capability after
the handshake completes. This will impact performance by introducing
an extra round-trip during connection set-up, but this may be the
only way to perform the negotiation within the limited TCP option
space available.
Unfortunately, none of the authors will be attending Hiroshima.
Andrew
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.