< draft-irtf-panrg-path-properties-03.txt   draft-irtf-panrg-path-properties-04.txt >
PANRG T. Enghardt PANRG T. Enghardt
Internet-Draft Netflix Internet-Draft Netflix
Intended status: Informational C. Kraehenbuehl Intended status: Informational C. Kraehenbuehl
Expires: January 10, 2022 ETH Zuerich Expires: 28 April 2022 ETH Zuerich
July 09, 2021 25 October 2021
A Vocabulary of Path Properties A Vocabulary of Path Properties
draft-irtf-panrg-path-properties-03 draft-irtf-panrg-path-properties-04
Abstract Abstract
Path properties express information about paths across a network and Path properties express information about paths across a network and
the services provided via such paths. In a path-aware network, path the services provided via such paths. In a path-aware network, path
properties may be fully or partially available to entities such as properties may be fully or partially available to entities such as
hosts. This document defines and categorizes path properties. hosts. This document defines and categorizes path properties.
Furthermore, the document specifies several path properties which Furthermore, the document specifies several path properties which
might be useful to hosts or other entities, e.g., for selecting might be useful to hosts or other entities, e.g., for selecting
between paths or for invoking some of the provided services. between paths or for invoking some of the provided services.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 10, 2022. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology usage for specific technologies . . . . . . . 5 2.1. Terminology usage for specific technologies . . . . . . . 5
3. Use Cases for Path Properties . . . . . . . . . . . . . . . . 5 3. Use Cases for Path Properties . . . . . . . . . . . . . . . . 5
3.1. Path Selection . . . . . . . . . . . . . . . . . . . . . 5 3.1. Path Selection . . . . . . . . . . . . . . . . . . . . . 6
3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 6 3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 7
3.3. Service Invocation . . . . . . . . . . . . . . . . . . . 7 3.3. Service Invocation . . . . . . . . . . . . . . . . . . . 7
4. Examples of Path Properties . . . . . . . . . . . . . . . . . 7 4. Examples of Path Properties . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . 10 7. Informative References . . . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The current Internet architecture does not explicitly support The current Internet architecture does not explicitly support
endpoint discovery of forwarding paths through the network as well as endpoint discovery of forwarding paths through the network as well as
the discovery of properties and services associated with these paths. the discovery of properties and services associated with these paths.
Path-aware networking, as defined in Section 1.1 of Path-aware networking, as defined in Section 1.1 of
[I-D.irtf-panrg-questions], describes "endpoint discovery of the [I-D.irtf-panrg-questions], describes "endpoint discovery of the
properties of paths they use for communication across an properties of paths they use for communication across an
internetwork, and endpoint reaction to these properties that affects internetwork, and endpoint reaction to these properties that affects
skipping to change at page 3, line 8 skipping to change at page 3, line 13
useful for the mentioned use cases. useful for the mentioned use cases.
Note that this document does not assume that any of the listed path Note that this document does not assume that any of the listed path
properties are actually available to any entity. The question of how properties are actually available to any entity. The question of how
entities can discover and distribute path properties in a trustworthy entities can discover and distribute path properties in a trustworthy
way is out of scope for this document. way is out of scope for this document.
2. Terminology 2. Terminology
Entity: A physical or virtual device or function, or a collection of Entity: A physical or virtual device or function, or a collection of
devices or functions, which can, for example, process packets, devices or functions, which plays a role related to path-aware
measure path properties, or access information about paths. With networking for particular paths and flows. An entity can be on-
respect to a given communication, an entity may be on the data path or off-path: On the path, an entity may participate in
plane or control plane, and it may be on-path or off-path. forwarding the flow, i.e., what may be called data plane
functionality. On or off the path, an entity may influence
aspects of how the flow is forwarded, i.e., what may be called
control plane functionality, such as Path Selection or Service
Invocation. An entity influencing forwarding aspects is usually
aware of path properties, e.g., by observing or measuring them or
by learning them from another entity.
Node: An entity which processes packets, e.g., sends, receives, Node: An on-path entity which processes packets, e.g., sends,
forwards, or modifies them. A node may be physical or virtual, receives, forwards, or modifies them. A node may be physical or
e.g., a physical device, a service function provided as a virtual virtual, e.g., a physical device, a service function provided as a
element, or even a single queue within a switch. A node may also virtual element, or even a single queue within a switch. A node
be an entity which consists of a collection of devices or may also be an entity which consists of a collection of devices or
functions, e.g., an entire Autonomous System (AS). functions, e.g., an entire Autonomous System (AS).
Host: A node that generally executes application programs on behalf Host: A node that generally executes application programs on behalf
of user(s), employing network and/or Internet communication of user(s), employing network and/or Internet communication
services in support of this function, as defined in [RFC1122]. services in support of this function, as defined in [RFC1122].
Note that hosts include both client nodes (e.g., running a web Note that hosts include both client nodes (e.g., running a web
browser) and server nodes (e.g., running a web server). browser) and server nodes (e.g., running a web server).
Link: A medium or communication facility that connects two or more Link: A medium or communication facility that connects two or more
nodes with each other. A link enables a node to send packets to nodes with each other. A link enables a node to send packets to
skipping to change at page 8, line 19 skipping to change at page 8, line 42
specific flow across a network to which one or multiple path specific flow across a network to which one or multiple path
elements belong. elements belong.
Service function: A service function that a path element applies to Service function: A service function that a path element applies to
a flow, see [RFC7665]. Examples of abstract service functions a flow, see [RFC7665]. Examples of abstract service functions
include firewalls, Network Address Translation (NAT), and TCP include firewalls, Network Address Translation (NAT), and TCP
optimizers. Some stateful service functions, such as NAT, need to optimizers. Some stateful service functions, such as NAT, need to
observe the same flow in both directions, e.g., by being an observe the same flow in both directions, e.g., by being an
element of both the path and the reverse path. element of both the path and the reverse path.
Transparency: When a node performs an action on a flow, the node is Transparency: When a node performs an action A on a flow F, the node
transparent to the flow with respect to some (meta-)information if is transparent to F with respect to some (meta-)information M if
the node performs this action independently of the given the node performs A independently of M. M can for example be the
(meta-)information. (Meta-)information can for example be the
existence of a protocol (header) in a packet or the content of a existence of a protocol (header) in a packet or the content of a
protocol header, payload, or both. Actions can for example be protocol header, payload, or both. A can for example be blocking
blocking packets or reading and modifying (other protocol) headers packets or reading and modifying (other protocol) headers or
or payloads. An IP router could be transparent to transport payloads. Transparency can be modeled using a function f, which
protocol headers such as TCP/UDP but not transparent to IP headers takes as input F and M and outputs the action taken by the node.
since its forwarding behavior depends on the IP headers. A If a taint analysis shows that the output of f is not tainted
firewall that only allows outgoing TCP connections by blocking all (impacted) by M or if the output of f is constant for arbitrary
incoming TCP SYN packets regardless of their IP address is values of M, then the node is considered to be transparent. An IP
transparent to IP but not to TCP headers. Finally, a NAT that router could be transparent to transport protocol headers such as
actively modifies IP and TCP/UDP headers based on their content is TCP/UDP but not transparent to IP headers since its forwarding
not transparent to either IP or TCP/UDP headers. Note that behavior depends on the IP headers. A firewall that only allows
according to this definition, a node that modifies packets in outgoing TCP connections by blocking all incoming TCP SYN packets
accordance with the hosts, such as a transparent HTTP proxy, as regardless of their IP address is transparent to IP but not to TCP
defined in [RFC2616], and a node listening and reacting to headers. Finally, a NAT that actively modifies IP and TCP/UDP
implicit or explicit signals, see [RFC8558], are not considered headers based on their content is not transparent to either IP or
transparent. TCP/UDP headers. Note that according to this definition, a node
that modifies packets in accordance with the hosts, such as a
transparent HTTP proxy, as defined in [RFC2616], and a node
listening and reacting to implicit or explicit signals, see
[RFC8558], are not considered transparent.
Administrative Domain: The administrative domain, e.g., the IGP Administrative Domain: The administrative domain, e.g., the IGP
area, AS, or Service provider network to which a path element area, AS, or Service provider network to which a path element
belongs. belongs.
Disjointness: For a set of two paths or subpaths, the number of Disjointness: For a set of two paths or subpaths, the number of
shared path elements can be a measure of intersection (e.g., shared path elements can be a measure of intersection (e.g.,
Jaccard coefficient, which is the number of shared elements Jaccard coefficient, which is the number of shared elements
divided by the total number of elements). Conversely, the number divided by the total number of elements). Conversely, the number
of non-shared path elements can be a measure of disjointness of non-shared path elements can be a measure of disjointness
skipping to change at page 10, line 20 skipping to change at page 10, line 46
One-Way Packet Loss: Packets sent by a node but not received by One-Way Packet Loss: Packets sent by a node but not received by
another node on the same path after a certain time interval are another node on the same path after a certain time interval are
considered lost. This property is analogous to the one-way loss considered lost. This property is analogous to the one-way loss
defined in [RFC7680] but not restricted to IP-layer traffic. defined in [RFC7680] but not restricted to IP-layer traffic.
Metrics such as loss patterns [RFC3357] and loss episodes Metrics such as loss patterns [RFC3357] and loss episodes
[RFC6534] can be expressed as aggregated properties. [RFC6534] can be expressed as aggregated properties.
5. Security Considerations 5. Security Considerations
If nodes are basing policy or path selection decisions on path If entities are basing policy or path selection decisions on path
properties, they need to rely on the accuracy of path properties that properties, they need to rely on the accuracy of path properties that
other devices communicate to them. In order to be able to trust such other devices communicate to them. In order to be able to trust such
path properties, nodes may need to establish a trust relationship or path properties, entities may need to establish a trust relationship
be able to verify the authenticity, integrity, and correctness of or be able to verify the authenticity, integrity, and correctness of
path properties received from another node. path properties received from another entity.
Security related properties such as confidentiality and integrity Security related properties such as confidentiality and integrity
protection of payloads are difficult to characterize since they are protection of payloads are difficult to characterize since they are
only meaningful with respect to a threat model which depends on the only meaningful with respect to a threat model which depends on the
use case, application, environment, and other factors. Likewise, use case, application, environment, and other factors. Likewise,
properties for trust relations between nodes cannot be meaningfully properties for trust relations between entities cannot be
defined without a concrete threat model, and defining a threat model meaningfully defined without a concrete threat model, and defining a
is out of scope for this draft. Properties related to threat model is out of scope for this draft. Properties related to
confidentiality, integrity, and trust are orthogonal to the path confidentiality, integrity, and trust are orthogonal to the path
terminology and path properties defined in this document. Such terminology and path properties defined in this document. Such
properties are tied to the communicating nodes and the protocols they properties are tied to the communicating nodes and the protocols they
use (e.g., client and server using HTTPS, or client and remote use (e.g., client and server using HTTPS, or client and remote
network node using VPN) while the path is typically oblivious to network node using VPN) while the path is typically oblivious to
them. Intuitively, the path describes what function the network them. Intuitively, the path describes what function the network
applies to packets, while confidentiality, integrity, and trust applies to packets, while confidentiality, integrity, and trust
describe what function the communicating parties apply to packets. describe what function the communicating parties apply to packets.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Informative References 7. Informative References
[I-D.ietf-alto-path-vector] [I-D.ietf-alto-path-vector]
Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J. Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J.
Zhang, "ALTO Extension: Path Vector", draft-ietf-alto- Zhang, "ALTO Extension: Path Vector", Work in Progress,
path-vector-14 (work in progress), February 2021. Internet-Draft, draft-ietf-alto-path-vector-18, 18 October
2021, <https://www.ietf.org/archive/id/draft-ietf-alto-
path-vector-18.txt>.
[I-D.ietf-alto-performance-metrics] [I-D.ietf-alto-performance-metrics]
Wu, Q., Yang, Y. R., Lee, Y., Dhody, D., Randriamasy, S., Wu, Q., Yang, Y. R., Lee, Y., Dhody, D., Randriamasy, S.,
and L. M. Contreras, "ALTO Performance Cost Metrics", and L. M. C. Murillo, "ALTO Performance Cost Metrics",
draft-ietf-alto-performance-metrics-15 (work in progress), Work in Progress, Internet-Draft, draft-ietf-alto-
February 2021. performance-metrics-19, 23 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-alto-
performance-metrics-19.txt>.
[I-D.ietf-idr-performance-routing] [I-D.ietf-idr-performance-routing]
Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C.
Jacquenet, "Performance-based BGP Routing Mechanism", Jacquenet, "Performance-based BGP Routing Mechanism", Work
draft-ietf-idr-performance-routing-03 (work in progress), in Progress, Internet-Draft, draft-ietf-idr-performance-
December 2020. routing-03, 22 December 2020,
<https://www.ietf.org/archive/id/draft-ietf-idr-
performance-routing-03.txt>.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-34 (work and Secure Transport", Work in Progress, Internet-Draft,
in progress), January 2021. draft-ietf-quic-transport-34, 14 January 2021,
<https://www.ietf.org/archive/id/draft-ietf-quic-
transport-34.txt>.
[I-D.ietf-tcpm-converters] [I-D.ietf-tcpm-converters]
Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S.,
and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- and B. Hesmans, "0-RTT TCP Convert Protocol", Work in
tcpm-converters-19 (work in progress), March 2020. Progress, Internet-Draft, draft-ietf-tcpm-converters-19,
22 March 2020, <https://www.ietf.org/archive/id/draft-
ietf-tcpm-converters-19.txt>.
[I-D.irtf-panrg-questions] [I-D.irtf-panrg-questions]
Trammell, B., "Current Open Questions in Path Aware Trammell, B., "Current Open Questions in Path Aware
Networking", draft-irtf-panrg-questions-09 (work in Networking", Work in Progress, Internet-Draft, draft-irtf-
progress), April 2021. panrg-questions-10, 11 October 2021,
<https://www.ietf.org/archive/id/draft-irtf-panrg-
questions-10.txt>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
Zappala, "Source Demand Routing: Packet Format and Zappala, "Source Demand Routing: Packet Format and
Forwarding Specification (Version 1)", RFC 1940, Forwarding Specification (Version 1)", RFC 1940,
DOI 10.17487/RFC1940, May 1996, DOI 10.17487/RFC1940, May 1996,
 End of changes. 20 change blocks. 
66 lines changed or deleted 86 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/