Challenges for the Internet Routing Infrastructure Introduced by Changes in Address Semantics
draft-king-irtf-challenges-in-routing-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Daniel King , Joanna Dang , Adrian Farrel | ||
| Last updated | 2021-02-11 | ||
| Replaced by | draft-king-rtgwg-challenges-in-routing | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-king-irtf-challenges-in-routing-00
IRTF D. King
Internet-Draft Lancaster University
Intended status: Informational J. Dang
Expires: August 15, 2021 Huawei Technologies
A. Farrel
Old Dog Consulting
February 11, 2021
Challenges for the Internet Routing Infrastructure Introduced by Changes
in Address Semantics
draft-king-irtf-challenges-in-routing-00
Abstract
Historically, the meaning of an IP address has been to identify an
interface on a network device. Routing protocols have been developed
based on the assumption that a destination address has this semantic.
Many proposals have been made to add semantics to IPv6 addresses.
These proposals may set the meaning of an address within the scope of
a limited domain, or suggest an address semantic that is meaningful
at specific points in the network (such as the source and
destination), but which can continue to be used without special
interpretation at transit points. Such proposals include providing
semantics specific to mobile networks, multicast traffic, different
device types, different underlying connectivity, hierarchical
connectivity, geographic location, application or network function
usage, or connectivity requirements.
Some new IP address semantics may have implications for how network
routing is performed. Some proposals might not be supported by
existing routing protocols and so would require changes. Other
proposals might enable advanced routing features or offer benefits in
scaling and management of routing systems.
This document presents a brief survey of technologies related to IP
address semantic proposals and describes the challenges to the
existing routing system that they present. It then summarises the
opportunities for research into new or modified routing protocols to
make use of new address semantics.
This document is presented as research to clarify and understand the
issues without directly proposing technical solutions that are ready
for productisation or deployment.
King, et al. Expires August 15, 2021 [Page 1]
Internet-Draft Routing Challenges February 2021
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Challenges to Current Internet Routing . . . . . . . . . . . 4
3. Network Path Selection . . . . . . . . . . . . . . . . . . . 6
3.1. Path Aware Routing . . . . . . . . . . . . . . . . . . . 7
4. What is Semantic Routing? . . . . . . . . . . . . . . . . . . 7
4.1. Semantic Prefix Domains . . . . . . . . . . . . . . . . . 9
5. Existing Approaches to Traffic Differentiation . . . . . . . 10
5.1. Deep Packet Inspection . . . . . . . . . . . . . . . . . 10
5.2. Differentiated Services . . . . . . . . . . . . . . . . . 11
5.3. Segment Routing . . . . . . . . . . . . . . . . . . . . . 11
5.4. Information-Centric Networking . . . . . . . . . . . . . 12
5.5. Locator/ID Separation Protocol (LISP) . . . . . . . . . . 13
5.6. Identifier-Locator Network Protocol . . . . . . . . . . . 13
5.7. Application-Layer Traffic Optimization . . . . . . . . . 13
King, et al. Expires August 15, 2021 [Page 2]
Internet-Draft Routing Challenges February 2021
5.8. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 14
5.9. Path Computation Element . . . . . . . . . . . . . . . . 14
5.10. Connectionless Network Protocol . . . . . . . . . . . . . 14
6. Overview of Current Routing Research Work . . . . . . . . . . 15
6.1. Clean Slate Approaches . . . . . . . . . . . . . . . . . 15
6.1.1. Recursive InterNetwork Architecture . . . . . . . . . 15
6.1.2. Scalability, Control, and Isolation on Next-
Generation Networks . . . . . . . . . . . . . . . . . 16
6.1.3. Expedited Internet Bypass Protocol . . . . . . . . . 16
6.2. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 17
6.3. Approaches that Modify Existing Routing Protocols . . . . 17
6.4. No Changes Needed . . . . . . . . . . . . . . . . . . . . 17
7. Challenges for Internet Routing Research . . . . . . . . . . 17
7.1. Routing Research Questions to be Addressed . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
The Internet continues to expand rapidly. At the same time, there
are increasingly varied classes and types of service. Some services
require a differentiated set traffic characteristics for successful
delivery and to guarantee user and application experience. This
places significant pressure on Service Providers to be aware of the
type of services being delivered, and to have access to detailed
information about how individual packets should be treated to meet
the user and application requirements.
Internet Protocol (IP) addressing facilitates how a device is
attached to the Internet and distinguished from every other device.
Addresses are used to direct packets to a destination (destination
address) and indicate to where replies should be sent (source
address). An IP address may be assigned to each device connected to
a network that uses IP. An IP address is used to both identify a
host and to indicate the location of the host.
The meaning of a unicast IPv6 address is defined as "An identifier
for a single interface." [RFC4291]. That document goes on to say,
"A packet sent to a unicast address is delivered to the interface
identified by that address."
Network routing protocols have been developed based on the assumption
that a destination address has this meaning. The protocols are
designed to determine paths through the network toward destination
King, et al. Expires August 15, 2021 [Page 3]
Internet-Draft Routing Challenges February 2021
addresses so that IP packets with a common destination address
converge on that destination.
This document presents a brief survey of proposals to extend the
semantics of IP addresses by assigning additional meanings to some
parts of the address, or by partitioning the address into a set of
subfields that give scoped addressing instructions. Some of these
proposals are intended to be deployed in limited domains (networks)
that are based on IP, while other proposals are intended for use
across the Internet. The impact the proposals have on the routing
system may require clean-slate solutions, hybrid solutions,
extensions to existing routing protocols, or potentially no changes
at all.
This document also presents some of the challenges to the existing
routing system that these changes in semantics may present. It then
summarises the existing research and opportunities for future
research into new or modified routing protocols to make use of new
address semantics.
This document draws on surveys and analysis already performed in "A
Survey of the Research on Future Internet Architectures"
[RESEARCHFIAref], and "ITU-T FG-NET2030 Architecture Framework"
[ITUNET2030ref], and work related to specific Internet technologies,
such as the Internet of Things (IOT) "Overview of Existing Routing
Protocols for Low Power and Lossy Networks" [IOTSURVEYref].
2. Challenges to Current Internet Routing
Today's Internet faces several significant challenges which are a
consequence of the architectural design decisions and exponential
growth. These challenges include mobility, multihoming, programmable
paths, and scalability, and were not the focus of the original design
of the Internet. Nevertheless, the Internet has, in general, coped
well in an incremental manner as each new challenge has evolved.
This list is presented to give context to the continuing requirements
that routing protocols must meet as new semantics are applied to IP
addresses.
Mobility - It is helpful to maintain an association between the
mobile station and its original IP address even after the mobile
node changes the network to which it is attached. This allows
continuity of services, but requires that the original network
must always be informed about the mobile nodes current location.
Multihoming - Multihomed stations or multihomed networks are
connected to the Internet via more than one access network and
therefore, may be assigned multiple IP addresses from different
King, et al. Expires August 15, 2021 [Page 4]
Internet-Draft Routing Challenges February 2021
pools of addresses. There are challenges concerning how traffic
is routed back to the source if the source has originated its
traffic using the wrong address for a particular connection, or if
one of the connections to the Internet is degraded.
Multi-path - The Internet was initially designed to find the
single, "best" path to a destination using a distributed routing
algorithm. The current Internet topology facilitates multiple
paths each with different characteristics and with different
failure likelihoods. It may be beneficial to send traffic over
multiple paths to achieve reliability and enhance throughput, and
it may be desirable to select one path or another in order to
provide delivery qualities or to avoid transiting specific areas
of the Internet. However, the way in which packets are routed
using the best or shortest path means that distinguishing these
alternate paths and directing traffic to them can be hard.
Further, problems concerning scalability, commercial agreements
among Service Providers, and the design of BGP make the
utilization of multi-path techniques difficult for inter-domain
routing.
Programmable paths - The ability to decouple Internet paths from
routing protocols and agreements between Service Providers, would
allow users and applications to configure and select Internet
paths themselves, based on required path (that is, traffic-
delivery) characteristics. Currently, user and application
packets follow the path selected by routing protocols and the way
traffic is routed through a network is under the exclusive control
of the Service Provider that owns the network.
Scalability - There are many scaling concerns that pose critical
challenges to the Internet. Not least among these challenges is
the size of the routing tables that routers in the Internet must
maintain and exchange with their peers. As the number of devices
attached to the Internet grows, so the number of addresses in use
also grows, and because of the address allocation schemes, the
mobility of devices, and the various connectivity options between
networks, the routing table sizes also grow and are not amenable
to aggregation. This problem exists even in limited domains (such
as IoT), where the size of the routing table - as more devices are
added to the network - may be a gating factor in ther
applicability of certain routing protocols.
The challenges outlined here were considered within the IETF by the
IABs "Routing and Addressing Workshop" held in Amsterdam, The
Netherlands on October 18-19, 2006 [RFC4984]. Several architectures
and protocols have since been developed and worked on within and
outside the IETF, and these are briefly examined in Section 5.
King, et al. Expires August 15, 2021 [Page 5]
Internet-Draft Routing Challenges February 2021
3. Network Path Selection
Two approaches are typically used for network path selection.
Firstly, a priori assessment by having the feasible paths and
constraints computed in advance. Secondly, real-time computation in
response to changing network conditions.
The first scenario may be conducted offline and allows for concurrent
or global optimization based on constraints and policy. As network
size and complexity increases, the required computing power may
increase exponentially.
The second approach must consider the speed of calculation. The
response processing may delay the service setup or the responsiveness
to changes (such as failures) in the network. Path selection filters
may be applied to reduce the complexity of the network data and the
computation algorithm, however, the path computation accuracy and
optimality may be negatively affected.
In both scenarios, the amount of information that needs to be
imported and processed can become very large (e.g., in large
networks, with many possible paths and route metrics), which might
impede the scalability of either method.
In the last decade, significant research has been conducted into the
architectural of the future Internet. During this research, several
techniques emerged, highlighting the benefits of path awareness and
path selection for end-hosts during this research, and multiple path-
aware network architectures have been proposed, including SCION and
RINA, and the work of the Path Aware Networking Research Gorup as
discussed later in this document.
When choosing the best paths or topology structures, the following
criteria may need to be considered:
o Method by which a path, or set of paths, is to be calculated. For
example, a path may be selected automatically by the routing
protocol or may imposed (perhaps for traffic engineering reasons)
by a central controller or management entity.
o Criteria used for selecting the best path. For example, classic
route preference, or administrative policies such as economic
costs, resilience, security, and if requested, applying
geopolitical considerations.
King, et al. Expires August 15, 2021 [Page 6]
Internet-Draft Routing Challenges February 2021
3.1. Path Aware Routing
The current Internet architecture is built using a best-effort
philosophy. There are techniques discussed in this document that
attempt better-than-best-effort delivery. The start-point and end-
point of a path are identified using IP addresses, but the path might
not run all the way from a packet's source to its destination. The
assumption is that a packet reaching the end of a path is forwarded
to its destination using best-effort techniques.
The IRTF's Path Aware Networking Research Group [PANRGref] aims to
support research in bringing path aware techniques into use in the
Internet. This research overlaps with many past and existing IETF
and IRTF efforts including multipath transport protocols, congestion
control in multiply-connected environments, and alternate routing
architectures.
4. What is Semantic Routing?
Networks are often divided into addressing regions for various
administrative or technological reasons. Different routing paradigms
may be applied in each region, and within a single region specific
"private" semantics may be applied to the IP addresses. This is not
new, but has been a pragmatic solution for achieving network function
in a limited domain (see Section 4.1).
These address semantics are established using customer types,
customer connections, topological constraints, performance groups,
and security, etc. Service Provides or network operators will apply
local policies to user and application packets as they enter the
network possibly mapping addresses or possibly encapsulating them
with an additional IP header. In some case, the packet has its
source and destination within a single network and the network
operator can apply address semantics policies across the whole
network. In other cases (such as general Internet traffic), a packet
will require a path across multiple networks, and each may apply its
own set of traffic forwarding policies. In these cases, there is
often no consistency or guaranteed performance unless a Service Level
Agreement (SLA) is applied to traffic traversing multiple networks.
Many proposals have been made to add semantics to IPv6 addresses
beyond the simple identification of the source and destination
[I-D.jia-scenarios-flexible-address-structure]. These proposals may
set the meaning of an address within the scope of a limited domain,
or suggest an address semantic that is meaningful at specific points
in the network. In this context, a "limited domain" means that the
interpretation of the address is only applicable to a well-defined
set of network nodes, and if a packet bearing an address with a
King, et al. Expires August 15, 2021 [Page 7]
Internet-Draft Routing Challenges February 2021
modified semantic were to escape from the domain, the special meaning
of the address would be lost. Additionally, the meaning of "specific
points in the network" is generally applied to the source and
destination nodes of a packet, while all transit nodes are unaware of
the special semantic, however it could be the case that some key
transit nodes are able to access the meaning of the address and so
apply special routing or other functions to the packet.
Such proposals include the following:
o Providing semantics specific to mobile networks so that a user or
device may move through the network without disruption to their
service [CONTENT-RTG-MOBILEref].
o Enabling optimized multicast traffic distribution by encoding
multicast tree and replication instructions within addresses
[MULTICAST-SRref].
o Using addresses to identify different device types so that their
traffic may be handled differently [SEMANTICRTG].
o Content-based routing (CBR), forwarding of the packet based on
message content rather than the destination addresses
[OPENSRNref].
o Deriving IP addresses from the physical layer identifiers and
using addresses depending on the underlying connectivity.
o Identifying hierarchical connectivity so that routing can be
simplified [EIBPref].
o Providing geographic location information within addresses
[GEO-IPref].
o Indicating the application or network function on a destination
device or at a specific location.
o Expressing how a packet should be handled, prioritised, or
allocated network resources as it is forwarded through the
network.
o Using cryptographic algorithms to mask the identity of the source
or destination, masking routing tables within the domain, while
still enabling packet forwarding across the network
[BLIND-FORWARDINGref].
In many cases, it may be argued that existing mechanisms applied on
top of the common address semantic defined in RFC 4291 can deliver
King, et al. Expires August 15, 2021 [Page 8]
Internet-Draft Routing Challenges February 2021
the correct functionality for these scenarios. That is, packets may
be tunneled over IP using a number of existing encapsulation
techniques. Nevertheless, there is pressure to reduce the amount of
encapsulation (partly to resist reduction in the maximum transmission
unit (MTU) over the network, and partly to achiever a flatter and
more transparent network architecture). This leads to investigations
into whether the current IP addresses can be "overloaded" (without
any negative connotations being attached to that word) by adding
semantics to the addresses.
Bringing new semantics to IP addresses may have implications for how
network routing is performed. Some proposals might not be supported
by existing routing protocols and so would require changes. Other
proposals might enable advanced routing features or offer benefits in
scaling and management of routing systems. The purpose of this
document is to coordinate research into the consequences for routing
of the various semantic addressing proposals, and to collect
references to research work on routing solutions.
Several technical challenges existing for semantic routing, these
include:
o Address consumption caused by lower address utility rate. The
wastage is mainly comes from aligning.
o Finite allocation for semantic address blocks.
o Encoding too many semantics into prefixes will require evaluation
of which to prioritise.
o Risk of privacy/information leakage.
o Burdening the user, application or prefix assignment node.
o Source address spoofing preventing mechanism may be required.
o Backwards compatibility with the existing Internet.
4.1. Semantic Prefix Domains
A semantic prefix domain [I-D.jiang-semantic-prefix] is a portion of
the Internet over which a consistent set of semantic-based policies
are administered in a coordinated fashion. Examples of semantic
prefix domains include:
o Administrative domains
o Applications
King, et al. Expires August 15, 2021 [Page 9]
Internet-Draft Routing Challenges February 2021
o Autonomous systems
o Hosts
o Network types
o Routers
o Trust regions
o User groups
A semantic prefix domain has a set of pre-established semantic
definitions which are only meaningful locally. Without an efficient
mechanism for notification, exchange, or configuration of semantics,
the definitions of semantics are only meaningful within the local
semantic prefix domain, and the addresses on a packet from within a
domain risk being misinterpreted by hosts and routers outside the
domain. While, sharing semantic definitions among semantic prefix
domains would enable wider semantic-based network function, such
approaches run the risk of complexity caused by overlapping
semantics, and require a significant trust model between network
operators. More successful approaches to multi-domain semantics
might be to rely either on backwards-compatible techniques or on
standardised semantics.
A semantic prefix domain may also span several physical networks and
traverse multiple service provider networks. However, when an
interim network is traversed (such as when an intermediary network is
used for interconnectivity) the relevance of the semantics is limited
to network domains that share a common semantic policy, and tunneling
may be needed to traverse transit domains.
5. Existing Approaches to Traffic Differentiation
Within the IETF, several existing approaches have been developed to
allow service providers to identify and mark IP traffic to enable
differentiated policy-based handling of the traffic by transit
routers (queuing, dropping, forwarding, etc.).
5.1. Deep Packet Inspection
Deep Packet Inspection (DPI) may be used by a router to learn the
characteristics of packets and so handle them differently. This
involves looking into the packet beyond the top-level network-layer
header to identify the payload. Once identified, the traffic type
can be used as an input for marking the packets for network handling,
or for performing specific policies on the packets.
King, et al. Expires August 15, 2021 [Page 10]
Internet-Draft Routing Challenges February 2021
However, DPI may be expensive both in processing costs and latency.
The processing costs means that dedicated infrastructure is necessary
to carry out the function and this may have an associated financial
cost. The latency incurred may be too much for use with any delay/
jitter sensitive applications. As a result, DPI is difficult for
large-scale deployment and its usage is often limited to specific
functions at the edge of the network.
5.2. Differentiated Services
Quality of Service (QoS) based on and Differentiated Services
[RFC2474] is a widely deployed framework specifying a simple and
scalable coarse-grained mechanism for classifying and managing
network traffic. However, in a service providers network, DiffServ
codepoint (DSCP) values cannot be trusted when they are set by the
customer, and may have different meanings as packets are passed
between networks.
In real-world scenarios, Service Providers deploy "remarking" points
at the edges of their network, re-classifying received packets by
rewriting the DSCP field according to local policy using information
such as the source/destination address, IP protocol number, transport
layer source/destination ports, and possibly applying DPI as
described in Section 5.1.
The traffic classification process and node-by-node processing leads
to increased packet processing overhead and complexity at the edge of
the Service Providers network.
5.3. Segment Routing
Segment Routing (SR) [RFC8402] leverages the source routing paradigm.
A node steers a packet through an ordered list of instructions,
called "segments". A segment can represent any instruction,
topological or service based. A segment can have a semantic local to
an SR node or global within an SR domain. SR provides a mechanism
that allows a flow to be restricted to a specific topological path,
while maintaining per-flow state only at the ingress node(s) to the
SR domain.
In SR for IPv6 networks (SRv6) segment routing functions are used to
achieve a networking objective that goes beyond packet routing, in
order to provide "network programming"
[I-D.ietf-spring-srv6-network-programming]. The network program is
expressed as a list of instructions, which are represented as 128-bit
segments, called Segment Identifiers (SID) - encoded and presented in
the form of an IPv6 address. The first instruction of the network
program is placed in the Destination Address field of the packet. If
King, et al. Expires August 15, 2021 [Page 11]
Internet-Draft Routing Challenges February 2021
the network program requires more than one instruction, the remaining
list of instructions is placed in the Segment Routing Extension
Header (SRH)[RFC8754].
An SRv6 instruction can represent any topological or service-based
instruction. The SRv6 domain is the service provider domain where
SRv6 services are built to transport any kind of customer traffic
including IPv4, IPv6, or frames. SRv6 is the instantiation of
Segment Routing deployed on the IPv6 data plane. Therefore, in order
to support SRv6, the network must first be enabled for IPv6.
For nodes forwarding traffic, the SRH in the IPv6 header is only
processed if the destination address identifies the local node. In
this case, the node must take several actions, including reading the
SRH, performing any node-specific actions identified by the
destination address or the next SIDs in the SRH, and re-writing the
IPv6 destination address field using information from the SRH before
forwarding the packet.
5.4. Information-Centric Networking
Information-Centric Networking (ICN) [ICNref] is an approach to
evolve the Internet infrastructure away from a host-centric paradigm,
based on perpetual connectivity and the end-to-end principle, to a
network architecture in which the focal point is information (or
content or data) that is assigned specific identifiers.
Several scenarios exist for semantic-based networking, providing
reachability based on Content Routing [CONTENTref] and Name Data
Networking [NDNref]. The technology area of ICN is now reaching
maturity, after many years of research and commercial investigation.
A technical discussion into the deployment and operation of ICNs
continues in the IETF: [RFC8763] provides several important
deployment considerations for facilitating ICN and practical
deployments.
More recently the concept of Hybrid-Information-Centric Networking
(hICN) has been introduced [HICNref]. In an hICN environment the ICN
aspect is integrated into the IPv6 architecture, reusing existing
IPv6 packet formats with the intention of maintaining compatibility
with existing and deployed IP network technology without creating
overlays that might require a new packet format or additional
encapsulations. The work is described in
[I-D.muscariello-intarea-hicn].
This document does not promote or endorse specific ICN solutions: we
focus on the potential routing challenges faced by these types of new
networks, and highlight key areas of research interest.
King, et al. Expires August 15, 2021 [Page 12]
Internet-Draft Routing Challenges February 2021
5.5. Locator/ID Separation Protocol (LISP)
The Locator/ID Separation Protocol (LISP) [RFC6830] was published by
the IETF as an Experimental RFC in 2013 and is now being moved to the
Standards Track [I-D.ietf-lisp-6834bis]. LISP separates IP addresses
into two numbering spaces: Endpoint Identifiers (EIDs) and Routing
Locators (RLOCs). IP packets addressed with EIDs are encapsulated
with RLOCs for routing and forwarding in the network.
LISP divides the address space into local edge networks and inter-
domain routers. Routers from edge ASes have interfaces that are
configured with RLOCs. Stations, on the other hand, are assigned an
EID, with a scope limited to their access networks. As end-to-end
packet forwarding includes both EIDs and RLOCs, a mapping system is
required. Multihoming becomes easier because one EID can be
associated to more than one RLOC or even to a local network address
prefix.
5.6. Identifier-Locator Network Protocol
The Identifier-Locator Network Protocol (ILNP) [RFC6740] is an
experimental network protocol designed to separate the two functions
of network addresses: identification of network endpoints, topology
or location information. Upon reaching the destination network, a
cache is used to find the corresponding node. Furthermore, DNS can
be dynamically updated, which is essential for mobility and also for
provider-independent addresses. Similar to LISP, multihoming can be
set by assigning multiple locators to the same identifier. In
addition, identifiers can also be encrypted for privacy reasons. It
was intended that ILNP should be backwards-compatible with existing
IP, and is incrementally-deployable.
5.7. Application-Layer Traffic Optimization
Application-Layer Traffic Optimization (ALTO) [RFC7285] is an
architecture and protocol. ALTO defines abstractions and services to
provide simplified network views and network services to guide the
application usage of network resources, including cost.
An ALTO server gathers information about the network and answers
queries from an ALTO client that wants to find a suitable path for
traffic. ALTO responses are typically used to route whole flows (not
individual packets) either to suitable destinations (such as network
functions) or onto paths that have specific qualities.
King, et al. Expires August 15, 2021 [Page 13]
Internet-Draft Routing Challenges February 2021
5.8. Multipath TCP
Multipath TCP (MPTCP) [RFC8684] enables the use of TCP in a multipath
network using multiple host addresses. A Multipath TCP connection
provides a bidirectional bytestream between two hosts communicating
like normal TCP and thus does not require any change to the
applications. However, Multipath TCP enables the hosts to use
different paths with different IP addresses to exchange packets
belonging to the MPTCP connection.
MPTCP it increases the available bandwidth, and so provides shorter
delays; it increases fault tolerance, by allowing the use of other
routes when one or more routes become unavailable; and it enables
traffic engineering and load balancing.
5.9. Path Computation Element
The Path Computation Element (PCE) [RFC4655] is an architecture and
protocol [RFC5440] that can be used to assist with network path
selection. A PCE is an entity capable of computing paths for a
single or set of services. A PCE might be a network node, network
management station, or dedicated computational platform that is
resource-aware and has the ability to consider multiple constraints
for sophisticated path computation. PCE applications compute label
switched paths for MPLS and GMPLS traffic engineering, but the PCE
has been extended for a variety of additional traffic engineering
problems.
5.10. Connectionless Network Protocol
The Connectionless Network Service (CLNP) [CLNPref] is a network
layer encoding that supports variable length, hierarchical
addressing. It is widely deployed in many communications networks
and is the ITU-T's standardised encoding for packets in the
management plane for Synchronous Digital Hierarchy (SDH) networks.
For a while, CLNP was considered in competition with IP as the
network layer encoding for the Internet, but IP (in conjunction with
TCP) won out.
Many of the considerations for semantic addressing can be handled
using CLNP, and it is particularly well suited to applications that
demand variable length addresses or that structure addresses
hierarchically for routing or geo-political reasons.
Routing for CLNP can be achieved using the IS-IS routing protocol in
its full form as documented in [ISISref] rather than its IP-only form
[RFC1195]. While this may make it possible to use CLNP alongside IP
in some routed networks, it does not integrate the use of IP
King, et al. Expires August 15, 2021 [Page 14]
Internet-Draft Routing Challenges February 2021
addresses with additional semantics with the historic use of IP
addresses except in "ships that pass in the night" fashion.
Alternatively, [RFC1069] explains how to carry regular IP addresses
in CLNP.
6. Overview of Current Routing Research Work
Several recent techniques for improving Internet routing have been
proposed, some of these are highlighted below.
6.1. Clean Slate Approaches
Incremental updates to the current Internet is seen as suboptimal and
an undesirable long-term solution. A clean slate redesign of inter-
domain routing would provide many benefits and could reuse existing
legacy routing protocols for intra-domain communication. The
following subsections outline current proposals for clean slate
inter-domain Internet routing.
6.1.1. Recursive InterNetwork Architecture
Recursive Inter Network Architecture (RINA) [RINAref] builds upon the
principle that applications communicate through Inter-process
Communication (IPC) facilities. For an application to communicate
through the distributed IPC facility, it only needs to know the name
of the destination application and to use the IPC interface to
request communication.
By leveraging IPC concepts RINA allows two processes to communicate,
IPC requires certain functions such as locating processes,
determining permission, passing information, scheduling, and managing
memory. Similarly, two applications on different end-hosts should
communicate by utilizing the services of a distributed IPC facility
(DIF). A DIF is an organizing structure, generally referred to as a
"layer".
The scope and functions provided by the different IPC facilities may
vary given the different type of network and performance goals.
Moreover, an IPC layer may recursively request services from other
IPC layers. The idea of recursively using multiple inter-process
communication services creates a multilayer structure repeated until
an IPC facility can fit well for physical technologies, e.g., wired
or wireless networks.
King, et al. Expires August 15, 2021 [Page 15]
Internet-Draft Routing Challenges February 2021
6.1.2. Scalability, Control, and Isolation on Next-Generation Networks
The SCION (Scalability, Control, and Isolation on Next-Generation
Networks) [SCIONref] inter-domain network architecture has been
designed to address security and scalability issues and provides an
alternative current Border Gateway Protocol (BGP) solutions. The
SCION proposal combines a globally distributed public key
infrastructure, a way to efficiently derive symmetric keys between
any network entities, and the forwarding approach of packet-carried
forwarding state.
SCION End-hosts fetch viable path segments from the path server
infrastructure, and construct the exact forwarding route themselves
by combining those path segments. The architecture ensures that a
variety of combinations among the path segments are feasible, while
cryptographic protections prevent unauthorized combinations or path-
segment alteration. The architecture further enables path
validation, providing per-packet verifiable guarantees on the path
traversed.
6.1.3. Expedited Internet Bypass Protocol
The Expedited Internet Bypass Protocol (EIBP) [EIBPref] is a clean
slate approach to routing and forwarding in the Internet using the
Internet infrastructure, but bypassing the Internet Protocol (IP).
The EIBP method may be deployed in current routers and when invoked
for a specific end to end IP hosts or networks, EIBP bypasses the
heavy traffic and security challenges faced at Layer-3. EIBP does
not require routing protocols, instead it abstracts network
structural (physical or logical) information into intelligent
forwarding addresses that are acquired by EIBP routers automatically.
The Forwarding tables used by EIBP are proportional to the
connectivity (degree) at a routing device making the protocol
scalable. The EIBP routing system does not require network-wide
dissemination. Topology change impacts are local and thus
instabilities on topology changes are minimal. EIBP is a low
configuration protocol, which can be deployed in an AS and extended
to multiple ASes independently. EIBP evaluations were conducted
using GENI testbeds and compared to IP using Open Shortest Path First
and Border Gateway Protocol. Significant performance improvements in
terms of convergence and churn rates highlight the capabilities of
EIBP.
King, et al. Expires August 15, 2021 [Page 16]
Internet-Draft Routing Challenges February 2021
6.2. Hybrid Approaches
Some research work is engaged in examining the emerging set of new
requirements that exceed the network and transport services of the
current Internet, which only delivers "best effort" service. This
work aims to determine what features can be built on top of existing
solutions by adding additional new components or features. A
starting point for this discussion can be found in
[I-D.bryant-arch-fwd-layer-ps].
6.3. Approaches that Modify Existing Routing Protocols
Some routing solutions to support semantic addressing may be possible
by applying small changes to existing routing protocols. These
modifications may be:
o Backward compatible with the pre-existing protocol enabling
insertion into existing networks.
o Compatible with forwarding existing IP packets enabling support of
legacy traffic.
o Applicable only to deployment within a limited domain
(Section 4.1).
6.4. No Changes Needed
It is entirely possible that some forms of modified address semantic
will work perfectly well with existing routing protocols and
mechanisms either across the whole Internet or within limited and
carefully controlled domains. Claims for this sort of functionality
need to be the subject of careful research and analysis as the
existing protocols were developed with a different view of the
meaning of IP addresses, and because routing systems are notoriously
fragile.
7. Challenges for Internet Routing Research
The techniques and architectures discussed in this document have
established very different strategies for semantic routing, and the
evolution of the Internet. The first being with incremental updates
and deployment, the second is based on clean slate proposals. If
applied to the Internet as a whole, the later strategy faces the
considerable challenge of how to drastically change the Internet with
minimal or no service disruption, while if applied to specific
controlled domains it raises the question of how nodes in those
domains can communicate across the Internet to nodes that are outside
the domain.
King, et al. Expires August 15, 2021 [Page 17]
Internet-Draft Routing Challenges February 2021
It may not be possible to embrace all emerging scenarios outlined in
this document with a single approach or solution. Requirements such
as 5G mobility, near-space-networking, and networking for outer-
space, may need to be handled using separate network technologies.
Therefore, developing a new Internet architecture that is both
economically feasible and which has the support of the networking
equipment vendors, is a significant challenge in the immediate future
of the Internet.
Improving Internet capabilities and capacity to scale, and address a
set of growing requirements presents significant research challenges,
and will require contributions from the networking research
community.
7.1. Routing Research Questions to be Addressed
As research into the scenarios and possible uses of semantic
addressing progresses, a number of questions need to be addressed in
the scope of routing. These questions go beyond "Why do we need this
function?" and "What could we achieve by carrying this additional
semantic in an IP address?" The questions are also distinct from
issues of how the additional semantics can be encoded within an IP
address. All of those issues are, of course, important
considerations in the debate about semantic addressing, but they form
part of the essential groundwork of research into semantic addressing
itself.
This section sets out some of the concerns about how the routing
system might be impacted by the use of semantic addressing. These
questions need to be addressed in separate research work or folded
into the discussion of each semantic addressing proposal.
1. What is the scope of the semantic address proposal? This
question may answered as:
* Global: It is intended to apply to all uses of IP addresses.
* Backbone: It is intended to apply to Internet connectivity.
* Overlay: It is to be used as an overlay network over previous
uses of IP or other underlay technologies using tunneling.
* Gateway: The semantic addressing will be used within a limited
domain, and communications with the wider internet will be
handled by a protocol or application gateway.
* Domain: The use of the semantic addressing is entirely limited
to within a domain or private network.
King, et al. Expires August 15, 2021 [Page 18]
Internet-Draft Routing Challenges February 2021
Underlying this issue is a broader question about the boundaries
of the use of IP, and the limit of "the Internet". If a limited
domain is used, is it a semantic prefix domain Section 4.1 where
a part of the IP address space identifies the domain so that an
address is routable to the domain but the additional semantics
are used only within the domain, or is the address used
exclusively within the domain so that the external impact of the
routability of the address that carries additional semantics is
not important?
2. What will be the impact on existing routing systems? What would
happen if an address with additional semantics was released
according to normal operations, accidentally, or maliciously?
How would the existing routing systems react? For example: how
are cryptographically generated addresses made routable; how are
the semantic parts of an address distinguished from the routable
parts; is there an impact on the size and maintenance of routing
tables due to the addition of semantics to addresses?
3. What path characteristics are needed for the routed paths? Since
one of the purposes of adding semantics to IP addresses is to
cause special processing by routers, it is important to
understand what behaviors are wanted. Such path characteristics
include (but are not limited to):
* Quality: expressed in terms of throughput, latency, jitter,
drop precedence, etc.
* Resilience: expressed in terms of survival of network failures
and delivery guarantees.
In these cases, how do the routing protocols utilise the address
semantics to determine the desired characteristics? What
additional information about the network does the protocol need
to gather? What changes to the routing algorithm is needed to
deliver packets according to the desired characteristics?
4. Can we solve these routing challenges with existing routing tools
and methods? We can break this question into more detailed
questions.
* Is new hardware needed? Existing deployed hardware has
certain assumptions about how forwarding is carried out based
on IP addresses and routing tables.
* Do we need new routing protocols? We might ask some
subsidiary questions:
King, et al. Expires August 15, 2021 [Page 19]
Internet-Draft Routing Challenges February 2021
+ Can we make do with existing protocols, possibly by tuning
configuration parameters or using them out of the box?
+ Can we make simple backward-compatible modifications to
existing protocols such that they work for today's IP
addresses as well as enhanced-semantic addresses?
+ Do we need entirely new protocols or radically evolutions
of existing protocols in order to deliver the functions
that we need?
+ Should we focus on the benefits of optimized routing
solutions, or should we attempt to generalize to enable
wider applicability?
Do we need new management tools and techniques? Management of
the routing system (especially diagnostic management) is a
crucial and often neglected part of the problem space.
5. What is the scalability impact for routing systems? Scalability
can be measured as:
* Routing table size. How many entries need to be maintained in
the routing table? Some approaches to semantic addressing may
be explicitly intended to address this problem.
* Routing performance. Routing performance may be considered in
terms of the volume of data that has to be exchanged both to
establish and to maintain the routing tables at the
participating routers. It may also be measured in terms of
how much processing is required to derive new routes when
there is a change in the network routing information.
* Routing convergence is the time that it takes for a routing
protocol to discover changes (especially faults) in the
network, to distribute the information about any changes to
the network, and to reach a stable state across the network
such that packets are routed consistently.
For all questions of routing scalability, research that presents
real numbers based on credible example networks is highly
desirable.
6. What aspects need to be standardised? It is really important to
understand the necessity of standardisaation within this
research. What degree of interoperability is expected between
devices and networks? Is the limited domain so constrained (for
example, to a single equipment vendor) that standardisation would
King, et al. Expires August 15, 2021 [Page 20]
Internet-Draft Routing Challenges February 2021
be meaningless? Is the application so narrow (for example, in
niche hardware environments) such that interoperability is best
handled by agreements among small groups of vendors such as in
industry consortia?
8. Security Considerations
TBD
This section should summarise the novel security issues raised for
routing by semantic routing. It does not need to cover all other
security considerations for semantic routing.
9. IANA Considerations
This document makes no requests for IANA action.
10. Acknowledgements
Thanks to Stewart Bryant for useful conversations.
This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 101015857 Secured autonomic traffic
management for a Tera of SDN flows (Teraflow).
11. Contributors
TBD
12. Informative References
[BLIND-FORWARDINGref]
Simsek, I., "On-Demand Blind Packet Forwarding",
Paper 30th International Telecommunication Networks and
Applications Conference (ITNAC), 2020, 2020,
<https://www.computer.org/csdl/proceedings-article/
itnac/2020/09315187/1qmfFPPggrC>.
[CLNPref] "Protocol for providing the connectionless-mode network
service: Protocol specification - Part 1",
standard ISO/IEC 8473-1:1998, 1998,
<https://www.iso.org/standard/30931.html>.
[CONTENT-RTG-MOBILEref]
Liu, H. and W. He, "Rich Semantic Content-oriented Routing
for mobile Ad Hoc Networks", Paper The International
Conference on Information Networking (ICOIN2014), 2014,
2014, <https://ieeexplore.ieee.org/document/6799682>.
King, et al. Expires August 15, 2021 [Page 21]
Internet-Draft Routing Challenges February 2021
[CONTENTref]
Choi, J., Han, J., and E. Cho, "A survey on content-
oriented networking for efficient content delivery",
Paper IEEE Communications Magazine, 49(3): 121-127, May
2011., 2011, <https://ieeexplore.ieee.org/
iel5/35/5723785/05723809.pdf>.
[EIBPref] Shenoy, N., "Can We Improve Internet Performance? An
Expedited Internet Bypass Protocol", Presentation 28th
IEEE International Conference on Network Protocols, 2020,
<https://icnp20.cs.ucr.edu/Slides/NIPAA/D-3_invited.pptx>.
[GEO-IPref]
Dasu, T., Kanza, Y., and D. Srivastava, "Geotagging IP
Packets for Location-Aware Software-Defined Networking in
the Presence of Virtual Network Functions", Paper 25th ACM
SIGSPATIAL International Conference on Advances in
Geographic Information Systems (ACM SIGSPATIAL 2017),
2017, <https://about.att.com/ecms/dam/sites/labs_research/
content/publications/
AI_Geotagging_IP_Packets_for_Location.pdf>.
[HICNref] Carofiglio, G., Muscariello, L., Auge, J., Papalini, M.,
Sardara, M., and A. Compagno, "Enabling ICN in the
Internet Protocol: Analysis and Evaluation of the Hybrid-
ICN Architecture", Paper Proceedings of the 6th ACM
Conference on Information-Centric Networking, 2019., 2019,
<https://www.researchgate.net/publication/336344520_Enabli
ng_ICN_in_the_Internet_Protocol_Analysis_and_Evaluation_of
_the_Hybrid-ICN_Architecture>.
[I-D.bryant-arch-fwd-layer-ps]
Bryant, S., Chunduri, U., Eckert, T., and A. Clemm,
"Forwarding Layer Problem Statement", draft-bryant-arch-
fwd-layer-ps-02 (work in progress), January 2021.
[I-D.ietf-lisp-6834bis]
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", draft-ietf-
lisp-6834bis-07 (work in progress), October 2020.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-28 (work in
progress), December 2020.
King, et al. Expires August 15, 2021 [Page 22]
Internet-Draft Routing Challenges February 2021
[I-D.jia-scenarios-flexible-address-structure]
Jia, Y., Li, G., and S. Jiang, "Scenarios for Flexible
Address Structure", draft-jia-scenarios-flexible-address-
structure-00 (work in progress), October 2020.
[I-D.jiang-semantic-prefix]
Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang,
"Analysis of Semantic Embedded IPv6 Address Schemas",
draft-jiang-semantic-prefix-06 (work in progress), July
2013.
[I-D.muscariello-intarea-hicn]
Muscariello, L., Carofiglio, G., Auge, J., Papalini, M.,
and M. Sardara, "Hybrid Information-Centric Networking",
draft-muscariello-intarea-hicn-04 (work in progress), May
2020.
[ICNref] Barbera, D., Xylomenos, G., Ververidis, C., Siris, V., and
N. Fotiou, "A Survey of information-centric networking
research", Paper IEEE Communications Surveys and
Tutorials, vol. 16, Iss. 2, Q2 2014, 2014,
<https://www.scopus.com/record/
display.uri?eid=2-s2.0-84901242669>.
[IOTSURVEYref]
Sheng, Z., Yang, S., Vasilakos, A., Mccann, J., and K.
Leung, "A Survey on the IETF Protocol Suite for the
Internet of Things: standards, challenges, and
opportunities", Paper IEEE Wireless Communications, vol.
20, no. 6, Dec 2013, 2014,
<https://ieeexplore.ieee.org/document/6704479>.
[ISISref] "Intermediate System to Intermediate System intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service", standard ISO/IEC
10589, 2002, <https://standards.iso.org/ittf/
PubliclyAvailableStandards/
c030932_ISO_IEC_10589_2002(E).zip>.
[ITUNET2030ref]
"Network 2030 Architecture Framework", Technical
Specification ITU-T Focus Group on Technologies for
Network 2030, 2020, <https://www.itu.int/en/ITU-
T/focusgroups/net2030/Documents/Network_2030_Architecture-
framework.pdf>.
King, et al. Expires August 15, 2021 [Page 23]
Internet-Draft Routing Challenges February 2021
[MULTICAST-SRref]
Jia, W. and W. He, "A Scalable Multicast Source Routing
Architecture for Data Center Networks", Paper IEEE
Journal on Selected Areas in Communications, vol. 32, no.
1, pp. 116-123, January 2014, 2014,
<https://ieeexplore.ieee.org/document/6799682>.
[NDNref] Zhang, L., Afanasyev, A., and J. Burke, "Named Data
Networking", Paper ACM SIGCOMM Computer Communication,
Review 44(3): 66-73, 2014, 2014.
[OPENSRNref]
Ren, P., Wang, X., Zhao, B., Wu, C., and H. Sun, "OpenSRN:
A Software-defined Semantic Routing Network Architecture",
Paper IEEE Conference on Computer Communications Workshops
(INFOCOM WKSHPS), Hong Kong, 2015, 2015,
<https://www.researchgate.net/
publication/308827498_OpenSRN_A_software-
defined_semantic_routing_network_architecture>.
[PANRGref]
"Path Aware Networking Research Group", RG Path Aware
Networking Research Group,
<https://datatracker.ietf.org/rg/panrg/about>.
[RESEARCHFIAref]
Pan, J., Paul, S., and R. Jain, "A Survey of the Research
on Future Internet Architectures", Paper IEEE
Communications Magazine, vol. 49, no. 7, July 2011, 2014,
<https://ieeexplore.ieee.org/document/5936152>.
[RFC1069] Callon, R. and H. Braun, "Guidelines for the use of
Internet-IP addresses in the ISO Connectionless-Mode
Network Protocol", RFC 1069, DOI 10.17487/RFC1069,
February 1989, <https://www.rfc-editor.org/info/rfc1069>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
King, et al. Expires August 15, 2021 [Page 24]
Internet-Draft Routing Challenges February 2021
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740,
DOI 10.17487/RFC6740, November 2012,
<https://www.rfc-editor.org/info/rfc6740>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>.
King, et al. Expires August 15, 2021 [Page 25]
Internet-Draft Routing Challenges February 2021
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
"Deployment Considerations for Information-Centric
Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April
2020, <https://www.rfc-editor.org/info/rfc8763>.
[RINAref] Day, J., "Patterns in Network Architecture: A Return to
Fundamentals", Book Prentice Hall, 2008.
[SCIONref]
Barbera, D., Chaut, L., Perrig, A., Reischuk, R., and P.
Szalachowski, "Patterns in Network Architecture: A Return
to Fundamentals", Paper The ACM, vol. 60, no. 6, June
2017, 2017,
<https://icnp20.cs.ucr.edu/Slides/NIPAA/D-3_invited.pptx>.
[SEMANTICRTG]
Strassner, J., Sung-Su, K., and J. Won-Ki, "Semantic
Routing for Improved Network Management in the Future
Internet", Book Chapter Springer, Recent Trends in
Wireless and Mobile Networks, 2010, 2010,
<https://link.springer.com/
chapter/10.1007/978-3-642-14171-3_14>.
Authors' Addresses
Daniel King
Lancaster University
Email: d.king@lancaster.ac.uk
Joanna Dang
Huawei Technologies
Email: dangjuanna@huawei.com
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
King, et al. Expires August 15, 2021 [Page 26]