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

2. 2IMIC, 8/30/99 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”) Flow with BW, Delay, Loss & Policy Requirements Link with bw, delay, loss properties Network with bw, delay, loss properties Inter-domain routing policies Source Dest

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

4. 4IMIC, 8/30/99 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 LSP 1 LSP 2 LSP 3 Microflows within an LSP Routing constraints: Resource requirement Priority & Preemption Policy Resiliency requirement Re-optimization of routing

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

6. 6IMIC, 8/30/99 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 SLA1 SLA2 SLA3 SLA4 SP1 SP2 source dest 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.

7. 7IMIC, 8/30/99 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 SLA1 SLA2 SLA3 SLA4 SP1 SP2 source Virtual Trunks

8. 8IMIC, 8/30/99 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: ??

9. 9IMIC, 8/30/99 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.

10. 10IMIC, 8/30/99 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 Flood Resource LSAs New route computation proc. New update procedures New resource tracking proc. (only bw defined so far) Existing DB representation Only single area considered Area 1 Area 2

11. 11IMIC, 8/30/99 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 Proprietary Flooding Area 1 Area 2

12. 12IMIC, 8/30/99 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 Topology Mapping & Interface Functions Intra-domain LS ProtocolLS Database To Peers

13. 13IMIC, 8/30/99 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 Pt-to-Pt or broadcast link Router To nodes E-I A BC D To nodes J-M To nodes N-Q To nodes R-W A: Mcast updates from E-I, request sync. B: Unicast updates from J-M C: Unicast updates from N-Q Network and MST CBR sync. on a LAN

14. 14IMIC, 8/30/99 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 2 Backbone Area Area 1 Area 2 Backbone Area

15. 15IMIC, 8/30/99 Route Computation