--- 1/draft-ietf-ccamp-transport-nbi-use-cases-00.txt 2017-10-30 11:13:34.712295345 -0700 +++ 2/draft-ietf-ccamp-transport-nbi-use-cases-01.txt 2017-10-30 11:13:34.768296676 -0700 @@ -1,18 +1,19 @@ CCAMP Working Group I. Busi (Ed.) Internet Draft Huawei Intended status: Informational D. King -Expires: April 2018 Lancaster University - October 09, 2017 + Lancaster University + +Expires: April 2018 October 30, 2017 Transport Northbound Interface Applicability Statement and Use Cases - draft-ietf-ccamp-transport-nbi-use-cases-00 + draft-ietf-ccamp-transport-nbi-use-cases-01 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. @@ -21,129 +22,129 @@ 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 Aoril 10, 2018. + 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 + (https://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. + 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 Transport network domains, including Optical Transport Network (OTN) and Wavelength Division Multiplexing (WDM) networks, are typically deployed based on a single vendor or technology platforms. They are often managed using proprietary interfaces to dedicated Element Management Systems (EMS), Network Management Systems (NMS) and increasingly Software Defined Network (SDN) controllers. A well-defined open interface to each domain management system or controller is required for network operators to facilitate control automation and orchestrate end-to-end services across multi-domain networks. These functions may be enabled using standardized data models (e.g. YANG), and appropriate protocol (e.g., RESTCONF). - This document describes the key use cases and requirements for - transport network control and management. It reviews proposed and - existing IETF transport network data models, their applicability, - and highlights gaps and requirements. + This document describes the key use cases and requirements to be + used as the basis for applicability statements analyzing how IETF + data models can be used for transport network control and + management. Table of Contents 1. Introduction ................................................3 - 1.1. Scope of this document .................................4 + 1.1. Scope of this document 4 2. Terminology .................................................4 - 3. Conventions used in this document............................4 + 3. Conventions used in this document 4 3.1. Topology and traffic flow processing ...................4 4. Use Case 1: Single-domain with single-layer .................5 4.1. Reference Network ......................................5 4.1.1. Single Transport Domain - OTN Network .............5 4.2. Topology Abstractions ..................................8 4.3. Service Configuration ..................................9 4.3.1. ODU Transit .......................................9 - 4.3.2. EPL over ODU ......................................10 - 4.3.3. Other OTN Client Services .........................10 - 4.3.4. EVPL over ODU .....................................11 - 4.3.5. EVPLAN and EVPTree Services .......................12 - 4.4. Multi-functional Access Links ..........................13 - 4.5. Protection Requirements ................................14 - 4.5.1. Linear Protection .................................15 - 5. Use Case 2: Single-domain with multi-layer ..................15 - 5.1. Reference Network ......................................15 - 5.2. Topology Abstractions ..................................16 - 5.3. Service Configuration ..................................16 - 6. Use Case 3: Multi-domain with single-layer ..................16 - 6.1. Reference Network ......................................16 - 6.2. Topology Abstractions ..................................19 - 6.3. Service Configuration ..................................19 - 6.3.1. ODU Transit .......................................20 - 6.3.2. EPL over ODU ......................................20 - 6.3.3. Other OTN Client Services .........................21 - 6.3.4. EVPL over ODU .....................................21 - 6.3.5. EVPLAN and EVPTree Services .......................21 - 6.4. Multi-functional Access Links ..........................22 - 6.5. Protection Scenarios ...................................22 - 6.5.1. Linear Protection (end-to-end) ....................23 - 6.5.2. Segmented Protection ..............................23 - 7. Use Case 4: Multi-domain and multi-layer ....................24 - 7.1. Reference Network ......................................24 - 7.2. Topology Abstractions ..................................25 - 7.3. Service Configuration ..................................25 - 8. Security Considerations .....................................25 - 9. IANA Considerations .........................................26 - 10. References .................................................26 - 10.1. Normative References ..................................26 - 10.2. Informative References ................................26 - 11. Acknowledgments ............................................27 + 4.3.2. EPL over ODU ..................................... 10 + 4.3.3. Other OTN Client Services ........................ 10 + 4.3.4. EVPL over ODU .................................... 11 + 4.3.5. EVPLAN and EVPTree Services ...................... 12 + 4.4. Multi-functional Access Links ......................... 13 + 4.5. Protection Requirements ............................... 14 + 4.5.1. Linear Protection ................................ 15 + 5. Use Case 2: Single-domain with multi-layer ................. 15 + 5.1. Reference Network ..................................... 15 + 5.2. Topology Abstractions ................................. 16 + 5.3. Service Configuration ................................. 16 + 6. Use Case 3: Multi-domain with single-layer ................. 16 + 6.1. Reference Network ..................................... 16 + 6.2. Topology Abstractions ................................. 19 + 6.3. Service Configuration ................................. 19 + 6.3.1. ODU Transit ...................................... 20 + 6.3.2. EPL over ODU ..................................... 20 + 6.3.3. Other OTN Client Services ........................ 21 + 6.3.4. EVPL over ODU .................................... 21 + 6.3.5. EVPLAN and EVPTree Services ...................... 21 + 6.4. Multi-functional Access Links ......................... 22 + 6.5. Protection Scenarios .................................. 22 + 6.5.1. Linear Protection (end-to-end) ................... 23 + 6.5.2. Segmented Protection ............................. 23 + 7. Use Case 4: Multi-domain and multi-layer ................... 24 + 7.1. Reference Network ..................................... 24 + 7.2. Topology Abstractions ................................. 25 + 7.3. Service Configuration ................................. 25 + 8. Security Considerations .................................... 25 + 9. IANA Considerations ........................................ 26 + 10. References ................................................ 26 + 10.1. Normative References ................................. 26 + 10.2. Informative References ............................... 26 + 11. Acknowledgments ........................................... 27 1. Introduction Transport of packet services are critical for a wide-range of applications and services, including: data center and LAN interconnects, Internet service backhauling, mobile backhaul and enterprise Carrier Ethernet Services. These services are typically setup using stovepipe NMS and EMS platforms, often requiring propriety management platforms and legacy management interfaces. A clear goal of operators will be to automate setup of transport services across multiple transport technology domains. A common open interface (API) to each domain controller and or management system is pre-requisite for network operators to control multi-vendor and multi-domain networks and enable also service provisioning coordination/automation. This can be achieved by using standardized YANG models, used together with an appropriate protocol (e.g., [RESTCONF]). This document describes key use cases for analyzing the - applicability of the existing models defined by the IETF for - transport networks. The intention of this document is to become an - applicability statement that provides detailed descriptions of how - IETF transport models are applied to solve the described use cases - and requirements. + applicability of the models defined by the IETF for transport + networks. The intention of this document is to provide the base + reference scenarios for applicability statements that will describe + in details how IETF transport models are applied to solve the + described use cases and requirements. 1.1. Scope of this document This document assumes a reference architecture, including interfaces, based on the Abstraction and Control of Traffic- Engineered Networks (ACTN), defined in [ACTN-Frame] The focus of this document is on the MPI (interface between the Multi Domain Service Coordinator (MDSC) and a Physical Network Controller (PNC), controlling a transport network domain). @@ -185,22 +186,22 @@ The order represents the order of traffic flow being forwarded through the network. The processing can be either an adaptation of a client layer into a server layer "(client -> server)" or switching at a given layer "([switching])". Multi-layer switching is indicated by two layer switching with client/server adaptation: "([client] -> [server])". For example, the following traffic flow: - C-R1 (|PKT| -> ODU2), S3 (|ODU2|), S5 (|ODU2|), S6 (|ODU2|), - C-R3 (ODU2 -> |PKT|) + C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]), + C-R3 (ODU2 -> [PKT]) Node C-R1 is switching at the packet (PKT) layer and mapping packets into a ODU2 before transmission to node S3. Nodes S3, S5 and S6 are switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 which then sends it to S6 which finally sends to C-R3. Node C-R3 terminates the ODU2 from S6 before switching at the packet (PKT) layer. The paths of working and protection transport entities are specified as an ordered list of nodes, separated with commas: @@ -401,42 +402,42 @@ routers and the transport network are OTN links. The physical/optical interconnection below the ODU layer is supposed to be pre-configured and not exposed at the MPI to the MDSC. To setup a 10Gb IP link between C-R1 to C-R3, an ODU2 end-to-end data plane connection needs to be created between C-R1 and C-R3, crossing transport nodes S3, S5, and S6. The traffic flow between C-R1 and C-R3 can be summarized as: - C-R1 (|PKT| -> ODU2), S3 (|ODU2|), S5 (|ODU2|), S6 (|ODU2|), - C-R3 (ODU2 -> |PKT|) + C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]), + C-R3 (ODU2 -> [PKT]) The MDSC should be capable via the MPI to request the setup of an ODU2 transit service with enough information that enable the transport PNC to instantiate and control the ODU2 data plane connection segment through nodes S3, S5, S6. 4.3.2. EPL over ODU This use case assumes that the physical links interconnecting the IP routers and the transport network are Ethernet links. In order to setup a 10Gb IP link between C-R1 to C-R3, an EPL service needs to be created between C-R1 and C-R3, supported by an ODU2 end-to-end connection between S3 and S6, crossing transport node S5. The traffic flow between C-R1 and C-R3 can be summarized as: - C-R1 (|PKT| -> ETH), S3 (ETH -> |ODU2|), S5 (|ODU2|), - S6 (|ODU2| -> ETH), C-R3 (ETH-> |PKT|) + C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S5 ([ODU2]), + S6 ([ODU2] -> ETH), C-R3 (ETH-> [PKT]) The MDSC should be capable via the MPI to request the setup of an EPL service with enough information that can permit the transport PNC to instantiate and control the ODU2 end-to-end data plane connection through nodes S3, S5, S6, as well as the adaptation functions inside S3 and S6: S3&S6 (ETH -> ODU2) and S9&S6 (ODU2 -> ETH). 4.3.3. Other OTN Client Services @@ -451,22 +452,22 @@ options. In order to setup a 10Gb IP link between C-R1 to C-R3 using, for example STM-64 physical links between the IP routers and the transport network, an STM-64 Private Line service needs to be created between C-R1 and C-R3, supported by an ODU2 end-to-end data plane connection between S3 and S6, crossing transport node S5. The traffic flow between C-R1 and C-R3 can be summarized as: - C-R1 (|PKT| -> STM-64), S3 (STM-64 -> |ODU2|), S5 (|ODU2|), - S6 (|ODU2| -> STM-64), C-R3 (STM-64 -> |PKT|) + C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S5 ([ODU2]), + S6 ([ODU2] -> STM-64), C-R3 (STM-64 -> [PKT]) The MDSC should be capable via the MPI to request the setup of an STM-64 Private Line service with enough information that can permit the transport PNC to instantiate and control the ODU2 end-to-end connection through nodes S3, S5, S6, as well as the adaptation functions inside S3 and S6: S3&S6 (STM-64 -> ODU2) and S9&S3 (STM-64 -> PKT). 4.3.4. EVPL over ODU @@ -481,41 +482,39 @@ crossing transport node S5, and between S3 and S2, crossing transport node S1. Since the two EVPL services are sharing the same Ethernet physical link between C-R1 and S3, different VLAN IDs are associated with different EVPL services: for example VLAN IDs 10 and 20 respectively. The traffic flow between C-R1 and C-R3 can be summarized as: - C-R1 (|PKT| -> VLAN), S3 (VLAN -> |ODU0|), S5 (|ODU0|), - S6 (|ODU0| -> VLAN), C-R3 (VLAN -> |PKT|) + C-R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S5 ([ODU0]), + S6 ([ODU0] -> VLAN), C-R3 (VLAN -> [PKT]) The traffic flow between C-R1 and C-R4 can be summarized as: - C-R1 (|PKT| -> VLAN), S3 (VLAN -> |ODU0|), S1 (|ODU0|), - S2 (|ODU0| -> VLAN), C-R4 (VLAN -> |PKT|) + C-R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S1 ([ODU0]), + S2 ([ODU0] -> VLAN), C-R4 (VLAN -> [PKT]) The MDSC should be capable via the MPI to request the setup of these EVPL services with enough information that can permit the transport PNC to instantiate and control the ODU0 end-to-end data plane connections as well as the adaptation functions on the boundary nodes: S3&S2&S6 (VLAN -> ODU0) and S3&S2&S6 (ODU0 -> VLAN). -Internet-Draft Transport NBI Use Cases October 201 - 4.3.5. EVPLAN and EVPTree Services This use case assumes that the physical links interconnecting the IP routers and the transport network are Ethernet links and that - different Ethernet services (e.g, EVPL, EVPLAN and EVPTree) can + different Ethernet services (e.g., EVPL, EVPLAN and EVPTree) can share the same physical link using different VLANs. Note - it is assumed that EPLAN and EPTree services can be supported by configuring EVPLAN and EVPTree with port mapping. In order to setup an IP subnet between C-R1, C-R2, C-R3 and C-R4, an EVPLAN/EVPTree service needs to be created, supported by two ODUflex end-to-end connections respectively between S3 and S6, crossing transport node S5, and between S3 and S2, crossing transport node S1. @@ -541,43 +540,43 @@ The MAC bridging function in node S6 is needed to select, based on the MAC Destination Address, whether the Ethernet frames received from the ODUflex should be set to C-R2 or C-R3, as well as whether the Ethernet frames received from C-R2 (or C-R3) should be sent to C-R3 (or C-R2) or to the ODUflex. For example, the traffic flow between C-R1 and C-R3 can be summarized as: - C-R1 (|PKT| -> VLAN), S3 (VLAN -> |MAC| -> |ODUflex|), - S5 (|ODUflex|), S6 (|ODUflex| -> |MAC| -> VLAN), - C-R3 (VLAN -> |PKT|) + C-R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), + S5 ([ODUflex]), S6 ([ODUflex] -> [MAC] -> VLAN), + C-R3 (VLAN -> [PKT]) The MAC bridging function in node S3 is also needed to select, based on the MAC Destination Address, whether the Ethernet frames one ODUflex should be sent to C-R1 or to the other ODUflex. For example, the traffic flow between C-R3 and C-R4 can be summarized as: - C-R3 (|PKT| -> VLAN), S6 (VLAN -> |MAC| -> |ODUflex|), - S5 (|ODUflex|), S3 (|ODUflex| -> |MAC| -> |ODUflex|), - S1 (|ODUflex|), S2 (|ODUflex| -> VLAN), C-R4 (VLAN -> |PKT|) + C-R3 ([PKT] -> VLAN), S6 (VLAN -> [MAC] -> [ODUflex]), + S5 ([ODUflex]), S3 ([ODUflex] -> [MAC] -> [ODUflex]), + S1 ([ODUflex]), S2 ([ODUflex] -> VLAN), C-R4 (VLAN -> [PKT]) In node S2 there is no need for any MAC bridging function since all the Ethernet frames received from C-R4 should be sent to the ODUflex toward S3 and viceversa. The traffic flow between C-R1 and C-R4 can be summarized as: - C-R1 (|PKT| -> VLAN), S3 (VLAN -> |MAC| -> |ODUflex|), - S1 (|ODUflex|), S2 (|ODUflex| -> VLAN), C-R4 (VLAN -> |PKT|) + C-R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), + S1 ([ODUflex]), S2 ([ODUflex] -> VLAN), C-R4 (VLAN -> [PKT]) The MDSC should be capable via the MPI to request the setup of this EVPLAN/EVPTree services with enough information that can permit the transport PNC to instantiate and control the ODUflex end-to-end data plane connections as well as the Ethernet Bridging and adaptation functions on the boundary nodes: S3&S6 (VLAN -> MAC -> ODU2), S3&S6 (ODU2 -> ETH -> VLAN), S2 (VLAN -> ODU2) and S2 (ODU2 -> VLAN). 4.4. Multi-functional Access Links @@ -597,27 +596,27 @@ For example, if the physical link between C-R1 and S3 is a multi- functional access link while the physical links between C-R3 and S6 and between C-R4 and S2 are STM-64 and 10GE physical links respectively, it is possible at the MPI to configure either an STM- 64 Private Line service between C-R1 and C-R3 or an EPL service between C-R1 and C-R4. The traffic flow between C-R1 and C-R3 can be summarized as: - C-R1 (|PKT| -> STM-64), S3 (STM-64 -> |ODU2|), S5 (|ODU2|), - S6 (|ODU2| -> STM-64), C-R3 (STM-64 -> |PKT|) + C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S5 ([ODU2]), + S6 ([ODU2] -> STM-64), C-R3 (STM-64 -> [PKT]) The traffic flow between C-R1 and C-R4 can be summarized as: - C-R1 (|PKT| -> ETH), S3 (ETH -> |ODU2|), S1 (|ODU2|), - S2 (|ODU2| -> ETH), C-R4 (ETH-> |PKT|) + C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), + S2 ([ODU2] -> ETH), C-R4 (ETH-> [PKT]) The MDSC should be capable via the MPI to request the setup of either service with enough information that can permit the transport PNC to instantiate and control the ODU2 end-to-end data plane connection as well as the adaptation functions inside S3 and S2 or S6. 4.5. Protection Requirements Protection switching provides a pre-allocated survivability @@ -873,73 +872,73 @@ 6.3.1. ODU Transit In order to setup a 10Gb IP link between C-R1 and C-R5, an ODU2 end- to-end data plane connection needs be created between C-R1 and C-R5, crossing transport nodes S3, S1, S2, S31, S33, S34, S15 and S18 which belong to different PNC domains. The traffic flow between C-R1 and C-R5 can be summarized as: - C-R1 (|PKT| -> ODU2), S3 (|ODU2|), S1 (|ODU2|), S2 (|ODU2|), - S31 (|ODU2|), S33 (|ODU2|), S34 (|ODU2|), - S15 (|ODU2|), S18 (|ODU2|), C-R5 (ODU2 -> |PKT|) + C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), + S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), + S15 ([ODU2]), S18 ([ODU2]), C-R5 (ODU2 -> [PKT]) 6.3.2. EPL over ODU In order to setup a 10Gb IP link between C-R1 and C-R5, an EPL service needs to be created between C-R1 and C-R5, supported by an ODU2 end-to-end data plane connection between transport nodes S3 and S18, crossing transport nodes S1, S2, S31, S33, S34 and S15 which belong to different PNC domains. The traffic flow between C-R1 and C-R5 can be summarized as: - C-R1 (|PKT| -> ETH), S3 (ETH -> |ODU2|), S1 (|ODU2|), - S2 (|ODU2|), S31 (|ODU2|), S33 (|ODU2|), S34 (|ODU2|), - S15 (|ODU2|), S18 (|ODU2| -> ETH), C-R5 (ETH -> |PKT|) + C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), + S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), + S15 ([ODU2]), S18 ([ODU2] -> ETH), C-R5 (ETH -> [PKT]) 6.3.3. Other OTN Client Services In order to setup a 10Gb IP link between C-R1 and C-R5 using, for example SDH physical links between the IP routers and the transport network, an STM-64 Private Line service needs to be created between C-R1 and C-R5, supported by ODU2 end-to-end data plane connection between transport nodes S3 and S18, crossing transport nodes S1, S2, S31, S33, S34 and S15 which belong to different PNC domains. The traffic flow between C-R1 and C-R5 can be summarized as: - C-R1 (|PKT| -> STM-64), S3 (STM-64 -> |ODU2|), S1 (|ODU2|), - S2 (|ODU2|), S31 (|ODU2|), S33 (|ODU2|), S34 (|ODU2|), - S15 (|ODU2|), S18 (|ODU2| -> STM-64), C-R5 (STM-64 -> |PKT|) + C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), + S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), + S15 ([ODU2]), S18 ([ODU2] -> STM-64), C-R5 (STM-64 -> [PKT]) 6.3.4. EVPL over ODU In order to setup two 1Gb IP links between C-R1 to C-R3 and between C-R1 and C-R5, two EVPL services need to be created, supported by two ODU0 end-to-end connections respectively between S3 and S6, crossing transport node S5, and between S3 and S18, crossing transport nodes S1, S2, S31, S33, S34 and S15 which belong to different PNC domains. The VLAN configuration on the access links is the same as described in section 4.3.4. The traffic flow between C-R1 and C-R3 is the same as described in section 4.3.4. The traffic flow between C-R1 and C-R5 can be summarized as: - C-R1 (|PKT| -> VLAN), S3 (VLAN -> |ODU2|), S1 (|ODU2|), - S2 (|ODU2|), S31 (|ODU2|), S33 (|ODU2|), S34 (|ODU2|), - S15 (|ODU2|), S18 (|ODU2| -> VLAN), C-R5 (VLAN -> |PKT|) + C-R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU2]), S1 ([ODU2]), + S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), + S15 ([ODU2]), S18 ([ODU2] -> VLAN), C-R5 (VLAN -> [PKT]) 6.3.5. EVPLAN and EVPTree Services In order to setup an IP subnet between C-R1, C-R2, C-R3 and C-R7, an EVPLAN/EVPTree service needs to be created, supported by two ODUflex end-to-end connections respectively between S3 and S6, crossing transport node S5, and between S3 and S18, crossing transport nodes S1, S2, S31, S33, S34 and S15 which belong to different PNC domains. The VLAN configuration on the access links is the same as described @@ -948,48 +947,48 @@ The configuration of the Ethernet Bridging capabilities on nodes S3 and S6 is the same as described in section 4.3.5 while the configuration on node S18 similar to the configuration of node S2 described in section 4.3.5. The traffic flow between C-R1 and C-R3 is the same as described in section 4.3.5. The traffic flow between C-R1 and C-R5 can be summarized as: - C-R1 (|PKT| -> VLAN), S3 (VLAN -> |MAC| -> |ODUflex|), - S1 (|ODUflex|), S2 (|ODUflex|), S31 (|ODUflex|), - S33 (|ODUflex|), S34 (|ODUflex|), - S15 (|ODUflex|), S18 (|ODUflex| -> VLAN), C-R5 (VLAN -> |PKT|) + C-R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), + S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]), + S33 ([ODUflex]), S34 ([ODUflex]), + S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), C-R5 (VLAN -> [PKT]) 6.4. Multi-functional Access Links The same considerations of section 4.4 apply with the only difference that the ODU data plane connections could be setup across multiple PNC domains. For example, if the physical link between C-R1 and S3 is a multi- functional access link while the physical links between C-R7 and S31 and between C-R5 and S18 are STM-64 and 10GE physical links respectively, it is possible to configure either an STM-64 Private Line service between C-R1 and C-R7 or an EPL service between C-R1 and C-R5. The traffic flow between C-R1 and C-R7 can be summarized as: - C-R1 (|PKT| -> STM-64), S3 (STM-64 -> |ODU2|), S1 (|ODU2|), - S2 (|ODU2|), S31 (|ODU2| -> STM-64), C-R3 (STM-64 -> |PKT|) + C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), + S2 ([ODU2]), S31 ([ODU2] -> STM-64), C-R3 (STM-64 -> [PKT]) The traffic flow between C-R1 and C-R5 can be summarized as: - C-R1 (|PKT| -> ETH), S3 (ETH -> |ODU2|), S1 (|ODU2|), - S2 (|ODU2|), S31 (|ODU2|), S33 (|ODU2|), S34 (|ODU2|), - S15 (|ODU2|), S18 (|ODU2| -> ETH), C-R5 (ETH -> |PKT|) + C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), + S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), + S15 ([ODU2]), S18 ([ODU2] -> ETH), C-R5 (ETH -> [PKT]) 6.5. Protection Scenarios The MDSC needs to be capable to coordinate different PNCs to configure protection switching when requesting the setup of the connectivity services described in section 6.3. Since in this use case it is assumed that switching within the transport network domain is performed only in one layer, also protection switching within the transport network domain can only be @@ -1143,21 +1142,21 @@ 10. References 10.1. Normative References [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for Information Exchange between Interconnected Traffic- Engineered Networks", BCP 206, RFC 7926, July 2016. [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol - Label Switching (GMPLS)", RFC 4427, April 2006. + Label Switching (GMPLS)", RFC 4427, March 2006. [ACTN-Frame] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction and Control of Transport Networks", draft- ietf-teas-actn-framework, work in progress. [ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interfaces for the optical transport network", June 2016. [ITU-T G.808.1-2014] ITU-T Recommendation G.808.1 (05/14), "Generic protection switching - Linear trail and subnetwork @@ -1172,24 +1171,20 @@ draft-ietf-teas-yang-te-topo, work in progress. [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. [Path-Compute] Busi, I., Belotti, S. et al., " Yang model for requesting Path Computation", draft-busibel-teas-yang- path-computation, work in progress. - [RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF - Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, - . - [ONF TR-527] ONF Technical Recommendation TR-527, "Functional Requirements for Transport API", June 2016. [ONF GitHub] ONF Open Transport (SNOWMASS) https://github.com/OpenNetworkingFoundation/Snowmass- ONFOpenTransport 11. Acknowledgments The authors would like to thank all members of the Transport NBI