idnits 2.17.1 draft-zhang-idr-bgp-extcommunity-qos-00.txt: -(105): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 221. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 197: '...anslations of it MAY be copied and fur...' RFC 2119 keyword, line 199: '...s implementation MAY be prepared, copi...' RFC 2119 keyword, line 203: '... document itself MAY not be modified i...' RFC 2119 keyword, line 207: '...the Internet Standards process MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 136 has weird spacing: '...ty name the...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Nov 2005) is 6727 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: 'IP' is defined on line 170, but no explicit reference was found in the text Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDR Working Group zhifeng Zhang 2 Internet Draft (Huawei) 3 Expires: May 2006 5 Nov 2005 7 draft-zhang-idr-bgp-extcommunity-qos-00.txt 9 ExtCommunity map and carry TOS value of IP header 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 16, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005).All Rights Reserved. 40 Abstract 42 This document defines a new BGP Extended Community, which can map 43 the value of IP TOS. Then, the Extended Community can classified 44 the route information at the same time can carry the value of TOS 45 which will apply into the IP packet. Then BGP and QoS have corre 46 -lation when we apply the QoS policy based on BGP,it will be simple. 48 Table of Contents 50 1. Introduction.................................................2 51 2. The BGP Extended Community map value of TOS..................2 52 3. Format of BGP ExtCommunity...................................2 53 4. Security Considerations......................................5 54 5. References...................................................5 55 6. Author's Addresses...........................................5 56 7. Full Copyright Statement.....................................6 58 1. Introduction 60 Since BGP commuity can only classify routing information,if you want to 61 apply QoS policy based on BGP ,you can use BGP community to classify 62 route information, then apply the TOS or some other QoS policy based 63 on the classified route information. 65 If BGP Extended Community can map TOS value of IP header at the same 66 time and keep the ability for classifing route information,the QoS 67 policy based on BGP will be simple. 69 2. The BGP Extended Community map value of TOS 71 In this document, we define the capability of Extended Community map 72 and carry the TOS value of IP header. When BGP import route information, 73 this Extended Community can be push or be apply by route policy, then 74 BGP route information can carry the TOS value of IP header. 76 3. Format of BGP ExtCommunity 78 The BGP Extended Community is encoded as an eight octet quantity. 80 In this document, we define the Format of the BGP Extended Community 81 as follows: 83 - Type Field : 1 octets 84 - TOS Value Field : 1 octets 85 - Value Field : Remaining octets 87 Type Field - the value mark the IANA regist information of BGP 88 Extended Community and the format of the Value Field 90 TOS Value Field - the value mark the TOS value that will be carried 91 by the stream matched correlation networking 92 information 94 Value Field - the value mark the classified route imformatin 96 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 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Type Field |TOS Value Field| Value Field | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Value Field | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 3.1 The Type Field 105 The size of Type Field for Regular types is 1 octet��as shown below�� 107 0 1 2 3 4 5 6 7 108 +-+-+-+-+-+-+-+-+ 109 |I|T| spare |V| 110 +-+-+-+-+-+-+-+-+ 112 I - IANA authority bit 113 T - TOS bit 114 Value 0: The TOS Value Field mark the default value 0 115 value 1: The TOS Value Field mark the value which would 116 be remarked the IP packet 117 V - The value of this bit which can identify the format of 118 the Value Field 119 Value 0: The high-order two octets of the Value Field is 120 administrator Field, the remaining octets is 121 sub-administrator Field 123 Value 1: The high-order four octets of the Value Field 124 is administrator Field, the remaining octets is 125 sub-administrator Field 127 3.2 TOS Value Field 129 The default value of TOS Value Field is 0. When the route information 130 be imported into BGP, we can define the TOS Field value that the route 131 informatin should carried. 133 According to defined DSCP value, we will define such BGP Extended 134 Community: 136 ExtCommunity name the high-order DSCP classes DSCP values 137 six bits of TOS 138 Value Field 139 ExtCom-EF 101110 EF 101110 140 ExtCom-AF41 100010 AF41 100010 141 ExtCom-AF42 100100 AF42 100100 142 ExtCom-AF43 100110 AF43 100110 143 ExtCom-AF31 011010 AF31 011010 144 ExtCom-AF32 011100 AF32 011100 145 ExtCom-AF33 011110 AF33 011110 146 ExtCom-AF21 010010 AF21 010010 147 ExtCom-AF22 010100 AF22 010100 148 ExtCom-AF23 010110 AF23 010110 149 ExtCom-AF11 001010 AF11 001010 150 ExtCom-AF12 001100 AF12 001100 151 ExtCom-AF13 001110 AF13 001110 152 ExtCom-BF 000000 BF 000000 154 The remaining bits of TOS Value Field use 0 as value. 156 3.3 Value Field 158 The Value Field used for identifing the route infomation which belong 159 to different community. 161 We can set and change the value of the Value Field, and can't impact 162 the other Field. 164 4. Security Considerations 166 This document does not introduce new security issues. 168 5. References 170 [IP] Postel "INTERNET PROTOCOL (IP)", RFC 791, September 1981. 172 [DS Field] K. Nichols,S. Blake,F. Baker, and D. Black, "Definition 173 of the Differentiated Services Field (DS Field) in the 174 IPv4 and IPv6 Headers", RFC 2474, December 1998. 176 [Architecture for DS] S. Blake,D. Black,M. Carlson,E. Davies,Z. Wang 177 and W. Weiss "An Architecture for Differentiated Services" 178 RFC 2475, December 1998. 180 6. Author's Addresses 182 zhifeng Zhang 183 Huawei Technologies 184 No. 3 Xinxi Road, Shangdi, 185 Haidian District, 186 Beijing, China 187 Email: zhangzhifeng@huawei.com 189 7. Full Copyright Statement 191 Copyright (C) The Internet Society (2005). 193 This document is subject to the rights, licenses and restrictions 194 contained in BCP 78, and except as set forth therein, the authors 195 retain all their rights. 197 This document and translations of it MAY be copied and furnished to 198 others, and derivative works that comment on or otherwise explain it 199 or assist in its implementation MAY be prepared, copied, published 200 and distributed, in whole or in part, without restriction of any 201 kind, provided that the above copyright notice and this paragraph 202 are included on all such copies and derivative works. However, this 203 document itself MAY not be modified in any way, such as by removing 204 the copyright notice or references to the Internet Society or other 205 Internet organizations, except as needed for the purpose of 206 developing Internet standards in which case the procedures for 207 copyrights defined in the Internet Standards process MUST be 208 followed, or as required to translate it into languages other than 209 English. 211 The limited permissions granted above are perpetual and will not be 212 revoked by the Internet Society or its successors or assigns. 214 This document and the information contained herein 215 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 216 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 217 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 218 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 219 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 220 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 221 OR FITNESS FOR A PARTICULAR PURPOSE.