[Cisco, Brocade]: Overview of Service Functions Deployment Issues

An IETF document by Paul Quinn, Cisco Systems and Thomas Nadeau [pictured], Brocade "provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments"

Introduction 

The delivery of end-to-end services often require various service functions including traditional network service functions (for example firewalls and server load balancers), as well as application- specific features such as http header manipulation. Service functions may be delivered within the context of an isolated user (e.g. a tenant), or shared amongst many users/user groups. 

Current service function deployment models are often tightly coupled to network topology and physical resources resulting in relatively rigid and static deployments. The static nature of such deployments greatly reduces, and in many cases, limits the ability of an operator to introduce new or modify existing services and/or service functions. Furthermore there is a cascading effect: changing one (or more) elements of a service function chain often effects other elements in the chain and/or the network elements used to construct the chain. 

This issue is particular acute in elastic service environments that require relatively rapid creation, destruction or movement of physical or virtual service functions or network elements. Additionally, the transition to virtual platforms requires an agile service insertion model that supports elastic and very granular service delivery, and post-facto modification; supports the movement of service functions and application workloads in the existing network, all the while retaining the network and service policies and the ability to easily bind service policy to granular information such as per-subscriber state. 

This document outlines the problems encountered with existing service deployment models for Service Function Chaining (SFC) (often referred to simply as service chaining; in this document the terms will be used interchangeably), as well as the problems of service chain creation, deletion, modification/update, policy integration with service chains, and policy enforcement within the network infrastructure. The document highlights three key areas of WG focus for addressing the issues highlighted in this draft that will form the basis the possible WG solutions that address the current problems.

See "Service Function Chaining Problem Statement draft-ietf-sfc-problem-statement-11.txt" - here.

[Guest Post] Standardizing Service Chaining Models for Next-generation Service Provider Architectures

By Nicolas Bouthors*, Distinguished Technologist, Qosmos

With intense competition in the communications industry, service providers are looking for ways to offer new services faster and more cost-effectively. Dynamic service chaining allows you to do just that. With application-aware service chaining, you can quickly and efficiently create and deliver new, composite services by routing network flows through multiple, linked service functions (SFs). Three industry organizations have proposed complementary standards for service chaining that include Deep Packet Inspection (DPI) integration because it is considered critical in making the models application-aware.

The Internet Engineering Task Force (IETF) is developing a service function chaining (SFC) architecture that uses network flow classification to route traffic between service functions. Incoming network packets are sent to a service classifier, which attaches a metadata header to each packet and then forwards it to the appropriate set of service functions for processing. DPI technologies are used to enhance the capabilities of the service classifier, allowing it to identify the application in use and collect and format detailed metadata in a standard way.
   

The European Telecommunications Standards Institute (ETSI) model is based on a generalized service architecture that uses network forwarding graphs to route traffic between virtual network functions (VNFs). Pre-defined virtual links connect service functions into chains. Network traffic is routed along service chains based on forwarding paths and policies. DPI provides the information needed to make service functions application-aware, and ETSI has defined the DPI module as a reusable virtual network function component (VNFC) within their architecture.
   

Finally, the Open Networking Foundation (ONF) has proposed a software-defined networking (SDN) service chaining framework that uses an OpenFlow-based programmable switch and network forwarding graph to direct traffic to the appropriate service functions. DPI provides the application information needed to route traffic according to SDN rules and policies.

The three organizations are actively working together and with the larger open source community to merge their projects into a complete, common service chaining model, as shown in Figure 1. ETSI and ONF are collaborating on network functions virtualization (NFV) and SDN integration projects to create proofs of concept (PoCs) and reference implementations. The ONF model leverages the OpenStack Networking (Neutron) Group-based Policy declarative approach to create communication contracts between groups of servers providing network services. And, more solidified specifications and reference implementations are planned for release in 2015 as each organization works toward key milestones. 

Figure 1: The combined IETF, ETSI, and ONF service chaining model.

In the above diagram, the DPI is supplied in the form a service aware module (in this case provided by Qosmos) which acts as a service classifier by providing real-time application awareness to virtual switches. As one of the leading experts in DPI technologies, Qosmos is active in all the IETF, ETSI and ONF initiatives for a common service chaining model, providing essential insight into DPI in order to speed development of the future standards and architectures and deployment of the next generation networks. The company also continues to work with standards organizations toward the vision of end-to-end application awareness throughout the next-generation service provider architecture, from orchestrator to data plane.

____________
*Nicolas has spent many years in the telecommunications and information systems field. He was instrumental in creating Hewlett-Packard’s OpenCall business. As the R&D manager of Inovatel, the advanced research organization of SFR, Nicolas led several innovative projects highlighting the impact of internet technologies on Mobile Operators. Nicolas holds several patents relating to Mobile Data Charging.

Nicolas joined Qosmos to focus on emerging SDN and NFV architectures. He contributes to IETF SFC, ONF and ETSI NFV initiatives to add Layer 4 to Layer 7 capabilities within global SDN/NFV architectures. 

Nicolas holds an engineering degree from the French schools Ecole Polytechnique and Les Mines de Paris.

Internet Draft: Re-classification Analysis in Service Function Chaining

A new IETF Internet draft by Xinpeng Wei, Huawei discusses Service Function Chaining. 

Abstract 

Service Function Chaining (SFC) provides the ability to classify and steer a flow via some network service(s). Some traffic flows require re-classification to a new service chain. This may be, for example, the result of further analysis of initial packets, or detection of multiple types of media. This document discusses re-classification scenarios in SFC, and several deployment models for the re-classifier and relevant analysis are provided. The proposal will recommend some architectural constraints for the SFC design.

See "Re-classification analysis in SFC draft-wei-sfc-re-classification-00" - here.

IETF: Requirements for Congestion Control

An informational RFC by Randell Jesup [pictured], Mozilla "attempts to describe a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for proposals coming out of the RMCAT  [RTP Media Congestion Avoidance Techniques] Working Group".

Some of the requirements:

• The congestion control algorithm must attempt to provide as-low-as-possible-delay transit for real-time traffic while still providing a useful amount of bandwidth.
   
• The algorithm must be fair to other flows, both realtime flows (such as other instances of itself), and TCP flows, both long-lived and bursts such as the traffic generated by a typical web browsing session
   
• The algorithm should quickly adapt to initial network conditions at the start of a flow. This should occur both if the initial bandwidth is above or below the bottleneck bandwidth
   
• The algorithm should not require any special support from network elements 

See "Congestion Control Requirements For RMCAT" - here. 

IETF Proposed Framework for Application Visibility

A new IETF Internet Draft "provides a framework for communicating information elements (a.k.a. metadata) in a consistent manner between applications and the network to provide better visibility of application flows, thereby enabling differentiated treatment of those flows. These information elements can be conveyed using various signaling protocols, including PCP, RSVP, and STUN".

Authors are: Toerless Eckert, Reinaldo Penno, Amine Choukir and Charles Eckel [pictured] - all from Cisco.

See "A Framework for Signaling Flow Characteristics between Applications and the Network" - here.

IETF Draft: Device-based Real-time Video QoE Improvement

A new IETF draft by Bhumip Khasnabish (pictured) and Gerard Fernando both from ZTE (US) suggest how to improve video QoE without network intervention.  

Abstract 

"This draft describes a method for improving the quality of experience (QoE) for real-time video and other multimedia services using features and functions of the end-point only, that is, without requiring any upgrade to the network transport infrastructure. Any upgrade to the network transport infrastructure not only incurs significant costs, these are also time consuming and technology- dependent. Therefore, these QoE improvement mechanisms are significantly more attractive to both network operators and service providers".

"This document defines a common set of QoE parameters that are applicable for HTTP, Websocket or RTP sessions .. In order to improve quality it is common practice to focus on improving network infrastructure (bandwidth increase, etc.). However, our proposal enables improvements in quality by utilizing transport independent QoE management".

See "End-point based Multimedia QoE Management" - here.

[IEFT Draft]: Manage and Enforce Polices for Devices Behind NAT

 
A new IETF draft by Mohamed Boucadair, France Telecom and Tirumaleswar Reddy, Prashanth Patil, and Dan Wing (pictured), Cisco aim to provide granular policy management and enforcement for multiple devices behind a single NAT address.

"This document describes how to use PCP to retrieve the identify of a host behind a NAT. Two use cases are discussed and the PCP applicability is analyzed. This document extends PCP with a new OpCode: QUERY. The proposed mechanism is valid for all NAT flavors including NAT44, NAT64 or NPTv6".

The PCP (Port Control Protocol) QUERY opcode "can be used to query PCP-aware NAT to retrieve the Internal IP Address and Internal Port of a given mapping"

PCP Mapping IPv6 and IPv4 (Source: Cisco)

See "Using PCP to Reveal a Host behind NAT" - here.

F5 Adds RFC 6733 Support to the Diameter Router; Better Security

F5 Networks announced that its "Traffix Signaling Delivery Controller is the market’s first Diameter solution to support the new Diameter specifications per the latest release of RFC 6733.. Some of the highlights of RFC 6733 [written by reps from Telcordia/Ericsson, Nokia and Network Zen] are as follows: 

• Tighter security with better connections between peers by requiring the use of TLS/TCP and DTLS/SCTP
• Added routing functionality and flexibility using routing table add-ons
• Additional SCTP functionality
• Updates to AVPs and messages to enable additional functionality and better interworking
• Caching mechanism to reduce signaling, increase performance, and enable additional routing capabilities"

Ben Volkow (pictured), VP of Product Development, F5 said: “We have been aware of RFC 6733 and welcome its arrival because it provides for several enhancements for CSPs in the areas of security, management, and flexibility”

See "F5’s expertise and leadership in diameter enable customers to be ready for new industry standards and optimize their LTE rollouts" - here.

IETF: DPI/Policy Enforcement, Re-direction and Caching IPv6 Challanges

An IEFT document by Roberta Maglione (pictured), Telecom Italia and Wojciech Dec, Cisco from the Softwire, working group that is currently discussing both encapsulation and translation based stateless IPv4/IPv6 solutions in order to be able to provide IPv4 connectivity to customers in an IPv6 only environment.

The group presents a use-case for the Application of Service Policies to the subscriber’s sessions, Application of web-redirection policies and Caching.

"With the continuing growing of video traffic, especially considering the increase of http video traffic (you tube like,) it is useful for the Service Providers to be able to cache the video stream at the Edge of the network in order to save bandwidth in upstream links. Using cache devices together with tunnel solutions would introduce similar challenges/issues as the ones described for DPI scenarios, in particular it would require applying caching functionality after the decapsulation point. Obviously this would not eliminate the benefits of the cache. Instead a MAP-T approach would allow caching the subscriber traffic at the edge of the network and gaining the bandwidth savings introduced by the caching. Crucially, any native IPv6 web-caches would be capable of processing IPv6 MAP-T traffic as fully native traffic.

In addition in some deployments today, Web Cache Control Protocol (WCCP) feature is used in order to redirect subscriber’s traffic to the cache devices. When a subscriber requests a page from a web server (located in the Internet, in this case), the network node where the WCCP is active, sends the request to a Cache Engine. If the cache engine has a copy of the requested page in storage, the engine sends the user that page. Otherwise, the engine gets the requested page and the objects on that page from the web server, stores a copy of the page and its objects (caches them), and forwards the page and objects to the user. WCCP is another example of web redirect thus, the same considerations described in section Section 2.3 and the benefits introduced by MAP-T also apply here". 

See "Uses cases for MAP-T" - here.

IETF: Draft for "Mobile Communication Congestion Exposure"

A new IETF draft for "Mobile Communication Congestion Exposure Scenario" was published (here), led by NEC, Ericsson and UC3M.

   

"This memo describes a mobile communications use case for congestion exposure (CONEX) with a particular focus on mobile communication networks such as 3GPP Evoled Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for CONEX mechanisms that particularly apply to mobile networks" 

   

"The CONEX congestion exposure mechanism is intended as a general technology that could be applied as a key element of congestion management solutions in a variety of use cases. The IETF CONEX WG will however work on a specific use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be".

CONEX Use Cases in the Mobile Communication Scenario: 

• CONEX as a Basis for Traffic Management, 
• CONEX to Incentivize Scavenger Transports, 
• Accounting for Congestion Volume
• CONEX as a Form of Differential QoS

Location Aware DNS Speeds Up Content Access

 

What looks like a trivial enhancement (at least conceptually) to the Internet's DNS protocol promises to help internet users get a faster service.

The "Global Internet Speedup", supported by Google and OpenDNS, implements a small change to DNS queries so users will enjoy the full advantage of CDNs and get the content they ask from the closets server.

Participating CDNs include BitGravity, CDNetworks, Cloudflare, Comodo and EdgeCast.

"When trying to reach a website that exists in 50 locations around the world .. You want to be sent to the closest, fastest or least congested location automatically.  Until now, figuring out which location is closest to you was not possible with DNS alone. Today, if you’re using OpenDNS or Google Public DNS and visiting a website or using a service provided by one of the participating networks or CDNs in the Global Internet Speedup then a truncated version of your IP address will be added into the DNS request. The Internet service or CDN will use this truncated IP address to make a more informed decision in how it responds so that you can be connected to the most optimal server"

See how it works - here and the proposed IETF draft - here and a press release "Global Internet Speedup Initiative Announced; Technology Companies Band Together on Innovation to Make the Internet Faster Around the World" - here.

IETF Draft on "Use case for congestion exposure" (CONEX)

A new draft memo from the IETF "describes a mobile communications use case for congestion exposure (CONEX) with a particular focus on mobile communication networks such as 3GPP LTE.  The draft describes the architecture of these networks (access and core networks), current QoS mechanisms and    then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for CONEX mechanisms that particularly apply to mobile networks"

See "Mobile Communication Congestion Exposure Scenario" - here. Authors are Dirk Kutscher (picture), Faisal Ghias Mir and Rolf Winter from NEC, Suresh Krishnan and Ying Zhang from Ericsson. 

See also "IETF: Experiments to Harmonize P2P Technology with the Infrastructure" - here.
  

"The CONEX congestion exposure mechanism is intended as a general technology that could be applied as a key element of congestion management solutions in a variety of use cases.  The IETF CONEX WG will however work on a specific use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be .. it can be said that traffic management in 3GPP EPS and other mobile communication architectures in very important.  Previously more static approach based on admission control and static QoS have been applied, but recently, there has been a perceived need for more dynamic mechanisms such as DPI.  Adding CONEX support might thus require revisiting the PCC architecture, depending on the scope and impact of a CONEX-based traffic management approach".

Draft for "Congestion Exposure (ConEx) Concepts and Abstract Mechanism" - here.

IETF: Experiments to Harmonize P2P Technology with the Infrastructure

   

Application-Layer Traffic Optimization (ALTO) is an IETF group charted to "design and specify an Application-Layer Traffic optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection" (more - here).

A new from the group "provides some suggestions about ALTO architecture through experiments made by P2P Network Experiment Council in Japan. This document also introduces experiments made by the Council in Japan to harmonize P2P technology with the infrastructure. Specifically, this document describes Hint Server technology, which is similar to ALTO technology"

See "ALTO-Like Activities and Experiments in P2P Network Experiment Council draft-kamei-p2p-experiments-japan-04" - here.



 

How to Build DPI Products? (Part IV - Performance Testing)

After we have seen some recommendations regarding the architecture of modern DPI systems (CPU, System, 100G support), we need also to verify (and benchmark) the performance of DPI devices in a modern network environment, taking into account the DPI aspects.

Benchmarking Methodology for Content-Aware Network Devices (here), is a new draft for an IETF document with the following purpose:

"define a set of test scenarios which may be used to create a series of statistics that will help to better understand the performance of network devices.  More specifically, these scenarios are designed to most accurately predict performance of these devices when subjected to modern traffic patterns .. Content-aware devices take many forms, shapes and architectures. These devices are advanced network interconnect devices that inspect deep into the application payload of network data packets to do classification.  While a list of devices that fall under this category will quickly become obsolete, an initial list of devices that would be well served by utilizing this type of methodology should prove useful.  Devices such as firewalls, intrusion detection and prevention devices, application delivery controllers, deep packet inspection devices, and unified threat management systems generally fall into the content-aware category."