You are on page 1of 62

BACKHAUL EVOLUTION

Bruno De Troch
June 2014

COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.


ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
OVERALL AGENDA

1. SReXperts EMEA 2014 Presentation


2. Seamless MPLS Details
3. Comparison with MPLS-TP

2
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SReXperts 2014 Presentation
Bruno De Troch
June 2014

COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.


ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
AGENDA

1. The importance of backhaul


2. The traditional backhaul model
3. Drivers for changes in backhaul
4. Capacity evolution
5. Connectivity evolution
6. The service oriented backhaul model
7. Conclusions

4
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
AGENDA

1. The importance of backhaul


2. The traditional backhaul model
3. Drivers for changes in backhaul
4. Capacity evolution
5. Connectivity evolution
6. The service oriented backhaul model
7. Conclusions

5
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
DELIVERING SERVICES WITH QUALITY IN A COMPETITIVE WORLD

Demand is surging
- Many more smart devices, sometimes with shared data plans
- More time is spent online
- Growing media rich consumption
- Increasing QoE expectations

New services should be enabled quickly and across the full customer base

High competitive pressure

Operational cost and complexity should be reduced

6
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THE IMPORTANCE OF BACKHAUL
AS SEEN BY MANY SERVICE PROVIDERS

The facts are we have the nation's largest 4G network covering nearly
250 million people with LTE and HSPA+ with enhanced backhaul,"

It's important to note that having enhanced backhaul in place is


necessary to deliver a 4G experience.

* From a FierceWireless interview with 2 Tier 1 MNOs

7
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
AGENDA

1. The importance of backhaul


2. The traditional backhaul model
3. Drivers for changes
4. Capacity evolution
5. Connectivity evolution
6. The service oriented backhaul model
7. Conclusions

8
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THE TRADITIONAL BACKHAUL MODEL
LAYERS AT WORK
Pipe Model
- Point-to-Point
- From Access Node (AN) to a smarter Service Node (SN)
- Lower Layer (below IP Layer) technology Smart(er)
Node

Access
Node

Backhaul
Non-IP

Many examples (Mobile and Non-Mobile) IP

- BS BSC (TDM Circuit, ATM PVC, Ethernet E-Line)


- DSLAM BNG (Wire, ATM PVC, Ethernet E-Line)
- CPE PE (Wire, TDM Circuit, FR/ATM PVC, Ethernet E-Line)

One hop @IP might result in one or more hops at lower layer(s)
9
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THE TRADITIONAL BACKHAUL MODEL
WHY DID WE DO THIS?
Cost

Perceived Complexity of higher layers

Operational reasons
- IP address management
- Responsibility and ownership spread across teams
-

10
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THE TRADITIONAL BACKHAUL MODEL
CHALLENGES
Non-Intelligent (mostly at lower layer) decision at pipe entry
- Defer decision to the more centralized service node/location (SN) Smart(er)

- Also if packet is dropped or needs special handling


Node
Access IN OUT
Node
Non-granular service locations Backhaul
- Either before IN or after OUT of pipe
- No mid-way escape possible
Any-to-any costly or not-optimal
- From IN to many pipes scaling problem on access node
- Hub-and-spoke of pipes scaling problem on hub node, E2E latency problem
Smart(er) Smart(er)
Node Node
Access IN OUT Access IN OUT
Node Node

Backhaul Backhaul

11
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THE TRADITIONAL BACKHAUL MODEL
QUESTIONING THE MODEL
Would it make sense to have IP decisions earlier in the chain?
- Why would we do it?
- What would we gain?
L3
Would it cost much more (to operate)?
< L3 < L3 < L3 < L3

What is the ideal midway point? IP/MPLS

L3

Blindly cross-connecting below the IP layer assumes you can trust the packet gets closer to the destination
L3
- Is this always true? < L3 < L3
- What about path/service redundancy?
- At what layer is it best handled? < L3 < L3

- How does different layers interact? L3 IP/MPLS


- Is fine-tuning of protocols/timers needed? < L3 < L3

12
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
AGENDA

1. The importance of backhaul


2. The traditional backhaul model
3. Drivers for changes
4. Capacity evolution
5. Connectivity evolution
6. The service oriented backhaul model
7. Conclusions

13
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
DRIVERS FOR CHANGES IN BACKHAUL

Capacity Increases
- More subscribers/devices/applications generate more and bigger flows

Coverage and Convergence Requirements


- Any Device on Any Access from Anywhere to Anywhere

Service Requirements
- New services impose new requirements (latency limits, synchronization, )

Operational Challenges
- Efficiency, simplicity and cost gains through automation

Standardization
- All IP

14
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
EXAMPLE: MOBILE BACKHAUL EVOLUTION
FIRST AND SECOND PHASE
Phase 1 (2G/3G):
Capacity Increases Point-to-Point connectivity model (no changes)
- TDM/FR/ATM migrated to Ethernet for higher throughput
- Still Point-to-Point between eNBs and RNCs

Phase 2 (2G/3G/LTE):
Capacity Increases Metro Fabric connectivity model
- Ethernet/IP with higher throughput
- Consistent Any-to-Any between eNBs and RNC/EPC/SeGW

15
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
EXAMPLE: MOBILE BACKHAUL EVOLUTION
THE THIRD PHASE
Phase 3 (Converged Backhaul):
Capacity Increases Global Fabric connectivity model
- Ethernet/IP with even higher throughput
- Metro Fabric to Global Fabric
- many possible termination points
(eNBs, MSAN, OLT, WiFI AP, RNC, EPC, WiFi GW, BNG, CDN, MBMS GW, DPI, IPTV GW, DC GW, )
- could be distributed or centralized
- could be physical of virtual

16
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
AGENDA

1. The importance of backhaul


2. The traditional backhaul model
3. Drivers for changes
4. Capacity evolution
5. Connectivity evolution
6. The service oriented backhaul model
7. Conclusions

17
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
CAPACITY EVOLUTION - THROUGHPUT
(MOBILE) DATA TRAFFIC INCREASING DRAMATICALLY

30 Gbps

10 Gbps
5 Gbps

*Traffic Evolution over 5 years


(taken from a European mobile operator, measured at peering point)
18
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THROUGHPUT IS NOT THE ONLY CAPACITY PARAMETER
THE IMPACT OF BACKHAUL DELAY ON PERFORMANCE

LTE TCP Window/Packet Drop/Delay on Mobile Throughput


Delay is the main factor affecting LTE throughput.
TCP throughput = TCP_Window_Size/Round_Trip_Time (latency).
Dropped packets can have a huge impact on overall throughput.
Large TCP window improves RF channel rate, but packet drop impact is more severe for large window.
19
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
AGENDA

1. The importance of backhaul


2. The traditional backhaul model
3. Drivers for changes
4. Capacity evolution
5. Connectivity evolution
6. The service oriented backhaul model
7. Conclusions

20
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
CONNECTIVITY EVOLUTION REQUIREMENTS

Convergence
- Any access (Multiple Media, Speeds, )
- Any topology

Any to Any Connectivity

Large Scale

Cost

21
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
EXAMPLE: LTE CHANGES THE ARCHITECTURE

TRADITIONAL
2G, 3G
BACKHAUL DATA CENTER
MTSO REGIONAL/NATIONAL GGSN
(TDM, ATM, Ethernet) BSC/RNC BACKBONE
Hub & Spoke (IP/MPLS)

MACROCELL

SGSN

MTSO
BACKHAUL BSC/RNC DATA CENTER
(IP/MPLS,CARRIER ETHERNET) SeGW REGIONAL/NATIONAL PGWs
BACKBONE
(IP/MPLS)
Any-to-Any Packet Sync
(X2, S1 flex)

IPSec

LTE, LTE+ SMALL CELL


SGWs
CENTRALIZED BBU

22
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
TODAY: SERVICE BORDERS ARE STILL NETWORK BORDERS
RNC

SGSN
MTSO

GGSN
IP-VPN IP/MPLS
Mobile Core
CSG

Hub 3G to
Mobile backhauling network Mobile core network
LTE
RNC
S1
SGSN
MTSO
X2 secured

Se-GW GGSN
IP-VPN IP/MPLS
Mobile Core
X2 unsecured CSG

S-GW

Hub P-GW MME


Mobile backhauling network Mobile core network

23
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
CONVERGED BACKHAUL REQUIRES EVEN MORE FLEXIBLE ARCHITECTURE

MTSO
BSC/RNC
BACKHAUL DATA CENTER
SeGW
(IP/MPLS,CARRIER ETHERNET) REGIONAL/NATIONAL PGWs
BACKBONE
(IP/MPLS)
Any-to-Any Packet Sync
(X2, S1 flex)

IPSec

LTE, LTE+ SMALL CELL


SGWs
CENTRALIZED BBU

BACKHAUL DATA CENTER


(IP/MPLS,CARRIER ETHERNET) REGIONAL/NATIONAL PGWs
BACKBONE
(IP/MPLS)
Any-to-Any Packet Sync
(X2, S1 flex, MSAN-BNG)

IPSec

MOBILE, SMALL CELL


FIXED SGWs
CENTRALIZED BBU

24
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
AGENDA

1. The importance of backhaul


2. The traditional backhaul model
3. Drivers for changes
4. Capacity evolution
5. Connectivity evolution
6. The service oriented backhaul model
7. Conclusions

25
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THE SERVICE ORIENTED BACKHAUL MODEL
TOWARDS A CONVERGED ACCESS AND AGGREGATION
Make the backhaul flexible enough for true service flexibility
- Any access
- Any topology
- Any service characteristics
- Any service termination point location
- Network Function Virtualization

Decouple transport and services


- Topological freedom of infrastructure
- Multiple service overlays

26
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THE GLOBAL ANY TO ANY FABRIC

BACKHAUL MTSO DATA CENTER


(IP/MPLS,CARRIER ETHERNET) BSC/RNC
REGIONAL/NATIONAL PGWs
BACKBONE
(IP/MPLS)
Any-to-Any Packet Sync
(X2, S1 flex, MSAN-BNG)

IPSec

MOBILE, SMALL CELL


FIXED SGWs
CENTRALIZED BBU

GLOBAL ANY-TO-ANY FABRIC

27
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THE GLOBAL FABRIC
POSSIBLE IMPLEMENTATION
Use IP/MPLS as unifying layer
- Bring it closer to the access
- Access Node connects Wire/Lambda to IP/MPLS Domain

Only 2 Touch Points for Service Enablement


- Access Node to Access Node
- Access Node to Service Node
- Service Node to Service Node

L3

No intermediate domain borders


< L3
IP/MPLS
L3
IP/MPLS
IP/MPLS

28
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THE GLOBAL ANY TO ANY FABRIC
CHALLENGES
Scale
- Higher number of devices
- More access nodes
- More service nodes
- Accommodate lower capabilities of most devices
- Control plane
- Data plane

End to end Resiliency


- Transport
- Services

Manageability

29
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
THE GLOBAL ANY TO ANY FABRIC
GOALS ARE IN-LINE WITH SEAMLESS MPLS CONCEPT
Scalability
- Allow the network to scale to 100s of metro regions with 1000+ nodes each, recognizing that some nodes
(e.g. access) have more limited capabilities

Fast Restoration
- Support fast service restoration after failures (using local or E2E repair techniques).
Transport restoration can speed up service restoration but service restoration is the ultimate goal.

End-to-End Provisioning
- Remove service-specific configuration between MPLS domains
- Create end-to-end services by decoupling service and transport layer

30
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
WHAT DID WE GAIN?
SERVICE FLEXIBILITY BY DECOUPLING TRANSPORT AND SERVICES
Transport:
- MPLS Transport possible between ANY possible endpoints
- Optimize Transport Paths irrespective of Application

Services:
- Overlay irrespective of transport
- Per-service Characteristics

31
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
To avoid waste of badndwith and extra-delays, MME / SGW /
EXAMPLE OF SERVICE FLEXIBILITY PGW shall be selected in same ePC site as SeGW
dependency between transport and service

CENTRALIZED SEGW
E-LINE
7750-SR
(Ethernet, MPLS, ) VPLS / H-VPLS IP-VPN SeGW
PCRF
RAN / e-RAN / Access Backhaul/Aggregation Core VRF

IP-VPN VRF

VRF
ETH Fiber or leased PGW
lines
VRF
ETH
7750-SR IP-VPN VRF

VRF SGW
SeGW
IP
VPN
ETH ePC site 1 MME

E-UTRAN VPN
PON ETH 7750-SR
ETH SeGW
IP
VPN PCRF
VRF
ETH
IP-VPN VRF
ETH VRF
PGW
uWave RNC site VRF
ETH IP-VPN VRF
VRF SGW
ETH SeGW
ETH

ePC site 2 MME

VRF S1-MME
eNB SeGW selection per ePC site: IP Signalling

Private VPRN
Same for all if Active-Standby ePC se
VRF
VRF c
User Plane
S1-U / X2 / S5
Per TAU/RAU if Active-Active (Load sharing)
32 VRF
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED. OAM OAM
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
EXAMPLE OF SERVICE FLEXIBILITY Independence of ePC node
selection from SeGW
DISTRIBUTED SEGW architecture

E-LINE
7750-SR
(Ethernet, MPLS, ) VPLS / H-VPLS IP-VPN 7750-SR
PCRF
RAN / e-RAN / Access Backhaul/Aggregation Core VRF
VRF
VRF
ETH Fiber or leased PGW
lines
VRF
ETH
7750-SR SeGW VRF
VRF SGW
VRF
SeGW
VRF
User Plane VPN
ETH VRF ePC site 1 MME
Signalling VPN
PON ETH 7750-SR
ETH VRF
OAM VPN
VRF PCRF
VRF
ETH VRF
VRF
ETH SeGW VRF
PGW
uWave RNC site
ETH Optimized X2 delay VRF
VRF
VRF SGW
ETH

ETH

ePC site 2 MME

VRF S1-MME
IP Signalling Larger SeGW deployment
Private VPRN

VP VRF se VRF S1-U / S5


LS backhaul c User Plane X2
VRF 33
OAM
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
OAM
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SERVICE OVERLAY MECHANISMS
HOW ARE SERVICES INSTANTIATED?
SDN Techniques
- Assume any-to-any connectivity through global fabric
- Similar to datacenter flat L2 network

Any service can be instantiated anywhere


- Flexible movement of services
- NFV Ready

In combination with End-to-End Network Management System

34
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SERVICES OVERLAY THROUGH A WAN SDN CONTROLLER

ReST Abstract Service


API and Model

Virtual Service (ReST, NETCONF)


Directory (VSD)

XMPP

Virtual Service Virtual Service


WAN SDN Controller (WSC)
Controller (VSC) Controller (VSC)

NETCONF, CLI, PCEP, SNMP, OF


OF OF

dVRS SD VPN nCPE


3rd Party 7x50 1830 1830 White 7x50
PE Box
WAN

Data Center Data Center

35
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
FUNCTIONAL COMPONENTS OF A WAN SDN CONTROLLER

Policy server OSS/Portal


( VSD)

ReST, Netconf/YANG, XMPP

Service Manager

Resource ReST ReST


Resource
Manager
OFPeering/
Controller
OF Manager Optics PCE
Service DB IP PCE TED+LSP TED + LSP
Controller
PCEP
OF BGP Netconf/YANG PCEP BGP-LS PCEP PCEP OF OSPF-TE

RR SAM

CLI, SNMP, OF PCEP

White box

36
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
ACCESS TO THE GLOBAL FABRIC
WHERE IS THE IDEAL ENTRY POINT TO THE IP/MPLS GLOBAL NETWORK?
L3

< L3
IP/MPLS
L3

Single Connection Any to Any


Dedicated to one customer Multiple (Redundant) Paths
Fixed Statistical Multiplexing
Cost Optimized Flexibility

37
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
EXTENDING THE GLOBAL FABRIC
NON IP/MPLS MULTIPLEXED ACCESS
Heterogeneous solution is still sometimes necessary
- Ethernet, L2oGRE
- Why: specific requirements, legacy, cost, politics
- Example: CPRI

Then a common management system is even more necessary

38
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
EXAMPLE: COMMON PUBLIC RADIO INTERFACE (CPRI)
Radio
Radio
Equipment Fronthaul Equipment
Controller
CPRI (e.g. over fiber)
RF Only Centralized
Base Band Unit
(BBU)
Summary
Interface standard for encapsulating antenna samples sent between a radio and a baseband unit (BBU)
Separation of functions brings efficiency and scale , aligned with a cloud model

Characteristics
Not packet based; signals are interleaved in a low latency TDM-like fashion
Assumes near zero jitter, near zero bit error rate
Defines multiple constant bit rate containers in multiples of 614Mbit/s up to 9.6Gbit/s -
Allows larger containers to be made up of smaller containers
Containers can be mixed between different sectors and between different technologies
Includes alarms and timing/synchronization

39
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
AGENDA

1. The importance of backhaul


2. The traditional backhaul model
3. Drivers for changes
4. Capacity evolution
5. Connectivity evolution
6. The service oriented backhaul model
7. Conclusions

40
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
CONCLUSIONS

Backhaul architectures need to evolve to cope with new service requirements

Service Flexibility is the key driver

IP/MPLS is the right technology to enables the required global any to any fabric

41
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
Seamless MPLS Details

COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.


ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SEAMLESS MPLS
END-2-END MPLS ENABLING SCALE AND SIMPLICITY

MPLS MPLS MPLS


Metro 1 Core Metro 2
Service label (PW,VC label)

Inter-area/AS label (BGP label)


Transport Layer
Intra-area/AS label (LDP/RSVP)

MOTIVATIONS AND DRIVERS WHY SEAMLESS MPLS ? SEAMLESS, SCALABLE, RESILIENT

Fixed Mobile Convergence Existing MPLS features (LDP inter area Makes deploying services faster and
LSP, inter area RSVP LDPoRSVP, PW more flexible by removing network
Evolution to LTE
switching) do not address end to boundaries
Cloud services scale, resiliency and manageability Helps scale the end-to-end network to
MPLS being deployed end-to-end more than 100,000 MPLS devices
Seamless MPLS extends MPLS network
form access to aggregation to the IP to integrate access, aggregation and Supports end-to-end fault detection,
core layers of the network core into a single MPLS domain fast protection and end-to-end
operations, administration and
Based on existing protocols (like BGP maintenance (OAM) functions.
and LDP) minimizing risk
For additional Information: Seamless MPLS Techblog
43
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SEAMLESS MPLS
THE PRINCIPLE

Seamless MPLS extends the core domain and integrates aggregation and access domains into a single MPLS
domain, whilst taking into account the limited feature-set and scale of aggregation nodes (AGNs) and access
nodes (ANs)
Uses divide-and-conquer approach large problem is divided into many smaller problems
Gateway between core and aggregation and core network is implemented by an Area Border Router (ABR)
Architecture can be used for residential, MBH, or business services (de-coupling transport from service layer)
Does not require any new protocols - just uses existing protocols such as BGP, LDP, RSVP and IGP (IS-IS/OSPF)

PE PE ABR P ABR PE PE
Access Aggregation Aggregation Access

Metro-region Core Metro-region

44
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SEAMLESS MPLS
KEEPING THE SCALABILITY, RESILIENCY AND END-POINT PROVISIONING
2 END-POINT PROVISIONING
SERVICE PW
Inter-metro MPLS transport tunnel

Metro MPLS Metro MPLS Metro MPLS


tunnel tunnel tunnel

P BNG
ABR-11 ABR-21
PE-1 PE-2
Aggregation Aggregation
3 RESILIENCY
PE-1 ABR-12 ABR-22 PE-2
Access IP/MPLS Access
Metro 1 IP/MPLS
core IP/MPLS
Metro 2
~1000 MPLS nodes
~1000 MPLS nodes
1 SCALABILITY Core connecting 100s of metro
regions

METRO 1 IGP/MPLS CORE IGP/MPLS METRO 2 IGP/MPLS


domain domain domain

45
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SEAMLESS MPLS
EXAMPLE OF ARCHITECTURE
LDP FRR LFA , RSVP
Filtering of BGP routes to IBGP 3107 is used for End to end provisioning
allow only relevant inter-metro MPLS
protects against link loopbacks to be leaked in connectivity
No service awareness in
or local ABR failures
the access domain
NHSelf with label
intermediate nodes
Resiliency is based on reprogramming in the All domains separated at MPLS
EDGE PIC for labeled BGP local ABR to allow having
route end to end BGP label LSP
level

RR NHSelf RR NHSelf RR NHSelf RR NHSelf


iBGP-3107 iBGP-3107 iBGP-3107 iBGP-3107 iBGP-3107 Can also work with ASBR,
if no collapsed PEs exist
LDP /RSVP LDP/RSVP LDP/RSVP LDP/RSVP LDP/RSVP
between core and
ISIS L1 ISIS L2 ISIS L2 ISIS L2 ISIS L1 aggregation
OSPF area OSPF area OSPF area 0 OSPF area OSPF area
Different instance ABR - RR NHSelf
ABR ABR
ABR/ PE ABR / PE
CSG Aggregation Aggregation CSG
P

ABR IP/MPLS ABR NHSelf NHSelf


core
eBGP-3107
IP/MPLS
Metro 2 ASBR ASBR
IP/MPLS
Metro 1

46
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
Comparison with MPLS-TP

COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.


ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
MPLS EVOLUTION

Over 10 years old!


- Initially fast switching mechanism
- Evolved to service delivery mechanism
Considered complex due to overloading
- Many functionalities
- Many protocols
- Dependability on IP
Triggered competing solutions (eg PBB-TE) and MPLS adapted mechanisms (eg MPLS-TP)
Latest step is to extend the MPLS stretch and define interactions
- Seamless MPLS
- MPLS in the Access
- Pseudowire Head-End Termination
THE PROMISES OF MPLS-TP

Focus on transport
- Back to the roots: transport only
- IP/MPLS considered too complex for transport
- Need for better OAM toolkit

Interest in the market is not because of added value, but rather because of simplicity

MPLS-TP is relatively easy to implement for IP/MPLS based solutions

49
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
MPLS-TP IN AN NUTSHELL

MPLS-TP is a subset of IP/MPLS


- The data plane is exactly the same (labels!)
- There is a special label that is used for inband communication (GAL -Generic Alert Label)
MPLS-TP does not have a control plane
- it is all down to manual configuration
- of the different labels for tunnels, and PW
- the idea is to use GMPLS as MPLS-TP Control Plane
- The OAM is different due to the lack of IP infrastructure ( a control plane) the OAM functions and tools
that are currently under definition must be able to operate in an IP-less environment;
For OAM there are two offers on the table: (Y.1731) and BFD
- It works with the GAL and some other infrastructure to be able to have multiple communications
channels (ACH)

50
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
MPLS-TP: MUST INTERWORK WITH NATIVE IP/MPLS

Per RFC 5654


The MPLS-TP data plane MUST be a subset of the MPLS data plane as defined by the IETF.
The MPLS-TP design SHOULD as far as reasonably possible reuse existing MPLS standards.
Mechanisms and capabilities MUST be able to interoperate with existing IETF MPLS
[RFC3031] and IETF PWE3 [RFC3985] control and data planes where appropriate.
Data-plane interoperability MUST NOT require a gateway function.
PRACTICAL (?) INTEGRATION OF MPLS-TP AND IP/MPLS

(*) Presented by TI at MPLS WC 2012


52
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
MPLS-TP TO IP/MPLS PRACTICAL INTEGRATION CONCERNS

No E2E visibility for provisioning


No E2E OAM consistency
No E2E redundancy mechanisms
Slower convergence due to overlay (base on keep alive iso detection)
No native P2MP connectivity
No E2E consistent QoS
No flexible service deployment

53
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
Comparison
COMPARISON of IP/MPLS
OF IP/MPLS and MPLS-TP
AND MPLS-TP
for Utility IP Network Transformation

Attribute IP/MPLS MPLS-TP


Maturity Proven, with many utility deployments Infancy, little or no proven deployment
10+years experience for utilities

Standardization Fully standardized Some still in progress

Multi-vendor Interoperability Proven, many Limited


Multi-vendor IP/MPLS MPLS-TP Proven, many Unproven
Interworking
VPN Supported L1, L2, L3 L1, L2 only

Services Support Full Transport only

IP Multicast Delivery Optimized None

Protection FRR or active/standby path Protection switching

Traffic Engineering Dynamic Static

Convergence Common NMS, training, and sparing Separate NMS, training, and sparing for
for L1 to L3 L1/L2 and L3
OAM Single platform for L1 to L3 Separate platform required for L3

7
54
COPYRIGHT 2011 ALCATEL-LUCENT.
COPYRIGHT ALL
2013 ALCATEL-LUCENT. ALL RIGHTS
RIGHTS RESERVED.
RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
Segment Routing

COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.


ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
MPLS OVERVIEW - HISTORY
Two main protocols: LDP or RSVP LDP RSVP
- LDP for scale and simplicity extensions
Overview Multipoint to point Point to point
to LFA/LFA policies/RLFA
- RSVP for TE and FRR for some time Operation Simple LSP per destination/
TE-path
To scale MPLS we enabled Dependencies Relies on IGP Relies on IGP TE
- LDPoRSVP
LBL allocation Local significant Local significant
- Seamless MPLS: LBL-BGP with LDP/RSVP per node (interface) per node (interface)
Traffic engineering: RSVP based Traffic Engineering No Yes
Services through: Scaling 1 LBL per node Nx(N-1)
(interface)
- BGP/IGP shortcuts, PW (T-LDP/BGP),
VPLS (LDP/BGP), VPRN (BGP), MVPN Fast Reroute LFA, LFA Policies, Link/Node protection
(BGP/mLDP/P2MP RSVP) Remote LFA - (detour/facility)
<100% coverage 100% coverage
Issues:
Multicast mLDP P2MP RSVP
- TE solutions dont scale when we want
more granularity/dynamicity, RLFA too IPv6 Extensions required Extensions required
complex (dynamic T-LDP signaling)
57
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SEGMENT ROUTING SROS
13.0
SIMPLIFYING CONTROL PLANE, IMPROVING DATA PLANE
Applications
Segment routing key technology concepts
- Nodes, links represented as segments APIs

- IGP used for segment label distribution


- SOURCE routing using learned SR labels Policy Resource
Driven Discovery &
- Native IP FRR Provisioning Control
- MPLS data path
SDN Controller
Deployment:
- Native SR network with external controller for TE Network
APIs
- Segment Routing to improve coverage (simplify DLFA/ Node-SID: 100
RLFA), Create virtual planes, steer traffic on non-SPF PKT
1000
paths 100
P P
Node-SID: 1000
Benefits: PE
P PE
- Simplify FRR: DLFA/RLFA/TILFA PKT Node-SID: 200
- Scalable TE 1000
200 P P
- Simplified control plane: no LDP/RSVP for transport LBL SEGMENT ROUTING
distribution (but can still be used) P
- T-LDP still required if LDP-VPLS, PW is deployed

SEGMENT ROUTING
58
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SEGMENT ROUTING SROS
13.0
MAIN APPLICATIONS
Shortest Path Routing Applications
- LDP transport LSP infrastructure replacement or backup coverage improvement
- Shorted path forwarding with ECMP: admin-group, SRLG support
- Achieve full protection coverage with LFA < Remote LFA < Directed LFA < TI LFA
- Can co-exist with LDP or RSVP in seamless MPLS deployments
Traffic Engineering (TE) Applications
- Traffic engineered tunnels with state at ingress LER only
- stateless TE LSR nodes
- Distributed or node-level TE for resilience: admin-group, SRLG support
- External TE Controller with Resource Discovery for more advanced TE
Alcatel-Lucent will introduce Segment Routing in SR-OS 13.0
- Addressing RLFA/DLFA for IP-FRR/LDP-FRR coverage improvement
- Allow MPLS-less operation if required by the use-case
- Flexible path setup in combination with Offline TE tools

59
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SEGMENT ROUTING SROS
13.0
CONTROL/DATA PLANE
Each NE has two type of segments:
Shortest Path
- Nodal segment (N-SID), a single global identifier per NE. Route to N-6
- Adjacency segment (A-SID), one local identifier for each
adjacency. data N-6
data N-6

- Both nodal/adjacency segment signaled in IS-IS data


A-3 A-1
Loose or explicit paths possible A-1 N-2 N-3
A-2

Label stacking (PE needs to be capable of pushing A-1 A-2


A-2 A-3
multiple labels on each data packet)
N-1 N-6
data N-6 data N-6
Adjacency labels useful in specific topologies (ring)
A-2 A-2 A-1
A-2
No specific MPLS protocol, part of IGP A-1
A-3
A-1 N-5 A-3
N-4
Scalable (no state on P-routers) A-1

Easy IPv6 integration data N-6 A-2 N-5


data N-6 A-2 N-5
The Path (ERO) is in the packet, not in the control
Source Route to N-6
plane (like RSVP-TE)

60
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SEGMENT ROUTING SROS
13.0
CONVERGENCE

SR will rely on Directed LFA which is based on LFA/RLFA


100 100
In case of RLFA, when there is no intersection between
A
the (extended) P-space and Q-space, directed Q-node
forwarding will be installed from the P-node towards B F
the adjacent Q-node Directed forwarding,
100 1000 based on adjacency
Directed LFA principle: segment

- Node segment to P node C E

- Adjacency segment from P to Q D 100 P-node


100
Compared to remote-LFA, directed LFA:
- Does not require T-LDP sessions
- Improves coverage (see example)
This is an example directed LFA (which would fail in case of RLFA):
1. SPF 1: P-space contains D and E. F is not part of (extended) P-
space due to the high metric between E and F.
DLFA offers a better coverage compared to RLFA
2. SPF 2: reverse SPF results in A and F as Q-space
3. Node segment to E, adjacency segment to F
61
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
SEGMENT ROUTING LDP RSVP SR
SUMMARY Overview Multipoint to point Point to point Multipoint to point

Operation Simple LSP per destination/ Simple


Agreement to be held on the TE-path
protocol semantics between Dependencies Relies on IGP Relies on IGP TE Relies on IGP +
vendors offline TE
LBL allocation Local significant per Local significant per Global
Multicast to be sorted node (interface) node (interface)

LBL stack depth concerns to be Traffic Engineering No Yes yes


analyzed with respect to TE
Scaling 1 LBL per node Nx(N-1) 1 LBL per node/
(interface) local interface
TE protocol functionality to be
worked out with respect to: Fast Reroute LFA, LFA Policies, Link/Node protection LFA, LFA Policies,
RLFA - <100% (detour/facility) RLFA/DLFA - can get
- Topology discovery coverage 100% coverage to 100% coverage
(better than LDP
- TE path placement with RLFA)
- Service/Flow mapping Multicast mLDP P2MP RSVP TBD
- Path statistics collection
IPv6 Extensions required Extensions required Native

62
COPYRIGHT 2013 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION