Failover for Service Function Chaining
draft-kang-sfc-failover-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | th.kang@kt.com , Sungsu Kim , EunKyoung Paik | ||
| Last updated | 2015-04-30 (Latest revision 2014-10-27) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
In SFC-enabled domain, failures can occur at Service Function(SF). If the failed node is on the path where a packet is delivered, packet cannot be sent to destination and such situation should be avoided. Currently, there are many ways to provide redundancy of SFs, such as VRRP. However, legacy redundancy method may not be used in SFC as Service Function Forwarders(SFFs) do not use IP or MAC address in their FIBs. In SFC, traffic is steered based on Service Function Path ID and Service Index. Therefore controller, which is responsible for a control plane function in SFC, can manage path of SFC. In this document, we illustrate failover method specifically for SFC which uses SFC encapsulation. We describe bypass mechanism to avoid failures in SFs and redirect traffic to backup SFs. For bypass mechanism, we propose SF classification of 1)mandatory SFs that function indispensible for packet delivery, such as NAT and 2)optional SFs that a packet can be delivered without them, such as Firewall and IDS.
Authors
th.kang@kt.com
Sungsu Kim
EunKyoung Paik
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)