old dog consulting should i migrate my mpls-te network to gmpls? and if so, how? adrian farrel old...

Old Dog Consulting

www.mpls2008.com

Should I Migrate My MPLS-TE Network to GMPLS?

And if so, how? Adrian Farrel

Old Dog [email protected]

2 Old Dog Consulting

Questions, Only Questions

What is MPLS-TE? What is GMPLS? How does GMPLS differ from MPLS-TE? How and why are protocols extended? How do we achieve interoperability? Why should we migrate and not extend? What are the strategies for migration? What should happen next?


MPLS-TE

Traffic engineering in MPLS packet networks Place traffic to optimize network use Reserve resources to guarantee QoS Establish LSPs for protection and restoration

Need to know what network resources are available Additions to IGP routing protocols (IS-IS and OSPF) Distributes bandwidth availability with link state

Need to compute routes for LSPs NMS, ingress LSR, or PCE

Need to signal for LSP establishment RSVP-TE


GMPLS

Origins lie in control of WDM systems MPλS Labels are re-invented and wavelengths Resources are implicit

Now extended to cover a variety of technologies Fiber/port switching Lambda switching (WDM, G.709 OTN) Timeslot switching (TDM) Layer 2 switching (Ethernet, ATM, Frame Relay, PBB) Packet switching (MPLS, MPLS-TP)

A set of protocols (IS-IS, OSPF, RSVP-TE, LMP) To distribute information about links and resources To establish LSPs To test and exchange information about data links


How Different is GMPLS?

GMPLS has become linked to optical networking …the term ASON (Automatically Switched Optical Network)

and is often used interchangeably with GMPLS… www.wikipedia.org

GMPLS protocols are designed to handle a variety of networking technologies Optical networks are just one such technology MPLS data planes are another

MPLS is a data plane technology and control plane protocols

GMPLS can control an MPLS data network The base protocols are the same

Routing protocols (IS-IS and OSPF) Signaling protocol (RSVP-TE) GMPLS is safe

Based on well-proven MPLS-TE Good experiences in non-packet networks


What Can GMPLS Do that MPLS-TE Can’t?

Separate control channel from data channel MPLS-TE assumes that the control traffic flows in the

same link as the data traffic Implications for link identification in the control

protocols Implication for link failure scenarios

GMPLS disassociates the control and data channels Supports many different technologies Don’t need routing adjacency between ends of data

links Scaling benefits in the control plane Need additional link identifiers Need to handle control and data channel failures

separately


What Else Can GMPLS do?

Bidirectional LSPs Single signaling exchange establishes symmetrical LSP

Link-level protection Advertise and use protection capabilities of links

Priority-based bandwidth Leverage set-up priority with bandwidth pools

Packet-centric link parameters Minimum LSP bandwidth MTU

SRLGs Integrated multi-layer networking

Becoming increasingly important in “packet optical networks”


Differences in Routing Protocols

MPLS-TE uses a top-level information element for the TE information in the routing protocol Extended IS reachability TLV in IS-IS Opaque TE LSA in OSPF MPLS-TE information is carried in sub-TLVs

GMPLS introduces new sub-TLVs for additional information Link local identifiers (because TE link is not control

channel) Link protection capabilities Priority-based bandwidth pools Interface switching capabilities Minimum LSP size and MTU


What Happens if I Mix MPLS-TE and GMPLS Routing?

MPLS nodes will: Generate only MPLS-TE information Receive GMPLS information and re-flood it Receive GMPLS information and not use it See all nodes in the network as if MPLS-TE

capable GMPLS nodes will:

Generate only GMPLS information Receive MPLS-TE information and re-flood it Perceive MPLS-TE nodes as sending deficient

information


Differences in Signaling Protocols

Changes in most basic label processing Label request (mandatory on Path)

MPLS-TE Label Request (C-Num = 19, C-Type = 1) Generalized Label Request (C-Num = 19, C-Type = 4)

Label (mandatory on Resv) MPLS-TE Label (C-Num = 16, C-Type = 1) Generalized Label (C-Num = 16, C-Type = 2)

This is the fundamental distinguisher Many new protocol objects in RSVP-TE

New objects are optional for inclusion but must be processed

Some new C-Types of existing objects Only expected if Generalized Label Request is used

Many new protocol procedures


What Happens if I Mix MPLS-TE and GMPLS Signaling?

MPLS nodes will: Generate only MPLS-TE messages Receive GMPLS messages and reject them

They carry unknown objects Fail to set up LSPs with adjacent GMPLS nodes

GMPLS nodes will: Generate only GMPLS messages Receive MPLS-TE messages and reject them

They carry the wrong label-request/label objects Fail to set up LSPs with adjacent GMPLS nodes


Feature CreepThe Risks of Protocol Extension

How do we pull GMPLS features into our MPLS-TE network? Vendors are looking to add value Providers demand features in RFQs

Vendors look for “quick fixes” in response Result is MPLS-TE with some bolt-on features

Features are usually taken from GMPLS RFCs Sometimes the wheel gets reinvented

Different vendors pick up different features Interoperability may be compromised

Over time the mix of features becomes complicated Networks become hard to build and operate

My conclusionIf we want the function of GMPLS we should use GMPLS


How to Achieve Interoperability

Important to agree interoperability is required Fundamental to the success of the Internet

Interoperability requires implementation of open standards

Protocol extensions will always be needed Must be backward compatible

Where backward compatibility is broken we must migrate Migration strategy must be agreed

It is an element of interoperability


Strategies For Migration

Explored by CCAMP working group of the IETF RFC 5145

Framework for MPLS-TE to GMPLS Migration Interworking through gateways

Protocol translation Controlled feature creep

“Agreed” introduction of protocol objects Interworking through overlays

Network layers to separate protocol stacks Integrated MPLS and GMPLS function

Dual-capability nodes within MPLS-TE networks


MPLS-TE / GMPLS Gateways

Known as the Interworking Model or Island Model Islands of MPLS-TE nodes and GMPLS nodes

Interaction through Gateway nodes Responsible for “mapping” protocol elements

Routing gateway Does not need to strip GMPLS info

Doing so would cause problems when flooding back into GMPLS network Cannot create GMPLS info

GMPLS network will not see MPLS network “correctly” Signaling

LSPs initiated in MPLS network can be mapped OK LSPs initiated in GMPLS network might not be possible (e.g. bidirectional)

How to position gateways? In the extreme, every other node is a gateway!

MPLSGMPLS


Controlled Feature Creep

Known as the Phased Model Vendors introduce new GMPLS features into their MPLS-TE

products Operators deploy new function as they need it

This is the default way we are operating today It is very risky!

Will vendors add features as backward compatible? Are operators required to upgrade the whole network?

Will all vendors add the same features in the same way? Will interoperability be compromised? Will the feature genuinely be available if only some

nodes support it? An understandable approach in response to an RFQ

Reactive design is never the best


Overlay Networks

GMPLS is good at overlay networks RFC 5212 GMPLS-based Multi-Layer Networks RFC 5146 Support of MPLS-TE over GMPLS Networks

Augmented model has dual-capability border nodes LSP across GMPLS network provide virtual links in the MPLS-TE

network GMPLS islands introduced in the MPLS-TE sea

MPLS-to-MPLS LSPs are supported LSPs within the GMPLS island are supported

As migration progresses we have MPLS puddles in a GMPLS continent

Can’t do GMPLS over MPLS-TE overlay Can’t do MPLS-to-GMPLS LSPs (requires translation)

MPLS

GMPLS


Integrated MPLS-TE and GMPLS Networks

Network nodes are either MPLS-TE only (legacy nodes) Dual capable MPLS-TE and GMPLS nodes (new nodes)

Routing Legacy advertises MPLS-TE New advertises GMPLS RFC 5073 : Advertise signaling capabilities

Path computation looks for consistent paths Default is MPLS-TE GMPLS is used if a path can be found

Signaling Depends on path selected

Allows piecemeal migration Add new dual capability nodes Upgrade MPLS-TE nodes When all nodes are GMPLS-capable, turn off MPLS-TE


Why is Now a Good Time?

MPLS-TE deployments have proven the concept of traffic engineering in MPLS networks

There is a drive towards operating MPLS-TE as a transport environment cf. MPLS-TP (T-MPLS) Requires advanced functions

Control/data separation Bidirectional services Advanced protection and recovery

GMPLS was developed specifically for transport Migration will take time

Start now!


What Should Be Done and Who Should Do It?

Select a migration strategy IETF recommends Integrated Networks model This appears to be the safest and most flexible solution

Get vendors to implement New shipments need to be dual capability nodes

MPLS-TE shipments are still OK, but don’t progress toward migration

Implementation is a relatively small step Incremental on the MPLS-TE codebase

Leverage on vendors is the operator’s RFI Ask for about GMPLS features with interoperability Ask about vendor’s migration strategy


Conclusion

GMPLS offers advanced MPLS-TE functions Highly desirable as MPLS-TE becomes more

transport-oriented Need smooth way to introduce GMPLS into

deployed MPLS-TE networks The industry must agree a migration model if

interoperability is to be guaranteed The Integrated Model provides the easiest

migration Vendors need to implement and ship

Vendors who implement first may gain an advantage


Questions

[email protected]

old dog consulting should i migrate my mpls-te network to gmpls? and if so, how? adrian farrel old...

Documents