CCAMP Working Group Zafar Ali Internet Draft Manoj Kumar Intended status: Experimental Antonello Bonfanti Akshaya Nadahalli Cisco Systems Fatai Zhang Huawei Technologies Expires: April 30, 2017 October 31, 2016 RSVP-TE Extension for Beyond 100G Signal Types in G.709 Optical Transport Networks (OTNs) draft-ali-ccamp-oducn-signal-type-00.txt 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 April 30, 2017. Copyright Notice Copyright (c) 2016 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. Expires April 2017 [Page 1] Internet-Draft draft-ali-ccamp-ODUCn-signal-type-00.txt This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract RFCs 4328 and 7139 provide signaling extensions in Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features. However, these specifications do not cover the additional Optical channel Data Unit (ODU) containers defined in G.709/Y.1331 for ODUC1, ODUC2, ODUC3, ODUC4, ODUC5, ODUC6, ODUC7, ODUC8 and ODUC9. This document defines new Signal Types for these additional containers. 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]. Table of Contents 1. Introduction ................................................. 2 2. RSVP-TE extension for Beyond 100G Signal Types ............... 3 3. Security Considerations .......................................3 4. IANA Considerations ...........................................3 5. References ....................................................3 5.1. Normative References ......................................3 5.2. Informative References ....................................4 1. Introduction [RFC7139] updates the portions of text related to the Optical channel Data Unit (ODU) described in [RFC4328] to provide extensions to Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) to support control for [G.709-v3] in the OTN-TDM SENDER_TSPEC and OTN-TDM FLOWSPEC objects. However, it does not specify Signal Types for the beyond 100G ODUCn containers defined in [G.709/Y.1331]. This document provides RSVP-TE signaling extensions to support ODUC1, ODUC2, ODUC3, ODUC4, ODUC5, ODUC6, ODUC7, ODUC8 and ODUC9 Signal Types. Expires April 2017 [Page 2] Internet-Draft draft-ali-ccamp-ODUCn-signal-type-00.txt 2. RSVP-TE extension for Beyond 100G Signal Types [RFC7139] defines the format of Traffic Parameters in OTN-TDM SENDER_TSPEC and OTN-TDM FLOWSPEC objects. These traffic parameters have a Signal Type field. This document defines the Signal Types for ODUC1, ODUC2, ODUC3, ODUC4, ODUC5, ODUC6, ODUC7, ODUC8 and ODUC9, as defined in the IANA Considerations section. They are allocated via the Specification Required policy added to the subregistry by [RFC7892]. 3. Security Considerations This document does not introduce any additional security issues beyond those identified in [RFC7139]. 4. IANA Considerations IANA maintains the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry that contains the "OTN Signal Type" subregistry. This document request IANA to add the following signal types in the subregistry via the Specification Required policy [RFC5226]: Value Type ----- ---- TBA1 ODUC1 (100Gbps OTN [G.709/Y.1331]) TBA2 ODUC2 (200Gbps OTN [G.709/Y.1331]) TBA3 ODUC3 (300Gbps OTN [G.709/Y.1331]) TBA4 ODUC4 (400Gbps OTN [G.709/Y.1331]) TBA5 ODUC5 (500Gbps OTN [G.709/Y.1331]) TBA6 ODUC6 (600Gbps OTN [G.709/Y.1331]) TBA7 ODUC7 (700Gbps OTN [G.709/Y.1331]) TBA8 ODUC8 (800Gbps OTN [G.709/Y.1331]) TBA9 ODUC9 (900Gbps OTN [G.709/Y.1331]) These Signal Types are carried in the Traffic Parameters in OTN-TDM SENDER_TSPEC and OTN-TDM FLOWSPEC objects [RFC7139]. 5. References 5.1. Normative References Expires April 2017 [Page 3] Internet-Draft draft-ali-ccamp-ODUCn-signal-type-00.txt [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, <http://www.rfc- editor.org/info/rfc4328>. [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, <http://www.rfc-editor.org/info/rfc7139>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7892] Ali, Z., Bonfanti, A., Hartley, M., and F. Zhang, "IANA Allocation Procedures for the GMPLS OTN Signal Type Registry", RFC 7892, DOI 10.17487/RFC7892, May 2016, <http://www.rfc-editor.org/info/rfc7892>. 5.2. Informative References [G.709-v3] ITU-T, "Interfaces for the optical transport network", Recommendation G.709/Y.1331, June 2016. [G.709/Y.1331] ITU-T, " Interfaces for the optical transport network", G.709/Y.1331 (06/16). [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc- editor.org/info/rfc5226>. [G.709-v3] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709/Y.1331 Recommendation, February, 2012. Authors’ Addresses Zafar Ali Cisco Systems Email: [email protected] Manoj Kumar Cisco System Email: [email protected] Akshaya Nadahalli Cisco Systems [email protected] Antonello Bonfanti Cisco Systems [email protected] Expires April 2017 [Page 4] Internet-Draft draft-ali-ccamp-ODUCn-signal-type-00.txt Fatai Zhang Huawei Technologies Email: [email protected] Expires April 2017 [Page 5] TEAS Working Group Italo Busi Internet Draft Huawei Intended status: Informational Sergio Belotti Expires: April 2017 Nokia Victor Lopez Oscar Gonzalez de Dios Telefonica Anurag Sharma Infinera Yan Shi China Unicom Ricard Vilalta CTTC Karthik Sethuraman NEC October 28, 2016 Yang model for requesting Path Computation draft-busibel-teas-yang-path-computation-00.txt 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), 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 Busi, Belotti, al. Expires April 28, 2017 [Page 1] Internet-DraftYang model for requesting Path Computation October 2016 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 28, 2016. Copyright Notice Copyright (c) 2016 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. Abstract There are scenarios, typically in a hierarchical SDN context, in which an orchestrator may not have detailed information to be able to perform an end-to-end path computation and would need to request lower layer/domain controllers to calculate some (partial) feasible paths. Multiple protocol solutions can be used for communication between different controller hierarchical levels. This document assumes that the controllers are communicating using YANG-based protocols (e.g., NETCONF or RESTCONF). This document describes some use cases for a YANG model to request path computation. Table of Contents 1. Introduction...................................................3 2. Use Cases......................................................4 2.1. IP-Optical integration....................................4 2.1.1. Inter-layer path computation.........................6 2.1.2. Route Diverse IP Services............................8 2.2. Multi-domain TE Networks..................................8 Busi, Belotti, et al. Expires April 28, 2017 [Page 2] Internet-DraftYang model for requesting Path Computation October 2016 2.3. Data center interconnections..............................9 3. Interactions with TE Topology.................................11 3.1. TE Topology Aggregation using the "virtual link model"...11 3.2. TE Topology Abstraction..................................14 3.3. Complementary use of TE topology and path computation....15 4. Motivation for a YANG Model...................................17 4.1. Benefits of common data models...........................17 4.2. Benefits of a single interface...........................18 4.3. Extensibility............................................19 5. Path Optimization Request.....................................19 6. YANG Model for requesting Path Computation....................19 7. Security Considerations.......................................20 8. IANA Considerations...........................................20 9. References....................................................20 9.1. Normative References.....................................20 9.2. Informative References...................................20 10. Acknowledgments..............................................21 1. Introduction There are scenarios, typically in a hierarchical SDN context, in which an orchestrator may not have detailed information to be able to perform an end-to-end path computation and would need to request lower layer/domain controllers to calculate some (partial) feasible paths. When we are thinking to this type of scenarios we have in mind specific level of interfaces on which this request can be applied. We can reference ABNO Control Interface [RFC7491] in which an Application Service Coordinator can request ABNO controller to take in charge path calculation (see Figure 1 in the RFC) and/or ACTN [ACTN-frame],where controller hierarchy is defined, the need for path computation arises on both interfaces CMI (interface between Customer Network Controller(CNC) and Multi Domain Service Coordinator (MDSC)) and/or MPI (interface between MSDC-PNC).[ACTN- Info] describes an information model for the Path Computation request. Multiple protocol solutions can be used for communication between different controller hierarchical levels. This document assumes that the controllers are communicating using YANG-based protocols (e.g., NETCONF or RESTCONF). Busi, Belotti, et al. Expires April 28, 2017 [Page 3] Internet-DraftYang model for requesting Path Computation October 2016 Path Computation Elements, Controllers and Orchestrators perform their operations based on Traffic Engineering Databases (TED). Such TEDs can be described, in a technology agnostic way, with the YANG Data Model for TE Topologies [TE-TOPO]. Furthermore, the technology specific details of the TED are modeled in the augmented TE topology models (e.g. [L1-TOPO] for Layer-1 ODU technologies). The availability of such topology models allows providing the TED using YANG-based protocols (e.g., NETCONF or RESTCONF). Furthermore, it enables a PCE/Controller performing the necessary abstractions or modifications and offering this customized topology to another PCE/Controller or high level orchestrator. The tunnels that can be provided over the networks described with the topology models can be also set-up, deleted and modified via YANG-based protocols (e.g., NETCONF or RESTCONF)using the TE-Tunnel Yang model [TE-TUNNEL]. This document describes some use cases where a path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. 2. Use Cases This section presents different use cases, where an orchestrator needs to request underlying SDN controllers for path computation. The presented uses cases have been grouped, depending on the different underlying topologies: a) IP-Optical integration; b) Multi-domain Traffic Engineered (TE) Networks; and c) Data center interconnections. 2.1. IP-Optical integration In these use cases, an Optical domain is used to provide connectivity between IP routers which are connected with the Optical domains using access links (see Figure 1). Busi, Belotti, et al. Expires April 28, 2017 [Page 4]