Skip to main content

motivation-and-applicability.body

This section describes use cases from which the requirements can be

derived.

As described in [RFC4655], a PCE can be used to compute MPLS-TE paths

within a "domain" (such as an IGP area) or across multiple domains

(such as a multi-area AS or multiple ASes).

  • Within a single area, the PCE offers enhanced computational power that may not be available on individual routers, sophisticated policy control and algorithms, and coordination of computation across the whole area.

  • If a router wants to compute a MPLS-TE path across IGP areas, then its own TED lacks visibility of the complete topology. That means that the router cannot determine the end-to-end path and cannot even select the right exit router (Area Border Router (ABR)) for an optimal path. This is an issue for large-scale networks that need to segment their core networks into distinct areas but still want to take advantage of MPLS-TE.

Previous solutions used per-domain path computation [RFC5152]. The

source router could only compute the path for the first area because

the router only has full topological visibility for the first area

along the path, but not for subsequent areas. Per-domain path

computation uses a technique called "loose-hop-expansion" [RFC3209]

and selects the exit ABR and other ABRs or AS Border Routers (ASBRs)

using the IGP-computed shortest path topology for the remainder of

the path. This may lead to sub-optimal paths, makes alternate/back-

up path computation hard, and might result in no TE path being found

when one really does exist.

The PCE presents a computation server that may have visibility into

more than one IGP area or AS, or may cooperate with other PCEs to

perform distributed path computation. The PCE obviously needs access

to the TED for the area(s) it serves, but [RFC4655] does not describe

how this is achieved. Many implementations make the PCE a passive

participant in the IGP so that it can learn the latest state of the

network, but this may be sub-optimal when the network is subject to a

high degree of churn or when the PCE is responsible for multiple

areas.

The following figure shows how a PCE can get its TED information

using the mechanism described in this document.

                +----------+                           +---------+
                |  -----   |                           |   BGP   |
                | | TED |<-+-------------------------->| Speaker |
                |  -----   |   TED synchronization     |         |
                |    |     |        mechanism:         +---------+
                |    |     | BGP with Link-State NLRI
                |    v     |
                |  -----   |
                | | PCE |  |
                |  -----   |
                +----------+
                     | Request/
                     | Response
                +----------+              +----------+

     Figure 2: External PCE Node Using a TED Synchronization Mechanism

The mechanism in this document allows the necessary TED information

to be collected from the IGP within the network, filtered according

to configurable policy, and distributed to the PCE as necessary.

An ALTO server [RFC5693] is an entity that generates an abstracted

network topology and provides it to network-aware applications over a

web-service-based API. Example applications are peer-to-peer (P2P)

clients or trackers, or Content Distribution Networks (CDNs). The

abstracted network topology comes in the form of two maps: a Network

Map that specifies allocation of prefixes to Partition Identifiers

(PIDs), and a Cost Map that specifies the cost between PIDs listed in

the Network Map. For more details, see [RFC7285].

ALTO abstract network topologies can be auto-generated from the

physical topology of the underlying network. The generation would

typically be based on policies and rules set by the operator. Both

prefix and TE data are required: prefix data is required to generate

ALTO Network Maps, and TE (topology) data is required to generate

ALTO Cost Maps. Prefix data is carried and originated in BGP, and TE

data is originated and carried in an IGP. The mechanism defined in

this document provides a single interface through which an ALTO

server can retrieve all the necessary prefix and network topology

data from the underlying network. Note that an ALTO server can use

other mechanisms to get network data, for example, peering with

multiple IGP and BGP speakers.

The following figure shows how an ALTO server can get network

topology information from the underlying network using the mechanism

described in this document.

     +--------+
     | Client |<--+
     +--------+   |
                  |    ALTO    +--------+     BGP with    +---------+
     +--------+   |  Protocol  |  ALTO  | Link-State NLRI |   BGP   |
     | Client |<--+------------| Server |<----------------| Speaker |
     +--------+   |            |        |                 |         |
                  |            +--------+                 +---------+
     +--------+   |
     | Client |<--+
     +--------+

         Figure 3: ALTO Server Using Network Topology Information
Last updated on