draft-ietf-taps-interface-16.txt | draft-ietf-taps-interface-17.txt | |||
---|---|---|---|---|
TAPS Working Group B. Trammell, Ed. | TAPS Working Group B. Trammell, Ed. | |||
Internet-Draft Google Switzerland GmbH | Internet-Draft Google Switzerland GmbH | |||
Intended status: Standards Track M. Welzl, Ed. | Intended status: Standards Track M. Welzl, Ed. | |||
Expires: 5 March 2023 University of Oslo | Expires: 31 March 2023 University of Oslo | |||
T. Enghardt | T. Enghardt | |||
Netflix | Netflix | |||
G. Fairhurst | G. Fairhurst | |||
University of Aberdeen | University of Aberdeen | |||
M. Kuehlewind | M. Kuehlewind | |||
Ericsson | Ericsson | |||
C. Perkins | C. Perkins | |||
University of Glasgow | University of Glasgow | |||
P. Tiesel | P. Tiesel | |||
SAP SE | SAP SE | |||
T. Pauly | T. Pauly | |||
Apple Inc. | Apple Inc. | |||
1 September 2022 | 27 September 2022 | |||
An Abstract Application Layer Interface to Transport Services | An Abstract Application Layer Interface to Transport Services | |||
draft-ietf-taps-interface-16 | draft-ietf-taps-interface-17 | |||
Abstract | Abstract | |||
This document describes an abstract application programming | This document describes an abstract application programming | |||
interface, API, to the transport layer that enables the selection of | interface, API, to the transport layer that enables the selection of | |||
transport protocols and network paths dynamically at runtime. This | transport protocols and network paths dynamically at runtime. This | |||
API enables faster deployment of new protocols and protocol features | API enables faster deployment of new protocols and protocol features | |||
without requiring changes to the applications. The specified API | without requiring changes to the applications. The specified API | |||
follows the Transport Services architecture by providing | follows the Transport Services architecture by providing | |||
asynchronous, atomic transmission of messages. It is intended to | asynchronous, atomic transmission of messages. It is intended to | |||
skipping to change at page 2, line 10 ¶ | skipping to change at page 2, line 10 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 5 March 2023. | This Internet-Draft will expire on 31 March 2023. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 44 ¶ | skipping to change at page 2, line 44 ¶ | |||
3.1.1. Server Example . . . . . . . . . . . . . . . . . . . 9 | 3.1.1. Server Example . . . . . . . . . . . . . . . . . . . 9 | |||
3.1.2. Client Example . . . . . . . . . . . . . . . . . . . 10 | 3.1.2. Client Example . . . . . . . . . . . . . . . . . . . 10 | |||
3.1.3. Peer Example . . . . . . . . . . . . . . . . . . . . 12 | 3.1.3. Peer Example . . . . . . . . . . . . . . . . . . . . 12 | |||
4. Transport Properties . . . . . . . . . . . . . . . . . . . . 13 | 4. Transport Properties . . . . . . . . . . . . . . . . . . . . 13 | |||
4.1. Transport Property Names . . . . . . . . . . . . . . . . 14 | 4.1. Transport Property Names . . . . . . . . . . . . . . . . 14 | |||
4.2. Transport Property Types . . . . . . . . . . . . . . . . 15 | 4.2. Transport Property Types . . . . . . . . . . . . . . . . 15 | |||
5. Scope of the API Definition . . . . . . . . . . . . . . . . . 15 | 5. Scope of the API Definition . . . . . . . . . . . . . . . . . 15 | |||
6. Pre-Establishment Phase . . . . . . . . . . . . . . . . . . . 16 | 6. Pre-Establishment Phase . . . . . . . . . . . . . . . . . . . 16 | |||
6.1. Specifying Endpoints . . . . . . . . . . . . . . . . . . 17 | 6.1. Specifying Endpoints . . . . . . . . . . . . . . . . . . 17 | |||
6.1.1. Using Multicast Endpoints . . . . . . . . . . . . . . 19 | 6.1.1. Using Multicast Endpoints . . . . . . . . . . . . . . 19 | |||
6.1.2. Constraining Interfaces for Endpoints . . . . . . . . 19 | 6.1.2. Constraining Interfaces for Endpoints . . . . . . . . 20 | |||
6.1.3. Endpoint Aliases . . . . . . . . . . . . . . . . . . 20 | 6.1.3. Endpoint Aliases . . . . . . . . . . . . . . . . . . 21 | |||
6.1.4. Endpoint Examples . . . . . . . . . . . . . . . . . . 20 | 6.1.4. Endpoint Examples . . . . . . . . . . . . . . . . . . 21 | |||
6.1.5. Multicast Examples . . . . . . . . . . . . . . . . . 21 | 6.1.5. Multicast Examples . . . . . . . . . . . . . . . . . 22 | |||
6.2. Specifying Transport Properties . . . . . . . . . . . . . 23 | 6.2. Specifying Transport Properties . . . . . . . . . . . . . 25 | |||
6.2.1. Reliable Data Transfer (Connection) . . . . . . . . . 26 | 6.2.1. Reliable Data Transfer (Connection) . . . . . . . . . 28 | |||
6.2.2. Preservation of Message Boundaries . . . . . . . . . 27 | 6.2.2. Preservation of Message Boundaries . . . . . . . . . 28 | |||
6.2.3. Configure Per-Message Reliability . . . . . . . . . . 27 | 6.2.3. Configure Per-Message Reliability . . . . . . . . . . 28 | |||
6.2.4. Preservation of Data Ordering . . . . . . . . . . . . 27 | 6.2.4. Preservation of Data Ordering . . . . . . . . . . . . 28 | |||
6.2.5. Use 0-RTT Session Establishment with a Safely | 6.2.5. Use 0-RTT Session Establishment with a Safely | |||
Replayable Message . . . . . . . . . . . . . . . . . 27 | Replayable Message . . . . . . . . . . . . . . . . . 29 | |||
6.2.6. Multistream Connections in Group . . . . . . . . . . 28 | 6.2.6. Multistream Connections in Group . . . . . . . . . . 29 | |||
6.2.7. Full Checksum Coverage on Sending . . . . . . . . . . 28 | 6.2.7. Full Checksum Coverage on Sending . . . . . . . . . . 29 | |||
6.2.8. Full Checksum Coverage on Receiving . . . . . . . . . 28 | 6.2.8. Full Checksum Coverage on Receiving . . . . . . . . . 29 | |||
6.2.9. Congestion control . . . . . . . . . . . . . . . . . 29 | 6.2.9. Congestion control . . . . . . . . . . . . . . . . . 30 | |||
6.2.10. Keep alive . . . . . . . . . . . . . . . . . . . . . 29 | 6.2.10. Keep alive . . . . . . . . . . . . . . . . . . . . . 30 | |||
6.2.11. Interface Instance or Type . . . . . . . . . . . . . 29 | 6.2.11. Interface Instance or Type . . . . . . . . . . . . . 30 | |||
6.2.12. Provisioning Domain Instance or Type . . . . . . . . 30 | 6.2.12. Provisioning Domain Instance or Type . . . . . . . . 31 | |||
6.2.13. Use Temporary Local Address . . . . . . . . . . . . . 31 | 6.2.13. Use Temporary Local Address . . . . . . . . . . . . . 32 | |||
6.2.14. Multipath Transport . . . . . . . . . . . . . . . . . 32 | 6.2.14. Multipath Transport . . . . . . . . . . . . . . . . . 33 | |||
6.2.15. Advertisement of Alternative Addresses . . . . . . . 33 | 6.2.15. Advertisement of Alternative Addresses . . . . . . . 34 | |||
6.2.16. Direction of communication . . . . . . . . . . . . . 33 | 6.2.16. Direction of communication . . . . . . . . . . . . . 34 | |||
6.2.17. Notification of ICMP soft error message arrival . . . 34 | 6.2.17. Notification of ICMP soft error message arrival . . . 35 | |||
6.2.18. Initiating side is not the first to write . . . . . . 34 | 6.2.18. Initiating side is not the first to write . . . . . . 35 | |||
6.3. Specifying Security Parameters and Callbacks . . . . . . 35 | 6.3. Specifying Security Parameters and Callbacks . . . . . . 36 | |||
6.3.1. Specifying Security Parameters on a Pre-Connection . 35 | 6.3.1. Specifying Security Parameters on a Pre-Connection . 36 | |||
6.3.2. Connection Establishment Callbacks . . . . . . . . . 37 | 6.3.2. Connection Establishment Callbacks . . . . . . . . . 38 | |||
7. Establishing Connections . . . . . . . . . . . . . . . . . . 37 | 7. Establishing Connections . . . . . . . . . . . . . . . . . . 38 | |||
7.1. Active Open: Initiate . . . . . . . . . . . . . . . . . . 38 | 7.1. Active Open: Initiate . . . . . . . . . . . . . . . . . . 39 | |||
7.2. Passive Open: Listen . . . . . . . . . . . . . . . . . . 39 | 7.2. Passive Open: Listen . . . . . . . . . . . . . . . . . . 40 | |||
7.3. Peer-to-Peer Establishment: Rendezvous . . . . . . . . . 40 | 7.3. Peer-to-Peer Establishment: Rendezvous . . . . . . . . . 41 | |||
7.4. Connection Groups . . . . . . . . . . . . . . . . . . . . 42 | 7.4. Connection Groups . . . . . . . . . . . . . . . . . . . . 43 | |||
7.5. Adding and Removing Endpoints on a Connection . . . . . . 44 | 7.5. Adding and Removing Endpoints on a Connection . . . . . . 45 | |||
8. Managing Connections . . . . . . . . . . . . . . . . . . . . 44 | 8. Managing Connections . . . . . . . . . . . . . . . . . . . . 45 | |||
8.1. Generic Connection Properties . . . . . . . . . . . . . . 46 | 8.1. Generic Connection Properties . . . . . . . . . . . . . . 47 | |||
8.1.1. Required Minimum Corruption Protection Coverage for | 8.1.1. Required Minimum Corruption Protection Coverage for | |||
Receiving . . . . . . . . . . . . . . . . . . . . . . 46 | Receiving . . . . . . . . . . . . . . . . . . . . . . 47 | |||
8.1.2. Connection Priority . . . . . . . . . . . . . . . . . 47 | 8.1.2. Connection Priority . . . . . . . . . . . . . . . . . 48 | |||
8.1.3. Timeout for Aborting Connection . . . . . . . . . . . 47 | 8.1.3. Timeout for Aborting Connection . . . . . . . . . . . 48 | |||
8.1.4. Timeout for keep alive packets . . . . . . . . . . . 47 | 8.1.4. Timeout for keep alive packets . . . . . . . . . . . 48 | |||
8.1.5. Connection Group Transmission Scheduler . . . . . . . 48 | 8.1.5. Connection Group Transmission Scheduler . . . . . . . 49 | |||
8.1.6. Capacity Profile . . . . . . . . . . . . . . . . . . 48 | 8.1.6. Capacity Profile . . . . . . . . . . . . . . . . . . 49 | |||
8.1.7. Policy for using Multipath Transports . . . . . . . . 50 | 8.1.7. Policy for using Multipath Transports . . . . . . . . 51 | |||
8.1.8. Bounds on Send or Receive Rate . . . . . . . . . . . 50 | 8.1.8. Bounds on Send or Receive Rate . . . . . . . . . . . 51 | |||
8.1.9. Group Connection Limit . . . . . . . . . . . . . . . 51 | 8.1.9. Group Connection Limit . . . . . . . . . . . . . . . 52 | |||
8.1.10. Isolate Session . . . . . . . . . . . . . . . . . . . 51 | 8.1.10. Isolate Session . . . . . . . . . . . . . . . . . . . 52 | |||
8.1.11. Read-only Connection Properties . . . . . . . . . . . 52 | 8.1.11. Read-only Connection Properties . . . . . . . . . . . 53 | |||
8.2. TCP-specific Properties: User Timeout Option (UTO) . . . 53 | 8.2. TCP-specific Properties: User Timeout Option (UTO) . . . 54 | |||
8.2.1. Advertised User Timeout . . . . . . . . . . . . . . . 53 | 8.2.1. Advertised User Timeout . . . . . . . . . . . . . . . 54 | |||
8.2.2. User Timeout Enabled . . . . . . . . . . . . . . . . 53 | 8.2.2. User Timeout Enabled . . . . . . . . . . . . . . . . 54 | |||
8.2.3. Timeout Changeable . . . . . . . . . . . . . . . . . 54 | 8.2.3. Timeout Changeable . . . . . . . . . . . . . . . . . 55 | |||
8.3. Connection Lifecycle Events . . . . . . . . . . . . . . . 54 | 8.3. Connection Lifecycle Events . . . . . . . . . . . . . . . 55 | |||
8.3.1. Soft Errors . . . . . . . . . . . . . . . . . . . . . 54 | 8.3.1. Soft Errors . . . . . . . . . . . . . . . . . . . . . 55 | |||
8.3.2. Path change . . . . . . . . . . . . . . . . . . . . . 54 | 8.3.2. Path change . . . . . . . . . . . . . . . . . . . . . 55 | |||
9. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . 54 | 9. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . 55 | |||
9.1. Messages and Framers . . . . . . . . . . . . . . . . . . 55 | 9.1. Messages and Framers . . . . . . . . . . . . . . . . . . 56 | |||
9.1.1. Message Contexts . . . . . . . . . . . . . . . . . . 55 | 9.1.1. Message Contexts . . . . . . . . . . . . . . . . . . 56 | |||
9.1.2. Message Framers . . . . . . . . . . . . . . . . . . . 55 | 9.1.2. Message Framers . . . . . . . . . . . . . . . . . . . 56 | |||
9.1.3. Message Properties . . . . . . . . . . . . . . . . . 58 | 9.1.3. Message Properties . . . . . . . . . . . . . . . . . 59 | |||
9.2. Sending Data . . . . . . . . . . . . . . . . . . . . . . 64 | 9.2. Sending Data . . . . . . . . . . . . . . . . . . . . . . 65 | |||
9.2.1. Basic Sending . . . . . . . . . . . . . . . . . . . . 64 | 9.2.1. Basic Sending . . . . . . . . . . . . . . . . . . . . 65 | |||
9.2.2. Send Events . . . . . . . . . . . . . . . . . . . . . 65 | 9.2.2. Send Events . . . . . . . . . . . . . . . . . . . . . 66 | |||
9.2.3. Partial Sends . . . . . . . . . . . . . . . . . . . . 66 | 9.2.3. Partial Sends . . . . . . . . . . . . . . . . . . . . 67 | |||
9.2.4. Batching Sends . . . . . . . . . . . . . . . . . . . 67 | 9.2.4. Batching Sends . . . . . . . . . . . . . . . . . . . 68 | |||
9.2.5. Send on Active Open: InitiateWithSend . . . . . . . . 67 | 9.2.5. Send on Active Open: InitiateWithSend . . . . . . . . 68 | |||
9.2.6. Priority and the Transport Services API . . . . . . . 68 | 9.2.6. Priority and the Transport Services API . . . . . . . 69 | |||
9.3. Receiving Data . . . . . . . . . . . . . . . . . . . . . 68 | 9.3. Receiving Data . . . . . . . . . . . . . . . . . . . . . 69 | |||
9.3.1. Enqueuing Receives . . . . . . . . . . . . . . . . . 69 | 9.3.1. Enqueuing Receives . . . . . . . . . . . . . . . . . 70 | |||
9.3.2. Receive Events . . . . . . . . . . . . . . . . . . . 69 | 9.3.2. Receive Events . . . . . . . . . . . . . . . . . . . 70 | |||
9.3.3. Receive Message Properties . . . . . . . . . . . . . 72 | 9.3.3. Receive Message Properties . . . . . . . . . . . . . 73 | |||
10. Connection Termination . . . . . . . . . . . . . . . . . . . 73 | 10. Connection Termination . . . . . . . . . . . . . . . . . . . 74 | |||
11. Connection State and Ordering of Operations and Events . . . 75 | 11. Connection State and Ordering of Operations and Events . . . 76 | |||
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 | 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 | |||
13. Privacy and Security Considerations . . . . . . . . . . . . . 76 | 13. Privacy and Security Considerations . . . . . . . . . . . . . 77 | |||
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 | 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 79 | |||
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 | 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 | |||
15.1. Normative References . . . . . . . . . . . . . . . . . . 78 | 15.1. Normative References . . . . . . . . . . . . . . . . . . 79 | |||
15.2. Informative References . . . . . . . . . . . . . . . . . 79 | 15.2. Informative References . . . . . . . . . . . . . . . . . 80 | |||
Appendix A. Implementation Mapping . . . . . . . . . . . . . . . 83 | Appendix A. Implementation Mapping . . . . . . . . . . . . . . . 84 | |||
A.1. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 83 | A.1. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 84 | |||
A.2. Events and Errors . . . . . . . . . . . . . . . . . . . . 84 | A.2. Events and Errors . . . . . . . . . . . . . . . . . . . . 85 | |||
A.3. Time Duration . . . . . . . . . . . . . . . . . . . . . . 84 | A.3. Time Duration . . . . . . . . . . . . . . . . . . . . . . 85 | |||
Appendix B. Convenience Functions . . . . . . . . . . . . . . . 84 | Appendix B. Convenience Functions . . . . . . . . . . . . . . . 85 | |||
B.1. Adding Preference Properties . . . . . . . . . . . . . . 84 | B.1. Adding Preference Properties . . . . . . . . . . . . . . 85 | |||
B.2. Transport Property Profiles . . . . . . . . . . . . . . . 84 | B.2. Transport Property Profiles . . . . . . . . . . . . . . . 85 | |||
B.2.1. reliable-inorder-stream . . . . . . . . . . . . . . . 85 | B.2.1. reliable-inorder-stream . . . . . . . . . . . . . . . 85 | |||
B.2.2. reliable-message . . . . . . . . . . . . . . . . . . 85 | B.2.2. reliable-message . . . . . . . . . . . . . . . . . . 86 | |||
B.2.3. unreliable-datagram . . . . . . . . . . . . . . . . . 85 | B.2.3. unreliable-datagram . . . . . . . . . . . . . . . . . 86 | |||
Appendix C. Relationship to the Minimal Set of Transport Services | Appendix C. Relationship to the Minimal Set of Transport Services | |||
for End Systems . . . . . . . . . . . . . . . . . . . . . 86 | for End Systems . . . . . . . . . . . . . . . . . . . . . 87 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 | |||
1. Introduction | 1. Introduction | |||
This document specifies an abstract application programming interface | This document specifies an abstract application programming interface | |||
(API) that specifies the interface component of the high-level | (API) that specifies the interface component of the high-level | |||
Transport Services architecture defined in [I-D.ietf-taps-arch]. A | Transport Services architecture defined in [I-D.ietf-taps-arch]. A | |||
Transport Services system supports asynchronous, atomic transmission | Transport Services system supports asynchronous, atomic transmission | |||
of messages over transport protocols and network paths dynamically | of messages over transport protocols and network paths dynamically | |||
selected at runtime, in environments where an endpoint selects from | selected at runtime, in environments where an endpoint selects from | |||
multiple interfaces and potential transport protocols. | multiple interfaces and potential transport protocols. | |||
skipping to change at page 7, line 20 ¶ | skipping to change at page 7, line 20 ¶ | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2. Overview of the API Design | 2. Overview of the API Design | |||
The design of the API specified in this document is based on a set of | The design of the API specified in this document is based on a set of | |||
principles, themselves an elaboration on the architectural design | principles, themselves an elaboration on the architectural design | |||
principles defined in [I-D.ietf-taps-arch]. The API defined in this | principles defined in [I-D.ietf-taps-arch]. The API defined in this | |||
document provides: | document provides: | |||
* A Transport Services system can offer a variety of transport | * A Transport Services system that can offer a variety of transport | |||
protocols, independent of the Protocol Stacks that will be used at | protocols, independent of the Protocol Stacks that will be used at | |||
runtime. All common features of these protocol stacks are made | runtime. To the degree possible, all common features of these | |||
available to the application in a transport-independent way to the | protocol stacks are made available to the application in a | |||
degree possible. This enables applications written to a single | transport-independent way. This enables applications written to a | |||
API to make use of transport protocols in terms of the features | single API to make use of transport protocols in terms of the | |||
they provide. | features they provide. | |||
* A unified API to datagram and stream-oriented transports, allowing | * A unified API to datagram and stream-oriented transports, allowing | |||
use of a common API for connection establishment and closing. | use of a common API for connection establishment and closing. | |||
* Message-orientation, as opposed to stream-orientation, using | * Message-orientation, as opposed to stream-orientation, using | |||
application-assisted framing and deframing where the underlying | application-assisted framing and deframing where the underlying | |||
transport does not provide these. | transport does not provide these. | |||
* Asynchronous Connection establishment, transmission, and | * Asynchronous Connection establishment, transmission, and | |||
reception. This allows concurrent operations during establishment | reception. This allows concurrent operations during establishment | |||
and event-driven application interactions with the transport | and event-driven application interactions with the transport | |||
layer; | layer. | |||
* Selection between alternate network paths, using additional | * Selection between alternate network paths, using additional | |||
information about the networks over which a connection can operate | information about the networks over which a connection can operate | |||
(e.g. Provisioning Domain (PvD) information [RFC7556]) where | (e.g. Provisioning Domain (PvD) information [RFC7556]) where | |||
available. | available. | |||
* Explicit support for transport-specific features to be applied, | * Explicit support for transport-specific features to be applied, | |||
should that particular transport be part of a chosen Protocol | should that particular transport be part of a chosen Protocol | |||
Stack. | Stack. | |||
skipping to change at page 9, line 10 ¶ | skipping to change at page 9, line 10 ¶ | |||
notifications also happen asynchronously on the Connection. It is | notifications also happen asynchronously on the Connection. It is | |||
not necessary for an application to handle all Events; some Events | not necessary for an application to handle all Events; some Events | |||
may have implementation-specific default handlers. The application | may have implementation-specific default handlers. The application | |||
should not assume that ignoring Events (e.g., Errors) is always safe. | should not assume that ignoring Events (e.g., Errors) is always safe. | |||
3.1. Usage Examples | 3.1. Usage Examples | |||
The following usage examples illustrate how an application might use | The following usage examples illustrate how an application might use | |||
the Transport Services API to: | the Transport Services API to: | |||
* Act as a server, by listening for incoming connections, receiving | * Act as a server, by listening for incoming Connections, receiving | |||
requests, and sending responses, see Section 3.1.1. | requests, and sending responses, see Section 3.1.1. | |||
* Act as a client, by connecting to a Remote Endpoint using | * Act as a client, by connecting to a Remote Endpoint using | |||
Initiate, sending requests, and receiving responses, see | Initiate, sending requests, and receiving responses, see | |||
Section 3.1.2. | Section 3.1.2. | |||
* Act as a peer, by connecting to a Remote Endpoint using Rendezvous | * Act as a peer, by connecting to a Remote Endpoint using Rendezvous | |||
while simultaneously waiting for incoming Connections, sending | while simultaneously waiting for incoming Connections, sending | |||
Messages, and receiving Messages, see Section 3.1.3. | Messages, and receiving Messages, see Section 3.1.3. | |||
The examples in this section presume that a transport protocol is | The examples in this section presume that a transport protocol is | |||
available between the Local and Remote Endpoints that provides | available between the Local and Remote Endpoints that provides | |||
Reliable Data Transfer, Preservation of Data Ordering, and | Reliable Data Transfer, Preservation of Data Ordering, and | |||
Preservation of Message Boundaries. In this case, the application | Preservation of Message Boundaries. In this case, the application | |||
can choose to receive only complete messages. | can choose to receive only complete Messages. | |||
If none of the available transport protocols provides Preservation of | If none of the available transport protocols provides Preservation of | |||
Message Boundaries, but there is a transport protocol that provides a | Message Boundaries, but there is a transport protocol that provides a | |||
reliable ordered byte stream, an application could receive this byte | reliable ordered byte stream, an application could receive this byte | |||
stream as partial Messages and transform it into application-layer | stream as partial Messages and transform it into application-layer | |||
Messages. Alternatively, an application might provide a Message | Messages. Alternatively, an application might provide a Message | |||
Framer, which can transform a sequence of Messages into a byte stream | Framer, which can transform a sequence of Messages into a byte stream | |||
and vice versa (Section 9.1.2). | and vice versa (Section 9.1.2). | |||
3.1.1. Server Example | 3.1.1. Server Example | |||
skipping to change at page 15, line 23 ¶ | skipping to change at page 15, line 23 ¶ | |||
Namespaces for each of the keywords provided in the IANA protocol | Namespaces for each of the keywords provided in the IANA protocol | |||
numbers registry (see https://www.iana.org/assignments/protocol- | numbers registry (see https://www.iana.org/assignments/protocol- | |||
numbers/protocol-numbers.xhtml) are reserved for Protocol Specific | numbers/protocol-numbers.xhtml) are reserved for Protocol Specific | |||
Properties and MUST NOT be used for vendor or implementation-specific | Properties and MUST NOT be used for vendor or implementation-specific | |||
properties. Avoid using any of the terms listed as keywords in the | properties. Avoid using any of the terms listed as keywords in the | |||
protocol numbers registry as any part of a vendor- or implementation- | protocol numbers registry as any part of a vendor- or implementation- | |||
specific property name. | specific property name. | |||
4.2. Transport Property Types | 4.2. Transport Property Types | |||
Each Transport Property has a one of the basic types described in | Each Transport Property has one of the basic types described in | |||
Section 1.1. | Section 1.1. | |||
Most Selection Properties (see Section 6.2) are of the Enumeration | Most Selection Properties (see Section 6.2) are of the Enumeration | |||
type, and use the Preference Enumeration, which takes one of five | type, and use the Preference Enumeration, which takes one of five | |||
possible values (Prohibit, Avoid, Ignore, Prefer, or Require) | possible values (Prohibit, Avoid, Ignore, Prefer, or Require) | |||
denoting the level of preference for a given property during protocol | denoting the level of preference for a given property during protocol | |||
selection. | selection. | |||
5. Scope of the API Definition | 5. Scope of the API Definition | |||
skipping to change at page 17, line 45 ¶ | skipping to change at page 17, line 45 ¶ | |||
on a Preconnection allows applications to override this for more | on a Preconnection allows applications to override this for more | |||
detailed control. | detailed control. | |||
If Message Framers are used (see Section 9.1.2), they MUST be added | If Message Framers are used (see Section 9.1.2), they MUST be added | |||
to the Preconnection during pre-establishment. | to the Preconnection during pre-establishment. | |||
6.1. Specifying Endpoints | 6.1. Specifying Endpoints | |||
The transport services API uses the Local Endpoint and Remote | The transport services API uses the Local Endpoint and Remote | |||
Endpoint Objects to refer to the endpoints of a transport connection. | Endpoint Objects to refer to the endpoints of a transport connection. | |||
Endpoints can be created as either Remote or Local: | Endpoints can be created as either remote or local: | |||
RemoteSpecifier := NewRemoteEndpoint() | RemoteSpecifier := NewRemoteEndpoint() | |||
LocalSpecifier := NewLocalEndpoint() | LocalSpecifier := NewLocalEndpoint() | |||
A single Endpoint Object represents the identity of a network host. | A single Endpoint Object represents the identity of a network host. | |||
That endpoint can be more or less specific depending on which | That endpoint can be more or less specific depending on which | |||
identifiers are set. For example, an Endpoint that only specifies a | identifiers are set. For example, an Endpoint that only specifies a | |||
hostname may in fact end up corresponding to several different IP | hostname may in fact end up corresponding to several different IP | |||
addresses on different hosts. | addresses on different hosts. | |||
An Endpoint Object can be configured with the following identifiers: | An Endpoint Object can be configured with the following identifiers: | |||
skipping to change at page 19, line 17 ¶ | skipping to change at page 19, line 17 ¶ | |||
Connection. Privacy considerations for the timing of this resolution | Connection. Privacy considerations for the timing of this resolution | |||
are given in Section 13. | are given in Section 13. | |||
The Resolve() action on a Preconnection can be used by the | The Resolve() action on a Preconnection can be used by the | |||
application to force early binding when required, for example with | application to force early binding when required, for example with | |||
some Network Address Translator (NAT) traversal protocols (see | some Network Address Translator (NAT) traversal protocols (see | |||
Section 7.3). | Section 7.3). | |||
6.1.1. Using Multicast Endpoints | 6.1.1. Using Multicast Endpoints | |||
Specifying a multicast group address on a Local Endpoint will | To use multicast, a Preconnection is first created with the Local/ | |||
indicate to the Transport Services system that the resulting | Remote Endpoint specifying the any-source multicast (ASM) or source- | |||
connection will be used to receive multicast messages. The Remote | specific multicast (SSM) multicast group and destination port number. | |||
Endpoint can be used to filter incoming multicast from specific | ||||
senders. Such a Preconnection will only support calling Listen(), | ||||
not Initiate(). Calling Listen() will cause the Transport Services | ||||
system to register for receiving multicast, such as issuing an IGMP | ||||
join [RFC3376] or using MLD for IPV6 [RFC4604]. Any Connections that | ||||
are accepted from this Listener are receive-only. | ||||
Similarly, specifying a multicast group address on the Remote | Calling Initiate() on that Preconnection creates a Connection that | |||
Endpoint will indicate that the resulting connection will be used to | can be used to send messages to the multicast group. The Connection | |||
send multicast messages, and that the Preconnection will support | object that is created will support Send() but not Receive(). Any | |||
Initiate() but not Listen(). Any Connections created this way are | Connections created this way are send-only, and do not join the | |||
send-only. | multicast group. The resulting Connection will have a Local Endpoint | |||
indicating the local interface to which the connection is bound and a | ||||
Remote Endpoint indicating the multicast group. | ||||
A Rendezvous() call on Preconnections containing group addresses | The following API calls can be used to configure a Preconnection | |||
results in an EstablishmentError as described in Section 7.3. | before calling Initiate(): | |||
RemoteSpecifier.WithMulticastGroupIPv4(GroupAddress) | ||||
RemoteSpecifier.WithMulticastGroupIPv6(GroupAddress) | ||||
RemoteSpecifier.WithPort(PortNumber) | ||||
RemoteSpecifier.WithTTL(TTL) | ||||
Calling Listen() on a Preconnection with a multicast group specified | ||||
on the Remote Endpoint will join the multicast group to receive | ||||
messages. This Listener will create one Connection for each Remote | ||||
Endpoint sending to the group, with the Local Endpoint set to the | ||||
group address. The set of Connection objects created forms a | ||||
Connection Group. The receiving interface can be restricted by | ||||
passing it as part of the LocalSpecifier or queried through the | ||||
MessagContext on the messages received (see Section 9.1.1 for further | ||||
details). | ||||
The following API calls can be used to configure a Preconnection | ||||
before calling Listen(): | ||||
LocalSpecifier.WithSingleSourceMulticastGroupIPv4(GroupAddress, SourceAddress) | ||||
LocalSpecifier.WithSingleSourceMulticastGroupIPv6(GroupAddress, SourceAddress) | ||||
LocalSpecifier.WithAnySourceMulticastGroupIPv4(GroupAddress) | ||||
LocalSpecifier.WithAnySourceMulticastGroupIPv6(GroupAddress) | ||||
LocalSpecifier.WithPort(PortNumber) | ||||
Calling Rendezvous() on a Preconnection with an any-source multicast | ||||
group address as the Remote Endpoint will join the multicast group, | ||||
and also indicates that the resulting connection can be used to send | ||||
messages to the multicast group. The Rendezvous() call will return | ||||
both a Connection that can be used to send to the group, that acts | ||||
the same as a connection returned by calling Initiate() with a | ||||
multicast Remote Endpoint, and a Listener that acts as if Listen() | ||||
had been called with a multicast Remote Endpoint. Calling | ||||
Rendezvous() on a Preconnection with a source-specific multicast | ||||
group address as the Local Endpoint results in an EstablishmentError. | ||||
The following API calls can be used to configure a Preconnection | ||||
before calling Rendezvous(): | ||||
RemoteSpecifier.WithMulticastGroupIPv4(GroupAddress) | ||||
RemoteSpecifier.WithMulticastGroupIPv6(GroupAddress) | ||||
RemoteSpecifier.WithPort(PortNumber) | ||||
RemoteSpecifier.WithTTL(TTL) | ||||
LocalSpecifier.WithAnySourceMulticastGroupIPv4(GroupAddress) | ||||
LocalSpecifier.WithAnySourceMulticastGroupIPv6(GroupAddress) | ||||
LocalSpecifier.WithPort(PortNumber) | ||||
LocalSpecifier.WithTTL(TTL) | ||||
See Section 6.1.5 for more examples. | See Section 6.1.5 for more examples. | |||
6.1.2. Constraining Interfaces for Endpoints | 6.1.2. Constraining Interfaces for Endpoints | |||
Note that this API has multiple ways to constrain and prioritize | Note that this API has multiple ways to constrain and prioritize | |||
endpoint candidates based on the network interface: | endpoint candidates based on the network interface: | |||
* Specifying an interface on a RemoteEndpoint qualifies the scope of | * Specifying an interface on a RemoteEndpoint qualifies the scope of | |||
the remote endpoint, e.g., for link-local addresses. | the remote endpoint, e.g., for link-local addresses. | |||
* Specifying an interface on a LocalEndpoint explicitly binds all | * Specifying an interface on a LocalEndpoint explicitly binds all | |||
candidates derived from this endpoint to use the specified | candidates derived from this endpoint to use the specified | |||
interface. | interface. | |||
* Specifying an interface using the interface Selection Property | * Specifying an interface using the interface Selection Property | |||
(Section 6.2.11) or indirectly via the pvd Selection Property | (Section 6.2.11) or indirectly via the pvd Selection Property | |||
(Section 6.2.12) influences the selection among the available | (Section 6.2.12) influences the selection among the available | |||
candidates. | candidates. | |||
While specifying an interface on an endpoint restricts the candidates | While specifying an Interface on an Endpoint restricts the candidates | |||
available for connection establishment in the Pre-Establishment | available for connection establishment in the Pre-Establishment | |||
Phase, the Selection Properties prioritize and constrain the | Phase, the Selection Properties prioritize and constrain the | |||
connection establishment. | connection establishment. | |||
6.1.3. Endpoint Aliases | 6.1.3. Endpoint Aliases | |||
An Endpoint can have an alternative definition when using different | An Endpoint can have an alternative definition when using different | |||
protocols. For example, a server that supports both TLS/TCP and QUIC | protocols. For example, a server that supports both TLS/TCP and QUIC | |||
may be accessible on two different port numbers depending on which | may be accessible on two different port numbers depending on which | |||
protocol is used. | protocol is used. | |||
skipping to change at page 20, line 32 ¶ | skipping to change at page 21, line 27 ¶ | |||
To support this, Endpoint Objects can specify "aliases". An Endpoint | To support this, Endpoint Objects can specify "aliases". An Endpoint | |||
can have multiple aliases set. | can have multiple aliases set. | |||
RemoteSpecifier.AddAlias(AlternateRemoteSpecifier) | RemoteSpecifier.AddAlias(AlternateRemoteSpecifier) | |||
In order to scope an alias to a specific transport protocol, an | In order to scope an alias to a specific transport protocol, an | |||
Endpoint can specify a protocol identifier. | Endpoint can specify a protocol identifier. | |||
RemoteSpecifier.WithProtocol(QUIC) | RemoteSpecifier.WithProtocol(QUIC) | |||
The following example shows a case where "example.com" has a server | The following example shows a case where example.com has a server | |||
running on port 443, with an alternate port of 8443 for QUIC. | running on port 443, with an alternate port of 8443 for QUIC. | |||
RemoteSpecifier := NewRemoteEndpoint() | RemoteSpecifier := NewRemoteEndpoint() | |||
RemoteSpecifier.WithHostname("example.com") | RemoteSpecifier.WithHostname("example.com") | |||
RemoteSpecifier.WithPort(443) | RemoteSpecifier.WithPort(443) | |||
QUICRemoteSpecifier := NewRemoteEndpoint() | QUICRemoteSpecifier := NewRemoteEndpoint() | |||
QUICRemoteSpecifier.WithHostname("example.com") | QUICRemoteSpecifier.WithHostname("example.com") | |||
QUICRemoteSpecifier.WithPort(8443) | QUICRemoteSpecifier.WithPort(8443) | |||
QUICRemoteSpecifier.WithProtocol(QUIC) | QUICRemoteSpecifier.WithProtocol(QUIC) | |||
skipping to change at page 21, line 42 ¶ | skipping to change at page 22, line 36 ¶ | |||
result in an Error once the application attempts to open a | result in an Error once the application attempts to open a | |||
Connection. | Connection. | |||
Specify a Local Endpoint using a STUN server: | Specify a Local Endpoint using a STUN server: | |||
LocalSpecifier := NewLocalEndpoint() | LocalSpecifier := NewLocalEndpoint() | |||
LocalSpecifier.WithStunServer(address, port, credentials) | LocalSpecifier.WithStunServer(address, port, credentials) | |||
6.1.5. Multicast Examples | 6.1.5. Multicast Examples | |||
Specify a Local Endpoint using an Any-Source Multicast group to join | The following examples show how multicast groups can be used. | |||
on a named local interface: | ||||
LocalSpecifier := NewLocalEndpoint() | Join an Any-Source Multicast group in receive-only mode, bound to a | |||
LocalSpecifier.WithIPv4Address(233.252.0.0) | known port on a named local interface: | |||
LocalSpecifier.WithInterface("en0") | ||||
Source-Specific Multicast requires setting both a Local and Remote | RemoteSpecifier := NewRemoteEndpoint() | |||
Endpoint: | ||||
LocalSpecifier := NewLocalEndpoint() | ||||
LocalSpecifier.WithAnySourceMulticastGroupIPv4(233.252.0.0) | ||||
LocalSpecifier.WithPort(5353) | ||||
LocalSpecifier.WithInterface("en0") | ||||
TransportProperties := ... | ||||
SecurityParameters := ... | ||||
Preconnection := newPreconnection(LocalSpecifier, | ||||
RemoteSpecifier, | ||||
TransportProperties, | ||||
SecurityProperties) | ||||
Listener := Preconnection.Listen() | ||||
Join an Source-Specific Multicast group in receive-only mode, bound | ||||
to a known port on a named local interface: | ||||
RemoteSpecifier := NewRemoteEndpoint() | ||||
LocalSpecifier := NewLocalEndpoint() | LocalSpecifier := NewLocalEndpoint() | |||
LocalSpecifier.WithIPv4Address(232.1.1.1) | LocalSpecifier.WithSingleSourceMulticastGroupIPv4(233.252.0.0, 198.51.100.10) | |||
LocalSpecifier.WithPort(5353) | ||||
LocalSpecifier.WithInterface("en0") | LocalSpecifier.WithInterface("en0") | |||
RemoteSpecifier := NewRemoteEndpoint() | TransportProperties := ... | |||
RemoteSpecifier.WithIPv4Address(192.0.2.22) | SecurityParameters := ... | |||
One common pattern for multicast is to both send and receive | Preconnection := newPreconnection(LocalSpecifier, | |||
multicast. For such cases, an application can set up both a Listener | RemoteSpecifier, | |||
and a Connection. The Listener is only used to accept Connections | TransportProperties, | |||
that receive inbound multicast. The initiated Connection is only | SecurityProperties) | |||
used to send multicast. | Listener := Preconnection.Listen() | |||
// Prepare multicast Listener | Create a Source-Specific Multicast group as a sender: | |||
LocalMulticastSpecifier := NewLocalEndpoint() | ||||
LocalMulticastSpecifier.WithIPv4Address(233.252.0.0) | ||||
LocalMulticastSpecifier.WithPort(5353) | ||||
LocalMulticastSpecifier.WithInterface("en0") | ||||
TransportProperties := NewTransportProperties() | RemoteSpecifier := NewRemoteEndpoint() | |||
TransportProperties.Require(preserve-msg-boundaries) | RemoteSpecifier.WithMulticastGroupIPv4(232.1.1.1) | |||
// Reliable Data Transfer and Preserve Order are Required by default | RemoteSpecifier.WithPort(5353) | |||
RemoteSpecifier.WithTTL(8) | ||||
// Specifying a Remote Endpoint is optional when using Listen() | LocalSpecifier := NewLocalEndpoint() | |||
Preconnection := NewPreconnection(LocalMulticastSpecifier, | LocalSpecifier.WithIPv4Address(192.0.2.22) | |||
TransportProperties, | LocalSpecifier.WithInterface("en0") | |||
SecurityParameters) | ||||
MulticastListener := Preconnection.Listen() | TransportProperties := ... | |||
SecurityParameters := ... | ||||
// Handle inbound messages sent to the multicast group | Preconnection := newPreconnection(LocalSpecifier, | |||
MulticastListener -> ConnectionReceived<MulticastReceiverConnection> | RemoteSpecifier, | |||
MulticastReceiverConnection.Receive() | TransportProperties, | |||
MulticastReceiverConnection -> Received<messageDataRequest, messageContext> | SecurityProperties) | |||
Connection := Preconnection.Initiate() | ||||
// Prepare Connection to send multicast | Join an any-source multicast group as both a sender and a receiver: | |||
LocalSpecifier := NewLocalEndpoint() | ||||
LocalSpecifier.WithPort(5353) | ||||
LocalSpecifier.WithInterface("en0") | ||||
RemoteMulticastSpecifier := NewRemoteEndpoint() | ||||
RemoteMulticastSpecifier.WithIPv4Address(233.252.0.0) | ||||
RemoteMulticastSpecifier.WithPort(5353) | ||||
RemoteMulticastSpecifier.WithInterface("en0") | ||||
Preconnection2 := NewPreconnection(LocalSpecifier, | RemoteSpecifier := NewRemoteEndpoint() | |||
RemoteMulticastSpecifier, | RemoteSpecifier.WithMulticastGroupIPv4(233.252.0.0) | |||
TransportProperties, | RemoteSpecifier.WithPort(5353) | |||
SecurityParameters) | RemoteSpecifier.WithTTL(8) | |||
// Send outbound messages to the multicast group | LocalSpecifier := NewLocalEndpoint() | |||
MulticastSenderConnection := Preconnection.Initiate() | LocalSpecifier.WithAnySourceMulticastGroupIPv4(233.252.0.0) | |||
MulticastSenderConnection.Send(messageData) | LocalSpecifier.WithIPv4Address(192.0.2.22) | |||
LocalSpecifier.WithPort(5353) | ||||
LocalSpecifier.WithInterface("en0") | ||||
TransportProperties := ... | ||||
SecurityParameters := ... | ||||
Preconnection := newPreconnection(LocalSpecifier, | ||||
RemoteSpecifier, | ||||
TransportProperties, | ||||
SecurityProperties) | ||||
Connection, Listener := Preconnection.Rendezvous() | ||||
6.2. Specifying Transport Properties | 6.2. Specifying Transport Properties | |||
A Preconnection Object holds properties reflecting the application's | A Preconnection Object holds properties reflecting the application's | |||
requirements and preferences for the transport. These include | requirements and preferences for the transport. These include | |||
Selection Properties for selecting protocol stacks and paths, as well | Selection Properties for selecting protocol stacks and paths, as well | |||
as Connection Properties and Message Properties for configuration of | as Connection Properties and Message Properties for configuration of | |||
the detailed operation of the selected Protocol Stacks on a per- | the detailed operation of the selected Protocol Stacks on a per- | |||
Connection and Message level. | Connection and Message level. | |||
skipping to change at page 24, line 17 ¶ | skipping to change at page 25, line 26 ¶ | |||
Since there could be paths over which some transport protocols are | Since there could be paths over which some transport protocols are | |||
unable to operate, or remote endpoints that support only specific | unable to operate, or remote endpoints that support only specific | |||
network addresses or transports, transport protocol selection is | network addresses or transports, transport protocol selection is | |||
necessarily tied to path selection. This may involve choosing | necessarily tied to path selection. This may involve choosing | |||
between multiple local interfaces that are connected to different | between multiple local interfaces that are connected to different | |||
access networks. | access networks. | |||
When additional information (such as Provisioning Domain (PvD) | When additional information (such as Provisioning Domain (PvD) | |||
information [RFC7556]) is available about the networks over which an | information [RFC7556]) is available about the networks over which an | |||
endpoint can operate, this can inform the selection between alternate | endpoint can operate, this can inform the selection between alternate | |||
network paths. Path information can include network segment PMTU, | network paths. Path information can include PMTU, set of supported | |||
set of supported DSCPs, expected usage, cost, etc. The usage of this | DSCPs, expected usage, cost, etc. The usage of this information by | |||
information by the Transport Services System is generally independent | the Transport Services System is generally independent of the | |||
of the specific mechanism/protocol used to receive the information | specific mechanism/protocol used to receive the information (e.g. | |||
(e.g. zero-conf, DHCP, or IPv6 RA). | zero-conf, DHCP, or IPv6 RA). | |||
Most Selection Properties are represented as Preferences, which can | Most Selection Properties are represented as Preferences, which can | |||
take one of five values: | take one of five values: | |||
+============+========================================+ | +============+========================================+ | |||
| Preference | Effect | | | Preference | Effect | | |||
+============+========================================+ | +============+========================================+ | |||
| Require | Select only protocols/paths providing | | | Require | Select only protocols/paths providing | | |||
| | the property, fail otherwise | | | | the property, fail otherwise | | |||
+------------+----------------------------------------+ | +------------+----------------------------------------+ | |||
skipping to change at page 25, line 12 ¶ | skipping to change at page 26, line 32 ¶ | |||
Table 1: Selection Property Preference Levels | Table 1: Selection Property Preference Levels | |||
The implementation MUST ensure an outcome that is consistent with all | The implementation MUST ensure an outcome that is consistent with all | |||
application requirements expressed using Require and Prohibit. While | application requirements expressed using Require and Prohibit. While | |||
preferences expressed using Prefer and Avoid influence protocol and | preferences expressed using Prefer and Avoid influence protocol and | |||
path selection as well, outcomes can vary given the same Selection | path selection as well, outcomes can vary given the same Selection | |||
Properties, because the available protocols and paths can differ | Properties, because the available protocols and paths can differ | |||
across systems and contexts. However, implementations are | across systems and contexts. However, implementations are | |||
RECOMMENDED to seek to provide a consistent outcome to an | RECOMMENDED to seek to provide a consistent outcome to an | |||
application, given the same set of Selection Properties. | application, when provided with the same set of Selection Properties. | |||
Note that application preferences can conflict with each other. For | Note that application preferences can conflict with each other. For | |||
example, if an application indicates a preference for a specific path | example, if an application indicates a preference for a specific path | |||
by specifying an interface, but also a preference for a protocol, a | by specifying an interface, but also a preference for a protocol, a | |||
situation might occur in which the preferred protocol is not | situation might occur in which the preferred protocol is not | |||
available on the preferred path. In such cases, applications can | available on the preferred path. In such cases, applications can | |||
expect properties that determine path selection to be prioritized | expect properties that determine path selection to be prioritized | |||
over properties that determine protocol selection. The transport | over properties that determine protocol selection. The transport | |||
system SHOULD determine the preferred path first, regardless of | system SHOULD determine the preferred path first, regardless of | |||
protocol preferences. This ordering is chosen to provide consistency | protocol preferences. This ordering is chosen to provide consistency | |||
skipping to change at page 26, line 24 ¶ | skipping to change at page 27, line 41 ¶ | |||
established, Selection Properties can only be read to check the | established, Selection Properties can only be read to check the | |||
properties used by the Connection. Upon reading, the Preference type | properties used by the Connection. Upon reading, the Preference type | |||
of a Selection Property changes into Boolean, where true means that | of a Selection Property changes into Boolean, where true means that | |||
the selected Protocol Stack supports the feature or uses the path | the selected Protocol Stack supports the feature or uses the path | |||
associated with the Selection Property, and false means that the | associated with the Selection Property, and false means that the | |||
Protocol Stack does not support the feature or use the path. | Protocol Stack does not support the feature or use the path. | |||
Implementations of Transport Services systems may alternatively use | Implementations of Transport Services systems may alternatively use | |||
the two Preference values Require and Prohibit to represent true and | the two Preference values Require and Prohibit to represent true and | |||
false, respectively. | false, respectively. | |||
An implementation of the Transport Services API must provide sensible | An implementation of the Transport Services API needs to provide | |||
defaults for Selection Properties. The default values for each | sensible defaults for Selection Properties. The default values for | |||
property below represent a configuration that can be implemented over | each property below represent a configuration that can be implemented | |||
TCP. If these default values are used and TCP is not supported by a | over TCP. If these default values are used and TCP is not supported | |||
Transport Services system, then an application using the default set | by a Transport Services system, then an application using the default | |||
of Properties might not succeed in establishing a connection. Using | set of Properties might not succeed in establishing a connection. | |||
the same default values for independent Transport Services | Using the same default values for independent Transport Services | |||
implementations can be beneficial when applications are ported | implementations can be beneficial when applications are ported | |||
between different implementations/platforms, even if this default | between different implementations/platforms, even if this default | |||
could lead to a connection failure when TCP is not available. If | could lead to a connection failure when TCP is not available. If | |||
default values other than those suggested below are used, it is | default values other than those suggested below are used, it is | |||
RECOMMENDED to clearly document any differences. | RECOMMENDED to clearly document any differences. | |||
6.2.1. Reliable Data Transfer (Connection) | 6.2.1. Reliable Data Transfer (Connection) | |||
Name: reliability | Name: reliability | |||
skipping to change at page 27, line 38 ¶ | skipping to change at page 28, line 52 ¶ | |||
6.2.4. Preservation of Data Ordering | 6.2.4. Preservation of Data Ordering | |||
Name: preserveOrder | Name: preserveOrder | |||
Type: Preference | Type: Preference | |||
Default: Require | Default: Require | |||
This property specifies whether the application wishes to use a | This property specifies whether the application wishes to use a | |||
transport protocol that can ensure that data is received by the | transport protocol that can ensure that data is received by the | |||
application on the other end in the same order as it was sent. | application at the Remote Endpoint in the same order as it was sent. | |||
6.2.5. Use 0-RTT Session Establishment with a Safely Replayable Message | 6.2.5. Use 0-RTT Session Establishment with a Safely Replayable Message | |||
Name: zeroRttMsg | Name: zeroRttMsg | |||
Type: Preference | Type: Preference | |||
Default: Ignore | Default: Ignore | |||
This property specifies whether an application would like to supply a | This property specifies whether an application would like to supply a | |||
Message to the transport protocol before Connection establishment | Message to the transport protocol before Connection establishment | |||
that will then be reliably transferred to the other side before or | that will then be reliably transferred to the other side before or | |||
during Connection establishment. This Message can potentially be | during Connection establishment. This Message can potentially be | |||
received multiple times (i.e., multiple copies of the message data | received multiple times (i.e., multiple copies of the message data | |||
may be passed to the Remote Endpoint). See also Section 9.1.3.4. | may be passed to the Remote Endpoint). See also Section 9.1.3.4. | |||
6.2.6. Multistream Connections in Group | 6.2.6. Multistream Connections in Group | |||
Name: multistreaming | Name: multistreaming | |||
skipping to change at page 30, line 23 ¶ | skipping to change at page 31, line 23 ¶ | |||
available for each interface and interface type available on the | available for each interface and interface type available on the | |||
system. | system. | |||
The set of valid interface types is implementation- and system- | The set of valid interface types is implementation- and system- | |||
specific. For example, on a mobile device, there may be Wi-Fi and | specific. For example, on a mobile device, there may be Wi-Fi and | |||
Cellular interface types available; whereas on a desktop computer, | Cellular interface types available; whereas on a desktop computer, | |||
Wi-Fi and Wired Ethernet interface types might be available. An | Wi-Fi and Wired Ethernet interface types might be available. An | |||
implementation should provide all types that are supported on the | implementation should provide all types that are supported on the | |||
local system, to allow applications to be written generically. For | local system, to allow applications to be written generically. For | |||
example, if a single implementation is used on both mobile devices | example, if a single implementation is used on both mobile devices | |||
and desktop devices, it should define the Cellular interface type for | and desktop devices, it ought to define the Cellular interface type | |||
both systems, since an application might wish to always prohibit | for both systems, since an application might wish to always prohibit | |||
cellular. | cellular. | |||
The set of interface types is expected to change over time as new | The set of interface types is expected to change over time as new | |||
access technologies become available. The taxonomy of interface | access technologies become available. The taxonomy of interface | |||
types on a given Transport Services system is implementation- | types on a given Transport Services system is implementation- | |||
specific. | specific. | |||
Interface types should not be treated as a proxy for properties of | Interface types should not be treated as a proxy for properties of | |||
interfaces such as metered or unmetered network access. If an | interfaces such as metered or unmetered network access. If an | |||
application needs to prohibit metered interfaces, this should be | application needs to prohibit metered interfaces, this should be | |||
skipping to change at page 32, line 14 ¶ | skipping to change at page 33, line 14 ¶ | |||
This property allows the application to express a preference for the | This property allows the application to express a preference for the | |||
use of temporary local addresses, sometimes called "privacy" | use of temporary local addresses, sometimes called "privacy" | |||
addresses [RFC8981]. Temporary addresses are generally used to | addresses [RFC8981]. Temporary addresses are generally used to | |||
prevent linking connections over time when a stable address, | prevent linking connections over time when a stable address, | |||
sometimes called "permanent" address, is not needed. There are some | sometimes called "permanent" address, is not needed. There are some | |||
caveats to note when specifying this property. First, if an | caveats to note when specifying this property. First, if an | |||
application Requires the use of temporary addresses, the resulting | application Requires the use of temporary addresses, the resulting | |||
Connection cannot use IPv4, because temporary addresses do not exist | Connection cannot use IPv4, because temporary addresses do not exist | |||
in IPv4. Second, temporary local addresses might involve trading off | in IPv4. Second, temporary local addresses might involve trading off | |||
privacy for performance. For instance, temporary addresses can | privacy for performance. For instance, temporary addresses (e.g., | |||
interfere with resumption mechanisms that some protocols rely on to | [RFC8981]) can interfere with resumption mechanisms that some | |||
reduce initial latency. | protocols rely on to reduce initial latency. | |||
6.2.14. Multipath Transport | 6.2.14. Multipath Transport | |||
Name: multipath | Name: multipath | |||
Type: Enumeration | Type: Enumeration | |||
Default: Disabled for connections created through initiate and | Default: Disabled for connections created through initiate and | |||
rendezvous, Passive for listeners | rendezvous, Passive for listeners | |||
skipping to change at page 33, line 5 ¶ | skipping to change at page 34, line 5 ¶ | |||
Passive: The connection will support the use of multiple paths if | Passive: The connection will support the use of multiple paths if | |||
the Remote Endpoint requests it. | the Remote Endpoint requests it. | |||
The policy for using multiple paths is specified using the separate | The policy for using multiple paths is specified using the separate | |||
multipathPolicy property, see Section 8.1.7 below. To enable the | multipathPolicy property, see Section 8.1.7 below. To enable the | |||
peer endpoint to initiate additional paths towards a local address | peer endpoint to initiate additional paths towards a local address | |||
other than the one initially used, it is necessary to set the | other than the one initially used, it is necessary to set the | |||
advertisesAltaddr property (see Section 6.2.15 below). | advertisesAltaddr property (see Section 6.2.15 below). | |||
Setting this property to "Active", can have privacy implications: It | Setting this property to Active can have privacy implications: It | |||
enables the transport to establish connectivity using alternate paths | enables the transport to establish connectivity using alternate paths | |||
that might result in users being linkable across the multiple paths, | that might result in users being linkable across the multiple paths, | |||
even if the advertisesAltaddr property (see Section 6.2.15 below) is | even if the advertisesAltaddr property (see Section 6.2.15 below) is | |||
set to false. | set to false. | |||
Note that Multipath Transport has no corresponding Selection Property | Note that Multipath Transport has no corresponding Selection Property | |||
of type Preference. Enumeration values other than "Disabled" are | of type Preference. Enumeration values other than Disabled are | |||
interpreted as a preference for choosing protocols that can make use | interpreted as a preference for choosing protocols that can make use | |||
of multiple paths. The "Disabled" value implies a requirement not to | of multiple paths. The Disabled value implies a requirement not to | |||
use multiple paths in parallel but does not prevent choosing a | use multiple paths in parallel but does not prevent choosing a | |||
protocol that is capable of using multiple paths, e.g., it does not | protocol that is capable of using multiple paths, e.g., it does not | |||
prevent choosing TCP, but prevents sending the MP_CAPABLE option in | prevent choosing TCP, but prevents sending the MP_CAPABLE option in | |||
the TCP handshake. | the TCP handshake. | |||
6.2.15. Advertisement of Alternative Addresses | 6.2.15. Advertisement of Alternative Addresses | |||
Name: advertisesAltaddr | Name: advertisesAltaddr | |||
Type: Boolean | Type: Boolean | |||
skipping to change at page 33, line 50 ¶ | skipping to change at page 34, line 50 ¶ | |||
6.2.16. Direction of communication | 6.2.16. Direction of communication | |||
Name: direction | Name: direction | |||
Type: Enumeration | Type: Enumeration | |||
Default: Bidirectional | Default: Bidirectional | |||
This property specifies whether an application wants to use the | This property specifies whether an application wants to use the | |||
connection for sending and/or receiving data. Possible values are: | Connection for sending and/or receiving data. Possible values are: | |||
Bidirectional: The connection must support sending and receiving | Bidirectional: The connection must support sending and receiving | |||
data | data | |||
Unidirectional send: The connection must support sending data, and | Unidirectional send: The connection must support sending data, and | |||
the application cannot use the connection to receive any data | the application cannot use the connection to receive any data | |||
Unidirectional receive: The connection must support receiving data, | Unidirectional receive: The connection must support receiving data, | |||
and the application cannot use the connection to send any data | and the application cannot use the connection to send any data | |||
skipping to change at page 35, line 5 ¶ | skipping to change at page 36, line 5 ¶ | |||
receiving them [RFC8085]. | receiving them [RFC8085]. | |||
6.2.18. Initiating side is not the first to write | 6.2.18. Initiating side is not the first to write | |||
Name: activeReadBeforeSend | Name: activeReadBeforeSend | |||
Type: Preference | Type: Preference | |||
Default: Ignore | Default: Ignore | |||
The most common client-server communication pattern involves the | The most common client-server communication pattern involves the | |||
client actively opening a connection, then sending data to the | client actively opening a Connection, then sending data to the | |||
server. The server listens (passive open), reads, and then answers. | server. The server listens (passive open), reads, and then answers. | |||
This property specifies whether an application wants to diverge from | This property specifies whether an application wants to diverge from | |||
this pattern -- either by actively opening with Initiate(), | this pattern -- either by actively opening with Initiate(), | |||
immediately followed by reading, or passively opening with Listen(), | immediately followed by reading, or passively opening with Listen(), | |||
immediately followed by writing. This property is ignored when | immediately followed by writing. This property is ignored when | |||
establishing connections using Rendezvous(). Requiring this property | establishing connections using Rendezvous(). Requiring this property | |||
limits the choice of mappings to underlying protocols, which can | limits the choice of mappings to underlying protocols, which can | |||
reduce efficiency. For example, it prevents the Transport Services | reduce efficiency. For example, it prevents the Transport Services | |||
system from mapping Connections to SCTP streams, where the first | system from mapping Connections to SCTP streams, where the first | |||
transmitted data takes the role of an active open signal | transmitted data takes the role of an active open signal | |||
skipping to change at page 39, line 41 ¶ | skipping to change at page 40, line 41 ¶ | |||
reused, e.g., to create another Listener. | reused, e.g., to create another Listener. | |||
Listener.Stop() | Listener.Stop() | |||
Listening continues until the global context shuts down, or until the | Listening continues until the global context shuts down, or until the | |||
Stop action is performed on the Listener object. | Stop action is performed on the Listener object. | |||
Listener -> ConnectionReceived<Connection> | Listener -> ConnectionReceived<Connection> | |||
The ConnectionReceived Event occurs when a Remote Endpoint has | The ConnectionReceived Event occurs when a Remote Endpoint has | |||
established a transport-layer connection to this Listener (for | established or cloned (e.g., by creating a new stream in a multi- | |||
Connection-oriented transport protocols), or when the first Message | stream transport; see Section 7.4) a transport-layer connection to | |||
has been received from the Remote Endpoint (for Connectionless | this Listener (for Connection-oriented transport protocols), or when | |||
protocols), causing a new Connection to be created. The resulting | the first Message has been received from the Remote Endpoint (for | |||
Connection is contained within the ConnectionReceived Event, and is | Connectionless protocols or streams of a multi-streaming transport), | |||
ready to use as soon as it is passed to the application via the | causing a new Connection to be created. The resulting Connection is | |||
event. | contained within the ConnectionReceived Event, and is ready to use as | |||
soon as it is passed to the application via the event. | ||||
Listener.SetNewConnectionLimit(value) | Listener.SetNewConnectionLimit(value) | |||
If the caller wants to rate-limit the number of inbound Connections | If the caller wants to rate-limit the number of inbound Connections | |||
that will be delivered, it can set a cap using | that will be delivered, it can set a cap using | |||
SetNewConnectionLimit(). This mechanism allows a server to protect | SetNewConnectionLimit(). This mechanism allows a server to protect | |||
itself from being drained of resources. Each time a new Connection | itself from being drained of resources. Each time a new Connection | |||
is delivered by the ConnectionReceived Event, the value is | is delivered by the ConnectionReceived Event, the value is | |||
automatically decremented. Once the value reaches zero, no further | automatically decremented. Once the value reaches zero, no further | |||
Connections will be delivered until the caller sets the limit to a | Connections will be delivered until the caller sets the limit to a | |||
higher value. By default, this value is Infinite. The caller is | higher value. By default, this value is Infinite. The caller is | |||
skipping to change at page 41, line 21 ¶ | skipping to change at page 42, line 21 ¶ | |||
action on the Preconnection can be used to discover these bindings: | action on the Preconnection can be used to discover these bindings: | |||
[]LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve() | []LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve() | |||
The Resolve() call returns lists of Local Endpoints and Remote | The Resolve() call returns lists of Local Endpoints and Remote | |||
Endpoints, that represent the concrete addresses, local and server | Endpoints, that represent the concrete addresses, local and server | |||
reflexive, on which a Rendezvous() for the Preconnection will listen | reflexive, on which a Rendezvous() for the Preconnection will listen | |||
for incoming Connections, and to which it will attempt to establish | for incoming Connections, and to which it will attempt to establish | |||
connections. | connections. | |||
Note that the set of LocalEndpoints returned by Resolve() might or | Note that the set of Local Endpoints returned by Resolve() might or | |||
might not contain information about all possible local interfaces; it | might not contain information about all possible local interfaces; it | |||
is valid only for a Rendezvous happening at the same time as the | is valid only for a Rendezvous happening at the same time as the | |||
resolution. Care should be taken in using these values in any other | resolution. Care should be taken in using these values in any other | |||
context. | context. | |||
An application that uses Rendezvous() to establish a peer-to-peer | An application that uses Rendezvous() to establish a peer-to-peer | |||
connection in the presence of NATs will configure the Preconnection | connection in the presence of NATs will configure the Preconnection | |||
object with at least one a Local Endpoint that supports NAT binding | object with at least one a Local Endpoint that supports NAT binding | |||
discovery. It will then Resolve() the Preconnection, and pass the | discovery. It will then Resolve() the Preconnection, and pass the | |||
resulting list of Local Endpoint candidates to the peer via a | resulting list of Local Endpoint candidates to the peer via a | |||
skipping to change at page 42, line 28 ¶ | skipping to change at page 43, line 28 ¶ | |||
7.4. Connection Groups | 7.4. Connection Groups | |||
Connection Groups can be created using the Clone Action: | Connection Groups can be created using the Clone Action: | |||
Connection := Connection.Clone(framer?, connectionProperties?) | Connection := Connection.Clone(framer?, connectionProperties?) | |||
Calling Clone on a Connection yields a Connection Group containing | Calling Clone on a Connection yields a Connection Group containing | |||
two Connections: the parent Connection on which Clone was called, and | two Connections: the parent Connection on which Clone was called, and | |||
a resulting cloned Connection. The new Connection is actively | a resulting cloned Connection. The new Connection is actively | |||
openend, and it will send a Ready Event or an EstablishmentError | openend, and it will locally send a Ready Event or an | |||
Event. Calling Clone on any of these Connections adds another | EstablishmentError Event. Calling Clone on any of these Connections | |||
Connection to the Connection Group. Connections in a Connection | adds another Connection to the Connection Group. Connections in a | |||
Group share all Connection Properties except connPriority (see | Connection Group share all Connection Properties except connPriority | |||
Section 8.1.2), and these Connection Properties are entangled: | (see Section 8.1.2), and these Connection Properties are entangled: | |||
Changing one of the Connection Properties on one Connection in the | Changing one of the Connection Properties on one Connection in the | |||
Connection Group automatically changes the Connection Property for | Connection Group automatically changes the Connection Property for | |||
all others. For example, changing connTimeout (see Section 8.1.3) on | all others. For example, changing connTimeout (see Section 8.1.3) on | |||
one Connection in a Connection Group will automatically make the same | one Connection in a Connection Group will automatically make the same | |||
change to this Connection Property for all other Connections in the | change to this Connection Property for all other Connections in the | |||
Connection Group. Like all other Properties, connPriority is copied | Connection Group. Like all other Properties, connPriority is copied | |||
to the new Connection when calling Clone(), but in this case, a later | to the new Connection when calling Clone(), but in this case, a later | |||
change to the connPriority on one Connection does not change it on | change to the connPriority on one Connection does not change it on | |||
the other Connections in the same Connection Group. | the other Connections in the same Connection Group. | |||
skipping to change at page 43, line 28 ¶ | skipping to change at page 44, line 28 ¶ | |||
Connections will belong to the same group if the application | Connections will belong to the same group if the application | |||
previously called Clone. Passive Connections can also be added to | previously called Clone. Passive Connections can also be added to | |||
the same group -- e.g., when a Listener receives a new Connection | the same group -- e.g., when a Listener receives a new Connection | |||
that is just a new stream of an already active multi-streaming | that is just a new stream of an already active multi-streaming | |||
protocol instance. | protocol instance. | |||
If the underlying protocol supports multi-streaming, it is natural to | If the underlying protocol supports multi-streaming, it is natural to | |||
use this functionality to implement Clone. In that case, Connections | use this functionality to implement Clone. In that case, Connections | |||
in a Connection Group are multiplexed together, giving them similar | in a Connection Group are multiplexed together, giving them similar | |||
treatment not only inside endpoints, but also across the end-to-end | treatment not only inside Endpoints, but also across the end-to-end | |||
Internet path. | Internet path. | |||
Note that calling Clone() can result in on-the-wire signaling, e.g., | Note that calling Clone() can result in on-the-wire signaling, e.g., | |||
to open a new transport connection, depending on the underlying | to open a new transport connection, depending on the underlying | |||
Protocol Stack. When Clone() leads to the opening of multiple such | Protocol Stack. When Clone() leads to the opening of multiple such | |||
connections, the Transport Services system will ensure consistency of | connections, the Transport Services system will ensure consistency of | |||
Connection Properties by uniformly applying them to all underlying | Connection Properties by uniformly applying them to all underlying | |||
connections in a group. Even in such a case, there are possibilities | connections in a group. Even in such a case, there are possibilities | |||
for a Transport Services system to implement prioritization within a | for a Transport Services system to implement prioritization within a | |||
Connection Group [TCP-COUPLING] [RFC8699]. | Connection Group [TCP-COUPLING] [RFC8699]. | |||
skipping to change at page 44, line 19 ¶ | skipping to change at page 45, line 19 ¶ | |||
communicating with, and the paths to those endpoints. A PathChange<> | communicating with, and the paths to those endpoints. A PathChange<> | |||
event, described in Section 8.3.2, will be generated when the path | event, described in Section 8.3.2, will be generated when the path | |||
changes. | changes. | |||
In some cases, however, it is necessary to explicitly indicate to a | In some cases, however, it is necessary to explicitly indicate to a | |||
Connection that a new remote endpoint has become available for use, | Connection that a new remote endpoint has become available for use, | |||
or to indicate that some remote endpoint is no longer available. | or to indicate that some remote endpoint is no longer available. | |||
This is most common in the case of peer to peer connections using | This is most common in the case of peer to peer connections using | |||
Trickle ICE [RFC8838]. | Trickle ICE [RFC8838]. | |||
The AddRemote() action can be used to add one or more new remote | The AddRemote() action can be used to add one or more new Remote | |||
endpoints to a Connection: | Endpoints to a Connection: | |||
Connection.AddRemote([]RemoteEndpoint) | Connection.AddRemote([]RemoteEndpoint) | |||
Endpoints that are already known to the Connection are ignored. A | Endpoints that are already known to the Connection are ignored. A | |||
call to AddRemote() makes the new remote endpoints available to the | call to AddRemote() makes the new Remote Endpoints available to the | |||
connection, but whether the Connection makes use of those endpoints | Connection, but whether the Connection makes use of those endpoints | |||
will depend on the underlying transport protocol. | will depend on the underlying transport protocol. | |||
Similarly, the RemoveRemote() action can be used to tell a connection | Similarly, the RemoveRemote() action can be used to tell a connection | |||
to stop using one or more remote endpoints: | to stop using one or more Remote Endpoints: | |||
Connection.RemoveRemote([]RemoteEndpoint) | Connection.RemoveRemote([]RemoteEndpoint) | |||
Removing all known remote endpoints can have the effect of aborting | Removing all known remote endpoints can have the effect of aborting | |||
the connection. The effect of removing the active remote endpoint(s) | the connection. The effect of removing the active Remote Endpoint(s) | |||
depends on the underlying transport: multipath aware transports might | depends on the underlying transport: multipath aware transports might | |||
be able to switch to a new path if other reachable remote endpoints | be able to switch to a new path if other reachable Remote Endpoints | |||
exist, or the connection might abort. | exist, or the connection might abort. | |||
Similarly, the AddLocal() and RemoveLocal() actions can be used to | Similarly, the AddLocal() and RemoveLocal() actions can be used to | |||
add and remove local endpoints to/from a Connection. | add and remove local endpoints to/from a Connection. | |||
8. Managing Connections | 8. Managing Connections | |||
During pre-establishment and after establishment, connections can be | During pre-establishment and after establishment, connections can be | |||
configured and queried using Connection Properties, and asynchronous | configured and queried using Connection Properties, and asynchronous | |||
information may be available about the state of the connection via | information may be available about the state of the connection via | |||
skipping to change at page 46, line 25 ¶ | skipping to change at page 47, line 25 ¶ | |||
application specified on the Preconnection. Selection Properties | application specified on the Preconnection. Selection Properties | |||
of type Preference will be exposed as boolean values indicating | of type Preference will be exposed as boolean values indicating | |||
whether or not the property applies to the selected transport. | whether or not the property applies to the selected transport. | |||
Note that the instantiated protocol stack might not match all | Note that the instantiated protocol stack might not match all | |||
Protocol Selection Properties that the application specified on | Protocol Selection Properties that the application specified on | |||
the Preconnection. | the Preconnection. | |||
* For Connections that are Established: information concerning the | * For Connections that are Established: information concerning the | |||
path(s) used by the Protocol Stack. This can be derived from | path(s) used by the Protocol Stack. This can be derived from | |||
local PVD information, measurements by the Protocol Stack, or | local PVD information, measurements by the Protocol Stack, or | |||
other sources. For example, a TAPS system that is configured to | other sources. For example, a Transport System that is configured | |||
receive and process PVD information [RFC7556] could also provide | to receive and process PVD information [RFC7556] could also | |||
network configuration information for the chosen path(s). | provide network configuration information for the chosen path(s). | |||
8.1. Generic Connection Properties | 8.1. Generic Connection Properties | |||
Generic Connection Properties are defined independent of the chosen | Generic Connection Properties are defined independent of the chosen | |||
protocol stack and therefore available on all Connections. | protocol stack and therefore available on all Connections. | |||
Many Connection Properties have a corresponding Selection Property | Many Connection Properties have a corresponding Selection Property | |||
that enables applications to express their preference for protocols | that enables applications to express their preference for protocols | |||
providing a supporting transport feature. | providing a supporting transport feature. | |||
skipping to change at page 77, line 30 ¶ | skipping to change at page 78, line 30 ¶ | |||
intended for path exposure, e.g., a DiffServ codepoint setting, that | intended for path exposure, e.g., a DiffServ codepoint setting, that | |||
is either provided directly by the application or indirectly | is either provided directly by the application or indirectly | |||
configured for a traffic profile. | configured for a traffic profile. | |||
Applications should be aware that communication attempts can lead to | Applications should be aware that communication attempts can lead to | |||
more than one connection establishment. This is the case, for | more than one connection establishment. This is the case, for | |||
example, when the Transport Services system also executes name | example, when the Transport Services system also executes name | |||
resolution, when support mechanisms such as TURN or ICE are used to | resolution, when support mechanisms such as TURN or ICE are used to | |||
establish connectivity, if protocols or paths are raised, or if a | establish connectivity, if protocols or paths are raised, or if a | |||
path fails and fallback or re-establishment is supported in the | path fails and fallback or re-establishment is supported in the | |||
Transport Services system. | Transport Services system. Applications should take special care | |||
when using 0-RTT session resumption (see Section 6.2.5), as early | ||||
data sent across multiple paths during connection establishment may | ||||
reveal information that can be used to correlate endpoints on these | ||||
paths. | ||||
Applications should also take care to not assume that all data | Applications should also take care to not assume that all data | |||
received using the Transport Services API is always complete or well- | received using the Transport Services API is always complete or well- | |||
formed. Specifically, messages that are received partially | formed. Specifically, messages that are received partially | |||
Section 9.3.2.2 could be a source of truncation attacks if | Section 9.3.2.2 could be a source of truncation attacks if | |||
applications do not distinguish between partial messages and complete | applications do not distinguish between partial messages and complete | |||
messages. | messages. | |||
The Transport Services API explicitly does not require the | The Transport Services API explicitly does not require the | |||
application to resolve names, though there is a tradeoff between | application to resolve names, though there is a tradeoff between | |||
skipping to change at page 79, line 51 ¶ | skipping to change at page 80, line 51 ¶ | |||
15.2. Informative References | 15.2. Informative References | |||
[I-D.ietf-httpbis-priority] | [I-D.ietf-httpbis-priority] | |||
Oku, K. and L. Pardue, "Extensible Prioritization Scheme | Oku, K. and L. Pardue, "Extensible Prioritization Scheme | |||
for HTTP", Work in Progress, Internet-Draft, draft-ietf- | for HTTP", Work in Progress, Internet-Draft, draft-ietf- | |||
httpbis-priority-12, 17 January 2022, | httpbis-priority-12, 17 January 2022, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- | <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- | |||
priority-12>. | priority-12>. | |||
[I-D.ietf-taps-impl] | [I-D.ietf-taps-impl] | |||
Brunstrom, A., Pauly, T., Enghardt, T., Tiesel, P. S., and | Brunstrom, A., Pauly, T., Enghardt, R., Tiesel, P. S., and | |||
M. Welzl, "Implementing Interfaces to Transport Services", | M. Welzl, "Implementing Interfaces to Transport Services", | |||
Work in Progress, Internet-Draft, draft-ietf-taps-impl-12, | Work in Progress, Internet-Draft, draft-ietf-taps-impl-13, | |||
7 March 2022, <https://datatracker.ietf.org/doc/html/ | 31 August 2022, <https://datatracker.ietf.org/doc/html/ | |||
draft-ietf-taps-impl-12>. | draft-ietf-taps-impl-13>. | |||
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
DOI 10.17487/RFC2474, December 1998, | DOI 10.17487/RFC2474, December 1998, | |||
<https://www.rfc-editor.org/rfc/rfc2474>. | <https://www.rfc-editor.org/rfc/rfc2474>. | |||
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, | [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, | |||
"Assured Forwarding PHB Group", RFC 2597, | "Assured Forwarding PHB Group", RFC 2597, | |||
DOI 10.17487/RFC2597, June 1999, | DOI 10.17487/RFC2597, June 1999, | |||
skipping to change at page 80, line 31 ¶ | skipping to change at page 81, line 31 ¶ | |||
Stiliadis, "An Expedited Forwarding PHB (Per-Hop | Stiliadis, "An Expedited Forwarding PHB (Per-Hop | |||
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, | Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, | |||
<https://www.rfc-editor.org/rfc/rfc3246>. | <https://www.rfc-editor.org/rfc/rfc3246>. | |||
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | |||
A., Peterson, J., Sparks, R., Handley, M., and E. | A., Peterson, J., Sparks, R., Handley, M., and E. | |||
Schooler, "SIP: Session Initiation Protocol", RFC 3261, | Schooler, "SIP: Session Initiation Protocol", RFC 3261, | |||
DOI 10.17487/RFC3261, June 2002, | DOI 10.17487/RFC3261, June 2002, | |||
<https://www.rfc-editor.org/rfc/rfc3261>. | <https://www.rfc-editor.org/rfc/rfc3261>. | |||
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. | ||||
Thyagarajan, "Internet Group Management Protocol, Version | ||||
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, | ||||
<https://www.rfc-editor.org/rfc/rfc3376>. | ||||
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration | [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration | |||
Guidelines for DiffServ Service Classes", RFC 4594, | Guidelines for DiffServ Service Classes", RFC 4594, | |||
DOI 10.17487/RFC4594, August 2006, | DOI 10.17487/RFC4594, August 2006, | |||
<https://www.rfc-editor.org/rfc/rfc4594>. | <https://www.rfc-editor.org/rfc/rfc4594>. | |||
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet | ||||
Group Management Protocol Version 3 (IGMPv3) and Multicast | ||||
Listener Discovery Protocol Version 2 (MLDv2) for Source- | ||||
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, | ||||
August 2006, <https://www.rfc-editor.org/rfc/rfc4604>. | ||||
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment | [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment | |||
(ICE): A Protocol for Network Address Translator (NAT) | (ICE): A Protocol for Network Address Translator (NAT) | |||
Traversal for Offer/Answer Protocols", RFC 5245, | Traversal for Offer/Answer Protocols", RFC 5245, | |||
DOI 10.17487/RFC5245, April 2010, | DOI 10.17487/RFC5245, April 2010, | |||
<https://www.rfc-editor.org/rfc/rfc5245>. | <https://www.rfc-editor.org/rfc/rfc5245>. | |||
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | |||
End of changes. 62 change blocks. | ||||
231 lines changed or deleted | 288 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |