< draft-purkayastha-sfc-service-indirection-01.txt   draft-purkayastha-sfc-service-indirection-02.txt >
Network Working Group D. Purkayastha Network Working Group D. Purkayastha
Internet-Draft A. Rahman Internet-Draft A. Rahman
Intended status: Informational D. Trossen Intended status: Informational D. Trossen
Expires: April 30, 2018 InterDigital Communications, LLC Expires: September 2, 2018 InterDigital Communications, LLC
Z. Despotovic Z. Despotovic
R. Khalili R. Khalili
Huawei Huawei
October 27, 2017 March 1, 2018
Alternative Handling of Dynamic Chaining and Service Indirection Alternative Handling of Dynamic Chaining and Service Indirection
draft-purkayastha-sfc-service-indirection-01 draft-purkayastha-sfc-service-indirection-02
Abstract Abstract
Many stringent requirements are imposed on today's network, such as Many stringent requirements are imposed on today's network, such as
low latency, high availability and reliability in order to support low latency, high availability and reliability in order to support
several use cases such as IoT, Gaming, Content distribution, Robotics several use cases such as IoT, Gaming, Content distribution, Robotics
etc. Networks need to be flexible and dynamic in terms of allocation etc. Networks need to be flexible and dynamic in terms of allocation
of services and resources. Network Operators should be able to of services and resources. Network Operators should be able to
reconfigure the composition of a service and steer users towards new reconfigure the composition of a service and steer users towards new
service end points as users move or resource availability changes. service end points as user move or resource availability changes.
SFC allows network operators to easily create and reconfigure service SFC allows network operators to easily create and reconfigure service
function chains dynamically in response to changing network function chains dynamically in response to changing network
requirements. We discuss a use case where Service Function Chain can requirements. We discuss a use case where Service Function Chain can
adapt or self-organize as demanded by the network condition without adapt or self-organize as demanded by the network condition without
requiring SPI re-classification. This can be achieved, for example, requiring SPI re-classification. This can be achieved, for example,
by decoupling the service consumer and service endpoint by a new by decoupling the service consumer and service endpoint by a new
service function proposed in this draft. We describe few service function proposed in this draft. We describe few
requirements for this service function to enable dynamic switching requirements for this service function to enable dynamic switching
between consumer and end point. between consumer and end point.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 April 30, 2018. This Internet-Draft will expire on September 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use Case Description . . . . . . . . . . . . . . . . . . . . 3 2. Use Case Description . . . . . . . . . . . . . . . . . . . . 3
2.1. Data Center . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Data Center . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. ETSI MEC USE CASE . . . . . . . . . . . . . . . . . . . . 4 2.2. Third party cloud service provider . . . . . . . . . . . 4
2.3. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. ETSI MEC USE CASE . . . . . . . . . . . . . . . . . . . . 5
2.4. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 5 2.4. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. NSH and Re-classification . . . . . . . . . . . . . . . . . . 5 2.5. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 6
3.1. Dynamic service chain creation using NSH . . . . . . . . 7 3. NSH and Re-classification . . . . . . . . . . . . . . . . . . 8
4. Challenges with dynamic indirection . . . . . . . . . . . . . 8 3.1. Dynamic service chain creation using NSH . . . . . . . . 9
5. Desired Features . . . . . . . . . . . . . . . . . . . . . . 10 4. Challenges with dynamic indirection . . . . . . . . . . . . . 10
6. Service Request Routing (SRR) Service Function . . . . . . . 10 5. HTTP as a transport . . . . . . . . . . . . . . . . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Service Request Routing (SRR) Service Function . . . . . . . 14
6.2. Notion of HTTP-Based Transport . . . . . . . . . . . . . 12 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Details of SRR Function . . . . . . . . . . . . . . . . . 13 6.2. Details of SRR Function . . . . . . . . . . . . . . . . . 16
7. Protocol Consideration . . . . . . . . . . . . . . . . . . . 18 7. Protocol Consideration . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Informative References . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 11. Informative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The requirements on today's networks are very diverse, enabling The requirements on today's networks are very diverse, enabling
multiple use cases such as IoT, Content Distribution, Gaming, Network multiple use cases such as IoT, Content Distribution, Gaming, Network
functions such as Cloud RAN. Every use case imposes certain functions such as Cloud RAN. Every use case imposes certain
requirements on the network. These requirements vary from one requirements on the network. These requirements vary from one
extreme to other and often they are in a divergent direction. extreme to other and often they are in a divergent direction.
Network operator and service providers are pushing many functions Network operator and service providers are pushing many functions
towards the edge of the network in order to be closer to the users. towards the edge of the network in order to be closer to the users.
skipping to change at page 2, line 51 skipping to change at page 3, line 4
1. Introduction 1. Introduction
The requirements on today's networks are very diverse, enabling The requirements on today's networks are very diverse, enabling
multiple use cases such as IoT, Content Distribution, Gaming, Network multiple use cases such as IoT, Content Distribution, Gaming, Network
functions such as Cloud RAN. Every use case imposes certain functions such as Cloud RAN. Every use case imposes certain
requirements on the network. These requirements vary from one requirements on the network. These requirements vary from one
extreme to other and often they are in a divergent direction. extreme to other and often they are in a divergent direction.
Network operator and service providers are pushing many functions Network operator and service providers are pushing many functions
towards the edge of the network in order to be closer to the users. towards the edge of the network in order to be closer to the users.
This reduces latency and backhaul traffic, as user request can be This reduces latency and backhaul traffic, as user request can be
processed locally. processed locally.
It becomes more challenging for the network when user mobility as It becomes more challenging when network congestion, user mobility as
well as non-deterministic availability of compute and storage well as non-deterministic availability of compute and storage
resources are considered. The impact is felt most in the edge of the resources are considered. The impact is felt most in the edge of the
network because as the users move, their point of attachment changes network because as the users move, their point of attachment changes
frequently, which results in (at least partially) relocating the frequently, which results in (at least partially) relocating the
service as well as the service endpoint. Furthermore, network service as well as the service endpoint. Furthermore, network
functions are pushed more and more towards the edge, where compute functions are pushed more and more towards the edge, where network,
and storage resources are constrained and availability is non- compute and storage resources are constrained and availability is
deterministic. Also, storage resources may need to be moved where non-deterministic. Constrained network resources may lead into
the user concentration is more in case of content delivery congestion in the network. Also, storage resources may need to be
applications. moved where the user concentration is more in case of content
delivery applications.
We describe a few use cases in the next section and derive the We describe few use cases in the next section and derive the
requirements for composing new services and service path in a dynamic requirement for composing new services and service path in a dynamic
edge network. We address this dynamicity by introducing a special edge network. We address this dynamicity by introducing a special
Service Function, called SRR (service request routing). We describe Service Function, called SRR (service request routing). We describe
the problems associated with today's network and Layer 3 based the problems associated with today's network and Layer 3 based
approach to handle dynamicity in the network. We then discuss how approach to handle dynamicity in the network. We then discuss how
such new Service Function with certain capabilities can handle the such new Service Function with certain capabilities can handle the
dynamicity better than these conventional methods. Note : State dynamicity better than these conventional methods.
migration is not in the scope of our solution since this problem is a
general one pertaining to re-chaining stateful SFs.
2. Use Case Description 2. Use Case Description
2.1. Data Center 2.1. Data Center
The data center use case draft [I-D.ietf-sfc-dc-use-cases] describes The data center use case draft [I-D.ietf-sfc-dc-use-cases] describes
an East West traffic use case. This is the predominant traffic in an East West traffic use case. This is the predominant traffic in
data centers today. Server virtualization has led to the new data centers today. Server virtualization has led to the new
paradigm where virtual machines can migrate from one server to paradigm where virtual machines can migrate from one server to
another across the data center. This explosion in east-west traffic another across the data center. This explosion in east-west traffic
skipping to change at page 4, line 24 skipping to change at page 4, line 26
It is clear that within the data center as well as in inter data It is clear that within the data center as well as in inter data
center scenarios, users are serviced by multiple SFs distributed center scenarios, users are serviced by multiple SFs distributed
inside as well as outside a location. In this scenario, it is clear inside as well as outside a location. In this scenario, it is clear
that Service function chains should be able to reselect, redirect that Service function chains should be able to reselect, redirect
traffic very fast. The draft identifies that Static service chains traffic very fast. The draft identifies that Static service chains
do not allow for modifying the SFCs as they require the ability to do not allow for modifying the SFCs as they require the ability to
add SNs or remove SNs to scale up and down the service capacity. add SNs or remove SNs to scale up and down the service capacity.
Likewise the ability to dynamically pick one among the many SN Likewise the ability to dynamically pick one among the many SN
instance is not available. instance is not available.
2.2. ETSI MEC USE CASE 2.2. Third party cloud service provider
This use case is related to an emerging business model, where
computational resources for edge cloud service are provided by
alternative facility providers that are non-traditional network
operators. This is due to the situation for many specific localized
use cases, where network operators may not have necessary real estate
available. They may even not be willing to spend on CAPEX and OPEX
for said point-of-presence, because there is no clear path for
sustainable cost recovery [UKNIC].
The industry is witnessing the emergence of real estate owners such
as building asset or management companies, cell tower owners, railway
companies or other facility owners willing to deploy edge cloud
resources. The facility provider, e.g. cell tower owner or building
management company, deploys edge computing resources throughout their
installation in the country. They have their own operation and
management software, which is capable of resource deployment, scale
up or scale down resources, deploy edge applications from third party
service providers . They are capable of offering service to more than
one network operator at a specific location, thus acting as a
"neutral host". The facility provider, which owns cloud resources
and provides application services, is referred to as "Third party
Edge Owner (TEO)".
There is more than one stakeholder in this ecosystem, E.g. Network
Service Provider, Real estate owner, Cloud capability (compute and
storage resource) provider, Application/service provider. An entity
can assume more than one role. From network operators point of view
there may be "Cloud provider" or "Cloud service provider" depending
on the roles assumed by external entity.
"Cloud Providers" provide cloud resources (compute and storage) to
network operators. Network operators rent those resources and manage
MEC host by themselves. Network operator can set up application
traffic rules, so that traffic can be processed, by that host.
"Cloud Service Providers" not only make resources available to
network operators or service providers, but also provides management
and hosting service. They can host edge applications on behalf of
application service providers and sets up user plane traffic to be
steered towards the edge application.
Cloud Service Providers, as well as many organizations that need to
share and analyze a quickly growing amount of data, such as
retailers, manufacturers, telcos, financial services firms, and many
more, are turning to localized Micro Data Centers(MDC) installed on
the factory floor, in the telco central office, the back of a retail
outlet, etc. The solution applies to a broad base of applications
that require low latency, high bandwidth, or both.
As Micro Date centers are deployed at the edge of the network, common
deployment options are:
o Micro Data Centers are deployed on L2 in the edge of the network
o Instead of single internet Point Of Presence (POP) deployment,
multiple internet POP deployment is desirable to localize data
o Service is composed out of these multiple POP deployment of MDC,
where data exchange and collaboration is expected among these MDCs
o Due to mobility, changes in network condition (e.g. congestion,
load), service composition may change frequently to support
promised quality of experience
2.3. ETSI MEC USE CASE
Take the following video orchestration service example from ETSI MEC Take the following video orchestration service example from ETSI MEC
Requirements document [ETSI_MEC]. The proposed use case of edge Requirements document [ETSI_MEC]. The proposed use case of edge
video orchestration suggests a scenario where visual content can be video orchestration suggests a scenario where visual content can be
produced and consumed at the same location close to consumers in a produced and consumed at the same location close to consumers in a
densely populated and clearly limited area. Such a case could be a densely populated and clearly limited area. Such a case could be a
sports event or concert where a remarkable number of consumers are sports event or concert where a remarkable number of consumers are
using their handheld devices to access user select tailored content. using their handheld devices to access user select tailored content.
The overall video experience is combined from multiple sources, such The overall video experience is combined from multiple sources, such
as local recording devices, which may be fixed as well as mobile, and as local recording devices, which may be fixed as well as mobile, and
master video from central production server. The user is given an master video from central production server. The user is given an
opportunity to select tailored views from a set of local video opportunity to select tailored views from a set of local video
sources. sources.
2.3. 3GPP 2.4. 3GPP
3GPP Rel. 15 introduces the notion of the service-based interface 3GPP Rel. 15 introduces the notion of the service-based interface
(SBI) as an alternative to the traditional call pattern invocation of (SBI) as an alternative to the traditional call pattern invocation of
network functions. This introduction targets the support for network functions. This introduction targets the support for
replication, e.g., driven by virtualized functions, as well as replication, e.g., driven by virtualized functions, as well as
supporting alternative interactions, e.g., for different vertical supporting alternative interactions, e.g., for different vertical
market specific control planes, by making the discovery as well as market specific control planes, by making the discovery as well as
composition of new interactions more flexible. composition of new interactions more flexible.
We believe that SFC is a suitable framework for the interconnection We believe that SFC is a suitable framework for the interconnection
of such network functions through the new SBI. One of the of such network functions through the new SBI. One of the
aforementioned driving forces, namely the replication of functions aforementioned driving forces, namely the replication of functions
aligns with our thinking in this draft in that indirections to new aligns with our thinking in this draft in that indirections to new
vertical instances need to be dynamic in reacting to the appearance vertical instances need to be dynamic in reacting to the appearance
of new virtual instances or to changes in policies for the selection of new virtual instances or to changes in policies for the selection
of specific instances by specific calling entities. of specific instances by specific calling entities.
2.4. Use Case Analysis 2.5. Use Case Analysis
In such a dynamic network environment, the capability to dynamically SFC allows network operators as well as service providers to compose
compose new services from available services as well as move a new services by chaining individual service functions.
service instance in response to user mobility or resource
availability is desirable. SFC allows network operators as well as In a dynamic network environment, like the edge of a network, the
service providers to compose new services by chaining individual capability to dynamically compose new services from available
service functions towards the composed new service. In a dynamic services as well as move a service instance is desirable. Dynamic
network environment where service functions move frequently because composition and relocation of services may be attributed to:
of user movement, load balancing or resource modification, service
function chains and the service end points need to be created and o Congestion in the network: Due to constrained network resources,
recreated frequently. SFC, as defined in IETF, is capable of increase in the network load may create congestion in the network,
modifying the service chain dynamically in response to network resulting in a congested Service Function Path. Service functions
conditions. may detect congestion and reconfigure the Service Function Path to
avoid it.
o In response to latency: in a dynamic network environment and with
the need for ultra-low latency communication, instantiation of new
service function endpoints might be the only remedy to combat the
increase of latency caused, e.g., by increased load on a previous
endpoint or mobility of the user and therefore increasing the
'distance' to the service function endpoint. Keeping the service
function endpoint 'close' to the user allows for reducing latency,
segregating communication in localized islands of service
interaction.
o In response to user mobility: In a dynamic network environment
where service functions move frequently because of user movement,
load balancing or resource modification, service function chains
and the service end points need to be created and recreated
frequently
o Resource availability.: Availability of compute and storage
resources varies with network load, number and type of
applications running etc. In the edge of the network, due to
sudden increase of users, compute load may increase. In this
situation applications, running on the compute resources may be
moved to another location where more resources are available.
In SFC, there is a notion of logical chaining of SFs and chaining of
actual physical locations, known as Rendered Service Path (RSP). RSP
provides a static binding of SFs to their physical location. In
order to create a chain in dynamic fashion, late binding of SFs and
physical location may be desired. SFC is capable of modifying the
service chain to certain extent in response to network conditions,
but not a complete solution has been described
In order to route the service requests to service end points in a In order to route the service requests to service end points in a
dynamic manner, we identify the following desirable features in a dynamic manner, we identify the following desirable features in a
service function chain: service function chain:
o Capability to trigger service chain reconfiguration based on
network information such as congestion indication, mobility,
degradation of user experience etc. Service Functions should be
able to process such network information, identify which section
of the chain needs to be reconfigured and take action
o Fast switching from one service instance to another by not relying o Fast switching from one service instance to another by not relying
on the DNS for service location resolution. Instead of DNS, the on the DNS for service location resolution. Instead of DNS, the
function should be able to identify the path, which will allow to function should be able to identify the path, which will allow to
reach the service end point. reach the service end point.
o Direct path mobility, where the path between the requester and the o Direct path mobility, where the path between the requester and the
responding service can be determined as being optimal (e.g., responding service can be determined as being optimal (e.g.,
shortest path or direct path to a selected instance), is needed to shortest path or direct path to a selected instance), is needed to
avoid the use of anchor points and further reduce service-level avoid the use of anchor points and further reduce service-level
latency latency
skipping to change at page 6, line 43 skipping to change at page 9, line 10
Selective traffic, subject to policy, may then be "steered" to the Selective traffic, subject to policy, may then be "steered" to the
requisite service resources, along with any "extra" information requisite service resources, along with any "extra" information
referred to as metadata. This metadata is used for policy referred to as metadata. This metadata is used for policy
enforcement. enforcement.
A basic form of service chaining may be realized using existing A basic form of service chaining may be realized using existing
transport encapsulations. This method of chaining relies upon the transport encapsulations. This method of chaining relies upon the
tunneling of selected data between service functions. Although this tunneling of selected data between service functions. Although this
form of service chaining achieves some level of abstraction from the form of service chaining achieves some level of abstraction from the
underlying topology, it does not truly create a service plane. NSH underlying topology, it does not truly create a service plane. NSH
[I-D.ietf-sfc-nsh] is a distinct identifiable plane that can be used [RFC8300] is a distinct identifiable plane that can be used across
across all transports to create a service chain and exchange metadata all transports to create a service chain and exchange metadata along
along the chain. the chain.
Fundamentally, however, the notion of "services" in SFC is tied into Fundamentally, however, the notion of "services" in SFC is tied into
specific service function endpoints, which lie along a well-defined specific service function endpoints, which lie along a well-defined
service function path (SFP) where the path is defined through lower service function path (SFP) where the path is defined through lower
layer transport encapsulations. If any such service function layer transport encapsulations. If any such service function
endpoint changes, the service chain needs to be adjusted; a procedure endpoint changes, the service chain needs to be adjusted; a procedure
we outline in the following sub-section. we outline in the following sub-section.
3.1. Dynamic service chain creation using NSH 3.1. Dynamic service chain creation using NSH
We revisit the dynamic service chain creation capability of NSH. NSH We revisit the dynamic service chain creation capability of NSH. NSH
defines a new service plane protocol [I-D.ietf-sfc-nsh]. A Network defines a new service plane protocol [RFC8300]. A Network Service
Service Header (NSH) contains service path information and optionally Header (NSH) contains service path information and optionally
metadata that are added to a packet or frame and used to create a metadata that are added to a packet or frame and used to create a
service plane. A control plane is required in order to exchange NSH service plane. A control plane is required in order to exchange NSH
values with participating nodes, and to provision the same nodes with values with participating nodes, and to provision the same nodes with
requisite information such as service path ID to overlay mapping. requisite information such as service path ID to overlay mapping.
The Network Service Header has three parts, Base header, Service Path The Network Service Header has three parts, Base header, Service Path
Header and Context Header. NSH Service Path Header is a 4-byte Header and Context Header. NSH Service Path Header is a 4-byte
service path header follows the base header and defines two fields service path header follows the base header and defines two fields
used to construct a service path: used to construct a service path:
skipping to change at page 8, line 20 skipping to change at page 10, line 36
etc. As users are moving, application or services being used by etc. As users are moving, application or services being used by
users, may need to be moved closer to the user's new location. This users, may need to be moved closer to the user's new location. This
implies another instance of the service function may need to be implies another instance of the service function may need to be
instantiated close to the user's new location. It may result in re- instantiated close to the user's new location. It may result in re-
establishing service path from the newly instantiated service establishing service path from the newly instantiated service
function to other service instances. It is also possible that the function to other service instances. It is also possible that the
newly instantiated service function may be redirected to a new newly instantiated service function may be redirected to a new
service end point (e.g. Application Server) for various reasons, service end point (e.g. Application Server) for various reasons,
such as incomplete content, proximity to data store, load balancing such as incomplete content, proximity to data store, load balancing
etc. In another scenario, a single instance of the service function etc. In another scenario, a single instance of the service function
may not handle all users. A single service function may be may not handle all users due to latency or load constraints. A
instantiated more than once to balance user load. As the number of single service function may be instantiated more than once to balance
instances increase and along with mobility, the complexity of service user load. As the number of instances increase and along with
routing increases. It is anticipated that there may be a constant mobility, the complexity of service routing increases. It is
action of function chaining, re-chaining occurring in the network. anticipated that there may be a constant action of function chaining,
re-chaining occurring in the network.
The challenge of dynamic indirection may be better described by The challenge of dynamic indirection may be better described by
analyzing the working of CDNs, which dynamically (re-)direct user- analyzing the working of CDNs, which dynamically (re-)direct user-
initiated requests towards the most appropriate content instance. initiated requests towards the most appropriate content instance.
This task becomes more difficult if granularity of the instance This task becomes more difficult if granularity of the instance
placement increases. For instance, in case of a CDN being realized placement increases. For instance, in case of a CDN being realized
close to end users, specifically in edge of the network, the specific close to end users, specifically in edge of the network, the specific
content instance might need to be selected dynamically. After content instance might need to be selected dynamically. After
initial selection, the instance may change during service execution. initial selection, the instance may change during service execution.
skipping to change at page 8, line 50 skipping to change at page 11, line 20
a given domain name and will try to return an IP address of a node a given domain name and will try to return an IP address of a node
geographically close to the client. Should the service provider want geographically close to the client. Should the service provider want
to replace an instance of their service with another one at a to replace an instance of their service with another one at a
different IP address (and potentially a different physical location different IP address (and potentially a different physical location
for various reasons such as load balancing, reliability etc.) then for various reasons such as load balancing, reliability etc.) then
the DNS tables must be updated, i.e., the service needs to be the DNS tables must be updated, i.e., the service needs to be
(re-)registered quickly. This is done by updating the local (re-)registered quickly. This is done by updating the local
authoritative DNS server which then propagates the new mapping to DNS authoritative DNS server which then propagates the new mapping to DNS
services across the world. DNS propagation can take up to 48 hours services across the world. DNS propagation can take up to 48 hours
so fast and dynamic switching from one service instance to another is so fast and dynamic switching from one service instance to another is
not possible in conventional networks. When relying on many not possible in conventional networks; even in more localized
surrogate service endpoints to exist in the edge network, there is a scenarios, the propagation of DNS updates might still be
clear issue of certain resources not being available in one surrogate insufficient. When relying on many surrogate service endpoints to
instance while existing in another so that changes in redirection exist in the edge network, there is a clear issue of certain
might be desirable, while also changes in local load drive the need resources not being available in one surrogate instance while
for such change in redirection. existing in another so that changes in redirection might be
desirable, while also changes in local load drive the need for such
change in redirection. With the emergence of container-based
virtualization platforms, service function endpoints can be
established in a matter of seconds and we therefore believe that the
'reachability' of such said service instance, i.e., the possibility
of route service requests to it from a client that was previously
served elsewhere, must follow a similar timeline, i.e., a few seconds
or even less.
The other issue in conventional network lies with mobility management The other issue in conventional network lies with mobility management
procedure. These procedures use an anchor point, which terminates a procedure. These procedures use an anchor point, which terminates a
session at the network edge. As user moves around, traffic is session at the network edge. As user moves around, traffic is
redirected from the anchor point to the new point of attachment. redirected from the anchor point to the new point of attachment.
Relying on typical mobility management approaches found in IP Relying on typical mobility management approaches found in IP
networks, usually leads to inefficient 'triangular' routing of networks, usually leads to inefficient 'triangular' routing of
requests through this common 'anchor' point. This triangular routing requests through this common 'anchor' point. This triangular routing
increases the latency in reaching the new service function or service increases the latency in reaching the new service function or service
end points as users move. end points as users move.
skipping to change at page 10, line 4 skipping to change at page 12, line 30
are the typical steps that happens in order to implement the are the typical steps that happens in order to implement the
indirection. indirection.
o A packet arrives at a particular node o A packet arrives at a particular node
o The node contacts the policy manager o The node contacts the policy manager
o Identifies the current classification is incorrect o Identifies the current classification is incorrect
o Reclassifies the packet, i.e. change the SPI o Reclassifies the packet, i.e. change the SPI
o Inserts the packet in the pipe, possibly towards the SFF o Inserts the packet in the pipe, possibly towards the SFF
The indirection mechanism in SFC involves certain steps to process The indirection mechanism in SFC involves certain steps to process
policy information and change the SPI in the packet header, making it policy information and change the SPI in the packet header, making it
suitable to handle dynamic indirection requirements. Our proposed SF suitable to handle dynamic indirection requirements. Our proposed SF
in this document provides an additional method to handle dynamic in this document provides an additional method to handle dynamic
indirection of service requests, not relying on the reclassification indirection of service requests, not relying on the reclassification
mechanism. Combining these two techniques may provide flexibility mechanism. Combining these two techniques may provide flexibility
and improvement over single method. and improvement over single method.
5. Desired Features 5. HTTP as a transport
In order to route the service requests to service end points in a With the extensive use of "web technology", "distributed services"
dynamic manner, we identify the following desirable features: and availability of heterogeneous network, HTTP has effectively
transitioned into the common transport for name-based E2E
communication across the web. In the context of SFC and SF, HTTP
requests and response are considered as the "Service Request (SR)".
This use case describes how these SRs are directed towards correct SF
in a fast and dynamic way. The routing and indirection of SRs are
abstracted at HTTP level, instead of the traditional approach where
routing decision for a service request is made at Layer 3.
o Fast switching from one service instance to another by not relying If we abstract HTTP as a transport, HTTP requests, such as GET, PUT
on DNS for service location resolution. Instead of DNS, the and POST can be routed based on the URI associated with the request,
function should be able to identify the path, which will allow to with the URI being simply the name of a resource or the invocation
reach the service end point. point for a service transaction. Based on the name of the resource
requested, the appropriate HTTP request can be routed to the suitable
service endpoint. If Service Functions (SF) could be identified
using URI or name, HTTP requests to an SF would be routed or directed
using name based routing. With that, the redirection to the most
suitable service instance is purely done based on named services with
HTTP being a specific (application layer) transport service.
o Direct path mobility, where the path between the requester and the The ongoing EU H2020 efforts like FLAME [H2020FLAME] are driven by
responding service can be determined as being optimal (e.g., city-scale many-POP deployments of compute infrastructure, all SDN-
shortest path or direct path to a selected instance), is needed to connected and OpenStack managed. Localized media use cases drive the
avoid the use of anchor points and reduce service-level latency need for name-based (HTTP as the main transport protocol here)
service instances being chained with the relationship between
specific virtual instances being controlled at the underlying
routing/switching level.
o Indirect service requests at the network level, transparent to the The notion of 'HTTP as-a transport', utilizing URLs as addressing
requesting client and without the involvement of the DNS. End scheme, can be used to create SFP as shown in Fig 2., i.e.,
user is not aware of the decision made by the SF. 192.168.x.x -> www.example.com -> 192.168.x.x -> www.example2.com ->
192.168.x.x -> ... -> www.exampleN.com. It is this 'name-based'
relationship that we see possibly realized through specific
replicated instances, where in turn the routing towards those
specific instances is realized by the SRR.
o New methods for forwarding, such as path-based forwarding, direct +--------+
path routing in mobility cases, path pinning for traffic steering | |
and simplified service-specific peering towards the Internet. |-------------------------|------------------+ SRR +
| | | |
| | +---/|\--+
| | |
+---\|/--+ +---------+ +--\|/--+ +------+ +----+---+
| | | | | | | | | |
+ Client +-->+ SRR +-->+ Media +-->+ SRR +-->+ Media +
| | | | | Fn1 | | | | Fn2 |
+--------+ +---------+ +-------+ +------+ +--------+
SFP:192.168.x.x-->www.example.com-->192.168.x.x
-->www.example2.com-->192.168.x.x-->www.exampleN.com
Figure 2: SFP with new HTTP-based Transport option
In a pure SFC architectural framework, Classifier function may
interact with SRR to obtain an SE (Service Encapsulation). E.g. the
Classifier function may look into the network locator map in Fig 2
and determine the next SF is www.example.com. It provides this
information to SRR to obtain the next hop information. SRR returns
the SE for next hop, which can be a "bitfield" information that is
being used in the overlay routing for this part of the SFP. The
Classifier function uses this SE to route the incoming packet
directly at the transport network level.
6. Service Request Routing (SRR) Service Function 6. Service Request Routing (SRR) Service Function
6.1. Overview 6.1. Overview
The following diagram shows the application of the new proposed SRR The following diagram shows the application of the new proposed SRR
service function in an example of media clients connecting to media service function in an example of media clients connecting to media
servers. There may be more than one media functions to support CDN servers. There may be more than one media functions to support CDN
like architecture, Surrogate servers to handle mobility and load like architecture, Surrogate servers to handle mobility and load
balancing. balancing.
skipping to change at page 11, line 17 skipping to change at page 14, line 34
|-------------------------|------------------+ SRR + |-------------------------|------------------+ SRR +
| | | | | | | |
| | +---/|\--+ | | +---/|\--+
| | | | | |
+---\|/--+ +---------+ +--\|/--+ +------+ +----+---+ +---\|/--+ +---------+ +--\|/--+ +------+ +----+---+
| | | | | | | | | | | | | | | | | | | |
+ Client +-->+ IP +-->+ Media +-->+ SRR +-->+ Media + + Client +-->+ IP +-->+ Media +-->+ SRR +-->+ Media +
| | | Routing | | Fn1 | | | | Fn2 | | | | Routing | | Fn1 | | | | Fn2 |
+--------+ +---------+ +-------+ +------+ +--------+ +--------+ +---------+ +-------+ +------+ +--------+
Figure 2: General SFC with SRR Flexible Chaining, Initiated via IP Figure 3: General SFC with SRR Flexible Chaining, initiated via IP
Routed Client Connection Routed Client Connection
The clients are connected to media functions through frontend routed The clients are connected to media functions through frontend routed
network, e.g., relying on standard IP routing, while media functions network, e.g., relying on standard IP routing, while media functions
are chained via the new proposed service request routing (SRR) are chained via the new proposed service request routing (SRR)
function. Alternatively, we also envision to utilize the SRR function. Alternatively, we also envision to utilize the SRR
function directly between client SF and media function SF, as function directly between client SF and media function SF, as
outlined in the figure below outlined in the figure below
+--------+ +--------+
| | | |
|-------------------------|------------------+ SRR + |-------------------------|------------------+ SRR +
| | | | | | | |
| | +---/|\--+ | | +---/|\--+
| | | | | |
+---\|/--+ +---------+ +--\|/--+ +------+ +----+---+ +---\|/--+ +---------+ +--\|/--+ +------+ +----+---+
| | | | | | | | | | | | | | | | | | | |
+ Client +-->+ SRR +-->+ Media +-->+ SRR +-->+ Media + + Client +-->+ SRR +-->+ Media +-->+ SRR +-->+ Media +
| | | | | Fn1 | | | | Fn2 | | | | | | Fn1 | | | | Fn2 |
+--------+ +---------+ +-------+ +------+ +--------+ +--------+ +---------+ +-------+ +------+ +--------+
Figure 3: General SFC with SRR Flexible Chaining, Initiated between Figure 4: General SFC with SRR Flexible Chaining, initiated via SRR
via SRR Chained Client Chained Client
For our considerations, we assume that each SF is realized by at For our considerations, we assume that each SF is realized by at
least one or more service function endpoints (SFEs). Hence, instead least one or more service function endpoints (SFEs). Hence, instead
of looking at "chaining" as a concept that connects specific SFEs of looking at "chaining" as a concept that connects specific SFEs
along a well-defined SFP, we propose to look at "chaining" at the along a well-defined SFP, we propose to look at "chaining" at the
level of "named" service functions rather than their specific level of "named" service functions rather than their specific
endpoints. With this in mind, the SRR service function lifts the endpoint instances. With this in mind, the SRR service function
relationship between the connecting SFs to the level of "logical" lifts the relationship between the connecting SFs to the level of
service functions rather than their specific realizing endpoints. "logical" service functions rather than their specific realizing
endpoints. Instead of relying on dynamic re-chaining in case of any
dynamically changing relationship between specific SFEs, the SRR
provides the selection of suitable SFEs while maintaining the logical
relationship between the SFs. In Section 6.3, we will present the
necessary extensions to the SFP concept to support this higher
abstraction of "chaining" via "named" logical SFs. The SRR
introduces the flexibility in routing service requests from client to
specific SFEs. In the edge network, where users are moving and
service end points may also change, having flexibility to decide and
steer service requests directly helps in guaranteeing the same
latency to user applications. Clearly, that is achieved by reducing
the switching time from SF to another. As service end point changes,
the routing functions makes instantaneous decision to route the
request to the appropriate media server.
Instead of relying on dynamic re-chaining in case of any dynamically The SRR introduces the flexibility in routing service requests from
changing relationship between specific SFEs, the SRR provides the client to specific SFEs in response to conditions such as congestion
selection of suitable SFEs while maintaining the logical relationship in the network, user mobility etc. In the edge network, where users
between the SFs. In Section 6.3, we will present the necessary are moving and service end points may also change, having flexibility
extensions to the SFP concept to support this higher abstraction of to decide and steer service requests directly helps in guaranteeing
"chaining" via "named" logical SFs. The SRR introduces the the same latency to user applications. The edge of the network maybe
flexibility in routing service requests from client to specific SFEs. congested due to limited network resources. The SRR may be able to
In the edge network, where users are moving and service end points determine network congestion and quickly route service requests to
may also change, having flexibility to decide and steer service other Service End point, which is not experiencing congestion. In
requests directly helps in guaranteeing the same latency to user addition, application-layer control functions might utilize latency
applications. Clearly, that is achieved by reducing the switching measurements to ensure that suitable service instances are being
time from SF to another. As service end point changes, the routing created during runtime of the scenario such as to ensure that service
function endpoints are available 'nearby' (possibly) moving so as to
keep a desired latency under a desired value.
Clearly, that is achieved by reducing the switching time from one SF
endpoint to another. As the service end point changes, the routing
functions makes instantaneous decision to route the request to the functions makes instantaneous decision to route the request to the
appropriate media server. appropriate media server.
The possible improvements of using SRR within an SFC framework are The possible improvements of using SRR within an SFC framework are
listed below: listed below:
o Fast (between 10 and 20ms) switching times from one service o Fast (between 10 and 20ms) switching times from one service
instance to another by not relying on the DNS for service instance to another by not relying on the DNS for service
discovery and directly routing service requests at the level of discovery and directly routing service requests at the level of
the transport network. the transport network.
skipping to change at page 12, line 45 skipping to change at page 16, line 40
leads to a net-level 'search' among all available surrogate leads to a net-level 'search' among all available surrogate
instances until the search is exhausted (with a negative result) instances until the search is exhausted (with a negative result)
or the resource is found. or the resource is found.
o New methods for forwarding, such as path-based forwarding, will o New methods for forwarding, such as path-based forwarding, will
enable direct path routing in mobility cases, path pinning for enable direct path routing in mobility cases, path pinning for
traffic steering and simplified service-specific peering towards traffic steering and simplified service-specific peering towards
the Internet. Such capability would allow for localizing traffic, the Internet. Such capability would allow for localizing traffic,
reduce latency and costs. reduce latency and costs.
6.2. Notion of HTTP-Based Transport 6.2. Details of SRR Function
As a first proposed extension to the SFC framework, we introduce the
notion of a "HTTP-based transport" utilizing URLs as addressing
scheme. With that, we can create SFPs as shown in Fig 4, "i.e.,
192.168.x.x -> www.foo.com -> 192.168.x.x -> www.foo2.com ->
192.168.x.x -> ... -> www.fooN.com." It is this "name-based"
relationship that we see possibly realized through specific
replicated instances, where in turn the routing towards those
specific instances is realized by the SRR.
+--------+
| |
|-------------------------|------------------+ SRR +
| | | |
| | +---/|\--+
| | |
+---\|/--+ +---------+ +--\|/--+ +------+ +----+---+
| | | | | | | | | |
+ Client +-->+ SRR +-->+ Media +-->+ SRR +-->+ Media +
| | | | | Fn1 | | | | Fn2 |
+--------+ +---------+ +-------+ +------+ +--------+
SFP:192.168.x.x-->www.foo.com-->192.168.x.x-->www.foo2.com-->192.168.x.x-->www.fooN.com
Figure 4: SFP with new HTTP-based Transport option
In a pure SFC architectural framework, Classifier function can may
interact with SRR to obtain an SE (Service Encapsulation). E.g. the
Classifier function may look into the network locator map in Fig 4
and determine the next SF is www.foo.com. It provides this
information to SRR to obtain the next hop information. SRR returns
the SE for next hop, which can be a "bitfield" information that is
being used in the overlay routing for this part of the SFP. The
Classifier function uses this SE to route the incoming packet
directly at the transport network level.
6.3. Details of SRR Function
Assuming such introduction of an HTTP-level transport notion, the SRR Assuming such introduction of an HTTP-level transport notion, the SRR
function can be decomposed further as shown in Fig 5. function can be decomposed further as shown in Fig 5.
+--------+ +--------+
| | | |
|-------------------------|------------------+ SRR + |-------------------------|------------------+ SRR +
| | | | | | | |
| | +---/|\--+ | | +---/|\--+
| | | | | |
skipping to change at page 14, line 22 skipping to change at page 17, line 22
| | | | | | | | | | | | | | | | | | | |
+ Client +-->+ SRR +-->+Service+-->+ SRR +-->+ Service + + Client +-->+ SRR +-->+Service+-->+ SRR +-->+ Service +
| | | | | Fn1 | | | | Fn2 | | | | | | Fn1 | | | | Fn2 |
+--------+ +---------+ +-------+ +------+ +---------+ +--------+ +---------+ +-------+ +------+ +---------+
/ \ / \
/ \ / \
/ \ / \
+--------------------------------------+ +--------------------------------------+
| +------------------+ | | +------------------+ |
| | +-----+ +----+ | +-----+ | | | +-----+ +----+ | +-----+ |
|---> | SFC | |NAP | | |NAP |-----> |---> | SFC | | SR | | | SR |----->
| | |Proxy| | | | | | | | | |Proxy| | | | | | |
| | +-----+ +----+ | +-/|\-+ | | | +-----+ +----+ | +-/|\-+ |
| | Use Proxy if NAP| | | | | Use Proxy if NAP| | |
| | is not SFC | | | | | is not SFC | | |
| | enabled | | | | | enabled | | |
| +-------/|\--------+ | | | +-------/|\--------+ | |
| | | | | | | |
| | | | | | | |
| | +----------+ | | | | +----------+ | |
| |->| tSFF1 |----- | | |->| tSFF1 |----- |
| +---/|\----+ | | +---/|\----+ |
| | | | | |
| | | | | |
| +----------+ | | | +----------+ | |
| | | | | | | | | |
| + PCE +---- | | + PCE +---- +-----+ |
| | | | | | |--------| RT | |
| +----------+ | | +----------+ +-----+ |
| | | |
+--------------------------------------+ +--------------------------------------+
Figure 5: SRR decomposition Figure 5: SRR decomposition
Another option for the two functions routing via the SRR could be Another option for the two functions routing via the SRR could be
entirely link-local, i.e., there's another simple tSFF2 between entirely link-local, i.e., there's another simple tSFF2 between
client and SRR as well as SF1 and SRR that is simply a link-local client and SRR as well as SF1 and SRR that is simply a link-local
transport. The following figure describes this alternate option. transport. The following figure describes this alternate option.
skipping to change at page 15, line 21 skipping to change at page 18, line 21
+---\|/--+ +---------+ +--\|/--+ +------+ +----+---+ +---\|/--+ +---------+ +--\|/--+ +------+ +----+---+
| | | | | | | | | | | | | | | | | | | |
+ Client +-->+ SRR +-->+Service+-->+ SRR +-->+Service + + Client +-->+ SRR +-->+Service+-->+ SRR +-->+Service +
| | | | | Fn1 | | | | Fn2 | | | | | | Fn1 | | | | Fn2 |
+--------+ +---------+ +-------+ +------+ +--------+ +--------+ +---------+ +-------+ +------+ +--------+
/ \ / \
/ \ / \
/ \ / \
+-----+ +---------------------------------+ +-----+ +---------------------------------+
|tSFF2|--------->+----+ +-----+ | +--------+ |tSFF2|--------->+----+ +-----+ | +--------+
+-----+ | |NAP | |NAP |----->| tSFF2 |--> +-----+ | | SR | | SR |----->| tSFF2 |-->
| | | | | | +--------+ | | | | | | +--------+
| +----+ +-/|\-+ | | +----+ +-/|\-+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | +-------+ | | | | +-------+ | |
| |---->| tSFF1 |--- | | |---->| tSFF1 |--- |
| +--/|\--+ | | +--/|\--+ |
| | | | | |
| | | | | |
| +-------+ | | | +-------+ | |
| | | | | | | | | |
| + PCE +--- | | + PCE +--- +----+ |
| | | | | | |--------| RT | |
| +-------+ | | +-------+ +----+ |
| | | |
+---------------------------------+ +---------------------------------+
Figure 6: SRR decomposition using link-local client/function Figure 6: SRR decomposition using link-local client/function
communication communication
The SRR function may be composed of the following functions: The SRR function may be composed of the following functions:
o NAP at the ingress, terminates on the client side Layer 3 and o Service Router(SR) at the ingress, terminates on the client side
above protocols, such as TCP Layer 3 and above protocols, such as TCP
o NAP at the egress, terminates any transport protocol on the o Service Router(SR) at the egress, terminates any transport
network outgoing (server) side protocol on the outgoing (server) side
o PCE, Path Computation Element Policy control and Enforcement o PCE, Path Computation Element function is responsible for
function is responsible for selecting the correct next SF, also selecting the correct next SF, also possibly realizing path policy
possibly realizing path policy enforcement. The result of the enforcement. The result of the selection is a path identifier
selection is a path identifier which is delivered to the ingress which is delivered to the ingress SR upon initial path computation
NAP upon initial path computation request (i.e., when sending a request (i.e., when sending a request to a specific URL on the SFP
request to a specific URL on the SFP for the first time). The for the first time). The path identifier is utilized for any
path identifier is utilized for any future request for a given future request for a given URL-based SF. In case of another SF
URL-based SF. In case of another SF instance becoming available, instance becoming available, indicated to the PCE through a
indicated to the PCE through a registration procedure, the PCE registration procedure, the PCE will instruct all ingress SRs to
will instruct all ingress NAPs to invalidate path identifiers to invalidate path identifiers to the specific URL of the SF,
the specific URL of the SF, resulting in an initial path resulting in an initial path computation request at the next SF
computation request at the next SF request forwarding. Through request forwarding. Through this, the newly registered SF
this, the newly registered SF instance might be utilized if the instance might be utilized if the policy-governed path computation
policy-governed path computation will select said SF instance. will select said SF instance.
o Reclassification Trigger Handler (RT) : Network measurement
information, such as latency, packet loss or network congestion,
etc. could be processed by the handler. This may trigger
reconfiguration of the specific service function endpoint chain
over which the SFC is being executed. The handler forwards the
information about the chain reconfiguration to PCE.
o Transport-derived SFF (tSFF1): the communication between ingress/ o Transport-derived SFF (tSFF1): the communication between ingress/
egress NAPs as well as NAPs to PCE is realized via a transport- egress SRs as well as SRs to PCE is realized via a transport-
derived SFF. We outline here three possible tSFFs derived SFF. We outline here three possible tSFFs
o SDN-based: The Transport Derived SFFThis option (tSFF), utilizes * SDN-based: This option utilizes path-based forwarding through
path-based forwarding utilizing through SDN-based wildcard SDN-based wildcard matching fields, supported with
matching fields, supported according to with OF1.2+ [Reed2016]. OF1.2+[Reed2016]. It can be embedded into slicing approach of
It can be embedded into slicing approach of underlying transport underlying transport infrastructure by leaving typical slicing
infrastructure by leaving typical slicing fields available (e.g., fields available (e.g., VLAN tags). The forwarding utilizes
VLAN tags). The forwarding utilizes the Ethernet frame format at the Ethernet frame format at Layer 2, representing the
Layer 2, representing the topological links of a specific topological links of a specific forwarding path in the
forwarding path in the transport network as unique bits in a fixed transport network as unique bits in a fixed size bit array.
size bit array. For the latter, the approach utilizes the IPv6 For the latter, the approach utilizes the IPv6 source and
source and destination fields for storing the bit array destination fields for storing the bit array information (in a
information (in a simple version for this forwarding, this limits simple version for this forwarding, this limits the topology to
the topology to 256 links but extensions schemes are possible, 256 links but extensions schemes are possible, which are left
which are left out of this document at this stage). AS mentioned, out of this document at this stage). AS mentioned, the SDN
tThe SDN forwarding decision action is a simple wildcard matching, forwarding decision action is a simple wildcard matching,
supported withby OF1.2+, with the wildcard representing the unique supported with OF1.2+, with the wildcard representing the
bit of a switch-specific output port. With that, the switch needs unique bit of a switch-specific output port. With that, the
to consider as many forwarding rules as switch local output ports switch needs to consider as many forwarding rules as switch
- see [Reed2016] for more information. Fig. xx illustrate this local output ports - see [Reed2016] for more information. Fig.
forwarding solution, including the ability to create ad-hoc xx illustrate this forwarding solution, including the ability
multicast relations by simply ORing individual bitarrays to create ad-hoc multicast relations by simply ORing individual
representing unicast paths. bitarrays representing unicast paths.
o Another approach is outlined in [I-D.ietf-bier-use-cases] where * Another approach is outlined in [I-D.ietf-bier-use-cases] where
the SFF is suggested to be realized via a BIER overlay, in turn the SFF is suggested to be realized via a BIER overlay, in turn
realized over a BIER-compliant underlay, such as MPLS. BIER realized over a BIER-compliant underlay, such as MPLS. BIER
utilizes a similar bit array approach for representing a utilizes a similar bit array approach for representing a
forwarding path in the overlay network but unlike [Reed2016], the forwarding path in the overlay network but unlike [Reed2016],
bit fields indicate the egress BIER-compliant router that the the bit fields indicate the egress BIER-compliant router that
packet is supposed to reach. the packet is supposed to reach.
o As yet another alternative, the tSFF may utilize a flow * As yet another alternative, the tSFF may utilize a flow
aggregation approach, outlined in [Khalili2016], called edge aggregation approach, outlined in [Khalili2016], called edge
switch classification (ESC). In this approach, a path from an switch classification (ESC). In this approach, a path from an
ingress to egress NAP is described as a so-called edge ingress to egress SR is described as a so-called edge
classification vector (ECV), which combines information on the classification vector (ECV), which combines information on the
aggregated flow (following [Khalili2016]) and the switch-local aggregated flow (following [Khalili2016]) and the switch-local
endpoint. The representation has similar bitarray characteristics endpoint. The representation has similar bitarray
as the previous two approaches characteristics as the previous two approaches
o NOTE: with the ingress and egress NAPs terminating SF Layer 3 o NOTE: with the ingress and egress SRs terminating SF Layer 3
connections and the utilization of bitarray-based tSFFs, the connections and the utilization of bitarray-based tSFFs, the
transmission of packets can effectively take place as an ad-hoc transmission of packets can effectively take place as an ad-hoc
Layer multicast while the SFC itself is denoted as an n-times Layer multicast while the SFC itself is denoted as an n-times
unicast SFC. As an example, consider the chaining of a set of n unicast SFC. As an example, consider the chaining of a set of n
clients to a single video server. Each sub-SFC from an individual clients to a single video server. Each sub-SFC from an individual
client to the video server will semantically result in a unicast client to the video server will semantically result in a unicast
response from the server back to the client (e.g., carrying the response from the server back to the client (e.g., carrying the
video chunk for a MPEG DASH-based video stream). When combining video chunk for a MPEG DASH-based video stream). When combining
the sub-SFCs to the single SFC with n times unicast relations to the sub-SFCs to the single SFC with n times unicast relations to
the server, the SRR will deliver the responses from the server via the server, the SRR will deliver the responses from the server via
one or more multicast responses to one or more clients. The size one or more multicast responses to one or more clients. The size
of the individual multicast groups will depend on the of the individual multicast groups will depend on the
synchronicity of the client requests (and therefore on the synchronicity of the client requests (and therefore on the
synchronicity of the server responses). Note that the multicast synchronicity of the server responses). Note that the multicast
relations here are ad-hoc created by ORing the bitarrays relations here are ad-hoc created by ORing the bitarrays
representing the specific clients to which the responses are meant representing the specific clients to which the responses are meant
to be sent. This is illustrated in the figure below. The HTTP to be sent. This is illustrated in the figure below. The HTTP
multicast use case is being presented in the BIER use case draft multicast use case is being presented in the BIER use case draft
[I-D.ietf-bier-use-cases]albeit without specific a SFC relation. [I-D.ietf-bier-use-cases]albeit without specific a SFC relation.
+---------+ +---------+ +---------+ +---------+
| | | | 10010011 00000010 +--------+ | | | | +--------+
+IP only +---+ ICN +--------| | ICN | +IP only +---+ ICN + 00000010 | ICN |
|reciever | | NAP1 | | |-----------| NAP3 | |receiver | | SR1 | |--------| SR3 |
|UE | +---------+ | | +---||---+ |UE | +----|----+ | +---||---+
+---------+ | | || +---------+ | 10010011 | ||
+----------+ +----------+ |-----||-------| +-----|----+ +----------+ |-----||-----|
| | | | | Cloud | | | | | | Cloud |
|SDN Switch|---|SDN Switch| | | |SDN Switch|---|SDN Switch| | |
| | | | |---||---| | | | | |--||--|
+----------+ +----------+ || +----|-----+ +----------+ ||
| || | 10100011 ||
+---------+ +---------+ | +----||------+ +---------+ +---|-----+ +----||----+
| | | | | | | | | | | | |
+IP only +---+ ICN +---------| + IP only + +IP only +---+ ICN + + IP only +
|sender UE| | NAP2 | 10100011 | Server | |sender UE| | SR2 | | Server |
+---------+ +---------+ +------------+ +---------+ +---------+ +----------+
Figure 7: Illustration of Bitfield-based Forwarding using SDN Figure 7: Illustration of Bitfield-based Forwarding using SDN
7. Protocol Consideration 7. Protocol Consideration
For the operations outlined in the previous section, we foresee the For the operations outlined in the previous section, we foresee the
following protocol changes are required: following protocol changes are required:
o NAP-to-NAP protocol for HTTP: HTTP based message exchange between o SR-to-SR protocol for HTTP: HTTP based message exchange between
client and server NAPs client and server SRs
o NAP-PCE protocol: Used for path computation, obtaining routing o SR-PCE protocol: Used for path computation, obtaining routing
information as well as provide path updates information as well as provide path updates
o Overlay transport protocol: Used for transport-level exchange over
any underlay network
o Registration protocol: Used to register FQDN service endpoints o Registration protocol: Used to register FQDN service endpoints
o Content certificate distribution protocol: Used for HTTPS support 8. Next Steps
8. IANA Considerations Feedback from the SFC WG on the validity of this solution and its
scope within the SFC WG. If such alternative to the re-
classification for service indirection is seen beneficial as well as
fitting with the charter of the WG, the next steps would be to update
the draft to outline potential protocol solutions required for the
realization of such SRR SF.
9. IANA Considerations
This document requests no IANA actions. This document requests no IANA actions.
9. Security Considerations 10. Security Considerations
TBD. TBD.
10. Informative References 11. Informative References
[ETSI_MEC] [ETSI_MEC]
ETSI, "Mobile Edge Computing (MEC), Technical ETSI, "Mobile Edge Computing (MEC), Technical
Requirements", GS MEC 002 1.1.1, March 2016, Requirements", GS MEC 002 1.1.1, March 2016,
<http://www.etsi.org/deliver/etsi_gs/ <http://www.etsi.org/deliver/etsi_gs/
MEC/001_099/002/01.01.01_60/gs_MEC002v010101p.pdf>. MEC/001_099/002/01.01.01_60/gs_MEC002v010101p.pdf>.
[H2020FLAME]
EU, "EU H2020 FLAME PROJECT", , March 2016,
<https://www.ict-flame.eu/>.
[I-D.ietf-bier-use-cases] [I-D.ietf-bier-use-cases]
Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C.
Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases", Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-06
draft-ietf-bier-use-cases-05 (work in progress), July (work in progress), January 2018.
2017.
[I-D.ietf-sfc-dc-use-cases] [I-D.ietf-sfc-dc-use-cases]
Kumar, S., Tufail, M., Majee, S., Captari, C., and S. Kumar, S., Tufail, M., Majee, S., Captari, C., and S.
Homma, "Service Function Chaining Use Cases In Data Homma, "Service Function Chaining Use Cases In Data
Centers", draft-ietf-sfc-dc-use-cases-06 (work in Centers", draft-ietf-sfc-dc-use-cases-06 (work in
progress), February 2017. progress), February 2017.
[I-D.ietf-sfc-nsh]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-27 (work in progress),
October 2017.
[Khalili2016] [Khalili2016]
Khalili, R., Poe, W., Despotovic, Z., and A. Hecker, Khalili, R., Poe, W., Despotovic, Z., and A. Hecker,
"Reducing State of SDN Switches in Mobile Core Networks by "Reducing State of SDN Switches in Mobile Core Networks by
Flow Rule Aggregation", ICCCN, August, 2016. Flow Rule Aggregation", ICCCN, August, 2016.
[Reed2016] [Reed2016]
Reed, M., Al-Naday, M., Thomas, N., Trossen, D., and S. Reed, M., Al-Naday, M., Thomas, N., Trossen, D., and S.
Spirou, "Reducing State of SDN Switches in Mobile Core Spirou, "Reducing State of SDN Switches in Mobile Core
Networks by Flow Rule Aggregation", ICC 2016, 2016. Networks by Flow Rule Aggregation", ICC 2016, 2016.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc7498>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[UKNIC] UK NIC, "5G Infrastructure Requirements in the UK", Final
Report 3.0, December 2016,
<https://www.gov.uk/government/uploads/system/uploads/
attachment_data/
file/577940/5G_Infrastructure_requirements_for_the_UK_-
_LS_Telcom_report_for_the_NIC.pdf>.
Authors' Addresses Authors' Addresses
Debashish Purkayastha Debashish Purkayastha
InterDigital Communications, LLC InterDigital Communications, LLC
Conshohocken Conshohocken
USA USA
Email: Debashish.Purkayastha@InterDigital.com Email: Debashish.Purkayastha@InterDigital.com
Akbar Rahman Akbar Rahman
InterDigital Communications, LLC InterDigital Communications, LLC
Montreal Montreal
 End of changes. 59 change blocks. 
238 lines changed or deleted 399 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/