One document matched: draft-martini-pwe3-ms-pw-pce-00.txt
Network Working Group Luca Martini
Internet Draft Cisco Systems Inc.
Expiration Date: April 2007
October 2006
Dynamic Placement of Pseudowires using a Path Computation Element
draft-martini-pwe3-ms-pw-pce-00.txt
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
When dynamically Pseudowires (PW) span across multiple service
providers networks, or across multiple autonomous systems, there is a
need to calculate the best route among a set of switching point PEs
(S-PE). A method for calculating said "best route", and choosing the
S-PEs is described in this document using the existing Path
Martini [Page 1]
Internet Draft draft-martini-pwe3-ms-pw-pce-00.txt October 2006
Computation Element work done in the PCE WG.
Table of Contents
1 Specification of Requirements ........................ 2
2 Terminology .......................................... 2
3 Introduction ......................................... 3
4 PCE requirements ..................................... 4
5 Path Computation Element Client ...................... 5
5.1 PCEP ................................................. 5
5.1.1 Open Object .......................................... 5
5.2 Addressing and Path Constraint ....................... 5
5.3 PCE Reply ............................................ 6
6 Signaling Procedures ................................. 6
6.1 PCE session setup and Path request procedures ........ 6
6.2 Link failure and path re-computing procedures ........ 6
7 IANA Considerations .................................. 6
8 Security Considerations .............................. 6
9 Full Copyright Statement ............................. 7
10 Intellectual Property Statement ...................... 7
11 IANA Considerations .................................. 8
12 Normative References ................................. 8
13 Informative References ............................... 8
14 Author Information ................................... 8
1. Specification of Requirements
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.
2. Terminology
This documents assumes familiarity with the terminology described in
[RFC3985], [MS-ARCH], [PW-SEG], and [RFC4655].
Martini [Page 2]
Internet Draft draft-martini-pwe3-ms-pw-pce-00.txt October 2006
3. Introduction
Multi segment pseudowires (MS-PW) can be used in a network composed
of multiple MPLS domains, where LSPs cannot span the multiple domains
to build a layer2 VPN service. A set of Single Segment Pseudo Wires
(SS-PW) that are used to construct the MS-PW that spans multiple
Switching Point Provider Edge routers. (S-PE) These S-PEs can be
chosen by some external method, and be statically configured, or can
be dynamically discovered using, the methods described in [DYNAMIC-
PW]. However none of these methods is guaranteed to result in the
best path given a well defined set of constraints. This documents
describes a new method to compute the best set of S-PEs to use for a
given MS-PW using a Path Computation Element (PCE).
[MS-REQ], describes several requirements for choosing , and placing
MS-PWs in a PSN using S-PE, most notably there is a requirement for
pre-computing, and also setting up a backup PW which shares as little
fate as possible with the primary PW. This can also be easily
accomplished by using the PCE.
|<--------------Pseudo Wire----------->|
| | AS | | AS |
AC | |<----1---->| |<----2--->| | AC
| V V V V V V |
| +----+ +-----+ +----+ +----+ |
+----+ | | |=====| |=====| |=====| | | +----+
| |-------|.....PW1..........PW2.........PW3.....|-------| |
| CE1| | | | | | | | | | | |CE2 |
+----+ | | |=====| |=====| |=====| | | +----+
^ +----+ +-----+ +----+ +----+ ^
| T-PE1 S-PE2 S-PE3 T-PE4 |
| ^ ^ |
| | | |
| PW switching points |
| |
| |
|<------------------- Emulated Service --------------->|
Figure 1: PW switching inter provider Reference Model
Figure 1, above, shows a typical inter provider, or inter domain PW
topology. If the MS-PW is dynamically placed [DYNAMIC-PW] the path
for the MS-PW is computed on a hop by hop basis by each PE. The use
of the PCE can be applied at several different points:
Martini [Page 3]
Internet Draft draft-martini-pwe3-ms-pw-pce-00.txt October 2006
-i. At the originating T-PE.
-ii. At the First S-PE
-iii. At the S-PE which spans the autonomous system (AS) boundary.
-iv. At the first S-PE outside the AS.
Clearly iii, and iv, are not optimal, therefore only i, and
ii will be explored in this document.
Native |<------------Pseudo Wire------------>|Native
Service| |Service
(AC) | |<-PSN1-->| |<-PSN2-->| |(AC)
| V V V V V V |
| +-----+ +-----+ +-----+ |
+---+ | |T-PE1|=========|S-PEi|=========|T-PE2| | +---+
| |-----|......PW1-Seg1.......|.PW1-Seg2......|-----| |
|CE1| | |=========| |=========| | |CE2|
| | +-----+ +-----+ +-----+ | |
+---+ |.||.| |.||.| +---+
|.||.| +-----+ |.||.|
|.||.|=========| |========== .||.|
|.||...PW2-Seg1......|.PW2-Seg2...||.|
|.| ===========|S-PEj|============ |.|
|.| +-----+ |.|
|.|============+-----+============= .|
|.....PW3-Seg1.|.....| PW3-Seg2......|
==============|S-PEk|===============
| |
+-----+
Figure 2 Multi-segment pseudo-wire redundancy
********** to be fixed to show 2 S-PEs
4. PCE requirements
In order to be able to computer the best exit path among a set of S-
PE, the PCE needs information about the topology, and capacity of the
PSN tunnels that are available between T-PE and S-PEs. In MPLS
traffic engineering this is accomplished by using the IGP as a
transport method for such information. (Flooding of link state as an
IGP opaque message) However this method is not optimal in the case of
S-PE and PSN tunnels because only a small subset of the network
elements in the IGP need this information. For this purpose a point
to multipoint tunnel can be used by each S-PE to provide the topology
information to the PCE. Another method could use BGP to flood the
required information. This will be explored in the next revision of
this document.
Martini [Page 4]
Internet Draft draft-martini-pwe3-ms-pw-pce-00.txt October 2006
5. Path Computation Element Client
5.1. PCEP
The PCE-based architecture used for the computation of MPLS and GMPLS
TE LSP paths is described in [RFC4655]. When the PCC and the PCE are
not collocated, a communication protocol between the PCC and the PCE
is required. PCEP is such a protocol designed specifically for
communications between a PCC and a PCE or between two PCEs: a PCC may
use PCEP to send a path computation request for one or more MS-PW
path(s) to a PCE and such a PCE may reply with a set of computed
path(s) if one or more path(s) obeying the set of constraints can be
found.
5.1.1. Open Object
The OPEN object contains a set of fields used to specify the PCEP
protocol version, Keepalive frequency, PCEP session ID along with
various flags. The OPEN object may also contain a set of TLVs used to
convey various session characteristics such as the detailed PCE
capabilities, policy rules and so on. For the purpose of using the
PCE to compute MS-PW paths we need to identify the fact that the PCEP
session will be used to compute MS-PW paths.
To this purpose we will define a new optional capability TLV to be
used within the OPEN Object.
5.2. Addressing and Path Constraint
A new END-POINT Object containing the L2 addresses as specified in
[AII] is as follows:
Martini [Page 5]
Internet Draft draft-martini-pwe3-ms-pw-pce-00.txt October 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID (contd.) | Source Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix (contd.) | Source AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AC ID | AII Type=02 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: END-POINTS object body format for L2VPN AII addresses
5.3. PCE Reply
6. Signaling Procedures
6.1. PCE session setup and Path request procedures
6.2. Link failure and path re-computing procedures
7. IANA Considerations
TBD
8. Security Considerations
TBD
Martini [Page 6]
Internet Draft draft-martini-pwe3-ms-pw-pce-00.txt October 2006
9. Full 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.
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.
10. 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.
Martini [Page 7]
Internet Draft draft-martini-pwe3-ms-pw-pce-00.txt October 2006
11. IANA Considerations
This document has no IANA Actions.
12. Normative References
[PW-SEG] Martini et.al. "Segmented Pseudo Wire",
draft-ietf-pwe3-segmented-pw-00.txt, IETF Work in Progress,
July 2005
[AII] "Pseudowire Attachment Identifiers for Aggregation and
VPN Autodiscovery", Chris M., et al
draft-metz-aii-aggregate-01.txt, October 2006 (work in progress)
February, 2006
13. Informative References
[MS-REQ] "Requirements for inter domain Pseudo-Wires", Bitar N.,
Martini L., Bocci M., October 2006 (Work in Progress)
[RFC3985] Stewart Bryant, et al., PWE3 Architecture,
RFC3985
[MS-ARCH] Bocci at al, "Architecture for Multi-Segment PWE3",
draft-bocci-bryant-pwe3-ms-pw-arch-01.txt, September 2005.
( work in progress )
14. Author Information
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
e-mail: lmartini@cisco.com
Martini [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-20 15:31:21 |