idnits 2.17.1 draft-dressler-nsis-metering-nslp-05.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1785. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 abstract seems to contain references ([I-D.fessi-nsis-m-nslp-framework]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (March 5, 2007) is 6233 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: 'RFC2234' is defined on line 1587, but no explicit reference was found in the text == Unused Reference: 'RFC4080' is defined on line 1613, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-psamp-sample-tech' is defined on line 1627, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-psamp-mib' is defined on line 1632, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-psamp-info' is defined on line 1637, but no explicit reference was found in the text == Unused Reference: 'I-D.dressler-ipfix-aggregation' is defined on line 1642, but no explicit reference was found in the text == Unused Reference: 'RFC3917' is defined on line 1647, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nsis-fw' is defined on line 1656, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'I-D.ietf-nsis-ntlp') ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-24 == Outdated reference: A later version (-11) exists of draft-ietf-psamp-sample-tech-07 == Outdated reference: A later version (-11) exists of draft-ietf-psamp-info-05 == Outdated reference: A later version (-05) exists of draft-dressler-ipfix-aggregation-03 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-12 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-13 == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-15 == Outdated reference: A later version (-04) exists of draft-fessi-nsis-m-nslp-framework-03 Summary: 6 errors (**), 0 flaws (~~), 19 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Fessi 3 Internet-Draft G. Carle 4 Expires: September 6, 2007 University of Tuebingen 5 F. Dressler 6 University of Erlangen 7 J. Quittek 8 NEC 9 C. Kappler 10 H. Tschofenig 11 Siemens AG 12 March 5, 2007 14 NSLP for Metering Configuration Signaling 15 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 6, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 Monitoring, metering and accounting of packets are increasingly 49 important functionality that needs to be provided in the Internet. 50 This document proposes the definition of a new NSIS Signaling Layer 51 Protocol (NSLP), named Metering NSLP (M-NSLP), which allows the 52 dynamic configuration of Metering Entities on the data path. An 53 accompanying document [I-D.fessi-nsis-m-nslp-framework] provides a 54 problem statement, describes scenarios where such a path-coupled 55 configuration of Metering Entities is useful, elaborates requirements 56 for a path-coupled protocol for the configuration of Metering 57 Entities and discusses the applicability of NSIS for this purpose. 58 This document defines a Metering NSLP protocol design and messages, 59 and describes the protocol operation. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Model of operation . . . . . . . . . . . . . . . . . . . . 7 69 3.2. Metering NSLP Messages . . . . . . . . . . . . . . . . . . 9 70 3.2.1. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . 9 71 3.2.2. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2.3. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.2.4. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.2.5. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4. Design Decisions . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.1. Soft State . . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.2. Message Sequencing . . . . . . . . . . . . . . . . . . . . 10 79 4.3. Message Scoping . . . . . . . . . . . . . . . . . . . . . 10 80 4.4. Selection of MNEs . . . . . . . . . . . . . . . . . . . . 11 81 4.5. Coordination of Metering Tasks . . . . . . . . . . . . . . 11 82 4.6. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 11 83 4.7. Reaction to Route Changes . . . . . . . . . . . . . . . . 11 84 4.8. Metering Configuration Information . . . . . . . . . . . . 12 85 4.9. Required State Information . . . . . . . . . . . . . . . . 12 87 5. Metering NSLP Messages and Objects . . . . . . . . . . . . . . 13 88 5.1. Metering NSLP Objects . . . . . . . . . . . . . . . . . . 13 89 5.1.1. The 'Session Identifier' Object (SID) . . . . . . . . 13 90 5.1.2. The 'Message Sequence Number' Object (MSN) . . . . . . 13 91 5.1.3. The 'Selection of Metering Entities' Object 92 (MNE_Selection) . . . . . . . . . . . . . . . . . . . 13 93 5.1.4. The 'Session Lifetime' Object (Session_LT) . . . . . . 14 94 5.1.5. The 'MNSLP Hop Count' Object (MNSLP_Hop_Count) . . . . 14 95 5.1.6. The 'Information Code' Object (INFO) . . . . . . . . . 14 96 5.1.7. MSPEC Objects . . . . . . . . . . . . . . . . . . . . 15 97 5.2. Metering NSLP Messages . . . . . . . . . . . . . . . . . . 15 98 5.2.1. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . 15 99 5.2.2. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 15 100 5.2.3. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 15 101 5.2.4. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 16 102 5.2.5. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 16 103 5.3. MSPEC Objects . . . . . . . . . . . . . . . . . . . . . . 16 104 5.3.1. IPFIX MSPEC Object . . . . . . . . . . . . . . . . . . 17 106 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 18 107 6.1. Session State Machine . . . . . . . . . . . . . . . . . . 18 108 6.2. Standard Message Processing Rules . . . . . . . . . . . . 21 109 6.2.1. Message Parsing . . . . . . . . . . . . . . . . . . . 21 110 6.2.2. Authentication and Authorization . . . . . . . . . . . 21 111 6.2.3. Message Sequencing . . . . . . . . . . . . . . . . . . 21 112 6.2.4. MNSLP Hop Counting . . . . . . . . . . . . . . . . . . 22 113 6.3. Message Processing Rules . . . . . . . . . . . . . . . . . 23 114 6.3.1. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . 23 115 6.3.2. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 24 116 6.3.3. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 24 117 6.3.4. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 25 118 6.3.5. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 25 119 6.4. Message Forwarding . . . . . . . . . . . . . . . . . . . . 26 120 6.5. Interaction with GIST . . . . . . . . . . . . . . . . . . 26 122 7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 27 123 7.1. Example with MNE_Selection is ANY . . . . . . . . . . . . 27 124 7.2. Example with MNE_Selection is ALL . . . . . . . . . . . . 28 125 7.3. Example with MNE_Selection is FIRST_and_LAST . . . . . . . 29 126 7.4. Example with a Route Changes . . . . . . . . . . . . . . . 30 128 8. Bit-Level Formats and Error Messages . . . . . . . . . . . . . 30 129 8.1. Metering NSLP Messages . . . . . . . . . . . . . . . . . . 30 130 8.2. Metering NSLP Objects . . . . . . . . . . . . . . . . . . 31 131 8.2.1. MSN . . . . . . . . . . . . . . . . . . . . . . . . . 32 132 8.2.2. Session_LT . . . . . . . . . . . . . . . . . . . . . . 32 133 8.2.3. MNE_Selection . . . . . . . . . . . . . . . . . . . . 32 134 8.2.4. INFO . . . . . . . . . . . . . . . . . . . . . . . . . 33 135 8.2.5. MSPEC Objects . . . . . . . . . . . . . . . . . . . . 33 137 9. Mapping onto M-NSLP Requirements . . . . . . . . . . . . . . . 34 139 10. Security considerations . . . . . . . . . . . . . . . . . . . 36 141 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36 143 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 144 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 145 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36 146 13.2. Informative References . . . . . . . . . . . . . . . . . . 37 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 149 Intellectual Property and Copyright Statements . . . . . . . . . . 41 151 1. Introduction 153 Monitoring, metering and accounting of packets is an important 154 functionality in many networks today. Several working groups have 155 described mechanisms to collect and report usage data for resource 156 consumption in a network by a particular entity. For example, the 157 IPFIX WG defines a protocol for this purpose. The PSAMP WG defines a 158 standard to sample subsets of packets by statistical and other 159 methods. RADIUS (see [RFC2865] and [RFC2866]) and DIAMETER (see 160 [RFC3588] and [I-D.ietf-aaa-diameter-cc]) are also protocols which 161 provide information about consumed resources. The Meter MIB 162 [RFC2720] is a MIB for collecting flow information. 164 However, it is also necessary to configure and coordinate the 165 entities performing the metering. RADIUS, DIAMETER and SNMP are 166 candidates for this configuration. Nevertheless, these protocols 167 require some knowledge about the location of the appropriate Metering 168 Entities to configure them. 170 In more complex network topologies and architectures, the appropriate 171 entities to meter the properties of a given data flow can be 172 discovered dynamically using path-coupled signaling. If more than 173 one Metering Entity is required, all of them can potentially be 174 configured and coordinated with a single message along the path. 176 Scenarios and requirements for Metering NSLP are described in 177 [I-D.fessi-nsis-m-nslp-framework]. 179 This draft defines the Metering NSLP for configuration and 180 coordination of Metering Entities in a path-coupled fashion. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 Furthermore, the terminology defined by GIST [I-D.ietf-nsis-ntlp] 189 applies to this draft. 191 Moreover, this document uses the following terms: 193 Metering Record 195 A Metering Record describes flow characteristics for a particular 196 flow. Examples of such data are packet counter and time 197 information. 199 Monitoring Probe 201 A Monitoring Probe is an entity that examines data flows in order 202 to gather Metering Records. 204 Metering Entity 206 A Metering Entity is a node that is equipped with one or more 207 Monitoring Probes. A Metering Entity MAY process the Metering 208 Records, e.g. by aggregating them or by sampling them, before they 209 are exported elsewhere, typically to a Collector. A Metering 210 Entity MAY host other functions, for example, for processing of 211 NSIS signaling. 213 Collector 215 A Collector receives Metering Records from one or multiple 216 Metering Entities. These Metering Records can be aggregated 217 and/or correlated by the Collector. The Collector is typically 218 not co-located with a Metering Entity. Another protocol (e.g. 219 IPFIX) is needed to transport the Metering Records from the 220 Metering Entity to the Collector. 222 Metering Configuration State 224 A State used/kept by the Metering Manager to configure the 225 Monitoring Probe. 227 Metering Manager 229 A unit co-located with the Monitoring Probe that communicates with 230 M-NSLP processing. It holds Metering Configuration State which is 231 used to configure the Monitoring Probe. 233 Metering NSIS Entity (MNE) 235 A Metering Entity which supports the Metering NSLP. 237 Metering NSIS Initiator (MNI) 239 The first node in the sequence of MNEs that issues a configuration 240 message for a flow or aggregate. 242 Metering NSIS Responder (MNR) 244 The last node in the sequence of MNEs that receives a 245 configuration message for a flow or aggregate. 247 Metering NSIS Forwarder (MNF) 249 A MNE that is neither MNI nor MNR. 251 3. Protocol Overview 253 The design for the Metering NSLP and the processing of M-NSLP 254 messages is in some aspects similar to QoS NSLP 255 [I-D.ietf-nsis-qos-nslp] and in other aspects to the NATFW NSLP 256 [I-D.ietf-nsis-nslp-natfw]. One of the main differences compared to 257 the QoS NSLP and the NATFW NSLP is that only a subset (in some cases 258 even only one) of the Metering Entities in the signaling path will 259 take part in the actual Metering. This fact has several consequences 260 on the signaling itself and therefore on the protocol design. 262 3.1. Model of operation 264 Figure 1 shows an example logical model of the operation of the 265 Metering NSLP and the associated metering mechanism in a MNE. 267 +---------------+ 268 | Local | 269 | Management | 270 +---------------+ 271 ^ 272 V 273 +---------+ +----------+ +----------+ 274 | Policy | | M-NSLP | | Metering | 275 | Control |<<>>|Processing|<<>>| Manager | 276 +---------+ +----------+ +----------+ 277 . ^ | V 278 | ^ . V 279 | V . V 280 | V . V 281 +----------+ V 282 | GIST | V 283 .-.-.-.-.-|Processing|-.-.-v.-.-.-.-.-.-.- 284 . +----------+ V | 285 | v . 286 . v | 287 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 288 | v | 289 . v . 290 | +---------------------+ | 291 +----------+ | | +-----------+ 292 <-.-| Input | | Monitoring | | Outgoing |-.-> 293 | Packet | | | | Interface | 294 ===>|Processing|===| Probe |====| |==> 295 +----------+ | | +-----------+ 296 +---------------------+ 298 <.-.-> = signaling flow 299 =====> = data flow (sender --> receiver) 300 <<<>>> = control and configuration operations 302 Figure 1: Metering-NSLP in Metering Entity 304 The Monitoring Probe collects metering data and processes them into 305 Metering Records, which can be sent to the Collector. The Monitoring 306 Probe is co-located with the Input Packet Processing and the Outgoing 307 Interface. 309 A M-NSLP message called CONFIGURE transports: 310 o Control information objects for the M-NSLP Processing, such as 311 message sequence numbers and whether the MNE should actually take 312 part in the metering process 314 o Metering configuration information objects, also called MSPEC 315 objects, that describe the actual configuration information. The 316 MSPEC objects are interpreted by the Metering Manager and SHOULD 317 be opaque to the M-NSLP Processing. 318 o Policy information to authenticate and authorize the configuration 319 request 321 The M-NSLP Processing decides if the current MNE is addressed by this 322 configuring message. If yes, the MSPEC objects are extracted from 323 the M-NSLP message and passed to the Metering Manager, where they are 324 interpreted and used to install Metering Configuration State. The 325 Metering Manager uses this state to configure the Monitoring Probe. 327 The Policy Control determines whether the sender of the M-NSLP 328 message is authorized to configure the Monitoring Probe. 330 From the perspective of a single node, the request for configuration 331 of Metering Entities may result from processing a local management 332 request, or from processing an incoming M-NSLP message. The local 333 management may in turn be triggered by a local application, e.g. when 334 a video is requested from a video server, or by a physically separate 335 network node. 337 3.2. Metering NSLP Messages 339 The Metering NSLP messages are classified into 3 categories: 340 o request messages 341 o response messages 342 o asynchronous notifications 344 3.2.1. CONFIGURE 346 CONFIGURE is a M-NSLP request message. It is used to create Metering 347 Configuration State in a Metering Entity. 349 3.2.2. REFRESH 351 REFRESH is a M-NSLP request message. It is used: 352 o to extend the lifetime of an existing M-NSLP session. 353 o for terminating a session (with session lifetime zero). 354 o to detect route changes at the NSLP layer. 356 3.2.3. OPTIONS 358 OPTIONS is a M-NSLP request message. It is used to inquire the 359 metetering capabilities of MNEs along the signaling path. 361 3.2.4. RESPONSE 363 The RESPONSE message is used to provide information about the result 364 of a previous M-NSLP request. This includes explicit confirmation of 365 the state manipulation signaled in the CONFIGURE/REFRESH message or 366 an error code. 368 3.2.5. NOTIFY 370 The NOTIFY message is an asynchronous notifications message used to 371 convey information to a MNE. It differs from RESPONSE messages in 372 that it is sent asynchronously and does not need to refer to any 373 particular state or previously received message. The information 374 conveyed by a NOTIFY message is typically related to error 375 conditions. An example would be a notification to the MNI about 376 state being torn down. 378 4. Design Decisions 380 4.1. Soft State 382 NSIS state is always soft state and needs to be refreshed. The 383 control information in CONFIGURE/REFRESH messages carry an object 384 that determines the lifetime of a M-NSLP session. The MNI suggests a 385 lifetime for the session that it is being signaled for. Each MNE 386 participating in the metering process MAY or MAY not accept the 387 suggested lifetime or MAY start the metering with a reduced lifetime, 388 depending on the local policies of the MNEs. This behavior is 389 similar to the calculation of session lifetime in the NATFW-NSLP 390 [I-D.ietf-nsis-nslp-natfw]. 392 4.2. Message Sequencing 394 The order in which M-NSLP requests arrive influences the eventual 395 configuration state that will be stored at a MNE. Therefore the 396 M-NSLP supports the detection of message duplication and re-ordering 397 using a Message Sequence Number (MSN) object. More Details on 398 Message Sequencing are provided in Section 6.2.3 400 4.3. Message Scoping 402 Metering Entities at the edge of a signaling scope (for example, at 403 the edge of the administrative domain of an ISP) MUST be marked 404 accordingly. The Metering NSLP does not provide means by itself to 405 discover dynamically the border of the signaling scope. 407 When a MNE recognize that it is at the edge of the signaling scope, 408 it MUST terminate the signaling and act as NSIS Responder (NR). 410 4.4. Selection of MNEs 412 An interesting feature of the Metering NSLP is that only a subset of 413 MNEs on the data path might take part in the actual metering. 414 Metering Entities taking part in the metering process are determined 415 based, for example, on their type or position on the path. 417 When a CONFIGURE message is sent, each MNE on the data path needs to 418 determine whether it will take part in the metering process. For 419 this reason, the 'Selection of Metering Entities' object is included 420 in CONFIGURE messages. 422 4.5. Coordination of Metering Tasks 424 The M-NSLP allocates different metering tasks to different Metering 425 Entities on the signaling path depending on their position and 426 metering capabilities. A 'Correlation ID' is included in the MSPEC 427 and distributed to the Metering Entities during the configuration 428 process. This 'Correlation ID' can be forwarded to the Collector, 429 which can correlate Metering Records coming from different Metering 430 Entities and belonging to the same session/measurement. 432 4.6. Aggregation 434 The metering configuration SHOULD allow aggregation of Metering 435 Records belonging to the same user or application. The information 436 required for the aggregation must be specified in the MSPEC. Such 437 aggregation can be done in two ways. 438 o A Monitoring Probe separately collects and reports data for each 439 micro flow (e.g., given for all different combinations of port 440 numbers) contained in the macro flow that is signaled by the NTLP. 441 o A Monitoring Probe separately collects micro flows but reports all 442 flows in a single record. 444 4.7. Reaction to Route Changes 446 M-NSLP automatically adapts to re-routing events. State along the 447 old path times out automatically. When a new REFRESH message is 448 initiated by the MNI and hits a MNE that is a new on the signaling 449 path, the MNE sends a negative RESPONSE with error code "Unknown 450 Session" backwards to the MNI. The MNI MAY re-initiate the signaling 451 along the new path. 453 Since metering tasks are allocated dynamically to MNEs on the path, 454 when a MNE receives a CONFIGURE message for an existing session, old 455 state for this session MUST be torn down and a new session is created 456 in order to avoid inconsistencies with an old configuration. 458 4.8. Metering Configuration Information 460 The actual configuration information for the Metering Entities is 461 carried within the MSPEC objects. MSPEC objects are interpreted by 462 the Metering Manager and SHOULD be opaque to M-NSLP Processing. Each 463 MSPEC object contains a meter configuration. A single CONFIGURE 464 message MAY contain multiple MSPEC objects describing different 465 metering tasks, which MAY be allocated to different MNEs. 467 The Metering NSLP does not provide its own format for encoding the 468 MSPEC objects. Instead, formats of existing protocols, such as IPFIX 469 [I-D.ietf-ipfix-protocol], Diameter [RFC3588], or NetFlow [RFC3954], 470 are re-used. The encoding of an MSPEC object depends on the metering 471 and reporting technology. For example, the MSPEC object used for the 472 configuration of an IPFIX device is encoded in IPFIX format. 473 Technology-specific encoding avoids the problems of mapping the 474 different semantics of information models for these technologies to 475 each other. 477 4.9. Required State Information 479 For each M-NSLP session, the required state information at each MNE 480 consists of: 482 NTLP state 484 NTLP state is required for each M-NSLP session at each MNE on the 485 signaling path, even if the MNE is not taking part in the metering 486 process, in order to avoid GIST re-discovering the MNE each time 487 when it refreshes its routing state [I-D.ietf-nsis-ntlp]. 489 M-NSLP state 491 M-NSLP state is required for each M-NSLP session at each MNE on 492 the signaling path. Even if the MNE is not taking part in the 493 metering process a minimal session state is required, which 494 consists of the Session Identifier (SID) and the Session Lifetime 495 (Session_LT). 496 Assume MNEs located on the signaling path, which are not taking 497 part in the metering process, would not save M-NSLP state for this 498 M-NSLP session. Then when a MNE receives a REFRESH message with 499 an unknown Session ID, it would not be able to make the 500 difference: 501 * whether the MNE is new on the signaling path due to a route 502 change 504 * or whether the MNE has been already on the signaling path but 505 is not taking part in the metering process. 506 Therefore, the MNE needs to keep M-NSLP state for this session in 507 order to be aware of it. Implementations of the M-NSLP MAY 508 include optimizations to reduce the amount of memory required if 509 the session is known but the MNE is not taking part in the 510 metering process. 512 Metering Configuration State (Optional) 514 Metering Configuration State is required for each M-NSLP only if 515 the MNE is taking part in the metering process. It includes the 516 MSPEC objects which describe the metering tasks that are allocated 517 to the MNE. 519 5. Metering NSLP Messages and Objects 521 5.1. Metering NSLP Objects 523 5.1.1. The 'Session Identifier' Object (SID) 525 SID is globally statistically unique identifier for a MNSLP session. 526 SID is not carried explicitly by MNSLP messages. It is rather 527 carried by GIST. 529 SID MUST be generated for each new MNSLP session by the MNI and 530 provided to GIST via the GIST API. All MNFs and the MNR receive the 531 SID via the GIST API and MUST NOT modify it. 533 Note that this is conform to the specification of GIST 534 [I-D.ietf-nsis-ntlp]: Section 3.5. (Signaling Sessions): "Signaling 535 applications provide the session identifier (SID) whenever they wish 536 to send a message, and GIST reports the SID when a message is 537 received." 539 5.1.2. The 'Message Sequence Number' Object (MSN) 541 MSN is used to detect duplicate and lost Metering NSLP messages. It 542 is also used to to mach an incoming RESPONSE message to the 543 appropriate request. 545 5.1.3. The 'Selection of Metering Entities' Object (MNE_Selection) 547 This object is required to determine which MNEs will actually take 548 part in the metering. The value of MNE_Selection can be one of the 549 following: 551 o FIRST: the first MNE in the signaling path, i.e. the NI. 553 o LAST: the last MNE signaling in the signaling path, i.e. the NR 555 o 'FIRST_and_LAST': both the NI and the NR take part in the 556 signaling. 558 o ANY: any available MNE can perform the metering. 560 o ALL: Each MNE capable of executing this metering request MUST 561 perform it. "ALL" must be interpreted here as "as many as 562 possible". 564 o Enterprise-specific: Enterprises may wish to define their own 565 methods to decide which Metering Entities should perform the 566 metering. In this case, the parameter 'Selection of Metering 567 Entities' needs to be combined with an enterprise-specific 568 identifier. (See also 569 http://www.iana.org/assignments/enterprise-numbers) If enterprises 570 use their own defined methods for the MNE selection, some other 571 M-NSLP objects not defined in this document may be required to 572 take the decision which MNE will take part in the metering 573 process. 575 5.1.4. The 'Session Lifetime' Object (Session_LT) 577 This object carries the requested lifetime for a M-NSLP session in a 578 CONFIGURE / REFRESH message or the granted session lifetime in a 579 RESPONSE message, in milliseconds. When a M-NSLP session expires, 580 the Metering Manager MUST configure the Monitoring Probe to stop the 581 Metering. 583 A value of zero for the 'Session Lifetime' object leads to immediate 584 termination of the corresponding session. 586 5.1.5. The 'MNSLP Hop Count' Object (MNSLP_Hop_Count) 588 This object carries the number of previous MNEs on the signaling path 589 for this session. This object is a integer which starts by zero at 590 the MNI and MUST be incremented by one at each MNSLP hop on the 591 signaling path. 593 5.1.6. The 'Information Code' Object (INFO) 595 This object carries the response code, which may be an indication for 596 either a successful or failed request depending on the value of the 597 'response code' field (See Section 8.2.4 for more details). 599 5.1.7. MSPEC Objects 601 The MSPEC objects describe the actual Configuration information. 602 They are interpreted in the Metering Manager and SHOULD be opaque to 603 M-NSLP Processing. MSPEC objects are described separately in 604 Section 5.3. 606 5.2. Metering NSLP Messages 608 This section defines which objects are carried in each Metering NSLP 609 message. The description is provided in Augmented Backus-Naur Form 610 (ABNF) specified in [RFC4234]. Message format at the bit-level is 611 provided in Section 8 613 The ABNF implies an order for the objects in a message. However, in 614 many (but not all) cases, object order makes no logical difference. 615 An implementation should create messages with the objects in the 616 order shown here, but accept the objects in any order, except for 617 MSPEC object(s) which always appear last in the message, and whose 618 mutual order matters. 620 All M-NSLP messages start with a common header 'HEADER' which is 621 defined in Section 8 623 Note that the Session ID (SID) is not explicitly mentioned in this 624 notation, since it is provided in GIST. 626 5.2.1. CONFIGURE 628 The format of a CONFIGURE message is as follows: 630 CONFIGURE = HEADER MSN Session_LT MNE_Selection [MNSLP_Hop_Count] 631 <1>*MSPEC 633 (According to [RFC4234] '<1>*MSPEC' means 'one or more MSPEC 634 objects') 636 5.2.2. REFRESH 638 The format of a REFRESH message is as follows: 640 REFRESH = HEADER MSN Session_LT 642 5.2.3. OPTIONS 644 The format of a OPTIONS message is as follows: 646 OPTIONS = HEADER MSN 648 5.2.4. RESPONSE 650 The format of a RESPONSE message is as follows: 652 RESPONSE = HEADER MSN INFO Session_LT <0>*MSPEC 654 (According to [RFC4234] '<0>*MSPEC' means 'zero or more MSPEC 655 objects') 657 The MSN MUST be the same as in the corresponding M-NSLP request in 658 order to match a RESPONSE message to the appropriate request 660 Session_LT carries the granted session lifetime, which might be lower 661 than the session lifetime requested by the MNI. 663 NO MSPEC object MUST be included if INFO indicates a successful 664 confirmation of the request. The MSPEC objects are required only to 665 report a failure in case the MSPEC objects list in the CONFIGURE 666 message, or a sub-set of it, can not be processed. 668 5.2.5. NOTIFY 670 The format of a NOTIFY message is as follow: 672 NOTIFY = HEADER INFO 674 The INFO indicates the reason for the notification. 676 5.3. MSPEC Objects 678 As mentioned above, the MSPEC objects describe the actual 679 configuration information. They are interpreted in the Metering 680 Manager and SHOULD be opaque to M-NSLP Processing. Each MSPEC object 681 contains a meter configuration. The MRI provides additional 682 information to the MSPEC object on the flows/packets to be metered. 683 The combination of the MRI and an MSPEC object contains a complete 684 description of a requested metering task. A single CONFIGURE message 685 may contain multiple MSPEC objects describing different metering 686 tasks. 688 There is no common format or semantics for encoding metering tasks 689 within an MSPEC object. The encoding of an MSPEC object depends on 690 the requested metering and reporting technology, such as IPFIX, 691 Diameter, or NetFlow. 693 There are different types of MSPEC objects depending on the metering 694 and reporting technology. For example, there are IPFIX MSPEC 695 objects, Diamter MSPEC objects, etc. The object type, which is 696 provided in the object header as described in Section 8.2, implicits 697 the requested metering and reporting technology. 699 Independently of the encoding, each MSPEC object MUST, in combination 700 with the MRI, contain sufficient information for configuring an MNE 701 to peform a metering task. Specifications of MSPEC objects MUST 702 ensure that they provide sufficient means for configuring the MNE as 703 described in sections 4.1.2 and 4.2.2 of 704 [I-D.fessi-nsis-m-nslp-framework]. 706 Below the MSPEC object for IPFIX metering tasks is specified. MSPEC 707 objects for other meters may be defined in further standards 708 documents. Proprietary MSPEC objects MAY be also used. 710 5.3.1. IPFIX MSPEC Object 712 The IPFIX MSPEC object uses structure, semantics and encoding of 713 IPFIX Messages as defined in [I-D.ietf-ipfix-protocol] and 714 [I-D.ietf-ipfix-info]. An IPFIX MSPEC object consists of a single 715 IPFIX Message that contains three Sets, a Template Set, an Option 716 Template Set, and a Data Set. Each set contains a single record only. 718 Fields of the header of the contained IPFIX Message are filled with 719 values according to section 3.1 of [I-D.ietf-ipfix-protocol] except 720 for fields "Export Time" and "Observation Domain ID" which must be 721 both set to 0x00000000. 723 The Template Record in the Template Set defines the requested 724 reporting. Except for the Template ID in the Template Record Header, 725 the MNE MUST use exactly this Template Record for reporting metering 726 results. The MNE also MUST use the Template ID received in the 727 Template record for its metering reports. But if there is a 728 collision caused by two different MSPEC objects (potentially from 729 different NSIS sessions) that would violate the uniqueness of 730 Template IDs as specified in section 3.4.1 of 731 [I-D.ietf-ipfix-protocol], then the MNE MUST solve this conflict by 732 modifying Template IDs. In order to keep the probability of such a 733 collision low, the Template ID SHOULD be a randomly generated number. 735 The Option Template Record in the Option Template Set describes the 736 format of the single Data Record in the Data Set. To the Template ID 737 the same rules apply as for the Template Record. The Scope Field 738 Count is always 0. 740 The Data Record in the Data Set contains the requested metering 741 configuration. It is structured according to the Option Template 742 Record in the Option Template Set. It MUST contain the following 743 Information Elements that are specified in [I-D.ietf-ipfix-info]. 745 flowKeyIndicator 747 This Information Element identifies which of the reported Flow 748 properties are Flow Keys. 750 collectorIPv4Address or collectorIPv6Address, respectively 752 The IPv4 or IPv6 address, respectively, to which metering results 753 are requested to be reported. 755 collectorProtocolVersion 757 The version of the IPFIX protocol to be used. 759 collectorTransportProtocol and collectorTransportPort 761 The transport protocol and transport port number to be used for 762 reporting metering results 764 The Data record MAY contain further Information Elements for 765 specifying the metering task, for example, the flowIdleTimeout. 767 If flow properties to be measured are specified in the Data record, 768 they serve as filter. Only Flows that match the values of all these 769 Information Element MUST be reported by the MNE. If multiple values 770 are contained for the same property, i.e. it multiple Information 771 Elements with the same Information Element identifier are contained, 772 then it is sufficient if one of these values is matched by a Flow. 774 6. Processing Rules 776 6.1. Session State Machine 778 The hereby presented state machine of a M-NSLP session outlines the 779 operation of the M-NSLP. It has three main states: 781 'closed': 783 At this state, the MNE does not keep any state for the session. 785 'pending': 787 At this state a CONFIGURE message has been received. The 788 'pending' state consists of 2 sub-states 789 pending.forward 791 The MNE is not taking part in the metering process. Instead, 792 it is just expecting a confirmation to know that the session is 793 active and some other MNEs will be metering. 795 pending.participating 797 The MNE is actively taking part in the metering process. The 798 MNE has been configured. However, the configuration has not 799 been activated yet, i.e. metering function has not been 800 started. 802 'metering': 804 At this state the configuration request has been successfully 805 confirmed with an appropriate RESPONSE message. The 'metering' 806 state consists also of 2 sub-states. 808 metering.forward 810 The MNE is not actively taking part in the metering process. 811 Instead, it is informed that the session is active and there 812 are some other MNEs along the signaling path for this session 813 that took over the metering process. 815 metering.participating 817 The MNE is actively taking part in the metering process The MNE 818 is metering according to a metering configuration received by a 819 CONFIGURE message. 821 A session is uniquely identified by the SID. All sessions start in 822 state 'closed'. Transitions between states are caused by events: 824 CONF: 826 This transition is triggered by a CONFIGURE message that is 827 received and processed successfully by the MNE and that identifies 828 a new session. 830 CONF-O: 832 This transition is triggered by a CONFIGURE message that is 833 received and processed successfully by the MNE and that identifies 834 an existing session in state 'pending' or 'metering'. This 835 transition leads always to the state 'closed' in order to avoid 836 inconsistencies with old configurations. Furthermore, this 837 transition MUST be immediately followed by a 'CONF' transition, 838 i.e. after the old session is torn down, a new session is created. 840 REFR: 842 This transition is triggered by a REFRESH message that identifies 843 an existing session in state 'pending' or 'metering'. 845 RESP-P: 847 This transition is triggered by a positive RESPONSE message that 848 indicates that a metering configuration request or a refreshing 849 request can be activated. This transaction always leads to state 850 'metering'. 852 RESP-N: 854 This transition is triggered by a negative RESPONSE message. This 855 transaction always leads to state 'closed'. 857 T-OUT-1: 859 This transition is triggered by a timeout of a session in state 860 'pending'. The time interval for this timeout is typically large 861 enough in order to tolerate network failures, network congestion 862 and slow MNEs along the signaling path. This transition always 863 leads to state 'closed'. 865 T-OUT-2: 867 This transition is triggered by a timeout of a session in state 868 'metering'. The time interval for this timeout is defined by the 869 MNSLP session lifetime. This transition always leads to state 870 'closed'. 872 REFR +----+ 873 | v 874 +----------+ 875 | session | 876 | closed |<---------------+ 877 +----------+ | 878 | ^ | 879 | | CONF-O | CONF-O 880 CONF | | RESP-N | RESP-N 881 v | T-OUT-1 | T-OUT-2 882 +----------+ +----------+ 883 | pending | RESP-P | metering | 884 | |---------->| | 885 +----------+ +----------+ 886 | ^ | ^ 887 REFR | | REFR | | 888 +----+ RESP-P +----+ 890 Figure 2: M-NSLP Session State Machine 892 6.2. Standard Message Processing Rules 894 6.2.1. Message Parsing 896 When a M-NSLP message is received, the MNE first checks the message 897 format. In case of a malformed message or a mandatory object is 898 missing, the MNE MUST NOT propagate the message any further. If the 899 message has been a request the MNE MUST construct an RESPONSE message 900 indicating the error condition and send it back to towards the MNI. 901 If it has been a response, the message is discarded silently. 903 If a message contains an object of an unrecognized type, then the 904 behavior depends on the object type value. 906 6.2.2. Authentication and Authorization 908 When a M-NSLP message is received, the MNE MUST determine whether the 909 sender of the request is authenticated and authorized before any 910 state changing actions are performed. 912 6.2.3. Message Sequencing 914 Message sequencing in the Metering NSLP is identical to message 915 sequencing in the NATFW NSLP. 917 In more details: 919 M-NSLP messages need to carry an identifier so that all MNEs along 920 the path can distinguish messages sent at different points in time. 921 Messages can be lost along the path or duplicated. So all MNEs 922 should be able to identify either old messages that have been 923 received before (duplicated), or the case that messages have been 924 lost before (loss). This requires every Metering message to carry a 925 message sequence number (MSN), see also Section 5.1.2. 927 The MSN MUST be set by the NI and MUST NOT be set or modified by any 928 other MNE. The initial value for the MSN MUST be generated randomly 929 and MUST be unique only within the session for which it is used. The 930 NI MUST increment the MSN by one for every message sent. Once the 931 MSN has reached the maximum value, the next value it takes is zero. 932 All MNEs MUST use the algorithm defined in [RFC1982] to detect MSN 933 wrap-arounds. 935 NSIS forwarders and the responder store the MSN from the initial 936 CONFIGURE packet which creates the session as the start value for the 937 session. NFs and NRs MUST include the received MSN value in the 938 corresponding RESPONSE message that they generate. 940 When receiving a request message, a MNE uses the MSN given in the 941 message to determine whether the state being requested is different 942 to the state already installed. If the received MSN value is equal 943 to or lower than the stored MSN value, this can indicate a duplicated 944 or replayed message. In this case, the message MUST NOT have any 945 impact the state of the MNE or the MNSLP session. However, the 946 message MUST be forwarded towards the next MNSLP hop, since one or 947 more of the MNEs on the rest of the signaling path may have not 948 received this message yet. 950 If the received MSN value is greater than the already stored MSN 951 value, the MNE MUST update its stored state accordingly, if permitted 952 by all security checks, and stores the updated MSN value accordingly. 954 6.2.4. MNSLP Hop Counting 956 Depending on the application scenario for the MNSLP, MNEs may need to 957 know their position on the signaling path. In this case, a MNE needs 958 to make the difference between: 959 o the number of IP hops between the MNI and itself 960 o the number of GIST hops between the MNI and itself 961 o the number of MNSLP hops between the MNI and itself 963 The GIST-hop-count and IP-TTL can be provided by the GIST API as 964 described in [I-D.ietf-nsis-ntlp] (Section B.1 and Section B.2). 966 The MNI MAY introduce an 'MNSLP Hop Count' object in the CONFIGURE 967 message. In cases it does, it MUST set the 'MNSLP Hop Count' to 968 zero. 970 If a 'MNSLP Hop Count' object is included in a CONFIGURE message, 971 MNFs and MNRs MUST increment the 'MNSLP Hop Count' by one before the 972 message is forwarded to the next MNSLP hop. 974 6.3. Message Processing Rules 976 6.3.1. CONFIGURE 978 When a MNE receives a CONFIGURE message, and after successful message 979 parsing and authentication/authorization are performed, the MNE 980 performs a lookup in its M-NSLP session table. If the session 981 already exists, the state for this session MUST be torn down and a 982 new session MUST be created in order to avoid inconsistencies with 983 earlier configurations due to the dynamic allocation of the MSPEC 984 objects to the MNEs. 986 Now, regardless of whether the session is new or has been renewed, 987 the MNE needs to figure out if it will take part in the metering 988 process based on the MNE_Selection object, the MSPEC objects list and 989 the capabilities of the MNE. 991 6.3.1.1. MNE_Selection is ALL 993 o If the MNE is capable of metering the objects in the MSPEC objects 994 list, then the MNE is taking part in the metering process. The 995 MNE MUST change the current session state to 996 'pending.participating'. 998 o If the MNE is NOT capable of metering the objects in the MSPEC 999 objects list, then the MNE is NOT taking part in the metering 1000 process. The MNE MUST change the current session state to 1001 'pending.forward' 1003 6.3.1.2. MNE_Selection is FIRST_and_LAST 1005 If MNE_Selection is FIRST_and_LAST and the MNE is the first or the 1006 last on the signaling path: 1008 o If the MNE is capable of metering the objects in the MSPEC objects 1009 list, then the MNE is taking part in the metering process. The 1010 MNE MUST change the current session state to 1011 'pending.participating'. 1013 o If MSPEC objects can not be metered, i.e. the MNE is the first or 1014 the last on the signaling path but is not capable to measure the 1015 objects given in the MSPEC objects list, the MNE generates a 1016 negative RESPONSE message with the appropriate INFO object. The 1017 MNE changes the current session state to 'closed'. 1018 o EDITORIAL NOTE: The case FIRST_and_LAST is different from the 1019 cases ALL and ANY here. 1021 If MNE_Selection is FIRST_and_LAST and the MNE is NOT the first NOR 1022 the last on the signaling path, the MNE MUST change the current 1023 session state to 'pending.forward'. 1025 6.3.1.3. MNE_Selection is ANY 1027 In case MNE_Selection is 'ANY', the MNE inspects the MSPEC objects 1028 list and removes those objects that it is capable to meter and adds 1029 them to its local MSPEC objects list for this session. This local 1030 MSPEC objects list represents the list of metering tasks allocated to 1031 this MNE for this session. 1032 o After inspecting the MSPEC objects list in the CONFIGURE message, 1033 if the local MSPEC objects list is empty, i.e. the MNE is not able 1034 to meter any of the given objects in the MSPEC objects list, the 1035 MNE MUST change the current session state to 'pending.forward'. 1036 o If the local MSPEC objects list is NOT empty, i.e. the MNE has 1037 been allocated some metering tasks from the MSPEC objects list, 1038 the MNE MUST change the current session state to 1039 'pending.participating'. The local MSPEC objects is stored in the 1040 Metering Configuration State in order to use when the 1041 configuration will be activated. 1043 6.3.2. REFRESH 1045 When a MNE receives a REFRESH message, and after successful message 1046 parsing and authentication/authorization are performed, the MNE 1047 performs a lookup in its M-NSLP session table. 1048 o If the Session ID is not known, the MNE constructs a negative 1049 RESPONSE message with the appropriate error code and sends it 1050 upstream towards the MNI. 1051 o If the Session ID is found, the MNE remembers the requested 1052 lifetime in the REFRESH message and waits for a confirmation with 1053 a RESPONSE message. The current session state remains the same. 1055 6.3.3. OPTIONS 1057 tbd. 1059 6.3.4. RESPONSE 1061 When a MNE receives a RESPONSE message and after successful message 1062 parsing and authentication/authorization are performed, the remaining 1063 processing of the RESPONSE message depends on whether it is a 1064 negative RESPONSE or a positive RESPONSE. If it is a negative 1065 RESPONSE with the appropriate INFO object: 1066 o The MNE MUST change the current state for this session to 1067 'closed'. 1068 o The MNE MAY keep state information for this session for 1069 optimization purposes, since the the MNI may re-initiate the 1070 signaling with different parameters soon. 1071 o The MNE MUST forward the message upstream towards the MNI as 1072 described in Section 6.4. 1074 When the MNI receives this message it MAY take the appropriate action 1075 based on the content of the INFO object. 1077 If the RESPONSE message is a positive RESONSE, the processing of the 1078 message depends on the type of the corresponding M-NSLP request: 1080 RESPONSE to a CONFIGURE message 1082 The pending configuration can be activated. If the session is 1083 currently in state 'pending.participating' the MNE MUST change the 1084 session state to 'metering.participating', and the Monitoring 1085 Probe MUST be configured to start the metering. 1086 If the session is in state 'pending.forward' the MNE MUST change 1087 the session state to 'metering.forward'. No configuration action 1088 with the Monitoring Probe is taken. 1090 RESPONSE to a REFRESH message 1092 All existing timeouts for this session are reset. The session 1093 lifetime is extended with the lifetime given in the RESPONSE 1094 message. Note that this can be different from the session 1095 lifetime given in the previous REFRESH message. 1097 In both cases, the MNE updates the session lifetime. If the session 1098 lifetime is zero, this implies that the session state is changed 1099 immediately to 'closed'. 1101 6.3.5. NOTIFY 1103 tbd. 1105 6.4. Message Forwarding 1107 CONFIGURE / REFRESH 1109 After a M-NSLP request is successfully processed as described in 1110 Section 6.3 (no error has been generated), then the session can be 1111 either in state 'pending' or 'metering'. Now, MNE needs to decide 1112 whether to forward the M-NSLP request towards the MNR or to 1113 construct a positive RESPONSE message. M-NSLP requests MUST be 1114 forwarded downstream except if: 1115 * the M-NSLP request has reached the MNR 1116 * the 'scoping' flag is set and the signaling scope has been 1117 reached. 1118 * all the involved MNEs in the metering process for this session 1119 have been reached. 1121 The latter case can occur with a CONFIGURE request if 1122 MNE_Selection is 'ANY' and the MSPEC objects list has become 1123 empty, i.e. an appropriate MNE has been already found for each 1124 object in the MSPEC objects list and all the metering tasks have 1125 been allocated to some Metering Entities. 1127 EDITORIAL NOTE: it has to verified whether this is the only case. 1129 In this case, the MNE MUST act as a MNR for this session from now 1130 on. All the remaining requests MUST NOT be forwarded any further. 1132 RESPONSE / NOTIFY 1134 M-NSLP response messages and asynchronous notifications are 1135 forwarded upstream, i.e. the reverse direction of the data flow, 1136 until they reach the MNI. 1138 6.5. Interaction with GIST 1140 M-NSLP request messages (CONFIGURE or REFRESH) are initiated by the 1141 MNI and forwarded downstream, i.e. in the same direction as the data 1142 flow, towards the MNR, using the GIST API. 1144 M-NSLP response messages can be initiated by the MNR or by any MNF on 1145 the signaling path and forwarded upstream, i.e. in the reverse 1146 direction as the data flow, towards the MNI, using the GIST API. 1148 M-NSLP asynchronous notifications can be initiated by any MNE on the 1149 signaling path and forwarded upstream, i.e. in the reverse direction 1150 as the data flow, towards the MNI, using the GIST API. 1152 All M-NSLP signaling is transported using GIST C-mode. 1154 EDITORIAL NOTE: it should be verified whether D-mode might be also an 1155 option for initial configuration messages. However, authentication/ 1156 authorization issues need to be considered. 1158 7. Examples of Operation 1160 7.1. Example with MNE_Selection is ANY 1162 The MNI constructs a CONFIGURE message with the required MSPEC 1163 objects, and sends it towards the MNR. Assume 2 MSPEC objects are 1164 included, for example, MSPEC1 for 'counting bytes', and MSPEC2 for 1165 'reporting the usage of the wireless link'. Assume further that MNI 1166 itself can perform MSPEC1 while and MNF2 can perform MSPEC2, for 1167 example, because it is an access router managing a range of WLAN 1168 networks. MNR can be, for example, the WLAN access point. 1170 The CONFIGURE message is interpreted by the MNEs along the data path. 1172 MNI removes MSPEC1 from the MSPEC objects list, changes its session 1173 state from 'closed' to 'pending.participating' and forwards the 1174 CONFIGURE message to MNF1. 1176 MNF1 receives the CONFIGURE message with only MSPEC2 in the MSPEC 1177 objects list. However, MNF1 does not have the capabilities to meter 1178 and report the usage of the wireless link. MNF1 changes its session 1179 state from 'closed' to 'pending.forward' and forwards the CONFIGURE 1180 message to MNF2. 1182 MNF2 interprets the CONFIGURE, removes MSPEC2 from the MSPEC objects 1183 list. Furthermore, it notices that the MSPEC object lists is now 1184 empty. Therefore, MNF2 replies with a positive RESPONSE message and 1185 becomes Responder for this session. Subsequent signaling for this 1186 session is stopped at MNF2 as shown in Figure 4. MNF2 starts the 1187 metering, changes the session state to 'metering.participating', 1188 constructs a positive RESPONSE message and sends it to MN1. 1190 MNF1 receives the RESPONSE message and changes the session state to 1191 'metering.forward'. 1193 MNI receives the RESPONSE message, starts the metering and changes 1194 the session state to 'metering.participating'. 1196 +---+ CONFIGURE +--- + CONFIGURE +-- -+ +---+ 1197 | |------------>| |------------>| | | | 1198 |MNI| |MNF1| |MNF2| |MNR| 1199 | |<------------| |<------------| | | | 1200 +---+ RESPONSE +--- + RESPONSE +----+ +---+ 1202 Figure 3: CONFIGURE-RESPONSE Message Flow with MNE_Selection 'ANY' 1204 +---+ REFRESH +---+ REFRESH +---+ +---+ 1205 | |------------>| |------------>| | | | 1206 |MNI| |MNF| |MNF| |MNR| 1207 | |<------------| |<------------| | | | 1208 +---+ RESPONSE +---+ RESPONSE +---+ +---+ 1210 Figure 4: REFRESH-RESPONSE Message Flow with MNE_Selection 'ANY' 1212 7.2. Example with MNE_Selection is ALL 1214 The MNI constructs a CONFIGURE message with the required MSPEC 1215 objects, and sends it towards the MNR. The message is interpreted by 1216 each MNEs on the data path. Each MNE changes its state for this 1217 session to 'pending.participating' or 'pending.forward' depending on 1218 whether they are taking part of the metering process. 1220 The MNR replies with a positive RESPONSE message. The RESPONSE 1221 message is interpreted by each MNE. Each MNE changes the session 1222 state to 'metering.participating' or 'metering.forward' depending on 1223 whether they are taking part of the metering process. 1225 +---+ CONFIGURE +---+ CONFIGURE +---+ CONFIGURE +---+ 1226 | |------------>| |------------>| |------------>| | 1227 |MNI| |MNF| |MNF| |MNR| 1228 | |<------------| |<------------| |<------------| | 1229 +---+ RESPONSE +---+ RESPONSE +---+ RESPONSE +---+ 1231 Figure 5: CONFIGURE-RESPONSE Message Flow with MNE_Selection 'ALL' 1233 Similarly, a REFRESH message is initiated by MNI, travels towards the 1234 MNR where a RESPONSE is issued and sent back. 1236 +---+ REFRESH +---+ REFRESH +---+ REFRESH +---+ 1237 | |------------>| |------------>| |------------>| | 1238 |MNI| |MNF| |MNF| |MNR| 1239 | |<------------| |<------------| |<------------| | 1240 +---+ RESPONSE +---+ RESPONSE +---+ RESPONSE +---+ 1242 Figure 6: REFRESH-RESPONSE Message Flow with MNE_Selection 'ALL' 1244 7.3. Example with MNE_Selection is FIRST_and_LAST 1246 The MNI constructs a CONFIGURE message with the required MSPEC 1247 objects, and sends it towards the MNR. The message is interpreted by 1248 each MNEs on the data path. Each MNE changes its state for this 1249 session to 'pending.forward' except MNI itself and MNR, which perform 1250 a transition to the state 'pending.participating'. 1252 The MNR replies with a positive RESPONSE message. The RESPONSE 1253 message is interpreted by each MNE. Each MNE changes the session 1254 state to 'metering.forward' except MNR and MNI, which perform a 1255 transition to the state 'metering.participating'. 1257 +---+ CONFIGURE +---+ CONFIGURE +---+ CONFIGURE +---+ 1258 | |------------>| |------------>| |------------>| | 1259 |MNI| |MNF| |MNF| |MNR| 1260 | |<------------| |<------------| |<------------| | 1261 +---+ RESPONSE +---+ RESPONSE +---+ RESPONSE +---+ 1263 Figure 7: CONFIGURE-RESPONSE Message Flow with MNE_Selection 1264 'FIRST_and_LAST' 1266 Similarly, a REFRESH message is initiated by MNI, travels towards the 1267 MNR where a RESPONSE is issued and sent back. 1269 +---+ REFRESH +---+ REFRESH +---+ REFRESH +---+ 1270 | |------------>| |------------>| |------------>| | 1271 |MNI| |MNF| |MNF| |MNR| 1272 | |<------------| |<------------| |<------------| | 1273 +---+ RESPONSE +---+ RESPONSE +---+ RESPONSE +---+ 1275 Figure 8: REFRESH-RESPONSE Message Flow with MNE_Selection 1276 'FIRST_and_LAST' 1278 7.4. Example with a Route Changes 1280 Assume a topology as in Figure 9: 1282 +-------+ +-------+ +-------+ +-------+ 1283 | MNI |----| MNF1 |-----| MNF2 |----| MNR1 | 1284 +-------+ +-------+ | +-------+ +-------+ 1285 | 1286 | +-------+ +-------+ +-----+ 1287 +---| MNF3 |----| MNR2 |----|host | 1288 +-------+ +-------+ +-----+ 1290 Figure 9: Example with a Route Change' 1292 After a route change MNF2 and MNR1 are not on the signaling path 1293 anymore. MNF3 is new on the signaling path and receives a REFRESH 1294 message with an unknown Session ID. It sends a negative RESPONSE 1295 with error code "Unknown Session". 1297 MNI receives the negative RESPONSE and re-initiates the signaling 1298 with a CONFIGURE message with the same Session ID. 1300 When the MNE receives a CONFIGURE message with the same Session ID it 1301 re-starts the configuration process: the session is considered as a 1302 new session. 1304 8. Bit-Level Formats and Error Messages 1306 8.1. Metering NSLP Messages 1308 All Metering NSLP messages start with a common header 'HEADER'. The 1309 Metering NSLP common header is similar to the QoS NSLP header. Note 1310 that it is not the same as the GIST Common Header. 1312 0 1 2 3 1313 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 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Message Type | Message Flags | Generic Flags | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 Figure 10: M-NSLP Message Common Header 1320 The fields in the common header are as follows: 1322 Message Type: 8 bits 1324 1 = CONFIGURE 1325 2 = RESPONSE 1326 3 = NOTIFY 1328 Message-specific flags: 8 bits 1329 These flags are defined as part of the specification of individual 1330 messages. 1332 Generic flags: 16 bits 1333 There exists currently one generic flag, the Scoping bit (S). The 1334 use of the S-bit is described with each message that makes use of 1335 it. 1337 The set of appropriate flags depends on the particular message 1338 being processed. Any bit not defined as a flag for a particular 1339 message MUST be set to zero on sending and MUST be ignored on 1340 receiving. 1342 8.2. Metering NSLP Objects 1344 The Metering NSLP uses the Type-Length-Value (TLV) object format 1345 defined by GIST [I-D.ietf-nsis-ntlp]. Every object consists of one 1346 or more 32-bit words with a one-word header. For convenience the 1347 standard object header is shown here: 1349 0 1 2 3 1350 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 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 |A|B|r|r| Type |r|r|r|r| Length | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 Figure 11: M-NSLP Object Common Header 1357 The value for the Type field comes from Metering NSLP object type 1358 space, the various objects are presented in subsequent sections. The 1359 Length field is given in units of 32 bit words and measures the 1360 length of the Value component of the TLV object (i.e., it does not 1361 include the standard header). 1363 The bits marked 'A' and 'B' are extensibility flags, and used to 1364 signal the desired treatment for objects whose treatment has not been 1365 defined in the protocol specification (i.e., whose Type field is 1366 unknown at the receiver). 1368 EDITORIAL NOTE: include text here for the explanation of the meaning 1369 of the A and B bits. 1371 8.2.1. MSN 1373 Type: MNSLP_MSN 1375 Length: 1 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Message Sequence Number | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 Figure 12: Message Sequence Number Object 1383 8.2.2. Session_LT 1385 Type: MNSLP_Session_LT 1387 Length: 1 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Session Lifetime | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 Figure 13: Session Lifetime Object 1395 8.2.3. MNE_Selection 1397 Type: MNSLP_MNE_Selection 1399 Length: 1 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Selection of Metering Entities | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 Figure 14: Selection of Metering Entities Object 1407 Possible values are: 1408 1 = ALL 1409 2 = ANY 1410 3 = FIRST 1411 4 = LAST 1412 5 = FIRST_and_LAST 1413 greater than 1024 : Enterprise Specific 1415 EDITORIAL NOTE: it still needs to be defined in the case Enterprise 1416 Specific, how MNSLP_SelectionMNEs is encoded. 1418 8.2.4. INFO 1420 This object carries the response code, which may be indications for 1421 either a successful request or failed request depending on the value 1422 of the 'response code' field. 1424 Note that the format of this object is similar the INFO object for 1425 the NATFW NSLP. 1427 Type: MNSLP_INFO 1429 Length: 1 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Resv. | Class | Response Code | Object Type | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 Figure 15: Information Code Object 1437 The field 'Resv.' is reserved for future extensions and MUST be set 1438 to zero when generating such an object and MUST be ignored when 1439 receiving. The 'Object Type' field contains the type of the object 1440 causing the error. The value of 'Object Type' is set to 0, if no 1441 object is concerned. The 4 bit class field contains the severity 1442 class. The following classes are defined: 1443 o 0x1: Informational (NOTIFY only) 1444 o 0x2: Success 1445 o 0x3: Protocol error 1446 o 0x4: Transient failure 1447 o 0x5: Permanent failure 1448 o 0x6: Signaling session failures 1450 EDITORIAL NOTE: Response Codes need to be defined here. 1452 8.2.5. MSPEC Objects 1454 Type: 1456 Different types are possible. 1458 * MNSLP_IPFIX_MSPEC 1459 * MNSLP_DIAMETER_MSPEC 1460 * MNSLP_NETFLOW9 1461 Note that this list is extensible. 1462 Length: Variable. 1464 9. Mapping onto M-NSLP Requirements 1466 EDITORIAL NOTE: This section needs to be updated. 1468 With the design described above, the requirements from 1469 [I-D.fessi-nsis-m-nslp-framework] are at this point satisfied as 1470 follows: 1472 Extensibility: 1474 The actual configuration information is encapsulated in the MSPEC. 1475 The MSPEC is designed such as it is interpreted by the Metering 1476 Manager and can be opaque to the M-NSLP processing. Furthermore, 1477 the MSPEC can be easily extended. Therefore, from the point of 1478 view of the configuration information, this requirement is 1479 fulfilled. Note however, that the Metering NSLP in its current 1480 design might show some lack of extensibility. For example, 1481 considering the selection of the MNEs, it might be useful for 1482 future application of the Metering NSLP to have the option "ANY 1483 N", where N is greater than one. 1485 Interoperability: 1487 Again, whether different metering solutions can interwork depends 1488 on how the MSPEC is designed. In QoS NSLP, the QSpec template 1489 design [I-D.ietf-nsis-qspec] aims at similar extensibility and 1490 interoperability. It needs to be studied whether or not the 1491 solutions chosen by the QSpec can also be applied to the MSPEC. 1493 Flexible metering models: 1495 As above, this is an issue of MSPEC design. 1497 Distinguishing flows 1499 The aggregation feature detailed in this requirement can be 1500 realized as described in Section 4.6. 1502 Flexible data collection: 1504 Another issue that can be fixed in the MSPEC. 1506 Location of Metering Entities: 1508 MNEs, including MNI and MNR can be located anywhere on the data 1509 path. 1511 Access parameters of the Collector Information: 1513 Access parameters of the Collector Information on how to deliver 1514 flow records to the Collector is coded in the MSPEC. 1516 Configuration of Metering Entities: 1518 The protocol can configure Metering Entities that are MNEs, or 1519 that are controlled by MNEs. 1521 Selection of Metering Entities: 1523 As described in Section 4.4, a MNE should be able to decide to 1524 pull out of the metering process. This is realized by the 1525 'Selection of Metering Entities' object. 1527 Metering Configuration State installation and removal: 1529 By means of the CONFIGURE message, the protocol can install and 1530 remove Metering Configuration State. 1532 Initiation and maintenance of metering tasks: 1534 Triggers and correlation identifier are transported in the MSPEC. 1536 Reaction to Route Changes: 1538 The protocol detects route changes by a REFRESH or a refreshing 1539 CONFIGURE message and installs state along the new route, as 1540 described in Section 4.7. 1542 Scoping of configuration: 1544 The M-NSLP needs to provide sufficient means for flexible scoping 1545 signaling messages. 1547 Requirements not mentioned in this list are not yet addressed. 1549 10. Security considerations 1551 The process of configuring entities to start and stop metering and to 1552 transmit collected resource records to a third party introduces 1553 security challenges. 1555 An extensive analysis of security issues related to the Metering NSLP 1556 is presented in Section 7 of [I-D.fessi-nsis-m-nslp-framework]. 1557 Based on this section, future versions of the M-NSLP protocol 1558 specification will elaborate the required security mechanisms for the 1559 M-NSLP. 1561 11. Open Issues 1563 Open issues for the Metering NSLP are discussed here: 1564 https://www.ri.uni-tuebingen.de/cgi-bin/roundup.cgi/mnslp/ 1566 12. Acknowledgements 1568 The authors would like to thank Robert Hancock, Martin Stiemerling 1569 and Andreas Klenk for their valuable input. 1571 Furthermore, the authors would like to thank Angie So. By providing 1572 the first running prototype of the Metering NSLP, she gave us a 1573 helpful feedback for the protocol specification. 1575 13. References 1577 13.1. Normative References 1579 [I-D.ietf-nsis-ntlp] 1580 Schulzrinne, H. and R. Hancock, "GIST: General Internet 1581 Signalling Transport", draft-ietf-nsis-ntlp-12 (work in 1582 progress), March 2007. 1584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1585 Requirement Levels", BCP 14, RFC 2119, March 1997. 1587 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1588 Specifications: ABNF", RFC 2234, November 1997. 1590 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1591 Specifications: ABNF", RFC 4234, October 2005. 1593 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1594 August 1996. 1596 13.2. Informative References 1598 [RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 1599 RFC 2720, October 1999. 1601 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1602 "Remote Authentication Dial In User Service (RADIUS)", 1603 RFC 2865, June 2000. 1605 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1607 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1608 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1610 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 1611 9", RFC 3954, October 2004. 1613 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1614 Bosch, "Next Steps in Signaling (NSIS): Framework", 1615 RFC 4080, June 2005. 1617 [I-D.ietf-ipfix-protocol] 1618 Claise, B., "Specification of the IPFIX Protocol for the 1619 Exchange", draft-ietf-ipfix-protocol-24 (work in 1620 progress), November 2006. 1622 [I-D.ietf-ipfix-info] 1623 Quittek, J., "Information Model for IP Flow Information 1624 Export", draft-ietf-ipfix-info-15 (work in progress), 1625 February 2007. 1627 [I-D.ietf-psamp-sample-tech] 1628 Zseby, T., "Sampling and Filtering Techniques for IP 1629 Packet Selection", draft-ietf-psamp-sample-tech-07 (work 1630 in progress), July 2005. 1632 [I-D.ietf-psamp-mib] 1633 Dietz, T. and B. Claise, "Definitions of Managed Objects 1634 for Packet Sampling", draft-ietf-psamp-mib-06 (work in 1635 progress), June 2006. 1637 [I-D.ietf-psamp-info] 1638 Dietz, T., "Information Model for Packet Sampling 1639 Exports", draft-ietf-psamp-info-05 (work in progress), 1640 October 2006. 1642 [I-D.dressler-ipfix-aggregation] 1643 Dressler, F., "IPFIX Aggregation", 1644 draft-dressler-ipfix-aggregation-03 (work in progress), 1645 June 2006. 1647 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1648 "Requirements for IP Flow Information Export (IPFIX)", 1649 RFC 3917, October 2004. 1651 [I-D.ietf-nsis-qos-nslp] 1652 Manner, J., "NSLP for Quality-of-Service Signaling", 1653 draft-ietf-nsis-qos-nslp-12 (work in progress), 1654 October 2006. 1656 [I-D.ietf-nsis-fw] 1657 Hancock, R., "Next Steps in Signaling: Framework", 1658 draft-ietf-nsis-fw-07 (work in progress), December 2004. 1660 [I-D.ietf-nsis-nslp-natfw] 1661 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 1662 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-13 (work in 1663 progress), October 2006. 1665 [I-D.ietf-nsis-qspec] 1666 Ash, J., "QoS NSLP QSPEC Template", 1667 draft-ietf-nsis-qspec-15 (work in progress), 1668 February 2007. 1670 [I-D.fessi-nsis-m-nslp-framework] 1671 Fessi, A., "Framework for Metering NSLP", 1672 draft-fessi-nsis-m-nslp-framework-03 (work in progress), 1673 June 2006. 1675 [I-D.ietf-aaa-diameter-cc] 1676 Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H. 1677 Hakala, "Diameter Credit-control Application", 1678 draft-ietf-aaa-diameter-cc-06 (work in progress), 1679 August 2004. 1681 [3GPP.32.240] 1682 3GPP, "Telecommunication management; Charging management; 1683 Charging architecture and principles", 3GPP TS 32.240 1684 6.0.0, September 2004. 1686 Authors' Addresses 1688 Ali Fessi 1689 University of Tuebingen 1690 Wilhelm-Schickard-Institute for Computer Science 1691 Sand 13 1692 Tuebingen 72072 1693 Germany 1695 Phone: +49 7071 29-70576 1696 Email: fessi@informatik.uni-tuebingen.de 1697 URI: http://net.informatik.uni-tuebingen.de/ 1699 Georg Carle 1700 University of Tuebingen 1701 Wilhelm-Schickard-Institute for Computer Science 1702 Sand 13 1703 Tuebingen 72072 1704 Germany 1706 Phone: +49 7071 29-70505 1707 Email: carle@informatik.uni-tuebingen.de 1708 URI: http://net.informatik.uni-tuebingen.de/ 1710 Falko Dressler 1711 University of Erlangen 1712 Department of Computer Science 7 1713 Martensstr. 3 1714 Erlangen 91058 1715 Germany 1717 Phone: +49 9131 85-27914 1718 Email: dressler@informatik.uni-erlangen.de 1719 URI: http://www7.informatik.uni-erlangen.de/ 1721 Juergen Quittek 1722 NEC 1723 Kurfuersten-Anlage 36 1724 Heidelberg 69115 1725 Germany 1727 Phone: +49 6221 90511-15 1728 Email: quittek@netlab.nec.de 1729 URI: http://www.netlab.nec.de/ 1730 Cornelia Kappler 1731 Siemens AG 1732 Siemensdamm 62 1733 Berlin 13627 1734 Germany 1736 Phone: +49 30 386-32894 1737 Email: cornelia.kappler@siemens.com 1739 Hannes Tschofenig 1740 Siemens AG 1741 Otto-Hahn-Ring 6 1742 Munich, Bayern 81739 1743 Germany 1745 Email: Hannes.Tschofenig@siemens.com 1747 Full Copyright Statement 1749 Copyright (C) The IETF Trust (2007). 1751 This document is subject to the rights, licenses and restrictions 1752 contained in BCP 78, and except as set forth therein, the authors 1753 retain all their rights. 1755 This document and the information contained herein are provided on an 1756 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1757 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1758 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1759 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1760 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1761 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1763 Intellectual Property 1765 The IETF takes no position regarding the validity or scope of any 1766 Intellectual Property Rights or other rights that might be claimed to 1767 pertain to the implementation or use of the technology described in 1768 this document or the extent to which any license under such rights 1769 might or might not be available; nor does it represent that it has 1770 made any independent effort to identify any such rights. Information 1771 on the procedures with respect to rights in RFC documents can be 1772 found in BCP 78 and BCP 79. 1774 Copies of IPR disclosures made to the IETF Secretariat and any 1775 assurances of licenses to be made available, or the result of an 1776 attempt made to obtain a general license or permission for the use of 1777 such proprietary rights by implementers or users of this 1778 specification can be obtained from the IETF on-line IPR repository at 1779 http://www.ietf.org/ipr. 1781 The IETF invites any interested party to bring to its attention any 1782 copyrights, patents or patent applications, or other proprietary 1783 rights that may cover technology that may be required to implement 1784 this standard. Please address the information to the IETF at 1785 ietf-ipr@ietf.org. 1787 Acknowledgment 1789 Funding for the RFC Editor function is provided by the IETF 1790 Administrative Support Activity (IASA).