Geneva, Switzerland, 11 June 2012 Future Networks: overview of standard industry developments Jamil Chawki and Olivier Le Grand France Telecom Orange Joint.

Geneva, Switzerland, 11 June 2012

Future Networks: overview of standard industry developments

Jamil Chawki and Olivier Le GrandFrance Telecom Orange

Joint ITU-T SG 13 and ISO/JTC1/SC 6 Workshop on

“Future Networks Standardization”

(Geneva, Switzerland, 11 June 2012)

Geneva, Switzerland, 11 June 2012 2

Outline

Future Networks: a Programmable Network ?Standardization in ONFStandardisation in IETF

SDN overall architecture

Standardisation in ITU-TStandardisation in ETSI Standardisation in 3GPPStandardisation in ISO IEC JTC1

Analysis and Recommendations

Future Networks: a Programmable Network ? Several solutions and Terminologies

SDN: Software-Defined Networking Introduced by the New initiative ONF and recently by ITU-T SG 13 Future NetworksUnder discussion at IETF as Network Programmability (or Software-Driven Networks )

Self Organizing & Autonomic Networks Network resources and policy controllerNetwork Virtualization & slicingCloud Network & Network as a Services …. Smart Ubiquitous & Distributed Services, Information-Centric Networks….

Opportunity for telecom operators: To hide network complexity by abstraction layer Improve “Dynamically” network Management ‘Programmability’ &

performance Ability to deliver “On demand” network resources

…And some use cases: Bandwidth On Demand, Network virtualization , Policy control, Chained Business services , Cloud Network, NaaS, Traffic Offload…

Standardization in ONF (started in June 2011)Goal of the Open Network Foundation: to make Software-Defined Networking the new norm for networks

SDN enables fully software implementation on simplified Generic Hardware

Software defined forwarding using open interface

Global management abstractions

Traffic routing decisions & policies tied closer to applicationsLeading the development of OpenFlow (OF) – an open interface for enabling SDN:

OF 1.1 (02/2011): MPLS tags/tunnels, multiple tables, countersOF 1.2 (12/2011): Wire protocol, IPv6, basic configurationOF 1.3 (04/2012): Topology discovery, test processes, test suites...OF 1.4 (08/2012): Capability discovery, test labs..

Open interfaces, not open source or reference implementations Membership +50 6+1 Founding & Board Members (BoD): DT, Verizon, NTT, Microsoft, FB,

Google, Yahoo 56 Other Members: KT, Comcast, France Telecom Orange, Cisco, IBM,

Intel, Juniper, NEC, Ciena, Oracle, HP, Dell, Broadcom, VMWare, Ciena, Force10, Ericsson, Huawei, Brocade, Riverbed, Netgear, ZTE, Citrix….

OpenFlow Switching : how it works?

OpenFlow is based on an L2-L4 switch, with an internal flow-table, and a "standardized" interface to add and remove flow entries.

New actions can be done on packet.

Large modifications of fields.

Routing on new criteria : L4, mix

Define network slice on flow criteria …

New routing protocol : multipath, load-balancing

OpenFlowController

OpenFlow-enabledLayer 2-4 Switch

OpenFlowProtocol

SSL

Flow table

SwitchPort

EthMAC

VLANID

IP TCP

Matches subsets of packet header fields

Control Plane

Data Plane

OpenFlow is implemented by several vendors

Standardisation in IETF IETF : new Programmable Network (Software-Driven Network)

Software-Driven Networks : to enable programmatic automation of configuration, management, monitoring, accounting/data mining of networks

Use cases: Bandwidth On Demand, Data center (Application-network information), Cloud bursting (Private/Public)

IETF WG ForCes: started since 2002, but hardly active now

Objective: to standardize open, programmable distributed network architecture including description of the functional model of a Forwarding Element and the specification of the protocol for communication between control and forwarding plane in the router.

Standards: FoRCES working group has produced several RFCs for requirements , architecture framework, Protocol description, Forwarding Element Model and MIB for control-data plane interaction on top of transport layer.

NETCONF/NETMOD:

provides a XML-based solution for network device configuration. It has been in wide-deployment (IP, LTE…)

it supports server-to-client configuration, but not client-to-server alarms or feedback.

Forwarding & Control Element Separation: IETF ForCES WG

Top down approach, first RFC in 2003, with 3 academic implementations.

Interaction of control and forwarding planes in distributed Routers

Protocols for (multiple) control elements (CE) and forwarding elements (FE)

Define objects model to instantiate functions in FE

------------------------------------------------- | | | | | | | |OSPF |RIP |BGP |RSVP |LDP |. . . | | | | | | | | ------------------------------------------------- | ForCES Interface | ------------------------------------------------- ^ ^ ForCES | |data control | |packets messages| |(e.g.,routing packets) v v ------------------------------------------------- | ForCES Interface | ------------------------------------------------- | | | | | | | |LPM Fwd|Meter |Shaper |NAT |Classi-|. . . | | | | | |fier | | ------------------------------------------------- | FE resources | -------------------------------------------------

Examples of CE and FE functions. (source FORCES)

CE

FE

Standardisation in ITU-T ITU-T SG 13 Futures Networks:

NGN RACF Y.2111 Resource and Admission Control FunctionFull Network Virtualization based on logically isolated network partition LINP Rec Y.3011 Framework of network virtualization for Future NetworksFramework of software-defined networking for Future Networks Y.SDNArchitecture of independent Scalable Control Plane Y.iSCP (in Future Packet Based Network FPBN)SUN Smart Ubiquitous Networks:

knowledgeable, context-aware, adaptable, autonomous, programmable allow access anytime anywhere

Cloud Networking and infrastructureNew Draft recommendations Y.CCInfra, Y.CCRA NaaS architecture was identified as a candidate for the next study period.

ITU-T SG16 Multimedia coding, systems and applicationsITU-T Media Gateways SG16 “H.248 packages for IP Routers”

Standardisation in ETSI E2NA/AFI Autonomic network engineering for the self-managing Future Internet started in 2009 (Enhancing ETSI Network Activities) Autonomic: network exhibit a certain level of autonomicity (intelligent behaviour)

• Main objectives: Harmonizing concepts & design principles for autonomic networking

1. Scenarios, Use Cases, and Requirements for Autonomic/Self-Managing Future Internet.

• Description of Scenarios, Use Cases, and Definition of Requirements for the Autonomic/Self-Managing Future Internet.

2. AFI Generic Autonomic Network Architecture  Reference Model Design a generic autonomic/self-managing network architecture as

reference model for engineering the Future Internet. 3. Implementable Autonomic Network Architecture

• How to make existing architecture "Autonomic-Aware"• 3 Sub WI set up in April 2011:

• ITU-T for NGN / IMS, • BBF for xDSL /FTTH, • 3GPP for Wireless Sensor networks / Wireless Mesh Network

Standardisation in 3GPP / SA5 OA&M for mobile networks (Access / Core / Control)Converged Management of fixed and mobile networksSelf-Organizing Networks (SON)

Objective: decrease OPEX/CAPEX related to network configuration, operation, optimizationMain functionalities:

Self-Configuration (Plug & Play of new eNodeB)Self-Healing (e.g. Cell Outage Compensation)Self-Optimization* (e.g. Mobility Load Balancing, Handover Optimization, Energy Saving Management, etc.)

Rel. 8/9/10 focused on SON for LTERel. 11 addresses 3G and inter-RAT SON (Radio Access Technology)

OA&M

eNodeB

Decision StatisticalAnalysis

Performance measurement reports, Alarm information,, etc.

Setting of Configurationparameters

SON functionrelated

indicators * Self-Optimization

Standardisation in ISO IEC JTC1 SC6

Jamil Chawki, ONF 2011

WG 7: Network, transport and future network : ISO/IEC DTR 29281-1

-Problems with current Internet (routing failures, scalability, insecurity, mobility, QoS, lack of efficient media distribution, packet switching, …)

- Design goals and high level requirements:• Scalability (routing architecture, multi-homing)• Naming & addressing scheme (separation of user identifier & device locator)• Security & QoS (including Privacy, Authentication)• Mobility (seamless mobility of devices, services, users; network-based mobility control, flow-level mobility, context awareness…)• Heterogeneity (device, physical media, application/service)• Network virtualization• Service composition (at design time & at run-time, context awareness)• Media distribution (content-centric networking)• Cross-layer communications• Management (autonomic)• Energy efficiency• Economic incentives

-Gap analysis (with NGN; IPv6 networks,…)"Packet switching technology is not assumed for FN at this moment"

Analysis and recommendation Analysis: Standard organizations are working on different FN concepts

Network resources and policy controllerNetwork Virtualization & slicingCloud Network & Network as a ServicesEnhancement of exiting Internet Data network Network Softwarization

IETF Forces: mature standard solution with 5 RFCs , but with limited vendor implementationONF-SDN ‘Defined’ based on OpenFlow: introducing new control plan and open interface (Open Flow API) but implemented by several vendors

Autonomic NetworkETSI AFI: new initiative, network operating system and management /Self management oriented 3GPP SON: first features specified in Rel8 - First implementations already available in LTE networks

Recommendations: To identify common Use cases and network services To achieve common Requirements and high level FN architecture

Backup slides

Flow table entry (version 1.0.0)

IngressPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCP/UDTsport

TCP/UDPdport

Rules : match against packets

Actions Stats

1. Forward packet to : (optional)1. All : not incoming iface2. Controller : encapsulate and send3. Local : to the local networking switch stack4. Table : perform actions in flow table5. In-port : send to given port6. Normal : traditional forwarding path7. Flood : along the minimum spt

2. Enqueue3. Drop packet4. Modify field (VLAN, MAC sd, IP sd, TOS, Ports sd)

+ mask, wildcards

Counters : per-table, per-flow, per-port and queue

VLANprio

IPTOS

Version 1.1.0+ Multi table

+ Metadata

+ MPLS label

+ MPLS traffic classNo v6!….

(source OpenFlow)

ITU-T : H.248.64 Routing Control

+-------------+ -+| CE - Policy |  +- MGC+------+------+ -+       |       | H.248.64       |+------+------+ -+| CE - Routing|  |+------+------+  |       |         +- MG+------+------+  || FE          |  |+-------------+ -+