MPLS Working Group
`Internet Draft
`
`Document: draft-vaananen-mpls-svc-
`diff-framework-00.txt
`Expiration Date: September 2000
`
`Muckai Girish
`SBC Technology Resources, Inc.
`Rayadurgam Ravikanth
`Nokia Research Center
`
`Pasi Vaananen
`Nokia Telecommunications
`March 2000
`
`A Framework for Service Differentiation in MPLS Networks
`
`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.
`
`1. Abstract
`
` It has been recognized that the success of the MPLS depends on the
` ability to better support the multiservice traffic integration with
` some levels of service guarantees, which are not feasible to
` implement with the current destination prefix only based packet
` forwarding paradigms.
`
` The efficient support for these services throughout the network is
` expected to be possible using label based forwarding paradigm in the
` network. Through the use of either RSVP based or LDP/CR-LDP based
` signaling, MPLS can also provide certain QoS guarantees using the
` LSPs.
`
` The goal of this document is to define a framework for service
` differentiation in MPLS networks. We discuss a set of services that
` have been identified so far for IP, and describe the traffic
` management mechanisms in various network elements that are needed
` for enabling the implementation of these more advanced services in
` MPLS networks.
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt
`
`1
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
`March 2000
`
`Cloudflare - Exhibit 1018, page 1
`
`

`

` This document describes the mechanisms and their applications with
` the intent to approach the level of the traffic management
` capabilities that are currently available in hybrid router/ATM or
` frame relay networks using the MPLS. This document concentrates on
` the issues from the public network operators point of view, although
` most of the discussion applies as well in the local network
` environments.
`
` Concepts and mechanisms described in this document are based on the
` previous work done in various working groups of IETF and other
` standardization bodies. Applicable concepts and terminology from
` previous work has been used as much as possible. This document
` concentrates on the MPLS specific issues, number of related
` mechanisms and concepts are only briefly presented for the sake of
` completeness, and the other related work is referred, where
` applicable.
`
`2. Introduction
`
` The ability of IP networks to support service level differentiation
` and traffic engineering is becoming very important. This area has
` been addressed in various working groups of IETF (e.g. INTSERV,
` RSVP, ISSLL, RAP, DIFFSERV, IPPM, QOSR, TEWG), IRTF (E2E), ATM Forum
` (TM), Frame Relay Forum, ITU-T, and various other organizations and
` user consortiums.
`
` We build on the ideas and previous work done in these working
` groups, and try to construct a coherent set of capabilities around
` the label based packet forwarding technology discussed in the MPLS
` working group of IETF, as described in the MPLS framework document
` [Callon99] and the MPLS architecture document [Rosen99a].
`
` The starting point is to identify a set of possible services that
` are implementable using current IP standards which will also cater
` to the various needs of customers and service providers in IP
` networking. We then move on to the focus of this draft which is to
` describe the set of traffic management functions and elements both
` in the control plane and the data plane that are needed for service
` differentiation. The TM functions done by the various network
` elements such as hosts, CPE devices, edge routers and core routers
` are then presented. Finally, the TM functions that are mandatory and
` optional for providing the services are listed for each of the
` network elements.
`
` The main purpose of this draft is to explicitly specify how the
` various technologies fit together in creating a multi-service IP
` network. In a sense this draft describes, in generality, the kind of
` functional blocks, in addition to the standard protocols, that may
` need to be present in MPLS capable nodes. In presenting a
` consolidated view of how service differentiation may be achieved,
` this document points to how varying technologies developed in
` possibly different groups in IETF are tied together. Further, such a
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt 2
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
` March 2000
`
`Cloudflare - Exhibit 1018, page 2
`
`

`

` view also strives to identify work items which may have implications
` in various IETF groups. It should be emphasized, however, that this
` draft only identifies rather generic functional blocks that would be
` needed, and it is fully recognized that actual implementations may
` vary depending on the functions that the node aims to support. In
` the light of this, the objective of this paper is simply
` informational.
`
` The document tries to take an evolutionary rather than revolutionary
` approach. We feel that the deployment of the technologies presented
` can be started on a small scale, and without changes to the host
` communication and application protocols, while this framework
` attempts to be flexible enough to be able to accommodate such
` changes when the technology matures and the incremental deployment
` is determined to be feasible and necessary.
`
` We hope that MPLS will evolve towards supporting the capabilities
` outlined in this document, but do realize that much more detailed
` discussions, research and specification work needs to be done before
` the complete set of "wishes" can be accomplished.
`
`3. Service Differentiation
`
` The advanced services requiring the use of the traffic management
` mechanisms can be broadly divided into two categories on the basis
` of (i) the level of assurance on service guarantees that can be
` achieved and (ii) the granularity of guarantees (simple to complex)
` that is provided. This division is made here to support the
` discussion of the related traffic management issues.
`
` MPLS will be used to provide the services that are being defined in
` the IETF, such as those based on Differentiated Services and
` Integrated Services. MPLS label switched paths can be used to
` construct aggregate paths, with the result that less state needs to
` be maintained.
`
` This document primarily deals with the components of traffic
` management that will be necessary to support the various services,
` and the issues discussed here are generic enough to apply to the
` various service categories that MPLS will need to support. The basic
` service categories differ from each other on basis of the end-to-end
` assurance with respect to the certain performance metrics, such as
` packet loss, delay, and delay variation these services expect from
` the network.
`
` The implementation of the more advanced service categories than pure
` best-effort affects the implementation of both data and control
` plane functionality in intermediate nodes. Some of the affected
` datapath functions are congestion control, queuing, packet
` classification, policing, scheduling, shaping and service mapping to
` interfaces. The associated control plane functions that are affected
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt 3
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
` March 2000
`
` include signaling protocols, accounting, policy control and routing
`
`Cloudflare - Exhibit 1018, page 3
`
`

`

` protocols.
`
` As a starting point we describe a set of services that can be
` supported in IP networks, using already defined mechanisms such as
` IntServ, DiffServ, congestion control etc. In later sections we will
` define the set of traffic management mechanisms that will be
` necessary/useful to support this service differentiation.
`
`3.1 Differentiated and Integrated Services
`
`3.1.1 Differentiated services
`
` Packet forwarding and queuing treatments for differentiated services
` are specified in the IETF DiffServ working group. The DiffServ
` working group does not standardize services, instead, it
` standardizes a small number of packet treatment mechanisms or PHBs
` (Per Hop Behaviors). End-to-end services can be constructed from
` these PHBs with appropriate traffic conditioning actions. The
` differentiated services architecture is documented in [RFC2475],
` while the differentiated services framework is documented in
` [Bernet99a]. The expedited forwarding (EF) PHB is proposed in
` [RFC2598], whereas the assured forwarding (AF) PHB group is
` presented in [RFC2597].
`
`3.1.1.1 Differentiated services in MPLS environments
`
` Generally no per LSP state need to be maintained in the network
` elements and the goal is to support a small, fixed number of service
` categories. It is expected that the state maintenance for the scoped
` services (defined later in this section) can be done in behavioral
` aggregate basis, although the parameters have to be specified on
` per-LSP basis, as well as admission control needs to be done for
` individual LSPs. Measurement based admission control may help in
` achievement of better utilization of the resources (subject to
` verification by simulation). Per stream attributes distributed using
` the label distribution mechanisms can include the differentiated
` service categories associated with the LSP. The mappings from
` Differentiated Service classes to MPLS paths are specified in
` [Francois99]. The support of differentiated services in MPLS
` environments requires signaling support for the association of the
` desired category with the label, or alternatively each packet needs
` to carry the information of the desired service category.
`
` MPLS allows the allocation of the bandwidth for the differential
` services in conjunction with other services in a controlled manner.
` This allows the network operator to allocate the available bandwidth
` between the differentiated service category and other categories, on
` a per LSP basis, providing good basic mechanisms required by the
` efficient network traffic engineering.
`
`3.1.2 Integrated Services
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt 4
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
` March 2000
`
` Several scalability issues related to RSVP signaling have been
`
`Cloudflare - Exhibit 1018, page 4
`
`

`

` identified that suggest that the support of the Integrated services
` in the backbone networks is not feasible at reasonable cost.
` Therefore, there are efforts ongoing in IETF for mapping these
` services to simpler mechanisms, i.e. DiffServ and/or MPLS on the
` backbone level (see [Bernet99b]). The model that is seen as enabling
` the provisioning of these services on the backbone level are based
` on the running full RSVP/IntServ in the stub networks and mapping
` the packets to simpler mechanisms in the border nodes of the public
` IP network.
`
` Services are specified in IntServ working group, while associated
` signaling mechanisms are specified in the RSVP working group.
` DiffServ and ISSLL working group are currently working on the
` service mappings, with most of the data plane work completed,
` biggest open issue is currently how to do admission control for the
` DiffServ capable backbone network.
`
`3.1.3 Scoped (and guaranteed) services
`
` These services provide hard guarantees that are explicitly specified
` for different granularities, and specific topological scopes, such
` as from network boundary to network boundary or end-to-end.
` Services are further specified using different, service specific set
` of parameters, such as bandwidth and/or delay, determined by the
` requested service class. The scoped / guaranteed services may be
` based on the contractual guarantees or user-network signaling, such
` as RSVP. Signaling protocol to disseminate associated service
` parameter information is required inside network.
`
` In IETF, guaranteed services have been specified by INTSERV and MPLS
` working groups. Integrated service framework is described in
` [RFC1633]. There are currently two services that have been defined
` by INTSERV; controlled load [RFC2211] and guaranteed service
` [RFC2212]. These services should be supported in MPLS environments.
`
` Service parameter mappings to different link layers specified in the
` ISSLL working groups should be applicable to MPLS, when augmented
` with the label encapsulation procedures specified in the MPLS WG.
`
`3.2 A Framework for Services
`
` We specify a framework for services here and all of the proposed
` services can be specified with appropriate attributes of this
` framework. The framework is described by two components: the traffic
` contract and the service objectives. The traffic contract describes
` the packet arrival patterns that the customer has contractually
` agreed to adhere to which is enforced by the service provider. The
` service objectives can be described by a combination of throughput,
` loss, delay and jitter parameters. Note that all parameters are not
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt 5
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
` March 2000
`
` necessarily specified for all the services that are described in the
` ensuing sections.
`
`Cloudflare - Exhibit 1018, page 5
`
`

`

`3.3 Service Scoping
`
` The level of assurance that can be provided using different
` mechanisms depends on the scope of the network region where the
` service is provided. Smallest useful service scope is likely a
` single subnet, and the largest scope is the whole Internet. Clearly,
` as the scope is extended, the provisioning of the service and
` achievable service level guarantees gets more complicated. Some
` examples of the different service scopes are:
`
` - Internet
` - Autonomous System
` - Routing domain
` - Within subnetwork
` - Anywhere --> destination network
` - Source Network --> destination network
` - Boundary router --> boundary router
` - Source host --> destination host
`
` The above list provides only some possibilities, and the scoping is
` clearly not subject to standardization, and will be performed as a
` network / service engineering task by the network operators.
`
` There have been proposals for very high assurance levels, that
` generally require communication of some attributes describing the
` traffic characteristics, and also definition of some quite limited
` scope (such as between two specific operator boundary router
` interfaces). The attributes required by the network for provisioning
` such services can be statically allocated (i.e. configured in NE:s)
` or dynamically requested and allocated using some form of signaling
` mechanism, such as RSVP and/or MPLS signaling.
`
` It should be noted that even in situations where the exact traffic
` characteristics and scope are known only at very coarse level (such
` as maximum profile of traffic in behavioral aggregate and inside ISP
` network), operators may want to provision certain service quality
` level for traffic on certain behavioral aggregate, as agreed to in
` service level agreements. This practice is analogous to SLAs in
` which some ISPs currently offer some delay bounds and loss ratios
` for best effort traffic. However the purpose of service
` differentiation is to provide the ability to independently specify
` different parameters for different service categories. Such
` guarantees need to be addressed using network engineering practices,
` together with monitoring and traffic engineering.
`
` Below, we describe some examples of IP services that can be
` constructed using available IP technologies.
`
`3.4 Examples of IP services
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt 6
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
` March 2000
`
`3.4.1 Best effort service
`
` Best effort service is the prominent service used in the current
`
`Cloudflare - Exhibit 1018, page 6
`
`

`

` Internet. The characteristics of the service can be deduced from the
` name, as there is generally no guarantees for any of the associated
` performance metrics. Best effort service is an unscoped service,
` since it is not specified with respect to any particular
` destination.
`
`3.4.2 Enhanced best effort service (EBE)
`
` This service is similar to the current best effort service, but with
` higher service quality perceived by the end-user, regardless of the
` applications. Enhanced best effort service can be realized without
` using any specific signaling protocols inside the network. It
` differs from "plain old best effort" because of the use of more
` advanced congestion control mechanisms/traffic engineering. The
` purpose is to provide more controlled and more fair behavior during
` congestion periods.
`
`3.4.2.1 EBE with RED
`
` One of the proposed enhancements required for the better end-to-end
` operation over "traditional" best effort service include passive
` congestion control mechanisms based on packet drop policies, such as
` random early detection (RED) [Floyd93], [RFC2309], as well as fair
` and enhanced queuing schemes. The use of RED does not require the
` maintenance of per-flow state in the network elements, and still can
` provide better goodput for TCP-like, adaptive applications as well
` as somewhat improved fairness.
`
`3.4.2.2 EBE with ECN
`
` In addition to passive congestion control mechanisms, active
` congestion control mechanisms, such as Explicit Congestion
` Notification [RFC2481]. ECN is based on explicit congestion feedback
` from network elements to transport protocol (TCP) in hosts.
` Extensions for supporting ECN in MPLS networks are specified in
` [Ramakr99].
`
`3.4.2.3 EBE with Traffic Engineering
`
` The use of label based forwarding paradigm (MPLS) adds capabilities
` for network operator traffic engineering, such as better ways to
` control the path selection for the traffic. This can significantly
` improve the performance seen by the best effort traffic.
`
`3.4.3 Bounded loss service (BLS)
`
` This service guarantees the delivery with a certain bounded loss for
` traffic that conforms to a specified rate. While bounded loss simply
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt 7
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
` March 2000
`
` refers to the service objective (as defined above), this really
` represents three different services when the traffic contract
` enforcement is also considered.
`
` - Three color marker based service [RFC 2697, RFC 2698]: Here the
`
`Cloudflare - Exhibit 1018, page 7
`
`

`

` customerÃs traffic is marked with one of three colors (using a dual
` token bucket scheme) and the packets marked with each color are
` guaranteed a certain maximum loss probability. Practically this
` could mean that packets conforming to committed rate specification
` have better delivery guarantee than those that exceed it.
`
` - Frame relay service: Here the packets are once again given loss
` probability bounds depending on whether the average (based on some
` sliding window or jumping window scheme) arrival rate conforms to
` agreed upon thresholds.
`
` - Customer marking based service: Here the customer might mark
` packets with different colors (representing different loss
` guarantees) and as long as the operator can verify (and enforce) the
` conformance of the markings to the traffic contract, these loss
` rates are guaranteed.
`
`3.4.4 Virtual leased line service
`
` Virtual leased line service is specified to provide service
` resembling the service experienced by the leased, point-to-point
` line. VLL service does not have explicit delay or jitter guarantees,
` but both are expected to be "low". To work as desired, VLL service
` must be scoped, and strictly policed (all non-compliant traffic is
` discarded) on the edges of the network. The only service parameter
` associated with the virtual leased line service is peak bandwidth.
` An example of supporting virtual leased line service is described in
` appendix A of [RFC2598] with the EF PHB and appropriate traffic
` conditioning actions.
`
`3.4.5 Guaranteed service
`
` Guaranteed service provides deterministic guarantees for both
` bandwidth, and upper bound on per packet delay. Guaranteed service
` is best suited for applications that require absolute delay bounds,
` and cannot adapt to network conditions. Guaranteed service is
` defined in [RFC2212].
`
`3.4.6 Controlled load service
`
` Controlled load service provides the service of the network that
` closely approximates the service user would receive from unloaded
` network. Controlled load service guarantees that bandwidth is
` allocated to the user, but does not guarantee the maximum delay
` bound experienced by packets. Controlled load service is defined in
` [RFC2211].
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt 8
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
` March 2000
`
`3.5 Mapping user traffic to service categories
`
` From the end-user/application perspective, the traffic can be
` classified on basis of the various performance parameters,
` including:
` - Loss sensitivity (loss tolerant = adaptive, loss sensitive = not
`
`Cloudflare - Exhibit 1018, page 8
`
`

`

` adaptive)
` - Delay sensitivity
` - Desired assurance of the service level
`
` In addition to the above, the level of service guarantees that can
` be expected from the network is dependent on the scope of the
` traffic (i.e. are endpoints of the connection known beforehand, and
` resources provisioned in advance for the stated scope using either
` signaling or provisioning). The end-to-end service should be
` dependent on the combination of the above factors, and the mapping
` to underlying mechanisms should be based on the user expectations.
` Note that the loss and delay sensitivity are not binary parameters,
` various levels of service with respect to these parameters are
` expected by different applications.
`
` Figure 3.2.4.-1 Example classification of the user traffic
`
` In addition to the scope of the service, one important aspect that
` further characterizes the type of service desired by the application
` is whether application is able to measure and adjust to network
` capabilities (i.e. adaptive applications), or if it requires some
` minimum level of performance with respect to loss, delay, or other
` metrics (i.e. non-adaptive applications). Adaptive applications use
` feedback loop to achieve the adaptation between traffic source and
` sink, while non-adaptive applications do not use feedback loop.
` Typical example of adaptive traffic is TCP traffic, while UDP
` traffic (e.g. voice over IP mapped on UDP/RTP) is typically non-
` adaptive.
`
` Using the information provided by the users and applications, the
` end-user traffic can be classified as depicted in the figure 3.2.4.-
` 1. The required traffic management mechanisms for the support of the
` fulfillment of the stated expectations are described in sections 8
` and 9.
`
` Figure 3.2.4.-2 Example mapping from the classes to IntServ/DiffServ
` categories
`
` Figure 3.2.4.-2 depicts the example of how the traffic can be
` classified to different service categories. Note that the other
` mappings are also possible, and the actual mapping will be
` controlled by the network operator service class configuration
` and/or router that performs the packet classification process.
` However, the above picture is useful in understanding the congestion
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt 9
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
` March 2000
`
` control and policing actions that need to be applied on each traffic
` class.
`
` Since the DiffServ working group is not defining the services, it is
` important that the implementation is flexible with respect to
` configuration of the policing actions, control mechanisms associated
` with different classes and mapping and scheduling mechanisms.
`
`Cloudflare - Exhibit 1018, page 9
`
`

`

` Official work to specify standard mappings have not been started in
` IETF, but there is expectation that most (if not all) services can
` be supported by the DiffServ categories specified so far, when
` augmented by the appropriate signaling and/or traffic conditioning
` mechanisms.
`
`3.5.1 Summary of service scoping
`
` Table 3.2.4. presents the summary of the scoping requirements for
` the different service types, in the order of the level of guarantee
` expected. Generally, the more guarantees or assurances of the
` service characteristics are specified, more tight scoping is
` required for achieving the service level objectives. Note that the
` scoping here generally means that service provisioning needs to know
` both the origination and end points (or set of those) to be able to
` provision service.
`
` Service: Scoped: Unscoped:
` Best Effort - X - DE
` Control traffic - X - PR 6,7
` [Precedence (X) - PR ? X - PR ?] ***
` [Assured forwarding (X) - AF1,2 X - AF 3,4]
` Controlled Load X - AF1 -
` Virtual leased line X - EF (/ AF1?) -
` Guaranteed X - EF -
`
` where, - = Not applicable, X=default, (X) = optional
`
` ***) The precedence classes have been originally defined to be
` unscoped, but overloading of codepoints by AF service may change
` this for certain classes.
`
` All scoped services require the communication of the associated
` service parameters (see service definitions above) across the
` network elements in the path, as well as policing in the edges.
` Unscoped services require either no policy enforcement or policy
` enforcement on the basis of service level agreements (SLA) on border
` network elements.
`
`3.6 Service level agreements
`
` Service level agreements are the contracts between users and network
` operators (or between network operators) that define the service(s)
` provided, pricing models and tariffs, service class parameters,
` service scoping, penalties, etc. Service level agreements ultimately
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt 10
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
` March 2000
`
` completely define the service characteristics and finally yield to
` requirements for the operator and customer equipment related to
` service provisioning and enforcement. Since the service level
` agreements are operator specific, and not subject to standardization
` (at least not in the IETF), it is important that the network
` elements and supporting management and provisioning systems provide
` a rich set of highly configurable mechanisms to allow operators to
` build the desired service. Mechanisms that are involved in the
`
`Cloudflare - Exhibit 1018, page 10
`
`

`

` construction of service are related to:
` - Service provisioning, management and monitoring
` - Service contract enforcement
` - Service monitoring
` - Accounting and billing
`
` All of the above high level requirements result in the need for
` specific mechanisms and protocols that need to be supported in
` network elements. These mechanisms are discussed in more detail in
` chapter 5 for data plane mechanisms, and chapter 4 for control plane
` mechanisms. Service level agreements and traffic conditioning
` agreements for the DiffServ networks are discussed in DiffServ
` framework document, [Bernet99a].
`
`3.7 Virtual private networks
`
` Virtual private networks are services designed to provide traffic
` isolation (in the sense of the overlapping / private address spaces
` and/or isolation of the traffic to own virtual connections) and/or
` service level guarantees for the traffic controlled by the VPN
` customer.
`
` VPNs can use any of the connection paradigms provided by the IP
` network or alternatively by virtual connection type network
` architectures, such as the mechanisms provided by MPLS. VPNs
` generally do not impose additional requirements for the traffic
` management functions, except those that are already described in
` this document, but can be considered specific type of application of
` these mechanisms. The mechanisms described in this document allow
` (but are not limited to) the construction of the following VPN
` types:
`
` Tunneled best effort, unscoped: this type of VPNs are "traditional"
` VPNs in the sense that the network service provider need not to be
` aware of the VPN at all. The disadvantage is that no service level
` guarantees can be provisioned for the VPN.
`
` Tunneled differentiated, unscoped: this type of VPN can also be
` constructed without specific knowledge by the service provider about
` VPN use per se. VPN customers can use any of the differentiated
` service categories which are covered by the SLA/TCA between the user
` and the provider. Marking can be performed by customer by marking
` the DSCP field of the VPN packets, or alternatively by the service
` provider by applying suitable traffic filter in the border nodes to
`
`M. Girish et al. draft-vaananen-mpls-svc-diff-framework-00.txt 11
`
`Internet Draft A Framework for Service Differentiation in MPLS Networks
` March 2000
`
` allow differentiated treatment. In the latter case, the filter
` parameters need to be covered by the SLA.
`
` Tunneled differentiated, scoped: this type of VPN is otherwise same
` as tunneled differentiated unscoped, except that the VPN service
` endpoints are part of the SLA in addition to the parameters
` specified above.
`
` Virtual circuit tunneled: these VPNs are always scoped, as the
`
`Cloudflare - Exhibit 1018, page 11
`
`

`

` tunnel endpoints need to be specified in every case. Tunnels can be
` associated with any of the supported traffic class using a desired
` set of parameters. Traffic can be associated with the tunnel either
` by customer (requires tunneling to CPE equipment) or by operator by
` applying traffic filter. Tunnel topologies supported can include
` point-to-point and multipoint to point. Virtual circuit tunneled VPN
` is conceptually similar to the traditional Frame Relay or ATM VPN
` service, with the exception that the control protocols and the
` traffic classes are specified in IETF.
`
` Virtual Private Routed Networks (VPRNs): this is a specific case of
` the VPN mainly applicable to large VPN applications. The difference
` between this and other approaches is that the tunnels and the
` associated topology is constrained and built automatically by the
` network operator, using a specific VPN identifier as an additional
` attribute for scoping and distributing topology information of the
` VPRN service. Tunnels are used to isolate traffic from different
` VPRNs, while the connectivity information is distributed typically
` as an attribute to routing information distribution. VPRN service
` effectively builds routing tables in intermediate nodes for each
` VPRN, and uses the tunnel identifies to determine the context (i.e.
` to select the appropriate forwarding table) of the packets belonging
` to different VPRNs.
`
` The virtual