Network Working Group PC. Fu Internet-Draft JZ. FU Intended status: Standards Track Huawei Technologies Expires: May 1, 2017 AJ. Wang RQ. Jing China Telecom October 28, 2016 A YANG Model for IP Link and Transport Service Mapping draft-fu-pce-ip-link-transport-service-mapping-01 Abstract IP+optical is a cross-layer collaboration technology for unified management of IP and optical networks. Based on framework proposed in [ACTN-FWK][I-D.ietf-teas-actn-framework], this draft presents specific information about the IP+optical solution: hierarchical controllers + disabled GMPLS UNIs. This solution does not involve UNI tunnel objects. Therefore, the mapping between IP links and transport services is key point of this solution. This draft provides a YANG model for the RESTCONF/NETCONF protocol. This YANG module defines NBIs for the IP+optical super controller. 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]. 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 May 1, 2017. Fu, et al. Expires May 1, 2017 [Page 1] Internet-Draft October 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. IP+optical solution . . . . . . . . . . . . . . . . . . . 2 1.2. Unified cross-layer algorithm . . . . . . . . . . . . . . 6 1.3. IP+VNT algorithm . . . . . . . . . . . . . . . . . . . . 7 1.4. IP Link and Transport Service Mapping . . . . . . . . . . 8 2. IP Link and Transport Service Mapping Model - YANG Tree . . . 10 3. IP Link and Transport Service Mapping Model - YANG Code . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Normative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction 1.1. IP+optical solution IP+optical is a cross-layer collaboration technology for unified management of IP and optical networks. IP+optical adopts the C/S architecture, where the IP network is the client-layer network and the optical network is the server-layer network. The mapping between IP-layer IP links and transport services is the key ability of an IP+optical network. Through the mapping, the services of IP layers and those of transport layers can be associated to implement use cases of IP+optical scenarios. IP+optical use cases include multi-layer topology visualization, automated network deployment, multi-layer automated service deployment, multi-layer protection and restoration, multi-layer optimization, and multi-layer maintenance window. Fu, et al. Expires May 1, 2017 [Page 2] Internet-Draft October 2016 Based on framework proposed in [ACTN- FWK][I-D.ietf-teas-actn-framework], this draft presents specific information about the IP+optical solution: hierarchical controllers + disabled GMPLS UNIs. This solution does not involve UNI tunnel objects. Therefore, the mapping between IP links and transport services is key point of this solution. The IP+optical solution implements cross-layer service provisioning through cross-layer link and association of multi-layer topologies. After service provisioning, this solution is required to present multi-layer service views for users to learn service status. In addition, the association management function needs to be available during fault demarcation and locating and cross-layer protection and restoration. To meet these demands, a service mapping needs to be maintained between IP-layer IP links and optical-layer transport services. +----------+ |IP+Optical| | Super | |Controller| +-/------\-+ / \ +---------/--+ +--\--------+ | IP | | Optical | | Controller | |Controller | +----+-------+ +---+-------+ | | +----+----------------+-------------+ /R | R |R R / / R R | / IP / R . R . | R R / Layer +-------------------------+---------+ . . . . | . . . . . . | . . . . . . | . . . . . . | . . . . . . | . . +---------------------+-------------+ / O . O . O . | O O / / O . O O / Optical / O O O O O / Layer +-----------------------------------+ Figure 1: IP+optical solution In real-world situations, IP+optical super controllers can be separately deployed or combined with other controllers. For example, in IP+optical single-domain scenarios, an IP+optical super controller Fu, et al. Expires May 1, 2017 [Page 3] Internet-Draft October 2016 can be combined with an IP domain controller. In IP multi-domain and optical multi-domain scenarios, you can deploy one separate IP super controller and one separate optical super controller. The two super controllers communicate through RESTConf interfaces and use the IP+VNT algorithm to complete E2E cross-layer path calculation. In such multi-domain scenarios, you can also deploy only one IP+optical super controller and use a unified cross-layer algorithm in the controller to complete E2E cross-layer path calculation. +----------+ |IP+Optical| | Super | |Controller| +--/-----\-+ / \ / +--\--------+ / | Optical | / |Controller | / +---+-------+ / | +-----/---------------+-------------+ /R / R |R R / / R R | / IP / R . R . | R R / Layer +-------------------------+---------+ . . . . | . . . . . . | . . . . . . | . . . . . . | . . . . . . | . . +---------------------+-------------+ / O . O . O . | O O / / O . O O / Optical / O O O O O / Layer +-----------------------------------+ Figure 2: IP+optical single-domain scenarios Fu, et al. Expires May 1, 2017 [Page 4] Internet-Draft October 2016 +--------------------+ | IP+Optical | | Super | | Controller | +/--------+---------\+ / | \ +-----------/+ +-----+-----+ +-\---------+ | IP | | Optical | | Optical | | Controller | |Controller | |Controller | +--------+---+ +-+---------+ +-------+---+ | | | +-+---------+---------------------+-------+ /R | R | R R | R / / . | . | R . R . | / IP / . R . R | . . R . . R | R / Layer +---.--.-.------+----.----------.-----+---+ . . . . | . . . . . . | . . . . . | . . . . . . | . . . . . | . . . . . . | . . . . . | . . . . . . | . . . . . | . . . . . . | . +--.-.------+----.----+ +---.-----+-------+ /O . O O | . O . / /. . O | O / / O O/ / O O | / Optical / O O / / O O / Layer +---------------------+ +-----------------+ Figure 3: IP domain and optical multi-domain scenarios-1 Fu, et al. Expires May 1, 2017 [Page 5] Internet-Draft October 2016 +------------+ +--------------------+ | IP | | IP+Optical | | Controller +------+ Controller | +-------+----+ +---+-------------+--+ | | | | | | | +--------+--+ +-----+-----+ | | Optical | | Optical | | |Controller | |Controller | | +--+--------+ +-------+---+ | | | +-+---------+---------------------+-------+ /R | R | R R | R / / . | . | R . R . | / IP / . R . R | . . R . . R | R / Layer +---.--.-.------+----.----------.-----+---+ . . . . | . . . . . . | . . . . . | . . . . . . | . . . . . | . . . . . . | . . . . . | . . . . . . | . . . . . | . . . . . . | . +--.-.------+----.----+ +---.-----+-------+ /O . O O | . O . / /. . O | O / / O O/ / O O | / Optical / O O / / O O / Layer +---------------------+ +-----------------+ Figure 4: IP domain and optical multi-domain scenarios-2 1.2. Unified cross-layer algorithm In this model, inter-layer path computation is performed by a single PCE of a Unified controller that has topology visibility into all layers. Such a PCE is called a multi-layer PCE. In Figure 2, the network is comprised of two layers. NEs H1, H2,H3, and H4 belong to the higher layer, and NEs H2, H3, L1, and L2 belong to the lower layer. The PCE is a multi-layer PCE that has visibility into both layers. It can perform end-to-end path computation across layers (single PCE path computation). For instance, it can compute an optimal path H1-H2-L1-L2-H3-H4. Of course, more complex cooperation may be required if an optimal end-to-end path is desired. Fu, et al. Expires May 1, 2017 [Page 6] Internet-Draft October 2016 Controller +-----------------------------------+ | +--------------+ | | |Multilayer-PCE| | | +--------------+ | | +--------++-----------++--------+ | | |IP ||Cross-Layer||Optical | | | |Topology||Topology ||Topology| | | +--------++-----------++--------+ | +----------------+------------------+ | | | ----- ----- | ----- ----- | R |--| R |........|.......| R |--| R | | H1 | | H2 | | H3 | | H4 | ----- -----\ /----- ----- \----- -----/ | O |--| O | | L1 | | L2 | ----- ----- Figure 5: Unified cross-layer algorithm 1.3. IP+VNT algorithm In this model, there is at least one PCE of controller per layer, and each PCE of controller has topology visibility restricted to its own layer. Some providers may want to keep the layer boundaries due to factors such as organizational and/or service management issues. The choice for multiple PCE computation instead of single PCE computation may also be driven by scalability considerations, as in this mode a PCE only needs to maintain topology information for one layer (resulting in a size reduction for the Traffic Engineering Database (TED)). Figure 3 shows multiple PCE inter-layer computation with inter-PCE communication. There is one PCE in each layer. The PCEs from each layer collaborate to compute an end-to-end path across layers. An IP-PCE of IP-domain controller uses IP topology and VNT topology information to perform path calculation at the higher layer. If a VNT link is selected, the IP-domain controller collaborates with the optical-domain controller for path calculation. The optical-PCE of optical-domain controller then uses cross-layer topology and optical topology information to calculate an underlying VNT path.A simple example of cooperation between the PCEs could be as follows: o IP controller sends a request to IP-PCE for a path H1-H4 with ip topo and VNT topo. Fu, et al. Expires May 1, 2017 [Page 7] Internet-Draft October 2016 o IP-PCE selects VNT link as the entry point and exit point to the lower layer. o IP-PCE of IP controller requests a path both ends of VNT link from Optical-PCE of optical controller. o Optical-PCE returns H2-L1-L2-H3 to IP-PCE. o IP-PCE is now able to compute the full path (H1-H2-L1-L2-H3-H4) IP Controller Optical Controller +-----------------------+ +-----------------------------------+ | +------+ | | +-----------+ | | |IP-PCE| +------+ |Optical-PCE| | | +------+ | | +-----------+ | |+--------++-----------+| | +--------++-----------++--------+ | ||IP ||VNT || | |VNT ||Cross-Layer||Optical | | ||Topology||Topology || | |Topology||Topology ||Topology| | |+--------++-----------+| | +--------++-----------++--------+ | +-----------+-----------+ +----------+------------------------+ | | | | | | | | | | ----- ----- VNT Link | ----- ----- | R |-+| R |......................|.| R |--| R | | H1 | | H2 | | | H3 | | H4 | ----- -----\ | /----- ----- \ / \ / \ / \ / \----- -----/ | O |--| O | | L1 | | L2 | ----- ----- Figure 6: IP+VNT algorithm 1.4. IP Link and Transport Service Mapping The mapping varies with IP link interfaces and changes with system creation, dismantlement, and scheduling changes. Fu, et al. Expires May 1, 2017 [Page 8] Internet-Draft October 2016 +-----+ +-----+ | R | IP Link | R | | H1 | | H2 | | @############################@ | | |\ /| | +---- + \ / + ----+ \ / \ Transport Service / \ +-----+ +-----+ / \| |--| |/ @**************@ | O | | O | | L1 | | L2 | | | | | +-----+ +-----+ Figure 7: Physical port connection scenario IP Link +-----+ +-----+ | R O|^^^^^^^^^^^^^^^^^^^^^^^^^^^^|O R | | H1 O|^^^^^^^^^^^^^^^^^^^^^^^^^^^^|O H2 | | O@^^^^^^^^^^^^^^^^^^^^^^^^^^^^@O | | |\ /| | +---- + \ / + ----+ \ / \ Transport Service / \ +-----+ +-----+ / \| |--| |/ @**************@ | O | | O | | L1 | | L2 | | | | | +-----+ +-----+ Figure 8: VLAN port connection scenario Fu, et al. Expires May 1, 2017 [Page 9] Internet-Draft October 2016 +-----+ +-----+ | R | IP Link | R | | H1 @ @ H2 | | E^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^E | | @ \ / @ | +---- +\ \ / /+ ----+ \ \ / / \ \ Transport Service/ / \ \+-----+ +-----+/ / \ @**************@ / \| |/ @**************@ | O | | O | | L1 | | L2 | +-----+ +-----+ Figure 9: Eth-trunk port connection scenario 2. IP Link and Transport Service Mapping Model - YANG Tree (preamble) module: ietf-mapping-ip_link-transport_service +--rw mapping-ip-link-transport-service +--rw mappings* [mapping-id] +--rw mapping-id string +--rw mapping-name? string +--rw ip-links | +--rw ip-link* [ip-link-name] | +--rw ip-link-name string | +--rw ip-link-base? enumeration | +--rw source-node-id? string | +--rw source-if-id? uint32 | +--rw sink-node-id? string | +--rw sink-if-id? uint32 | +--rw bandwidth? decimal64 | +--rw delay? decimal64 | +--rw srlg? decimal64 | +--rw ip-optical? protection-type +--rw transport-service +--rw transport-service-id? uint32 +--rw bandwidth? decimal64 +--rw delay-limit? decimal64 +--rw delayvariation-limit? decimal64 +--rw srlg? decimal64 +--rw ip-optical? protection-type +--rw supporting-tunnel-name? string (postamble) Fu, et al. Expires May 1, 2017 [Page 10] Internet-Draft October 2016 3. IP Link and Transport Service Mapping Model - YANG Code (preamble) module ietf-mapping-ip_link-transport_service { namespace "urn:ietf:params:xml:ns:yang: ietf-mapping-ip_link-transport_service"; prefix "ip-trans-map"; organization "Huawei Technologies"; contact "fupengcheng@huawei.com"; description "The YANG module defines a mapping between ip link and transport."; revision 2016-10-28 { description "Initial revision."; } /* Features */ feature ip-link { description "ip-link paras"; } feature transport { description "transport paras"; } /* Typedefs */ typedef protection-type { type string; description "ip or optical protection type."; } /* Groupings */ grouping ip-link-paras { container ip-links { list ip-link { key ip-link-name; leaf ip-link-name { type string; description Fu, et al. Expires May 1, 2017 [Page 11] Internet-Draft October 2016 "name of an ip link."; } leaf ip-link-base { type enumeration { enum "physical" { description "physical link."; } enum "vlan-if" { description "vlan if"; } enum "eth-trunk" { description "eth-trunk"; } } } leaf source-node-id { type string; description "source node id."; } leaf source-if-id { type uint32; description "source if id."; } leaf sink-node-id { type string; description "sink node id."; } leaf sink-if-id { type uint32; description "sink if id."; } leaf bandwidth { type decimal64 { fraction-digits 2; } description "bandwidth."; } leaf delay { type decimal64 { fraction-digits 2; Fu, et al. Expires May 1, 2017 [Page 12] Internet-Draft October 2016 } description "delay."; } leaf srlg { type decimal64 { fraction-digits 2; } description "srlg."; } leaf ip-optical { type protection-type; description "IP_Optial."; } description "List of ip links"; } description "Container of ip links"; } description "This grouping defines ip link parameters"; } grouping transport-service-paras { container transport-service { leaf transport-service-id { type uint32; description "transport service id."; } leaf bandwidth { type decimal64 { fraction-digits 2; } description "bandwidth."; } leaf delay-limit { type decimal64 { fraction-digits 2; } description "delay limit."; } Fu, et al. Expires May 1, 2017 [Page 13] Internet-Draft October 2016 leaf delayvariation-limit { type decimal64 { fraction-digits 2; } description "delayvariation limit."; } leaf srlg { type decimal64 { fraction-digits 2; } description "srlg."; } leaf ip-optical { type protection-type; description "IP_Optial."; } leaf supporting-tunnel-name { type string; description " supporting tunnel name."; } } description "This grouping defines transport service parameters"; } /* Main blocks */ container mapping-ip-link-transport-service { list mappings { key mapping-id; leaf mapping-id { type string; description "key of a mapping."; } leaf mapping-name { type string; description "name of a mapping"; } uses ip-link-paras; uses transport-service-paras; } Fu, et al. Expires May 1, 2017 [Page 14] Internet-Draft October 2016 } } (postamble) 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations 6. Acknowledgements 7. Normative References [I-D.ietf-teas-actn-framework] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and Control of Traffic Engineered Networks", draft-ietf-teas- actn-framework-01 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Pengcheng FU Huawei Technologies Email: fupengcheng@huawei.com Jianzhong FU Huawei Technologies Email: fujianzhong@huawei.com Aijun.Wang China Telecom Email: wangaj@ctbri.com.cn Fu, et al. Expires May 1, 2017 [Page 15] Internet-Draft October 2016 Ruiquan Jing China Telecom Email: jingrq@ctbri.com.cn Fu, et al. Expires May 1, 2017 [Page 16]