CCAMP Working Group Haomian Zheng Internet Draft Italo Busi Intended status: Informational Huawei Yunbin Xu CAICT Ricard Vilalta CTTC Expires: April 2018 October 30, 2017 Analysis of Transport North Bound Interface Use Case 3 draft-tnbidt-ccamp-transport-nbi-analysis-uc3-00 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 30, 2018. 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 Zheng, Busi et al. Expires April 30, 2018 [Page 1] Internet-Draft T-NBI Use Case 3 Analysis October 2017 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 This document analyses how YANG models being defined by IETF (TEAS and CCAMP WG in particular) can be used to support Use Case 3 (multi- domain with single-layer) scenarios as referenced later in this document. Table of Contents 1. Introduction...................................................3 1.1. Assumptions...............................................3 1.2. Feedbacks provided to the IETF Working Groups.............3 2. Conventions used in this document..............................3 3. Scenario Overview..............................................3 3.1. Topology Abstractions.....................................4 3.1.1. Single Domain Topology...............................5 3.1.2. Multi-domain Topology Stitching......................6 3.2. Multi-domain Service Configuration........................7 3.2.1. Procedure Description................................7 3.2.2. ODU Transit Service..................................9 3.2.3. EPL over ODU Service.................................9 3.2.4. Other OTN Client Services............................9 3.3. Protection Scenarios......................................9 3.3.1. Linear Protection (end-to-end).......................9 3.3.2. Segmented Protection.................................9 4. Topology Abstraction: detailed JSON examples..................10 5. Service Configuration: detailed JSON examples.................10 5.1. ODU Transit Service......................................10 6. Security Considerations.......................................10 7. IANA Considerations...........................................10 8. Conclusions...................................................10 9. References....................................................10 9.1. Normative References.....................................10 9.2. Informative References...................................11 10. Acknowledgments..............................................11 Zheng, Busi et al. Expires April 30, 2018 [Page 2] Internet-Draft T-NBI Use Case 3 Analysis October 2017 1. Introduction This document analyses how YANG models developed by IETF (TEAS and CCAMP WG) can be used to support Use Case 3 (multi-domain with single-layer) scenarios as described in [TNBI-UseCases]. 1.1. Assumptions This document is using the ACTN [ACTN-Fwk] as an architecture that deploys the IETF models. The motivation of this draft is to analyze how existing IETF models can be used on the MPI between the PNC and the MDSC to support the use case 3 scenarios as defined in section 6 of [TNBI-UseCases]. This document assumes the applicability of the YANG models to the ACTN interfaces as defined in [ACTN-YANG] and therefore considers the TE Topology YANG model defined in [TE-TOPO], with the OTN Topology augmentation defined in [OTN-TOPO] and the TE Tunnel YANG model defined in [TE-TUNNEL], with the OTN Tunnel augmentation defined in [OTN-TUNNEL]. In this document, the assumptions made in section 1 of [TNBI-UseCase- 1] still apply. In summary, it is assumed that 1) MDSC uses the explicit-route-object list on MPI to specify the ingress/egress links for a tunnel segment request, and 2) label and TS availability information are reported from PNC to MDSC. 1.2. Feedbacks provided to the IETF Working Groups The analysis done in this version of this document has triggered the following feedbacks to TEAS WG: o Updates to the plug-id definition in [TE-TOPO] to support plug-id also when auto-discovery (e.g., LMP based) mechanisms are used on inter-domain links 2. Conventions used in this document The conventions defined in section 2 of [TNBI-UseCase-1] still apply in this document. 3. Scenario Overview Use Case 3 is described in [TNBI-Use Cases] as a multi-domain with single layer network scenario supporting different types of services. This section provides a high-level overview of how IETF YANG models Zheng, Busi et al. Expires April 30, 2018 [Page 3] Internet-Draft T-NBI Use Case 3 Analysis October 2017 can be used to support these uses cases at the MPI between the Transport PNC and the MDSC. Section 3.1 describes the different topology abstractions provided to the MDSC by each PNC via its own MPI. The reference network and controlling hierarchy is defined in section 6.1 of [TNBI-Use Cases]. Section 3.2 describes how the difference services, defined in section 6.3 of [TNBI-UseCases], can be setup by the MDSC by coordinating requests to each PNC via their own MPIs. Section 3.3 describes how the protection scenarios can be deployed, including end-to-end protection and segment protection, for both intra-domain and inter-domain scenario. 3.1. Topology Abstractions The reference network is shown in Figure 1, which is the same as Figure 3 of [TNBI-UseCases]: Zheng, Busi et al. Expires April 30, 2018 [Page 4] Internet-Draft T-NBI Use Case 3 Analysis October 2017 ........................ .......... : : : : : Network domain 1 : ............. :Customer: : : : : :domain 1: : S1 -------+ : : Network : : : : / \ : : domain 3 : .......... : C-R1 ------- S3 ----- S4 \ : : : : : : : : \ \ S2 --------+ : :Customer: : : : \ \ | : : \ : :domain 3: : : : S5 \ | : : \ : : : : C-R2 ------+ / \ \ | : : S31 --------- C-R7 : : : : \ / \ \ | : : / \ : : : : : : S6 ---- S7 ---- S8 ------ S32 S33 ------ C-R8 : : : : / | | : : / \ / : :........: : C-R3 ------+ | | : :/ S34 : : : :..........|.......|...: / / : :........: | | /:.../.......: | | / / ...........|.......|..../..../... : | | / / : .......... : Network | | / / : : : : domain 2 | | / / : :Customer: : S11 ---- S12 / : :domain 2: : / | \ / : : : : S13 S14 | S15 ------------- C-R4 : : | \ / \ | \ : : : : | S16 \ | \ : : : : | / S17 -- S18 --------- C-R5 : : | / \ / : : : : S19 ---- S20 ---- S21 ------------ C-R6 : : : : : :...............................: :........: Figure 1 Reference Topology The network is portioned in three domains with inter-domain links connecting the domains with each other. The controlling hierarchy is shown in Figure 3 of [TNBI-UseCases]: the three PNCs are responsible for the topology abstraction and device configuration for their respective domains, and the MDSC is used to coordinate the 3 domains. 3.1.1. Single Domain Topology Each PNC reports its respective topology to the MDSC with different abstraction method, as described in section 6.2 of [TNBI-UseCases]. Zheng, Busi et al. Expires April 30, 2018 [Page 5] Internet-Draft T-NBI Use Case 3 Analysis October 2017 The physical topology of domain 1 and the topology abstraction (i.e., white topology abstraction) provided by PNC1 are the same as those described in section 3.1.1 of [TNBI-UseCase-1] for the single domain topology abstraction use case. PNC2 provides a "type A grey topology abstraction": only one abstract node (i.e., AN2), with only inter-domain and access links, is reported at the MPI2. PNC3 provides a "type B grey topology abstraction": two abstract nodes (i.e., AN31 and AN32), with internal links, inter-domain links and access links, are reported at the MPI3. 3.1.2. Multi-domain Topology Stitching As assumed in the beginning of this section, MDSC does not have any knowledge of the topologies of each domain until each PNC reports its own abstraction topology, so the MDSC needs to merge together the abstract topologies provided by different PNCs, at the MPIs, to build its own topology view, as described in section 4.3 of [TE-TOPO]. Given the topologies reported from multiple PNCs, the MDSC need to stitch the multi-domain topology and obtain the full map of topology. The topology of each domain main be in an abstracted shape (refer to section 5.2 of [ACTN-Fwk]for different level of abstraction), while the inter-domain link information MUST be complete and fully configured by the MDSC. The inter-domain link information is reported to the MDSC by the two PNCs, controlling the two ends of the inter-domain link. The MDSC needs to understand how to "stitch" together these inter- domain links. One possibility is to use the plug-id information, defined in [TE- TOPO]: two inter-domain links reporting the same plug-id value can be merged as a single intra-domain link within any MDSC native topology. The value of the reported plug-id information can be either assigned by a central network authority, and configured within the two PNC domains, or it can be discovered using automatic discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]). In case the plug-id values are assigned by a central authority, it is under the central authority responsibility to assign unique values. In case the plug-id values are automatically discovered, the information discovered by the automatic discovery mechanisms needs to Zheng, Busi et al. Expires April 30, 2018 [Page 6] Internet-Draft T-NBI Use Case 3 Analysis October 2017 be encoded as a bit string within the plug-id value. This encoding is implementation specific but the encoding rules need to be consistent across all the PNCs. In case of co-existence within the same network of multiple sources for the plug-id (e.g., central authority and automatic discovery or even different automatic discovery mechanisms), it is RECOMMENDED that the plug-id namespace is partitioned to avoid that different sources assign the same plug-id value to different inter-domain link. The encoding of the plug-id namespace within the plug-id value is implementation specific but needs to be consistent across all the PNCs. Another possibility is to pre-configure, either in the adjacent PNCs or in the MDSC, the association between the inter-domain link identifiers (topology-id, node-id and tp-id) assigned by the two adjacent PNCs to the same inter-domain link. This option requires further investigation. 3.2. Multi-domain Service Configuration Multi-domain service configuration can be found in section 6.3 of [TNBI-Usecases]. As an example, the objective in this section is to configure a transport service between C-R1 and C-R5. The cross-domain routing is assumed to be C-R1 <-> S3 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 <-> C-R5. According to the different client signal type, there is different adaptation required. In this document, we are trying our best to reuse what has been defined in [TNBI-UseCase-1], which is the single domain case. 3.2.1. Procedure Description The service configuration procedure is assumed to be initiated (step 1 in Figure 2) at the CMI from CNC to MDSC, using XXX(LxSM, transport-service, VN, TBD) service models. The MDSC will understand this configure as as a request to setup a service from node A to node Z. Analysis of the CMI models is for further study. Zheng, Busi et al. Expires April 30, 2018 [Page 7] Internet-Draft T-NBI Use Case 3 Analysis October 2017 | | {1} V ---------------- | {2} | | {3} MDSC | | | ---------------- ^ ^ ^ {3.1} | | | +---------+ |{3.2} | | | +----------+ | V | | ---------- |{3.3} | | PNC2 | | | ---------- | | ^ | V | {4.2} | ---------- V | | PNC1 | ----- V ---------- (Network) ---------- ^ ( Domain 2) | PNC3 | | {4.1} ( _) ---------- V ( ) ^ ----- C==========D | {4.3} (Network) / ( ) \ V ( Domain 1) / ----- \ ----- ( )/ \ (Network) A===========B \ ( Domain 3) / ( ) \( ) AP-1 ( ) X===========Z ----- ( ) \ ( ) AP-2 ----- Figure 2 Multi-domain Service Setup After receiving such request, MDSC determines the domain sequence, i.e., domain 1 <-> domain 2 <-> domain 3, with corresponding PNCs and inter-domain links (step 1 in Figure 2). As described in [PATH-COMPUTE], the domain sequence can be determined by running the MDSC own path computation on the MDSC internal topology, defined in section 3.1.2, if and only if the MDSC has enough topology information. Otherwise the MDSC can send path computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 in Zheng, Busi et al. Expires April 30, 2018 [Page 8] Internet-Draft T-NBI Use Case 3 Analysis October 2017 Figure 2) and use this information to determine the optimal path on its internal topology and therefore the domain sequence. The MDSC will then decompose the tunnel request into a few tunnel segments via tunnel model (including both TE tunnel model and OTN tunnel model), and request different PNCs to setup each intra-domain tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 2). Assume that each intra-domain tunnel segment can be set up successfully, and each PNC response to the MDSC respectively. Based on each segment, MDSC will take care of the configuration of both the intra-domain tunnel segment and inter-domain tunnel via corresponding MPI (via TE tunnel model and OTN tunnel model). More specifically, for the inter-domain configuration, the ts bitmap and tpn information need to be configured via OTN tunnel model. . Then the end-to-end OTN tunnel will be ready. In any case, the access link configuration is done only on the PNCs that control the access links (e.g., PNC-1 and PNC-3 in our example) and not on the PNCs of transit domain (e.g., PNC-2 in our example). Access link will be configured by MDSC after the OTN tunnel is set up. Access configuration is different and dependent on the different type of service. More details can be found in the following sections. 3.2.2. ODU Transit Service To be added 3.2.3. EPL over ODU Service To be added 3.2.4. Other OTN Client Services To be added 3.3. Protection Scenarios 3.3.1. Linear Protection (end-to-end) To be added 3.3.2. Segmented Protection To be added Zheng, Busi et al. Expires April 30, 2018 [Page 9] Internet-Draft T-NBI Use Case 3 Analysis October 2017 4. Topology Abstraction: detailed JSON examples To be added 5. Service Configuration: detailed JSON examples 5.1. ODU Transit Service To be added 6. Security Considerations This section is for further study 7. IANA Considerations This document requires no IANA actions. 8. Conclusions This section is for further study 9. References 9.1. Normative References [ACTN-Fwk] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction and Control of Transport Networks", draft-ietf-teas-actn- framework, work in progress. [TNBI-UseCases] Busi, I., King, D. et al, "Transport Northbound Interface Use Cases", draft-ietf-ccamp-transport-nbi-use- cases, work in progress. [TNBI-UseCase-1] Busi, I., King, D. et al, "Analysis of Transport North Bound Interface Use Case 1", draft-tnbidt-ccamp- transport-nbi-analysis-uc1, work in progress. [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", draft- ietf-teas-yang-te-topo, work in progress. [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical Transport Network Topology", draft-ietf-ccamp-otn-topo-yang, work in progress. Zheng, Busi et al. Expires April 30, 2018 [Page 10] Internet-Draft T-NBI Use Case 3 Analysis October 2017 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang- te, work in progress. [PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for requesting Path Computation", draft-busibel-teas-yang-path- computation, work in progress. [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft- sharma-ccamp-otn-tunnel-model, work in progress. 9.2. Informative References [RFC6898] Li, D. et al., "Link Management Protocol Behavior Negotiation and Configuration Modifications", RFC 6898, March 2013. [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks", draft-zhang-teas-actn-yang, work in progress. [I2RS-TOPO] Clemm, A. et al., "A Data Model for Network Topologies", draft-ietf-i2rs-yang-network-topo, work in progress. 10. Acknowledgments The authors would like to thank all members of the Transport NBI Design Team involved in the definition of use cases, gap analysis and guidelines for using the IETF YANG models at the Northbound Interface (NBI) of a Transport SDN Controller. The authors would like to thank Xian Zhang, Anurag Sharma, Sergio Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated the work on gap analysis for transport NBI and having provided foundations work for the development of this document. The authors would like to thank the authors of the TE Topology and Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular Igor Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their support in addressing any gap identified during the analysis work. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Zheng, Busi et al. Expires April 30, 2018 [Page 11] Internet-Draft T-NBI Use Case 3 Analysis October 2017 Haomian Zheng (Editor) Huawei Email: zhenghaomian@huawei.com Italo Busi Huawei Email: italo.busi@huawei.com Yunbin Xu (Editor) CAICT Email: xuyunbin@ritt.cn mailto:d.king@lancaster.ac.uk Ricard Vilalta CTTC Email: ricard.vilalta@cttc.es Carlo Perocchio Ericsson Email: carlo.perocchio@ericsson.com Gianmarco Bruno Ericsson Email: gianmarco.bruno@ericsson.com Zheng, Busi et al. Expires April 30, 2018 [Page 12]