Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Standards Track France Telecom
Expires: December 19, 2013 June 17, 2013
Differentiated Network-Located Function Chaining Framework
draft-boucadair-network-function-chaining-00
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/.
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 December 19, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Boucadair & Jacquenet Expires December 19, 2013 [Page 1]
Internet-Draft NLFC June 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6. Generic Requirements . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. NLFC Provisioning . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Assign NLF Identifiers . . . . . . . . . . . . . . . . . 6
3.2. NLF Locator . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Building NLF Maps . . . . . . . . . . . . . . . . . . . . 7
3.4. Building A NLFC Policy Table . . . . . . . . . . . . . . 7
4. Theory Of Operation . . . . . . . . . . . . . . . . . . . . . 8
4.1. NLFC Boundary Node . . . . . . . . . . . . . . . . . . . 9
4.2. Classifier . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. NLFC Ingress Node . . . . . . . . . . . . . . . . . . . . 9
4.4. NLF Node . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Intermediate Node . . . . . . . . . . . . . . . . . . . . 11
4.6. NLFC Egress Node . . . . . . . . . . . . . . . . . . . . 11
5. Protocol Extensions? . . . . . . . . . . . . . . . . . . . . 11
5.1. Transmit NLFC Map Index In a Packet . . . . . . . . . . . 11
5.1.1. NLFC Map Index . . . . . . . . . . . . . . . . . . . 11
5.1.2. Why Not SSR? . . . . . . . . . . . . . . . . . . . . 11
5.1.3. Where To Store NLFC Map Indexes In A Packet? . . . . 12
5.2. Force the path to cross a NLF Node . . . . . . . . . . . 12
6. Misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. NLF Loops . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Direct Adjacency . . . . . . . . . . . . . . . . . . . . 13
6.3. NLF Node is also a Classifier . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Boucadair & Jacquenet Expires December 19, 2013 [Page 2]
Internet-Draft NLFC June 2013
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, etc.
Such advanced functions are denoted NLF (Network-Located Function) in
this document.
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 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 [RFC6459]).
1.3. Objectives
The main objectives of the proposed framework are as follows:
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 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 objectives.
Boucadair & Jacquenet Expires December 19, 2013 [Page 3]
Internet-Draft NLFC June 2013
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, etc.
o 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.
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.
o 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).
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 business requirements.
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 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.
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. This design choice 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
the policies can be enforced using other methods).
o To avoid fragmentation, a minimal set of information needs to be
signaled (possibly in data packets).
o Advanced features (e.g., load balancing objectives) are also
policy-based. Invoked enforcement points are not aware of such
objectives.
Boucadair & Jacquenet Expires December 19, 2013 [Page 4]
Internet-Draft NLFC June 2013
1.6. Generic Requirements
The followng 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 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.
o 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.
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, 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 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.
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. NLFC Policy
Table may contain a default NLFC Map.
Boucadair & Jacquenet Expires December 19, 2013 [Page 5]
Internet-Draft NLFC June 2013
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.
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 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.
o 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.
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.
In the rest of the document, we assume a NLF locator is structured as
an IP address (IPv4 or IPv6). The use of FQDN is out of scope of
this version of the draft.
Note that one or more locators may be bound to the same NLF.
Boucadair & Jacquenet Expires December 19, 2013 [Page 6]
Internet-Draft NLFC June 2013
3.3. Building NLF Maps
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. In addition to the NLF list, an NLFC
Map is built with a unique identifier called NLFC Map Index.
Inbound and Outbound NLFC Maps are both configured. Incoming packets
will be tagged with an 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:
{IPv6_Firewall; HOST_ID_Inject; NAT64}.
To handle incoming packets destined to the same IPv6 host, the
following NLFC Map can be defined:
{IPv4_Firewall; NAT64}.
3.4. Building A NLFC Policy Table
A PDP (Policy Decision Point, [RFC2753]) is the central entity which
is responsible for maintaining a NLFC Policy Table, and enforcing
appropriate policies in NLF Nodes and NLFC Boundary Nodes (see Figure
1). Policy enforcement can be achieved using a variety of protocols
(e.g., NETCONF [RFC6241]).
o . . . . . . . . . . . . . . . . . . . . . . . o
. NLFC Policy Enforcement .
. +-------+ .
. | |-----------------+ .
. +-------| PDP | | .
. | | |-------+ | .
. | +-------+ | | .
o . . | . . . . . | . . . . . | . . . . | . . . o
o . . | . . . . . | . . . . . | . . . . | . . . o
. | | | | .
. v v v v .
. +---------+ +---------+ +-------+ +-------+ .
. |NLFC_BN_1| |NLFC_BN_n| | NLF_1 | | NLF_m | .
. +---------+ +---------+ +-------+ +-------+ .
. NLFC-enabled Domain .
o . . . . . . . . . . . . . . . . . . .|. . . . o
Boucadair & Jacquenet Expires December 19, 2013 [Page 7]
Internet-Draft NLFC June 2013
Figure 1: NLFC Policy Enforcement
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
o List of NLF Locators
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 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 [RFC2475] 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.
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 succeeded.
Boucadair & Jacquenet Expires December 19, 2013 [Page 8]
Internet-Draft NLFC June 2013
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
exists the domain at a NLFC Egress Node (Section 4.6).
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 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).
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.
o Check if 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 (i.e., based upon the IP address
conveyed in the DA field of the header).
o 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
Boucadair & Jacquenet Expires December 19, 2013 [Page 9]
Internet-Draft NLFC June 2013
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 NLFC Node
or an Intermediate Node.
4.4. 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 latter MUST:
o Check if 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 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.
Boucadair & Jacquenet Expires December 19, 2013 [Page 10]
Internet-Draft NLFC June 2013
4.5. Intermediate Node
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.
4.6. 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.
5. Protocol Extensions?
This section discusses two main protocol issues to be handled in
order to deploy DiffForward.
5.1. Transmit 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 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 a large set of NLFC Maps. A 16-bit field would provide a
comfortable solution.
5.1.2. Why Not SSR?
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.
Boucadair & Jacquenet Expires December 19, 2013 [Page 11]
Internet-Draft NLFC June 2013
Injecting an 8-bit or even 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 extension header
o Use IPv6 Flow Label
o Re-use an existing field (e.g., DS field)
o Etc.
5.2. Force the path to cross a NLF Node
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.
6. Misc
6.1. NLF Loops
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.
Figure 2 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.
+-----------------------------------------------+
| NLFC Policy Table |
+-----------------------------------------------+
|Local NLF Identifier: NLFa |
Boucadair & Jacquenet Expires December 19, 2013 [Page 12]
Internet-Draft NLFC June 2013
+-----------------------------------------------+
|Classification Rules |
| Rule 1: If DEST=IP1; then NLFC_MAP_INDEX1 |
| Rule 2: IF DEST=IP3; then NLFC_MAP_INDEX2 |
+-----------------------------------------------+
|NLFC Maps |
| NLFC_MAP_INDEX1: NLFa, NLFc |
| NLFC_MAP_INDEX2: NLFd, NLFa, NLFb, NLFh |
+-----------------------------------------------+
|NLFC Maps |
| Locator_NLFb: Locb |
| Locator_NLFc: Locc |
| Locator_NLFd: Locd |
| Locator_NLFh: Loch |
+-----------------------------------------------+
Figure 2
6.2. 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 additional encapsulation scheme is needed to
exchange traffic between these nodes.
6.3. NLF Node is also a Classifier
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 Figure 3. 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.
+-----------------------------------------------+
| NLFC Policy Table |
+-----------------------------------------------+
Boucadair & Jacquenet Expires December 19, 2013 [Page 13]
Internet-Draft NLFC June 2013
|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 |
+-----------------------------------------------+
|NLFC Maps |
| NLFC_MAP_INDEX1: NLFa, NLFc |
| NLFC_MAP_INDEX2: NLFd, NLFb |
| NLFC_MAP_INDEX3: NLFa, NLFh |
+-----------------------------------------------+
Figure 3
7. IANA Considerations
Required IANA actions will be discussed in future version of the
document.
8. Security Considerations
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 [RFC6146].
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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Boucadair & Jacquenet Expires December 19, 2013 [Page 14]
Internet-Draft NLFC June 2013
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
9.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.
[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.
Authors' Addresses
Boucadair & Jacquenet Expires December 19, 2013 [Page 15]
Internet-Draft NLFC June 2013
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Christian Jacquenet
France Telecom
Rennes 35000
France
Email: christian.jacquenet@orange.com
Boucadair & Jacquenet Expires December 19, 2013 [Page 16]