idnits 2.17.1 draft-mark-powd-00.txt: -(245): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(420): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 11 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7592 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: 'Figure 3-2' is mentioned on line 185, but not defined == Missing Reference: 'RFC1305' is mentioned on line 242, but not defined ** Obsolete undefined reference: RFC 1305 (Obsoleted by RFC 5905) == Unused Reference: 'DuGG03' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'QuZC03' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'TPBC03' is defined on line 536, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ClDG00' -- Possible downref: Non-RFC (?) normative reference: ref. 'DuGG03' -- Possible downref: Non-RFC (?) normative reference: ref. 'DuGr00' -- Possible downref: Non-RFC (?) normative reference: ref. 'GrDM98' -- Possible downref: Non-RFC (?) normative reference: ref. 'QuZC03' -- Possible downref: Non-RFC (?) normative reference: ref. 'TPBC03' -- Possible downref: Non-RFC (?) normative reference: ref. 'ZsZC01' ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft L. Mark 3 Document: G. Pohl 4 Expires: January 2004 T. Zseby 5 Fraunhofer FOKUS 6 K. Sugauchi 7 Hitachi 9 June 2003 11 Passive One-way Delay Measurement 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. Internet-Drafts are draft 22 documents valid for a maximum of six months and may be updated, 23 replaced, or obsoleted by other documents at any time. It is 24 inappropriate to use Internet-Drafts as reference material or to 25 cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes a non-intrusive method for measuring 36 one-way delay of IP packets. 38 Table of Contents 40 1. Introduction.................................................2 41 2. Terminology..................................................2 42 3. General Architecture.........................................3 43 4. Observation Point Selection..................................5 44 5. Packet Capturing.............................................5 45 6. Timestamping.................................................5 46 7. Filtering/Classification.....................................5 47 8. Packet ID Generation.........................................6 48 9. OWD Calculation Process......................................7 49 10. Measurement Result Transfer..................................7 50 11. Security Considerations......................................8 51 11.1 Measurement Infrastructure...................................8 52 11.2 Exchange of Measurement Data.................................8 53 11.3 Sensitivity..................................................9 54 12. References...................................................9 55 13. Author's Addresses..........................................10 56 14. Full Copyright Statement....................................10 57 1. Introduction 59 There exist a variety of motivations for performing passive 60 measurements in IP networks. Many applications require the 61 measurement of the Quality of Service (QoS) for the transport of 62 specific IP flows or traffic aggregates. Network providers and 63 customers are interested whether negotiated QoS values in SLAs 64 are met (SLA validation). Measurements also provide the basis 65 for usage-based accounting. Furthermore, measurement results are 66 an important input for traffic engineering decisions. 68 Special motivations for One-way delay measurements are listed in 69 RFC2679. The advantage of passive measurements is that these 70 measurements are based on existing traffic within the network. 71 They provide a statement about the delay of the current traffic 72 in the observed network section. Since no test traffic is 73 generated, passive measurements can only be applied in cases 74 where the kind of traffic we are interested in is already 75 present in the network. This is the case for most applications 76 where a statements about the actual situation in the network is 77 required (like SLA validation, traffic engineering). 79 The goodness of the results of passive QoS measurements depend 80 on the choice of the right observation points because the 81 measurement results are only valid between the observation 82 points. 84 This draft adopts the terminology of IPFIX, PSAMP and IPPM. 86 2. Terminology 88 Collecting Process 89 The collecting process receives records of flow or packet 90 information. The data is stored for later processing (by 91 the calculation process) 93 Exporting Process 94 The exporting processes send flow and packet records to the 95 collecting processes. The records are generated by the 96 measurement process. 98 IP Packet Selection Process 99 An IP packet selection process takes IP packets or parts of 100 IP packets (e.g. header) as input and extracts a subset of 101 these packets by applying a selection function. 103 Filtering 104 Filtering selects a subset of packets by applying 105 deterministic functions on parts of the packet content like 106 header fields or parts of the payload. A filtering process 107 needs to process the packet (look at packet header and/or 108 payload) in order to make the selection decision. 110 Measurement Device 111 A measurement device has access to at least one observation 112 point. It is hosting at least one measurement process and 113 one export process. 115 Metering/Measurement Process 116 The measurement process generates records of packet and 117 flow information. Packets passing the observation point are 118 captured, timestamped, filtered and classified. The 119 measurement process calculates the packet IDs. 121 3. General Architecture 123 Passive one-way delay measurements require two measurement 124 processes at two observation points � at a reference and at a 125 monitor observation point. We consider a unidirectional flow of 126 packets as determined by source and destination address of its 127 packets. The mentioned reference observation point is closer to 128 the source of the packets while the monitor observation point is 129 closer to the destination of the flow. The two measurement 130 processes at reference and monitor observation point generate a 131 timestamp and a unique packet ID for each packet as it passes an 132 observation point. The information is sent to a common 133 collecting process. A calculation process uses the data to 134 calculate the one-way delay. (This structure is shown in [Figure 135 3-1: Passive OWD Measurement Setup].) 137 +-----------------+ 138 | Calculation | 139 | Process | 140 | | 141 +-----------------+ 142 ^ 143 | 144 +--------+--------+ 145 | Collecting | 146 +------>| Process |<-----+ 147 | | | | 148 | +-----------------+ | 149 +----------+-----------+ +----------+-----------+ 150 | Exporting | | Exporting | 151 | Process | | Process | 152 | (1)| | (2)| 153 +----------+-----------+ +----------+-----------+ 154 ^ ^ 155 .............|................................|................. 156 . | | . 157 . +----------+-----------+ +----------+-----------+ . 158 . | Measurement | | Measurement | . 159 . | Process | | Process | . 160 . | (1)| | (2)| . 161 . +----------+-----------+ +----------+-----------+ . 162 . |reference point |monitor point . 163 .............|................................|................. 164 | | 165 | Network under Observation | 166 ===========*================================*===============>> 168 [Figure 3-1: Passive OWD Measurement Setup] 170 For each packet that is measured a timestamp and a packet ID has 171 to be generated, stored and transmitted to a collecting process. 172 Then the delay calculation takes place, based on correlating 173 results from the different observation points. Therefore the 174 amount of measurement result data that arises per second depends 175 on the number of measured packets n per second, the number of 176 bits l_t used for the representation of the timestamp and the 177 number of bits l_id for the packet ID. 179 The location of the collecting process does not need to be 180 necessarily physically different from the measurement process. 181 Instead, the collecting process could be co-located with one of 182 the measurement processes in order to reduce the effort for 183 transmitting measurement data. 185 [Figure 3-2] presents a refined view of the OWD Measurement 186 Processes. 188 to Exporting Process (1) to Exporting Process (2) 189 ^ ^ 190 | | 191 .............|................................|................. 192 . | | . 193 . | id, T_ref | id, T_mon . 194 . | [class] | [class] . 195 . +----------+-----------+ +----------+-----------+ . 196 . | Packet ID Generation | | Packet ID Generation | . 197 . +----------+-----------+ +----------+-----------+ . 198 . ^ ^ . 199 . |packet,T_ref, |packet,T_mon, . 200 . | [class] | [class] . 201 . +----------+-----------+ +----------+-----------+ . 202 . | Classification +--+ | Classification +--+ . 203 . +----------+-----------+ d| +----------+-----------+ d| . 204 . ^ i| ^ i| . 205 . |packet,T_ref s| |packet,T_mon s| . 206 . +----------+-----------+ c| +----------+-----------+ c| . 207 . | Timestamping | a| | Timestamping | a| . 208 . +----------+-----------+ r| +----------+-----------+ r| . 209 . ^ d| ^ d| . 210 . |packet v |packet v . 211 . +----------+-----------+ +----------+-----------+ . 212 . | Packet Capturing | | Packet Capturing | . 213 . +----------+-----------+ +----------+-----------+ . 214 . ^ ^ . 215 .............|................................|................. 216 |reference point |monitor point 217 | | 218 | Network under Observation | 219 ===========*================================*===============>> 220 ts1 == timestamp at reference point 221 ts2 == timestamp at monitor point 222 id == generated packet id (e.g. CRC) 223 class == packet class can be assigned by a classification 224 process 226 [Figure 3-2: OWD Measurement Processes] 228 The processes involved are packet capturing, timestamping, 229 filtering and classification, generation of a packet ID and 230 transfer of measurement data. The requirements for these 231 processes are examined in detail in the following subsections. 233 Further issues that must be dealt with are the optimal selection 234 of the observation points, privacy issues when capturing public 235 traffic, difficulties in packet event correlation when packets 236 are lost or duplicated, and the overall amount of measurement 237 data captured and transmitted for evaluation. 239 A problem that has to be solved when using multiple measurement 240 points is clock synchronization between these points. Current 241 solutions are based on the Network Time Protocol (NTP) 242 [RFC1305], the Global Positioning System (GPS), and radio 243 signals (e.g. DCF77). Each solution has its own drawbacks and 244 advantages. [RFC2679] explains time keeping related terms like 245 �synchronization�, �accuracy�, �resolution� and �skew� - 246 furthermore, it examines errors and uncertainties caused by 247 imperfect synchronization and clocks. 249 4. Observation Point Selection 251 The placement of measurement processes is crucial in the sense 252 that the observation point determines the endpoints for the 253 measurement of the delay. When we aim to measure the delay 254 between a source and destination host the locations for the 255 observation points have to be as close as possible to source and 256 destination, respectively. Although strictly speaking we never 257 are able to measure a true end-to-end delay, practically we will 258 have a very good estimation if we obeyed an appropriate 259 observation point selection. 261 There is a second point that has a direct impact on observation 262 point determination. We need a priori knowledge of the physical 263 path that packets or flows, that we intend to examine, will 264 follow. Then one has to select measurement processes, which are 265 located at observation points along this path. 267 5. Packet Capturing 269 A certain amount of bytes needs to be captured per packet as 270 basis for the generation of a packet ID. The packet ID collision 271 probability depends on the generation function and the number of 272 bytes that are used as input. In [DuGr00] it is stated that for 273 IPv4 the first 40 Bytes starting at the IP header are 274 sufficient. 276 6. Timestamping 278 A timestamp can be represented as absolute time. With this, the 279 number of bits needed for the representation of the timestamp 280 depends only on the desired accuracy for the measured metric. A 281 possibility to reduce the number of bits l_t used for the 282 timestamp is to use relative timestamps. One approach is to make 283 an assumption on the maximum time t_max a packet needs to 284 traverse the network from the ingress to the egress measurement 285 point. With this upper limit, the timestamp needs to be non- 286 ambiguous only within this limit. In this case the value l_t 287 depends not only on the desired accuracy of the time 288 representation but also on the predetermined limit for the 289 maximum time the packet needs to traverse the network. Another 290 possibility is to use an absolute timestamp only for the first 291 packet in a given time interval [0,t_int] and use timestamps 292 relative to this for successive packets that arrive in the same 293 interval. 294 Further issues are that the time that is needed for the time- 295 stamping process can differ for subsequent packets, which can 296 also lead to inaccuracy [ClDG00]. 298 7. Filtering/Classification 300 A filtering or classification of packets is required if only 301 selected packets are used for the measurement. A filter is 302 useful to reduce the amount of resulting measurement data and 303 the required processing time for the subsequent processes (like 304 packet ID generation). The classification can filter out packets 305 with specific characteristics as to choose packets from the 306 population of interest. These can be for example all packets 307 that belong to a specific flow or traffic aggregate 308 (characterized by a common DiffServ Codepoint) in order to 309 determine the quality for specific applications or traffic 310 classes. 311 In certain cases it is important to maintain the information to 312 which flow or class the measured packet belongs to. For instance 313 if the quality for different DiffServ traffic aggregates is 314 measured simultaneously it is desired to keep the information 315 about the class together with packet ID and timestamp. 317 In some cases, the packet ID already contains additional 318 information because it has been calculated with a bijective 319 function on the fields of information (e.g. a lossless 320 compression function that compresses the IP header can be 321 decompressed to determine the information on source and 322 destination). In all other cases, the wanted information has to 323 be transferred to the analysis application in addition to the 324 packet ID. 326 8. Packet ID Generation 328 Passive measurements are based on methods where packets are 329 neither marked nor modified. Consequently the recognition has to 330 be based on fields that already exist in the packet. In order to 331 get the same packet ID for one packet at both measurement points 332 the packet ID generation should be based only on fields that are 333 invariant or predictable during the transport. Fields that are 334 highly variable between the packets (e.g. the datagram ID for 335 IPv4) are more suitable than fields that are nearly constant or 336 vary only between a few values (e.g. version field). The 337 generation of a packet ID should be based on fields that 339 - already exist in the packet (no modification of the 340 packet), 341 - are invariant or predictable during the transport (at least 342 on the path from the ingress to the egress second 343 measurement point) and 344 - are highly variable between the different packets. 346 This topic is covered in [RFC2402], in [GrDM98], [DuGr00] and 347 [ZsZC01]. 349 The request for low collisions (uniqueness of the ID) 350 contradicts the request for a small packet ID; because the more 351 bits are used for representing the packet ID the lower is the 352 probability of collisions. The collision probability within a 353 traffic trace depends on 354 - the distribution of the bit sequences taken as input to the 355 packet ID generation (that means it is highly dependent on 356 the considered traffic mix), 357 - the packet ID generation function, 358 - the size of the packet ID l_id, 359 - the used Operating System (OS) (if the datagram ID is 360 considered) 362 The goal is to achieve an acceptable low probability of 363 collisions with a packet ID that does not exceed the available 364 capacity for the measurement result data transfer. As for the 365 timestamp, the packet ID only needs to be unique in the given 366 time interval [0, t_max]. This limits the number of possible 367 combinations to the number of packets n_max that can be observed 368 within this interval. For example for a 155 Mbits/s link with an 369 average packet size of 512 Bytes and a maximum time to traverse 370 the network of 10s, n_max would be 378,420 packets. This amount 371 of combinations can be represented by 19 bits. 373 IPv4 and IPv6 packets have different packet headers. That 374 implies that the fields of the IP packets, which can be used for 375 packet ID generation differ between IPv4 and IPv6 packets. 377 IPv4: ip-len, ip-ID, ip-prot, srcaddr, dstaddr, X bytes payload 378 IPv6: payload-len, ip-prot, srcaddr, dstaddr, Y bytes payload 380 There are different possibilities to generate an ID from the 381 considered fields: 382 - unprocessed plain 383 - one-way hash function (e.g. MD5) 384 - checksum CRC 385 - compression function 386 Functions that map a large bit sequence (the selected fields of 387 the packet) to a smaller bit sequence (the packet ID) can always 388 increase the collision probability. Using the selected fields of 389 the packet without further processing means to use the 390 calculation basis itself instead of a derived ID. This would 391 lead to the minimum collision probability that ever can be 392 achieved with the given traffic mix. Furthermore it would reduce 393 the required processing power because no function has to be 394 performed on the selected fields. Nevertheless this method would 395 result in a packet ID size m that is equal to the sum of bits in 396 the selected fields. Especially for small packets this would 397 increase the rate required for the measurement report messages 398 up to the rate for the data flow itself. 400 9. OWD Calculation Process 402 To estimate the one-way delay of an IP packet between two 403 observation points Ref (reference) and Mon (monitor) the 404 difference of the arrival times of the packet at the two 405 observation points is calculated: 407 T_owd = T_ref � T_mon 409 The correlation between the two timestamps to the same IP packet 410 is done via the packet ID in conjunction with a time window 411 T_delta. If a packet represented by its specific ID is captured 412 at the reference point but its ID is not detected at the monitor 413 point within T_delta the packet is considered as lost. 415 Note, that the difference in time, i.e. One-way delay, for a 416 specific packet between two monitor points is semantically 417 equivalent to the singleton metric defined in [RFC2679]. 419 The IPPM Framework [RFC2330] refers to packet properties (packet 420 type) as �type-P�. A �type-P� might subsume properties such as 421 protocol (UDP/TCP), size, TOS/DSCP, and so on. For passive One- 422 way delay measurements, types of packets that are considered 423 within the metric depend on the applied filter. Therefore, a 424 description of set filters should be provided as part of any 425 result. 427 10. Measurement Result Transfer 429 In order to calculate QoS parameters like delay, two timestamps 430 have to be compared. Measurement results (timestamps and packet 431 ID) from different observation points have to be collected at a 432 common location in order to calculate the delay value. This 433 collection point can be located on a separate host. It also can 434 be co-located with one of the measurement processes in order to 435 reduce the amount of data that has to be transferred over the 436 network. The following possibilities to transfer the measurement 437 results have to be distinguished: 439 a) In-band: The measurement results are sent directly on the 440 same path as the data. 441 b) Out-of-band: The measurement results are sent on a separate 442 path. 444 Solution a) leads to additional load on the network under test. 445 That means measurement result data packets can influence and 446 distort the original data flow and we might end up with 447 disadvantages that are inherent in active measurements. The in- 448 band sending of packets with measurement results therefore 449 somehow contradicts the passive approach where no influence on 450 the original traffic is desired. Nevertheless, there is a 451 difference between sending test traffic for active measurements 452 and the transmission of measurement results. The amount, type 453 and timeframe for the sending of test traffic for active 454 measurements are dictated by the measurement task. In contrast 455 to this, the sending of measurement results can be controlled by 456 other means. For instance, it could be sent with a lower 457 priority (e.g. lower-than-best-effort class) or only at times 458 when the network is lightly loaded, or routed over paths that 459 are currently not loaded (e.g. via MPLS). Which alternative is 460 to be preferred depends on the policy for the evaluation of the 461 metric (e.g. real-time or non-real-time). 463 Solution b) requires a separate path to the analysis application 464 or collection point. This can be achieved for instance via a 465 second interface card and a separate measurement network that 466 connects all measurement points. This approach does not 467 influence the data traffic but requires capacity in a different 468 network. 469 In all cases, additional transfer capacity (either within the 470 examined or a separate network) is required. For economic 471 reasons even a separate reporting network would probably have a 472 lower capacity then the �production network�. As a result, to 473 save resources (storage capacity and bandwidth) the measurement 474 result traffic should be kept as low as possible. 476 11. Security Considerations 478 11.1 Measurement Infrastructure 480 We have to distinguish between two different interfaces of a 481 measurement device: there is one interface to control the 482 devices and to exchange measurement data; a second interface is 483 used to capture the traffic. 485 The access to the measurement infrastructure and the measurement 486 devices in particular must be secured in a manner indicated by 487 best known praxis in order to prevent unintended malicious use 488 of the measurement infrastructure. 490 Malicious injection of packets into the network under test 491 through the capture interface can be prevented by properly 492 utilizing network taps or optical splitters or by proper design 493 of the physical interface. 495 11.2 Exchange of Measurement Data 497 The exchange of measurement data is vulnerable and appropriate 498 actions have to be taken to hinder injection of faked 499 measurement data. (However, the design of a data exchange 500 protocol is out of the scope of this document. Please refer to 501 IPFIX related documents for further details.) 503 11.3 Sensitivity 505 When only packet identifier and timestamps are stored then the 506 measurement data itself do not contain sensitive content as long 507 as the packet identifier generation process is irreversible, so 508 that for instance IP addresses cannot be retrieved. 510 12. References 512 [ClDG00] John Cleary, et al.: Design Principles for Accurate 513 passive Measurement, The First Passive and Active 514 Measurement Workshop PAM 2000, Hamilton, New 515 Zealand, April 3-4, 2000 517 [DuGG03] Nick Duffield, et al.: A Framework for Passive 518 Packet Measurement, Internet Draft , March 2003 521 [DuGr00] Nick Duffield, Matthias Grossglauser: �Trajectory 522 Sampling for Direct Traffic Observation�, 523 Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, 524 August 28 - September 1, 2000 526 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, 527 Jed MARTENS, John G. CLEARY: Nonintrusive and 528 Accurate Measurement of Unidirectional Delay and 529 Delay Variation on the Internet, INET'98, Geneva, 530 Switzerland, July 21-24, 1998 532 [QuZC03] J. Quittek, et al.: Requirements for IP Flow 533 Information Export, Internet Draft , June 2003 536 [TPBC03] T. Tseby, R. Penno, N. Brownly, B. Claise: 537 IPFIX Applicability, Internet Draft , June 2003 540 [ZsZC01] T. Zseby, S. Zander, G. Carle: Evalutation of 541 building blocks for passive one-way delay 542 measurements, PAM2001, Amsterdam, April 23-24, 2001 544 [RFC2330] Paxon, V., Almes, G., Mahdavi, J.,Mathis, M., 545 �Framework for IP Performance Metrics�, RFC 2330, 546 May 1998 548 [RFC2402] Kent, S., Atkinson, R., �IP Authentication Header�, 549 RFC 2402, Nov 1998 551 [RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, �A One- 552 way Delay Metric for IPPM�, RFC 2679, September 553 1999 554 13. Author's Addresses 556 Lutz Mark 557 Fraunhofer Institute for Open Communication Systems 558 Kaiserin-Augusta-Allee 31 559 10589 Berlin 560 Germany 561 Phone: +49-30-34 63 7306 562 Fax: +49-30-34 53 8306 563 Email: mark@fokus.fraunhofer.de 565 Guido Pohl 566 Fraunhofer Institute for Open Communication Systems 567 Kaiserin-Augusta-Allee 31 568 10589 Berlin 569 Germany 570 Phone: +49-30-34 63 7164 571 Fax: +49-30-34 53 8164 572 Email: pohl@fokus.fraunhofer.de 574 Tanja Zseby 575 Fraunhofer Institute for Open Communication Systems 576 Kaiserin-Augusta-Allee 31 577 10589 Berlin 578 Germany 579 Phone: +49-30-34 63 7153 580 Fax: +49-30-34 53 8153 581 Email: zseby@fokus.fraunhofer.de 583 Kiminori Sugauchi 584 Hitachi, ltd., System Development Laboratory 585 1099, Ohzenji, Asao-ku, Kawasaki-shi, Kanagawa-ken, 586 215-0013 Japan 587 Phone: +81-44-959-0266 588 Fax: +81-44-959-0860 589 E-mail: sugauchi@sdl.hitachi.co.jp 591 14. Full Copyright Statement 593 Copyright (C) The Internet Society (2002). All Rights Reserved. 594 This document and translations of it may be copied and furnished 595 to others, and derivative works that comment on or otherwise 596 explain it or assist in its implementation may be prepared, 597 copied, published and distributed, in whole or in part, without 598 restriction of any kind, provided that the above copyright 599 notice and this paragraph are included on all such copies and 600 derivative works. However, this document itself may not be 601 modified in any way, such as by removing the copyright notice or 602 references to the Internet Society or other Internet 603 organizations, except as needed for the purpose of developing 604 Internet standards in which case the procedures for copyrights 605 defined in the Internet Standards process must be followed, or 606 as required to translate it into languages other than 607 English. 609 The limited permissions granted above are perpetual and will not 610 be revoked by the Internet Society or its successors or assigns. 612 This document and the information contained herein is provided 613 on an 614 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 615 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 616 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 617 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 618 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 619 PARTICULAR PURPOSE.