PCE position in IoT
A Context-Aware PCE
PACE workshop, June, 2014
© 2014, CRAAX
2
Objectives
 Positioning the Path Computation Element (PCE) in
an Internet of Things (IoT) scenario.
 Describing the synergy between PCE, ID/LOC Split
Architectures (ILSAs).
 Introducing
the
Context-Aware PCE.
novel
concept
of
3
Methodology for a Context-Aware
PCE
 A PCE endpoint might be attached to an ID.
 The mapping between an ID to a locator(s) is
done according to a given context.
4
Challenges for a Context-Aware PCE
Enable interaction between a PCE and a
ILSA scheme
Enhance current PCEP in order to support
both context-information and IDs based
endpoints
Defining reconfigurable recovery actions
5
Context-Aware PCE
The driver of an IP/Optical connection
is not a location,…..
An interest, also called ”thing” (something that
a node can provide) motivates an
IP/Optical connection ,…
An interest is defined within a context
6
Context-Aware PCE
 The conventional model of host-oriented connections does not
fare well in multi-domain and large-scale network scenarios where
mobility features are enabled (mobility of both hosts and data).
Consider Cloud and OpenData environments using optical
transport technologies in order to cope their bandwidth-hungry
requirements.
 Network research community foresee in the coming years the
demise of host-oriented communication models. This is noticeable
by the recent studies already available related to new internet
architectures, many of them relying on a information-centric or
context-aware internet models [1].
 The aforementioned bullets motivated us to introduce the novel
concept of Context-Aware PCE.
7
Context-Aware PCE
 Contrary to a conventional PCE where endpoints of a
PCReq are location dependent, i.e., Host-Oriented PCE, in a
Context-Aware PCE
scenario endpoints are contextdependents. To this end, interaction between a PCE and an
ILSA scheme is required.
 The rationale behind ILSA schemes is to decouple the
application layer from endpoints location. This new
communication model is commonly known as informationcentric or context-aware networking
 This communication model can be adopted in PCE
scenarios by coupling PCReq endpoints to IDs.
8
Context-Aware PCE
 Path Computation Clients (PCCs ) similar to the application
layer are only interested to make a connection to a certain
endpoint or content no matter its location. The relevant in a
context-aware communication model is the “What”
(“connection to something”) rather than the “Where”
(“connection to a location”).
 The identity of an endpoint depends of some given context,
e.g., location, time, traffic volume, etc. Thus, a connection
holding time and the network recourses allocated to it might
vary according to the PCC interest.
 A context-aware PCE paves the way to traffic-oriented,
energy-oriented, resilient communications among others.
9
Context-Aware PCE
 In the use-cases presented in the slides 11-14 a PCReq end-point is
coupled to an ID. An ID is an abstract object that is not physically
attached to a device , e.g., Wavelength Router (WR) or IP/MPLS
router). An ID might represent a collection of devices with a
common feature, e.g., data repositories GIS providers WRs within a
Data Center.
 An ID is mapped to a locator (an address attached to a device),
according to a given context, e.g., trending topic measured at
different time-scales. The entity in charge of the mapping process is
an ILSA scheme.
 An PCEP object is enhanced with the parameters IDs and
Connection-Context.
10
Traffic-Oriented Communication
TED
Two cross-layer connection
associated to LSP A-B and one to
LSP-A-C. PCC’s policy is to
allocate more network resources
All cross-layer
to the current Treding-Topic
connections associated
to LSP A-C
ContextAware
PCE
•ID Data-Repo is mapped to a
locator belonging to the domain
related to the given context
(trending topic in this case)
Contextparameter:
restaurants
High volume of queries
related to keywords:
football match, Barcelona
vs. Madrid
Time 18:00
20:00
PCReq for LSP A-Data-Repo
Context-Aware
connections
PCReq-Update
Enhanced PCEP object
Source: Locator A.
Destination: ID Data-Repo
Connection-Context: TrendingTopic
Context-Parameter: Football
Bandwidth: ….
Metric: ….
Football match over,
queries related to
keywords: restaurant,
dinner, Barcelona
Optical PCE
VNTM
Traffic-Oriented Communication
TED
In this scenario, we skip the steps for setting-up
the LSPs. We intend to show a scenario in
which LSPs are established with trending-topic
as the Connection-Context. The ContextParameter is updated daily
Monday:
Saturday:
Increase
Decrease
number
number
of Transponders
of Transponders
associated
associated to
to this
this link
link
Monday: Decrease
Saturday:
Increase number of
Transponders associated to
this link
Context-Aware
connections
Optical PCE
Context-Aware
VNTM
PCE
Use-Case: Energy-Oriented Communication
TED
•ID GIS mapped to a locator
belonging to the GIS Provider
using the sun as its main
energy-source
Enhanced PCEP object
Source: Locator A.
Destination: ID GIS
Connection-Context: Energy
In this scenario, we do not show how theSource
ILSA
scheme knows which GIS provider (domainContext-Parameter:
1 or
Sun
2) is powered by sun-energy. A synchronization
Bandwidth:….
process might be required.
Metric: ….
PCReq for LSP A-GIS
Context-Aware
connection
ContextAware
PCE
Optical PCE
VNTM
Time 24:00
12:00
Time 24:00
12:00
PCReq-Update
13
Resilient Communication
In this scenario, router C is the
primary router and router B is a
backup
router.
No
Context
parameter is used. However, an ID is
used as an end-point.
TED
Optical PCE
ContextAware
PCE
VNTM
•Map ID (X) to locators
C, and B
Due to the failure on router B, a
protection action triggers the
provisioning of router D as the
backup router for router C
D
PCReq for both primary and backup LSP A-X
14
Context-Aware PCE
It is not unrealistic to assume a periodic and highly
dynamic behavior regarding trending-topics and
internet traffic, as shown on slides 11-12.
15
16
Context-Aware PCE
Notice that search topics regularly follow a periodic behavior. with a Period time= 7days. Data
extracted from [1].
Context-Aware PCE
The figure shown in this slide depicts the Queries distribution (daily) between June-September
(2013) in Barcelona (Relative Values), extracted from [2]. Certain search topics such as movie
theaters exhibit a drastic increase during weekends. The opposite occurs with search topics such
as banks) This drives us to encourage the practice of dynamical allocation of network resources
dedicated to a connection between an Information Asset Provider (IAP) such as a GIS provider
or a Data Repositories, and an Open Data Stakeholder ODS), e.g., the domain owner of a
OpenData Middleware).
The x axis is the accumulative for three
days of a month, i .e., Monday=Data
of three Mondays for June-September
17
Context-Aware Graph
 There is an increasing deployment of smart devices (sensors, open
data gathering servers, etc), coining the so-called Smart Cities –a
concept encompassed by the IoT. Consequently, City councils are
encouraging the developing of new internet applications that
exploit Smart City services.
 Upon the composition of a smart-service, i.e., a service that collects
information from several data sources, physical connectivity to the
data sources must be established. Traditionally, both service
composition and path computation have been two processes
independently from each other.
 Our intention is to combine Apps devoted to service composition
and a context-aware PCE scheme into a collaborative ecosystem,
where a context-aware PCE computes a path based on both the
context-aware Graph and Transport Network Graph.
18
Context-Aware Graph
Path Cost Improvement
 Increase the set of candidate paths for a given end-point pair.
 More candidate paths -> Higher reliability.
 Enable Interoperability between distinct network protocols, e.g.,
IPv4, IPv6.
 Evaluation with regard to the Path Cost Improvement have
been done assuming distributed source-based routing [3]. But
there is not any study assessing the Path Cost improvement in
centralized path computation architectures such as PCE.
20
Conventional Path Computation in a
multi-network protocol scenario
Only one candidate
path to destination
D.
Path Computation Improvement in a
multi-network protocol scenario
Dest:D,Label 2
Dest:3, Label 1
Three candidate paths to
destination D.
Dest :D,Label 2
Dest: D Label 2
ID D:
Mapped to
LOCs D or 3,