idnits 2.17.1 draft-ietf-dime-qos-attributes-06.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1176. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1187. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1200. 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (May 26, 2008) is 5813 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) == Missing Reference: 'EAP-Master-Session-Key' is mentioned on line 869, but not defined == Missing Reference: 'QoS-desired' is mentioned on line 1019, but not defined == Missing Reference: 'QoS-Authorized' is mentioned on line 1022, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'DSCP' == Outdated reference: A later version (-11) exists of draft-ietf-dime-qos-parameters-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMPTYPE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPOPTIONS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PROTOCOL' ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) -- Possible downref: Non-RFC (?) normative reference: ref. 'TCPOPTIONS' == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-05 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen, Ed. 3 Extensions (DIME) TeliaSonera 4 Internet-Draft H. Tschofenig 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: November 27, 2008 M. Arumaithurai 7 University of Goettingen 8 M. Jones 9 A. Lior 10 Bridgewater Systems 11 May 26, 2008 13 Quality of Service Attributes for Diameter 14 draft-ietf-dime-qos-attributes-06.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on November 27, 2008. 41 Abstract 43 This document extends the QoSFilterRule AVP functionality of the 44 Diameter Base protocol and the functionality of the QoS-Filter-Rule 45 AVP defined in RFC 4005. The ability to convey Quality of Service 46 information using the AVPs defined in this document is available to 47 existing and future Diameter applications where permitted by the 48 command ABNF. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Diameter QoS Defined AVPs . . . . . . . . . . . . . . . . . . 4 55 3.1. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 4 56 3.2. QoS-Profile-Template AVP . . . . . . . . . . . . . . . . . 5 57 3.3. Vendor-Specific-QoS-Profile-Template AVP . . . . . . . . . 5 58 3.4. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 5 59 3.5. Extended-QoS-Filter-Rule AVP . . . . . . . . . . . . . . . 5 60 3.6. QoS-Semantics . . . . . . . . . . . . . . . . . . . . . . 6 61 3.7. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . . . 6 62 3.8. QoS-Rule-Precedence AVP . . . . . . . . . . . . . . . . . 6 63 4. Semantics of QoS Parameters . . . . . . . . . . . . . . . . . 6 64 5. Diameter Classifier AVPs . . . . . . . . . . . . . . . . . . . 7 65 5.1. Classifier AVP . . . . . . . . . . . . . . . . . . . . . . 10 66 5.2. Classifier-ID AVP . . . . . . . . . . . . . . . . . . . . 11 67 5.3. Protocol AVP . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.4. Direction AVP . . . . . . . . . . . . . . . . . . . . . . 11 69 5.5. From-Spec AVP . . . . . . . . . . . . . . . . . . . . . . 12 70 5.6. To-Spec AVP . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.7. Source and Destination AVPs . . . . . . . . . . . . . . . 13 72 5.7.1. Negated AVP . . . . . . . . . . . . . . . . . . . . . 13 73 5.7.2. IP-Address AVP . . . . . . . . . . . . . . . . . . . . 14 74 5.7.3. IP-Address-Range AVP . . . . . . . . . . . . . . . . . 14 75 5.7.4. IP-Address-Start AVP . . . . . . . . . . . . . . . . . 14 76 5.7.5. IP-Address-End AVP . . . . . . . . . . . . . . . . . . 15 77 5.7.6. IP-Address-Mask AVP . . . . . . . . . . . . . . . . . 15 78 5.7.7. IP-Mask-Bit-Mask-Width AVP . . . . . . . . . . . . . . 15 79 5.7.8. MAC-Address AVP . . . . . . . . . . . . . . . . . . . 15 80 5.7.9. Port AVP . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.7.10. Port-Range AVP . . . . . . . . . . . . . . . . . . . . 15 82 5.7.11. Port-Start AVP . . . . . . . . . . . . . . . . . . . . 16 83 5.7.12. Port-End AVP . . . . . . . . . . . . . . . . . . . . . 16 84 5.7.13. Use-Assigned-Address AVP . . . . . . . . . . . . . . . 16 85 5.8. Header Option AVPs . . . . . . . . . . . . . . . . . . . . 16 86 5.8.1. Diffserv-Code-Point AVP . . . . . . . . . . . . . . . 16 87 5.8.2. Fragmentation-Flag AVP . . . . . . . . . . . . . . . . 16 88 5.8.3. IP-Option AVP . . . . . . . . . . . . . . . . . . . . 17 89 5.8.4. IP-Option-Type AVP . . . . . . . . . . . . . . . . . . 17 90 5.8.5. IP-Option-Value AVP . . . . . . . . . . . . . . . . . 17 91 5.8.6. TCP-Option AVP . . . . . . . . . . . . . . . . . . . . 17 92 5.8.7. TCP-Option-Type AVP . . . . . . . . . . . . . . . . . 18 93 5.8.8. TCP-Option-Value AVP . . . . . . . . . . . . . . . . . 18 94 5.8.9. TCP-Flags AVP . . . . . . . . . . . . . . . . . . . . 18 95 5.8.10. TCP-Flag-Type AVP . . . . . . . . . . . . . . . . . . 18 96 5.8.11. ICMP-Type . . . . . . . . . . . . . . . . . . . . . . 19 97 5.8.12. ICMP-Type-Number AVP . . . . . . . . . . . . . . . . . 19 98 5.8.13. ICMP-Code AVP . . . . . . . . . . . . . . . . . . . . 19 99 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 6.1. Diameter EAP with QoS Information . . . . . . . . . . . . 20 101 6.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 21 102 6.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 22 103 6.4. Diameter Server Initiated Re-authorization of QoS . . . . 23 104 6.5. Diameter Credit Control with QoS Information . . . . . . . 24 105 6.6. Classifier mapping from IPFilterRule type . . . . . . . . 25 106 6.7. Complex Classifier . . . . . . . . . . . . . . . . . . . . 25 107 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 111 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 112 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 114 Intellectual Property and Copyright Statements . . . . . . . . . . 29 116 1. Introduction 118 This document defines a number of Diameter Quality of Service (QoS) 119 related AVPs that can be used in existing and future Diameter 120 applications where permitted by the command ABNF. The Extended-QoS- 121 Filter-Rule AVP thereby replaces the QoSFilterRule, defined in RFC 122 3588 [RFC3588], and the QoS-Filter-Rule, defined in RFC 4005 123 [RFC4005]. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 3. Diameter QoS Defined AVPs 133 The following table lists the Diameter AVPs used by this document, 134 their AVP code values, types and possible flag values. 136 +------------------+ 137 | AVP Flag Rules | 138 +------------------------------------------------|----+---+----+----+ 139 | AVP Section |MUST|MAY|SHLD|MUST| 140 | Attribute Name Code Defined Data Type | | | NOT| NOT| 141 +------------------------------------------------+----+---+----+----+ 142 |QoS-Capability TBD 3.1 Grouped | | P | |M,V | 143 |QoS-Profile-Template TBD 3.2 Unsigned32 | | P | |M,V | 144 |Vendor-Specific- | | | | | 145 | QoS-Profile-Template TBD 3.3 Grouped | | P | |M,V | 146 |QoS-Resources TBD 3.4 Grouped | | P | |M,V | 147 |Extended-QoS-Filter-Rule TBD 3.5 Grouped | | P | |M,V | 148 |QoS-Semantics TBD 3.6 Enumerated | | P | |M,V | 149 |QoS-Parameters TBD 3.7 OctetString| | P | |M,V | 150 |QoS-Rule-Precedence TBD 3.8 Unsigned32 | | P | |M,V | 151 +------------------------------------------------+----+---+----+----+ 153 3.1. QoS-Capability AVP 155 The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains 156 a list of supported Quality of Service profile templates (and 157 therefore the support of the respective parameter AVPs). 159 QoS-Capability ::= < AVP Header: XXX > 160 1* { QoS-Profile-Template } 161 * [ AVP ] 163 3.2. QoS-Profile-Template AVP 165 The QoS-Profile-Template AVP (AVP Code TBD) is of type Unsigned32 and 166 contains a QoS profile template identifier. An initial QoS profile 167 template is defined with value of 0 and is described in 168 [I-D.ietf-dime-qos-parameters]. The registry for the QoS profile 169 templates is created with the same document. 171 3.3. Vendor-Specific-QoS-Profile-Template AVP 173 The Vendor-Specific-QoS-Profile-Template AVP (AVP Code TBD) is of 174 type Grouped and defines a vendor-specific QoS profile template. 176 The Vendor-Id AVP contains a 32 bit IANA SMI Network Management 177 Private Enterprise Code and the QoS-Profile-Template AVP contains the 178 template identifier assigned by the vendor. 180 Vendor-Specific-QoS-Profile-Template ::= < AVP Header: XXX > 181 { Vendor-Id } 182 { QoS-Profile-Template } 183 * [ AVP ] 185 3.4. QoS-Resources AVP 187 The QoS-Resources AVP (AVP Code TBD) is of type Grouped and includes 188 a description of the Quality of Service resources for policing 189 traffic flows. 191 QoS-Resources ::= < AVP Header: XXX > 192 * [ Extended-QoS-Filter-Rule ] 193 * [ AVP ] 195 3.5. Extended-QoS-Filter-Rule AVP 197 The Extended-QoS-Filter-Rule AVP (AVP Code TBD) is of type Grouped 198 and defines one or more traffic flows together with a set of QoS 199 parameters that should be applied to the flow(s) by the Resource 200 Management Function. This AVP uses the Classifier AVP (see 201 Section 5) to describe traffic flows. 203 Extended-QoS-Filter-Rule ::= < AVP Header: XXX > 204 { QoS-Semantics } 205 { QoS-Profile-Template } 206 [ QoS-Parameters ] 207 [ QoS-Rule-Precedence ] 208 [ Classifier ] 209 * [ AVP ] 211 3.6. QoS-Semantics 213 The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and 214 provides the semantics for the QoS-Profile-Template and QoS- 215 Parameters AVPs in the Extended-QoS-Filter-Rule AVP. 217 This document defines the following values: 219 (0): QoS-Desired 220 (1): QoS-Available 221 (2): QoS-Reserved 222 (3): Minimum-QoS 223 (4): QoS-Authorized 225 3.7. QoS-Parameters AVP 227 The QoS-Parameters AVP (AVP Code TBD) is of type OctetString and 228 contains Quality of Service parameters. These parameters are defined 229 in a separate document, see [I-D.ietf-dime-qos-parameters]. 231 3.8. QoS-Rule-Precedence AVP 233 The QoS-Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and 234 specifies the execution order of the rules expressed in the QoS- 235 Resources AVP. Rules with equal precedence MAY be executed in 236 parallel if supported by the Resource Management Function. If the 237 QoS-Rule-Precedence AVP is absent from the Extended-QoS-Filter-Rule 238 AVP, the rules SHOULD be executed in the order in which they appear 239 in the QoS-Resources AVP. 241 4. Semantics of QoS Parameters 243 The QoS parameters carried in the QoS-Resources AVP may appear in 244 different messages. The semantic of the QoS parameters depend on the 245 information provided in the QoS-Semantics AVP which currently defines 246 5 values, namely QoS-Desired (0), QoS-Available (1), QoS-Reserved 247 (2), Minimum-QoS (3), and QoS-Authorized (4). 249 The semantics of the different values are as follows: 251 Object Type Direction Semantic 252 --------------------------------------------------------------------- 253 QoS-Desired C->S Please authorize the indicated QoS 254 QoS-Desired C<-S NA 255 QoS-Available C->S Admission Control at router indicates 256 that this QoS is available. (note 1) 257 QoS-Available C<-S Indicated QoS is available. (note 2) 258 QoS-Reserved C->S Used for reporting during accounting. 259 QoS-Reserved C<-S NA 260 Minimum-QoS C->S Indicates that the client is not 261 interested in authorizing QoS that is 262 lower than Min. QoS. 263 Minimum-QoS C<-S The client must not provide QoS 264 guarantees lower than Min. QoS. 265 QoS-Authorized C->S NA 266 QoS-Authorized C<-S Indicated QoS authorized 268 Legend: 270 C: Diameter client 271 S: Diameter server 272 NA: Not applicable to this document; 273 no semantic defined in this specification 275 Notes: 277 (1) QoS-Available is only useful in relationship with QoS-Desired 278 (and optionally with Minimum-QoS). 279 (2) QoS-Available is only useful when the AAA server performs 280 admission control and knows about the resources in the network. 282 5. Diameter Classifier AVPs 284 Classifiers are used in many applications to specify how to classify 285 packets. For example in a QoS application, if a packet matches a 286 classifier then that packet will be treated in accordance with a QoS 287 specification associated with that classifier. 289 The Classifiers are sent to on on-path element (e.g. a router) which 290 uses the classifier to match packets. Figure 1 shows a typical 291 deployment. 293 +-----------+ 294 +-----------+| 295 +--------+ +-------------+ +------------+|| 296 | | IN | | | ||| 297 | +--------->| +------------->| ||| 298 |Managed | | Classifying | | Unmanaged ||| 299 |Terminal| OUT | Entity | | Terminal ||| 300 | |<---------+ |<-------------+ ||+ 301 | | | | | |+ 302 +--------+ +-------------+ +------------+ 303 ^ 304 | Classifiers 305 | 306 +------+-------+ 307 | | 308 | AAA | 309 | | 310 +--------------+ 312 Figure 1: Example of a Classifier Architecture 314 The managed terminal, the terminal for which the classifiers are 315 being specified is located on the left of the Classifying Entity. 316 The unmanaged terminal, the terminal that receives packets from the 317 Managed terminal or sends packets to the managed terminal is located 318 to the right side of the Classifying Entity. 320 The Classifying Entity is responsible for classifying packets that 321 are incoming (IN) from the Managed Terminal or packets outgoing (OUT) 322 to the Managed Terminal. 324 A Classifier consists of a group of attributes that specify how to 325 match a packet. Each set of attributes expresses values about 326 aspects of the packet - typically the packet header. Different 327 protocols therefore would use different attributes. 329 In general a Classifier consists of the following: 331 Identifier: 333 The identifier uniquely identifies this classifier and maybe used 334 to reference the classifier from another structure. 336 From: 338 Specifies the rule for matching the source part of the packet. 340 To: 342 Specifies the rule for matching the destination part of the 343 packet. 345 Protocol: 347 Specifies the matching protocol of the packet. 349 Direction: 351 Specifies whether the classifier is to apply to packets flowing 352 from the Managed Terminal (IN) or to packets flowing to the 353 Managed Terminal (OUT), or packets flowing in both direction. 355 Options: 357 Associated with each protocol or layer, or various values specific 358 to the header of the protocol or layer. Options allow matching on 359 those values. 361 Each protocol type will have a specific set of attributes that can be 362 used to specify a classifier for that protocol. These attributes 363 will be grouped under a grouped AVP called a Classifier AVP. 365 The following table lists the Classifer AVPs used by this document, 366 their AVP code values, types and possible flag values. 368 +------------------+ 369 | AVP Flag Rules | 370 +------------------------------------------------|----+---+----+----+ 371 | AVP Section |MUST|MAY|SHLD|MUST| 372 | Attribute Name Code Defined Data Type | | | NOT| NOT| 373 +------------------------------------------------+----+---+----+----+ 374 |Classifier TBD 5.1 Grouped | | P | |M,V | 375 |Classifier-ID TBD 5.2 OctetString| | P | |M,V | 376 |Protocol TBD 5.3 Enumerated | | P | |M,V | 377 |Direction TBD 5.4 Enumerated | | P | |M,V | 378 |From-Spec TBD 5.5 Grouped | | P | |M,V | 379 |To-Spec TBD 5.6 Grouped | | P | |M,V | 380 |Negated TBD 5.7.1 Enumerated | | P | |M,V | 381 |IP-Address TBD 5.7.2 Address | | P | |M,V | 382 |IP-Address-Range TBD 5.7.3 Grouped | | P | |M,V | 383 |IP-Address-Start TBD 5.7.4 Address | | P | |M,V | 384 |IP-Address-End TBD 5.7.5 Address | | P | |M,V | 385 |IP-Address-Mask TBD 5.7.6 Grouped | | P | |M,V | 386 |IP-Mask-Bit-Mask-Width TBD 5.7.7 OctetString| | P | |M,V | 387 |MAC-Address TBD 5.7.8 OctetString| | P | |M,V | 388 |Port TBD 5.7.9 Integer32 | | P | |M,V | 389 |Port-Range TBD 5.7.10 Grouped | | P | |M,V | 390 |Port-Start TBD 5.7.11 Integer32 | | P | |M,V | 391 |Port-End TBD 5.7.12 Integer32 | | P | |M,V | 392 |Use-Assigned-Address TBD 5.7.13 Enumerated | | P | |M,V | 393 |Diffserv-Code-Point TBD 5.8.1 Enumerated | | P | |M,V | 394 |Fragmentation-Flag TBD 5.8.2 Enumerated | | P | |M,V | 395 |IP-Option TBD 5.8.3 Grouped | | P | |M,V | 396 |IP-Option-Type TBD 5.8.4 Enumerated | | P | |M,V | 397 |IP-Option-Value TBD 5.8.5 OctetString| | P | |M,V | 398 |TCP-Option TBD 5.8.6 Grouped | | P | |M,V | 399 |TCP-Option-Type TBD 5.8.7 Enumerated | | P | |M,V | 400 |TCP-Option-Value TBD 5.8.8 OctetString| | P | |M,V | 401 |TCP-Flags TBD 5.8.9 Grouped | | P | |M,V | 402 |TCP-Flag-Type TBD 5.8.10 Enumerated | | P | |M,V | 403 |ICMP-Type TBD 5.8.11 Grouped | | P | |M,V | 404 |ICMP-Type-Number TBD 5.8.12 Enumerated | | P | |M,V | 405 |ICMP-Code TBD 5.8.13 Enumerated | | P | |M,V | 406 +------------------------------------------------+----+---+----+----+ 408 5.1. Classifier AVP 410 The Classifier AVP (AVP Code TBD) is a grouped AVP that consists of a 411 set of attributes that specify how to match a packet. 413 Classifier ::= < AVP Header: XXX > 414 { Classifier-ID } 415 { Protocol } 416 { Direction } 417 * [ From-Spec ] 418 * [ To-Spec ] 419 * [ Diffserv-Code-Point ] 420 [ Fragmentation-Flag ] 421 * [ IP-Option ] 422 * [ TCP-Option ] 423 [ TCP-Flags ] 424 * [ ICMP-Type ] 425 * [ AVP ] 427 5.2. Classifier-ID AVP 429 The Classifier-ID AVP (AVP Code TBD) is of type OctetString and 430 uniquely identifies the classifier. Each application will define the 431 uniqueness scope of this identifier, e.g. unique per terminal or 432 globally unique. Exactly one Classifier-ID AVP MUST be contained 433 within a Classifier AVP. 435 5.3. Protocol AVP 437 The Protocol AVP (AVP Code TBD) is of type Enumerated and specifies 438 the protocol being matched. The attributes included in the 439 Classifier AVP must be consistent with the value of the Protocol AVP. 440 Exactly one Protocol AVP MUST be contained within a Classifier AVP. 441 The values for this AVP are managed by IANA under the Protocol 442 Numbers registry [PROTOCOL]. 444 5.4. Direction AVP 446 The Direction AVP (AVP Code TBD) is of type Enumerated that specifies 447 in which direction to apply the Classifier. The values of the 448 enumeration are: "IN","OUT","BOTH". In the "IN" and "BOTH" 449 directions, the From-Spec refers to the address of the Managed 450 Terminal and the To-Spec refers to the unmanaged terminal. In the 451 "OUT" direction, the From-Spec refers to the Unmanaged Terminal 452 whereas the To-Spec refers to the Managed Terminal. 454 Value | Name and Semantic 455 ------+------------------------------------------------------------ 456 0 | RESERVED 457 1 | IN - The classifier applies to downlink flows only. 458 2 | OUT - The classifier applies to uplink flows only. 459 3 | BOTH - The classifier applies to both downlink 460 | and uplink flows. 462 5.5. From-Spec AVP 464 The From-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the 465 Source Specification used to match the packet. Zero or more of these 466 AVPs may appear in the Classifier. If this AVP is absent from the 467 Classifier then all packets are matched regardless of the source 468 address. If more than one instance of this AVP appears in the 469 Classifier then the source of the packet can match any From-Spec AVP. 470 The contents of this AVP are protocol specific. 472 If more than one instance of the IP address AVPs (IP-Address, IP- 473 Address-Range, IP-Address-Mask, Use-Assigned-Address) appear in the 474 From-Spec AVP then the source IP address of the packet must match one 475 of the addresses represented by these AVPs. 477 If more that one instance of the MAC-Address AVP appears in the From- 478 Spec then the the source MAC address of the packet must match one of 479 the addresses represented in these AVPs. 481 If more that one instance of the port AVPs (Port, Port-Range) appears 482 in the From-Spec AVP then the source port number must match one of 483 the port numbers represented in these AVPs. 485 If the IP address, MAC address and port AVPs appear in the same From- 486 Spec AVP then the source packet must match all the specifications, 487 i.e. match the IP address AND MAC address AND port number. 489 From-Spec ::= < AVP Header: XXX > 490 * [ IP-Address ] 491 * [ IP-Address-Range ] 492 * [ IP-Address-Mask ] 493 * [ MAC-Address ] 494 * [ Port ] 495 * [ Port-Range ] 496 [ Negated ] 497 [ Use-Assigned-Address ] 498 * [ AVP ] 500 5.6. To-Spec AVP 502 The To-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the 503 Destination Specification used to match the packet. Zero or more of 504 these AVPs may appear in the Classifier. If this AVP is absent from 505 the Classifier then all packets are matched regardless of the 506 destination address. If more than one instance of this AVP appears 507 in the Classifier then the destination of the packet can match any 508 To-Spec AVP. The contents of this AVP are protocol specific. 510 If more than one instance of the IP address AVPs (IP-Address, IP- 511 Address-Range, IP-Address-Mask, Use-Assigned-Address) appear in the 512 To-Spec AVP then the destination IP address of the packet must match 513 one of the addresses represented by these AVPs. 515 If more that one instance of the MAC-Address AVP appears in the To- 516 Spec then the the destination MAC address of the packet must match 517 one of the addresses represented in these AVPs. 519 If more that one instance of the port AVPs (Port, Port-Range) appears 520 in the To-Spec AVP then the destination port number must match one of 521 the port numbers represented in these AVPs. 523 If the IP address, MAC address and port AVPs appear in the same To- 524 Spec AVP then the destination packet must match all the 525 specifications, i.e. match the IP address AND MAC address AND port 526 number. 528 To-Spec ::= < AVP Header: XXX > 529 * [ IP-Address ] 530 * [ IP-Address-Range ] 531 * [ IP-Address-Mask ] 532 * [ MAC-Address ] 533 * [ Port ] 534 * [ Port-Range ] 535 [ Negated ] 536 [ Use-Assigned-Address ] 537 * [ AVP ] 539 5.7. Source and Destination AVPs 541 For packet classification the contents of the From-Spec and To-Spec 542 can contain the following AVPs. 544 By combining several of these AVPs within a From-Spec or To-Spec AVP 545 and using more than one From-Spec or To-Spec AVP in the Classifier 546 AVP, one can express many different types of address pools. 548 5.7.1. Negated AVP 550 The Negated AVP (AVP Code TBD) of type Enumerated containing the 551 values of True or False. Exactly zero or one of these AVPs may 552 appear in the From-Spec or To-Spec AVP. When set to True the meaning 553 of the match in the To-Spec and From-Spec are negated, causing all 554 other addresses to be matched instead. 556 When set to False, or when the AVP is not included in the From-Spec 557 or To-Spec AVP then the meaning of the match is not inverted, causing 558 only the addresses specified to be matched. 560 Note that the negation does not impact the port comparisons. 562 Value | Name 563 ------+-------- 564 0 | False 565 1 | True 567 5.7.2. IP-Address AVP 569 The IP-Address AVP (AVP Code TBD) is of type Address and specifies a 570 single IP address (IPv4 or IPv6) address to match. 572 5.7.3. IP-Address-Range AVP 574 The IP-Address-Range AVP (AVP Code TBD) is of type Grouped and 575 specifies an inclusive IP address range. 577 IP-Address-Range ::= < AVP Header: XXX > 578 [ IP-Address-Start ] 579 [ IP-Address-End ] 580 * [ AVP ] 582 If the IP-Address-Start AVP is not included then the address range 583 starts from the first valid IP address up to and including the 584 specified IP-Address-End address. 586 If the IP-Address-End AVP is not included then the address range 587 starts at the address specified by the IP-Address-Start AVP and 588 includes all the remaining valid IP addresses. 590 For the IP-Address-Range AVP to be valid, the IP-Address-Start AVP 591 MUST contain a value that is less than that of the IP-Address-End 592 AVP. 594 5.7.4. IP-Address-Start AVP 596 The IP-Address-Start AVP (AVP Code TBD) is of type Address and 597 specifies the first IP address (IPv4 or IPv6) address of an IP 598 address range. 600 5.7.5. IP-Address-End AVP 602 The IP-Address-End AVP (AVP Code TBD) is of type Address and 603 specifies the last IP address (IPv4 or IPv6) address of an address 604 range. 606 5.7.6. IP-Address-Mask AVP 608 The IP-Address-Mask AVP (AVP Code TBD) is of type Grouped and 609 specifies an IP address range using a base IP address and the bit- 610 width of the mask. For example, a range expressed as 1.2.3.0/24 will 611 match all IP addresses from 1.2.3.0 up to and including 1.2.3.255. 612 The bit-width MUST be valid for the type of IP address. 614 IP-Address-Mask ::= < AVP Header: XXX > 615 { IP-Address } 616 { IP-Bit-Mask-Width } 617 * [ AVP ] 619 5.7.7. IP-Mask-Bit-Mask-Width AVP 621 The IP-Bit-Mask-Width AVP (AVP Code TBD) is of type OctetString. The 622 value is a single octet and specifies the width of an IP address bit- 623 mask. 625 5.7.8. MAC-Address AVP 627 The MAC-Address AVP (AVP Code TBD) is of type OctetString and 628 specifies a single MAC address. The value is a 6 octets encoding of 629 the MAC address as it would appear in the frame header. 631 5.7.9. Port AVP 633 The Port AVP (AVP Code TBD) is of type Integer32 in the range of 0 to 634 65535 and specifies the TCP or UDP port number to match. 636 5.7.10. Port-Range AVP 638 The Port-Range AVP (AVP Code TBD) is of type Grouped and specifies an 639 inclusive range of ports. 641 Port-Range ::= < AVP Header: XXX > 642 [ Port-Start ] 643 [ Port-End ] 644 * [ AVP ] 646 If the Port-Start AVP is omitted then port 0 is assumed. If the 647 Port-End AVP is omitted then port 65535 is assumed. 649 5.7.11. Port-Start AVP 651 The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies 652 the first port number of an IP port range. 654 5.7.12. Port-End AVP 656 The Port-End AVP (AVP Code TBD) is of type Integer32 and specifies 657 the last port number of an IP port range. 659 5.7.13. Use-Assigned-Address AVP 661 In some scenarios, the AAA does not know the IP address assigned to 662 the Managed Terminal at the time that the Classifier is sent to the 663 Classifying Entity. The Use-Assigned-Address AVP (AVP Code TBD) is 664 of type Enumerated containing the values of True or False. When 665 present and set to True, it represents the IP address assigned to the 666 Managed Terminal. 668 Value | Name 669 ------+-------- 670 0 | False 671 1 | True 673 5.8. Header Option AVPs 675 The Classifier AVP may contain one or more of the following AVPs to 676 match on the various possible IP, TCP or ICMP header options. 678 5.8.1. Diffserv-Code-Point AVP 680 The Diffserv-Code-Point AVP (AVP Code TBD) is of type Enumerated and 681 specifies the Differentiated Services Field Codepoints to match in 682 the IP header. The values are managed by IANA under the 683 Differentiated Services Field Codepoints registry [DSCP]. 685 5.8.2. Fragmentation-Flag AVP 687 The Fragmentation-Flag AVP (AVP Code TBD) is of type Enumerated and 688 specifies the packet fragmentation flags to match in the IP header. 690 Value | Name and Semantic 691 ------+------------------------------------------------------------ 692 0 | RESERVED 693 1 | Don't Fragment (DF) 694 2 | More Fragments (MF) 696 5.8.3. IP-Option AVP 698 The IP-Option AVP (AVP Code TBD) is of type Grouped and specifies an 699 IP header option that must be matched. 701 IP-Option ::= < AVP Header: XXX > 702 { IP-Option-Type } 703 * [ IP-Option-Value ] 704 [ Negated ] 705 * [ AVP ] 707 If one or more IP-Option-Value AVPs are present, one of the values 708 MUST match the value in the IP header option. If the IP-Option-Value 709 AVP is absent, the option type MUST be present in the IP header but 710 the value is wild carded. 712 The Negated AVP is used in conjunction with the IP-Option-Value AVPs 713 to specify IP header options which do not match specific values. The 714 Negated AVP is used without the IP-Option-Value AVP to specify IP 715 headers which do not contain the option type. 717 5.8.4. IP-Option-Type AVP 719 The IP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the 720 values are managed by IANA under the IP Option Numbers registry 721 [IPOPTIONS]. 723 5.8.5. IP-Option-Value AVP 725 The IP-Option-Value AVP (AVP Code TBD) is of type OctetString and 726 contains the option value that must be matched. 728 5.8.6. TCP-Option AVP 730 The TCP-Option AVP (AVP Code TBD) is of type Grouped and specifies a 731 TCP header option that must be matched. 733 TCP-Option ::= < AVP Header: XXX > 734 { TCP-Option-Type } 735 * [ TCP-Option-Value ] 736 [ Negated ] 737 * [ AVP ] 739 If one or more TCP-Option-Value AVPs are present, one of the values 740 MUST match the value in the TCP header option. If the TCP-Option- 741 Value AVP is absent, the option type MUST be present in the TCP 742 header but the value is wild carded. 744 The Negated AVP is used in conjunction which the TCP-Option-Value 745 AVPs to specify TCP header options which do not match specific 746 values. The Negated AVP is used without the TCP-Option-Value AVP to 747 specify TCP headers which do not contain the option type. 749 5.8.7. TCP-Option-Type AVP 751 The TCP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the 752 values are managed by IANA under the TCP Option Numbers registry 753 [TCPOPTIONS]. 755 5.8.8. TCP-Option-Value AVP 757 The TCP-Option-Value AVP (AVP Code TBD) is of type OctetString and 758 contains the option value that must be matched. 760 5.8.9. TCP-Flags AVP 762 The TCP-Flags AVP (AVP Code TBD) is of type Grouped and specifies a 763 set of TCP control flags that must be matched. 765 TCP-Flags ::= < AVP Header: XXX > 766 * [ TCP-Flag-Type ] 767 [ Negated ] 768 * [ AVP ] 770 If the Negated AVP is not present, the TCP-Flag-Type AVPs specifies 771 which flags MUST be set. If the Negated AVP is present, the TCP- 772 Flag-Type AVPs specifies which flags MUST be cleared. 774 5.8.10. TCP-Flag-Type AVP 776 The TCP-Flag-Type AVP (AVP Code TBD) is of type Enumerated and 777 specifies a TCP control flag type that must be matched. 779 Value | Name and Semantic 780 ------+------------------------------------------------------------ 781 0 | RESERVED 782 1 | CWR - Congestion Window Reduced. 783 2 | ECE - ECN-Echo. TCP peer is ECN capable. 784 3 | URG - URGent pointer field is significant. 785 4 | ACK - ACKnowledgment field is significant. 786 5 | PSH - Push function. 787 6 | RST - Reset the connection. 788 7 | SYN - Synchronize sequence numbers. 789 8 | FIN - No more data from sender. 791 5.8.11. ICMP-Type 793 The ICMP-Type AVP (AVP Code TBD) is of type Grouped and specifies a 794 ICMP message type that must be matched. 796 ICMP-Type ::= < AVP Header: XXX > 797 { ICMP-Type-Number } 798 * [ ICMP-Code ] 799 [ Negated ] 800 * [ AVP ] 802 If the ICMP-Code AVP is present, the value MUST match that in the 803 ICMP header. If the ICMP-Code AVP is absent, the ICMP type MUST be 804 present in the ICMP header but the code is wild carded. 806 The Negated AVP is used in conjunction which the ICMP-Code AVPs to 807 specify ICMP codes which do not match specific values. The Negated 808 AVP is used without the ICMP-Code AVP to specify ICMP headers which 809 do not contain the ICMP type. 811 5.8.12. ICMP-Type-Number AVP 813 The ICMP-Type-Number AVP (AVP Code TBD) is of type Enumerated and the 814 values are managed by IANA under the ICMP Type Numbers registry 815 [ICMPTYPE]. 817 5.8.13. ICMP-Code AVP 819 The ICMP-Code AVP (AVP Code TBD) is of type Enumerated and the values 820 are managed by IANA under the ICMP Type Numbers registry [ICMPTYPE]. 822 6. Examples 824 This section shows a number of signaling flows where QoS negotiation 825 and authorization is part of the conventional NASREQ, EAP or Credit 826 Control applications message exchanges. The signalling flows for the 827 Diameter QoS Application are described in 828 [I-D.ietf-dime-diameter-qos]. 830 6.1. Diameter EAP with QoS Information 832 Figure 2 shows a simple signaling flow where a NAS (Diameter Client) 833 announces its QoS awareness and capabilities included into the DER 834 message and as part of the access authentication procedure. Upon 835 completion of the EAP exchange, the Diameter Server provides a pre- 836 provisioned QoS profile with the QoS-Semantics in the Extended-QoS- 837 Filter-Rule AVP set to "QoS-Authorized", to the NAS in the final DEA 838 message. 840 End Diameter Diameter 841 Host Client Server 842 | | | 843 | (initiate EAP) | | 844 |<----------------------------->| | 845 | | Diameter-EAP-Request | 846 | | EAP-Payload(EAP Start) | 847 | | QoS-Capability | 848 | |------------------------------->| 849 | | | 850 | | Diameter-EAP-Answer | 851 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 852 | | EAP-Payload(EAP Request #1) | 853 | |<-------------------------------| 854 | EAP Request(Identity) | | 855 |<------------------------------| | 856 : : : 857 : <<>> : 858 : : : 859 | | | 860 | EAP Response #N | | 861 |------------------------------>| | 862 | | Diameter-EAP-Request | 863 | | EAP-Payload(EAP Response #N) | 864 | |------------------------------->| 865 | | | 866 | | Diameter-EAP-Answer | 867 | | Result-Code=DIAMETER_SUCCESS | 868 | | EAP-Payload(EAP Success) | 869 | | [EAP-Master-Session-Key] | 870 | | (authorization AVPs) | 871 | | QoS-Resources(QoS-Authorized) | 872 | |<-------------------------------| 873 | | | 874 | EAP Success | | 875 |<------------------------------| | 876 | | | 878 Figure 2: Example of a Diameter EAP enhanced with QoS Information 880 6.2. Diameter NASREQ with QoS Information 882 Figure 3 shows a similar pre-provisioned QoS signaling as in Figure 2 883 but using the NASREQ application instead of EAP application. 885 End Diameter 886 Host NAS Server 887 | | | 888 | Start Network | | 889 | Attachment | | 890 |<---------------->| | 891 | | | 892 | |AA-Request | 893 | |NASREQ-Payload | 894 | |QoS-Capability | 895 | +----------------------------->| 896 | | | 897 | | AA-Answer| 898 | Result-Code=DIAMETER_MULTI_ROUND_AUTH| 899 | NASREQ-Payload(NASREQ Request #1)| 900 | |<-----------------------------+ 901 | | | 902 | Request | | 903 |<-----------------+ | 904 | | | 905 : : : 906 : <<>> : 907 : : : 908 | Response #N | | 909 +----------------->| | 910 | | | 911 | |AA-Request | 912 | |NASREQ-Payload ( Response #N )| 913 | +----------------------------->| 914 | | | 915 | | AA-Answer| 916 | | Result-Code=DIAMETER_SUCCESS| 917 | | (authorization AVPs)| 918 | |QoS-Resources(QoS-Authorized) | 919 | |<-----------------------------+ 920 | | | 921 | Success | | 922 |<-----------------+ | 923 | | | 925 Figure 3: Example of a Diameter NASREQ enhanced with QoS Information 927 6.3. QoS Authorization 929 Figure 4 shows an example of authorization only QoS signaling as part 930 of the NASREQ message exchange. The NAS provides the Diameter server 931 with the "QoS-Desired" QoS-Semantics AVP included in the QoS- 932 Resources AVP. The Diameter server then either authorizes the 933 indicated QoS or rejects the request and informs the NAS about the 934 result. In this scenario the NAS does not need to include the QoS- 935 Capability AVP in the AAR message as the QoS-Resources AVP implicitly 936 does the same and also the NAS is authorizing a specific QoS profile, 937 not a pre-provisioned one. 939 End Diameter 940 Host NAS Server 941 | | | 942 | | | 943 | QoS Request | | 944 +----------------->| | 945 | | | 946 | |AA-Request | 947 | |Auth-Request-Type=AUTHORIZE_ONLY 948 | |NASREQ-Payload | 949 | |QoS-Resources(QoS-Desired) | 950 | +----------------------------->| 951 | | | 952 | | AA-Answer| 953 | | NASREQ-Payload(Success)| 954 | | QoS-Resources(QoS-Authorized)| 955 | |<-----------------------------+ 956 | Accept | | 957 |<-----------------+ | 958 | | | 959 | | | 960 | | | 962 Figure 4: Example of an Authorization-Only Message Flow 964 6.4. Diameter Server Initiated Re-authorization of QoS 966 Figure 5 shows a message exchange for a Diameter server initiated QoS 967 re-authorization procedure. The Diameter server sends the NAS a RAR 968 message requesting re-authorization for an existing session and the 969 NAS acknowledges it with a RAA message. The NAS is aware of its 970 existing QoS profile and information for the ongoing session that the 971 Diameter server requested for re-authorization. Thus, the NAS must 972 initiate re-authorization of the existing QoS profile. The re- 973 authorization procedure is the same as in Figure 4. 975 End Diameter 976 Host NAS Server 977 | | | 978 | | | 979 : : : 980 : <<>> : 981 : : : 982 | | | 983 | | RA-Request | 984 | |<-----------------------------+ 985 | | | 986 | |RA-Answer | 987 | |Result-Code=DIAMETER_SUCCESS | 988 | +----------------------------->| 989 | | | 990 | | | 991 | |AA-Request | 992 | |NASREQ-Payload | 993 | |Auth-Request-Type=AUTHORIZE_ONLY 994 | |QoS-Resources(QoS-Desired) | 995 | +----------------------------->| 996 | | | 997 | | AA-Answer| 998 | | Result-Code=DIAMETER_SUCCESS| 999 | | (authorization AVPs)| 1000 | | QoS-Resources(QoS-Authorized)| 1001 | |<-----------------------------+ 1002 | | | 1004 Figure 5: Example of a Server-initiated Re-Authorization Procedure 1006 6.5. Diameter Credit Control with QoS Information 1008 In this case the User is charged as soon as the Service Element (CC 1009 client) receives the service request. In this case the client uses 1010 the "QoS-Desired" QoS-Semantics parameter in the QoS-Resources AVP 1011 that it sends to the Accounitng server. The server responds with a 1012 "QoS-Available" QoS-Semantics parameter in the QoS-Resources AVP 1013 Service Element 1014 End User (CC Client) B CC Server 1015 | | | | 1016 |(1) Service Request | | | 1017 |-------------------->| | | 1018 | |(2) CCR (event, DIRECT_DEBITING,| 1019 | | QoS-Resources[QoS-desired]) | 1020 | |-------------------------------->| 1021 | |(3) CCA (Granted-Units, QoS- | 1022 | | Resources[QoS-Authorized]) | 1023 | |<--------------------------------| 1024 |(4) Service Delivery | | | 1025 |<--------------------| | | 1026 |(5) Begin service | | | 1027 |<------------------------------------>| | 1028 | | | | 1029 . . . . 1030 . . . . 1032 Figure 6: Example for a One-Time Diameter Credit Control Charging 1033 Event 1035 6.6. Classifier mapping from IPFilterRule type 1037 6.7. Complex Classifier 1039 7. Acknowledgments 1041 We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, 1042 Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano,Tolga 1043 Asveren, Mike Montemurro,Glen Zorn, Avri Doria, Dong Sun, Tina Tsou, 1044 Pete McCann, Georgios Karagiannis and Elwyn Davies for their 1045 comments. 1047 8. IANA Considerations 1049 This specification requests IANA to assignment of new AVPs from the 1050 AVP Code namespace defined in RFC 3588 [RFC3588]. Section 3 and 1051 Section 5 list the newly defined AVPs. 1053 IANA is requested to allocate a registry for the QoS-Semantics. The 1054 following values are allocated by this specification. 1056 (0): QoS-Desired 1057 (1): QoS-Available 1058 (2): QoS-Reserved 1059 (3): Minimum-QoS 1060 (4): QoS-Authorized 1062 A specification is required to add a new value to the registry. A 1063 standards track document is required to depreciate, delete, or modify 1064 existing values. 1066 9. Security Considerations 1068 This document describes the extension of Diameter for conveying 1069 Quality of Service information. The security considerations of the 1070 Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. 1071 Use of the AVPs defined in this document MUST take into consideration 1072 the security issues and requirements of the Diameter Base protocol. 1074 10. References 1076 10.1. Normative References 1078 [DSCP] IANA,, "Differentiated Services Field Codepoints", 1079 http://www.iana.org/assignments/dscp-registry. 1081 [I-D.ietf-dime-qos-parameters] 1082 Korhonen, J. and H. Tschofenig, "Quality of Service 1083 Parameters for Usage with the AAA Framework", 1084 draft-ietf-dime-qos-parameters-03 (work in progress), 1085 February 2008. 1087 [ICMPTYPE] 1088 IANA,, "ICMP Type Numbers", 1089 http://www.iana.org/assignments/icmp-parameters. 1091 [IPOPTIONS] 1092 IANA,, "IP Option Numbers", 1093 http://www.iana.org/assignments/ip-parameters. 1095 [PROTOCOL] 1096 IANA,, "Protocol Types", 1097 http://www.iana.org/assignments/protocol-numbers. 1099 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1100 Requirement Levels", BCP 14, RFC 2119, March 1997. 1102 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1103 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1105 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1106 "Diameter Network Access Server Application", RFC 4005, 1107 August 2005. 1109 [TCPOPTIONS] 1110 IANA,, "TCP Option Numbers", 1111 http://www.iana.org/assignments/tcp-parameters. 1113 10.2. Informative References 1115 [I-D.ietf-dime-diameter-qos] 1116 Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 1117 and G. Zorn, "Diameter Quality of Service Application", 1118 draft-ietf-dime-diameter-qos-05 (work in progress), 1119 February 2008. 1121 Authors' Addresses 1123 Jouni Korhonen (editor) 1124 TeliaSonera 1125 Teollisuuskatu 13 1126 Sonera FIN-00051 1127 Finland 1129 Email: jouni.korhonen@teliasonera.com 1131 Hannes Tschofenig 1132 Nokia Siemens Networks 1133 Linnoitustie 6 1134 Espoo 02600 1135 Finland 1137 Phone: +358 (50) 4871445 1138 Email: Hannes.Tschofenig@gmx.net 1139 URI: http://www.tschofenig.priv.at 1141 Mayutan Arumaithurai 1142 University of Goettingen 1144 Email: mayutan.arumaithurai@gmail.com 1145 Mark Jones 1146 Bridgewater Systems 1147 303 Terry Fox Drive 1148 Ottawa, Ontario K2K 3J1 1149 Canada 1151 Email: mark.jones@bridgewatersystems.com 1153 Avi Lior 1154 Bridgewater Systems 1155 303 Terry Fox Drive, Suite 500 1156 Ottawa, Ontario 1157 Canada K2K 3J1 1159 Phone: +1 613-591-6655 1160 Email: avi@bridgewatersystems.com 1162 Full Copyright Statement 1164 Copyright (C) The IETF Trust (2008). 1166 This document is subject to the rights, licenses and restrictions 1167 contained in BCP 78, and except as set forth therein, the authors 1168 retain all their rights. 1170 This document and the information contained herein are provided on an 1171 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1172 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1173 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1174 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1175 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1176 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1178 Intellectual Property 1180 The IETF takes no position regarding the validity or scope of any 1181 Intellectual Property Rights or other rights that might be claimed to 1182 pertain to the implementation or use of the technology described in 1183 this document or the extent to which any license under such rights 1184 might or might not be available; nor does it represent that it has 1185 made any independent effort to identify any such rights. Information 1186 on the procedures with respect to rights in RFC documents can be 1187 found in BCP 78 and BCP 79. 1189 Copies of IPR disclosures made to the IETF Secretariat and any 1190 assurances of licenses to be made available, or the result of an 1191 attempt made to obtain a general license or permission for the use of 1192 such proprietary rights by implementers or users of this 1193 specification can be obtained from the IETF on-line IPR repository at 1194 http://www.ietf.org/ipr. 1196 The IETF invites any interested party to bring to its attention any 1197 copyrights, patents or patent applications, or other proprietary 1198 rights that may cover technology that may be required to implement 1199 this standard. Please address the information to the IETF at 1200 ietf-ipr@ietf.org.