Service Chaining using MPLS Source Routing draftxumplsservicechaining00 Xiaohu

  • Slides: 7
Download presentation
Service Chaining using MPLS Source Routing draft-xu-mpls-service-chaining-00 Xiaohu Xu & Stewart Bryant (Huawei) Hamid

Service Chaining using MPLS Source Routing draft-xu-mpls-service-chaining-00 Xiaohu Xu & Stewart Bryant (Huawei) Hamid Assarpour (Broadcom) Himanshu Shah (Ciena) Luis M. Contreras (Telefonica I+D) Daniel Bernier (Bell Canada)

Introduction • Service Function Chaining steers a packet through an ordered set of Service

Introduction • Service Function Chaining steers a packet through an ordered set of Service Functions. • At ingress a classifier selects the Service Function Path and prepends this path to the packet. • There is great similarity between this operation and the use of source routed tunnels as developed in SPRING. • In this draft we show the source routing approach using stacked MPLS labels developed for SPRING may be used to implement an SFC path. • This is method is a “Transport-Derived SFF” (Section 4. 3. 1 of [RFC 7665] )

Encoding SFP as a Label Stack • SFFs are MPLS Segment Routing Nodes •

Encoding SFP as a Label Stack • SFFs are MPLS Segment Routing Nodes • Advertise Nodal SIDs for themselves (NSID) • Advertise local label for each attached Service function (SF SID) • Classifier imposes label stack comprising ordered set of NSID and SF SID on packet. • LSRs forward to SFF using Nodal (or Adjacency) SIDs, SFF directs packet to Service Function based on SF SID • This approach is suitable as replacement for any “traditional” i. e. hard -wired service function chain. • No change to data-plane required.

The Passage of a Packet SR/SFC Domain Packet to Z SC SID: 101 SID:

The Passage of a Packet SR/SFC Domain Packet to Z SC SID: 101 SID: 102 SID: 103 SF 2 SF 1 Z 1001 The packet is selected to travel through an SFP {SFF 1 ->SFF 2>SF 3}. 101 1002 103 Packet to Z SFF 2 SFF 1 SID: 1001 1002 103 Packet to Z SID: 1002 Packet to Z

IP Connectivity • Where connectivity is fully or partially IP, then one of a

IP Connectivity • Where connectivity is fully or partially IP, then one of a number of MPLS over IP tunnels can be used to interconnect SFFs: • RFC 4023 (MPLS/IP or MPLS/GRE) • RFC 7510 (MPLS/UDP) • RFC 4817 (MPLS/L 2 TPv 3) • Since the underlay can be IPv 4, IPv 6 or MPLS the solution is transport independent

Packet of a Packet in an IP Backbone SR/SFC Domain Packet to Z SC

Packet of a Packet in an IP Backbone SR/SFC Domain Packet to Z SC IP (SC->SFF 1) The packet is selected to travel through an SFC {SF 1, SF 3}. SID: 101 SID: 102 SID: 103 SF 1 SF 2 SF 3 Z 1001 1002 103 SFF 1 SID: 1001 Packet to Z SFF 2 IP (SFF 1 ->SFF 2) 1002 103 This label would be striped if it’s a PHP label. Packet to Z SID: 1002 This label would be striped if it’s a PHP label.

Next Steps • We think this is an interesting approach that allows the majority

Next Steps • We think this is an interesting approach that allows the majority of the SFC functionality to be instantiated using existing h/w. We would appreciate comments and contributions to the work. • We next need to look at the signalling. • Which WGs needs to progress this?