Network Working Group Y. Lee Internet Draft Huawei Intended status: Standard Track Expires: April 2010 G. Bernstein Grotto Networking October 19, 2009 PCEP Extensions in support of WSON Signal Compatibility Constraints draft-lee-pce-wson-signal-compatibility-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 April 19, 2009. 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 (http://trustee.ietf.org/license-info) in effect on the date of Lee & Bernstein Expires April 19, 2010 [Page 1] Internet-Draft PCEP Extension for WSON RWA October 2009 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 BSD License. Abstract This memo provides the Path Computation Element communication Protocol (PCEP) extensions for the support of signal compatibility constraints in Wavelength Switched Optical Networks (WSON). Signal compatibility is an essential path computation constraint in path computation of WSON networks where network elements can be limited to processing WSON signals with specific characteristics and attributes. 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 0. Table of Contents 1. Introduction...................................................3 2. PCEP Requirements..............................................4 3. PCEP Extensions (Encoding).....................................5 3.1. The PCC to PCE Interface..................................5 3.1.1. Signal Compatibility Indicator in the RP Object in the PC Request Message..........................................5 3.1.2. Modulation Type List sub-TLV.........................5 3.1.3. FEC Type List sub-TLV................................7 3.1.4. The GPID Type Sub-TLV................................9 3.2. The PCE to PCC Interface..................................9 3.2.1. Modulation Type TLV.................................10 3.2.2. FEC Type TLV........................................10 3.2.3. Regeneration Point TLV..............................10 4. Manageability Considerations..................................11 5. Security Considerations.......................................11 6. IANA Considerations...........................................11 7. Acknowledgments...............................................12 8. References....................................................12 Lee Expires April 19, 2010 [Page 2] Internet-Draft PCEP Extension for WSON RWA October 2009 8.1. Normative References.....................................12 8.2. Informative References...................................13 Authors' Addresses...............................................13 Intellectual Property Statement..................................13 Disclaimer of Validity...........................................14 1. Introduction [RFC4655] defines the PCE based Architecture and explains how a Path Computation Element (PCE) may compute Label Switched Paths (LSP) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks at the request of Path Computation Clients (PCCs). A PCC is shown to be any network component that makes such a request and may be for instance an Optical Switching Element within a Wavelength Division Multiplexing (WDM) network. The PCE, itself, can be located anywhere within the network, and may be within an optical switching element, a Network Management System (NMS) or Operational Support System (OSS), or may be an independent network server. The PCE communications Protocol (PCEP) is the communication protocol used between PCC and PCE, and may also be used between cooperating PCEs. [RFC4657] sets out the common protocol requirements for PCEP. Additional application-specific requirements for PCEP are deferred to separate documents. This document provides the Path Computation Element communication Protocol (PCEP) extensions for the support of signal compatibility constraints in Wavelength Switched Optical Networks (WSON). Signal compatibility is an essential path computation constraint in path computation of WSON networks where network elements can be limited to processing WSON signals with specific characteristics and attributes. Signals used in a WSON are not always compatible with common network elements including regenerators, OEO switches, wavelength converters, etc. [WSON-Compat] defines the GMPLS control plane framework that allows both multiple WSON signal types and common hybrid electro optical systems. Reference [WSON-Compat] characterizes WSON signals in line with ITU-T standards, and adds attributes describing signal compatibility constraints to WSON network elements. [CompatOSPF] provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. On a high-level the following network element information would be required for the path computation element (PCE) to be able Lee Expires April 19, 2010 [Page 3] Internet-Draft PCEP Extension for WSON RWA October 2009 to compute a constrained path that satisfies signal compatibility and processing constraints: . Input Compatibility: the type of signals it can receive (modulation types, rate, FEC types) . Regeneration Capability: the types of processing/enhancement it can perform (1R, 2R, 3R) . The types of conversions it can perform (modulation types, FEC types) . Output Format: the type of signals it can transmit (modulation types, rate, FEC types) 2. PCEP Requirements This section provides a set of PCEP requirements to support signal compatibility constraints. When requesting a path computation (PCReq) to PCE, the PCC should be able to indicate the following: o The acceptable signal attributes at the transmitter (at the source): (i) modulation types; (ii) FEC types o The acceptable signal attributes at the receiver (at the sink): (i) modulation types; (ii) FEC types o The GPID type of an LSP The PCE should be able to respond (PC Rep) to the PCC with the following: o The conformity of the requested optical characteristics associated with the resulting LSP with the source, sink and NE along the LSP. o Additional LSP attributes modified along the path (e.g., modulation format change, etc.) Lee Expires April 19, 2010 [Page 4] Internet-Draft PCEP Extension for WSON RWA October 2009 o Special node processing with the resulting LSP (e.g., regeneration point) 3. PCEP Extensions (Encoding) This section provides PCEP encoding to support the identified requirements in Section 2. 3.1. The PCC to PCE Interface This section provides the enhancements to the RP Object and its associated sub-TLV in the PC Request message from the PCC to the PCE interface to support signal compatibility constraints. 3.1.1. Signal Compatibility Indicator in the RP Object in the PC Request Message The RP object should have a bit indicating that signal compatibility check (say SC bit) should be performed for a path computation. 3.1.2. Modulation Type List sub-TLV When the SC bit in the RP Object is set to 1, then the RP object should include the Modulation Type List TLV associated with the request. Modulation types listed in the Modulation Type List TLV indicate allowable modulation types in both the source (transmitter) and the sink (receiver). The modulation type list sub-TLV may consist of two different types of fields: a standard modulation field or a vendor specific modulation field. Both start with the same 32 bit header shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|I| Modulation ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where S bit set to 1 indicates a standardized modulation format and S bit set to 0 indicates a vendor specific modulation format. The length is the length in bytes of the entire modulation type field. Where I bit set to 1 indicates an input modulation format and where I bit set to 0 indicates an output modulation format. Note that the source modulation type is implied when I bit is set to 0 and that the sink modulation type is implied when I bit is set to 1. Lee Expires April 19, 2010 [Page 5] Internet-Draft PCEP Extension for WSON RWA October 2009 The format for the standardized type for the input modulation at the sink is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Modulation ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional modulation parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the modulation ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Modulation ID Takes on the following currently defined values: 0 Reserved 1 optical tributary signal class NRZ 1.25G 2 optical tributary signal class NRZ 2.5G 3 optical tributary signal class NRZ 10G 4 optical tributary signal class NRZ 40G 5 optical tributary signal class RZ 40G Note that future modulation types may require additional parameters in their characterization. The format for vendor specific input modulation field at the sink is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Vendor Modulation ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Any vendor specific additional modulation parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee Expires April 19, 2010 [Page 6] Internet-Draft PCEP Extension for WSON RWA October 2009 Vendor Modulation ID This is a vendor assigned identifier for the modulation type. Enterprise Number A unique identifier of an organization encoded as a 32-bit integer. Enterprise Numbers are assigned by IANA and managed through an IANA registry [RFC2578]. Vendor Specific Additional parameters There can be potentially additional parameters characterizing the vendor specific modulation. 3.1.3. FEC Type List sub-TLV When the SC bit in the RP Object is set to 1, then the RP object should include the FEC Type List TLV associated with the request. FEC types listed in the FEC Type List TLV indicate allowable modulation types in both the source (transmitter) and the sink (receiver). The FEC type list sub-TLV may consist of two different types of fields: a standard FEC field or a vendor specific FEC field. Both start with the same 32 bit header shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|I| FEC ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional FEC parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the FEC ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where S bit set to 1 indicates a standardized FEC format and S bit set to 0 indicates a vendor specific FEC format. The length is the length in bytes of the entire FEC type field. Where the length is the length in bytes of the entire FEC type field. Where I bit set to 1 indicates an input FEC format and where I bit set to 0 indicates an output FEC format. Note that the source FEC Lee Expires April 19, 2010 [Page 7] Internet-Draft PCEP Extension for WSON RWA October 2009 type is implied when I bit is set to 0 and that the sink FEC type is implied when I bit is set to 1. The format for input standard FEC field at the sink is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| FEC ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional FEC parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the FEC ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Takes on the following currently defined values for the standard FEC ID: 0 Reserved 1 G.709 RS FEC 2 G.709V compliant Ultra FEC The format for input vendor-specific FEC field at the sink is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Vendor FEC ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Any vendor specific additional FEC parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee Expires April 19, 2010 [Page 8] Internet-Draft PCEP Extension for WSON RWA October 2009 Vendor FEC ID This is a vendor assigned identifier for the FEC type. Enterprise Number A unique identifier of an organization encoded as a 32-bit integer. Enterprise Numbers are assigned by IANA and managed through an IANA registry [RFC2578]. Vendor Specific Additional FEC parameters There can be potentially additional parameters characterizing the vendor specific FEC. 3.1.4. The GPID Type Sub-TLV When the SC bit in the RP Object is set to 1, then the RP object should include the GPID Type sub-TLV with the path request. The GPID Type should be one of Generalized Protocol Identifiers (GPIDs). GPIDs are assigned by IANA and many are defined in [RFC3471] and [RFC4328]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GPID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where GPID is an identifier encoded as a 32-bit integer. 3.2. The PCE to PCC Interface This section provides the enhancements to the RP Object and its associated sub-TLV in the PC Reply message from the PCE to the PCC interface to support signal compatibility constraints. The PCE MUST specify the detail signal compatibility information in response to the "SC" (Signal Compatibility) request made by the PCC. The ERO object in the PC Rep message MUST include the following TLV if the SC-bit is set in the RP object in the PC Req message: Lee Expires April 19, 2010 [Page 9] Internet-Draft PCEP Extension for WSON RWA October 2009 o Modulation Type TLV o FEC Type TLV o Regeneration Point TLV Note that each of the TLV defined above would be in an ERO as subobjects placed after the node identifier (IP address). 3.2.1. Modulation Type TLV The modulation type sub-TLV indicates the output modulation type associated with the node identifier. It starts with the same 32 bit header shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Modulation ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.2. FEC Type TLV The FEC type sub-TLV indicates the output FEC type associated with the node identifier. It starts with the same 32 bit header shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.3. Regeneration Point TLV The Regeneration Point TLV indicates this particular node is a regeneration point. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | C | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee Expires April 19, 2010 [Page 10] Internet-Draft PCEP Extension for WSON RWA October 2009 Where T bit indicates the type of regenerator: T=0: Reserved T=1: 1R Regenerator T=2: 2R Regenerator T=3: 3R Regenerator Where C bit indicates the capability of regenerator: C=0: Reserved C=1: Fixed Regeneration Point C=2: Selective Regeneration Pools Note that when the capability of regenerator is indicated to be Selective Regeneration Pools, regeneration pool properties such as ingress and egress restrictions and availability need to be specified. This encoding is to be determined in the later revision. 4. Manageability Considerations This document does not add additional manageability considerations. 5. Security Considerations This document has no requirement for a change to the security models within PCEP [PCEP]. However the additional information distributed in order to address the RWA problem represents a disclosure of network capabilities that an operator may wish to keep private. Consideration should be given to securing this information. 6. IANA Considerations A future revision of this document will present requests to IANA for codepoint allocation. Lee Expires April 19, 2010 [Page 11] Internet-Draft PCEP Extension for WSON RWA October 2009 7. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "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., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", RFC 5440, March 2009. [CompatOSPF] Lee, Y. and Bernstein, G., "OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", draft-lee-ccamp-wson-signal- compatibility-ospf, work in progress. Lee Expires April 19, 2010 [Page 12] Internet-Draft PCEP Extension for WSON RWA October 2009 8.2. Informative References [WSON-IMP] Lee, Y. and Bernstein, G. (Editors), D. Li, G. Martinelli, "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments", draft-ietf-ccamp-wson- impairments, work in progress. [WSON-Frame] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks", draft-ietf-ccamp-rwa-wson-framework, work in progress. [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. Authors' Addresses Young Lee (Ed.) Huawei Technologies 1700 Alma Drive, Suite 100 Plano, TX 75075, USA Phone: (972) 509-5599 (x2240) Email: ylee@huawei.com Greg Bernstein (Ed.) Grotto Networking Fremont, CA, USA Phone: (510) 573-2237 Email: gregb@grotto-networking.com Intellectual Property Statement 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 under such rights might or might not be available; nor does it Lee Expires April 19, 2010 [Page 13] Internet-Draft PCEP Extension for WSON RWA October 2009 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. 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 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lee Expires April 19, 2010 [Page 14]