Inter-domain TrafficEngineering
Retaining System Autonomy With LSPHierarchies

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

1Oxymoron A phrase in which two contradictory terms arecombined• A deafening silence• A mournful optimist• A tragic comedy

 To some degree, the term “inter-domain trafficengineering” is also an oxymoron

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

2

Inter-Domain Traffic Engineering Traffic engineering a flow that originates on one
routing domain and terminates in another Motivation for separating routing domains• Scaling• Security considerations• Administrative considerations• Fate sharing

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

3Decomposition
 In order to understand inter-domain trafficengineering, we must define the following terms• Traffic engineering• Routing domain

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

4Traffic Engineering An aspect of network engineering concerned withthe performance optimization
 Typically, traffic engineering tools redirect selectedflows from the IGP shortest path onto an alternativepath. Redirecting those flows diverts traffic fromcongested interfaces and distributes traffic acrossavailable interfaces
 Most traffic engineering tools are extensions of therouting subsystem• RSVP-TE, IGP extensions for traffic engineering

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

5Routing Domain
 A group of routers that enforces a common routing
and forwarding policy• Determines which subnets are accessible to which
gateway interfaces• Determines what forwarding behavior is afforded to eachflow• Determines what path a flow will take through the routing
domain Typically, all routers within a routing domain arecontrolled by a single administrative authority

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

6Routing Domain Autonomy
 A peer network can offer traffic, but it cannot
determine the following:• Whether the traffic will be delivered• The QoS that will be afforded to that traffic• The route that traffic will traverse within the autonomous
routing domain Except by mutual agreement• For example, using BGP MEDs

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

7Tension Between Inter-domain Traffic Engineeringand Routing Domain Autonomy
 Peer networks frequently want to optimize end-toend performance for flows that originate in one
network and terminate in another Peer networks rarely want to compromise theirautonomy to the degree required to accomplish thisgoal• Don’t want to share IGP information• Don’t want to merge RSVP signaling domains

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

8LSP Hierarchy Can Resolve This Conflict
 Each peer network configures MPLS LSPs
connecting its Autonomous System Border Routers
to its other edge routers• PSN LSPs

 Each peer network advertises the PSN LSP as aforwarding adjacency into its IGP• Possibly coloring the forwarding adjacency to indicatedthat it is a PSN LSP

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

9LSP Hierarchy (continued)
 Peer network uses RSVP-TE to signal end-to-end
LSP• Possibly constraining end-to-end LSP to traverse onlylinks of a specific color• Possibly constraining end-to-end LSP with other QoS
requirements

 RSVP-TE views each PSN LSP as a hop containwithin the end-to-end LSP On the forwarding plane, end-to-end LSPs arenested within PSN LSPs

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

10Reference Model
End-to-end LSP
PSN LSP

PSN LSPCEPE

ASBR

ASBR

PEAS 1AS 1

AS2AS2

Copyright © 2005 Juniper Networks, Inc.

CE

www.juniper.net

11

Inter-Domain TE is Achieved
 RSVP-TE used to signal end-to-end LSP RSVP-TE treats each PSN LSP as a single hop in
the end-to-end LSP RSVP-TE views the QoS characteristics of each
PSN LSP as the QoS characteristics of a hop
within the end-to-end LSP RSVP-TE determines which ASBRs and PSN
LSP’s the end-to-end will traverse

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

12

Autonomy is maintained One peer cannot influence the path that a PSN
LSP will traverse in another peer’s network
 No need to merge IGP domains
 There is a need to signal end-to-end LSPs acrossrouting domain boundaries, but this can beconstrained with policy• For example, policy may require end-to-end LSP totraverse PSN LSPs

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

13

Other Benefits
 Only PEs and ASBRs need to maintain state
regarding end-to-end LSP• Interior routers in either peer network need not maintainstate regarding end-to-end LSP

 Network events that cause the PSN LSP to rerouteneed not propagate to the end-to-end LSP• So long as PSN LSP restores within required period oftime

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

14

Application
 IP Traffic Engineering• Managing micro-flows between MAN and WAN

 Multi-segment pseudo-wires

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

15

Conclusions
 LSP Hierarchy should be considered as a tool forachieving inter-domain traffic engineering RSVP-TE should be considered as a tool for
signaling LSP hierarchies.

Copyright © 2005 Juniper Networks, Inc.

www.juniper.net

16