Network Working Group F. Zhang Internet-Draft F. Gao Intended status: Informational Y. Bao Expires: January 4, 2010 ZTE Corpoporation July 03, 2009 Requirements for PCE Applied in OTN draft-zhang-pce-reqs-for-otn-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 4, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes specific requirements for applying Path Computation Element (PCE) in Optical Transport Networks (OTN). Zhang, et al. Expires January 4, 2010 [Page 1] Internet-Draft Requirements for PCE Applied in OTN July 2009 Lightpath provisioning in OTN needs the pre-consideration of the Optical Data Unit (ODUk) cross connection because of the additional optical impairments constraints on the Optical Channel (OCh) lightpath available for use. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. PCE Applications . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Requirements when PCC Specifies the Signal Format . . . . . 5 3.2. Requirements when PCE Determines the Signal Format . . . . 5 3.3. Source Routing . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative references . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Zhang, et al. Expires January 4, 2010 [Page 2] Internet-Draft Requirements for PCE Applied in OTN July 2009 1. Introduction A Path Computation Element (PCE) is an entity that is able to compute Label Switched Paths (LSP) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and General MPLS (GMPLS) networks, as defined in [RFC4655]. Any network element can act as a Path Computation Client (PCC) that requests the PCE to compute a set of TE-LSPs based on some kinds of constraints. The communication protocol between PCE and PCC or between cooperating PCEs is defined in [RFC5440]. G.709 Optical Transport Networks (OTN) are usually responsible for transmitting data for the client layer, as specified in the ITU-T G.709 recommendation [G.709]. It provides Optical Channel Data Unit (ODUk) digital layer and Optical Channel (OCh) optical layer cross connection based on different service bandwidth requests. Optical signal along the optical path maybe be altered by the optical impairments that is classified into two categories, linear and nonlinear. Linear effects, such as amplifier spontaneous emission (ASE), polarization mode dispersion (PMD), chromatic dispersion (CD) are independent of signal power and affect wavelength individually. However, nonlinearities (such as non-linear phase shift (NLPS)) are much more complex: they generate not only impairments on each channel, but also crosstalk between channels. Given that the existing standards covering optical characteristics (impairments) and the knowledge of how the impact of impairments may be estimated along a path, [RFC4054] provides an overview of some critical optical impairments and their routing Wavelength implications. Framework for impairment aware path computation based on the PCE architecture in WSON can be found in [wson-impairments] and [wson-routing-wavelength]. [wson-impairments] considers pre-setting a limited Bit Error Ratio (BER) value to estimate the calculated optical path quality. The limited BER value is dependent on the bit rate, the signal format and Forwarding Error Coding (FEC), however, the last two factors are determined by the digital encapsulation. In order to give a reasonable limited BER value, it is better to consider the ODUK and OCh layer provisioning together in OTN. 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 RFC-2119 [1]. Zhang, et al. Expires January 4, 2010 [Page 3] Internet-Draft Requirements for PCE Applied in OTN July 2009 3. PCE Applications Figure 1 shows a simple network topology, where NE1, NE2, NE3, NE4, NE5 are all OTN equipments, such as OXC, PXC, ROADM, etc. PCE is a function entity that is incorporated into the NMS or remote from the NMS using XML or PCEP to communicate with each other. PCE can share the traffic engineering database (TED) with NMS, get the TED with the help of IGP-TE, or the network elements (NEs) just send their traffic parameters directly to PCE using the method described in [PCE-TED]. No matter what methods we can assume that PCE knows the modulation formats and FEC types NE can support. Here for simplicity, we do not figure out the position of NMS. Assuming that one Ethernet service with 40G bandwidth is required from C1 to C3, the required signal format/FEC needs to be specified by PCC (N1), but could also be determined by PCE automatically based on policy, configuration, or network capabilities. This is related to the policies which can be implemented per [RFC5394]. The requirements described according to applied policies will list in the next two sections. +-----+ | PCE | +-----+ | | | +-----+ +-----+ C1------| NE1 |---------------| NE2 | +-----+ +-----+ | \ | | \ | | \ | | \+-----+ | | | NE5 | | | +-----+ | | \ | | \ | | \ | +-----+ \ +-----+ | NE4 |---------------| NE3 |------C3 +-----+ +-----+ Figure 1: Simple OTN network Zhang, et al. Expires January 4, 2010 [Page 4] Internet-Draft Requirements for PCE Applied in OTN July 2009 3.1. Requirements when PCC Specifies the Signal Format In this case, the PCC specifies the transport scheme for the service based on the requested bandwidth and the pre-configured transport policies when receiving the service request from C1 to C3 from client layer, then requests the PCE to compute the corresponding path. For example, the node N1 makes a decision to adopt Differential Quadrature Phase-Shift Keying (DQPSK) as the signal modulation format with FEC coding, then it will determine the pre-FEC that should be specified in the PCReq message. The pre-FEC value is out of the scope of this document, but apparently should take into account of the following factors: (1)the format/rate will give a required value that must be met in the receiver. (2)the degradation caused by PMD, OSNR, NPLS should be considered in the pre-setting value. (3)the margin reserved for the future operation/repair. (4)FEC revision. When receiving the PCReq message, PCE computes the path that satisfies the set of constraints in the PCReq message. If successful, the corresponding path will be returned to PCC in the PCRep message. Note that the PCE should return the calculated BER value in the PCRep message. 3.2. Requirements when PCE Determines the Signal Format In this case, when receiving the request for a service from C1 to C3 from the client layer, the PCC sends the PCReq message with the bandwidth object to the PCE before the ODUK cross connection. The PCE determines the signal modulation format/FEC function for the service based on the requested bandwidth, the estimated distance between N1 and N3, and the pre-configured transport policies after receiving the PCReq message, whereafter sets the pre-FEC value considering the factors the same as described in Section 3.1. If PCE can successfully work out the lightpath that satisfies the limited BER value , the information of the corresponding signal modulation format and FEC function will be sent to the PCC in the PCRep message in order that the PCC can set up the ODUk cross connection correctly. Of course, the calculated BER value should also be given to the PCC. 3.3. Source Routing In the transparent optical networks, the middle NE (e.g. N2/N4/N5 in figure 1) can not see the signal modulation format and FEC type, so the calculated light path can be end-to-end path from source to destination. However, the middle NE may terminate the optical signal in the opaque optical networks. In such cases, the PCE should give back to PCC the related information that every opaque hop's modulation format and FEC type. When signaling, PCC put this Zhang, et al. Expires January 4, 2010 [Page 5] Internet-Draft Requirements for PCE Applied in OTN July 2009 information in the ERO object of RSVP-TE, so every NE can use this information to setup the cross connection. 4. IANA Considerations TBD. 5. Security Considerations This document just focuses on the requirements of applying PCE in the OTN networks, so there is no additional security need to be considered until it need extend PCEP to support these requirements. 6. Acknowledgement The author would like to thank Xihua Fu for his useful comments. 7. References 7.1. Normative references [G.698.1] ITU-T Recommendation G.698.1, "Multichannel DWDM applications with Single-Channel optical interface", December 2006. [G.709] ITU-T G.709 Recommendation, "Interface for the Optical Transport Network (OTN)", February 2001. [RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints on Optical Layer Routing", RFC 4054, May 2005. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. Zhang, et al. Expires January 4, 2010 [Page 6] Internet-Draft Requirements for PCE Applied in OTN July 2009 7.2. Informative References [PCE-TED] Lee, Y. and G. Bernstein, "Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements", May 2009. [wson-impairments] Bernstein, G. and Y. Lee, "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments", June 2009. [wson-routing-wavelength] Lee, Y. and G. Bernstein, "PCEP Requirements for WSON Routing and Wavelength Assignment", March 2009. Authors' Addresses Fei Zhang ZTE Corpoporation 68 Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877612 Email: zhang.fei3@zte.com.cn Feng Gao ZTE Corpoporation ZTE Plaza, 19 Huayuandonglu Road Haidian District, Beijing 100191 P.R.China Phone: +86 010 82963969 Email: gao.feng1@zte.com.cn Yuanlin Bao ZTE Corpoporation ZTE Industrial Park, XiLi LiuXian Road Nanshan District, Shenzhen 518055 P.R.China Phone: +86 0755 26773731 Email: bao.yuanlin@zte.com.cn Zhang, et al. Expires January 4, 2010 [Page 7]