Path Signals
draft-hardie-path-signals-03
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Ted Hardie | ||
| Last updated | 2018-04-19 (Latest revision 2018-04-02) | ||
| Replaced by | draft-iab-path-signals | ||
| RFC stream | Internet Architecture Board (IAB) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | IAB state | Replaced | |
| Consensus boilerplate | Unknown | ||
| IAB shepherd | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This document discusses the nature of signals seen by on-path elements, contrasting implicit and explicit signals. For example, TCP's state mechanics uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on- path network elements lack those signals. This document recommends that explict signals be used by transports which encrypt their state mechanics. It also recommends that a signal be exposed to the path only when the signal's originator intends that it be used by the network elements on the path.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)