One document matched: draft-vasseur-ccamp-ce-ce-te-01.txt
Differences from draft-vasseur-ccamp-ce-ce-te-00.txt
Networking Working Group JP. Vasseur, Ed.
Internet-Draft Gargi. Nalawade
Expires: December 26, 2006 Cisco Systems, Inc
K. Kumaki
KDDI Corporation
June 24, 2006
An MP-BGP protocol extension to advertize TE-related PE-CE link
information
draft-vasseur-ccamp-ce-ce-te-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on December 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document proposes MP-BGP protocol extension so as to convey
Traffic Engineering Link characterictics of PE (Provider Edge) - CE
(Customer Edge) links in order to extend the visibility of the
Traffic Engineering Database to those links. This can then be used
to more efficiently compute CE-to-CE Traffic Engineering Label
Vasseur, et al. Expires December 26, 2006 [Page 1]
Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006
Swtiched Path (TE LSP) when required to provide specific services
such as bandwidth guarantees and end to end fast protection in a
Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN)
environment.
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].
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MP-BGP Protocol extensions . . . . . . . . . . . . . . . . . . 6
4. TED update . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Proposed Status and Discussion [To Be Removed
Upon Publication] . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Vasseur, et al. Expires December 26, 2006 [Page 2]
Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006
1. Terminology
Terminology used in this document LSR: Label Switch Router.
BRPC: Backward Recursive Path Computation procedure.
CE: Customer Edge.
IGP Area: OSPF Area or IS-IS level.
Inter-domain TE LSP: A TE LSP whose path transits across at least two
different domains where a domain can either be an IGP area, an
Autonomous System or a sub-AS (BGP confederations).
NLRI: Network Layer Reachability Information.
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
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.
PCEP: Path Computation Element Protocol.
PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the
PCE).
PE: Provider Edge.
RD: Route Distinguisher.
SAFI: Subsequence Address Family Identifier.
TED: Traffic Engineering Database which contains the topology and
resource information of the domain. The TED may be fed by IGP
extensions or potentially by other means.
TE LSP: Traffic Engineering Label Switched Path.
VSPT: Virtual Shortest Path Tree.
2. Introduction
IGP extensions have been defined for OSPF (see [[RFC3630]) and for
IS-IS (see [[RFC3784]) so as advertise Traffic Engineering link
characteristics across an IGP area, which can then be used to compute
Vasseur, et al. Expires December 26, 2006 [Page 3]
Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006
MPLS Traffic Engineering Label Switched Path (TE LSP).
In Multiprotocol Label Switching Virtual Private Network (MPLS VPN)
enabled networks ([[RFC4364]), IP connectivity is provided to
customers sites by means VPNs enabled across an MPLS VPN network.
Service Providers have been using constrained based routing using
MPLS Traffic Engineering in their MPLS core between Provider Edge
(PE) Label Switch Router (LSR) to carry the traffic between the PEs
more optimaly and also to provide fast traffic restoration using a
local protection technique such as Fast Reroute ([[RFC4090]]).
In addition to IP connectivity services, Service Providers expressed
the requirements to also be able to provide other services to VPN
network based where Customer Edge (CE) routers could be
interconnected via TE LSPs so as to offer CE-to-CE bandwidth
guarantees, CE-to-CE protection (using a local protection recovery
mechanism such as Fast Reroute [[RFC4090]]), and CE-to-CE path
diversity. It must be noted that CE-to-CE path diversity may be
required in order to load balance the flows while avoiding to affect
all the traffic between the CEs upon the occurence of a single
failure or when a global protection mechanism is used, in which case
the second TE LSP is used as a backup should the primary TE LSP be
affected by a failure.
The provisioning of a CE-to-CE TE LSP can be seen as a particular
instanciation of inter-domain MPLS Traffic Engineering whereby a TE
LSP is computed across multiple routing domains. Thus, CE-to-CE TE
LSP can be computed using either the per-domain path computation
approach (described in [[I-D.ietf-ccamp-inter-domain-pd-path-comp]])
or a PCE-based path computation technique such as [[I-D.vasseur-pce-
brpc]].
That said, the per-domain path computation technique may be
suboptimal. Consider the following network:
Vasseur, et al. Expires December 26, 2006 [Page 4]
Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006
CE1---PE1----P1----P2-----PE3----CE3
| | | | /
PE2----P3----P4-----PE4--/
CE1, CE2 and CE3 belong to the same VPNx
PE1, ..., PE4 are PEs routers
P1, ..., P4 are P routers
Objective is to compute a TE LSP T1 from CE1 to CE2
Figure 1 - An example of CE to CE TE LSP
[I-D.ietf-ccamp-inter-domain-pd-path-comp] specifies a path
computation technique whereby each path segment is being computed (on
a per domain basis) during TE LSP signaling. In case of the example
provided in figure 1, CE1 would compute the TE LSP up to PE1 (if PE1
is chosen as its prefered next-hop), then PE1 would select its best
next hop PE and would compute the path segment up to that node and
finally that last egress PE would compute the last path segment up to
the destination CE. Altough such path computation allows for the
computation of CE-to-CE TE LSP it cannot guarantee that the computed
path is optimal (shortest constrained inter-domain TE LSP) and may
lead to call admission failure due to the lack of TE information from
the ingress to CE about the core network and from the ingress PE
about the remote PE-CE link.
Furthermore, the computation of a set of N diverse inter-domain paths
is quite challenging.
In contrast, PCE-based path computation techniques (see [[I-D.ietf-
pce-architecture]]) have been defined that allows for the computation
of shortest constrained inter-domain TE LSP, an particular
instantiation of which is the CE-to-CE path computation. A Multi-PCE
path computation technique has been described in [[I-D.vasseur-pce-
brpc]] that can be used for the computation of such shortest
constrained CE-to-CE TE LSP. Applying the BRPC procedure, a CE
acting as a PCC (Path Computation Client) sends a path computation
request of one of its attached PE acting as a PCE (in the form of a
PCEP [[I-D.ietf-pce-pcep]] PCReq message, which in turn relays the
PCReq message to the egress PE (also acting as a PCE). The shortest
constrained CE-to-CE TE LSP would then be computed using the backward
recursive scheme specifed in . [I-D.vasseur-pce-brpc]. In the
particular context of CE-to-CE TE LSP, the BRPC procedure can be
optimized by extending the TED visibility to some PE-CE links.
Indeed, the knowledge of TE PE-CE link characteristics would allow
the ingress PE (e.g. PE1) to compute in one pass the optimal
(shortest) CE-to-CE TE LSP.
Vasseur, et al. Expires December 26, 2006 [Page 5]
Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006
MP-BGP protocol extensions are proposed in this document to extend
the TED visibility to some PE-CE links.
3. MP-BGP Protocol extensions
A set of Traffic Engineering TLVs have been defined in [RFC3784] and
[RFC3630] for ISIS and OSPF respectively. Furthermore other TE link
attributes may be advertised using the TLV specified in [[I-D.ietf-
isis-link-attr]]. No new TE TLVs are specified in this document and
the existing TE TLVs will be re-used for the PE-CE link without any
change.
This document introduces a new SAFI called TE-Link SAFI [to be
defined in a further revision of this document]. The NLRI of this
SAFI is of the form RD:IP-address, where the RD is the RD of the VRF
as described in [RFC4364] and the IP-address is the address of the CE
router. The MP-BGP update for this SAFI will also be accompanied by
extended community attribute carrying Export Route-targets as defined
in [RFC4364]. This document also defines a new attribute called the
TE attribute which carries the set of sub-TLVs defined in [RFC3784].
The format of the BGP TE attribute will be defined in a further
revision of this document.
4. TED update
The mode of operation described in this document requires to extend
the TED so as to make it VPN-aware. That said, this does not require
any protocol extensions per-say and will not be discussed in this
document.
The receipt of an MP-BGP update comprising a new BGP TE attribute
will simply trigger a TED update should a TE-related information for
a PE-CE link be changed. An implementation MAY use a threshold-based
mechanisms to rate limit the frequency at which BGP updates will be
sent (similarly to the IGP case).
5. Example
An example is provided in this section that shows how the MP-BGP
extensions defined in this document optimizes the BRPC path
computation in the context of CE-to-CE TE LSP. Back to the exemplary
network depicted in Figure 1.
Step 1: The ingress CE (e.g. CE1) selects a PCE (say PE1).
Vasseur, et al. Expires December 26, 2006 [Page 6]
Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006
Step 2: Upon receiving the PCReq message from CE1, PE1 (acting as a
PCE) determines the set S of PEs with a PE-CE link to the destination
CE (e.g. CE2). The following VSPT is then computed:
VSPT computed by the ingress PE acting as a PCE
CE2
/ \
PE1 PE2
Step 3: The shortest constrained path is then returned to CE1 in the
form of a PCRep message (with loose hop).
6. IANA Considerations
The SAFI code for the TE SAFI will be assigned by IANA.
The BGP TE attribute code will also be assigned by the IANA.
7. Security Considerations
This document raises no new security issues for BGP.
8. Acknowledgements
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.ietf-ccamp-inter-domain-pd-path-comp]
Vasseur, J., "A Per-domain path computation method for
establishing Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)",
draft-ietf-ccamp-inter-domain-pd-path-comp-02 (work in
progress), February 2006.
[I-D.ietf-ccamp-inter-domain-rsvp-te]
Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions",
Vasseur, et al. Expires December 26, 2006 [Page 7]
Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006
draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in
progress), March 2006.
[I-D.ietf-isis-link-attr]
Vasseur, J. and S. Previdi, "Definition of an IS-IS Link
Attribute sub-TLV", draft-ietf-isis-link-attr-01 (work in
progress), May 2005.
[I-D.ietf-pce-architecture]
Farrel, A., "A Path Computation Element (PCE) Based
Architecture", draft-ietf-pce-architecture-05 (work in
progress), April 2006.
[I-D.ietf-pce-pcep]
Vasseur, J., "Path Computation Element (PCE) communication
Protocol (PCEP) - Version 1", draft-ietf-pce-pcep-02 (work
in progress), June 2006.
[I-D.vasseur-pce-brpc]
Vasseur, J., "A Backward Recursive PCE-based Computation
(BRPC) procedure to compute shortest inter-domain Traffic
Engineering Label Switched Paths",
draft-vasseur-pce-brpc-01 (work in progress), June 2006.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
Appendix A. Proposed Status and Discussion [To Be Removed Upon
Publication]
This Internet-Draft is being submitted for eventual publication as an
RFC with a proposed status of Standard. Discussion of this proposal
should take place on the following mailing list: ccamp@ietf.org.
Vasseur, et al. Expires December 26, 2006 [Page 8]
Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006
Authors' Addresses
JP Vasseur (editor)
Cisco Systems, Inc
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: jpv@cisco.com
Gargi Nalawade
Cisco Systems, Inc
510 McCarthy Blvd
Milpitas, MA 95035
USA
Email: gargi@cisco.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower Iidabashi, Chiyoda-ku,
Tokyo, 102-8460
JAPAN
Email: ke-kumaki@kddi.com
Vasseur, et al. Expires December 26, 2006 [Page 9]
Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vasseur, et al. Expires December 26, 2006 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-22 22:25:07 |