--- 1/draft-ietf-taps-arch-10.txt 2021-07-12 02:14:10.578335707 -0700 +++ 2/draft-ietf-taps-arch-11.txt 2021-07-12 02:14:10.638337162 -0700 @@ -1,29 +1,29 @@ TAPS Working Group T. Pauly, Ed. Internet-Draft Apple Inc. Intended status: Standards Track B. Trammell, Ed. -Expires: 1 November 2021 Google Switzerland GmbH +Expires: 13 January 2022 Google Switzerland GmbH A. Brunstrom Karlstad University G. Fairhurst University of Aberdeen C. Perkins University of Glasgow P. Tiesel SAP SE C.A. Wood Cloudflare - 30 April 2021 + 12 July 2021 An Architecture for Transport Services - draft-ietf-taps-arch-10 + draft-ietf-taps-arch-11 Abstract This document describes an architecture for exposing transport protocol features to applications for network communication, the Transport Services architecture. The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven interaction pattern. It uses messages for representing data transfer to applications, and it describes how implementations can use multiple IP addresses, multiple protocols, and multiple paths, and @@ -38,21 +38,21 @@ 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 https://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 1 November 2021. + This Internet-Draft will expire on 13 January 2022. Copyright Notice Copyright (c) 2021 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 (https://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 @@ -62,48 +62,48 @@ provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Specification of Requirements . . . . . . . . . . . . . . 5 2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7 - 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 7 - 2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 8 + 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 8 + 2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 9 3. API and Implementation Requirements . . . . . . . . . . . . . 9 - 3.1. Provide Common APIs for Common Features . . . . . . . . . 9 + 3.1. Provide Common APIs for Common Features . . . . . . . . . 10 3.2. Allow Access to Specialized Features . . . . . . . . . . 10 3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 11 3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 12 - 4. Transport Services Architecture and Concepts . . . . . . . . 12 - 4.1. Transport Services API Concepts . . . . . . . . . . . . . 13 - 4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 15 - 4.1.2. Connections and Related Objects . . . . . . . . . . . 15 - 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 16 - 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 17 - 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 18 - 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 19 - 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 20 - 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 20 - 4.2. Transport Services Implementation Concepts . . . . . . . 21 - 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 22 - 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 22 - 4.2.3. Separating Connection Contexts . . . . . . . . . . . 23 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 - 8.2. Informative References . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 + 4. Transport Services Architecture and Concepts . . . . . . . . 13 + 4.1. Transport Services API Concepts . . . . . . . . . . . . . 14 + 4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 16 + 4.1.2. Connections and Related Objects . . . . . . . . . . . 16 + 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 17 + 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 18 + 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 19 + 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 20 + 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 21 + 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 21 + 4.2. Transport Services Implementation Concepts . . . . . . . 22 + 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 23 + 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 23 + 4.2.3. Separating Connection Contexts . . . . . . . . . . . 24 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 8.2. Informative References . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Many application programming interfaces (APIs) to perform transport networking have been deployed, perhaps the most widely known and imitated being the BSD Socket [POSIX] interface (Socket API). The naming of objects and functions across these APIs is not consistent, and varies depending on the protocol being used. For example, sending and receiving streams of data is conceptually the same for both an unencrypted Transmission Control Protocol (TCP) stream and @@ -182,20 +182,27 @@ Services API. These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without requiring significant changes by application developers. * Section 4 presents the Transport Services architecture diagram and defines the concepts that are used by both the API and implementation documents. The Preconnection allows applications to configure Connection Properties, and the Connection represents an object that can be used to send and receive Messages. + * A Connection is an abstraction that represents the communication. + If the transport services interface selects a protocol such as TCP + for the communication, a Connection will correspond to an + underlying protocol connection. If however a protocol such as UDP + is selected, the Connection remains an abstraction at the end + points. + 1.3. Specification of Requirements 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. API Model @@ -772,21 +780,21 @@ local or remote state to enable the transmission of Messages. For some protocols, this will initiate a client-to-server style handshake; for other protocols, this will just establish local state (e.g., with connectionless protocols such as UDP). The process of identifying options for connecting, such as resolution of the Remote Endpoint, occurs in response to the Initiate call. * Listen: Enables a listener to accept incoming Connections. The Listener will then create Connection objects as incoming connections are accepted (Section 4.1.6). Listeners by default - register with multiple paths, protocols, and local endpoints, + register with multiple paths, protocols, and Local Endpoints, unless constrained by Selection Properties and/or the specified Local Endpoint(s). Connections can be accepted on any of the available paths or endpoints. * Rendezvous: The action of establishing a peer-to-peer connection with a Remote Endpoint. It simultaneously attempts to initiate a connection to a Remote Endpoint while listening for an incoming connection from that endpoint. The process of identifying options for the connection, such as resolution of the Remote Endpoint, occurs in response to the Rendezvous call. As with Listeners, the @@ -1085,103 +1093,103 @@ helped shape the architecture described here. Thanks as well to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear for their implementation and design efforts, including Happy Eyeballs, that heavily influenced this work. 8. References 8.1. Normative References [I-D.ietf-taps-interface] Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., - Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., Pauly, - T., and K. Rose, "An Abstract Application Layer Interface - to Transport Services", Work in Progress, Internet-Draft, - draft-ietf-taps-interface-12, 9 April 2021, - . + Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A., + Pauly, T., and K. Rose, "An Abstract Application Layer + Interface to Transport Services", Work in Progress, + Internet-Draft, draft-ietf-taps-interface-12, 9 April + 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - . + . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . + May 2017, . 8.2. Informative References [I-D.ietf-taps-impl] Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., - Jones, T., Tiesel, P., Perkins, C., and M. Welzl, + Jones, T., Tiesel, P. S., Perkins, C., and M. Welzl, "Implementing Interfaces to Transport Services", Work in - Progress, Internet-Draft, draft-ietf-taps-impl-08, 2 - November 2020, . + Progress, Internet-Draft, draft-ietf-taps-impl-09, 30 + April 2021, . [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open group Technical Standard: Base Specifications, Issue 7", 2008. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, - . + . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, - . + . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, - . + . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, - . + . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, - . + . [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, - . + . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, - . + . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, - . + . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, - . + . [RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey of the Interaction between Security Protocols and Transport Services", RFC 8922, DOI 10.17487/RFC8922, October 2020, - . + . [RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport Services for End Systems", RFC 8923, DOI 10.17487/RFC8923, - October 2020, . + October 2020, . Authors' Addresses Tommy Pauly (editor) Apple Inc. One Apple Park Way Cupertino, California 95014, United States of America Email: tpauly@apple.com