Service Function Chaining Use Case
draft-xu-spring-sfc-use-case-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Xiaohu Xu | ||
| Last updated | 2014-04-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xu-spring-sfc-use-case-00
Network Working Group X. Xu
Internet-Draft Huawei
Intended status: Informational April 18, 2014
Expires: October 20, 2014
Service Function Chaining Use Case
draft-xu-spring-sfc-use-case-00
Abstract
This document describes a particular use case for SPRING where the
Segment Routing mechanism is leveraged to realize the service path
layer functionality of the Service Function Chaining (i.e, steering
traffic through the service function path).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 20, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Xu Expires October 20, 2014 [Page 1]
Internet-Draft April 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SFC Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. SFC in MPLS-SR Case . . . . . . . . . . . . . . . . . . . 3
3.2. SFC in IPv6-SR Case . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
When applying a particular Service Function Chaining (SFC)
[I-D.quinn-sfc-arch] to the traffic selected by the service
classifier, the traffic need to be steered through an ordered set of
service nodes in the network. This ordered set of service nodes
indicates the service function path which is actually the
instantiation of the above SFC in the network. Furthermore,
additional information about the traffic (a.k.a. metadata) which is
helpful for enabling value-added services may need to be carried
across those service nodes within the SFC instantiation. As
mentioned in [I-D.rijsman-sfc-metadata-considerations] "...it is
important to make a distinction between fields which are used at the
service path layer to identify the Service Path Segment, and
additional fields which carry metadata which is imposed and
interpreted at the service function layer. Combining both types of
fields into a single header should probably be avoided from a
layering point of view. "
Segment Routing (SR) [I-D.filsfils-rtgwg-segment-routing] is a source
routing paradigm which can be used to steer traffic through an
ordered set of routers. SR can be applied to both MPLS data plane
[I-D.filsfils-spring-segment-routing-mpls] and IPv6 data planes
[I-D.previdi-6man-segment-routing-header].
This document describes a particular use case for SPRING where the SR
mechanism is leveraged to realize the service path layer
functionality of the SFC (i.e, steering traffic through the service
function path).
Xu Expires October 20, 2014 [Page 2]
Internet-Draft April 2014
1.1. Requirements Language
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].
2. Terminology
This memo makes use of the terms defined in
[I-D.filsfils-rtgwg-segment-routing] and [I-D.quinn-sfc-arch].
3. SFC Use Case
Assume SN1 and SN2 are two SR nodes meanwhile they are service nodes
which offer service S1 and S2 respectively. In addition, they have
allocated and advertised segment IDs for the services they are
offering. For example, SN1 allocates and advertises a segment ID,
SID(S1) for service S1 while SN2 allocates and advertises a segment
ID, SID(S2) for service S2. These segment IDs which are used to
indicate services are referred to as service segment ID. In
addition, assume the node segment IDs for SN1 and SN2 are SID(SN1)
and SID(SN2) respectively.
How to steer a packet through a service fucntion path in both MPLS-SR
and IPv6-SR cases is illustrated in the following two sub-sections
respectively.
3.1. SFC in MPLS-SR Case
In the MPLS-SR case, those service segment IDs as mentioned above
would be interpreted as local MPLS labels. Meanwhile, to simplify
the illustrationIn, those node segment IDs as mentioned above would
be interpreted as MPLS global labels here.
Now assume a given packet destined for destination D is required to
go through a service function chain {S1, S2} before reaching its
final destination D. The service classifier therefore would attach a
segment list {SID(SN1), SID(S1), SID(SN2), SID(S2)} to the packet.
This segment list is actually represented by a MPLS label stack. In
addition, the service classifier could optionally impose metadata on
the packet through the Network Service Header (NSH)
[I-D.quinn-sfc-nsh]. Here the Service Path field wihin the NSH would
not be used for path selection anymore and therefore it MUST be set
to a particular value to indicate this particular usage. In
addition, the service index value is set to 2 since there are two
service nodes within the service path. How to impose the NSH on a
MPLS packet is outside the scope of this document. When the
encapsulated packet arrives at SN1, SN1 would know which service
Xu Expires October 20, 2014 [Page 3]
Internet-Draft April 2014
should be performed according to SID (S1). If a NSH is carried in
that packet, SN1 could further consume the metadata contained in the
NSH and meanwhile decrease the service index value within the NSH by
one. When the encapsualted packet arrives at SN2, SN2 would do the
similar action as what has been done by SN1. Furthermore, since SN2
is the last service node within the service path, SN2 MUST strip the
NSH if it has been imposed before sending the packet to D.
3.2. SFC in IPv6-SR Case
In the IPv6-SR case, those service segment IDs as mentioned above
would be interpreted as IPv6 link-local addresses while those node
segment IDs as mentioned above would be interpreted as IPv6 global
unicast addresses.
Now assume a given IPv6 packet destined for destination D is required
to go through a service function chain {S1, S2} before reaching its
final destination D. The service classifier therefore would attach a
SR header containing a segment list {SID(S1),
SID(SN2),SID(S2),SID(D)} to the IPv6 packet. This segment list is
actually represented by an ordered list of IPv6 addresses. The IPv6
destination address is filled with SID(SN1). In addition, the
service classifier could optionally impose metadata on the above IPv6
packet through the NSH and meanwhile carry the original IPv6 source
address in the Original Source Address field of the packet. When the
above IPv6 packet arrives at SN1, SN1 would know which service should
be performed according to SID (S1). If a NSH is carried in that
packet, SN1 could further consume the metadata contained in the NSH
and meanwhile decrease the service index value within the NSH by one.
When the packet arrives at SN2, SN2 would do the similar action as
what has been done by SN1. Furthermore, since SN2 is the second last
node in the segment list, SN2 could strip the SR header (if required)
and meanwhile fill in the IPv6 source address with the Original
Source Address (if available) before sending the packet towards D.
Besides, since SN2 is the last service node within the service path,
SN2 MUST strip the NSH if it has been imposed before sending the
packet to D.
4. Acknowledgements
TBD .
5. IANA Considerations
TBD.
Xu Expires October 20, 2014 [Page 4]
Internet-Draft April 2014
6. Security Considerations
This document does not introduce any new security considerations.
7. References
7.1. Normative References
[I-D.filsfils-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing with MPLS data plane", draft-filsfils-
spring-segment-routing-mpls-01 (work in progress), April
2014.
[I-D.previdi-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6
Segment Routing Header (SRH)", draft-previdi-6man-segment-
routing-header-00 (work in progress), March 2014.
[I-D.quinn-sfc-arch]
Quinn, P. and A. Beliveau, "Service Function Chaining
(SFC) Architecture", draft-quinn-sfc-arch-04 (work in
progress), January 2014.
[I-D.quinn-sfc-nsh]
Quinn, P., Guichard, J., Fernando, R., Surendra, S.,
Smith, M., Yadav, N., Agarwal, P., Manur, R., Chauhan, A.,
Elzur, U., McConnell, B., and C. Wright, "Network Service
Header", draft-quinn-sfc-nsh-02 (work in progress),
February 2014.
[I-D.rijsman-sfc-metadata-considerations]
Rijsman, B. and J. Moisand, "Metadata Considerations",
draft-rijsman-sfc-metadata-considerations-00 (work in
progress), February 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
Xu Expires October 20, 2014 [Page 5]
Internet-Draft April 2014
[I-D.filsfils-rtgwg-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-rtgwg-
segment-routing-01 (work in progress), October 2013.
Author's Address
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
Xu Expires October 20, 2014 [Page 6]