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-01.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 established 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
Martini [Page 1]
Internet Draft draft-martini-pwe3-ms-pw-pce-01.txt October 2006
method for calculating said "best route", and choosing the S-PEs is
described in this document using the existing Path Computation
Element work done in the PCE WG.
Table of Contents
1 Specification of Requirements ........................ 2
2 Terminology .......................................... 3
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 ........ 7
6.2 Link failure and path re-optimization procedures ..... 7
7 IANA Considerations .................................. 7
8 Security Considerations .............................. 7
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.
Martini [Page 2]
Internet Draft draft-martini-pwe3-ms-pw-pce-01.txt October 2006
2. Terminology
This documents assumes familiarity with the terminology described in
[RFC3985], [MS-ARCH], [PW-SEG], and [RFC4655].
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) based
architecture.
[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
Martini [Page 3]
Internet Draft draft-martini-pwe3-ms-pw-pce-01.txt October 2006
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:
-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 compute 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).[OSPF-TE][ISIS-TE]
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
Martini [Page 4]
Internet Draft draft-martini-pwe3-ms-pw-pce-01.txt October 2006
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.
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, defined in [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. Furthermore, such capability will be
added to the PCED TLV defined in [draft-ietf-pce-disco-proto-isis]
and [draft-ietf-pce-disco-proto-ospf] carried within the ISIS Router
capability TLV and Router Information LSA.
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-01.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
Once a T-PE is configured with a specific TAII it determines which
role it will play according to the procedures immediately initiates
the PW signalling procedure. If the T-PE is configured to use a PCE ,
and the connection to the PCE is established, a request to compute
the path to the destination TAII is sent to the PCE. When annother
backup path is required that does not include any of the S-PEs
present in the primary path, an new request is sent to the PCE , with
an explicit list of S-PEs to exclude from the path computation. Using
this procedure , any number of independent backup paths can easily be
computed if they exist.
The active T-PE can then select the primary PW and setup independent
backup PW to be enabled in case the primary PW fails.
If the PCE reply message includes a NO-PATH object, then PCE failed
to compute a path to the requested destination. In this case the PE
can attempt to signal the PW on a hop by hop "best effort" basis, or
terminnate the signalling procedures and re-try at a later time.
Martini [Page 6]
Internet Draft draft-martini-pwe3-ms-pw-pce-01.txt October 2006
6.1. PCE session setup and path request procedures
6.2. Link failure and path re-optimization procedures
7. IANA Considerations
TBD
8. Security Considerations
TBD
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.
Martini [Page 7]
Internet Draft draft-martini-pwe3-ms-pw-pce-01.txt October 2006
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.
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]
Internet Draft draft-martini-pwe3-ms-pw-pce-01.txt October 2006
Martini [Page 9]