idnits 2.17.1 draft-xu-sfc-using-mpls-spring-06.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 (July 3, 2016) is 2852 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational draft: draft-ietf-sfc-architecture (ref. 'I-D.ietf-sfc-architecture') == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-04 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-08 Summary: 1 error (**), 0 flaws (~~), 4 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 Huawei 4 Intended status: Standards Track H. Shah 5 Expires: January 4, 2017 Ciena 6 L. Contreras 7 Telefonica I+D 8 D. Bernier 9 Bell Canada 10 July 3, 2016 12 Service Function Chaining Using MPLS-SPRING 13 draft-xu-sfc-using-mpls-spring-06 15 Abstract 17 Source Packet Routing in Networking (SPRING) WG specifies a special 18 source routing mechanism. Such source routing mechanism can be 19 leveraged to realize the service path layer functionality of the 20 service function chaining (i.e, steering traffic through a particular 21 service function path) by encoding the service function path or the 22 service function chain information as the explicit path information. 23 This document describes how to leverage the MPLS-based source routing 24 mechanism as developed by the SPRING WG to realize the service path 25 layer functionality of the service function chaining. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 4, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Solution Description . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Encoding SFP Information by an MPLS Label Stack . . . . . 4 66 3.2. How to Contain Metadata within an MPLS Packet . . . . . . 5 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 73 8.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 When applying a particular Service Function Chain (SFC) 79 [I-D.ietf-sfc-architecture] to the traffic selected by a service 80 classifier, the traffic need to be steered through an ordered set of 81 Service Functions (SF) in the network. This ordered set of SFs in 82 the network indicates the Service Function Path (SFP) associated with 83 the above SFC. To steer the selected traffic through an ordered list 84 of SFs in the network, the traffic need to be attached by the service 85 classifier with the information about the SFP (i.e., specifying 86 exactly which Service Function Forwarders (SFFs) and which SFs are to 87 be visited by traffic), the SFC, or the partially specified SFP which 88 is in between the former two extremes. Source Packet Routing in 89 Networking (SPRING) WG specifies a special source routing mechanism 90 which can be used to steer traffic through an ordered set of routers 91 (i.e., an explicit path). Such source routing mechanism can be 92 leveraged to realize the service path layer functionality of the SFC 93 (i.e., steering traffic through a particular SFP) by encoding the SFP 94 information as the explicit path information contained in packets. 95 The source routing mechanism specified by the SPRING WG can be 96 applied to the MPLS data plane 98 [I-D.ietf-spring-segment-routing-mpls]. This document describes how 99 to leverage the MPLS-based source routing mechanisms to realize the 100 service path layer functionality of the service function chaining. 101 Note that this approach is aligned with the Transport Derived SFF 102 mode as described in Section 4.3.1 of [I-D.ietf-sfc-architecture]. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 2. Terminology 112 This memo makes use of the terms defined in 113 [I-D.ietf-spring-segment-routing] and [I-D.ietf-sfc-architecture]. 115 3. Solution Description 117 +----------------------------------------------- ----+ 118 | SPRING Networks | 119 | +---------+ +---------+ | 120 | | SF1 | | SF2 | | 121 | +----+----+ +----+----+ | 122 | | | | 123 | (1) | (2) | (3) | 124 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+ 125 |Classifier+------+ SFF1 +-------+ SFF2 +-------+ D | 126 +----------+ +---------+ +---------+ +---+---+ 127 | | 128 +----------------------------------------------------+ 129 Figure 1: Service Function Chaining in SPRING Networks 131 As shown in Figure 1, assume SFF1 and SFF2 are two MPLS-SPRING- 132 capable nodes. They are also Service Function Forwarders (SFF) to 133 which two SFs (i.e., SF1 and SF2) are attached respectively. In 134 addition, they have allocated and advertised Segment IDs (SID) for 135 their locally attached SFs. In the MPLS-SPRING context, SIDs are 136 intercepted as MPLS labels. For example, SFF1 allocates and 137 advertises an SID (i.e., SID(SF1)) for SF1 while SFF2 allocates and 138 advertises an SID ( i.e., SID(SF2)) for SF2. These SIDs which are 139 used to indicate SFs are referred to as SF SIDs. To encode the SFP 140 information by an MPLS label stack, those SF SIDs as mentioned above 141 would be interpreted as local MPLS labels. In addition, assume node 142 SIDs for SFF1 and SFF2 are SID(SFF1) and SID(SFF2) respectively. Now 143 assume a given traffic flow destined for destination D is selected by 144 the service classifier to go through a particular SFC (i.e., SF1-> 145 SF2) before reaching its final destination D. Section 3.1 describes 146 how to leverage the MPLS- based source routing mechanisms to realize 147 the service path functionality of the service function chaining 148 (i.e., by encoding the SFP information within an MPLS label stack). 149 Section 3.2 describes how to carry metadata over MPLS packets. 151 3.1. Encoding SFP Information by an MPLS Label Stack 153 Since the selected packet needs to travel through an SFC (i.e., 154 SF1->SF2), the service classifier would attach a segment list of 155 (i.e., SID(SFF1)->SID(SF1)->SID(SFF2)-> SID(SF2)) which indicates the 156 corresponding SFP to the packet. This segment list is actually 157 represented by a MPLS label stack. To some extent, the MPLS label 158 stack here could be looked as a specific implementation of the SFC 159 encapsulation used for containing the SFP information 160 [I-D.ietf-sfc-architecture]. When the encapsulated packet arrives at 161 SFF1, SFF1 would know which SF should be performed according to the 162 current top label (i.e., SID (SF1)) of the received MPLS packet. If 163 SF1 is an SFC encapsulation-aware SF, the MPLS packet would be sent 164 to SF1 after the top label is poped. After receiving the MPLS packet 165 returned from SF1, SFF1 would send it to SFF2 according to the 166 current top label (i.e., SID (SFF2) ). If SF1 is a legacy SF which 167 could not process the MPLS label stack, the whole MPLS label stack 168 (i.e., SID(SFF2)->SID(SF2)) MUST be stripped before sending the 169 packet to SF1. After receiving the packet returned from SF1, SFF1 170 would re-impose the MPLS label stack which had been stripped before 171 to the packet and then send it to SFF2 according to the current top 172 label (i.e., SID (SFF2) ). When the encapsulated packet arrives at 173 SFF2, SFF2 would perform the similar action as what has been done by 174 SFF1. 176 If there is no MPLS LSP towards the next node segment (i.e., the next 177 SFF identified by the current top label), the corresponding IP-based 178 tunnel (e.g., MPLS-in-IP/GRE tunnel [RFC4023], MPLS-in-UDP tunnel 179 [RFC7510] or MPLS-in-L2TPv3 tunnel [RFC4817]) could be used instead 180 (For more details about this special usage, please refer to 181 [I-D.xu-spring-islands-connection-over-ip]). Since the transport 182 (i.e., the underlay) could be IPv4, IPv6 or even MPLS networks, the 183 above approach of encoding the SFP information by an MPLS label stack 184 is fully transport-independent which is one of the major requirements 185 for the SFC encapsulation [I-D.ietf-sfc-architecture]. 187 In addition, the service classifier could further impose metadata on 188 the MPLS packet through the Network Service Header (NSH) 189 [I-D.ietf-sfc-nsh] (As for how to contain the NSH within a MPLS 190 packet, please see Section 3.3). Here the Service Path field wihin 191 the NSH would not be used for the path selection purpose anymore and 192 therefore it MUST be set to a particular value to indicate such 193 particular usage. In addition, the service index value within the 194 NSH is set to a value indicating the total number of SFs within the 195 service function path. The service index SHOULD be decreased by one 196 on each SF or SFC-proxy on behalf of the corresponding legacy SF. 197 When the service index become zero, the NSH MUST be removed from the 198 packet by the SF or SFC-proxy on behalf of the corresponding legacy 199 SF. 201 3.2. How to Contain Metadata within an MPLS Packet 203 Since the MPLS encapsulation has no explicit protocol identifier 204 field to indicate the protocol type of the MPLS payload, how to 205 indicate the presence of metadata (i.e., the NSH which is only used 206 as a metadata containner) in MPLS packets is a potential issue. 207 There is a possible way to address the above issue: SFFs allocate two 208 different labels for a given SF, one indicates the presence of NSH 209 while the other indicates the absence of NSH. This approach has no 210 change to the current MPLS architecture but it would require more 211 than one label binding for a given SF. More details about how to 212 contain metadata within an MPLS packet would be considered in the 213 future version of this draft. 215 4. Acknowledgements 217 The authors would like to thank Loa Andersson and Andrew G. Malis 218 for their valuable comments and suggestions on the draft. The 219 authors would like to thank Adrian Farrel, Stewart Bryant, Alexander 220 Vainshtein, Joel M. Halpern for their comments on how to indicate 221 the presence of metadata within an MPLS packet. 223 5. Contributors 225 Zhenbin Li (Huawei Technologies) 227 6. IANA Considerations 229 TBD. 231 7. Security Considerations 233 TBD 235 8. References 237 8.1. Normative References 239 [I-D.ietf-sfc-architecture] 240 Halpern, J. and C. Pignataro, "Service Function Chaining 241 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 242 in progress), July 2015. 244 [I-D.ietf-spring-segment-routing-mpls] 245 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 246 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 247 and E. Crabbe, "Segment Routing with MPLS data plane", 248 draft-ietf-spring-segment-routing-mpls-04 (work in 249 progress), March 2016. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, 253 DOI 10.17487/RFC2119, March 1997, 254 . 256 8.2. Informative References 258 [I-D.ietf-sfc-nsh] 259 Quinn, P. and U. Elzur, "Network Service Header", draft- 260 ietf-sfc-nsh-05 (work in progress), May 2016. 262 [I-D.ietf-spring-segment-routing] 263 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 264 and R. Shakir, "Segment Routing Architecture", draft-ietf- 265 spring-segment-routing-08 (work in progress), May 2016. 267 [I-D.xu-spring-islands-connection-over-ip] 268 Xu, X., Raszuk, R., Chunduri, U., Contreras, L., and L. 269 Jalil, "Connecting MPLS-SPRING Islands over IP Networks", 270 draft-xu-spring-islands-connection-over-ip-05 (work in 271 progress), March 2016. 273 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 274 "Encapsulating MPLS in IP or Generic Routing Encapsulation 275 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 276 . 278 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 279 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 280 Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March 281 2007, . 283 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 284 "Encapsulating MPLS in UDP", RFC 7510, 285 DOI 10.17487/RFC7510, April 2015, 286 . 288 Authors' Addresses 290 Xiaohu Xu 291 Huawei 293 Email: xuxiaohu@huawei.com 295 Himanshu Shah 296 Ciena 298 Email: hshah@ciena.com 300 Luis M. Contreras 301 Telefonica I+D 302 Ronda de la Comunicacion, s/n 303 Sur-3 building, 3rd floor 304 Madrid, 28050 305 Spain 307 Email: luismiguel.contrerasmurillo@telefonica.com 308 URI: http://people.tid.es/LuisM.Contreras/ 310 Daniel Bernier 311 Bell Canada 313 Email: daniel.bernier@bell.ca