idnits 2.17.1 draft-xu-mpls-service-chaining-03.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, 2017) is 2492 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) == Unused Reference: 'I-D.ietf-sfc-nsh' is defined on line 410, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 == Outdated reference: A later version (-09) exists of draft-xu-mpls-payload-protocol-identifier-02 == Outdated reference: A later version (-04) exists of draft-xu-mpls-unified-source-routing-instruction-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group X. Xu 3 Internet-Draft S. Bryant 4 Intended status: Standards Track Huawei 5 Expires: December 31, 2017 H. Assarpour 6 Broadcom 7 H. Shah 8 Ciena 9 L. Contreras 10 Telefonica I+D 11 D. Bernier 12 Bell Canada 13 J. Tantsura 14 Individual 15 S. Ma 16 Juniper 17 M. Vigoureux 18 Nokia 19 June 29, 2017 21 Service Chaining using Unified Source Routing Instructions 22 draft-xu-mpls-service-chaining-03 24 Abstract 26 Source Packet Routing in Networking (SPRING) WG is developing an MPLS 27 source routing mechanism. The MPLS source routing mechanism can be 28 leveraged to realize a unified source routing instruction which works 29 across both IPv4 and IPv6 underlays in addition to the MPLS underlay. 30 This document describes how to leverage the unified source routing 31 instruction to realize a transport-independent service function 32 chaining by encoding the service function path information or service 33 function chain information as an MPLS label stack. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on December 31, 2017. 58 Copyright Notice 60 Copyright (c) 2017 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. Solution Description . . . . . . . . . . . . . . . . . . . . 3 78 3.1. Encoding SFP Information by an MPLS Label Stack . . . . . 4 79 3.2. Encoding SFC Information by an MPLS Label Stack . . . . . 7 80 3.3. How to Contain Metadata within an MPLS Packet . . . . . . 9 81 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 7.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 When applying a particular Service Function Chain (SFC) [RFC7665] to 92 the traffic selected by a service classifier, the traffic need to be 93 steered through an ordered set of Service Functions (SF) in the 94 network. This ordered set of SFs in the network indicates the 95 Service Function Path (SFP) associated with the above SFC. In order 96 to steer the selected traffic through the required ordered list of 97 SFs, the service classifier needs to attach information to the packet 98 specifying exactly which Service Function Forwarders (SFFs) and which 99 SFs are to be visited by traffic), the SFC, or the partially 100 specified SFP which is in between the former two extremes. 102 The Source Packet Routing in Networking (SPRING) WG is developing an 103 MPLS source routing mechanism which can be used to steer traffic 104 through an ordered set of routers (i.e., an explicit path) and 105 instruct nodes on that path to execute specific operations on the 106 packet. By leveraging the MPLS source routing mechanism, 107 [I-D.xu-mpls-unified-source-routing-instruction] describes a unified 108 source routing instruction which works across both IPv4 and IPv6 109 underlays in addition to the MPLS underlay. This document describes 110 how to leverage the unified source routing instruction to realize a 111 transport-independent service function chaining by encoding the 112 service function path information or service function chain 113 information as an MPLS label stack. 115 2. Terminology 117 This memo makes use of the terms defined in 118 [I-D.ietf-spring-segment-routing-mpls], 119 [I-D.xu-mpls-unified-source-routing-instruction] and [RFC7665]. 121 3. Solution Description 123 +----------------------------------------------- ----+ 124 | MPLS SPRING Networks | 125 | +---------+ +---------+ | 126 | | SF1 | | SF2 | | 127 | +----+----+ +----+----+ | 128 | ^ | |(3) ^ | |(6) | 129 | (1) (2)| | V (4) (5)| | V (7) | 130 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+ 131 |Classifier+------+ SFF1 +-------+ SFF2 +-------+ D | 132 +----------+ +---------+ +---------+ +---+---+ 133 | | 134 +----------------------------------------------------+ 135 Figure 1: Service Function Chaining in MPLS-SPRING Networks 137 As shown in Figure 1, SFF1 and SFF2 are two MPLS-SPRING-capable 138 nodes. They are also SFFs, each with one SF attached. In addition, 139 they have allocated and advertised MPLS labels for their locally 140 attached SFs. For example, SFF1 allocates and advertises a label 141 (i.e., L(SF1)) for SF1 while SFF2 allocates and advertises a label ( 142 i.e., L(SF2)) for SF2. These labels, which are used to indicate SFs 143 are referred to as SF labels. To encode the SFP information as an 144 MPLS label stack, local MPLS labels are allocated from SFFs' (e.g., 145 SFF1 in Figure 1) label spaces to identify their locally attached SFs 146 (e.g., SF1 in Figure 1), whilst the SFFs are identified by either 147 nodal SIDs or adjacency SIDs depending on how strictly the network 148 path needs to be specified. In addition, assume node SIDs for SFF1 149 and SFF2 are L(SFF1) and L(SFF2) respectively. In contrast, to 150 encode the SFC information by an MPLS label stack, those SF labels 151 MUST be domain-wide unique MPLS labels. 153 Now assume a given traffic flow destined for destination D is 154 selected by the service classifier to go through a particular SFC 155 (i.e., SF1-> SF2) before reaching its final destination D. 156 Section 3.1 and 3.2 describe approaches of leveraging the MPLS- based 157 source routing mechanisms to realize the service function chaining by 158 encoding the SFP information within an MPLS label stack and by 159 encoding the SFC information within an MPLS label stack respectively. 160 Since the encoding of the partially specified SFP is just a simple 161 combination of the encoding of the SFP and the encoding of the SFC, 162 this document would not describe how to encode the partially 163 specified SFP anymore. 165 3.1. Encoding SFP Information by an MPLS Label Stack 166 +----------------------------------------------- ----+ 167 | MPLS SPRING Networks | 168 | +---------+ +---------+ | 169 | | SF1 | | SF2 | | 170 | +----+----+ +----+----+ | 171 | +---------+ | | +---------+ | 172 | | L(SFF2) | | | |Pkt to D | | 173 | +---------+ | | +---------+ | 174 | | L(SF2) | | | | 175 | +---------+ | ^ | | | 176 | |Pkt to D | ^ | | | | | | 177 | +---------+ | | | (5)| | |(6) | 178 | (2)| | |(3) | | V | 179 | (1) | | V (4) | (7) | 180 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+ 181 |Classifier+------+ SFF1 +-------+ SFF2 +-------+ D | 182 +----------+ +---------+ +---------+ +---+---+ 183 | +---------+ +---------+ +---------+ | 184 | | L(SFF1) | | L(SFF2) | |Pkt to D | | 185 | +---------+ +---------+ +---------+ | 186 | | L(SF1) | | L(SF2) | | 187 | +---------+ +---------+ | 188 | | L(SFF2) | |Pkt to D | | 189 | +---------+ +---------+ | 190 | | L(SF2) | | 191 | +---------+ | 192 | |Pkt to D | | 193 | +---------+ | 194 +----------------------------------------------------+ 195 Figure 2: Packet Walk in MPLS underlay 197 As shown in Figure 2, since the selected packet needs to travel 198 through an SFC (i.e., SF1->SF2), the service classifier would attach 199 a segment list of (i.e., SID(SFF1)->SID(SF1)->SID(SFF2)-> SID(SF2)) 200 which indicates the corresponding SFP to the packet. This segment 201 list is represented by an MPLS label stack. To some extent, the MPLS 202 label stack here could be looked as a specific implementation of the 203 SFC encapsulation used for containing the SFP information [RFC7665]. 204 When the encapsulated packet arrives at SFF1, SFF1 would know which 205 SF should be performed according to the top label (i.e., SID (SF1)) 206 of the received MPLS packet. We first consider the case where SF1 is 207 an encapsulation aware SF, i.e., it understands how to process a 208 packet with a pre-pended MPLS label stack. In this case the packet 209 would be sent to SF1 by SFF1 with the label stack SID(SFF2)-> 210 SID(SF2). SF1 would perform the required service function on the 211 received MPLS packet where the payload is constrained to be an IP 212 packet, and the SF needs to process both IPv4 and IPv6 packets (note 213 that the SF would use the first nibble of the MPLS payload to 214 identify the payload type). After the MPLS packet is returned from 215 SF1, SFF1 would send it to SFF2 according to the top label (i.e., SID 216 (SFF2) ). 218 If SF1 is a legacy SF, i.e. one that is unable to process the MPLS 219 label stack, the remaining MPLS label stack (i.e., 220 SID(SFF2)->SID(SF2)) MUST be saved and stripped from the packet 221 before sending the packet to SF1. When the packet is returned from 222 SF1, SFF1 would re-impose the MPLS label stack which had been 223 previously stripped and then send the packet to SFF2 according to the 224 current top label (i.e., SID (SFF2) ). As for how to associate the 225 corresponding MPLS label stack with the packets returned from legacy 226 SFs, those mechanisms as described in 227 [I-D.song-sfc-legacy-sf-mapping] could be considered. 229 When the encapsulated packet arrives at SFF2, SFF2 would perform the 230 similar action to that described above. 232 As shown in Figure 3, if there is no MPLS LSP towards the next node 233 segment (i.e., the next SFF identified by the current top label), the 234 corresponding IP-based tunnel for MPLS (e.g., MPLS-in-IP/GRE tunnel 235 [RFC4023], MPLS-in-UDP tunnel [RFC7510] or MPLS-in-L2TPv3 tunnel 236 [RFC4817]) would be used instead, according to the unified source 237 routing instruction as described in 238 [I-D.xu-mpls-unified-source-routing-instruction]. 240 +----------------------------------------------- ----+ 241 | IP Networks | 242 | +---------+ +---------+ | 243 | | SF1 | | SF2 | | 244 | +----+----+ +----+----+ | 245 | +---------+ | | +---------+ | 246 | | L(SFF2) | | | |Pkt to D | | 247 | +---------+ | | +---------+ | 248 | | L(SF2) | | | | 249 | +---------+ | ^ | | | 250 | |Pkt to D | ^ | | | | | | 251 | +---------+ | | | (5)| | |(6) | 252 | (2)| | |(3) | | V | 253 | (1) | | V (4) | (7) | 254 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+ 255 |Classifier+------+ SFF1 +-------+ SFF2 +-------+ D | 256 +----------+ +---------+ +---------+ +---+---+ 257 | +---------+ +---------+ | 258 | |IP Tunnel| |IP Tunnel| +---------+ | 259 | |to SFF1 | | to SFF2 | |Pkt to D | | 260 | +---------+ +---------+ +---------+ | 261 | | L(SF1) | | L(SF2) | | 262 | +---------+ +---------+ | 263 | | L(SFF2) | |Pkt to D | | 264 | +---------+ +---------+ | 265 | | L(SF2) | | 266 | +---------+ | 267 | |Pkt to D | | 268 | +---------+ | 269 +----------------------------------------------------+ 270 Figure 3: Packet Walk in IP underlay 272 Since the transport (i.e., the underlay) could be IPv4, IPv6 or even 273 MPLS networks, the above approach of encoding the SFP information by 274 an MPLS label stack is fully transport-independent which is one of 275 the major requirements for the SFC encapsulation [RFC7665]. 277 3.2. Encoding SFC Information by an MPLS Label Stack 279 Since the selected packet needs to travel through an SFC (i.e., 280 SF1->SF2), the service classifier would attach an MPLS label stack 281 (i.e., L(SF1)->L(SF2)) which indicates that SFC to the packet. Since 282 it's known to the service classifier that SFF1 is attached with an 283 instance of SF1, the service classifier would therefore send the MPLS 284 encapsulated packet through either an MPLS LSP tunnel or an IP-based 285 tunnel towards SFF1 (as shown in Figure 4 and 5 respectively). When 286 the MPLS encapsulated packet arrives at SFF1, SFF1 would know which 287 SF should be performed according to the current top label (i.e., 288 L(SF1)). Similarly, SFF1 would send the packet returned from SF1 to 289 SFF2 through either an MPLS LSP tunnel or an IP-based tunnel towards 290 SFF2 since it's known to SFF1 that SFF2 is attached with an instance 291 of SF2. When the encapsulated packet arrives at SFF2, SFF2 would do 292 the similar action as what has been done by SFF1. Since the 293 transport (i.e., the underlay) could be IPv4, IPv6 or even MPLS 294 networks, the above approach of encoding the SFC information by an 295 MPLS label stack is fully transport-independent which is one of the 296 major requirements for the SFC encapsulation [RFC7665]. 298 +----------------------------------------------- ----+ 299 | MPLS Networks | 300 | +---------+ +---------+ | 301 | | SF1 | | SF2 | | 302 | +----+----+ +----+----+ | 303 | | | +---------+ | 304 | | | |Pkt to D | | 305 | +---------+ | | +---------+ | 306 | | L(SF2) | | | | 307 | +---------+ | ^ | | | 308 | |Pkt to D | ^ | | | | | | 309 | +---------+ | | | (5)| | |(6) | 310 | (2)| | |(3) | | V | 311 | (1) | | V (4) | (7) | 312 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+ 313 |Classifier+------+ SFF1 +-------+ SFF2 +-------+ D | 314 +----------+ +---------+ +---------+ +---+---+ 315 | +---------+ +---------+ +---------+ | 316 | | L(SFF1) | | L(SFF2) | |Pkt to D | | 317 | +---------+ +---------+ +---------+ | 318 | | L(SF1) | | L(SF2) | | 319 | +---------+ +---------+ | 320 | | L(SF2) | |Pkt to D | | 321 | +---------+ +---------+ | 322 | |Pkt to D | | 323 | +---------+ | 324 +----------------------------------------------------+ 325 Figure 4: Packet Walk in MPLS underlay 326 +----------------------------------------------- ----+ 327 | IP Networks | 328 | +---------+ +---------+ | 329 | | SF1 | | SF2 | | 330 | +----+----+ +----+----+ | 331 | | | +---------+ | 332 | | | |Pkt to D | | 333 | +---------+ | | +---------+ | 334 | | L(SF2) | | | | 335 | +---------+ | ^ | | | 336 | |Pkt to D | ^ | | | | | | 337 | +---------+ | | | (5)| | |(6) | 338 | (2)| | |(3) | | V | 339 | (1) | | V (4) | (7) | 340 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+ 341 |Classifier+------+ SFF1 +-------+ SFF2 +-------+ D | 342 +----------+ +---------+ +---------+ +---+---+ 343 | +---------+ +---------+ | 344 | |IP Tunnel| |IP Tunnel| +---------+ | 345 | |to SFF1 | | to SFF2 | |Pkt to D | | 346 | +---------+ +---------+ +---------+ | 347 | | L(SF1) | | L(SF2) | | 348 | +---------+ +---------+ | 349 | | L(SF2) | |Pkt to D | | 350 | +---------+ +---------+ | 351 | |Pkt to D | | 352 | +---------+ | 353 +----------------------------------------------------+ 354 Figure 5: Packet Walk in IP underlay 356 3.3. How to Contain Metadata within an MPLS Packet 358 Since the MPLS encapsulation has no explicit protocol identifier 359 field to indicate the protocol type of the MPLS payload, how to 360 indicate the presence of metadata (i.e., the NSH which is only used 361 as a metadata containner) in an MPLS packet is a potential issue to 362 be addressed. One possible way to address the above issue is: SFFs 363 allocate two different labels for a given SF, one indicates the 364 presence of NSH while the other indicates the absence of NSH. This 365 approach has no change to the current MPLS architecture but it would 366 require more than one label binding for a given SF. Another possible 367 way is to introduce a protocol identifier field within the MPLS 368 packet as described in [I-D.xu-mpls-payload-protocol-identifier]. 370 More details about how to contain metadata within an MPLS packet 371 would be considered in the future version of this draft. 373 4. Acknowledgements 375 The authors would like to thank Loa Andersson, Andrew G. Malis, 376 Adrian Farrel, Alexander Vainshtein and Joel M. Halpern for their 377 valuable comments and suggestions on the document. 379 5. IANA Considerations 381 This document makes no request of IANA. 383 6. Security Considerations 385 It is fundamental to the SFC design that the classifier is a trusted 386 resource which determines the processing that the packet will be 387 subject to, including for example the firewall. It is also 388 fundamental to the SPRING design that packets are routed through the 389 network using the path specified by the node imposing the SIDs. 390 Where an SF is not encapsulation aware the packet may exist as an IP 391 packet, however this is an intrinsic part of the SFC design which 392 needs to define how a packet is protected in that environment. Where 393 a tunnel is used to link two non-MPLS domains, the tunnel design 394 needs to specify how it is secured. Thus the secutity 395 vulnerabilities are addressed in the underlying technologies used by 396 this design, which itself does not introduce any new security 397 vulnerabilities. 399 7. References 401 7.1. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 7.2. Informative References 410 [I-D.ietf-sfc-nsh] 411 Quinn, P. and U. Elzur, "Network Service Header", draft- 412 ietf-sfc-nsh-12 (work in progress), February 2017. 414 [I-D.ietf-spring-segment-routing-mpls] 415 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 416 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 417 data plane", draft-ietf-spring-segment-routing-mpls-10 418 (work in progress), June 2017. 420 [I-D.song-sfc-legacy-sf-mapping] 421 Song, H., You, J., Yong, L., Jiang, Y., Dunbar, L., 422 Bouthors, N., and D. Dolson, "SFC Header Mapping for 423 Legacy SF", draft-song-sfc-legacy-sf-mapping-08 (work in 424 progress), September 2016. 426 [I-D.xu-mpls-payload-protocol-identifier] 427 Xu, X., "MPLS Payload Protocol Identifier", draft-xu-mpls- 428 payload-protocol-identifier-02 (work in progress), 429 December 2016. 431 [I-D.xu-mpls-unified-source-routing-instruction] 432 Xu, X., Bryant, S., Raszuk, R., Chunduri, U., Contreras, 433 L., Jalil, L., Assarpour, H., Velde, G., Tantsura, J., and 434 S. Ma, "Unified Source Routing Instruction using MPLS 435 Label Stack", draft-xu-mpls-unified-source-routing- 436 instruction-02 (work in progress), June 2017. 438 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 439 "Encapsulating MPLS in IP or Generic Routing Encapsulation 440 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 441 . 443 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 444 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 445 Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March 446 2007, . 448 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 449 "Encapsulating MPLS in UDP", RFC 7510, 450 DOI 10.17487/RFC7510, April 2015, 451 . 453 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 454 Chaining (SFC) Architecture", RFC 7665, 455 DOI 10.17487/RFC7665, October 2015, 456 . 458 Authors' Addresses 460 Xiaohu Xu 461 Huawei 463 Email: xuxiaohu@huawei.com 464 Stewart Bryant 465 Huawei 467 Email: stewart.bryant@gmail.com 469 Hamid Assarpour 470 Broadcom 472 Email: hamid.assarpour@broadcom.com 474 Himanshu Shah 475 Ciena 477 Email: hshah@ciena.com 479 Luis M. Contreras 480 Telefonica I+D 481 Ronda de la Comunicacion, s/n 482 Sur-3 building, 3rd floor 483 Madrid, 28050 484 Spain 486 Email: luismiguel.contrerasmurillo@telefonica.com 487 URI: http://people.tid.es/LuisM.Contreras/ 489 Daniel Bernier 490 Bell Canada 492 Email: daniel.bernier@bell.ca 494 Jeff Tantsura 495 Individual 497 Email: jefftant@gmail.com 499 Shaowen Ma 500 Juniper 502 Email: mashaowen@gmail.com 503 Martin Vigoureux 504 Nokia 506 Email: martin.vigoureux@nokia.com