Service Delivery Automation in IPv6 Networks

Transcription

1 Service Delivery Automation in IPv6 Networks C. Jacquenet Slide 1

2 Outline Rationale Beyond the SDN hype: a true need for automation Global framework From service negotiation and design to delivery and operation New networking paradigms Introducing service-inferred differentiated forwarding policies Conclusion Slide 2

3 Rationale Introduce robust automation in complex service delivery for the sake of cost optimization and improved service production times Based upon a set of service-specific policies According to customer s requirements, possibly yielding a dynamic negotiation of service parameters Exploit dynamic resource allocation and policy enforcement schemes Likely based upon the use of various protocols and tools, depending on the nature of the service Need for feedback mechanisms to assess efficiency of service delivery procedure and service parameter compliance For the sake of service assurance and fulfillment Slide 3

4 Global Framework Use of AAA protocols, service negotiation protocols (PPP, BGP, Candidate protocols include (OpenFlow), PCEP, NETCONF, etc. (depending on requirements CPNP), etc. Customer & Connectivity Provisioning Profile (CPP) Management Systems and foreseen applicability) Service Structuring Plane (incl. Management) Customer Control Plane Peer Service Provider CNI Forwarding Plane (Packet handling) ICI Policy Sub-Stratum Slide 4 Control Sub-Stratum Management Sub-Stratum SDN is hereby defined as a set of techniques used to facilitate the design, the delivery and the operation of network services in a deterministic, dynamic and scalable fashion (RFC 7149)

5 Dynamics of an SDN Architecture Discovery of network topology, devices and their capabilities Further documented by information models and data Service exposure and parameter negotiation By means of standard, commonly agreed, Connectivity Provisioning Profile templates Policy enforcement and resource allocation schemes Based upon automated configuration procedures Feedback mechanisms To assess how efficiently a given policy (or a set thereof) is enforced from a service fulfillment and assurance perspective Slide 5

6 Service Production Chain Service orchestration is mastered by Service Provider Based upon abstract Service Components CPP Template-derived (RFC 7297) policy provisioning information feeds the Policy Decision Point (PDP) intelligence to optimize decisionmaking process As per negotiation outcomes PDP then forwards policy decisions and configuration information to devices Yielding automated service production PDP Services SSS Layer Policy and Control Packet processing Slide 6

7 Challenges IP network operation now assumes the complex chaining of various elementary capabilities (a.k.a. Service Functions) Besides basic routing and forwarding functions (e.g., NAT, DPI, TCP optimizer, etc.) Some of these functions may be virtualized, depending on the service design, performance and scale considerations, etc. How to efficiently forward traffic entering a network that supports these Service Functions? Differentiation is ensured by structuring the set of network functions to be invoked Packet processing decisions become service-inferred and policy-derived Slide 7

8 What For? Compute and establish service-inferred forwarding paths Thereby contributing to the optimization of overall service delivery and operation Master Service Function (SF) chaining regardless of the underlying topology and routing policies Yielding a SF-based differentiated forwarding policy enforcement scheme Facilitate SF operation while avoiding any major topology upgrade Derive chronology of SF invocation according to the required service and associated parameters Contribute to the automation of dynamic resource allocation and policy enforcement procedures Slide 8

9 A Typical Use Case Numerous functions are enabled at the (s)gi I/F Some of these functions may be co-located and virtualized The number of these functions is still growing Due to the deployment of new value-added services e.g., DPI, billing and charging, TCP optimization, web optimization, etc. Dependency between functions is hard to assess e.g., which function should be solicited first to process a packet within a flow? Source: SK Telecom Slide 9

10 SFC Approach Dynamic SF configuration is distinct from packet processing SF functions are seen as (virtual) black boxes No assumption about the underlying technology SF chaining varies as a function of the service and the traffic directionality Chaining is described by information processed by devices that participate to the delivery of a given service Such information is signaled by the packets themselves Slide 10

11 Service Function Chaining Framework PDP makes decisions according to the information maintained in SFC Policy Tables PDP decisions (chain structuring, traffic classification rules) are applied by SF (boundary) nodes which process traffic accordingly SFC Policy Enforcement PDP SFC_BN_1 SFC_BN_n SF_1 SF_2 SF_3 SFC-enabled Domain Slide 11

12 The PDP Intelligence PDP-maintained SFC Policy Tables describe the SFCspecific policies to be enforced SF nodes are provisioned with: Local SF Identifier(s) so that the node can position itself in the SFC Map SFC Maps and Locators PDP also provide boundary nodes with (traffic) Classification Rules A rule is bound to one SFC Map Traffic classification typically relies upon (the combination of) various packet header fields (DA, SA, DS, etc.) Slide 12

13 A Selection of Pending Issues SFC information encoding 8-bit is probably enough, 16-bit is comfortable Where to carry the SFC information? DS field, Flow Label, new IPv6 extension header, new IP option, L2 field, TCP option, define a new shim, etc. Which encapsulation scheme suits best? When next SF node to forward traffic to is not the next hop as per legacy IP forwarding paradigm GRE, IP-in-IP, LISP, etc., are candidate options Security issues at SFC domain boundaries Means to protect against DDoS or illegitimate invocation of resources must be supported Slide 13

14 Tentative Conclusion Beneath automation resides a complex combination of various techniques, protocols, computation logics and modeling languages Some of them have been investigated and sometimes standardized for a while This complexity is the key challenge for the sake of automated service delivery and operation procedures Multi-service, IPv6 Internet demands robust, scalable, self-adaptive, forwarding paradigms Service providers MUST play a key role in the ongoing specification and standardization efforts Large scale, open and resource-adjustable testbeds become of paramount importance Slide 14

15 Thank You! Slide 15