idnits 2.17.1 draft-keten-mpls-expbit-02.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 5) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. 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 (September 15, 2016) is 2779 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) -- Looks like a reference, but probably isn't: 'RFC2119' on line 88 -- Looks like a reference, but probably isn't: 'RFC2234' on line 175 == Unused Reference: '1' is defined on line 194, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 197, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 201, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 204, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Independent Submission U. Keten 2 Internet Draft Turk Telekom A.S. 3 Intended status: Proposed Standard September 15, 2016 4 Expires: February 2017 6 MPLS EXP/TC BIT EXPANSION 7 draft-keten-mpls-expbit-02.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on FEB 14, 2016. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. 44 Abstract 46 This document specifies the new label/header architecture for a new 47 Multiprotocol Label Switching and proposes a new Label Standard. 48 With this new architecture the aim is to provide more QoS options. 50 Table of Contents 52 1. Introduction ................................................ 3 53 2. Conventions used in this document............................ 3 54 3. Overview and Current Encoding of the Label Stack............. 4 55 4. New Proposed Encoding of the Label Stack..................... 4 56 5. More QoS parameters ......................................... 5 57 6. Backwards Compatability...................................... 5 58 7. Formal Syntax ............................................... 5 59 8. Security Considerations...................................... 5 60 9. IANA Considerations ......................................... 5 61 10. Conclusions ................................................ 5 62 11. References ................................................. 6 63 11.1. Normative References................................... 6 64 11.2. Informative References................................. 6 65 12. Acknowledgments ............................................ 6 67 1. Introduction 69 This internet draft outlines a proposed change for the MPLS 70 architecture as defined in RFC 3031 and the MPLS Label Stack 71 Encoding RFC 3032 to suit the need of differentiated services 72 and their requirements for more differentiated QoS. 74 Current services require more specific QoS parameters then the 75 8 possibilities provided by the 3 bit in the EXP/COS/TC field. 77 3 bits is not enough to differentiate in our current service 78 oriented environment. 80 With this Proposed Standard a possibility of 32 QoS settings 81 can be achieved. 83 2. Conventions used in this document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 In this document, these words will appear with that interpretation 90 only when in ALL CAPS. Lower case uses of these words are not to be 91 interpreted as carrying significance described in RFC 2119. 93 In this document, the characters ">>" preceding an indented line(s) 94 indicates a statement using the key words listed above. This 95 convention aids reviewers in quickly identifying or finding the 96 portions of this RFC covered by these keywords. 98 3. Overview and Current Encoding of the Label Stack 100 The current label stack as described in RFC 3032 is represented 101 as a sequence of "label stack entries". 102 Each label stack entry is represented by 4 octets. 104 This is shown in Figure 1: 106 Octets 0 1 2 3 4 108 Bits 1 2 3 4 5 6 7 8 110 Label -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+- 111 Stack | Label | EXP |S| TTL | 112 Entry -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+- 114 Figure 1 116 Label: Label Value, 20 bit 117 EXP/TC/COS: 3 bits defined as TC, RFC 5462 118 S: Bottom of Stack, 1 bit 119 TTL: Time to Live, 8 bits 121 4. New Proposed Encoding of the Label Stack 123 The New label stack described is represented as the same sequence 124 of "label stack entries" as in RFC 3032. However the assigned 8 125 bits to TTL have been deducted by 2, to a total of 6 bits and 126 added to a new complimentary QoS X stack which will be a 2 bits 127 entry. 129 This is shown in Figure 2. 131 Octets 0 1 2 3 4 132 Bits 1 2 3 4 5 6 7 8 134 Label -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+- 135 Stack | Label | EXP |S| X | TTL | 136 Entry -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+- 138 Figure 2 140 Label: Label Value, 20 bit 141 EXP/TC/COS: 5 bits defined in New Proposed Format 142 S: Bottom of Stack, 1 bit 143 X: Complimentary QoS bits 144 TTL: Time to Live, 6 bits 146 5. More QoS parameters 148 With the addition of 2 more complimentary bits as the X stack, more 149 QoS parameters can be set to suit the needs of current IP Internet 150 services. 152 MPLS networks will not need such large TTL's, taking the 2 153 most-significant-bits from the TTL and giving them a different 154 purpose could have more meaning. 156 6. Backwards Compatability 158 Assumed is that these most-significant-bits bits will "never" be 159 decremented. For consideration is that certain OAM mechanisms do rely 160 on TTL decrementing to zero to trap frames. This is to specify that 161 OAM protocols in this new architecture would never set these 162 "extended" TC bits. Intended is to use these as extra "trash" tiers. 163 Alternatively, these could be considered as "premium" trash tiers 164 and hopping too much is grounds to have your extended TC "downgraded". 166 In terms of implementation as a software upgrade in existing gear, 167 this should be doable. NPU/FPGA/NFV-based solutions could add this 168 functionality with a software upgrade. Semi-programmable ASICs could 169 do this with some reconfiguration/programming. 170 Only fully baked-in ASICs would have difficulty implementing this. 172 7. Formal Syntax 174 The following syntax specification uses the augmented Backus-Naur 175 Form (BNF) as described in RFC-2234 [RFC2234]. 177 8. Security Considerations 179 There are no security considerations. 181 9. IANA Considerations 183 This document has no actions for IANA. 185 10. Conclusions 187 With this document a necessary and easy change is advised. More 188 diverse QoS settings will enable a more service oriented network. 190 11. References 192 11.1. Normative References 194 [1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 195 Label Switching Architecture", RFC 3031, January 2001. 197 [2] Rosen, E., Tappan, D. Fedorkow G., Y. Rekhter, D. Farinacci, 198 T. Li, A. Conta "MPLS Label Stack Encoding", RFC 3032, 199 January 2001 201 [3] Bradner, S.,"Key words for use in RFCs to Indicate Requirement 202 Levels", BCP 14, RFC 2119, March 1997. 204 [4] L. Andersson, Acreo AB, R. Asati, Multiprotocol Label 205 Switching (MPLS) Label Stack Entry:"EXP" Field Renamed to 206 "Traffic Class" Field,RFC 5462, February 2009 208 11.2. Informative References 210 No Informative References 212 12. Acknowledgments 214 This document was prepared using 2-Word-v2.0.template.dot. 216 Authors' Addresses 218 Umut Keten 219 Turk Telekom A.S. 220 Ankara GM 222 Phone: +90 553 349 9669 223 Email: umut.keten@turktelekom.com.tr