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]