CCAMP Working Group Haomian Zheng Internet-Draft Italo Busi Intended status: Standards Track Huawei Zafar Ali Cisco Sergio Belotti Nokia Daniele Ceccarelli Ericsson Daniel King Lancaster University Expires: September 6, 2017 March 6, 2017 Framework for GMPLS Control of Optical Transport Networks in G.709 Edition 5 draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt Abstract The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations Optical Transport Networks (OTNs, G.709) to edition 5 to support new features, including beyond 100 Gbps (B100G) OTN containers. This document summarizes the architecture and requirements, and provides corresponding control plane considerations to guide protocol extensions development in support of OTNv5 control mechanisms. 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." Zheng et al Expires September 2017 [Page 1] draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017 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 6, 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 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 ................................................. 3 1.1. Scope ................................................... 3 2. Terminology .................................................. 3 2.1. Conventions Used in this Document ....................... 3 2.2. OTN Related Terminologies in this Document .............. 3 3. Optical Transport Network Version 5 Overview ................. 4 3.1. OTN B100G Network ....................................... 4 3.1.1. Client Signal Mapping .............................. 4 3.1.2. Supporting clients signals with ODUCn .............. 5 3.2. MSI of ODUCn ............................................ 6 3.3. OTUCn sub rates (OTUCn-M) ............................... 7 4. Connection Management of ODUCn ............................... 7 5. GMPLS Implications ........................................... 8 5.1. Implications for GMPLS Signaling ........................ 8 5.2. Implications for GMPLS Routing .......................... 8 6. Security Considerations ...................................... 9 7. Contributors' Addresses ..................................... 10 8. References .................................................. 10 8.1. Normative References ................................... 10 8.2. Informative References ................................. 11 Authors' Addresses ............................................. 11 Zheng et al Expires September 2017 [Page 2] draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017 1. Introduction ITU-T G.709v3, published in 2012, defined the interfaces to Optical Transport Network (OTN), supporting a variety of Optical Data Unit (ODU) containers up to 100 Gbps and flexible multiplexing hierarchy. The OTN control plane framework was described in [RFC7062], corresponding signaling and routing extensions were further specified in [RFC7139] and [RFC7138] respectively. Furthermore, there were additional updates made to G.709v4, resulting in additional extensions which are described in [RFC7892] and [RFC7963]. To meet the increasing demand for higher client bit rates, Edition 5 of G.709 [ITU-T G.709v5] has been released to provide beyond 100G capabilities by introducing an ODUCn layer, which contains an optical payload unit(OPUCn). This document reviews relevant aspects of beyond 100 Gbps (B100G) OTN technology and how it impacts current GMPLS control-plane protocols. It highlights new considerations and proposes how to update the mechanisms described in [RFC7062] to meet B100G control plane requirements. 1.1. Scope For the purposes of the B100G control plane discussion, the OTN should be considered as a combination of the current OTN ODUk/Cn and the wavelength optical layer. This document focuses on only the control of the ODUk/ODUCn layer. The optical layer control will be addressed in a separate document. 2. Terminology 2.1. 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 [RFC2119]. 2.2. OTN Related Terminologies in this Document Terminologies from section 2 of [RFC7062] are reused in this document, with the following additional terminologies defined in [ITU-T G.709v5] used in this document: ODUCn: Optical Data Unit - Cn Zheng et al Expires September 2017 [Page 3] draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017 OPUCn: Optical Payload Unit- Cn OTUCn: completely standardized Optical Transport Unit-Cn 3. Optical Transport Network Version 5 Overview This section provides an overview of new features provided by G.709v5 Optical Transport Network. 3.1. OTN B100G Network 3.1.1. Client Signal Mapping +-----------------------+-----------------------------------+ | ODU Type | ODU nominal bit rate | +-----------------------+-----------------------------------+ | ODU0 | 1,244,160 Kbps | | ODU1 | 239/238 x 2,488,320 Kbps | | ODU2 | 239/237 x 9,953,280 Kbps | | ODU3 | 239/236 x 39,813,120 Kbps | | ODU4 | 239/227 x 99,532,800 Kbps | | ODUCn | n x 239/226 x 99,532,800 Kbps | | | | | ODUflex for | | |Constant Bit Rate (CBR)| 239/238 x client signal bit rate | | Client signals | | | | | | ODUflex for Generic | | | Framing Procedure | Configured bit rate | | - Framed (GFP-F) | | | Mapped client signal | | +-----------------------+-----------------------------------+ Table 1: ODU Types and Bit Rates NOTE: The nominal ODUCn rates are approximately n x 105,258,138.053 kbit/s. Zheng et al Expires September 2017 [Page 4] draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017 Furthermore, and per [ITU-T G.709v5], the tolerance of ODUCn is +/- 20 ppm. The frame period for ODUCn is 1.163 s. Additionally, it defined 5 Gbps tributary slots for ODU Cn. The number of tributary slots (TS) defined in [ITU-T G.709v5] for each ODU are shown in Table 2. +------------+-------------------------------------+ | | Nominal TS capacity | | ODU Server +-------------------------------------+ | | 1.25 Gbit/s | 2.5 Gbit/s | 5 Gbit/s | +------------+-------------+------------+----------+ | ODU0 | 1 | N/A | N/A | +------------+-------------+------------+----------+ | ODU1 | 2 | N/A | N/A | +------------+-------------+------------+----------+ | ODU2 | 8 | 4 | N/A | +------------+-------------+------------+----------+ | ODU3 | 32 | 16 | N/A | +------------+-------------+------------+----------+ | ODU4 | 80 | N/A | N/A | +------------+-------------+------------+----------+ | ODUCn | N/A | N/A | 20*n | +------------+-------------+------------+----------+ Table 2: Number of tributary slots (TS) 3.1.2. Supporting clients signals with ODUCn According to [ITU-T G.709v5], various client signals can be mapped to be supported by ODUCn. Typical client signal includes Ethernet, MPLS and IP. The signal hierarchies can be found in Figure 1. Client (e.g., IP, Ethernet, MPLS, ...) | OTN client signals (ODUk) | ODUCn Zheng et al Expires September 2017 [Page 5] draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017 | OTUCn Figure 1: Mapping Client Signal to ODUCn Packet streams (e.g., Ethernet, MPLS, IP) which are encapsulated with the generic framing procedure is considered as the client and can be carried by OTN client signals (known as ODUk, including ODU0~4 and ODUflex). Then the OTN client signals will be further mapped into ODUCn containers and multiplexed into OTUCn. It is worth noting that the maximum bit rate for ODUk is 100G (ODU4), which is the same rate of ODUC1. The mapping from ODU client signal to ODU Containers is also required when ODU4 is multiplexed into ODUC1. Examples of multiplexing can be found as follow: - ODU0/ ODU1/ ODU2/ ODU3/ ODU4 into ODUC1 multiplexing with 5Gbps TS granularity: ODU0/ ODU1/ ODU2/ ODU3/ ODU4 occupies 1/1/2/8/20 of the 20 TSs for ODUC1. It is worth noting that for ODU0 and ODU1, the 5G TS is only partially occupied. The type of the transported payload, encoded as the payload type, is set to 22 for ODUCn. 3.2. MSI of ODUCn When multiplexing an OTN client signal into ODUCn, [ITU-T G.709v5] specifies the information that must be transported in-band to correctly demultiplexing the signal. MSI is used to specify the identifier of each multiplexing section. The MSI information is located in the mapping specific area of the PSI signal and is local to each link. The MSI information is organized as a set of entries, with n entries for each OPUC TS. The MSI has a fixed length of 40n bytes and indicates the ODTU content of each tributary slot (TS) of an OPUCn. Two bytes are used for each tributary slot. The information carried by each entry is: - TS availability bit 1 indicates if the tributary slot is available or unavailable. Zheng et al Expires September 2017 [Page 6] draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017 - The TS occupation bit 9 indicates if the tributary slot is allocated or unallocated. - The tributary port number in bits 2 to 8 and 10 to 16 indicates the port number of the ODTUCn.ts that is being transported in this TS; a flexible assignment of tributary port to tributary slots is possible. ODTUC.ts tributary ports are numbered 1 to 10n. The value is set to all-0s when the occupation bit has the value 0 (tributary slot is unallocated). Tributary Port Number (TPN) indicates the port number of the OTN client signal transported by the ODUCn. The TPN is the same for all the TSs assigned to the transport of the same OTN client signal. 3.3. OTUCn sub rates (OTUCn-M) An OTUCn with a bit rate that is not an integer multiple of 100 Gbit/s can be described as an OTUCn-M. An OTUCn-M frame contains n instances of OTUC overhead, ODUC overhead and OPUC overhead together with M 5Gbit/s OPUCn TS. When an OTUCn-M is used to carry an ODUCn (20n-M) TS are marked as unavailable, in the OPUCn multiplex structure identifier (MSI), since they cannot be used to carry a client signal. 4. Connection Management of ODUCn ODUk based connection management has been described in section 4 of [RFC7062]. In this section the connection management of ODUCn is described, which is independent but used together with ODUk based connection management. ODUCn based connection management is concerned with controlling the connectivity of ODUCn paths. According to ITU-T G.872, the intermediate nodes with ODUCn do not support the switching of ODUCn time slot. Intermediate ODUCn points are only considered as a forwarding node. Once an ODUCn path is used to transport client signal, the TS occupied will not change across the ODUCn network. Zheng et al Expires September 2017 [Page 7] draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017 5. GMPLS Implications 5.1. Implications for GMPLS Signaling For OTNv3 network control, [RFC7139] defines RSVP-TE signaling extensions, extending the base specifications [RFC3473] and [RFC4328]. As described in Section 3, [ITU-T G.709v5] introduced some new features including the ODUCn, OTUCn for beyond 100G control. The mechanisms defined in [RFC7139] do not support such features, and protocol extensions SHALL be necessary to allow them to be controlled by a GMPLS control plane. In summary, the following new signaling aspects SHOULD be considered: - Support for specifying new signal types and related traffic information: The traffic parameters should be extended in a signaling message to support the new ODUCn; - Support the new TS granularity: the signaling protocol should be able to identify the TS granularity (i.e., the new 5 Gbps TS granularity) to be used for establishing a Hierarchical LSP that will be used to carry service LSP(s) requiring a specific TS granularity. - Support for LSP setup of new ODUCn containers with related mapping and multiplexing capabilities: A new label format must be defined to carry the exact TS's allocation information related to the extended mapping and multiplexing hierarchy (for example, ODU4 into ODUCn multiplexing (with 5 Gbps TS granularity)), in order to set up all the possible ODU connections. - Support for TPN allocation and negotiation: TPN needs to be configured as part of the MSI information (see more information in Section 3.1.2.1). A signaling mechanism must be identified to carry TPN information if the control plane is used to configure MSI information. - Support for LSP setup of OTUCn sub rates (OTUCn-M) path: based on previous extensions, there should be new signal mechanism to declare the OTUCn-m information. 5.2. Implications for GMPLS Routing The path computation process needs to select a suitable route for an ODUCn connection request. Evaluation of the available bandwidth on each candidate link is required for path computation. The routing Zheng et al Expires September 2017 [Page 8] draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017 protocol SHOULD be extended to carry sufficient information to represent ODU Traffic Engineering (TE) topology. The Interface Switching Capability Descriptors defined in [RFC4203] present a new constraint for LSP path computation. [RFC4203] defines the Switching Capability, related Maximum LSP Bandwidth, and Switching Capability specific information. [RFC7138] updates the ISCD to support ODU4, ODU2e and ODUflex. The new Switching Capability specific information provided in [RFC7138] have to be adapted to support new features contained in [ITU-T G.709v5]. The following requirements should be considered: - Support for carrying the link multiplexing capability: As discussed in Section 3.1.2, many different types of ODUk can be multiplexed into the ODUCn. For example, ODU4 may be multiplexed into ODUC1. An OTUCn link may support one or more types of ODUk signals. The routing protocol should be capable of carrying this multiplexing capability. - Support for additional Tributary Slot Granularity advertisement: as new tributary slot granularity (5G TS) is introduced in [G.709 v5], there is a need to specify this parameter. - Support for advertisement of OTUCn sub rates support information: Given the same n value, there is possible different OTUCn sub rates. Corresponding information should be defined in the routing mechanism to satisfy this feature. 6. Security Considerations TBD. Zheng et al Expires September 2017 [Page 9] draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017 7. Contributors' Addresses Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Antonello Bonfanti Cisco Email: abonfant@cisco.com Dieter Beller Nokia Email: Dieter.Beller@nokia.com 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [ITU-T G.709v5] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709/Y.1331 Recommendation, June 2016. [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, [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006, [RFC7138] D. Ceccarelli, F. Zhang, S. Belotti, R. Rao, J. Drake, 'Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks', RFC7138, March 2014. [RFC7139] F. Zhang, G. Zhang, S. Belotti, D. Ceccarelli, K. Pithewan, 'GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks', RFC7139, March 2014. Zheng et al Expires September 2017 [Page 10] draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017 [RFC7892] Z. Ali, A. Bonfanti, M. Hartley, F. Zhang, 'IANA Allocation Procedures for the GMPLS OTN Signal Type Registry', RFC7892, May 2016. 8.2. Informative References [RFC7062] F. Zhang, D. Li, H. Li, S. Belotti, D. Ceccarelli, 'Framework for GMPLS and PCE Control of G.709 Optical Transport Networks', RFC 7062, November 2013. [RFC7963] Z. Ali, A. Bonfanti, M. Hartley, F. Zhang, 'RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs)', RFC7963, August 2016. Authors' Addresses Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Italo Busi Huawei Technologies Email: Italo.Busi@huawei.com Zafar Ali Cisco Email: zali@cisco.com Sergio Belotti Nokia Email: sergio.belotti@nokia.com Daniele Ceccarelli Ericsson Email: daniele.ceccarelli@ericsson.com Daniel King Lancaster University Email: d.king@lancaster.ac.uk Zheng et al Expires September 2017 [Page 11]