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]