rfc9217.original.xml   rfc9217.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.24 --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -irtf-panrg-questions-12" number="9217" tocInclude="true" sortRefs="true" symRef
-irtf-panrg-questions-12" category="info" tocInclude="true" sortRefs="true" symR s="true" obsoletes="" updates="" submissionType="IRTF" category="info" consensus
efs="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version=" ="true" xml:lang="en" version="3">
3">
<!-- xml2rfc v2v3 conversion 3.12.0 --> <!-- [rfced] FYI: We've updated the term "path aware" when used in attributive p
osition, including in the title of this document. Please let us know if this is
not preferred.
Original:
Current Open Questions in Path Aware Networking
Updated:
Current Open Questions in Path-Aware Networking
Note: We did not hyphenate as part of "Path Aware Networking proposed Research G
roup" since it does not appear as part of the RG name.
-->
<front> <front>
<title abbrev="PAN questions">Current Open Questions in Path Aware Networkin <title abbrev="PAN questions">Current Open Questions in Path-Aware Networkin
g</title> g</title>
<seriesInfo name="Internet-Draft" value="draft-irtf-panrg-questions-12"/> <seriesInfo name="RFC" value="9217"/>
<author initials="B." surname="Trammell" fullname="Brian Trammell"> <author initials="B." surname="Trammell" fullname="Brian Trammell">
<organization>Google Switzerland GmbH</organization> <organization>Google Switzerland GmbH</organization>
<address> <address>
<postal> <postal>
<street>Gustav-Gull-Platz 1</street> <street>Gustav-Gull-Platz 1</street>
<city>8004 Zurich</city> <city>Zurich</city>
<code>8004</code>
<country>Switzerland</country> <country>Switzerland</country>
</postal> </postal>
<email>ietf@trammell.ch</email> <email>ietf@trammell.ch</email>
</address> </address>
</author> </author>
<date year="2022" month="January" day="25"/> <date year="2022" month="March"/>
<workgroup>Path Aware Networking RG</workgroup> <workgroup>Path Aware Networking</workgroup>
<keyword>Internet-Draft</keyword>
<!-- [rfced] Please insert any keywords (beyond those that appear in the title)
for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t>In contrast to the present Internet architecture, a path-aware internet <t>In contrast to the present Internet architecture, a path-aware
working internetworking architecture has two important properties: it exposes
architecture has two important properties: it exposes the properties of the properties of available Internet paths to endpoints, and it provides
available Internet paths to endpoints, and provides for endpoints and for endpoints and applications to use these properties to select paths
applications to use these properties to select paths through the Internet for through the Internet for their traffic. While this property of "path
their traffic. While this property of "path awareness" already exists in many awareness" already exists in many Internet-connected networks within
Internet-connected networks within single domains and via administrative single domains and via administrative interfaces to the network layer, a
interfaces to the network layer, a fully path-aware internetwork expands these fully path-aware internetwork expands these concepts across layers and
concepts across layers and across the Internet.</t> across the Internet.</t>
<t>This document poses questions in path-aware networking open as of 2021,
that <t>This document poses questions in path-aware networking, open as of
must be answered in the design, development, and deployment of path-aware 2021, that must be answered in the design, development, and deployment
internetworks. It was originally written to frame discussions in the Path Aware of path-aware internetworks. It was originally written to frame
Networking proposed Research Group (PANRG), and has been published to snapshot discussions in the Path Aware Networking Research Group (PANRG), and has
current thinking in this space.</t> been published to snapshot current thinking in this space.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/panrg/questions"/>.</t>
</note>
</front> </front>
<middle> <middle>
<!-- [rfced] For ease of the reader, should a definition or reference for SD-WAN
be added? If yes, please provide the reference information. Perhaps an inform
ative reference to the definition in RFC 9061?
Original:
(e.g., Path Computation Element (PCE) [RFC4655] and Software-Defined
Wide Area Network (SD-WAN) approaches)
-->
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction to Path-Aware Networking</name> <name>Introduction to Path-Aware Networking</name>
<t>In the current Internet architecture, the network layer provides a <t>In the current Internet architecture, the network layer provides a
best-effort service to the endpoints using it, without verifiability of the best-effort service to the endpoints using it, without verifiability of
properties of the path between tne endpoints. While there are network layer the properties of the path between the endpoints. While there are
technologies that attempt better-than-best-effort delivery, the interfaces to network-layer technologies that attempt better-than-best-effort
these are generally administrative as opposed to endpoint-exposed (e.g. Path delivery, the interfaces to these are generally administrative as
Computation Element (PCE) <xref target="RFC4655" format="default"/> and Software opposed to endpoint exposed (e.g., Path Computation Element (PCE) <xref
-Defined Wide Area Network target="RFC4655" format="default"/> and Software-Defined Wide Area
(SD-WAN) approaches), and they are often restricted to single Network (SD-WAN) approaches), and they are often restricted to single
administrative domains. In this architecture, an application can assume that a administrative domains. In this architecture, an application can assume
packet with a given destination address will eventually be forwarded toward that that a packet with a given destination address will eventually be
destination, but little else.</t> forwarded toward that destination, but little else.</t>
<t>A transport layer protocol such as TCP can provide reliability over thi <t>A transport-layer protocol such as TCP can provide reliability over
s this best-effort service, and a protocol above the network layer, such
best-effort service, and a protocol above the network layer, such as as Transport Layer Security (TLS) <xref target="RFC8446"
Transport Layer Security (TLS) <xref target="RFC8446" format="default"/> can aut format="default"/>, can authenticate the remote endpoint. However,
henticate the remote little, if any, explicit information about the path is available to the
endpoint. However, little, if any, explicit information about the path endpoints, and any assumptions made about that path often do not hold.
is available to the endpoints, and any assumptions made about that path These sometimes have serious impacts on the application, as in the case
often do not hold. These sometimes have serious impacts on the application, with BGP hijacking attacks.</t>
as in the case with BGP hijacking attacks.</t> <t>By contrast, in a path-aware internetworking architecture, endpoints
<t>By contrast, in a path-aware internetworking architecture, endpoints ca can select or influence the path(s) through the network used by any
n given packet or flow. The network and transport layers explicitly expose
select or influence the path(s) through the network used by any given information about the path or paths available to the endpoints and to
packet or flow. The network and transport layers explicitly expose information the applications running on them, so that they can make this
about the path or paths available to the endpoints and to the applications selection. The Application-Layer Traffic Optimization (ALTO) protocol
running on them, so that they can make this selection. The Application Layer <xref target="RFC7285" format="default"/> can be seen as an example of a
Traffic Optimization (ALTO) protocol <xref target="RFC7285" format="default"/> c path-awareness approach implemented in transport-layer terms on the
an be seen as an example present Internet protocol stack.</t>
of a path-awareness approach implemented in transport-layer terms on the
present Internet protocol stack.</t>
<t>Path selection provides explicit visibility and control of network trea tment to <t>Path selection provides explicit visibility and control of network trea tment to
applications and users of the network. This selection is available to the applications and users of the network. This selection is available to the
application, transport, and/or network layer entities at each endpoint. Path application-, transport-, and/or network-layer entities at each endpoint. Path
control at the flow and subflow level enables the design of new transport control at the flow and subflow level enables the design of new transport
protocols that can leverage multipath connectivity across disjoint paths through protocols that can leverage multipath connectivity across disjoint paths through
the Internet, even over a single physical interface. When exposed to the Internet, even over a single physical interface. When exposed to
applications, or to end-users through a system configuration interface, path applications, or to end users through a system configuration interface, path
control allows the specification of constraints on the paths that traffic should control allows the specification of constraints on the paths that traffic should
traverse, for instance to confound passive surveillance in the network core traverse, for instance to confound passive surveillance in the network core
<xref target="RFC7624" format="default"/>.</t> <xref target="RFC7624" format="default"/>.</t>
<t>We note that this property of "path awareness" already exists in many <t>We note that this property of "path awareness" already exists in many
Internet-connected networks within single domains. Indeed, much of the practice Internet-connected networks within single domains. Indeed, much of the
of network engineering using encapsulation at layer 3 can be said to be "path practice of network engineering using encapsulation at layer 3 can be
aware", in that it explicitly assigns traffic at tunnel endpoints to a given said to be "path aware" in that it explicitly assigns traffic at tunnel
path within the network. Path-aware internetworking seeks to extend this endpoints to a given path within the network. Path-aware internetworking
awareness across domain boundaries without resorting to overlays, except as a seeks to extend this awareness across domain boundaries without
transition technology.</t> resorting to overlays, except as a transition technology.</t>
<t>This document presents a snapshot of open questions in this space that will need <t>This document presents a snapshot of open questions in this space that will need
to be answered in order to realize a path-aware internetworking architecture; it to be answered in order to realize a path-aware internetworking architecture; it
is published to further frame discussions within and outside the Path Aware is published to further frame discussions within and outside the Path Aware
Networking Research Group, and is published with the rough consensus of that Networking Research Group, and is published with the rough consensus of that
group.</t> group.</t>
<section anchor="definitions" numbered="true" toc="default"> <section anchor="definitions" numbered="true" toc="default">
<name>Definitions</name> <name>Definitions</name>
<t>For purposes of this document, "path aware networking" describes endp oint <t>For purposes of this document, "path-aware networking" describes endp oint
discovery of the properties of paths they use for communication across an discovery of the properties of paths they use for communication across an
internetwork, and endpoint reaction to these properties that affects routing internetwork, and endpoint reaction to these properties that affects routing
and/or data transfer. Note that this can and already does happen to some extent and/or data transfer. Note that this can and already does happen to some extent
in the current Internet architecture; this definition expands current techniques in the current Internet architecture; this definition expands current techniques
of path discovery and manipulation to cross administrative domain boundaries and of path discovery and manipulation to cross administrative domain boundaries and
up to the transport and application layers at the endpoints.</t> up to the transport and application layers at the endpoints.</t>
<t>Expanding on this definition, a "path aware internetwork" is one in w <t>Expanding on this definition, a "path-aware internetwork" is one in
hich which endpoint discovery of path properties and endpoint selection of
endpoint discovery of path properties and endpoint selection of paths used by paths used by traffic exchanged by the endpoint are explicitly
traffic exchanged by the endpoint are explicitly supported, regardless of the supported regardless of the specific design of the protocol features
specific design of the protocol features which enable this discovery and that enable this discovery and selection.</t>
selection.</t> <t>A "path", for the purposes of these definitions, is abstractly
<t>A "path", for the purposes of these definitions, is abstractly define defined as a sequence of adjacent path elements over which a packet
d as a can be transmitted, where the definition of "path element" is
sequence of adjacent path elements over which a packet can be transmitted, technology dependent. As this document is intended to pose questions
where the definition of "path element" is technology-dependent. As this document rather than answer them, it assumes that this definition will be
is intended to pose questions rather than answer them, it assumes that this refined as part of the answer to the first two questions it poses
definition will be refined as part of the answer the first two questions it about the vocabulary of path properties and how they are
poses, about the vocabulary of path properties and how they are disseminated.</t disseminated.</t>
> <t>Research into path-aware internetworking covers any and all aspects o
<t>Research into path aware internetworking covers any and all aspects o f
f designing, building, and operating path-aware internetworks or the networks
designing, building, and operating path aware internetworks or the networks
and endpoints attached to them. This document presents a collection of and endpoints attached to them. This document presents a collection of
research questions to address in order to make a path aware Internet a research questions to address in order to make a path-aware Internet a
reality.</t> reality.</t>
</section> </section>
</section> </section>
<section anchor="questions" numbered="true" toc="default"> <section anchor="questions" numbered="true" toc="default">
<name>Questions</name> <name>Questions</name>
<t>Realizing path-aware networking requires answers to a set of open resea <t>Realizing path-aware networking requires answers to a set of open
rch research questions. This document poses these questions as a starting
questions. This document poses these questions, as a starting point for point for discussions about how to realize path awareness in the
discussions about how to realize path awareness in the Internet, and to direct Internet and to direct future research efforts within the Path Aware
future research efforts within the Path Aware Networking Research Group.</t> Networking Research Group.</t>
<section anchor="a-vocabulary-of-path-properties" numbered="true" toc="def ault"> <section anchor="a-vocabulary-of-path-properties" numbered="true" toc="def ault">
<name>A Vocabulary of Path Properties</name> <name>A Vocabulary of Path Properties</name>
<t>The first question: how are paths and path properties defined and rep resented?</t> <t>The first question: how are paths and path properties defined and rep resented?</t>
<t>In order for information about paths to be exposed to an endpoint, an <t>In order for information about paths to be exposed to an endpoint,
d for the and for the endpoint to make use of that information,
endpoint to make use of that information, it is necessary to define a common <!-- [rfced] Is it necessary to a) define a common vocabulary for paths and b) t
vocabulary for paths through an internetwork, and properties of those paths. The he properties of those paths, or to define a) a common vocablary for paths and b
elements of this vocabulary could include terminology for components of a path ) properties of the paths?
and properties defined for these components, for the entire path, or for
subpaths of a path. These properties may be relatively static, such as the Original:
presence of a given node or service function on the path; as well as relatively In order for information about paths to be exposed to an endpoint,
dynamic, such as the current values of metrics such as loss and latency.</t> and for the endpoint to make use of that information, it is necessary
<t>This vocabulary and its representation must be defined carefully, as to define a common vocabulary for paths through an internetwork, and
its design properties of those paths.
will have impacts on the properties (e.g., expressiveness, scalability, security -->
) it is necessary
of a given path-aware internetworking architecture. For example, a system that e to define a common vocabulary for paths through an internetwork and
xposes properties of those paths. The elements of this vocabulary could
node-level information for the topology through each network would maximize include terminology for components of a path and properties defined
information about the individual components of the path at the endpoints, at for these components, for the entire path or for subpaths of a
the expense of making internal network topology universally public, which may path. These properties may be relatively static, such as the presence
be in conflict with the business goals of each network's operator. Furthermore, of a given node or service function on the path, as well as relatively
properties related to individual components of the path may change frequently dynamic, such as the current values of metrics such as loss and
and may quickly become outdated. However, aggregating the properties of latency.</t>
individual components to distill end-to-end properties for the entire path is <t>This vocabulary and its representation must be defined carefully,
not trivial.</t> as its design will have impacts on the properties (e.g.,
expressiveness, scalability, and security) of a given path-aware
internetworking architecture. For example, a system that exposes
node-level information for the topology through each network would
maximize information about the individual components of the path at
the endpoints, at the expense of making internal network topology
universally public, which may be in conflict with the business goals
of each network's operator. Furthermore, properties related to
individual components of the path may change frequently and may
quickly become outdated. However, aggregating the properties of
individual components to distill end-to-end properties for the entire
path is not trivial.</t>
</section> </section>
<section anchor="discovery-distribution-and-trustworthiness-of-path-proper ties" numbered="true" toc="default"> <section anchor="discovery-distribution-and-trustworthiness-of-path-proper ties" numbered="true" toc="default">
<name>Discovery, Distribution, and Trustworthiness of Path Properties</n ame> <name>Discovery, Distribution, and Trustworthiness of Path Properties</n ame>
<t>The second question: how do endpoints and applications get access to accurate, <t>The second question: how do endpoints and applications get access to accurate,
useful, and trustworthy path properties?</t> useful, and trustworthy path properties?</t>
<t>Once endpoints and networks have a shared vocabulary for expressing p <t>Once endpoints and networks have a shared vocabulary for expressing
ath path properties, the network must have some method for distributing
properties, the network must have some method for distributing those path those path properties to the endpoints. Regardless of how path
properties to the endpoints. Regardless of how path property information is property information is distributed, the endpoints require a method to
distributed, the endpoints require a method to authenticate authenticate the properties in order to determine that they originated
the properties -- to determine that they originated from and pertain to the from and pertain to the path that they purport to.</t>
path that they purport to.</t>
<t>Choices in distribution and authentication methods will have impacts on the <t>Choices in distribution and authentication methods will have impacts on the
scalability of a path-aware architecture. Possible dimensions in the space of scalability of a path-aware architecture. Possible dimensions in the space of
distribution methods include in-band versus out-of-band, push versus pull distribution methods include in band versus out of band, push versus pull
versus publish-subscribe, and so on. There are temporal issues with path versus publish subscribe, and so on. There are temporal issues with path
property dissemination as well, especially with dynamic properties, since the property dissemination as well, especially with dynamic properties, since the
measurement or elicitation of dynamic properties may be outdated by the time measurement or elicitation of dynamic properties may be outdated by the time
that information is available at the endpoints, and interactions between the that information is available at the endpoints, and interactions between the
measurement and dissemination delay may exhibit pathological behavior for measurement and dissemination delay may exhibit pathological behavior for
unlucky points in the parameter space.</t> unlucky points in the parameter space.</t>
</section> </section>
<section anchor="supporting-path-selection" numbered="true" toc="default"> <section anchor="supporting-path-selection" numbered="true" toc="default">
<name>Supporting Path Selection</name> <name>Supporting Path Selection</name>
<t>The third question: how can endpoints select paths to use for traffic <t>The third question: how can endpoints select paths to use for
in a way traffic in a way that can be trusted by the network, the endpoints,
that can be trusted by the network, the endpoints, and the applications using th and the applications using them?</t>
em?</t> <t>Access to trustworthy path properties is only half of the challenge
<t>Access to trustworthy path properties is only half of the challenge i in establishing a path-aware architecture. Endpoints must be able to
n use this information in order to select paths for specific traffic
establishing a path-aware architecture. Endpoints must be able to use this they send. As with the dissemination of path properties, choices made
information in order to select paths for specific traffic they send. As with the in path-selection methods will also have an impact on the trade-off
dissemination of path properties, choices made in path selection methods will between scalability and expressiveness of a path-aware
also have an impact on the tradeoff between scalability and expressiveness of a architecture. One key choice here is between in-band and out-of-band
path-aware architecture. One key choice here is between in-band and control of path selection. Another is granularity of path selection
out-of-band control of path selection. Another is granularity of path selection (whether per packet, per flow, or per larger aggregate), which also
(whether per packet, per flow, or per larger aggregate), which also has a large has a large impact on the scalability/expressiveness trade-off. Path
impact on the scalabilty/expressiveness tradeoff. Path selection must, like selection must, like path property information, be trustworthy, such
path property information, be trustworthy, such that the result of a path that the result of a path selection at an endpoint is
selection at an endpoint is predictable. Moreover, any path selection mechanism predictable. Moreover, any path-selection mechanism should aim to
should aim to provide an outcome that is not worse than using a single path, or provide an outcome that is not worse than using a single path or
selecting paths at random.</t> selecting paths at random.</t>
<t>Path selection may be exposed in terms of the properties of the path or the identity <t>Path selection may be exposed in terms of the properties of the path or the identity
of elements of the path. In the latter case, a path may be identified at any of of elements of the path. In the latter case, a path may be identified at any of
multiple layers (e.g. routing domain identifier, network layer address, higher-l ayer multiple layers (e.g., routing domain identifier, network-layer address, higher- layer
identifier or name, and so on). In this case, care must be taken to present identifier or name, and so on). In this case, care must be taken to present
semantically useful information to those making decisions about which path(s) semantically useful information to those making decisions about which path(s)
to trust.</t> to trust.</t>
</section> </section>
<section anchor="interfaces-for-path-awareness" numbered="true" toc="defau lt"> <section anchor="interfaces-for-path-awareness" numbered="true" toc="defau lt">
<name>Interfaces for Path Awareness</name> <name>Interfaces for Path Awareness</name>
<t>The fourth question: how can interfaces among the network, transport, <t>The fourth question: how can interfaces among the network,
and transport, and application layers support the use of path
application layers support the use of path awareness?</t> awareness?</t>
<t>In order for applications to make effective use of a path-aware netwo <t>In order for applications to make effective use of a path-aware
rking networking architecture, the control interfaces presented by the
architecture, the control interfaces presented by the network and transport network and transport layers must also expose path properties to the
layers must also expose path properties to the application in a useful way, and application in a useful way, and provide a useful set of paths among
provide a useful set of paths among which the application can select. Path which the application can select. Path selection must be possible
selection must be possible based not only on the preferences and policies of the based not only on the preferences and policies of the application
application developer, but of end-users as well. Also, the path selection developer, but of end users as well. Also, the path-selection
interfaces presented to applications and end users will need to support multiple interfaces presented to applications and end users will need to
levels of granularity. Most applications' requirements can be satisfied with the support multiple levels of granularity. Most applications'
expression of path selection policies in terms of properties of the paths, while requirements can be satisfied with the expression of path-selection
some applications may need finer-grained, per-path control. These interfaces policies in terms of properties of the paths, while some applications
will need to support incremental development and deployment of applications, and may need finer-grained, per-path control. These interfaces will need
provide sensible defaults, to avoid hindering their adoption.</t> to support incremental development and deployment of applications, and
provide sensible defaults, to avoid hindering their adoption.</t>
</section> </section>
<section anchor="implications-of-path-awareness-for-the-transport-and-appl ication-layers" numbered="true" toc="default"> <section anchor="implications-of-path-awareness-for-the-transport-and-appl ication-layers" numbered="true" toc="default">
<name>Implications of Path Awareness for the Transport and Application L ayers</name> <name>Implications of Path Awareness for the Transport and Application L ayers</name>
<t>The fifth question: how should transport-layer and higher layer proto <t>The fifth question: how should transport-layer and higher-layer
cols be protocols be redesigned to work most effectively over a path-aware
redesigned to work most effectively over a path-aware networking layer?</t> networking layer?</t>
<t>In the current Internet, the basic assumption that at a given time al l <t>In the current Internet, the basic assumption that at a given time al l
traffic for a given flow will receive the same network treatment and traverse traffic for a given flow will receive the same network treatment and traverse
the same path or equivalend paths often holds. In a path aware network, the same path or equivalent paths often holds. In a path-aware network,
this assumption is more easily violated. The weakening of this assumption this assumption is more easily violated. The weakening of this assumption
has implications for the design of protocols above any path-aware network layer. </t> has implications for the design of protocols above any path-aware network layer. </t>
<t>For example, one advantage of multipath communication is that a given <t>For example, one advantage of multipath communication is that a given
end-to-end flow can be "sprayed" along multiple paths in order to confound end-to-end flow can be "sprayed" along multiple paths in order to confound
attempts to collect data or metadata from those flows for pervasive attempts to collect data or metadata from those flows for pervasive
surveillance purposes <xref target="RFC7624" format="default"/>. However, the be nefits of this approach are surveillance purposes <xref target="RFC7624" format="default"/>. However, the be nefits of this approach are
reduced if the upper-layer protocols use linkable identifiers on packets reduced if the upper-layer protocols use linkable identifiers on packets
belonging to the same flow across different paths. Clients may mitigate belonging to the same flow across different paths. Clients may mitigate
linkability by opting to not re-use cleartext connection identifiers, such as linkability by opting to not reuse cleartext connection identifiers, such as
TLS session IDs or tickets, on separate paths. The privacy-conscious TLS session IDs or tickets, on separate paths. The privacy-conscious
strategies required for effective privacy in a path-aware Internet are only strategies required for effective privacy in a path-aware Internet are only
possible if higher-layer protocols such as TLS permit clients to obtain possible if higher-layer protocols such as TLS permit clients to obtain
unlinkable identifiers.</t> unlinkable identifiers.</t>
</section> </section>
<section anchor="what-is-an-endpoint" numbered="true" toc="default"> <section anchor="what-is-an-endpoint" numbered="true" toc="default">
<name>What is an Endpoint?</name> <name>What is an Endpoint?</name>
<t>The sixth question: how is path awareness (in terms of vocabulary and <t>The sixth question: how is path awareness (in terms of vocabulary and
interfaces) different when applied to tunnel and overlay endpoints?</t> interfaces) different when applied to tunnel and overlay endpoints?</t>
<t>The vision of path-aware networking articulated so far makes an assum ption <t>The vision of path-aware networking articulated so far makes an assum ption
skipping to change at line 254 skipping to change at line 301
are running (terminals with user agents, servers, and so on). However, are running (terminals with user agents, servers, and so on). However,
incremental deployment may require that a path-aware network "core" be used to incremental deployment may require that a path-aware network "core" be used to
interconnect islands of legacy protocol networks. In these cases, it is the interconnect islands of legacy protocol networks. In these cases, it is the
gateways, not the application endpoints, that receive path properties and make gateways, not the application endpoints, that receive path properties and make
path selections for that traffic. The interfaces provided by this gateway are path selections for that traffic. The interfaces provided by this gateway are
necessarily different than those a path-aware networking layer provides to its necessarily different than those a path-aware networking layer provides to its
transport and application layers, and the path property information the transport and application layers, and the path property information the
gateway needs and makes available over those interfaces may also be different.</ t> gateway needs and makes available over those interfaces may also be different.</ t>
</section> </section>
<section anchor="operating-a-path-aware-network" numbered="true" toc="defa ult"> <section anchor="operating-a-path-aware-network" numbered="true" toc="defa ult">
<name>Operating a Path Aware Network</name> <name>Operating a Path-Aware Network</name>
<t>The seventh question: how can a path aware network in a path aware in <t>The seventh question: how can a path-aware network in a path-aware in
ternetwork ternetwork
be effectively operated, given control inputs from network administrators, be effectively operated, given control inputs from network administrators,
application designers, and end users?</t> application designers, and end users?</t>
<t>The network operations model in the current Internet architecture ass <t>The network operations model in the current Internet architecture
umes that assumes that traffic flows are controlled by the decisions and
traffic flows are controlled by the decisions and policies made by network policies made by network operators as expressed in interdomain and
operators, as expressed in interdomain and intradomain routing protocols. In intradomain routing protocols. In a network providing path selection
a network providing path selection to the endpoints, however, this assumption to the endpoints, however, this assumption no longer holds, as
no longer holds, as endpoints may react to path properties by selecting endpoints may react to path properties by selecting alternate
alternate paths. Competing control inputs from path-aware endpoints and the rout paths. Competing control inputs from path-aware endpoints and the
ing routing control plane may lead to more difficult traffic engineering
control plane may lead to more difficult traffic engineering or nonconvergent or non-convergent forwarding, especially if the endpoints' and
forwarding, especially if the endpoints' and operators' notion of the "best" pat operators' notion of the "best" path for given traffic diverges
h significantly. The degree of difficulty may depend on the fidelity of
for given traffic diverges significantly. The degree of difficulty may depend on information made available to path-selection algorithms at the
the fidelity of information made available to path selection algorithms at endpoints. Explicit path selection can also specify outbound paths,
the endpoints. Explicit path selection can also specify while BGP policies are expressed in terms of inbound traffic.</t>
outbound paths, while BGP policies are expressed in terms of inbound traffic.</t <t>A concept for path-aware network operations will need to have clear
> methods for the resolution of apparent (if not actual) conflicts of
<t>A concept for path aware network operations will need to have clear m intent between the network's operator and the path selection at an
ethods endpoint. It will also need a set of safety principles to ensure that
for the resolution of apparent (if not actual) conflicts of intent between the increasing path control does not lead to decreasing connectivity; one
network's operator and the path selection at an endpoint. It will also need such safety principle could be "the existence of at least one path
set of safety principles to ensure that increasing path control does not lead between two endpoints guarantees the selection of at least one path
to decreasing connectivity; one such safety principle could be "the existence between those endpoints."</t>
of at least one path between two endpoints guarantees the selection of at
least one path between those endpoints."</t>
</section> </section>
<section anchor="deploying-a-path-aware-network" numbered="true" toc="defa ult"> <section anchor="deploying-a-path-aware-network" numbered="true" toc="defa ult">
<name>Deploying a Path Aware Network</name> <name>Deploying a Path-Aware Network</name>
<t>The eighth question: how can the incentives of network operators and <t>The eighth question: how can the incentives of network operators and
end-users end users
be aligned to realize the vision of path aware networking, and how can the be aligned to realize the vision of path-aware networking, and how can the
transition from current ("path-oblivious") to path-aware networking be managed?< /t> transition from current ("path-oblivious") to path-aware networking be managed?< /t>
<t>The vision presented in the introduction discusses path aware network <t>The vision presented in the introduction discusses path-aware
ing from networking from the point of view of the benefits accruing at the
the point of view of the benefits accruing at the endpoints, to designers of endpoints, to designers of transport protocols and applications as
transport protocols and applications as well as to the end users of those well as to the end users of those applications. However, this vision
applications. However, this vision requires action not only at the endpoints but requires action not only at the endpoints but also within the
also within the interconnected networks offering path aware connectivity. While interconnected networks offering path-aware connectivity. While the
the specific actions required are a matter of the design and implementation of a specific actions required are a matter of the design and
specific realization of a path aware protocol stack, it is clear than any path implementation of a specific realization of a path-aware protocol
aware architecture will require network operators to give up some control of stack, it is clear that any path-aware architecture will require
their networks over to endpoint-driven control inputs.</t> network operators to give up some control of their networks over to
<t>Here the question of apparent versus actual conflicts of intent arise endpoint-driven control inputs.</t>
s again: <t>Here, the question of apparent versus actual conflicts of intent
certain network operations requirements may appear essential, but are merely arises again: certain network operation requirements may appear
accidents of the interfaces provided by current routing and management essential but are merely accidents of the interfaces provided by
protocols. For example, related (but adjacent) to path aware networking, the current routing and management protocols. For example, related (but
widespread use of the TCP wire image <xref target="RFC8546" format="default"/> i adjacent) to path-aware networking, the widespread use of the TCP wire
n network monitoring for DDoS image <xref target="RFC8546" format="default"/> in network monitoring
prevention appears in conflict with the deployment of encrypted transports, only for DDoS prevention appears in conflict with the deployment of
because path signaling <xref target="RFC8558" format="default"/> has been implic encrypted transports, only because path signaling <xref
it in the deployment of past target="RFC8558" format="default"/> has been implicit in the
transport protocols.</t> deployment of past transport protocols.</t>
<t>Similarly, incentives for deployment must show how existing network o <t>Similarly, incentives for deployment must show how existing network
perations operation requirements are met through new path selection and property
requirements are met through new path selection and property dissemination dissemination mechanisms.</t>
mechanisms.</t> <t>The incentives for network operators and equipment vendors need to
<t>The incentives for network operators and equipment vendors need to be be made clear, in terms of a plan to transition <xref target="RFC8170"
made format="default"/> an internetwork to path-aware operation, one
clear, in terms of a plan to transition <xref target="RFC8170" format="default"/ network and facility at a time. This plan to transition must also take
> an internetwork to into account that the dynamics of path-aware networking early in this
path-aware operation, one network and facility at a time. This plan to transition (when few endpoints and flows in the Internet use path
transition must also take into account that the dynamics of path aware selection) may be different than those later in the transition.</t>
networking early in this transition (when few endpoints and flows in the
Internet use path selection) may be different than those later in the
transition.</t>
<t>Aspects of data security and information management in a network that explicitly <t>Aspects of data security and information management in a network that explicitly
radiates more information about the network's deployment and configuration, and radiates more information about the network's deployment and configuration, and
implicitly radiates information about endpoint configuration and preference implicitly radiates information about endpoint configuration and preference
through path selection, must also be addressed.</t> through path selection, must also be addressed.</t>
</section> </section>
</section> </section>
<section anchor="acknowledgments" numbered="true" toc="default">
<name>Acknowledgments</name> <!-- [rfced] Please provide text for a Security Considerations section per the R
<t>Many thanks to Adrian Perrig, Jean-Pierre Smith, Mirja Kuehlewind, Oliv FC Style Guide (see section 4.8.5 of RFC 7322 <https://www.rfc-editor.org/rfc/rf
ier c7322.html#section-4.8.5>).
Bonaventure, Martin Thomson, Shwetha Bhandari, Chris Wood, Lee Howard, Mohamed
Boucadair, Thorben Krueger, Gorry Fairhurst, Spencer Dawkins, Reese Enghardt, In addition, please consider whether an IANA Considerations section should be ad
Laurent Ciavaglia, Stephen Farrell, and Richard Yang, for discussions ded. While the section is not required in RFCs, IANA prefers that a section be
leading to questions in this document, and for feedback on the document itself.< included to clearly indicate that "this document has no IANA actions."
/t> -->
<t>This work is partially supported by the European Commission under Horiz
on 2020
grant agreement no. 688421 Measurement and Architecture for a Middleboxed
Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and
Innovation under contract no. 15.0268. This support does not imply endorsement.<
/t>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4655">
<front>
<title>A Path Computation Element (PCE)-Based Architecture</title>
<author fullname="A. Farrel" initials="A." surname="Farrel">
<organization/>
</author>
<author fullname="J.-P. Vasseur" initials="J.-P." surname="Vasseur">
<organization/>
</author>
<author fullname="J. Ash" initials="J." surname="Ash">
<organization/>
</author>
<date month="August" year="2006"/>
<abstract>
<t>Constraint-based path computation is a fundamental building block
for traffic engineering systems such as Multiprotocol Label Switching (MPLS) an
d Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation
in large, multi-domain, multi-region, or multi-layer networks is complex and may
require special computational components and cooperation between the different
network domains.</t>
<t>This document specifies the architecture for a Path Computation E
lement (PCE)-based model to address this problem space. This document does not
attempt to provide a detailed description of all the architectural components, b
ut rather it describes a set of building blocks for the PCE architecture from wh
ich solutions may be constructed. This memo provides information for the Intern
et community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4655"/>
<seriesInfo name="DOI" value="10.17487/RFC4655"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Securi
ty (TLS) protocol. TLS allows client/server applications to communicate over th
e Internet in a way that is designed to prevent eavesdropping, tampering, and me
ssage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077
, 5246, and 6961. This document also specifies new requirements for TLS 1.2 imp
lementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC7285">
<front>
<title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
<author fullname="R. Alimi" initials="R." role="editor" surname="Alimi
">
<organization/>
</author>
<author fullname="R. Penno" initials="R." role="editor" surname="Penno
">
<organization/>
</author>
<author fullname="Y. Yang" initials="Y." role="editor" surname="Yang">
<organization/>
</author>
<author fullname="S. Kiesel" initials="S." surname="Kiesel">
<organization/>
</author>
<author fullname="S. Previdi" initials="S." surname="Previdi">
<organization/>
</author>
<author fullname="W. Roome" initials="W." surname="Roome">
<organization/>
</author>
<author fullname="S. Shalunov" initials="S." surname="Shalunov">
<organization/>
</author>
<author fullname="R. Woundy" initials="R." surname="Woundy">
<organization/>
</author>
<date month="September" year="2014"/>
<abstract>
<t>Applications using the Internet already have access to some topol
ogy information of Internet Service Provider (ISP) networks. For example, views
to Internet routing tables at Looking Glass servers are available and can be pr
actically downloaded to many network application clients. What is missing is kn
owledge of the underlying network topologies from the point of view of ISPs. In
other words, what an ISP prefers in terms of traffic optimization -- and a way
to distribute it.</t>
<t>The Application-Layer Traffic Optimization (ALTO) services define
d in this document provide network information (e.g., basic network location str
ucture and preferences of network paths) with the goal of modifying network reso
urce consumption patterns while maintaining or improving application performance
. The basic information of ALTO is based on abstract maps of a network. These
maps provide a simplified view, yet enough information about a network for appli
cations to effectively utilize them. Additional services are built on top of th
e maps.</t>
<t>This document describes a protocol implementing the ALTO services
. Although the ALTO services would primarily be provided by ISPs, other entities
, such as content service providers, could also provide ALTO services. Applicat
ions that could use the ALTO services are those that have a choice to which end
points to connect. Examples of such applications are peer-to-peer (P2P) and con
tent delivery networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7285"/>
<seriesInfo name="DOI" value="10.17487/RFC7285"/>
</reference>
<reference anchor="RFC7624">
<front>
<title>Confidentiality in the Face of Pervasive Surveillance: A Threat
Model and Problem Statement</title>
<author fullname="R. Barnes" initials="R." surname="Barnes">
<organization/>
</author>
<author fullname="B. Schneier" initials="B." surname="Schneier">
<organization/>
</author>
<author fullname="C. Jennings" initials="C." surname="Jennings">
<organization/>
</author>
<author fullname="T. Hardie" initials="T." surname="Hardie">
<organization/>
</author>
<author fullname="B. Trammell" initials="B." surname="Trammell">
<organization/>
</author>
<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization/>
</author>
<author fullname="D. Borkmann" initials="D." surname="Borkmann">
<organization/>
</author>
<date month="August" year="2015"/>
<abstract>
<t>Since the initial revelations of pervasive surveillance in 2013,
several classes of attacks on Internet communications have been discovered. In
this document, we develop a threat model that describes these attacks on Interne
t confidentiality. We assume an attacker that is interested in undetected, indi
scriminate eavesdropping. The threat model is based on published, verified atta
cks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7624"/>
<seriesInfo name="DOI" value="10.17487/RFC7624"/>
</reference>
<reference anchor="RFC8546">
<front>
<title>The Wire Image of a Network Protocol</title>
<author fullname="B. Trammell" initials="B." surname="Trammell">
<organization/>
</author>
<author fullname="M. Kuehlewind" initials="M." surname="Kuehlewind">
<organization/>
</author>
<date month="April" year="2019"/>
<abstract>
<t>This document defines the wire image, an abstraction of the infor
mation available to an on-path non-participant in a networking protocol. This a
bstraction is intended to shed light on the implications that increased encrypti
on has for network functions that use the wire image.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8546"/>
<seriesInfo name="DOI" value="10.17487/RFC8546"/>
</reference>
<reference anchor="RFC8558">
<front>
<title>Transport Protocol Path Signals</title>
<author fullname="T. Hardie" initials="T." role="editor" surname="Hard
ie">
<organization/>
</author>
<date month="April" year="2019"/>
<abstract>
<t>This document discusses the nature of signals seen by on-path ele
ments examining transport protocols, contrasting implicit and explicit signals.
For example, TCP's state machine uses a series of well-known messages that are
exchanged in the clear. Because these are visible to network elements on the pa
th between the two nodes setting up the transport connection, they are often use
d as signals by those network elements. In transports that do not exchange thes
e messages in the clear, on-path network elements lack those signals. Often, the
removal of those signals is intended by those moving the messages to confidenti
al channels. Where the endpoints desire that network elements along the path re
ceive these signals, this document recommends explicit signals be used.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8558"/>
<seriesInfo name="DOI" value="10.17487/RFC8558"/>
</reference>
<reference anchor="RFC8170">
<front>
<title>Planning for Protocol Adoption and Subsequent Transitions</titl
e>
<author fullname="D. Thaler" initials="D." role="editor" surname="Thal
er">
<organization/>
</author>
<date month="May" year="2017"/>
<abstract>
<t>Over the many years since the introduction of the Internet Protoc
ol, we have seen a number of transitions throughout the protocol stack, such as
deploying a new protocol, or updating or replacing an existing protocol. Many p
rotocols and technologies were not designed to enable smooth transition to alter
natives or to easily deploy extensions; thus, some transitions, such as the intr
oduction of IPv6, have been difficult. This document attempts to summarize some
basic principles to enable future transitions, and it also summarizes what make
s for a good transition plan.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8170"/>
<seriesInfo name="DOI" value="10.17487/RFC8170"/>
</reference>
</references>
</back>
<!-- ##markdown-source:
H4sIALUe8GEAA71c2ZIbR3Z9z6/IaD2oGQH0ULSkoVsPcpOiKM6IEq1mmGE7
HI5EVQLIYaEKqqVBaEL/7nOXXApAa+bJD5rpJlC53OXcc5fq5XJpxjA2/ta+
nPret6P9ee9b+++TH8bQtYMNrX3nxq29O7je25/8eOj6j6HdGLda9f7h1r67
+8n+Gr9u6q5q3Q7L1b1bj8vQj+vl3rX9Zpm+s/zimand6G9Nhf/ddP3xFrus
O2PCvr+1Yz8N47OnT//16TNDe236btrfXj6E/eW1+eiP+K2+tW/a0fetH5ff
0dbGDKNr6/91TdfiOEc/mH24tf89dtXCDl0/9n494Kfjjn74H2PcNG67/tZY
u8R/Fkcabu2LG/u+d7udbxr+R7nbiz64dv5B129u7euu2zTe3h/C+JvvG2xv
X+9WP/AX/M6FBhf14/rfRn3yptryZwMO40c8j5u7h+XrqWmW7xo3/ma/4M+r
MEJGz58+/dL+19QHfarqpnYk4RX7GdN2/c6N4QHiNSTV/NtyubRuhb1cBem8
abEAnnfDaMfOjltv970fyAKiIK3rq20YfTVOvV9YZ/fQwdKxDoJ+J1lD8VW7
dYPFJzbs9hC0w5L7vtv7fgweMg2j9Z/23eAH3TV+ZLu1cQ8Qk1tBiukUtOtA
Z/Rtve+wMdRGosWDD6HGY7hk/ow+Mm6/bwKsiy0YT06Dp72G2W7498E3OHLc
YQtL22z5UGlzrG3wD6GHXbr1OlQ39sM2NLRcGOJqR5zcXtEqlqXT+mG4sq7p
vauPuGwYRnaknWuPJpkpxN9id19bleNgocgtvjdAotii7mAzLd/IPgRnXb0L
bSAFkkYNq2DtKrkKnVrXsY07+p4UtoYlHR9TG2kBSw8iGYPjVH5PAqz6bhhk
Edlc/6UUzI0x70kC8PdpR0YjCv21xI1i32wptiN8caRs++zpsy8WWNaNZgfT
tyuP7YaD7yETPE/7Qb9h0y7w/w++6fa0lWi/9vumO/LWWClvZcorDjf2zWgP
tFsfNqF1JI5DH8YRZ4DQ1nBE7BGGahqGeGzaNqONKdCG1I1r1vYXCIws3r4m
cLLXwMBfXj+Rg5HxrzzW30+rJgxbfJ0srXX7YduNplKYJUXzorwjJDnsocob
cdNdqOvGG/MZybvv6qkiodI6dLDlGQz+/bNA3/ud3ZrOH3d5xJXPjCU7k7Nm
BR0u/RqmP8JD+odQ+Whh2c2mgQ8PbZDRdtNoH3wf1sGtQhPEI/CAmXm3+DuJ
doXNSUZjW6yZXQsWYAuzkTMaHH/bdk23Ye+F1VgHRe72ZDj4oV/i39plefra
N/CU/ig3njmMETygXTZw2J5NY+5hbKV70XgBP0tBr9pe+5vNjZiKednt9tPI
iGNfNZ7t8vrdy1dP7N///u0v37/88uuvvvr9dzaQ+249kgKX3/l1aLHOBwje
3gEsokqtub7/bvnh7qcnFkjWd67CWdW8cOwjnxqrQICA7BERYVQrY+AwJ9dQ
HIEvqKmd4HprC7y0Ff0+DPBqlbGBYX6ECZGeYR4bLNmSX47wJ37C1TWOQejV
NBZ+2o4TSxPuDC3gqjWfjn4QZy8eXtgVTAcWAw5ifTOQB9wR1rYDxY5snYjb
XWOHCU4Htbx/+Y4PqmYLMTTZ8qBxvuclQxYhuryiW+H7l9BTtzLv01l+5LPc
ezgX7XP9/sf7qN7nX375NdTLsgOPgAhInLJu73fd6E00nxv7Q3eAlLCFXHth
wxqngpHCsKAGxMcUuEm6K3Ku6DmG1Jdi5KlX6u3ao2hwL1C8c5BQXMZJuDNi
PnVn2260266pb6x9zy4xdDs/hh28ZOsgGggudNNAwRzEAR4hCFOYzMK4BJyV
wwpsKS9ev7Pb8DfYDgEFPBU/DdDui2MiHgt66o9oxYmlZvSBoI0GbwR/iKuZ
fFv5JKbr4cksnkfdTuS3qyOLiA05GjdWWTfd4YZkkL7N/jY3xSEpqTkqjSm1
ZebaomWFXDyuM9mlOxXqYPqpbTlgsmR3xFpFfwwBZGo791GJiMgCj8kF7gp/
ZqslKyb2AnYP1Ybf5KPrux/f//wk+4LY8p+fPf9KbXlF6pdwjd/8J7fbA14A
5KXSiO0knCIzEfjTGB7FtxRPhnp30YbMGeHMfk7WAmNhcE2Xy1EqecpDGIL6
PcmRLQvP44hRieDWbmQ8BujPiCE9AIPoU2jSR0iGpUztBZ8rV1rkW7ID/gla
n0dXwgOOgdCeJyllMKAbmnhsUS5bIp9umFb8c0PsBw/RAYaCF8k9D3l/EyWo
AZKUSA/3buPtbmrGwGap1DM8sNyE3YEF/Y2ONGfDpiR9C0Z3AVgXWep+exwg
iCaHVyDJB0CgjXHyRO4L8gqJp0sRf/RUrHkcENHpfOuwmXox07TwQqArSauB
bEQcw95XIB9q8pAKvkPxjx1MESvei4Ss3gBGNjW1wa+40oD114wmlDkK56GD
IM1CsgFApVg6TP2DR5zjLyjmRV1XHeii+tDXz778/XcY8AdPAOuj4/5/5QwU
62vv6wWUDnOL1ItSPwRBU7iHb8GLPTAeSCOcDkAKrjo1Gn5iDP6XhAguMGDh
Rz6/4fNfLUQc+L4keBEkSXAbSsNU5iQHIBvbc4RArOYSHkMieqeZT757PEoA
oz5KhvgJQa2W4F9gkxo4i8auSJ+uJ2+MzBUwBN+hlbAGWTduPFA4poSIwc+w
hwVh4ZGGHs+TIAE0YtGR8JPsOeWZpUaZ8YvImDpBDbDF7jQN6sCf2GFgGk34
zf/zEfMbqIIIwywTWU89EewLuY9KnYAHUhmIVz2eC81TICEes62YBDD/Yd8m
h/TtMCnYggVyYQci/Owzy0w4SNgz31PQnHpJKPnLhYgXpc8UaeUVIWLVhxUF
B7UrQ5cjdR6zA5TZSAQERFMqEJDvV91uN7URR9RwwDVKKctd4yaW1JLSs/Mi
A1Po9doTdcKFRy6WSIyo3egEute+v7E/zXGCuSSxOYWEumNGtt9L6kosTewd
Kv4nkr5vVI5J0in9Txkp2XUgMzUqHJsFSCcBFIV9xAUCR5HOpWSj9DIqyCBJ
VoqT+RRfriAqseAwzvkRLOQVnzRxodk1qMxRmkSpqSuyyK5loD5sqW6WtDYz
DX68UNpMv5kGJJNRFmkipAEokHluhFqWh+dErcDCYdrT1QmXe79BPtQQPmmq
HGNYEdvVZoUTrcFjoMhBrqJsQMVR6slkMki5FAvnSkIbrzdzLTLXLEyAHnEd
LRLiwLWmqIyBg/9VWDYRwBrM3itbQOLGlG8QaiDnI5Riaq1hgxW/o9JLvTAH
TvGFyCSDTAFRl2P1ZbRd1h62X3tiTXfDHBYI5UjzraSaXI0qEBe2ueWkkH2K
oFUpdRg11x2y55niSIzLK8rhkhz2rh+jbvJadh16qqQeuhLowcdI1IsiiXvo
KreCEz1ueVsQvpTlQ7OD31Gy7GuoM6EuLtvZR8yeHIXNYZBUkEEEdIkMbOQq
q1gYvkfpd2hq/olxHwdxHAkfWXuwakbxd1M6yyB5nkYaErFy6UsREjadPcv0
8WZZfMQKtLRQhkHOelx5wAx4hmPkSJH5s9zEILlR6Iz3Oi9K9jDt0LMCSKPK
SAafw3c8n0nnO7taLGmXprdg16F8RgiGwAJVlcvIK+bBis9hfs4NI9nMXFzz
xhrnrkaznrj0nsQoZY+hpFKPtFBmgVzi8Z39j5mZ8pPvkpkS7YkWH296y8en
tTXhZdI8t+6EJvis92oKvv6Wy5aiXyHgp9WP1AJY+SKr4JxULU/EoRiXYT6a
C8V35R3l8gwA0CE4NURMlyWB8inZQHc7pPSFx65TPp9Sltaec4PToieBET/G
2bnJaKnkptihooQES1bNRPQL2XIQ9Iv0ZI94ps+KD5iTHaOQVRbYOj+VowBl
pKorzsfIIpFtyuXS2jdaEiqW37mjAGLD8Z6CGpU9q1QwKzJ7DRVaMmw73Ahb
xZLyemrV+3N+9g0tcPCMVsUepj62bneySSIuD66ZRNQ7T8XQIX2rEfpWg1sg
NlSJsBcCZ95K3Czao9hd7EdEaVawbO6msEPTAxqlDYcIrpSdVMgKoXGlmOt7
hGYkDfwfLoO0WauW+EXrik9MIbN/kujfWCLNWp9Z5Dya7V2bbYbkv5RKQulh
0SLGbi+GFk2bCxUxTTywXe7cJ6oeeXO5QBlA0h5CPbnmxFJTPeyU3OGsI5cY
cEhkB2wvcFjpi9B9XZMLOfGAIOgU3LjGzPkG7EI4B4zTrJjuUeKOD8achqwo
uyUg3XSu4VOVF/x80NjXgYl/LynSDvn8ouxgsEEK9Pzjq5KjCC1EqsXMCYTK
CI8+AjZD9ZFr5BUReUiw5hCfi8NusyGOKGnpWZ/08v4cDgDHDSfXy7Fb+jk4
XHB/4J+hGjA85yG4RhOySCgX9CM+Wk1KtrHee+rQQ2gUWJS/XgwQsOgOX59H
iLo7KX3OSnIbCuIVgTHje1VRDQhKAH7D+zTmpe2PpxEGkeRnQp35Dom6sJfC
ObaOUusTXI/OqRyh0Pu8X8bIIJVx0hwgZ9sJ2tZJUqyyiPpm3nOeJzcIv2Ue
QBIq73ScuSpx07gH5RDzOrJyGFxQz0QSLJoR5sSKlkuJdhJkUuoJ4qnNUjL1
dd/tJKbhKUrstPzJh8xPcFLRU7yF/bzcdoGabPh2XRiPaDsfiGGWT6qtowsg
agqIzGFJEXGOgO+A9YEyojogus66uVJoId5bHifuHYNtaJcrbrUDW6hMMY3L
bs3/tMD9hm38AClwY9LPXO5YInRK9UFMdOisluK1kUltyq6nIimyDa08zYzj
WDB9lpWEQcQMTgulcU0PaSS0pXnCaKX3YXbeDZCGtMVh05x4pqLo+bMxnEf8
iQks9X/MKVua18EvQDmFUkJtqYcMuct7cjLu38+uWwNZj3wY/2kbVkEoH/d6
qbS88rCNoDRlapup+ni0avYhsgeqZ2Hz1EgHjN1Lvk3+yAh1HzNjASgAWH+K
T1VBKoeTAZEu1Yli5s/9qwOiTqq2c6YLiMiyTNTwgrhOmz5agqXMCVh2l5Dw
DzBPahwwj61r1jECIfAguaLYE1qD6zk2U6YNj3vQq3TtNI2hDQ+ZnwH8zKyh
yMlmciIBpWJGlBTDBPhVzcl7jMpmbgbnGfECVxE04S6mTpUURZkSQQwCe6co
3yqSRDaGc9S+W6+TUZbIwjnsjJwx2JhHRfUz8PIjdeH4cJb9PGSDj1BC1ZgC
R8r21PwaEApiMNUosMqmdy3FJcW8+TfN9WHr+Zt7+o9LLAv+mTpFzOXpFzy+
oS6Nkgj/JFIkFRElpfwdMxdTlMp4/NOJQKIAdeKh0MBEndwmfNSocCl0LZJf
iBErkY8BhNLWqRmLpCYvT/XT7JJcY0b0BrUj47yxb0HSOiFM7fHcOIiBhWFn
pNNjXdhxeUjHBrAw1MMMTMBu4HY4zsgGj4/FH3OzS/OleD4lC1y1hNbqbnfe
tFSIjXkr4ZU0QS/VpMvOMVPqmnuHR0oK5nmj1wxNJ34amoXpuf8eR/XizrLG
OlDmPbKYEAqlGdj4WHaVYRatUMcqbnoS4p13NLUws7DbsIExSnfX5O/T+WlY
soiHT/IAipyScqoENSPS9FZ0w2kYJLxzTBQo9An/mwUjJiLEsTRfqAE4ZTVF
zF2HAUzEUIkLb/IkEIFVLoyQpWt1o6Mk4EJwKKaI3K5Tcp4xftYJNhfq21oD
5se0LDGv9JyWQ06HGbmg4bmlQAV3XWOG648MZkoIiiBUXCSVYk5i1nwCwugN
WGWMIzoAcRqRzqcZJFCqFhEvRTrJDeMnWnBTl2LpihpPlyNFiIdpB30OR2RQ
+8gHV47cjvyaw2TKzv0aqN1WWnVFbgmulJxwpjkdPiQvoGklcsXUu1aiBgCH
QBbZfzNgX5QzcfPTWQSf5hFSO5BjqxpM9FjDOTwftIgUhISklmLRz2NKIKiR
2rdjGBgMUhCOSF9E4GLmIgqmBK7LoDVwkMEJOTOa3Y+giC9E5ZR+uaHWPKUw
WGUZRxLIKmPFKQvNXBQGGK/cC+ywmA29MBo6Hz0ozY76kZIx+LWDcCnRg1oe
ulAD1tpamuIjT/+6uttrS4XwY1dcLaa/CUBSlv1+1us6G8pJddT1GdBouDqd
nuH2AAPuyWAcUQ+DsMg1KZGUJKtkEwkrmmOc3bhcBec1v310iFSsG+5EXfw0
X6YtzjHVrCh3oIZDao8xiOmHPM7CGu195YOO3g3Uij4f2FH04dkMk74XwyPZ
9oNrvBaaB52IpFk2mXWc9QgiQhuZgMzHx29U6LHITwIEhDSjkUoM6ebgKSxx
51FrtflJQywqlJYQ9Z4beFk/MmcYOcpc9iL4G2l9pyoeNS5d/YAgSMM7VBgr
5nfKNnWIbWYdoShKPyxudfyrYd9jn5qmTAhZEwMQ6ZV0Po69GB2wHeQfuV8j
bWscFMzb8c9cI5BYvOaJnLWQ0AdH5NHMRmZS93E2J5OrXmxh8KJ1KOrjabiM
ZhBg5VNFPEpwB3gQ6UchbQqKTWg/cgKTWQmXFYQz03QoiUGnPpJ1yexVHIla
c4wYY/X+ZRMYSgnNdmEMxKyN7COJBMIn4YSsSSGn9xQnbNV414/+05hGr7qS
XQ3FuOmP9wAmAeM330m7LfCBySLwESW6Y9lPwLXhB9WRhoOGimY1DXfj/UZq
lhwCpEKVWYM+czaAWcwOeI6XJsVRCLwke4W001Quzr6nahKuqZKigZoVFY4o
bb+gEMHTD0q+YagxCf1Wa4jh0xk4Ugow741dl7FpXtwvwu+TQqEHGlDj0KC9
ShlJ4h6oDADlVF2P8hDKCHmOntThqyapEIMbrV3PVI1vVaBGGsEtg2jsM5ft
3tkrL6R7TeDKGVE6QpwTvZZCHhW3ObITlUACKH0farqwnZV0PHqdmUfTFD3J
zGNVURHmAnhd0dzbFZ1+0mk/FrkaOrTV8JgJ5NYgFYXNpYmG4i2NNvaqHPfL
pS1H3IRc7MDjWFykPuGBRTmFDxiDyqW+OinDzMlNhOw8EigeNaNsTBaUGVN2
LgdiLIp9Qwoc2bY4cRQ8/MNIm8dZqaEARPpHszG5ZvR4jbiQGZOmfPeyeKcz
8t2MabG+mdezJep1xEN/ToMB7kIfOdb7afb/Us50KRJn6LkwZkBdnBlt4e2J
MAqNyDnMfoJzcARKOUseSEIevzhh8kyQoigT41YXj0voGAQT167mhtk/nrCa
TZJk8sMRke6nZ25yllWkrGUGwpWu1TGexsTGlAwTKFmXSgLLTJN1Lb/2Tn+P
uXzCaXIz49IlxfrSrEdm/OdvFWxzeJ5ToLazFERhTEy75IC5jMj4QdWlOKxS
uOTqaFMRxbiGm305rtH7NH6USZZzVRdOdTJHL/OGvGZ8cA/88XwWBGFGVeZ7
ZOCE13kauByFpfJF12IJXJsg1OibLDwpU9TklYWkU3xejNFAY58TamnUoO9d
0SspV1LiIuhRxqwHqAPvhoBK0zk0zkw9Q4Gk2m96zzQwHVwK5jIVZTmyUDJB
7zxJ4bCEBXkHpBxiP1G6azYd8sjtbkgt2dykehXH7U8eYt8mwJBy75GKnSud
l87pIL8KkqxbR+KyDafAHVp5NkIxTa/pW4lp8uIEQwpHnaWJXANm0hULxCaS
cxr2baaoFICDY5e+hiYpwsBaJ9c8SQ1kPRnNWc76Ged94zk4P1bAlDcS6aws
OJ751bLH4NZ+pPCIcEzEXF96pbZJnFxBmHapRZlcg0dD6fBk4IabeumL5aj/
N5xTMFs73UsHTyhNkHY8AJSKIzyMwAsPIz89f33vUFKUzQRqCknpKwqzwUnY
1GNrcBTKxnalE8HEQv443niw0YvhRmYRaDwRDjWUL4Mkx4zwL1UcCjeuSalz
nMAaz1jf2dzxIo3s6cblpDhjVYwZ1zzbuOxWDXQBkn71JHrhOT1YEV614G71
nHvm+lGItyxeD9WJMj9cPiofR5rAXEknqhz8IUJTyrpcVfWTvLN1GgfYtDSC
UhE5E5Yi0T3t6RcTPTmylC/eQP+zF0Rm6SBN68jl84yeXDdV9E7PSUU6aQUV
w28lJy1fn+iI5pwMPJY+oy+lSvkhNrVigzMlV0767lKDV4FqFYDDcnwpKrW5
XB73FWvLn5Qnmb8QFXmxAJtOsx5tfgljzke0zCL8/dwDoIwNF5D3MsmQm1P6
xnuW0YPvy2xkWfcXWBjw+oc41Rt9cgax2jMXhL0IsGDSZL5uA/5yayodObgA
9rPCJtPW/Z5kQkEFXu8aqdRygwFnosGbquK0MxUsH+H40V0je9LBd/gizxkX
ZGpWrImjQde8rQ5HJw+/ABsEFQci/3sa788Dip7fbT2QysKOCj/6gulX/IJp
IY1d1wbokR0bJ/nuu+6exu6IgnPUYYEMl2eh5hVS4Hx/3HPGGf2Ziw0NDVNV
booVfjJnmCq9b65n+uo5zpReeJdaGL++emGXPdD/EmDAbO7DDrykp+G6ArZ5
pKZIRqmuPxDS0n8coOgo58ZhZsYhJjCmqTZ6Xe40QOcZqZMxDJMaiMONAPHJ
+R6JK9hfytHQRk3/GnkJA3vtDXvwYsZ+HBNVafanCKKC/uLPT/nl8fnfb0Cm
XYSPJACpHJYdHFi59rkphaf6rM4u645lzMrNHerIyZw5fIf+1khu1+ogyTAP
i6aINZ7Umd50Kta/5srLGlqYM3fJk8Ry0vtuNtte1NaT2NW8mG+TE/Zxlbwr
Uck0/S4FzDhuqWlTyZSjs0uGmqSts5T6LodBnhWwm1aPLw9EZpJYGLIOAuQX
HKUrEb0HYktLn6+a+uDzVyTFhGNHy0Rjn4tuUSiXCI+0cPm9gs/sXfWx7Q5I
TjfsN8a8pdBCopVX6+5q/qM373zfB8DXX7xrl+8CfvP2fheoK/429H9z9q+T
3zb+EGhq6meiOr43L7rW8Z8FoBbkW56Eh/11u4HOdL89gKE7+wJb0RtDC/ty
izBgP3QdlvgROc8P/KcD8GS3dTvQ5RfdVLnaBTgQVulBXOxf+8lviDC87vr+
aL/Hh9upp7mE+z1JBPjoDjBM4NovnupMr9rNFouOC/Ojm9iKXgakR5smODwz
+j1Z6fcO12t07PCXUNET9j8dwbfO+8UJfiK3tZZ9z1/0yy+vxSH1NfBghYge
u5HpJQIQMN+s45yy1EnknRPJN9MbRLGG8Goi5IJmkDHvgtSNJ+pdQWx9+A2/
PXv67KmhTiFUTzkk79N2N/br58+/fPaFfXsymXVXcgjp3bzlv0ey6j5B+sk3
r9/evX2jf5VCD3N/wAkgPkrk7ykHGaFQJ9nbK9BUNff4yoEY/pu27R7EjOXg
8ucBKjnkF1/dPH329fP4Tra2/1LGQ17DpVoa2dhxuer/AMaY1nTUSgAA
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7285.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7624.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8546.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8558.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8170.
xml"/>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
Note that our scripts did not find any words of concern.
--> -->
</references>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Many thanks to <contact fullname="Adrian Perrig"/>, <contact
fullname="Jean-Pierre Smith"/>, <contact fullname="Mirja Kühlewind"/>,
<contact fullname="Olivier Bonaventure"/>, <contact fullname="Martin
Thomson"/>, <contact fullname="Shwetha Bhandari"/>, <contact
fullname="Chris Wood"/>, <contact fullname="Lee Howard"/>, <contact
fullname="Mohamed Boucadair"/>, <contact fullname="Thorben Krüger"/>,
<contact fullname="Gorry Fairhurst"/>, <contact fullname="Spencer
Dawkins"/>, <contact fullname="Reese Enghardt"/>, <contact
fullname="Laurent Ciavaglia"/>, <contact fullname="Stephen Farrell"/>,
and <contact fullname="Richard Yang"/> for discussions leading to
questions in this document and for feedback on the document itself.</t>
<t>This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture for
a Middleboxed Internet (MAMI) and by the Swiss State Secretariat for
Education, Research, and Innovation under contract no. 15.0268. This
support does not imply endorsement.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 33 change blocks. 
621 lines changed or deleted 314 lines changed or added

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