--- 1/draft-ietf-pce-wson-rwa-ext-12.txt 2019-02-07 10:13:18.414449404 -0800 +++ 2/draft-ietf-pce-wson-rwa-ext-13.txt 2019-02-07 10:13:18.462450564 -0800 @@ -1,21 +1,21 @@ Network Working Group Y. Lee, Ed. Internet Draft Huawei Technologies Intended status: Standard Track R. Casellas, Ed. -Expires: August 5, 2019 CTTC +Expires: August 6, 2019 CTTC - February 6, 2019 + February 7, 2019 PCEP Extension for WSON Routing and Wavelength Assignment - draft-ietf-pce-wson-rwa-ext-12 + draft-ietf-pce-wson-rwa-ext-13 Abstract This document provides the Path Computation Element communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Path provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing @@ -34,21 +34,21 @@ 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 August 5, 2019. + This Internet-Draft will expire on August 6, 2019. Copyright Notice Copyright (c) 2019 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 @@ -62,44 +62,44 @@ 1. Terminology....................................................3 2. Requirements Language..........................................3 3. Introduction...................................................3 4. Encoding of a RWA Path Request.................................6 4.1. Wavelength Assignment (WA) Object.........................6 4.2. Wavelength Selection TLV..................................8 4.3. Wavelength Restriction Constraint TLV.....................9 4.3.1. Link Identifier Field...............................11 4.3.2. Wavelength Restriction Field........................12 - 4.4. Signal processing capability restrictions................13 - 4.4.1. Signal Processing Exclusion XRO Sub-Object..........15 - 4.4.2. IRO sub-object: signal processing inclusion.........16 + 4.4. Signal processing capability restrictions................14 + 4.4.1. Signal Processing Exclusion XRO Subobject...........15 + 4.4.2. IRO subobject: signal processing inclusion..........16 5. Encoding of a RWA Path Reply..................................16 5.1. Error Indicator..........................................18 5.2. NO-PATH Indicator........................................18 6. Manageability Considerations..................................19 6.1. Control of Function and Policy...........................19 6.2. Liveness Detection and Monitoring........................19 - 6.3. Verifying Correct Operation..............................19 + 6.3. Verifying Correct Operation..............................20 6.4. Requirements on Other Protocols and Functional Components20 6.5. Impact on Network Operation..............................20 7. Security Considerations.......................................20 8. IANA Considerations...........................................20 8.1. New PCEP Object..........................................20 8.2. New PCEP TLV: Wavelength Selection TLV...................21 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV......21 8.4. New PCEP TLV: Wavelength Allocation TLV..................21 8.5. New PCEP TLV: Optical Interface Class List TLV...........22 8.6. New PCEP TLV: Client Signal TLV..........................22 8.7. New No-Path Reasons......................................22 8.8. New Error-Types and Error-Values.........................23 - 8.9. New Sub-object for the Exclude Route Object..............23 - 8.10. New Sub-object for the Include Route Object.............24 + 8.9. New Subobject for the Exclude Route Object...............23 + 8.10. New Subobject for the Include Route Object..............24 9. Acknowledgments...............................................24 10. References...................................................24 10.1. Normative References....................................24 10.2. Informative References..................................25 11. Contributors.................................................27 Authors' Addresses...............................................28 1. Terminology This document uses the terminology defined in [RFC4655], and @@ -347,31 +347,30 @@ to be returned by the PCE. This TLV is only applied when M bit is set in the WA Object specified in Section 4.1. This TLV MUST NOT be used when the M bit is cleared. The encoding of this TLV is specified as the Wavelength Selection Sub-TLV in Section 4.2.2 of [RFC7689]. 4.3. Wavelength Restriction Constraint TLV For any request that contains a wavelength assignment, the requester - (PCC) MUST be able to specify a restriction on the wavelengths to be - used. This restriction is to be interpreted by the PCE as a - constraint on the tuning ability of the origination laser - transmitter or on any other maintenance related constraints. Note - that if the LSP LSC spans different segments, the PCE MUST have - mechanisms to know the tunability restrictions of the involved - wavelength converters / regenerators, e.g. by means of the Traffic - Engineering Database (TED) either via IGP or Network Management - System (NMS). Even if the PCE knows the tunability of the - transmitter, the PCC MUST be able to apply additional constraints to - the request. + (PCC) MUST specify a restriction on the wavelengths to be used. This + restriction is to be interpreted by the PCE as a constraint on the + tuning ability of the origination laser transmitter or on any other + maintenance related constraints. Note that if the LSP LSC spans + different segments, the PCE must have mechanisms to know the + tunability restrictions of the involved wavelength converters / + regenerators, e.g. by means of the Traffic Engineering Database + (TED) either via IGP or Network Management System (NMS). Even if the + PCE knows the tunability of the transmitter, the PCC must be able to + apply additional constraints to the request. The format of the Wavelength Restriction Constraint TLV is as follows: ::= ( )... @@ -494,33 +493,38 @@ | TE Node ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (8 bits): It indicates the type of the link identifier. Reserved (16 bits): Reserved for future use and SHOULD be zeroed and ignored on receipt. + The Type field is extensible. Please refer to the IANA registry + allocated for Link Management Protocol (LMP) [RFC4204]: + https://www.iana.org/assignments/lmp-parameters/lmp- + parameters.xhtml#lmp-parameters-15. + 4.3.2. Wavelength Restriction Field - The Wavelength Restriction Field of the wavelength restriction TLV - is encoded as a Label Set field as specified in Section 2.6 in - [RFC7579] with base label encoded as a 32 bit LSC label, defined in - [RFC6205]. The Label Set format is repeated here for convenience, - with the base label internal structure included. See [RFC6205] for a - description of Grid, C.S, Identifier and n, as well as [RFC7579] for - the details of each action. + The Wavelength Restriction Field of the Wavelength Restriction + Constraint TLV is encoded as a Label Set field as specified in + Section 2.6 in [RFC7579] with base label encoded as a 32 bit LSC + label, defined in [RFC6205]. The Label Set format is repeated here + for convenience, with the base label internal structure included. + See [RFC6205] for a description of Grid, C.S, Identifier and n, as + well as [RFC7579] for the details of each action. 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action| Num Labels | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S | Identifier | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional fields as necessary per action | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Action (4 bits): @@ -534,20 +538,30 @@ 3 - Exclusive Range 4 - Bitmap Set Num Labels (12 bits): It is generally the number of labels. It has a specific meaning depending on the action value. Length (16 bits): It is the length in bytes of the entire Wavelength Restriction field. + The Identifier has a specific PCEP context. To clarify the + interpretation of the Identifier, the following additional + explanation is added. + + Identifier (9 bits): The value to be included in the "Identifier" + field of the WDM label in RSVP-TE signaling, as defined in section + 3.2 of [RFC6205]. The PCC MAY use the assigned value for the + Identifier field in the corresponding LSP-related messages in RSVP- + TE signaling. + See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional field discussion for each action. 4.4. Signal processing capability restrictions Path computation for WSON includes checking of signal processing capabilities at each interface against requested capability; the PCE MUST have mechanisms to know the signal processing capabilities at each interface, e.g. by means of the Traffic Engineering Database (TED) either via IGP or Network Management System (NMS). Moreover, @@ -578,90 +592,89 @@ ::= [...] Where signal-compatibility-restriction ::= - The encoding for the Optical Interface Class List (TBD5) is described in Section 4.1 of [RFC7581]. The encoding for the Client Signal Information (TBD6) is described in Section 4.2 of [RFC7581]. -4.4.1. Signal Processing Exclusion XRO Sub-Object +4.4.1. Signal Processing Exclusion XRO Subobject The PCC/PCE should be able to exclude particular types of signal processing along the path in order to handle client restriction or multi-domain path computation. [RFC5440] defines how Exclude Route - Object (XRO) sub-object is used. In this draft, we add a new XRO - sub-object, signal processing sub-object. + Object (XRO) subobject is used. In this draft, we add a new XRO + subobject, signal processing subobject. - In order to support the exclusion a new XRO sub-object is defined: + In order to support the exclusion a new XRO subobject is defined: the signal processing exclusion: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type =TBD | Length | Reserved | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-sub objects | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 5 Signaling Processing XRO Sub-Object + Figure 5 Signaling Processing XRO Subobject Refer to [RFC5521] for the definition of X, Length and Attribute. Type (7 bits): The Type of the XRO sub-sub objects. See below for the two TBD values (TBD9 and TBD10) to be assigned by the IANA. Reserved bits (8 bits) are for future use and SHOULD be zeroed and ignored on receipt. The Attribute field (8 bits): [RFC5521] defines several Attribute - values; the only permitted Attribute values for this sub-object are + values; the only permitted Attribute values for this subobject are 0 (Interface) or 1 (Node). The permitted sub-sub objects are the Optical Interface Class List and the Client Signal information whose encodings are described in Section 4.1 and Section 4.2 of [RFC7581], respectively. - The XRO needs to support the new sub-object types: + The XRO needs to support the new subobject types: Type Sub-sub object TBD9 Optical Interface Class List TBD10 Client Signal Information -4.4.2. IRO sub-object: signal processing inclusion +4.4.2. IRO subobject: signal processing inclusion - Similar to the XRO sub-object, the PCC/PCE should be able to include + Similar to the XRO subobject, the PCC/PCE should be able to include particular types of signal processing along the path in order to handle client restriction or multi-domain path computation. - [RFC5440] defines how Include Route Object (IRO) sub-object is used. - In this draft, we add a new IRO sub-object, signal processing sub- - object. + [RFC5440] defines how Include Route Object (IRO) subobject is used. + In this draft, we add a new IRO subobject, signal processing + subobject. - The IRO needs to support the new sub-object types as defined in + The IRO needs to support the new subobject types as defined in Section 4.2 [RFC7689] "WSON Processing Hop Attribute TLV" (TBD9) defined for ERO in Section 4.2 [RFC7689] to the PCEP IRO object [RFC5440]: - Type Sub-sub-object + Type Sub-subobject TBD11 Optical Interface Class List TBD12 Client Signal Information 5. Encoding of a RWA Path Reply This section provides the encoding of a RWA Path Reply for wavelength allocation request as discussed in Section 4. Recall that wavelength allocation can be performed by the PCE by different @@ -931,56 +944,54 @@ TBD8 WSON RWA Error 1: Insufficient [This.I-D] Memory 2: RWA computation [This.I-D] Not supported 3: Syntactical [This.I-D] Encoding error -8.9. New Sub-object for the Exclude Route Object +8.9. New Subobject for the Exclude Route Object The "PCEP Parameters" registry contains a subregistry "PCEP Objects" with an entry for the Exclude Route Object (XRO). IANA is requested to add a further subobject that can be carried in the XRO as follows: - Sub-object Type Reference + Subobject Type Reference ---------------------------------------------------------- - TBD9 Optical Interface Class List [This.I-D] TBD10 Client Signal Information [This.I-D] -8.10. New Sub-object for the Include Route Object +8.10. New Subobject for the Include Route Object The "PCEP Parameters" registry contains a subregistry "PCEP Objects" with an entry for the Include Route Object (IRO). IANA is requested to add a further subobject that can be carried in the IRO as follows: - Sub-object Type Reference + Subobject Type Reference ---------------------------------------------------------- TBD11 Optical Interface Class List [This.I-D] TBD12 Client Signal Information [This.I-D] 9. Acknowledgments - The authors would like to thank Adrian Farrel for many helpful - comments that greatly improved the contents of this draft. - - This document was prepared using 2-Word-v2.0.template.dot. + The authors would like to thank Adrian Farrel and Julien Meuric for + many helpful comments that greatly improved the contents of this + draft. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. @@ -1010,33 +1021,41 @@ [RFC7689] Bernstein et al., "Signaling Extensions for Wavelength Switched Optical Networks", RFC 7689, November 2015. [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", RFC 7688, November 2015. [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017. + [RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS: + Usage of TLS to Provide a Secure Transport for the Path + Computation Element Communication Protocol (PCEP)", RFC + 8253, October 2017. + [PCEP-GMPLS] C. Margaria, et al., "PCEP extensions for GMPLS", draft-ietf-pce-gmpls-pcep-extensions, work in progress. 10.2. Informative References [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471. January 2003. [RFC4203] K. Kompella, Ed., Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. + [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, + October 2005. + [RFC4655] A. Farrel, JP. Vasseur, G. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC5420, February 2009. [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) communication Protocol", RFC 5440, March 2009.[RFC5521] Oki, E, T. Takeda, and A. Farrel, @@ -1054,25 +1073,20 @@ [RFC7446] Y. Lee, G. Bernstein, (Editors), "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", RFC 7446, February 2015. [RFC7449] Y. Lee, G. Bernstein, (Editors), "Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment", RFC 7449, February 2015. - [RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS: - Usage of TLS to Provide a Secure Transport for the Path - Computation Element Communication Protocol (PCEP)", RFC - 8253, October 2017. - [PCEP-LS] Y. Lee, et al., "PCEP Extension for Distribution of Link- State and TE information for Optical Networks", draft-lee- pce-pcep-ls-optical, work in progress. 11. Contributors Fatai Zhang Huawei Technologies Email: zhangfatai@huawei.com