Name-Based Service Function Forwarder (nSFF) Component within aService Function Chaining (SFC) Framework
2019
Adoption of cloud and fog technology allows operators to deploy a
single "Service Function" to multiple "Execution locations". The
decision to steer traffic to a specific location may change frequently
based on load, proximity etc. Under the current SFC framework,
steering traffic dynamically to the different execution end points
require a specific 're-chaining', i.e., a change in the service
function path reflecting the different IP endpoints to be used for the
new execution points. This procedure may be complex and take time. In
order to simplify re-chaining and reduce the time to complete the
procedure, we discuss separating the logical Service Function Path
from the specific execution end points. This can be done by
identifying the Service Functions using a name rather than a routable
IP endpoint (or Layer 2 address). This document describes the
necessary extensions, additional functions and protocol details in SFF
(Service Function Forwarder) to handle name based relationships. This
document presents InterDigital's approach to name-based service
function chaining. It does not represent IETF consensus and is
presented here so that the SFC community may benefit from considering
this mechanism and the possibility of its use in the edge data
centers.
Keywords:
- Correction
- Source
- Cite
- Save
- Machine Reading By IdeaReader
0
References
2
Citations
NaN
KQI