Constraint-Based Unicast and Multicast: Practical Issues

1. Constraint-Based Unicast and Multicast:Practical Issues Bala Rajagopalan NEC C&C Research Labs Princeton, NJ braja@ccrl.nj.nec.com IMIC, 8/30/99

2. What is Constraint-Based Routing? • Includes QoS-based routing and policy routing • New jargon to establish technical territory • Devised in the context of MPLS LSPs, but applies to microflows also (generically, “flows”) Link with bw, delay, loss properties Dest Source Flow with BW, Delay, Loss & Policy Requirements Inter-domain routing policies Network with bw, delay, loss properties IMIC, 8/30/99

3. A Methodology for IP Network Design • Constraint-based routing capability results in efficient design and resource utilization Scheduling & Buffering Scheme Node-Pair Traffic Demands & Initial Topology Traffic Flow on Links Network Topology & Routing Link Capacity Determination Flow Routing Topology Optimization IMIC, 8/30/99

4. Traffic Engineering and Constraint Based Routing • Current TE goal is to map traffic onto the network such that available resources are utilized efficiently and QoS requirements of traffic is satisfied • MPLS LSPs are envisioned for creating virtual trunks that carry traffic between node pairs (equivalent of frame-relay or ATM PVCs). LSPs isolate resources for different flow aggregates • Routing constraints: • Resource requirement • Priority & Preemption • Policy • Resiliency requirement • Re-optimization of routing LSP 1 LSP 2 Microflows within an LSP LSP 3 IMIC, 8/30/99

5. Service Models (1) : VPN • Customer provides point-to-point demands and QoS requirements • Service provider capacity engineers and establishes virtual trunks (LSPs) Internet SP Network Virtual Trunk IMIC, 8/30/99

6. Service Model (2) : Diffserv • Service provider establishes SLAs with customers • SLAs indicate service quality based on traffic parameters • SLAs need not require customer specification of traffic matrix • Network design is difficult dest SLA3 SLA4 Traffic from source to dest must receive treatment as per SLA1, even though it goes through a foreign SP. Also, dest may not be known apriori. SLA1 SP2 SP1 source SLA2 IMIC, 8/30/99

7. SLA3 SP1 SP2 SLA4 SLA1 source SLA2 Virtual Trunks Traffic Engineering for Diffserv • In principle: • Derive point-to-point demands from SLAs and traffic measurements • Determine virtual trunking requirements between node pairs • Establish trunks using CBR dest IMIC, 8/30/99

8. Constraint-Based Routing Model in Summary • Given: Network topology, resource availability, policy and other attributes of nodes and links • Flows: Aggregated microflows or virtual trunks • Dynamism: Keep track of network state changes; dynamic rerouting of flows after topological changes; redundant paths and load-balancing? • Routing architecture: Distributed • Route computation: Based on apriori notions of optimization of resource usage, traffic parameters, routing metrics, etc. • Route computation trigger: By operator using offline mechanisms • Route maintenance: Based on specified policies • Multicast: ?? IMIC, 8/30/99

9. Practical Issues • Scalability: No experience with large-scale state-dependent routing in the Internet; current proposals limited to intradomain flat networks • Interdomain Routing: State transfer between domains for CBR? • Flexibility in Routing: CBR, being a tool for optimization, invites proprietary solutions. How to accommodate a plurality of solutions? • Multicast: What is the model? • Static trees, computed centrally • Dynamic trees on a per-group basis? • Integration within a service management framework: Defining the interfaces to capacity management, provisioning, and offline network analysis. IMIC, 8/30/99

10. CBR Approach 1: IGP Extensions (e.g., OSPF) • Add CBR features to existing IGP s.t. changes are minimal • Some IGPs provide mechanisms for adding new messages, e.g., OSPF transparent LSAs Area 1 Area 2 New route computation proc. New update procedures New resource tracking proc. (only bw defined so far) Existing DB representation Only single area considered Flood Resource LSAs IMIC, 8/30/99

11. CBR Approach 2: Proprietary Protocols • Proprietary message formats, update protocols, hierarchy arrangements, database representation, etc. • Proprietary CBR features: Flow definition, priority, preemption, rerouting features, etc. • Requires homogeneous equipment Area 2 Proprietary Flooding Area 1 IMIC, 8/30/99

12. CBR Approach 3: Distributed Overlay • Utilize underlying IGP (DV or link state) for reachability computations • Efficient update propagation techniques for scalability (facilitates dynamic routing) • IGP-independent state representation • State aggregation for hierarchical routing possible • Metric values not constrained by IGP limitations • Requires only the definition of a standard interface between IGPs and CBR protocols, to be implemented locally CBR Protocol CBR Database To Peers Topology Mapping & Interface Functions To Peers Intra-domain LS Protocol LS Database IMIC, 8/30/99

13. CBR Overlay: Essential Ideas • CBR protocol utilizes underlying IGP for building an MST of the topology (MST based on administrative link cost) • State information broadcast on the MST • State information synchronized and maintained as MST changes • Requires interface function to indicate topology change To nodes E-I A: Mcast updates from E-I, request sync. B: Unicast updates from J-M C: Unicast updates from N-Q A Pt-to-Pt or broadcast link To nodes N-Q Router B C To nodes J-M D To nodes R-W Network and MST CBR sync. on a LAN IMIC, 8/30/99

14. CBR Overlay on OSPF • Hierarchical MST construction; one for each area and one for the backbone • CBR topology database generated from OSPF database using interface functions • Independent representation of network state, including summary state for external areas • Updates sent on backbone MST are propagated on area MSTs Area 1 Area 1 Backbone Area Backbone Area Area 2 Area 2 IMIC, 8/30/99

15. Route Computation IMIC, 8/30/99