MPLS Architecture and the Transport ProfilesLOA ANDERSSON MPLS WG CO-CHAIR

MPLS World CongressParisFEB 09, 2010

There is a mirage…

› We even spend conferences to talk about this mirage› The mirage is called “MPLS-TP”

– We have been way to successful in selling the TP-acronym

› The messengers tells us about the mirage– They bring us two very different messages

© Ericsson AB 2010

© Ericsson AB 2010

Splitting MPLS!

Splitting MPLS is not on the agenda!

› That is what the JWT decision is about› IETF is still the design authority for MPLS› we will make sure that the MPLS architecture says intact

© Ericsson AB 2010

The Emperor’s New Clothes

› Where is nothing new about MPLS-TP!

© Ericsson AB 2010

Emperor’s new clothes - II

› The “nothing new” statement is also wrong– A good and useful set of transport requirements– A set of enhancements to MPLS OAM– New signaling capabilities (GACH and DCN)

© Ericsson AB 2010

What is the MPLS-TP project adding TO MPLS?› Features to permit MPLS to assume a role in “packet

transport”› Enhancements to the IETF suite of MPLS OAM tools

– BFD, LSP-Ping– Functions for enhanced Fault Management , Alarm Management,

Performance Monitoring– Functions to enhance dataplane resiliency AIS/LOCK etc.

› Enhancements to the MPLS signalling for transport connections

– GMPLS› Bi-directional path setup› Optional out of band control plane› OAM configurationThese features are enhancements to existing protocols

They add value across the MPLS architecture, not just for the transport application

What is it all about!

MPLS

transport requirements

75 % down25% to go

© Ericsson AB 2010

MPLS The TransportProfile(s) of MPLS

© Ericsson AB 2010

the Venn DiagramHow the MPLS-TP features fit into the MPLS World

TP project adds to MPLS.It is NOT a distinct technology.

Features developed

by the MPLS-TPproject

Colored Glasses…

One problem, one hammer, one nail!

… gives a strange view!

© Ericsson AB 2010

Alternative View - I

MPLS

MPLSMPLS

© Ericsson AB 2010

A busy crowd

© Ericsson AB 2010

MPLS

Multicast

Preemption

GMPLS for PacketSecurityCP Extensions

TP Project

LDP Upgrade

Upstream Labels

A few words on terminology…

› What is a profile?– The MPLS-TP project got it wrong– Differs to much from earlier use of the term

› A profile (as traditionally used)– An exhaustive list of functions that creates a coherent and

testable system (sometimes RFC, sometimes pointing at sections and paragraphs in RFC)

› The Transport Profile on MPLS is bag of goodies– Now goodies are good to have, but need to organized

› We have a few earlier attempts to create MPLS profiles– I’ve written one and Eric Rosen another– Both long dead

© Ericsson AB 2010

The Transport Profiles

› Three possible profiles Transport Profiles of MPLS– Data plane driven– Off line path computation– The full GMPLS control plane for packet networks

› Similarities and Differences– All three profiles have the same data plane behavior– They scale differently– The operational behavior is different

© Ericsson AB 2010

The MPLS Architecture keeps it all together

© Ericsson AB 2010

MPLS

Multicast

Preemption

GMPLS for Packet

SecurityCP Extensions

TP Project

LDP Upgrade

Upstream Labels

MPLS

Architecture and Profiles – Data plane driven

© Ericsson AB 2010

MPLS

Multicast

Preemption

GMPLS for Packet

SecurityCP Extensions

TP Project

LDP Upgrade

Upstream Labels

MPLS

Architecture and Profiles – Off line Path Computation

© Ericsson AB 2010

MPLS

Multicast

Preemption

GMPLS for Packet

SecurityCP Extensions

TP Project

LDP Upgrade

Upstream Labels

MPLS

Architecture and Profiles – GMPLS for Packet Networks

© Ericsson AB 2010

MPLS

Multicast

Preemption

GMPLS for Packet

SecurityCP Extensions

TP Project

LDP Upgrade

Upstream Labels

MPLS

What is the state of the MPLS-TP Project

› We are making progress– “All” RFCs are identified– All documents published at least as individual Internet Drafts– The critical documents are working groups drafts– Most documents needed for implementation are stable

› We have quite a potential for improvement– IETF and ITU-T cooperation is not easy

› We are solving issues as we go along (reviews, liaisons, managers team)

– New check point in April› The first set of Recommendations have dependencies to a

defined set IETF documents (IETF need to deliver)– Second Check point in June

› ITU-T Recommendations for consent© Ericsson AB 2010

MPLS

An Open Question!

© Ericsson AB 2010

MPLS Full MPLSMPLS++ NG-MPLS MPLSv2

End of presentations

› Thank you!› Questions?

© Ericsson AB 2010