Internet Draft J. Quittek NEC Europe Ltd. Expires: April 2001 M. Pias University College London 13 October 2000 A high-level application-oriented interface to the traffic flow measurement architecture 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo specifies a high-level application-oriented interface to the Realtime Traffic Flow Measurement (RTFM) Architecture. The abstract interface models the RTFM architecture while hiding many of the details not relevant to an application programmer who want to integrate IP traffic measurements into an application. Particularly the interaction between manager, reader, and meter is hidden by the interface, and rule sets used for traffic measurement specification are replaced by simpler data structures. Furthermore, the RTFM interface supports complex actions like modifying a traffic measurement specification while it is already being applied. The interface is defined in an abstract way. It can be implemented by an application programming interface as well as by a network protocol. Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 1] Internet Draft RTFM Interface 13 October 2000 Table of Contents 1. Introduction 2. RTFM Interface Overview 2.1. Motivation 2.1.1. Scenario 1: Accounting and Charging for QoS 2.1.2. Scenario 2: Policy-based Network Management 2.2. Requirements 2.3. Applications and the RTFM Arch Integration 2.4. Declarative Flow Model 3. Notation of the API Specification 4. API Specification 4.1. FlowDescription 4.2. FlowAttribute 4.3. Manager 4.4. Reader 4.5. Meter 5. Required Extensions 6. Security Considerations 7. Acknowledgments 8. References 9. Authors' Addresses Appendix A: C mapping of API specification Appendix B: Java mapping of API specification 1. Introduction This memo specifies an experimental application programming interface (API) to the Realtime Traffic Flow Measurement (RTFM) Architecture [RTFM-ARC]. This memo uses terminology from the RTFM architecture document [RTFM- ARC] and the description of new attributes for traffic flow measurements [RTFM-NEW] Comments should be made directly to the RTFM mailing list at rtfm@auckland.ac.nz. 2. RTFM interface overview The need for a high-level interface to the RTFM architecture arose independently in different projects relying on traffic flow measurements. For these projects it appeared to be advantageous to access components of the RTFM architecture, namely managers, meters, and readers, via an abstract interface hiding many of the components' details. In particular, several details concerning the overhead required for Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 2] Internet Draft RTFM Interface 13 October 2000 coordination of managers, meters and readers, and details concerning the specification of flows by rule sets appeared to be not relevant for the applications and have been hidden by the interface. The attempt made by this memo is to unify different interfaces to the RTFM architecture, which have been developed so far. The unified iterfaces aims to be generic in order to cover any application willing to use the RTFM architecture. The RTFM interface is defined in a way that it can be implemented as an application programming interface (API) as well as a network protocol. Appendices A and B define mappings of the RTFM interface to a C API and to a Java API, respectively. A network protocol implementing the interface is not defined by this memo. 2.1. Motivation The motivation for the RTFM interface is illustrated by two application scenarios. The first one deals with accounting and charging for QoS. The subject of the second scenario is policy-based network management. 2.1.1. Scenario 1: Accounting and Charging for QoS In the scenario illustrated by Figure 1, a service provider multicasts tariff objects to all accounting modules for his customers customers (1). Once a customer accounting module has received a tariff, it loads dynamically a module called Tariff Translator (TT) in order to perform a translation to appropriate Meter Policies (MP) (2,3). Thus, the MP is a set of ECA (Event-Condition-Action) generic policies derived from the tariff. It specifies explicitly/implicitly accounting/metering requirements. After that, the MP is transformed to Meter specific control and uploaded into a Meter (4). For the RTFM architecture, the meter control is a rule set as described in [RTFM-ARC]. Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 3] Internet Draft RTFM Interface 13 October 2000 +----------------+ | RTFM Meter | +----------------+ 5.Data ^ ^ (Pull Mode) | | 4. Control (Ruleset) v | / +------------+ 2.Tariff +-----------+ / ..... +------| Customer A |--------->| Tariff | \ / ...... | +------------+ | Translator| \/ | 6.Data / ^ +-----------+ \ / | (unicast) / | 3.Meter Policies | \/ | / +-------------------+ / v / / +--------+ / 1. Tariff Multicast / |Provider|----------------------------------------------------------- +--------+ \ \ \ \ \ /\ \ / \/ \ \ +------------+ Tariff +-----------+ . . . +--------------| Customer B |-------->| Tariff | . . . | +------------+ | Translator| | ^ ^ +-----------+ | Control | Data | | | (Meter "x" | (Push +------------------+ | specific) | Mode) Meter Policies | +----------------+ +--------->| Meter "x" | +----------------+ Figure 1: QoS Charging Scenario The Provider/Customer collect the accounting data from Meters either using one of the following modes (5): (a) Pull Mode or Proactive: a Reader polls the meter periodically in order to gather metered data, usually through a request/reply mechanism. (b) Push Mode or Reactive: a Meter pushes out data to a set of Readers/Collectors registered as listeners when a pre-defined event occurs. We have identified so far some categories of events as follows: - packet-related (e.g. set of packets arrival), - temporal (e.g. clock timeout), - protocol-related (specific TCP stream)... Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 4] Internet Draft RTFM Interface 13 October 2000 Finally, the bill is generated using the logic within the Tariff. The translation performed in steps 2,3 has derived the accounting requirements. Therefore, the collected data from the meters is one form of input to calculate the usage charge. Other inputs might be derived from the marketing and business strategies of the service provider. Each customer accounting module makes use of an API in order to cope with configuration and data collection. All the logic of those both processes are encapsulated by the implementation of two partial interfaces which composes this API. One for control and another for data. The interface defines an abstract programming model for the RTFM architecture, which hides several details not easy understandable by application programmers. An implementation of the interface establishes an abstraction layer between the application and the RTFM architecture. +------------------------------+ | Application | +------------------------------+ ^ ^ | Control | Data | (Meter | (Pull or Push mode) v Policies) v +------------------------------+ | RTFM interface | +------------------------------+ ^ ^ | Control | Data | (ruleset) | (Pull mode) v v +------------------------------+ | RTFM Architecture | +------------------------------+ Figure 2: RTFM Interface Abstraction Layer 2.1.2. Scenario 2: Policy-based Network Management Subject of the second scenario is policy-based network management. Core components of a policy-based network management system are policy decision points (PDPs) and policy enforcement points (PEPs) [RFC2753]. Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 5] Internet Draft RTFM Interface 13 October 2000 ________________ Policy server | | _____ | Network Node | | |-------------> | _____ | | | May use LDAP,SNMP,... for accessing | | | | | | policy database, authentication,etc. | | PEP |<-----|----->| PDP |-------------> | |_____| | |_____| | | | May monitor the network |________________| <-----+----------------> Figure 3: Policy Server Scenario The PEP is located at a network node and enforces policy decision made by the PDP. Decisions of the PDP are based on policy rules stored at policy databases and on the current state of the managed network. Policy decisions may be triggered by requests of a PEP, by user interaction, or by other events in the monitored network. This includes two cases where traffic measurement functionality is required: (a) A policy may depend on current traffic information, e.g. the the decision on whether a user is allowed to open a new connection may depend on the traffic volume he already produced. In this case, the policy server must be able to retrieve accounting information for that particular user. The requirement of the PDP application is similar to mode (a) in the first scenario. Loading a policy depending on transferred data volume from the policy database corresponds to the Tariff multicast. After parsing the policy, the PDP must initiate traffic measurements for all users affected the policy, in order to have measured data available when needed. Therefore it configures one or more traffic meters. When a decision has to be made, the PDP collects traffic data in pull mode. (b) The second case corresponds to case (b) in the first scenario. A policy decision of the PDP, e.g. to reconfigure resource reservations, is triggered by traffic events, e.g. if the bandwidth or volume of a particular user exceeds a given limit. In this case, the PDP receives traffic information in push mode. An active entity monitoring traffic must notify the PDP. Also for this scenario an interface establishing an abstract layer Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 6] Internet Draft RTFM Interface 13 October 2000 between the application (the PDP) and the RTFM architecture appears to be desirable. As in the first scenario, the interface hides details of traffic measurements, and offers functions for control and push/pull data transfer. 2.2. Applications and the RTFM Architecture Integration In a general view, there exist two kinds of applications using the RTFM architecture: (a) Plain (standalone) traffic measurement: this kind of applications is well supported by the architecture. The rule sets are created manually or with SRL [RFC-SRL] to be uploaded into the Meter. The metered data is collected by the Readers and stored (e.g. in a file) for further processing. (b) Applications with integrated traffic measurement: envisaged by the applications described in section 1.1. This kind of applications require to generate rulesets automatically and to gather traffic measurement data for immediate processing. The support by the RTFM architecture for this kind is not sufficient. Therefore, we understand that using a library is the suitable approach for the integration of application and RTFM architecture. 2.3. Requirements The following requirements were identified and are addressed in this document: (a) Applications should be able to control traffic measurements at a high level of abstraction from the RTFM architecture. The level of abstraction should be as high as possible, but at the same time it should be as low as necessary for providing sufficient functionality. (b) Applications should be able to gather measured traffic data in pull and push mode at a high level of abstraction. Again, the level of abstraction should be as high as possible and as low as necessary. (c) The functionality provided at the interface should be sufficiently generic to support different kinds of traffic measurement applications including Accounting and Charging, QoS monitoring as well as plain traffic measurement applications. 2.4. Declarative Flow Model Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 7] Internet Draft RTFM Interface 13 October 2000 One issue arising from requirement (a) of section 1.3 is the specification of flows to be measured. Controlling traffic measurements includes specify the flows to be measured. A specification by rulesets as defined by the RTFM architecture is rather complicated and error-prone, because it is a procedural specification. Rulesets are sequences of instructions to be executed by the pattern matching engine within the meter. A flow is specified by the set of all results of the execution of this procedure for all possible packet headers passing the meter. This is not well suited for an application, that would have to generate rulesets automatically. For the RTFM interface specified by this memo, a declarative specification of flows have been chosen. A flows specification consists of a list of attribute constraints which may be exact, wild-carded or generic. The latter one may generate more than one flow table entry out of a single flow description. Implementations of the RTFM interface have to provide the functionality of translating declarative flow specifications to procedural rulesets. 2.5. Modifying Active Traffic Measurements To be done. 3. Notation of the API Specification The interface specification is open to be implemented as API or as network protocol. Procedural API implementations, e.g. in C, are supported as well as object-oriented implementations. Therefore, we define data structures separated from functions on these data structures, supporting non-object-oriented approaches. However, we group data structures and functions in a way that reflects the grouping of attributes and methods by classes in object-oriented approaches. An object-oriented application is should define a class for each group (FlowDescription, FlowAttribute, Manager, Reader, Meter). How this specification can be mapped to implementations in programming languages is illustrated by appendices A and B. Appendix A shows a mapping of the API Specification to C data structures and function declarations, Appendix B contains a mapping to Java interfaces. Implementation of the interface by a network protocol is not discussed further in this document. The specification of each groups contains two sections: Data Structure and Functions. In the first section, the data structure(s) Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 8] Internet Draft RTFM Interface 13 October 2000 of this group is described as a list of fields. For each field, a name and a type are specified. The semantics of each field is explained. If a field is defined as a data structure of another group, the name of that particular group is used to specify the field's type. Applications using the API may read and set fields of the data structure, and pass and receive the data structure to or from function calls. In the second section all functions on the data structure are listed and described. The description includes parameters passed to the functions, return values and the functions' semantics. In order to comply with object-oriented paradigms, fields of a data structure may be modified only by functions belonging to the same group as the data structure. However, data structures may be passed to and returned by any function. The definitions use some basic data types: IPAddressType, SignedIntegerX and UnsignedIntegerX with X=8 or X=16. These types have to be defined more precisely by a mapping of the abstract specification in this document to an API or a network protocol. The IPAddressType may also be different for IPv4 and IPv6 implementations. 4. RTFM Interface Specification The RTFM interface consists of six groups, FlowDescription, FlowAttribute, Manager, Reader, and Meter. Each group contains a data structure and a set of functions on these data structures. For FlowDescription and FlowAttribute the data structures are the more relevant part, while for Manager, Reader, and Meter the offered functions are of more importance. The FlowDescription data structure serves to specify a single flow or a set of different flows to be metered. The FlowAttribute data structure serves to describe a single attribute of a flow by type and value. Within the interface definition, mostly sets of FlowAttribute data structures are used. The FlowData The groups Manager, Reader, and Meter model well known components of the RTFM architecture. 4.1. FlowDescription Instances of the FlowDescription data structure serve to specify a single flow or a set of different flows. Different to rule sets, the specification is declarative and not procedural. A FlowDescription leaves much less choices of specifying a flow than rule sets do, but the reduction of flexibility comes in line with an increase of simplicity. Still, the remaining flexibility is expected Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 9] Internet Draft RTFM Interface 13 October 2000 to be sufficient for most of the applications requiring traffic flow measurements. An implementation of the interface has to translate the FlowDescription data structure (and further input) into RTFM rule sets 4.1.1. Data Structure The FlowDescription data structure specifies a flow by nine fields: +----------------------+-----------------------+ | Name | Type | +----------------------+-----------------------+ | sourceIPAddress | IPAddressType | | destinationIPAddress | IPAddressType | | sourceIPMask | SignedInteger8 | | destinationIPMask | SignedInteger8 | | transportType | UnsignedInteger8 | | sourcePort | UnsignedInteger8 | | destinationPort | UnsignedInteger8 | | direction | UnsignedInteger8 | | futherAttributeSet | Set of FlowAtteribute | +----------------------+-----------------------+ 4.1.1.1 sourceIPAddress and destIPAddress The sourceIPAddress field and the destinationIPAddress field both have the type of an IP address. This may be different for IPv4 and IPv6 networks. The fields define which source and destination IP addresses must be contained in a packet, if it is assigned to the specified flow(s). How many bits of sourceIPMask and destinationIPMask are relevant is specified by sourceIPMask and destinationIPMask. 4.1.1.2 sourceIPMask and destinationIPMask For the IP addresses, these masks specify which bits of the address are wildcards. There are two kinds of wildcards: distinctive and non-distinctive. If wildcards are specified as non-distinctive, all packets differing in just these wildcards are counted in the same account. For distinctive wildcards, a new account is generated for each occurring bit pattern matching the wildcard. The sourceIPMask field and the destinationIPMask field specify the number of wildcard bits in the respective IP address starting with the least significant bit. The range of this field is [-32,32]. 0 means no wildcards, i.e. the respective IP address must be matched Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 10] Internet Draft RTFM Interface 13 October 2000 exactly. 32 or -32 are complete wildcards, i.e. any address matches. Positive bit numbers are used for non-distinctive wildcards, negative numbers for distinctive ones. As an example we take the IP address 134.45.123.56. If the corresponding mask has a value of 16, then all IP addresses 134.45.X.Y match and are assigned to the same flow. If the mask value is -8, then all addresses 134.45.123.X match, but each occurring value of X, is assigned to a different flow. 4.1.1.3 transportType This field specifies the value of the transport type, an IP packet must contain in order to be assigned to the specified flow(s). Only the following predefined values are valid for this field: 0 - any transport type matches (non-distinctive) 1 - TCP or UDP matches (non-distinctive) 2 - only TCP matches 3 - only UDP matches 4 - only ICMP matches 5 - only IGMP matches 4.1.1.4 sourcePort and destinationPort The sourcePort and destinationPort fields specify which respective port number an IP packet must contain in order to be assigned to the specified flow(s). A value of 0 is used as a non-distinctive wildcard matching any port number. These fields are only considered, when the transport type of the IP packet is TCP or UDP. 4.1.1.5 direction This fields serves to distinguish directed an undirected flows. It has 4 valid values: 0 - direction independent (non-distinctive) As described as the default case in [RTFM-ARC], a value of 0 indicates, that packets either matching the forward direction or the backward direction are assigned to the same flow(s). 1 - forward direction A value of 1 indicates that only packets matching exactly the specified source and destination are to be assigned to the specified flow(s). 2 - backward direction A value of 2 indicates that only packets matching the backward Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 11] Internet Draft RTFM Interface 13 October 2000 direction, i.e. the specified source matches the packet's destination and the specified destination matches the packet's source, are to be assigned to the specified flow(s). 3 - direction dependent (distinctive) A value of 3 indicates, that packets matching the forward direction and packets matching the backward direction are assigned to different flows. 4.1.1.6 futherAttributeSet This field contains a set of FlowAttribute. The set may be implemented as an array or list or other container. Alternatively, the field may just be a reference to a set of FlowAttribute. The set may be empty. In this case it has no influence on the assignment of packets to flows. If it is non-empty, each element of the list has to be matched exactly by an IP packet, if it is assigned to the specified flow(s). The set must not contain COUNT attributes. 4.1.2. Functions The functions on the FlowDescription data structure are restricted to get and set functions. For each field xxxXxxx there exists two functions getXxxXxxx() and setXxxXxxx(), e.g. getSourceIPAddress() and setSourceIPAddress(). Function getXxxXxxx() takes no argument and returns a value of the respective type, function setXxxXxxx() takes a parameter of the respective type and returns nothing. 4.2. FlowAttribute A FlowAttribute is a simple pair of an attribute type and an attribute value. 4.2.1. Data Structure +----------------------+-----------------------------+ | Name | Type | +----------------------+-----------------------------+ | attributeType | UnsignedInteger8 | | attributeValue | (depends on attribute type) | +----------------------+-----------------------------+ 4.2.1.1 attributeType The attributeType field contains a number indicating the type of the Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 12] Internet Draft RTFM Interface 13 October 2000 attribute. Valid numbers for this field are defined by [RTFM-ARC] and [RTFM-NEW]. 4.2.1.2 AttributeValue This field contains the value of the attribute. Its type depends on the attribute type. 4.2.2. Functions The funtions on the FlowDescription data structure are restricted to get and set functions. For each field xxxXxxx there exists two functions getXxxXxxx() and setXxxXxxx(), e.g. getAttributeType() and setAttributeType(). Function getXxxXxxx() takes no argument and returns a value of the respective type, function setXxxXxxx() takes a parameter of the respective type and returns nothing. 4.3. Manager The Manager provides functionality of an RTFM manager as specified in [RTFM-ARC]. However, most of its functionality is hidden by the interface, although the implementation must provide it. 4.3.1. Data Structure To be done, may be empty. 4.3.2. Functions So far there is only one function defined. Further ones need to be added. 4.3.2.1. measureFlow() Parameters name: flowDescription type: FlowDescription desc: Specification of the flow to be measured name: flowAttributes type: Set of FlowAttribute desc: List of Attributes to be measured. Here, just the attribute types are of interest. Attribute values in this list are ignored. name: meter type: Meter desc: The meter to be used for measurements Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 13] Internet Draft RTFM Interface 13 October 2000 name: firstTimeInterpretation type: UnsignedInteger8 desc: Interpretation of the start time timestamp of a flow name: collectTimeInterval type: UnsignedInteger16 desc: The readers interval of collecting flow data given in seconds The function's result is of type Reader. The function translates the passed FlowDescription into an RTFM rule set. Parameter flowAttributes specifies which attributes of the flow are to be measured. Only the attribute types are of this list of attributes are processed. Attribute values within parameter flowAttributes are ignored. The rule set is installed at the specified Meter and the Reader which is returned as result is configured to collect data from the Meter regularly. After the function is completed, the user of the interface may read measured flow data from the returned Reader. An invalid (null) Reader is returned, if the function failed. The interpretation of a flows start time can be modified by parameter startTimeInterpretation. Three valid values are defined for this parameter: 0 - ABSOLUTE: start time corresponds to the definition of attribute FirstTime in [RTFM-ARC]. 1 - RELATIVE: start time is equal to the time at which this function is called. 2 - RELATIVE_INCREMENTAL: start ime is equal to the last time, flow data has been read. The initial value of FirstTime is the time at which this function is called. To be done: description of collectTimeInterval The following example illustrates the difference between the three possible ways for interpreting the FirstTime attribute. Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 14] Internet Draft RTFM Interface 13 October 2000 +-------------------------------------+ | Packets received from host X | +-------------------------+----------+----------+---------------+ | Timestamp | ABSOLUTE | RELATIVE | RELATIVE_INCR | +-------------------------+----------+----------+---------------+ | t1. 2000-01-13 17:00:00 | 300 | | | | | | | | | t2. 2000-01-13 17:30:00 | 350 | 0 | 0 | | | | | | | t3. 2000-01-13 18:00:00 | 500 | 150 | 150 | | | | | | | t4. 2000-01-13 18:30:00 | 515 | 165 | 15 | | | | | | | t5. 2000-01-13 19:00:00 | 670 | 320 | 155 | | ....... | ... | ... | ... | | ....... | ... | ... | ... | +-------------------------+----------+----------+---------------+ 4.4. Reader group 4.4.1. Data Structure 4.4.2. Functions This section needs to be elaborated. 4.4.2.2. getFlowDesc() 4.4.2.3. readFlowData() 4.4.2.4. installFlowDataListener() Add this Reader as a new FlowData Listener in the the list of Listeners. 4.4.2.5. deleteFlowDataListener() Delete this Reader from the list of Listeners. 4.5 Meter The Meter data structure and functions serve just to identify a real meter. The functions do not give access to metering functionality. Meter data structures are passed to Managers and readers for specifying which Meter to manage or read. 4.5.1 Data Structure Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 15] Internet Draft RTFM Interface 13 October 2000 +-----------+------------------+ | Name | Type | +-----------+------------------+ | host | IPAddressType | | port | UnsignedInteger8 | | community | String | +-----------+------------------+ 4.5.1.1. host The host field specifies the IP address at which the Meter can be contacted. 4.5.1.2. port The UDP port at which the Meter can be contacted at the host. 4.5.1.3. community The community string which is required to access the Meter. 4.5.2. Functions The funtions on the FlowDescription data structure are restricted to get and set functions. For each field xxxx there exists two functions getXxxx() and setXxxx(), e.g. getHost() and setHost(). Function getXxxx() takes no argument and returns a value of the respective type, function setXxxx() takes a parameter of the respective type and returns nothing. 5. Required Extensions To be done: Extensions of the RTFM architecture or the Meter MIB required for the implementation of the RTFM interface. 6. Security Considerations This document contains a generic specification of an RTFM interface. To API implementations of the interface the same general security considerations apply than to other libraries for network management applications. API implementation might use network protocols, for example SNMP, for accessing real instances of a Meter. In such a case, the security considerations concerning the particular protocol apply. If the RTFM interface is implemented by a network protocol, several security issues have to be investigated. But this discussion is not subject of this memo. Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 16] Internet Draft RTFM Interface 13 October 2000 7. Acknowledgments To be done. 8. References [RTFM-ARC] Brownlee, N., Mills, C. and Ruth, G., "Traffic Flow Measurement: Architecture", RFC 2722, October 1999. [RTFM-SRL] Brownlee, N., "SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups, RFC 2723, October 1999. [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999. [RTFM-NEW] Handelman, S., Stibler, S., Brownlee, N. and G. Ruth, "RTFM: New Attributes for Traffic Flow Measurement", RFC 2724, October 1999. [RFC2753] R. Yavatkar and D. Pendarakis, R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. 9. Authors' Addresses Juergen Quittek NEC Europe Ltd. C&C Research Laboratories Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de Marcelo Pias University College London (UCL) Department of Computer Science Gower Street London WC1E 6BT UK Phone: +44 171 387 1397 EMail: m.pias@cs.ucl.ac.uk Appendix A: C mapping of the RTFM interface specification Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 17] Internet Draft RTFM Interface 13 October 2000 To be done. Appendix B: Java mapping of the RTFM interface specification To be done. Quittek&Pias draft-quittek-rtfm-generic-interface-00 [Page 18]