Internet Engineering Task Force Q. Wang, Ed. Internet-Draft ZTE Intended status: Informational R. Valiveti Expires: September 7, 2017 I. Hussain R. Rao Infinera Corp H. Helvoort Hai Gaoming B.V Y. Xu CAICT March 6, 2017 GMPLS Signalling Extensions for control of B100G OTUCn/ODUCn Network draft-zihc-ccamp-otn-b100g-signalling-00 Abstract This document provides extensions to GMPLS signalling to control the B100G OTUCn/ODUCn Network, as a result of the introduction of new beyond 100G OTUCn/ODUCn signals in ITU-T Recommendation G.709 [G.709-2016]. 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 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 September 7, 2017. Copyright Notice Copyright (c) 2017 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 Wang, et al. Expires September 7, 2017 [Page 1] Internet-Draft GMPLS ODUCn Framework March 2017 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview of the GMPLS Extensions for Support of OTUCn/ODUCn . 3 5. Generalized Label Request . . . . . . . . . . . . . . . . . . 4 5.1. LSP Encoding Type . . . . . . . . . . . . . . . . . . . . 4 5.2. Refination of Traffic Parameters for OTUCn/ODUCn in G.709 4 6. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Label Format . . . . . . . . . . . . . . . . . . . . . . 5 6.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The 2016 version of G.709 [G.709-2016] introduces support for higher rate OTU and ODU signals, termed OTUCn and ODUCn (which have a nominal rate of 100n Gbps). The newly introduced OTUCn and ODUCn represent a very powerful extension to the OTN capabilities, and one which naturally scales to transport any newer clients with bit rates in excess of 100G, as they are introduced. B100G framework document [I-D.zih-ccamp-otn-b100g-fwk] provides a framework to allow the development of protocol extensions to support GMPLS control of OTN as specified in [G.709-2016]. Based on this framework, this document provide Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions to support control of OTUCn/ ODUCn introduced in [G.709-2016]. Note: the RSVP-TE signalling extensions in this document will try to reuse the extensions defined in RFC4328 [RFC4328] and RFC7139 [RFC7139]. Wang, et al. Expires September 7, 2017 [Page 2] Internet-Draft GMPLS ODUCn Framework March 2017 2. Requirements Language 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 [RFC2119]. 3. Terminology OPUCn Optical Payload Unit-Cn ODUCn Optical Data Unit-Cn OTUCn completely standardized Optical Transport Unit-Cn OTUCn-M Optical Transport Unit-Cn with n OxUC overhead instances and M 5G tributary slots OTUCn completely standardized Optical Transport Unit-Cn 4. Overview of the GMPLS Extensions for Support of OTUCn/ODUCn New OTUCn/ODUCn are specified in [G.709-2016]. The corresponding new Signal Types are defined below: completely standardized Optical Transport Unit-Cn (OTUCn) Optical Transport Unit-Cn with n OxUC overhead instances and M 5G tributary slots (OTUCn-M) Optical Data Unit-Cn (ODUCn) A new tributary slot granularity (i.e., 5 Gbps) is described in [G.709-2016]. But this kind of tributary slot (TS) can only be used at ODUCn capable interfaces. Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk) and ODUCn is not supported by [G.709-2016] any more. The implementation of the OTUCn/ODUCn Signal which has been briefly described in [I-D.zih-ccamp-otn-b100g-fwk] is achieved through the bonding of FlexO interfaces, which can also be referred to as PHYs. Higher rate OTUCn is split into n instances of OTUC at the FlexO source nodes. One or more OTUC instances are associated with one FlexO interface. Several end-to-end FlexO connections (PHYs) are bonded together as one FlexO group to carry the OTUCn. The FlexO layer are used as the server layer of the OTUCn signal. Wang, et al. Expires September 7, 2017 [Page 3] Internet-Draft GMPLS ODUCn Framework March 2017 5. Generalized Label Request As desfined in RFC3471 [RFC3471], the Generalized Label Request includes a common part (i.e., used for any switching technology) and a technology dependent part (i.e., the traffic parameters). Both of these two parts are extended in RFC4328 [RFC4328] and RFC7139 [RFC7139] to accommodate GMPLS Signalling to the G.709 transport plane recommendation. In this document, the LSP Encoding Type in the common part and the traffic parameter in the technology dependent part are extended/ refined to accommodate the G.709 Recommendation [G.709-2016]. The other parts are not changed. 5.1. LSP Encoding Type In [G.709-2016], the ODUCn is used as a high-order signal only. Only other lower-rate (i.e. low-order) ODUs can be multiplexed into an ODUCn signal; in other words, no non-OTN client signals can be directly mapped to an ODUCn signal. A new code-points for the LSP LSP Encoding Type is defined: ================================================= Value Type ----- ---- XX G.709 ODUCn (Digital Path) ================================================= Figure 1 5.2. Refination of Traffic Parameters for OTUCn/ODUCn in G.709 Section 3.2 of RFC4328 [RFC4328] defines the initial traffic parameters, and RFC7139 [RFC7139] extend the format by adding the Bit_Rate field and deleting the NMC (Number of Multiplexed Components). This document refine the Traffic Parameter format defined in section 5 RFC7139 [RFC7139]. Wang, et al. Expires September 7, 2017 [Page 4] Internet-Draft GMPLS ODUCn Framework March 2017 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | n | Multiplier (MT) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bit_Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Signal Type: three new signal types (i.e., OTUCn, OTUCn-M, ODUCn) are defined in this document. n (8 bits): "n" is an positive integer and contained in "OTUCn/OTUCn- M/ODUCn", and it can used to represent the bandwidth resource being requested. Also "n" is equal to the number of the OTUC/ODUC/OPUC instances. NVC (Number of Virtual Components) defined in RFC7139 [RFC7139] is not used any more, because virtual concatenation is not support in the [G.709-2016]. MT (Multiplexer): defined in section 3.2.4 of RFC4328 [RFC4328]. Bit_Rate: defined in section 5 of RFC7139 [RFC7139]. This Traffic Parameters for the OTN-TDM-capable Switching Type are carried in the OTN-TDM SENDER_TSPEC object in the Path message and the OTN-TDM FLOWSPEC object in the Resv message. 6. Generalized Label This section defines the format of the OTUCn/OTUCn-M/ODUCn Generalized Label. 6.1. Label Format Following is the GENERALIZED_LABEL object format for OTUCn/OTUCn-M/ ODUCn. Wang, et al. Expires September 7, 2017 [Page 5] Internet-Draft GMPLS ODUCn Framework March 2017 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TPN | IF Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Bit Map of Available/Unavailable Slots | Resvd | NUS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Bit Map of Available/Unavailable Slots | Resvd | NUS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 This GENERALIZED_LABEL object is used to indicate how the ODU client signal is multiplexed into the ODUCn link. Note that the LO OUDj Signal Type is indicated by Traffic Parameters, while the type of ODUCn link is identified by the bonding FlexO capable interfaces carried in the IF_ID RSVP_HOP object. TPN: defined in section 6.1 of RFC7139 [RFC7139]. IF (Interface) Type (8 bits): indicate the interface type of the port that provide support for OTUCn/OTUCn-M/ODUCn, which can be 100G/200G/400G Ethernet PHY interfaces. Length (12 bits): indicates the number of bits of the Bit Map field. This field can also be used to indicate the number of the OTUC/ODUC instances being requested. For example, the number of OTUC/ODUC instances can be derived through the length number divided by 4. Bit Map of Available/Unavailable Slots: when the label is used to set up OTUCn-M path, this field is used to represent the position of unavailable slots, when the label is used to set up ODUCn path, this field is used to represent the slots resource allocated for client. NUS (Number of Unavailable Slots): indicate the number of unavailable slots. This GENERALIZED_LABEL object contains several label blocks, with each block correspond to one OTUC instance. Compatibility: actually, there will be different FlexO interfaces used for carrying OTUCn signal, and the length of the bit map may be different. The label format defined in this document can only support the 100G interface. If the label format is used in the case of 200G/400G interfaces, the bit map field can be extended to Wang, et al. Expires September 7, 2017 [Page 6] Internet-Draft GMPLS ODUCn Framework March 2017 accommodate the slots number. Besides this, byte alignment also needs to be taken into consideration. 6.2. Procedures This section does not change the procedure of RSVP-TE protocol described in section 6.2 of RFC7139 [RFC7139], like birdirectional LSP, LABEL_SET object, except the process procedure at the node. When a downstream node or egress node receives a Path message containing a GENERALIZED_LABEL_REQUEST object for setting up an ODUflex LSP over an ODUCn connection from its upstream neighbor node. The node need to check if there are n Ethernet PHYs (FlexO capable) available for transport ODUflex LSP. When an upstream node receives a Resv message containing a GENERALIZED_LABEL object, it MUST first identify which ODU Signal Type is multiplexed or mapped into which ODU Signal Type according to the Traffic Parameters and the IF_ID RSVP_HOP object in the received message. The IF_ID RSVP_HOP object contains several TLVs, and each of them has an one-to-one relationship with one label block. In another word, which component FlexO interface is used to carry a specific OTUC instance needs to be explicitly specified. In the case of ODUCn-to-OTUCn mapping, the TPN field MUST be set to 0. Bit Map information is not required and MUST NOT be included, so the Length field MUST be set to 0 as well. The NUS field should be set to 0. In the case of ODUCn-to-OTUCn-M mapping, the NUS field is set to indicate the number of unavailable in this connection, and the postions of these slots are indicated by the Bit map field. Unavailable slots can not be assigned to ODUCn. This information is required when provide resource for ODUCn client signal. In the case of ODU Client-to-ODUCn multiplexing, the node MUST retrieve the reserved tributary slots in the ODUCn by its downstream neighbor node according to the position of the bits that are set to 1 in the Bit Map field. The TS granularity is 5G, so that the node can multiplex the ODU Client into the ODUCn based on the TS granularity. The node MUST also retrieve the TPN value assigned by its downstream neighbor node from the label and fill the TPN into the related MSI byte(s) in the OPUCn overhead in the data plane. A new LSP_ATTRIBUTE object needs to be extended to collect the number and position of the unavailable slots at each link in the connection, so the destination node can compute a proper label. Wang, et al. Expires September 7, 2017 [Page 7] Internet-Draft GMPLS ODUCn Framework March 2017 When PCE is involved, an ERO can be used to indicate the nodes and ports passed according to the resouce information at each nodes and ports. Thus the LSP_ATTRIBUTE object used to collect unavailable slots information are not needed any more. 7. Security Considerations TBD 8. IANA Considerations The signal types documented in this draft needs to be allocate by IANA. 9. References 9.1. Normative References [G.709-2012] ITU, "Optical Transport Network Interfaces", ITU Recommendation G.709, February 2012, . [G.709-2016] ITU, "Optical Transport Network Interfaces", ITU Recommendation G.709, July 2016, . [G.709.1] ITU, "Flexible OTN short-reach interface", ITU Recommendation G.709.1, October 2016. [G.798] ITU, "Characteristics of optical transport network hierarchy equipment functional blocks", ITU Recommendation G.798, February 2014, . [G.872-2012] ITU, "The Architecture of Optical Transport Networks", ITU Recommendation G.872, October 2012, . [G.872-2017] ITU, "The Architecture of Optical Transport Networks", ITU Recommendation G.872, October 2012, . Wang, et al. Expires September 7, 2017 [Page 8] Internet-Draft GMPLS ODUCn Framework March 2017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, . [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, . [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, DOI 10.17487/RFC4328, January 2006, . [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", RFC 7062, DOI 10.17487/RFC7062, November 2013, . [RFC7096] Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed., Caviglia, D., Zhang, F., and D. Li, "Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)", RFC 7096, DOI 10.17487/RFC7096, January 2014, . [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., and K. Pithewan, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", RFC 7139, DOI 10.17487/RFC7139, March 2014, . Wang, et al. Expires September 7, 2017 [Page 9] Internet-Draft GMPLS ODUCn Framework March 2017 9.2. Informative References [I-D.zih-ccamp-otn-b100g-fwk] Wang, Q., Zhang, Y., Valiveti, R., Hussain, I., Rao, R., and H. Helvoort, "GMPLS Routing and Signaling Framework for B100G", draft-zih-ccamp-otn-b100g-fwk-00 (work in progress), February 2017. [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, . Authors' Addresses Qilei Wang (editor) ZTE Nanjing CN Email: wang.qilei@zte.com.cn Radha Valiveti Infinera Corp 169 Java Drive Sunnyvale, CA 94089 USA Email: rvaliveti@infinera.com Iftekhar Hussain Infinera Corp 169 Java Drive Sunnyvale, CA 94089 USA Email: IHussain@infinera.com Rajan Rao Infinera Corp 169 Java Drive Sunnyvale, CA 94089 USA Email: rrao@infinera.com Wang, et al. Expires September 7, 2017 [Page 10] Internet-Draft GMPLS ODUCn Framework March 2017 Huub van Helvoort Hai Gaoming B.V Email: huubatwork@gmail.com Yunbin Xu CAICT Beijing CN Email: xuyunbin@ritt.cn Wang, et al. Expires September 7, 2017 [Page 11]