Reliability Framework for SRv6 Service Function Chaining

SFC Reliability Protection Mechanisms

SFF Redundant Backup Protection Method Deploy primary and backup SFFs for SF. SF is dual-homed connected to both SFFs simultaneously. When the routing between the primary SFF and SF is unreachable or primary SFF fails, the service message is switched to the backup SFF and forwarded to SF via the backup SFF. The following describes the working process of SFF redundant backup protection mechanism based on SF's SRv6 capabilities and SRv6 Proxy behavior.

Static SR Proxy As shown in , SFF1 and SFF2 are two Service Function Forwarders that are backed up to each other. SF is connected to both SFF1 and SFF2.

Firstly, configure SFF1 and SFF2 as follows: Configure the mapping relationship cache entries for the same SRH and interface connecting SF on two SFFs. Two SFFs use the same Locator segment to assign their respective static proxy SID. Two SFFs with the same configuration as the primary static proxy SID and backup static proxy SID. Both specify SFF1 as the primary and SFF2 as the backup. Normally, the Ingress node encapsulates the SRH header and fills the SID list with <E1, E2, D, X1>, indicating that the message is forwarded along the path Ingress->SFF1->SF->SFF1->NodeD->Egress. After receiving the message, SFF1 matches it to the local primary static proxy SID based on the destination address X1 of the message. SFF1 performs the processing of End.AS behavior, removes the IPv6 header and SRH, and sends the original message to SF through the interface corresponding to the service SID. When SFF1 detects that the route from SFF1 to SF is unreachable, it encapsulates a new SRv6 header to the message based on the configured backup SFF. There are two encapsulation options for the SRv6 header: Option 1: With SRH, forward the payload to the backup SFF through the SRv6 TE path. The SRH SID list contains the segment IDs of the nodes that need to be passed through for backup SFF. SID[0] is backup static proxy SID. Option 2: Forward the payload to the backup SFF through the SRv6 BE path. The IPv6 DA is backup static proxy SID. SFF1 searches the routing table and forwards the updated message to SFF2. After receiving the message, if the route from SFF2 to SF is reachable, SFF2 removes the outer SRv6 header, and forwards the payload to SF. If the route from SFF2 to SF is also unreachable, discard the message. For option 1, the encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in .

SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +-----------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=X1 | | DA=C | | DA=D | | DA=E1 | +------------+ +-----------+ +------------+ +------------+ |SRH: | |SRH: | |SRH: | |SRH: | | SL=3, | | SL=1, | | SL=2, | | SL=1, | |(E2,E1,D,X1)| | (X2,C) | |(E2,E1,D,X1)| |(E2,E1,D,X1)| +------------+ +-----------+ +------------+ +------------+ | Payload | | Payload | | Payload | | Payload | +------------+ +-----------+ +------------+ +------------+ ]]> For option 2, the encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in .

SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +-----------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=X1 | | DA=X2 | | DA=D | | DA=E1 | +------------+ +-----------+ +------------+ +------------+ |SRH: | | Payload | |SRH: | |SRH: | | SL=3, | +-----------+ | SL=2, | | SL=1, | |(E2,E1,D,X1)| |(E2,E1,D,X1)| |(E2,E1,D,X1)| +------------+ +------------+ +------------+ | Payload | | Payload | | Payload | +------------+ +------------+ +------------+ ]]>

Dynamic SR Proxy Compared to static SR Proxy, dynamic SR Proxy has the ability to learn mapping relationship cache entries. The mapping relationship cache between SRH and the interface connecting SF is dynamically generated based on the SRH of the messages received by SFF. After enabling SFF redundant backup protection function, when the primary SFF senses that it is unreachable to SF, the SRH are not removed. Instead, SFF1 needs to carry the original SRH to the backup SFF. As shown in , SFF1 and SFF2 are two Service Function Forwarders that are backed up to each other, and SF is connected to both SFF1 and SFF2. Firstly, configure SFF1 and SFF2 as follows: Two SFFs use the same Locator segment to assign their respective dynamic proxy SID. Two SFFs with the same configuration as the primary dynamic proxy SID and backup dynamic proxy SID. Both specify SFF1 as the primary and SFF2 as the backup.

Normally, the Ingress node encapsulates the SRH header and fills the SID list with <E1, E2, D, X1>, indicating that the message is forwarded along the path Ingress->SFF1->SF->SFF1->NodeD->Egress. After receiving the message, SFF1 matches it to the local dynamic proxy SID based on the destination address X1 of the message. SFF1 performs the processing of End.AD behavior, decapsulates the message, removes the IPv6 header and SRH, and sends the payload to SF through the interface corresponding to the service SID. At the same time, SFF1 records the mapping relationship cache between SRH and the interface connecting SF, in order to recover the SRH when the message returns from SF. When SFF1 detects that the route from SFF1 to SF is unreachable, SFF1 does not remove the existing IPv6 header and SRH, and there are two process options for the SRv6 header: Option 1: SFF1 adds another SRv6 header to the message. The SRH SID list contains the segment IDs of the nodes that need to be passed through for backup SFF. SID[0] is backup dynamic proxy SID. Option 2: SFF1 reuses existing IPv6 headers. SFF1 replaces the IPv6 DA to backup dynamic proxy SID. SFF1 searches the routing table and forwards the updated message to SFF2. After the message arrives at SFF2, it is matched to the local backup dynamic proxy SID based on the destination address X2. SFF2 removes the outer IPv6 header(s), sends the payload to SF, and records the mapping relationship cache between SRH and the interface connecting SF. If the route from SFF2 to SF is unreachable, it is considered that both the primary and backup SFFs are unable to process and the message is discarded. For option 1, the encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in .

SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=X1 | | DA=C | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | |SRH: | |SRH: | |SRH: | | SL=3, | | SL=1, | | SL=2, | | SL=1, | |(E2,E1,D,X1)| | (X2,C) | |(E2,E1,D,X1)| |(E2,E1,D,X1)| +------------+ +------------+ +------------+ +------------+ | Payload | |IPv6 Hdr: | | Payload | | Payload | +------------+ | DA=D | +------------+ +------------+ +------------+ |SRH: | | SL=2, | |(E2,E1,D,X1)| +------------+ | Payload | +------------+ ]]> For option 2, the encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in .

SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=X1 | | DA=X2 | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | |SRH: | |SRH: | |SRH: | | SL=3, | | SL=2, | | SL=2, | | SL=1, | |(E2,E1,D,X1)| |(E2,E1,D,X1)| |(E2,E1,D,X1)| |(E2,E1,D,X1)| +------------+ +------------+ +------------+ +------------+ | Payload | | Payload | | Payload | | Payload | +------------+ +------------+ +------------+ +------------+ ]]>

Masquerading SR Proxy SFC masquerading proxy is suitable for scenarios where SF can recognize SRv6 packets but does not support processing SRH. Before forwarding the message to the SF, the masquerading SR proxy first updates SID[0] of Segment list to DA, and then directly forwards the SRv6 message to SF. After SF completes the service processing, it does not process the SRv6 SRH and forwards the message back to SFF. After receiving the message returned from SF, SFF updates DA to SID[SL] of Segment list and continues forwarding. Because the SRH has always been carried in the message without modification, SFF does not need to re encapsulate the SRH after receiving the message returned from SF, and can directly use the SRH inside the message. In the scenario of using masquerading SR proxy, after enabling SFF redundant backup protection function, when the primary SFF senses that the route with SF is unreachable, the primary SFF does not remove the IPv6 header and SRH. Instead, SFF1 needs to carry the SRH to the backup SFF. Taking as an example, the detailed protection processing process is as follows.

Configure SFF1 and SFF2 as follows: Two SFFs use the same Locator segment to assign their respective masquerading proxy SID. Two SFFs with the same configuration as the primary masquerading proxy SID and Backup masquerading proxy SID. Both specify SFF1 as the primary and SFF2 as the backup. Normally, the message is forwarded along the path Ingress->SFF1->SF->SFF1->NodeD->Egress. After receiving the message, SFF1 matches it to the local masquerading proxy SID based on the DA of the message. SFF1 performs the processing of the End.AM behavior, changing DA to SID[0] of Segment list, and then sending the message to SF through the interface connecting to SF. When SFF1 detects that the route from SFF1 to SF is unreachable, there are two options: Option 1: SFF-1 replaces the IPv6 DA with the backup masquerading proxy SID. After the message arrives at SFF2, SFF2 changes the DA to SID[0] of the Segment list, and then sending the message to SF through the interface connecting to SF. Option 2: SFF-1 adds another SRv6 header to the message. The SRH[0] is backup masquerading proxy SID. After the message arrives at SFF2, SFF2 first removes the outer SRv6 header and restores the inner SRv6 message. Then, use the SID[0] of the SRH Segment List as the destination address to send the message to SF. If the route from SFF2 to SF is unreachable, it is considered that both the primary and backup SFFs are unable to process and the message is discarded. For option 1, the encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in .

SRv6-aware SF SF, which supports SRv6 functionality, serves as a SRv6 endpoint node and is arranged on the path of SRv6 Policy forwarding. Its reliability protection mechanism is identical to that of SRv6 endpoint nodes, and no special handling is required in the SFF redundant backup protection mechanism. 3.2. SF Redundant Backup Protection Method There are active and standby SFs in the network, which are connected to the same SFF or different SFFs. SF redundant backup protection method is the process of bypassing the faulty primary SF and continuing to send messages to backup SF for processing. The following describes the working processes of the SF redundant backup protection method based on SF's SRv6 capability and SRv6 Proxy's behavior.

Static SR Proxy As shown in , there is a backup service function node SF2 for primary service function node SF1 in the SFC network. SF1 is connected to SFF1 with a single-homed connection, and SF2 is connected to SFF2 with a single-homed connection. In order to implement the SF redundant backup protection function, it is necessary to enable the SF backup function on SFF1 and configure the bypass proxy connected to the backup SF.

When SFF1 detects that the route from SFF1 to SF1 is unreachable, it encapsulates a new SRv6 header to the message. There are two encapsulation options for the SRv6 header: Option 1: With SRH, forward the payload to the bypass SFF through the SRv6 TE path. The SRH SID list contains the segment IDs of the nodes that need to be passed through for the SFF connecting to the backup SF. SRH[0] is the bypass static proxy SID. Option 2: Forward the payload to the bypass SFF through the SRv6 BE path. The IPv6 DA is bypass static proxy SID. SFF1 searches the routing table and forwards the updated message to SFF2. After receiving the message, SFF2 removes the IPv6 header, and sends the payload to SF2. If the route from SFF2 to SF2 is also unreachable, discard the message. For option 1, the encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in .

SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=B | | DA=C2 | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | | SRH: | |SRH: | |SRH: | | SL=3, | | SL=1, | | SL=2, | | SL=1, | |(E2,E1,D,B) | | (C1,C2) | |(E2,E1,D,B) | |(E2,E1,D,B)| +------------+ +------------+ +------------+ +------------+ | Payload | |IPv6 Hdr: | | Payload | | Payload | +------------+ | DA=D | +------------+ +------------+ +------------+ | SRH: | | SL=2, | |(E2,E1,D,B) | +------------+ | Payload | +------------+ ]]> For option 2, the encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in .

SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=B | | DA=C1 | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | | Payload | |SRH: | |SRH: | | SL=3, | +------------+ | SL=2, | | SL=1, | |(E2,E1,D,B) | |(E2,E1,D,B) | |(E2,E1,D,B)| +------------+ +------------+ +------------+ | Payload | | Payload | | Payload | +------------+ +------------+ +------------+ ]]>

Dynamic SR Proxy Because the dynamic SR proxy needs to dynamically generate a mapping relationship cache with the virtual interface connecting to SF based on the SRH of the message, after enabling SF redundant backup protection function, when the SFF senses that the route with primary SF is unreachable, it cannot remove IPv6 encapsulation. Instead, a new IPv6 header needs to be added outside the IPv6 header, and the original IPv6 packet is sent as a payload to the bypass SFF connecting to the backup SF.

As shown in , there is a backup service function node SF2 for SF1. SF1 is connected to SFF1 with a single-homed connection, and SF2 is connected to SFF2. Enable the SF redundant backup protection function and specify SFF2 as the bypass protection node on SFF1. Configure the bypass dynamic proxy SID corresponding to the backup SF on SFF-2. Normally, the message is forwarded along the path Ingress->SFF1->SF1->SFF1->NodeD->Egress. After receiving the message, SFF1 matches it to the local dynamic proxy SID based on the DA. SFF1 performs the processing of the dynamic proxy behavior, removes the original IPv6 header and SRH, and sends the payload to SF1 through the virtual interface connecting SF1. At the same time, SFF1 records the mapping relationship cache between SRH and the interface connecting SF1. When SFF1 detects that the route from SFF1 to SF1 is unreachable, SFF1 does not remove the existing IPv6 header and SRH, and there are two process options: Option 1: SFF1 adds another SRv6 header to the message. The SRH SID list contains the segment IDs of the nodes that need to be passed through for the SFF connecting to the backup SF. SID[0] is bypass dynamic proxy SID. Option 2: SFF1 reuses existing IPv6 headers. SFF1 replaces the IPv6 DA to bypass dynamic proxy SID. SFF1 looks up the routing table and forwards the encapsulated message to SFF2. After the message arrives at SFF2, it is matched to the local bypass dynamic proxy SID based on the DA. SFF-2 removes the outer IPv6 header(s), sends the payload to SF2, and records the mapping relationship cache between SRH and the virtual interface connecting SF2. If SFF2 to SF2 are also unreachable, discard the message. For option 1, the encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in .

SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=B | | DA=C1 | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | |SRH: | |SRH: | |SRH: | | SL=3, | | SL=2, | | SL=2, | | SL=1, | |(E2,E1,D,B) | |(E2,E1,D,B) | |(E2,E1,D,B) | |(E2,E1,D,B) | +------------+ +------------+ +------------+ +------------+ | Payload | | Payload | | Payload | | Payload | +------------+ +------------+ +------------+ +------------+ ]]>

Masquerading SR Proxy The SF redundant backup protection mechanism of the masquerading SR proxy is basically the same as the SF redundant backup protection method of the dynamic SR proxy, except that the SID of the bypass SFF needs to be with masquerading proxy behavior.

As shown in , when SFF1 detects that it is unreachable from SFF1 to SF1, SFF1 does not remove the existing IPv6 header and SRH, and there are two process options: Option 1: SFF1 adds another SRv6 header to the message. The SID[0] is bypass masquerading proxy SID. After the message arrives at SFF2, SFF2 first removes the outer SRv6 header and restores the inner SRv6 message. Then, use the SID[0] of the SRH Segment List as the destination address to send the message to backup SF. Option 2: SFF-1 replaces the IPv6 DA with the bypass masquerading proxy SID. After the message arrives at SFF2, SFF2 changes the DA to SID[0] of the Segment list, and then sending the message to backup SF through the interface connecting to backup SF. If SFF2 to SF2 are also unreachable, discard the message. For option 1, the encapsulation of messages transmitted between SRv6 nodes from Ingress to Egress is shown in .

SFF1 SFF1->SFF2 SFF2->D D->Egress +------------+ +------------+ +------------+ +------------+ |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | |IPv6 Hdr: | | DA=B | | DA=C1 | | DA=D | | DA=E1 | +------------+ +------------+ +------------+ +------------+ |SRH: | |SRH: | |SRH: | |SRH: | | SL=3, | | SL=2, | | SL=2, | | SL=1, | |(E2,E1,D,B) | |(E2,E1,D,B) | |(E2,E1,D,B) | |(E2,E1,D,B) | +------------+ +------------+ +------------+ +------------+ | Payload | | Payload | | Payload | | Payload | +------------+ +------------+ +------------+ +------------+ ]]>

SFF Bypass forwarding Method The SFF bypass forwarding method is applied to scenarios where backup SFF and backup SF are not deployed for SR Proxy. As shown in , when SFF1 senses an SF fault or the route to SF is unreachable, it skips the service function node and directly forwards packets to downstream nodes.

When SFF senses that SF is unreachable, it does not remove the IPv6 header, changes the destination address of the message to SID[SL], looks up the routing table, and forwards the message.

The Service Flow Affiliation Maintenance Method In the current SFC scenario, SF can be deployed on multiple VMs/containers, so that a VM/container can switch to another one when it is overloaded or failed. There is no specific configuration for SF, so the user's business will be distributed to one of the free VMs/containers randomly according to a set algorithm by the load balancer inside the SF. For some specific users or services, the flow affiliation is to hope that the service flow can always be maintained in a certain VM/container to realize the optimal service, until the current VM/container is overloaded or failed before switching, rather than randomly distributed to different VM/container. Therefore, we need to configure the network device with relevant policies for the VM/container level and implement corresponding processing in the forwarding process to realize the maintenance of flow affiliation and session continuity. For example, we expect to use the VM/container in shared or exclusive mode, or prefer a certain type of VM/container such as GPU. The service chain head node (SC) can determine a target SRv6 policy based on the service of the target user, and the SRv6 policy includes at least one logical device(VM or container) selection indication information corresponding to the target service. The information contains as follows: preferred VM or container and a selection strategy for this, an exclusive mode or a shared mode for the VM/container, and a selection strategy for the second best VM/container in case of failure of the preferred one. According to the target SRv6 policy, an IPv6 message for the service to be transmitted is generated, including the SF SID with the VM/container selection indication information. Then SC sends a SRv6 policy message to the next hop node such as SFF, with the Function field and/or Argument field of the SF SID including said VM/container selection indication information, which can be recorded in the Function flavor parameter or the color attribute of the SRv6 Policy.