-
Notifications
You must be signed in to change notification settings - Fork 2
Home
Theresa Enghardt edited this page Feb 12, 2020
·
8 revisions
This wiki lists existing IETF/IRTF work that defines paths, path elements, path properties, or other terms used in the Path Properties draft.
- "A Unified Approach to Inter-Domain Routing" (RFC 1322)
- Path: domains (or confederations) traversed so far, sequence of routing domains, carried in a special path attribute (basically an AS path)
- BGP-4 (RFC 4271)
- AS: set of routers under a single technical administration, using an IGP and common metrics to determine how to route packets within — or at least appears so to the outside
- Path = AS_PATH: information reported in Path Attribute field of an UPDATE message. sequence of AS path segments. each AS path segment is a triple (path segment type, path segment length, path segment value. value is AS number.)
- Advertisement of Multiple Paths in BGP (RFC 7911)
- (RFC4271 allows advertising only one path for a particular prefix — here they introduce a Path Identifier which can be used to advertise multiple paths for the same address prefix without replacing, using ADD PATH)
- Path Computation Element (PCE) (RFC 4655)
- PCE: computes a network path or route based on network graph and apply computational constraints (defined in RFC 4655)
- (fundamental building block for traffic engineering in MPLS and GMPLS)
- (applicable in intra-domain, inter-domain, inter-layer)
- domain: collection of network elements within a common sphere of address management or path computation responsibility, can be IGP areas, ASes, multiple ASes within a Service provider network. may also exist as sub-domains of areas or ASes.
- explicit path: list of strict hops from start to destination
- strict/loose path: mix of strict and loose hops comprising at least one loose hop representing the destination, a hop may be an abstract node such as an AS
- (strict and loose are never defined)
- → Path: sequence of hops that a packet may traverse (implicit)
- "The path computation request may include a significant set of requirements, including the following: […] the number of disjoint paths required and whether near-disjoint paths are acceptable" -- but what is near-disjoint is never defined
- Path Computation Element (PCE) Communication Protocol (PCEP) - (RFC 5440)
- Explicit path: list of strict hops where a hop may be an abstract node such as an AS
- Analysis of Inter-Domain Label Switched Path (LSP) Recovery (RFC 5298)
- Diversity: See RFC4726. Diversity means the relationship of multiple LSPs, where those LSPs do not share some specific type of resource (e.g., link, node, or shared risk link group (SRLG)). Diversity is also referred to as disjointness.
- Segment Routing Architecture (RFC 8402)
- segment: an instruction a node executes on an incoming packet (e.g., forward packet according to shortest path to destination, forward through specific interface, deliver packet to given application)
- does not define path. but talks about "path computed using the routing algorithm", can be expressed as a single IGP segment or multiple
- RSVP (RFC 2205)
- implicitly defines a path via Figures. Perhaps a sequence of nodes.
- Flow: "session" = data flow with particular destination and transport-layer protocol. defined as dest-address, protocolID, dest-port (optional)
- RSVP Proxy Approaches (RFC 5945)
- On-path: located on the data path of the actual flow of application data ... implicitly defines path, again.
- Flow: TODO
- RSVP-TE: Extensions to RSVP for LSP Tunnels (RFC 3209)
- EXPLICIT_ROUTE object (ERO): "An explicit route is a particular path in the network topology. Typically, the explicit route is determined by a node, with the intent of directing traffic along that path."
- "An explicit route is described as a list of groups of nodes along the explicit route. In addition to the ability to identify specific nodes along the path, an explicit route can identify a group of nodes that must be traversed along the path."
- ERO subobject content can essentially be an IPv4 prefix, an IPv6 prefix, or an AS number.
- strict subobject: "The path between a strict node and its preceding node MUST include only network nodes from the strict node and its preceding abstract node."
- loose subobject: "The path between a loose node and its preceding node MAY include other network nodes that are not part of the strict node or its preceding abstract node."
- Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) (RFC 7570): Adds generic attributes to EROs
- Service Function Chaining (SFC) Architecture (RFC 7665):
- Service Function (SF): "A function that is responsible for specific treatment of received packets. A Service Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a service function can be realized as a virtual element or be embedded in a physical network element. One or more Service Functions can be embedded in the same network element. Multiple occurrences of the service function can exist in the same administrative domain."
- Service Function Chain (SFC): "A service function chain defines an ordered set of abstract service functions and ordering constraints that must be applied to packets and/or frames and/or flows selected as a result of classification. An example of an abstract service function is "a firewall". The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term "service chain" is often used as shorthand for service function chain."
- Service Function Path (SFP): "The service function path is a constrained specification of where packets assigned to a certain service function path must go. While it may be so constrained as to identify the exact locations, it can also be less specific. The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of abstract service functions to be delivered, and the fully specified notion of exactly which SFF/SFs the packet will visit when it actually traverses the network. By allowing the control components to specify this level of indirection, the operator may control the degree of SFF/SF selection authority that is delegated to the network."
- Framework for IP Performance Metrics (RFC 2330)
- Host: computer capable of communicating using IP, includes routers
- Router: host which facilitates network-level communication between hosts by forwarding IP packets
- Link: link-level connection between two or more hosts
- Path: sequence of hosts - link - router - link - [router - link -]* - host.
- Subpath: subsequence of a given path which is itself a path.
- Metrics: quantities related to performance and reliability of the Internet
- (also defines cloud, exchange, path digest, but those do not seem relevant to us??)
- (also defines how metrics can be measured, estimated, and composed)
- route metric: path from A to B at a given time
- (define propagation time and bandwidth based on bits, not on packets)
- (also defines standard-formed packet as a minimal IP packet)
- "Type-P": metric's value depends on the type of packet involved in the metric. e.g., "IP-type-P-connectivity" and/or "IP-port-HTTP-connectivity"
- Advanced Unidirectional Route Assessment (AURA) (draft-ietf-ippm-route)
- specifies new route metric (based on RFC2330) — "identify path taken by a packet or flow traversing the Internet between two hosts"
- Host Identity: unique address for host, e.g., globally routable IP address(es) of the same host
- (Discoverable and cooperating host)
- Hop: Host identity, optionally arrival and/or departure interface ID, RTT, arrival timestamp
- → this should be able to express as a path property later. or a set of properties.
TODO: Find all Path properties that are essentially IPPM metrics and reference them
- "TCP Performance Implications of Network Path Asymmetry" (RFC 3449)
- implicitly defines a path
- normative ref to Path MTU Discovery, so maybe they use this definition? but it's RFC 1191 and this one does not have an explicit definition of a path either.
- (RFC 3481) (2.5G/3G networks) does the same
- MPTCP (RFC 6824)
- Path: Sequence of links between sender and receiver, defined by a 4-tuple of src/dst addr/port
- subflow: flow of TCP segments over an individual path
- host: end host operating an MPTCP implementation
- ALTO protocol (RFC 7285)
- Protocol to publish information about network topology and costs of sending packets
- Endpoint which wants to access a resource, e.g., a file, can choose between different endpoints based on this information
- Information:
- Network map: endpoints denoted by addresses; grouping of network endpoints (which are close to each other) as Provider-Defined Identifier (PID), which can be a subnet, a POP, a metropolitan area, an AS, etc
- Cost map: defined pairwise between source/destination network locations (PIDs), e.g., routing costs
- Endpoint properties: defined with types and values, e.g., the PID
- (endpoint costs)
- Path: Implicitly defined as source-destination endpoint pair, to which a path cost applies
- ALTO Extension: Path Vector (draft-ietf-alto-path-vector)
- Abstract network elements (ANEs): basically path elements
- Path vector: array of ANEs traversed from source to destination: basically a path
- Properties of abstract ANEs: basically path properties. E.g., maximum reserved bandwidth, persistent entities that are contained by an ANE
- ALTO Performance Cost Metrics (draft-ietf-alto-performance-metrics)
- Defines ALTO cost metrics that are not routing costs, but related to network performance on a path
- Metrics defined: One Way Delay, RoundTrip Time, Packet Delay Variation, Hop Count, Packet Loss, Throughput, Link Maximum Reservable Bandwidth, Link Residue Bandwidth
- Unified Properties for the ALTO Protocol (draft-ietf-alto-unified-props-new)
- generalizes "endpoint properties" of RFC 7285 to generic entities to which properties can apply
- ALTO entity: generic entity, can be a PID, a network element, a cell in a cellular network, an abstracted network element as defined in Path Vector extension, or a TCP/IP network flow that has a server defined identifier consisting of the defining TCP/IP 5-Tuple
- Entity property: similar to endpoint property. Note that objects may be both entities and properties.
- Entity domain: a set of entities of same type, defines identity semantics and format, e.g., "ipv4", "pid"
- Path MTU Discovery for IP version 6 (RFC 8201) (uses same terminology as IPv6 (RFC 8200) but has more terms!)
- node: device that implements IPv6
- router: node that forwards IPv6 packets not explicitly addressed to itself
- host: node that is not a router
- upper layer: protocol layer immediately above IPv6
- link: communication facility or medium over which nodes can communicate at the link layer. can also be a tunnel
- interface: node's attachment to a link
- packet: IPv6 header plus payload. size less than or equal to Path MTU
- path: set of links traversed by a packet between source node and destination node
- flow: sequence of packets sent from a particular source to a particular (unicast or multicast) destination, for which the source requires special handling by intervening routers
- flow ID: combination of source address and non-zero flow label
- Packetization Layer Path MTU Discovery (RFC 4821)
- node: device that implements IP (either v4 or v6)
- otherwise follows RFC 8201
- Flow: context in which MTU Discovery algorithms can be invoked. e.g. an instance of a packetization protocol, for example, one side of a TCP connection.
- packetization layer: Layer of network stack that segments data into packets
-
Requirements for Internet Hosts -- Communication Layers (RFC 1122)
- Host: ultimate consumer of communication services. A host generally executes application programs on behalf of user(s), employing network and/or Internet communication services in support of this function.
-
IAB: Transport Protocol Path Signals (RFC 8558)
- no explicit definitions, but seems to be close to what we mean
- "path between two nodes setting up the transport connection"
- "on-path network elements"
-
Security Area: Delegated Path Validation and Delegated Path Discovery Protocol Requirements (RFC 3379) — PKIX Working Group
- Certification Path: Chain of multiple certificates
- Here, Path appears to mean something completely unrelated to what we mean
-
Applications: XML Path Language (RFC 5261)
- Here, Path appears to mean something completely unrelated to what we mean
-
Applications: Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts (RFC 3327)
- defines an extension header field named "Path"
- unclear if this is related to what we mean
Administrative Domains and Routing Domains A Model for Routing in the Internet
Path MTU Discovery RFC1191
IPPM link capacity RFC5136
IPPM link usage RFC5136
IPPM one-way delay RFC7679
IPPM RTT RFC2681
IPPM one-way delay variation RFC3393
IPPM one-way loss RFC7680
IPPM round-trip loss RFC6673
IPPM one-way loss pattern RFC3357
IPPM one-way loss episode RFC6534