Network working group L. Dunbar
Internet Draft A. Malis
Intended status: Standard Track Huawei
Expires: October 2014
April 29, 2014
Framework for Service Function Instances Restoration
draft-dunbar-sfc-fun-instances-restoration-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 30, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dunbar, et al. Expires October 29, 2014 [Page 1]
Internet-Draft SF Instances Restoration Framework April 2014
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This draft describes the framework of protection and restoration of
Service Chain Instance Path when some instances on the path fail or
need to be replaced.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
3. Background.....................................................4
3.1. Multiple Instances of one Service Function................4
3.2. Multiple ways for expressing Service Chain Instance Path..4
3.3. Virtualized Service Function Instances impact to Service
Chain..........................................................6
4. Local Repair of Service Function Instances.....................7
5. Global Repair of Service function instances....................8
6. Regional Repair of Service function instances.................10
7. Conclusion and Recommendation.................................10
8. Manageability Considerations..................................10
9. Security Considerations.......................................10
10. IANA Considerations..........................................10
11. References...................................................11
11.1. Normative References....................................11
11.2. Informative References..................................11
12. Acknowledgments..............................................11
1. Introduction
This draft describes the framework for protection and restoration of
a Service Chain Instance Path when some instances on the path fail
or need to be replaced.
Protection and restoration become more crucial in virtualized
environments (e.g. ETSI NFV), where there is higher chance of
Dunbar, et al. Expires October 29, 2014 [Page 2]
Internet-Draft SF Instances Restoration Framework April 2014
Service function instances failing, being decommissioned or over-
utilized.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Definition of Terms
NFV: Network Function Virtualization [NFV-Terminology].
SF: Service Function [SFC-Problem].
SFF: Service Function Forwarder.
SFIC: Service Function Instance Component. One service function
(e.g. NAT44) could have two different service function
instantiations, one that applies policy-set-A (NAT44-A) and other
that applies policy-set-B (NAT44-B). There could be multiple
"entities" of NAT44-B (e.g. one "entity" only has 10G capability),
and many "entities" of NAT44-B. Each entity has its own unique
address. The "entity" in this context is called "Service Function
Instance Component" (SFIC).
Service Chain: The sequence of service functions, e.g. Chain#1 {s1,
s4, s6}, Chain#2{s4, s7} at functional level. Also see the
definition of "Service Function Chain" in [SFC-Problem].
Service Chain Instance Path: The actual Service Function Instance
Components selected for a service chain.
SFF: Service Function Forwarding Node.
VNF: Virtualized Network Function [NFV-Terminology].
Dunbar, et al. Expires October 29, 2014 [Page 3]
Internet-Draft SF Instances Restoration Framework April 2014
4. Background
4.1. Multiple Instances of one Service Function
One service function (say, NAT44) could have two different service
function instantiations, one that applies to policy-set-A (NAT44-A)
and other that applies to policy-set-B (NAT44-B). There could be
multiple "entities" of NAT44-A (e.g. one "entity" only has 10G
capability), and many "entities" of NAT44-B. Each entity has its own
unique address (or Locator in [SFC-Reduction]). The "Entity" in this
context is called "Service Function Instance Component" (SFIC).
Identical SFICs could be attached to different Service Function
Forwarder (SFF) nodes. It is also possible to have multiple
identical SFICs attached to one Service Function Forwarder (SFF)
node, especially in a Network Function Virtualization (NFV)
environment where each SFIC is a virtual service function instance
with limited capacity.
At the functional level, the order of service functions, e.g.
Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often
which SFIC of the Service Function "s1" is selected for the Chain #1
is not. It is also possible that multiple SFICs of one service
function can be reached by different network nodes. The actual SFIC
selected for a service chain is called "Service Chain Instance
Path".
4.2. Multiple ways for expressing Service Chain Instance Path
How SFICs are selected for a given Service Chain to form the actual
Service Chain Instance Path is outside the scope of this draft. It
is assumed that there is an entity (e.g. service chain orchestration
system) that is responsible for selecting the SFICs for a Service
Chain.
This document focuses on how Service Function Forwarder nodes or
network nodes are informed of the selected SFICs for a particular
Service Chain, especially when there are changes of SFICs on the
Service Chain. To make description easier, the following Service
Chain architecture reference is used:
Dunbar, et al. Expires October 29, 2014 [Page 4]
Internet-Draft SF Instances Restoration Framework April 2014
|1 ----- |n |21 ---- |2m
+---+---+ +---+---+ +-+---+ +--+-----+
| SF#1 | |SF#n | |SF#i1| |SF#im |
| | | | | | | |
+---+---+ +---+---+ +--+--+ +--+--+--+
: : : : :
: : : : :
\ / \ /
+--------------+ +--------+ +---------+
-- >| Chain | | SFF | ------ | SFF | ---->
|classifier | |Node-1 | | Node-i |
+--------------+ +----+---+ +----+--+-+
\ | /
\ | SFC Encapsulation /
\ | /
,. ......................................._
,-' `-.
/ `.
| Network |
`. /
`.__.................................. _,-'
Figure 1 Framework of Service Chain
Some head end Service Chain Classifier can be configured with (or
has the ability to specify) the exact Service Chain Instance Path
for a given service chain. Under this scenario, the exact Service
Chain Instance Path can be expressed by:
- Being encoded in every data packet;
- Being signaled in-band via the data path from the head end
Service Chain Classifier node to all the relevant nodes to
install the appropriate flow steering policies (similar to MPLS
traffic engineering signaling);
- Being sent as out-of-band control messages to all the relevant
nodes to install the appropriate flow steering policies (similar
to GMPLS signaling); or
- Being provisioned into each node by a centralized network
controller (similar to SDN) or by a network management system.
Dunbar, et al. Expires October 29, 2014 [Page 5]
Internet-Draft SF Instances Restoration Framework April 2014
The benefit of encoding the exact path in every data packet is less
contention when there the Service Chain Instance Path changes.
However, there are major drawbacks, such as
- extra packet header fields are needed to carry the exact
instance path, that can increase the likelihood of packet
fragmentation due to MTU size, and
- extra encapsulation processing load at the head end Service
Chain classifier node.
Packet fragmentation and reassembly is very processor and memory
intensive. Good practice is to avoid packet fragmentation and
reassembly as much as possible. Carry an exact instance path in every
packet might be possible if service function instances can be
represented by compact labels, similar to the MPLS label stack.
When the in-band or out-of-band signaling methods are used, i.e.
sending flow steering policies to relevant SFF nodes or network
nodes, the packets associated with a specific flow can be classified
with a simple identifier (or Service Chain ID). Packet size is
smaller and processing at the SC Classifier can be simpler as well.
The out-of-band method doesn't even require the head end Service
Chain Classifier to be configured with, nor has the capability to
specify, the exact Service Chain Instance Path. The out-of-band
steering policies can be sent from an external entity, such as a
centralized network controller or service chain orchestration system.
Under this scenario, it doesn't require the head end Chain Classifier
node to be aware of any change to the instances on the chain.
At times it might not be feasible for the head end Service Chain
Classifier to be aware of the exact instances selected for a given
Service Chain because they are managed by different administrative
entities.
If each Service Function has a large number of SFICs, it scales
better if the Service Chain classifier only identifies the service
chain at the functional level, and there is another entity managing
the detailed service instance path.
4.3. Virtualized Service Function Instances impact to Service Chain
When Service Chain Instance Path consists of virtualized service
function instances, e.g. in an ETSI NFV environment, the likelihood
Dunbar, et al. Expires October 29, 2014 [Page 6]
Internet-Draft SF Instances Restoration Framework April 2014
or frequent changes to the Service Chain Instance Path might be
higher due to:
- Higher failure rate of virtualized service function instances
because most of them will not have build-in protection mechanism
- When some instances are over-utilized, it is relatively easy to
replace them by other instances or instantiate more instances to
take over the work load.
5. Local Restoration of Service Function Instances
When one SF Forwarder (SFF) node has multiple Service Function
Instance Components (SFICs) of the same service function attached,
the SFF can make a local decision on which instance is selected for
a specific service chain.
E.g. In the diagram below, The SF Forwarder (SFF) "A" has two
instances of Service Function #7(SF7-1 & SF7-2), and 3 instances of
Service Function #2 (SF2-2, SF2-4, SF2-5).
+----+ +---+ +---+ +---+
| SF2| |SF2| |SF2| |SFx|
| -2 | |-4 | |-5 | |-1 |
+----+ +---+ +---+ +---+
| | | |
+------+-------+-------+
|
+----+ +---+ | +---+ +---+
| SF7| |SF7| | |SF5| |SF5|
| -1 | |-2 | | |-2 | |-4 |
+----+ +---+ | +---+ +---+
: / / /
: / / /-----/
\ / / /
+--------------+ +---------- +----+
-- >| Chain |-- | SFF |------| SFF| ---->
|classifier | | A | | C |
+--------------+ +----------+ +----+
Figure 2 Local Restoration among multiple service instances
Dunbar, et al. Expires October 29, 2014 [Page 7]
Internet-Draft SF Instances Restoration Framework April 2014
For a service chain that consists of "Service Function #7" followed
by "Service Function #2", which is represented by SF7->SF2, the
steering policy to SFF "A" could be:
{SF7-1, SF7-3} -> {SF2-2, SF2-4, SF2-5}.
The multiple components within the {} represents the equal function
instances that SFF "A" can select locally.
When one service function instance fails, the SFF "A" can locally
choose another instance without informing the SC Classifier node, or
other SFF or network nodes.
The local protection and restoration is relatively simple and clean.
ECMP can be used to balance all the available service function
instances attached locally.
6. Global Restoration of Service function instances
Sometimes changing the Service Chain Instance Path involves using
service function instances at different SF Forwarding (SSF) nodes.
For example, for a Chain #7 -> #2 -> #3 -> #5 in the figure above:
- Original instance path: #7 & #2 at SFF "A"; #3 & #5 at SFF
"C".
- New instance path: #7 at SFF "A" and #2& #3 & #5 at SFF "C".
This section examines possible ways to achieve the restoration when
the change of instance path involves multiple nodes.
6.1. Encoding the Exact Instance Path in Data Packets
If the detailed Service Chain Instance Path is encoded in data
packets, the SC Classifier can be notified of the change and encode
the new instance path in the data packets of the flow. This method
won't cause any contention issue among all the involved nodes.
As mentioned in the previous section, encoding exact instance path in
every packet can cause packets fragmentation, which is very
processing intensive. Therefore, it's not optimal to require every
data packet to carry an exact instance path, especially when the
Service Chain instance path doesn't change very frequently, as in
minutes or hours.
Dunbar, et al. Expires October 29, 2014 [Page 8]
Internet-Draft SF Instances Restoration Framework April 2014
6.2. In-Band Signaling of an Instance Path change
A similar method to MPLS RSVP-TE [RSVP-TE] signaling can be
considered for the head end node to signal a required service
instance path, and then let the data packets traverse the
established path.
The drawback of this approach is that the head end node might
receive packets belonging to the service chain before the instance
path has been established. It is very similar to the issues
encountered by MPLS Fast Reroute [FRR]. MPLS FRR requires that
packets be dropped if a restoration path is being dynamically
signaled because there was not a pre-established backup path..
6.3. Out-Of-Band Signaling of an Instance Path change
If the out-of-band method is used, i.e. sending the updated flow
steering policies to indicate the changes of the instance path, there
could be issues of synchronization and race conditions. For example,
if the SFF "A" and SFF "C" get flow steering policies at slightly
different times, some packets of the flow might miss some service
functions on the chain.
6.4. Provisioning an Instance Path change
In SDN or SDN-like environments, changes to the Instance Path can be
provisioned or programmed into network nodes via a central controller
or Network Management System (NMS). This simplifies the nodes, since
they are not required to use a signaling protocol, but there may be
problems introduced (such as loops or dropped packets) if network
nodes are not updated in the proper order or very soon to each other;
the nodes should be updated in a similar time scale to the use of a
signaling protocol. In addition, the network may have a single point
of failure if the controller or NMS is not itself redundant.
6.5. Hybrid Method
For global restoration of service function instances, it is
worthwhile to explore a hybrid mode, i.e. when there are changes
involving using service instances at different SFF nodes, the SC
Classifier node is informed to encode the detailed instance path to
data packets until all the involved SFF nodes complete the
installation of the new steering policy for the flow.
Dunbar, et al. Expires October 29, 2014 [Page 9]
Internet-Draft SF Instances Restoration Framework April 2014
7. Regional Restoration of Service Function Instances
It might not be always be feasible for the head end Service Chain
Classifier to be aware of the exact instances selected for a given
Service Chain due to being managed by multiple administrative
entities. Then Regional restoration should be considered.
Regional restoration can take the similar approach as the Global
restoration: choosing a regional ingress node that can take over the
responsibility of installing the new steering policies to the
involved SFF nodes or network nodes.
The Regional ingress node should be:
- on the data path of the flow of the given service chain;
- in front of the relevant the SFF nodes or network nodes that
are impacted by the change of the Service Chain Instance
Path;
- capable of encoding the detailed Service Chain Instance Path
to the data packets of the identified flow; and
- capable of removing the detailed Service Chain Instance Path
encoding in data packets after all the impacted SFF nodes and
network nodes completed the policy installation.
8. Conclusion and Recommendation
TBD
9. Manageability Considerations
TBD
10. Security Considerations
TBD
11. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove
this section before publication.
Dunbar, et al. Expires October 29, 2014 [Page 10]
Internet-Draft SF Instances Restoration Framework April 2014
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[SFC-Problem] P. Quinn, et al, "Service Function Chaining Problem
statement", draft-ietf-sfc-problem-statement-02, work in
progress, April 2014
[NFV-Terminology] ETSI NFV ISG, "Network Functions Virtualisation
(NFV); Terminology for Main Concepts in NFV", ETSI GS NFV
003 V1.1.1, Oct. 2013,
http://www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.01.
01_60/gs_NFV003v010101p.pdf
[SFC-Reduction] R. Parker, "Service Function Chaining: Chain to Path
Reduction", draft-parker-sfc-chain-to-path-00, work in
progress, Nov. 2013
[RSVP-TE] D. Awduche, Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[FRR] P. Pan, Swallow, G., and Atlas, A., "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005
13. Acknowledgments
Many thanks to Ron Bonica for the discussion in formulating the
content for the draft.
This document was prepared using 2-Word-v2.0.template.dot.
Dunbar, et al. Expires October 29, 2014 [Page 11]
Internet-Draft SF Instances Restoration Framework April 2014
Authors' Addresses
Linda Dunbar
Huawei Technologies
5340 Legacy Drive, Suite 175
Plano, TX 75024, USA
Phone: (469) 277 5840
Email: ldunbar@huawei.com
USA
Email: rbonica@juniper.net
Andrew G. Malis
Huawei Technologies
USA
Email: agmalis@gmail.com
Dunbar, et al. Expires October 29, 2014 [Page 12]