Path Computation Element (PCE) Traffic Engineering Database (TED) Requirements
draft-dugeon-pce-ted-reqs-00
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 | Olivier Dugeon , Julien Meuric | ||
| Last updated | 2012-03-05 | ||
| 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-dugeon-pce-ted-reqs-00
Path Computation Element Working Group O. Dugeon
Internet-Draft J. Meuric
Intended status: Informational Orange Labs
Expires: September 6, 2012 March 5, 2012
Path Computation Element (PCE) Traffic Engineering Database (TED)
Requirements
draft-dugeon-pce-ted-reqs-00
Abstract
During the past 4 years, Path Computation Element (PCE) WG has
produced a set of RFCs to standardize the behavior of the Path
Computation Element as a tool to help MPLS-TE LSP tunnels placement.
In the PCE architecture, a main assumption has been done concerning
the information that the PCE needs to perform its computation: the
Traffic Engineering Database (TED) contains all pertinent and
suitable information regarding the networks that is in the scope of a
PCE. Nevertheless, requirements and inventory of TED information
have not been formalized. In addition, some recent RFC (like BRPC
RFC 5441) or WG draft (like draft-ietf-pce-hierarchy ...) suffer from
a lack of information coming from the TED resulting to a non optimal
result or some difficulties to deploy them. This memo tries to
identity all TED requirements for the PCE as well as provides some
helps to operators to fulfill the PCE TED.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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."
Dugeon & Meuric Expires September 6, 2012 [Page 1]
Internet-Draft PCE TED Req. March 2012
This Internet-Draft will expire on September 6, 2012.
Copyright Notice
Copyright (c) 2012 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.
Dugeon & Meuric Expires September 6, 2012 [Page 2]
Internet-Draft PCE TED Req. March 2012
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
1.1. PCE assumption and hypothesis . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. TED Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. MPLS Layer . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Intra-domain . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. inter-domain . . . . . . . . . . . . . . . . . . . . . 6
2.2. Optical Layer . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Operational Information . . . . . . . . . . . . . . . . . 7
3. TED Management . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. MPLS layer . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Intra-domain . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. inter-domain . . . . . . . . . . . . . . . . . . . . . 8
3.2. Optical layer . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Operational information . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Intra-domain information . . . . . . . . . . . . . . . . . 9
5.2. Inter-domain information . . . . . . . . . . . . . . . . . 9
5.3. Operational information . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Dugeon & Meuric Expires September 6, 2012 [Page 3]
Internet-Draft PCE TED Req. March 2012
1. Problem Statement
Looking to the different RFCs that describe the PCE architecture and
in particular RFC 4655 [RFC4655], RFC 5440 [RFC5440] and RFC 5441
[RFC5441] as well as the draft H-PCE [I-D.ietf-pce-hierarchy-fwk],
the Path Computation Element (PCE) need to acquire a set of
information that are usually store in the Traffic Engineering
Database (TED) in order to perform its path computation. Even if
intra-domain topology acquisition is well documented and known (e.g.
by listen to the IGP-TE protocol that runs inside the network),
inter-domain topology information, PCE peer address, neighbor AS ...
that are necessary for the Backward Recursive Path Computation (BRPC)
and the Hierarchical PCE are not documented and not well
standardized.
The purpose of this memo is to inventory the required information
that should be part of the PCE TED and the different mechanism that
allow an operator to fulfill it.
1.1. PCE assumption and hypothesis
In some cases both functions (path computation and TED management)
are slightly coupled: border node identification, endpoint
localization and topology aggregation for domain sequence
selection,... to name a few in which an IGP-based TED may not be
sufficient. It is also important to differentiate several
environments with different requirements for the multidomain problem.
The PCE is scoped for any kind of network, from transport networks
(TDM/WDM) with a rather limited number of domains, few
interconnections, and few confidentiality issues, transport networks
with a large number of domains, MPLS networks with several
administrative domains, and big IP/MPLS networks with a large number
of domains with peering agreements. For each of them, a different
solution for the multi-domain path computation may apply. A solution
may not be scalable for one, but perfect for another.
Up to now, PCE WG has based its work and standard on the assumption
and hypothesis that the TED contains all pertinent information
suitable for the PCE to compute an optimal MPLS-TE LSP placement over
the networks the PCE controls or a set of domains through BRPC
algorithm. We could identify two major sources of information for
the TED:
o The intra-domain routing protocol like OSPF-TE or IS-IS-TE
o The inter-domain routing protocol i.e. BGP
If the first source gives a precise and synchronize view of the
Dugeon & Meuric Expires September 6, 2012 [Page 4]
Internet-Draft PCE TED Req. March 2012
controlled network, BGP just provides network reachability with only
one AS path (unless using recent add path option). Nevertheless, to
optimize inter-domain path computation, like BRPC, route diversity
and a minimum set of Traffic Engineering information about the
foreign domains could be helpful.
1.2. Terminology
ABR: Area Border Routers. Routers used to connect two IGP areas
(areas in OSPF or levels in IS-IS).
ASBR: Autonomous System Border Router. Router used to connect
together ASes of the same or different service providers via one or
more inter-AS links.
AS: Autonomous System
Boundary Node (BN): a boundary node is either an ABR in the context
of inter-area Traffic Engineering or an ASBR in the context of
inter-AS Traffic Engineering.
Domain: an Autonomous System
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along
a determined sequence of domains.
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along
a determined sequence of domains.
Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
IGP-TE: Interior Gateway Protocol with Traffic Engineering support.
Both OSPF-TE and IS-IS-TE are indentify in this category.
PCE: Path Computation Element. An entity (component, application, or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
PCE(i) is a PCE with the scope of domain(i).
TED: Traffic Engineering Database.
2. TED Requirements
This section made a first inventory of the main requirements of the
Dugeon & Meuric Expires September 6, 2012 [Page 5]
Internet-Draft PCE TED Req. March 2012
PCE TED in term of information that the database should contains
2.1. MPLS Layer
This section describes the IP layer information that are suitable for
the PCE TED.
2.1.1. Intra-domain
This is the main part of the TED. As the PCE controls the underlying
networks, it MUST be aware of the precise details of the networks
topology in order to compute the optimal Inter-area TE LSP path. For
that purpose, the TED MUST contains all information that allow the
PCE to reconstitute the topology graph of the networks and at least:
o Border Nodes: This include both area and AS boundary nodes (ABR
and ASBR),
o Internal Nodes: All nodes of the networks that are not border
node,
o Internal Links that rely nodes (both internal and border nodes),
o External Links that rely the area or the AS to the other area or
AS,
o Area number or Region level (depending of the IGP-TE),
o Traffic Engineering information of the different links (with e.g.
recent metric extensions proposal OSPF Traffic Engineering (TE)
Metric Extensions [I-D.ietf-ospf-te-metric-extensions])
All these information are exchange between the IGP-TE protocol
(OSPF-TE or IS-IS-TE).
2.1.2. inter-domain
Inter-domain information are mandatory when operator intend to use
the PCE to compute Inter-AS TE LSP path that cross AS boundary. For
that purpose, the TED SHOULD contains all information that allow the
PCE to determine the optimal AS path for the MPLS-TE LSP computation
and at least:
o ASBR of the foreign domain,
o ASBR Links between ASBR i.e. links between Border Node (n) to
Border node (n+1),
Dugeon & Meuric Expires September 6, 2012 [Page 6]
Internet-Draft PCE TED Req. March 2012
o Traffic Engineering of ASBR links as describe in RFC 5392
[RFC5392] and in RFC 5316 [RFC5316],
o Traffic Engineering performance between Border Nodes (n) to give
performance indication on foreign domain n,
o PCE (i) peer address associated with the AS number of the foreign
domain (i),
Unfortunately, only RFC 5316 and RFC 5392 could help to provide
required TED information in the case of inter-domain.
2.2. Optical Layer
To be provided latter.
2.3. Operational Information
This part of the TED contains all others information pertinent for
the PCE to compute TE LSP path but that are provided through the
management system.
3. TED Management
This section aims to provide Best Current Practices when mechanisms
are well-known and some hints when to standard solution exists to
manage the PCE TED, and so give help to fulfill it.
3.1. MPLS layer
3.1.1. Intra-domain
As the TED mainly contains the intra-domain topology graph, it is
RECOMMENDED to link the PCE with the underlying IGP-TE (OSPF-TE or
IS-IS-TE routing protocol). By configuring the PCE as a source sink
only, it is possible to listen to the routing protocol and then
acquired the complete topology graph. In addition, the TED will
synchronize as fast as the routing protocol converges like any router
in the domain.
In addition, management tools like network vendors management system
SHOULD be used to complement the topology graph provided by the
routing protocol.
Dugeon & Meuric Expires September 6, 2012 [Page 7]
Internet-Draft PCE TED Req. March 2012
3.1.2. inter-domain
First of all, RFC 5316 and RFC 5392 MUST be activated in the IGP-TE
(respectively in IS-IS-TE and OSPF-TE) in order to collect TE
information on the inter-domain links. This give the advantage for
the PCE to determine what could be feasible, during path computation,
on the peering links.
AS path and network reachability are of course obtain from the BGP
and routing tables. But, it is not possible to collect neither route
diversity nor TE information on foreign domain.
So, the main part of the inter-domain topology, like route diversity
and TE information (i.e. transit delay, packet loss ratio, transit
jitter ...) on a foreign domain could not be obtain easely. Right
now, we have identified several know methods to fulfill the TED with
these kind of information:
o Use the north bound distribution of Link-State and TE Information
using BGP [I-D.gredler-idr-ls-distribution] proposal to exchange
TE information about the foreign domain,
o Use PCNtf message to convey, inside vendor attribute (but in a non
standardize way), TE information of foreign domain between PCE,
o Use management system,
As well as some potential new mechanisms that needs some
standardization effort:
o A hierarchical IGP-TE that could help to convey at the AS level TE
information on an abstract / aggregate view of the foreign AS
topology,
o Extend PCEP, and in particular PCNtf message to convey such TE
information on the foreign
3.2. Optical layer
To be provided latter.
3.3. Operational information
Most of the time operationals information are provided through the
management system of the operator. But some could be automatically
discovered. In particular, in intra-domain, PCE could discover
automatically its peer through the deployment of RFC
Dugeon & Meuric Expires September 6, 2012 [Page 8]
Internet-Draft PCE TED Req. March 2012
4. IANA Considerations
This document makes no request of IANA for the moment.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
Acquisition of information for the PCE TED is of course sensible from
a security point of view, especially when acquiring information from
others AS. This section aims at providing best practices to prevent
some security threat when the PCE try to acquire TED information.
5.1. Intra-domain information
Same security considerations must be applied to the PCE when it is
connected to an IGP-TE protocol as the routing protocol itself. Best
practices observed and deployed by operators must also be taken into
account when installing a PCE. In fact, the PCE itself, when
deployed as a standalone server, must be considered as a standard
router regarding the IGP-TE. So, disregarding OSPF or IS-IS, same
security rules must be app lied e.g. login/passwd to protect the
connectivity.
5.2. Inter-domain information
Inter-domain relation and so information exchange are subject to high
potential hijack and so need attention from the security point of
view. To avoid disclosing or expose confidential information that
two operators would exchange to fulfil the TED of their respective
PCE, the relation SHOULD be protected by standard cryptography
mechanism. E.g. using IPsec tunnel is RECOMMENDED to protect the
connectivity between PCE and TED exchange.
5.3. Operational information
All operational information like PCE peer addresses are generaly
added manually to the TED and so don't need any particular protection
nor subject to security. But, as these based information are needed
to let PCE connected to its peers, is could potentially contains
sensitive parameters like login and password. So, standard Best
Practices are RECOMMENEDED to avoid basic security exposition.
Dugeon & Meuric Expires September 6, 2012 [Page 9]
Internet-Draft PCE TED Req. March 2012
6. Acknowledgements
The authors want to thanks PCE's WG members and in particular Ramon
Casellas, Oscar Gonzalez de Dios and Daniel King for their inputs of
this subject.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward-Recursive PCE-Based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", RFC 5441, April 2009.
7.2. Informative References
[I-D.gredler-idr-ls-distribution]
Gredler, H., Medved, J., Farrel, A., and S. Previdi,
"North-Bound Distribution of Link-State and TE Information
using BGP", draft-gredler-idr-ls-distribution-00 (work in
progress), September 2011.
[I-D.ietf-ospf-te-metric-extensions]
Atlas, A., Drake, J., Giacalone, S., Previdi, S., and D.
Ward, "OSPF Traffic Engineering (TE) Metric Extensions",
draft-ietf-ospf-te-metric-extensions-00 (work in
progress), November 2011.
[I-D.ietf-pce-hierarchy-fwk]
Farrel, A. and D. King, "The Application of the Path
Computation Element Architecture to the Determination of a
Sequence of Domains in MPLS and GMPLS",
draft-ietf-pce-hierarchy-fwk-00 (work in progress),
October 2011.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Dugeon & Meuric Expires September 6, 2012 [Page 10]
Internet-Draft PCE TED Req. March 2012
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, December 2008.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, January 2009.
Authors' Addresses
Olivier Dugeon
Orange Labs
2, Avenue Pierre Marzin
Lannion 22307
France
Email: olivier.dugeon@orange.com
Julien Meuric
Orange Labs
2, Avenue Pierre Marzin
Lannion 22307
France
Email: julien.meuric@orange.com
Dugeon & Meuric Expires September 6, 2012 [Page 11]