Declaration of Rachel J. Wafters on Authentication of Publication
`
`I, Rachel J. Wafters, am a librarian, and the Director of Wisconsin TechSearch
`
`("WTS"), located at 728 State Street, Madison, Wisconsin, 53706. WTS is an
`
`interlibrary loan department at the University of Wisconsin-Madison. I have worked as
`
`a librarian at the University of Wisconsin library system since 1998. I have been
`
`employed at WTS since 2002, first as a librarian and, beginning in 2011, as the Director.
`
`Through the course of my employment, I have become well informed about the
`
`operations of the University of Wisconsin library system, which follows standard library
`
`practices.
`
`This Declaration relates to the dates of receipt and availability of the following:
`
`Andrikopoulos, I., Pavlou, G. (1999) Supporting differentiated
`services in MPLS networks. IWQoS '997 1999 Seventh
`International Workshop on Quality of Service, pp.207-215
`
`Standard operating procedures for materials at the University of Wisconsin-
`
`Madison Libraries. When a volume was received by the Library, it would be checked
`
`in, added to library holdings records, and made available to readers as soon after its
`
`arrival as possible. The procedure normally took a few days or at most 2 to 3 weeks.
`
`Exhibit A to this Declaration is true and accurate copy of the front matter of the
`
`IWQoS '99: 1999 Seventh International Workshop on Quality of Service (1999)
`
`publication, which includes a stamp on the verso page showing that this book is the
`
`property of the Wendt Library at the University of Wisconsin-Madison. Exhibit A also
`
`1
`
`Cloudflare - Exhibit 1007, page 1
`
`Cloudflare - Exhibit 1007, page 1
`
`

`

`Declaration of Rachel J. Wafters on Authentication of Publication
`
`includes an excerpt of pages 207 to 215 of that volume, showing the article entitled
`
`Supporting differentiated services in MPLS networks (1999).
`
`Attached as Exhibit B is the cataloging system record of the University of
`
`Wisconsin-Madison Libraries for its copy of the IWQoS '99: 1999 Seventh International
`
`Workshop on Quality of Service (1999) publication. As shown in the "Receiving date"
`
`field of this Exhibit, the University of Wisconsin-Madison Libraries owned this book
`
`and had it cataloged in the system as of August 12, 1999.
`
`Members of the interested public could locate the IWQoS '99: 1999 Seventh
`
`International Workshop on Quality of Service (1999) publication after it was cataloged
`
`by searching the public library catalog or requesting a search through WTS. The search
`
`could be done by title, author, and/or subject key words. Members of the interested
`
`public could access the publication by locating it on the library's shelves or requesting it
`
`from WTS.
`
`I declare that all statements made herein of my own knowledge are true and that
`
`all statements made on information and belief are believed to be true; and further that
`
`these statements were made with the knowledge that willful false statements and the like
`
`so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18
`
`of the United States Code.
`
`Date: July 28, 2020
`
`RacheJ2l W atters
`
`2
`
`Cloudflare - Exhibit 1007, page 2
`
`Cloudflare - Exhibit 1007, page 2
`
`

`

`Declaration of Rachel J. Wafters on Authentication of Publication
`
`Wisconsin TechSearch
`Memorial Library
`728 State Street
`Madison, Wisconsin 53706
`
`Director
`
`3
`
`Cloudflare - Exhibit 1007, page 3
`
`Cloudflare - Exhibit 1007, page 3
`
`

`

`1999 Seventh
`International Workshop
`on Quality of Service
`
`IWQoS '99
`
`O
`
`London, England
`May 31 - June 4, 1999
`
`IEEE
`
`E,
`!..01,1,11,41,
`SO.:Tr r
`
`Cloudflare - Exhibit 1007, program cover
`
`Cloudflare - Exhibit 1007, program cover
`
`

`

`1999 Seventh
`International Workshop
`on Quality of Service
`
`IWQoS '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
`
`Cloudfare - Exhibit 1007, page i
`
`Cloudfare - Exhibit 1007, page i
`
`

`

`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 U.S. 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-IEEE (1-800-678-4333)
`1-732-981-0060
`1-732-981-1393
`1-732-981-9667 (FAX)
`email: customer.service@ieee.org
`
`Kurt -K. Wendt Libra-FY—
`University of VVisconsin-Madisoll
`215 N. Rar;dal! Avenue
`Madison, Wi 53706-168&
`
`Cloudfare - Exhibit 1007, page ii
`
`Cloudfare - Exhibit 1007, page ii
`
`

`

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

`

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

`

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

`

`Supporting Differentiated Services in MPLS Networks
`
`Ilias Andrikopoulos and George Pavlou
`
`Centre for Communication Systems Research (CCSR)
`University of Surrey
`Guildford, Surrey, GU2 5XH, UK
`Email: {I.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 QoS 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 (QoS).
`
`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 OSI 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/99410.00 © 1999 IEEE
`
`207
`
`Cloudflare - Exhibit 1007, page 207
`
`Cloudflare - Exhibit 1007, page 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
`characteristics. In section 4, various approaches for
`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
`Differentiated services, as proposed by
`Differentiated Services Working Group, allow IP traffic to
`be classified into a finite number of service classes that
`receive different router treatment. For example, traffic
`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
`services do not attempt to give explicit end-to-end
`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].
`actual
`perform
`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
`treatment for the individual packets. Consequently, the
`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
`is a contract,
`Level Agreement (SLA). The SLA
`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
`the SLS
`is
`A profound subset of
`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
`receive
`that may
`belonging
`to a
`traffic stream
`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.
`Two types of classifiers are currently defined: the
`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
`Traffic conditioners form the most vital part of a
`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.
`
`208
`Cloudflare - Exhibit 1007, page 208
`
`Cloudflare - Exhibit 1007, page 208
`
`

`

`• 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 above mentioned
`typical arrangement of
`A
`components is illustrated in Figure 1.
`
`F
`
`Incoming
`Packets
`•
`r
`ClassMer
`
`1=>
`
`i
`
`Shaper/
`Dropper
`
`Outgoing
`Packets
`
`•
`
`Meter
`
`Marker
`
`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
`
`packets a probability of timely forwarding that is not
`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 EF 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 EF 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 SLS established between the adjacent domains.
`
`209
`
`Cloudflare - Exhibit 1007, page 209
`
`Cloudflare - Exhibit 1007, page 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 Layer 2 (e.g. ATM, Frame Relay) and
`Layer 3 (e.g. IP, IPX) of the OSI RM.
`link-level
`Label Switching Routers
`(LSRs) use
`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.
`
`L2 Header
`
`Label
`
`L3 Header
`
`shim
`header
`
`e.g. IPv6
`
`Label
`20
`L2 Header
`
`Exp
`3
`Label/IP Header
`
`TTL
`8
`L3 Data
`
`e.g. ATM
`
`Label / 1.2 Header
`
`L3 Data
`
`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/IP (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
`Network
`
`Stub
`Network
`
`Stub
`Network
`
`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
`Cloudflare - Exhibit 1007, page 210
`
`Cloudflare - Exhibit 1007, page 210
`
`

`

`According to Rosen et al., three conceptual information
`bases are needed to hold MPLS-related information [10]:
`
`• Next Hop Label Forwarding Entry (NHLFE). The
`NHLFE is used when forwarding 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
`that
`in an MPLS network so
`efficiently utilised
`differentiated services are supported.
`in MPLS
`The support of differentiated services
`environments requires either signalling support for the
`association of the desired category with the label, or each
`the
`to a stream needs to carry
`packet belonging
`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
`against the ATM switching "philosophy". Hence, the
`DSCP in the IP 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 VPI (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
`the
`to perform
`interior DS-compliant ATM LSRs
`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
`other words, the label is regarded as the behaviour
`aggregate selector.
`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