idnits 2.17.1 draft-xu-spring-sfc-use-case-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2014) is 3589 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.filsfils-spring-segment-routing-mpls' is defined on line 216, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-mpls-02 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-01 == Outdated reference: A later version (-07) exists of draft-quinn-sfc-nsh-02 == Outdated reference: A later version (-04) exists of draft-filsfils-spring-segment-routing-03 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei 5 Expires: December 31, 2014 H. Shah 6 Ciena 7 L. Contreras 8 Telefonica I+D 9 June 29, 2014 11 Service Function Chaining Use Case for SPRING 12 draft-xu-spring-sfc-use-case-02 14 Abstract 16 This document describes a particular use case for SPRING where the 17 Segment Routing mechanism is leveraged to realize the service path 18 layer functionality of the Service Function Chaining (i.e, steering 19 traffic through the service function path). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 31, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. SFC Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. SFC in MPLS-SR Case . . . . . . . . . . . . . . . . . . . 3 60 3.2. SFC in IPv6-SR Case . . . . . . . . . . . . . . . . . . . 4 61 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 7.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 When applying a particular Service Function Chaining (SFC) 72 [I-D.quinn-sfc-arch] to the traffic selected by the service 73 classifier, the traffic need to be steered through an ordered set of 74 service nodes in the network. This ordered set of service nodes 75 indicates the service function path which is actually the 76 instantiation of the above SFC in the network. Furthermore, 77 additional information about the traffic (a.k.a. metadata) which is 78 helpful for enabling value-added services may need to be carried 79 across those service nodes within the SFC instantiation. As 80 mentioned in [I-D.rijsman-sfc-metadata-considerations] "...it is 81 important to make a distinction between fields which are used at the 82 service path layer to identify the Service Path Segment, and 83 additional fields which carry metadata which is imposed and 84 interpreted at the service function layer. Combining both types of 85 fields into a single header should probably be avoided from a 86 layering point of view. " 88 Segment Routing (SR) [I-D.filsfils-spring-segment-routing] is a 89 source routing paradigm which can be used to steer traffic through an 90 ordered set of routers. SR can be applied to the MPLS data plane 91 [I-D.gredler-spring-mpls] 92 [I-D.filsfils-spring-segment-routing-mpls]and the IPv6 data plane 93 [I-D.previdi-6man-segment-routing-header]. 95 This document describes a particular use case for SPRING where the SR 96 mechanism is leveraged to realize the service path layer 97 functionality of the SFC (i.e, steering traffic through the service 98 function path). 100 1.1. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 2. Terminology 108 This memo makes use of the terms defined in 109 [I-D.filsfils-spring-segment-routing] and [I-D.quinn-sfc-arch]. 111 3. SFC Use Case 113 +----------------------------------------------- ----+ 114 | SR Netowrks | 115 | +---------+ +---------+ | 116 | | +-----+ | | +-----+ | | 117 | (1) | | SF1 | | (2) | | SF2 | | (3) | 118 +----+-----+ ---> | +-----+ | ----> | +-----+ | ---> +---+---+ 119 |Classifier+------+ SN1 +-------+ SN2 +-------+ D | 120 +----------+ +---------+ +---------+ +---+---+ 121 | | 122 +----------------------------------------------------+ 123 Figure 1: Service Function Chaining in SR Networks 125 As shown in Figure 1, assume SN1 and SN2 are two SR-capable nodes 126 meanwhile they are service nodes which offer service function SF1 and 127 SF2 respectively. In addition, they have allocated and advertised 128 segment IDs (SID) for the service functions they are offering. For 129 example, SN1 allocates and advertises an SID, i.e., SID(SF1) for 130 service function SF1 while SN2 allocates and advertises an SID, i.e., 131 SID(SF2) for service function SF2. These SIDs which are used to 132 indicate service functions are referred to as Service Function SIDs. 133 In addition, assume the node SIDs for SN1 and SN2 are SID(SN1) and 134 SID(SN2) respectively. 136 How to steer a packet through a service fucntion path in both MPLS-SR 137 and IPv6-SR cases is illustrated in the following two sub-sections 138 respectively. 140 3.1. SFC in MPLS-SR Case 142 In the MPLS-SR case, those service function SIDs as mentioned above 143 would be interpreted as local MPLS labels. Meanwhile, to simplify 144 the illustrationIn in this document, those node SIDs as mentioned 145 above would be interpreted as MPLS global labels. 147 Now assume a given packet destined for destination D is required to 148 go through a service function chain {SF1, SF2} before reaching its 149 final destination D. The service classifier therefore would attach a 150 segment list {SID(SN1), SID(SF1), SID(SN2), SID(SF2)} to the packet. 151 This segment list is actually represented by a MPLS label stack. In 152 addition, the service classifier could optionally impose metadata on 153 the packet through the Network Service Header (NSH) 154 [I-D.quinn-sfc-nsh]. Here the Service Path field wihin the NSH would 155 not be used for the path selection purpose anymore and therefore it 156 MUST be set to a particular value to indicate such particular usage. 157 In addition, the service index value within the NSH is set to 2 since 158 there are two service nodes within the service function path. How to 159 impose the NSH on a MPLS packet is outside the scope of this 160 document. When the encapsulated packet arrives at SN1, SN1 would 161 know which service function should be performed according to SID 162 (SF1). If a NSH is carried in that packet, SN1 could further consume 163 the metadata contained in the NSH and meanwhile decrease the service 164 index value within the NSH by one. When the encapsualted packet 165 arrives at SN2, SN2 would do the similar action as what has been done 166 by SN1. Furthermore, since SN2 is the last service node within the 167 service function path, SN2 MUST strip the NSH (if it has been 168 imposed) before sending the packet to D. 170 3.2. SFC in IPv6-SR Case 172 In the IPv6-SR case, those service function SIDs as mentioned above 173 would be interpreted as IPv6 link-local addresses while those node 174 SIDs as mentioned above would be interpreted as IPv6 global unicast 175 addresses. 177 Now assume a given IPv6 packet destined for destination D is required 178 to go through a service function chain {SF1, SF2} before reaching its 179 final destination D. The service classifier therefore would attach a 180 SR header containing a segment list {SID(SF1), 181 SID(SN2),SID(SF2),SID(D)} to the IPv6 packet. This segment list is 182 actually represented by an ordered list of IPv6 addresses. The IPv6 183 destination address is filled with SID(SN1). In addition, the 184 service classifier could optionally impose metadata on the above IPv6 185 packet through the NSH and meanwhile carry the original IPv6 source 186 address in the Original Source Address field of the packet. When the 187 above IPv6 packet arrives at SN1, SN1 would know which service 188 function should be performed according to SID (SF1). If a NSH is 189 carried in that packet, SN1 could further consume the metadata 190 contained in the NSH and meanwhile decrease the service index value 191 within the NSH by one. When the packet arrives at SN2, SN2 would do 192 the similar action as what has been done by SN1. Furthermore, since 193 SN2 is the second last node in the segment list, SN2 should strip the 194 SR header and meanwhile fill in the IPv6 source address with the 195 Original Source Address (if available) before sending the packet 196 towards D. Besides, since SN2 is the last service node within the 197 service path, SN2 MUST strip the NSH (if it has been imposed) before 198 sending the packet to D. 200 4. Acknowledgements 202 TBD. 204 5. IANA Considerations 206 TBD. 208 6. Security Considerations 210 This document does not introduce any new security risk. 212 7. References 214 7.1. Normative References 216 [I-D.filsfils-spring-segment-routing-mpls] 217 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 218 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 219 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 220 "Segment Routing with MPLS data plane", draft-filsfils- 221 spring-segment-routing-mpls-02 (work in progress), June 222 2014. 224 [I-D.gredler-spring-mpls] 225 Gredler, H., Rekhter, Y., Jalil, L., Kini, S., and X. Xu, 226 "Supporting Source/Explicitly Routed Tunnels via Stacked 227 LSPs", draft-gredler-spring-mpls-06 (work in progress), 228 May 2014. 230 [I-D.previdi-6man-segment-routing-header] 231 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 232 Segment Routing Header (SRH)", draft-previdi-6man-segment- 233 routing-header-01 (work in progress), June 2014. 235 [I-D.quinn-sfc-arch] 236 Quinn, P. and J. Halpern, "Service Function Chaining (SFC) 237 Architecture", draft-quinn-sfc-arch-05 (work in progress), 238 May 2014. 240 [I-D.quinn-sfc-nsh] 241 Quinn, P., Guichard, J., Fernando, R., Surendra, S., 242 Smith, M., Yadav, N., Agarwal, P., Manur, R., Chauhan, A., 243 Elzur, U., McConnell, B., and C. Wright, "Network Service 244 Header", draft-quinn-sfc-nsh-02 (work in progress), 245 February 2014. 247 [I-D.rijsman-sfc-metadata-considerations] 248 Rijsman, B. and J. Moisand, "Metadata Considerations", 249 draft-rijsman-sfc-metadata-considerations-00 (work in 250 progress), February 2014. 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 7.2. Informative References 257 [I-D.filsfils-spring-segment-routing] 258 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 259 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 260 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 261 "Segment Routing Architecture", draft-filsfils-spring- 262 segment-routing-03 (work in progress), June 2014. 264 Authors' Addresses 266 Xiaohu Xu 267 Huawei 269 Email: xuxiaohu@huawei.com 271 Zhenbin Li 272 Huawei 274 Email: lizhenbin@huawei.com 276 Himanshu Shah 277 Ciena 279 Email: hshah@ciena.com 280 Luis M. Contreras 281 Telefonica I+D 282 Ronda de la Comunicacion, s/n 283 Sur-3 building, 3rd floor 284 Madrid, 28050 285 Spain 287 Email: luismiguel.contrerasmurillo@telefonica.com 288 URI: http://people.tid.es/LuisM.Contreras/