Traffic Engineering Database dissemination for Hierarchical PCE scenarios
draft-lopez-pce-hpce-ted-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Victor Lopez , Oscar Gonzalez de Dios , Daniel King , Stefano Previdi | ||
| Last updated | 2014-02-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lopez-pce-hpce-ted-01
Network Working Group V. Lopez
Internet-Draft O. Gonzalez de Dios
Intended status: Informational Telefonica I+D
Expires: August 15, 2014 D. King
Old Dog Consulting
S. Previdi
Cisco Systems, Inc.
February 11, 2014
Traffic Engineering Database dissemination for Hierarchical PCE
scenarios
draft-lopez-pce-hpce-ted-01
Abstract
The PCE architecture is well-defined and may be used to compute the
optimal path for LSPS across domains in MPLS-TE and GMPLS networks.
The Hierarchical Path Computation Element (H-PCE) [RFC6805] was
developed to provide an optimal path when the sequence of domains is
not known in advance. The procedure and mechanism for populating the
Traffic Engineering Database (TED) with domain topology and link
information used in H-PCE-based path computations is open to
interpretation. This informational document describes how topology
dissemination mechanisms may be used to provide TE information
between Parent and Child PCEs (within the H-PCE context). In
particular, it describes how BGP-LS might be used to provide inter-
domain connectivity. This document is not intended to define new
extensions, it demonstrates how existing procedures and mechanisms
may be used.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 15, 2014.
Lopez, et al. Expires August 15, 2014 [Page 1]
Internet-Draft TED-HPCE February 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Parent PCE Domain Topology . . . . . . . . . . . . . . . 3
1.2. Parent PCE TED requirements . . . . . . . . . . . . . . . 4
2. H-PCE Domain Topology Dissemination and Construction Methods 4
3. H-PCE architecture using BGP-LS . . . . . . . . . . . . . . . 5
4. Including Inter-domain connectivity in BGP-LS . . . . . . . . 8
4.1. Mapping from OSPF-TE . . . . . . . . . . . . . . . . . . 8
4.2. Mapping from ISIS-TE . . . . . . . . . . . . . . . . . . 8
5. BGP considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Manageability Considerations . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
In scenarios with multiple domains in both MPLS-TE and GMPLS
networks, the hierarchical Path Computation Element (H-PCE)
Architecture, defined in [RFC6805], allows to obtain the optimum end-
to-end path. The architecture exploits a hierarchical relation among
domains.
[RFC6805] defines the architecture and requirements for the end-to-
end path computation across domains. The solution draft for the
H-PCE [I-D.draft-zhang-pce-hierarchy-extensions-04] is focused on the
PCEP protocol extensions to support such H-PCE procedures, including
negotiation of capabilities and errors. However, neither the
architecture nor the solution draft specify which mechanism must to
Lopez, et al. Expires August 15, 2014 [Page 2]
Internet-Draft TED-HPCE February 2014
be used to build and populate the parent PCE (pPCE) Traffic
Engineering Database (TED).
The H-PCE architecture documents define the minimum content needed in
the traffic engineering database required to compute paths. The
information required by parent TEDB are identified in [RFC6805] and
further elaborated in
[I-D.draft-ietf-pce-inter-area-as-applicability-03]. For instance,
[RFC6805] and [I-D.draft-ietf-pce-inter-area-as-applicability-03]
suggest that BGP-LS could be used as a "northbound" TE advertisement.
This means that a PCE does not need to listen IGP in its domain, but
its TED is populated by messages received (for example) from a Route
Reflector. [I-D.draft-ietf-idr-te-pm-bgp-00] extends BGP-LS to
disseminate traffic engineering information. The parameters
considered are: delay, packet loss and bandwidth.
This document highlights the applicability of BGP-LS to the
dissemination of domain topology within the H-PCE architecture. In
particular, it describes how can BGP-LS be used to send the inter-
domain connectivity. It also shows how can OSPF-TE and ISIS-TE
updates be mapped into BGP-LS.
Note that this document is not intended to define new protocol
extensions, it is an informational document and where required it
highlights where existing mechanisms and protocols may be applied.
1.1. Parent PCE Domain Topology
The pPCE maintains a domain topology map of the child domains and
their interconnectivity. This map does not include any visibility
into the child domains. Where inter-domain connectivity is provided
by TE links, the capabilities of those links may also be known to the
pPCE. The pPCE maintains a TED for the parent domain, the nodes in
the parent domain are abstractions of the cPCE domains (connected by
real or virtual TE links), but the pPCE domain may also include real
nodes and links.
The procedure and protocol mechanism for disseminating and
construction of the pPCE TED may be provided using a number of
mechanisms, including manually configuring the necessary information
or automated using a separate instance of a routing protocol to
advertise the domain interconnectivity. Since inter-domain TE links
can be advertised by the IGPs operating in the child domains, this
information could then be exported to the parent PCE either by the
child PCEs or using north-bound export mechanisms.
Lopez, et al. Expires August 15, 2014 [Page 3]
Internet-Draft TED-HPCE February 2014
1.2. Parent PCE TED requirements
The information that would be exchanged includes:
o Identifier of advertising child PCE.
o Identifier of PCE's domain.
o Identifier of the link.
o TE properties of the link (metrics, bandwidth).
o Other properties of the link (technology-specific).
o Identifier of link endpoints.
o Identifier of adjacent domain.
2. H-PCE Domain Topology Dissemination and Construction Methods
A variety of methods exist to provide are different alternatives so
the parent PCE can get the topological information from the child
PCEs (cPCEs):
o Statically configure all inter-domain link and topology
information.
o Membership of an IGP instance. The necessary topological
information could be disseminated by joining the IGP instance of
each child PCE domain. However, by doing so, it would break the
domain confidentiality principles and is subject to scalability
issues.
o PCEP Notification Messages. Another solution is to send the
interconnection information between domains using PCEP
Notifications (see section 4.8.4 of [RFC6805]). One approach,
followed in research work, is embedding in PCEP Notifications the
Inter-AS OSPF-TE Link State Advertisements (LSA) to send the
Inter-Domain Link information from child PCEs to the parent PCE
and to send reachability information (list of end-points in each
domain). However, it is argued that the utilization of PCEP to
disseminate topology is beyond scope of the protocol.
o Separate IGP instance. [RFC6805] points out that in models such
as ASON it is possible to consider a separate instance of an IGP
running within the parent domain where the participating protocol
speakers are the nodes directly present in that domain and the
PCEs (parent and child PCEs).
Lopez, et al. Expires August 15, 2014 [Page 4]
Internet-Draft TED-HPCE February 2014
o Use north-bound distribution of TE information. The North-Bound
Distribution of Link-State and TE Information using BGP has been
recently propose in the IEFT
[I-D.draft-ietf-idr-ls-distribution-04]. This approach is known
as BGP-LS and defines a mechanism by which links state and traffic
engineering information can be collected from networks and
exported to external elements using the BGP routing protocol. By
using BGP-LS as northbound distribution mechanism, there would be
a BGP speaker in each domains that sends the necessary information
to a BGP speaker in the parent domain. This architecture is
further elaborated in this document.
3. H-PCE architecture using BGP-LS
As mentioned in [I-D.draft-dugeon-pce-ted-reqs-02] PCE has to
retrieve Traffic Engineering (TE) information to carry out its path
computation. This is required not only for intra-domain information,
which can be got using IGP (like OSPF-TE or ISIS-TE), but also for
inter-domain information in the Hierarchical PCE (H-PCE)
architecture.
Figure 1 shows an example of a H-PCE architecture. In this example,
there is a parent PCE and three child PCEs, and they are organized in
multiple domains. The parent PCE does not have information of the
whole network, but is only aware of the connectivity among the
domains and provides coordination to the child PCEs. Figure 2 shows
which is the visibility that parent PCE has from the network
according to the definition in [RFC6805].
Thanks to this topological information, when there is a request to a
child PCE with the destination in another domain, this path request
is sent to the parent PCE, which selects a set of candidate domain
paths and sends requests to the child PCEs responsible for these
domains. Then, the parent PCE selects the best solution and it is
transmitted to the source PCE.
Lopez, et al. Expires August 15, 2014 [Page 5]
Internet-Draft TED-HPCE February 2014
-----------------------------------------------------------------
| Parent PCE Domain |
| ----- |
| |pPCE | |
| ----- |
| |
| ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | |
| | | | | | | |
| | ------ | | ------ | | ------ | |
| | |cPCE 1| | | |cPCE 2| | | |cPCE 3| | |
| | ------ | | ------ | | ------ | |
| | | | | | | |
| | ----| |---- ----| |---- | |
| | |BN11+---+BN21| |BN23+---+BN31| | |
| | ----| |---- ----| |---- | |
| | | | | | | |
| | ----| |---- ----| |---- | |
| | |BN12+---+BN22| |BN24+---+BN32| | |
| | ----| |---- ----| |---- | |
| | | | | | | |
| ---------------- ---------------- ---------------- |
-----------------------------------------------------------------
Figure 1: Example of Hierarchical PCE architecture
----------------------------
| Parent PCE view |
| ---- |
| |pPCE| |
| ---- |
| |
| ---- ---- ---- |
| | |---| |---| | |
| | D1 | | D2 | | D3 | |
| | |---| |---| | |
| ---- ---- ---- |
----------------------------
Figure 2: Parent PCE topology information
Thanks to the dissemination of inter-domain adjacency information
from each cPCE to the pPCE, the pPCE can have a view of reachability
between the domains. The H-PCE architecture with BGP-LS is shown in
Lopez, et al. Expires August 15, 2014 [Page 6]
Internet-Draft TED-HPCE February 2014
Figure 3. Each domain has a cPCE that is able to compute paths in
the domain. This child PCE has access to a domain TED, which is
built using IGP information. In each domain, a BGP speaker has
access to such domain TED and acts as BGP-LS Route Reflector to
provide network topology to the pPCE. Next to the pPCE, there is a
BGP speaker that maintains a BGP session with each of the BGP
speakers in the domains to receive the topology and build the parent
TED. A policy can be applied to the BGP-LS speakers to decide which
information is sent to its peer speaker. The minimum amount of
information that needs to be exchanged is the inter-domain
connectivity, including the details of the Traffic Engineering Inter-
domain Links [RFC6805]. With this information, the parent PCE is
able to have access to a domain topology map and its connectivity.
Additionally, the BGP-LS speaker can be configured to send some
intra-domain information for virtual or candidate paths with some TE
information. In this case, the parent PCE has access to an extended
database, with visibility of both intra-domain and inter-domain
information and can compute the sequence of domains with better
accuracy.
BGP-LS [I-D.draft-ietf-idr-ls-distribution-04] extends the BGP Update
messages to advertise link-state topology thanks to new BGP Network
Layer Reachability Information (NLRI). The Link State information is
sent in two BGP attributes, the MP_REACH (defined in [RFC4670]) and a
LINK_STATE attribute (defined in
[I-D.draft-ietf-idr-ls-distribution-04]). To describe the inter
domain links, in the MP_REACH attribute, a Link NLRI can be used with
the local node descriptors the address of the source, and in the
remote descriptors, the address of the destination of the link. The
Link Descriptors field has a TLV (Link Local/Remote Identifiers),
which carries the prefix of the Unnumbered or Numbered Interface. In
case of the message informs about an intra-domain link, the standard
traffic engineering information is included in the LINK_STATE
attribute.
Lopez, et al. Expires August 15, 2014 [Page 7]
Internet-Draft TED-HPCE February 2014
----------------------------------------------------------------------
| Parent PCE Domain |
| ------- ----- ----- |
| -------+BGP-LS +---+ TED +--+pPCE | |
| / |Speaker| ----- ----- |
| / --+---+ |
| / | \_________________
| / | \
| ------------/-------- ----+------------ ------+------------ |
| | Domain 1 / | | | Domain 2 | | | Domain 3 | |
| | / | | | | | | | |
| | ------+ | | -+----- | | ---+--- | |
| | |BGP-LS | | | |BGP-LS | | | |BGP-LS | | |
| | |Speaker| | | |Speaker| | | |Speaker| | |
| | ---+--- | | ---+--- | | ---+--- | |
| | | | | | | | | | |
| | ---+--- ------ | | ---+-- ------ | | ---+--- ------ | |
| | | TED +-+cPCE 1| | | | TED +-+cPCE| | | | TED +-+cPCE 1| | |
| | ---+--- ------ | | ---+-- ------ | | ---+--- ------ | |
| | | | | | | | | | |
| | ---+--- | | ---+--- | | ---+--- | |
| | | IGP | | | | IGP | | | | IGP | | |
| | | Peer | | | | Peer | | | | Peer | | |
| | ------- | | ------- | | ------- | |
| | | | | | | | | | |
| ------+--------------- -----+----------- ------+------------ |
| | | | |
| ------------------- ---------------- ------------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | |
| ------------------- ---------------- ------------------- |
----------------------------------------------------------------------
Figure 3: Example of Hierarchical PCE architecture with BGP-LS
4. Including Inter-domain connectivity in BGP-LS
TBD
4.1. Mapping from OSPF-TE
TBD
4.2. Mapping from ISIS-TE
TBD
Lopez, et al. Expires August 15, 2014 [Page 8]
Internet-Draft TED-HPCE February 2014
5. BGP considerations
TBD
o Supporting BGP-4
o BGP Speakers
o Graceful Restart
o SRLGs
o Multiprotocol extensions
6. Manageability Considerations
TBD
7. Security Considerations
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC
4670, August 2006.
[RFC6805] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination of a
Sequence of Domains in MPLS and GMPLS", RFC 6805, November
2012.
8.2. Informative References
[I-D.draft-dugeon-pce-ted-reqs-02]
Dugeon, O., Meuric, J., Douville, R., Casellas, R., and O.
Gonzalez de Dios, "Path Computation Element (PCE) Traffic
Engineering Database (TED) Requirements", July 2013.
[I-D.draft-ietf-idr-ls-distribution-04]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", November 2013.
Lopez, et al. Expires August 15, 2014 [Page 9]
Internet-Draft TED-HPCE February 2014
[I-D.draft-ietf-idr-te-pm-bgp-00]
Wu, Q., Wang, D., Previdi, S., Gredler, H., and S. Ray,
"BGP attribute for North-Bound Distribution of Traffic
Engineering (TE) performance Metrics", January 2014.
[I-D.draft-ietf-pce-inter-area-as-applicability-03]
King, D., Meuric, J., Dugeon, O., Zhao, Q., and O.
Gonzalez de Dios, "Applicability of the Path Computation
Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic
Engineering", February 2013.
[I-D.draft-zhang-pce-hierarchy-extensions-04]
Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
and D. King, "Extensions to Path Computation Element
Communication Protocol (PCEP) for Hierarchical Path
Computation Elements (PCE)", July 2013.
Authors' Addresses
Victor Lopez
Telefonica I+D
Don Ramon de la Cruz 82-84
Madrid 28045
Spain
Phone: +34913128872
Email: vlopez@tid.es
Oscar Gonzalez de Dios
Telefonica I+D
Don Ramon de la Cruz 82-84
Madrid 28045
Spain
Phone: +34913128832
Email: ogondio@tid.es
Daniel King
Old Dog Consulting
UK
Email: daniel@olddog.co.uk
Lopez, et al. Expires August 15, 2014 [Page 10]
Internet-Draft TED-HPCE February 2014
Stefano Previdi
Cisco Systems, Inc.
Via Del Serafico 200
Rome 00144
IT
Email: sprevidi@cisco.com
Lopez, et al. Expires August 15, 2014 [Page 11]