Transport-Independent Path Layer State Management
draft-trammell-plus-statefulness-03
|
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2017-03-28
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
xml
pdf
html
bibtex
|
| Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group M. Kuehlewind
Internet-Draft B. Trammell
Intended status: Informational ETH Zurich
Expires: September 29, 2017 J. Hildebrand
March 28, 2017
Transport-Independent Path Layer State Management
draft-trammell-plus-statefulness-03
Abstract
This document describes a simple state machine for stateful network
devices on a path between two endpoints to associate state with
traffic traversing them on a per-flow basis, as well as abstract
signaling mechanisms for driving the state machine. This state
machine is intended to replace the de-facto use of the TCP state
machine or incomplete forms thereof by stateful network devices in a
transport-independent way, while still allowing for fast state
timeout of non-established or undesirable flows.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 29, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Kuehlewind, et al. Expires September 29, 2017 [Page 1]
Internet-Draft PLUS Statefulness March 2017
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Uniflow States . . . . . . . . . . . . . . . . . . . . . 7
3.2. Biflow States . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Additional States and Actions . . . . . . . . . . . . . . 8
4. Abstract Signaling Mechanisms . . . . . . . . . . . . . . . . 8
4.1. Flow Identification . . . . . . . . . . . . . . . . . . . 9
4.2. Association and Confirmation Signaling . . . . . . . . . 9
4.2.1. Start-of-flow versus continual signaling . . . . . . 10
4.3. Bidirectional Stop Signaling . . . . . . . . . . . . . . 11
4.3.1. Authenticated Stop Signaling . . . . . . . . . . . . 12
4.4. Separate Utility . . . . . . . . . . . . . . . . . . . . 12
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 12
5.1. Middlebox Deployment . . . . . . . . . . . . . . . . . . 12
5.2. Endpoint Deployment . . . . . . . . . . . . . . . . . . . 13
6. Signal mappings for transport protocols . . . . . . . . . . . 13
6.1. Signal mapping for TCP . . . . . . . . . . . . . . . . . 13
6.2. Signal mapping for QUIC . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The boundary between the network and transport layers was originally
defined to be that between information used (and potentially
modified) hop-by-hop, and that used end-to-end. End-to-end
information in the transport layer is associated with state at the
endpoints, but processing of network-layer information was assumed to
Show full document text