idnits 2.17.1 draft-knoll-idr-qos-attribute-00.txt: 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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 500. 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 Copyright Line does not match the current year -- 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 (June 8, 2008) is 5801 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing Working Group Th. Knoll 3 Internet-Draft Chemnitz University of Technology 4 Intended status: Standards Track June 8, 2008 5 Expires: December 10, 2008 7 BGP Extended Community Attribute for QoS Marking 8 draft-knoll-idr-qos-attribute-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 10, 2008. 35 Abstract 37 This document specifies a simple signalling mechanism for inter- 38 domain QoS marking using a BGP Extended Community QoS Attribute. 39 Class based packet forwarding for delay and loss critical services is 40 currently performed in an individual AS internal manner. The new QoS 41 marking attribute makes the QoS class setup within the IP prefix 42 advertising AS known to all access and transit ASes. This enables 43 individual (re-)marking and forwarding treatment adaptation to the 44 original QoS class setup of the respective IP prefix. The attribute 45 provides the means to signal QoS markings on different layers, which 46 are linked together in QoS class sets. It provides inter-domain and 47 cross-layer insight into the QoS class mapping of the source AS with 48 minimal signalling traffic. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definition of the QoS Marking Attribute . . . . . . . . . . . 3 60 2.1. Extended Community Type . . . . . . . . . . . . . . . . . 3 61 2.2. Structure of the QoS Marking Attribute . . . . . . . . . . 4 62 2.3. Technology Type Enumeration . . . . . . . . . . . . . . . 6 63 3. Attribute Usage . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1. QoS Marking Attribute Example . . . . . . . . . . . . . . 7 65 3.2. AS Border Packet Forwarding . . . . . . . . . . . . . . . 7 66 3.3. IP Prefix Aggregation . . . . . . . . . . . . . . . . . . 7 67 4. Confidentiality Considerations . . . . . . . . . . . . . . . . 8 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Appendix A. QoS Marking Attribute Example . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Intellectual Property and Copyright Statements . . . . . . . . . . 12 77 1. Introduction 79 A new BGP Extended Community Attribute is defined in this document, 80 which carries QoS marking information for different network layer 81 technologies across ASes. This attribute is called "QoS Marking 82 Attribute". This new attribute provides a mechanism for labelling 83 priority class information carried in BGP-4 [RFC4271]. It allows for 84 the consistent exchange of priority class encoding values between BGP 85 peers for physical, data link, network and transport layer QoS 86 mechanisms. These labels can be used to control the distribution of 87 this information, for the encoding and for treatment adjustments 88 within the AS or for other applications. 90 Several QoS Marking Attributes MAY be included in a single BGP UPDATE 91 message. Each QoS Marking Attribute is encoded as 8-octet tuple, as 92 follows. 94 2. Definition of the QoS Marking Attribute 96 2.1. Extended Community Type 98 The new QoS Marking Attribute is encoded as a BGP Extended Community 99 Attribute [RFC4360]. It is therefore a transitive optional BGP 100 attribute with Type Code 16. An adoption to the simple BGP Community 101 Attribute encoding [RFC1997] is not defined in this document. The 102 actual encoding within the BGP Extended Community Attribute is as 103 follows. 105 The QoS Marking Attribute is of regular type which results in a 1 106 octet Type field followed by 7 octets for the QoS marking structure. 107 The Type is IANA-assignable (FCFS procedure) and marks the community 108 as transitive across ASes. The type number has been assigned by IANA 109 to 0xYY (0x00-x3f). 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 |0 0 x x x x x x| | 114 +-+-+-+-+-+-+-+-+ 7 octet QoS Marking Attribute structure | 115 | | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Note to RFC Editor: The actual type number needs to replace the '0xYY 119 (0x00-x3f)' after the IANA assignment has occurred. 121 2.2. Structure of the QoS Marking Attribute 123 The QoS Marking Attributes provides a flexible encoding structure for 124 various QoS Markings on different layers. This flexibility is 125 achieved by a Flags, a QoS Set Number and a Technology Type field 126 within the 7 octet structure as defined below. 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Flags | QoS Set Number| Technology Type | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | QoS Marking O | QoS Marking A | P. Count | C. Unused ='0'| 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Flags: 136 0 1 2 3 4 5 6 7 137 +--+--+--+--+--+--+--+--+ 138 |L2 L1 L0|R |I |A |0 |0 | 139 +--+--+--+--+--+--+--+--+ 141 All used and unused flags default to a value of '0'. The 142 following table shows the bit encoding of the Flags field. 144 +-----+-----------+-------------------------------------------------+ 145 | Bit | Flag | Encoding | 146 +-----+-----------+-------------------------------------------------+ 147 | 0-2 | L2 & L1 & | Specification of the applied enumeration list | 148 | | L0 | for the Technology Type | 149 | 3 | R | '1' ... remarking occurred | 150 | 4 | I | '1' ... QoS marking ignored | 151 | 5 | A | '1' ... QoS class aggregation occurred | 152 | 6,7 | unused | Default to '0' | 153 +-----+-----------+-------------------------------------------------+ 155 Technology Type Enumeration can be chosen from different sources 156 as follows. 158 +----------+-----------------------------------------------+ 159 | L2&L1&L0 | Enumeration List | 160 +----------+-----------------------------------------------+ 161 | '000' | GMPLS LSP encoding Type see [GMPLS-SIG] | 162 | '001' | MPLS Pseudowire Type see [RFC4446] | 163 | '010' | EtherType see [EtherType] | 164 | '011' | IANA Protocol Numbers see [RFC5237] | 165 | '100' | MIB II Interface List see [RFC2863] | 166 | '111' | alternative Technology Type see (Section 2.3) | 167 +----------+-----------------------------------------------+ 168 The Flags "R, I and A" are set to '0' in the advertisement by the 169 IP prefix originating AS. Transit ASes MUST change the flag value 170 to '1' once the respective event occurred. If the QoS marking 171 actively used in the transit AS internal forwarding is different 172 from the advertised original one, the 'Remarking (R)' flag is set 173 to '1'. This MUST be done separately for each technology type 174 attribute within the attribute set. The same applies to the 175 'Ignore (I)' flag, if the respective advertised QoS marking is 176 ignored in the transit AS internal forwarding. 178 The 'Aggregation (A)' flag MUST be set to '1' by the UPDATE 179 message relaying transit AS, if the respective IP prefixes will be 180 advertised inside an IP prefix aggregate. 182 QoS Set Number: 184 Several single QoS Marking Attributes can be grouped logically 185 into a QoS Marking Attribute Set characterized by a QoS Set 186 Number. This grouping of the single QoS Marking Attributes into a 187 set provides a cross-layer linking between the QoS class 188 encodings. The number of signalled QoS Marking Attributes as well 189 as QoS Marking Attribute Sets is at the operator's choice of the 190 originating AS. The enumerated QoS set numbers have BGP UPDATE 191 message local significance starting with set number 0x00. 193 Technology Type: 195 The technology type encoding follows commonly used enumerations as 196 referred to by the L2&L1&L0 bit combinations stated above. If the 197 use of external enumerations is not favoured or the mapping of 198 commonly used technologies is sufficient, the enumeration list in 199 (Section 2.3) SHALL be used. 201 QoS Marking / Enumeration O & A: 203 The interpretation of these identically approached fields depends on 204 the selected layer and technology. QoS mechanisms using bit 205 encodings for the targeted priority (e.g. IP DSCP, Ethernet User 206 Priority, MPLS EXP etc.) MUST use a copy of the encoding in this 207 attribute field. Unused higher order bits default to '0'. Other 208 technologies, which use other ways of labelling priority information 209 such as L-LSPs, VPI/VCI inferred ATM classes, lambda inferred 210 priority, etc. SHALL use class enumerations as encoding in this 211 attribute field. 213 There are two QoS Marking fields within the QoS Marking Attribute for 214 the "original (O)" and the "active (A)" QoS marking. 216 QoS Marking O (Original QoS Marking): 218 The IP prefix originating AS copies the internally associated QoS 219 encoding of the given Technology Type into this one octet field. 220 The field MUST remain unchanged in BGP UPDATE messages of relaying 221 nodes. 223 QoS Marking A (Active QoS Marking): 225 QoS Marking A and O MUST be identically encoded by the prefix 226 originating AS. 228 All other ASes use this Active QoS Marking field to advertise 229 their internal QoS encoding of the given class and technology. A 230 cleared Marking field signals that this traffic class experiences 231 default traffic treatment within the transit AS forwarding 232 technology. 234 Processing Count (P. Count): 236 Each BGP instance, which processes the attribute and appends a 237 different AS number to the AS_PATH, MUST increase this counter by 238 one. The attribute originating instance initializes the counter 239 value to '0x00'. 241 Currently Unused (C. Unused): 243 This one octet field is currently unused and MUST be set to 244 '0x00'. 246 2.3. Technology Type Enumeration 248 A small list of technologies is provided in the table below for the 249 direct encoding of common technology types. 251 +--------+------------------------------------+ 252 | Value | Technology Type | 253 +--------+------------------------------------+ 254 | 0x0000 | DiffServ enabled IPv4 | 255 | 0x0001 | DiffServ enabled IPv6 | 256 | 0x0010 | Ethernet using 802.1q priority tag | 257 | 0x0020 | MPLS using E-LSP | 258 | 0x0021 | MPLS using L-LSP | 259 | 0x0100 | GMPLS - time slot encoding | 260 | 0x0101 | GMPLS - lambda encoding | 261 | 0x0102 | GMPLS - fibre encoding | 262 +--------+------------------------------------+ 264 3. Attribute Usage 266 Providers MAY choose to process the QoS Marking Attributes and adopt 267 the priority encoding according to their local policy. Whether this 268 MAY also lead to different IGP routing decisions or even effect BGP 269 update filters is out of scope for the attribute definition. 271 Only the IP prefix originating AS is allowed to signal the QoS 272 Marking Attributes and Sets. Transit ASes MUST NOT modify or extend 273 the QoS Set except for the update of each 'QoS Marking A' field 274 contained in the Attribute Set, the respective "R, I, A" flags and 275 the Processing Counter. 277 3.1. QoS Marking Attribute Example 279 See Appendix A for an example QoS Marking Attribute Set. 281 3.2. AS Border Packet Forwarding 283 IP packet forwarding based on packet header QoS encoding might 284 require remarking of packets in order to match AS internal policies 285 and encodings of neighbouring ASes. 287 Identical QoS class sets and encodings between neighbouring ASes do 288 not require any remarking. Different encodings will be matched on 289 the outgoing traffic. 291 Outgoing traffic for a given IP prefix uses the 'QoS Marking A' 292 information of the respective BGP UPDATE message QoS Marking 293 Attribute for adopted remarking of the forwarded packet. 295 If the Process Count is smaller than the number of different AS 296 numbers in the AS PATH or if the 'I' flag is set for a given 297 encoding, the outgoing traffic will be remarked using the 'QoS 298 Marking O' information instead. 300 'QoS Marking O' information is also used for outgoing remarking, if 301 the targeted class is not supported by the neighbouring AS. 303 3.3. IP Prefix Aggregation 305 Several IP prefixes of different IP prefix originating ASes MAY be 306 aggregated to a shorter IP prefix in transit ASes. The QoS Marking 307 Attribute Set of the resulting IP prefix aggregate is chosen as 308 follows: 310 1. If only on aggregate member contains an associated QoS Marking 311 Attribute Set, than this Set MUST be used as resulting QoS 312 Marking Attribute Set for the IP prefix aggregate. 314 2. If several aggregate members contain an associated QoS Marking 315 Attribute Set, than the Set of the shortest IP prefix aggregate 316 member MUST be used as resulting QoS Marking Attribute Set for 317 the IP prefix aggregate. Equal IP prefix aggregate member 318 lengths SHOULD be resolved in favour of the IP prefix with lower 319 IP addresses. 321 In case of IP prefix aggregation, the 'Aggregation (A)' flag of each 322 QoS Marking Attribute within the Set MUST be set to '1'. 324 4. Confidentiality Considerations 326 The disclosure of confidential AS intrinsic information is of no 327 concern since the signalled marking for QoS class encodings can be 328 adopted prior to the UPDATE advertisement of the IP prefix 329 originating AS. AS internal cross-layer remarking and policy based 330 update filtering allows for consistent QoS class support despite made 331 up QoS class set and encoding information within UPDATE 332 advertisements. In case of such policy hiding strategy the required 333 originating AS internal ingress and egress remarking SHALL be done 334 transparently without explicit "Active Marking" and 'R' flag 335 signalling. 337 5. IANA Considerations 339 This document defines a new BGP Extended Community Attribute, which 340 needs to be assigned a number by IANA within the Extended Community 341 Attribute list. 343 The new QoS Marking Attribute is a BGP Extended Community Attribute 344 of regular type. It is IANA-assignable (FCFS procedure) and is 345 transitive across ASes. 347 An number assignment application within the numbering range of 0x00 - 348 x3f is made to IANA. 350 Note to RFC Editor: this section may be removed on publication as an 351 RFC. 353 6. Security Considerations 355 The new QoS marking Attribute does not raise extra security concerns. 356 Existing BGP security measures are in place by means of the reused 357 transport within BGP UPDATE messages. 359 7. References 361 7.1. Normative References 363 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 364 Communities Attribute", RFC 1997, August 1996. 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, March 1997. 369 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 370 MIB", RFC 2863, June 2000. 372 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 373 Protocol 4 (BGP-4)", RFC 4271, January 2006. 375 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 376 Communities Attribute", RFC 4360, February 2006. 378 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 379 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 381 [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for 382 the Protocol Field", BCP 37, RFC 5237, February 2008. 384 7.2. Informative References 386 [EtherType] 387 IEEE, "IEEE EtherType registration list", June 2008, 388 . 390 [GMPLS-SIG] 391 IANA, "GMPLS Signaling Parameters", June 2008, 392 . 394 Appendix A. QoS Marking Attribute Example 396 The example AS is advertising several IP prefixes, which experience 397 equal QoS treatment from AS internal networks. The IP packet 398 forwarding policy within this originating AS defines e.g. 3 traffic 399 classes for IP traffic (DSCP1, DSCP2 and DSCP3). These three classes 400 are also consistently taken care off within AS internal 802.1q 401 Ethernet switches (using UPC1, UPC2 and UPC3) as well as within the 402 EXP bit supporting MPLS tunnel forwarding. The BGP UPDATE message 403 for the announced IP prefixes will contain the following QoS Marking 404 Attribute Set together with the IP prefix NLRI. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 |1 1 1 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |0 0 1 0 1 1 1 0|0 0 1 0 1 1 1 0| currently used = '0' | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |1 1 1 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0| 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |0 0 0 0 0 1 1 1|0 0 0 0 0 1 1 1| currently used = '0' | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |1 1 1 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0| 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 |0 0 0 0 0 1 0 1|0 0 0 0 0 1 0 1| currently used = '0' | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 |1 1 1 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |0 0 0 1 1 0 0 0|0 0 0 1 1 0 0 0| currently used = '0' | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 |1 1 1 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0| 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 |0 0 0 0 0 1 0 1|0 0 0 0 0 1 0 1| currently used = '0' | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |1 1 1 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0| 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |0 0 0 0 0 0 1 1|0 0 0 0 0 0 1 1| currently used = '0' | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 |1 1 1 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 |0 0 0 0 1 0 0 0|0 0 0 0 1 0 0 0| currently used = '0' | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 |1 1 1 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0| 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1| currently used = '0' | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 |1 1 1 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0| 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1| currently used = '0' | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 The class set as well as the example encodings are arbitrarily 448 chosen. 450 Author's Address 452 Thomas Martin Knoll 453 Chemnitz University of Technology 454 Reichenhainer Str. 70 /331 455 Chemnitz, 09126 456 GERMANY 458 Phone: +49-371-531-33246 459 Fax: +49-371-531-833246 460 Email: knoll@etit.tu-chemnitz.de 462 Full Copyright Statement 464 Copyright (C) The IETF Trust (2008). 466 This document is subject to the rights, licenses and restrictions 467 contained in BCP 78, and except as set forth therein, the authors 468 retain all their rights. 470 This document and the information contained herein are provided on an 471 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 472 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 473 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 474 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 475 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 476 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 478 Intellectual Property 480 The IETF takes no position regarding the validity or scope of any 481 Intellectual Property Rights or other rights that might be claimed to 482 pertain to the implementation or use of the technology described in 483 this document or the extent to which any license under such rights 484 might or might not be available; nor does it represent that it has 485 made any independent effort to identify any such rights. Information 486 on the procedures with respect to rights in RFC documents can be 487 found in BCP 78 and BCP 79. 489 Copies of IPR disclosures made to the IETF Secretariat and any 490 assurances of licenses to be made available, or the result of an 491 attempt made to obtain a general license or permission for the use of 492 such proprietary rights by implementers or users of this 493 specification can be obtained from the IETF on-line IPR repository at 494 http://www.ietf.org/ipr. 496 The IETF invites any interested party to bring to its attention any 497 copyrights, patents or patent applications, or other proprietary 498 rights that may cover technology that may be required to implement 499 this standard. Please address the information to the IETF at 500 ietf-ipr@ietf.org.