YANG Model for Transmission Control
Protocol (TCP) ConfigurationHochschule Esslingen -
University of Applied SciencesFlandernstr. 10173732EsslingenGermanymichael.scharf@hs-esslingen.deCisco Systems
Incvmurgai@cisco.comVMwaremjethanandani@gmail.com
Transport
TCPMYANGThis document specifies a YANG model for TCP on devices that are
configured by network management protocols. The YANG model defines
groupings for fundamental parameters that can be modified in many TCP
implementations. The model includes definitions from YANG Groupings for
TCP Client and TCP Servers (I-D.ietf-netconf-tcp-client-server). The
model is NMDA (RFC 8342) compliant.The Transmission Control Protocol (TCP) is
used by many applications in the Internet, including control and
management protocols. Therefore, TCP is implemented on network elements
that can be configured via network management protocols such as NETCONF or RESTCONF. This document specifies a YANG 1.1 model for configuring TCP on network
elements that support YANG data models, and is Network Management Datastore Architecture (NMDA)
compliant. This document includes definitions from YANG Groupings for TCP
Clients and TCP Servers. The model focuses on fundamental and
standard TCP functions that are widely implemented. The model can be
augmented to address more advanced or implementation-specific TCP
features.Many protocol stacks on internet hosts use other methods to configure
TCP, such as operating system configuration or policies. Many TCP/IP
stacks cannot be configured by network management protocols such as
NETCONF or RESTCONF and they do not use YANG data models.
Yet, such TCP implementations often also have means to configure the
parameters listed in this document. All parameters defined in this
document are optional.This specification is orthogonal to Management
Information Base (MIB) for the Transmission Control Protocol
(TCP). The TCP Extended Statistics MIB
is also available, and there are MIBs for UDP Management Information Base for the User Datagram
Protocol (UDP) and Stream Control
Transmission Protocol (SCTP) Management Information Base (MIB).
It is possible to translate a MIB into a YANG model, for instance
using Translation of Structure of Management
Information Version 2 (SMIv2) MIB Modules to YANG Modules. However,
this approach is not used in this document, as such a translated model
would not be up-to-date.There are also other related YANG models. Examples are:Application protocol models may include TCP parameters, for
example in case of BGP YANG
Model for Service Provider Networks .TCP header attributes are modeled in other models, such as YANG Data Model for Network Access Control Lists
(ACLs) and Distributed Denial-of-Service
Open Thread Signaling (DOTS) Data Channel Specification.TCP-related configuration of a NAT (e.g., NAT44, NAT64,
Destination NAT, ...) is defined in A YANG
Module for Network Address Translation (NAT) and Network Prefix
Translation (NPT) and A YANG Data
Model for Dual-Stack Lite (DS-Lite) .The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only when,
they appear in all capitals, as shown here.TCP is implemented on many different system architectures. As a
result, there are may different and often implementation-specific ways
to configure parameters of the TCP protocol engine. In addition, in
many TCP/IP stacks configuration exists for different scopes:Global configuration: Many TCP implementations have
configuration parameters that affect all TCP connections. Typical
examples include enabling or disabling optional protocol
features.Interface configuration: It can be useful to use different TCP
parameters on different interfaces, e.g., different device ports
or IP interfaces. In that case, TCP parameters can be part of the
interface configuration. Typical examples are the Maximum Segment
Size (MSS) or configuration related to hardware offloading.Connection parameters: Many implementations have means to
influence the behavior of each TCP connection, e.g., on the
programming interface used by applications. A typical example are
socket options in the socket API, such as disabling the Nagle
algorithm by TCP_NODELAY. If an application uses such an
interface, it is possible that the configuration of the
application or application protocol includes TCP-related
parameters. An example is the BGP YANG Model for Service
Provider Networks .Policies: Setting of TCP parameters can also be part of system
policies, templates, or profiles. An example would be the
preferences defined in the TAPS interface An Abstract Application Layer
Interface to Transport Services.There is no ground truth for setting certain TCP parameters, and
traditionally different implementation have used different modeling
approaches. For instance, one implementation may define a given
configuration parameter globally, while another one uses per-interface
settings, and both approaches work well for the corresponding use
cases. Also, different systems may use different default values.The YANG model defined in this document includes definitions from
the YANG Groupings
for TCP Clients and TCP Servers. Similar to the base model,
this specification defines YANG groupings. This allows reuse of
these groupings in different YANG data models. It is intended that
these groupings will be used either standalone or for TCP-based
protocols as part of a stack of protocol-specific configuration
models.In addition to configuration of the TCP protocol engine, a TCP
implementation typically also offers access to operational state and
statistics. This includes amongst others:Statistics: Counters for the number of active/passive opens,
sent and received segments, errors, and possibly other detailed
debugging informationTCP connection table: Access to status information for all TCP
connectionsTCP listener table: Tnformation about all TCP listening
endpointsSimilar to the TCP MIB, this document
also specifies a TCP connection table.TODO: A future version of this document may include statistics equivalent
to the TCP MIB:active-openspassive-opensattempt-failsestablish-resetscurrently-establishedin-segmentsout-segmentsretransmitted-segmentsin-errorsout-resetsThere are a number of basic system parameters that are configurable
on many TCP implementations, even if not all TCP implementations may
indeed have exactly all these settings. Also, the syntax, semantics
and scope (e.g., global or interface-specific) can be different in
different system architectures.The following list of fundamental parameters considers both TCP
implementations on hosts and on routers:Keepalives (see also ) Idle-time (in seconds): integerProbe-interval (in seconds): integerMax-probes: integerMaximum MSS (in byte): integerFIN timeout (in seconds): integerSACK (disable/enable): booleanTimestamps (disable/enable): booleanPath MTU Discovery (disable/enable): booleanECN Enabling (disable/passive/active): enumerationTCP-AO is increasingly supported on routers and also requires
configuration.Some other parameters are also common but not ubiquitously
supported, or modeled in very different ways:Delayed ACK timeout (in ms)Initial RTO value (in ms)Maximum number of retransmissionsWindow scalingMaximum number of connectionsTCP can be implemented in different ways and design choices by the
protocol engine often affect configuration options. In a number of
areas there are major differences between different software
architectures. As a result, there are not many commonalities in the
corresponding configuration parameters:Window size: TCP stacks can either store window state variables
(such as the congestion window) in segments or in bytes.Buffer sizes: The memory management depends on the operating
system. As the size of buffers can vary over several orders of
magnitude, very different implementations exist. This typically
influences TCP flow control.Timers: Timer implementation is another area in which TCP
stacks may differ.Congestion control algorithms: Many congestion control
algorithms have configuration parameters, but except for
fundamental properties they often tie into the specific
implementation.This document only models fundamental system parameters that are
configurable on many TCP implementations, and for which the
configuration is reasonably similar.[[Editor's node: This section requires further work.]]This document extends the YANG model "ietf-tcp-common" defined in
. The intention
is to define YANG groupings for TCP parameters so that they can be used
in different YANG models.As an example for the configuration of SACK, a YANG model could
import the YANG model "ietf-tcp-common" as well as the model defined
in this document as follows:This section provides a abridged tree diagram for the YANG module
defined in this document. Annotations used in the diagram are defined
in YANG Tree Diagrams .[[Editor's note: This section is TBD.]]Editor's note: How to use ietf-tcp-common as basis? For instance, is
the tcp-system-grouping therein needed?This document registers two URIs in the "ns" subregistry of the
IETF XML Registry . Following the format
in IETF XML Registry , the following
registrations are requested:This document registers a YANG modules in the YANG Module Names
registry YANG - A Data Modeling Language
. Following the format in YANG - A Data
Modeling Language , the following registrations are
requested:The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such as
NETCONF or RESTCONF .
The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS .The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular
NETCONF or RESTCONF users to a preconfigured subset of all available
NETCONF or RESTCONF protocol operations and content.Michael Scharf was supported by the StandICT.eu project, which is
funded by the European Commission under the Horizon 2020 Programme.The following persons have contributed to this document by reviews:
Mohamed BoucadairChanges compared to draft-scharf-tcpm-yang-tcp-02Initial proposal of a YANG model including base configuration
parameters, TCP-AO configuration, and a connection listEditorial bugfixes and outdated references reported by Mohamed
BoucadairAdditional co-author Mahesh JethanandaniChanges compared to draft-scharf-tcpm-yang-tcp-01Alignment with Removing backward-compatibility to the TCP MIBAdditional co-author Vishal MurgaiChanges compared to draft-scharf-tcpm-yang-tcp-00Editorial improvements