Internet Draft P. A. Aranda Gutierre Telefonica I+D Expires: May 2001 J. Carapinha Portugal Telecom Inovacao P. Castelli CSELT H. J. Einsiedler Deutsche Telekom T-Nova A. J. Elizondo Telefonica I+D R.Geib Deutsche Telekom T-Nova M. Krampell EURESCOM GmbH P. J. McGee Deutsche Telekom T-Nova J. Quittek NEC Europe Ltd. I. Svinnset Telenor AS B. Varga MATAV Rod Webb Corning 10 November 2000 Protocol Implementation Conformance Statement for the Assured Forwarding Per-Hop Behavior Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 1] Internet Draft PICS for the AF PHB 10 November 2000 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is an output of the EURESCOM project P1006: "Differentiated Services - Network Configuration and Management" (http://www.eurescom.de/Public/Projects/P1000-series/P1006/P1006.htm) Abstract This document provides the Protocol Implementation Conformance Statement (PICS) form for the Assured Forwarding (AF) Per Hop Behaviour (PHB) as defined in RFC 2597. Additional requirements posed by RFC 2475, RFC 2697 and RFC 2698 are taken into account where applicable. The purpose of this PICS is to provide a mechanism whereby a supplier of an implementation of the requirements defined in the RFCs indicated above may provide information about the implementation in a unified manner. Table of content 1. Introduction 2. Implementation Conformance Statements 2.1. Traffic Classification and Conditioning 2.1.1. Classification 2.1.2. AF PHB Group 2.1.3. Conditioning 2.2. Marking and Re-marking 2.3. Queuing and Discard Behaviour 2.4. Tunnelling 3. Security Considerations 4. References 5. Authors Addresses 1. Introduction To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and options have been implemented for a given specification. Such a statement is called Implementation Conformance Statement (ICS). An ICS for an implementation or system claimed to conform to a given protocol specification is called Protocol ICS (PICS). This document provides the PICS form for the AF PHB. It describes the requirements that SHALL be satisfied by any conformant implementation of the AF PHB. The requirements listed in this document are defined by RFC 2597 [RFC2597]; additional requirements defined by RFC 2475 [RFC2475], RFC 2697 [RFC2697] and RFC 2698 [RFC2698] are also taken into account where applicable. Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 2] Internet Draft PICS for the AF PHB 10 November 2000 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. A version of this form in the Portable Document Format (PDF) is available at http://www.eurescom.de/public/projectresults/p1000-series/1006ts1.htm 2.0 Implementation Conformance Statements The PICS form contained in this document is comprised of information in a tabular form. The meaning of the different columns is the following: - Description column: it provides a short text description of the item (requirement) to be evaluated. It implicitly means "is the supported by the implementation?" - Reference column: it gives reference to the Section of RFC 2597, RFC 2475, RFC2697 or RFC 2698 in which the item is defined. - Status column: it provides the quality of the item according to the referenced RFCs. The status of the item may assume one out of the following values: - Mandatory (RFC says MUST): the capability is REQUIRED to be supported. - Optional (RFC says SHOULD or MAY): the capability SHOULD/MAY be supported or not. - Conditional: the capability is applicable only if one or more earlier optional or conditional capabilities are implemented. If applicable, a conditional item can be either mandatory or optional (see notes on conditional items below). - Yes/No column: this column SHALL be filled with "yes" if the capability is supported by the implementation, it SHALL be filled with "no" if the capability is not supported by the implementation. Notes on Conditional items: (1): If (14=Yes) or (15=Yes) or (16=Yes) or (17=Yes) or (18=Yes) then Optional else N/A (2): If (31=Yes) then Mandatory else N/A (3): If (40=Yes) then Optional else N/A (4): If (40=Yes) then Mandatory else N/A (5): If (46=Yes) then Optional else N/A (6): If (46=Yes) then Mandatory else N/A Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 3] Internet Draft PICS for the AF PHB 10 November 2000 Information about the implementation provider: +-----------------------+-------------------------------------------+ | Form filled in by | | | (Company/Institution) | | +-----------------------+-------------------------------------------+ | Responsible person | | | (First name, surname) | | +-----------------------+-------------------------------------------+ | Company address | | | (Name, street, | | | town, country) | | | | | +-----------------------+-------------------------------------------+ | Phone | | +-----------------------+-------------------------------------------+ | Fax | | +-----------------------+-------------------------------------------+ | E-mail | | +-----------------------+--------------------------+----------------+ | The information can be made public | | | (including other manufactures/vendors): (yes/no) | | +--------------------------------------------------+----------------+ 2.1 Traffic Classification and Conditioning 2.1.1 Classification +-----------------------------------+------------+---------+--------+ | Description | Reference | Status | Yes/No | +-----------------------------------+------------+---------+--------+ | Behavior Aggregate | +-----------------------------------+------------+---------+--------+ | 1. Does your system classify | RFC 2475 | Option. | | | incoming IP traffic according | Sec 2.3.1, | | | | to the DS Codepoints: | RFC 2597 | | | | | Sec 2. and | | | | | Sec 6. | | | +--------------------------+--------+------------+---------+--------+ | 2. Class 1, Low | 001010 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | 3. Class 1, Medium | 001100 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | 4. Class 1, High | 001110 | | Option. | | | Dropping Precedence | | | | | Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 4] Internet Draft PICS for the AF PHB 10 November 2000 +--------------------------+--------+------------+---------+--------+ | 5. Class 2, Low | 010010 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | 6. Class 2, Medium | 010100 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | 7. Class 2, High | 010110 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | 8. Class 3, Low | 011010 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | 9. Class 3, Medium | 011100 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | 10. Class 3, High | 011110 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | 11. Class 4, Low | 100010 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | 12. Class 4, Medium | 100100 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | 13. Class 4, High | 100110 | | Option. | | | Dropping Precedence | | | | | +--------------------------+--------+------------+---------+--------+ | Multiple Field | +-----------------------------------+------------+---------+--------+ | 14. Does your system classify | RFC 2475 | Option. | | | incoming IP traffic according | Sec 2.3.1. | | | | to the destination address? | | | | +-----------------------------------+------------+---------+--------+ | 15. Does your system classify | RFC 2475 | Option. | | | incoming IP traffic according | Sec 2.3.1. | | | | to the source address? | | | | +-----------------------------------+------------+---------+--------+ | 16. Does your system classify | RFC 2475 | Option. | | | incoming IP traffic according | Sec 2.3.1. | | | | to the protocol ID? | | | | +-----------------------------------+------------+---------+--------+ | 17. Does your system classify | RFC 2475 | Option. | | | incoming IP traffic according | Sec 2.3.1. | | | | to the source port? | | | | Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 5] Internet Draft PICS for the AF PHB 10 November 2000 +-----------------------------------+------------+---------+--------+ | 18. Does your system classify | RFC 2475 | Option. | | | incoming IP traffic according | Sec 2.3.1. | | | | to the destination port? | | | | +-----------------------------------+------------+---------+--------+ | 19. If any features of 14.-18. | RFC 2475 | Cond(1) | | | are implemented, does your | Sec 2.3.1. | | | | system classify incoming IP | | | | | traffic according to a | | | | | combination of more than one | | | | | of the implemented features? | | | | +-----------------------------------+------------+---------+--------+ Product Specification +-----------+-----------------+-------------+-----------------------+ | | Product(Type) | Release | Technology (e.g. RED, | | | | | WFQ, IPCHAIN, QDISC) | +-----------+-----------------+-------------+-----------------------+ | Behavior | | | | | Aggregate | | | | +-----------+-----------------+-------------+-----------------------+ | Multiple | | | | | Field | | | | +-----------+-----------------+-------------+-----------------------+ +-------------------------------------------------------------------+ | Comments: | | | | | | | +-------------------------------------------------------------------+ 2.1.2 AF PHB Group +-----------------------------------+------------+---------+--------+ | Description | Reference | Status | Yes/No | +-----------------------------------+------------+---------+--------+ | 20. Does your system implement | RFC 2597 | Option. | | | all four general use AF | Sec 2. | | | | classes? | | | | +-----------------------------------+------------+---------+--------+ | 21. Does your system forward | RFC 2597 | Mandat. | | | packets from any one AF class | Sec 2. | | | | independent of the packets of | | | | | any other AF class? | | | | Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 6] Internet Draft PICS for the AF PHB 10 November 2000 +-----------------------------------+------------+---------+--------+ | 22. Does your system allocate | RFC 2597 | Mandat. | | | a minimum amount of buffer | Sec 2. | | | | space to each implemented AF | | | | | class? | | | | +-----------------------------------+------------+---------+--------+ | 23. Does your system allocate | RFC 2597 | Mandat. | | | a minimum amount of bandwidth | Sec 2. | | | | to each implemented AF class? | | | | +-----------------------------------+------------+---------+--------+ | 24. Is the amount of buffer space | RFC 2597 | Mandat. | | | for each implemented AF class | Sec 2. | | | | configurable by your system? | | | | +-----------------------------------+------------+---------+--------+ | 25. Is the amount of bandwidth | RFC 2597 | Mandat. | | | for each implemented AF class | Sec 2. | | | | configurable by your system? | | | | +-----------------------------------+------------+---------+--------+ | 26. Does your system achieve the | RFC 2597 | Option. | | | configured rate over small | Sec 2. | | | | time scales for each AF | | | | | service class? | | | | +-----------------------------------+------------+---------+--------+ | 27. Does your system achieve the | RFC 2597 | Option. | | | configured rate over large | Sec 2. | | | | time scales for each AF | | | | | service class? | | | | +-----------------------------------+------------+---------+--------+ | 28. Does your system allow excess | RFC 2597 | Option. | | | resources to be assigned to | Sec 2. | | | | AF classes? | | | | +-----------------------------------+------------+---------+--------+ | 29. Does your system not forward | RFC 2597 | Mandat. | | | an IP packet with smaller | Sec 2. | | | | probability if it contains a | | | | | drop precedence value p than | | | | | if it contains a drop pre- | | | | | cedence value q when p < q? | | | | +-----------------------------------+------------+---------+--------+ | 30. Does your system accept all | RFC 2597 | Mandat. | | | three drop precedence DSCP's | Sec 2. | | | | within any AF class? | | | | +-----------------------------------+------------+---------+--------+ | 31. Does your system yield at | RFC 2597 | Mandat. | | | least two drop precedence | Sec 2. | | | | levels per AF class? | | | | Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 7] Internet Draft PICS for the AF PHB 10 November 2000 +-----------------------------------+------------+---------+--------+ | 32. Does your system support | RFC 2597 | Option. | | | three different drop pre- | Sec 2. | | | | cedence levels per AF class? | | | | +-----------------------------------+------------+---------+--------+ | 33. If your system yields only | RFC 2597 | Cond(2) | | | two drop precedence levels | Sec 2. | | | | per AF class, does the DSCP | | | | | AFx1 yield lower loss | | | | | probability than DSCP AFx2 | | | | | and AFx3? | | | | +-----------------------------------+------------+---------+--------+ | 34. Does your system not re-order | RFC 2597 | Mandat. | | | AF packets belonging to the | Sec 2. | | | | same micro-flow regardless of | | | | | their drop precedence? | | | | +-----------------------------------+------------+---------+--------+ Product Specification +-----------+-----------------+-------------+-----------------------+ | | Product(Type) | Release | Technology (e.g. RED, | | | | | WFQ, IPCHAIN, QDISC) | +-----------+-----------------+-------------+-----------------------+ | AF PHB | | | | | Group | | | | +-----------+-----------------+-------------+-----------------------+ +-------------------------------------------------------------------+ | Comments: | | | | | | | +-------------------------------------------------------------------+ 2.1.3 Conditioning +-----------------------------------+------------+---------+--------+ | Description | Reference | Status | Yes/No | +-----------------------------------+------------+---------+--------+ | 35. Does your system implement | RFC 2597 | Option. | | | traffic shaping at the edge | Sec 3. | | | | of a domain to control the | | | | | amount of AF traffic entering | | | | | or exiting it? | | | | Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 8] Internet Draft PICS for the AF PHB 10 November 2000 +-----------------------------------+------------+---------+--------+ | 36. Does your system implement | RFC 2597 | Option. | | | packet discarding at the edge | Sec 3. | | | | of a domain to control the | | | | | amount of AF traffic entering | | | | | or exiting it? | | | | +-----------------------------------+------------+---------+--------+ | 37. Does your system change the | RFC 2597 | Option. | | | drop precedence of packets at | Sec 3. | | | | the edge of a domain to con- | | | | | trol the amount of AF traffic | | | | | entering or exiting it? | | | | +-----------------------------------+------------+---------+--------+ | 38. Does your system change the | RFC 2597 | Option. | | | AF class of packets at the | Sec 3. | | | | edge of a domain to control | | | | | the amount of AF traffic | | | | | entering or exiting it? | | | | +-----------------------------------+------------+---------+--------+ | 39. Do the conditioning actions | RFC 2597 | Mandat. | | | of your system not cause | Sec 3. | | | | re-ordering of packets of the | | | | | same micro-flow? | | | | +-----------------------------------+------------+---------+--------+ Product Specification +-----------+-----------------+-------------+-----------------------+ | | Product(Type) | Release | Technology (e.g. RED, | | | | | WFQ, IPCHAIN, QDISC) | +-----------+-----------------+-------------+-----------------------+ | Condi- | | | | | tioning | | | | +-----------+-----------------+-------------+-----------------------+ +-------------------------------------------------------------------+ | Comments: | | | | | | | +-------------------------------------------------------------------+ Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 9] Internet Draft PICS for the AF PHB 10 November 2000 2.2 Marking and Re-marking +-----------------------------------+------------+---------+--------+ | Description | Reference | Status | Yes/No | +-----------------------------------+------------+---------+--------+ | 40. Does your system support a | RFC 2697 | Option. | | | "Single Rate Three Colour | | | | | Marker (srTCM)"? | | | | +-----------------------------------+------------+---------+--------+ | 41. If your system supports | RFC 2697 | Cond(3) | | | srTCM, does it have | Sec 3. | | | | implemented the | | | | | Colour-Blind mode? | | | | +-----------------------------------+------------+---------+--------+ | 42. If your system supports | RFC 2697 | Cond(3) | | | srTCM, does it have | Sec 3. | | | | implemented the | | | | | Colour-Aware mode? | | | | +-----------------------------------+------------+---------+--------+ | 43. If your system supports | RFC 2697 | Cond(4) | | | srTCM, is the Committed | Sec 2. | | | | Information Rate (CIR) | | | | | measured in bytes of IP | | | | | packets per second (without | | | | | link and physical layer | | | | | information)? | | | | +-----------------------------------+------------+---------+--------+ | 44. If your system supports | RFC 2697 | Cond(4) | | | srTCM, is the Committed Burst | Sec 2. | | | | Size (CBS) measured in bytes? | | | | +-----------------------------------+------------+---------+--------+ | 45. If your system supports | RFC 2697 | Cond(4) | | | srTCM, is the Excess Burst | Sec 2. | | | | Size (EBS) measured in bytes? | | | | +-----------------------------------+------------+---------+--------+ | 46. Does your system support a | RFC 2698 | Option. | | | "Two Rate Three Colour Marker | | | | | Marker (trTCM)"? | | | | +-----------------------------------+------------+---------+--------+ | 47. If your system supports | RFC 2698 | Cond(5) | | | trTCM, does it have | Sec 3. | | | | implemented the | | | | | Colour-Blind mode? | | | | Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 10] Internet Draft PICS for the AF PHB 10 November 2000 +-----------------------------------+------------+---------+--------+ | 48. If your system supports | RFC 2698 | Cond(5) | | | trTCM, does it have | Sec 3. | | | | implemented the | | | | | Colour-Aware mode? | | | | +-----------------------------------+------------+---------+--------+ | 49. If your system supports | RFC 2698 | Cond(6) | | | trTCM, is the Peak | Sec 2. | | | | Information Rate (PIR) | | | | | measured in bytes of IP | | | | | packets per second (without | | | | | link and physical layer | | | | | information)? | | | | +-----------------------------------+------------+---------+--------+ | 50. If your system supports | RFC 2698 | Cond(6) | | | trTCM, is the Committed | Sec 2. | | | | Information Rate (CIR) | | | | | measured in bytes of IP | | | | | packets per second (without | | | | | link and physical layer | | | | | information)? | | | | +-----------------------------------+------------+---------+--------+ | 51. If your system supports | RFC 2698 | Cond(6) | | | trTCM, is the Peak Burst Size | Sec 2. | | | | (PBS) measured in bytes? | | | | +-----------------------------------+------------+---------+--------+ | 52. If your system supports | RFC 2698 | Cond(6) | | | trTCM, is the Committed Burst | Sec 2. | | | | Size (CBS) measured in bytes? | | | | +-----------------------------------+------------+---------+--------+ Product Specification +-----------+-----------------+-------------+-----------------------+ | | Product(Type) | Release | Technology (e.g. RED, | | | | | WFQ, IPCHAIN, QDISC) | +-----------+-----------------+-------------+-----------------------+ | Marking | | | | | and Re- | | | | | marking | | | | +-----------+-----------------+-------------+-----------------------+ +-------------------------------------------------------------------+ | Comments: | | | | | | | +-------------------------------------------------------------------+ Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 11] Internet Draft PICS for the AF PHB 10 November 2000 2.3 Queuing and Discard Behavior +-----------------------------------+------------+---------+--------+ | Description | Reference | Status | Yes/No | +-----------------------------------+------------+---------+--------+ | 53. Does your system minimise | RFC 2597 | Mandat. | | | long-term congestion within | Sec 4. | | | | each AF class? | | | | +-----------------------------------+------------+---------+--------+ | 54. Does your system allow | RFC 2597 | Mandat. | | | short-term congestion | Sec 4. | | | | resulting from bursts within | | | | | each AF class? | | | | +-----------------------------------+------------+---------+--------+ | 55. Does your system drop packets | RFC 2597 | Mandat. | | | as a result of long term | Sec 4. | | | | congestion within an AF | | | | | class? | | | | +-----------------------------------+------------+---------+--------+ | 56. Does your system queue | RFC 2597 | Mandat. | | | packets as a result of short | Sec 4. | | | | term congestion within an AF | | | | | class? | | | | +-----------------------------------+------------+---------+--------+ | 57. Does your system's dropping | RFC 2597 | Mandat. | | | algorithm result in an equal | Sec 4. | | | | packet discard probability | | | | | for flows with different | | | | | short-term burst shapes but | | | | | identical longer-term packet | | | | | rates, if both flows are | | | | | within the same AF class? | | | | +-----------------------------------+------------+---------+--------+ | 58. Does your system's dropping | RFC 2597 | Mandat. | | | algorithm result in a discard | Sec 4. | | | | rate of a particular | | | | | micro-flow's packets within | | | | | a single precedence level | | | | | which is proportional to that | | | | | flow's percentage of the | | | | | total amount of traffic | | | | | passing through that | | | | | precedence level at any | | | | | smoothed congestion level? | | | | Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 12] Internet Draft PICS for the AF PHB 10 November 2000 +-----------------------------------+------------+---------+--------+ | 59. Does your system's dropping | RFC 2597 | Mandat. | | | algorithm respond gradually | Sec 4. | | | | to congestion? | | | | +-----------------------------------+------------+---------+--------+ | 60. Are the dropping algorithm | RFC 2597 | Mandat. | | | control parameters of your | Sec 4. | | | | system independently | | | | | configurable for each packet | | | | | drop precedence and for each | | | | | AF class? | | | | +-----------------------------------+------------+---------+--------+ Product Specification +-------------+---------------+-------------+-----------------------+ | | Product(Type) | Release | Technology (e.g. RED, | | | | | WFQ, IPCHAIN, QDISC) | +-------------+---------------+-------------+-----------------------+ | Queuing | | | | | and Discard | | | | | Behavior | | | | +-------------+---------------+-------------+-----------------------+ +-------------------------------------------------------------------+ | Comments: | | | | | | | +-------------------------------------------------------------------+ 2.4 Tunneling +-----------------------------------+------------+---------+--------+ | Description | Reference | Status | Yes/No | +-----------------------------------+------------+---------+--------+ | 61. Does your system not reduce | RFC 2597 | Mandat. | | | the forwarding assurance of | Sec 5. | | | | tunneled AF packets? | | | | +-----------------------------------+------------+---------+--------+ | 62. Does your system not re-order | RFC 2597 | Mandat. | | | packets within a tunneled AF | Sec 5. | | | | micro-flow? | | | | +-----------------------------------+------------+---------+--------+ Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 13] Internet Draft PICS for the AF PHB 10 November 2000 Product Specification +-------------+---------------+-------------+-----------------------+ | | Product(Type) | Release | Technology (e.g. RED, | | | | | WFQ, IPCHAIN, QDISC) | +-------------+---------------+-------------+-----------------------+ | Tunneling | | | | | | | | | +-------------+---------------+-------------+-----------------------+ +-------------------------------------------------------------------+ | Comments: | | | | | | | +-------------------------------------------------------------------+ 3. Security Considerations This PICS form does not raise new network security issues because it is just a form for specifying implementation conformance of network equipment. Merely, a filled form might have to be treated as a confidential document. 4. References [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2597] J.Heinanen, F.Baker, W.Weiss, and J.Wroclawski, "An Assured Forwarding PHB", RFC 2597, June 1999. [RFC2697] J. Heinanen and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999. [RFC2698] J. Heinanen and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, September 1999. Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 14] Internet Draft PICS for the AF PHB 10 November 2000 5. Authors' Addresses Pedro A. Aranda Gutierre Telefonica, Investigacion y Desarrollo Emilio Vargas 6 28043 Madrid Spain Phone: +34 91 337 4702 Email: paag@tid.es Jorge Carapinha Portugal Telecom Inovacao Rua Eng. Jose Ferreira Pinto Basto 3810 Aveiro Portugal Phone: +35 1 234 403 486 Email: jorgec@ptinovacao.pt Paolo Castelli CSELT Via G. Reiss Romoli 274 10148 Torino Italy Phone: +39 011 228 8855 Email: paolo.castelli@cselt.it Hans Joachim Einsiedler T-Nova Deutsche Telekom Innovationsgesellschaft GmbH Goslarer Ufer 35 10589 Berlin Germany Phone: +49 30 3497-3518 Email: hans.einsiedler@telekom.de Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 15] Internet Draft PICS for the AF PHB 10 November 2000 Antonio Jose Elizondo Telefonica, Investigacion y Desarrollo Emilio Vargas 6 28043 Madrid Spain Phone: +34 91 337 4782 Email: ajea@tid.es Ruediger Geib T-Nova Deutsche Telekom Innovationsgesellschaft GmbH Am Kavalleriesand 3 64285 Darmstadt Germany Phone: +49 6151 832138 Email: Ruediger.Geib@telekom.de Magnus Krampell EURESCOM GmbH Schloss-Wolfsbrunnenweg 35 69118 Heidelberg Germany Phone: +49 6221 989 381 Email: krampell@eurescom.de Paul J. McGee T-Nova Deutsche Telekom Innovationsgesellschaft GmbH Goslarer Ufer 35 10589 Berlin Germany Phone: +49 30 3497-???? Email: paul-joseph.mcgee@telekom.de Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 16] Internet Draft PICS for the AF PHB 10 November 2000 Juergen Quittek NEC Europe Ltd. C&C Research Laboratories Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de Inge Svinnset Telenor AS Postboks 83 2007 Kjeller Norway Phone: +47 63 84 8742 Email: inge-einar.svinnset@telenor.com Balazs Varga MATAV Neumann Janos krt.1/G 1117 Budapest Hungary Phone: +36 1 347 2185 Email: varga.balazs@ln.matav.hu Rod Webb Corning Research Centre Adastral Park Martlesham Heath Ipswich Suffolk, IP5 3RE Great Britain Phone: +44 1473 663247 Email: webbrp@corning.com Aranda et al. draft-eurescom-p1006-af-pics-00 [Page 17]