idnits 2.17.1 draft-kumar-ipfix-sfc-extension-05.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 (March 13, 2017) is 2599 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: 'RFC7012' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC7013' is defined on line 490, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Work group N. Kumar 3 Internet-Draft C. Pignataro 4 Intended status: Standards Track P. Quinn 5 Expires: September 14, 2017 Cisco Systems, Inc. 6 March 13, 2017 8 IPFIX Information Element extension for SFC 9 draft-kumar-ipfix-sfc-extension-05 11 Abstract 13 Service Function Chaining (SFC) is an architecture that enables any 14 operator to apply selective set of services by steering the traffic 15 through an ordered set of service functions without any topology 16 dependency. 18 This document defines the required Information Elements to represent 19 the details about service flows over any 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 September 14, 2017. 38 Copyright Notice 40 Copyright (c) 2017 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 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Network Service Header . . . . . . . . . . . . . . . . . . . 3 59 5. Flow measurement in SFC environment . . . . . . . . . . . . . 4 60 5.1. Observation Point . . . . . . . . . . . . . . . . . . . . 5 61 5.2. Flow measurement . . . . . . . . . . . . . . . . . . . . 5 62 6. Service Flow Information Elements . . . . . . . . . . . . . . 6 63 6.1. nshBaseVersion . . . . . . . . . . . . . . . . . . . . . 6 64 6.2. nshBaseFlags . . . . . . . . . . . . . . . . . . . . . . 6 65 6.3. nshBaseHeaderLength . . . . . . . . . . . . . . . . . . . 7 66 6.4. nshBaseMDType . . . . . . . . . . . . . . . . . . . . . . 7 67 6.5. nshBaseNextProtocol . . . . . . . . . . . . . . . . . . . 7 68 6.6. nshSphServicePathID . . . . . . . . . . . . . . . . . . . 8 69 6.7. nshSphServiceIndex . . . . . . . . . . . . . . . . . . . 8 70 6.8. nshMetadataMch . . . . . . . . . . . . . . . . . . . . . 9 71 6.9. nshMetadataVch . . . . . . . . . . . . . . . . . . . . . 9 72 6.10. nshIPv4NextSFF . . . . . . . . . . . . . . . . . . . . . 9 73 6.11. nshIPv6NextSFF . . . . . . . . . . . . . . . . . . . . . 10 74 6.12. nshEtherNextSFF . . . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 78 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 11 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 11.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 [RFC7665] introduces and explains SFC architecture that enables any 87 operator to apply selective set of services by steering the traffic 88 through an ordered set of service functions without any topology 89 dependency. Such ordered set of service functions to be applied to a 90 packet is defined as service function chaining. As defined in 91 [I-D.ietf-sfc-nsh], a classifier will add Network Service Header 92 (NSH) to a packet that defines the corresponding service path to 93 follow. 95 This document defines the required Information Elements to represent 96 the details about traffic flows over any Service Function Path and 97 export to Collector. 99 2. Requirements notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 3. Terminology 107 This document uses the terminologies defined in [RFC7665] and 108 [RFC7011]. In addition, this document defines the below 109 terminologies: 111 Service Flow 113 A Service Flow is defined as a set of packets over a specific 114 Service Function Path. 116 4. Network Service Header 118 Section 3.1 of [I-D.ietf-sfc-nsh] defines the Network Service Header 119 format used by the classifier to encapsulate the traffic, carrying 120 instruction about the service functions to be applied to the packet. 121 This header comprises a 4 byte base header followed by a 4 byte 122 service path header and a variable size context header. 124 In order to accomodate different needs from different use cases, 125 there are 2 types of Network Service Header defined in 126 [I-D.ietf-sfc-nsh] that preserves same Base header and Service Path 127 header while differs in Context header. NSH MD-type 1 have a fixed 128 size Mandatory Context header while NSH MD-type 2 have a variable 129 size TLV based context header. The details are below: 131 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Service Path ID | Service Index | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Mandatory Context Header | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Mandatory Context Header | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Mandatory Context Header | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Mandatory Context Header | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: NSH MD-type 1 148 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Service Path ID | Service Index | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 ~ Optional Variable Length Context Headers ~ 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 2: NSH MD-type 2 161 The details about different header fields are detailed in Section 3.4 162 and 3.5 of [I-D.ietf-sfc-nsh]. 164 5. Flow measurement in SFC environment 166 SFC introduces the concept of steering user traffic over an ordered 167 set of service function by utilizing service overlay between service 168 functions over the existing network topology. The measurement of 169 Service flow over Service Function Chain are required for various 170 application such as but not limited to below: 172 o Capacity Planning - To ensure distributing load between Service 173 Functions. 175 o OAM and troubleshooting - To measure the performance and 176 troubleshooting failures. 178 o Traffic Profiling - Determine the characteristics of traffic flow 179 over SFP. 181 o Security - To identify DoS attack or malicious intrusion. 183 In SFC environment, Classifier and Service Function Forwarder (SFF) 184 are the different nodes that handles SFC encapsulation and it is 185 appropriate to collect the Service Flow records in these nodes. 187 5.1. Observation Point 189 An Observation point in SFC environment is where Flow record for 190 Service Flow will be collected and exported to the Collector. In a 191 Classifier or SFF, an Observation point can be any physical or 192 logical port that: 194 o Forwards NSH encapsulated packets or frame from Classifier to SFF. 196 o Receives NSH encapsulated packets or frame from Classifier or 197 previous SFF. 199 o Receives NSH encapsulated packets or frame from Service Function 200 after packet treatment applied. 202 o Forwards NSH encapsulated packets or frame to next Service 203 Function Forwarder. 205 o Forwards NSH encapsulated packets or frame to Service Function for 206 packet treatment. 208 5.2. Flow measurement 210 The ability to collect Flow record for different flows observed at 211 the above range of Observation point allows an Operator to measure 212 flow properties before and after the application of any service 213 function within a service function path. An implementation SHOULD 214 support the use of Information Elements defined in section 6 to 215 measure and export the flow information. In addition, it also MAY 216 support the use of other Flow keys relevant to the underlay network 217 to collect any additional information from transport header 218 encapsulating NSH header. 220 6. Service Flow Information Elements 222 This document defines the below set of Information Elements that are 223 necessary for enabling IPFIX traffic measurement for Service Flow: 225 +---------+------------------------------------------+ 226 | ID | Name | 227 +---------+------------------------------------------+ 228 | TBD1 | nshBaseVersion | 229 | TBD2 | nshBaseFlags | 230 | TBD3 | nshBaseHeaderLength | 231 | TBD4 | nshBaseMDType | 232 | TBD5 | nshBaseNextProtocol | 233 | TBD6 | nshSphServicePathID | 234 | TBD7 | nshSphServiceIndex | 235 | TBD8 | nshMetadataMch | 236 | TBD9 | nshMetadataVch | 237 | TBD10 | nshIPv4NextSFF | 238 | TBD11 | nshIPv6NextSFF | 239 | TBD12 | nshEtherNextSFF | 240 +---------+------------------------------------------+ 242 6.1. nshBaseVersion 244 Description: 246 The Version field in NSH header. 248 Abstract Data Type: unsigned8 250 Element ID: TBD1 252 Data Type Semantic: identifier 254 Range: The valid range is 0-3. 256 Reference: 258 See Section 3.2 of [I-D.ietf-sfc-nsh] 260 6.2. nshBaseFlags 262 Description: 264 The flag bits from bit position 2 to 9 in NSH Base header. This 265 information is encoded as a bit field. 267 Abstract Data Type: unsigned8 269 Element ID: TBD2 271 Data Type Semantic: flags 273 Reference: 275 See Section 3.2 of [I-D.ietf-sfc-nsh] 277 6.3. nshBaseHeaderLength 279 Description: 281 The length of the NSH header including any optional variable TLVs. 283 Abstract Data Type: unsigned8 285 Element ID: TBD3 287 Range: The valid range is 0-255. 289 Reference: 291 See Section 3.2 of [I-D.ietf-sfc-nsh] 293 6.4. nshBaseMDType 295 Description: 297 Defines the Metadata format beyond the NSH Base header. 299 Abstract Data Type: unsigned8 301 Element ID: TBD4 303 Data Type Semantic: identifier 305 Reference: 307 See Section 3.2 of [I-D.ietf-sfc-nsh] 309 6.5. nshBaseNextProtocol 311 Description: 313 This indicates the type of the payload packet encapsulated within 314 the NSH header. 316 Abstract Data Type: unsigned8 318 Element ID: TBD5 320 Data Type Semantic: identifier 322 Reference: 324 See Section 3.2 of [I-D.ietf-sfc-nsh] 326 6.6. nshSphServicePathID 328 Description: 330 Service Path ID uniquely identifies the Service Chain which is a 331 sequence of service function to be applied on the payload packet. 333 Abstract Data Type: unsigned32 335 Element ID: TBD6 337 Data Type Semantic: identifier 339 Reference: 341 See Section 3.3 of [I-D.ietf-sfc-nsh] 343 6.7. nshSphServiceIndex 345 Description: 347 Service Index identifies the next service function to be applied 348 in the service chain. 350 Abstract Data Type: unsigned8 352 Element ID: TBD7 354 Range : The valid range is between 0-255. 356 Reference: 358 See Section 3.3 of [I-D.ietf-sfc-nsh] 360 6.8. nshMetadataMch 362 Description: 364 When MD Type is 1 on NSH header, Service Base header is followed 365 by fixed size Mandatory Context Header. The format of this header 366 varies depending on the implementation. This information element 367 is of 16 bytes size. 369 Abstract Data Type: OctetArray 371 Element ID: TBD8 373 Reference: 375 See Section 3.4 of [I-D.ietf-sfc-nsh] 377 6.9. nshMetadataVch 379 Description: 381 When MD Type is 2 on NSH header, Service Base header is followed 382 by Variable size Context Header. The format of this header varies 383 depending on the implementation. This Informational element 384 carries n octets from the NSH Service Path header. 386 A value of 64 reduced from nshBaseHeaderLength expresses how much 387 Metadata was observed, while the remainder is padding. 389 Abstract Data Type: OctetArray 391 Element ID: TBD9 393 Reference: 395 See Section 3.5 of [I-D.ietf-sfc-nsh] 397 6.10. nshIPv4NextSFF 399 Description: 401 This defines the IPv4 address of the next SFF in the Service 402 Function Path. This Information element is of size 4 bytes. 404 Abstract Data Type: ipv4Address 406 Element ID: TBD10 407 Data Type Semantic: identifier 409 Reference: 411 See Section 7.1 of [I-D.ietf-sfc-nsh] 413 6.11. nshIPv6NextSFF 415 Description: 417 This defines the IPv6 address of the next SFF in the Service 418 Function Path. This Information element is of size 16 bytes. 420 Abstract Data Type: ipv6Address 422 Element ID: TBD11 424 Data Type Semantic: identifier 426 Reference: 428 See Section 7.1 of [I-D.ietf-sfc-nsh] 430 6.12. nshEtherNextSFF 432 Description: 434 This defines the Ethernet Address of the next SFF in the Service 435 Function Path. This Information element is of size 16 bytes. 437 Abstract Data Type: macAddress 439 Element ID: TBD12 441 Data Type Semantic: identifier 443 Reference: 445 See Section 7.1 of [I-D.ietf-sfc-nsh] 447 7. IANA Considerations 449 To be Updated. 451 8. Security Considerations 453 TBD 455 9. Acknowledgement 457 The authors would like to thank Jim Guichard, Stewart Bryant, Benoit 458 Claise, Richard Furr and Joel M. Harpern for their contribution. 460 10. Contributing Authors 462 TBD 464 11. References 466 11.1. Normative References 468 [I-D.ietf-sfc-nsh] 469 Quinn, P. and U. Elzur, "Network Service Header", draft- 470 ietf-sfc-nsh-12 (work in progress), February 2017. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 478 "Specification of the IP Flow Information Export (IPFIX) 479 Protocol for the Exchange of Flow Information", STD 77, 480 RFC 7011, DOI 10.17487/RFC7011, September 2013, 481 . 483 11.2. Informative References 485 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 486 for IP Flow Information Export (IPFIX)", RFC 7012, 487 DOI 10.17487/RFC7012, September 2013, 488 . 490 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and 491 Reviewers of IP Flow Information Export (IPFIX) 492 Information Elements", BCP 184, RFC 7013, 493 DOI 10.17487/RFC7013, September 2013, 494 . 496 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 497 Chaining (SFC) Architecture", RFC 7665, 498 DOI 10.17487/RFC7665, October 2015, 499 . 501 Authors' Addresses 503 Nagendra Kumar 504 Cisco Systems, Inc. 505 7200 Kit Creek Road 506 Research Triangle Park, NC 27709 507 US 509 Email: naikumar@cisco.com 511 Carlos Pignataro 512 Cisco Systems, Inc. 513 7200 Kit Creek Road 514 Research Triangle Park, NC 27709-4987 515 US 517 Email: cpignata@cisco.com 519 Paul Quinn 520 Cisco Systems, Inc. 521 170 West Tasman Dr 522 San Jose, CA 523 US 525 Email: paulq@cisco.com