idnits 2.17.1 draft-browne-ietf-sfc-nsh-timestamp-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: ---------------------------------------------------------------------------- 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 -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC0791' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC6071' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'SFC-PS' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'SFC-arch' is defined on line 635, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Browne 3 Internet-Draft A. Chilikin 4 Intended status: Standards Track B. Ryan 5 Expires: April 20, 2016 Intel 6 October 19 2015 8 Network Service Header Time Stamping 9 draft-browne-ietf-sfc-nsh-timestamp-00 11 Abstract 13 This draft describes a method of time-stamping Network Service Header 14 (NSH) encapsulated packets or frames on service chains in order to 15 measure accurately hop by hop performance delays of application flows 16 carried within the chain. This method may be used to monitor 17 performance and highlight problems with virtual links (vlinks) VNFs 18 or PNFs on the rendered service path (RSP). 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 20, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2.1. Definition of Terms . . . . . . . . . . . . . . . . . . 3 62 3. NSH Time stamping . . . . . . . . . . . . . . . . . . . . . 5 63 3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2 Operation . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.3 Implementation . . . . . . . . . . . . . . . . . . . . . . 8 66 4. NSH Time stamping Encapsulation . . . . . . . . . . . . . . . 9 67 5. Hybrid Models . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.1 Targeted VNF Time Stamp . . . . . . . . . . . . . . . . . 12 69 6. Fragmentation Considerations . . . . . . . . . . . . . . . . 12 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 8. Open Items for WG Discussion . . . . . . . . . . . . . . . . 12 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 Network Service Header (NSH) as defined by draft-ietf-sfc-nsh-00 80 defines a method to insert a service-aware header in between payload 81 and transport headers. This allows a great deal of flexibility and 82 programmability in the forwarding plane allowing user flows to be 83 programmed on the fly for the appropriate service functions (SFs). 85 Whilst NSH promises a compelling vista of operational agility for 86 Service Providers, many service providers are concerned about losing 87 service visibility in the transition from physical appliance SFs to 88 virtualized SFs running in the NFV domain. This concern increases 89 when we consider that many service providers wish to run their 90 networks seamlessly in 'hybrid' mode: - that is, whereby they wish to 91 mix physical and virtual SFs and run services seamlessly between the 92 two domains. 94 This draft describes a generic method to monitor and debug service 95 chains and application performance of the flows within a service 96 chain. This method is compliant with hybrid architectures in which 97 VNFs and PNFs are freely mixed in the service chain. This method also 98 is flexible to monitor an entire chain performance or part thereof as 99 desired. Please refer to draft-ietf-sfc-nsh-00.txt as background 100 architecture for the method described in this document. 102 The method described in this draft is not an OAM protocol like Y.1731 103 or Y.1564 for example. As such it does not define new OAM packet 104 types or operation. Rather it monitors the service chain performance 105 for subscriber payloads and indicates subscriber QoE rather than 106 out-of-band infrastructure metrics. 108 2.1. Definition of Terms 110 Classification: Locally instantiated policy and 111 customer/network/service profile matching of traffic flows for 112 identification of appropriate outbound forwarding actions. 114 First TS Node (FTSN) - Must mark packet correctly. Must understand 5 115 tuple information in order to match TS Controller flow table. 117 Last TS Node (LTSN) - must read all MD & export to system performance 118 statistics agent or repository. Should also send NSH header - the SI 119 will indicate if a PNF(s) was at the end of the chain. The LTSN 120 changes the SPI in order that the underlay routes the metadata back 121 directly to the TSDB. 123 Network Node/Element: Device that forwards packets or frames based 124 on outer header information. In most cases is not aware of the 125 presence of NSH. 127 Network Overlay: Logical network built on top of existing network 128 (the underlay). Packets are encapsulated or tunneled to create the 129 overlay network topology. 131 Network Service Header: Data plane header added to frames/packets. 132 The header contains information required for service chaining, as 133 well as metadata added and consumed by network nodes and service 134 elements. 136 NSH Proxy: Acts as a gateway: removes and inserts SH on behalf of a 137 service function that is not NSH aware. 139 PNF: Physical Network Function 140 Service Classifier: Function that performs classification and 141 imposes an NSH. Creates a service path. Non-initial 142 (i.e. subsequent) classification can occur as needed and can alter, 143 or create a new service path. 145 Service Function (SF): A function that is responsible for specific 146 treatment of received packets. A service function can act at the 147 network layer or other OSI layers. A service function can be virtual 148 instance or be embedded in a physical network element. One of 149 multiple service functions can be embedded in the same network 150 element. Multiple instances of the service function can be enabled in 151 the same administrative domain. 153 Service Function Chain (SFC): A service function chain defines an 154 ordered set of service functions that must be applied to packets 155 and/or frames selected as a result of classification. The implied 156 order may not be a linear progression as the architecture allows for 157 nodes that copy to more than one branch. The term service chain is 158 often used as shorthand for service function chain. 160 Service Function Path (SFP): The instantiation of a SFC in the 161 network. Packets follow a service function path from a classifier 162 through the requisite service functions. 164 TS Controller: The TS Controller may be part of the service chaining 165 application, SDN controller, NFVO or any MANO entity. For clarity we 166 define the TS Controller separately here as the central logic that 167 decides what packets to timestamp and how. The TS Controller 168 instructs the classifier on how to mark the NSH header. 170 Time Stamp Control Plane (TSCP) - the control plane between the FTSN 171 and the TS Controller. 173 Time Stamp Database (TSDB) - external storage of Metadata for 174 reporting, trend analysis etc. 176 UTC: Real Time Clock 178 VNF: Virtual Network Function 180 3. NSH Time stamping 182 As a generic architecture, please refer to figure 1 below:- 184 TS 185 Controller 186 | TSDB 187 | TSCP Interface | 188 ,---. ,---. ,---. ,---. 189 / \ / \ / \ / \ 190 ( SCL )-------->( SF1 )--------->( SF2 )--------->( SFN ) 191 \ FTSN/ \ / \ / \ LTSN/ 192 `---' `---' `---' `---' 194 Figure 1: Logical roles in NSH Time Stamping 196 The TS Controller will most probably be part of the SFC controller 197 but is explained separately in this document for clarity. The TS 198 Controller is responsible for initiating start/stop timestamp 199 requests to the SCL or FTSN, and also for distributing timestamp NSH 200 policy into the service chain via the Time Stamping Control Plane 201 (TSCP) interface. 203 The First Time Stamp Node (FTSN) will typically be part of the 204 service classifier but again is called out as separate logical entity 205 for clarity. The FTSN is responsible for marking NSH MD Type 0x2 206 fields for the correct flow with the appropriate NSH fields. This 207 tells all upstream nodes how to behave in terms of time stamping at 208 VNF ingress,egress or both, or ignoring the timestamp NSH metadata 209 completely. The FTSN also writes the UTC value into the header so the 210 chain:flow performance can be compared to previous samples for 211 offline analysis. The FTSN should return an error to the TS 212 Controller if not synchronized to time-of-day and forward the packet 213 along the service-chain unchanged. 215 SF1, SF2 timestamp the packets as dictated by the FTSN and process 216 the payload as per normal. 218 Note 1: The exact location of the timestamp creation may not be in 219 the VNF itself as referenced in section 3.3. 221 Note 2: Special cases exist where some of the SFs (PNFs or VNFs) are 222 NSH-unaware. This is covered in section 6. 224 The Last Time Stamp Node (LTSN) should export all NSH time stamp 225 metadata to the Time stamp Database (TSDB) for offline analysis, 226 strip the entire header and forward the packet to the IP next hop. In 227 fully virtualized environments the LTSN will be co-located with the 228 VNF that decrements NSH SI to zero. Corner cases exist whereby this 229 is not the case and is covered in section 6. 231 3.1 Prerequisites 233 In order to guarantee metadata accuracy, all servers hosting VNFs 234 should be synchronized from a centralized stable clock. As PNFs do 235 not time stamp there is no need for synchronize. There are two types 236 of synchronization required. 237 A) Low accuracy time-of-day as described in 1 below and 238 B) High accuracy (sub-microsecond) as described by 2 or 3 below. 240 1. Each platform (including the TS Controller) should synch their 241 system real-time-clock from an NTP server. This is used to mark 242 the metadata in the chain. The UTC format is written by the first 243 SF in the chain to apply a timestamp. NTP accuracy can vary by 244 several milliseconds between locations. This is not an issue as 245 the UTC stamp is merely being used as a reference inserted into 246 the TSDB for performance monitoring. It is not a reference for the 247 timestamp itself. 249 2. Synchronous Ethernet. Each platform should be synchronized to a 250 primary reference clock (PRC) and use G.8261, G.8262 and G.8264 251 ITU specifications. 253 3. IEEE 1588: Each platform should be frequency-synchronized to a 254 primary reference clock (PRC) and use IEEE 1588-2008 for frequency 255 distribution. 257 If a SF is not synchronized at the moment of time stamping, it should 258 indicate synch status in the NSH header. This is described in more 259 detail in section 5. 261 By synchronizing the network in this way, the time stamping operation 262 is independent of the current RSP, whether the entire chain is served 263 by one NFVI-PoP or by multiple. Indeed the time stamp MD can indicate 264 where a chain has been moved due to a resource starvation event as 265 indicated in the figure 2 below, between VNF 3 and VNF 4 at time B. 267 Delay 268 | v 269 | v 270 | x 271 | x x = UTC time A 272 | xv v = UTC time B 273 | xv 274 | xv 275 |______|______|______|______|______|_____ 276 VNF1 VNF2 VNF3 VNF4 VNF5 278 Figure 2: Flow performance in a service chain 280 Regarding draft-ietf-sfc-nsh-00, section 3.2. We would request that 281 the text is changed to reflect that MD-Type 0x2 MUST be supported to 282 aid methods like the one outlined in this draft. 284 3.2 Operation 286 Section 3.5 of draft-ietf-sfc-nsh-00.txt defines NSH metadata type 2 287 encapsulation as per the figure below. Please refer to the draft for 288 detailed explanation. Time stamed flows will use this format. 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Service Path ID | Service Index | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | TLV Class | Type |R|R|R| Len | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Variable Metadata | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 3: NSH MD type 2 Encapsulation 302 Flow Selection 304 The TS Controller should maintain a list of flows within each 305 service chain to be monitored. This flow table should be in the 306 format SPI:5 tuple ID. The TS Controller should map these pairs to 307 unique Flow IDs per service chain within the extended NSH header 308 specified in this draft. The TS Controller should instruct the FTSN 309 node initiate timestamping on flow table match. The TS Controller 310 should also tell the classifier the duration of the time stamping 311 operation, either by number of packets in the flow or a duration in 312 UTC format. 314 In this way the system can monitor the performance of an individual 315 subscriber in a chain or just a specific application the subscriber 316 is running. 318 The TS Controller should write the list of monitored flows into the 319 TSDB for correlation of performance data. Thus when the TSDB 320 receives data from the LTSN it understands to which flow the data 321 pertains. 323 The association of source IP to subscriber identity is outside the 324 scope of this draft and will vary by network application. For 325 example the method of association of a source IP to IMSI in mobile 326 cores will be different to how a CPE with NAT function may be 327 chained in an enterprise NFV application. 329 TSCP Interface 331 A new timestamp control plane (TSCP) interface is required between 332 the TS Controller and the FTSN or classifier. This interface:- 333 - Communicates which chains:flows to timestamp. This can be a 334 specific chain:flow combination or include wildcards for 335 monitoring subscribers across multiple chains or multiple flows 336 within one chain. 337 - How the timestamp should be applied (ingress, egress, both or 338 specific) 339 - When to stop time stamping 341 Exact specification of TSCP is for further study. 343 3.3 Implementation 345 Whilst applying and operating on the timestamps themselves incur an 346 additional small delay in the service chain it can be assumed that 347 these additional delays are all relative for the flow in question. 348 Thus whist the absolute timestamps may not be fully accurate for 349 normal non-time stamped traffic they can be assumed to be relative. 351 It is assumed that the method described in this document would only 352 operate on a small percentage of user flows. The service provider 353 may choose a flexible policy in the TS Controller to time stamp a 354 selection of user-plane every minute for example to highlight any 355 performance issues. Of course the TS Controller can stress test an 356 individual flow or chain should a deeper analysis be required. We 357 can expect that this type of deep analysis has an impact on the 358 performance of the chain itself whilst under investigation. The 359 impact will be dependent on vendor implementation and outside the 360 scope of this document. 362 The timestamp may be applied at various parts of the NFV 363 architecture. The VNF, hypervisor (assuming no SRIOV pass-through), 364 vSwitch or NIC are all potential locations that's can append the 365 packet with the requested timestamp. Whilst it is desirable to 366 timestamp as close as possible to the VNF for performance accuracy, 367 the exact location of the timestamp application is outside the scope 368 of this document, but should be consistent across the individual 369 TS Controller domain. 371 4. NSH Time stamping Encapsulation 373 NSH time stamping encapsulation is shown below in figure 4:- 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | NextProto=0x0 | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Service Path ID | Service Index | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | TLV Class=0x10 | Type=0x01 |R|R|R| Len | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | UTC Reference | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Syn |R|E|I|TSI|TS Service Indx| Flow ID | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 388 | Ingress Timestamp (I bit is set)(FTSN) | 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Egress Timestamp (E bit is set)(FTSN) | 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 / / 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Syn |R|E|I|TSI|TS Service Indx| Flow ID | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 398 | Ingress Timestamp (I bit is set) | 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Egress Timestamp (E bit is set) | 402 | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Syn |R|E|I|TSI|TS Service Indx| Flow ID | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 406 | Ingress Timestamp (I bit is set) (LTSN) | 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Egress Timestamp (E bit is set) (LTSN) | 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 4: NSH Time Stamp Encapsulation 415 Relevant fields in header that the FTSN must implement: 417 The O bit should not be set as we are operating on subscriber packets 419 The C bit should be set indicating critical metadata exists 420 The MD type must be set to 0x2 422 TLV Class must be set to 0x10 (General KPI Monitoring) as requested 423 in section 11, and in addition that we define the timestamp type to 424 be 0x01. 426 Type = 0x00 Reserved. 427 Type = 0x01 Timestamp. 429 The MSB of the Type field must be set to zero. Thus if a receiver 430 along the path does not understand the time stamping protocol it will 431 pass the packet transparently and not drop. This scheme allows for 432 extensibility to the mechanism described in this document to other 433 KPI collections and operations. 435 FTSN timestamp metadata contains Timestamp Service Index (TSI) field 436 which must be set as follows: 438 0x0 Timestamp mode, no Service index specified in the TS Service 439 Index field. 441 0x1 Timestamp Hybrid mode is selected, Time Stamp Service Index 442 contains LTSN Service index. This is used when PNFs or NSH-unaware 443 SFs are used at the tail of the chain. If TSI=0x1, then the value in 444 the type field informs the chain which SF should act as the LTSN. 446 0x2 Timestamp Specific mode is selected, Time Stamp Service Index 447 contains the targeted Service Index. In this case the Time Stamp 448 Service Index field indicates which SF is to be time stamped. Both 449 ingress and egress timestamps are performed when the SI=TSSI on the 450 chain. In this mode the FTSN will also apply UTC and ingress time 451 stamp. This will indicate the delay along the entire service chain to 452 the targeted SF. This method may also be used as a light 453 implementation to monitor end-to-end service chain performance 454 whereby the targeted SF is the LTSN. 456 The Flow ID is a unique 16 bit identifier written into the header by 457 the classifier. This allow 65536 flows to be concurrently timestamped 458 on any given NSH service chain (SPI). Flow IDs are not written by 459 subsequent SFs in the chain. The FTSN exports monitored flow IDs to 460 the TSDB for correlation. 462 The E bit should be set if Egress timestamp is requested. 464 The I bit should be set if Ingress timestamp is requested. 466 UTC reference is the wall clock of the FTSN, and may be used for 467 historical comparison of SC performance. If the FTSN is not 468 time-of-day synched it should inform the TS controller over the TSCP 469 interface. 471 The Syn bits are an indication of the synchronization status of the 472 node performing the time stamp and must be set as follows: 473 In Synch: 0x00 474 In holdover: 0x01 475 In free run: 0x02 476 Out of Synch: 0x03 478 If the network node is out of synch or in free run no timestamp is 479 applied by the node (but other timestamp MD is applied) and the 480 packet is processed normally. 482 If FTSN is out of synch or in free run timestamp request rejected and 483 not propagated though the chain. The FTSN should inform the TS 484 controller in such an event over the TSCP interface. 486 The Outer service index value is copied into the timestamp metadata 487 to help cater for hybrid chains that's are a mix of VNFs and PNFs or 488 through SFs that do not understand NSH. Thus if a flow transits 489 through a PNF or a NSH-unaware node the delta in the inner service 490 index between time stamps will indicate this. 492 Timestamps are applied in PTP format (64 bit) and corresponding bits 493 (I and E) reported in the timestamp metadata header. 495 5. Hybrid Models 497 A hybrid chain may be defined as a chain whereby there is a mix of 498 NSH-aware and NSH-unaware SFs. This may be the case is some PNFs are 499 used in the chain or if VNFs are used that do not support NSH. 501 Example 1: PNF in the middle 503 TS 504 Controller 505 | TSDB 506 | TSCP Interface | 507 ,---. ,---. ,---. ,---. 508 / \ / \ / \ / \ 509 ( SCL )-------->( SF1 )--------->( SF2 )--------->( SFN ) 510 \ FTSN/ \ / \ PNF1/ \ LTSN/ 511 `---' `---' `---' `---' 513 Figure 5: Hybrid chain with PNF in middle 515 In this example the FTSN begins operation and sets the SI to 3, SF1 516 decrements this to 2 and passes the flow to a SFC proxy (not shown). 517 The proxy strips the NSH header and passes to the PNF. On receipt 518 back from the PNF the Proxy decrements the SI and passes the packet 519 onto the LTSN with a SI=1. 521 After the LTSN processes the traffic it knows it is the last node on 522 the chain from the SI value and exports the entire NSH header and all 523 metadata to the TSDB. The payload is forwarded to the next hop on the 524 underlay minus the NSH header. The TS information packet is given a 525 new SPI which acts as a homing tag to transport the timestamp data 526 back to the TSDB. 528 Example 2: PNF at the end 530 TS 531 Controller 532 | TSDB 533 | TSCP Interface | 534 ,---. ,---. ,---. ,---. 535 / \ / \ / \ / \ 536 ( SCL )-------->( SF1 )--------->( SF2 )--------->( PNFN ) 537 \ FTSN/ \ / \ LTSN/ \ / 538 `---' `---' `---' `---' 540 Figure 6: Hybrid Chain with PNF at end 542 In this example the FTSN begins operation and sets the SI to 3, the 543 TSI field set to 0x1, and the type to 1. Thus when SF2 receives the 544 packet with SI=1, it understands that it is expected to take on the 545 role of the LTSN as it is the last NSH-aware node in the chain. 547 5.1 Targeted VNF Time Stamp 549 For the majority of flows within the service chain, time stamps 550 (ingress,egress or both) will be carried out at each hop until the SI 551 decrements to zero and the NSH header and TS MD is exported to the 552 TSDB. There may exist however the need to just test a particular VNF 553 (perhaps after a scale out operation or software upgrade for 554 example). In this case the FTSN should mark the NSH header 555 as follows:- 557 TSI field is set to 0x2. Type is set to the expected SI at the SF in 558 question. When outer SI = type. Timestamps are applied at SF ingress, 559 egress and the NSH header and MD exported to the TSDB. 561 6. Fragmentation Considerations 563 The method described in this draft does not support fragmentation. 564 The TS Controller should return an error should a time stamping 565 request from an external system exceed MTU limits and require 566 fragmentation. 568 Depending on the length of the payload and the type of timestamp and 569 chain length, this will vary for each packet. 571 In most service provider architectures we would expect a SI << 10, 572 and that may include some PNFs in the chain which do not add 573 overhead. Thus for typical IMIX packet sizes we expect to able to 574 perform time stamping on the vast majority of flows without 575 fragmenting. 577 7. Security Considerations 579 TBD 581 8. Open Items for WG Discussion 583 1. Specification and operation of TSCP 584 2. AOB 586 9. Acknowledgments 588 The authors would like to thank Ron Parker of Affirmed Networks and 589 Seungik Lee of ETRI for their reviews of this draft. 591 10. IANA Considerations 593 TLV Class Registry 595 IANA is requested to set up a registry of "TLV Types". These are 596 16-bit values. Registry entries are assigned by using the 597 "IETF Review" policy defined in RFC 5226 [RFC5226]. One new type is 598 required for KPI General Monitoring and time stamping type as 599 discussed above. 601 11. References 603 11.1. Normative References 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, 607 DOI 10.17487/RFC2119, March 1997, 608 . 610 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 611 September 1981. 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, March 1997. 616 11.2. Informative References 618 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 619 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 620 March 2000. 622 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 623 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 624 May 2008. 626 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 627 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 628 February 2011. 630 [SFC-PS] Quinn, P., Ed. and T. Nadeau, Ed., "Service Function 631 Chaining Problem Statement", 2014, 632 . 635 [SFC-arch] Quinn, P., Ed. and J. Halpern, Ed., "Service Function 636 Chaining (SFC) Architecture", 2014, 637 . 639 [dcalloc] Guichard, J., Smith, M., and S. Kumar, "Network Service 640 Header (NSH) Context Header Allocation (Data Center)", 641 2014, 642 . 645 [moballoc] Napper, J. and S. Kumar, "NSH Context Header Allocation -- 646 Mobility", 2014, 647 . 650 Author's Address 652 Rory Browne 653 Email: rory.browne@intel.com 655 Andrey Chilikin 656 Email: andrey.chilikin@intel.com 658 Brendan Ryan 659 Email: brendan.ryan@intel.com 661 Intel 662 Dromore House 663 Shannon 664 Co.Clare 665 Ireland