Differentiated Network-Located Function Chaining
FrameworkFrance TelecomRennes35000Francemohamed.boucadair@orange.comFrance TelecomRennes35000Francechristian.jacquenet@orange.comAffirmed NetworksActon,MAUSARon_Parker@affirmednetworks.comTelefonica I+DDon Ramon de la Cruz, 82Madrid28006Spain+34 913 129 041diego@tid.esJuniper Networks1194 N. Mathilda Ave.Sunnyvale,CA 94089USApyegani@juniper.netnetwork function chaining, overlay, flexibility, adaptability,
elasticityIP networks rely more and more on the combination of advanced
functions (besides the basic routing and forwarding functions). This
document defines a solution to enforce Network-Located Function Chaining
(NLFC) with minimum requirements on the underlying network.The proposed solution allows for Differentiated Forwarding
(DiffForward): packets are classified at the entry point of an
NLFC-enabled network, and are then forwarded on a per NLFC map
basis.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.IP networks rely more and more on the combination of advanced
functions (besides the basic routing and forwarding functions).
Typical examples of such functions include firewall (e.g., ), DPI (Deep Packet Inspection), LI (Lawful
Intercept) module, NAT44 , NAT64 , DS-Lite AFTR ,
NPTv6 , HOST_ID injection, HTTP Header
Enrichment function, TCP tweaking and optimization functions,
transparent caching, charging function, load-balancer, etc.Such advanced functions are denoted NLF (Network-Located Function)
in this document.The major concern is how to provide differentiated forwarding for
packets entering a network enabling advanced network functions.
Differentiation is ensured by tweaking the set of network functions to
be invoked. How to bind a packet to a forwarding plane is
policy-based.This document defines a framework to enforce Network-Located
Function Chaining (NLFC) with minimum requirements on the underlying
network. The proposed solution allows for Differentiated Forwarding
(DiffForward): packets are classified at the entry point of an
NLFC-enabled network, and are then forwarded on a per NLFC map
basis.This document does not make any assumption on the deployment
context. The proposed framework covers both fixed and mobile networks
(e.g., to rationalize the proliferation of advanced features at the Gi
Interface ).The main objectives of the proposed framework are as follows:Efficiently master the chained activation of network-located
functions, regardless of the underlying network topology and
routing policies.Allow for differentiated packet forwarding by selecting the set
of network-located functions to be invoked.Allow to easily change the chronology of the activation of
network-located functions to be invoked.Allow to easily change the set of network-located functions to
be invoked.Ease withdrawal of network-located functions and minimize any
subsequent topology upgrade.Automate the overall process of generating and enforcing
policies to accommodate a set of network connectivity
objectives.The following assumptions are made:Not all NLFs can be characterized with a standard definition in
terms of technical description, detailed specification, etc.There is no global nor standard list of NLFs enabled in a given
administrative domain. The set of NLFs varies on a per deployment
basis.There is no global nor standard NLF chaining logic. The ordered
set of NLFs that need to be activated to deliver a given
connectivity service is specific to each administrative
entity.The chaining of NLFs and the criteria to invoke some of them
are local to each administrative entity that operates a
connectivity network (also called administrative domain).NLF chaining logic and related policies should not be exposed
outside a given administrative domain.Several NLF chaining logics can be simultaneously enforced
within an administrative domain to meet business requirements.No assumption is made on how FIBs and RIBs of involved nodes
are populated.How to bind the traffic to a given NLF chaining is
policy-based.Given the assumptions listed in ,
the rationale of the framework is as follows:The framework separates the dynamic provisioning of required
NLF functions from packet handling operations (e.g., forwarding
decisions).NLFs are handled as black-boxes; the technical characterization
of each NLF is not required.No IANA registry is required to store the list of NLFs.No IANA registry is required to store the NLF chaining
candidates.No frozen NLF chaining is assumed. The definition of NLF chains
is an information that will be processed by the nodes that
participate to the delivery of a network service. The set of
listed/chained NLF functions is generated by each administrative
entity operating the network.NLF handling is policy-based: NLF chains can be updated or
deleted, new NLFs can be added without any impact on existing
NLFs, etc. This design choice is compliant with the global
framework discussed in .For the sake of efficiency, policy enforcement is automated
(but the policies can be enforced using other methods).To minimize fragmentation, a minimal set of information needs
to be signaled (possibly in data packets).Advanced features (e.g., load balancing objectives) are also
policy-based. Invoked enforcement points are not aware of such
objectives.NLFs can be embedded in nodes that intervene in the transport
service or be embedded in dedicated nodes (e.g., dedicated
servers). The decision to implement one of these two models is
deployment-specific and it is orthogonal to the overall
procedure.Multiple NLFC-enabled domains can be deployed within the same
administrative domain. Nodes are provisioned with the policy table
of the NLFC-enabled domain they belong to.The overall consistency is ensured by the PDP.The PDP can be responsible to enforce other policies than the
NLFC Policy Tables. This document makes use of the following terms:DiffForward: refers to the differentiated forwarding procedure as
specified in this document.NLF (Network-Located Function): refers to a function which is
enabled in the network operated by an administrative entity. NLF can
be for example: firewall (e.g., ), DPI
(Deep Packet Inspection), LI (Lawful Intercept) module, NAT44 , NAT64 ,
DS-Lite AFTR , NPTv6 , HOST_ID injection, HTTP Header Enrichment
function, TCP optimizer, load-balancer, etc. This document does not
make any assumption on the enabled NLFs.NLFC-enabled domain: denotes a network (or a region thereof) that
implements DiffForward.NLF Identifier: is a unique identifier that identifies
unambiguously a NLF within an NLFC-enabled domain. NLF Identifiers
are assigned, configured and managed by the administrative entity
operating an NLFC-enabled domain. NLF identifiers can be structured
as strings; other formats can be used. NLF Identifiers are not
required to be globally unique nor be exposed to or used by another
NLF-enabled domain.NLFC Map: refers to an ordered list of NLF identifiers. Each NLFC
Map is identified with a unique identifier called NLFC Map
Index.NLFC Policy Table: is a table containing a list of NLFC Maps,
NLFC classification rules and Locators for all NLF Nodes. NLFC
Policy Table may contain a default NLFC Map.NLFC Boundary Node (or Boundary Node): denotes a node that
connects one NLFC-enabled domain to a node either located in another
NLFC-enabled domain or in a domain that is NLFC-unaware.NLFC Egress Node (or Egress Node): denotes a NLFC Boundary Node
that handles traffic which leaves the NLFC-enabled domain the Egress
Node belongs to.NLFC Ingress Node (or Ingress Node): denotes a NLFC Boundary Node
that handles traffic which enters the NLFC-enabled domain the
ingress Node belongs to.NLF Node: denotes any node within an NLFC-enabled domain that
embeds one or multiple NLFs.Legacy Node (Node for short): refers to any node that is not a
NLF Node nor NLFC Boundary Node. This node can be located within a
NLFC-enabled domain or outside a NLFC-enabled domain.NLFC Classifier (or Classifier): an entity which classifies
packets based on the content of packet headers according to
classification rules defined in a NLFC Policy Table. Packets are
then marked with the corresponding NLFC Map Index. NLFC Classifier
is embedded in a NLFC Boundary Node. An NLFC Classifier may be
identified by a dedicated NLF Identifier.The administrative entity that operates a NLFC-enabled domain
maintains a local repository that lists the enabled NLFs. This
administrative entity assigns a unique NLF identifier for each
NLF.NLF identifiers can be structured as strings or any other format.
The main constraint on the format is that two NLFs MUST be assigned
with different identifiers. NLF identifiers are case-sensitive.A NLF may be embedded in one or several NLF Nodes. The NLF locator
is typically the IP address or the FQDN to reach a given NLF Node.The use of an IP address is RECOMMENDED to ovoid overloading NLF
Nodes with name resolution capabilities. Resolution capabilities
(together with advanced traffic engineering functions) are supported
by the PDP (Policy Decision Point). In the rest of the document, we
assume a NLF locator is structured as an IP address (IPv4 or
IPv6).A NLF can be multi-instantiated; as such one or more locators may
be bound to the same NLF.Added-value services delivered to end-user rely on the invocation
of several NLFs. For each of these services, the administrative entity
that operates an NLFC-enabled domain builds one or several NLFC Maps.
Each of these maps characterizes the list of NLFs to be invoked with
their exact invocation order.Each NLFC Map is unambiguously identified with a unique identifier
called NLFC Map Index. The NLFC Map Index MUST be expressible as an
unsigned integer.Distinct chains can be applied for inbound and outbound traffic.
The direction of the traffic is not included as an attribute of the
NLFC Map, but directionality may be implemented using two chains:
i.e., two NLFC Maps are installed in the NLFC Policy Table. In such
case, incoming packets are marked with Index_1 while outgoing packets
will be forwarded according to a distinct NLFC Map identified with
Index_2.An example of NLFC Map to handle IPv6 traffic destined to an IPv4
remote server is defined as follows: {15, {IPv6_Firewall, HOST_ID_Inject, NAT64}}.To handle incoming packets destined to the same IPv6 host,
the following NLFC Map can be defined:{10, {IPv4_Firewall, NAT64}}.A PDP (Policy Decision Point, ) is
the central entity which is responsible for maintaining NLFC Policy
Tables, and enforcing appropriate policies in NLF Nodes and NLFC
Boundary Nodes (see ). Policy enforcement
can be achieved using a variety of protocols (e.g., NETCONF ).One or multiple NLFC-enabled domains may be under the
responsibility of the same PDP. Delimiting the scope of each
NLFC-enabled domain is under the responsibility of the administrative
entity operating the network. The NLF Node MUST be provisioned with the following
information:Local NLF Identifier(s): This information is required for an
NLF to identify itself within an NLFC Map.List of NLFC Maps: The PDP may configure the full list (default
mode) or only as subset of NLFC Maps in which the local NLF is
involved (see ).List of NLF Locators: The PDP may configure the full list of
locators (default mode) or only the locators of next hop NLFs of
NLFC Maps in which the local NLF is involved (see ).Likewise, the NLFC Boundary Node MUST be provisioned with the
following information:List of NLFC MapsList of NLF LocatorsList of NLFC Map Classification Rules (see Section ).In addition to the NLFC Policy Table, other NLF-specific policies
can be installed by the PDP (e.g., configure distinct users
profiles).Policies managed and stored by the PDP may be configured to the PDP
manually or be triggered by dynamic means (e.g., AAA).In the event of any update (e.g., define a new NLFC Map, delete an
NLFC Map, add a new NLF Locator, update classification policy), the
PDP MUST enforce the updated policy configuration in all NLF Nodes and
NLFC Boundary Nodes.Load-balancing among several NLF Nodes supporting the same NLF can
be driven by the PDP. Indeed, the PDP can generate multiple
classification rules and NLFC Maps to meet load-balancing
objectives.The processing of packets by the nodes that belong to a
NLFC-enabled domain does not necessarily require any interaction with
the PDP, depending on the nature of the NLF supported by the nodes and
the corresponding policies to be enforced. For example, traffic
conditioning capabilities are typical
NLF functions that may require additional solicitation to the PDP for
the NLF node to decide what to do with some out-of-profile
traffic.The behavior of each node of a NLFC-enabled domain is specified in
the following sections. We assume that the provisioning operations
discussed in have succeeded.NLFC Boundary Nodes act both as a NLFC Ingress Node and as a NLFC
Egress Node for the respective directions of the traffic.Traffic enters a NLFC-enabled domain at a NLFC Ingress Node () and exists the domain at a NLFC Egress Node
().The NLFC Classifier classifies packets based on (some of) the
contents of the packet header. Concretely, it classifies packets based
on the value of a combination of one or more header fields, such as
source address, destination address, DS field, protocol ID, source
port and destination port numbers, and any other information.Each NLFC Map Classification Rule MUST be bound to one single NLFC
Map (i.e., the classification rule must include only one NLFC Map
Index).When a packet is received through an interface of the NLFC Ingress
Node that connects to the outside of the NLFC domain, the Ingress Node
MUST:Inspect the received packet and strip any existing NLFC Map
Index.Check if the received packet matches an existing classification
rule (see ).If no rule matches, forward the packet to the next hop
according to legacy forwarding behavior (e.g., based upon the IP
address conveyed in the DA field of the header).If a rule matches, proceed to the following:Retrieve the locator of the first NLF as indicated in the
NLFC Map entry the rule matches.Check whether the corresponding NLF node is an immediate
neighbor. If so, update the packet with the NLFC Map Index of
NLFC Map entry it matches and then forward the packet to
the corresponding NLF Node.If not, (1) encapsulate the original packet into a new
one destined to the corresponding NLF node, (2) update the
encapsulated packet with the NLFC Map Index of NLFC Map
entry it matches, and (3) forward the packet to the next
hop to reach the first NLF node.As a result of this process, the packet will be sent to an
NLF Node or an Intermediate Node.When a packet is received through an interface that connects the
NLFC Egress Node to its NLFC domain, the Egress Node MUST:Strip any existing NLFC Map Index.Forward the packet according to legacy forwarding policies.This section assumes the NLF Nodes does not embed a Classifier as
discussed in .When a packet is received by a NLF Node, the latter MUST:Check if the packet conveys a NLFC Map Index.If no NLFC Map Index is included, forward the packet according
to legacy forwarding policies.If the packet conveys a NLFC Map Index, Retrieve the corresponding NLFC Map from the NLFC Policy
Table.Check if the local NLF Identifier is present in the NLFC
Map:If not, forward the packet according to legacy
forwarding policies.If so, the packet is decapsulated (if needed) and then
presented as an input to the local NLF. In case several
NLFs are co-located in the same node, the packet is
processed by all NLFs indicated in the NLFC Map. Once the
packet is successfully handled by local NLF(s), the packet
is forwarded to the next NLF Node in the list or to an
intermediate node (if the local NLFC Node is the last
element in the NLFC Map). If the local NLF node is not the
last one in the NLFC Map, it retrieves the next NLF Node
from the list, retrieve its locator for the NLFC Policy
Table, and forwards the packet to the next hop. If the
local NLF Node is the last element in the NLFC Map, it
forwards the packet to the next hop according to legacy
forwarding policies.An Intermediate Node is any node that does not support any NLF
function and which is located within a NLFC-enabled domain.No modification is required to intermediate nodes to handle
incoming packets. In particular, routing and forwarding are achieved
using legacy procedures.This section discusses two main protocol issues to be handled in
order to deploy DiffForward.A NLFC Map Index is an integer that points to a NLFC Map.In order to avoid all nodes of a NLFC-enabled domain to be
NLF-aware, this specification recommends to undertake classifiers at
boundary nodes while intermediate nodes forward the packets
according to the NLFC Map Index conveyed in the packet (NLF Node) or
according to typical forwarding policies (any NLF-unaware node).An 8-bit field would be sufficient to accommodate deployment
contexts with reasonable set of NLFC Maps. A 16-bit (or 32-bit)
field would provide a comfortable solution (e.g., to accommodate the
requirement discussed in ).Instead of injecting a Map Index, an alternate solution would be
to use SSR IP option or any similar solution to indicate a loose or
strict explicit route. This alternative was not considered because
of the negative impact on the processing and potential fragmentation
issues.Injecting an 8-bit or even 16-bit field would minimize
fragmentation issues.NLFC Map Indexes can be conveyed in various locations of a
packet:At L2 levelDefine a new IP option or a new IPv6 extension headerUse IPv6 Flow LabelRe-use an existing field (e.g., DS field)TCP optionGRE KeyDefine a new shimEtc.A NLFC Ingress Node or an NLF Node MUST be able to forward a packet
matching an existing NLFC Map to a NLF Node. The locator of the next
NLF is retrieved from the NLFC Policy Table. In case the next NLF Node
in the list is not an immediate neighbor, a solution to force the
packet to cross that NLF Node MUST be supported. This document
suggests the use of IP-in-IP encapsulation scheme. Other tunneling
solutions can be considered in the future.The following deployment considerations should be taken into
account:Avoid inducing severe path stretch compared to the path
followed if no NLF is involved.Minimize path computation delays: due to enforcement of
classification rules in all participating nodes, misconception of
network-located function chaining, inappropriate choice of nodes
elected to embed network-located functions, etc.Avoid NLF invocation loops: the design of NLF chainings should
minimize as much as possible NLF invocation loops. Note, means to
prevent NLF loops may be enabled in each NLF Node (see ).Some NLFs may be provisioned with a set of local differentiated
policies (denoted as profiles). For example, an NLF realizing DPI may
be configured to block Peer-to-Peer protocols for some group of users
while authorize it for another group of users.The profile selection policy can be local to a NLF or be controlled
by the PDP. In the latter case, distinct NLF identifiers can be
assigned for each profile. Doing so, the PDP conveys to the NLF the
profile to be enforced for received traffic.If NLF Nodes are also configured to behave as Classifiers, NLFC Map
Index is not required to be explicitly signalled in each packet.
Concretely, the NLFC Policy Table configured to the NLF Node includes
also classification rules. These classification rules are enforced to
determine whether the local NLF must be involved. If an incoming
packet matches at least one classification rule pointing to an NLFC
Map in which the NLF Identifier is listed, the NLF Node retrieves the
next hop NLF from the NLF Map indicated in the classification rule,
the packet is handled by the local NLF, and then the NLF Node forwards
the packet to the next hop NLF. If not, the packet is forwarded to the
next hop following legacy forwarding behavior.Let consider the example shown in .
The local NLF Node embeds NLFa. After checking the classification
rules and the NLFC Maps, the NLF Node concludes NLFa must be invoked
only when a packet matches Rule 1 and Rule 3. If a packet matches Rule
1, the next NLF is NLFc. If a packet matches Rule 3, the next NLF is
NLFh.NLF Nodes may be enabled in a NLFC-enabled domain so that each of
them has a direct adjacency with other NLF Nodes. In such
configuration, no additional encapsulation scheme is needed to
exchange traffic between these nodes.NLF Nodes use the NLFC Policy Table to detect whether the local NLF
was already applied for the received packet (i.e., detect NLF Loop).
The NLF Node MUST invoke the local NLF only if the packet is received
from a NLFC Boundary Node or a NLF Node having an identifier listed
before the local NLF in the NLF Map matched by the packet. NLF Loop
detection SHOULD be a configurable feature. shows an example of a NLFC Policy Table
of a NLF Node embedding NLFa. If we consider a packet, received from
Locb, matches Rule 2. NLFa must not be invoked because NLFb is listed
after NLFa (see the NLFC Map list). That packet will be forwarded
without invoking NLFa.The support of this feature is OPTIONAL.If NLF loop detection is not activated in an NLFC-enabled domain,
the PDP may provision to underlying nodes a lite NLFC Policy Table.
Lite NLFC Policy Table is a subset of the full NLFC Policy Table which
includes:Only the NLFC Maps in which the local NLF is involved.Only the next hop NLF instead of the full NLF chain.An example of lite NLFC Policy Table is shown in .Determination by the PDP of liveness of each NLF in the service
chain provides a number of benefits. These include:Enhanced status reporting by the PDP (i.e., an operational
status for any given chain derived from liveness state of its
NLFs).Ability to support various resiliency policies (i.e., bypass
NLF Node, use alternate NLF Node, use alternate chain, drop
traffic, etc.) .Ability to support simple load balancing across multiple NLF
instances that provide equivalent function (although more than
liveness is required for complex load balancing schemes).In order to determine liveness of any particular NLF Node, standard
protocols such as ICMP or BFD (both single-hop and multi-hop )
may be utilized between the PDP and the NLF Nodes.For more sophisticated load-balancing support, protocols that allow
for both liveness determination and the transfer of
application-specific data, such as SNMP and NETCONF may be utilized
between the PDP and the NLF Nodes.The support of this feature is OPTIONAL.Required IANA actions will be discussed in future version of the
document.Means to defend NLFC Boundary Nodes and NLF Nodes against broken NLFC
Policy Table MUST be enabled. For example, authenticated means are to be
used between a PDP and the underlying NLFC elements.NLFC Boundary Nodes MUST strip any existing NLFC Map Index when
handling an incoming packet. A list of authorized NLFC Map Indexes are
configured to the underlying NLFC elements.NETCONF-related security considerations are discussed in .Means to defend against denial-of-service must be supported. Means to
prevent NLF loops should be supported.Nodes involved in the same NLFC-enabled domain MUST be provisioned
with the same NLFC Policy Table. Inconsistencies in this tables will
result in forwarding mis-behavior.Many thanks to D. Abgrall, D. Minodier, Y. Le Le Goff, and D. Cheng
for their review and comments.