Network Working Group M. Boucadair Internet-Draft C. Jacquenet Intended status: Standards Track France Telecom Expires: December 30, 2013 R. Parker Affirmed Networks D. Lopez Telefonica I+D P. Yegani Juniper Networks June 28, 2013 Differentiated Network-Located Function Chaining Framework draft-boucadair-network-function-chaining-01 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 30, 2013. Boucadair, et al. Expires December 30, 2013 [Page 1] Internet-Draft NLFC June 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 1.5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. NLFC Provisioning . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Assign NLF Identifiers . . . . . . . . . . . . . . . . . 7 3.2. NLF Locator . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Building NLFC Maps . . . . . . . . . . . . . . . . . . . 7 3.4. Building NLFC Policy Tables . . . . . . . . . . . . . . . 8 4. Theory Of Operation . . . . . . . . . . . . . . . . . . . . . 9 4.1. NLFC Boundary Node . . . . . . . . . . . . . . . . . . . 9 4.2. Classifier . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. NLFC Ingress Node . . . . . . . . . . . . . . . . . . . . 10 4.4. NLFC Egress Node . . . . . . . . . . . . . . . . . . . . 10 4.5. NLF Node . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Intermediate Nodes . . . . . . . . . . . . . . . . . . . 11 5. Protocol Extensions? . . . . . . . . . . . . . . . . . . . . 11 5.1. Transmit NLFC Map Index In a Packet . . . . . . . . . . . 11 5.1.1. NLFC Map Index . . . . . . . . . . . . . . . . . . . 12 5.1.2. Why Not SSR? . . . . . . . . . . . . . . . . . . . . 12 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. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 6.1. Generic Requirements . . . . . . . . . . . . . . . . . . 13 6.2. NLF Profiles . . . . . . . . . . . . . . . . . . . . . . 13 6.3. NLF Node is also a Classifier . . . . . . . . . . . . . . 13 6.4. Direct Adjacency . . . . . . . . . . . . . . . . . . . . 14 6.5. NLF Loops . . . . . . . . . . . . . . . . . . . . . . . . 14 Boucadair, et al. Expires December 30, 2013 [Page 2] Internet-Draft NLFC June 2013 6.6. Lite NLFC Policy Table . . . . . . . . . . . . . . . . . 15 6.7. Liveness Detection of NLFs by the PDP . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 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. 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: Boucadair, et al. Expires December 30, 2013 [Page 3] Internet-Draft NLFC June 2013 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. 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. 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. Boucadair, et al. Expires December 30, 2013 [Page 4] Internet-Draft NLFC June 2013 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 minimize 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. o 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. 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 is ensured by the PDP. o The PDP can be responsible to enforce other policies than 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. Boucadair, et al. Expires December 30, 2013 [Page 5] Internet-Draft NLFC June 2013 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. 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 Boucadair, et al. Expires December 30, 2013 [Page 6] Internet-Draft NLFC June 2013 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 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. 3.3. Building NLFC 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. 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}}. Boucadair, et al. Expires December 30, 2013 [Page 7] Internet-Draft NLFC June 2013 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, 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]). 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. 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 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: The PDP may configure the full list (default mode) or only as subset of NLFC Maps in which the local NLF 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 the local NLF is involved (see Section 6.6). Boucadair, et al. Expires December 30, 2013 [Page 8] Internet-Draft NLFC June 2013 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 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 [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. 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.4). 4.2. Classifier Boucadair, et al. Expires December 30, 2013 [Page 9] Internet-Draft NLFC June 2013 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 (e.g., 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 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. Boucadair, et al. Expires December 30, 2013 [Page 10] Internet-Draft NLFC June 2013 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 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. 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. 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 Boucadair, et al. Expires December 30, 2013 [Page 11] Internet-Draft NLFC June 2013 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 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 Section 6.2). 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. 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 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. 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. Boucadair, et al. Expires December 30, 2013 [Page 12] Internet-Draft NLFC June 2013 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 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 (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, 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. 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 2. 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. Boucadair, et al. Expires December 30, 2013 [Page 13] Internet-Draft NLFC June 2013 +-----------------------------------------------+ | 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 | +-----------------------------------------------+ |NLFC Maps | | {NLFC_MAP_INDEX1, {NLFa, NLFc} | | {NLFC_MAP_INDEX2, {NLFd, NLFb} | | {NLFC_MAP_INDEX3, {NLFa, NLFh} | +-----------------------------------------------+ Figure 2 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 additional encapsulation scheme is needed 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 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 3 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 | +-----------------------------------------------+ |NLFC Maps | | {NLFC_MAP_INDEX1, {NLFa, NLFc} | | {NLFC_MAP_INDEX2, {NLFd, NLFa, NLFb, NLFh} | Boucadair, et al. Expires December 30, 2013 [Page 14] Internet-Draft NLFC June 2013 +-----------------------------------------------+ |NLFC Locators | | Locator_NLFb: Locb | | Locator_NLFc: Locc | | Locator_NLFd: Locd | | Locator_NLFh: Loch | +-----------------------------------------------+ Figure 3 The support of this feature is OPTIONAL. 6.6. Lite NLFC Policy Table 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: 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 lite 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 6.7. Liveness Detection of NLFs by the PDP Determination by the PDP of liveness of each NLF in the service chain provides a number of benefits. These include: o Enhanced status reporting by the PDP (i.e., an operational status for any given chain derived from liveness state of its NLFs). Boucadair, et al. Expires December 30, 2013 [Page 15] Internet-Draft NLFC June 2013 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 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 [RFC5881] and multi- hop [RFC5883]) 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. 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. Acknowledgments Many thanks to D. Abgrall, D. Minodier, Y. Le Le Goff, and D. Cheng for their review and comments. Boucadair, et al. Expires December 30, 2013 [Page 16] Internet-Draft NLFC June 2013 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. 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. Boucadair, et al. Expires December 30, 2013 [Page 17] Internet-Draft NLFC June 2013 [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 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 Boucadair, et al. Expires December 30, 2013 [Page 18] Internet-Draft NLFC June 2013 Parviz Yegani Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA Email: pyegani@juniper.net Boucadair, et al. Expires December 30, 2013 [Page 19]