Network Working Group Internet Draft Expiration Date: January 2002 Lily Cheng John Ellson Yangguang Xu Lucent Technologies, Inc. July 2001 A Framework for Internet Network Engineering draft-cheng-network-engineering-framework-00.txt 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 document outlines an early draft of a Network Engineering (NE) framework. It defines Network Engineering function and discusses the differences between Traffic Engineering (TE) and Network Engineering. It identifies network architecture and major functional capabilities for Network Engineering. Network Engineering provides a new set of capabilities to incorporate Traffic Engineering to optimize the network efficiency, operation, and utilization. Table of Content 1.0 Introduction and Background 1.1 Long-term and Short-term Internet Engineering Models 1.2 Conventional Traffic Engineering and Limitation 1.3 Layered Network 1.4 Conventional IP Network Planning and Limitation 1.5 Terminology 2.0 Network Engineering 2.1 Why Network Engineering 2.2 What is Network Engineering 2.3 How 2.4 When 2.5 Where 3.0 Architectural Elements of Network Engineering 3.1 Architectural Overview 3.2 Traffic Information 3.3 Network Topology Information 3.3.1 IP Network Topology Information 3.3.2 Transport Network Topology Information 3.4 Triggering Mechanisms 3.5 Optimization Module 3.6 Link Operations 4.0 Network Engineering and Traffic Engineering - A Closed-loop relation 5.0 Summary 6.0 Security 7.0 Authors Addresses 8.0 References 1. Introduction and Background 1.1 Long-term and Short-term Internet Engineering Models Figure 1 illustrates the long-term and short-term Internet Engineering model for a network. Traditionally, Network Planning is used to build a physical network with static topology. Traffic Engineering is used to optimize network resource utilization for traffic demands. It is the optimization of network resources based on a fixed network topology. It allows traffic to utilize network resources in an efficient way. Network Planning is a long-term process to optimize network resources for long-term traffic growth, while Traffic Engineering is a short-term process to optimize network resources for short-term traffic fluctuation. --------- / Traffic \ \---------/ | | Traffic Engineering (Short-term) v -------------------- /Network w. Resources\ Network w/ Physical Topology \--------------------/ ^ | Network Planning (Long-term) | ---------------------- /NE, NE, NE, link, link\ Resrc. Pool w/ uninstalled NEs & links \----------------------/ Figure 1 Long-term and Short-term Internet Engineering Processes 1.2 Conventional Traffic Engineering and Limitation Traffic Engineering, in short is putting traffic where the capacity is. This is contrasted with Network Engineering, which is putting capacity to where the traffic wants to be. [TE-FRWK] has a detailed definition of Internet Traffic Engineering. "Internet traffic engineering is defined as that aspect of Internet Network Engineering dealing with the issues of performance evaluation and performance optimization of operational IP networks. Traffic Engineering encompasses the application of technology and scientific principles to the measurement, characterization, modeling, and control of Internet traffic [RFC-2702, AWD2] ... " In traditional IP traffic engineering, the underlying network topology is assumed to be relatively static [rfc2702, te-MPLS-diff]. In particular, the links connecting the IP/MPLS routers in the backbone are typically provisioned for a long period of time due to the difficulties of rapid reconfiguration of the links. The main objective of IP/MPLS traffic engineering is efficient mapping of traffic demands onto the network topology to maximize resource utilization while meeting QoS constraints such as delay and packet loss. The traffic demands may be obtained from measurement, projection, customer prescription, Service Level Agreement (SLA), or combination of the above. The mapping may be done in a multi-period fashion corresponding to diurnal or weekly patterns. In a MPLS network, the mapping is facilitated by establishing explicit label switched paths. In a connectionless IP network, the mapping can be attempted by adjusting IGP weights. The key assumption of current Internet Traffic Engineering is that the total network resources for IP routers to use are fixed. This assumption is changed by the Automatically Switched Transport Network (ASTN). Instead of a fixed amount of resources, the total network resources for IP routers can now be flexible. The IP network can get more resources from its provider network, which may be a lower layer network. It can also return resources to its provider network. The ASTN is a provider network to the IP network, which provides a flexible network resource pool to the IP client network. However, the resources (bandwidth, links, ports) of the pool are limited. 1.3 Layered Network In the computational view, the network is layered. For "switching" networks, they can be layered according to network's "switching" granularity. For example, an IP router's switching granularity is a packet; a SONET circuit's switching granularity is STS-1; a non-OEO optical switch's switching granularity is a wavelength. These different types of NEs are at different network layers. They form client/server relationship among each other. PDM (packet/cell) ____________________________________________________________ TDM LO (DS-1, VT1.5 etc.) | | | ______________________________V_______ | | TDM HO (DS-3, STS-1 etc.) | | | __________________________________V______V____ | WDM | | ______________________________________V_____________V___ SDM | __________________________________________V________________ Figure 1 Switching Hierarchies This layered view doesn't need to translate into implementation or network partition directly. In the computational view, there is a separate logical control entity for each layer. In the implementation, these entities may collapse or integrated onto a single control plane. However, it is critical to understand implication of layering to the Network Engineering process. The implication of layering is that network connections at different logical layers are triggered by different reasons and may be created at different time because of: (1) Bandwidth*Time Mismatch The bandwidth*time in the IP user networks is of finer granularity; whereas the bandwidth*time in the provider networks is of larger granularity. Hence, multiple IP links often tunneled into a link to increase link utilization. The holding time of an IP link is usually shorter than the holding time of an optical link, since an optical link typically contains multiple IP links. Tearing down one or more IP links may only result in the reduction of bandwidth in an optical link. Tearing down an optical link can only be done if all constituent IP links are torn down, or if the remaining IP links can be re-routed through another optical link. (2) Cost/Value Mismatch The establishment of a link incurs a certain cost to the client IP network. It is important that the cost is within a planned budget. This may involve re-optimization and tearing down some circuit links. The circuit network is a limited resource, it is important that the total value of the links established from a circuit network is maximized. 1.4 Conventional IP Network Planning and Limitation In conventional IP network, static topology is normally set up at the network planning time according to the most stringent traffic demand patterns in a given duration. Because of forecasting mismatch and the inability of changing the network topology fast enough, Traffic Engineering limits itself to achieve higher network resource utilization. Observe that the static topology of the IP network introduces limitations. Consider first the case when traffic demands are well estimated a priori. In this case, provisioning needs to be done according to the most stringent traffic demand patterns in a given duration (even under the assumption that the best TE plan, which can take advantages of multi-period traffic pattern is used). Therefore, network resources remain under-utilized when traffic demands are light (e.g., during weekends or evenings) since provisioned links cannot be released easily. When the traffic demands cannot be estimated accurately, network planning may not be done correctly. For example, if link provisioning is inadequate, traffic demands can exceed the required network resources. This may occur because of forecasting mismatch or the inability of provisioning the network fast enough to meet the growth in resource requirements. On the other hand, it may be necessary to over- provision the network due to the difficulties of forecasting the traffic growth accurately. Furthermore, if the provisioning cycle (i.e., the time it takes to add resources to the network) is long, resource provisioning needs to take into account the projected traffic growth until the beginning of the next cycle. Consequently the extra network resources may be significantly under-utilized at the early part of a cycle if the projected growth is large. 1.5 Terminology Link-connection û one channel between subnets. That is to say one unit of capacity between subnets. A link connection may or may not be carrying traffic. Link û a set of all link connections between a pair of subnets that are equivalent for routing. This definition allows a link to have zero link connections. An IP link û a unidirectional physical connection between two IP routers. Note that usually IP links are bi-directional. Any request for a bi-directional link can then be accomplished by two requests, each for an uni-directional link. It could be an optical network connection through the underlying circuit switched network. In this case, an IP router has logical adjacency with its IP router peer and physical adjacency with the circuit switch that it is connected to. A configurable IP link-connection û an IP link, which can be dynamically setup and released within the circuit-switched layer, thus may actively change the IP network topology. A non-configurable IP link-connection û an IP link, which cannot be dynamically setup and released within the circuit-switched layer. User Network û an IP network, which can dynamically setup and release a link within the circuit-switched Network. Provider Network û a circuit-switched network, which can dynamically setup and release a link for the user network. Capacity û The ability of a link or link connection to carry traffic, doesnÆt imply the traffic is present or not present. Traffic û the presence of traffic in the capacity of a link or link connection. Overloaded port û A port which has more traffic than the port capacity Overloaded router û An IP router which has no more port capacity for addition traffic Configurability û the ability of the IP layer to add a link, delete a link, and modify the parameter(s) of a link. 2. Network Engineering 2.1 Why Network Engineering We present a first-draft description of Internet Network Engineering functionality and capabilities to address the limitation of classic IP Traffic Engineering and Network Planning. Figure 2 illustrates the engineering hierarchy for an Internet Engineering Process for a network to satisfy traffic demands from both short-term and long-term perspectives. --------- / Traffic \ \---------/ | | Traffic Engineering v -------------------- /Network w. Capacity \ User Network w/ Static Topology \--------------------/ ^ | Network Engineering | --------------------- / Network w. Links \ Provider Network w/ Links to change \---------------------/ User Network Topology and Capacity ^ | Network Planning | ---------------------- /NE, NE, NE, link, link\ Resrc. Pool w/ uninstalled NEs & links \----------------------/ Figure 2 Engineering Hierarchy We consider a network consists of a set of IP routers that are inter- connected either through fix links or through a set of circuit switches. That is, there are two logical layers, i.e., IP layer and the underlying circuit-switched layer. These two logical layers interact in a user-provider relationship. The circuit-switched layer can be thought of as merely providing dynamically configurable links for the client network. Network Engineering considers user link configuration within a provider domain, hence the choice of the signaling protocol, which will carry parameters defined in this paper, is not relevant for the time being. 2.2 What is Network Engineering Network Engineering is a part of a larger Network Planning function, which makes decisions on installing fiber and network equipment for a network based on forecast traffic demands. The user network and provider network will have independent Network Planning processes. The computation for Network Planning is typically done offline since it involves searching on multi-dimensional solution spaces. Network Engineering is an automation of the part of Network Planning that can be supported from a provider network. Network Engineering is an automatic network provisioning procedure. It is to allocate/de-allocate provider network resources to be used by the user network. In other words, Network Engineering is to put the capacity where the traffic wants to be. Internet Network Engineering process concerns with the management of the (virtual) links in the IP network based on the traffic demands that are expected between any two routers in the network (pro-active) and the actual traffic demands (re-active). The fundamental issue is design, ranking, and choice of an IP link, which is to be established by the circuit-switched layer. It is also worth being able to calculate the number of current open connections and the maximum number of open connections allowed (due to limits in either capacity or connection identifiers). Network Engineering may also add a link or modify (i.e. increase) a link on request of a traffic engineering process (if compliant with policy), which is not able to complete a call in the absence of available bandwidth. In the following sub-sections, we will elaborate the ôhowö, ôwhenö, and ôwhereö concept. 2.3 How To data network, conventional transport networks are "static". They are provisioned as leased line services. Classic IP TE considers a fixed IP layer topology. A distributed transport control plane can provide an on-demand automatic choice and configuration of underlying circuits to be used in the IP layer. The new control plane of the transport network transforms the "dummy pipes" into a foundation for switched connection services, a service platform that can provide automatic link provisioning function rather than simple transmission. This new function enables numerous upper layer services. This new dynamic of adding and deleting capacity of the transport network has profound impacts on conventional data networking. It changes the data network's basic assumption that the transport network consists of fixed pipes, i.e., a static network. In the new paradigm, the transport network can be considered as a configurable back plane. Packet switches can dynamically adjust the network topology according to end network traffic to optimize overall network performance. 2.4 When Network Engineering also monitors the layered network to determine - when a new link should be added to the IP network, - when an existing link should be modified (i.e. increased or reduced), or - when a link should be released. Network Engineering is a new functional module in addition to conventional Traffic Engineering. This function is independent of any network models (e.g., peers, overlay or augmented)). 2.5 Where The connection resources available from the provider network are limited. Network Engineering much choose where the most beneficial links to add. Network Engineering should also monitor the bandwidth demands from a source/destination relationship in order to identify the traffic patterns in the network. Where necessary, a network's topology can be optimized by e.g. adding direct links between two heavily interconnected nodes. Decisions are taken based on policies set by the network operator. Many efforts have been devoted to the control plane design. That is, ôhowö to automatically provision a link. Our work on the other hand focuses on ôwhenö and ôwhereö to automatically provision a link. 3. Architectural Element of Network Engineering 3.1 Architectural Overview Figure 3 shows an architecture for the Network Engineering. A decision making functional module is triggered by some triggering mechanisms (e.g., proactive input or reactive input), and takes the current network status (e.g., traffic information and topology information) to compute the output. The input of the Network Engineering process is the current measured state of the user network. Proactive information makes possible traffic shaping for particular purposes, e.g., busy hour, network overload threshold, etc. The proactive mechanism might also use the bandwidth advertising from the circuit network in order to pre-estimate the links to establish. The bandwidth advertising might be invoked periodically. Reactive information can trigger the establishment of new links upon measured performance. The output of the Network Engineering phase is a target IP link, which can be configured as a switched circuit. In other words, the result of the Network Engineering is to add a link, delete a link, or modify parameters of a link. +------------------------+ | IP Traffic Information | +------------|-----------+ +-----------+ | | Proactive | +------------v-----------+ +------------+ | Input | Triggers | | | | +-----------+--------->| IP Network Engineering +---->| Operations | | Reactive | | | | | | Input | +------------^-----------+ +------------+ +-----------+ | +------------|------------+ | IP Topology Information | +-------------------------+ Figure 3 Network Engineering Architecture 3.2 Traffic Information An IP network has network internal information and external information, that can be applied to proactively or reactively triggering switched links. The network internal information deals with the traffic statistics collected over a certain period of time, based on which particular traffic flows can be established according to the predictable traffic patterns. The internal information can also trigger the reconfiguration of the existing traffic patterns for more efficient service-level guarantees or network throughput. This information is reactive but can be also used predictively by assuming cyclic traffic patterns. The network-external information deals with boundary-to-boundary traffic requests. If such a request identifies an amount of resources that is needed to predict the need for circuits. This information can be neither estimated nor measured. An example of such information might be a new contract or a new traffic request. In this case, for example, the predictable traffic patterns as defined by the long-term traffic measurements have to be revised. Examples of internal information are: packet loss [rfc2680], router overload, port overload, link overload. Examples of external information are: SLA violations, or new SLAs. Such information triggers the network design to automatically configure an IP link. Depending on the triggering information, configuration can be adding, deleting circuit links, or modifying existing traffic parameters. Both external and internal information may result in connection requests. The network-internal information are obtained based on the measurements within the user network, and the network-external information can be estimated based on the service contract information related to the new traffic. 3.3 Network Topology Information 3.3.1 IP Network Topology Information In order to perform Network Engineering function, the IP router need to have the following topology information: 1. Conventional Routes to IP peers These are standard IP routes to various destinations learnt through conventional IGPs (e.g., ISIS or OSPF) as well as EGPs (e.g., BGP). 2. Forwarding Adjacencies Forwarding Adjacencies [LSP-HIER] are IP (i.e., Layer 3) neighbors that are connected by an underlying circuit-LSP through a provider network. These connections are dynamic in nature and can be set up and torn down as required. Both IP routes and Forwarding Adjacencies are used for packet forwarding. Such information is disseminated using the usual IGP/EGP routing protocols. A Provider network treats traffic carrying this kind of information as user traffic. In addition to these two types of information, a client network also maintains information about: 3. Potential Fas - PFAs are remote CAGs [BGP/GMPLS]. They represent NEs that belong to the same client network (in a remote location) or to a different client network that allows NEs in the local network to connect to it. The NEs represented by a PFA are not connected yet but can be connected to the local NE. Such a connection is a direct connection at the IP layer with an underlying physical connection that spans multiple AS-es. Information about PFAs can be disseminated through BGP extensions in the provider network or some other directory server/yellow pages mechanism. 4. Accessible IP Routes through the PFAs This provides information about all the IP routers reachable through a PFA endpoint. For example, in Figure 1, a route to A1 would be an accessible IP route reachable through PFA A2 from the viewpoint of router A5. Such information can be used for the IP Network Engineering [NE-FRWK] function to determine the source and destination of the optical circuit connections. Although this document does not address the issue of how this information is disseminated, we note here that various options exist for doing so. These options include dissemination through established client network connections or a dedicated client network control plane network. 3.3.2 Server Network Topology Information There is no topology information exchange needed at the user-provider boundary. The user knows its own topology and treats the provider network as a point-like switch. 3.4 Triggering Mechanisms There is a set of triggering events, which defines ôwhenö to activate network engineering function. 1. Direct user request û User should be able to request a network engineering function. For example, an operator may need to do on- line or off-line capacity planning or business modeling for his network. 2. Response to adding a link û It is among network engineering capability to add a link to the network. The request maybe a result of future planning of the network or an unexpected traffic loads. 3. Response to deleting a link û It is among network engineering capability to delete a link from the network. The request maybe a result of future planning to an expected reduced traffic loads. 4. Response to modifying a link û It is among Network Engineering capability to modify a link to the network. If the request is to increase the capacity of a link, it maybe a result of future planning of the network or an unexpected traffic loads. If the request is to decrease the capacity of a link, it maybe a result of future planning or reduced traffic loads. 5. Congestion condition û Congestion problem is probably one of the most studied problem in contemporary Internet networks. When a congestion condition is not properly handled, it will significantly degrade network performance. 6. Router overload û Upon a router overload condition, it is desirable to find an alternative route for traffic going through the router. 7. Link overload û Upon a link overload condition, it is desirable to add more capacity parallel to the congested link. If this is not feasible, it is desirable to increase capacity over a different route and redirect some of the existing traffic to the newly added link to relief the overloaded condition. 8. Maintenance û In the maintenance phase, it is also desirable to run Network Engineering function. 9. Failure û Upon a failure situation, e.g., link failure, network failure, etc., it is desirable to run Network Engineering function. 10. Routine û If none of the above condition occurs, it is desirable to run the Network Engineering function on a regular basis. Routinely running network engineering function can insure that the network is making the most efficient use of it network resources. The interval of the routine depends on the network sizes and traffic loads of the network. 3.5 The Decision Making Module Network Engineering decision making module will involve the path computation depending on the knowledge of the layered network. The problem of selecting a new link that best satisfies demands for bandwidth is a multi-dimensional optimization problem, i.e. one that is mathematically "hard" and probably not possible to compute perfectly, even in principle. This problem can be decomposed into two parts: link design, and link choice. The design phase identifies a set of links that would satisfy some needs; whereas the choice phase chooses a final set of links based on maximizing total value. First of all, link design provides a set of potential links that meets the following criteria: 1. links that are configurable in the circuit-switched layer (e.g., with free ports, and free capacities), and 2. links that has enough capacity to meet traffic demands. During the design phase, we distinguish different types of links based on the number of hops the link bridges. The output of link design can be zero or more candidate links to be ôconfiguredö (e.g., add, delete, modify) in the circuit-switched layer. If no link is selected, it means blocking in the circuit layer. Secondly in the choice phase, a set of criteria, for choosing a final link amongst a set of candidate links, is needed. The criteria are based on the consideration of bandwidth, distance, and duration. Link choice ranks the set of potential links, selected from the above link design, according to the following set of parameters: 1. number of hops bridged, 2. bandwidth utilization of the new link, 3. value (or more correctly, rate of return on investment), 4. number of switched-ports spared, or 5. etc. It then requests the reduced set of maximum value from the potential links. One implication of the link choice is that a link design may get refused for reasons of insufficient value. The value of any link requested can be expressed by 1. multiple attributes (as listed for link choice) or 2. a single metric mixed out of multiple parameters (e.g. bandwidth, distance, etc.). To avoid the problems of multi-dimensional optimization as described above, a single metric can be chosen as precedent, based on which a choice is made if all other requirements are satisfied. 3.6 Link Operations There are four types of link operations: 1. add a link Adding a link is to add a potential route with zero capacity. This type of link bridges two or more hops of existing IP links. Note that it changes the IP network topology without adding new capacity. Routing tables will need to be modified. Consider an IP (user) over an circuit (provider) network, where traffic flows from the source node A to the destination node Z. The following figure shows adding a new link p-s. A p q r s Z O------O......O......O......O-------O :....................: 2. add a link connection Adding a link connection is to increase the capacity of an existing link. This new link (connection) bridges a single hop of IP link. It parallels an existing link and increases capacity of this link without changing the network topology. The following figure shows adding a new link connection r-s. A p q r s Z O------O......O......O:::::::O-------O 3. delete a link connection This operation is only allowed when the traffic of that link connection is zero. Deleting a link connection is to decrease the capacity of a link. It may reduce the capacity of a link to zero. 4. delete a link This operation is only allowed when the number of link connections in the link is zero. That is, when the capacity of the link is zero. To delete a link means to remove a potential route with zero capacity. For the purpose of network engineering, if we need a new link with some capacity, we need to add a link (with zero capacity), and then add a new link connection to increase the capacity of this new link. If we need to delete a link, we will need to delete all the link connections in that link before deleting the link. 4 Network Engineering and Traffic Engineering - A Closed-loop Relation This section illustrates a closed-loop relationship between Network Engineering and Traffic Engineering processes (Figure 4). A closed-loop link provisioning process would automatically configure circuits in the circuit network [cheng1]. The cycle is closed because changes in bandwidth or topology affect the state of the user network. ---------------------------------- +--> the state of the user network | ---|---------^-------------|------ | | | | | topology& | topology & | traffic route Triggers | updates updates | | | | | topology | | | updates +-v----------+ +------v------+ | | Traffic | | Network | | | Engineering|--->-| Engineering |-+ ^ +------------+ +-------------+ | | | +--+--------+ | | topology | | | discovery | | +-----+-----+ User Network -----------+------------- UNI -------------------+--------- | Provider Network | | Operation Operations result | | +------------+ | +---<-------| Operations |-----<------+ +------|-----+ ^ | | v ---------------|-------------------- the state of the provider network ------------------------------------ Figure 4 A Closed-loop Procedure for NE and TE Within the circuit layer a choice between candidate switched circuits can be made for the IP network in order to have the maximum advantages of a dynamic configuration. All circuits, which may be configured, are within the bounds requested by the IP layer, otherwise the request is rejected. 5. Summary In this paper, we have outlined an early draft for an Internet Network Engineering framework. Traffic problems, which occur due to the limitations of Traffic Engineering, can trigger Network Engineering processes to further optimize the network performance. Network Engineering is to automatically select a link for addition, deletion, and modification to address Traffic Engineering limitation. Network Engineering and Traffic Engineering form a closed-loop process to optimize the network resources. We also note that the specific choice of technologies is not essential to a Network Engineering process. It is important to recognize the problem is recursive. The closed-loop process for Network Engineering and Traffic Engineering is applicable to any user-provider relationship networks. 6. Security Issues This document raises no new security concerns for MPLS signaling. 7. Authors Addresses Lily Cheng John Ellson Lucent Technologies, Inc. 101 Crawfords Corner Rd Holmdel, NJ 07733 Email {lilycheng, ellson}@lucent.com Yangguang Xu Lucent Technologies, Inc. 1600 Osgood St. North Andover, MA08145 Email xuyg@lucent.com Iraj Saniee Lucent Technologies, Inc. 600-700 Mountain Ave. Murry Hill, NJ07974 Email iis@lucent.com 8. References [rfc2702] Awduche D. et. al. "Requirements for Traffic Engineering over MPLS", RFC2702, September 1999. [newsome00] Newsome, G. "IP Traffic Engineering resulting in Optical Layer Connections", IETF draft draft-newsome-mgmtplanerqmts-00.txt, November 2000. [te-ip-01] Duroyon O. et. al. "G.LSP Service Model framework in an optical G-MPLS network", IETF draft, draft-duroyon-te-ip- optical.01.txt, November 2000. [te-MPLS-diff] Le Faucheur et. al. "Requirements for support of Diff- serv-aware MPLS Traffic Engineering", IETF draft, draft-ietf-mpls-diff- te-reqts-00.txt, November 2000. [te-frame] Awduche, D. et. al. "A framework for Internet Traffic Engineering" IETF draft, draft-ietf-tewg-framework-02.txt, July 2000. [rfc2679] Almes, G. et. al. "A One-way Delay Metric for IPPM," RFC2679, September 1999. [rfc2680] Almes, G. et. al. "A One-way Packet Loss Metric for IPPM," RFC2680, September 1999.