idnits 2.17.1 draft-bryant-mpls-sfl-framework-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 : ---------------------------------------------------------------------------- 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 10, 2016) is 2877 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-mpls-flow-ident-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS S. Bryant 3 Internet-Draft Independent 4 Intended status: Informational G. Swallow 5 Expires: December 12, 2016 S. Sivabalan 6 Cisco Systems 7 G. Mirsky 8 Ericsson 9 M. Chen 10 Z. Li 11 Huawei 12 June 10, 2016 14 Synonymous Flow Label Framework 15 draft-bryant-mpls-sfl-framework-01 17 Abstract 19 draft-ietf-mpls-flow-ident describes the requirement for introducing 20 flow identities within the MPLS architecture. This document 21 describes a method of accomplishing this by using a technique called 22 Synonymous Flow Labels in which labels which mimic the behaviour of 23 other labels provide the identification service. These identifiers 24 can be used to trigger per-flow operations on the on the packet at 25 the receiving label switching router. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 12, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Synonymous Flow Labels . . . . . . . . . . . . . . . . . . . 2 63 3. User Service Traffic in the Data Plane . . . . . . . . . . . 4 64 3.1. Applications Label Present . . . . . . . . . . . . . . . 4 65 3.1.1. Setting TTL and the Traffic Class Bits . . . . . . . 4 66 3.2. Single Label Stack . . . . . . . . . . . . . . . . . . . 5 67 3.2.1. Setting TTL and the Traffic Class Bits . . . . . . . 6 68 3.3. Aggregation of SFL Actions . . . . . . . . . . . . . . . 6 69 4. Equal Cost Multipath Considerations . . . . . . . . . . . . . 7 70 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 9.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 [I-D.ietf-mpls-flow-ident] describes the requirement for introducing 82 flow identities within the MPLS architecture. 84 This document describes a method of accomplishing this by using a 85 technique called Synonymous Flow Labels (SFL) (see (Section 2)) in 86 which labels which mimic the behaviour of other labels provide the 87 identification service. These identifiers can be used to trigger 88 per-flow operations on the packet at the receiving label switching 89 router. 91 2. Synonymous Flow Labels 93 An SFL is defined to be a label that causes exactly the same 94 behaviour at the egress Label Switching Router (LSR) as the label it 95 replaces, but in addition also causes an agreed action to take place 96 on the packet. There are many possible additional actions such as 97 the measurement of the number of received packets in a flow, 98 triggering IPFIX inspection, triggering other types of Deep Packet 99 Inspection, or identification of the packet source. In, for example, 100 a Performance Monitoring (PM) application, the agreed action could be 101 the recording of the receipt of the packet by incrementing a packet 102 counter. This is a natural action in many MPLS implementations, and 103 where supported this permits the implementation of high quality 104 packet loss measurement without any change to the packet forwarding 105 system. 107 Consider an MPLS application such as a pseudowire (PW), and consider 108 that it is desired to use the approach specified in this document to 109 make a packet loss measurement. By some method outside the scope of 110 this text, two labels, synonymous with the PW labels are obtained 111 from the egress terminating provider edge (T-PE). By alternating 112 between these SFLs and using them in place of the PW label, the PW 113 packets may be batched for counting without any impact on the PW 114 forwarding behaviour (note that strictly only one SFL is needed in 115 this application, but that is an optimization that is a matter for 116 the implementor). 118 Now consider an MPLS application that is multi-point to point such as 119 a VPN. Here it is necessary to identify a packet batch from a 120 specific source. This is achieved by making the SFLs source 121 specific, so that batches from one source are marked differently from 122 batches from another source. The sources all operate independently 123 and asynchronously from each other, independently co-ordinating with 124 the destination. Each ingress is thus able to establish its own SFL 125 to identify the sub-flow and thus enable PM per flow. 127 Finally we need to consider the case where there is no MPLS 128 application label such as occurs when sending IP over an LSP. In 129 this case introducing an SFL that was synonymous with the LSP label 130 would introduce network wide forwarding state. This would not be 131 acceptable for scaling reasons. We therefore have no choice but to 132 introduce an additional label. Where penultimate hop popping (PHP) 133 is in use, the semantics of this additional label can be similar to 134 the LSP label. Where PHP is not in use, the semantics are similar to 135 an MPLS explicit NULL. In both of these cases the label has the 136 additional semantics of the SFL. 138 Note that to achieve the goals set out in Section 1 SFLs need to be 139 allocated from the platform label table. 141 3. User Service Traffic in the Data Plane 143 As noted in Section 2 it is necessary to consider two cases: 145 1. Applications label present 147 2. Single label stack 149 3.1. Applications Label Present 151 Figure 1 shows the case in which both an LSP label and an application 152 label are present in the MPLS label stack. Traffic with no SFL 153 function present runs over the "normal" stack, and SFL enabled flows 154 run over the SFL stack with the SFL used to indicate the packet 155 batch. 157 +-----------------+ +-----------------+ 158 | | | | 159 | LSP | | LSP | . 348 9.2. Informative References 350 [I-D.ietf-mpls-flow-ident] 351 Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 352 Mirsky, "MPLS Flow Identification Considerations", draft- 353 ietf-mpls-flow-ident-00 (work in progress), December 2015. 355 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 356 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 357 RFC 6790, DOI 10.17487/RFC6790, November 2012, 358 . 360 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 361 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 362 2014, . 364 Authors' Addresses 366 Stewart Bryant 367 Independent 369 Email: stewart.bryant@gmail.com 371 George Swallow 372 Cisco Systems 374 Email: swallow@cisco.com 376 Siva Sivabalan 377 Cisco Systems 379 Email: msiva@cisco.com 381 Greg Mirsky 382 Ericsson 384 Email: gregory.mirsky@ericsson.com 386 Mach(Guoyi) Chen 387 Huawei 389 Email: mach.chen@huawei.com 390 Zhenbin(Robin) Li 391 Huawei 393 Email: lizhenbin@huawei.com