Challenges in Traffic Engineered IP networks

1
Challenges in Traffic Engineered IP networks

• Stockholm 2006-02-16Loa Andersson, Acreo
  ABIAB, MPLS WG co-chair

2
The Future

• is not what it used to be, whats more it never
  was!Lee Hayes, the Weavers!
• However, the future is still there and we have
  lots of interesting problems to solve!

3
Det nya router-labbet

• Congratulations!
• hopefully it will be possible to form some
  future common projects between Acreo and the
  router-lab.

4
Service Reference Model
Service
User
SP
Access
Product
ISP(core)
ISP (access)
Traffic exchange
Legend Service is the agreement between
end-user and the Service Provider
(end-2-end) Access is the agreement that exists
between end-user and his ISP, necessary to access
services Traffic Exchange is the agreement
between two ISPs Product is the is the agreement
between a service provide, necessary to deliver
services ISP (access) is the architecture of the
access networks ISP (core) is the architecture of
the core networks
5
Acreo activity areas
Service
User
SP
Access
Product
ISP2(core)
ISP (access)
Traffic exchange
Legend Service is the agreement between
end-user and the Service Provider
(end-2-end) Access is the agreement that exists
between end-user and his ISP, necessary to access
services Traffic Exchange is the agreement
between two ISPs Product is the is the agreement
between a service provide, necessary to deliver
services ISP (access) is the architecture of the
access networks ISP (core) is the architecture of
the core networks
6
Three major focus areas

• Intra-domain Traffic Engineering
• Been there, done that!
• Inter-domain Traffic Engineering
• Service provider politics
• Information sharing / Information hiding
• Inter-layer (multi-layer) control (TE)
• Single control plane several data plane instances?

7
Why Traffic Engineering

• Control, predictability, extendable
• How to place traffic, explicit routes
• Avoiding Congestion and Overload
• Alternate paths
• Protection and restoration
• Effective use of resources
• gt relaxed managers

8
Traffic Engineering
A
10 Mbit/s
30 Mbit/s
30 Mbit/s
10 Mbit/s
B
F
D
E
E
C
10 Mbit/s
H
9
Explicit routes

• Want to use (or avoid) specific resources
• load sharing, back up (recovery) paths,
  measurements, tests

3
Explicit routing
3
3
4
4
routing
10
QoS Constraints

• Constraint based routing

Constraint based routing
routing
20Mbit
11
Pieces of the jigsaw

• Sometimes we need (want) to forward packets along
  different paths than indicated by the SPF
• All applications dont have the same requirement

12
Intra-domain

• Knowledge necessary
• ..., but not enough!
• You need tools!
• There are several possible tools
• but one of them are the 10-year old

13
A few words about MPLS

• Multi-Protocol Label Switching (MPLS)
• An Acronym gone astray!

14
MPLS - one simple paradigm
Link local identifier
LABEL
A packet comes in on one interface and is sent
out on a new interface with a new label attached
LABEL SWAPPING
15
How it works!
LSR
LSR Label Switching Router
16
MPLS basics

• Labels are assigned to match routing the Label
  Distribution Protocol (LDP)
• or
• Labels are assigned to match Traffic Engineering
  needs - the Resource ReserVation
  Protocol-Traffic Enginering (RSVP-TE)

17
Why MPLS?

• BGP free core network
• Overlay networks, becomes peer networks
• Traffic Engineering
• PWE3 tunneling mechanism

18
Why MPLS?

• To be honest
• without 2547 MPLS would have been much less
  succesful
• 2547 is a technology to delivery L3 VPNs over
  MPLS enabled IP networks.
• Once you have MPLS in your network, there are
  several things you might want to do.

19
The Inter-domain dilemma
Oh no I've said too muchI haven't said enough
20
Inter-domain routing TE
21
Several methods

• Trial and horror
• Inter-operator politics and agreements
• Path Computation Element (PCE)

22
Inter-domain Traffic Engineering

• Knowledge necessary
• ..., but not enough!
• You need tools!

And the answer is MPLS and PCE!
23
Multi-layer networks
dynamic
Application
IP
Ethernet
static
WDM
24
The Application world
Application
API
IP
Network Black Box
Ethernet
WDM
25
Multi Layer Networks
Application
MPLS
IP
Ethernet
WDM
26
M P Lambda S

• The label distribution protocols (RSVP-TE),
  could signal a lambda.
• The routing protocols should work for optical
  equipment if we understand to handle ports.

27
Side track

• RFC 3251 Electricity over IP
• a.k.a MPLampS ?

28
MPLambdaS becomes GMPLS

• Once you let the spirit out
• Not only Lambdas, but anythinga switch could
  handle!
• Ports, fibers, groups of fibers, etc.
• This became GMPLS andthe CCAMP working group.
• Spirits are dangerous!

29
The idea abridged
L(n) CP
L(n)
L(n-1) CP
L(n-1)
30
The idea abridged
L(n) CP
L(n)
L(n-1) CP
L(n-1)
FA Forwarding Adjacency
31
The witch brew
IP routing
multi-layer
(G)MPLS
TE
PCE
Inter-Domain
32
Multi-layer data plane
Layer n
Layer n LSP
Layer n-1
Layer n-1 LSP
Layer n-2
Layer n-2 LSP
33
One step control plane
Layer n
Layer n LSP
Layer n-1
Layer n-1 LSP
Layer n-2
Layer n-2 LSP
34
OK but what about Ethernet?

• Ethernet is Eternal
• but ever changing!
• Started as a campus technology
• Today it has entered into provider networks.
• IEEE802.1ad and IEEE802.1ah

35
The GMPLS standards
leaves a big hole concerning Ethernet!
GMPLS controlled Ethernet (gels).
36
Three different interested groups

• Ethernet in the core
• Traffic Engineering (operators)
• Fast configuration
• Ethernet in the access
• Configuration tool
• Research community
• Advanced routing research
• Multilayer networks

37
GELS Requirements

• Status is pretty shaky!
• Too be published soon!
• It seems that the operators are not that
  connected with the vendors when it comes the
  requirements.

38
GELS Framework

• Good news There is a framework that has been
  submitted ?
• Discusses why and how of the GMPLS controlled
  Ethernet

39
IEEE feedback

• Several personal (company) opinions on what the
  IEEE think
• nothing that could be interpreted as
  authoritative yet.

40
Two discussion (I)

• Do we want to do this at all?
• Ethernet dont need a control plane
• Way to complex
• Changes the Ethernet data plane
• Makes my head ache
• Will never work

41
Two discussion (II)

• How do we want to do this?
• Scenarios
• Which label
• Cant change data plane
• What about IEEE?

42
Implementations

• Acreo have 2 implementations
• The first
• New tpid
• 13 bit label
• Linux based and the Dragon project
• Runs on the SwitchCore chip
• Interworks with Transmode XC and Juniper routers
• Wont fulfill the requirtments

43
Implementations

• Acreo have 2 implementations
• The second
• Uses the 802.1Q VID
• 12 bit label
• Linux based and the Dragon project
• Runs on the SwitchCore chip
• Interworks with Transmode XC and Juniper routers

44
Implementation guide
45
Demo-network data-plane (gels)
GMPLS Ethernet LSPs
IP
Linux
SwitchCore
Linux
46
From the research perspective
Control Plane
OSPF-TE
OSPF-TE
OSPF-TE
OSPF-TE
OSPF-TE
RSVP-TE
RSVP-TE
RSVP-TE
RSVP-TE
RSVP-TE
Layer n
Layer n LSP
Ethernet
Data Plane
Ethernet LSP
Layer n-2
Layer n-2 LSP
47
Friends and Foes
48
Challenges in Traffic Engineered networks

• Intra-domain traffic engineering
• Well under way
• The rest is engineering
• Inter-domain traffic engineering
• Technology is understood
• Politics might cause a delay
• Multi-layer routing and traffic engineering
• Breaking area, huge opportunities
• Area in general
• Major Nordic operators took the lead
• Research needs to catch up

49
End of presentation!

• Questions?