1999 Seventh
`
`International Workshop
`on Quality of Service
`
`1::
`IWQ05 ’99
`
`London, England
`May 31 — June 4, 1999
`
`=
`
`IEEE
`d' V!"
`v
`‘I
`
`4:"
`
`‘ ’J r.
`
`f:-
`
`a
`(3‘
`
`.
`
`M
`
`Palo Alto Networks V. Sable Networks
`
`IPR2020-01712
`
`EX 1 0 1 9
`
`EX1019
`Palo Alto Networks v. Sable Networks
`IPR2020-01712
`
`

`

`
`
`'1999 Seventh
`
`International Workshop
`on Quality of Service
`
`:3:
`I‘M/Q05 ’99
`
`London, England
`May 31 — June 4, 1999
`
`Sponsored by IEEE Communications Society and
`
`IFIP WG6.1 in Association with ACM SIGCOMM
`
`With generous support from
`
`Nortel Research UK
`
`Hewlett Packard Internet Research Institute,
`
`Microsoft Research, and Sprint Labs
`
`

`

`1999 Seventh International Workshop on Quality of Service
`
`Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond the
`limits of US. copyright law for private use of patrons those articles in this volume that carry a
`code at the bottom of the first page, provided the per—copy fee indicated in the code is paid through
`the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923. For other copying,
`reprint, or republication permission, write to the IEEE Copyright Manager, IEEE Operations
`Center, 445 Hoes Lane, Piscataway, NJ 08855-1331. All rights reserved. Copyright © 1999 by
`The Institute of Electrical and Electronics Engineers, Inc.
`
`ISBN Softbound:
`
`0-7803-5671-3
`
`IEEE Catalog Number:
`
`Library of Congress:
`
`98EX354
`
`99—63125
`
`Additional copies of this publication are available from
`
`IEEE Operations Center
`P. O. Box 1331
`445 Hoes Lane
`
`Piscataway, NJ 08855-1331 USA
`
`1-800—678-1EEE (1-800-678-4333)
`1-732—981-0060
`1-732—981-1393
`
`1-732—981-9667 (FAX)
`email: customerservice@ieee.org
`
`'r .. U.
`"Kurt K. \,-"‘-.fem,‘i Library
`Universiéy 0;? ‘
`'20.? ”zndlsofl
`215 i‘v. f
`.7" 3311;;0
`Madison, \M 53705—1688‘1
`
`
`
`

`

`IWSZOS ’99 Table of Contents
`
`Session 1 — Admission Control and Related Matters ................................................................................................ 1
`
`Measurement-Based Admission Control: What is the Research Agenda? ............................................................ 3
`Lee Breslau, Sugih Jamin, Scott Shenker
`
`The DIY Approach to QOS .................................................................................................................................. 6
`Gunnar Karlsson and Fredrik Orava
`
`IP over Photons: How not to waste the waist of the Hourglass ............................................................................ 9
`Jon Crowcroft
`
`Utility Curves: Mean Opinion Scores Considered Biased .................................................................................. 12
`Hendrik Knoche, Herman De Meer, David Kirsh
`
`Session 2 — Distributed QoS Architecture ............................................................................................................... 15
`
`Performance of QoS Agents for Provisioning Network Resources .................................................................... 17
`Olov Schelén , Andreas Nilsson, Joakim Norrgard, Stephen Pink
`
`A Distributed Resource Management Architecture that Supports Advance
`Reservations and Co-Allocation ......................................................................................................................... 27
`Ian Foster, Carl Kesselman, Craig Lee, Bob Lindell, Klara Nahrstedt, Alain Roy
`
`Optimal State Prediction for Feedback-Based QoS Adaptions ........................................................................... 37
`Baochun Li, Dongyan Xu, Klara Nahrstedt
`
`Session 3 - Software Structures and QoS ................................................................................................................ 47
`
`The Role of Reflection in Supporting Dynamic QoS Management Functions ................................................... 49
`Gordon Blair , Anders Anderson, Lynne Blair, Geoff Coulson
`
`A Software Framework for Application Level QoS Management ..................................................................... 52
`Varuni Witana, Michael Fry and Mark Antoniades
`
`Securing QoS: Threats to RSVP Messages and Their Countermeasures ............................................................ 62
`Tsung-Li Wu, S. Felix Wu, Zhi Fu, He Huang, Fengmin Gong
`
`Virtuosity: Performing Virtual Network Resource Management ....................................................................... 65
`Andrew T. Campbell, John Vicente, Daniel A. Villela
`
`Session 4 - Performance ............................................................................................................................................ 77
`
`On Service Guarantees for Input Buffered Crossbar Switches:
`A Capacity Decomposition Approach by Birkoff and von Neumann. ................................................................ 79
`Cheng-Shang Chang, Wen—Jyh Chen and Hsiang-Yi Huang
`
`QOS Enhancement with Partial State .................................................................................................................. 87—
`Deying Tong, A. L. Narasimha Reddy
`
`Evaluation of Differentiated Services using an Implementation under Linux .................................................... 97
`Roland Bless, Klaus Wehrle
`
`
`
`
`
`

`

`Session 5 — Routing & Forwarding ........................................................................................................................ 107
`
`Efficient Multi—field Packet Classification for QoS Purposes .......................................................................... 109
`Niklas Borg, Emil Svanberg and Olov Schelén
`
`Quality—of-Service Routing using Maximally Disjoint Paths ........................................................................... 1 19
`Nina Taft-Plotkin, Bhargav Bellur and Richard Ogier
`
`Quality-of—Service Routing without Global Information Exchange ................................................................. 129
`Srihari Nelakuditi, Rose P Tsang, and Zhi-Li Zhang.
`
`A Proposal for an Asymmetric Best-Effort Service .......................................................................................... 132
`Paul Hurley, Jean—Yves Le Boudec
`
`Session 6 — (panel/discussion)
`
`Panel: What Service Differentiation Do Users Really Want?
`
`Session 7 — Aggregation ........................................................................................................................................... 135
`
`Source—oriented Topology Aggregation with Multiple QoS Parameters
`in Hierarchical ATM Networks ........................................................................................................................ 137
`
`Turgay Korkmaz and Marwan Krunz
`
`Aggregation of Guaranteed Service Flows ....................................................................................................... 147
`Jens Schmitt, Martin Karsten, Lars Wolf, Ralf Steinmetz
`
`Impact of Marking Strategy on Aggregated Flows in a
`Differentiated Services Network ..................................................................................................................... 156
`
`ijun Yeom, A. L. Narasimha Reddy
`
`Paris Metro Pricing: The Minimalist Differentiated Services Solution ............................................................ 159
`Andrew Odlyzko
`
`Session 8 — Pricing ................................................................................................................................................... 163
`
`Managing and Pricing Service Level Agreements for Differentiated Services ................................................ 165
`Costas Courcoubetis and Vasilios A. Siris
`
`Provider-Oriented Linear Price Calculation for Integrated Services ................................................................ 174
`Martin Karsten, Jens Schmitt, Lars Wolf, Ralf Steinmetz
`
`Market Pricing of Differential Internet Services ............................................................................................... 184
`Nemo Semret, Raymond R.F. Liao. Andrew T. Campbell, Aurel A. Lazar
`
`Session 9 — MPLS ..................................................................................................................................................... 195
`
`Resource Allocation in Multiservice MPLS ..................................................................................................... 197
`
`Magda Chatzaki, Stelios Sartzetakis, Nikos Papadakis, Costas Courcoubetis
`
`Supporting Differentiated Services in MPLS Networks ................................................................................... 207
`Ilias Andrikopoulos, George Pavlou
`
`Web Server QoS Management by Adaptive Content Delivery ......................................................................... 216
`Tarek F. Abdelzaher, Nina Bhatti
`
`vi
`
`

`

`Session Based Admission Control:
`
`A Mechanism for Improving Performance of Commercial Web Sites ............................................................. 226
`Ludmila Cherkasova and Peter Phaal
`
`Session 10 — Flow Control & Adaptation & RED ................................................................................................. 237
`
`Hop-by-hop Flow Control as a Method to Improve Q08 in 802.3 LANs ......................................................... 239
`Jerzy Wechta, Martin Fricker, Fred Halsall
`
`Work Conserving vs. Non-workconserving Packet Scheduling: An Issue Revisited ....................................... 248
`Jorg Liebeherr, Erhan Yilmaz
`
`Drop Behaviour of RED for Bursty and Smooth Traffic .................................................................................. 257
`Thomas Bonald, Martin May
`
`Reasons Not to Deploy RED ............................................................................................................................ 260
`Martin May, Jean Bolot, Christophe Diot, Bryan Lyles
`
`Author Index ...................................................................................................................................... Follows page 262
`
`vii
`
`

`

`Supporting Differentiated Services in MPLS Networks
`
`Ilias Andrikopoulos and George Pavlou
`
`Centre for Communication Systems Research (CCSR)
`
`University of Surrey
`
`Guildford, Surrey, GU2 SXH, UK
`Email: {1.Andrikopoulos, G.Pavlou}@ee.surrey.ac.uk
`
`Abstract: Multi-Protocol Label Switching is a relatively
`new technology based on the association of labels with
`routes and the use of labels to forward packets. In other
`words MPLS integrates the label-swapping paradigm with
`network-layer routing. Differentiated Services define a
`model for implementing scalable differentiation of 008 in
`the Internet. Packets are classified and marked, policed
`and shaped at the edge of the network in order to receive a
`particular per-hop forwarding behaviour on nodes along
`their path. Per-flow state does not need to be maintained in
`the interior network nodes,
`thus leading to increased
`scalability. This obviates the use of complex signalling
`protocols like RSVP. The inherent characteristics of
`MPLS make it a very good candidate for providing
`Differentiated Services. In this paper we describe various
`approaches which can be used to support differentiated
`services in MPLS environments.
`
`Keywords: Differentiated Services, Multi-Protocol Label
`Switching (MPLS), Asynchronous Transfer Mode (ATM),
`Internet Protocol (IP), Quality of Service (008).
`
`1. Introduction
`
`Over the last years a lot of research has been carried out
`and various standards have been ratified from IETF and
`
`ATM Forum addressing the integration of IP and ATM.
`Example" proposed solutions are Classical IP over ATM,
`Multi-Protocol over ATM (MPOA), LAN Emulation
`(LANE) and Next Hop Resolution Protocol
`(NHRP).
`Additionally, various complex signalling protocols, such
`as P-NNI, have been developed so that ATM networks can
`be deployed in the wide area.
`
`MPLS has been recently introduced as a new approach
`for integrating IP with ATM [1]. Also known as IP
`switching, IP over ATM, or Layer 3 Switching, it tries to
`provide the best of both IP and ATM worlds:
`the
`efficiency and simplicity of IP routing together with the
`high-speed switching of ATM by integrating the label-
`
`swapping paradigm with network-layer routing. Label—
`swapping is performed by associating labels with routes
`and using the label value to forward packets at Layer 2 of
`the 081 Reference Model (RM), including the procedure
`of determining the value of any replacement label. All IP
`routing functionality remains as is, but the forwarding is
`now performed at the ATM layer by means of switching.
`The complex ATM signalling protocols are not required
`and, more specifically, all the ATM protocols above the
`ATM Adaptation Layer (AAL) are completely removed.
`
`Although still in the “draft” process within the MPLS
`Working Group in the IETF, a great deal of research work
`has been done and several proposals have been submitted.
`Moreover, a current European ACTS project called IthACI
`(Internet and the ATM: Experiments and Enhancements
`for Convergence and Integration), aims to provide a
`number of important enhancements to MPLS: multicast,
`QoS provisioning, IP mobility and resource management —
`features which will make MPLS a viable technology. It is
`in the context of this project the research work described
`in this paper has been undertaken.
`
`Differentiated Services define a model for implementing
`scalable differentiation in the
`Internet. Packets
`are
`
`classified and marked, policed and shaped at the edge of
`the network in order to receive a particular per-hop
`forwarding behaviour on nodes along their path. Per-flow
`state does not need to be maintained in the interior
`
`network nodes, which leads to increased scalability.
`
`By closely examining the various characteristics of
`MPLS, one can see that it is a very good candidate for
`providing differentiated services. Traffic classification, its
`ability to reserve Class of Service (COS)
`through its
`lightweight signalling protocol LDP (Label Distribution
`Protocol) and the label aggregation feature are some of its
`useful properties.
`
`This paper attempts to show how Differentiated Services
`can be supported in MPLS networks. Section 2 briefly
`
`0-7803-5671-3/99/$10.00 © 1999 IEEE
`
`207
`
`
`
`
`
`
`
`
`
`

`

`
`
`presents the main features of the Differentiated Services
`model and its basic architecture as defined in the current
`
`Internet Drafts. Section 3 gives a short introduction to the
`MPLS
`architecture
`and
`lists
`some
`of
`its main
`
`for
`In section 4, various approaches
`characteristics.
`supporting Differentiated Services in MPLS networks are
`described and a solution is proposed and elaborated. An
`example is also used to explain analytically the proposed
`architecture. Finally, our conclusions and a summary are
`presented in section 5.
`
`2. Differentiated Services
`
`IETF
`the
`as proposed by
`services,
`Differentiated
`Differentiated Services Working Group, allow 1P traffic to
`be classified into a finite number of service classes that
`
`traffic
`receive different router treatment. For example,
`belonging to a higher priority and/or delay service class
`receives some form of preferential treatment over traffic
`classified into a
`lower
`service class. Differentiated
`
`to give explicit end-to-end
`services do not attempt
`guarantees. Instead, in congested network elements, traffic
`with a higher class of priority has a higher probability of
`getting through, or in case of delay priority, is scheduled
`for transmission before traffic that is less delay-sensitive
`
`[2].
`
`perform actual
`to
`required
`information
`The
`differentiation in the network elements is carried in the
`
`Type of Service (TOS) field of the IPv4 packet headers or
`the Traffic Class field of the IPv6 packet headers, referred
`to as the DS Field or Codepoint (DSCP) [3]. Thus, since
`the information required by the buffer management and
`scheduling mechanisms is carried within the packet,
`differentiated services do not require signalling protocols
`to control the mechanisms that are used to select different
`
`the
`treatment for the individual packets. Consequently,
`amount of state information, which is required to be
`maintained per node,
`is proportional
`to the number of
`service classes and not proportional
`to the number of
`application flows.
`
`At each differentiated services user/provider boundary,
`the service provided is defined by means of a Service
`Level Agreement
`(SLA). The SLA is
`a
`contract,
`established either statically or dynamically, that specifies
`the overall performance and features which can be
`expected by a customer. Because differentiated services
`are for unidirectional traffic only, each direction must be
`considered separately. The subset of the SLA which
`provides the technical specification of the service is
`referred to as the Service Level Specification (SLS).
`
`the Traffic
`is
`the SL8
`subset of
`A profound
`Conditioning Specification (TCS) which specifies detailed
`
`service parameters for each service level. These service
`parameters include service performance parameters (e.g.
`throughput, latency, drop probability) and traffic profiles
`corresponding to the requested service. Furthermore, the
`TCS may define the marking and shaping functions to be
`provided.
`
`2.1 Fundamental Functional Elements of the
`
`Differentiated Services Architecture
`
`The Differentiated Services architecture is composed of a
`number of functional elements, namely packet classifiers,
`traffic conditioners and per-hop forwarding behaviours
`(PHB) [4]. According to the basic differentiated services
`architecture definition, these elements are normally placed
`in ingress and egress boundary nodes of a differentiated
`services domain and in interior DS-compliant nodes.
`However, it is not necessary for all the elements to be
`present
`in all
`the DS—compliant nodes, something that
`strictly depends on the functionality that is required at
`each node [5].
`In the following paragraphs a short
`description for each of the elements is given and the
`various components
`that comprise them are briefly
`presented.
`Packet Classifiers
`
`Packet classification is a significant function which is
`normally required at the edge of the differentiated services
`network. Its goal is to provide identification of the packets
`belonging
`to
`a
`traffic
`stream that may
`receive
`differentiated services. Classification is done with packet
`classifiers, which select packets based on the content of
`packet headers according to well—defined rules determined
`by the Traffic Conditioning Agreement.
`
`the
`Two types of classifiers are currently defined:
`Behaviour Aggregate
`(BA)
`classifier, which selects
`packets based on the DS Codepoint only, and the Multi-
`Field (MF) classifier, which performs the selection based
`on the combination of one or more header fields.
`
`Traffic Conditioners
`
`form the most vital part of a
`Traffic conditioners
`differentiated services network. Their goal
`is to apply
`conditioning functions on the previously classified packets
`according to a predefined TCS. A traffic conditioner
`consists of one or more of the following components:
`
`° Meter
`
`A device which measures the temporal properties of a
`traffic stream selected by a classifier.
`° Marker
`
`A device that sets the DS Codepoint in a packet based
`on well defined rules.
`
`
`
`

`

`° Shaper
`
`A device that delays packets within a traffic stream to
`cause the stream to conform to some defined traffic
`
`profile.
`
`° Dropper/Policer
`
`A device that discards packets based on specified rules
`(e.g. when the traffic stream does not conform to its
`TCS).
`
`the
`of
`arrangement
`A typical
`components is illustrated in Figure 1.
`
`above mentioned
`
`
`
`Traffic
`Conditioner
`
`Figure 1 Typical arrangement of a Packet Classifier and a
`Traffic Conditioner [4].
`
`Per-Hop Forwarding Behaviours (PHB)
`A PHB is a description of the externally observable
`forwarding behaviour of a differentiated services node,
`applied to a collection of packets with the same DS
`Codepoint that are crossing a link in a particular direction
`(called differentiated services behaviour aggregate). Each
`service class is associated with a PHB. PHBs are defined
`in terms of behaviour characteristics relevant to service
`provisioning policies, and not
`in terms of particular
`implementations. PHBs may also be specified in terms of
`their resource priority relative to other PHBs, or in terms
`of their relative observable traffic characteristics. These
`PHBs are normally specified as group PHBs and are
`implemented by means of buffer management and packet
`scheduling mechanisms.
`To preserve partial backwards compatibility with known
`current uses of the IP Precedence field without sacrificing
`future flexibility, minimum requirements on a set of PHBs
`that are compatible with most of the deployed forwarding
`treatments selected by the IP Precedence field have been
`defined.
`In this context,
`the set of codepoints that are
`mapped to PHBs meeting these minimum requirements are
`known as Class Selector Codepoints. The minimum
`requirements for PHBs that these codepoints may map to
`are called the Class Selector PHB Requirements. PHBs
`selected by a Class Selector Codepoint should give
`
`is not
`packets a probability of timely forwarding that
`lower than that given to packets marked with a Class
`Selector codepoint of lower relative order,
`i.e. smaller
`numerical value, under reasonable operating conditions
`and traffic loads [3].
`
`Currently there are three proposed PHBs which are
`briefly described below.
`The Default
`(DE) PHB is the common, best-effort
`forwarding available in today’s Internet. IP packets marked
`for this service are sent into a network without adhering to
`any particular rules and the network will deliver as many
`of these packets as possible and as soon as possible but
`without any guarantees.
`The Expedited Forwarding (EF) PHB is a high priority
`behaviour typically used for network control traffic such
`as routing updates. The BF PHB is defined as a forwarding
`treatment for a particular differentiated services aggregate
`where the departure rate of the aggregate’s packets from
`any DS-compliant node must
`equal or
`exceed a
`configurable rate. The BF traffic should be allocated this
`rate independently of the intensity of any other traffic
`attempting to transit the node [6].
`Finally, the Assured Forwarding (AF) PHB is a means
`for a provider differentiated services domain to offer
`different levels of forwarding assurances for IP packets
`received from a customer differentiated services domain.
`Four AF classes are defined, where each AF class in each
`differentiated services node is allocated a certain amount
`of forwarding resources, e.g. buffer space and bandwidth.
`Within each AF class, IP packets are marked with one of
`three possible drop precedence values.
`In case of
`congestion, the drop precedence of a packet determines
`the relative importance of the packet within the AF class
`[7]-
`According to the basic architecture assumptions, traffic
`classifiers and conditioners can be located within DS-
`compliant nodes at the ingress and egress boundary of a
`differentiated services domain, although they can also be
`found in nodes within the interior of a differentiated
`services domain, or within a non-DS-compliant domain
`since this is not precluded. However, the exact location of
`the various components mainly depends on policy and
`management issues as specified by the network provider.
`Typically, end-users/customers will mark their packets
`to indicate the service they would like to receive. Then,
`the user traffic entering a differentiated services domain
`will be conditioned at the ingress node according to the
`predetermined SLS. Moreover, packets going from one
`domain to another may need to be re-marked, according to
`the SL8 established between the adjacent domains.
`
`209
`
`
`
`

`

`3. Multi-Protocol Label Switching
`
`MPLS is a technology that integrates the label-swapping
`paradigm with network-layer routing. Although the main
`focus of MPLS is IP-over-ATM networks,
`it
`is not
`restricted to these technologies. Its goal is to be multi-
`protocol at both Layer2 (e.g. ATM, Frame Relay) and
`Layer 3 (e.g. IP, IPX) of the OSI RM.
`
`link-level
`use
`(LSRs)
`Switching Routers
`Label
`forwarding to provide a simple and fast packet-forwarding
`capability. Label swapping is accomplished by associating
`fixed-length labels with routes and using the label value to
`forward packets, including the procedure of determining
`the value of any replacement
`label. Depending on the
`Layer 2 and Layer 3 technologies involved, different label
`encoding schemes can be used [8]. These are illustrated in
`Figure 2.
`
`
`
` shim
`
`header
`
`20
`
`a
`
`1
`
`8
`
`e.g. IPv6
`
`e.g. ATM
`
`Label/L2Header
`
`Label: Label Value
`Exp: Experimental Use
`
`S: Bottom of Stack
`TTL: Time to Live
`
`Figure 2 Three different label encoding schemes.
`
`When unlabelled packets need to traverse the same path
`between an ingress and an egress LSR (packets from an
`aggregate of one or more flows are said to belong to a
`stream) belonging to the same MPLS domain, a Label
`Switched Path (LSP) —— a LSP is similar to a unidirectional
`ATM Virtual Circuit (VC) — needs to be set-up. This will
`allow the packets to be forwarded from one MPLS node to
`another just by using the assigned label as an index to a
`forwarding table. The LSP set-up can be traffic, request,
`or topology-driven [1]. In the traffic-driven scheme the
`label assignment is triggered by the arrival of data at an
`LSR, whereas with the request-driven scheme the label is
`assigned in response to normal processing of request
`based control
`traffic.
`In the case of a topology-driven
`scheme the labels are pre-assigned according to existing
`routing protocol information.
`
`The packets are first classified at the ingress node. Then
`a mapping between IP packets and a LSP, must take place.
`This is done by providing a Forwarding Equivalence Class
`(FEC) Specification for each LSP. A FEC is specified as a
`set of one or more FEC elements, where each FEC
`element
`identifies a set of IP packets which may be
`mapped to the corresponding LSP. Currently, two types of
`FEC elements exist: the IP address prefix and the host
`address. In the former, the IP address is said to match the
`IP address prefix if and only if this address begins with
`this prefix. In the latter, there must be an exact match
`between the two addresses.
`
`In the MPLS domain, in order for a LSP to be set—up,
`labels must be negotiated, distributed, and their semantics
`defined through a protocol, namely the Label Distribution
`Protocol (LDP) [9]. LDP is the signalling protocol through
`which one LSR informs its peers of the label/FEC
`bindings it has made. An LSR may use a discovery
`mechanism to discover potential LDP peers. This is done
`by sending Hello Messages on the MPLS-interface using
`UDP/[P (User Datagram Protocol
`/ Internet Protocol).
`Moreover, LDP sessions between LSR peers
`are
`established on top of TCP/IP (Transmission Control
`Protocol / Internet Protocol) -based reliable connections.
`LDP messages are exchanged through LDP Protocol Data
`Units (PDUs). Each LDP PDU can carry at least one LDP
`message. It consists of an LDP header which is followed
`by one or more LDP messages. The information carried by
`LDP messages is encoded by using the TLV (Type-
`Length-Value) scheme. LDP messages are classified under
`four main categories: discovery, session, advertisement
`and notification messages.
`
`As the labelled packets are transmitted downstream
`along the LSP, each LSR examines the label and forwards
`the packets downstream to the next hop according to its
`locally significant Next Hop Label Forwarding Entry.
`
`MPLS
`
`
`
`Figure 3 A Multi-Protocol Label Switching network connected
`to two stub networks on either edge comprising two ingress, two
`core and two egress Label Switching Routers.
`
`210
`
`
`
`

`

`According to Rosen et (11., three conceptual information
`bases are needed to hold MPLS—related information [10]:
`
`0 Next Hop Label Forwarding Entry (NHLFE). The
`NHLFE is used when forwardng a labelled packet. It
`contains the outgoing interface (next hop), the data
`link encapsulation used for the transmitted packets,
`the outgoing label and the operation (add, replace, or
`remove) to perform on the label stack.
`
`'
`
`°
`
`Incoming Label Map (ILM). The ILM is a mapping
`from incoming labels to NHLFEs.
`It
`is used when
`forwarding packets that arrive as labelled packets.
`
`FEC-to-NHLFE Map (FTN). The FTN is a mapping
`from FECs to NHLFEs. It is used when forwarding
`packets that arrive unlabeled, but which are to be
`labelled before forwarding.
`
`In the next section we will be dealing with possible ways
`for providing support of differentiated services in MPLS
`networks. These will be further clarified by using an
`example to describe the operation of
`the proposed
`architecture.
`
`4. Differentiated Services and MPLS
`
`As it has already been mentioned in section 2, in order to
`support differentiated services in a network environment,
`three fundamental functional elements must be present:
`packet
`classifiers,
`traffic
`conditioners
`and
`per-hop
`behaviours. We have already discussed how and where
`these elements should be placed in order for the network
`to be capable of providing differentiated services. The
`question that arises is how these components will be
`efficiently utilised in
`an MPLS network so
`that
`differentiated services are supported.
`
`in MPLS
`support of differentiated services
`The
`environments requires either signalling support for the
`association of the desired category with the label, or each
`packet belonging to a
`stream needs
`to carry the
`information of the desired service category (behaviour
`
`aggregate).
`
`In this paper we deal with ATM LSRs and hence the
`packets of a labelled IP stream are actually transported by
`ATM cells. This poses the question of whether certain
`peculiarities of ATM should be taken into account or
`whether a generic approach, independent of the link layer
`technology, should be followed. If it had not been ATM at
`Layer 2, it would be possible to include a “shim” header in
`the packets as mentioned earlier in this paper. However,
`with ATM, a “shim” header cannot be used because this
`would involve doing segmentation and re-assembly at
`
`each ATM-LSR in order to read the DSCP field which is
`
`the
`the ATM switching “philosophy”. Hence,
`against
`DSCP in the 1P header is not accessible by the ATM
`hardware responsible for the forwarding. Therefore, two
`alternative solutions may be considered. Either to have
`some part of the ATM cell header mapped to the DSCP, or
`to use LDP.
`
`In the first approach, the most likely solution is to use
`the VP1 (Virtual Path Identifier) and part of the VCI
`(Virtual Channel Identifier) of the ATM cell header as the
`label, and the remaining eight least significant bits of the
`VCI be used to map the DSCP [11]. Then all that
`is
`needed is the existence of a functional component in the
`interior DS-compliant ATM LSRs
`to perform the
`appropriate traffic management mechanisms on the cells
`by interpreting the DSCP correctly, with respect to the
`PHB.
`
`In the second approach, which is more likely for future
`deployment, the DSCP is mapped to an LSP at the ingress
`of the MPLS domain. This means that for each DSCP
`
`value/PHB a separate LSP will be established for the same
`egress LSR. So, if there are n Classes and m egress LSRs,
`n - m LSPs need to be set-up, n labels for each of the m
`FECs. The packets belonging to streams with the same
`DSCP and FEC will be forwarded on the same LSP. In
`
`the label
`other words,
`aggregate selector.
`
`is regarded as
`
`the behaviour
`
`Furthermore, two LSPs are allowed to be merged into
`one LSP only if the packets they carry belong to the same
`Behaviour Aggregate or, even better, if they have the same
`DSCP. The decision for the merge will be taken at the
`merging LSR based upon the DSCP entry it has in its
`modified NHLFE table. Given that the two DSCP values
`
`are identical and provided that the necessary resources are
`available for the rest of the common LSP, the two LSPs
`
`can be merged. To check whether there are available
`resources or not is the role of an admission control module
`
`resident in each LSR. A request message needs to be sent
`to all
`following hops
`to check for
`the necessary
`bandwidth.
`If this can be eventually granted,
`then the
`merging process may proceed.
`
`Additionally, there must be an MPLS—to-ATM mapping
`element in every MPLS DS-compliant node which will
`perform the mapping between the Behaviour Aggregate
`and the ATM traffic class and traffic parameters.
`An issue that would need more discussion is what
`
`happens when the MPLS network is topology-driven.
`Should there be n - m already established LSPs thus
`forming a kind of overlay network on top of the physical
`network, or should the LSPs be set—up on demand, which
`conserves resources in case some of the standard service
`
`
`
`211
`
`
`
`

`

`
`
`Figure 4 Example of a label table of an FTN without extension
`for MPLS support
`(a.b.c.d and x.y.w.z correspond to IP
`addresses).
`
`VPIom v
`
`FEC
`Element
`
`
`
`
`
`
`
`
`
`Fig