Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Standards Track France Telecom
Expires: January 04, 2014 R. Parker
Affirmed Networks
D. Lopez
Telefonica I+D
P. Yegani
Juniper Networks
J. Guichard
P. Quinn
Cisco Systems, Inc.
July 03, 2013
Differentiated Network-Located Function Chaining Framework
draft-boucadair-network-function-chaining-02
Abstract
IP 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.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Boucadair, et al. Expires January 04, 2014 [Page 1]
Internet-Draft NLFC July 2013
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 04, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. On the Proliferation of Network-Located Functions . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. NLFC Provisioning . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Assign NLF Identifiers . . . . . . . . . . . . . . . . . 7
3.2. NLF Locator . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Building NLFC Maps . . . . . . . . . . . . . . . . . . . 8
3.4. Building NLFC Policy Tables . . . . . . . . . . . . . . . 8
4. Theory Of Operation . . . . . . . . . . . . . . . . . . . . . 10
4.1. NLFC Boundary Node . . . . . . . . . . . . . . . . . . . 10
4.2. Classifier . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. NLFC Ingress Node . . . . . . . . . . . . . . . . . . . . 10
4.4. NLFC Egress Node . . . . . . . . . . . . . . . . . . . . 11
4.5. NLF Node . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Intermediate Nodes . . . . . . . . . . . . . . . . . . . 12
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 12
5.1. Transmit A NLFC Map Index In A Packet . . . . . . . . . . 12
5.1.1. NLFC Map Index . . . . . . . . . . . . . . . . . . . 12
5.1.2. Why Not Loose Or Strict Source Routing (SSR)? . . . . 13
5.1.3. Where To Store NLFC Map Indexes In A Packet? . . . . 13
Boucadair, et al. Expires January 04, 2014 [Page 2]
Internet-Draft NLFC July 2013
5.2. Steer Paths To Cross Specific NLF Nodes . . . . . . . . . 13
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 13
6.1. Generic Requirements . . . . . . . . . . . . . . . . . . 13
6.2. NLF Profiles . . . . . . . . . . . . . . . . . . . . . . 14
6.3. NLF Node Is Also A Classifier . . . . . . . . . . . . . . 14
6.4. Direct Adjacency . . . . . . . . . . . . . . . . . . . . 15
6.5. NLF Loops . . . . . . . . . . . . . . . . . . . . . . . . 15
6.6. Lightweight NLFC Policy Table . . . . . . . . . . . . . . 16
6.7. Liveness Detection Of NLFs By The PDP . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
1.1. On the Proliferation of Network-Located Functions
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.,
[RFC6092]), DPI (Deep Packet Inspection), LI (Lawful Intercept)
module, NAT44 [RFC3022], NAT64 [RFC6146], DS-Lite AFTR [RFC6333],
NPTv6 [RFC6296], 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 dynamic enforcement of a NLF-derived, adequate forwarding policy
for packets entering a network that supports such advanced network
functions has become a key challenge for operators and service
providers. NLF-inferred differentiated forwarding is ensured by
tweaking the set of network functions to be invoked. How to bind a
flow of packets that share at least one common characteristic to a
forwarding plane is policy-based, and subject to the set of NLF
functions that need to be solicited for the processing of this
specific flow.
Boucadair, et al. Expires January 04, 2014 [Page 3]
Internet-Draft NLFC July 2013
1.2. Scope
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 according to the ordered set
of NLF functions that need to be activated to process these packets
in the NLFC-enabled network.
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 [RFC6459]).
1.3. Objectives
The main objectives of the proposed framework are listed below:
o Efficiently master the chained activation of network-located
functions, regardless of the underlying network topology and
routing policies.
o Allow for differentiated packet forwarding by selecting the set of
network-located functions to be invoked.
o Allow to easily change the chronology of the activation of
network-located functions to be invoked.
o Allow to easily change the set of network-located functions to be
invoked.
o Ease management (including withdrawal) of network-located
functions and minimize any subsequent topology upgrade.
o Automate the overall process of generating and enforcing policies
to accommodate a set of network connectivity service objectives.
1.4. Assumptions
The following assumptions are made:
o Not all NLFs can be characterized with a standard definition in
terms of technical description, detailed specification,
configuration, etc.
o There is no global nor standard list of NLFs enabled in a given
administrative domain. The set of NLFs varies as a function of
the service to be provided and according to the networking
environment.
o 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.
Boucadair, et al. Expires January 04, 2014 [Page 4]
Internet-Draft NLFC July 2013
o The chaining of NLFs and the criteria to invoke some of them are
specific to each administrative entity that operates the NLF-
enabled network (also called administrative domain).
o NLF chaining logic and related policies should not be exposed
outside a given administrative domain.
o Several NLF chaining logics can be simultaneously enforced within
an administrative domain to meet various business requirements.
o No assumption is made on how FIBs and RIBs of involved nodes are
populated.
o How to bind the traffic to a given NLF chaining is policy-based.
1.5. Rationale
Given the assumptions listed in Section 1.4, the rationale of the
framework is as follows:
o The framework separates the dynamic provisioning of required NLF
functions from packet handling operations (e.g., forwarding
decisions).
o NLFs are handled as black boxes; the technical characterization of
each NLF is not required.
o No IANA registry is required to store the list of NLFs.
o No IANA registry is required to store the NLF chaining candidates.
o No specific NLF chaining is assumed. The description 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.
o NLF handling is policy-based: NLF chains can be updated or
deleted, new NLFs can be added without any impact on existing
NLFs, etc. In particular, this design is compliant with the
global framework discussed in [I-D.sin-sdnrg-sdn-approach].
o For the sake of efficiency, policy enforcement is automated (but
policies can be statically enforced, for example).
o To minimize fragmentation, a minimal set of information needs to
be signaled (possibly in data packets).
o Advanced features (e.g., load balancing) are also described and
configured according to policies that can be service-specific.
Policy decisions are made by a Policiy Decision Point [RFC2753]
and the solicited enforcement points are responsible for applying
these decisions, whatever the objective to achieve.
o NLFs can be embedded in nodes that intervene in the transport
service or supported by dedicated nodes (e.g., dedicated servers).
The decision to implement one of these two models (or a
combination thereof) is deployment-specific and it is orthogonal
to the overall procedure.
Boucadair, et al. Expires January 04, 2014 [Page 5]
Internet-Draft NLFC July 2013
o 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.
o The overall consistency of the differentiated forwarding policy is
ensured by the PDP.
o The PDP can be responsible to enforce other policies than those
described in the NLFC Policy Tables.
2. Terminology
This document makes use of the following terms:
o DiffForward: refers to the differentiated forwarding procedure as
specified in this document.
o 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., [RFC6092]), DPI (Deep Packet
Inspection), LI (Lawful Intercept) module, NAT44 [RFC3022], NAT64
[RFC6146], DS-Lite AFTR [RFC6333], NPTv6 [RFC6296], HOST_ID
injection, HTTP Header Enrichment function, TCP optimizer, load-
balancer, etc. This document does not make any assumption on the
enabled NLFs.
o NLFC-enabled domain: denotes a network (or a region thereof) that
implements DiffForward.
o NLF Identifier: is a unique identifier that unambiguously
identifies a NLF within a NLFC-enabled domain. NLF Identifiers
are assigned, configured and managed by the administrative entity
that operates the 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.
o NLFC Map: refers to an ordered list of NLF identifiers. Each NLFC
Map is identified with a unique identifier called NLFC Map Index.
o NLFC Policy Table: is a table containing a list of NLFC Maps, NLFC
classification rules and Locators for all NLF Nodes. A NLFC
Policy Table may contain a default NLFC Map.
o 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.
Boucadair, et al. Expires January 04, 2014 [Page 6]
Internet-Draft NLFC July 2013
o 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.
o 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.
o NLF Node: denotes any node within an NLFC-enabled domain that
embeds one or multiple NLFs.
o NLF Locator: A NLF Node identifier used to reach the said NLF
node. A locator is typically an IP address or a FQDN.
o Legacy Node (Node for short): refers to any node that is not a NLF
Node nor a NLFC Boundary Node. This node can be located within a
NLFC-enabled domain or outside a NLFC-enabled domain.
o NLFC Classifier (or Classifier): an entity which classifies
packets based on the packet header contents 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. A NLFC Classifier
may be identified by a dedicated NLF Identifier.
3. NLFC Provisioning
3.1. Assign NLF Identifiers
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.
3.2. NLF Locator
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 avoid any extra complexity
related to the support of name resolution capabilities in NLF Nodes.
Resolution capabilities 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).
Boucadair, et al. Expires January 04, 2014 [Page 7]
Internet-Draft NLFC July 2013
A NLF Node can be reached by one or more locators, which may
therefore be bound to the same NLF.
3.3. Building NLFC Maps
Added-value services delivered to the 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 the NLFC Map Index. The NLFC Map Index MUST be described as
an unsigned integer.
Distinct chains can be applied for inbound and outbound traffic. The
directionality of traffic is not included as an attribute of the NLFC
Map, but it may be implicitly described by using two NLFC Maps
installed and maintained in the NLFC Policy Table. In such case,
incoming packets would be marked with Index_1 for example, while
outgoing packets would 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}}.
3.4. Building NLFC Policy Tables
A PDP (Policy Decision Point, [RFC2753]) is the central entity which
is responsible for maintaining NLFC Policy Tables (Figure 1), and
enforcing appropriate policies in NLF Nodes and NLFC Boundary Nodes
(Figure 1). PDP-made decisions can be forwarded to the participating
nodes by using a variety of protocols (e.g., NETCONF [RFC6241]).
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 that operates
the NLF-enabled network.
o . . . . . . . . . . . . . . . . . . . . . . . o
. NLFC Policy Enforcement .
Boucadair, et al. Expires January 04, 2014 [Page 8]
Internet-Draft NLFC July 2013
. +-------+ .
. | |-----------------+ .
. +-------| PDP | | .
. | | |-------+ | .
. | +-------+ | | .
o . . | . . . . . | . . . . . | . . . . | . . . o
o . . | . . . . . | . . . . . | . . . . | . . . o
. | | | | .
. v v v v .
. +---------+ +---------+ +-------+ +-------+ .
. |NLFC_BN_1| |NLFC_BN_n| | NLF_1 | | NLF_m | .
. +---------+ +---------+ +-------+ +-------+ .
. NLFC-enabled Domain .
o . . . . . . . . . . . . . . . . . . . . . . . o
Figure 1: NLFC Policy Enforcement Scheme.
The NLF Node MUST be provisioned with the following information:
o Local NLF Identifier(s): This information is required for an NLF
to identify itself within an NLFC Map.
o List of NLFC Maps: The PDP may configure the full list (default
mode) or only as subset of NLFC Maps in which a NLF supported by
the local NLF node is involved (see Section 6.6).
o 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 a NLF supported by the local NLF node is
involved (see Section 6.6).
Likewise, the NLFC Boundary Node MUST be provisioned with the
following information:
o List of NLFC Maps
o List of NLF Locators
o List of NLFC Map Classification Rules (see Section Section 4.2).
In addition to the NLFC Policy Table, other NLF-specific policies can
be installed by the PDP (e.g., configure distinct user profiles,
activate specific traffic filters, configure traffic conditioners,
etc.).
Policies managed by the PDP may be statically instantiated or
dynamically triggered by external means (e.g., a AAA server).
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 forward the updated policy configuration information in all
relevant NLF Nodes and NLFC Boundary Nodes.
Boucadair, et al. Expires January 04, 2014 [Page 9]
Internet-Draft NLFC July 2013
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 [RFC2475] are typical NLF functions that
may require additional solicitation of the PDP for the NLF node to
decide what to do with some out-of-profile traffic.
4. Theory Of Operation
The behavior of each node of a NLFC-enabled domain is specified in
the following sections. We assume that the provisioning operations
discussed in Section 3 have been successful (i.e., NLF functions have
been adequately configured according to the (service-specific) policy
to be enforced).
4.1. NLFC Boundary Node
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
(Section 4.3) and exits the domain at a NLFC Egress Node
(Section 4.4).
4.2. Classifier
The NLFC Classifier classifies packets based on (some of) the
contents of the packet header. Concretely, it classifies packets
based on the possible 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).
4.3. NLFC Ingress Node
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:
o Inspect the received packet and strip any existing NLFC Map Index.
Boucadair, et al. Expires January 04, 2014 [Page 10]
Internet-Draft NLFC July 2013
o Check whether the received packet matches an existing
classification rule (see Section 4.2).
o 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).
o If a rule matches, proceed with the following operations:
* 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
that will be forwarded 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.
4.4. NLFC Egress Node
When a packet is received through an interface that connects the NLFC
Egress Node to its NLFC domain, the Egress Node MUST:
o Strip any existing NLFC Map Index.
o Forward the packet according to legacy forwarding policies.
4.5. NLF Node
This section assumes the NLF Nodes does not embed a Classifier as
discussed in Section 6.3.
When a packet is received by a NLF Node, the NLF Node MUST:
o Check whether the packet conveys a NLFC Map Index.
o If no NLFC Map Index is included, forward the packet according to
legacy forwarding policies.
o If the packet conveys a NLFC Map Index,
* Retrieve the corresponding NLFC Map from the NLFC Policy Table.
* Check whether the local NLF Identifier is present in the NLFC
Map:
Boucadair, et al. Expires January 04, 2014 [Page 11]
Internet-Draft NLFC July 2013
+ 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.
4.6. Intermediate Nodes
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.
5. Design Considerations
This section discusses two main protocol issues to be handled in
order to deploy DiffForward.
5.1. Transmit A NLFC Map Index In A Packet
5.1.1. NLFC Map Index
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
that assume a reasonable set of NLFC Maps. A 16-bit (or 32-bit)
field would be more flexible (e.g., to accommodate the requirement
discussed in Section 6.2).
Boucadair, et al. Expires January 04, 2014 [Page 12]
Internet-Draft NLFC July 2013
5.1.2. Why Not Loose Or Strict Source Routing (SSR)?
Instead of injecting a Map Index, an alternate solution would be to
use the SSR IPv4 option or any similar solution to indicate a loose
or strict explicit route. This alternative was not considered
because of the likely dramatic impact on the processing and potential
fragmentation issues that may jeopardize the overall performance of
the DiffForward operation.
Injecting an 8-bit or a 16-bit field would minimize fragmentation
issues.
5.1.3. Where To Store NLFC Map Indexes In A Packet?
NLFC Map Indexes can be conveyed in various locations of a packet:
o At L2 level
o Define a new IP option or a new IPv6 extension header
o Use IPv6 Flow Label
o Re-use an existing field (e.g., DS field)
o TCP option
o GRE Key
o Define a new shim
o Etc.
5.2. Steer Paths To Cross Specific NLF Nodes
A NLFC Ingress Node or a NLF Node MUST be able to forward a packet
that macthes an existing NLFC Map to the relevant next hop 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 the IP-in-IP
encapsulation scheme. Other tunneling solutions can be considered in
the future.
6. Deployment Considerations
6.1. Generic Requirements
The following deployment considerations should be taken into account:
o Avoid inducing severe path stretch compared to the path followed
if no NLF is involved.
o Minimize path computation delays: due to the 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., must be avoided.
Boucadair, et al. Expires January 04, 2014 [Page 13]
Internet-Draft NLFC July 2013
o Avoid NLF invocation loops: the design of NLF chainings should
minimize as much as possible NLF invocation loops. Note that
means to prevent NLF loops may be enabled in each NLF Node (see
Section 6.5).
6.2. NLF Profiles
Some NLFs may be provisioned with a set of local differentiated
policies (denoted as profiles). For example, a DPI NLF may be
configured to block Peer-to-Peer (P2P) protocols for some users while
the same P2P services could be authorized for other 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 forwards the traffic-
specific profile to be enforced to the relevant NLF nodes.
6.3. NLF Node Is Also A Classifier
If NLF Nodes are also configured to behave as Classifiers, the NLFC
Map Index is not required to be explicitly signalled in each packet.
Concretely, the NLFC Policy Table maintained by the NLF Node includes
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 then handled by the local NLF, and the NLF Node
subsequently forwards the packet to the next hop NLF. If not, the
packet is forwarded to the next hop according to a typical IP
forwarding policy.
Let us consider the example shown in Figure 2. The local NLF Node
embeds NLFa. Once classification rules and the NLFC Maps are
checked, the NLF Node concludes NLFa must be invoked only when a
packet matches Rules 1 and 3. If a packet matches Rule 1, the next
NLF is NLFc. If a packet matches Rule 3, the next NLF is NLFh.
+-----------------------------------------------+
| NLFC Policy Table |
+-----------------------------------------------+
|Local NLF Identifier: NLFa |
+-----------------------------------------------+
|Classification Rules |
| Rule 1: If DEST=IP1; then NLFC_MAP_INDEX1 |
| Rule 2: If DEST=IP2; then NLFC_MAP_INDEX2 |
| Rule 3: IF DEST=IP3; then NLFC_MAP_INDEX3 |
Boucadair, et al. Expires January 04, 2014 [Page 14]
Internet-Draft NLFC July 2013
+-----------------------------------------------+
|NLFC Maps |
| {NLFC_MAP_INDEX1, {NLFa, NLFc} |
| {NLFC_MAP_INDEX2, {NLFd, NLFb} |
| {NLFC_MAP_INDEX3, {NLFa, NLFh} |
+-----------------------------------------------+
Figure 2: NLFC Policy Table Example.
6.4. Direct Adjacency
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 specific encapsulation scheme is required to
exchange traffic between these nodes.
6.5. NLF Loops
NLF Nodes use the NLFC Policy Table to detect whether the local NLF
was already applied to 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.
Figure 3 shows an example of a NLFC Policy Table of a NLF Node
embedding NLFa. Assume a packet received from Locb that 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.
+-----------------------------------------------+
| NLFC Policy Table |
+-----------------------------------------------+
|Local NLF Identifier: NLFa |
+-----------------------------------------------+
|NLFC Maps |
| {NLFC_MAP_INDEX1, {NLFa, NLFc} |
| {NLFC_MAP_INDEX2, {NLFd, NLFa, NLFb, NLFh} |
+-----------------------------------------------+
|NLFC Locators |
| Locator_NLFb: Locb |
| Locator_NLFc: Locc |
| Locator_NLFd: Locd |
| Locator_NLFh: Loch |
+-----------------------------------------------+
Figure 3: Dealing With NLF Loops.
Boucadair, et al. Expires January 04, 2014 [Page 15]
Internet-Draft NLFC July 2013
The support of this feature is OPTIONAL.
6.6. Lightweight NLFC Policy Table
If NLF loop detection is not activated in an NLFC-enabled domain, the
PDP may provision NLF nodes with a "lightweight" NLFC Policy Table.
A lightweight NLFC Policy Table is a subset of the full NLFC Policy
Table that includes:
o Only the NLFC Maps in which the local NLF is involved.
o Only the next hop NLF instead of the full NLF chain.
An example of a lightweight NLFC Policy Table is shown in Figure 4.
+-----------------------------------------------+
| NLFC Policy Table |
+-----------------------------------------------+
|Local NLF Identifier: NLFa |
+-----------------------------------------------+
|Lite NLFC Maps |
| NLFC_MAP_INDEX1, Next_Hop_NLF = NLFc |
| NLFC_MAP_INDEX2, Next_Hop_NLF = NLFb |
+-----------------------------------------------+
|NLFC Locators |
| Locator_NLFb: Locb |
| Locator_NLFc: Locc |
+-----------------------------------------------+
Figure 4: Lightweight NLFC Policy Table.
6.7. Liveness Detection Of NLFs By The PDP
The ability of the PDP to check the liveness of each NLF invoked in a
service chain has several advantages, including:
o Enhanced status reporting by the PDP (i.e., an operational status
for any given service chain derived from liveness state of its
NLFs).
o Ability to support various resiliency policies (i.e., bypass NLF
Node, use alternate NLF Node, use alternate chain, drop traffic,
etc.) .
o Ability to support load balancing capabilities to solicit multiple
NLF instances that provide equivalent functions.
In order to determine the liveness of any particular NLF Node,
standard protocols such as ICMP or BFD (both single-hop [RFC5881] and
multi-hop [RFC5883]) may be utilized between the PDP and the NLF
Nodes.
Boucadair, et al. Expires January 04, 2014 [Page 16]
Internet-Draft NLFC July 2013
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.
7. IANA Considerations
Required IANA actions will be discussed in future versions of the
document.
8. Security Considerations
Means to protect NLFC Boundary Nodes and NLF Nodes against various
forms of DDoS attacks MUST be supported. For example, mutual PDP and
NLF node authentication should be supported. Means to protect NLF
nodes against malformed, poorly configured (deliberately or not) NLFC
Policy Tables should be supported.
NLFC Boundary Nodes MUST strip any existing NLFC Map Index when
handling an incoming packet. A list of authorized NLFC Map Indexes
are configured in the NLFC elements.
NETCONF-related security considerations are discussed in [RFC6146].
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. Possible table inconsistencies may
result in forwarding errors.
9. Acknowledgments
Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, and D. Cheng for
their review and comments.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
Boucadair, et al. Expires January 04, 2014 [Page 17]
Internet-Draft NLFC July 2013
10.2. Informative References
[I-D.sin-sdnrg-sdn-approach]
Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Service Provider's Perspective", draft-sin-
sdnrg-sdn-approach-03 (work in progress), June 2013.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January
2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
2010.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, June 2010.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, January
2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012.
Boucadair, et al. Expires January 04, 2014 [Page 18]
Internet-Draft NLFC July 2013
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Christian Jacquenet
France Telecom
Rennes 35000
France
Email: christian.jacquenet@orange.com
Ron Parker
Affirmed Networks
Acton, MA
USA
Email: Ron_Parker@affirmednetworks.com
Diego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 82
Madrid 28006
Spain
Phone: +34 913 129 041
Email: diego@tid.es
Parviz Yegani
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
Email: pyegani@juniper.net
Boucadair, et al. Expires January 04, 2014 [Page 19]
Internet-Draft NLFC July 2013
Jim Guichard
Cisco Systems, Inc.
USA
Email: jguichar@cisco.com
Paul Quinn
Cisco Systems, Inc.
USA
Email: paulq@cisco.com
Boucadair, et al. Expires January 04, 2014 [Page 20]