ARCFIREict-arcfire.eu/wp-content/uploads/2017/10/arcfire_d21... · 2017-10-25 · D2.1 Converged network opera-tional environment report Document: ARCFIRE D2.1 Date: August 29th 2016

Grant Agreement No.: 687871

ARCFIRE

Large-scale RINA Experimentation on FIRE+

Instrument: Research and Innovation ActionThematic Priority: H2020-ICT-2015

D2.1 Converged network operational environment report

Due date of Deliverable: Month 5Actual submission date: Month 8, 2016

Start date of the project: January 1st, 2016. Duration: 24 monthsversion: V1.0

Project funded by the European Commission in the H2020 Programme (2014-2020)

Dissemination level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

D2.1 Converged network opera-tional environment report

Document: ARCFIRE D2.1

Date: August 29th 2016

H2020 Grant Agreement No. 687871

Project Name Large-scale RINA Experimentation on FIRE+

Document Name Deliverable 2.1

Document Title Converged network operational environment report

Workpackage WP2

Authors

Eduard Grasa (i2CAT

Leonardo Bergesio (i2CAT)

Miquel Tarzan (i2CAT)

Sven van der Meer (LMI)

Diego Lopez (TID)

Editor Eduard Grasa (i2CAT)

Delivery Date August 29th 2016

Version v1

2




Executive Summary

Although network convergence is a long desired goal, current service providers are still workingto integrate different access technologies and different network services into a single, common in-frastructure. Future-proof service providers must design and deploy converged networks that arecapable of supporting any access media and any application requirement using a common infras-tructure. This deliverable analyzes what technologies can be used today to design and implementsuch a converged network vision following an all-IP approach. In order to allow for a best-casecomparison with a RINA design in D2.2, we have adopted the perspective that the provider designshis network from scratch. This way there is no need to consider support for legacy technologies,minimizing the number of protocols required in the network.

Section 2 reviews the main technologies and protocols used in the different parts of a typi-cal service provider network today, with the goal of analyzing how the multiple components thatintegrate it interact with each other and how the various protocols are layered and interoperate.This section analyzes i) different access network technologies for different physical media - LTEAdvanced for cellular radio, WiFi for wireless LANs, xDSL for copper-based access networks andFTTH for optical fibre; ii) carrier Ethernet and MPLS as technologies for traffic aggregation at themetro level; iii) MPLS-based BGP-free service provider core networks; iv) technologies for allow-ing a service provider to interconnect with other networks (via peering and transit agreements); v)multi-tenant, large-scale datacenter networking solutions; vi) technologies for providing L2 andL3 VPN services based on BGP; vii) network security and viii) network management approachesincluding technologies for exploiting network programmability.

The conclusions of this analysis are used in section 3 to design the architecture of a convergedservice provider network, supporting multiple types of access media and a varied set of networkservices. It is important to highlight that this is a logical design: it has the essential elements of areal design, but each real network will have very detailed constraints that will result in variationsand refinements to this more general model. Nevertheless, the model is detailed enough to allowfor a meaningful analysis and comparison with RINA-based converged service provider networks.

Section 4 reports the results of an analysis of architectural limitations in the converged serviceprovider network design depicted in section 3. The analysis of the limitations has been dividedinto 7 areas: network architecture; protocol design; naming, addressing and routing; mobility andmulti-homing; quality of service, resource allocation, congestion control; security and networkmanagement. Section 5 concludes that the limitations identified in the previous section are inherentin the network architecture and protocols upon which the design is based. Therefore, in orderfor these limitations to be overcome an alternative network architecture is required. ARCFIRE’sdeliverable D2.2 will propose a logical RINA-based converged service provider network design,and compare it to the design outlined in D2.1 in the light of the limitations identified in thisdocument.

3




Table of Contents

1 Motivation for converged operator networks 8

2 Current network technologies and protocols 102.1 Access networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Cellular networks: LTE Advanced . . . . . . . . . . . . . . . . . . . . . 102.1.2 WiFi (IEEE 802.11) and Proxy Mobile IPv6 (PMIP) . . . . . . . . . . . 152.1.3 xDSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.4 Fiber to the Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Metro aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2.1 Carrier Ethernet MAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2.2 MPLS-based MAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4 Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.1 Service provider interconnection edge . . . . . . . . . . . . . . . . . . . 322.5 Data centre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.6 Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.6.1 MPLS/BGP Layer 3 Virtual Private Networks (RFC 4364) . . . . . . . . 352.6.2 VPLS, Virtual Private Line Services (RFC 4761, RFC 4762) . . . . . . . 392.6.3 Ethernet VPN (RFC 7432, RFC 7623) . . . . . . . . . . . . . . . . . . . 43

2.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.7.1 Establishment of security associations . . . . . . . . . . . . . . . . . . . 442.7.2 Confidentiality and integrity . . . . . . . . . . . . . . . . . . . . . . . . 442.7.3 Access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.7.4 Intrusion Detection (IDS) and Prevention (IPS) systems . . . . . . . . . 46

2.8 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.8.1 Managing a converged network today . . . . . . . . . . . . . . . . . . . 472.8.2 Network programmability: Software Defined Networking . . . . . . . . 49

3 Architecture of a converged network operator today 52

4 Limitations of current converged operator networks 604.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.2 Protocol design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.3 Naming, addressing and routing . . . . . . . . . . . . . . . . . . . . . . . . . . 614.4 Mobility and multi-homing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.5 Quality of service, resource allocation, congestion control . . . . . . . . . . . . . 634.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4




4.7 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5 Conclusions 66

5




List of Figures

1 A high level view of an operator network providing mobile and fix access . . . . 82 A high level view of a converged operator network . . . . . . . . . . . . . . . . 93 LTE reference network architecture . . . . . . . . . . . . . . . . . . . . . . . . . 114 Overview of the LTE user plane . . . . . . . . . . . . . . . . . . . . . . . . . . 125 LTE user plane protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 LTE control plane protocol stack (I) . . . . . . . . . . . . . . . . . . . . . . . . 147 LTE control plane protocol stack (II) . . . . . . . . . . . . . . . . . . . . . . . . 158 IEEE 802.11 architecture: entities . . . . . . . . . . . . . . . . . . . . . . . . . 169 IEEE 802.11 architecture: protocol layers . . . . . . . . . . . . . . . . . . . . . 1710 Proxy Mobile IPv6 deployment scenario . . . . . . . . . . . . . . . . . . . . . . 1811 Data and control plane layers in PMIPv6 example . . . . . . . . . . . . . . . . . 1912 Main components of data service delivery over DSL . . . . . . . . . . . . . . . . 2113 Protocols on a DSL IP service delivery network . . . . . . . . . . . . . . . . . . 2114 Components of FTTH solutions, with point-to-point and point-to-multipoint (PON)

local loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2215 Protocol layers for point-to-point FTTH service delivery . . . . . . . . . . . . . 2316 Protocol layers for G-PON FTTH service delivery . . . . . . . . . . . . . . . . . 2417 High-level representation of the entities connected by Metropolitan Area Networks 2518 Carrier Ethernet network implemented with 802.1ad (Q-in-Q) . . . . . . . . . . 2619 Carrier Ethernet network implemented with 802.1ah (MAC-in-MAC) . . . . . . 2720 Carrier Ethernet network implemented with Ethernet over MPLS over Ethernet . 2821 MPLS-based MAN control plane . . . . . . . . . . . . . . . . . . . . . . . . . . 2822 Service provider core network based on MPLS technologies . . . . . . . . . . . 2923 Data plane of a BGP-free MPLS-based service provider core network . . . . . . 3024 Control plane of a BGP-free MPLS-based service provider core network (without

VPN control plane protocols) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3125 Scaling the MPLS-TE data plane using hierarchical LSPs . . . . . . . . . . . . . 3126 Service provider edge, dedicated to interconnection with other networks . . . . . 3327 Schematic of the DCN of a large-scale data-centre . . . . . . . . . . . . . . . . . 3428 Data plane of a DCN with an IPv6-based fabric and multi-tenant support . . . . . 3529 Control plane of a DCN with an IPv6-based fabric and multi-tenant support . . . 3630 Layer 3 VPN model from RFC 4364 . . . . . . . . . . . . . . . . . . . . . . . . 3631 RFC 4364 Layer 3 VPN data plane . . . . . . . . . . . . . . . . . . . . . . . . . 3732 RFC 4364 Layer 3 VPN control plane . . . . . . . . . . . . . . . . . . . . . . . 3833 RFC 4761/2 VPLS architecture (CE directly attached to PE) . . . . . . . . . . . 3934 RFC 4761/2 VPLS data plane (CE directly attached to PE) . . . . . . . . . . . . 4035 RFC 4761/2 VPLS control plane (CE directly attached to PE) . . . . . . . . . . . 41

6




36 Example of Hierarchical VPLS (H-VPLS) data plane . . . . . . . . . . . . . . . 4237 Example of PBB VPLS data plane . . . . . . . . . . . . . . . . . . . . . . . . . 4238 Classical Manager - Management Agent paradigm . . . . . . . . . . . . . . . . . 4739 Current situation: lack of convergence in the Network Management System (source:

NGMN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4840 Harmonization of models for fixed and wireless network segments (source: NGMN) 4941 SDN Architecure Overview (source: ONF) . . . . . . . . . . . . . . . . . . . . 5042 High level view of the main parts of a converged service providers network . . . 5243 Converged operator network data plane layers: residential fixed Internet access . 5344 Converged operator network control plane layers: residential fixed Internet access 5445 Converged operator network data plane layers: 4G Internet access . . . . . . . . 5546 Converged operator network control plane layers: 4G Internet access . . . . . . . 5647 Converged operator network data plane layers: Layer 3 VPN between customer sites 5748 Converged operator network control plane layers: Layer 3 VPN between customer

sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7




1 Motivation for converged operator networks

Although network convergence is a long desired goal, current service providers are still workingto integrate different access technologies and different network services into a single, commoninfrastructure. Figure 1 shows a typical example of a network operator that is providing Internetaccess and other dedicated network services (such as VPNs or voice) to its customers via fixed andmobile access technologies. The picture highlights the main inefficiencies that service providersare facing in this type of environment:

Ethernet Aggregation

ATM Aggregation

PSTN

Service Platforms

Mobile IP Backbone

TDM

Fixed IP Backbone

ATM Aggregation

Ethernet Aggregation

Radio base stations

2G/3G/4G

Micro, Pico solutions

DSLAM IP

Voice DSLAM ATM

data

Distribution SWITCH

ADSL

Copper Loop Up to 5 Kms (voice+data)

Homes

Businesses Fiber p2p Enterprises

and homes (FTTH/FTTC)

Individuals

Voice

Voice

data

data Internet

Internet

Service Platforms

ONT

Figure 1: A high level view of an operator network providing mobile and fix access

• Different access technologies use a dedicated aggregation and backbone network segments,resulting in a poor utilization of the infrastructure.

• Users will have different subscriber profiles depending on the way they are connecting tothe network (mobile vs. fix).

• The provider must deploy duplicated service platforms, each of them attached to the relevantbackbones (mobile vs. fix).

• Service continuity when transitioning from one type of access to another (e.g. mobile toWiFi to DSL/FTTH) is very challenging, due to the lack of backbone and service platformintegration.

• Deployment of new services also becomes cumbersome due to the same reasons.

8




• All of the former issues result in complex network management, usually employing sepa-rated, specific management solutions for the mobile and the fix network. Not only does thisapproach rise operational costs but it also causes the network to be less reliable than it could.

More and more network operators are becoming aware that this way of deploying networkswill not provide a sustainable basis to support their business in the long run. Future-proof serviceproviders must design and deploy converged networks that are capable of supporting any accessmedia and any application requirement using a common infrastructure. In this type of networkcustomers would have a single profile, enabling them to access the services purchased to theprovider via any access technology foreseen in his contract.

Manage users and sessions, Local managed services

Capillarity, Capacity, Mobility support

Multiplexing Switching, Transport

Control functions, Regional managed services

Devices

Places

Users Access Aggregation Local Points of Presence Core Regional Data Centres

Radio

Fiber

Figure 2: A high level view of a converged operator network

Figure 2 shows a simplified, high level view of how a converged operator network could looklike. Multiple access subnetworks (for copper, radio, fibre, coax, satellite and any physical mediumsupported by the provider) are connected to a common aggregation platform (e.g. a Metropoli-tan Area Network), which multiplexes the traffic and delivers it to one ore more local Points ofPresence (PoPs). These PoPs are used to manage customers and sessions, authenticating users androuting their traffic towards their desired services - which may be a small datacentre located at thePoP itself, regional data centers attached to the network core, the Internet, virtual private networks,etc. Local PoPs provide points of entry to the providers core network, which performs transportand switching functions between Local PoPs, regional datacentres and interconnects with otherproviders.

This deliverable analyzes what technologies can be used today to design and implement such aconverged network vision following an all-IP approach - which is the current trend in the telecom-munications and computer networking industry. In order to allow for a best-case comparison witha RINA design in D2.2, we have adopted the perspective that the provider designs his networkfrom scratch. This way there is no need to consider support for legacy technologies, minimizingthe number of protocols required in the network.

9




2 Current network technologies and protocols

Section 2 reviews the main technologies and protocols used in the different parts of a typicalservice providers network today, with the goal of analyzing how the multiple components thatintegrate it interact with each other and how the various protocols are layered and interoperate.The conclusions of this analysis will be used in section 3 to design the architecture of a convergedservice provider network, supporting multiple types of access media and a varied set of networkservices.

2.1 Access networks

Access networks are used to physically connect multiple types of customers (corporate, residen-tial) to the service providers network. There are different types of access network depending onwhich physical media they are based on (radio, optical fibre, copper, coax), their scope and levelof service. In this document we focus on four types of access technologies which provide a veryrepresentative set of the full access network spectrum:

• LTE Advanced as an example of cellular radio access networks.

• IEEE 802.11 (WiFi) as an example of Wireless Local access networks.

• xDSL as an example of copper-based access networks.

• FTTH technologies (both point to point and point to multipoint) as an example of opticalfibre access networks.

2.1.1 Cellular networks: LTE Advanced

LTE, Long Term Evolution, is a 3GPP standard for a cellular wireless access network [1]. It is anevolution of the UMTS/HSPA standards, with a new radio interface and core network improve-ments. The LTE reference network architecture presented in Figure 3 displays the main entities ofan LTE network. LTE elements are divided into two functional areas: the user plane, which trans-ports user data to/from the mobile access network to/from an external IP network; and the controlplane, which manages the user plane resources and performs functions such as user authentication,billing or charging.

• User Equipment, UE. The mobile device, connects to an eNodeB over the LTE-Uu inter-face.

• eNodeB, eNB, the base station. Performs radio resource management functions such asdynamic resource allocation, radio admission control or connection mobility control. Con-nected to other eNodeBs via X2 interface. A network of eNodeBs forms a 4G Radio AccessNetwork (RAN), called E-UTRAN (Evolved UMTS Terrestrial Radio Access Network).

10




E-UTRAN (4G RAN, LTE)

eNodeB UE

X2 S1-MME

S1-U

ServingGateway

PDNGateway

S5

S10HSS

S6aPCRF

Gx

PDNs

APNs

SGi U-Plane

C-Plane

EPC = PS domain

Figure 3: LTE reference network architecture

• Serving Gateway, S-GW. Provides connectivity between a number of eNodeBs and one ormore PDN Gateways. The S-GW is the local mobility anchor for inter-eNB handover andhandovers with other 3GPP networks.

• PDN Gateway, P-GW. Connects the EPC (Evolved Packet Core) to an external IP net-work (e.g. the Internet, an IMS network, etc.). Assigns an IP address to the UE from thePDN space. It is the mobility anchor for handovers between 3GPP and non-3GPP accessnetworks. It performs policy enforcement, packet filtering and charging based on the rulesprovided by a PCRF.

• Mobility Management Element, MME. It communicates with an HSS for UE authenti-cation and profile download, and provides UEs with EPS mobility management and EPSsession management. It also performs paging functions and manages tracking area lists.

• Home Subscriber Server, HSS. Central database where user profiles are stored, along withauthentication information.

• Policy and Charging Rules Function, PCRF. Stores policies to provide the adequate qual-ity of service to the EPS bearers of the different users, as well as information to charge andbill based on the user profile.

In essence the mobile access network is a very large IP subnetwork where UEs are the hostsand P-GWs the border routers to an external IP Network (the public Internet or an IMS networkfor instance). UEs and P-GWs are one hop away of each other, the other entities in the mobileaccess network user plane work together to provide virtual layer 2 flows between UEs and P-GWscalled EPS bearers. The particularity of EPS bearers is that they continue to deliver service evenif the UE moves through the mobile access network. Figure 4 shows a conceptual diagram of theuser plane of an LTE network, with a UE connected to a P-GW via an EPS bearer.

11




PS domain = IP network

Stable node (P-GW)

Intermediate anchor (S-GW)

IP address

Mobility tunnel

HO / cell selection

Relocation

Selection

UE

eNodeB

SGSN

ePDG Non-3GPP access, e.g. Wi-Fi, WiMAX

EPS bearer = concatenation of radio bearer + S1 bearer (GTP tunnel between eNB and S-GW) + S5/S8 bearer (GTP tunnel between S-GW and P-GW)

Figure 4: Overview of the LTE user plane

12




Each EPS bearer is implemented through a concatenation of three tunnels: one between the UEand the eNB (the radio bearer), another one between the eNB and the S-GW (the S1 bearer) andanother one between the S-GW and the P-GW (the S5/S8 bearer). When the UE moves through theLTE network and changes its attachment to eNBs (a procedure called handover), the LTE controlplane has to destroy and re-create some of these tunnels. There are four main cases:

• Handover between two eNBs attached to the same S-GW. In this case both the radio bearerand the S1 bearer have to be destroyed and re-created. eNBs and/or S-GWs buffer packetsduring the handover procedure in order to avoid any losses.

• Handover between two eNBs attached to different S-GWs. In this case the three tunnels haveto be destroyed and re-created.

• Handover to a UMTS network. The UE moves outside of the scope of the E-UTRAN to aUTRAN. The same S-GW may be re-used or a new one has to be selected, therefore at leasttwo tunnels have to be destroyed and re-created.

• Handover to a non-3GPP access network such as WiFi. The UE moves outside of a 3GPPaccess network and therefore the EPS bearer concept no longer applies. L3 connectivityis preserved through the use of a Layer 3 mobility solution such as Proxy Mobile IP v6(PMIPv6).

IP (end to end)

TCP or UDP

PDCP GTP-U

Protocol conversion

GTP-U

RLC

MAC

L1

UDP

IP (LTE transport)

MAC MAC . . .

L1 . . . L1

UDP

IP (LTE transport)

MAC MAC . . .

L1 . . . L1 UE

eNodeB S-GW P-GW

EPS bearer EPS bearer

LTE-Uu

S1-U S5/S8

MAC

L1

SGi

Figure 5: LTE user plane protocol stack

Figure 5 shows an overview of the LTE user-plane protocol stack. In the radio access segmentthere are three main protocols. PDCP, the Packet Data convergence Protocol, tunnels IP packetsover the radio link. It performs header compression, ciphering and integrity protection as well as

13




packet re-ordering and retransmission if required. RLC, the Radio Link Control protocol, per-forms segmentation/concatenation of PDCP PDUs. The LTE MAC layer provides the multiplex-ing functions between the RLC layer logical channels and the physical layer transport channels.It also performs scheduling of PDUs according to the QoS characteristics of the different logicalchannels.

The other segments (eNB/S-GW and S-GW/P-GW) are interconnected by the internal trans-port IP network. GTP-U over UDP, the GPRS tunneling protocol, is used at each segment toimplement the tunnels belonging to the different bearers over the transport IP network. Each node(eNB, S-GW and P-GW) has an internal forwarding table maintained by the LTE control plane,which is used to forward data from tunnel to tunnel within an EPS bearer. When a handover occurstunnels and mappings have to be updated. Therefore we can characterize packet forwarding withinthe EPC (Evolved Packet Core) as a virtual circuit switching strategy.

PDCP

Protocol conversion

GTP-C

RLC

MAC

L1

SCTP

IP (LTE transport)

MAC MAC . . .

L1 . . . L1

UDP

IP (LTE transport)

MAC MAC . . .

L1 . . . L1 UE

eNodeB MME S-GW

LTE-Uu

S1-MME S11

RRC S1-AP

NAS

GTP-C

UDP

IP (LTE transport)

MAC MAC . . .

L1 . . . L1

S5 P-GW

Figure 6: LTE control plane protocol stack (I)

Figures 6 and 7 show an overview of the main LTE control-plane protocol stacks. Interac-tion between the UE and eNodeB is controlled by the RRC protocol (Radio Resource Control),which performs functions required for efficient management of radio resources (e.g. radio bearerallocation) and supports the transfer of the NAS signaling. eNodeBs interact with the MobilityManagement Element (MME) via the S1AP protocol (S1 Application Protocol), which performsfunctions such as E-RAB management, UE context management and NAS signaling transport.UEs interact with MMEs via the NAS (Non-Access Stratum) protocol, which performs mobilitymanagement and bearer management functions. The MME interacts with the S-GW via the GTP-C protocol, which supports the exchange of control information to setup and manage GTP tunnels.It is also the same protocol through which the S-GW and the P-GW interact.

eNodeBs interact with each other through the X2AP protocol (X2 Application Protocol),which supports UE mobility (data forwarding, UE context release) and self-optimization network

14




eNodeB

X2-AP

SCTP

IP (LTE transport)

MAC MAC . . .

L1 . . . L1

X2 eNodeB MME

GTP-C

UDP

IP (LTE transport)

MAC MAC . . .

L1 . . . L1

S10 MME MME

Diamater

SCTP

IP (LTE transport)

MAC MAC . . .

L1 . . . L1

S6a HSS P-GW

Diamater

SCTP

IP (LTE transport)

MAC MAC . . .

L1 . . . L1

Gx PCRF

Figure 7: LTE control plane protocol stack (II)

functions (coordination with other eNodeBs to optimize handovers) within the E-UTRAN. MMEscoordinate via the GTP-C protocol. MME interacts with the HSS via the Diameter protocol,which supports the exchange of subscription and subscriber authentication information. Diam-eter is also used between the P-GW and the PCRF in order to obtain the Policy and ChargingControl (PCC) rules.

2.1.2 WiFi (IEEE 802.11) and Proxy Mobile IPv6 (PMIP)

2.1.2.1 WiFi (IEEE 802.11)

IEEE 802.11 [2], also known as WiFi, is the most commonly deployed technology for WirelessLocal Area Networks (WLANs), allowing devices to communicate via radio waves. The IEEE802.11 protocol specifies the MAC and Physical layers of the OSI reference model. Figure 8depicts the main entities of the WiFi architecture, operating in infrastructure mode (in ad-hocmode the architecture is just a set of stations forming a mesh network).

• Station, STA. Any device that contains an IEEE 802.11 conforming MAC and physicallayer.

• Access Point, AP. Any entity that has station functionality and provides access to the dis-tribution system via the wireless medium for associated stations.

• Basic Service Set, BSS. A set of stations controlled by a single coordination function(equivalent to a cell in cellular networks).

• Distribution system, DS. A system used to interconnect a number of BSS and integratedLANs to create an Extended Service Set.

• Extended Service Set, ESS. A set of one or more interconnected BSSs and integrated LANsthat appear as a single BSS to the LLC layer.

• Portal. A device that provides access to another local area network or wide area networkby relaying at the network layer.

15




Portal

IEEE802.xLANorWAN

AP AP AP

STASTA

STASTA

STA

STASTA STA

Distribution System

BSS BSS BSS

Extended Service Set (ESS)

Figure 8: IEEE 802.11 architecture: entities

IEEE 802.11 is designed to provide stations with a similar level of service as if they wereconnected to a wired LAN, with the added ability of station mobility. WiFi defines three transitiontypes based on mobility: no transition (stationary stations or stations that never get out of the rangeof a single BSS), BSS transition (stations that roam between BSSs belonging to the same ESS) andESS transition (stations roaming between BSSs belonging to different ESSs). In the case of BSStransitions IEE 802.11 can perform seamless (non service-affecting) handovers, but this propertycannot be guaranteed for ESS transitions (has to be managed at higher layers).

Figure 9 shows the different OSI layers in the different devices of the IEEE 802.11 architecture.The left part of the figure shows an example of the layers between two STAs that belong to differentBSSs of the same ESS. The right part of the figure shows the layers of an STA connecting to a hostoutside of the ESS. In contrast with IP-based designs, the functions performed by the WiFi MAClayer are not divided into different protocols (belonging to so-called control or data planes), butare components of the IEEE 802.11 MAC protocol. Depending of the role of the functions, theyare divided into three main categories that result in three different PDU types: data transfer, datatransfer control and layer management.

Layer management functions basically take care of association management and authentica-tion. Association management comprises three functions: association, reassociation and disasso-ciation. The association function allows a station to establish an initial association with an accesspoint: this way the AP learns the identity and address of the station and optionally authenticatesit. Then the AP communicates this information to other APs within the ESS to facilitate routingand forwarding. Reassociation allows an established association to be transferred from one AP toanother, facilitating the mobility of the station from one BSS to another. Finally, the disassocia-

16




IP

TCP or UDP

LLC

IEEE 802.11 (MAC)

PHY (802.11..) PHY (802.11..) DN layer(s)

. . . STA

AP AP

STA

BSS BSS DS

ESS

AP

PHY (802.11..)

IEEE 802.11 (MAC)

DN layer(s)

. . .

Portal

LLC

IP

MAC MAC . . .

L1 . . . L1

Host STA

TCP or UDP

BSS DS

ESS

Figure 9: IEEE 802.11 architecture: protocol layers

tion function terminates an existing association, causing the APs in the ESS to update its internalstate.

The two main data transfer control functions are reliable data delivery and medium accesscontrol - flow control is provided by the logical link control sublayer, on top of the MAC sublayer.Reliable data delivery functions are in charge of bounding the packet loss rate seen by higherlayers, so that it is sufficiently small for that layer to operate correctly. Data transfer controluses an immediate acknowledgement scheme, in which the receiver has to acknowledge (ACK)each PDU right after receiving it. If the senders retransmission timer expires without havingreceived an ACK it retransmits the original frame. Since the physical medium is shared, IEEE802.11 specifies two coordination functions to decide which station can transmit: a distributedcoordination function based on sensing the physical media before attempting a transmission -and backing off exponentially if a collision is detected; and an optional centralized MAC controlalgorithm to provide contention-fee service. To further decrease the likelihood of a collision, theRequest to Send (RTS) and Clear To Send (CTS) PDUs can be used by stations before transmittinga frame.

Data transfer functions are in charge of forwarding data between stations on the same or dif-ferent BSSs and to optionally provide privacy and confidentiality through the use of encryption.

2.1.2.2 Proxy Mobile IPv6 (PMIP)

Mobility across WiFi APs is limited to a layer 2 domain only unless there is some support providedby higher layers. If a network operator wants to provide seamless mobility across a relatively largelogical area (such as a campus network) it needs to combine WiFi mobility with an IP mobility so-lution. Proxy Mobile IPv6 (PMIP) [3] is a network-based mobility management protocol designed

17




with this goal in mind, also enabling mobility between Wireless LANs and 3GPP mobile accessnetworks. The rationale for PMIPv6 is based on three factors: i) MIPv6 [4] requires changes tothe protocol stack in OS kernels and is hard to deploy; ii) the hand-off is not efficient and incurslarge delay; and iii) kernel modifications opens the opportunity for security attacks. Basically,PMIPv6 goes back to using a Foreign Agent as in MIPv4 [5], and is limited to localized networkswith limited topology where hand-off signaling delays are minimal.

PublicInternet

Large-scale RINA Experimentation on FIRE+ 4

MAG

AP AP

STA/ MN

STA/ MN

STA/ MN

STA/ MN STA/

MN

STA/ MN

STADistribution System

BSS BSS


MAG

AP AP

STA/ MN

STA/ MN

STA/ MN

STA/ MN

STA/ MN

STA/ MN

Distribution System

BSS BSS


LAGIPv6 network

IPv6-in-IPv6tunnel

IPv6-in-IPv6tunnel

Local Mobiliy Domain (LMD)

Figure 10: Proxy Mobile IPv6 deployment scenario

Figure 10 shows an example PMIP deployment scenario, illustrating all the entities that arespecified by the protocol.

• Local Mobility Domain (LMD). A network that is PMIP enabled and consists of one LMAand multiple MAGs.

• Local Mobility Anchor (LMA). All traffic from and to the Mobile Node (MN) is routedthrough the LMA. The LMA maintains a set of routes for each MN connected to the LMD.

• Mobile Access Gateway (MAG). The MAG performs the mobility-related signaling onbehalf of the MNs attached to the access links and is usually the first-hop router for the MH.

• Mobile Node (MN). A host that moves through the LMD.

When the MN attaches the LMD, it requests an IPv6 prefix to the MAG. The MAG authen-ticates the client via its MAC address, and requests an IPv6 prefix for the MN to the LMA. TheLMA allocates a prefix for the MN and associates the MN prefix to the MAG address. After thatthe LMA creates an IPV6-in-IPv6 tunnel that is used for tunneling packets originated from and

18




addressed to the mobile node. After the tunnel is created, the MN gets assigned its prefix by theMAG, creating a routing table entry for the prefix.

AP

PHY (802.11..)

IEEE 802.11 (MAC)

DN layer(s)

. . .

MAG

PPP over Ethernet

IPv6

MAC

MAC

. . .

L1 . . .

L1

Host

MN

TCP or UDP

BSS DS

ESS

MAC

L1

IPv6

LAG

MAC

L1

. . .

. . .

LMD MAC . . .

L1 . . .

MAC

L1

IPv6

PMIPv6

MAG LAG

Figure 11: Data and control plane layers in PMIPv6 example

When there is a handover, the MN detaches from the original MAG (which detects it via somelayer 2 event). The MAG notifies the LMA, which starts a timer to detect if the MN has leftthe LMD or is just re-attaching to another MAG. The MN attaches to another MAG, following theprocedure explained in the former paragraph. This time, when the LMA receives the prefix requestfrom the MAG, it sees it has an entry already for the MN, so it stops the timer, updates the entryassociated to the MN, sets up the tunnel with the new MAG and responds with the same IPv6prefix. Since the MN doesnt see an IP address change, all ongoing transport layer connectionsremain open. The control and data plane protocols involved in PMIP operation are depicted inFigure 11.

PMIPv6 relies on a single, centralized mobility anchor (the LMA), creating a bottleneck anda single point of failure and forcing all the traffic to/from Mobile Nodes in a mobility domain togo through the LMA. DMM protocols being considered at the IETF aim at distributing mobileInternet traffic in an optimal way while not relaying on centrally deployed mobility anchors [6].The model under consideration is still a flat (single layer) Internet architecture with all-IP backhaul

19




support, where multiple mobility anchors are distributed among the access network.[7] provides a discussion on how to materialize the DMM goals in practice using three different

approaches:

• Using an evolution of PMIPv6 therefore tunnels - distributing the forwarding amongstmultiple mobility anchors but keeping a centralized database;

• Using SDN - even more centralized, a central controller has to configure the forwardingtables of all mobility anchor routers, also requiring these mobility anchor routers to dotranslation of IP addresses in the packets from/to mobile nodes;

• Using BGP routing and DNS. This solution uses no mobility anchors at all, just routingupdates to update the location of the Mobile Node in the network. However, two problemswith this approach are: i) since the scope of the network layer is the whole world routingconvergence is too slow; and ii) since the Mobile Node IP address does not change (it isnot an address), routing overhead is high and contributes to further increases in the size offorwarding tables tracking mobile nodes.

2.1.3 xDSL

Digital Subscriber Line (DSL) technologies ?? is a collective term for a set of transmission tech-nologies for delivering data services on the access loop. DSL is designed to exploit the installedbase of twisted pair telephone copper cable to transport data services. This feature has made DSLcommercially attractive to service providers, who use it to provide Internet access, IPTV, VPNsor VoIP to residential and enterprise customer. Figure 12 provides an overview of the differentelements in the customer and service provider networks used for delivering data services overDSL.

DSL technologies provide connectivity between the home router (Customer Premises Equip-ment, CPE) and the DSLAM (Digital Subscriber Line Access Multiplexer). DSLAMs, usuallylocated at telephone exchanges, connect to multiple customer CPEs, aggregating their traffic andforwarding it to a Broadband Remote Access Server (BRAS) over the providers aggregation net-work. BRASs are a key component of DSL broadband access networks that serve as an aggrega-tion point for subscriber traffic (IP, PPP and ATM) and provide session termination and subscribermanagement functions such as authentication, authorization, accounting (AAA), and IP addressassignment.

Figure 13 depicts the protocols that are typically used to provide data services over DSL. TheCPE is physically connected to the DSLAM via the twisted pair copper cable; that is where DSLphysical layer provides its service. ATM was traditionally layered on top of DSL, since DSLAMstypically operated over ATM aggregation networks. Today service providers are converging to-wards Ethernet aggregation using Carrier Ethernet solutions, therefore DSLAMs have evolved tosupport Ethernet uplinks instead of ATM ones.

20




CPEHost

Host

LAN

CPEHost

Host

LAN

CPEHost

Host

LAN

DSLAM

DSLAM

AggregationBRAS Core

Home 1

Home 2

Home N

Local loop (copper)

Figure 12: Main components of data service delivery over DSL

Host

CPE

PHY

802.3 (MAC)

IP

DSLAM BRAS

TCP or UDP

MAC . . .

L1 . . .

MAC

L1

Host

PPP and PPPoE

802.3 (MAC)

ATM

xDSL

802.1q or ad

Aggregation layer(s)

Customer network

Provider network

Local loop Aggregation

Figure 13: Protocols on a DSL IP service delivery network

21




Assuming Ethernet is used at the providers metropolitan aggregation network, 802.1q or802.1ad over other protocols (refer to the Aggregation section of this document) is used to in-terconnect the DSLAM with the BRAS. The CPE needs to run a Point to Point Protocol overEthernet (PPPoE) session against the BRAS, so that the BRAS can authenticate each individualcustomer and assign one or more IP addresses to it depending on the services it has purchasedfrom the provider (Internet access, VoIP, etc.). EAP, the Extensible Authentication Protocol, isnormally used to carry out authentication, usually through the interaction with a Radius server.Once authenticated, the customer traffic is routed via the providers core to its final destination(other customers on the provider network, the Internet, etc.)

2.1.4 Fiber to the Home

Fiber to the home (FTTH) is the delivery of a communications signal over optical fiber from theoperators switching equipment all the way to a home or business. Connectivity over the local loopis provided via optical fibre via two main architectures: point to point and point to multipoint.Point-to-point solutions connect the customers CPE to active service providers switching equip-ment (usually Ethernet) via a dedicated fibre. In point to multi-point deployments the optical fiberis shared among multiple customers, whose signals are multiplexed via TDM or a combination ofTDM and WDM. Passive splitters allow the combination/splitting of individual user signals. Thisarchitecture is usually called Passive Optical Network or PON.

LAN

CPE

HHLAN

CPE

HHLAN

CPE

HHLAN

CPE

HHLAN

CPE

HHLAN

CPE

HHLAN

CPE

HHLAN

CPE

HH

Eth Switc

h

Eth Switc

h

LANHH

LANHH

LANHH

LANHH

LANHH

LANHH

LANHH

LANHH

Passive splitter

Passive splitter

Eth Switch / IP router

Eth Switch / IP router

CPE CPE CPE CPE CPE CPE CPE CPE

Multi Service Edge

Aggregation

Core

Point to Multipoint

(PON)

Point to Point

Local loop (Fibre)

Figure 14: Components of FTTH solutions, with point-to-point and point-to-multipoint (PON)local loops

22




Both approaches have their pros and cons. PON infrastructures require less fibre, no activeequipment in the local loop and less ports in the operators aggregation switches and are cheaperto deploy. In contrast point-to-point solutions have more bandwidth per subscriber, the bandwidthis symmetrical (equal upload and download capacity), are easier to test, maintain and upgrade anddeliver maximum flexibility.

Host

PHY

802.3 (MAC)

IP

TCP or UDP

. . .

. . .

MAC

L1

Host

802.3 (MAC)

PHY

CPE Local Loop Switch

PHY

Aggregation Switch


MAC

L1

Multi Service Edge

802.1q

. . .

Customer network


Provider Network

PPP and PPPoE

Figure 15: Protocol layers for point-to-point FTTH service delivery

Figure 15 shows the protocols that are usually used to deliver network services over FTTHpoint to point access. In fact, the figure is very similar to that of the xDSL technology, withdifferent local loop technologies. The CPE is directly connected to an Ethernet switch usuallydeployed in the neighborhood, aggregating multiple point-to-point links to different customers. Inturn, this local aggregation switch is connected to an access aggregation Ethernet switch (or IProuter), which is connected to the service providers metropolitan aggregation network. The aggre-gated traffic of multiple customers is delivered to a Multi Service Edge router, where individualcustomers are authenticated and its traffic routed to different destinations over the providers core(public Internet, VoIP network, etc).

Figure 16 shows the same scenario but in the case of a PON deployment. What changes inthis situation is that there are no local aggregation switches - just splitters - which means the CPEsare directly connected to the aggregation switch via the PON layers. Multiple PON technologiesexist, the Figure depicts the use of GPON [8], in which Ethernet frames are encapsulated insideGEM (GPON encapsulation method) frames.

23




Host

PHY

802.3 (MAC)

IP

TCP or UDP

. . .

. . .

MAC

L1

Host

802.3 (MAC)

CPE

PHY (GPON)

Aggregation Switch


MAC

L1

Multi Service Edge

802.1q

. . .

GEM


Provider Network

Customer network

PPP and PPPoE

Figure 16: Protocol layers for G-PON FTTH service delivery

2.2 Metro aggregation

Metropolitan Area Networks (MAN) are responsible of i) aggregating all the access traffic in ametropolitan (or rural) region and delivering it to the providers core network PoPs and ii) to deliverthe traffic of the providers core PoPs in a certain region to the different access networks. Someyears ago most of the traffic transported by a MAN was either originated outside of the MANor destined towards the operators core; but the advent of Cloud computing, the popularization ofContent Distribution Networks (CDNs) and the placement of datacenters providing Cloud servicesdirectly connected to the MAN has increased the ratio of intra-MAN traffic, which has in turninfluenced its design.

Regarding technologies for implementing MAN networks, there are two main alternatives.A full Ethernet MAN providing carrier Ethernet services across MAN PoPs is suitable if all thetraffic transported by the MAN is of IP/Ethernet nature. Carrier Ethernet services itself may beimplemented only via Ethernet technology or by leveraging MPLS. If the MAN has to transport adiverse traffic mix consisting of IP/Ethernet but also of ATM and other legacy technologies, thenan IP/MPLS MAN network is the most adequate choice.

2.2.1 Carrier Ethernet MAN

In a Carrier Ethernet network customer Ethernet data is transported across Point-to-Point, Point-to-Multipoint and Multipoint-to-Multipoint Ethernet Virtual Circuits (EVCs). Carrier Ethernet

24




Wireless Access

xDSL, PON Ethernet access

eNodeB traffic

PtP Ethernet Access

Local DataCentre

Core router

Metropolitan Area Network

Service Edge (LAG, S/P-GW, BRAS, etc)

Metro Edge

Metro Edge

Metro Edge

Metro Edge

Metro Edge

Metro Edge

Metro Core

Metro Core

Metro Core

Core PoP

Figure 17: High-level representation of the entities connected by Metropolitan Area Networks

service providers connect to customers via Ethernet port-based or VLAN-based UNIs (User toNetwork Interfaces), and exchange traffic with other carrier Ethernet service providers via E-NNIs (Ethernet Network to Network interfaces). The MEF (Metro Ethernet Forum) defines threemain categories of carrier Ethernet services that can be configured with a rich set of attributes(bandwidth profiles, classes of services, performance objectives, forwarding rules, etc.) [9].

• E-Line. Point-to-point EVCs. There are two types of E-Line services: Ethernet PrivateLine, a Port-based service with single EVC across dedicated UNIs; and Ethernet VirtualPrivate Line, which enables multiple point-to-point EVCs to be delivered over a single UNIto customer premises.

• E-LAN. Multipoint-to-multipoint EVCs. There are two types of E-LAN services: EP-LAN,which provides a transparent LAN service; and EVP-LAN, in which participating UNIs canbe devoted to different services.

• E-Tree. Rooted multipoint EVCs. Two options are also available: EP-Tree and EVP-Tree.

2.2.1.1 Ethernet-based design

One way of providing Carrier Ethernet services is via an Ethernet-based design, in which theCarrier Ethernet provider network is composed by bridges that forward the customer Ethernet

25




frames towards their output destinations. Customer services may be port-based or VLAN-based,therefore the provider has the need to isolate its internal VLAN space from the customers VLANspace. IEEE 802.1ad or Q-in-Q [10] allows the provider to introduce an additional VLAN tag tothe Ethernet frame; thus enabling the carriage of multiple customer VLANs over a single providerVLAN, as shown in Figure 18. 802.1ad enabled Ethernet bridges are also called Provider Bridges.

Eth PHY Eth PHY Eth PHY Eth PHY

Edge Provider Bridge

Edge Provider Bridge

Provider Bridge

Customer Bridge

Customer Bridge

802.1ad 802.1q 802.1q

Carrier Ethernet Network

Protocol conversion / Local

bridging

Figure 18: Carrier Ethernet network implemented with 802.1ad (Q-in-Q)

However Provider Bridging has three big limitations. One is that the customer and providernetworks are not properly isolated, and provider bridges have to learn all customer MAC ad-dresses, which damages scalability. A second problem is that the number of service instances inthe provider network is limited to 4096. Last but not least, the provider uses the Spanning TreeProtocol (STP) to route Ethernet frames across the provider network, which hinders the ability toperform traffic engineering.

IEEE 802.1ah [11] or Provider Backbone Bridging (PBB, also known as MAC-in-MAC), wasdesigned to overcome the first two limitations. In a PBB network, the edge bridges (called Back-bone Edge Bridges) encapsulate customer MAC frames into a backbone MAC frame which usesbackbone MAC and VLAN addresses. Ethernet frames in the backbone are forwarded accordingto the destination backbone MAC address and VLAN, thus isolating the providers address spaceand routing domain from the customers address spaces (Figure 19). Moreover PBB also defines a24-bit service instance tag, which allows a PBB network to support 4096*4096 service instances.

PBB still uses the SPT to forward frames across the PBB network, thus still being unable ofperforming traffic engineering. Two solutions to this issue exist. One is to use PBB-TE (PBBwith Traffic Engineering), IEEE 802.1Qay [12]. In PBB-TE there is no STP instance running;instead the management system provisions a series of PBB-TE trunks across the PBB network viastatic forwarding database entries, taking care of not creating forwarding loops. Backbone EdgeBridges assign MAC frames belonging to specific service instances to a particular PBB-TE trunk.

26




Eth PHY

Eth PHY Eth PHY

Eth PHY

Backbone Edge

Bridge

Backbone Edge

Bridge

Backbone Core

Bridge

Customer Bridge

Customer Bridge

802.1q


802.1ah

Figure 19: Carrier Ethernet network implemented with 802.1ah (MAC-in-MAC)

The other option is to deploy an SPB (Shortest Path Bridging) control plane instead of STP. SPB(IEEE 802.1aq [13]) brings link-state routing to PB and PBB Ethernet networks.

2.2.1.2 Ethernet over MPLS design

A popular alternative to IEEE 802.1 technologies in carrier Ethernet networks is to use a MPLSnetwork to deliver the Ethernet services, design known as Ethernet over MPLS (EoMPLS) [14].In fact this design is very similar to PBB-TE. MPLS edge routers are connected via pre-configuredLabel Switch Paths (outer MPLS label, used for forwarding the PDU across the provider network).Each individual Ethernet service is assigned another MPLS label (inner label), which is used atthe egress MPLS switch to deliver the payload to the correct UNI. The data plane for the EoMPLSsolution is depicted in Figure 20.

2.2.2 MPLS-based MAN

MPLS-based Metropolitan Area Networks are a generalization of the Ethernet over MPLS (EoM-PLS) paradigm. MPLS-based MANs are capable of transporting any layer 2 technology over theMAN, such as Ethernet, ATM or Frame Relay [15]. The data and control plane of this solution isessentially the same as in the EoMPLS paradigm, the difference being that the transport servicesare restricted to the emulation of point-to-point circuits (called pseudo-wires) - therefore thereis no support for point-to-multipoint or multipoint to multipoint - unless the technology beingtransported is Ethernet.

Figure 21 shows the protocols in the control plane of an MPLS MAN providing AToM (Any

27




Eth PHY

Eth / Phy Eth / PHY

Eth PHY

Label Edge

Router

Label Edge

Router

Label Switch Router

Customer Bridge

Customer Bridge

802.1q


MPLS

MPLS

Figure 20: Carrier Ethernet network implemented with Ethernet over MPLS over Ethernet

Eth / Phy Eth / PHY

Label Edge

Router (PE)

Label Edge

Router (PE)

Label Switch Router

(P)

Customer Bridge

Customer Bridge

Metropolitan Access Network

IP

IS-IS IS-IS

TCP TCP

LDP LDP

Figure 21: MPLS-based MAN control plane

28




Transport over MPLS) services. All routers in the MPLS networks run an Internal Gateway Pro-tocol (IGP) to discover the connectivity graph of the network - usually OSPF or IS-IS. LDP, theLabel Distribution Protocol, can be used over TCP to negotiate the labels to be used for each LSP- Label Switch Path - and for the different pseudo-wires.

2.3 Core

The core network of a service provider is in charge of transporting the traffic between core Pointsof Presence (PoPs). Traffic at core PoPs may be coming from the operators customers (aggregatedvia the access and metropolitan area networks), local or regional datacentres and other operators(via private peering exchanges or via public exchanges such as Internet eXchange points). Figure22 depicts a core network composed of 4 PoPs interconnected via a meshed ring topology.

PE PE PE PE

P P

. . . . . . . . . . . .

Core PoP

To customers

To customers

To customers

To NOC

To customers

To customers

To peer

To Regional

DC

To Regional

DC

To customers

To customers

To IXP

To IXP

To customers

To customers

To customers

Figure 22: Service provider core network based on MPLS technologies

One design that is becoming very popular among service providers is to run a so-called BGP-free core network. In such a design, service providers leverage the MPLS technology to confine

29




BGP to the network edges (PE routers), thus reducing the memory requirements and CPU load ofthe core routers (P routers). Core routers become completely isolated from the Internet and justforward packets based on MPLS labels, allowing the service provider to have a more stable core.To do so, PEs use MPLS LSPs as the next hop for BGP routes, thus allowing IP packets directedto the Internet to be transported by the MPLS-only core. Such a design is also very convenientsince MPLS in the core is almost a must if the service provider wants to offer L2 and/or L3 VPNservices.

P

L2/L1

L2/L1

PE PE P

IP (Internet) or IP (VPN) or Ethernet (VPN)

Core Network (MPLS-based)

MPLS (LSP)

L2/L1

L2/L1 L2/L1

MPLS (service – VPN/PseudoWire)

Figure 23: Data plane of a BGP-free MPLS-based service provider core network

Figure 23 illustrates an example data plane of a BGP-free MPLS core network. PEs are con-nected via a set of LSPs that transport the traffic via the providers core (P routers just switchpackets according to their MPLS labels). Depending on the type of service provided by the PE(Internet access, L3 VPN or L2 VPN) an additional MPLS service label will be used. This MPLSservice label is only used by the PEs in order to distinguish to which particular service (pseudo-wire, VPN instance) the packet belongs to; therefore it is transparent to the P routers.

In addition to the multi-service support and the BGP-free core, MPLS also delivers two addi-tional benefits to service providers. The first one is the ability to perform traffic engineering on thecore network, allowing the provider to maximize the usage of the network resources and to applya rich set of QoS options to the traffic. Another advantage is the faster reaction to failures via theMPLS fast reroute options, in which backup paths for LSPs are pre-computed and put in placeonce a network failure is detected. Both MPLS fast reroute [16] and traffic engineering optionsrequire the usage of the RSVP-TE protocol [17] in the MPLS control plane, illustrated in Figure24. The Figure show the MPLS control plane protocols required to setup the LSPs, and the iBGPsessions running between PEs to allow for the exchange of Internet routes. Service providers thathave a medium to large number of PEs in their core network use dedicated BGP Route Reflectors[18] in order to minimize the number of BGP sessions in PE routers. Control plane protocols

30




P

L2/L1

PE PE P


L2/L1 L2/L1

IS-IS IS-IS IS-IS

IP

RSVP (TE)

TCP

iBGP

Figure 24: Control plane of a BGP-free MPLS-based service provider core network (without VPNcontrol plane protocols)

P1

L2/L1

L2/L1 PE PE

P1

IP (Internet) or IP (VPN) or Ethernet (VPN)


MPLS (LSP)

L2/L1

L2/L1 L2/L1

MPLS (service – VPN/PseudoWire)

L2/L1 L2/L1

P2 P2

MPLS (LSP)

Figure 25: Scaling the MPLS-TE data plane using hierarchical LSPs

31




required to setup VPN services are not shown, since they are later discussed in section 2.6.2 ofthis document.

Some service providers run very large core networks, so large that may have trouble scalingif the core network follows a flat design such as the one shown in Figure 22. Assuming a fullmesh of LSPs between PE routers, P routers will have to maintain the state of all LSPs betweenPEs; bounding the upper limit of PEs supported by the core network. In order to alleviate thisissue it is possible to use hierarchical LSPs as shown in Figure 25. In this design P1 routers onlymaintain the state of the LSPs between P2 routers, while P2 routers maintain the state of the LSPsthat start/end in the PEs they are directly connected to. A detailed analysis and discussion of theissues in scaling MPLS-TE networks can be found in [19].

2.4 Interconnection

Service provider networks need to exchange traffic with each other in order to be able to reach des-tinations that are not part of the provider’s customer base. Two types of commercial relationshipscan be established between service providers when they exchange traffic: peering and transit.

• When two providers establish a peering agreement they agree to exchange their traffic androuting information for their mutual benefit, so they don’t charge each other. Providersparticipating in peering agreements typically have a similar size and exchange a similaramount of traffic (although this is not always the case).

• When two providers establish a transit agreement one provider (the smaller one) purchasestransit services across the network of the larger provider to get access to other parts of theInternet (usually the whole Internet).

Service provider’s usually exchange Internet traffic, but this is not the only IP-based internet-work available today. IPX (IP eXchange) [20] provides a global backbone for the exchange ofIP traffic with service differentiation and quality of service guarantees (in contrast with Internetexchanges). IPX providers offer transit services across the IPX backbone to network operators.These can benefit from the guaranteed Service Level Agreements offered by IPX providers to sup-port a set of services such as mobile network roaming signaling, exchange of real-time traffic suchas HD voice or video, etc.

2.4.1 Service provider interconnection edge

The segment of the service provider’s network dedicated to the interconnection with other net-works is usually attached to the core network. Figure 26 shows a PE router directly connected toan upstream service provider, and another PE router located at an Internet eXchange Point (IXP)where it can peer with other service providers. These edge routers run eBGP sessions with both

32




To customers

To regional data centre

To customers

PE Upstream

Core Network PE PE

Interx

PE InterX

PE

PE

P

P

P

IXP Network

PE Peer

PE Peer

eBGP

eBGP

eBGP

iBGP

iBGP

iBGP

iBGP

Figure 26: Service provider edge, dedicated to interconnection with other networks

upstream providers and peers, and redistribute the routes learned towards the provider’s internalservice routers via iBGP.

Internet eXchange Points (IXPs) are a solution to minimize the costs of peering. Instead ofhaving point to point connections to each peer, a group of providers connects to a common net-work that provides an underlying infrastructure for the exchange of traffic. IXPs usually providea provider-neutral facility in which service providers can deploy their own routers and peer withother service provider through the IXP’s interconnection network (usually at layer 2). For ex-ample the Amsterdam Internet eXchange (AMS-IX), offers a distributed Ethernet interconnectionnetwork based on VPLS (refer to section 2.6.2). IXPs also provide additional services for the goodof service providers, not to compete with them - for example it may host a root DNS server.

Routers of peer service providers establish eBGP sessions amongst them. In order to enhancethe scalability of peering sessions, very large IXPs may deploy route servers. Route servers act asproxies of eBGP connections, thus avoiding the need to establish N*N eBGP sessions between Nrouters that want to peer.

2.5 Data centre

Network operators use data-centers as a cost-effective means to operate network services for theircustomers (such as DNS servers or tunnel terminators); but also to provide computing and storageresources for third-party services (cloud computing) or internal usage (hosting virtual networkfunctions such as virtual CPEs, firewalls or mobile network gateways).

33




A popular design in large-scale data-centre network (DCN) design, first adopted by web-scalecompanies like Google [21] or Facebook [22], is based on multi-stage Clos fabrics. This designuses a high number of commodity switches (Layer 2 or Layer 3) connected according to a Clostopology that provides homogeneous cross-sectional bandwidth between any pair of servers in theDC, as well as a very high redundancy due to the large number of equal cost paths between serverendpoints.

Figure 27: Schematic of the DCN of a large-scale data-centre

Figure 27 shows an example of a large-scale DCN that uses a 5-stage modular Clos fabric tointerconnect all the Top-of-Rack (ToR) switches in the DC. Depending on the requirements of theapplications deployed in the DC compute nodes and the operational policies of the DC operator,the DCN fabric can use a full layer 2 (L2) design, a full layer 3 (L3) design or a hybrid design (inwhich the first stages of the Clos topology may be L2 and the last ones L3).

Figure 28 shows the data-plane view of a DCN with a full L3 fabric based on IPv6. The DCNdepicted in the example also supports multi-tenancy; that is: isolated connectivity domains thatbring together a set of dedicated computing and storage resources; effectively creating the illusionthat they are owned by a customer. Scalable multi-tenancy is usually achieved via the so-callednetwork virtualization overlays over layer 3 [23], which essentially are network virtualization tech-nologies that allow virtual tenant layer 2 networks to be overlaid in top of the data-centre fabric.This way each tenant network can use its own addressing and routing policies, independently of

34




the other tenants. In the case of Figure 28 multi-tenancy is achieved through the use of VXLAN,the Virtual eXtensible Local Area Network protocol.

ToR ToR Fabric Spine Fabric

Server Server IPv4 or IPv6 (Fabric layer)

UDP VM VM

Ethernet Ethernet Ethernet Ethernet

VXLAN 802.1Q 802.3 802.1Q

IPv4 or IPv6 (tenant overlay)

TCP or UDP or SCTP, … (transport layer)

802.3

Protocol conversion,

Local bridging

Figure 28: Data plane of a DCN with an IPv6-based fabric and multi-tenant support

The control plane of the multi-tenant DCN is shown in figure 29. BGP is used in the DCNfabric as the only routing protocol. The routers belong to the different stages of the Clos fabric areconfigured as Autonomous Systems (ASs), exchanging routing information with their peers viaBGP. Multi-tenancy is also achieved via BGP with multi-protocol extensions, since this protocolis the one that disseminates VPN routes associated to different VXLAN ids between ToRs. Thefigure shows a configuration in which spine switches have been configured as route reflectors toavoid a full mesh of BGP sessions between ToRs.

2.6 Virtual Private Networks

This section analyzes the most popular models used by service providers to deliver scalable Layer2 and Layer 3 VPN services to their customers.

2.6.1 MPLS/BGP Layer 3 Virtual Private Networks (RFC 4364)

This section provides a reference model for an RFC 4364 [24] Layer 3 VPN network service andhighlights its use of the IP protocol suite.

Figure 30 illustrates an example of the L3VPN model from RFC 4364, showing a single ser-vice provider offering L3 VPN services to three different customers, each one with two sites. Cus-tomers can use overlapping address spaces, which are isolated in the service provider IP/MPLScore using a combination of Multiprotocol BGP (MBGP) in the control plane and MPLS in thedata plane. The model defines the following types of devices:

35




ToR ToR Fabric Spine Fabric Server Server

IPv4 or IPv6 (Fabric layer)

TCP

Ethernet Ethernet Ethernet Ethernet

LACP

Ethernet

LACP

Ethernet

TCP

eBGP eBGP

TCP TCP

eBGP eBGP

TCP

eBGP

TCP

eBGP

Figure 29: Control plane of a DCN with an IPv6-based fabric and multi-tenant support

10.1/16

PE

Customer 1 Site 1

10.1/16

CE Customer 2

Site 1

CE

PE

PE

P P

P VRF VRF

VRF VRF

VRF VRF

10.2/16

Customer 1 Site 2

CE

10.1/16 Customer 3

Site 1

CE

10.2/16

Customer 3 Site 2

CE

10.2/16

Customer 2 Site 2 CE

Provider IP/MPLS Core

eBGP/RIP/

OSPF

eBGP/RIP/

OSPF

eBGP/RIP/

OSPF

eBGP/RIP/

OSPF

eBGP/RIP/

OSPF

eBGP/RIP/

OSPF

Control plane Data plane

iBGP iBGP

iBGP

Figure 30: Layer 3 VPN model from RFC 4364

36




• CEs are Customer Edge Routers, which must support L3 (IP) routing. CEs can exchangeroutes with PEs in a number of ways, including by static configurations, using an InteriorGateway Protocol (IGP) such as RIP or OSPF or using eBGP.

• PEs are Provider Edge Routers. PEs do most of the work in providing the L3 VPN service.Each PE router maintains separate forwarding tables: one is the default forwarding table,the others are VPN Routing and Forwarding tables or VRFs. VRFs provide address androute isolation to the VPNs. PEs run iBGP sessions between them (full mesh or via routereflectors) to exchange VPN routes, and are connected to each other via the providers back-bone using MPLS Label Switched Paths or other tunnelling mechanisms (such as MPLS inGRE encapsulation).

• Ps are the Provider Routers that dont attach to CE devices. They dont have knowledgeabout VPN routes and its role is just to provide connectivity between PEs, usually usingbest-effort or traffic-engineered MPLS LSPs.

PE 1

VRF VRF

VRF VRF

PE 2 P2 P1 CE 2 CE 1 H1 H2

Customer 1 Site 1 Network Service Provider Network Customer 1 Site 2 Network

Eth/Net Eth/Net

TCP App App

IP (VPN)

Eth/Net Eth/Net

Eth/Net Eth/Net Eth/Net

MPLS

MPLS

Figure 31: RFC 4364 Layer 3 VPN data plane

Figure 31 shows the data plane of a BGP/MPLS VPN service, with a service provider networkconnecting two sites of a customer. The Layer 3 VPN is the IP layer that is floating on top of theproviders MPLS core. Each PE knows how to map customer traffic to a VRF (associating a datalink layer circuit to a VRF). The VRF in the ingress PE is capable of forwarding the IP packets ofthe VPN to the PE that is the next hop to the final destination (egress PE).

Since different VPNs can use overlapping IP address space, the ingress PE pushes a MPLSlabel that will allow the egress PE to associate the incoming packet to a specific VRF (these labelsare disseminated by the MBGP control plane). Next the ingress PR forwards the packet to theMPLS LSP indicated by the VRF (which leads to the egress router). Provider routers in betweenjust forward the packets in LSPs following normal MPLS operation, without being aware of any

37




VPN constructs. When the packet arrives at the other end of the LSP, the egress PE checks theMPLS label to learn which VRF to query, and then it queries the VRF and delivers the packet toCE2.

CE 1 PE 1

VRF VRF

P1

TCP

P2

VRF VRF

PE 2 CE 2

Service Provider Network

IS-IS and LDP sessions between

peers


peers


peers eBGP session

customer-provider eBGP session

customer-provider

iBGP session between PEs

Eth/Net

IP (VPN)

TCP

eBGP

Eth/Net

IP (VPN)

TCP

eBGP


IS-IS IS-IS IS-IS

IP (Provider)

TCP TCP TCP

LDP LDP LDP

TCP

iBGP

Figure 32: RFC 4364 Layer 3 VPN control plane

The protocols that support the L3 VPN model of Figure 30 are illustrated for the ControlPlane (CP) in Figure 32. The figure illustrates the main protocols used in the control plane of thecustomer and provider networks. Starting at the customer network, the CE runs an eBGP sessionwith the PE in order to exchange routes (from the customer site and to the rest of the VPN). Inaddition to eBGP other options are possible such as static configuration or the use of an IGP likeRIP, OSPF or IS-IS.

Focusing on the provider network, two main tasks for the control plane can be distinguished:the exchange of VPN routes and the exchange of label information related to the state of the MPLSLSPs. The latter task is accomplished following the regular MPLS operation procedures. Fromthe multiple protocols available to exchange MPLS label information, RFC 4364 mandates that atleast LDP the Label Distribution Protocol - is supported.

PEs use MBGP to exchange VPN route information (BGP route reflectors can be used to scaleup the control plane of large provider networks). Since different VPNs can have overlappingaddress space, RFC 4364 introduces a new address family called VPN IPv4. A VPN IPv4 addressis formed by appending a 8-byte Route Distinguisher (RD) to the IPv4 address prefix of the VPNroute. When a PE router distributes a VPN-IPv4 route via BGP, it uses its own address as the BGPnext hop, and it also assigns and distributes an MPLS label associated to the route. This MPLSlabel is the one that will appear in data plane packets received from the backbone and will allow

38




the PE to select the right VRF and forward the packet to a customers CE.Last but not least, since both LDP and BGP-MP run on top of TCP, the service provider

network needs an IP layer for control plane connectivity. In order to maintain the connectivity ofthe IP control plane and react against failures, PEs and Ps need to run an IGP such as OSPF orIS-IS (as depicted in Figure 32).

RFC 4364 Layer 3 VPNs also support more complex use cases in which CEs belonging tothe same VPN may be attached to different Autonomous Systems (ASs) belonging to the same ordifferent providers, in which case running iBGP sessions between PEs is not possible.

2.6.2 VPLS, Virtual Private Line Services (RFC 4761, RFC 4762)

This section provides a reference model for an RFC 4761/62 Ethernet VPN network services(multi-point to multi-point) over an IP/MPLS network, and highlights its use of the IP protocolsuite. Two options are possible for the VPLS control plane: BGP (RFC 4761 [25]) and LDP (RFC4762[26]).

LAN

PE

Customer 1 Site 1

LAN

Customer 2 Site 1

CE (router or bridge)

PE

PE

P P

P VPLS

VPLS

VPLS VPLS

VPLS VPLS

LAN

Customer 1 Site 2 LAN

Customer 3 Site 1

LAN

Customer 3 Site 2

LAN

Customer 2 Site 2

Provider IP/MPLS Core

Control plane Data plane

T-LDP or iBGP

T-LDP or iBGP

T-LDP or iBGP






Figure 33: RFC 4761/2 VPLS architecture (CE directly attached to PE)

Figure 33 illustrates an example of the VPLS model from RFC 4761/2, showing a singleservice provider offering VPLS services to three different customers, each one with two sites. Themodel is similar to the L3VPN service, with a number of differences:

39




• VPLS offers a Virtual L2 bridge service, therefore CEs can be Ethernet bridges (could alsobe routers).

• (MAC) address learning is performed in the data plane instead of the control plane.

• VPLS instances in each PE play the equivalent role of VRFs. VPLS instances perform thetraditional MAC-learning behaviour from layer 2 bridges. All VPLS instances belonging tothe same VPN are directly connected through a mesh of MPLS Pseudo Wires (PW) over theproviders MPLS core.

• Targeted LDP sessions (with or without BGP for auto-discovery of PEs) or BGP can be usedas the VPLS control plane between PEs in order to setup and maintain the mesh of PWs.

Figure 34 shows the data plane of a VPLS service, with a service provider network connect-ing two sites of a customer. Each PE knows how to map customer traffic to a VPLS instance(associating an Ethernet port or VLAN to a VPLS instance). When the VPLS instance receivesan incoming Ethernet frame from a customer port/VLAN, it can perform two actions: i) in caseof known destination MAC addresses and unicast traffic it looks up the output Pseudo Wire in itslocal table and forwards the frame; ii) in case of unknown unicast destination MAC addresses andbroadcast/multicast traffic it floods the frame through all the VPLS instance output ports (PseudoWires and/or VLANs). The VPLS instance at the egress PE performs an equivalent action.

PE 1

VPLS VPLS

VPLS VPLS

PE 2 P2 P1 CE 2 CE 1 H1 H2


PHY PHY

TCP App App

IP

PHY PHY


MPLS

MPLS

IEEE 802.3 (VPN)

Figure 34: RFC 4761/2 VPLS data plane (CE directly attached to PE)

Figure 35 illustrates the main protocols used in the control plane of the provider network. LSPsbetween PEs are established using the same procedures as in the L3VPN use case (the exampleillustrates the use of LDP). PE discovery can be achieved by BGP or by manual configuration.

40




PE 1

VPLS VPLS

P1

TCP

P2

VPLS VPLS

PE 2

Service Provider Network


peers


peers


peers

iBGP and/or T-LDP session between PEs


IS-IS IS-IS IS-IS

IP (Provider)

TCP TCP TCP

LDP LDP LDP

TCP

iBGP or T-LDP

Figure 35: RFC 4761/2 VPLS control plane (CE directly attached to PE)

The Pseudo Wire mesh can be created through the use of MBGP (in this case route reflectors canbe used to scale the control plane) or a mesh of T-LDP sessions between PEs.

With the flat architecture depicted in Figure 34 it is hard for service providers to scale networkswith large numbers of PEs (due to the requirement for a full mesh of Pseudo Wires). HierarchicalVPLS (H-VPLS) mitigates this issue by creating a hierarchy with different types of PE followinga hub/spoke model. A number of hub PE devices are connected to the providers core and inter-connected via the full mesh of Pseudo Wires. One or more spoke PE devices are connected toeach hub via 802.1ad [10] trunks or MPLS Pseudo Wires. Spoke PEs are the ones connected tothe CEs of one or more customers, and are connected to a hub PE via a L2 tunnel. An example ofthis configuration is provided in Figure 36.

H-VPLS still has scalability issues since hub PEs require a VPLS forwarder instance per VPLSservice per customer, and the same number of Pseudo Wires. Hub PEs also see all individualcustomer MAC addresses. In order to mitigate the MAC address and the VPLS service/PseudoWire scalability issues, PBB-VPLS has been proposed as an informational RFC (RFC 7041 [27]).In PBB-VPLS traffic of customer VPLS instances is multiplexed into one or more Backbone VPLSinstances using the capabilities provided by PBB (IEEE 802.1ah [11]), as shown in 37. Hub PEsare completely unaware of customer VPLS instances and MAC addresses.

41




PE-rs 1

VPLS

PE-rs 2 P2 P1 CE 2 CE 1 H2


MTU-s 1

VPLS VPLS

MTU-s 2

VPLS VPLS

P (metro) P (metro)

VPLS

App TCP

IP

802.1q

Eth/Net Eth/Net

MPLS

MPLS


MPLS

MPLS

Eth/Net Eth/Net

MPLS

MPLS 802.1q

Ethernet (802.3)

VPLS VPLS

Figure 36: Example of Hierarchical VPLS (H-VPLS) data plane

PE-rs 1

VPLS

PE-rs 2 P2 P1 CE 2 CE 1 H2

Customer 1 Site 1 Network Customer 1 Site 2 Network

MTU-s 1

VPLS VPLS

MTU-s 2

VPLS VPLS

P (metro) P (metro)

VPLS

App TCP

IP

802.1q

Eth/Net Eth/Net

MPLS

MPLS


MPLS

MPLS

Eth/Net Eth/Net

MPLS

MPLS

802.1q

Ethernet (802.3)

PBB (802.1ah)

Figure 37: Example of PBB VPLS data plane

42




2.6.3 Ethernet VPN (RFC 7432, RFC 7623)

Ethernet VPN (EVPN) is the IETF response to limitations in the operation of VPLS (such as therelative complexity in provisioning VPLS services and the problems introduced by MAC-learningin the data plane) together with the advent of new requirements for L2 VPNs such as the supportof new topologies (like E-Tree), support for all-active multihoming, new service interfaces or newuse cases (Data Center Interconnect).

EVPN defines a single control plane (MBGP) with options for three different data planes:EVPN over MPLS [28], EVPN over PBB over MPLS [29] and EVPN over NVO3 Network Virtu-alization over Layer 3 (VXLAN, NVGRE and MPLSoGRE) [30]. EVPN follows the operationalmodel of Layer 3 VPNs:

• Per EVPN MAC-VRFs (equivalent to layer 3 VPN VRFs) in PEs provide forwarding isola-tion between EVPNs.

• MBGP is used in the control plane to advertise VPN routes between PEs (using the sameapproach as defined in L3 VPNs). This is a key difference with VPLS, where MAC addresslearning happens in the data plane.

• MAC address learning between CE and PE can be performed by different means (data planelearning, LLDP, ARP, etc.).

EVPN can use MPLS as its data plane - as in the L3VPN case but two other data plane optionsare also available:

• PBB over MPLS. In this scenario PEs are Backbone Edge Bridges (BEB) and aggregatecustomer MAC addresses into one or more backbone MAC addresses. The BGP controlplane only carries the backbone route advertisements, and therefore is not exposed to cus-tomer MACs. The PBB-EVPN data-plane improves the scalability of the standalone MPLSdata plane.

• NVO3. In this scenario PEs are interconnected via virtual network overlays over Layer 3.This enables the transparent provisioning of EVPN services over one or more IP networks,or the extension of the EVPN to the hypervisor in the case of datacenter deployments.

2.7 Security

The number of technologies present in a service provider network is too large to provide a com-prehensive review in this report. However, they can be classified in different categories, whichaddress different requirements of network security. This section defines these categories and listsa number of representative protocols that are part of each category, while section 3 explains howthey are applied in different areas of the converged service provider network.

43




2.7.1 Establishment of security associations

Although different protocols use different terminologies, here we use the term security associationto define the procedure by which two protocol machines authenticate each other and negotiate aset of algorithms and cryptographic material (such as keys, initialization vectors, etc.) to setup asecure communication between them that provides data confidentiality and integrity. A number ofdifferent protocols to establish security association exist, differing in i) the strength of authentica-tion; ii) the options for configuring the confidentiality and integrity verification mechanisms andiii) the network protocols (data plane or control plane) that they have been designed to protect.Some representative examples are:

• Internet Key Agreement (IKEv2) [31]. This protocol is used within IPsec [32] to negotiatesecurity associations between IPsec peers. IKEv2 uses the Diffie-Hellman exchange algo-rithm to achieve Perfect Forward Secrecy (PFS). Authentication is carried out through X.509certificates. IKEv2 negotiates encryption algorithms (AES, DES, 3DES, etc), pseudo-randomfunctions (such as HMAC) and integrity algorithms (HMAC, DES or AES).

• Authentication and Key Agreement (AKA) [1]. The EPS AKA procedure is used in LTEnetworks to provide mutual authentication between networks and users. It consists in threelogical steps: first an HSS generates EPS authentication vectors and delivers them to anMME. These authentication vectors are used for mutual authentication between the MMEand UE. Once mutually authenticated, the UE an MME have the same master key, which isused to derive the encryption and integrity keys used by the NAS and AS protocols.

• TLS Handshake Protocol [33]. Designed to provide end-to-end security to application pro-tocols over the transport layer. The TLS Handshake protocol is a framework that allows forseveral authentication options and the negotiation of cipher suites (encryption, compression,message integrity) for its companion TLS Record protocol. TLS defines a number of au-thentication mechanisms (public key with and without certification), use of Diffie-Hellmanfor Perfect Forward Secrecy and a rich selection of cipher suites.

• Extensible Authentication Protocol (EAP) [34]. Authentication framework frequentlyused in wireless networks and point-to-point connections (such as PPoE in XDSL). In addi-tion to optional mutual authentication, EAP provides procedures for the transport and usageof keying material and parameters generated by EAP methods. EAP defines the messageformats, and each EAP variant defines the way to encapsulate EAP messages within thespecific protocols messages.

2.7.2 Confidentiality and integrity

Confidentiality allows two peers to exchange information with the guarantee that no third partywill be able to access that information, even if it intercepts the communication. Integrity allows to

44




peers to communicate with the guarantee that the messages they exchange will not be modified bya third party while in transit, or if they are modified the receiving party will detect it. Confiden-tiality is achieved via cryptographic algorithms that provide encryption services; while integrity isachieved via pseudo-random functions that make use of several hashing algorithms. Confidential-ity and integrity are usually implemented within the same protocol. Again, the differentiation indifferent protocols of this class is due to i) the strength of the encryption/message integrity algo-rithms and cryptographic procedures; ii) the length of the cryptographic material they use; and iii)the different protocols they are protecting. Some representative examples are:

• Authentication Header (AH) and Encapsulating Security Payload (ESP). They are partof the IPsec suite. AH is used to guarantee the integrity of the data sent in the IP packets, itdoes not provided confidentiality. It uses a keyed hash function (at least HMAC-MD5 andHMAC-SHA-1 have to be supported). EPS ensures confidentiality of the data with optionalintegrity. At least it must support HMAC-SHA1 for message authentication and AES inCBC mode for message encryption.

• Non Access Stratum (NAS) and PDCP (Packed Data Convergence Protocol). They areused in LTE networks. The NAS protocol, among other functions, provides confidentialityand message integrity to the signaling between the MME and the UE. PDCP supports theRRC control plane protocol between the UE and the eNodeB, as well as the user data-planeIP protocol. PDCP provides both encryption and message protection services to RRC, whileonly encryption services to user-plane IP packets.

• TLS Record protocol [33]. It is the companion of the TLS Handshake protocol. It performsencryption, compression and message integrity functions using the algorithms negotiated bythe TLS Handshake protocol.

2.7.3 Access control

Access control is the procedure by which access to a resource by a subject is evaluated. Havingauthenticated the subject, access control allows the owner of the resource to take an authorizationdecision either allowing or denying access to the requested resource.

The simplest access control mechanisms are access control lists (ACLs), which allow binarydecisions based on the subjects identity. For example service providers usually deploy a number ofACLs in their routers to make sure customers dont try to send traffic destined towards the providersinfrastructure IP range. Another use is in WiFi networks, in which only certain MAC addressesmay be granted access to different services (i.e. the Internet vs. a captive portal). Statelessfirewalls are another examples of ACLs, in which access to a certain resource (e.g. IP address andtransport port) may be only granted to a certain range of source IP addresses.

Role-based access control technologies improve the scalability of ACLs by granting accessto groups of subjects instead of individual subjects. The authentication mechanism must much

45




the subject to one of the existing groups.Attribute-based access control solutions provide finer-grained control by performing the access control decision taking into account attributes that mustbe evaluated in real time (such as time of day, number of access attempts, etc.). Finally, capability-based access control solutions provide more scalability in a system where there are a larger groupof different subjects compared to the types of resources these subjects want to access. Whena subject is authenticated, it receives a capability that grants her access to different resources.Access control is performed by checking the capability that the subject presents when it tries toaccess a resource.

2.7.4 Intrusion Detection (IDS) and Prevention (IPS) systems

Despite the security-related network technologies presented in previous subsections, it is still pos-sible for attackers to bypass all the defenses and carry out successful attacks. Intrusion DetectionSystems (IDS) are designed to identify potentially malicious traffic attacking the provider and/orthe customer network resources. Service providers usually deploy network-based IDS systems,which monitor the network traffic and network resources looking for patterns that may signal on-going attacks. There are two major strategies to detect these patterns: i) a statistical approach, inwhich monitored traffic is compared to a normal baseline - what is the normal bandwidth usage,what share of protocols are seen in the network links, etc; and ii) a rule-based approach, in whichthe IDS observes events in the network and applies a set of programmed rules to decide whetherthe situation is normal or the network is under attack.

IDS systems are just designed to detect attacks; while Intrusion Prevention Systems (IPS) alsotry to block or stop the attacks by performing actions such as sending alarms, dropping detectedmalicious packets, resetting a connection and/or blocking traffic from the offending IP address.

2.8 Network Management

As seen in previous sections of this chapter, service provider networks are designed as multipleco-operating layers that perform different functions implemented by a diverse set of protocols.Allowing distributed applications to achieve an optimal performance through the network requiresthe different layers to collaborate, so that application quality requirements can be enforced downto the physical wires. Each layer and protocol needs to be properly configured, and this configura-tion must be continuously updated due to the dynamicity of the network operational environment(node and link failures, degradation of physical layer conditions) or changes in the volume andcharacteristics of the traffic offered to the network.

Network Management Systems (NMSs) are in charge of keeping the network operating inoptimal conditions, monitoring the behavior of the different layers that make up the network,reasoning about their current and desired states, and taking any corrective actions to update thenetwork configuration if needed (due to misalignments in performance or reliability and securityissues).

46




Figure 38: Classical Manager - Management Agent paradigm

The classic management paradigm, illustrated by Figure 38 and often referred to as Manager-Agent Paradigm, builds a management system out of Managers and Agents supported by ManagedObjects (MO) and Management Information Bases (MIB). A manager realises management func-tionality, in classic terms grouped functionally as fault, configuration, performance, accountingand security management (also called the FCAPS). An agent controls real resources, which caneither be physical (network nodes, e.g. switches, routers) or logical (e.g. elements of a protocolstack or other non-physical artifacts). To simplify management instrumentation, an agent does notoperate directly on the resource but uses MOs, which represent an abstraction of a resource formanagement purposes including communication, functional and information modelling aspects.

The communication between Manager and Agent is realised by a Management Service defin-ing the management protocol and the information exchanged using it. The communication be-tween Manager and Agent is often standardised in terms of notifications and (management) op-erations. An Agent sends notifications issued by MOs to the manager and the manager send(management) operations to the Agent, which in turn issues them to the respective MOs.

2.8.1 Managing a converged network today

The Next Generation Converged Operation Requirements (NGCOR) [35] published by the NextGeneration Mobile Networks (NGMN) group describes the current state of the art regarding con-verged operator network management and provides requirements towards a truly converged net-work management and operations environment. NGMN follows the TMN model of describing thearchitecture of the management system, in which two tiers exist: i) the Element ManagementSystem (EMS), which manages individual network elements and provides a higher layer (north-bound) interface to ii) the Operations and Support Systems (OSS) layer, which provides config-uration, performance, administration, security and fault management applications for a number ofnetwork elements.

As illustrated in Figure 39, today we live in a no convergence NMS architecture scenario.Different EMSs - using different management protocols and object models - are dedicated to spe-

47




Figure 39: Current situation: lack of convergence in the Network Management System (source:NGMN)

cific network technologies, domains or regions (LTE access, EPC core, IP/MPLS network, fixedaccess, etc). What is more, EMS northbound interfaces are also specific to network technologiesand domains, and standardized by different SDOs (e.g. 3GPP, IETF or TMF). Last but not least,the network operator usually has different OSS applications per domain. All in all this scenariocauses the management of the full network to be extremely complex.

NGMN has identified a number of different approaches with similar goals that need to beharmonized in order to achieve a converged network scenario, briefly explained in the bullet pointsbelow. To do so NGMN proposes to work with SDOs in order to create federated managementmodels that are consistent across all the regions of the network, as shown in Figure 40.

• The IETF is working in the NETCONF protocol and the YANG [36] data modeling lan-guage in response to the limitations of SNMP/SMI for configuration management. YANGallows operators to define service models that are then mapped to configurations of specificdevice data models (created by the device manufacturers).

• TMF has defined the Multi-technology Operations Systems (MTOSI) framework [37]. OSSto EMS communications is a special case and defined by the Multi-Technology NetworkManagement (MTNM) standards. MTNM provides CORBA-based interfaces for managingmulti-technology networks (SDH, ATM, DSL, Ethernet, etc.). MTOSI also leverages theeTOM model for service classifications and SID for information modeling.

48




Figure 40: Harmonization of models for fixed and wireless network segments (source: NGMN)

• SDN northbound APIs. Refer to next section.

• 3GPP self-configuration of network elements. 3GPP defines procedures to bring a networkelement into service requiring minimal man operator intervention or not at al. It coverssoftware and radio configuration aspects.

2.8.2 Network programmability: Software Defined Networking

Work on adaptive, programmable networks capable of accommodating to different operational en-vironments and to sup-port ever-changing application requirements has been carried out for morethan 20 years. Since the beginning, programmable networks have been seen as key to the rapidcreation and deployment of new network services. Such networks require a set of open, pro-grammable network interfaces that enable external programs to access to the internal state andcontrol of network device. Past efforts crystalized in proposals such as he IETF General SwitchManagement Protocol (GSMP) [38], which enabled the partitioning of a label switch (ATM, Eth-ernet) into multiple virtual switches, allowing external controllers to manage the virtual switchesvia the GSMP protocol; ii) the IETF FORCES initiative [39], which defines a framework and as-sociated protocols to standardize the information exchange between the control and forwardingplanes of an IP network element; and iii) the IEEE P1520 [40] standard project, which aimed atestablishing a reference model for networks APIs. However, none of these past proposals gained

49




the popularity and traction amongst the network industry as todays Software Defined Networking(SDN) revolution.

Figure 41: SDN Architecure Overview (source: ONF)

Figure 41 describes the architecture of Software Defined Networks as defined by the OpenNetworking Foundation (ONF) [41]. SDN architecture is composed by four main entities:

• Interconnected network elements in the data plane, which communicate between a numberof endpoints.

• One or more SDN controllers in the controller plane, each one hosting the functions tocontrol one or more network elements and exposing network services to applications via anAPI.

• SDN applications that interact with the network services offered by the controller layer.

• OSS systems that provide supporting management functions and integrate the SDN with theremaining provider infrastructure.

SDN sees the network as a set of forwarding devices that can be managed by logically central-ized software controllers via well-defined APIs. SDN has decoupled control software from spe-cialized forwarding hardware by virtualising underlying physical resources and provided (semi-)standardized interfaces to the virtualized hardware resources; allowing for an increased servicedeployment agility and an increased reusability of bare-metal hardware. By placing the control

50




plane protocols on separated x86 hardware the service provider can change the functionality of theresulting system by just issuing software updates. Scaling the control plane of a network devicealso becomes easier, since it just requires the deployment of more x86 hardware.

From the perspective of this deliverable, which analyzes the protocol architecture of convergedservice provider networks, SDN does not influence the result of the analysis too much, though thereduction of control protocols that SDN proposes and the possibility of moving towards unifiedcontrol and management mechanisms could be considered a first step in the direction of a con-verged architecture.

For example, an operator may decide implementing MPLS traffic engineering via a centralizedSDN controller instead of using RSVP-TE. Such a controller would rewrite the forwarding table ofthe controlled devices according to some traffic engineering policy dictated by the operator. Thisis, in essence, equivalent to having the Network Management System centrally provisioning LSPswithin an MPLS cloud (where the controller plays the role of the NMS and the SDN protocol - e.g.OpenFlow - plays the role of the management protocol), and potentially taking care of additionalconfiguration in other segments of the network. Hence SDN can be viewed as a re-branded andbetter integrated form of Network Management, with more decision power being outsourced fromthe network devices to this integrated Management System. This view is also consistent with theone stated by NGMN in its NGCOR document, in which it expresses the need of harmonizing SDN(northbound) APIs with other initiatives with similar goals such as MTOSI, NETCONF/YANG oreTOM.

51




3 Architecture of a converged network operator today

Having reviewed the main technologies that can be used to construct a converged service providernetwork today, this chapter of D2.1 puts everything together to design such a network. It is impor-tant to highlight that this is a logical design: it has the essential elements of a real design, but eachreal network will have very detailed constraints that will result in variations and refinements to thismore general model. Nevertheless, the model is detailed enough to allow for a meaningful analy-sis and comparison with RINA-based converged service provider networks. Figure 42 provides ahigh level view of the main parts of a converged service provider network.

xDSL FTTH WiFi 4G

National DC Regional DC(s)

Metropolitan aggregation


… …

Metro DC

Metro DC

Access

Internet Border

Private peering with other operators , or Internet transit

To Internet eXchange Point (IXP)

IP eXchange border To IPX network (IMS traffic)

micro DC

Metropolitan aggregation Metropolitan

aggregation




Core/backbone

Figure 42: High level view of the main parts of a converged service providers network

Several types of access networks (xDSL, FTTH, WiFi and 4G) allow the provider to reachits customers (residential, business, mobile) via wired and wireless physical media. As explainedin section 2.1 this type of access technologies have been chosen to be highly representative, butother access networks could be added (e.g. DOCSIS for Hybrid Fiber/Coax networks) withoutmodifying the design. The traffic from these access networks is aggregated by metropolitan areanetworks (which may cover a neighborhood, a whole city or a semi-urban/rural area depending onthe density of customers), which aggregate the traffic towards the network core.

Different types of customers and/or services are identified and authenticated before enteringthe core. After that the traffic is forwarded towards another core PoP - if it is addressed to anothercustomer of the service provider or to a service hosted in the service provider’s DCs - or to anInterconnect edge router (e.g. Internet edge) otherwise. The service provider may have differentdatacentres attached to different parts of the network:

52




• Micro data-centers attached to the access networks, supporting the Mobile Edge Comput-ing paradigm by running very latency-critical services very close to its customers. Micro-data-centers may also be used to support C-RAN (Cloud RAN) deployments.

• Metro data-centers attached to the metropolitan networks. These DCs could host serviceproviders network services such as DHCP, DNS or authentication servers; but also ContentDelivery Networks (CDNs) or even provide cloud computing services to customers.

• Regional or national data-centers attached to the core networks. Could run the sameservices as metro data-centers at a national scale, as well as mobile network gateways and/orthe Network Operations Center (NOC).

DSLAM

XDSL

AAL5/ATM

CPE BRAS/Edge router Carrier Eth.

PE Carrier Eth.

PE

802.3

802.1ah

802.1q/p or 802.1ad

Eth PHY Eth PHY

Eth PHY Eth PHY

Carrier Eth. P

802.3

Eth PHY

PPP and PPPoE

Host L2/L1

IP (Internet)

Core router Core router

L2/L1 L2/L1

MPLS (LSP)

Internet Border Router


802.3

Eth PHY

Customer network Service Prov. 2 Service Prov. 1 network

Access

Aggregation Service Edge Core (BGP-free) Internet Edge

Internet eXchange Point Core PoP, city B Core PoP, city A City A Ethernet-based MAN City A Cabinets

MPLS (VPN/Pseudo Wire)

TCP/UDP

Figure 43: Converged operator network data plane layers: residential fixed Internet access

Figure 43 shows the data plane of the service provider network when a customer accesses anapplication available through the Internet via xDSL access. The design shows a Carrier-Ethernetbased MAN (could also have been an MPLS-based MAN) that aggregates traffics from DSLAMsin the metropolitan area and forwards it to one or more BRAS routers located at a core PoP. BRAS

53




routers authenticate the customer and further route customer traffic towards the Internet. Theprovider’s core network is BGP-free and based on MPLS.

DSLAM

XDSL

AAL5/ATM

CPE BRAS/Edge router Carrier Eth.

PE Carrier Eth.

PE

802.3

IEEE 802.1aq (SPB)

802.1q/p or 802.1ad

Eth PHY Eth PHY

Eth PHY Eth PHY

Carrier Eth. P

802.3

Eth PHY

PPP and PPPoE

Host

L2/L1


L2/L1 L2/L1

IP (operator)



802.3

Eth PHY

Customer network Service Prov. 2 Service Prov. 1 network

Access

Aggregation Service Edge Core (BGP-free) Internet Edge

Internet eXchange Point Core PoP, city B Core PoP, city A City A Ethernet-based MAN City A Cabinets

TCP

IS-IS IS-IS IS-IS

iBGP

RSVP (TE) IP

TCP

eBGP

Figure 44: Converged operator network control plane layers: residential fixed Internet access

The control plane layers for the same scenario are depicted in Figure 44. PPP allows the BRASto authenticate different customers. The MAN runs a Shortest Path Bridging (SPB)-based controlplane, allowing the metropolitan network to leverage multiple redundant paths and to performtraffic engineering. eBGP is used by the provider border router’s to exchange traffic with its peeror upstream routers. The routes learned are disseminated to the BRAS(es) via iBGP. The BGP-free core runs the MPLS control plane protocols required to set-up LSPs with traffic engineeringcapabilities: IS-IS for link-state distribution and RSVP-TE to setup LSPs.

Figure 45 shows the data plane of the service provider network when a customer accesses anapplication available through the Internet via LTE access. The eNodeB (base station) is attachedto the aggregation network (could be directly attached to a MAN router as in the Figure or througha PON), which aggregates the traffic from multiple base stations into a Core PoP. The core PoPcontains a Multi Service Edge - which could be dedicated to serve traffic from eNodeBs - andforwards the traffic to the mobile network gateways forming the EPC (Evolved Packet Core).The S-GW and the P-GW could be located at the core PoP as in the Figure, or in a datacenter

54




DSLAM eNodeB

Multi Service Edge Carrier Eth.

PE Carrier Eth.

PE

802.1ah

802.1q/p or 802.1ad

Eth PHY Eth PHY

Eth PHY Eth PHY

Carrier Eth. P

MAC

PHY

UE

802.3

Eth PHY

P-GW

Service Prov. 1 network

Access Core (BGP-free) Internet Edge

Core PoP, city B Core PoP, city A

City A Ethernet-based MAN City A Antenna sites

RLC

PDCP

S-GW

IP (provider)

UDP

GTP-U

Eth PHY

802.3

UDP

GTP-U

IP (Internet)

Aggregation

L2/L1


L2/L1 L2/L1

MPLS (LSP)



802.3

Eth PHY

Service Edge Mobile gateways

Figure 45: Converged operator network data plane layers: 4G Internet access

55




belonging to the service provider. Once the traffic reaches the P-GW, it if it is for the Internet itis forwarded to one of the provider’s Internet border routers through the MPLS core network. Inthe example depicted in Figure 45 the S-GW and the P-GW are two separate physical devices, buttheir functionality could be combined into a single one. Also, the P-GW is directly attached to thecore routers using MPLS; another option if the P-GW does not support MPLS is to connect it to aPE router at the core PoP.

DSLAM

eNodeB Multi Service Edge Carrier Eth.

PE Carrier Eth.

PE

802.1aq (SPB)

802.1q/p or 802.1ad

Eth PHY Eth PHY

Eth PHY Eth PHY

Carrier Eth. P

MAC

PHY

UE 802.3

Eth PHY

P-GW

Service Prov. 1 network

Access Core (BGP-free) Internet Edge

Core PoP, city B Core PoP, city A

City A Ethernet-based MAN City A Antenna sites

RLC

PDCP

S-GW

IP (provider)

Eth PHY

802.3

UDP

GTP-C

Aggregation Service Edge Mobile gateways

RRC

802.3

Eth PHY

MME

S1-AP

NAS

SCTP GTP-C

UDP

L2/L1


L2/L1 L2/L1

IP (operator)


802.3

Eth PHY

TCP

IS-IS IS-IS IS-IS

iBGP

RSVP (TE) IP

TCP

eBGP

Figure 46: Converged operator network control plane layers: 4G Internet access

A partial view on the control plane layers is shown in Figure 46. The UE runs the NAS protocolagainst the Mobility Management Element (MME), which allows the MME to authenticate theuser and negotiate handovers. The P-GW runs iBGP with Internet border routers, allowing it toroute UE traffic to the Internet.

Figure 47 illustrates the systems and data plane layers involved to provide a Layer 3 VPNservices between two sites of the same business customer, located at different cities. In this exam-ple the customer CPE router is directly attached the provider’s MAN via Ethernet. The L3 VPNservice is carried over a VLAN until the MS Edge router, which is running a Virtual Routing andForwarding (VRF) instance to forward the VPN traffic through the MPLS core. When VPN trafficexits the MPLS core, another VRF instance forwards it through another VLAN over the MAN at

56




CPE MS Edge router

Carrier Eth. PE

Carrier Eth. PE

802.1ah

802.1q/p or 802.1ad

Eth PHY

Eth PHY Eth PHY Eth PHY

Carrier Eth. P

802.3

Eth PHY

Host L2/L1

IP (VPN)


L2/L1 L2/L1

MPLS (LSP)

MS Edge Router

Customer network Service Prov. 1 network

Aggregation Service Edge Core (BGP-free)

Core PoP, city B Core PoP, city A City A Ethernet-based MAN


TCP/UDP

Carrier Eth. PE

Carrier Eth. PE

802.1ah

Eth PHY Eth PHY

Carrier Eth. P

802.1q/p or 802.1ad

Eth PHY

802.3

Eth PHY Eth PHY

Aggregation Service Edge

Customer network

City B Ethernet-based MAN

Host

CPE

Figure 47: Converged operator network data plane layers: Layer 3 VPN between customer sites

CPE

MS Edge router

Carrier Eth. PE

Carrier Eth. PE

802.1aq (SPB)

802.1q/p or 802.1ad

Eth PHY

Eth PHY Eth PHY Eth PHY

Carrier Eth. P

Core router Core router MS Edge Router

Customer network Service Prov. 1 network

Aggregation Service Edge Core (BGP-free)

Core PoP, city B Core PoP, city A City A Ethernet-based MAN

Carrier Eth. PE

Carrier Eth. PE

802.1aq (SPB)

Eth PHY Eth PHY

Carrier Eth. P

802.1q/p or 802.1ad

Eth PHY Eth PHY

Aggregation Service Edge

Customer network

City B Ethernet-based MAN

CPE L2/L1 L2/L1 L2/L1

IP (operator)

TCP

IS-IS IS-IS IS-IS

iBGP

RSVP (TE)

IP

TCP

eBGP

IP

TCP

eBGP

Figure 48: Converged operator network control plane layers: Layer 3 VPN between customer sites

57




city B, delivering it to the CPE belonging to the customer.Control plane layers are shown in Figure 48. Customers CPEs run eBGP sessions with the

provider’s MS Edge routers to exchange VPN route information. These VPN routes are dissemi-nated over the provider’s core via iBGP, allowing all VPN locations to learn the routes required toforward the VPN traffic across all sites.

Securing the network is a crucial requirement to meet. Service providers must protect theirown networks from malicious traffic coming from peer/transit providers and from their customernetworks; but they also need to protect their customers from malicious traffic coming from theInternet or other internetworks accessed by their customers.

Access networks are one of the first lines of defense. Different access technologies will posedifferent threat levels due to their own nature (wireless vs. wired), and need to be secured ac-cordingly. Various authentication, security association, confidentiality and integrity protectionmechanisms can be deployed depending on the access technology:

• LTE security suite for the LTE cellular access. LTE already incorporates a number of proto-cols for performing authentication and key agreement (AKA), and to provide confidentialityand integrity to user plane (PDCP) and control plane traffic (PDCP and NAS).

• IPsec to securely connect gateways going through an untrusted network - for example, be-tween eNodeBs and a security gateway in the case the backhaul is shared amongst multipleproviders; or to provide IPsec VPNs to customers.

• EAP with different flavours for WiFi access and fixed point-to-point access (e.g. xDSL orFTTH).

In addition to that, a usual good security practice is to filter customers layer 3 traffic throughthe use of ACLs to protect the data plane and the control plane traffic. ACLs look for spoofedIP addresses (source IP addresses belonging to the provider address space), IP packets destinedto the providers internal routers or IP addresses belonging to private IP address space. In casethe customer is running BGP sessions with the provider (such as in the case of layer 2 or layer3 VPNs), BGP ingress filtering should be enforced to make sure customers only advertise routesbelonging to networks that belong to them.

The service provider also interacts with other peer and transit service providers, an interactionthat must be protected. The main protocol used within providers is BGP, therefore it is advisablethat all BGP routing updates are authenticated - at least using MD5 authentication. BGP routefiltering on peer route announcement is also a good security practice, although it has to be tradedoff with the large number of prefixes involved. Securing IGPs (IS-IS or OSPF) and other controlplane protocols such as LDP will minimize the chances of rogue members disrupting the internalrouting. Rate control of control plane protocol messages (especially ICMP) is a useful featureto implement, since it can help the provider to avoid or mitigate Denial of Service (DoS) attacksexploiting control plane protocols.

58




When it comes to network management, convergence is still a complicated goal: differentnetwork technologies still required different network management protocols, object models andmanagement applications. However, for the scope of ARCFIRE and in the spirit of performing abest case (for IP-based technologies) comparison against RINA in D2.2, we assume in the nearfuture it will be possible to manage the whole network with NETCONF and YANG (or with anequivalent set of protocol/object models).

59




4 Limitations of current converged operator networks

This section reports the results of an analysis to the architecture of converged service provider net-works designed with current technologies, such as the one depicted in chapter 3. The analysis ofthe limitations has been divided into 7 areas: network architecture/structure; protocol design; nam-ing, addressing and routing; mobility and multi-homing; quality of service, resource allocation,congestion control; security and network management.

4.1 Structure

• Different layers, different functions. Network architectures in use today are mostly basedon the functional layering paradigm, in which different layers perform different functions.The typical theoretical model describes 4 layers (physical, data link, network and transport)with application protocols on top. Layers are seen as a unit of modularity. The functionsof each layer are performed by different protocols, which are independently designed fromeach other. This design pattern causes a lot of overhead and repetition (layer 2 protocolshave many functions in common with layer 4 protocols, for instance).

• Functions in different layers must be independent. The current partitioning of functionsin different layers has proved to be problematic: IP fragmentation does not work because inorder to operate correctly in needs information that TCP has, but IP has to operate indepen-dently from it (since it is in another layer).

• Fixed number of layers = limited number of scopes. Layers enable the isolation of stateof different scopes: this is their fundamental property. The theoretical architecture just hasroom for two scopes: data link and network; i.e. the whole Internet. In real internetworksthis is clearly not sufficient - network providers want to isolate their internal resource al-location, routing and forwarding policies from the rest of the Internet, for example. Thishas caused the proliferation of new protocols which belong to layers 2.5 - such as MPLS-, virtual layers above transport - such as VXLAN -, tunnels - such as GRE - or recursiveencapsulations - such as MAC-in-MAC. These protocols have evolved with no organizationto solve individual use-cases as they appeared, invalidating the original architectural modeland increasing the complexity of networks.

• Incomplete and/or missing layer APIs. Most layers do not have a standard API that ab-stracts the service that the layer provides, therefore all users of a layer must know the detailsabout the specific protocols implementing the layer functionality. The only layer that has a(de-facto) standard API is the transport layer with the Sockets API. However Sockets don’thide the transport layer implementation details and expose individual transport protocols toapplications. Therefore applications have to be aware of the choice of available transportprotocols, and make a savvy decision based on its requirements. This fact not only makes

60




networked applications more complex, but also makes the deployment of new transport pro-tocols very hard.

• Where are the data and control planes? Current network protocols are classified as be-longing to the data plane or to the control plane depending on their functionality. But aquick analysis of diagrams showing the protocol structure of a network - such as the onesprovided in chapter 2 and 3 of this deliverable - show no elements that can be identified asplanes; the diagrams just show systems (boxes, machines) and layers of protocols.

4.2 Protocol design

• Multiple protocols per layer. Even with the functional layering approach - in which eachlayer performs a different function - today there are multiple protocols that can be used ineach layer. This is due to the fact that current protocols are hand-crafted to solve a particularuse-case or to cover a small range of requirements. When these requirements cannot bemet a new protocol is designed from scratch. The transport layer is a good example of thisapproach, in which different protocols like TCP, UDP, SCTP or DCCP mostly differ in theway they do flow and retransmission control. A protocol design strategy that identified majorcommonalities across protocols and tried to make a generic design adaptable to differentenvironments would considerably reduce the number of protocols required in a network.

• Protocols designed independently from each other. Closely related to the last bulletpoint, most protocols today are designed in isolation from each other, which maximizesspecification and implementation work due to repeated functions that are re-invented byeach protocol. For example all routing protocols out there (OSPF, IS-IS, BGP, RIP, etc.) areabout maintaining a partially distributed database across network nodes, and then applyingdifferent algorithms locally to compute forwarding tables. What changes from protocolto protocol is the strategy used for replication, the information exchanged and the localalgorithms; but the mechanisms used to encode the information - abstract and concretesyntaxes - and to communicate updates can be common to all of them. Redesigning groupsof protocols with common goals in order to maximize commonality between them wouldsimplify designing, deploying, operating and managing network protocols.

4.3 Naming, addressing and routing

• Lack of application names. A well formed network architecture needs application namesthat are location-independent, so that applications attached to the network can maintain theiridentity regardless of where they are. In the Internet URLs may appear to play this role, but aclose inspection reveals that this is not right. The URL is a concatenation of a domain name,a transport layer port and a string which is meaningful to the application. Domain namesare just synonyms to IP addresses (they are resolved to IP addresses by DNS, which is a

61




directory service external to the network). When an application requests a transport serviceto the sockets API it passes the address where the destination application is attached: thenetwork does not know about names. If the application changes its point of attachment tothe network, its IP address changes and all the transport connections to that application arebroken. Also, access control rules (e.g. firewall rules) are written in terms of IP addressesand transport ports; which means that they have to be updated every time an applicationchanges its attachment to the network.

• Naming the interface instead of the node. Within a layer a node is the protocol machinethat strips off the header of that protocol in that layer. Therefore protocol PDUs within alayer are addressed to nodes. However in the TCP/IP protocol suite addresses are assignedto interfaces (Points of attachment to the layer below), not nodes. This fact makes realmulti-homing impossible to support (because the network does not know that two interfaceaddresses reach the same node), makes router forwarding tables 3/4 times larger and greatlycomplicates mobility.

• No names for layers, no layer directory. Although some layers do have names (BSS-idin the case of WLANs or VLAN-ids in the case of VLANs), the upper layers close to theapplications dont have them. This fact, together with the lack of application names, causeapplications to be available through a single layer at a time (usually the topmost one), or tomultiple layers if the application is attached to interfaces of multiple top layers (e.g. an in-terface belonging to the public Internet, another interface belonging to a private IP network).The lack of layer directories makes discovering what is the best layer to reach an applicationimpossible: this information has to be statically configured into client applications.

4.4 Mobility and multi-homing

• Need for special protocols to achieve multi-homing. A number of approaches has beenproposed to achieve multi-homing in current networks. Classical (or true) multi-homingrequires provider-independent addresses - which cannot be aggregated in the global Internetrouting table - a dynamic routing protocol (typically BGP) and at least two links: eachone to a different provider. When one of the links to a provider fails BGP will recomputethe AS path so that the other provider is selected. However this only allows multi-homingat the AS-level. Host multi-homing has partial support through protocols that exploit theuse of multiple IP interfaces (such as SCTP, MP-TCP or SHIM6). However in this approachpackets that are already en route towards an IP address belonging to an interface that is downwill be lost (hence, only partial multi-homing support is achieved). The whole approachmakes multi-homing complex and only partially supported.

• Need for special protocols and artifacts to achieve mobility. That support for mobility -which can be just seen as dynamic multi-homing - is cumbersome should come to no sur-

62




prise. The lack of application names and node addresses require the use of special protocolsand artifacts to support some degree of host mobility. Most of current mobility solutionsrequire setting up tunnels through specialized protocols. Managing these tunnels results insignificant overhead, since they have to be updated every time the mobile host changes itspoint of attachment to the network. Different types of mobile networks with varying supportfor host mobility require different protocols (e.g. WiFi vs. cellular). Tunnel-less mobilitysolutions based on true multi-homing such as the one achieved via BGP have been inves-tigated but proven too slow, since BGP was never designed to cope with the fast-changingnature of mobile access networks.

4.5 Quality of service, resource allocation, congestion control

• Lack of consistent QoS model across layers. The lack of a clear, consistent model to com-municate performance requirements across layers make it hard to manage the performanceof a multi-layer network so that it delivers consistent service experiences to its customers.Since there are no abstract mechanisms for the communication of performance requirementsbetween layers, this communication has to be designed on a use-case per use-case basis, usu-ally involving the Network Management System. The layer also must be able to identify theflows belonging to different QoS groups, which also depends on the technology being used:DSCP code marking can be used in the case of IP, MPLS traffic engineering based on thevalues of MPLS labels, VLAN tags for Ethernet or I-SID (service identifiers) in the case ofPBB.

• Only end-to-end (too long) congestion control loops. Dealing with congestion at thetransport layer only maximizes the length of the congestion control loop, which also maxi-mizes the time to react to congestion and its variance (oscillations). As a consequence, TCPsenders may be reacting to congestion that is no longer there; or by the time the TCP senderreacts the network is already in a very congested state. If congestion was managed at thelevel of each individual network, shorter and more effective control loops would be possible.

• Predatory (implicit) congestion control. The use of lost or duplicate packets as a signal ofcongestion causes TCP to interpret packet loss due to link failures as congestion (which isusual in TCP-over-wireless scenarios). As a consequence TCP overreacts to inexistent con-gestion, degrading the throughput and delay experienced by applications. Explicit Conges-tion Notifications (ECN) signaling by routers in the path traversed by the PDUs belongingto the TCP connection provides a better feedback signal to react to congestion.

• Homogeneous congestion control policies for heterogeneous networks. Transport pro-tocol connections typically go through a number of different networks and/or network seg-ments with different characteristics (wired/wireless access, aggregation, core, interconnect,datacenter, etc). Trying to find a single congestion controller that can behave optimally for

63




the composed end to end loop control loop is just impossible: what is optimal for a certainsegment is not efficient for another one. Again, if congestion is managed at the network ornetwork segment level - through multiple, shorter control loops - each control loop can beoptimized for the network segment it is controlling.

4.6 Security

• Most protocols come with their own security model. The TCP/IP protocol suite secu-rity model is usually based on building security functions for each protocol. For example,DNSSEC provides data integrity and authentication to security-aware resolvers. IPsec isa general framework for secure IP communications, supporting confidentiality, integrity,authentication or protection against replay attacks. However since IPsec works end-to-end within a layer, it either only protects the IP payload (transport mode) or makes IPconnection-oriented (tunnel mode), encapsulating a protected IP packet into an unprotectedIP packet. This makes IPsec a partial solution, not addressing the requirements of IP controlplane protocols, which need to define their own security functions, such as OSPF or BGP.TLS, the Transport Layer Security Protocol, specifies a set of related security functions toenable secure communications over the transport layer. All in all, this approach results in ahigh overhead and unbounded complexity, since new protocols will in many cases requireits companion security protocols.

• Coupled port allocation and synchronizations functions. Use of well-known ports.Transport layer protocols overloads the port-id to be both a local handle (socket) and theconnection-endpoint-id (cep-id). Furthermore the lack of application names overloads port-ids with application semantics: application endpoints are identified by a combination of IPaddress and a well-known port-id that is assigned when the application binds to an IP layer.Static destination port-id values have to be known by the source application when request-ing a transport connection. Therefore an attacker wanting to intercept a particular transportconnection only needs to guess/spoof the source port-id.

• No application names: network addresses exposed to applications. Since the TCP/IPprotocol suite does not have application names (DNS is an external directory), IP layersexpose addresses to applications. This disclosure of information facilitates spoofing of IPaddresses, and in combination with the use of common monitoring tools such as tracerouteor ping allows attackers on end hosts to learn about the addresses of potential targets ina layer as well as the network connectivity graph. Attackers can use this information tosetup DDoS attacks by automating the discovery and infection of vulnerable machines, orto attack the network infrastructure by gaining control over routers.

64




4.7 Network Management

• Too little commonality in network protocols. Different layers perform different functions,which require different protocols. Even within the same layer multiple protocols are re-quired to adapt the layer to different operational requirements. Each protocol comes with itsown protocol machine definition, its own configuration and its own state model. Managingnetworks designed this way is hard and cumbersome, since the NMS needs to understandthe state, operation and configuration models of all the different protocols in the network, aswell as their interactions.

• No well defined model for interaction between layers. To manage a multi-layer network,not only needs the NMS to understand individual protocols, but also the interaction amongstthe multiple protocol layers. Since there is no well-defined, consistent layer API, each layerinteraction has to be dealt with on a case-by-case basis, complicating network configuration,performance and security management.

• Different protocols and object models for Network Management. Although NETCONFand YANG are gaining traction as a protocol and object model for network configurationmanagement, they are still far from covering all the network segments and technologies.CMIP and X.700, SNMP and SMI, and SID (the Shared Information and Data Model) arestill prevalent in different networking areas. As a consequence converged operator networkstoday are likely to require multiple protocols and object models for management, compli-cating this task even more.

• No bounded set of APIs for network programmability. SDN wants to enhance the pro-grammability of network devices through the separation of the data forwarding and controlplanes. Current SDN approaches focus on defining APIs and protocols for data forward-ing via centralized controllers. However, since SDN does not change the organization ofnetwork protocols and layers, and the number of network protocols is unbounded, the setof APIs required to support network programmability is also unbounded. Therefore pro-grammability is achieved at the cost of increased complexity, making it difficult to agree ona set of standard APIs to facilitate programmability of network functions across a wide setof device manufacturers.

65




5 Conclusions

D2.1 has explored the most efficient way to design the network of a converged service provider de-livering multiple types of services over a heterogeneous set of access networks. The logical designprovided in this document has tried to minimize the use of different protocols and technologies tothe bare minimum. The key technologies required are:

• LTE to support 4G mobile access in cellular networks.

• WiFi and PMIPv6 for scalable Wireless LAN access networks.

• xDSL and FTTH for residential and business fixed access.

• Ethernet bridging - in its different variants: VLANs, Provider Bridges and Provider Back-bone Bridges - to segment user traffic belonging to different services.

• MPLS, MultiProtocol Label Switching to multiplex traffic belonging to different usersand services over the MAN and/or core networks and to perform traffic engineering.

• Multi-protocol BGP and its associated configurations to support Layer 2 and Layer 3 VPNservices.

• VXLAN or another L2 over L3/L4 tunneling protocols to support multi-tenancy in datacen-tres.

• IPv4 and IPv6 to transport the traffic of customer applications and exchange traffic withpeer or upstream network service providers.

• NETCONF and YANG as the network management protocol and managed object modelinglanguage, respectively.

This document has identified a number of limitations in the design regarding network archi-tecture; protocol design; naming, addressing and routing; mobility and multi-homing; resourceallocation and congestion management; security and network management. These limitations areinherent in the network architecture and protocols upon which the design is based. Therefore, inorder for these limitations to be overcome an alternate network architecture is required. ARC-FIRE’s deliverable D2.2 will propose a logical RINA-based converged service provider networkdesign, and compare it to the design outlined in D2.1 in the light of the limitations identified inthis document.

66




References

[1] 3GPP, “3gpp release 14,” 3GPP Release 14, December 2015.

[2] I. 802.11, “Ieee 802.11 working group web page,” online: http://www.ieee802.org/11/, May2016.

[3] S. Gundavelli, K. Leung, V. Devarappalli, K. Chowdhury, and B. Patil, “Proxy mobile ipv6,”IETF Network Working Group RFC 5213, August 2008.

[4] D. Johnson, C. Perkins, and J. Arkko, “Mobility support in ipv6,” IETF Network WorkingGroup RFC 3775, June 2004.

[5] C. Perkins, “Ip mobility support for ipv4,” IETF Network Working Group, RFC 3344, Au-gust 2002.

[6] J.Lee, J. Bonnin, P. Seite, and H. A. Chan, “Distributed ip mobility management from theperspective of the ietf: motivations, requirements, approaches, comparison, and challenges,”IEEE Wireless Communications, vol. 20, no. 5, pp. 159–168, October 2013.

[7] F. Giust, L. Cominardi, and C. Bernardos, “Distributed mobility management for future 5gnetworks: overview and analysis of existing approaches,” IEEE Communications Magazine,vol. 53, no. 1, pp. 142–149, January 2015.

[8] ITU-T, “Gigabit-capable passive optical networks (gpon): general characteristics,” ITU-TRecommendation G.984.1, March 2008.

[9] M. E. Forum, “Mef6.1 ethernet services definition - phase 2,” MEF Technical Specification,April 2008.

[10] I. 802.1, “802.1ad - provider bridges draft 6.0,” IEEE 802.1ad, September 2005.

[11] ——, “802.1ah - provider backbone bridges draft 4.2,” IEEE 802.1ah, April 2008.

[12] I. . W. Group, “802.1qay - provider backbone bridges traffic engineering,” IEEE 802.1Qay,March 2009.

[13] I. 802.1, “802.1aq - shortest path bridging,” IEEE 802.1aq, March 2012.

[14] L. Martini, E. Rosen, N. El-Aawar, and G. Heron, “Encapsulation methods for transport ofethernet over mpls networks,” IETF RFC 4448, April 2006.

[15] L. Martini, E. Rosen, and N. El-Awaar, “Transport of layer 2 frames over mpls,” IETF Net-work Working Group RFC 4906, June 2007.

67




[16] P. Pan, G. Swallow, and A. Atlas, “Fast reroute extensions to rsvp-te for lsp tunnels,” IETFNetwork Working Group RFC 4090, May 2005.

[17] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. Swallow, “Rsvp-te: Extensionsto rsvp for lsp tunnels,” IETF Network Working Group RFC 3209, December 2001.

[18] T. Bates, E. Chen, and R. Chandra, “Bgp route reflection: An alternative to full mesh internalbgp (ibgp),” IETF Network Working Group RFC 4456, April 2006.

[19] S. Yakusawa, A. Farrell, and O. Komolafe, “An analysis of scaling issues in mpls-te corenetworks,” IETF Network Working Group draft-ietf-mpls-te-scaling-analysis-05, December2008.

[20] GSMA, “Guidelines for ipx provider networks (previously interservice provider ip backboneguidelines),” GSMA official document IR.34, January 2016.

[21] A. Singh and J. Ong, “Jupiter rising: A decade of clos topologies andcentralized control ingoogle’s datacenter network,” Proceedings of the ACM SIGCOMM conference, 2015.

[22] A. Andreiev, “Introducing data center fabric, the next-generation facebook data center net-work,” Facebook blog, 2015.

[23] T. Narten, E. Gray, D. Black, L. Fang, L. Kreeger, and M. Napierala, “Problem statement:Overlays for network virtualization,” RFC 7364, October 2014.

[24] E. Rosen and Y. Rekhter, “Bgp/mpls ip virtual private networks (vpns),” IETF NetworkWorking Group, RFC 4364, February 2006.

[25] K. Kompella and Y. Rekhter, “Virtual private lan service (vpls) using bgp for auto-discoveryand signaling,” IETF Network Working Group, RFC 4761, January 2007.

[26] M. Lasserre and V. Kompella, “Virtual private lan service (vpls) using label distributionprotocol (ldp) signaling,” IETF Network Working Group, RFC 4762, January 2007.

[27] A. Sajassi and N. Bitar, “Extensions to the virtual private lan service (vpls) provider edge(pe) model for provider backbone bridging,” IETF RFC 7041, November 2013.

[28] A. Sajassi, R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, and W. Henderickx, “Bgpmpls-based ethernet vpn,” IETF RFC 7432, February 2015.

[29] A. Sajassi, S. Salan, N. Bitar, A. Isaac, and W. Henderickx, “Provider backbone bridgingcombined with ethernet vpn (pbb-evpn),” IETF RFC 7623, September 2015.

68




[30] A. Sajassi, J. Drake, N. Bitar, A. Isaac, J. Uttaro, and W. Henderickx, “A network virtualiza-tion overlay solution using evpn,” IETF BESS Working Group, draft-ietf-bess-evpn-overlay-02, October 2015.

[31] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, “Internet key exchange protocolversion 2 (ikev2),” IETF RFC7296, October 2014.

[32] S. Kent and A. Seo, “Security architecture for the internet protocol,” IETF RFC 4301, De-cember 2005.

[33] T. Dierks and E. Rescorla, “The transport layer security (tls) protocol version 1.2,” IETFRFC 5246, August 2008.

[34] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz, “Extensible authenticationprotocol (eap),” IETF RFC3748, 2004 June.

[35] N. Alliance, “Next generation converged operation requirements: introduction, generic re-quirements, modelling and tooling requirements,” NGMN Alliance, Tech. Rep., 2013.

[36] S. Wallin and C. Wilkstrom, “Automating network and service configuration using netconfand yang,” in Proceeding LISA’11 Proceedings of the 25th international conference on LargeInstallation System Administration, 2011.

[37] T. M. Forum, “Multi technology network management website,” Online:https://www.tmforum.org/mtnm/.

[38] A. Dora and K. Sundell, “General switch managementprotocol (gsmp) applicability,” IETFNetwork Working Group, RFC 3294, 2002.

[39] R. Dantu, T. Anderson, R. Gopal, and L. Yang, “Forwarding andcontrol element separation(forces) framework,” IETF Tech Report, 2004.

[40] J. Biswas, A. Lazar, J. Huard, and K. Lim, “The ieee p1520 standardsinitiative for pro-grammable network interfaces,” IEEE Communications Magazine, vol. 36, no. 10, October1998.

[41] O. N. Foundation, “Sdn architecture, issue 1,” ONF TR-502, June 2014.

69

Documents

ARCFIREict-arcfire.eu/wp-content/uploads/2017/10/arcfire_d21... · 2017-10-25 · D2.1 Converged network opera-tional environment report Document: ARCFIRE D2.1 Date: August 29th 2016