1. MPLS Architecture and the
Transport Profiles
LOA ANDERSSON MPLS WG CO-CHAIR
MPLS World Congress
Paris
FEB 09, 2010

2. 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

3. © Ericsson AB 2010
Splitting MPLS!

4. 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

5. The Emperor’s New Clothes
› Where is nothing new about MPLS-TP!
© Ericsson AB 2010

6. 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

7. 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 configuration
These features are enhancements to existing protocols
They add value across the MPLS architecture, not just for the
transport application

8. What is it all about!
MPLS
transport requirements
75 % down25% to go
© Ericsson AB 2010

9. MPLS The Transport
Profile(s) of MPLS
© Ericsson AB 2010
the Venn Diagram
How 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-TP
project

10. Colored Glasses…
One problem, one hammer, one nail!
… gives a strange view!
© Ericsson AB 2010

11. Alternative View - I
MPLS
MPLS
MPLS
© Ericsson AB 2010

12. A busy crowd
© Ericsson AB 2010
MPLS
Multicast
Preemption
GMPLS for Packet
SecurityCP Extensions
TP Project
LDP Upgrade
Upstream Labels

13. 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

14. 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

15. 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

16. Architecture and Profiles – Data plane driven
© Ericsson AB 2010
MPLS
Multicast
Preemption
GMPLS for Packet
SecurityCP Extensions
TP Project
LDP Upgrade
Upstream Labels
MPLS

17. 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

18. 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

19. 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

20. MPLS
An Open Question!
© Ericsson AB 2010
MPLS Full MPLSMPLS++NG-MPLSMPLSv2

21. End of presentations
› Thank you!
› Questions?
© Ericsson AB 2010