idnits 2.17.1 draft-cabellos-sfc-map-assisted-proxy-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 383 lines 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2015) is 3109 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-11 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-threats-13 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-01 == Outdated reference: A later version (-12) exists of draft-rodrigueznatal-lisp-multi-tuple-eids-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Cabellos 3 Internet-Draft UPC-BarcelonaTech 4 Intended status: Experimental S. Barkai 5 Expires: April 21, 2016 B. Perlman 6 Hewlett Packard Enterprise 7 V. Ermagan 8 F. Maino 9 Cisco Systems Inc 10 A. Rodriguez-Natal 11 UPC-BarcelonaTech 12 October 19, 2015 14 Map-Assisted SFC Proxy using LISP 15 draft-cabellos-sfc-map-assisted-proxy-00.txt 17 Abstract 19 This document specifies a map-assisted SFC proxy. The SFC proxy uses 20 the LISP Mapping System to store the NSH header indexed by 5-tuple, 21 before decapsulating and forwarding the packet to the legacy 22 function. After the function has processed the packet, the SFC proxy 23 retrieves the NSH header from the Mapping System to SFC encapsulate 24 it. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 21, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction 67 2. Overview 68 2.1. Flow example 69 2.2. Benefits of Map-Assisted SFC Proxies 70 3. Encoding of 5-tuple and NSH in LISP messages 71 3.1. Encoding of 5-tuple Index 72 3.2. Encoding of NSH Header 73 4. SFC Proxy Processing 74 5. Security Considerations 75 6. IANA Considerations 76 7. References 77 7.1. Normative References 78 7.2. Informative References 79 Authors' Addresses 81 1. Introduction 83 The Locator/ID Separation Protocol (LISP) [RFC6830] is an overlay 84 protocol that creates two namespaces: EIDs (End-point IDentifiers) 85 and RLOCs (Routing LOCators). The LISP Mapping System stores the 86 mappings between both namespaces, LISP provides a standard way for 87 its data-plane elements, called xTRs, to store and retrieve mappings 88 from the Mapping System to make forwarding decisions: Map-Request, 89 Map-Request and Map-Reply. Finally, LISP also offers a flexible 90 syntax for both EIDs and RLOCs by means of LCAFs [I-D.ietf-lisp-lcaf] 91 to define what is an EID and what is an RLOC. 93 With such architecture in place, the LISP control-plane represents a 94 programmable protocol. The Mapping System is a logically centralized 95 database that stores network state, which is retrieved by data-plane 96 nodes in a standard way to make decisions. Any external control 97 plane can program the LISP Mapping System while any data-plane node 98 can be map-assisted. 100 This document specifies a map-assisted SFC proxy 101 [I-D.ietf-sfc-architecture]. An SFC acts on behalf the SFC unaware 102 functions on the SFC domain. Basically the SFC Proxy removes the SFC 103 encapsulation, forwards the packet to the SFC unaware function, 104 receives back the packets and reapplies an SFC encapsulation. 105 Specifically this document specifies how to map-assist the 106 encapsulation operation by means of the LISP control-plane. 108 In short, the SFC Proxy before decapsulating the packet stores (Map- 109 Registers) the NSH header (including Context Headers) 110 [I-D.ietf-sfc-nsh] in the LISP Mapping System indexed by the 5-tuple 111 of the packet {5-tuple->NSH}. After the SFC unaware function has 112 processed the packet, the proxy retrieves (Map-Requests based on the 113 5-tuple of the packet) the NSH+Context headers to SFC encapsulate the 114 packet. 116 This has two main benefits; first the SFC proxy is stateless and 117 connectionless. Second, in some cases the legacy function may change 118 the headers of the original packet, the SFC control plane can change 119 the stored mapping {5-tuple->NSH} in the Mapping System accordingly 120 and allow for fast reclassification by the proxy. 122 2. Overview 124 2.1. Flow example 126 This section shows a flow example of map-assisted SFC Proxy 127 processing: 129 +------------+ +------------+ 130 |LISP Mapping| |SFC Control | 131 | System | | Plane | 132 | | | | 133 +------------+ +------------+ 134 ^ 135 | 136 Map-Register 137 {5-tuple->NSH} 138 | 139 | +----------+ 140 +----------+ +----+-----+ | SFC | 141 | SFF |------->|SFC Proxy |------->| Unaware | 142 +----------+ +----------+ | Function | 143 +----------+ 144 Figure 1.- SFC Proxy Decapsulation 146 1. An SFC proxy receives an SFC encapsulated packet as defined in 147 the SFC architecture [I-D.ietf-sfc-architecture]. 149 2. The SFC proxy Map-Registers the SFC encapsulation in the LISP 150 Mapping System (figure 1), this includes the entire NSH header: 151 Base Header, Service Header and Context Headers. The NSH header 152 is indexed by the 5-tuple of the payload. Both the 5-tuple and 153 the NSH header are encoded using two different LISP LCAFs, 154 further details can be found in Section 3. 156 3. The SFC proxy forwards the packet to the SFC unaware function as 157 specified in the SFC architecture [I-D.ietf-sfc-architecture]. 159 4. The SFC unaware function processes the packet and sends it back 160 to the SFC proxy. 162 5. Upon reception of the processed packet, the SFC proxy must SFC 163 encapsulate the packet. For this it retrieves the NSH header 164 from the LISP Mapping System using a Map-Request indexed by the 165 5-tuple of the received packet (figure 2). Once the packet is 166 SFC encapsulated, the SFC proxy forwards it as defined in the SFC 167 architecture [I-D.ietf-sfc-architecture]. 169 +------------+ Reclassificaton +------------+ 170 |LISP Mapping|{New 5-tuple->NSH}|SFC Control | 171 | System | <----------------| Plane | 172 | | | | 173 +---------+--+ +------------+ 174 ^ | 175 | Map-Reply 176 | {NSH} 177 Map-Request | 178 {5-tuple?} | 179 | v +----------+ 180 +----------+ ++---------+ | SFC | 181 | SFF |<-------|SFC Proxy |<-------| Unaware | 182 +----------+ +----------+ | Function | 183 +----------+ 184 Figure 2.- SFC Proxy Encapsulation 186 2.2. Benefits of Map-Assisted SFC Proxies 188 The Map-Assisted encapsulation described in step 5 of the previous 189 section brings the following benefits to the SFC architecture: 191 o The map-assisted SFC proxy is connectionless and stateless, as 192 such it does not need to store state to forward packets from/to 193 SFC unaware functions. Since the required state is stored in the 194 Mapping System, any other SFC proxy can receive the processed 195 packets and SFC encapsulate them. 197 o In some scenarios the legacy functions may change the packet 198 header and hence, the SFC proxy must re-classify it. With map- 199 assisted SFC proxies, the SFC control-plane can change the stored 200 state on the Mapping System to accordingly and allow map-assisted 201 stateless reclassification by the SFC-Proxy. This is illustrated 202 in the figure 2 by the "Reclassification" arrow. How the SFC 203 control plane updates information on the LISP Mapping system is 204 out of the scope of this document. In any case, please note that 205 the SFC proxy still operates as described in this document and 206 remains unaware of the reclassification. 208 3. Encoding of 5-tuple and NSH in LISP messages 210 This section describes the LCAFs used to encode both the 5-tuple and 211 NSH header (Base, Service Path and Context Headers). The 5-tuple 212 index is encoded in a LISP record as an EID while the NSH header as 213 an RLOC. 215 3.1. Encoding of 5-tuple Index 217 The Multiple-tuple EID [I-D.rodrigueznatal-lisp-multi-tuple-eid] is 218 used to encode the 5-tuple EID that indexes the NSH header, 219 specifically using the "Exact Match" mode and EID mask-ken set to 0. 221 3.2. Encoding of NSH Header 223 The NSH header (Base Header, Service Path Header and Context Headers) 224 [I-D.ietf-sfc-nsh] is encoded using the JSON Data Model Type LCAF as 225 defined in [I-D.ietf-lisp-lcaf]. The header is encoded in binary 226 format using BSON [BSON] as a single binary field (subtype "Generic 227 binary subtype"): 229 document ::= int32 binary "\x00" 231 A LISP record only transports a single NSH header and all the "Loc" 232 fields are ignored except "Loc-AFI" and "Locator". 234 4. SFC Proxy Processing 236 This section specifies the behavior of a map-assisted SFC Proxy, the 237 proxy acts as specified in [I-D.ietf-sfc-architecture] with the 238 following exceptions. 240 Inbound: For traffic received from the SFF and before removing the 241 SFC encapsulation, the proxy Map-Registers the NSH header (Base, 242 Service and Context) using the 5-tuple and JSON LCAFs defined in 243 Section 3, the 5-tuple is applied to the original payload. After 244 this the SFC Proxy acts as specified in [I-D.ietf-sfc-architecture]. 246 Outbound: For returning traffic from the legacy SF, the SFC Proxy 247 Map-Requests using a 5-tuple lookup LCAF and receives back the entire 248 NSH header encoded using the JSON LCAF. The proxy applies the NSH 249 encapsulation, decrements the Service Index and forwards the traffic 250 as specified in [I-D.ietf-sfc-architecture]. 252 In addition to this please note the following: 254 o In some scenarios the SFC Control Plane may have changed the 255 {5-tuple->NSH} mapping to account for changes made by the legacy 256 SF to the payload. 258 o The LISP Mapping System can identify the registering and 259 requesting SFC Proxy using the RLOC of the Map-Register and Map- 260 Request message respectively. This is useful when the inbound and 261 outbound SFC Proxies are different. 263 o This document assumes that the payload is IP (IPv4 or IPv6) and a 264 transport header (TCP or UDP). Further revisions of this document 265 will consider other payloads. 267 5. Security Considerations 269 The map-assisted SFC Proxy does not introduce additional security 270 considerations beyond the ones described in 271 [I-D.ietf-sfc-architecture] and [I-D.ietf-lisp-threats]. 273 6. IANA Considerations 275 This memo includes no request to IANA. 277 7. References 279 7.1. Normative References 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, 283 DOI 10.17487/RFC2119, March 1997, 284 . 286 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 287 Locator/ID Separation Protocol (LISP)", RFC 6830, 288 DOI 10.17487/RFC6830, January 2013, 289 . 291 7.2. Informative References 293 [BSON] MongoDB, , ""BSON - Binary JSON Specification 294 "http://bsonspec.org/"", June 2015. 296 [I-D.ietf-lisp-lcaf] 297 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 298 Address Format (LCAF)", draft-ietf-lisp-lcaf-11 (work in 299 progress), September 2015. 301 [I-D.ietf-lisp-threats] 302 Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats 303 Analysis", draft-ietf-lisp-threats-13 (work in progress), 304 August 2015. 306 [I-D.ietf-sfc-architecture] 307 Halpern, J. and C. Pignataro, "Service Function Chaining 308 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 309 in progress), July 2015. 311 [I-D.ietf-sfc-nsh] 312 Quinn, P. and U. Elzur, "Network Service Header", draft- 313 ietf-sfc-nsh-01 (work in progress), July 2015. 315 [I-D.rodrigueznatal-lisp-multi-tuple-eid] 316 Rodriguez-Natal, A., Cabellos-Aparicio, A., Barkai, S., 317 Ermagan, V., Maino, F., Lewis, D., and D. Farinacci, 318 ""LISP support for Multi-Tuple EIDs" draft-rodrigueznatal- 319 lisp-multi-tuple-eids-00 (work in progress)", June 2015. 321 Authors' Addresses 323 Albert Cabellos 324 UPC-BarcelonaTech 325 c/ Jordi Girona 1-3 326 Barcelona, Catalonia 08034 327 Spain 329 Email: acabello@ac.upc.edu 331 Sharon Barkai 332 Hewlett Packard Enterprise 333 3000 Hanover Street 334 Palo Alto, CA 335 USA 337 Email: sharon.barkai@hpe.com 339 Barak Perlman 340 Hewlett Packard Enterprise 341 3000 Hanover Street 342 Palo Alto, CA 343 USA 345 Email: barak.perlman@hpe.com 347 Vina Ermagan 348 Cisco Systems Inc 349 170 W Tasman Drive 350 San Jose, CA 95134 351 USA 353 Email: vermagan@cisco.com 355 Fabio Maino 356 Cisco Systems Inc 357 170 W Tasman Drive 358 San Jose, CA 95134 359 USA 361 Email: fmaino@cisco.com 363 Alberto Rodriguez-Natal 364 UPC-BarcelonaTech 365 c/ Jordi Girona 1-3 366 Barcelona, Catalonia 08034 367 Spain 369 Email: arnatal@ac.upc.edu