draft-ietf-taps-transports-usage-udp-02.txt   draft-ietf-taps-transports-usage-udp-03.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones Internet-Draft T. Jones
Intended status: Informational University of Aberdeen Intended status: Informational University of Aberdeen
Expires: November 15, 2017 May 16, 2017 Expires: November 23, 2017 May 24, 2017
Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-
Lite) Transport Protocols Lite) Transport Protocols
draft-ietf-taps-transports-usage-udp-02 draft-ietf-taps-transports-usage-udp-03
Abstract Abstract
This is an informational document that describes the transport This is an informational document that describes the transport
protocol interface primitives provided by the User Datagram Protocol protocol interface primitives provided by the User Datagram Protocol
(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport
protocols. It identifies the datagram services exposed to protocols. It identifies the datagram services exposed to
applications and how an application can configure and use the applications and how an application can configure and use the
features offered by the Internet datagram transport service. The features offered by the Internet datagram transport service. The
resulting road map to documentation may be of help to users of the resulting road map to documentation may be of help to users of the
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 November 15, 2017. This Internet-Draft will expire on November 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://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 3, line 48 skipping to change at page 3, line 48
This section summarizes the relevant text parts of the RFCs This section summarizes the relevant text parts of the RFCs
describing the UDP and UDP-Lite protocols, focusing on what the describing the UDP and UDP-Lite protocols, focusing on what the
transport protocols provide to the application (in and how the transport protocols provide to the application (in and how the
transport is used (based on abstract API descriptions, where they are transport is used (based on abstract API descriptions, where they are
available). available).
This section describes unicast usage, but UDP and UDP-Lite also This section describes unicast usage, but UDP and UDP-Lite also
support IPv4 broadcast and IPv4/IPv6 multicast [RFC8085]. Many support IPv4 broadcast and IPv4/IPv6 multicast [RFC8085]. Many
primitives also apply when the transports are used with IP broadcast primitives also apply when the transports are used with IP broadcast
and multicast. Appendix Appendix Appendix A describes where to find and multicast. Appendix describes where to find documentation for
documentation for network-layer primitives required to use UDP or network-layer primitives required to use UDP
UDP-Lite with IP multicast. or UDP-Lite with IP multicast.
3.1. Primitives Provided by UDP 3.1. Primitives Provided by UDP
The User Datagram Protocol (UDP) [RFC0768] States: "This User The User Datagram Protocol (UDP) [RFC0768] States: "This User
Datagram Protocol (UDP) is defined to make available a datagram mode Datagram Protocol (UDP) is defined to make available a datagram mode
of packet-switched computer communication in the environment of an of packet-switched computer communication in the environment of an
interconnected set of computer networks." It "provides a procedure interconnected set of computer networks." It "provides a procedure
for application programs to send messages to other programs with a for application programs to send messages to other programs with a
minimum of protocol mechanism (..)". minimum of protocol mechanism (..)".
The User Interface section of RFC768 states that the user interface The User Interface section of RFC768 states that the user interface
skipping to change at page 7, line 40 skipping to change at page 7, line 38
[RFC8085]). NOTE: In many other IETF transports (e.g., TCP, SCTP) [RFC8085]). NOTE: In many other IETF transports (e.g., TCP, SCTP)
the transport provides the support needed to use DF. However, when the transport provides the support needed to use DF. However, when
using UDP, the application is responsible for the techniques using UDP, the application is responsible for the techniques
needed to discover the effective path maximum transmission unit needed to discover the effective path maximum transmission unit
(PMTU) allowed on the network path, coordinating with the network (PMTU) allowed on the network path, coordinating with the network
layer. The acceptable maximum packet size can be determined using layer. The acceptable maximum packet size can be determined using
Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path
MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis]. MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis].
GET_MMS_S: The GET_MMS_S primitive retrieves a network-layer value GET_MMS_S: The GET_MMS_S primitive retrieves a network-layer value
that indicates the maximum send transport-message size that may be that indicates the maximum message size (MMS) that may be sent at
sent using a non-fragmented IP packet from the configured the transport layer using a non-fragmented IP packet from the
interface. This value is specified in section 6.1 of [RFC1191] configured interface. This value is specified in section 6.1 of
and section 5.1 of [I-D.ietf-6man-rfc1981bis]. It is calculated [RFC1191] and section 5.1 of [I-D.ietf-6man-rfc1981bis]. It is
from Effective Maximum Transmit Unit for Sending (EMTU_S), and the calculated from Effective Maximum Transmit Unit for Sending
link MTU for the given source IP address. This takes into account (EMTU_S), and the link MTU for the given source IP address. This
of the size of the IP header plus space reserved by the IP layer takes into account the size of the IP header plus space reserved
for additional headers (if any). UDP applications should use this by the IP layer for additional headers (if any). UDP applications
value as part of a method to avoid sending UDP datagrams that should use this value as part of a method to avoid sending UDP
would result in IP packets that exceed the effective PMTU allowed datagrams that would result in IP packets that exceed the
across the network path. The effective PMTU (specified in Section effective PMTU allowed across the network path. The effective
1 of [RFC1191]) is equivalent to the EMTU_S (specified in PMTU (specified in Section 1 of [RFC1191]) is equivalent to the
[RFC1122]). The specification of PLPMTUD [RFC4821] states: "If EMTU_S (specified in [RFC1122]). The specification of PLPMTUD
PLPMTUD updates the MTU for a particular path, all Packetization [RFC4821] states: "If PLPMTUD updates the MTU for a particular
Layer sessions that share the path representation (as described in path, all Packetization Layer sessions that share the path
Section 5.2) SHOULD be notified to make use of the new MTU and representation (as described in Section 5.2) SHOULD be notified to
make the required congestion control adjustments". make use of the new MTU and make the required congestion control
adjustments".
GET_MMS_R: The GET_MMS_R primitive retrieves a network-layer value GET_MMS_R: The GET_MMS_R primitive retrieves a network-layer value
that indicates the largest receive transport-message size that may that indicates the maximum message size (MMS) that may be received
be received from the configured interface. This value is at the transport layer from the configured interface. This value
specified in section 3.1 of [RFC1191]. It is calculated from is specified in section 3.1 of [RFC1191]. It is calculated from
Effective Maximum Transmit Unit for Receiving (EMTU_R), and the Effective Maximum Transmit Unit for Receiving (EMTU_R), and the
link MTU for the given source IP address, and takes into account link MTU for the given source IP address, and takes into account
the size of the IP header plus space reserved by the IP layer for the size of the IP header plus space reserved by the IP layer for
additional headers (if any). additional headers (if any).
SET_TTL: The SET_TTL primitive sets the hop limit (TTL field) in the SET_TTL: The SET_TTL primitive sets the hop limit (TTL field) in the
network-layer that is used in the IPv4 header of a packet that network-layer that is used in the IPv4 header of a packet that
carries an UDP datagram. This is used to limit the scope of carries an UDP datagram. This is used to limit the scope of
unicast datagrams. Section 3.2.2.4 of the requirements for unicast datagrams. Section 3.2.2.4 of the requirements for
Internet hosts [RFC1122] states an "incoming Time Exceeded message Internet hosts [RFC1122] states an "incoming Time Exceeded message
skipping to change at page 19, line 11 skipping to change at page 19, line 11
Ed). Ed).
TAPS WG draft -02: TAPS WG draft -02:
o Updated to align with latest taps-transport-usage ID. o Updated to align with latest taps-transport-usage ID.
o Revised to clarify MTU usage and track work in IPv6 PMTU o Revised to clarify MTU usage and track work in IPv6 PMTU
o Usage of DF clarified. o Usage of DF clarified.
TAPS WG draft -03
o edit to MMS entries.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Fraser Noble Building Aberdeen, AB24 3UE Fraser Noble Building Aberdeen, AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
 End of changes. 7 change blocks. 
26 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/