Network work group Fatai Zhang Internet Draft Dan Li Intended status: Informational Jianhua Gao Expires: September 2009 Huawei March 02, 2009 Requirements for PCE applied in Time-Division Multiplexing (TDM) Networks draft-zhang-pce-reqs-for-tdm-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 September 02, 2009. Abstract This document describes the special requirements for applying the Path Computation Element (PCE) in Time-Division Multiplexing (TDM) networks, including Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Digital Wrapper (G.709 ODUk). The material presented in this document is collected here for analysis. The intention is to separate this material into separate documents on generic GMPLS requirements, generic GMPLS extensions, and TDM-specific requirements and extensions. Zhang Expires September 2009 [Page 1] Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009 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]. Table of Contents 1. Introduction..................................................2 1.1. Disposition of this Document.............................3 2. Terminology...................................................4 3. PCE Applications..............................................4 4. Requirements..................................................5 4.1. Requirements when PCC Specifies the Connection Type......5 4.2. Requirements when PCE Determines the Connection Type.....6 5. Security Considerations.......................................7 6. IANA Considerations...........................................7 7. Acknowledgments...............................................7 8. References....................................................7 9. Authors' Addresses............................................8 1. Introduction As defined in [RFC4655], a Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and of applying computational constraints during the computation. Any node in the network can act as a Path Computation Client (PCC) and request PCE to compute a path that satisfies the set of constraints. When it finishes computing, the PCE will respond with the path to the PCC. The communication protocol between PCE and PCC has been described in [PCEP]. The main work for PCE so far has been its application in MPLS networks that are already stable and mature. However, the application of PCE to GMPLS in packet and non-packet networks has also been considered. GMPLS has more technology-specific and generic traffic engineering constraints, and some of these, for TDM networks, need further extensions to PCEP. First, the properties of the LSP being computed should be fed to the PCE from the PCC. These properties include the switching capabilities (e.g., TDM, lambda, LSC, etc.), the encoding type (e.g., SDH/Sonet, Digital Wrapper, lambda, etc.), and the signaling type (e.g., VC12, VC3, ODUk, etc.). This information is very important for the PCE to zhang Expires September 2009 [Page 2] Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009 compute a required Path. These properties are parameters are added to PCEP in [PCEP-Layer]. Second, the reliability of the network is very important for transport networks. So the PCE should get information about required level of protection for the LSP from the PCC. In TDM networks, there are abundant protection types to satisfy different demand for the service, for example, 1+1 protection, 1:1 protection, 1: n protection, full rerouting, shared-mesh restoration, and segment recovery, etc. This information is really important for PCE to compute the corresponding work LSP and protection LSP correctly on operating the traffic engineering database (TED). In addition, the link protection also should be taken into account for PCE path computation. The requirements for LSP protection type and link protection type are addressed briefly in [PCE-App-Req]. Third, in TDM networks (e.g., SDH/OTN networks), a client service can be transmitted by various connection(s) of TDM with different connection type. For example, in the SDH networks, if the client service which is 100M Ethernet is required to be transported over the SDH networks, the Ethernet service can be provided by a VC4 connection, and it can also be provided by three concatenated VC3 connections (Contiguous or Virtual Concatenation). So this information about connection type is vital for PCE to compute the correct LSP(s) to transport the service traffic. The above three requirements are very important for PCE to compute the desirable paths when PCE applied in the TDM networks. However, the first two requirements are addressed partially in [PCEP-Layer] and [PCE-App-Req], so this document focuses on the third requirement. 1.1. Disposition of this Document The material presented in this document is collected here for analysis. The intention is to separate this material into separate documents as follows: - Generic GMPLS requirements for PCEP will be merged into a single document working with the authors of [PCE-App-Req]. - A new document will be created to provide generic GMPLS extensions to PCEP to address the generic requirements. - This document will be reduced to contain the TDM-specific requirements (If needed, we can use one document to cover the zhang Expires September 2009 [Page 3] Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009 TDM-specific requirements and extensions). 2. Terminology 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. PCE Applications The TDM networks are usually responsible for transmitting data for the client layer. These TDM networks can provide different types of connections for customer services based on different service bandwidth requests. The applications and the corresponding additional requirements for applying PCE in TDM networks are described below. In order to simplify the description, this document just discusses the scenario in SDH networks as an example. The scenarios in SONET or G.709 ODUk layer networks are similar. +------+ +------+ +------+ | | | | | | A1--| N1 +------------------+ N2 | | PCE | | | | | | | +--+---+ +---+--+ +------+ | \ | | \ +------+ | | | | | | | N5 | | | | | | | +------+ \ | +--+---+ \ +---+--+ | | | | | N4 +------------------+ N3 |--A3 | | | | +------+ +------+ Figure 1: A simple SDH network Figure 1 shows a simple network topology, where N1, N2, N3, N4, and N5 are all SDH switches. Assume that one Ethernet service with 100M zhang Expires September 2009 [Page 4] Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009 bandwidth is required from A1 to A3 over this network. The client Ethernet service could be provided by a VC4 connection from N1 to N3, and it could also be provided by three concatenated VC3 connections (Contiguous or Virtual concatenation) from N1 to N3. The type of connectivity that is required (one VC4 or three concatenated VC3) needs to be specified by PCC (e.g., N1 or NMS), 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 next section lists requirements described according to different the policies that are applied. 4. Requirements 4.1. Requirements when PCC Specifies the Connection Type In this case, when receiving the service request from A1 to A3 from client layer, the PCC (e.g., N1) specifies the transport scheme for the service based on the requested bandwidth and the transport policies pre-configured, and then requests the PCE to compute the corresponding path. For example, the node N1 specifies that it needs three virtual concatenated VC3 connections in the Path Computation Request message to the PCE. Therefore, the following information should be specified by PCC in the PCReq message: (1) Signal Type: Indicates the type of elementary signal that constitutes the requested LSP. A lot of signal types with different granularity have been defined in SONET/SDH and G.709 ODUk, such as VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, ODU2 and ODU3 in G.709 ODUk. See [RFC4606] and [RFC4328] (Note that switching capability and encoding type should also be specified which are described in [PCE-App-Req]). (2) Concatenation Type: In SDH/ SONET and G.709 ODUk networks, two kinds of concatenation modes are defined: contiguous concatenation which requires co-router for each member signal and requires all the interfaces along the path to support this capability, and virtual concatenation which allows diverse routes for the member signals and only requires the ingress and egress interfaces to support this capability. Note that for the virtual concatenation, it also may specify co-routed or separated-routed. See [RFC4606] and [RFC4328] about Concatenation information. zhang Expires September 2009 [Page 5] Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009 (3) Concatenation Number: Indicates the number of signals that are requested to be contiguously or virtually concatenated. Also see [RFC4606] and [RFC4328]. 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 above information (Signal type, Concatenation type, Concatenation number) in the PCRep message to tell PCC how to create the corresponding connections. In the case of virtual concatenation, when separate-routed paths are required, it is necessary for the PCE to indicate that how many member signals are needed in each route. For example, in Figure 1, if the node N1 requests a virtual concatenation connection with four VC4 signals and these four VC4 member signals should be separated-routed, the result of path computation may be two VC4 signals along the route N1-N2-N3 and another two VC4 signal along the route N1-N5-N3. 4.2. Requirements when PCE Determines the Connection Type In this case, when receiving the request for a service from A1 to A3 from the client layer, the PCC (e.g., N1) sends the PCReq message to the PCE. The message contains the information about requested bandwidth, as described in [PCEP]. When receiving the PCReq message, the PCE determines the transport scheme for the service based on the requested bandwidth and the pre- configured transport policies, and then computes the path. If successful, the information of the corresponding paths will be sent to the PCC in the PCRep message. In order that the PCC can set up the corresponding path, the PCE should tell the PCC the transport scheme, i.e., the connection type. So the PCRep message should contain the information described below: (1) Signal Type: Same as described in Section 4.1. (2) Concatenation Type: Same as described in Section 4.1. (3) Concatenation Number: Same as described in Section 4.1. In the case of virtual concatenation when separated routed paths are returned, it is also necessary for the PCE to indicate that how many zhang Expires September 2009 [Page 6] Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009 member signals are needed in each route, which is the same as described in Section 4.1. 5. Security Considerations This document just focuses on the requirements when PCE is applied in the TDM networks, so there is no additional security introduced. Possible security issues should be considered when it need extend PCEP to support these requirements. 6. IANA Considerations There is no IANA request in this document. 7. Acknowledgments TBD. 8. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PCEP] JP. Vasseur et al, "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 -" draft-ietf- pce-pcep (work in progress). [PCE-App-Req] Tomohiro Otani, Kenichi Ogaki and Diego Caviglia, "Requirements for GMPLS applications of PCE" draft-ietf- pce-gmpls-aps-req-00 (work in progress). [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, September 2006. [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC4606] E. Mannie and D. Papadimitriou, "GMPLS extensions for SONET and SDH control", RFC 4606, August 2006. [RFC4328] D. Papadimitriou, "GMPLS Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [RFC5394] I. Bryskin, D. Papadimitriou, L. Berger and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008. zhang Expires September 2009 [Page 7] Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009 [PCEP-Layer] E. Oki, T. Takeda, J-L. Le Roux, and A. Farrel, "Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", draft-ietf-pce-inter-layer-ext, work in progress. 9. Authors' Addresses Fatai Zhang Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972912 Email: Zhangfatai@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28973237 Email: danli@huawei.com Jianhua Gao Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972912 Email: gjhhit@huawei.com Intellectual Property The IETF Trust 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 any IETF Document or the extent to which any license zhang Expires September 2009 [Page 8] Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009 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. Copies of Intellectual Property 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 THEREIN WILL NOT INFRINGE zhang Expires September 2009 [Page 9] Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement 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. zhang Expires September 2009 [Page 10]