IETF87 - STATUS BoF: Performance Engineered LSPs
0 likes621 views
This document discusses the need for performance engineered label switched paths (LSPs) in IP/MPLS networks to meet service requirements. It notes that not all services have the same routing constraints as the shortest path tree. The document proposes using segment routing to create data plane paths without mid-point state. It suggests reusing existing CSPF and PCE functions to calculate and signal paths according to constraints like affinity, diversity or latency requirements on a per-service basis.
IETF87 - STATUS BoF: Performance Engineered LSPs
- 1. STATUS Use Case: Performance Engineered LSPs. Rob Shakir, E2E Network Architect, BT. STATUS BoF, IETF 87. July 29, 2013.
- 2. © BriHsh TelecommunicaHons plc Slide 2 Key Requirement. Create LSPs within an IP/MPLS infrastructure which: • Are routed away from the SPT based on performance constraints (affinity, latency, SRLG etc.). • Or based on coupling with other LSPs within the network (e.g., for diversity or bidirecHonality). • Provide adequate scale to support per-‐service or per-‐flow constraints. • Are routed according to distributed CSPF or centrally based on service requirements.
- 3. © BriHsh TelecommunicaHons plc Slide 3 Background – What’s the problem we’re trying to address? • In IP/MPLS networks, we have a concept of one “base” topology – which is the SPT. • One set of logic applied to choose IGP costs – used to route all services within this topology. • Problem for a core network suppor:ng mul:ple services: Not all services have the same logic as to the constraints for their rouHng through the infrastructure. Co-‐rou:ng service placement based on consideraHon of other services within the network. Pinned paths where services are constrained based on underlying path resources. • How do we meet the requirement for such constraints? - Transport networks have generally provided such constrained paths. - More applicaHons requiring performance guarantees. - For all traffic (e.g., Broadcast). - A subset (e.g., voice within a mulH-‐service VPN). Problem: Provide means to introduce rouHng constraints which diverge from the SPT on a per-‐service or per-‐ flow basis, uHlising the exisHng underlying IP/MPLS network infrastructure.
- 4. © BriHsh TelecommunicaHons plc Slide 4 Path Constraints and Technology Options. • Per-‐service/flow rou:ng requires a significant increase in the number of RSVP-‐TE LSPs when compared to current deployments: - Number of LSPs is greater than full mesh (already not recommended). - Scale limit of mid-‐point signalling during large failures. • Limited addi:onal func:onality is offered by having mid-‐point state. - Generally only admission control. - Required in a subset of path rouHng scenarios. Mid-‐point Overloading – Post-‐Mortem Model Unbounded RSVP-‐TE queue growth based on inability to process PATH messages within LSP retry Hme – LSPs never successfully re-‐signal. • Requirement for a number of types of constrained service/flow rou:ng: - Co-‐rouHng. - Considering SRLG/Node/Link diversity or bi-‐direcHonal paths. - Affinity-‐based rouHng. - Diverging from SPT based on constraining available paths by colour/admin-‐group. - Performance-‐managed services. - Latency, available bandwidth, etc. • Clearly, a number of these constraints can be delivered by RSVP-‐TE today.
- 5. © BriHsh TelecommunicaHons plc Slide 5 Suggested Architecture. • Use segment rou:ng (STATUS approach) to provide means to instan:ate the data-‐plane paths. - Removes constraint of number of LSPs that can be created by removing mid-‐point state. - Stacked labels indicate the path to be taken through the network. - Some consideraHon of per-‐label semanHcs may be required (parHcularly for reversion). • Re-‐use exis:ng CSPF machinery where it is applicable. - Distributed path calculaHon based on IGP or TED influences selecHon (e.g., affinity etc.) - Extended IGP afributes can provide increased CSPF-‐funcHonality. - dra$-‐previdi-‐isis-‐te-‐metric-‐extensions-‐03 - dra$-‐ie4-‐ospf-‐te-‐metric-‐extensions-‐04 • Re-‐use exis:ng PCE to provide SID stacks where global visibility is required. - Co-‐computaHon of coupled services (bidirecHonal, diverse with divergent head-‐ends). - Stateful PCE can provide admission control where required. - Only maintain state for the subset of services where it is required. • Use case described in more detail in dra$-‐shakir-‐rtgwg-‐sr-‐performance-‐engineered-‐lsps. • Encourage swig progress towards standardised soluHons to meet these requirements. - Extend IETF technologies to meet an IP/MPLS funcHonality gap. - ExisHng WGs provide a good forum with experts in each domain.
- 6. © BriHsh TelecommunicaHons plc Slide 6 Thanks! Questions/Comments?