< draft-mcbride-edge-data-discovery-overview-02.txt   draft-mcbride-edge-data-discovery-overview-03.txt >
COINRG M. McBride COINRG M. McBride
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Standards Track D. Kutscher Intended status: Standards Track D. Kutscher
Expires: January 8, 2020 Emden University Expires: August 1, 2020 Emden University
E. Schooler E. Schooler
Intel Intel
CJ. Bernardos CJ. Bernardos
UC3M UC3M
July 07, 2019 January 29, 2020
Edge Data Discovery for COIN Edge Data Discovery for COIN
draft-mcbride-edge-data-discovery-overview-02 draft-mcbride-edge-data-discovery-overview-03
Abstract Abstract
This document describes the problem of distributed data discovery in This document describes the problem of distributed data discovery in
edge computing, and in particular for computing-in-the-network edge computing, and in particular for computing-in-the-network
(COIN), which may require both the marshalling of data at the outset (COIN), both the marshalling of data at the outset of a computation
of a computation and the persistence of the resultant data after the and the persistence of the resultant data after the computation.
computation. Although the data might originate at the network edge, Although the data might originate at the network edge, as more and
as more and more distributed data is created, processed, and stored, more distributed data is created, processed, and stored, it becomes
it becomes increasingly dispersed throughout the network. There increasingly dispersed throughout the network. There needs to be a
needs to be a standard way to find it. New and existing protocols standard way to find it. New and existing protocols will need to be
will need to be developed to support distributed data discovery at developed to support distributed data discovery at the network edge
the network edge and beyond. and beyond.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 8, 2020. This Internet-Draft will expire on August 1, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Edge Data . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Edge Data . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Edge Data Discovery Problem Scope . . . . . . . . . . . . . . 4 2. Edge Data Discovery Problem Scope . . . . . . . . . . . . . . 4
2.1. A Cloud-Edge Continuum . . . . . . . . . . . . . . . . . 5 2.1. A Cloud-Edge Continuum . . . . . . . . . . . . . . . . . 5
2.2. Types of Edge Data . . . . . . . . . . . . . . . . . . . 6 2.2. Types of Edge Data . . . . . . . . . . . . . . . . . . . 6
3. Scenarios Requiring Discovery of Edge Data Resources . . . . 7 2.2.1. Example Meta Data . . . . . . . . . . . . . . . . . . 7
4. Edge Data Discovery . . . . . . . . . . . . . . . . . . . . . 7 3. Scenarios for Discovering Edge Data Resources . . . . . . . . 8
4.1. Types of Discovery . . . . . . . . . . . . . . . . . . . 7 4. Edge Data Discovery . . . . . . . . . . . . . . . . . . . . . 9
4.2. Naming the Data . . . . . . . . . . . . . . . . . . . . . 8 4.1. Types of Discovery . . . . . . . . . . . . . . . . . . . 9
5. Use Cases of edge data discovery . . . . . . . . . . . . . . 9 4.2. Naming the Data . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Use Cases of edge data discovery . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Edge computing is an architectural shift that migrates Cloud Edge computing is an architectural shift that migrates Cloud
functionality (compute, storage, networking, control, data functionality (compute, storage, networking, control, data
management, etc.) out of the back-end data center to be more management, etc.) out of the back-end data center to be more
proximate to the IoT data being generated and analyzed at the edges proximate to the IoT data being generated and analyzed at the edges
of the network. Edge computing provides local compute, storage and of the network. Edge computing provides local compute, storage and
connectivity services, often required for latency- and bandwidth- connectivity services, often required for latency- and bandwidth-
sensitive applications. Thus, Edge Computing plays a key role in sensitive applications. Thus, Edge Computing plays a key role in
skipping to change at page 4, line 16 skipping to change at page 4, line 19
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.4. Terminology 1.4. Terminology
o Edge: The edge encompasses all entities not in the back-end cloud. o Edge: The edge encompasses all entities not in the back-end cloud.
The device edge represents the very leaves of the network and The device edge is the boundary between digital and physical
encompasses the entities found in the last mile network. Sensors, entities in the last mile network. Sensors, gateways, compute
gateways, compute nodes are included. Because the things that nodes are included. The infrastructure edge includes equipment on
populate the IoT can be both physical and/or cyber, in some the network operator side of the last mile network including cell
solutions, particularly in software-defined or digital-twin
contexts, the device edge can include logical (vs physical)
entities. The infrastructure edge includes equipment on the
network operator side of the last mile network including cell
towers, edge data centers, cable headends, POPs, etc. See towers, edge data centers, cable headends, POPs, etc. See
Figure 1 for other possible tiers of edge clouds between the Figure 1 for other possible tiers of edge clouds between the
device edge and the back-end cloud data center. device edge and the back-end cloud data center.
o Edge Computing: Distributed computation that is performed near the o Edge Computing: Distributed computation that is performed near the
network edge, where nearness is determined by the system network edge, where nearness is determined by the system
requirements. This includes high performance compute, storage and requirements. This includes high performance compute, storage and
network equipment on either the device or infrastructure edge. network equipment on either the device or infrastructure edge.
o Edge Data Discovery: The process of finding required data from o Edge Data Discovery: The process of finding required data from
edge entities, i.e., from databases, files systems, device memory edge entities, i.e., from databases, files systems, device memory
that might be physically distributed in the network, and that might be physically distributed in the network, and providing
consolidating it by providing access to it logically as if it were access to it logically as if it were a single unified source,
a single unified source, perhaps through its namespace, that can perhaps through its namespace, that can be evaluated or searched.
be evaluated or searched.
o ICN: Information Centric Networking. An ICN-enabled network o ICN: Information Centric Networking. An ICN-enabled network
routes data by name (vs address), caches content natively in the routes data by name (vs address), caches content natively in the
network, and employs data-centric security. Data discovery may network, and employs data-centric security. Data discovery may
require that data be associated with a name or names, a series of require that data be associated with a name or names, a series of
descriptive attributes, and/or a unique identifier. descriptive attributes, and/or a unique identifier.
2. Edge Data Discovery Problem Scope 2. Edge Data Discovery Problem Scope
Our focus is on how to define and scope the edge data discovery Our focus is on how to define and scope the edge data discovery
problem. This requires some discussion of the evolving definition of problem. This requires some discussion of the evolving definition of
the edge as part of a cloud-to-edge continuum and in turn what is the edge as part of a cloud-to-edge continuum and in turn what is
meant by edge data as well as the meta-data surrounding the edge meant by edge data as well as the meta-data about edge data.
data.
2.1. A Cloud-Edge Continuum 2.1. A Cloud-Edge Continuum
Although Edge Computing data typically originates at edge devices, Although Edge Computing data typically originates at edge devices,
there is nothing that precludes edge data from being created anywhere there is nothing that precludes edge data from being created anywhere
in the cloud-to-edge computing continuum (Figure 1). New edge data in the cloud-to-edge computing continuum (Figure 1). New edge data
may result as a byproduct of computation being performed on the data may result as a byproduct of computation being performed on the data
stream anywhere along its path in the network. For stream anywhere along its path in the network. For
example,infrastructure edges may create new edge data when multiple example,infrastructure edges may create new edge data when multiple
data streams converge upon this aggregation point and require data streams converge upon this aggregation point and require
skipping to change at page 7, line 10 skipping to change at page 7, line 10
often sequestored within the Edge where it was created. A goal of often sequestored within the Edge where it was created. A goal of
this discussion is to consider the prospect that different types of this discussion is to consider the prospect that different types of
edge data will be made accessible across disparate edges, for example edge data will be made accessible across disparate edges, for example
to enable richer multi-modal analytics. But this will happen only if to enable richer multi-modal analytics. But this will happen only if
data can be described, searched and discovered across heterogeneous data can be described, searched and discovered across heterogeneous
edges in a standard way. Having a mechanism to enable granular edge edges in a standard way. Having a mechanism to enable granular edge
data discovery is the problem that needs solving either with existing data discovery is the problem that needs solving either with existing
or new protocols. The mechanisms shouldn't care to which flavor or new protocols. The mechanisms shouldn't care to which flavor
cloud or edge the request for data discovery is made. cloud or edge the request for data discovery is made.
3. Scenarios Requiring Discovery of Edge Data Resources 2.2.1. Example Meta Data
SFC Data and meta-data discovery
Service function chaining (SFC) allows the instantiation of an
ordered set of service functions and subsequent "steering" of traffic
through them. Service functions provide a specific treatment of
received packets, therefore they need to be known so they can be used
in a given service composition via SFC. So far, how the SFs are
discovered and composed has been out of the scope of discussions in
IETF. While there are some mechanisms that can be used and/or
extended to provide this functionality, work needs to be done. An
example of this can be found in [I-D.bernardos-sfc-discovery].
In an SFC environment deployed at the edge, the discovery protocol
may also need to make available the following meta-data information
per SF:
o Service Function Type, identifying the category of SF provided.
o SFC-aware: Yes/No. Indicates if the SF is SFC-aware.
o Route Distinguisher (RD): IP address indicating the location of
the SF(I).
o Pricing/costs details.
o Migration capabilities of the SF: whether a given function can be
moved to another provider (potentially including information about
compatible providers topologically close).
o Mobility of the device hosting the SF, with e.g. the following
sub-options:
Level: no, low, high; or a corresponding scale (e.g., 1 to 10).
Current geographical area (e.g., GPS coordinates, post code).
Target moving area (e.g., GPS coordinates, post code).
o Power source of the device hosting the SF, with e.g. the following
sub-options:
Battery: Yes/No. If Yes, the following sub-options could be
defined:
Capacity of the battery (e.g., mmWh).
Charge status (e.g., %).
Lifetime (e.g., minutes).
Discovery of resources in an NFV environment: virtualized resources
do not need to be limited to those available in traditional data
centers, where the infrastructure is stable, static, typically
homogeneous and managed by a single admin entity. Computational
capabilities are becoming more and more ubiquitous, with terminal
devices getting extremely powerful, as well as other types of devices
that are close to the end users at the edge (e.g., vehicular onboard
devices for infotainment, micro data centers deployed at the edge,
etc.). It is envisioned that these devices would be able to offer
storage, computing and networking resources to nearby network
infrastructure, devices and things (the fog paradigm). These
resources can be used to host functions, for example to offload/
complement other resources available at traditional data centers, but
also to reduce the end-to- end latency or to provide access to
specialized information (e.g., context available at the edge) or
hardware. Similar to the discovery of functions, while there are
mechanisms that can be reused/extended, there is no complete solution
yet defined. An example of work in this area is
[I-D.bernardos-intarea-vim-discovery]."
3. Scenarios for Discovering Edge Data Resources
1. A set of data resources appears (e.g., a mobile node hosting data 1. A set of data resources appears (e.g., a mobile node hosting data
joins a network) and they want to be discovered by an existing joins a network) and they want to be discovered by an existing
but possibly virtualized and/or ephemeral data directory but possibly virtualized and/or ephemeral data directory
infrastructure. infrastructure.
2. A device wants to discover data resources available at or near 2. A device wants to discover data resources available at or near
its current location. As some of these resources may be mobile, its current location. As some of these resources may be mobile,
the available set of edge data may vary over time. the available set of edge data may vary over time.
3. A device wants to discover to where best in the edge 3. A device wants to discover to where best in the edge
infrastructure to opportunistically upload its data, for example infrastructure to opportunistically upload its data, for example
if a mobile device wants to offload its data to the if a mobile device wants to offload its data to the
infrastructure (for greater data availability, battery savings, infrastructure (for greater data availability, battery savings,
etc.). etc.)
4. Edge Data Discovery 4. Edge Data Discovery
How can we discover data on the edge and make use of it? There are How can we discover data on the edge and make use of it? There are
proprietary implementations that collect data from various databases proprietary implementations that collect data from various databases
and consolidate it for evaluation. We need a standard protocol set and consolidate it for evaluation. We need a standard protocol set
for doing this data discovery, on the device or infrastructure edge, for doing this data discovery, on the device or infrastructure edge,
in order to meet the requirements of many use cases. We will have in order to meet the requirements of many use cases. We will have
terabytes of data on the edge and need a way to identify its terabytes of data on the edge and need a way to identify its
existence and find the desired data. A user requires the need to existence and find the desired data. A user requires the need to
skipping to change at page 8, line 17 skipping to change at page 9, line 43
to discovery one another. to discovery one another.
Discovery of link state and traffic engineering data/services by Discovery of link state and traffic engineering data/services by
external devices. BGP-LS is one solution. external devices. BGP-LS is one solution.
The question is if one or more of these protocols might be a suitable The question is if one or more of these protocols might be a suitable
contender to extend to support edge data discovery? contender to extend to support edge data discovery?
4.2. Naming the Data 4.2. Naming the Data
Information-Centric Networking (ICN) RFC 7927 [RFC7927] is a class of Named Data Networking (NDN) is one of five research projects funded
architectures and protocols that provide "access to named data" as a by the U.S. National Science Foundation under its Future Internet
first-order network service. Instead of host-to-host communication Architecture Program. NDN has its roots in an earlier project,
as in IP networks, ICNs often use location-independent names to Content-Centric Networking (CCN), which Van Jacobson started at Xerox
identify data objects, and the network provides the services of PARC around the time of his Google talk, to turn his architecture
processing (answering) requests for named data with the objective to vision into a running prototype (see also his CoNEXT 2009 paper and
finally deliver the requested data objects to a requesting consumer. especially Jacobsons ACM Queue interview). The motivation is the
mis-match of todays Internet architecture and its usage. Today we
Such an approach has profound effects on various aspects of a build, support, and use Internet applications and services on top of
networking system, including security (by enabling object-based an extremely capable architecture not designed to support them. What
security on a message/packet level), forwarding behavior (name-based if we had an architecture designed to support them? Specifically,
forwarding, caching), but also on more operational aspects such as todays IP packets can name only endpoints of conversations (IP
bootstrapping, discovery etc. addresses) at the network layer. What if we generalize this layer to
name any information (or content), not just endpoints? We make it
The CCNx and NDN (https://named-data.net) variants of ICN are based easier to develop, manage, secure, and use our networks. NDN can be
on a request/response abstraction where consumers (hosts, application applied to edge data discovery to make it much easier to extract data
requesting named data) send INTEREST messages into the network that and meta-data by naming it. If data was named we would be able to
are forwarded by network elements to a destination that can provide discover the appropriate data simply by its name.
the requested named data object. Corresponding responses are sent as
so-called DATA messages that follow the reverse INTEREST path.
Each unique data object is named unambiguously in a hierarchical
naming scheme and is authenticated through Public-Key cryptography
(data objects can also optionally be encrypted in different ways).
The naming concept and the object-based security approach lay the
foundation for location independent operation. The network can
generally operate without any notion of location, and nodes
(consumers, forwarders) can forward requests for named data objects
directly, i.e., without any additional address resolution. Location
independence also enables additional features, for example the
possibility to replicate and cache named data objects. On-patch
caching is a standard feature in many ICN systems -- typically for
enhancing reliability and performance.
In CCNx and NDN, forwarders are stateful, i.e., they keep track of
forwarded INTEREST to later match the received DATA messages.
Stateful forwarding (in conjunction with the general named-based and
location-independent operation) also empowers forwarders to execute
individual forwarding strategies and perform optimizations such as
in-network retransmissions, multicasting requests (in cases there are
several opportunities for accessing a particular named data object)
etc.
Naming data and application-specific naming conventions are naturally
important aspects in ICN. It is common that applications define
their own naming convention (i.e., semantics of elements in the name
hierarchy). Such names can often directly derived from application
requirements, for example a name like /my-home/living-
room/light/switch/main could be relevant in a smart home setting, and
corresponding devices and application could use a corresponding
convention to facilitate controllers finding sensors and actors in
such a system with minimal user configuration.
The aforementioned features make ICN amenable to data discovery.
Because there is no name/address chasm as in IP-based systems, data
can be discovered by sending INTEREST to named data objects directly
(assuming a naming convention as described above). Moreover, ICN can
authenticate received data objects directly, for example using local
trust anchors in the network (for example in a home network).
Advanced ICN features for data discovery include the concept of
manifests in CCNx, i.e., ICN objects that describe data collections,
and data set synchronization protocols in NDN (https://named-
data.net/publications/li2018sync-intro/) that can inform consumers
about the availability of new data in a tree-based data structure
(with automatic retrieval and authentication). Also, ICN is not
limited to accessing static data. Frameworks such as Named Function
Networking (http://www.named-function.net) and RICE can provide the
general ICN feature for discovery not only for data but also for name
functions (for in-network computing) and for their results.
5. Use Cases of edge data discovery 5. Use Cases of edge data discovery
1. Autonomous Vehicles 1. Autonomous Vehicles
Autonomous vehicles rely on the processing of huge amounts of complex Autonomous vehicles rely on the processing of huge amounts of complex
data in real-time for fast and accurate decisions. These vehicles data in real-time for fast and accurate decisions. These vehicles
will rely on high performance compute, storage and network resources will rely on high performance compute, storage and network resources
to process the volumes of data they produce in a low latency way. to process the volumes of data they produce in a low latency way.
Various systems will need a standard way to discover the pertinent Various systems will need a standard way to discover the pertinent
skipping to change at page 10, line 4 skipping to change at page 10, line 25
1. Autonomous Vehicles 1. Autonomous Vehicles
Autonomous vehicles rely on the processing of huge amounts of complex Autonomous vehicles rely on the processing of huge amounts of complex
data in real-time for fast and accurate decisions. These vehicles data in real-time for fast and accurate decisions. These vehicles
will rely on high performance compute, storage and network resources will rely on high performance compute, storage and network resources
to process the volumes of data they produce in a low latency way. to process the volumes of data they produce in a low latency way.
Various systems will need a standard way to discover the pertinent Various systems will need a standard way to discover the pertinent
data for decision making data for decision making
2. Video Surveillance 2. Video Surveillance
The majority of the video surveillance footage will remain at the The majority of the video surveillance footage will remain at the
edge infrastructure (not sent to the cloud data center). This edge infrastructure (not sent to the cloud data center). This
footage is coming from vehicles, factories, hotels, universities, footage is coming from vehicles, factories, hotels, universities,
farms, etc.Much of the video footage will not be interesting to those farms, etc.Much of the video footage will not be interesting to those
evaluating the data. A mechanism, set of protocols perhaps, is evaluating the data. A mechanism, set of protocols perhaps, is
needed to identify the interesting data at the edge. What needed to identify the interesting data at the edge. What
constitutes interesting will be context specific, e.g., video frames constitutes interesting will be context specific, e.g., video frames
with a car in it, a backyard nocturnal creature in it, a person or with a car in it, a backyard nocturnal creature in it, a person or
bicyclist or etc. Interesting video data may be stored longer in bicyclist or etc. Interesting video data may be stored longer in
storage systems at the very edge of the network or in flight in storage systems at the very edge of the network or in flight in
networking equipment further away from the device edge. networking equipment further away from the device edge.
3. Elevator Networks 3. Elevator Networks
Elevators are one of many industrial applications of edge computing. Elevators are one of many industrial applications of edge computing.
Edge equipment receives data from 100's of elevator sensors. The Edge equipment receives data from 100's of elevator sensors. The
data coming into the edge equipment is vibration, temperature, speed, data coming into the edge equipment is vibration, temperature, speed,
level, video, etc. We need the ability to identify where the data we level, video, etc. We need the ability to identify where the data we
need to evalute is located. need to evalute is located.
4. Service Function Chaining
Service function chaining (SFC) allows the instantiation of an
ordered set of service functions and the subsequent "steering" of
traffic through them. Service functions provide a specific treatment
of received packets, therefore they need to be known so they can be
used in a given service composition via SFC. So far, how the SFs are
discovered and composed has been out of the scope of discussions in
IETF. While there are some mechanisms that can be used and/or
extended to provide this functionality, work needs to be done. An
example of this can be found in [I-D.bernardos-sfc-discovery].
In an SFC environment deployed at the edge, the discovery protocol
may also need the following kind of meta-data information per SF:
o Service Function Type, identifying the category of SF provided.
o SFC-aware: Yes/No. Indicates if the SF is SFC-aware.
o Route Distinguisher (RD): IP address indicating the location of
the SF(I).
o Pricing/costs details.
o Migration capabilities of the SF: whether a given function can be
moved to another provider (potentially including information about
compatible providers topologically close).
o Mobility of the device hosting the SF, with e.g. the following
sub-options:
Level: no, low, high; or a corresponding scale (e.g., 1 to 10).
Current geographical area (e.g., GPS coordinates, post code).
Target moving area (e.g., GPS coordinates, post code).
o Power source of the device hosting the SF, with e.g. the following
sub-options:
Battery: Yes/No. If Yes, the following sub-options could be
defined:
Capacity of the battery (e.g., mmWh).
Charge status (e.g., %).
Lifetime (e.g., minutes).
Discovery of resources in an NFV environment: virtualized resources
do not need to be limited to those available in traditional data
centers, where the infrastructure is stable, static, typically
homogeneous and managed by a single admin entity. Computational
capabilities are becoming more and more ubiquitous, with terminal
devices getting extremely powerful, as well as other types of devices
that are close to the end users at the edge (e.g., vehicular onboard
devices for infotainment, micro data centers deployed at the edge,
etc.). It is envisioned that these devices would be able to offer
storage, computing and networking resources to nearby network
infrastructure, devices and things (the fog paradigm). These
resources can be used to host functions, for example to offload/
complement other resources available at traditional data centers, but
also to reduce the end-to-end latency or to provide access to
specialized information (e.g., context available at the edge) or
hardware. Similar to the discovery of functions, while there are
mechanisms that can be reused/extended, there is no complete solution
yet defined. An example of work in this area is
[I-D.bernardos-intarea-vim-discovery]." The availability of this
meta-data about the capabilities of nearby physical as well as
virtualized resources can be made discoverable through edge data
discovery mechanisms.
6. IANA Considerations 6. IANA Considerations
N/A N/A
7. Security Considerations 7. Security Considerations
Security considerations will be a critical component of edge data Security considerations will be a critical component of edge data
discovery particularly as intelligence is moved to the extreme edge discovery particularly as intelligence is moved to the extreme edge
where data is to be extracted. where data is to be extracted.
8. Acknowledgement 8. Acknowledgement
The co-authors thank Dave Oran for his detailed feedback on an
earlier version of this draft.
9. Normative References 9. Normative References
[I-D.bernardos-intarea-vim-discovery] [I-D.bernardos-intarea-vim-discovery]
Bernardos, C. and A. Mourad, "IPv6-based discovery and Bernardos, C. and A. Mourad, "IPv6-based discovery and
association of Virtualization Infrastructure Manager (VIM) association of Virtualization Infrastructure Manager (VIM)
and Network Function Virtualization Orchestrator (NFVO)", and Network Function Virtualization Orchestrator (NFVO)",
draft-bernardos-intarea-vim-discovery-01 (work in draft-bernardos-intarea-vim-discovery-02 (work in
progress), February 2019. progress), August 2019.
[I-D.bernardos-sfc-discovery] [I-D.bernardos-sfc-discovery]
Bernardos, C. and A. Mourad, "Service Function discovery Bernardos, C. and A. Mourad, "Service Function discovery
in fog environments", draft-bernardos-sfc-discovery-02 in fog environments", draft-bernardos-sfc-discovery-03
(work in progress), March 2019. (work in progress), September 2019.
[I-D.irtf-icnrg-ccnxmessages]
Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
Format", draft-irtf-icnrg-ccnxmessages-09 (work in
progress), January 2019.
[I-D.irtf-icnrg-ccnxsemantics]
Mosko, M., Solis, I., and C. Wood, "CCNx Semantics",
draft-irtf-icnrg-ccnxsemantics-10 (work in progress),
January 2019.
[I-D.kutscher-icnrg-rice]
Krol, M., Habak, K., Oran, D., Kutscher, D., and I.
Psaras, "Remote Method Invocation in ICN", draft-kutscher-
icnrg-rice-00 (work in progress), October 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
"Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>.
Authors' Addresses Authors' Addresses
Mike McBride Mike McBride
Futurewei Futurewei
Email: michael.mcbride@futurewei.com Email: michael.mcbride@futurewei.com
Dirk Kutscher Dirk Kutscher
Emden University Emden University
Email: ietf@dkutscher.net Email: ietf@dkutscher.net
Eve Schooler Eve Schooler
Intel Intel
Email: eve.m.schooler@intel.com Email: eve.m.schooler@intel.com
URI: http://www.eveschooler.com URI: http://www.eveschooler.com
Carlos J. Bernardos Carlos J. Bernardos
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30 Av. Universidad, 30
Leganes, Madrid 28911 Leganes, Madrid 28911
Spain Spain
Phone: +34 91624 6236 Phone: +34 91624 6236
Email: cjbc@it.uc3m.es Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/ URI: http://www.it.uc3m.es/cjbc/
 End of changes. 20 change blocks. 
212 lines changed or deleted 130 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/