idnits 2.17.1 draft-vallamkonda-sfc-metadata-model-01.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 : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 378 has weird spacing: '...te-name attr...' == Line 380 has weird spacing: '...te-name valu...' == Line 386 has weird spacing: '...-attack attac...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 5, 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) == Missing Reference: 'RFC7665' is mentioned on line 106, but not defined == Missing Reference: 'RFC2119' is mentioned on line 129, but not defined == Unused Reference: 'RFC7365' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 449, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7365 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SFC working group S. Vallamkonda 2 Internet Draft F5 Neworks 3 Intended status: Standard Track L. Dunbar 4 Expires: November 8, 2017 Huawei 5 D. Dolson 6 Sandvine 7 July 5, 2016 9 A Framework for SFC Metadata 10 draft-vallamkonda-sfc-metadata-model-01 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may not be modified, 19 and derivative works of it may not be created, except to publish it 20 as an RFC and to translate it into languages other than English. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on November 8, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Abstract 57 Various types of metadata are applicable to Service Function 58 Chaining (SFC). Metadata can be used for many purposes, such as 59 conveying processing information, resource usage, and flow specific 60 information, from prior nodes along the Service Function Path. It 61 can also be vendor specific to leverage vendor capabilities and hint 62 to downstream Service functions dynamically for improved 63 performance. In contrast, metadata carried out of band introduces 64 latency and overhead with inefficiency and non-synchronous to real- 65 time traffic. A Service Function (SF) that needs to process the 66 information carried by the metadata may need detailed information of 67 the metadata structure carried by the packets and can have local 68 policies based on metadata. 70 The purpose of this document is to specify a framework and 71 information model on how to provision information about metadata 72 among classifiers and service functions on a service function chain. 74 Table of Contents 76 1. Introduction...................................................3 77 2. Terminology....................................................3 78 3. Use Cases of Metadata exchanged by SFs (by multiple vendors)...4 79 4. Standardized Encoding of Metadata attached to packets..........5 80 5. Framework of encoding metadata.................................5 81 6. Classes of Metadata............................................6 82 6.1. Metadata passed between controller and SFs................6 83 6.1.1. IP Endpoint Property.................................7 84 6.2. Metadata carried by payload packets.......................7 85 6.2.1. Routing Domain.......................................7 86 6.2.2. Traffic Policy Indication............................8 87 6.2.3. Flow Classification..................................8 88 7. Metadata Information and Data Model............................8 89 7.1. Objects over the Vendor registration interface............8 90 7.2. Objects over the Control Plane to SF interface............8 91 7.3. Objects encoded in the NSH carried by data packets over SF 92 path...........................................................9 93 8. Dictionary for Metadata........................................9 94 8.1. Metadata wire format.....................................10 95 9. Security Considerations.......................................11 96 10. IANA Considerations..........................................11 97 11. References...................................................11 98 11.1. Normative References....................................11 99 11.2. Informative References..................................11 100 11.3. Acknowledgments.........................................11 102 1. Introduction 104 Service Function Chaining (SFC) is a technology for directing 105 network traffic via a set of functions in a specific order. The SFC 106 architecture document [RFC7665] has in-depth description of SFC, 107 which will not be repeated here. 109 The metadata specified by [sfc-nsh] provides a mechanism for 110 additional information exchanged between nodes along the service 111 function path. 113 Even though many metadata exchanged among the service functions on a 114 path are proprietary, there are some metadata that are expected to 115 convey information from upstream service functions to downstream 116 service functions by different vendors, such as time stamp and 117 others. It is important that this information is not hardcoded and 118 static but provisioned to a Service Node. This document will first 119 describe the use cases (or the examples) of such metadata that are 120 expected to be passed among service functions. It will then 121 describe a framework on how to identify metadata, and specifies the 122 information model and corresponding data model for those metadata. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 Metadata: Information about a packet that is attached to a packet, 131 specifically within the NSH header. 133 SF: Service Function 135 3. Use Cases of Metadata exchanged by SFs (by multiple vendors) 137 The SFC architecture calls for metadata to be included in packets 138 sent between elements of a service chain. 140 Several types of Service Functions inject packets into data streams. 141 Examples include routers creating ICMP messages, or firewalls 142 creating TCP reset packets. The question that naturally arises is 143 what metadata should be attached to payload packets. This question 144 cannot be answered without knowing what each type of metadata means. 145 Further, without this there is ambiguity on limitations and 146 restrictions for services offered by the service functions on the 147 service function path. 149 +----+ +----+ +----+ 150 ---->|SFF1|----->|SFF2|------->|SFF | 151 <----| |<-----| |<-------| | 152 +----+ +----+ +----+ 153 | | | 154 | +-------+ | 155 | | | +------+ 156 +----+ +----+ +----+ | SF4 |-> 157 |SF1 | | SF2| |SF3 | +------+ 158 +----+ +----+ +----+ 159 Figure 1: Metadata passed between SFs 161 Figure 1 shows a SFC with two service functions: L3-L7 ACL with 162 firewall (SF1) and second with DPI (SF2). The path can be symmetric 163 or asymmetric on per pathID/flow basis. 165 SF1 and SF2 are different NFVs providing different services to flow. 167 Here are some examples that SF2 needs packets to carry the 168 processing information done by SF1: 170 SF1 may at real-time attach DoS information for the next SF in 171 downstream. SF1 provides the hint and it is up to the downstream SFs 172 to process it or ignore it. However if a downstream SF chooses to 173 processes, it needs standardized metadata data model to understand 174 the hint encoded by SF1 in packets. 176 SF1 may send protocol flood (DNS/HTTP/SYN) indicators in metadata. 177 This may be attached to packet based on local policy that can be 178 time orevent based. The downstream SF2 would need to be aware of a 179 standardized format (the proposal) to interpret the data. Then it 180 may process the packet per local policy. 182 Without standard method and framework, service functions can't pass 183 meaningful metadata to other SFs on a service function chain to 184 achieve sophisticated service functions. 186 4. Standardized Encoding of Metadata attached to packets 188 Metadata could be self-describing or there could be control-plane 189 descriptions of metadata encoding in the form of a metadata 190 dictionary (or a combination thereof). In either case, there needs 191 to be a language for describing the meaning of metadata context 192 vocabulary. 194 This document provides the analysis of various types metadata, the 195 framework to carry metadata across SFs or SFF on a SFC path, and the 196 corresponding information and data model for some well-known 197 metadata that can be useful for services functions. 199 Note: this document does not document all potential metadata used by 200 SFs, because there are many types of proprietary metadata exchanged 201 among SFs. 203 5. Framework of encoding metadata 205 To minimize the extra bytes added to packets in NSH, it is necessary 206 to have compact encoding of the metadata carried by data packets. 207 Achieving this goal will need control plane to inform the encoding 208 mechanisms to SFs via out of band control channels. 210 In addition, it is necessary for vendors to register the metadata 211 that their corresponding SFs can send and receive, as depicted in 212 the following diagram: 214 +----------------------------------------------+ 215 | | 216 | SFC Control Plane +-------+ 217 +-------| | | 218 | | | |C5 219 C1 +------^-----------^-------------^-------------+ | 220 +---------------------|C3---------|-------------|-------------+ | 221 | | +----+ | | | v 222 | | | SF | |C2 |C2 | +------------+ 223 | | +----+ | | | | SF metadata| 224 | +----V--- --+ | | | | |registration| 225 | | SFC | +----+ +-|--+ +----+ | +------------+ 226 | |Classifier |---->|SFF |----->|SFF |------->|SFF | | 227 | | Node |<----| |<-----| |<-------| | | 228 | +-----------+ +----+ +----+ +----+ | 229 | | | | | 230 | |C2 ------- | | 231 | | | | +-----------+ C4 | 232 | V +----+ +----+ | SFC Proxy |--> | 233 | | SF | |SF | +-----------+ | 234 | +----+ +----+ | 235 | |C3 |C3 | 236 | SFC Data Plane Components V V | 237 +-------------------------------------------------------------+ 238 Figure 2: SFC Architecture Extension for Metadata 240 SF Registration Interface (C5) is for vendors of the SFs to inform 241 the controller on the metadata their SFs supported. The information 242 over this interface should include: 244 SF vendor name ABC 245 metadata objects 246 Objects passed over the Controller - SF interface (C3) 247 Objects carried by data packets, i.e. encoded in the packets'NSH 248 Actions that can be performed on the SFs 250 6. Classes of Metadata 252 6.1. Metadata passed between controller and SFs 254 This section describes the metadata not carried by payload packets, 255 but instead communicated between controller and SFs, i.e. over the 256 C3 interface of the Figure 2 above. 258 The metadata over the C3 interface should carry the policies 259 associated with each metadata encoding carried by the packets 260 through the SFs (in NSH header). 262 6.1.1. IP Endpoint Property 264 A metadata type indicates a property of an IP endpoint of either the 265 source or the destination IP address in the encapsulated 266 conversation. 268 As examples, the metadata could indicate a user's class of service, 269 that the endpoint is flagged as the subject of an attack or may 270 indicate the account number to charge the user's traffic. 272 Injected packets may clone this type of metadata from other packets 273 having the same IP endpoint, for packets in the same direction. 275 6.2. Metadata carried by payload packets 277 The metadata carried by payload packets need to be encoded in the 278 NSH header. However, the interpretation of the encoding has to be 279 exchanged between controller and the SFs. 281 6.2.1. Routing Domain 283 A Routing Domain metadata type indicates the specific private 284 network for the packet. A policy could be "Neither traffic nor 285 information may cross between domains". Service functions must use 286 the domain to discriminate between overlapping private IPv4. When a 287 packet exits SFC (has the NSH header removed), a Routing Domain 288 metadata can indicate which routing table should be used to forward 289 the packet. E.g., Routing Domain metadata allows support of multiple 290 private networks within the same SFC cluster. 292 Metadata of this type is generally attached by the classifier. In 293 general, this type of metadata must not be removed or modified by 294 SFs (except in the case when the intention is to route traffic 295 between domains). 297 Injected packets must include this type of metadata, to indicate the 298 routing domain the packet is being injected into. 300 6.2.2. Traffic Policy Indication 302 This metadata type indicates a class of treatment for customer 303 traffic, which may be attached by the classifier or another SF in 304 the chain. 306 Class values are assigned and administered by the operator. 308 This type of metadata is not required on every packet. If missing, 309 a default policy can be applied. 311 The most recent value can be cached for the customer IP address; 312 injected packets can use the cached value. 314 6.2.3. Flow Classification 316 This metadata type indicates a flow classification. 318 As examples, the metadata could indicate a DPI classification result 319 or whether the flow has been selected for differentiated service. 321 This type may be attached by the classifier or another SF in the 322 chain. It may also be overwritten by SFs along the chain. 324 This type of metadata is a property of the session 5-tuple. 325 Injected packets may clone this property from other packets of the 326 flow, for packets in the same direction. 328 7. Metadata Information and Data Model 330 7.1. Objects over the Vendor registration interface 332 7.2. Objects over the Control Plane to SF interface 334 The purpose of the control plane interface to SF is to describe to 335 the classifier and service functions both the encoding and semantics 336 of each type of metadata. 338 The model of each instance of metadata should include: 340 - Keyword name 341 - Long description 342 - Data type (integer, string, enumeration of type X, timestamp, 343 indirect handle to Y, etc.) 344 - The class of metadata is it (see section 6)? 345 - how is it transported? 346 - in a MD-Type1 slot number 1, , 4 347 - in a MD-Type2 TLV, with code number N and vendor type V. 349 "Indirect handle" indicates that the value is a key into a table 350 transferred out of band. E.g., it could be a handle for a subscriber 351 identity or it could be a handle for a mobile cell sector. 353 TODO: model in YANG. 355 7.3. Objects encoded in the NSH carried by data packets over SF path 357 In the data packets, metadata items are identified by either 359 (a) Position within the fixed MD-Type 1 header 361 (b) Vendor/Code within the variable-length MD-Type 2 header. 363 The position or vendor/code is to be conveyed in the control plane 364 ahead of arrival of the information in the data packets. 366 8. Dictionary for Metadata 368 The metadata can be defined by vendor in common published format in 369 ASCII file. This file could be used by other vendors of Service 370 Nodes (SF/SFFs) to recognize the metadata and its content 371 dynamically. The metadata can be used by local policies on Service 372 Node if needed. This common format encourages rapid deployment and 373 supports interoperability on real-time traffic without restrictions 374 of hardcoding or worry about dynamically changing capabilities of 375 Service nodes in SFC. 377 VENDOR-DEF vendor_name vendor_id 378 VENDOR-ATTRIBUTE attribute-name attribute_ID syntax_type 379 (DEFAULT, LENGTH, etc) flags 380 ATTRIBUTE-VALUE attribute-name value_name 381 value_number_associated 382 Example: 384 VENDOR-DEF ABC 100 385 VENDOR-ATTRIBUTE dns-attack 10 DEFAULT 386 ATTRIBUTE-VALUE dns-attack attack_state 1 (suspect), 2 387 (found). 389 8.1. Metadata wire format 391 The above dictionary format of metadata specification could be 392 translated in a common wire format for interoperability. Some data 393 will be passed over the C5 (Registration) interface and others will 394 be passed over the C3 interface in the Figure 2 above. 396 Editor's note: details will be added after the framework is 397 accepted. 399 Thus the salient benefits of this metadata framework are: 401 o It is independent of capabilities discovery of SF by Controller which 402 is configuration and provision. It is different from Metadata which 403 is real time on per flow and per packet. 404 o The metadata dictionary can be uploaded to Controller which is the 405 central entity which can download to SFs during provision of SFs as 406 OOB initially and later as needed along with its local policy for 407 flows and metadata. 408 o Metadata flags can specify additional information to downstream 409 Service Nodes in chain such as donot-delete, append-only, etc. 410 o The proposal does not limit the semantics or content context of 411 Metadata at any node. The content can be local resource such as CPU, 412 Storage indicators affected by the flow and/or flow specific service 413 information. 414 o It eliminates hardcoding, static prototyping and type guessing by 415 products and versions. 416 o It is independent of any specific hardware. 417 o The framework is portable across SFC technologies and SFC protocols. 418 o The framework can be used to enhance definitions by extending to 419 subtypes within both generic and vendor global categories. 421 o Scale: It supports growth of vendors, their product types and 422 capabilities with versions and ease of adding attribute and types. 423 o The highlevel class classification would be generic and vendor where 424 generic would be applicable for all NFVs/Services of same category 425 (minimum subset support across all products to be compatible), and 426 vendor specific are enhanced based particularly on a vendor and their 427 product. Both of these can be specific as any data format as JSON, 428 yang, etc. 430 9. Security Considerations 432 This draft does not introduce any new security considerations beyond 433 what may be present in proposed solutions. 435 10. IANA Considerations 437 This document requires no IANA actions. RFC Editor: Please remove 438 this section before publication. 440 11. References 442 11.1. Normative References 444 [RFC7365] Lasserre, M. et al., "Framework for data center (DC) 445 network virtualization", October 2014. 447 11.2. Informative References 449 [RFC7348] Mahalingam, M. et al., " Virtual eXtensible Local Area 450 Network (VXLAN): A Framework for Overlaying Virtualized 451 Layer 2 Networks over Layer 3 Networks", August 2014. 453 11.3. Acknowledgments 455 Thanks are to. 457 This document was prepared using 2-Word-v2.0.template.dot. 459 Authors' Addresses 461 Sunil Vallamkonda 462 F5 Networks 463 3545 N. 1st Street 464 San Jose, CA 95134 465 USA 467 Phone: +1 408 274 4820 468 Email: sunilvk@f5.com 470 Linda Dunbar 471 Huawei Technologies 472 5340 Legacy Drive, Suite 1750 473 Plano, TX 75024, USA 474 Phone: (469) 277 5840 475 Email: ldunbar@huawei.com 477 David Dolson 478 Sandvine 479 408 Albert Street 480 Waterloo, ON N2L 3V3 481 Canada 483 Phone: +1 519 880 2400 484 Email: ddolson@sandvine.com