PCE X. Li Internet-Draft BUPT Intended status: Informational XF. Lin Expires: January 2, 2013 ZTE Corporation shg. Huang J. Zhang M. Zhang HX. Wang BUPT July 1, 2012 Path Computation Element (PCE) Extensions for Link State Conflict Avoidance Mechanism in Optical Transport Networks draft-huangshg-pce-conflict-avoidance-00 Abstract This document proposes a PCE based link state conflict avoidance mechanism. Path Computation Element (PCE) can compute a network path or route based on the information stored in Traffic Engineering Database (TED) and TED collects the link resources information through the OSPF-TE protocol. The proposed conflict avoidance mechanism gives each link two state which respectively represents the resource in this link is changed or not. The extended OSPF-TE protocol will also flood the link state information when it floods the link resources information. PCE will add the link state to the calculated path when it returns the calculated path to Path Computation Clients (PCC). When the RSVP-TE protocol reserves the resource along the calculated path, it will compare the link state stored in the calculated path with the link state stored in the local. If the link state between the calculated path and the local is inconsistent then the RSVP-TE protocol will stop the resource reservation process, release the reserved resource and promote the OSPF-TE protocol to flood the Link resources information immediately. 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 Li, et al. Expires January 2, 2013 [Page 1] Internet-Draft PCE extensions for link state conflict July 2012 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 2, 2013. 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. Li, et al. Expires January 2, 2013 [Page 2] Internet-Draft PCE extensions for link state conflict July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . . 5 3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability of Link State Conflict Avoidance Mechanism in Optical Transport . . . . . . . . . . . . . . . . . . . . . 5 4.1. Two-value link state . . . . . . . . . . . . . . . . . . . 6 4.2. Path Computation Request and Path Computation Reply . . . . 7 4.3. RSVP-TE Process . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Li, et al. Expires January 2, 2013 [Page 3] Internet-Draft PCE extensions for link state conflict July 2012 1. Introduction With the development in large scale optical transport network, the calculation of optimal route becomes complicated and unrealistic under the distributed optical network of multi-layers and multi- domains. Path Computation Element (PCE) which is capable of computing a network path or route based on a network graph, and of applying computational constraints has effectively solved this issue. [RFC4655] specifies the architecture for a Path Computation Element (PCE)-based mode. It discusses PCE-based implementations including composite, external, and multiple PCE path computation. Furthermore, it discusses architectural considerations including centralized computation, distributed computation, synchronization, PCE discovery and load balancing, detection of PCE liveness, communication between Path Computation Clients (PCCs) and the PCE (PCC-PCE communication) and PCE-PCE communication, Traffic Engineering Database (TED) synchronization, stateful and stateless PCEs, monitoring, policy and confidentiality and evaluation metrics. [RFC5440] specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects. [RFC5557] provides a set of requirements and PCEP extensions in support of concurrent path computation applications. A concurrent path computation is a path computation application where a set of TE paths are computed concurrently in order to efficiently utilize network resources. The computation method involved with a concurrent path computation is referred to as "global concurrent optimization" in this document. Appropriate computation algorithms to perform this type of optimization are out of the scope of this document. PCE system structure characteristics include: PCE is compatible with existing MPLS/GMPLS agreement. PCE is compatible with existing MPLS/ GMPLS network operation mode, including management level. PCE uses a single, signaling protocol and structure, suitable for different network environment, such as inner domain, between domains, and between different operators, etc. PCE allows operators or equipment manufacturers use different routing algorithms, based on complex traffic engineering parameters and strategy calculation routing; and has the flexible system structures. PCE can work with nets element Li, et al. Expires January 2, 2013 [Page 4] Internet-Draft PCE extensions for link state conflict July 2012 equipment together, also can be in a single server implementation. When the PCC and the PCE is not in the same physical location, they use PCEP protocol and BRPC algorithm to realize multi-domain path requests and path calculation. 2. Conventions Used in This Document 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 [RFC2119]. 3. Terminologies PCC: Path Computation Client. PCE: Path Computation Element. TED: Traffic Engineering Database. PCEP: The PCE communication Protocol. 4. Applicability of Link State Conflict Avoidance Mechanism in Optical Transport Once a request has been presented to a PCE, it chooses the proper route within the network based on the resource information in TED. The TED gathers the information related to the current topology and resource usage in the network by continuous interaction with the OSPF-TE protocol. When the PCE has chosen the route for a router demand, the corresponding LSP will be setup using RSVP-TE protocol, which will take care of performing node-by-node admission control and actual resource allocation. OSPF-TE advertises the change of local resource allocation status to all other TED by sending a Link State Update message containing a special kind of Link State Advertisement object called opaque LSA. The LSU message is distributed to all LSRs using the OSPF flooding procedure. In order to avoid that the massive information flooding is executed for each minimal change, some flooding reduction mechanisms are used, so that the origination rate of OSPF-TE LSU messages can be reduced. But the flooding reduction mechanisms may cause that the resource information stored in the TED cannot be updated in real time. A potential solution would be to advertise a two-value state for each local link with little size of packet. This would require implementations to process these two-value state TLVs during the path Li, et al. Expires January 2, 2013 [Page 5] Internet-Draft PCE extensions for link state conflict July 2012 calculation in PCE. It need to increase the rate of OSPF-TE Link State messages and is anticipated that the Link State messages will prove more generally useful. 4.1. Two-value link state Each local link will be given two-value (0,1) link state where 1represent the resource in local link state have be changed and 0 represent the resource in local link state have no changed. The link state TLV is as presented in the Fig.1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Li, et al. Expires January 2, 2013 [Page 6] Internet-Draft PCE extensions for link state conflict July 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(36) | C-Tyoe(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Advertising Router | Reserved | Label Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchanne l | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchanne N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2. Path Computation Request and Path Computation Reply Once a PCC has successfully established a PCEP session with one or more PCEs, it sends a path computation request to the PCE that contains a variety of objects that specify the set of constraints and attributes for the path to be computed. Upon receiving a path computation request from a PCC, the PCE triggers a path computation. The PCE manages to compute a path that includes the link state information. Then PCE returns the set of computed paths (EXPLICIT_ROUTE object) to the requesting PCC. Note that PCEP supports the capability to send link state TLV in the computed path. 4.3. RSVP-TE Process RSVP-TE enables the allocation of resources along the path. The source node adds an EXPLICIT_ROUTE object to the RSVP-TE Path message. The EXPLICIT_ROUTE object specifies the route as a sequence of nodes. When the RSVP-TE reserve the resource in the local link then in will compare the link state stored in the calculated path with the link state stored in the local. If the link state between the calculated path and the local is inconsistent then the RSVP-TE protocol will stop the resource reservation process, release the reserved resource and promote the OSPF-TE protocol to flood the Link resources information immediately. 5. Security Considerations TBD. Li, et al. Expires January 2, 2013 [Page 7] Internet-Draft PCE extensions for link state conflict July 2012 6. Acknowledgments TBD. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. [RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element(PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. Authors' Addresses Xin Li BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613426082735 Email: xinli@bupt.edu.cn URI: http://www.bupt.edu.cn/ Xuefeng Lin ZTE Corporation No.16,Huayuan Road,Haidian District Beijing 100191 P.R.China Phone: +8615901011821 Email: lin.xuefeng@zte.com.cn URI: http://www.zte.com.cn/ Li, et al. Expires January 2, 2013 [Page 8] Internet-Draft PCE extensions for link state conflict July 2012 Shanguo Huang BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613693578265 Email: shghuang@bupt.edu.cn URI: http://www.bupt.edu.cn/ Jie Zhang BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613911060930 Email: lgr24@bupt.edu.cn URI: http://www.bupt.edu.cn/ Min Zhang BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613910621756 Email: @bupt.edu.cn URI: http://www.bupt.edu.cn/ Hongxiang Wang BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613683683550 Email: wanghx@bupt.edu.cn URI: http://www.bupt.edu.cn/ Li, et al. Expires January 2, 2013 [Page 9]