Joint ITU-T SG 13 and ISO/JTC1/SC 6
Workshop on
“Future Networks Standardization”
(Geneva, Switzerland, 11 June 2012)
Future Networks: overview of
standard industry developments
Jamil Chawki and Olivier Le Grand
France Telecom Orange
Geneva, Switzerland, 11 June 2012
Outline
Future Networks: a Programmable Network ?
Standardization in ONF
Standardisation in IETF
SDN overall architecture
Standardisation
Standardisation
Standardisation
Standardisation
in ITU-T
in ETSI
in 3GPP
in ISO IEC JTC1
Analysis and Recommendations
Geneva, Switzerland, 11 June 2012
2
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 Networks
Under discussion at IETF as Network Programmability (or SoftwareDriven Networks )
Self Organizing & Autonomic Networks
Network resources and policy controller
Network Virtualization & slicing
Cloud 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 applications
Leading the development of OpenFlow (OF) – an open interface for
enabling SDN:
OF 1.1 (02/2011): MPLS tags/tunnels, multiple tables, counters
OF 1.2 (12/2011): Wire protocol, IPv6, basic configuration
OF 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.
Control Plane
OpenFlow
Large modifications of fields.
Controller
Routing on new criteria : L4, mix
OpenFlow
Define network slice on flow criteria …
Protocol
New routing protocol : multipath, load-balancing
SSL
OpenFlow is implemented by
several vendors
Data Plane
Flow table
OpenFlow-enabled
Layer 2-4 Switch
Matches subsets of packet header fields
Switch Eth VLAN
Port MAC
ID
IP
TCP
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
CE
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)
Standardisation in ITU-T

ITU-T SG 13 Futures Networks:
NGN RACF Y.2111 Resource and Admission Control Function
Full Network Virtualization based on logically isolated network partition
LINP Rec Y.3011 Framework of network virtualization for Future Networks
Framework of software-defined networking for Future Networks Y.SDN
Architecture 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 infrastructure
New 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 applications
ITU-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/SelfManaging 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 networks
Self-Organizing Networks (SON)
Objective: decrease OPEX/CAPEX related to network configuration,
operation, optimization
Main 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 LTE
Rel. 11 addresses 3G and inter-RAT SON (Radio Access Technology)
OA&M
Decision
SON function
related
indicators
Setting of Configuration
parameters
eNodeB
Statistical
Analysis
* Self-Optimization
Performance
measurement reports,
Alarm information,, etc.
Standardisation in ISO IEC JTC1 SC6
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"
Jamil Chawki, ONF 2011
Analysis and recommendation
Analysis: Standard organizations are working on different FN concepts
Network resources and policy controller
Network Virtualization & slicing
Cloud Network & Network as a Services
Enhancement of exiting Internet Data network
Network Softwarization
IETF Forces: mature standard solution with 5 RFCs , but with
limited vendor implementation
ONF-SDN ‘Defined’ based on OpenFlow: introducing new control
plan and open interface (Open Flow API) but implemented by
several vendors
Autonomic Network
ETSI 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)
Rules : match
against packets
Actions
Stats
Counters : per-table, per-flow, per-port and queue
1.
2.
3.
4.
Forward packet to :
(optional)
1. All : not incoming iface
2. Controller : encapsulate and send
3. Local : to the local networking switch stack
4. Table : perform actions in flow table
5. In-port : send to given port
6. Normal : traditional forwarding path
7. Flood : along the minimum spt
Enqueue
Drop packet
Modify field (VLAN, MAC sd, IP sd, TOS, Ports sd)
Ingress MAC MAC Eth VLAN VLAN IP
Port
src dst type
ID
prio Src
Version 1.1.0
+ Multi table
+
+
+
Metadata
MPLS label
MPLS traffic
class
No v6!….
IP IP IP TCP/UDT TCP/UDP
Dst Prot TOS sport
dport
+ mask, wildcards
(source OpenFlow)
ITU-T : H.248.64 Routing Control
+-------------+ -+
| CE - Policy | +- MGC
+------+------+ -+
|
| H.248.64
|
+------+------+ -+
| CE - Routing| |
+------+------+ |
|
+- MG
+------+------+ |
| FE
| |
+-------------+ -+