| < draft-ietf-ccamp-transport-nbi-app-statement-13.txt | draft-ietf-ccamp-transport-nbi-app-statement-14.txt > | |||
|---|---|---|---|---|
| CCAMP Working Group I. Busi, Ed. | CCAMP Working Group I. Busi, Ed. | |||
| Internet-Draft Huawei | Internet-Draft Huawei | |||
| Intended status: Informational D. King, Ed. | Intended status: Informational D. King, Ed. | |||
| Expires: April 2, 2022 Old Dog Consulting | Expires: 26 September 2022 Old Dog Consulting | |||
| H. Zheng, Ed. | H. Zheng, Ed. | |||
| Huawei | Huawei | |||
| Y. Xu, Ed. | Y. Xu, Ed. | |||
| CAICT | CAICT | |||
| September 29, 2021 | 25 March 2022 | |||
| Transport Northbound Interface Applicability Statement | Transport Northbound Interface Applicability Statement | |||
| draft-ietf-ccamp-transport-nbi-app-statement-13 | draft-ietf-ccamp-transport-nbi-app-statement-14 | |||
| Abstract | Abstract | |||
| This document provides an analysis of the applicability of the YANG | This document provides an analysis of the applicability of the YANG | |||
| models defined by the IETF (Traffic Engineering Architecture and | models defined by the IETF (in particular in the Traffic Engineering | |||
| Signaling (TEAS) moreover, Common Control and Measurement Plane | Architecture and Signaling (TEAS) and Common Control and Measurement | |||
| (CCAMP) WGs in particular) to support ODU transit services, | Plane (CCAMP) working groups) to support ODU transit services, | |||
| Transparent client services and EPL/EVPL Ethernet services over OTN | transparent client services, and Ethernet Private Line/Ethernet | |||
| single and multi-domain network scenarios. | Virtual Private Line (EPL/EVPL) services over Optical Transport | |||
| Network (OTN) in single and multi-domain network scenarios. | ||||
| This document also describes how existing YANG models can be used | This document also describes how existing YANG models can be used | |||
| through a number of worked examples and JSON fragments. | through several worked examples and JSON fragments. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on April 2, 2022. | This Internet-Draft will expire on 26 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
| publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
| carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
| to this document. Code Components extracted from this document must | extracted from this document must include Revised BSD License text as | |||
| include Simplified BSD License text as described in Section 4.e of | described in Section 4.e of the Trust Legal Provisions and are | |||
| the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Revised BSD License. | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. The Scope of this Document . . . . . . . . . . . . . . . 4 | 1.1. The Scope of this Document . . . . . . . . . . . . . . . 4 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Conventions Used in this Document . . . . . . . . . . . . . . 7 | 3. Conventions Used in this Document . . . . . . . . . . . . . . 7 | |||
| 3.1. Topology and Traffic Flow Processing . . . . . . . . . . 7 | 3.1. Topology and Traffic Flow Processing . . . . . . . . . . 7 | |||
| 3.2. JSON code . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Scenarios Description . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4. Scenarios Description . . . . . . . . . . . . . . . . . . . . 9 | 4.1. Reference Network . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.1. Reference Network . . . . . . . . . . . . . . . . . . . . 9 | 4.2. Topology Abstractions . . . . . . . . . . . . . . . . . . 12 | |||
| 4.2. Topology Abstractions . . . . . . . . . . . . . . . . . . 13 | 4.3. Service Configuration . . . . . . . . . . . . . . . . . . 14 | |||
| 4.3. Service Configuration . . . . . . . . . . . . . . . . . . 15 | 4.3.1. ODU Transit . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 4.3.1. ODU Transit . . . . . . . . . . . . . . . . . . . . . 15 | 4.3.2. EPL over ODU . . . . . . . . . . . . . . . . . . . . 15 | |||
| 4.3.2. EPL over ODU . . . . . . . . . . . . . . . . . . . . 16 | 4.3.3. Transparent Client Services . . . . . . . . . . . . . 16 | |||
| 4.3.3. Transparent Client Services . . . . . . . . . . . . . 17 | 4.3.4. EVPL over ODU . . . . . . . . . . . . . . . . . . . . 17 | |||
| 4.3.4. EVPL over ODU . . . . . . . . . . . . . . . . . . . . 18 | 4.4. Multi-Function Access Links . . . . . . . . . . . . . . . 18 | |||
| 4.4. Multi-function Access Links . . . . . . . . . . . . . . . 19 | 4.5. Protection and Restoration Configuration . . . . . . . . 19 | |||
| 4.5. Protection and Restoration Configuration . . . . . . . . 20 | 4.5.1. Linear Protection (End-to-End) . . . . . . . . . . . 20 | |||
| 4.5.1. Linear Protection (end-to-end) . . . . . . . . . . . 21 | 4.5.2. Segmented Protection . . . . . . . . . . . . . . . . 21 | |||
| 4.5.2. Segmented Protection . . . . . . . . . . . . . . . . 22 | 4.6. Event Notifications and Alarms . . . . . . . . . . . . . 21 | |||
| 4.6. Notification . . . . . . . . . . . . . . . . . . . . . . 22 | 4.7. Path Computation with Constraints . . . . . . . . . . . . 22 | |||
| 4.7. Path Computation with Constraints . . . . . . . . . . . . 23 | 5. YANG Model Analysis . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 5. YANG Model Analysis . . . . . . . . . . . . . . . . . . . . . 24 | 5.1. YANG Models for Topology Abstraction . . . . . . . . . . 23 | |||
| 5.1. YANG Models for Topology Abstraction . . . . . . . . . . 24 | 5.1.1. Domain 1 Black Topology Abstraction . . . . . . . . . 24 | |||
| 5.1.1. Domain 1 Black Topology Abstraction . . . . . . . . . 25 | 5.1.2. Domain 2 Black Topology Abstraction . . . . . . . . . 28 | |||
| 5.1.2. Domain 2 Black Topology Abstraction . . . . . . . . . 29 | 5.1.3. Domain 3 White Topology Abstraction . . . . . . . . . 29 | |||
| 5.1.3. Domain 3 White Topology Abstraction . . . . . . . . . 30 | 5.1.4. Multi-domain Topology Merging . . . . . . . . . . . . 29 | |||
| 5.1.4. Multi-domain Topology Merging . . . . . . . . . . . . 30 | 5.2. YANG Models for Service Configuration . . . . . . . . . . 32 | |||
| 5.2. YANG Models for Service Configuration . . . . . . . . . . 33 | 5.2.1. ODU Transit Service . . . . . . . . . . . . . . . . . 35 | |||
| 5.2.1. ODU Transit Service . . . . . . . . . . . . . . . . . 36 | 5.2.2. EPL over ODU Service . . . . . . . . . . . . . . . . 37 | |||
| 5.2.2. EPL over ODU Service . . . . . . . . . . . . . . . . 38 | 5.2.3. Other OTN Client Services . . . . . . . . . . . . . . 40 | |||
| 5.2.3. Other OTN Client Services . . . . . . . . . . . . . . 41 | 5.2.4. EVPL over ODU Service . . . . . . . . . . . . . . . . 41 | |||
| 5.2.4. EVPL over ODU Service . . . . . . . . . . . . . . . . 42 | 5.3. YANG Models for Protection Configuration . . . . . . . . 42 | |||
| 5.3. YANG Models for Protection Configuration . . . . . . . . 43 | 5.3.1. Linear Protection (end-to-end) . . . . . . . . . . . 42 | |||
| 5.3.1. Linear Protection (end-to-end) . . . . . . . . . . . 43 | ||||
| 5.3.2. Segmented Protection . . . . . . . . . . . . . . . . 44 | 5.3.2. Segmented Protection . . . . . . . . . . . . . . . . 44 | |||
| 5.4. Notifications . . . . . . . . . . . . . . . . . . . . . . 46 | 5.4. Notifications . . . . . . . . . . . . . . . . . . . . . . 45 | |||
| 5.5. Path Computation with Constraints . . . . . . . . . . . . 46 | 5.5. Path Computation with Constraints . . . . . . . . . . . . 46 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 46 | ||||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 47 | ||||
| 6.1. OTN Security . . . . . . . . . . . . . . . . . . . . . . 47 | 6.1. OTN Security . . . . . . . . . . . . . . . . . . . . . . 47 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 47 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 47 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 49 | 8.2. Informative References . . . . . . . . . . . . . . . . . 49 | |||
| Appendix A. Validating a JSON fragment against a YANG Model . . 51 | Appendix A. Validating a JSON fragment against a YANG Model . . 51 | |||
| A.1. Manipulation of JSON fragments . . . . . . . . . . . . . 51 | A.1. JSON CODE . . . . . . . . . . . . . . . . . . . . . . . . 51 | |||
| A.2. Comments in JSON fragments . . . . . . . . . . . . . . . 52 | A.2. Manipulation of JSON fragments . . . . . . . . . . . . . 52 | |||
| A.3. Validation of JSON fragments: DSDL-based approach . . . . 52 | A.3. Comments in JSON fragments . . . . . . . . . . . . . . . 53 | |||
| A.4. Validation of JSON fragments: why not using an XSD-based | A.4. Validation of JSON fragments: DSDL-based approach . . . . 53 | |||
| approach . . . . . . . . . . . . . . . . . . . . . . . . 53 | A.5. Validation of JSON fragments: why not using an XSD-based | |||
| Appendix B. Detailed JSON Examples . . . . . . . . . . . . . . . 53 | approach . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
| B.1. JSON Examples for Topology Abstractions . . . . . . . . . 53 | Appendix B. Detailed JSON Examples . . . . . . . . . . . . . . . 54 | |||
| B.1.1. JSON Code: mpi1-otn-topology.json . . . . . . . . . . 53 | B.1. JSON Examples for Topology Abstractions . . . . . . . . . 54 | |||
| B.1.2. JSON Code: mpi1-eth-topology.json . . . . . . . . . . 75 | B.1.1. JSON Code: mpi1-otn-topology.json . . . . . . . . . . 55 | |||
| B.2. JSON Examples for Service Configuration . . . . . . . . . 80 | B.1.2. JSON Code: mpi1-eth-topology.json . . . . . . . . . . 77 | |||
| B.2.1. JSON Code: mpi1-odu2-service-config.json . . . . . . 80 | B.2. JSON Examples for Service Configuration . . . . . . . . . 82 | |||
| B.2.2. JSON Code: mpi1-odu2-tunnel-config.json . . . . . . . 83 | B.2.1. JSON Code: mpi1-odu2-service-config.json . . . . . . 82 | |||
| B.2.3. JSON Code: mpi1-epl-service-config.json . . . . . . . 86 | B.2.2. JSON Code: mpi1-odu2-tunnel-config.json . . . . . . . 85 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 87 | B.2.3. JSON Code: mpi1-epl-service-config.json . . . . . . . 88 | |||
| Additional Authors' Addresses . . . . . . . . . . . . . . . . . . 88 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 89 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 90 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 | ||||
| 1. Introduction | 1. Introduction | |||
| Transport network domains, including Optical Transport Network (OTN) | Transport network domains, including Optical Transport Network (OTN) | |||
| and Wavelength Division Multiplexing (WDM) networks, are typically | and Wavelength Division Multiplexing (WDM) networks are typically | |||
| deployed based on a single vendor or technology platforms. They are | deployed based on a single vendor or a single technology platform. | |||
| often managed using proprietary interfaces to dedicated Element | They are often managed using proprietary interfaces to dedicated | |||
| Management Systems (EMS), Network Management Systems (NMS) and | Element Management Systems (EMS), Network Management Systems (NMS) | |||
| increasingly Software Defined Network (SDN) controllers. | and increasingly Software Defined Network (SDN) controllers. | |||
| Support of packet connectivity services over transport network | Support of packet connectivity services over a transport network | |||
| domains are critical for a wide range of applications and services, | domain is critical for a wide range of applications and services, | |||
| including data center and LAN interconnects, Internet service | including data center and LAN interconnects, Internet service | |||
| backhauling, mobile backhaul and enterprise Carrier Ethernet | backhauling, mobile backhaul and enterprise Carrier Ethernet | |||
| services. A clear goal of operators is to automate the setup of | services. An explicit goal of operators is to automate the setup of | |||
| these connectivity services across multiple transport network | these connectivity services across multiple transport network | |||
| domains, that may utilize different technologies. | domains, that may utilize different technologies. | |||
| A well-defined common open interface to each domain controller or a | A well-defined common open interface to each domain controller or a | |||
| management system is required for network operators to control multi- | management system is required for network operators to control multi- | |||
| vendor and multi-domain networks and also enable coordination and | vendor and multi-domain networks and also enable coordination and | |||
| automation of service provisioning. This is facilitated by using | automation of service provisioning. This is facilitated by using | |||
| standardized data models (e.g., YANG models), and an appropriate | standardized data models (e.g., YANG models), and an appropriate | |||
| protocol (e.g., RESTCONF [RFC8040]). | protocol (e.g., RESTCONF [RFC8040]). | |||
| This document examines the applicability of the YANG models being | This document examines the applicability of the YANG models defined | |||
| defined by IETF (Traffic Engineering Architecture and Signaling | by the IETF (in particular in the Traffic Engineering Architecture | |||
| (TEAS) moreover, Common Control and Measurement Plane (CCAMP) WGs in | and Signaling (TEAS) and Common Control and Measurement Plane (CCAMP) | |||
| particular) to support Optical Transport Networks (OTN) single and | working groups) to support OTN in a single and multi-domain network | |||
| multi-domain scenarios. | scenarios. | |||
| 1.1. The Scope of this Document | 1.1. The Scope of this Document | |||
| This document assumes a reference architecture, including interfaces, | This document assumes a reference architecture, including interfaces, | |||
| based on the Abstraction and Control of Traffic- Engineered Networks | based on the Framework for Abstraction and Control of Traffic- | |||
| (ACTN), defined in [RFC8453]. | Engineered Networks (ACTN), defined in [RFC8453]. | |||
| The focus of this document is on the interface between the Multi | The focus of this document is on the interface between the Multi | |||
| Domain Service Coordinator (MDSC) and a Provisioning Network | Domain Service Coordinator (MDSC) and a Provisioning Network | |||
| Controller (PNC), controlling a transport network domain, called | Controller (PNC), controlling a transport network domain, called | |||
| MDSC-PNC Interface (MPI) in [RFC8453]. | MDSC-PNC Interface (MPI) in [RFC8453]. | |||
| It is worth noting that the same MPI analyzed in this document could | It is worth noting that the same MPI analyzed in this document could | |||
| be used between hierarchical MDSC controllers, as shown in Figure 4 | be used between hierarchical MDSC controllers, as shown in Figure 4 | |||
| of [RFC8453]. | of [RFC8453]. | |||
| Detailed analysis of the interface between the Customer Network | A detailed analysis of the interface between the Customer Network | |||
| Controller (CNC) and the MDSC, called CNC-MDSC Interface (CMI) in | Controller (CNC) and the MDSC, called CNC-MDSC Interface (CMI) in | |||
| [RFC8453], as well as of the interface between service and network | [RFC8453], as well as the interface between service and network | |||
| orchestrators are outside the scope of this document. However, when | orchestrators are outside the scope of this document. However, when | |||
| needed, this document describes some considerations and assumptions | needed, this document describes some considerations and assumptions | |||
| about the information which needs to be provided at these interfaces. | about the information which needs to be provided at these interfaces. | |||
| The list of the IETF YANG models which apply to the ACTN MPI can be | ||||
| The list of the IETF YANG models which are applicable to the ACTN MPI | found in [ACTN-YANG]. | |||
| can be found in [ACTN-YANG]. | ||||
| The Functional Requirements for the transport API as described in the | The Functional Requirements for the transport API as described in the | |||
| Optical Networking Foundation (ONF) document [ONF_TR-527] have been | Optical Networking Foundation (ONF) document [ONF_TR-527] have been | |||
| taken as input for defining the reference scenarios analyzed in this | taken as input for defining the reference scenarios analyzed in this | |||
| document. | document. | |||
| The analysis provided in this document confirms that the IETF YANG | The analysis provided in this document confirms that the IETF YANG | |||
| models defined in [RFC8453], [RFC8795], [OTN-TOPO], [CLIENT-TOPO], | models defined in [RFC8453], [RFC8795], [OTN-TOPO], [CLIENT-TOPO], | |||
| [TE-TUNNEL], [PATH-COMPUTE], [OTN-TUNNEL] and [CLIENT-SIGNAL] can be | [TE-TUNNEL], [PATH-COMPUTE], [OTN-TUNNEL], and [CLIENT-SIGNAL] can be | |||
| used together to control a multi-domain OTN network to support | used together to control a multi-domain OTN network to support | |||
| different types of multi-domain services, such as ODU transit | different types of multi-domain services, such as Optical Data Unit | |||
| services, Transparent client services and EPL/EVPL Ethernet services, | (ODU) transit services, Transparent client services and EPL/EVPL | |||
| over a multi-domain OTN connection, satisfying also the requirements | Ethernet Private Line/Ethernet Virtual Private Line (EPL/EVPL) | |||
| in [ONF_TR-527]. | services, over a multi-domain OTN connection, satisfying also the | |||
| requirements in [ONF_TR-527]. | ||||
| 2. Terminology | 2. Terminology | |||
| Domain A domain, as defined in [RFC4655], is "any collection of | Domain A domain, as defined in [RFC4655], is "any collection of | |||
| network elements within a common sphere of address management or | network elements within a common sphere of address management or | |||
| path computation responsibility". Specifically, within this | path computation responsibility". Specifically, within this | |||
| document, we mean a part of an operator's network that is under | document, we mean a part of an operator's network that is under | |||
| common management (i.e., under shared operational management using | common management (i.e., under shared operational management using | |||
| the same instances of a tool and the same policies). Network | the same instances of a tool and the same policies). Network | |||
| elements will often be grouped into domains based on technologies, | elements will often be grouped into domains based on technologies, | |||
| vendor profiles, or geographic proximity. | vendor profiles, or geographic proximity. | |||
| CNC Customer Network Controller | CNC Customer Network Controller | |||
| Connection The data plane configuration of an LSP, within this | Connection The data plane configuration of an LSP: within this | |||
| document it is typically an ODU LSP. An end-to-end connection/LSP | document it is typically an ODU LSP. An end-to-end connection/LSP | |||
| represents an entire connection/LSP between the connection/LSP | represents an entire connection between the connection node end- | |||
| node end-points. A connection/LSP segment represents a portion of | points. A connection/LSP segment represents a portion of the end- | |||
| the end-to-end connection/LSP. | to-end connection. | |||
| Connectivity Service A service, or connectivity service, in the | Connectivity Service A connectivity service, in the context of this | |||
| context of this document can be considered as some form of | document, can be considered as a connection between customer | |||
| connectivity service between customer sites across the network | sites, across the network operator's network [RFC8309]. | |||
| operator's network [RFC8309]. | ||||
| E-LINE Ethernet Line | E-LINE Ethernet Line | |||
| EPL Ethernet Private Line | EPL Ethernet Private Line | |||
| EVPL Ethernet Virtual Private Line | EVPL Ethernet Virtual Private Line | |||
| ILL Inter-Layer Lock | ILL Inter-Layer Lock | |||
| Link A link, or a physical link, is used to reprent the adjacency | Link It is used to represent the adjacency between two nodes. | |||
| between two physical nodes. The term OTN link represents a link | The term physical link represents a link between two physical | |||
| between two OTN switching physical nodes. | nodes. The term OTN link represents a link between two OTN nodes. | |||
| LSP Label Switched Path | LSP Label Switched Path | |||
| LTP Link Termination Point | LTP Link Termination Point | |||
| MDSC Multi-Domain Service Coordinator | MDSC Multi-Domain Service Coordinator | |||
| Network Configuration As described in [RFC8309] it describes the | Network Configuration As described in [RFC8309] it describes the | |||
| instructions provided to a controller on how to configure parts of | instructions provided to a controller on how to configure parts of | |||
| a network. | a network. | |||
| skipping to change at page 6, line 4 ¶ | skipping to change at page 5, line 47 ¶ | |||
| LTP Link Termination Point | LTP Link Termination Point | |||
| MDSC Multi-Domain Service Coordinator | MDSC Multi-Domain Service Coordinator | |||
| Network Configuration As described in [RFC8309] it describes the | Network Configuration As described in [RFC8309] it describes the | |||
| instructions provided to a controller on how to configure parts of | instructions provided to a controller on how to configure parts of | |||
| a network. | a network. | |||
| ODU Optical Channel Data Unit | ODU Optical Channel Data Unit | |||
| OTU Optical Channel Transport Unit | OTU Optical Channel Transport Unit | |||
| OTN Optical Transport Network | OTN Optical Transport Network | |||
| PNC Provisioning Network Controller | PNC Provisioning Network Controller | |||
| Protection Switching Protection switching, as defined in | Protection Switching Protection switching, as defined in | |||
| [ITU-T_G.808.1] and [RFC4427], provides the capability to swith | [ITU-T_G.808.1] and [RFC4427], provides the capability to switch | |||
| the traffic in case of network failurs over pre-allocated networks | the traffic in case of network failures over pre-allocated | |||
| resourse. Typically linear protection methods would be used and | networks resources. Typically linear protection methods would be | |||
| configured to operate as 1+1 unidirectional, 1+1 bidirectional or | used and configured to operate as 1+1 unidirectional, 1+1 | |||
| 1:n bidirectional. This ensures fast and simple service | bidirectional or 1:n bidirectional. This ensures fast and simple | |||
| survivability. | service survivability. | |||
| Protection Transport Entity/LSP A protection transport entity/LSP, | Protection Transport Entity/LSP A protection transport entity/LSP, | |||
| as defined in [ITU-T_G.808.1] and [RFC4427], represents the path | as defined in [ITU-T_G.808.1] and [RFC4427], represents the path | |||
| where the "normal" user traffic is transported during protection | where the "normal" user traffic is transported during protection | |||
| switching events (e.g., when the working transport entity/LSP | switching events (e.g., when the working transport entity/LSP | |||
| fails). | fails). | |||
| Restoration Restoration methods, as defined in [RFC4427], provide | Restoration Restoration methods, as defined in [RFC4427], provide | |||
| the capability to reroute and restore traffic around network | the capability to reroute and restore traffic around network | |||
| failures without the necessity to allocate network resources as | failures without the necessity to allocate network resources as | |||
| required for dedicated 1+1 protection schemes. On the other hand, | required for dedicated 1+1 protection schemes. On the other hand, | |||
| restoration times are typically longer than protection switching | restoration times are typically longer than protection switching | |||
| times. | times. | |||
| Service Model As described in [RFC8309] it describes a service and | Service Model As described in [RFC8309] it describes a service and | |||
| the parameters of the service in a portable way that can be used | the parameters of the service in a portable way that can be used | |||
| uniformly and independent of the equipment and operating | uniformly and independent of the equipment and operating | |||
| environment. | environment. | |||
| TE Link As defined in [RFC8795], it is an element of a TE topology, | TE Link As defined in [RFC8795], is an element of a TE topology, | |||
| presented as an edge on TE graph. | presented as an edge on TE graph. | |||
| TE Tunnel As defined in [TE-TUTORIAL], it is a connection-oriented | TE Tunnel As defined in [TE-TUNNEL], it is a connection-oriented | |||
| service provided by a layer network of delivery of a client's data | service provided by a layered network of delivery of a client's | |||
| between source and destination tunnel termination points. | data between source and destination tunnel termination points. | |||
| See also [TE-TUTORIAL]. | ||||
| TE Tunnel Segment As defined in [TE-TUTORIAL], it is a part of a | TE Tunnel Segment As defined in [TE-TUNNEL], it is a part of a | |||
| multi-domain TE tunnel that spans. | multi-domain TE tunnel that spans. See also [TE-TUTORIAL]. | |||
| TE Tunnel Hand-off As defined in [TE-TUTORIAL], it is an access link | TE Tunnel Hand-off It is an access or inter-domain LTP by which a | |||
| or inter-domain link by which a multi-domain TE tunnel enters or | multi-domain TE tunnel enters or exits a given network domain. | |||
| exits a given network domain. | See also [TE-TUTORIAL]. | |||
| Note - The three definitions above are currently in [TE-TUTORIAL] but | Note - The three definitions above are currently in [TE-TUTORIAL] but | |||
| it is expected that they will be moved to [TE-TUNNEL]. When this | it is expected that they will be moved to [TE-TUNNEL]. When this | |||
| happens, the reference will be updated and the [TE-TUTORIAL] | happens, the reference will be updated and the [TE-TUTORIAL] | |||
| reference will be downgraded to Informative. | reference will be downgraded to Informative. | |||
| TPN Tributary Port Number | TPN Tributary Port Number | |||
| TTP Tunnel Termination Point | TTP Tunnel Termination Point | |||
| skipping to change at page 8, line 23 ¶ | skipping to change at page 8, line 19 ¶ | |||
| as an ordered list of nodes, separated with commas: | as an ordered list of nodes, separated with commas: | |||
| <node> {, <node>} | <node> {, <node>} | |||
| The order represents the order of traffic flow being forwarded | The order represents the order of traffic flow being forwarded | |||
| through the network in the forward direction. In the case of | through the network in the forward direction. In the case of | |||
| bidirectional paths, the forward and backward directions are selected | bidirectional paths, the forward and backward directions are selected | |||
| arbitrarily, but the convention is consistent between working/ | arbitrarily, but the convention is consistent between working/ | |||
| protection path pairs, as well as across multiple domains. | protection path pairs, as well as across multiple domains. | |||
| 3.2. JSON code | The use of curly brackets denotes multiple nodes in a list. | |||
| This document provides some detailed JSON code examples to describe | ||||
| how the YANG models being developed by the IETF (TEAS and CCAMP WG in | ||||
| particular) may be used. The scenario examples are provided using | ||||
| JSON to facilitate readability. | ||||
| Different objects need to have an identifier. The convention used to | ||||
| create mnemonic identifiers is to use the object name (e.g., S3 for | ||||
| node S3), followed by its type (e.g., NODE), separated by an "-", | ||||
| followed by "-ID". For example, the mnemonic identifier for node S3 | ||||
| would be S3-NODE-ID. | ||||
| The JSON language does not support the insertion of comments that | ||||
| have been instead found to be useful when writing the examples. This | ||||
| document will insert comments into the JSON code as JSON name/value | ||||
| pair with the JSON name string starting with the "//" characters. | ||||
| For example, when describing the example of a TE Topology instance | ||||
| representing the ODU Abstract Topology exposed by the Transport PNC, | ||||
| the following comment has been added to the JSON code: | ||||
| "// comment": "ODU Abstract Topology @ MPI", | ||||
| The JSON code examples provided in this document have been validated | ||||
| against the YANG models following the validation process described in | ||||
| Appendix A, which would not consider the comments. | ||||
| To have successful validation of the examples, some numbering scheme | ||||
| has been defined to assign identifiers to the different entities | ||||
| which would pass the syntax checks. In that case, to simplify the | ||||
| reading, another JSON name/value pair formatted as a comment and | ||||
| using the mnemonic identifiers is also provided. For example, the | ||||
| identifier of node S3 (S3-NODE-ID) has been assumed to be "10.0.0.3" | ||||
| and would be shown in the JSON code example using the two JSON name/ | ||||
| value pair: | ||||
| "// te-node-id": "S3-NODE-ID", | ||||
| "te-node-id": "10.0.0.3", | ||||
| The first JSON name/value pair will be automatically removed in the | ||||
| first step of the validation process, while the second JSON name/ | ||||
| value pair will be validated against the YANG model definitions. | ||||
| 4. Scenarios Description | 4. Scenarios Description | |||
| 4.1. Reference Network | 4.1. Reference Network | |||
| The physical topology of the reference network is shown in Figure 1. | The physical topology of the reference network is shown in Figure 1. | |||
| It represents an OTN network composed of three transport network | It represents an OTN network composed of three transport network | |||
| domains which provide connectivity services to an IP customer network | domains that provide connectivity services to an IP customer network | |||
| through nine access links: | through nine access links: | |||
| ........................ | ........................ | |||
| ......... : : | ......... : : | |||
| : : Network domain 1 : ............. | : : Network domain 1 : ............. | |||
| Customer: : : : : | Customer: : : : : | |||
| domain : : S1 -------+ : : Network : | domain : : S1 -------+ : : Network : | |||
| : : / \ : : domain 3 : .......... | : : / \ : : domain 3 : .......... | |||
| R1 ------- S3 ----- S4 \ : : : : | R1 ------- S3 ----- S4 \ : : : : | |||
| : : \ \ S2 --------+ : :Customer | : : \ \ S2 --------+ : :Customer | |||
| skipping to change at page 10, line 42 ¶ | skipping to change at page 9, line 42 ¶ | |||
| : | / S17 -- S18 --------- R8 | : | / S17 -- S18 --------- R8 | |||
| : | / \ / : : | : | / \ / : : | |||
| : S19 ---- S20 ---- S21 ------------ R9 | : S19 ---- S20 ---- S21 ------------ R9 | |||
| : : : | : : : | |||
| :...............................: :............. | :...............................: :............. | |||
| Figure 1: Reference network | Figure 1: Reference network | |||
| This document assumes that all the Si transport network switching | This document assumes that all the Si transport network switching | |||
| nodes are capable of switching in the electrical domain (ODU | nodes are capable of switching in the electrical domain (ODU | |||
| switching) moreover, that all the Si-Sj OTN links within the | switching) moreover, all the Si-Sj OTN links within the transport | |||
| transport network (intra-domain or inter-domain) are 100G links while | network (intra-domain or inter-domain) are 100G links while the | |||
| the access Ri-Sj links are 10G links. | access Ri-Sj links are 10G links. | |||
| This document also assumes that within the transport network, the | This document also assumes that within the transport network, the | |||
| physical/optical connections supporting the Si-Sj OTN links (up to | physical/optical connections supporting the Si-Sj OTN links (up to | |||
| the OTU4 trail), are pre-provisioned using mechanisms which are | the OTU4 trail), are pre-provisioned using mechanisms that are | |||
| outside the scope of this document and are not exposed at the MPIs to | outside the scope of this document and are not exposed at the MPIs to | |||
| the MDSC. | the MDSC. | |||
| Different transmission technologies can be used on the access links | Different transmission technologies can be used on the access links | |||
| (e.g., Ethernet, STM-N and OTU). Section 4.3 provides more details | (e.g., Ethernet, Synchronous Transport Module (STM) and OTU). | |||
| about the different assumptions on the access links for different | Section 4.3 provides more details about the different assumptions on | |||
| types of connectivity services and Section 4.4 describes the control | the access links for different types of connectivity services, and | |||
| of access links which can support different technology configurations | Section 4.4 describes the control of access links that can support | |||
| (e.g., STM-64, 10GE or OTU2) depending on the type of service being | different technology configurations (e.g., STM-64, 10GE or OTU2) | |||
| configured (multi-function access links). | depending on the type of service being configured (multi-function | |||
| access links). | ||||
| To carry client signals (e.g., Ethernet or STM-N) over OTN, some ODU | To carry client signals (e.g., Ethernet or STM-N) over OTN, some ODU | |||
| termination and adaptation resources need to be available on the | termination and adaptation resources need to be available on the | |||
| physical edge nodes (e.g., node S3 and S18). The location of these | physical edge nodes (e.g., node S3 and S18). The location of these | |||
| resources within the physical node is implementation specific and | resources within the physical node is implementation-specific and | |||
| outside the scope of standardization. This document assumes that | outside the scope of standardization. This document assumes that | |||
| these termination and adaptation resources are located on the | these termination and adaptation resources are located on the | |||
| physical interfaces of the edge nodes terminating the access links. | physical interfaces of the edge nodes terminating the access links. | |||
| In other words, each physical access link has a set dedicated ODU | In other words, each physical access link has a set of dedicated ODU | |||
| termination and adaptation resources. | termination and adaptation resources. | |||
| The transport network control architecture, shown in Figure 2, | The transport network control architecture, shown in Figure 2, | |||
| follows the ACTN architecture as defined in the ACTN framework | follows the ACTN architecture as defined in the ACTN framework | |||
| document [RFC8453], and uses the same functional components: | document [RFC8453], and uses the same functional components: | |||
| -------------- | -------------- | |||
| | | | | | | |||
| | CNC | | | CNC | | |||
| | | | | | | |||
| skipping to change at page 12, line 46 ¶ | skipping to change at page 11, line 46 ¶ | |||
| ----- ( ) | ----- ( ) | |||
| ( ) | ( ) | |||
| ----- | ----- | |||
| Figure 2: Controlling Hierarchies | Figure 2: Controlling Hierarchies | |||
| The NEs within network domains 1, 2 and 3 of Figure 1 are controlled, | The NEs within network domains 1, 2 and 3 of Figure 1 are controlled, | |||
| respectively, by PNC1, PNC2 and PNC3 of Figure 2. The MDSC control | respectively, by PNC1, PNC2 and PNC3 of Figure 2. The MDSC control | |||
| the end-to-end network through the MPIs toward the underlying PNCs. | the end-to-end network through the MPIs toward the underlying PNCs. | |||
| The ACTN framework facilitates the separation of the network and | The ACTN framework facilitates separating the network and service | |||
| service control from the underlying technology. It helps the | control from the underlying technology. It helps the customer to | |||
| customer to define the network as desired by business needs. The CMI | define the network as desired by business needs. The CMI is defined | |||
| is defined to keep a minimal level of dependency (or no dependency at | to keep a minimal level of dependency (or no dependency at all) from | |||
| all) from the underlying network technologies. The MPI instead | the underlying network technologies. The MPI instead requires some | |||
| requires some specialization according to the domain technology. | specialization according to the domain technology. | |||
| The control interfaces within the scope of this document are the | The control interfaces within the scope of this document are the | |||
| three MPIs, as shown in Figure 2. | three MPIs, as shown in Figure 2. | |||
| The split of functionality at the MPI in the ACTN architecture | The split of functionality at the MPI in the ACTN architecture | |||
| between the MDSC (multi-domain controller) and the PNCs (domain | between the MDSC and the PNCs, is equivalent to separation | |||
| controllers), is equivalent to separation functionality assumed in | functionality assumed in the ONF T-API interface, as described in the | |||
| the ONF T-API interface, as described in the ONF T-API multi-domain | ONF T-API multi-domain use cases [ONF_TR-527]. Furthermore, this | |||
| use cases [ONF_TR-527]. Furthermore, this functional separation is | functional separation is similarly defined in the MEF PRESTO | |||
| similarly defined in the MEF PRESTO interface between the Service | interface between the Service Orchestration Functionality (SOF) and | |||
| Orchestration Functionality (SOF) and the Infrastructure Control and | the Infrastructure Control and Management (ICM) in the MEF LSO | |||
| Management (ICM) in the MEF LSO Architecture [MEF55]. | Architecture [MEF55]. | |||
| This document does not make any assumption about the control | This document does not make any assumption about the control | |||
| architecture of the customer IP network: in line with [RFC8453], the | architecture of the customer IP network: in line with [RFC8453], the | |||
| CNC is just a functional component within the customer control | CNC is just a functional component within the customer control | |||
| architecture which is capable of requesting connectivity services on | architecture which is capable of requesting connectivity services on | |||
| demand between IP routers at the CMI. | demand between IP routers at the CMI. | |||
| The CNC can request connectivity services between IP routers which | The CNC can request connectivity services between IP routers which | |||
| can be attached to different transport network domains (e.g., between | can be attached to different transport network domains (e.g., between | |||
| R1 and R8 in Figure 1) or to the same transport network domain (e.g., | R1 and R8 in Figure 1) or to the same transport network domain (e.g., | |||
| skipping to change at page 13, line 50 ¶ | skipping to change at page 12, line 50 ¶ | |||
| and decide the network configuration to request only at the MPI of | and decide the network configuration to request only at the MPI of | |||
| the PNC controlling that domain (e.g., MPI1 of PNC1 in Figure 2). | the PNC controlling that domain (e.g., MPI1 of PNC1 in Figure 2). | |||
| 4.2. Topology Abstractions | 4.2. Topology Abstractions | |||
| Abstraction provides a selective method for representing connectivity | Abstraction provides a selective method for representing connectivity | |||
| information within a domain. There are multiple methods to abstract | information within a domain. There are multiple methods to abstract | |||
| a network topology. This document assumes the abstraction method | a network topology. This document assumes the abstraction method | |||
| defined in [RFC7926]: | defined in [RFC7926]: | |||
| Abstraction is the process of applying the policy to the available | Abstraction is the process of applying policy to the available TE | |||
| TE information within a domain, to produce selective information | information within a domain, to produce selective information that | |||
| that represents the potential ability to connect across the | represents the potential ability to connect across the domain. | |||
| domain. Thus, abstraction does not necessarily offer all possible | ||||
| connectivity options, but presents a general view of potential | Thus, abstraction does not necessarily offer all possible | |||
| connectivity options, but it presents a general view of potential | ||||
| connectivity according to the policies that determine how the | connectivity according to the policies that determine how the | |||
| domain's administrator wants to allow the domain resources to be | domain's administrator wants to allow the domain resources to be | |||
| used. | used. | |||
| [RFC8453] Provides the context of topology abstraction in the ACTN | [RFC8453] Provides the context of topology abstraction in the ACTN | |||
| architecture and discusses a few alternatives for the abstraction | architecture and discusses a few alternatives for the abstraction | |||
| methods for both packet and optical networks. This is an important | methods for both packet and optical networks. This is an important | |||
| consideration since the choice of the abstraction method impacts | consideration since the choice of the abstraction method impacts | |||
| protocol design and the information it carries. According to | protocol design and the information it carries. According to | |||
| [RFC8453], there are three types of topologies: | [RFC8453], there are three types of topologies: | |||
| o White topology: This is a case where the PNC provides the actual | * White topology: This is a case where the PNC provides the actual | |||
| network topology to the MDSC without any hiding or filtering. In | network topology to the MDSC without any hiding or filtering. In | |||
| this case, the MDSC has the full knowledge of the underlying | this case, the MDSC has the full knowledge of the underlying | |||
| network topology; | network topology; | |||
| o Black topology: The entire domain network is abstracted as a | * Black topology: The entire domain network is abstracted as a | |||
| single virtual node with the access links and inter-domain links | single virtual node with the access links and inter-domain links | |||
| without disclosing any node internal connectivity information; | without disclosing any node internal connectivity information; | |||
| o Grey topology: This abstraction level is between black topology | * Grey topology: This abstraction level is between black topology | |||
| and white topology from a granularity point of view. | and white topology from a granularity point of view. | |||
| Each PNC should provide the MDSC a network topology abstraction | Each PNC should provide the MDSC a network topology abstraction | |||
| hiding the internal details of the physical domain network topology | hiding the internal details of the physical domain network topology | |||
| controlled by the PNC. As described in section 3 of [RFC8453], the | controlled by the PNC. As described in section 3 of [RFC8453], the | |||
| level of abstraction provided by each PNC is based on the PNC | level of abstraction provided by each PNC is based on the PNC | |||
| configuration parameters and it is independent of the abstractions | configuration parameters and it is independent of the abstractions | |||
| provided by other PNCs. Therefore, it is possible that different | provided by other PNCs. Therefore, it is possible that different | |||
| PNCs provide different types of topology abstractions. The MDSC can | PNCs provides different topology abstractions. The MDSC can operate | |||
| operate on each MPI abstract topology regardless of, and | on each MPI abstract topology regardless of, and independently from, | |||
| independently from, the type of abstraction provided by its | the type of abstraction provided by its underlying PNC. | |||
| underlying PNC. | ||||
| For analyzing how the MDSC can operate on an abstract topology | For analyzing how the MDSC can operate on an abstract topology | |||
| provided by several PNcs that independently applied different | provided by several PNCs that independently applied different | |||
| abstraction policies and therefore provided different types of | abstraction policies and therefore provided different types of | |||
| abstract topologies, the following assumptions are made for the | abstract topologies, the following assumptions are made for the | |||
| reference network in Figure 1: | reference network in Figure 1: | |||
| o PNC1 and PNC2 provide black topology abstractions which expose at | * PNC1 and PNC2 provide black topology abstractions which expose at | |||
| MPI1, and MPI2 respectively, a single virtual node (representing | MPI1, and MPI2 respectively, a single virtual node (representing | |||
| the whole network domain 1, and domain 2 respectively). | the whole network domain 1, and domain 2 respectively). | |||
| o PNC3 provides a white topology abstraction which exposes at MPI3 | * PNC3 provides a white topology abstraction which exposes at MPI3 | |||
| all the physical nodes and links within network domain 3. | all the physical nodes and links within network domain 3. | |||
| The MDSC should be capable of stitching together the abstracted | The MDSC should be capable of stitching together the abstracted | |||
| topologies provided by each PNC to build its view of the multi- | topologies provided by each PNC to build its view of the multi- | |||
| domain network topology. This topology knowledge may require proper | domain network topology. This topology knowledge may require proper | |||
| oversight, including the application of local policy, configuration | oversight, including the application of local policy, configuration | |||
| methods, and the application of a trust model. Methods of how to | methods, and the application of a trust model. Methods of how to | |||
| manage these aspects are out of scope for this document, but | manage these aspects are out of scope for this document, but | |||
| recomandations are provided in the Security section of this document. | recomandations are provided in the Security section of this document. | |||
| The MDSC can also provide topology abstraction of its view of the | The MDSC can also provide topology abstraction of its view of the | |||
| multi-domain network topology at its CMIs depending on the customers' | multi-domain network topology at its CMIs depending on the customers' | |||
| needs and policies: it can provide different types of topology | needs and policies: it can provide different topology abstractions at | |||
| abstractions at different CMIs. Analyzing the topology abstractions | different CMIs. Analyzing the topology abstractions provided by the | |||
| provided by the MDSC to its CMIs is outside the scope of this | MDSC to its CMIs is outside the scope of this document. | |||
| document. | ||||
| 4.3. Service Configuration | 4.3. Service Configuration | |||
| In the following scenarios, it is assumed that the CNC is capable of | In the following scenarios, it is assumed that the CNC is capable of | |||
| requesting connectivity services from the MDSC, for example to | requesting connectivity services from the MDSC, for example, to | |||
| interconnect IP routers. | interconnect IP routers. | |||
| The type of connectivity services depends on the type of physical | The type of connectivity services depends on the type of physical | |||
| links (e.g. OTN link, ETH link or SDH link) between the routers and | links (e.g. OTN link, ETH link or SDH link) between the routers and | |||
| transport network. | transport network. | |||
| The packet processing inside IP routers, including packet | The packet processing inside IP routers, including packet | |||
| encapsualation and decapsulation, Ri (PKT -> foo) and Rj (foo -> | encapsualation and decapsulation, Ri (PKT -> foo) and Rj (foo -> | |||
| PKT), are assumed to be performed by means that are not under the | PKT), are assumed to be performed by means that are not under the | |||
| control of, and not visible to, the MDSC nor to the PNCs. Therefore, | control of, and not visible to, the MDSC or to the PNCs. Therefore, | |||
| these mechanisms are outside the scope of this document. | these mechanisms are outside the scope of this document. | |||
| 4.3.1. ODU Transit | 4.3.1. ODU Transit | |||
| The physical links interconnecting the IP routers and the transport | The physical links interconnecting the IP routers and the transport | |||
| network can be 10G OTN links. | network can be 10G OTN links. | |||
| In this case, it is assumed that the physical/optical | In this case, it is assumed that the physical/optical | |||
| interconnections below the ODU layer (up to the OTU2 trail) are pre- | interconnections below the ODU layer (up to the OTU2 trail) are pre- | |||
| provisioned using mechanisms which are outside the scope of this | provisioned using mechanisms which are outside the scope of this | |||
| document and not exposed at the MPIs between the PNCs and the MDSC. | document and not exposed at the MPIs between the PNCs and the MDSC. | |||
| For simplicity of the description, it is also assumed that these | For simplicity of the description, it is also assumed that these | |||
| interfaces are not channelized (i.e., they can only support one | interfaces are not channelized (i.e., they can only support one | |||
| ODU2). | ODU2). | |||
| When a 10Gb IP link between R1 and R8 is needed, an ODU2 end-to-end | When a 10Gb IP connectivity service between R1 and R8 is needed, an | |||
| connection needs to be created, passing through transport network | ODU2 end-to-end connection needs to be created, passing through | |||
| nodes S3, S1, S2, S31, S33, S34, S15 and S18 which belong to | transport network nodes S3, S1, S2, S31, S33, S34, S15 and S18, which | |||
| different PNC domains (multi-domain service request): | belong to different PNC domains (multi-domain service request): | |||
| R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]), | R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]), | |||
| S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)], | S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)], | |||
| S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)] | S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)] | |||
| The MDSC receives, at the CMI,the request to create an ODU2 transit | The MDSC receives, at the CMI, the request to create an ODU2 transit | |||
| service between the access links on S3 and S18, which belong to | service between the access links on S3 and S18, which belong to | |||
| different PNC domains (multi-domain service request). The MDSC also | different PNC domains (multi-domain service request). The MDSC also | |||
| determines the network configuration requests to be sent to its | determines the network configuration requests to be sent to its | |||
| underlying PNCs, at the MPIs, to coordinate the setup of a multi- | underlying PNCs, at the MPIs, to coordinate the setup of a multi- | |||
| domain ODU2 connection segment between the access links on S3 and | domain ODU2 connection segment between the access links on S3 and | |||
| S18. | S18. | |||
| When a 10Gb IP link between R1 and R3 is needed, an ODU2 end-to-end | When a 10Gb IP connectivity service between R1 and R3 is needed, an | |||
| connection needs to be created, passing through transport network | ODU2 end-to-end connection needs to be created, passing through | |||
| nodes S3, S5 and S6 which belong to the same PNC domain (single- | transport network nodes S3, S5 and S6 which belong to the same PNC | |||
| domain service request): | domain (single- domain service request): | |||
| R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)], | R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)], | |||
| R3 [ODU2 -> (PKT)] | R3 [ODU2 -> (PKT)] | |||
| As described in Section 4.1, the mechanisms, used by the CNC at the | As described in Section 4.1, the mechanisms, used by the CNC at the | |||
| CMI, are independent on whether the service request is single-domain | CMI, are independent on whether the service request is single-domain | |||
| service or multi-domain. | service or multi-domain. | |||
| The MDSC can figure out that it needs to setup an ODU2 transit | The MDSC can figure out that it needs to setup an ODU2 transit | |||
| service between the access links on S3 and S6, which belong to the | service between the access links on S3 and S6, which belong to the | |||
| skipping to change at page 16, line 46 ¶ | skipping to change at page 15, line 44 ¶ | |||
| 4.3.2. EPL over ODU | 4.3.2. EPL over ODU | |||
| The physical links interconnecting the IP routers and the transport | The physical links interconnecting the IP routers and the transport | |||
| network can be 10G Ethernet physical links (10GE). | network can be 10G Ethernet physical links (10GE). | |||
| In this case, it is assumed that the Ethernet physical interfaces (up | In this case, it is assumed that the Ethernet physical interfaces (up | |||
| to the MAC layer) are pre-provisioned using mechanisms which are | to the MAC layer) are pre-provisioned using mechanisms which are | |||
| outside the scope of this document and not exposed at the MPIs | outside the scope of this document and not exposed at the MPIs | |||
| between the PNCs and the MDSC. | between the PNCs and the MDSC. | |||
| When a 10Gb IP link between between R1 and R8 is needed, an EPL | When a 10Gb IP connectivity service between R1 and R8 is needed, an | |||
| service needs to be created, supported by an ODU2 end-to-end | EPL service needs to be created, supported by an ODU2 end-to-end | |||
| connection, between transport network nodes S3 and S18, passing | connection, between transport network nodes S3 and S18, passing | |||
| through transport network nodes S1, S2, S31, S33, S34 and S15, which | through transport network nodes S1, S2, S31, S33, S34 and S15, which | |||
| belong to different PNC domains (multi-domain service request): | belong to different PNC domains (multi-domain service request): | |||
| R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)], | R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)], | |||
| S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)], | S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)], | |||
| S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)] | S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)] | |||
| The MDSC receives, at the CMI, the request to create an EPL service | The MDSC receives, at the CMI, the request to create an EPL service | |||
| between the access links on S3 and S18, which belong to different PNC | between the access links on S3 and S18, which belong to different PNC | |||
| domains (multi-domain service request). The MDSC determines the | domains (multi-domain service request). The MDSC determines the | |||
| network configurations to request, at the MPIs, to its underlying | network configurations to request, at the MPIs, to its underlying | |||
| PNCs, to coordinate the setup of an end-to-end ODU2 connection | PNCs, to coordinate the setup of an end-to-end ODU2 connection | |||
| between the nodes S3 and S8, including the configuration of the | between the nodes S3 and S8, including the configuration of the | |||
| adaptation functions inside these edge nodes, such as S3 [ETH -> | adaptation functions inside these edge nodes, such as S3 [ETH -> | |||
| (ODU2)] and S18 [(ODU2) -> ETH]. | (ODU2)] and S18 [(ODU2) -> ETH]. | |||
| When a 10Gb IP link between R1 and R2 is needed, an EPL service needs | When a 10Gb IP connection between R1 and R2 is needed, an EPL service | |||
| to be created, supported by an ODU2 end-to-end connection between | needs to be created, supported by a ODU2 end-to-end connection | |||
| transport network nodes S3 and S6, passing through the transport | between transport network nodes S3 and S6, passing through the | |||
| network node S5, which belong to the same PNC domain (single-domain | transport network node S5, which belong to the same PNC domain | |||
| service request): | (single-domain service request): | |||
| R1 [(PKT) -> ETH], S3 [ETH -> (PKT)] S5 [(ODU2)], | R1 [(PKT) -> ETH], S3 [ETH -> (PKT)] S5 [(ODU2)], | |||
| S6 [(ODU2) -> ETH], R2 [ETH -> (PKT)] | S6 [(ODU2) -> ETH], R2 [ETH -> (PKT)] | |||
| As described in Section 4.1, the mechanisms used by the CNC at the | As described in Section 4.1, the mechanisms used by the CNC at the | |||
| CMI are independent on whether the service request is single-domain | CMI are independent on whether the service request is single-domain | |||
| service or multi-domain. | service or multi-domain. | |||
| Based on the assumption above, in this case, the MDSC can figure out | Based on the assumption above, in this case, the MDSC can figure out | |||
| that it needs to setup an EPL service between the access links on S3 | that it needs to setup an EPL service between the access links on S3 | |||
| and S6, which belong to the same PNC domain (single-domain service | and S6, that belong to the same PNC domain (single-domain service | |||
| request) and it decides the proper network configuration to request | request) and it decides the proper network configuration to request | |||
| PNC1. | PNC1. | |||
| 4.3.3. Transparent Client Services | 4.3.3. Transparent Client Services | |||
| [ITU-T_G.709] defines mappings of different Transparent Client layers | [ITU-T_G.709] defines mappings of different Transparent Client layers | |||
| into ODU. Most of them are used to provide Private Line services | into ODU. Most of them are used to provide Private Line services | |||
| over an OTN transport network supporting a variety of types of | over an OTN transport network supporting a variety of types of | |||
| physical access links (e.g., Ethernet, SDH STM-N, Fibre Channel, | physical access links (e.g., Ethernet, SDH STM-N, Fibre Channel, | |||
| InfiniBand, etc.) interconnecting the IP routers and the transport | InfiniBand, etc.) interconnect the IP routers and the transport | |||
| network. | network. | |||
| When a 10Gb IP link between R1 and R8 is needed, using, for example | When a 10Gb IP connectivity service between R1 and R8 is needed, | |||
| SDH physical links between the IP routers and the transport network, | using, for example SDH physical links between the IP routers and the | |||
| an STM-64 Private Line service needs to be created, supported by an | transport network, an STM-64 Private Line service needs to be | |||
| ODU2 end-to-end connection, between transport network nodes S3 and | created, supported by a ODU2 end-to-end connection, between transport | |||
| S18, passing through transport network nodes S1, S2, S31, S33, S34 | network nodes S3 and S18, passing through transport network nodes S1, | |||
| and S15, which belong to different PNC domains (multi-domain service | S2, S31, S33, S34 and S15, which belong to different PNC domains | |||
| request): | (multi-domain service request): | |||
| R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S1 [(ODU2)], | R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S1 [(ODU2)], | |||
| S2 [(ODU2)], S31 [(ODU2)], S33 [(ODU2)], S34[(ODU2)], | S2 [(ODU2)], S31 [(ODU2)], S33 [(ODU2)], S34[(ODU2)], | |||
| S15 [(ODU2)], S18 [(ODU2) -> STM-64], R8 [STM-64 -> (PKT)] | S15 [(ODU2)], S18 [(ODU2) -> STM-64], R8 [STM-64 -> (PKT)] | |||
| As described (Section 4.1) the CNC provides the essential information | As described (Section 4.1) the CNC provides the essential information | |||
| to permit the MDSC to compute which type of service is needed, in | to permit the MDSC to compute which type of service is needed, in | |||
| this case, an STM-64 Private Line Service between the access links on | this case, an STM-64 Private Line Service between the access links on | |||
| S3 and S8, and it also decides the network configurations, including | S3 and S8, and it also decides the network configurations, including | |||
| the configuration of the adaptation functions inside these edge | the configuration of the adaptation functions inside these edge | |||
| nodes, such as S3 [STM-64 -> (ODU2)] and S18 [(ODU2) -> STM-64]. | nodes, such as S3 [STM-64 -> (ODU2)] and S18 [(ODU2) -> STM-64]. | |||
| When a 10Gb IP link between R1 and R3 is needed, an STM-64 Private | When a 10Gb IP connectivity service between R1 and R3 is needed, an | |||
| Line service needs to be created between R1 and R3 (single-domain | STM-64 Private Line service needs to be created between R1 and R3 | |||
| service request): | (single-domain service request): | |||
| R1 [(PKT) -> STM-64], S3[STM-64 -> (ODU2)], S5 [(ODU2)], | R1 [(PKT) -> STM-64], S3[STM-64 -> (ODU2)], S5 [(ODU2)], | |||
| S6 [(ODU2) -> STM-64], R3[STM-64 -> (PKT)] | S6 [(ODU2) -> STM-64], R3[STM-64 -> (PKT)] | |||
| As described in Section 4.1, the mechanisms, used by the CNC at the | As described in Section 4.1, the mechanisms, used by the CNC at the | |||
| CMI, are independent on whether the service request is single-domain | CMI, are independent on whether the service request is single-domain | |||
| service or multi-domain. | service or multi-domain. | |||
| Based on the assumption above, in this case, the MDSC can figure out | Based on the assumption above, in this case, the MDSC can figure out | |||
| that it needs to setup an STM-64 Private Line service between the | that it needs to setup an STM-64 Private Line service between the | |||
| access links on S3 and S6, which belong to the same PNC domain | access links on S3 and S6, which belong to the same PNC domain | |||
| (single-domain service request) and it decides the proper network | (single-domain service request), and it decides the proper network | |||
| configuration to request PNC1. | configuration to request PNC1. | |||
| 4.3.4. EVPL over ODU | 4.3.4. EVPL over ODU | |||
| When the physical links interconnecting the IP routers and the | When the physical links interconnecting the IP routers and the | |||
| transport network are Ethernet physical links, it is also possible | transport network are Ethernet physical links, it is also possible | |||
| that different Ethernet services (e.g., EVPL) can share the same | that different Ethernet services (e.g., EVPL) can share the same | |||
| physical access link using different VLANs. | physical access link using different VLANs. | |||
| As described in Section 4.3.2, it is assumed that the Ethernet | As described in Section 4.3.2, it is assumed that the Ethernet | |||
| skipping to change at page 19, line 11 ¶ | skipping to change at page 18, line 11 ¶ | |||
| R1 [(PKT) -> VLAN], S3[VLAN -> (ODU0)], S1 [(ODU0)], | R1 [(PKT) -> VLAN], S3[VLAN -> (ODU0)], S1 [(ODU0)], | |||
| S2 [(ODU0)], S31 [(ODU0)], S33 [(ODU0)], S34 [(ODU0)], | S2 [(ODU0)], S31 [(ODU0)], S33 [(ODU0)], S34 [(ODU0)], | |||
| S15 [(ODU0)], S18 [(ODU0) -> VLAN], R8[VLAN -> (PKT)] | S15 [(ODU0)], S18 [(ODU0) -> VLAN], R8[VLAN -> (PKT)] | |||
| It is worth noting that the first EVPL service is required between | It is worth noting that the first EVPL service is required between | |||
| access links which belong to the same PNC domain (single-domain | access links which belong to the same PNC domain (single-domain | |||
| service request) while the second EVPL service is required between | service request) while the second EVPL service is required between | |||
| access links which belong to different PNC domains (multi-domain | access links which belong to different PNC domains (multi-domain | |||
| service request). | service request). | |||
| Since the two EVPL services are sharing the same Ethernet physical | Since the two EVPL services share the same Ethernet physical link | |||
| link between R1 and S3, different VLAN IDs are associated with | between R1 and S3, different VLAN IDs are associated with different | |||
| different EVPL services: for example, VLAN IDs 10 and 20 | EVPL services: for example, VLAN IDs 10 and 20 respectively. | |||
| respectively. | ||||
| Based on the assumptions described in Section 4.3.2, the CNC sends a | Based on the assumptions described in Section 4.3.2, the CNC sends a | |||
| request to the MDSC, at the CMI, to setup these EVPL services. The | request to the MDSC, at the CMI, to set up these EVPL services. The | |||
| MDSC will determine the network configurations to request to the | MDSC will determine the network configurations to request to the | |||
| underlying PNCs, as described in Section 4.3.2. | underlying PNCs, as described in Section 4.3.2. | |||
| 4.4. Multi-function Access Links | 4.4. Multi-Function Access Links | |||
| Some physical links interconnecting the IP routers and the transport | Some physical links interconnecting the IP routers and the transport | |||
| network can be configured in different modes, e.g., as OTU2 trail or | network can be configured in different modes, e.g., as OTU2 trail or | |||
| STM-64 or 10GE physical links. | STM-64 or 10GE physical links. | |||
| This configuration can be pre-provisioned by means which are outside | This configuration can be pre-provisioned by means which are outside | |||
| the scope of this document. In this case, these links will appear at | the scope of this document. In this case, these links will appear at | |||
| the MPI as links supporting only one mode (depending on how the link | the MPI as links supporting only one mode (depending on how the link | |||
| has been pre-provisioned) and will be controlled at the MPI as | has been pre-provisioned) and will be controlled at the MPI as | |||
| discussed in Section 4.3: for example, a 10G multi-function access | discussed in Section 4.3: for example, a 10G multi-function access | |||
| skipping to change at page 20, line 9 ¶ | skipping to change at page 19, line 9 ¶ | |||
| R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S5 [(ODU2)], | R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S5 [(ODU2)], | |||
| S6 [(ODU2) -> STM-64], R4 [STM-64 -> (PKT)] | S6 [(ODU2) -> STM-64], R4 [STM-64 -> (PKT)] | |||
| The traffic flow between R1 and R8 can be summarized as: | The traffic flow between R1 and R8 can be summarized as: | |||
| R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)], | R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)], | |||
| S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)], | S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)], | |||
| S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)] | S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)] | |||
| The CNC is capable of requesting, via the CMI, the setup either an | The CNC is capable of requesting, via the CMI, the setup of either an | |||
| STM-64 Private Line service, between R1 and R4, or an EPL service, | STM-64 Private Line service, between R1 and R4, or an EPL service, | |||
| between R1 and R8. | between R1 and R8. | |||
| The MDSC, based on the service being request, decides the network | The MDSC, based on the service being requested, decides the network | |||
| configurations to request, at the MPIs, to its underlying PNCs, to | configurations to request, at the MPIs, to its underlying PNCs, to | |||
| coordinate the setup of an end-to-end ODU2 connection, either between | coordinate the setup of an end-to-end ODU2 connection, either between | |||
| nodes S3 and S6, or between nodes S3 and S18, including the | nodes S3 and S6, or between nodes S3 and S18, including the | |||
| configuration of the adaptation functions on these edge nodes, and in | configuration of the adaptation functions on these edge nodes, and in | |||
| particular whether the multi-function access link between R1 and S3 | particular whether the multi-function access link between R1 and S3 | |||
| should operate as an STM-64 or as a 10GE physical link. | should operate as an STM-64 or as a 10GE physical link. | |||
| Assumptions used in this example, as well as the service scenarios of | Assumptions used in this example, as well as the service scenarios of | |||
| Section 4.3, include: | Section 4.3, include: | |||
| o the R1-S3 and R8-S18 access links will be multi-function access | * the R1-S3 and R8-S18 access links will be multi-function access | |||
| links, which can be configured as an OTU2 trail or as an STM-64 or | links, which can be configured as an OTU2 trail or as an STM-64 or | |||
| a 10GE physical link; | a 10GE physical link; | |||
| o the R3-S6 access link will be a multi-function access link which | * the R3-S6 access link will be a multi-function access link which | |||
| can be configured as an OTU2 trail or as an STM-64 physical link; | can be configured as an OTU2 trail or as an STM-64 physical link; | |||
| o the R4-S6 access link is pre-provisioned as an STM-64 physical | * the R4-S6 access link is pre-provisioned as an STM-64 physical | |||
| link; | link; | |||
| o all the other access links (and, in particular, the R2-S6 access | * all the other access links (and, in particular, the R2-S6 access | |||
| links) are pre-provisioned as 10GE physical links, up to the MAC | links) are pre-provisioned as 10GE physical links, up to the MAC | |||
| layer. | layer. | |||
| 4.5. Protection and Restoration Configuration | 4.5. Protection and Restoration Configuration | |||
| As described in [RFC4427], recovery can be performed by either | As described in [RFC4427], recovery can be performed by either | |||
| protection switching or restoration mechanisms. This section | protection switching or restoration mechanisms. This section | |||
| describes only services which are protected with linear protection, | describes only services which are protected with linear protection, | |||
| considering both end-to-end and segment protection, as defined in | considering both end-to-end and segment protection, as defined in | |||
| [ITU-T_G.808.1] and [RFC4427]. The description of services using | [ITU-T_G.808.1] and [RFC4427]. The description of services using | |||
| skipping to change at page 21, line 11 ¶ | skipping to change at page 20, line 11 ¶ | |||
| configurations to request different PNCs to coordinate the protection | configurations to request different PNCs to coordinate the protection | |||
| switching configuration to support protected connectivity services | switching configuration to support protected connectivity services | |||
| described in Section 4.3. | described in Section 4.3. | |||
| In the service examples described in Section 4.3, switching within | In the service examples described in Section 4.3, switching within | |||
| the transport network domain is only performed at the OTN ODU layer. | the transport network domain is only performed at the OTN ODU layer. | |||
| Therefore, it is also assumed that protection switching within the | Therefore, it is also assumed that protection switching within the | |||
| transport network also occurs at the OTN ODU layer, using the | transport network also occurs at the OTN ODU layer, using the | |||
| mechanisms defined in [ITU-T_G.873.1]. | mechanisms defined in [ITU-T_G.873.1]. | |||
| 4.5.1. Linear Protection (end-to-end) | 4.5.1. Linear Protection (End-to-End) | |||
| To protect the connectivity services described in Section 4.3 from | To protect the connectivity services described in Section 4.3 from | |||
| failures within the OTN multi-domain transport network, the MDSC can | failures within the OTN multi-domain transport network, the MDSC can | |||
| decide to request its underlying PNCs to configure ODU2 linear | decide to request its underlying PNCs to configure ODU2 linear | |||
| protection between the transport network edge nodes (e.g., nodes S3 | protection between the transport network edge nodes (e.g., nodes S3 | |||
| and S18 for the services setup between R1 and R8). | and S18 for the services setup between R1 and R8). | |||
| It is assumed that the OTN linear protection is configured as 1+1 | It is assumed that the OTN linear protection is configured as 1+1 | |||
| unidirectional protection switching type according to the definition | unidirectional protection switching type according to the definition | |||
| in [ITU-T_G.808.1] and [ITU-T_G.873.1], as well as in [RFC4427]. | in [ITU-T_G.808.1] and [ITU-T_G.873.1], as well as in [RFC4427]. | |||
| In these scenarios, a working transport entity and a protection | In these scenarios, a working transport entity and a protection | |||
| transport entity, as defined in [ITU-T_G.808.1], (or a working LSP | transport entity, as defined in [ITU-T_G.808.1], (or a working LSP | |||
| and a protection LSP, as defined in [RFC4427]) should be configured | and a protection LSP, as defined in [RFC4427]) should be configured | |||
| in the data plane. | in the data plane. | |||
| Two cases can be considered: | Two cases can be considered: | |||
| o In one case, the working and protection transport entities pass | * In one case, the working and protection transport entities pass | |||
| through the same PNC domains: | through the same PNC domains: | |||
| Working transport entity: S3, S1, S2, | Working transport entity: S3, S1, S2, | |||
| S31, S33, S34, | S31, S33, S34, | |||
| S15, S18 | S15, S18 | |||
| Protection transport entity: S3, S4, S8, | Protection transport entity: S3, S4, S8, | |||
| S32, | S32, | |||
| S12, S17, S18 | S12, S17, S18 | |||
| o In another case, the working and protection transport entities can | * In another case, the working and protection transport entities can | |||
| pass through different PNC domains: | pass through different PNC domains: | |||
| Working transport entity: S3, S5, S7, | Working transport entity: S3, S5, S7, | |||
| S11, S12, S17, S18 | S11, S12, S17, S18 | |||
| Protection transport entity: S3, S1, S2, | Protection transport entity: S3, S1, S2, | |||
| S31, S33, S34, | S31, S33, S34, | |||
| S15, S18 | S15, S18 | |||
| The PNCs should be capable of reporting to the MDSC which is the | The PNCs should be capable of reporting to the MDSC which, is the | |||
| active transport entity, as defined in [ITU-T_G.808.1], in the data | active transport entity, as defined in [ITU-T_G.808.1], in the data | |||
| plane. | plane. | |||
| Given the fast dynamic of protection switching operations in the data | Given the fast dynamic of protection switching operations in the data | |||
| plane (e.g., 50ms switching time), this reporting is not expected to | plane (e.g., 50ms switching time), this reporting is not expected to | |||
| be in real-time. | be in real-time. | |||
| It is also worth noting that with unidirectional protection | It is also worth noting that with unidirectional protection | |||
| switching, e.g., 1+1 unidirectional protection switching, the active | switching, e.g., 1+1 unidirectional protection switching, the active | |||
| transport entity may be different in the two directions. | transport entity may be different in the two directions. | |||
| 4.5.2. Segmented Protection | 4.5.2. Segmented Protection | |||
| To protect the connectivity services defined in Section 4.3 from | To protect the connectivity services defined in Section 4.3 from | |||
| failures within the OTN multi-domain transport network, the MDSC can | failures within the OTN multi-domain transport network, the MDSC can | |||
| decide to request its underlying PNCs to configure ODU2 linear | decide to request its underlying PNCs to configure ODU2 linear | |||
| protection between the edge nodes of each domain. | protection between the edge nodes of each domain. | |||
| For example, MDSC can request PNC1 to configure linear protection | For example, the MDSC can request PNC1 to configure linear protection | |||
| between its edge nodes S3 and S2: | between its edge nodes S3 and S2: | |||
| Working transport entity: S3, S1, S2 | Working transport entity: S3, S1, S2 | |||
| Protection transport entity: S3, S4, S8, S2 | Protection transport entity: S3, S4, S8, S2 | |||
| MDSC can also request PNC2 to configure linear protection between | MDSC can also request PNC2 to configure linear protection between | |||
| its edge nodes S15 and S18: | its edge nodes S15 and S18: | |||
| Working transport entity: S15, S18 | Working transport entity: S15, S18 | |||
| Protection transport entity: S15, S12, S17, S18 | Protection transport entity: S15, S12, S17, S18 | |||
| MDSC can also request PNC3 to configure linear protection between its | MDSC can also request PNC3 to configure linear protection between its | |||
| edge nodes S31 and S34: | edge nodes S31 and S34: | |||
| Working transport entity: S31, S33, S34 | Working transport entity: S31, S33, S34 | |||
| Protection transport entity: S31, S32, S34 | Protection transport entity: S31, S32, S34 | |||
| 4.6. Notification | 4.6. Event Notifications and Alarms | |||
| To realize the topology update, service update and restoration | To realize the three functions of topology update, service update, | |||
| function, following notification types should be supported: | and restoration, the following notification types need to be | |||
| supported: | ||||
| 1. Object create | 1. Object create | |||
| 2. Object delete | 2. Object delete | |||
| 3. Object state change | 3. Object state change | |||
| 4. Alarm | 4. Alarm | |||
| There are three types of topology abstraction types defined in | There are three types of topology abstraction types defined in | |||
| Section 4.2, and the notifications should also be abstracted. The | Section 4.1, Paragraph 16, and the notifications should also be | |||
| PNC and MDSC should coordinate together to determine the notification | abstracted. The PNC and MDSC should coordinate together to determine | |||
| policy. This will include information such as when an intra-domain | the notification policy. This will include information such as when | |||
| alarm occurred. The PNC may not report the alarm, but it should | an intra-domain alarm occurred. The PNC may not report the alarm, | |||
| provide notification of the service state change to the MDSC. | but it should provide notification of the service state change to the | |||
| MDSC. | ||||
| Analysis and methods of how event alarms are triggered, managed and | Detailed analysis and methods of how event alarms are triggered, | |||
| propagated are outside the scope of this document. | managed and propagated are outside the scope of this document. | |||
| 4.7. Path Computation with Constraints | 4.7. Path Computation with Constraints | |||
| It is possible to define constraints to be taken into account during | It is possible to define constraints to be taken into account during | |||
| path computation procedures (e.g., IRO/XRO). | path computation procedures (e.g., Include Route Object (IRO) and | |||
| Exclude Route Object (XRO) [RFC5521]). | ||||
| For example, the CNC can request, at the CMI, an ODU transit service, | For example, the CNC can request, at the CMI, an ODU transit service, | |||
| as described in Section 4.3.1, between R1 and R8 with the constraint | as described in Section 4.3.1, between R1 and R8 with the constraint | |||
| to pass through the link from S2 to S31 (IRO), such that a qualified | to pass through the link from S2 to S31 (IRO), such that a qualified | |||
| path could be: | path could be: | |||
| R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]), | R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]), | |||
| S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)], | S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)], | |||
| S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)] | S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)] | |||
| If the CNC instead requested to pass through the link from S8 to S12, | If the CNC instead requested to pass through the link from S8 to S12, | |||
| then the above path would not be qualified, while the following would | then the above path would not be qualified, while the following would | |||
| be: | be: | |||
| R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), S2[(ODU2]), | R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), S2[(ODU2]), | |||
| S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R8 [ODU2 -> | S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R8 [ODU2 -> | |||
| (PKT)] | (PKT)] | |||
| The mechanisms, used by the CNC to provide path constraints at the | The mechanisms used by the CNC to provide path constraints at the | |||
| CMI, are outside the scope of this document. It is assumed that the | CMI, are outside the scope of this document. It is assumed that the | |||
| MDSC can satisfy these constraints and take them into account in its | MDSC can satisfy these constraints and take them into account in its | |||
| path computation procedures (which would decide at least which | path computation procedures (which would decide at least which | |||
| domains and inter-domain links) and in the path computation | domains and inter-domain links) and in the path computation | |||
| constraints to provide to its underlying PNCs, to be taken into | constraints to provide to its underlying PNCs, to be taken into | |||
| account in the path computation procedures implemented by the PNCs | account in the path computation procedures implemented by the PNCs | |||
| (with a more detailed view of topology). | (with a more detailed view of topology). | |||
| Further detailed analysis is outside the scope of this document. | Further detailed analysis is outside the scope of this document. | |||
| skipping to change at page 24, line 28 ¶ | skipping to change at page 23, line 30 ¶ | |||
| their own MPIs, the network configuration needed to setup the | their own MPIs, the network configuration needed to setup the | |||
| different services described in Section 4.3. | different services described in Section 4.3. | |||
| Section 5.3 describes how the protection scenarios can be deployed, | Section 5.3 describes how the protection scenarios can be deployed, | |||
| including end-to-end protection and segment protection, for both | including end-to-end protection and segment protection, for both | |||
| intra-domain and inter-domain scenario. | intra-domain and inter-domain scenario. | |||
| 5.1. YANG Models for Topology Abstraction | 5.1. YANG Models for Topology Abstraction | |||
| This section analyses how each PNC can report its respective abstract | This section analyses how each PNC can report its respective abstract | |||
| topology to the MDSC, as described in Section 4.2, using the Topology | topology to the MDSC, as described in Section 4.1, Paragraph 16, | |||
| YANG models, defined in [RFC8345], with the TE Topology YANG | using the Topology YANG models, defined in [RFC8345], with the TE | |||
| augmentations, provided in [RFC8795], and the OTN technology-specific | Topology YANG augmentations, provided in [RFC8795], and the OTN | |||
| YANG augmentations, defined in [OTN-TOPO] or the Ethernet client | technology-specific YANG augmentations, defined in [OTN-TOPO] or the | |||
| technology-specific YANG augmentations, defined in [CLIENT-TOPO]. | Ethernet client technology-specific YANG augmentations, defined in | |||
| [CLIENT-TOPO]. | ||||
| As described in Section 4.1, the OTU4 trails on inter-domain and | As described in Section 4.1, the OTU4 trails on inter-domain and | |||
| intra-domain physical links are pre-provisioned and therefore not | intra-domain physical links are pre-provisioned and, therefore, not | |||
| exposed at the MPIs. Only the TE Links they support can be exposed | exposed at the MPIs. Only the TE Links they support can be exposed | |||
| at the MPI, depending on the topology abstraction performed by the | at the MPI, depending on the topology abstraction performed by the | |||
| PNC. | PNC. | |||
| The access links can be multi-function access links, as described in | The access links can be multi-function access links, as described in | |||
| Section 4.4. | Section 4.4. | |||
| As described in Section 4.1, each physical access link has a | As described in Section 4.1, each physical access link has a | |||
| dedicated set of ODU termination and adaptation resources. | dedicated set of ODU termination and adaptation resources. | |||
| The [OTN-TOPO] model allows reporting within the OTN abstract | The [OTN-TOPO] model allows reporting within the OTN abstract | |||
| topology also the access links which are capable of supporting the | topology also the access links which are capable of supporting the | |||
| transparent client layers, defined in Section 4.3.3 and in | transparent client layers, defined in Section 4.3.3 and in | |||
| [CLIENT-SIGNAL]. These links can also be multi-function access links | [CLIENT-SIGNAL]. These links can also be multi-function access links | |||
| that can be configured as a transparent client physical links (e.g., | that can be configured as transparent client physical links (e.g., | |||
| STM-64 physical link) or as an OTUk trail. | STM-64 physical link) or as an OTUk trail. | |||
| In order to support the EPL and EVPL services, described in | In order to support the EPL and EVPL services, described in | |||
| Section 4.3.2 and Section 4.3.2, the access links, which are capable | Section 4.3.2 and Section 4.3.4, the access links, which are capable | |||
| of being configured as Ethernet physical links, are reported by each | of being configured as Ethernet physical links, are reported by each | |||
| PNC within its respective Ethernet abstract topology, using the | PNC within its respective Ethernet abstract topology, using the | |||
| Topology YANG models, defined in [RFC8345], with the TE Topology YANG | Topology YANG models, defined in [RFC8345], with the TE Topology YANG | |||
| augmentations, defined in [RFC8795], and the Ethernet client | augmentations, defined in [RFC8795], and the Ethernet client | |||
| technology-specific YANG augmentations, defined in [CLIENT-TOPO]. | technology-specific YANG augmentations, defined in [CLIENT-TOPO]. | |||
| These links can also be multi-function access links that can be | These links can also be multi-function access links that can be | |||
| configured as an Ethernet physical link, an OTUk trail, or as a | configured as an Ethernet physical link, an OTUk trail, or as a | |||
| transparent client physical links (e.g., STM-64 physical link). In | transparent client physical links (e.g., STM-64 physical link). In | |||
| this case, these physical access links are represented in both the | this case, these physical access links are represented in both the | |||
| OTN and Ethernet abstract topologies. | OTN and Ethernet abstract topologies. | |||
| skipping to change at page 25, line 28 ¶ | skipping to change at page 24, line 35 ¶ | |||
| The PNC reports the capabilities of the access or inter-domain link | The PNC reports the capabilities of the access or inter-domain link | |||
| ends it can control. It is the MDSC responsibility to request | ends it can control. It is the MDSC responsibility to request | |||
| configuration of these links matching the capabilities of both link | configuration of these links matching the capabilities of both link | |||
| ends. | ends. | |||
| It is worth noting that in the network scenarios analyzed in this | It is worth noting that in the network scenarios analyzed in this | |||
| document (where switching is performed only at the ODU layer), the | document (where switching is performed only at the ODU layer), the | |||
| Ethernet abstract topologies reported by the PNCs describes only the | Ethernet abstract topologies reported by the PNCs describes only the | |||
| Ethernet client access links: no Ethernet TE switching capabilities | Ethernet client access links: no Ethernet TE switching capabilities | |||
| are reported in these Ethernet abstract topologies, to report that | are reported in these Ethernet abstract topologies, to report that | |||
| the underlying networt domain is not capable to support Ethernet TE | the underlying networt domain is not capable supporting Ethernet TE | |||
| Tunnels/LSPs. | Tunnels/LSPs. | |||
| 5.1.1. Domain 1 Black Topology Abstraction | 5.1.1. Domain 1 Black Topology Abstraction | |||
| PNC1 provides the required black topology abstraction, as described | PNC1 provides the required black topology abstraction, as described | |||
| in Section 4.2. It exposes at MPI1 to the MDSC, two TE Topology | in Section 4.1, Paragraph 16. It exposes at MPI1 to the MDSC, two TE | |||
| instances with only one TE node each. | Topology instances with only one TE node each. | |||
| The first TE Topology instance reports the domain 1 OTN abstract | The first TE Topology instance reports the domain 1 OTN abstract | |||
| topology view (MPI1 OTN Topology), using the OTN technology-specific | topology view (MPI1 OTN Topology), using the OTN technology-specific | |||
| augmentations [OTN-TOPO], with only one abstract TE node (i.e., AN1) | augmentations [OTN-TOPO], with only one abstract TE node (i.e., AN1) | |||
| moreover, only inter-domain and access abstract TE links (which | moreover, only inter-domain and access abstract TE links (which | |||
| represent the inter-domain physical links and the access physical | represent the inter-domain physical links and the access physical | |||
| links which can support ODU, or transparent client layers, both), as | links that can support ODU, or transparent client layers, both), as | |||
| shown in Figure 3 below. | shown in Figure 3 below. | |||
| ................................... | ................................... | |||
| : : | : : | |||
| : +-----------------+ : | : +-----------------+ : | |||
| : | | : | : | | : | |||
| (R1)- - --------| |-------- - -(S31) | (R1)- - --------| |-------- - -(S31) | |||
| : AN1-1 | | AN1-7 : | : AN1-1 | | AN1-7 : | |||
| : | | : | : | | : | |||
| (R3)- - --------| | : | (R3)- - --------| | : | |||
| skipping to change at page 27, line 15 ¶ | skipping to change at page 26, line 15 ¶ | |||
| The OTU4 trails on the inter-domain physical links (e.g., the link | The OTU4 trails on the inter-domain physical links (e.g., the link | |||
| between S2 and S31) are pre-provisioned and exposed as external TE | between S2 and S31) are pre-provisioned and exposed as external TE | |||
| Links, within the MPI1 OTN topology (e.g., the external TE Link | Links, within the MPI1 OTN topology (e.g., the external TE Link | |||
| terminating on AN1-7 TE Link Termination Point (LTP) abstracting the | terminating on AN1-7 TE Link Termination Point (LTP) abstracting the | |||
| OTU4 trail between S2 and S31). | OTU4 trail between S2 and S31). | |||
| The PNC1 exports at MPI1 the following external TE Links, within the | The PNC1 exports at MPI1 the following external TE Links, within the | |||
| MPI1 OTN topology, representing the multi-function access links under | MPI1 OTN topology, representing the multi-function access links under | |||
| its control: | its control: | |||
| o two abstract TE Links, terminating on LTP AN1-1 and AN1-2 | * two abstract TE Links, terminating on LTP AN1-1 and AN1-2 | |||
| respectively, abstracting the physical access link between S3 and | respectively, abstracting the physical access link between S3 and | |||
| R1 and the access link between S6 and R3 respectively, reporting | R1 and the access link between S6 and R3 respectively, reporting | |||
| that they can support STM-64 client signals as well as ODU2 | that they can support STM-64 client signals as well as ODU2 | |||
| connections; | connections; | |||
| o one abstract TE Link, terminating on LTP AN1-3, abstracting the | * one abstract TE Link, terminating on LTP AN1-3, abstracting the | |||
| physical access link between S6 and R4, reporting that it can | physical access link between S6 and R4, reporting that it can | |||
| support STM-64 client signals but no ODU2 connections. | support STM-64 client signals but no ODU2 connections. | |||
| The information about the 10GE access link between S6 and R2 as well | The information about the 10GE access link between S6 and R2 as well | |||
| as the fact that the access link between S3 and R1 can also be | as the fact that the access link between S3 and R1 can also be | |||
| configured as a 10GE link cannot be exposed by PNC1 within the MPI1 | configured as a 10GE link cannot be exposed by PNC1 within the MPI1 | |||
| OTN topology. | OTN topology. | |||
| Therefore, PNC1 exports at MPI1, within the MPI1 ETH topology, two | Therefore, PNC1 exports at MPI1, within the MPI1 ETH topology, two | |||
| abstract TE Links, terminating on LTP AN1-1 and AN1-8 respectively, | abstract TE Links, terminating on LTP AN1-1 and AN1-8 respectively, | |||
| abstracting the physical access link between S3 and R1 and the access | abstracting the physical access link between S3 and R1 and the access | |||
| link between S6 and R2 respectively, reporting that they can support | link between S6 and R2 respectively, reporting that they can support | |||
| Ethernet client signal with port-based and VLAN-based | Ethernet client signal with port-based and VLAN-based | |||
| classifications. | classifications. | |||
| PNC1 should expose at MPI1 also the ODU termination and adaptation | PNC1 should expose at MPI1 also the ODU termination and adaptation | |||
| resources which are available to carry client signals (e.g., Ethernet | resources that are available to carry client signals (e.g., Ethernet | |||
| or STM-N) over OTN. This information is reported by the Tunnel | or STM-N) over OTN. This information is reported by the Tunnel | |||
| Termination Points (TTPs) within the MPI1 OTN Topology. | Termination Points (TTPs) within the MPI1 OTN Topology. | |||
| In particular, PNC1 will report, within the MPI1 OTN Topology, one | In particular, PNC1 will report, within the MPI1 OTN Topology, one | |||
| TTP for each access link (i.e., AN1-1, AN1-2, AN1-3 and AN1-8) and | TTP for each access link (i.e., AN1-1, AN1-2, AN1-3 and AN1-8) and | |||
| will assign a transition link or an inter-layer lock identifier, | will assign a transition link or an inter-layer lock identifier, | |||
| which is unique across all the TE Topologies PNC1 is exposing at | which is unique across all the TE Topologies PNC1 is exposing at | |||
| MPI1, to each TTP and access link's LTP pair. | MPI1, to each TTP and access link's LTP pair. | |||
| For simplicity purposes, this document assigns the same number to the | For simplicity purposes, this document assigns the same number to the | |||
| skipping to change at page 28, line 42 ¶ | skipping to change at page 27, line 42 ¶ | |||
| (R3)- - -----| S6 |---| S7 |---| S8 |----- - -(S32) | (R3)- - -----| S6 |---| S7 |---| S8 |----- - -(S32) | |||
| :S6-2+----+4 2+----+4 3+----+ : | :S6-2+----+4 2+----+4 3+----+ : | |||
| : / | | : | : / | | : | |||
| (R3)- - ------ S7-3 | | S8-4 : | (R3)- - ------ S7-3 | | S8-4 : | |||
| :S6-3 | | : | :S6-3 | | : | |||
| :...............|........|.......: | :...............|........|.......: | |||
| | | | | | | |||
| (S11) (S12) | (S11) (S12) | |||
| Figure 5: Physical Topology controlled by PNC1 | Figure 5: Physical Topology controlled by PNC1 | |||
| The PNC1 native topology is not exposed and therefore it under PNC | The PNC1 native topology is not exposed, and therefore it is the | |||
| responsibility to abstract the whole domain physical topology as a | PNC's responsibility to abstract the whole domain physical topology | |||
| single TE node and to maintain a mapping between the LTPs exposed at | as a single TE node and to maintain a mapping between the LTPs | |||
| MPI abstract topologies and the associated physical interfaces | exposed at MPI abstract topologies and the associated physical | |||
| controlled by the PNC: | interfaces controlled by the PNC: | |||
| Physical Interface OTN Topology LTP ETH Topology LTP | Physical Interface OTN Topology LTP ETH Topology LTP | |||
| (Figure 5) (Figure 3) (Figure 4) | (Figure 5) (Figure 3) (Figure 4) | |||
| S2-3 AN1-7 | S2-3 AN1-7 | |||
| S3-1 AN1-1 AN1-1 | S3-1 AN1-1 AN1-1 | |||
| S6-1 AN1-8 | S6-1 AN1-8 | |||
| S6-2 AN1-2 | S6-2 AN1-2 | |||
| S6-3 AN1-3 | S6-3 AN1-3 | |||
| S7-3 AN1-4 | S7-3 AN1-4 | |||
| S8-4 AN1-5 | S8-4 AN1-5 | |||
| skipping to change at page 29, line 29 ¶ | skipping to change at page 28, line 29 ¶ | |||
| at MPI1. | at MPI1. | |||
| Appendix B.1.2 provides the detailed JSON code example ("mpi1-eth- | Appendix B.1.2 provides the detailed JSON code example ("mpi1-eth- | |||
| topology.json") describing how the MPI1 ETH Topology is reported by | topology.json") describing how the MPI1 ETH Topology is reported by | |||
| the PNC1, using the [RFC8345], [RFC8795] and [CLIENT-TOPO] YANG | the PNC1, using the [RFC8345], [RFC8795] and [CLIENT-TOPO] YANG | |||
| models, at MPI1. | models, at MPI1. | |||
| It is worth noting that this JSON code example does not provide all | It is worth noting that this JSON code example does not provide all | |||
| the attributes defined in the relevant YANG models, including: | the attributes defined in the relevant YANG models, including: | |||
| o YANG attributes which are outside the scope of this document are | * YANG attributes that are outside the scope of this document are | |||
| not shown; | not shown; | |||
| o The attributes describing the set of label values that are | * The attributes describing the set of label values that are | |||
| available at the inter-domain links (label-restriction container) | available at the inter-domain links (label-restriction container) | |||
| are also not shown to simplify the JSON code example; | are also not shown to simplify the JSON code example; | |||
| o The comments describing the rationale for not including some | * The comments describing the rationale for not including some | |||
| attributes in this JSON code example even if in the scope of this | attributes in this JSON code example even if in the scope of this | |||
| document are identified with the prefix "// __COMMENT" and | document are identified with the prefix "// comment" and included | |||
| included only in the first object instance (e.g., in the Access | only in the first object instance (e.g., in the Access Link from | |||
| Link from the AN1-1 description or in the AN1-1 LTP description). | the AN1-1 description or in the AN1-1 LTP description). | |||
| 5.1.2. Domain 2 Black Topology Abstraction | 5.1.2. Domain 2 Black Topology Abstraction | |||
| PNC2 provides the required black topology abstraction, as described | PNC2 provides the required black topology abstraction, as described | |||
| in Section 4.2, to expose to the MDSC, at MPI2, two TE Topology | in Section 4.1, Paragraph 16, to expose to the MDSC, at MPI2, two TE | |||
| instances with only one TE node each: | Topology instances with only one TE node each: | |||
| o the first instance reports the domain 2 OTN abstract topology view | * the first instance reports the domain 2 OTN abstract topology view | |||
| (MPI2 OTN Topology), with only one abstract node (i.e., AN2) and | (MPI2 OTN Topology), with only one abstract node (i.e., AN2) and | |||
| only inter-domain and access abstract TE links (which represent | only inter-domain and access abstract TE links (which represent | |||
| the inter-domain physical links and the access physical links | the inter-domain physical links and the access physical links that | |||
| which can support ODU, or transparent client layers or both); | can support ODU, transparent client layers, or both); | |||
| o the instance reports the domain 2 Ethernet abstract topology view | * the instance reports the domain 2 Ethernet abstract topology view | |||
| (MPI2 ETH Topology), with only one abstract TE node (i.e., AN2) | (MPI2 ETH Topology), with only one abstract TE node (i.e., AN2) | |||
| and only access abstract TE links (which represent the access | and only access abstract TE links (which represent the access | |||
| physical links which can support Ethernet client layers). | physical links which can support Ethernet client layers). | |||
| PNC2 also reports the ODU termination and adaptation resources which | PNC2 also reports the ODU termination and adaptation resources which | |||
| are available to carry client signals (e.g., Ethernet or STM-N) over | are available to carry client signals (e.g., Ethernet or STM-N) over | |||
| OTN in the TTPs within the MPI2 OTN Topology. | OTN in the TTPs within the MPI2 OTN Topology. | |||
| In particular, PNC2 reports in both the MPI2 OTN Topology and MPI2 | In particular, PNC2 reports in both the MPI2 OTN Topology and MPI2 | |||
| ETH Topology an AN2-1 access link which abstracts the multi-function | ETH Topology an access link that abstracts the multi-function | |||
| physical access link between S18 and R8, which is assumed to | physical access link between S18 and R8, and terminates on the AN2-1 | |||
| correspond to the S18-3 LTP, within the PNC2 native topology. It | LTP that corresponds to the S18-3 physical interface, within the PNC2 | |||
| also reports in the MPI2 ETH Topology a TTP which abstracts the ODU | native topology. It also reports in the MPI2 ODU Topology an AN2-1 | |||
| termination and adaptation resources dedicated to this physical | TTP which abstracts the ODU termination and adaptation resources | |||
| access link and the inter-layer lock between this TTP, and the AN2-1 | dedicated to this physical access link and the inter-layer lock | |||
| LTPs reported within the MPI2 OTN Topology and the MPI2 ETH Topology. | between the AN2-1 TTP, and the AN2-1 LTPs reported within the MPI2 | |||
| OTN Topology and the MPI2 ETH Topology. | ||||
| 5.1.3. Domain 3 White Topology Abstraction | 5.1.3. Domain 3 White Topology Abstraction | |||
| PNC3 provides the required white topology abstraction, as described | PNC3 provides the required white topology abstraction, as described | |||
| in Section 4.2, to expose to the MDSC, at MPI3, two TE Topology | in Section 4.1, Paragraph 16, to expose to the MDSC, at MPI3, two TE | |||
| instances with multiple TE nodes, one for each physical node: | Topology instances with multiple TE nodes, one for each physical | |||
| node: | ||||
| o the first instance reports the domain 3 OTN topology view (MPI3 | * the first instance reports the domain 3 OTN topology view (MPI3 | |||
| OTN Topology), with four TE nodes, which represent the four | OTN Topology), with four TE nodes, which represent the four | |||
| physical nodes (i.e. S31, S32, S33 and S34), and abstract TE | physical nodes (i.e. S31, S32, S33 and S34), and abstract TE | |||
| links, which represent the inter-domain and internal physical | links, which represent the inter-domain and internal physical | |||
| links; | links; | |||
| o the second instance reports the domain 3 Ethernet abstract | * the second instance reports the domain 3 Ethernet abstract | |||
| topology view (MPI3 ETH Topology), with only two TE nodes, which | topology view (MPI3 ETH Topology), with only two TE nodes, which | |||
| represent the two edge physical nodes (i.e., S31 and S33) and only | represent the two edge physical nodes (i.e., S31 and S33) and only | |||
| the two access TE links which represent the access physical links. | the two access TE links which represent the access physical links. | |||
| PNC3 also reports the ODU termination and adaptation resources which | PNC3 also reports the ODU termination and adaptation resources which | |||
| are available to carry client signals (e.g., Ethernet or STM-N) over | are available to carry client signals (e.g., Ethernet or STM-N) over | |||
| OTN in the TTPs within the MPI3 OTN Topology. | OTN in the TTPs within the MPI3 OTN Topology. | |||
| 5.1.4. Multi-domain Topology Merging | 5.1.4. Multi-domain Topology Merging | |||
| MDSC does not have any knowledge of the topologies of each domain | MDSC does not have any knowledge of the topologies of each domain | |||
| until each PNC reports its own abstract topologies, so the MDSC needs | until each PNC reports its abstract topologies, so the MDSC needs to | |||
| to merge these abstract topologies, provided by different PNCs, to | merge these abstract topologies, provided by different PNCs, to build | |||
| build its own topology view of the multi-domain network (MDSC multi- | its topology view of the multi-domain network (MDSC multi-domain | |||
| domain native topology), as described in section 4.3 of [RFC8795]. | native topology), as described in section 4.3 of [RFC8795]. | |||
| The topology of each domain may be in an abstracted shape (refer to | The topology of each domain may be in an abstracted shape (refer to | |||
| section 5.2 of [RFC8453] for a different level of abstraction), while | section 5.2 of [RFC8453] for a different level of abstraction), while | |||
| the inter-domain link information must be complete and fully | the inter-domain link information must be complete and fully | |||
| configured by the MDSC. | configured by the MDSC. | |||
| The inter-domain link information is reported to the MDSC by the two | The inter-domain link information is reported to the MDSC by the two | |||
| PNCs, controlling the two ends of the inter-domain link. | PNCs, controlling the two ends of the inter-domain link. | |||
| The MDSC needs to know how to merge these inter-domain links. One | The MDSC needs to know how to merge these inter-domain links. One | |||
| skipping to change at page 31, line 26 ¶ | skipping to change at page 30, line 26 ¶ | |||
| topologies, terminating on two LTPs reporting the same plug-id value | topologies, terminating on two LTPs reporting the same plug-id value | |||
| can be merged as a single intra-domain link, within any MDSC native | can be merged as a single intra-domain link, within any MDSC native | |||
| topology. | topology. | |||
| The value of the reported plug-id information can be either assigned | The value of the reported plug-id information can be either assigned | |||
| by a central network authority and configured within the two PNC | by a central network authority and configured within the two PNC | |||
| domains. Alternatively, it may be discovered using an automatic | domains. Alternatively, it may be discovered using an automatic | |||
| discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]). | discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]). | |||
| In case the plug-id values are assigned by a central authority, it is | In case the plug-id values are assigned by a central authority, it is | |||
| under the central authority responsibility to assign unique values. | under the central authority's responsibility to assign unique values. | |||
| In case the plug-id values are automatically discovered, the | In case the plug-id values are automatically discovered, the | |||
| information discovered by the automatic discovery mechanisms needs to | information discovered by the automatic discovery mechanisms needs to | |||
| be encoded as a bit string within the plug-id value. This encoding | be encoded as a bit string within the plug-id value. This encoding | |||
| is implementation-specific, but the encoding rules need to be | is implementation-specific, but the encoding rules need to be | |||
| consistent across all the PNCs. | consistent across all the PNCs. | |||
| In case of co-existence within the same network of multiple sources | In case of co-existence within the same network of multiple sources | |||
| for the plug-id (e.g., central authority and automatic discovery or | for the plug-id (e.g., central authority and automatic discovery or | |||
| even different automatic discovery mechanisms), it is needed that the | even different automatic discovery mechanisms), it is needed that the | |||
| plug-id namespace is partitioned to avoid that different sources | plug-id namespace is partitioned to avoid that different sources | |||
| assign the same plug-id value to different inter-domain links. Also, | assign the same plug-id value to different inter-domain links. Also, | |||
| the encoding of the plug-id namespace within the plug-id value is | the encoding of the plug-id namespace within the plug-id value is | |||
| implementation specific and will need to be consistent across all the | implementation-specific and will need to be consistent across all the | |||
| PNCs. | PNCs. | |||
| This document assumes that the plug-id is assigned by a central | This document assumes that the plug-id is assigned by a central | |||
| authority, with the first octet set to 0x00 to represent the central | authority, with the first octet set to 0x00 to represent the central | |||
| authority namespace. The configuration method used, within each PNC | authority namespace. The configuration method used, within each PNC | |||
| domain, are outside the scope of this document. | domain, are outside the scope of this document. | |||
| For example, this document assumes that the following plug-id values | For example, this document assumes that the following plug-id values | |||
| are assigned, by administrative configuration, to the inter-domain | are assigned, by administrative configuration, to the inter-domain | |||
| links shown in Figure 1: | links shown in Figure 1: | |||
| skipping to change at page 32, line 52 ¶ | skipping to change at page 31, line 52 ¶ | |||
| : | + / +--+ : | : | + / +--+ : | |||
| : | |/ / : | : | |/ / : | |||
| : Black +--- AN2 ------------- - -(R7) | : Black +--- AN2 ------------- - -(R7) | |||
| : Topology | | AN2-1 : | : Topology | | AN2-1 : | |||
| : Abstraction | +-------------- - -(R8) | : Abstraction | +-------------- - -(R8) | |||
| : | : | : | : | |||
| : +---------------- - -(R9) | : +---------------- - -(R9) | |||
| : : | : : | |||
| :...............................: | :...............................: | |||
| Figure 6: Multi-domain Abstract Topology controlled by an MDSC | Figure 6: Multi-domain Abstract Topology controlled by an MDSC | |||
| 5.2. YANG Models for Service Configuration | 5.2. YANG Models for Service Configuration | |||
| This section analyses how the MDSC can request the different PNCs to | This section analyses how the MDSC can request the different PNCs to | |||
| setup different multi-domains services, as described in Section 4.3, | setup different multi-domains services, as described in Section 4.3, | |||
| using the TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN | using the TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN | |||
| technology-specific augmentations, defined in [OTN-TUNNEL] with the | technology-specific augmentations, defined in [OTN-TUNNEL] with the | |||
| client service YANG model defined in [CLIENT-SIGNAL]. | client service YANG model defined in [CLIENT-SIGNAL]. | |||
| The service configuration procedure is assumed to be initiated (step | The service configuration procedure is assumed to be initiated (step | |||
| 1 in Figure 7) at the CMI from CNC to MDSC. Analysis of the CMI | 1 in Figure 7) at the CMI from CNC to MDSC. Analysis of the CMI | |||
| models is (e.g., L1CSM, L2SM, VN) is outside the scope of this | models (e.g., L1CSM, L2SM, VN) are outside the scope of this | |||
| document, but it is assumed that the CMI YANG models provide all the | document, but it is assumed that the CMI YANG models provide all the | |||
| information that allows the MDSC to understand that it needs to | information that allows the MDSC to understand that it needs to | |||
| coordinate the setup of a multi-domain ODU data plane connection | coordinate the setup of a multi-domain ODU data plane connection | |||
| (which can be either an end-to-end connection or a segment | (which can be either an end-to-end connection or a segment | |||
| connection) and, when needed, also the configuration of the | connection) and, when needed, also the configuration of the | |||
| adaptation functions in the edge nodes belonging to different | adaptation functions in the edge nodes belonging to different | |||
| domains. | domains. | |||
| | | | | |||
| | {1} | | {1} | |||
| skipping to change at page 34, line 40 ¶ | skipping to change at page 33, line 40 ¶ | |||
| (Network) / ( ) \ V | (Network) / ( ) \ V | |||
| ( Domain 1) / ----- \ ----- | ( Domain 1) / ----- \ ----- | |||
| ( )/ \ (Network) | ( )/ \ (Network) | |||
| A===========B \ ( Domain 3) | A===========B \ ( Domain 3) | |||
| / ( ) \( ) | / ( ) \( ) | |||
| AP-1 ( ) X===========Z | AP-1 ( ) X===========Z | |||
| ----- ( ) \ | ----- ( ) \ | |||
| ( ) AP-2 | ( ) AP-2 | |||
| ----- | ----- | |||
| Figure 7: Multi-domain Service Setup | Figure 7: Multi-domain Service Setup | |||
| As an example, the objective in this section is to configure a | As an example, the objective in this section is to configure a | |||
| connectivity service between R1 and R8, such as one of the services | connectivity service between R1 and R8, such as one of the services | |||
| described in Section 4.3. The inter-domain path is assumed to be R1 | described in Section 4.3. The inter-domain path is assumed to be R1 | |||
| <-> S3 <-> S1 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 <-> R8 | <-> S3 <-> S1 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 <-> R8 | |||
| (see the physical topology in Figure 1). | (see the physical topology in Figure 1). | |||
| According to the different client signal types, different adaptations | According to the different client signal types, different adaptations | |||
| can be required to be configured at the edge nodes (i.e., S3 and | can be required to be configured at the edge nodes (i.e., S3 and | |||
| S18). | S18). | |||
| skipping to change at page 35, line 15 ¶ | skipping to change at page 34, line 15 ¶ | |||
| After receiving such request, MDSC determines the domain sequence, | After receiving such request, MDSC determines the domain sequence, | |||
| i.e., domain 1 <-> domain 3 <-> domain 2, with corresponding PNCs and | i.e., domain 1 <-> domain 3 <-> domain 2, with corresponding PNCs and | |||
| the inter-domain links (step 2 in Figure 7). | the inter-domain links (step 2 in Figure 7). | |||
| As described in [PATH-COMPUTE], the domain sequence can be determined | As described in [PATH-COMPUTE], the domain sequence can be determined | |||
| by running the MDSC own path computation on the MDSC native topology, | by running the MDSC own path computation on the MDSC native topology, | |||
| defined in Section 5.1.4, if and only if the MDSC has enough topology | defined in Section 5.1.4, if and only if the MDSC has enough topology | |||
| information. Otherwise, the MDSC can send path computation requests | information. Otherwise, the MDSC can send path computation requests | |||
| to the different PNCs (steps 2.1, 2.2 and 2.3 in Figure 7) and use | to the different PNCs (steps 2.1, 2.2 and 2.3 in Figure 7) and use | |||
| this information to determine the optimal path on its internal | this information to determine the optimal path on its internal | |||
| topology and therefore the domain sequence. | topology and, therefore, the domain sequence. | |||
| The MDSC will then decompose the tunnel request into a few TE tunnel | The MDSC will then decompose the tunnel request into a few TE tunnel | |||
| segments and request different PNCs to setup each intra-domain TE | segments and request different PNCs to setup each intra-domain TE | |||
| tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 7). | tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 7). | |||
| The MDSC will take care of the configuration of both the intra- | The MDSC will take care of the configuration of both the intra- | |||
| domain TE tunnel segments and inter-domain TE tunnel hand-off via | domain TE tunnel segments and inter-domain TE tunnel hand-off via | |||
| corresponding MPI (using the TE tunnel YANG model defined in | corresponding MPI (using the TE tunnel YANG model defined in | |||
| [TE-TUNNEL] and the OTN tunnel YANG model augmentations defined in | [TE-TUNNEL] and the OTN tunnel YANG model augmentations defined in | |||
| [OTN-TUNNEL]) through all the PNCs controlling the domains selected | [OTN-TUNNEL]) through all the PNCs controlling the domains selected | |||
| skipping to change at page 36, line 7 ¶ | skipping to change at page 35, line 7 ¶ | |||
| in [RFC8795] is being updated to report the label set information. | in [RFC8795] is being updated to report the label set information. | |||
| See section 1.7 of [TE-TUTORIAL] for more details. | See section 1.7 of [TE-TUTORIAL] for more details. | |||
| The MDSC, when coordinating the setup of a multi-domain ODU | The MDSC, when coordinating the setup of a multi-domain ODU | |||
| connection, also configures the data plane resources (i.e., the list | connection, also configures the data plane resources (i.e., the list | |||
| of timeslots and the TPN) to be used on the inter-domain links. The | of timeslots and the TPN) to be used on the inter-domain links. The | |||
| MDSC can know the timeslots which are available on the physical OTN | MDSC can know the timeslots which are available on the physical OTN | |||
| nodes terminating the inter-domain links (e.g., S2 and S31) from the | nodes terminating the inter-domain links (e.g., S2 and S31) from the | |||
| OTN Topology information exposed, at the MPIs, by the PNCs | OTN Topology information exposed, at the MPIs, by the PNCs | |||
| controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling | controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling | |||
| the physical nodes S2 and S31 respectively). | the physical nodes S2 and S31, respectively). | |||
| In any case, the access link configuration is done only on the PNCs | 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) and not on the | that control the access links (e.g., PNC-1 and PNC-3) and not on the | |||
| PNCs of transit domain(s) (e.g., PNC-2). An access link will be | PNCs of transit domain(s) (e.g., PNC-2). An access link will be | |||
| configured by MDSC after the OTN tunnel is set up. | configured by MDSC after the OTN tunnel is set up. | |||
| Access configuration will vary and will be dependent on each type of | Access configuration will vary and will be dependent on each type of | |||
| service. Further discussion and examples are provided in the | service. Further discussion and examples are provided in the | |||
| following sub-sections. | following sub-sections. | |||
| skipping to change at page 36, line 41 ¶ | skipping to change at page 35, line 41 ¶ | |||
| Abstract Topology (Figure 3), exposed by PNC1, and that R8 is | Abstract Topology (Figure 3), exposed by PNC1, and that R8 is | |||
| attached to the access link terminating on AN2-1 LTP in the MPI2 | attached to the access link terminating on AN2-1 LTP in the MPI2 | |||
| Abstract Topology, exposed by PNC2. | Abstract Topology, exposed by PNC2. | |||
| MDSC then performs multi-domain path computation (step 2 in Figure 7) | MDSC then performs multi-domain path computation (step 2 in Figure 7) | |||
| and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3 | and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3 | |||
| respectively, to setup ODU2 (Transit Segment) Tunnels within the OTN | respectively, to setup ODU2 (Transit Segment) Tunnels within the OTN | |||
| Abstract Topologies they expose (MPI1 OTN Abstract Topology, MPI2 OTN | Abstract Topologies they expose (MPI1 OTN Abstract Topology, MPI2 OTN | |||
| Abstract Topology and MPI3 OTN Abstract Topology, respectively). | Abstract Topology and MPI3 OTN Abstract Topology, respectively). | |||
| MDSC requests, at MPI1, PNC1 to setup an ODU2 (Transit Segment) | The MDSC requests, at MPI1, PNC1 to setup an ODU2 (Transit Segment) | |||
| Tunnel with one primary path between AN-1 and AN1-7 LTPs, within the | Tunnel with one primary path between AN-1 and AN1-7 LTPs, within the | |||
| MPI1 OTN Abstract Topology (Figure 3), using the TE Tunnel YANG | MPI1 OTN Abstract Topology (Figure 3), using the TE Tunnel YANG | |||
| model, defined in [TE-TUNNEL], with the OTN technology-specific | model, defined in [TE-TUNNEL], with the OTN technology-specific | |||
| augmentations, defined in [OTN-TUNNEL]: | augmentations, defined in [OTN-TUNNEL]: | |||
| o Source and Destination TTPs are not specified (since it is a | * Source and Destination TTPs are not specified (since it is a | |||
| Transit Tunnel): i.e., the source, src-tp-id, destination and dst- | Transit Tunnel): i.e., the source, src-tp-id, destination and dst- | |||
| tp-id attributes of the TE tunnel instance are empty | tp-id attributes of the TE tunnel instance are empty | |||
| o Ingress and egress points are indicated in the route-object- | * Ingress and egress points are indicated in the route-object- | |||
| include-exclude list of the explicit-route-objects of the primary | include-exclude list of the explicit-route-objects of the primary | |||
| path: | path: | |||
| * The first element references the access link terminating on | - The first element references the access link terminating on | |||
| AN1-1 LTP | AN1-1 LTP | |||
| * The last two element reference respectively the inter-domain | - The last two element reference respectively the inter-domain | |||
| link terminating on AN1-7 LTP and the data plane resources | link terminating on AN1-7 LTP and the data plane resources | |||
| (i.e., the list of timeslots and the TPN) used by the ODU2 | (i.e., the list of timeslots and the TPN) used by the ODU2 | |||
| connection over that link. | connection over that link. | |||
| Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service- | Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service- | |||
| config.json") describing how the setup of this ODU2 (Transit Segment) | config.json") describing how the setup of this ODU2 (Transit Segment) | |||
| Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and | Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and | |||
| [OTN-TUNNEL] YANG models at MPI1. | [OTN-TUNNEL] YANG models at MPI1. | |||
| PNC1 knows, as described in the mapping table in Section 5.1.1, that | PNC1 knows, as described in the mapping table in Section 5.1.1, that | |||
| AN-1 and AN1-7 LTPs within the MPI1 OTN Abstract Topology it exposes | AN-1 and AN1-7 LTPs within the MPI1 OTN Abstract Topology it exposes | |||
| at MPI1 correspond to the S3-1 and S2-3 LTPs, respectively, within | at MPI1 correspond to the S3-1 and S2-3 LTPs, respectively, within | |||
| its native topology. Therefore it performs path computation, for an | its native topology. Therefore it performs path computation for an | |||
| ODU2 connection between these LTPs within its native topology, and | ODU2 connection between these LTPs within its native topology, and | |||
| sets up the ODU2 cross-connections within the physical nodes S3, S1 | sets up the ODU2 cross-connections within the physical nodes S3, S1 | |||
| and S2. | and S2. | |||
| Since the R1-S3 access link is a multi-function access link, PNC1 | Since the R1-S3 access link is a multi-function access link, PNC1 | |||
| also configures the OTU2 trail before setting up the ODU2 cross- | also configures the OTU2 trail before setting up the ODU2 cross- | |||
| connection in node S3. | connection in node S3. | |||
| As part of the OUD2 cross-connection configuration in node S2, PNC1 | As part of the OUD2 cross-connection configuration in node S2, PNC1 | |||
| configures the data plane resources (i.e., the list of timeslots and | configures the data plane resources (i.e., the list of timeslots and | |||
| skipping to change at page 38, line 28 ¶ | skipping to change at page 37, line 31 ¶ | |||
| From its native topology, shown in Figure 6, the MDSC understands, by | From its native topology, shown in Figure 6, the MDSC understands, by | |||
| means which are outside the scope of this document, that R1 is | means which are outside the scope of this document, that R1 is | |||
| attached to the access link terminating on AN1-1 LTP in the MPI1 ETH | attached to the access link terminating on AN1-1 LTP in the MPI1 ETH | |||
| Abstract Topology, exposed by PNC1, and that R8 is attached to the | Abstract Topology, exposed by PNC1, and that R8 is attached to the | |||
| access link terminating on AN2-1 LTP in the MPI2 ETH Abstract | access link terminating on AN2-1 LTP in the MPI2 ETH Abstract | |||
| Topology, exposed by PNC2. | Topology, exposed by PNC2. | |||
| As described in Section 5.1.1 and Section 5.1.2: | As described in Section 5.1.1 and Section 5.1.2: | |||
| o the AN1-1 LTP, within the MPI1 ETH Abstract Topology, and the | * the AN1-1 LTP, within the MPI1 ETH Abstract Topology, and the | |||
| AN1-1 TTP, within the MPI1 OTN Abstract Topology, have the same | AN1-1 TTP, within the MPI1 OTN Abstract Topology, have the same | |||
| IIL identifier (within the scope of MPI1); | IIL identifier (within the scope of MPI1); | |||
| o the AN2-1 LTP, within the MPI2 ETH Abstract Topology, and the | * the AN2-1 LTP, within the MPI2 ETH Abstract Topology, and the | |||
| AN2-1 TTP, within the MPI2 OTN Abstract Topology, have the same | AN2-1 TTP, within the MPI2 OTN Abstract Topology, have the same | |||
| IIL identifier (within the scope of MPI2). | IIL identifier (within the scope of MPI2). | |||
| Therefore, the MDSC also understands that it needs to coordinate the | Therefore, the MDSC also understands that it needs to coordinate the | |||
| setup of a multi-domain ODU2 Tunnel between AN1-1 and AN2-1 TTPs, | setup of a multi-domain ODU2 Tunnel between AN1-1 and AN2-1 TTPs, | |||
| abstracting S3-1 and S18-3 TTPs, within the OTN Abstract Topologies | abstracting the ODU termination and adaptation resources on S3-1 and | |||
| exposed by PNC1 and PNC2, respectively. | S18-3 physical interfaces, within the OTN Abstract Topologies exposed | |||
| by PNC1 and PNC2, respectively. | ||||
| MDSC then performs multi-domain path computation (step 2 in Figure 7) | MDSC then performs multi-domain path computation (step 2 in Figure 7) | |||
| and then requests: | and then requests: | |||
| o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the | * PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the | |||
| MPI1 OTN Abstract Topology; | MPI1 OTN Abstract Topology; | |||
| o PNC1, at MPI1, to steer the Ethernet client traffic from/to AN1-1 | * PNC1, at MPI1, to steer the Ethernet client traffic from/to AN1-1 | |||
| LTP, within the MPI1 ETH Abstract Topology, thought that ODU2 | LTP, within the MPI1 ETH Abstract Topology, thought that ODU2 | |||
| (Head Segment) Tunnel; | (Head Segment) Tunnel; | |||
| o PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within | * PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within | |||
| the MPI3 OTN Abstract Topology; | the MPI3 OTN Abstract Topology; | |||
| o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the MPI2 | * PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the MPI2 | |||
| OTN Abstract Topology; | OTN Abstract Topology; | |||
| o PNC2, at MPI2, to steer the Ethernet client traffic to/from AN2-1 | * PNC2, at MPI2, to steer the Ethernet client traffic to/from AN2-1 | |||
| LTP, within the MPI2 ETH Abstract Topology, through that ODU2 | LTP, within the MPI2 ETH Abstract Topology, through that ODU2 | |||
| (Tail Segment) Tunnel. | (Tail Segment) Tunnel. | |||
| MDSC requests, at MPI1, PNC1 to setup an ODU2 (Head Segment) Tunnel | MDSC requests, at MPI1, PNC1 to setup an ODU2 (Head Segment) Tunnel | |||
| with one primary path between the AN1-1 TTP and AN1-7 LTP, within the | with one primary path between the AN1-1 TTP and AN1-7 LTP, within the | |||
| MPI1 OTN Abstract Topology (Figure 3), using the TE Tunnel YANG | MPI1 OTN Abstract Topology (Figure 3), using the TE Tunnel YANG | |||
| model, defined in [TE-TUNNEL], with the OTN technology-specific | model, defined in [TE-TUNNEL], with the OTN technology-specific | |||
| augmentations, defined in [OTN-TUNNEL]: | augmentations, defined in [OTN-TUNNEL]: | |||
| o Only the Source TTP (i.e., AN1 TE-Node and AN1-1 TTP) is specified | * Only the Source TTP (i.e., AN1 TE-Node and AN1-1 TTP) is specified | |||
| (since it is a Head Segment Tunnel): therefore the Destination TTP | (since it is a Head Segment Tunnel): therefore the Destination TTP | |||
| is not specified | is not specified | |||
| o The egress point in indicated in the route-object-include-exclude | * The egress point in indicated in the route-object-include-exclude | |||
| list of the explicit-route-objects of the primary path: | list of the explicit-route-objects of the primary path: | |||
| * The last two element reference respectively the inter-domain | - The last two element reference respectively the inter-domain | |||
| link terminating on AN1-7 LTP and the data plane resources | link terminating on AN1-7 LTP and the data plane resources | |||
| (i.e., the list of timeslots and the TPN) used by the ODU2 | (i.e., the list of timeslots and the TPN) used by the ODU2 | |||
| connection over that link. | connection over that link. | |||
| Since there is not enough information about which client traffic | ||||
| should be steered to the OTN Tunnel, the ODU2 (Head Segment) Tunnel | ||||
| is setup with the administrative auto state, as defined in | ||||
| [TE-TUNNEL]. | ||||
| Appendix B.2.2 provides the detailed JSON code ("mpi1-odu2-tunnel- | Appendix B.2.2 provides the detailed JSON code ("mpi1-odu2-tunnel- | |||
| config.json") describing how the setup of this ODU2 (Head Segment) | config.json") describing how the setup of this ODU2 (Head Segment) | |||
| Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and | Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and | |||
| [OTN-TUNNEL] YANG models at MPI1. | [OTN-TUNNEL] YANG models at MPI1. | |||
| MDSC requests, at MPI1, PNC1 to steer the Ethernet client traffic | MDSC requests, at MPI1, PNC1 to steer the Ethernet client traffic | |||
| from/to AN1-2 LTP, within the MPI1 ETH Abstract Topology (Figure 4), | from/to AN1-2 LTP, within the MPI1 ETH Abstract Topology (Figure 4), | |||
| thought the MPI1 ODU2 (Head Segment) Tunnel, using the Ethernet | thought the MPI1 ODU2 (Head Segment) Tunnel, using the Ethernet | |||
| Client YANG model, defined in [CLIENT-SIGNAL]. | Client YANG model, defined in [CLIENT-SIGNAL]. | |||
| skipping to change at page 40, line 20 ¶ | skipping to change at page 39, line 31 ¶ | |||
| domain link, as requested by the MDSC. | domain link, as requested by the MDSC. | |||
| After the configuration of the ODU2 cross-connection in node S3, PNC1 | After the configuration of the ODU2 cross-connection in node S3, PNC1 | |||
| also configures the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation | also configures the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation | |||
| functions, within node S3, as shown in Section 4.3.2. | functions, within node S3, as shown in Section 4.3.2. | |||
| Since the R1-S3 access link is a multi-function access link, PNC1 | Since the R1-S3 access link is a multi-function access link, PNC1 | |||
| also configures the 10GE link before this step. | also configures the 10GE link before this step. | |||
| Following similar requests from MDSC to setup ODU2 (Segment) Tunnels | Following similar requests from MDSC to setup ODU2 (Segment) Tunnels | |||
| within the OTN Abstract Topologies they expose as well as the | within the OTN Abstract Topologies, they expose as well as the | |||
| steering of the Ethernet client traffic, PNC3 then sets up ODU2 | steering of the Ethernet client traffic, PNC3 then sets up ODU2 | |||
| cross-connections on nodes S31 and S33 while PNC2 sets up ODU2 cross- | cross-connections on nodes S31 and S33 while PNC2 sets up ODU2 cross- | |||
| connections on nodes S15 and S18 as well as the [ETH -> (ODU2)] and | connections on nodes S15 and S18 as well as the [ETH -> (ODU2)] and | |||
| [(ODU2) -> ETH] adaptation functions in node S18, as shown in | [(ODU2) -> ETH] adaptation functions in node S18, as shown in | |||
| Section 4.3.2. PNC2 also configures the 10GE link on the S18-R8 | Section 4.3.2. PNC2 also configures the 10GE link on the S18-R8 | |||
| multi-function access link. | multi-function access link. | |||
| 5.2.2.1. Single Domain Example | 5.2.2.1. Single Domain Example | |||
| When this IP link, between R1 and R2, is needed, the CNC requests, at | When this IP link, between R1 and R2, is needed, the CNC requests, at | |||
| the CMI, the MDSC to setup an EPL service. | the CMI, the MDSC to setup an EPL service. | |||
| Following the procedures described in Section 5.2.2, the MDSC | Following the procedures described in Section 5.2.2, the MDSC | |||
| requests PCN1 to: | requests PCN1 to: | |||
| o Setup an ODU2 (end-to-end) Tunnel between the AN1-1 and AN1-2 | * Setup an ODU2 (end-to-end) Tunnel between the AN1-1 and AN1-2 | |||
| TTPs, abstracting S3-1 and S6-1 TTPs, within the MPI1 OTN Abstract | TTPs, abstracting S3-1 and S6-1 TTPs, within the MPI1 OTN Abstract | |||
| Topology exposed by PNC1 at MPI1; | Topology exposed by PNC1 at MPI1; | |||
| o Steer the Ethernet client traffic between the AN1-1 and AN1-8 | * Steer the Ethernet client traffic between the AN1-1 and AN1-8 | |||
| LTPs, exposed by PNC1 within MPI1 ETH Abstract Topology, through | LTPs, exposed by PNC1 within MPI1 ETH Abstract Topology, through | |||
| that ODU2 (end-to-end) Tunnel. | that ODU2 (end-to-end) Tunnel. | |||
| Then PNC1 sets up ODU2 cross-connections on nodes S3, S5 and S6 as | Then PNC1 sets up ODU2 cross-connections on nodes S3, S5 and S6 as | |||
| well as the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation functions | well as the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation functions | |||
| in nodes S3 and S6, as shown in Section 4.3.2. PNC1 also configures | in nodes S3 and S6, as shown in Section 4.3.2. PNC1 also configures | |||
| the 10GE link on the R1-S3 multi-function access link (the R2-S6 | the 10GE link on the R1-S3 multi-function access link (the R2-S6 | |||
| access link has been pre-provisioned as a 10GE link, as described in | access link has been pre-provisioned as a 10GE link, as described in | |||
| Section 4.4). | Section 4.4). | |||
| 5.2.3. Other OTN Client Services | 5.2.3. Other OTN Client Services | |||
| In this scenario, described in Section 4.3.3, the access links are | In this scenario, described in Section 4.3.3, the access links are | |||
| configured as STM-64 links and, as described in Section 5.1, reported | configured as STM-64 links and, as described in Section 5.1, reported | |||
| by each PNC as TE Links within the OTN Abstract Topologies they | by each PNC as TE Links within the OTN Abstract Topologies they | |||
| expose to the MDSC. | expose to the MDSC. | |||
| The CNC requests, at the CMI, MDSC to setup an STM-64 Private Line | The CNC requests, at the CMI, MDSC to setup an STM-64 Private Line | |||
| service between R1 and R8. | service between R1 and R8. | |||
| Following similar procedures as described in Section 5.2.2, MDSC | Following similar procedures as described in Section 5.2.2, the MDSC | |||
| understands that: | understands that: | |||
| o R1 is attached to the access link terminating on AN1-1 LTP in the | * R1 is attached to the access link terminating on AN1-1 LTP in the | |||
| MPI1 OTN Abstract Topology, exposed by PNC1, and that R8 is | MPI1 OTN Abstract Topology, exposed by PNC1, and that R8 is | |||
| attached to the access link terminating on AN2-1 LTP in the MPI2 | attached to the access link terminating on AN2-1 LTP in the MPI2 | |||
| OTN Abstract Topology, exposed by PNC2; | OTN Abstract Topology, exposed by PNC2; | |||
| o it needs to coordinate the setup of a multi-domain ODU2 Tunnel | * it needs to coordinate the setup of a multi-domain ODU2 Tunnel | |||
| between the AN1-1 and AN2-1 TTPs, abstracting S3-1 and S18-3 TTPs, | between the AN1-1 and AN2-1 TTPs, abstracting the ODU termination | |||
| and adaptation resources on S3-1 and S18-3 physical interfaces, | ||||
| within the OTN Abstract Topologies exposed by PNC1 and PNC2, | within the OTN Abstract Topologies exposed by PNC1 and PNC2, | |||
| respectively. | respectively. | |||
| The MDSC then performs multi-domain path computation (step 2 in | The MDSC then performs multi-domain path computation (step 2 in | |||
| Figure 7) and then requests: | Figure 7) and then requests: | |||
| o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the | * PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the | |||
| MPI1 OTN Abstract Topology; | MPI1 OTN Abstract Topology; | |||
| o PNC1, at MPI1, to steer the STM-64 transparent client traffic | * PNC1, at MPI1, to steer the STM-64 transparent client traffic | |||
| from/to AN1-1 LTP, within the MPI1 OTN Abstract Topology, thought | from/to AN1-1 LTP, within the MPI1 OTN Abstract Topology, thought | |||
| that ODU2 (Head Segment) Tunnel; | that ODU2 (Head Segment) Tunnel; | |||
| o PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within | * PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within | |||
| the MPI3 OTN Abstract Topology; | the MPI3 OTN Abstract Topology; | |||
| o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the MPI2 | * PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the MPI2 | |||
| OTN Abstract Topology; | OTN Abstract Topology; | |||
| o PNC2, at MPI2, to steer the STM-64 transparent client traffic to/ | * PNC2, at MPI2, to steer the STM-64 transparent client traffic to/ | |||
| from AN2-1 LTP, within the MPI2 ETH Abstract Topology, through | from AN2-1 LTP, within the MPI2 ETH Abstract Topology, through | |||
| that ODU2 (Tail Segment) Tunnel. | that ODU2 (Tail Segment) Tunnel. | |||
| PNC1, PNC2 and PNC3 then sets up the ODU2 cross-connections within | PNC1, PNC2 and PNC3 then sets up the ODU2 cross-connections within | |||
| the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the | the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the | |||
| [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation functions in | [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation functions in | |||
| nodes S3 and S18, as shown in Section 4.3.3. PNC1 and PNC2 also | nodes S3 and S18, as shown in Section 4.3.3. PNC1 and PNC2 also | |||
| configure the STM-64 links on the R1-S3 and R8-S18 multi-function | configure the STM-64 links on the R1-S3 and R8-S18 multi-function | |||
| access links, respectively. | access links, respectively. | |||
| 5.2.3.1. Single Domain Example | 5.2.3.1. Single Domain Example | |||
| When this IP link, between R1 and R3, is needed, the CNC requests, at | When an IP link, between R1 and R3, is needed, the CNC requests, at | |||
| the CMI, the MDSC to setup an STM-64 Private Line service. | the CMI, the MDSC to setup an STM-64 Private Line service. | |||
| The MDSC and PNC1 follows similar procedures as described in | The MDSC and PNC1 follows similar procedures as described in | |||
| Section 5.2.2.1 to set up ODU2 cross-connections on nodes S3, S5 and | Section 5.2.2.1 to set up ODU2 cross-connections on nodes S3, S5 and | |||
| S6 as well as the [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation | S6 as well as the [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation | |||
| functions in nodes S3 and S6, as shown in Section 4.3.3. PNC1 also | functions in nodes S3 and S6, as shown in Section 4.3.3. PNC1 also | |||
| configures the STM-64 links on the R1-S3 and R3-S6 multi-function | configures the STM-64 links on the R1-S3 and R3-S6 multi-function | |||
| access links. | access links. | |||
| 5.2.4. EVPL over ODU Service | 5.2.4. EVPL over ODU Service | |||
| In this scenario, described in Section 4.3.2, the access links are | In this scenario, described in Section 4.3.2, the access links are | |||
| configured as 10GE links, as described in Section 5.2.2 above. | configured as 10GE links, as described in Section 5.2.2 above. | |||
| The CNC requests, at the CMI, the MDSC to setup two EVPL services: | The CNC requests, at the CMI, the MDSC to setup two EVPL services: | |||
| one between R1 and R2, and another between R1 and R8. | one between R1 and R2, and another between R1 and R8. | |||
| Following similar procedures as described in Section 5.2.2 and | Following similar procedures as described in Section 5.2.2 and | |||
| Section 5.2.2.1, MDSC understands that: | Section 5.2.2.1, MDSC understands that: | |||
| o R1 and R2 are attached to the access links terminating | * R1 and R2 are attached to the access links terminating | |||
| respectively on AN1-1 and AN1-8 LTPs in the MPI1 ETH Abstract | respectively on AN1-1 and AN1-8 LTPs in the MPI1 ETH Abstract | |||
| Topology, exposed by PNC1, and that R8 is attached to the access | Topology, exposed by PNC1, and that R8 is attached to the access | |||
| link terminating on AN2-1 LTP in the MPI2 ETH Abstract Topology, | link terminating on AN2-1 LTP in the MPI2 ETH Abstract Topology, | |||
| exposed by PNC2; | exposed by PNC2; | |||
| o To setup the first (single-domain) EVPL service, between R1 and | * To setup the first (single-domain) EVPL service, between R1 and | |||
| R2, it needs to coordinate the setup of a single-domain ODU0 | R2, it needs to coordinate the setup of a single-domain ODU0 | |||
| Tunnel between the AN1-1 and AN1-8 TTPs, abstracting S3-1 and S6-1 | Tunnel between the AN1-1 and AN1-8 TTPs, abstracting S3-1 and S6-1 | |||
| TTPs, within the OTN Abstract Topology exposed by PNC1; | TTPs, within the OTN Abstract Topology exposed by PNC1; | |||
| o To setup the second (multi-domain) EPVL service, between R1 and | * To setup the second (multi-domain) EPVL service, between R1 and | |||
| R8, it needs to coordinate the setup of a multi-domain ODU0 Tunnel | R8, it needs to coordinate the setup of a multi-domain ODU0 Tunnel | |||
| between the AN1-1 and AN2-1 TTPs, abstracting nodes S3-1 and S18-3 | between the AN1-1 and AN2-1 TTPs, abstracting the ODU termination | |||
| TTPs, within the OTN Abstract Topologies exposed by PNC1 and PNC2, | and adaptation resources on S3-1 and S18-3 physical interfaces, | |||
| within the OTN Abstract Topologies exposed by PNC1 and PNC2, | ||||
| respectively. | respectively. | |||
| To setup the first (single-domain) EVPL service between R1 and R2, | To setup the first (single-domain) EVPL service between R1 and R2, | |||
| the MDSC and PNC1 follows similar procedures as described in | the MDSC and PNC1 follows similar procedures as described in | |||
| Section 5.2.2.1 to set up ODU0 cross-connections on nodes S3, S5 and | Section 5.2.2.1 to set up ODU0 cross-connections on nodes S3, S5 and | |||
| S6 as well as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation | S6 as well as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation | |||
| functions, in nodes S3 and S6, as shown in Section 4.3.2. PNC1 also | functions, in nodes S3 and S6, as shown in Section 4.3.2. PNC1 also | |||
| configures the 10GE link on the R1-S3 multi-function access link. | configures the 10GE link on the R1-S3 multi-function access link. | |||
| As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation | As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation | |||
| functions configurations in nodes S2 and S6, PNC1 configures also the | functions configurations in nodes S2 and S6, PNC1 configures also the | |||
| classification rules required to associated only the Ethernet client | classification rules required to associate only the Ethernet client | |||
| traffic received with VLAN ID 10 on the R1-S3 and R2-S6 access links | traffic received with VLAN ID 10 on the R1-S3 and R2-S6 access links | |||
| with this EVPL service. The MDSC provides this information to PNC1 | with this EVPL service. The MDSC provides this information to PNC1 | |||
| using the [CLIENT-SIGNAL] model. | using the [CLIENT-SIGNAL] model. | |||
| To setup the second (multi-domain) EVPL service between R1 and R8, | To setup the second (multi-domain) EVPL service between R1 and R8, | |||
| the MDSC, PNC1, PNC2 and PNC3 follows similar procedures as described | the MDSC, PNC1, PNC2 and PNC3 follows similar procedures as described | |||
| in Section 5.2.2 to setup the ODU0 cross-connections within the | in Section 5.2.2 to setup the ODU0 cross-connections within the | |||
| physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the [VLAN | physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the [VLAN | |||
| -> (ODU0)] and [(ODU0) -> VLAN] adaptation functions in nodes S3 and | -> (ODU0)] and [(ODU0) -> VLAN] adaptation functions in nodes S3 and | |||
| S18, as shown in Section 4.3.2. PNC2 also configures the 10GE link | S18, as shown in Section 4.3.2. PNC2 also configures the 10GE link | |||
| skipping to change at page 43, line 43 ¶ | skipping to change at page 43, line 7 ¶ | |||
| 5.3.1. Linear Protection (end-to-end) | 5.3.1. Linear Protection (end-to-end) | |||
| As described in Section 4.5.1, the MDSC can decide to protect a | As described in Section 4.5.1, the MDSC can decide to protect a | |||
| multi-domain connectivity service by setting up ODU linear protection | multi-domain connectivity service by setting up ODU linear protection | |||
| switching between edge nodes controlled by different PNCs (e.g., | switching between edge nodes controlled by different PNCs (e.g., | |||
| nodes S3 and S8, controlled by PNC1 and PNC2 respectively, to protect | nodes S3 and S8, controlled by PNC1 and PNC2 respectively, to protect | |||
| services between R1 and R8). | services between R1 and R8). | |||
| MDSC performs path computation, as described in Section 5.2, to | MDSC performs path computation, as described in Section 5.2, to | |||
| compute both the paths for working and protection transport entities: | compute both the paths for working and protection transport entities: | |||
| the computed paths can pass through these same PNC domains or through | the computed paths can pass through these exact PNC domains or | |||
| different transit PNC domains. | through different transit PNC domains. | |||
| Considering the case, described in Section 4.5.1, where the working | Considering the case, described in Section 4.5.1, where the working | |||
| and protection transport entities pass through the same domain, MDSC | and protection transport entities pass through the same domain, MDSC | |||
| would perform the same steps described in Section 5.2 to setup the | would perform the same steps described in Section 5.2 to setup the | |||
| ODU Tunnel and to configure the steering of the client traffic | ODU Tunnel and to configure the steering of the client traffic | |||
| between the access links and the ODU Tunnel. The only differences | between the access links and the ODU Tunnel. The only differences | |||
| are in the configuration of the ODU Tunnels. | are in the configuration of the ODU Tunnels. | |||
| MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment) | MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment) | |||
| Tunnel within the MPI1 OTN Abstract Topology (Figure 3), using the TE | Tunnel within the MPI1 OTN Abstract Topology (Figure 3), using the TE | |||
| Tunnel YANG model, defined in [TE-TUNNEL], with the OTN technology- | Tunnel YANG model, defined in [TE-TUNNEL], with the OTN technology- | |||
| specific augmentations, defined in [OTN-TUNNEL], with one primary | specific augmentations, defined in [OTN-TUNNEL], with one primary | |||
| path and one secondary path with 1+1 protection switching enabled: | path and one secondary path with 1+1 protection switching enabled: | |||
| o Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a | * Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a | |||
| Head Segment Tunnel), as described in Section 5.2.2; | Head Segment Tunnel), as described in Section 5.2.2; | |||
| o The egress point for the working transport entity in indicated in | * The egress point for the working transport entity in indicated in | |||
| the route-object-include-exclude list of the explicit-route- | the route-object-include-exclude list of the explicit-route- | |||
| objects of the primary path, as described in Section 5.2.2; | objects of the primary path, as described in Section 5.2.2; | |||
| o The protection switching end-point in indicated in the route- | * The protection switching end-point in indicated in the route- | |||
| object-include-exclude list of the explicit-route-objects of the | object-include-exclude list of the explicit-route-objects of the | |||
| secondary path: | secondary path: | |||
| * The first element references the TE-Node of the Source TTP | - The first element references the TE-Node of the Source TTP | |||
| (i.e., AN1 TE-Node); | (i.e., AN1 TE-Node); | |||
| o The egress point for the protection transport entity in indicated | * The egress point for the protection transport entity in indicated | |||
| in the route-object-include-exclude list of the explicit-route- | in the route-object-include-exclude list of the explicit-route- | |||
| objects of the secondary path: | objects of the secondary path: | |||
| * The last two element reference respectively the inter-domain | - The last two element reference respectively the inter-domain | |||
| link terminating on AN1-6 LTP and the data plane resources | link terminating on AN1-6 LTP and the data plane resources | |||
| (i.e., the list of timeslots and the TPN) used by the ODU2 | (i.e., the list of timeslots and the TPN) used by the ODU2 | |||
| connection over that link. | connection over that link. | |||
| PNC1 knows, as described in the table in Section 5.1.1, that the | PNC1 knows, as described in the table in Section 5.1.1, that the | |||
| AN1-1 TTP, AN1-7 LTP and the AN1-6 LTP, within the MPI1 OTN Abstract | AN1-1 TTP, AN1-7 LTP and the AN1-6 LTP, within the MPI1 OTN Abstract | |||
| Topology it exposes at MPI1, correspond to S3-1 TTP, S2-3 LTP and the | Topology it exposes at MPI1, correspond to S3-1 TTP, S2-3 LTP and the | |||
| S8-5 LTP, respectively, within its native topology. It also | S8-5 LTP, respectively, within its native topology. It also | |||
| understands, from the route-object-include-exclude list of the | understands, from the route-object-include-exclude list of the | |||
| explicit-route-objects of the secondary path configuration (whose | explicit-route-objects of the secondary path configuration (whose | |||
| last two elements represent an inter-domain link), that node S3 is | last two elements represent an inter-domain link), that node S3 is | |||
| the end-point of the protection group while the other end-point is | the end-point of the protection group while the other end-point is | |||
| outside of its control domain. | outside of its control domain. | |||
| PNC1 can performs path computation within its native topology and | PNC1 can perform path computation within its native topology and | |||
| setup the ODU connections in nodes S3, S1, S2, S4 and S8 as well as | setup the ODU connections in nodes S3, S1, S2, S4 and S8 as well as | |||
| configure the protection group in node S3. | configure the protection group in node S3. | |||
| 5.3.2. Segmented Protection | 5.3.2. Segmented Protection | |||
| Under specific policies, it is possible to deploy a segmented | Under specific policies, it is possible to deploy a segmented | |||
| protection for multi-domain services. The configuration of the | protection for multi-domain services. The configuration of the | |||
| segmented protection can be divided into a few steps, considering the | segmented protection can be divided into a few steps, considering the | |||
| example in Section 4.5.2, the following steps would be used. | example in Section 4.5.2, the following steps would be used. | |||
| skipping to change at page 45, line 21 ¶ | skipping to change at page 44, line 40 ¶ | |||
| the ODU Tunnel and to configure the steering of the client traffic | the ODU Tunnel and to configure the steering of the client traffic | |||
| between the access links and the ODU Tunnel. The only differences | between the access links and the ODU Tunnel. The only differences | |||
| are in the configuration of the ODU Tunnels. | are in the configuration of the ODU Tunnels. | |||
| MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment) | MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment) | |||
| Tunnel within the MPI1 OTN Abstract Topology (Figure 3), using the TE | Tunnel within the MPI1 OTN Abstract Topology (Figure 3), using the TE | |||
| Tunnel YANG model, defined in [TE-TUNNEL], with the OTN technology- | Tunnel YANG model, defined in [TE-TUNNEL], with the OTN technology- | |||
| specific augmentations, defined in [OTN-TUNNEL], with one primary | specific augmentations, defined in [OTN-TUNNEL], with one primary | |||
| path and one secondary path with 1+1 protection switching enabled: | path and one secondary path with 1+1 protection switching enabled: | |||
| o Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a | * Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a | |||
| Head Segment Tunnel), as described in Section 5.2.2; | Head Segment Tunnel), as described in Section 5.2.2; | |||
| o The egress point (i.e., AN1-7 LTP) is indicated in the route- | * The egress point (i.e., AN1-7 LTP) is indicated in the route- | |||
| object-include-exclude list of the explicit-route-objects of the | object-include-exclude list of the explicit-route-objects of the | |||
| primary path, as described in Section 5.2.2; | primary path, as described in Section 5.2.2; | |||
| o The protection switching end-points are indicated in the route- | * The protection switching end-points are indicated in the route- | |||
| object-include-exclude list of the explicit-route-objects of the | object-include-exclude list of the explicit-route-objects of the | |||
| secondary path: | secondary path: | |||
| * The first element references the TE-Node of the Source TTP | - The first element references the TE-Node of the Source TTP | |||
| (i.e., AN1 TE-Node); | (i.e., AN1 TE-Node); | |||
| * The last element references the TE-Node of the egress point | - The last element references the TE-Node of the egress point | |||
| (i.e., AN1 TE-Node). | (i.e., AN1 TE-Node). | |||
| As described in Section 5.2.2, PNC1 knows that the AN1-1 TTP and the | As described in Section 5.2.2, PNC1 knows that the AN1-1 TTP and the | |||
| AN1-7 LTP, within the MPI1 OTN Abstract Topology it exposes at MPI1, | AN1-7 LTP, within the MPI1 OTN Abstract Topology it exposes at MPI1, | |||
| correspond to S3-1 TTP and the S2-3 LTP, respectively, within its | correspond to S3-1 TTP and the S2-3 LTP, respectively, within its | |||
| native topology. It also understands, from the route-object-include- | native topology. It also understands, from the route-object-include- | |||
| exclude list of the explicit-route-objects of the secondary path | exclude list of the explicit-route-objects of the secondary path | |||
| configuration (whole last element represent an abstract node | configuration (whole last element represent an abstract node | |||
| terminating the inter-domain link used for the primary path), that | terminating the inter-domain link used for the primary path), that | |||
| skipping to change at page 46, line 17 ¶ | skipping to change at page 45, line 34 ¶ | |||
| expose. PNC3 then sets up ODU2 cross-connections on nodes S31, S32, | expose. PNC3 then sets up ODU2 cross-connections on nodes S31, S32, | |||
| S33 and S34 and segment protection between nodes S31 and D34. PNC2 | S33 and S34 and segment protection between nodes S31 and D34. PNC2 | |||
| sets up ODU2 cross-connections on nodes S15, S12, S17 and S18 and | sets up ODU2 cross-connections on nodes S15, S12, S17 and S18 and | |||
| segment protection between nodes S15 and S18. | segment protection between nodes S15 and S18. | |||
| MDSC stitch the configuration above to form its internal view of the | MDSC stitch the configuration above to form its internal view of the | |||
| end-to-end tunnel with segmented protection. | end-to-end tunnel with segmented protection. | |||
| Given the configuration above, the protection capability has been | Given the configuration above, the protection capability has been | |||
| deployed on the tunnels. The head-end node of each domain can do the | deployed on the tunnels. The head-end node of each domain can do the | |||
| switching once there is a failure on one the tunnel segment. For | switching once there is a failure on one of the tunnel segments. For | |||
| example, in Network domain 1, when there is a failure on the S1-S2 | example, in Network domain 1, when there is a failure on the S1-S2 | |||
| lin, the head-end nodes S2 and S3 will automatically do the switching | lin, the head-end nodes S2 and S3 will automatically do the switching | |||
| to S3-S4-S8-S2. This switching will be reported to the corresponding | to S3-S4-S8-S2. This switching will be reported to the corresponding | |||
| PNC (PNC1 in this example) and then MDSC. Other PNCs (PNC2 and PNC3 | PNC (PNC1 in this example) and then MDSC. Other PNCs (PNC2 and PNC3 | |||
| in this example) will not be aware of the failure and switching, nor | in this example) will not be aware of the failure and switching, nor | |||
| do the nodes in Network domain 2 and 3. | do the nodes in network domains 2 and 3. | |||
| 5.4. Notifications | 5.4. Notifications | |||
| Notification mechanisms are required for the scenarios analyzed in | Notification mechanisms are required for the scenarios analyzed in | |||
| this draft, as described in Section 4.6. | this draft, as described in Section 4.6. | |||
| The notification mechanisms are protocol-dependent. It is assumed | The notification mechanisms are protocol-dependent. It is assumed | |||
| that the RESTCONF protocol, defined in [RFC8040], is used at the MPIs | that the RESTCONF protocol, defined in [RFC8040] is optional, and may | |||
| mentioned in this document. | be used at the MPIs mentioned in this document. | |||
| On the perspective of MPI, the MDSC is the client while the PNC is | From the perspective of MPI, the MDSC is the client while the PNC is | |||
| acting as the server of the notification. The essential event | acting as the server of the notification. The essential event | |||
| streams, subscription and processing rules after receiving | streams, subscription and processing rules after receiving | |||
| notification can be found in section 6 of [RFC8040]. | notification can be found in section 6 of [RFC8040]. | |||
| Additional alarm reporting functions and alarm report management may | ||||
| be found in [ITU-T_X.733] and [ITU-T_X.734] | ||||
| Further detailed analysis of notification management is outside the | ||||
| scope of this document. | ||||
| 5.5. Path Computation with Constraints | 5.5. Path Computation with Constraints | |||
| The path computation constraints that can be supported at the MPI | The path computation constraints that can be supported at the MPI | |||
| using the IETF YANG models defined in [TE-TUNNEL] and [PATH-COMPUTE]. | using the IETF YANG models defined in [TE-TUNNEL] and [PATH-COMPUTE]. | |||
| When there is a technology-specific network (e.g., OTN), the | When there is a technology-specific network (e.g., OTN), the | |||
| corresponding technology (e.g., OTN) model should also be used to | corresponding technology (e.g., OTN) model should also be used to | |||
| specify the tunnel information on MPI, with the constraint included | specify the tunnel information on MPI, with the constraint included | |||
| in TE Tunnel model. | in TE Tunnel model. | |||
| Further detailed analysis is outside the scope of this document | Further detailed analysis is outside the scope of this document. | |||
| 6. Security Considerations | 6. Security Considerations | |||
| This document analyses the applicability of the YANG models being | This document analyses the applicability of the YANG models being | |||
| defined by the IETF to support OTN single and multi-domain scenarios. | defined by the IETF to support OTN single and multi-domain scenarios. | |||
| When deploying ACTN functional components the securing of external | When deploying ACTN functional components the securing of external | |||
| interfaces and hardening of resource datastores, the protection of | interfaces and hardening of resource datastores, the protection of | |||
| confidential information, and limiting the access of function, should | confidential information, and limit the access of function, should | |||
| all be carefully considered. Section 9 of [RFC8453] highlights that | all be carefully considered. Section 9 of [RFC8453] highlights that | |||
| implementations should consider encrypting data that flows between | implementations should consider encrypting data that flows between | |||
| key components, especially when they are implemented at remote node. | key components, especially when they are implemented at remote nodes. | |||
| Further discussion on securing the interface between the MDSC and | Further discussion on securing the interface between the MDSC and | |||
| PNCs via the MDSC-PNC Interface (MPI) is discussed in section 9.2 of | PNCs via the MDSC-PNC Interface (MPI) is discussed in section 9.2 of | |||
| [RFC8453]. | [RFC8453]. | |||
| The YANG modules highlighted in this document are designed to be | The YANG modules highlighted in this document are designed to be | |||
| accessed via network configuration protocols such as NETCONF | accessed via network configuration protocols such as NETCONF | |||
| [RFC6241] or RESTCONF [RFC8040]. When using NETCONF, utilizing a | [RFC6241] or RESTCONF [RFC8040]. When using NETCONF, utilizing a | |||
| secure transport via Secure Shell (SSH) [RFC6242] is mandatory. If | secure transport via Secure Shell (SSH) [RFC6242] is mandatory. If | |||
| using RESTCONF, then secure transport via TLS [RFC8446] is mandatory. | using RESTCONF, then secure transport via TLS [RFC8446] is mandatory. | |||
| When using either NETCONF or RESTCONF, the use of Network | When using either NETCONF or RESTCONF, the use of Network | |||
| Configuration Access Control Model (NACM) [RFC8341] may be used to | Configuration Access Control Model (NACM) [RFC8341] may be used to | |||
| restrict access to specific protocol operations and content. | restrict access to specific protocol operations and content. | |||
| 6.1. OTN Security | 6.1. OTN Security | |||
| Inherently OTN networks ensure privacy and security via hard | Inherently OTN networks ensure privacy and security via hard | |||
| partitioning of traffic onto dedicated circuits. The separation of | partitioning of traffic onto dedicated circuits. The separation of | |||
| network traffic makes it difficult to intercept data transferred | network traffic makes it difficult to intercept data transferred | |||
| between nodes over OTN-channelized links. | between nodes over OTN-channelized links. | |||
| In OTN the (General Communication Channel) GCC is used for OAM | Within OTN environments, the (General Communication Channel) GCC is | |||
| functions such as performance monitoring, fault detection, and | used for OAM functions such as performance monitoring, fault | |||
| signaling. The GCC control channel should be secured using a | detection, and signaling. The GCC control channel should be secured | |||
| suitable mechanism. | using a suitable mechanism. | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| This document requires no IANA actions. | This document requires no IANA actions. | |||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [CLIENT-SIGNAL] | [CLIENT-SIGNAL] | |||
| Zheng, H., Guo, A., Busi, I., Snitser, A., Lazzeri, F., | Zheng, H., Guo, A., Busi, I., Snitser, A., and F. Lazzeri, | |||
| Xu, Y., Zhao, Y., Liu, X., and G. Fioccola, "A YANG Data | "A YANG Data Model for Transport Network Client Signals", | |||
| Model for Transport Network Client Signals", draft-ietf- | Work in Progress, Internet-Draft, draft-ietf-ccamp-client- | |||
| ccamp-client-signal-yang-05 (work in progress), July 2021. | signal-yang-06, 5 January 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-ccamp-client- | ||||
| signal-yang-06.txt>. | ||||
| [CLIENT-TOPO] | [CLIENT-TOPO] | |||
| Zheng, H., Guo, A., Busi, I., Xu, Y., Zhao, Y., and X. | Zheng, H., Guo, A., Busi, I., Xu, Y., Zhao, Y., and X. | |||
| Liu, "A YANG Data Model for Ethernet TE Topology", draft- | Liu, "A YANG Data Model for Ethernet TE Topology", Work in | |||
| ietf-ccamp-eth-client-te-topo-yang-01 (work in progress), | Progress, Internet-Draft, draft-ietf-ccamp-eth-client-te- | |||
| September 2021. | topo-yang-02, 7 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-ccamp-eth- | ||||
| client-te-topo-yang-02.txt>. | ||||
| [ITU-T_G.709] | [ITU-T_G.709] | |||
| ITU-T Recommendation G.709, "Interfaces for the optical | ITU-T Recommendation G.709, "Interfaces for the optical | |||
| transport network", ITU-T G.709 , March 2020. | transport network", ITU-T G.709 , March 2020. | |||
| [ITU-T_G.808.1] | [ITU-T_G.808.1] | |||
| ITU-T Recommendation G.808.1, "Generic protection | International Telecommunication Union, "Generic protection | |||
| switching - Linear trail and subnetwork protection", ITU-T | switching - Linear trail and subnetwork protection", ITU-T | |||
| G.808.1 , May 2014. | Recommendation G.808.1 , May 2014. | |||
| [ITU-T_G.873.1] | [ITU-T_G.873.1] | |||
| ITU-T Recommendation G.873.1, "Optical transport network | International Telecommunication Union, "Optical transport | |||
| (OTN): Linear protection", ITU-T G.808.1 , October 2017. | network (OTN): Linear protection", ITU-T Recommendation | |||
| G.873.1 , October 2017. | ||||
| [OTN-TOPO] | [OTN-TOPO] Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D. | |||
| Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D. | ||||
| Dios, "A YANG Data Model for Optical Transport Network | Dios, "A YANG Data Model for Optical Transport Network | |||
| Topology", draft-ietf-ccamp-otn-topo-yang-13 (work in | Topology", Work in Progress, Internet-Draft, draft-ietf- | |||
| progress), July 2021. | ccamp-otn-topo-yang-14, 7 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-ccamp-otn- | ||||
| topo-yang-14.txt>. | ||||
| [OTN-TUNNEL] | [OTN-TUNNEL] | |||
| Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, | Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, | |||
| "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- | "OTN Tunnel YANG Model", Work in Progress, Internet-Draft, | |||
| model-14 (work in progress), July 2021. | draft-ietf-ccamp-otn-tunnel-model-15, 7 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-ccamp-otn- | ||||
| tunnel-model-15.txt>. | ||||
| [PATH-COMPUTE] | [PATH-COMPUTE] | |||
| Busi, I., Belotti, S., Lopez, V., Sharma, A., and Y. Shi, | Busi, I., Belotti, S., Dios, O. G. D., Sharma, A., and D. | |||
| "YANG Data Model for requesting Path Computation", draft- | Ceccarelli, "A YANG Data Model for requesting path | |||
| ietf-teas-yang-path-computation-16 (work in progress), | computation", Work in Progress, Internet-Draft, draft- | |||
| September 2021. | ietf-teas-yang-path-computation-18, 22 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-teas-yang- | ||||
| path-computation-18.txt>. | ||||
| [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery | [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery | |||
| (Protection and Restoration) Terminology for Generalized | (Protection and Restoration) Terminology for Generalized | |||
| Multi-Protocol Label Switching (GMPLS)", RFC 4427, | Multi-Protocol Label Switching (GMPLS)", RFC 4427, | |||
| DOI 10.17487/RFC4427, March 2006, | DOI 10.17487/RFC4427, March 2006, | |||
| <https://www.rfc-editor.org/info/rfc4427>. | <https://www.rfc-editor.org/info/rfc4427>. | |||
| [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation | [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path | |||
| Element (PCE)-Based Architecture", RFC 4655, | Computation Element (PCE)-Based Architecture", RFC 4655, | |||
| DOI 10.17487/RFC4655, August 2006, | DOI 10.17487/RFC4655, August 2006, | |||
| <https://www.rfc-editor.org/info/rfc4655>. | <https://www.rfc-editor.org/info/rfc4655>. | |||
| [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the | ||||
| Path Computation Element Communication Protocol (PCEP) for | ||||
| Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April | ||||
| 2009, <https://www.rfc-editor.org/info/rfc5521>. | ||||
| [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., | [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., | |||
| Ceccarelli, D., and X. Zhang, "Problem Statement and | Ceccarelli, D., and X. Zhang, "Problem Statement and | |||
| Architecture for Information Exchange between | Architecture for Information Exchange between | |||
| Interconnected Traffic-Engineered Networks", BCP 206, | Interconnected Traffic-Engineered Networks", BCP 206, | |||
| RFC 7926, DOI 10.17487/RFC7926, July 2016, | RFC 7926, DOI 10.17487/RFC7926, July 2016, | |||
| <https://www.rfc-editor.org/info/rfc7926>. | <https://www.rfc-editor.org/info/rfc7926>. | |||
| [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., | [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., | |||
| Ananthakrishnan, H., and X. Liu, "A YANG Data Model for | Ananthakrishnan, H., and X. Liu, "A YANG Data Model for | |||
| Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March | Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March | |||
| skipping to change at page 49, line 37 ¶ | skipping to change at page 49, line 32 ¶ | |||
| [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and | [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and | |||
| O. Gonzalez de Dios, "YANG Data Model for Traffic | O. Gonzalez de Dios, "YANG Data Model for Traffic | |||
| Engineering (TE) Topologies", RFC 8795, | Engineering (TE) Topologies", RFC 8795, | |||
| DOI 10.17487/RFC8795, August 2020, | DOI 10.17487/RFC8795, August 2020, | |||
| <https://www.rfc-editor.org/info/rfc8795>. | <https://www.rfc-editor.org/info/rfc8795>. | |||
| [TE-TUNNEL] | [TE-TUNNEL] | |||
| Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., | Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., | |||
| and O. G. D. Dios, "A YANG Data Model for Traffic | and O. G. D. Dios, "A YANG Data Model for Traffic | |||
| Engineering Tunnels, Label Switched Paths and Interfaces", | Engineering Tunnels, Label Switched Paths and Interfaces", | |||
| draft-ietf-teas-yang-te-27 (work in progress), July 2021. | Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- | |||
| 29, 7 February 2022, <https://www.ietf.org/archive/id/ | ||||
| draft-ietf-teas-yang-te-29.txt>. | ||||
| 8.2. Informative References | 8.2. Informative References | |||
| [ACTN-YANG] | [ACTN-YANG] | |||
| Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. | Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. | |||
| Belotti, "Applicability of YANG models for Abstraction and | Belotti, "Applicability of YANG models for Abstraction and | |||
| Control of Traffic Engineered Networks", draft-ietf-teas- | Control of Traffic Engineered Networks", Work in Progress, | |||
| actn-yang-08 (work in progress), September 2021. | Internet-Draft, draft-ietf-teas-actn-yang-09, 7 March | |||
| 2022, <https://www.ietf.org/archive/id/draft-ietf-teas- | ||||
| actn-yang-09.txt>. | ||||
| [MEF55] Metro Ethernet Forum, "Lifecycle Service Orchestration | [ITU-T_X.733] | |||
| (LSO): Reference Architecture and Framework", Technical | International Telecommunication Union, "Information | |||
| Specification MEF 55 , March 2016, | technology - Open Systems Interconnection - Systems | |||
| Management: Alarm reporting function", ITU-T | ||||
| Recommendation X.733 , February 1992. | ||||
| [ITU-T_X.734] | ||||
| International Telecommunication Union, "Information | ||||
| technology - Open Systems Interconnection - Systems | ||||
| Management: Event report management function", ITU-T | ||||
| Recommendation X.734 , September 1992. | ||||
| [MEF55] MEF Forum, "Lifecycle Service Orchestration (LSO): | ||||
| Reference Architecture and Framework", MEF 55 , March | ||||
| 2016, | ||||
| <https://www.mef.net/Assets/Technical_Specifications/PDF/ | <https://www.mef.net/Assets/Technical_Specifications/PDF/ | |||
| MEF_55.pdf>. | MEF_55.pdf>. | |||
| [ONF_TR-527] | [ONF_TR-527] | |||
| ONF Technical Recommendation TR-527, "Functional | Open Networking Foundation, "Functional Requirements for | |||
| Requirements for Transport API", ONF TR-527 , May 2014. | Transport API", ONF Technical Recommendation TR-527 , May | |||
| 2014. | ||||
| [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | |||
| and A. Bierman, Ed., "Network Configuration Protocol | and A. Bierman, Ed., "Network Configuration Protocol | |||
| (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | |||
| <https://www.rfc-editor.org/info/rfc6241>. | <https://www.rfc-editor.org/info/rfc6241>. | |||
| [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | |||
| Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | |||
| <https://www.rfc-editor.org/info/rfc6242>. | <https://www.rfc-editor.org/info/rfc6242>. | |||
| skipping to change at page 50, line 47 ¶ | skipping to change at page 51, line 12 ¶ | |||
| Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
| <https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
| [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, | [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, | |||
| "Handling Long Lines in Content of Internet-Drafts and | "Handling Long Lines in Content of Internet-Drafts and | |||
| RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, | RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, | |||
| <https://www.rfc-editor.org/info/rfc8792>. | <https://www.rfc-editor.org/info/rfc8792>. | |||
| [TE-TUTORIAL] | [TE-TUTORIAL] | |||
| Bryskin, I., Beeram, V. P., Saad, T., and X. Liu, "TE | Bryskin, I., Beeram, V. P., Saad, T., and X. Liu, "TE | |||
| Topology and Tunnel Modeling for Transport Networks", | Topology and Tunnel Modeling for Transport Networks", Work | |||
| draft-ietf-teas-te-topo-and-tunnel-modeling-06 (work in | in Progress, Internet-Draft, draft-ietf-teas-te-topo-and- | |||
| progress), July 2020. | tunnel-modeling-06, 12 July 2020, | |||
| <https://www.ietf.org/archive/id/draft-ietf-teas-te-topo- | ||||
| and-tunnel-modeling-06.txt>. | ||||
| Appendix A. Validating a JSON fragment against a YANG Model | Appendix A. Validating a JSON fragment against a YANG Model | |||
| The objective is to have a tool that allows validating whether a | The objective is to have a tool that allows validating whether a | |||
| piece of JSON code embedded in an Internet-Draft is compliant with a | piece of JSON code embedded in an Internet-Draft is compliant with a | |||
| YANG model without using a client/server. | YANG model without using a client/server. | |||
| A.1. Manipulation of JSON fragments | A.1. JSON CODE | |||
| This document provides some detailed JSON code examples to describe | ||||
| how the YANG models being developed by the IETF (TEAS and CCAMP WG in | ||||
| particular) may be used. The scenario examples are provided using | ||||
| JSON to facilitate readability. | ||||
| Different objects need to have an identifier. The convention used to | ||||
| create mnemonic identifiers is to use the object name (e.g., S3 for | ||||
| node S3), followed by its type (e.g., NODE), separated by a "-", | ||||
| followed by "-ID". For example, the mnemonic identifier for AN1 | ||||
| would be AN1-NODE-ID. | ||||
| The JSON language does not inherently support the insertion of | ||||
| comments. This document will insert comments into the JSON code as | ||||
| JSON name/value pair with the JSON name string starting with the "//" | ||||
| characters. For example, when describing the example of a TE | ||||
| Topology instance representing the ODU Abstract Topology exposed by | ||||
| the Transport PNC, the following comment has been added to the JSON | ||||
| code: | ||||
| "// comment": "ODU Abstract Topology @ MPI", | ||||
| The JSON code examples provided in this document have been validated | ||||
| against the YANG models following the validation process described in | ||||
| Appendix A, which would not consider the comments. | ||||
| To have successful validation of the examples, some numbering scheme | ||||
| has been defined to assign identifiers to the different entities | ||||
| which would pass the syntax checks. In that case, to simplify the | ||||
| reading, another JSON name/value pair formatted as a comment and | ||||
| using the mnemonic identifiers is also provided. For example, the | ||||
| identifier of AN1 (AN1-NODE-ID) has been assumed to be "192.0.2.1" | ||||
| and would be shown in the JSON code example using the two JSON name/ | ||||
| value pair: | ||||
| "// te-node-id": "AN1-NODE-ID", | ||||
| "te-node-id": "192.0.2.1", | ||||
| The first JSON name/value pair will be automatically removed in the | ||||
| first step of the validation process, while the second JSON name/ | ||||
| value pair will be validated against the YANG model definitions. | ||||
| A.2. Manipulation of JSON fragments | ||||
| This section describes the various ways JSON fragments are used in | This section describes the various ways JSON fragments are used in | |||
| the I-D processing and how to manage them. | the I-D processing and how to manage them. | |||
| Let's call "folded-JSON" the JSON embedded in the I-D: it fits the 72 | Let's call "folded-JSON" the JSON embedded in the I-D: it fits the 72 | |||
| chars width and it is acceptable for it to be invalid JSON. | chars width and it is acceptable for it to be invalid JSON. | |||
| We then define "unfolded-JSON" a valid JSON fragment having the same | We then define "unfolded-JSON" a valid JSON fragment having the same | |||
| contents of the "folded-JSON " without folding, i.e. limits on the | contents of the "folded-JSON " without folding, i.e. limits on the | |||
| text width. The folding/unfolding operation may be done according to | text width. The folding/unfolding operation may be done according to | |||
| skipping to change at page 51, line 50 ¶ | skipping to change at page 53, line 18 ¶ | |||
| <-- fold_it <-- author edits | <-- fold_it <-- author edits | |||
| <=72-chars? must may may | <=72-chars? must may may | |||
| valid JSON? may must must | valid JSON? may must must | |||
| JSON-encoding | JSON-encoding | |||
| of YANG data? may may must | of YANG data? may may must | |||
| Our validation toolchain has been designed to take a JSON in any of | The validation toolchain has been designed to take a JSON in any of | |||
| the three formats and validate it automatically against a set of | the three formats and validate it automatically against a set of | |||
| relevant YANG modules using available open-source tools. It can be | relevant YANG modules using available open-source tools. | |||
| found at: https://github.com/GianmarcoBruno/json-yang/ | ||||
| A.2. Comments in JSON fragments | The tool used to validate the JSON examples in this document can be | |||
| found at: https://github.com/ietf-ccamp-wg/json-yang/tree/2.2 | ||||
| We found useful to introduce two kinds of comments, both defined as | A.3. Comments in JSON fragments | |||
| key-value pairs where the key starts with "//": | ||||
| o free-form descriptive comments, e.g."// COMMENT" : "refine this" | We found it useful to introduce two kinds of comments, both defined | |||
| as key-value pairs where the key starts with "//": | ||||
| * free-form descriptive comments, e.g."// comment" : "refine this" | ||||
| to describe properties of JSON fragments. | to describe properties of JSON fragments. | |||
| o machine-usable directives e.g. "// *REFERENCES__DRAFTS*" : { | * machine-usable directives e.g. "// header" : {"reference-drafts" : | |||
| "ietf-routing-types@2017-12-04": "rfc8294",} which can be used to | { "ietf-routing-types@2017-12-04": "rfc8294",}} which can be used | |||
| automatically download from the network the relevant I-Ds or RFCs | to automatically download from the network the relevant I-Ds or | |||
| and extract from them the YANG models of interest. This is | RFCs and extract from them the YANG models of interest. This is | |||
| particularly useful to keep consistency when the drafting work is | particularly useful to keep consistency when the drafting work is | |||
| rapidly evolving. | rapidly evolving. | |||
| A.3. Validation of JSON fragments: DSDL-based approach | A.4. Validation of JSON fragments: DSDL-based approach | |||
| The idea is to generate a JSON driver file (JTOX) from YANG, then use | The idea is to generate a JSON driver file (JTOX) from YANG, then use | |||
| it to translate JSON to XML and validate it against the DSDL schemas, | it to translate JSON to XML and validate it against the DSDL schemas, | |||
| as shown in Figure 8. | as shown in Figure 8. | |||
| Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson | Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson | |||
| (2) | (2) | |||
| YANG-module ---> DSDL-schemas (RNG,SCH,DSRL) | YANG-module ---> DSDL-schemas (RNG,SCH,DSRL) | |||
| | | | | | | |||
| | (1) | | | (1) | | |||
| | | | | | | |||
| Config/state JTOX-file | (4) | Config/state JTOX-file | (4) | |||
| \ | | | \ | | | |||
| \ | | | \ | | | |||
| \ V V | \ V V | |||
| JSON-file------------> XML-file ----------------> Output | JSON-file------------> XML-file ----------------> Output | |||
| (3) | (3) | |||
| Figure 8: DSDL-based approach for JSON code validation | Figure 8: DSDL-based approach for JSON code validation | |||
| In order to allow the use of comments following the convention | In order to allow the use of comments following the convention | |||
| defined in Section 3, without impacting the validation process, these | defined in Section 3, without impacting the validation process, these | |||
| comments will be automatically removed from the JSON-file that will | comments will be automatically removed from the JSON-file that will | |||
| be validate. | be validated. | |||
| A.4. Validation of JSON fragments: why not using an XSD-based approach | A.5. Validation of JSON fragments: why not using an XSD-based approach | |||
| This approach has been analyzed and discarded because no longer | This approach has been analyzed and discarded because no longer | |||
| supported by pyang. | supported by pyang. | |||
| The idea is to convert YANG to XSD, JSON to XML and validate it | The idea is to convert YANG to XSD, JSON to XML and validate it | |||
| against the XSD, as shown in Figure 9: | against the XSD, as shown in Figure 9: | |||
| (1) | (1) | |||
| YANG-module ---> XSD-schema - \ (3) | YANG-module ---> XSD-schema - \ (3) | |||
| +--> Validation | +--> Validation | |||
| JSON-file------> XML-file ----/ | JSON-file------> XML-file ----/ | |||
| (2) | (2) | |||
| Figure 9: XSD-based approach for JSON code validation | Figure 9: XSD-based approach for JSON code validation | |||
| The pyang support for the XSD output format was deprecated in 1.5 and | The pyang support for the XSD output format was deprecated in 1.5 and | |||
| removed in 1.7.1. However pyang 1.7.1 is necessary to work with YANG | removed in 1.7.1. However, pyang 1.7.1 is necessary to work with | |||
| 1.1 so the process shown in Figure 9 will stop just at step (1). | YANG 1.1 so the process shown in Figure 9 will stop just at step (1). | |||
| Appendix B. Detailed JSON Examples | Appendix B. Detailed JSON Examples | |||
| The JSON code examples provided in this appendix have been validated | The JSON code examples provided in this appendix have been validated | |||
| using the tools in Appendix A and folded using the tool in [RFC8792]. | using the tools in Appendix A and folded using the tool in [RFC8792]. | |||
| B.1. JSON Examples for Topology Abstractions | B.1. JSON Examples for Topology Abstractions | |||
| B.1.1. JSON Code: mpi1-otn-topology.json | B.1.1. JSON Code: mpi1-otn-topology.json | |||
| This is the JSON code reporting the OTN Topology @ MPI1: | This is the JSON code reporting the OTN Topology @ MPI1: | |||
| ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== | =============== NOTE: '\\' line wrapping per RFC 8792 =============== | |||
| { | { | |||
| "// __LAST_UPDATE__": "October 21, 2019", | "// header": { | |||
| "// __TITLE__": "ODU Black Topology @ MPI1", | "last-update": "March 15, 2022", | |||
| "// __REFERENCE_DRAFTS__": { | "title": "ODU Black Topology @ MPI1", | |||
| "ietf-routing-types@2017-12-04": "rfc8294", | "missing-attributes": true, | |||
| "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", | "reference-drafts": { | |||
| "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\ | "ietf-routing-types@2017-12-04": "rfc8294", | |||
| \2", | "ietf-te-types@2020-06-10": "rfc8776", | |||
| "ietf-network@2018-02-26": "rfc8345", | "ietf-layer1-types@2021-02-19": "draft-ietf-ccamp-layer1-types\ | |||
| "ietf-network-topology@2018-02-26": "rfc8345", | \-10", | |||
| "ietf-te-topology@2019-02-07": "draft-ietf-teas-yang-te-topo-22", | "ietf-network@2018-02-26": "rfc8345", | |||
| "ietf-otn-topology@2019-07-07": "draft-ietf-ccamp-otn-topo-yang-\ | "ietf-network-topology@2018-02-26": "rfc8345", | |||
| \08" | "ietf-te-topology@2020-08-06": "rfc8795", | |||
| "ietf-otn-topology@2021-07-08": "draft-ietf-ccamp-otn-topo-yan\ | ||||
| \g-13" | ||||
| } | ||||
| }, | }, | |||
| "// __MISSING_ATTRIBUTES__": true, | ||||
| "ietf-network:networks": { | "ietf-network:networks": { | |||
| "network": [ | "network": [ | |||
| { | { | |||
| "network-id": "providerId/201/clientId/300/topologyId/otn-bl\ | "network-id": "providerId/201/clientId/300/topologyId/otn-bl\ | |||
| \ack-topology", | \ack-topology", | |||
| "network-types": { | "network-types": { | |||
| "ietf-te-topology:te-topology": { | "ietf-te-topology:te-topology": { | |||
| "ietf-otn-topology:otn-topology": {} | "ietf-otn-topology:otn-topology": {} | |||
| } | } | |||
| }, | }, | |||
| "ietf-te-topology:te-topology-identifier": { | "ietf-te-topology:te-topology-identifier": { | |||
| "provider-id": 201, | "provider-id": 201, | |||
| "client-id": 300, | "client-id": 300, | |||
| "topology-id": "otn-black-topology" | "topology-id": "otn-black-topology" | |||
| }, | }, | |||
| "// __COMMENT__ ietf-te-topology:te": "presence container re\ | "// comment ietf-te-topology:te": "presence container requir\ | |||
| \quires: provider-id, client-id and te-topology-id", | \es: provider-id, client-id and te-topology-id", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "OTN Black Topology @ MPI1" | "name": "OTN Black Topology @ MPI1" | |||
| }, | }, | |||
| "ietf-network:node": [ | "ietf-network:node": [ | |||
| { | { | |||
| "// __NODE__:__DESCRIPTION__": { | "// node description": { | |||
| "name": "AN1", | "name": "AN1", | |||
| "identifier": "10.0.0.1", | "identifier": "192.0.2.1", | |||
| "type": "Abstract Node", | "type": "Abstract Node", | |||
| "physical node(s)": "The whole network domain 1" | "physical node(s)": "The whole network domain 1" | |||
| }, | }, | |||
| "node-id": "10.0.0.1", | "node-id": "192.0.2.1", | |||
| "ietf-te-topology:te-node-id": "10.0.0.1", | "ietf-te-topology:te-node-id": "192.0.2.1", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-node-attributes": { | "te-node-attributes": { | |||
| "name": "AN11", | "name": "AN11", | |||
| "is-abstract": "", | "is-abstract": [ | |||
| null | ||||
| ], | ||||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "tunnel-termination-point": [ | "tunnel-termination-point": [ | |||
| { | { | |||
| "// __COMMENT__ tunnel-tp-id": "AN1-1 TTP-ID (1 ->\ | "// comment tunnel-tp-id": "AN1-1 TTP-ID (1 -> 0x0\ | |||
| \ 0x01 -> 'AQ==')", | \1 -> 'AQ==' in base64)", | |||
| "tunnel-tp-id": "AQ==", | "tunnel-tp-id": "AQ==", | |||
| "name": "AN1-1 OTN TTP", | "name": "AN1-1 OTN TTP", | |||
| "// __COMMENT__ encoding and switching-capability"\ | "// comment encoding and switching-capability": "O\ | |||
| \: "OTN (ODU)", | \TN (ODU)", | |||
| "switching-capability": "ietf-te-types:switching-o\ | "switching-capability": "ietf-te-types:switching-o\ | |||
| \tn", | \tn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "// __COMMENT__ inter-layer-lock-id": "{ AN1-1 ILL\ | "// comment inter-layer-lock-id": "{ AN1-1 ILL-ID \ | |||
| \-ID (1) }", | \(1) }", | |||
| "inter-layer-lock-id": [ | "inter-layer-lock-id": [ | |||
| 1 | 1 | |||
| ], | ], | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up" | "oper-status": "up" | |||
| }, | }, | |||
| { | { | |||
| "// __COMMENT__ tunnel-tp-id": "AN1-2 TTP-ID (2 ->\ | "// comment tunnel-tp-id": "AN1-2 TTP-ID (2 -> 0x0\ | |||
| \ 0x02 -> 'Ag==')", | \2 -> 'Ag==' in base64)", | |||
| "tunnel-tp-id": "Ag==", | "tunnel-tp-id": "Ag==", | |||
| "name": "AN1-2 OTN TTP", | "name": "AN1-2 OTN TTP", | |||
| "// __COMMENT__ encoding and switching-capability"\ | "// comment encoding and switching-capability": "O\ | |||
| \: "OTN (ODU)", | \TN (ODU)", | |||
| "switching-capability": "ietf-te-types:switching-o\ | "switching-capability": "ietf-te-types:switching-o\ | |||
| \tn", | \tn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "// __COMMENT__ inter-layer-lock-id": "{ AN1-2 ILL\ | "// comment inter-layer-lock-id": "{ AN1-2 ILL-ID \ | |||
| \-ID (2) }", | \(2) }", | |||
| "inter-layer-lock-id": [ | "inter-layer-lock-id": [ | |||
| 2 | 2 | |||
| ], | ], | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up" | "oper-status": "up" | |||
| }, | }, | |||
| { | { | |||
| "// __COMMENT__ tunnel-tp-id": "AN1-3 TTP-ID (3 ->\ | "// comment tunnel-tp-id": "AN1-3 TTP-ID (3 -> 0x0\ | |||
| \ 0x03 -> 'Awo=')", | \3 -> 'Awo=' in base64)", | |||
| "tunnel-tp-id": "Awo=", | "tunnel-tp-id": "Awo=", | |||
| "name": "AN1-3 OTN TTP", | "name": "AN1-3 OTN TTP", | |||
| "// __COMMENT__ encoding and switching-capability"\ | "// comment encoding and switching-capability": "O\ | |||
| \: "OTN (ODU)", | \TN (ODU)", | |||
| "switching-capability": "ietf-te-types:switching-o\ | "switching-capability": "ietf-te-types:switching-o\ | |||
| \tn", | \tn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "// __COMMENT__ inter-layer-lock-id": "{ AN1-3 ILL\ | "// comment inter-layer-lock-id": "{ AN1-3 ILL-ID \ | |||
| \-ID (3) }", | \(3) }", | |||
| "inter-layer-lock-id": [ | "inter-layer-lock-id": [ | |||
| 3 | 3 | |||
| ], | ], | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up" | "oper-status": "up" | |||
| }, | }, | |||
| { | { | |||
| "// __COMMENT__ tunnel-tp-id": "AN1-8 TTP-ID (8 ->\ | "// comment tunnel-tp-id": "AN1-8 TTP-ID (8 -> 0x0\ | |||
| \ 0x08 -> 'CA==')", | \8 -> 'CA==' in base64)", | |||
| "tunnel-tp-id": "CA==", | "tunnel-tp-id": "CA==", | |||
| "name": "AN1-8 OTN TTP", | "name": "AN1-8 OTN TTP", | |||
| "// __COMMENT__ encoding and switching-capability"\ | "// comment encoding and switching-capability": "O\ | |||
| \: "OTN (ODU)", | \TN (ODU)", | |||
| "switching-capability": "ietf-te-types:switching-o\ | "switching-capability": "ietf-te-types:switching-o\ | |||
| \tn", | \tn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "// __COMMENT__ inter-layer-lock-id": "{ AN1-8 ILL\ | "// comment inter-layer-lock-id": "{ AN1-8 ILL-ID \ | |||
| \-ID (1) }", | \(1) }", | |||
| "inter-layer-lock-id": [ | "inter-layer-lock-id": [ | |||
| 8 | 8 | |||
| ], | ], | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up" | "oper-status": "up" | |||
| } | } | |||
| ] | ] | |||
| }, | }, | |||
| "ietf-network-topology:termination-point": [ | "ietf-network-topology:termination-point": [ | |||
| { | { | |||
| "// __DESCRIPTION__:__LTP__": { | "// ltp description": { | |||
| "name": "AN1-1 LTP", | "name": "AN1-1 LTP", | |||
| "link type(s)": "Multi-function (OTU2, STM-64 and \ | "link type(s)": "Multi-function (OTU2, STM-64 and \ | |||
| \10GE)", | \10GE)", | |||
| "physical node": "S3", | "physical node": "S3", | |||
| "unnumberd/ifIndex": 1, | "unnumberd/ifIndex": 1, | |||
| "port type": "tributary port", | "port type": "tributary port", | |||
| "connected to": "R1" | "connected to": "R1" | |||
| }, | }, | |||
| "tp-id": "1", | "tp-id": "1", | |||
| "ietf-te-topology:te-tp-id": 1, | "ietf-te-topology:te-tp-id": 1, | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "AN1-1 LTP", | "name": "AN1-1 LTP", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabil\ | "// comment encoding and switching-capability"\ | |||
| \ity": "OTN (ODU)", | \: "OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switchi\ | "switching-capability": "ietf-te-types:switchi\ | |||
| \ng-otn", | \ng-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-laye\ | "ietf-otn-topology:otn": { | |||
| \r1-types:ODU2" | "odu-type": "ietf-layer1-types:ODU2" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __NOT-PRESENT__ inter-domain-plug-id": "Use of\ | "// not-present inter-domain-plug-id": "Use of plu\ | |||
| \ plug-id for access Link is outside the scope of this document", | \g-id for access Link is outside the scope of this document", | |||
| "// __COMMENT__ inter-layer-lock-id": "{ AN1-1 ILL\ | "// comment inter-layer-lock-id": "{ AN1-1 ILL-ID \ | |||
| \-ID (1) }", | \(1) }", | |||
| "inter-layer-lock-id": [ | "inter-layer-lock-id": [ | |||
| 1 | 1 | |||
| ], | ], | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "ietf-otn-topology:client-svc": { | "ietf-otn-topology:client-svc": { | |||
| "client-facing": true, | "client-facing": true, | |||
| "supported-client-signal": [ | "supported-client-signal": [ | |||
| "ietf-layer1-types:STM-64" | "ietf-layer1-types:STM-64" | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LTP__": { | "// ltp description": { | |||
| "name": "AN1-2 LTP", | "name": "AN1-2 LTP", | |||
| "link type(s)": "Multi-function (OTU2 and STM-64)", | "link type(s)": "Multi-function (OTU2 and STM-64)"\ | |||
| \, | ||||
| "physical node": "S6", | "physical node": "S6", | |||
| "unnumberd/ifIndex": 2, | "unnumberd/ifIndex": 2, | |||
| "port type": "tributary port", | "port type": "tributary port", | |||
| "connected to": "R3" | "connected to": "R3" | |||
| }, | }, | |||
| "tp-id": "2", | "tp-id": "2", | |||
| "ietf-te-topology:te-tp-id": 2, | "ietf-te-topology:te-tp-id": 2, | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "AN1-2 LTP", | "name": "AN1-2 LTP", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabil\ | "// comment encoding and switching-capability"\ | |||
| \ity": "OTN (ODU)", | \: "OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switchi\ | "switching-capability": "ietf-te-types:switchi\ | |||
| \ng-otn", | \ng-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-laye\ | "ietf-otn-topology:otn": { | |||
| \r1-types:ODU2" | "odu-type": "ietf-layer1-types:ODU2" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __NOT-PRESENT__ inter-domain-plug-id": "Use of\ | "// not-present inter-domain-plug-id": "Use of plu\ | |||
| \ plug-id for access Link is outside the scope of this document", | \g-id for access Link is outside the scope of this document", | |||
| "// __COMMENT__ inter-layer-lock-id": "{ AN1-2 ILL\ | "// comment inter-layer-lock-id": "{ AN1-2 ILL-ID \ | |||
| \-ID (2) }", | \(2) }", | |||
| "inter-layer-lock-id": [ | "inter-layer-lock-id": [ | |||
| 2 | 2 | |||
| ], | ], | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "ietf-otn-topology:client-svc": { | "ietf-otn-topology:client-svc": { | |||
| "client-facing": true, | "client-facing": true, | |||
| "supported-client-signal": [ | "supported-client-signal": [ | |||
| "ietf-layer1-types:STM-64" | "ietf-layer1-types:STM-64" | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LTP__": { | "// ltp description": { | |||
| "name": "AN1-3 LTP", | "name": "AN1-3 LTP", | |||
| "link type(s)": "STM-64", | "link type(s)": "STM-64", | |||
| "physical node": "S6", | "physical node": "S6", | |||
| "unnumberd/ifIndex": 3, | "unnumberd/ifIndex": 3, | |||
| "port type": "tributary port", | "port type": "tributary port", | |||
| "connected to": "R4" | "connected to": "R4" | |||
| }, | }, | |||
| "tp-id": "3", | "tp-id": "3", | |||
| "ietf-te-topology:te-tp-id": 3, | "ietf-te-topology:te-tp-id": 3, | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "AN1-3 LTP", | "name": "AN1-3 LTP", | |||
| "// __NOT-PRESENT__ interface-switching-capability\ | "// not-present interface-switching-capability": "\ | |||
| \": "STM-64 Access Link only (no ODU switching)", | \STM-64 Access Link only (no ODU switching)", | |||
| "// __NOT-PRESENT__ inter-domain-plug-id": "Use of\ | "// not-present inter-domain-plug-id": "Use of plu\ | |||
| \ plug-id for access Link is outside the scope of this document", | \g-id for access Link is outside the scope of this document", | |||
| "// __COMMENT__ inter-layer-lock-id": "{ AN1-3 ILL\ | "// comment inter-layer-lock-id": "{ AN1-3 ILL-ID \ | |||
| \-ID (3) }", | \(3) }", | |||
| "inter-layer-lock-id": [ | "inter-layer-lock-id": [ | |||
| 3 | 3 | |||
| ], | ], | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "ietf-otn-topology:client-svc": { | "ietf-otn-topology:client-svc": { | |||
| "client-facing": true, | "client-facing": true, | |||
| "supported-client-signal": [ | "supported-client-signal": [ | |||
| "ietf-layer1-types:STM-64" | "ietf-layer1-types:STM-64" | |||
| ] | ] | |||
| skipping to change at page 59, line 4 ¶ | skipping to change at page 60, line 32 ¶ | |||
| 3 | 3 | |||
| ], | ], | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "ietf-otn-topology:client-svc": { | "ietf-otn-topology:client-svc": { | |||
| "client-facing": true, | "client-facing": true, | |||
| "supported-client-signal": [ | "supported-client-signal": [ | |||
| "ietf-layer1-types:STM-64" | "ietf-layer1-types:STM-64" | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LTP__": { | "// ltp description": { | |||
| "name": "AN1-4 LTP", | "name": "AN1-4 LTP", | |||
| "link type(s)": "OTU4", | "link type(s)": "OTU4", | |||
| "physical node": "S7", | "physical node": "S7", | |||
| "unnumberd/ifIndex": 3, | "unnumberd/ifIndex": 3, | |||
| "port type": "inter-domain port", | "port type": "inter-domain port", | |||
| "connected to": "S11" | "connected to": "S11" | |||
| }, | }, | |||
| "tp-id": "4", | "tp-id": "4", | |||
| "ietf-te-topology:te-tp-id": 4, | "ietf-te-topology:te-tp-id": 4, | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "AN1-4 LTP", | "name": "AN1-4 LTP", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabil\ | "// comment encoding and switching-capability"\ | |||
| \ity": "OTN (ODU)", | \: "OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switchi\ | "switching-capability": "ietf-te-types:switchi\ | |||
| \ng-otn", | \ng-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-laye\ | "ietf-otn-topology:otn": { | |||
| \r1-types:ODU4" | "odu-type": "ietf-layer1-types:ODU4" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __COMMENT__ inter-domain-plug-id": "S7-S11 Plu\ | "// comment inter-domain-plug-id": "S7-S11 Plug-id\ | |||
| \g-id (0x000711 -> AAcR)", | \ (0x000711 -> AAcR)", | |||
| "inter-domain-plug-id": "AAcR", | "inter-domain-plug-id": "AAcR", | |||
| "// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ | "// not-present inter-layer-lock-id": "ODU Server \ | |||
| \ver Layer topology not exposed", | \Layer topology not exposed", | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ | "// not-present ietf-otn-topology:client-svc": "OT\ | |||
| \ "OTN inter-domain link" | \N inter-domain link" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LTP__": { | "// ltp description": { | |||
| "name": "AN1-5 LTP", | "name": "AN1-5 LTP", | |||
| "link type(s)": "OTU4", | "link type(s)": "OTU4", | |||
| "physical node": "S8", | "physical node": "S8", | |||
| "unnumberd/ifIndex": 4, | "unnumberd/ifIndex": 4, | |||
| "port type": "inter-domain port", | "port type": "inter-domain port", | |||
| "connected to": "S12" | "connected to": "S12" | |||
| }, | }, | |||
| "tp-id": "5", | "tp-id": "5", | |||
| "ietf-te-topology:te-tp-id": 5, | "ietf-te-topology:te-tp-id": 5, | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "AN1-5 LTP", | "name": "AN1-5 LTP", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabil\ | "// comment encoding and switching-capability"\ | |||
| \ity": "OTN (ODU)", | \: "OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switchi\ | "switching-capability": "ietf-te-types:switchi\ | |||
| \ng-otn", | \ng-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-laye\ | "ietf-otn-topology:otn": { | |||
| \r1-types:ODU4" | "odu-type": "ietf-layer1-types:ODU4" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __COMMENT__ inter-domain-plug-id": "S8-S12 Plu\ | "// comment inter-domain-plug-id": "S8-S12 Plug-id\ | |||
| \g-id (0x000812 -> AAgS)", | \ (0x000812 -> AAgS)", | |||
| "inter-domain-plug-id": "AAgS", | "inter-domain-plug-id": "AAgS", | |||
| "// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ | "// not-present inter-layer-lock-id": "ODU Server \ | |||
| \ver Layer topology not exposed", | \Layer topology not exposed", | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ | "// not-present ietf-otn-topology:client-svc": "OT\ | |||
| \ "OTN inter-domain link" | \N inter-domain link" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LTP__": { | "// ltp description": { | |||
| "name": "AN1-6 LTP", | "name": "AN1-6 LTP", | |||
| "link type(s)": "OTU4", | "link type(s)": "OTU4", | |||
| "physical node": "S8", | "physical node": "S8", | |||
| "unnumberd/ifIndex": 5, | "unnumberd/ifIndex": 5, | |||
| "port type": "inter-domain port", | "port type": "inter-domain port", | |||
| "connected to": "S32" | "connected to": "S32" | |||
| }, | }, | |||
| "tp-id": "6", | "tp-id": "6", | |||
| "ietf-te-topology:te-tp-id": 6, | "ietf-te-topology:te-tp-id": 6, | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "AN1-6 LTP", | "name": "AN1-6 LTP", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabil\ | "// comment encoding and switching-capability"\ | |||
| \ity": "OTN (ODU)", | \: "OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switchi\ | "switching-capability": "ietf-te-types:switchi\ | |||
| \ng-otn", | \ng-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-laye\ | "ietf-otn-topology:otn": { | |||
| \r1-types:ODU4" | "odu-type": "ietf-layer1-types:ODU4" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __COMMENT__ inter-domain-plug-id": "S8-S32 Plu\ | "// comment inter-domain-plug-id": "S8-S32 Plug-id\ | |||
| \g-id (0x000832 -> AAgy)", | \ (0x000832 -> AAgy)", | |||
| "inter-domain-plug-id": "AAgy", | "inter-domain-plug-id": "AAgy", | |||
| "// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ | "// not-present inter-layer-lock-id": "ODU Server \ | |||
| \ver Layer topology not exposed", | \Layer topology not exposed", | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ | "// not-present ietf-otn-topology:client-svc": "OT\ | |||
| \ "OTN inter-domain link" | \N inter-domain link" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LTP__": { | "// ltp description": { | |||
| "name": "AN1-7 LTP", | "name": "AN1-7 LTP", | |||
| "link type(s)": "OTU4", | "link type(s)": "OTU4", | |||
| "physical node": "S2", | "physical node": "S2", | |||
| "unnumberd/ifIndex": 3, | "unnumberd/ifIndex": 3, | |||
| "port type": "inter-domain port", | "port type": "inter-domain port", | |||
| "connected to": "S31" | "connected to": "S31" | |||
| }, | }, | |||
| "tp-id": "7", | "tp-id": "7", | |||
| "ietf-te-topology:te-tp-id": 7, | "ietf-te-topology:te-tp-id": 7, | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "AN1-7 LTP", | "name": "AN1-7 LTP", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabil\ | "// comment encoding and switching-capability"\ | |||
| \: "OTN (ODU)", | ||||
| \ity": "OTN (ODU)", | ||||
| "switching-capability": "ietf-te-types:switchi\ | "switching-capability": "ietf-te-types:switchi\ | |||
| \ng-otn", | \ng-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-laye\ | "ietf-otn-topology:otn": { | |||
| \r1-types:ODU4" | "odu-type": "ietf-layer1-types:ODU4" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __COMMENT__ inter-domain-plug-id": "S2-S31 Plu\ | "// comment inter-domain-plug-id": "S2-S31 Plug-id\ | |||
| \g-id (0x000231 -> AAIx)", | ||||
| \ (0x000231 -> AAIx)", | ||||
| "inter-domain-plug-id": "AAIx", | "inter-domain-plug-id": "AAIx", | |||
| "// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ | "// not-present inter-layer-lock-id": "ODU Server \ | |||
| \ver Layer topology not exposed", | \Layer topology not exposed", | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ | "// not-present ietf-otn-topology:client-svc": "OT\ | |||
| \ "OTN inter-domain link" | \N inter-domain link" | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "ietf-network-topology:link": [ | "ietf-network-topology:link": [ | |||
| { | { | |||
| "// __DESCRIPTION__:__LINK__": { | "// link description": { | |||
| "name": "Access Link from AN1-1", | "name": "Access Link from AN1-1", | |||
| "type": "Multi-function access link (OTU2, STM-64 and \ | "type": "Multi-function access link (OTU2, STM-64 and \ | |||
| \10GE)", | \10GE)", | |||
| "physical link": "Link from S3-1 to R1" | "physical link": "Link from S3-1 to R1" | |||
| }, | }, | |||
| "link-id": "teNodeId/10.0.0.1/teLinkId/1", | "link-id": "teNodeId/192.0.2.1/teLinkId/1", | |||
| "source": { | "source": { | |||
| "source-node": "10.0.0.1", | "source-node": "192.0.2.1", | |||
| "source-tp": 1 | "source-tp": "1" | |||
| }, | }, | |||
| "// __NOT-PRESENT__ destination": "access link", | "// not-present destination": "access link", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-link-attributes": { | "te-link-attributes": { | |||
| "name": "Access Link from AN1-1", | "name": "Access Link from AN1-1", | |||
| "// __NOT-PRESENT__ external-domain": "The plug-id i\ | "// not-present external-domain": "The plug-id is us\ | |||
| \s used instead of this container", | \ed instead of this container", | |||
| "// __NOT-PRESENT__ is-abstract": "The access link i\ | "// not-present is-abstract": "The access link is no\ | |||
| \s not abstract", | \t abstract", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabilit\ | "// comment encoding and switching-capability": \ | |||
| \y": "OTN (ODU)", | \"OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switching\ | "switching-capability": "ietf-te-types:switching\ | |||
| \-otn", | \-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-layer1\ | "ietf-otn-topology:otn": { | |||
| \-types:ODU2" | "odu-type": "ietf-layer1-types:ODU4" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __COMMENT__ label-restrictions": "Outside the sc\ | "// comment label-restrictions": "Outside the scope \ | |||
| \ope of this JSON example", | \of this JSON example", | |||
| "max-link-bandwidth": { | "max-link-bandwidth": { | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odulist": [ | "ietf-otn-topology:odulist": [ | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU2", | "odu-type": "ietf-layer1-types:ODU2", | |||
| "number": 1 | "number": 1 | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| }, | }, | |||
| skipping to change at page 64, line 11 ¶ | skipping to change at page 65, line 45 ¶ | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odulist": [ | "ietf-otn-topology:odulist": [ | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU2", | "odu-type": "ietf-layer1-types:ODU2", | |||
| "number": 1 | "number": 1 | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ], | ], | |||
| "// __NOT-PRESENT__ ietf-otn-topology:tsg": "Access \ | "// not-present ietf-otn-topology:tsg": "Access Link\ | |||
| \Link with no HO-ODU termination and LO-ODU switching", | \ with no HO-ODU termination and LO-ODU switching", | |||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ is-transitional": "It is not a tra\ | "// not-present is-transitional": "It is not a transit\ | |||
| \nsitional link" | \ional link" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LINK__": { | "// link description": { | |||
| "name": "Access Link from AN1-2", | "name": "Access Link from AN1-2", | |||
| "type": "Multi-function access link (OTU2 and STM-64)", | "type": "Multi-function access link (OTU2 and STM-64)"\ | |||
| \, | ||||
| "physical link": "Link from S6-2 to R3" | "physical link": "Link from S6-2 to R3" | |||
| }, | }, | |||
| "link-id": "teNodeId/10.0.0.1/teLinkId/2", | "link-id": "teNodeId/192.0.2.1/teLinkId/2", | |||
| "source": { | "source": { | |||
| "source-node": "10.0.0.1", | "source-node": "192.0.2.1", | |||
| "source-tp": 2 | "source-tp": "2" | |||
| }, | }, | |||
| "// __NOT-PRESENT__ destination": "access link", | "// not-present destination": "access link", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-link-attributes": { | "te-link-attributes": { | |||
| "name": "Access Link from AN1-2", | "name": "Access Link from AN1-2", | |||
| "// __NOT-PRESENT__ external-domain": "The plug-id i\ | "// not-present external-domain": "The plug-id is us\ | |||
| \s used instead of this container", | \ed instead of this container", | |||
| "// __NOT-PRESENT__ is-abstract": "The access link i\ | "// not-present is-abstract": "The access link is no\ | |||
| \s not abstract", | \t abstract", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabilit\ | "// comment encoding and switching-capability": \ | |||
| \y": "OTN (ODU)", | \"OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switching\ | "switching-capability": "ietf-te-types:switching\ | |||
| \-otn", | \-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-layer1\ | "ietf-otn-topology:otn": { | |||
| \-types:ODU2" | "odu-type": "ietf-layer1-types:ODU2" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __COMMENT__ label-restrictions": "Outside the sc\ | "// comment label-restrictions": "Outside the scope \ | |||
| \ope of this JSON example", | \of this JSON example", | |||
| "max-link-bandwidth": { | "max-link-bandwidth": { | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odulist": [ | "ietf-otn-topology:odulist": [ | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU2", | "odu-type": "ietf-layer1-types:ODU2", | |||
| "number": 1 | "number": 1 | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| }, | }, | |||
| "max-resv-link-bandwidth": { | "max-resv-link-bandwidth": { | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odulist": [ | "ietf-otn-topology:odulist": [ | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU2", | "odu-type": "ietf-layer1-types:ODU2", | |||
| "number": 1 | "number": 1 | |||
| skipping to change at page 65, line 44 ¶ | skipping to change at page 67, line 32 ¶ | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odulist": [ | "ietf-otn-topology:odulist": [ | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU2", | "odu-type": "ietf-layer1-types:ODU2", | |||
| "number": 1 | "number": 1 | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ], | ], | |||
| "// __NOT-PRESENT__ ietf-otn-topology:tsg": "Access \ | "// not-present ietf-otn-topology:tsg": "Access Link\ | |||
| \Link with no HO-ODU termination and LO-ODU switching", | \ with no HO-ODU termination and LO-ODU switching", | |||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ is-transitional": "It is not a tra\ | "// not-present is-transitional": "It is not a transit\ | |||
| \nsitional link" | \ional link" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LINK__": { | "// link description": { | |||
| "name": "Access Link from AN1-3", | "name": "Access Link from AN1-3", | |||
| "type": "STM-64 Access link", | "type": "STM-64 Access link", | |||
| "physical link": "Link from S6-3 to R4" | "physical link": "Link from S6-3 to R4" | |||
| }, | }, | |||
| "link-id": "teNodeId/10.0.0.1/teLinkId/3", | "link-id": "teNodeId/192.0.2.1/teLinkId/3", | |||
| "source": { | "source": { | |||
| "source-node": "10.0.0.1", | "source-node": "192.0.2.1", | |||
| "source-tp": 3 | "source-tp": "3" | |||
| }, | }, | |||
| "// __NOT-PRESENT__ destination": "access link", | "// not-present destination": "access link", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-link-attributes": { | "te-link-attributes": { | |||
| "name": "Access Link from AN1-3", | "name": "Access Link from AN1-3", | |||
| "// __NOT-PRESENT__ external-domain": "The plug-id i\ | "// not-present external-domain": "The plug-id is us\ | |||
| \s used instead of this container", | \ed instead of this container", | |||
| "// __NOT-PRESENT__ is-abstract": "The access link i\ | "// not-present is-abstract": "The access link is no\ | |||
| \s not abstract", | \t abstract", | |||
| "// __NOT-PRESENT__ interface-switching-capability":\ | "// not-present interface-switching-capability": "ST\ | |||
| \ "STM-64 Access Link only (no ODU switching)", | \M-64 Access Link only (no ODU switching)", | |||
| "// __NOT-PRESENT__ max-link-bandwidth": "STM-64 Acc\ | "// not-present max-link-bandwidth": "STM-64 Access \ | |||
| \ess Link only (no ODU switching)", | \Link only (no ODU switching)", | |||
| "// __NOT-PRESENT__ max-resv-link-bandwidth": "STM-6\ | "// not-present max-resv-link-bandwidth": "STM-64 Ac\ | |||
| \4 Access Link only (no ODU switching)", | \cess Link only (no ODU switching)", | |||
| "// __NOT-PRESENT__ unreserved-bandwidth": "STM-64 A\ | "// not-present unreserved-bandwidth": "STM-64 Acces\ | |||
| \ccess Link only (no ODU switching)", | \s Link only (no ODU switching)", | |||
| "// __NOT-PRESENT__ ietf-otn-topology:tsg": "STM-64 \ | "// not-present ietf-otn-topology:tsg": "STM-64 Acce\ | |||
| \Access Link only (no HO-ODU termination and LO-ODU switching)", | \ss Link only (no HO-ODU termination and LO-ODU switching)", | |||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ is-transitional": "It is not a tra\ | "// not-present is-transitional": "It is not a transit\ | |||
| \nsitional link" | \ional link" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LINK__": { | "// link description": { | |||
| "name": "Inter-domain Link from AN1-4", | "name": "Inter-domain Link from AN1-4", | |||
| "type": "OTU4 inter-domain link", | "type": "OTU4 inter-domain link", | |||
| "physical link": "Link from S7-3 to S11" | "physical link": "Link from S7-3 to S11" | |||
| }, | }, | |||
| "link-id": "teNodeId/10.0.0.1/teLinkId/4", | "link-id": "teNodeId/192.0.2.1/teLinkId/4", | |||
| "source": { | "source": { | |||
| "source-node": "10.0.0.1", | "source-node": "192.0.2.1", | |||
| "source-tp": 4 | "source-tp": "4" | |||
| }, | }, | |||
| "// __NOT-PRESENT__ destination": "inter-domain link", | "// not-present destination": "inter-domain link", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-link-attributes": { | "te-link-attributes": { | |||
| "name": "Inter-domain Link from AN1-4", | "name": "Inter-domain Link from AN1-4", | |||
| "// __NOT-PRESENT__ external-domain": "The plug-id i\ | "// not-present external-domain": "The plug-id is us\ | |||
| \s used instead of this container", | \ed instead of this container", | |||
| "// __NOT-PRESENT__ is-abstract": "The access link i\ | "// not-present is-abstract": "The access link is no\ | |||
| \s not abstract", | \t abstract", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabilit\ | "// comment encoding and switching-capability": \ | |||
| \y": "OTN (ODU)", | \"OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switching\ | "switching-capability": "ietf-te-types:switching\ | |||
| \-otn", | \-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-layer1\ | "ietf-otn-topology:otn": { | |||
| \-types:ODU4" | "odu-type": "ietf-layer1-types:ODU2" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __COMMENT__ label-restrictions": "Outside the sc\ | "// comment label-restrictions": "Outside the scope \ | |||
| \ope of this JSON example", | \of this JSON example", | |||
| "max-link-bandwidth": { | "max-link-bandwidth": { | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odulist": [ | "ietf-otn-topology:odulist": [ | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU4", | "odu-type": "ietf-layer1-types:ODU4", | |||
| "number": 1 | "number": 1 | |||
| }, | }, | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU2", | "odu-type": "ietf-layer1-types:ODU2", | |||
| "number": 10 | "number": 10 | |||
| skipping to change at page 68, line 46 ¶ | skipping to change at page 70, line 35 ¶ | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ], | ], | |||
| "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ | "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ | |||
| \G", | \G", | |||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ is-transitional": "It is not a tra\ | "// not-present is-transitional": "It is not a transit\ | |||
| \nsitional link" | \ional link" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LINK__": { | "// link description": { | |||
| "name": "Inter-domain Link from AN1-5", | "name": "Inter-domain Link from AN1-5", | |||
| "type": "OTU4 inter-domain link", | "type": "OTU4 inter-domain link", | |||
| "physical link": "Link from S8-4 to S12" | "physical link": "Link from S8-4 to S12" | |||
| }, | }, | |||
| "link-id": "teNodeId/10.0.0.1/teLinkId/5", | "link-id": "teNodeId/192.0.2.1/teLinkId/5", | |||
| "source": { | "source": { | |||
| "source-node": "10.0.0.1", | "source-node": "192.0.2.1", | |||
| "source-tp": 5 | "source-tp": "5" | |||
| }, | }, | |||
| "// __NOT-PRESENT__ destination": "inter-domain link", | "// not-present destination": "inter-domain link", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-link-attributes": { | "te-link-attributes": { | |||
| "name": "Inter-domain Link from AN1-5", | "name": "Inter-domain Link from AN1-5", | |||
| "// __NOT-PRESENT__ external-domain": "The plug-id i\ | "// not-present external-domain": "The plug-id is us\ | |||
| \s used instead of this container", | \ed instead of this container", | |||
| "// __NOT-PRESENT__ is-abstract": "The access link i\ | "// not-present is-abstract": "The access link is no\ | |||
| \s not abstract", | \t abstract", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabilit\ | "// comment encoding and switching-capability": \ | |||
| \y": "OTN (ODU)", | \"OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switching\ | "switching-capability": "ietf-te-types:switching\ | |||
| \-otn", | \-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-layer1\ | "ietf-otn-topology:otn": { | |||
| \-types:ODU4" | "odu-type": "ietf-layer1-types:ODU4" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __COMMENT__ label-restrictions": "Outside the sc\ | "// comment label-restrictions": "Outside the scope \ | |||
| \ope of this JSON example", | \of this JSON example", | |||
| "max-link-bandwidth": { | "max-link-bandwidth": { | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odulist": [ | "ietf-otn-topology:odulist": [ | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU4", | "odu-type": "ietf-layer1-types:ODU4", | |||
| "number": 1 | "number": 1 | |||
| }, | }, | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU2", | "odu-type": "ietf-layer1-types:ODU2", | |||
| "number": 10 | "number": 10 | |||
| skipping to change at page 71, line 7 ¶ | skipping to change at page 72, line 44 ¶ | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ], | ], | |||
| "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ | "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ | |||
| \G", | \G", | |||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ is-transitional": "It is not a tra\ | "// not-present is-transitional": "It is not a transit\ | |||
| \nsitional link" | \ional link" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LINK__": { | "// link description": { | |||
| "name": "Inter-domain Link from AN1-6", | "name": "Inter-domain Link from AN1-6", | |||
| "type": "OTU4 inter-domain link", | "type": "OTU4 inter-domain link", | |||
| "physical link": "Link from S8-5 to S32" | "physical link": "Link from S8-5 to S32" | |||
| }, | }, | |||
| "link-id": "teNodeId/10.0.0.1/teLinkId/6", | "link-id": "teNodeId/192.0.2.1/teLinkId/6", | |||
| "source": { | "source": { | |||
| "source-node": "10.0.0.1", | "source-node": "192.0.2.1", | |||
| "source-tp": 6 | "source-tp": "6" | |||
| }, | }, | |||
| "// __NOT-PRESENT__ destination": "inter-domain link", | "// not-present destination": "inter-domain link", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-link-attributes": { | "te-link-attributes": { | |||
| "name": "Inter-domain Link from AN1-6", | "name": "Inter-domain Link from AN1-6", | |||
| "// __NOT-PRESENT__ external-domain": "The plug-id i\ | "// not-present external-domain": "The plug-id is us\ | |||
| \s used instead of this container", | \ed instead of this container", | |||
| "// __NOT-PRESENT__ is-abstract": "The access link i\ | "// not-present is-abstract": "The access link is no\ | |||
| \s not abstract", | \t abstract", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabilit\ | "// comment encoding and switching-capability": \ | |||
| \y": "OTN (ODU)", | \"OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switching\ | "switching-capability": "ietf-te-types:switching\ | |||
| \-otn", | \-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-layer1\ | "ietf-otn-topology:otn": { | |||
| \-types:ODU4" | "odu-type": "ietf-layer1-types:ODU4" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __COMMENT__ label-restrictions": "Outside the sc\ | "// comment label-restrictions": "Outside the scope \ | |||
| \ope of this JSON example", | \of this JSON example", | |||
| "max-link-bandwidth": { | "max-link-bandwidth": { | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odulist": [ | "ietf-otn-topology:odulist": [ | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU4", | "odu-type": "ietf-layer1-types:ODU4", | |||
| "number": 1 | "number": 1 | |||
| }, | }, | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU2", | "odu-type": "ietf-layer1-types:ODU2", | |||
| "number": 10 | "number": 10 | |||
| skipping to change at page 73, line 14 ¶ | skipping to change at page 75, line 4 ¶ | |||
| "odu-type": "ietf-layer1-types:ODU0", | "odu-type": "ietf-layer1-types:ODU0", | |||
| "number": 80 | "number": 80 | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ], | ], | |||
| "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ | "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ | |||
| \G", | \G", | |||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ is-transitional": "It is not a tra\ | "// not-present is-transitional": "It is not a transit\ | |||
| \nsitional link" | \ional link" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LINK__": { | "// link description": { | |||
| "name": "Inter-domain Link from AN1-7", | "name": "Inter-domain Link from AN1-7", | |||
| "type": "OTU4 inter-domain link", | "type": "OTU4 inter-domain link", | |||
| "physical link": "Link from S2-3 to S31" | "physical link": "Link from S2-3 to S31" | |||
| }, | }, | |||
| "link-id": "teNodeId/10.0.0.1teLinkId/7", | "link-id": "teNodeId/192.0.2.1teLinkId/7", | |||
| "source": { | "source": { | |||
| "source-node": "10.0.0.1", | "source-node": "192.0.2.1", | |||
| "source-tp": 7 | "source-tp": "7" | |||
| }, | }, | |||
| "// __NOT-PRESENT__ destination": "inter-domain link", | "// not-present destination": "inter-domain link", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-link-attributes": { | "te-link-attributes": { | |||
| "name": "Inter-domain Link from AN1-7", | "name": "Inter-domain Link from AN1-7", | |||
| "// __NOT-PRESENT__ external-domain": "The plug-id i\ | "// not-present external-domain": "The plug-id is us\ | |||
| \s used instead of this container", | \ed instead of this container", | |||
| "// __NOT-PRESENT__ is-abstract": "The access link i\ | "// not-present is-abstract": "The access link is no\ | |||
| \s not abstract", | \t abstract", | |||
| "interface-switching-capability": [ | "interface-switching-capability": [ | |||
| { | { | |||
| "// __COMMENT__ encoding and switching-capabilit\ | "// comment encoding and switching-capability": \ | |||
| \y": "OTN (ODU)", | \"OTN (ODU)", | |||
| "switching-capability": "ietf-te-types:switching\ | "switching-capability": "ietf-te-types:switching\ | |||
| \-otn", | \-otn", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "max-lsp-bandwidth": [ | "max-lsp-bandwidth": [ | |||
| { | { | |||
| "priority": 0, | "priority": 0, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odu-type": "ietf-layer1\ | "ietf-otn-topology:otn": { | |||
| \-types:ODU4" | "odu-type": "ietf-layer1-types:ODU4" | |||
| } | ||||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "// __COMMENT__ label-restrictions": "Outside the sc\ | "// comment label-restrictions": "Outside the scope \ | |||
| \ope of this JSON example", | \of this JSON example", | |||
| "max-link-bandwidth": { | "max-link-bandwidth": { | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-topology:odulist": [ | "ietf-otn-topology:odulist": [ | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU4", | "odu-type": "ietf-layer1-types:ODU4", | |||
| "number": 1 | "number": 1 | |||
| }, | }, | |||
| { | { | |||
| "odu-type": "ietf-layer1-types:ODU2", | "odu-type": "ietf-layer1-types:ODU2", | |||
| "number": 10 | "number": 10 | |||
| skipping to change at page 75, line 25 ¶ | skipping to change at page 77, line 16 ¶ | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ], | ], | |||
| "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ | "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ | |||
| \G", | \G", | |||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ is-transitional": "It is not a tra\ | "// not-present is-transitional": "It is not a transit\ | |||
| \nsitional link" | \ional link" | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| B.1.2. JSON Code: mpi1-eth-topology.json | B.1.2. JSON Code: mpi1-eth-topology.json | |||
| This is the JSON code reporting the ETH Topology @ MPI1: | This is the JSON code reporting the ETH Topology @ MPI1: | |||
| ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== | =============== NOTE: '\\' line wrapping per RFC 8792 =============== | |||
| { | { | |||
| "// __LAST_UPDATE__": "November 19, 2019", | "// header": { | |||
| "// __TITLE__": "ETH Black Topology @ MPI1", | "last-update": "March 15, 2022", | |||
| "// __REFERENCE_DRAFTS__": { | "title": "ETH Black Topology @ MPI1", | |||
| "ietf-routing-types@2017-12-04": "rfc8294", | "reference-drafts": { | |||
| "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", | "ietf-routing-types@2017-12-04": "rfc8294", | |||
| "ietf-network@2018-02-26": "rfc8345", | "ietf-te-types@2020-06-10": "rfc8776", | |||
| "ietf-network-topology@2018-02-26": "rfc8345", | "ietf-network@2018-02-26": "rfc8345", | |||
| "ietf-te-topology@2019-02-07": "draft-ietf-teas-yang-te-topo-22", | "ietf-network-topology@2018-02-26": "rfc8345", | |||
| "ietf-eth-tran-types@2019-03-27": "draft-ietf-ccamp-client-signa\ | "ietf-te-topology@2020-08-06": "rfc8795", | |||
| \l-yang-00", | "ietf-eth-tran-types@2021-07-07": "draft-ietf-ccamp-client-sig\ | |||
| "ietf-eth-te-topology@2019-11-18": "draft-zheng-ccamp-client-top\ | \nal-yang-05", | |||
| \o-yang-08" | "ietf-eth-te-topology@2019-11-18": "draft-ietf-ccamp-eth-clien\ | |||
| \t-te-topo-yang-00" | ||||
| } | ||||
| }, | }, | |||
| "// __MISSING_ATTRIBUTES__": true, | ||||
| "ietf-network:networks": { | "ietf-network:networks": { | |||
| "network": [ | "network": [ | |||
| { | { | |||
| "network-id": "providerId/201/clientId/300/topologyId/eth-bl\ | "network-id": "providerId/201/clientId/300/topologyId/eth-bl\ | |||
| \ack-topology", | \ack-topology", | |||
| "network-types": { | "network-types": { | |||
| "ietf-te-topology:te-topology": { | "ietf-te-topology:te-topology": { | |||
| "ietf-eth-te-topology:eth-tran-topology": {} | "ietf-eth-te-topology:eth-tran-topology": {} | |||
| } | } | |||
| }, | }, | |||
| "ietf-te-topology:te-topology-identifier": { | "ietf-te-topology:te-topology-identifier": { | |||
| "provider-id": 201, | "provider-id": 201, | |||
| "client-id": 300, | "client-id": 300, | |||
| "topology-id": "eth-black-topology" | "topology-id": "eth-black-topology" | |||
| }, | }, | |||
| "// __COMMENT__ ietf-te-topology:te": "presence container re\ | "// comment ietf-te-topology:te": "presence container requir\ | |||
| \quires: provider-id, client-id and te-topology-id", | \es: provider-id, client-id and te-topology-id", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "ETH Black Topology @ MPI1" | "name": "ETH Black Topology @ MPI1" | |||
| }, | }, | |||
| "ietf-network:node": [ | "ietf-network:node": [ | |||
| { | { | |||
| "// __NODE__:__DESCRIPTION__": { | "// node description": { | |||
| "name": "AN1", | "name": "AN1", | |||
| "identifier": "10.0.0.1", | "identifier": "192.0.2.1", | |||
| "type": "Abstract Node", | "type": "Abstract Node", | |||
| "physical node(s)": "The whole network domain 1" | "physical node(s)": "The whole network domain 1" | |||
| }, | }, | |||
| "node-id": "10.0.0.1", | "node-id": "192.0.2.1", | |||
| "ietf-te-topology:te-node-id": "10.0.0.1", | "ietf-te-topology:te-node-id": "192.0.2.1", | |||
| "// __COMMENT__ supporting-node": "Not used because topo\ | "// comment supporting-node": "Not used because topology\ | |||
| \logy hierarchy is outside the scope of this JSON example", | \ hierarchy is outside the scope of this JSON example", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-node-attributes": { | "te-node-attributes": { | |||
| "name": "AN11", | "name": "AN11", | |||
| "is-abstract": "", | "is-abstract": [ | |||
| null | ||||
| ], | ||||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ tunnel-termination-point": "ETH Ac\ | "// not-present tunnel-termination-point": "ETH Access\ | |||
| \cess Links only (no ETH TE switching)" | \ Links only (no ETH TE switching)" | |||
| }, | }, | |||
| "ietf-network-topology:termination-point": [ | "ietf-network-topology:termination-point": [ | |||
| { | { | |||
| "// __DESCRIPTION__:__LTP__": { | "// ltp description": { | |||
| "name": "AN1-1 LTP", | "name": "AN1-1 LTP", | |||
| "link type(s)": "Multi-function (OTU2, STM-64 and \ | "link type(s)": "Multi-function (OTU2, STM-64 and \ | |||
| \10GE)", | \10GE)", | |||
| "physical node": "S3", | "physical node": "S3", | |||
| "unnumberd/ifIndex": 1, | "unnumberd/ifIndex": 1, | |||
| "port type": "tributary port", | "port type": "tributary port", | |||
| "connected to": "R1" | "connected to": "R1" | |||
| }, | }, | |||
| "tp-id": "1", | "tp-id": "1", | |||
| "ietf-te-topology:te-tp-id": 1, | "ietf-te-topology:te-tp-id": 1, | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "AN1-1 LTP", | "name": "AN1-1 LTP", | |||
| "// __NOT-PRESENT__ interface-switching-capability\ | "// not-present interface-switching-capability": "\ | |||
| \": "ETH Access Link only (no ETH TE switching)", | \ETH Access Link only (no ETH TE switching)", | |||
| "// __COMMENT__ inter-domain-plug-id": "Use of plu\ | "// comment inter-domain-plug-id": "Use of plug-id\ | |||
| \g-id for access Link is outside the scope of this document", | \ for access Link is outside the scope of this document", | |||
| "// __COMMENT__ inter-layer-lock-id": "AN1-1 ILL-I\ | "// comment inter-layer-lock-id": "AN1-1 ILL-ID (1\ | |||
| \D (1)", | \)", | |||
| "inter-layer-lock-id": [ | "inter-layer-lock-id": [ | |||
| 1 | 1 | |||
| ], | ], | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up" | "oper-status": "up" | |||
| }, | }, | |||
| "// __COMMENT__ ingress-bandwidth-profile": "Outside\ | "// comment ietf-eth-te-topology:ingress-bandwidth-p\ | |||
| \ the scope of this JSON example", | \rofile": "Outside the scope of this JSON example", | |||
| "ietf-eth-te-topology:eth-svc": { | "ietf-eth-te-topology:eth-svc": { | |||
| "client-facing": true, | "client-facing": true, | |||
| "supported-classification": { | "supported-classification": { | |||
| "port-classification": true, | "port-classification": true, | |||
| "vlan-classification": { | "vlan-classification": { | |||
| "vlan-tag-classification": true, | "vlan-tag-classification": true, | |||
| "outer-tag": { | "outer-tag": { | |||
| "supported-tag-types": [ | "supported-tag-types": [ | |||
| "ietf-eth-tran-types:classify-c-vlan" | "ietf-eth-tran-types:classify-c-vlan" | |||
| ], | ], | |||
| "vlan-range": "1-4094" | "vlan-range": "1-4094" | |||
| } | } | |||
| } | } | |||
| }, | }, | |||
| "supported-vlan-operations": { | "supported-vlan-operations": { | |||
| "transparent-vlan-operations": true | "transparent-vlan-operations": true | |||
| } | } | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LTP__": { | "// ltp description": { | |||
| "name": "AN1-8 LTP", | "name": "AN1-8 LTP", | |||
| "link type(s)": "10GE", | "link type(s)": "10GE", | |||
| "physical node": "S6", | "physical node": "S6", | |||
| "unnumberd/ifIndex": 1, | "unnumberd/ifIndex": 1, | |||
| "port type": "tributary port", | "port type": "tributary port", | |||
| "connected to": "R2" | "connected to": "R2" | |||
| }, | }, | |||
| "tp-id": "8", | "tp-id": "8", | |||
| "ietf-te-topology:te-tp-id": 8, | "ietf-te-topology:te-tp-id": 8, | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "name": "AN1-8 LTP", | "name": "AN1-8 LTP", | |||
| "// __COMMENT__ inter-layer-lock-id": "AN1-8 ILL-I\ | "// comment inter-layer-lock-id": "AN1-8 ILL-ID (8\ | |||
| \D (8)", | \)", | |||
| "// __NOT-PRESENT__ interface-switching-capability\ | "// not-present interface-switching-capability": "\ | |||
| \": "ETH Access Link only (no ETH TE switching)", | \ETH Access Link only (no ETH TE switching)", | |||
| "// __COMMENT__ inter-domain-plug-id": "Use of plu\ | "// comment inter-domain-plug-id": "Use of plug-id\ | |||
| \g-id for access Link is outside the scope of this document", | \ for access Link is outside the scope of this document", | |||
| "inter-layer-lock-id": [ | "inter-layer-lock-id": [ | |||
| 8 | 8 | |||
| ], | ], | |||
| "admin-status": "up", | "admin-status": "up", | |||
| "oper-status": "up" | "oper-status": "up" | |||
| }, | }, | |||
| "// __COMMENT__ ingress-bandwidth-profile": "Outside\ | "// comment ingress-bandwidth-profile": "Outside the\ | |||
| \ the scope of this JSON example", | \ scope of this JSON example", | |||
| "ietf-eth-te-topology:eth-svc": { | "ietf-eth-te-topology:eth-svc": { | |||
| "client-facing": true, | "client-facing": true, | |||
| "supported-classification": { | "supported-classification": { | |||
| "port-classification": true, | "port-classification": true, | |||
| "vlan-classification": { | "vlan-classification": { | |||
| "vlan-tag-classification": true, | "vlan-tag-classification": true, | |||
| "outer-tag": { | "outer-tag": { | |||
| "supported-tag-types": [ | "supported-tag-types": [ | |||
| "ietf-eth-tran-types:classify-c-vlan" | "ietf-eth-tran-types:classify-c-vlan" | |||
| ], | ], | |||
| skipping to change at page 79, line 5 ¶ | skipping to change at page 80, line 48 ¶ | |||
| "supported-vlan-operations": { | "supported-vlan-operations": { | |||
| "transparent-vlan-operations": true | "transparent-vlan-operations": true | |||
| } | } | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ], | ], | |||
| "ietf-network-topology:link": [ | "ietf-network-topology:link": [ | |||
| { | { | |||
| "// __DESCRIPTION__:__LINK__": { | "// link description": { | |||
| "name": "Access Link from AN1-1", | "name": "Access Link from AN1-1", | |||
| "type": "Multi-function access link (OTU2, STM-64 and \ | "type": "Multi-function access link (OTU2, STM-64 and \ | |||
| \10GE)", | \10GE)", | |||
| "physical link": "Link from S3-1 to R1" | "physical link": "Link from S3-1 to R1" | |||
| }, | }, | |||
| "link-id": "teNodeId/10.0.0.1/teLinkId/1", | "link-id": "teNodeId/192.0.2.1/teLinkId/1", | |||
| "source": { | "source": { | |||
| "source-node": "10.0.0.1", | "source-node": "192.0.2.1", | |||
| "source-tp": 1 | "source-tp": "1" | |||
| }, | }, | |||
| "// __NOT-PRESENT__ destination": "access link", | "// not-present destination": "access link", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-link-attributes": { | "te-link-attributes": { | |||
| "name": "Access Link from AN1-1", | "name": "Access Link from AN1-1", | |||
| "// __NOT-PRESENT__ external-domain": "The plug-id i\ | "// not-present external-domain": "The plug-id is us\ | |||
| \s used instead of this container", | \ed instead of this container", | |||
| "// __NOT-PRESENT__ is-abstract": "The access link i\ | "// not-present is-abstract": "The access link is no\ | |||
| \s not abstract", | \t abstract", | |||
| "// __NOT-PRESENT__ interface-switching-capability":\ | "// not-present interface-switching-capability": "ET\ | |||
| \ "ETH Access Link only (no ETH TE switching)", | \H Access Link only (no ETH TE switching)", | |||
| "// __NOT-PRESENT__ label-restrictions": "ETH Access\ | "// not-present label-restrictions": "ETH Access Lin\ | |||
| \ Link only (no ETH TE switching)", | \k only (no ETH TE switching)", | |||
| "// __NOT-PRESENT__ max-link-bandwidth": "ETH Access\ | "// not-present max-link-bandwidth": "ETH Access Lin\ | |||
| \ Link only (no ETH TE switching)", | \k only (no ETH TE switching)", | |||
| "// __NOT-PRESENT__ max-resv-link-bandwidth": "ETH A\ | "// not-present max-resv-link-bandwidth": "ETH Acces\ | |||
| \ccess Link only (no ETH TE switching)", | \s Link only (no ETH TE switching)", | |||
| "// __NOT-PRESENT__ unreserved-bandwidth": "ETH Acce\ | "// not-present unreserved-bandwidth": "ETH Access L\ | |||
| \ss Link only (no ETH TE switching)", | \ink only (no ETH TE switching)", | |||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ is-transitional": "It is not a tra\ | "// not-present is-transitional": "It is not a transit\ | |||
| \nsitional link" | \ional link" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __DESCRIPTION__:__LINK__": { | "// link description": { | |||
| "name": "Access Link from AN1-8", | "name": "Access Link from AN1-8", | |||
| "type": "10GE access link", | "type": "10GE access link", | |||
| "physical link": "Link from S6-1 to R2" | "physical link": "Link from S6-1 to R2" | |||
| }, | }, | |||
| "link-id": "teNodeId/10.0.0.1/teLinkId/8", | "link-id": "teNodeId/192.0.2.1/teLinkId/8", | |||
| "source": { | "source": { | |||
| "source-node": "10.0.0.1", | "source-node": "192.0.2.1", | |||
| "source-tp": 8 | "source-tp": "8" | |||
| }, | }, | |||
| "// __NOT-PRESENT__ destination": "access link", | "// not-present destination": "access link", | |||
| "ietf-te-topology:te": { | "ietf-te-topology:te": { | |||
| "te-link-attributes": { | "te-link-attributes": { | |||
| "name": "Access Link from AN1-8", | "name": "Access Link from AN1-8", | |||
| "// __NOT-PRESENT__ external-domain": "The plug-id i\ | "// not-present external-domain": "The plug-id is us\ | |||
| \s used instead of this container", | \ed instead of this container", | |||
| "// __NOT-PRESENT__ is-abstract": "The access link i\ | "// not-present is-abstract": "The access link is no\ | |||
| \s not abstract", | \t abstract", | |||
| "// __NOT-PRESENT__ interface-switching-capability":\ | "// not-present interface-switching-capability": "ET\ | |||
| \ "ETH Access Link only (no ETH TE switching)", | \H Access Link only (no ETH TE switching)", | |||
| "// __NOT-PRESENT__ label-restrictions": "ETH Access\ | "// not-present label-restrictions": "ETH Access Lin\ | |||
| \ Link only (no ETH TE switching)", | \k only (no ETH TE switching)", | |||
| "// __NOT-PRESENT__ max-link-bandwidth": "ETH Access\ | "// not-present max-link-bandwidth": "ETH Access Lin\ | |||
| \ Link only (no ETH TE switching)", | \k only (no ETH TE switching)", | |||
| "// __NOT-PRESENT__ max-resv-link-bandwidth": "ETH A\ | "// not-present max-resv-link-bandwidth": "ETH Acces\ | |||
| \ccess Link only (no ETH TE switching)", | \s Link only (no ETH TE switching)", | |||
| "// __NOT-PRESENT__ unreserved-bandwidth": "ETH Acce\ | "// not-present unreserved-bandwidth": "ETH Access L\ | |||
| \ss Link only (no ETH TE switching)", | \ink only (no ETH TE switching)", | |||
| "admin-status": "up" | "admin-status": "up" | |||
| }, | }, | |||
| "oper-status": "up", | "oper-status": "up", | |||
| "// __NOT-PRESENT__ is-transitional": "It is not a tra\ | "// not-present is-transitional": "It is not a transit\ | |||
| \nsitional link" | \ional link" | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| B.2. JSON Examples for Service Configuration | B.2. JSON Examples for Service Configuration | |||
| B.2.1. JSON Code: mpi1-odu2-service-config.json | B.2.1. JSON Code: mpi1-odu2-service-config.json | |||
| This is the JSON code reporting the ODU2 transit service | This is the JSON code reporting the ODU2 transit service | |||
| configuration @ MPI1: | configuration @ MPI1: | |||
| ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== | =============== NOTE: '\\' line wrapping per RFC 8792 =============== | |||
| { | { | |||
| "// __LAST_UPDATE__": "October 23, 2019", | "// header": { | |||
| "// __TITLE__": "ODU2 Service Configuration @ MPI1", | "// last-update": "March 15, 2022", | |||
| "// __REFERENCE_DRAFTS__": { | "// title": "ODU2 Service Configuration @ MPI1", | |||
| "reference-drafts": { | ||||
| "ietf-routing-types@2017-12-04": "rfc8294", | "ietf-routing-types@2017-12-04": "rfc8294", | |||
| "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", | "ietf-te-types@2020-06-10": "rfc8776", | |||
| "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\ | "ietf-layer1-types@2021-02-19": "draft-ietf-ccamp-layer1-types-1\ | |||
| \2", | \0", | |||
| "ietf-te@2019-04-09": "draft-ietf-teas-yang-te-21", | "ietf-te@2021-02-20": "draft-ietf-teas-yang-te-26", | |||
| "ietf-otn-tunnel@2019-10-23": "draft-ietf-ccamp-otn-tunnel-model\ | "ietf-otn-tunnel@2021-06-25": "draft-ietf-ccamp-otn-tunnel-model\ | |||
| \-08" | \-14" | |||
| } | ||||
| }, | }, | |||
| "// __MISSING_ATTRIBUTES__": true, | "// missing-attributes": true, | |||
| "// __RESTCONF_OPERATION__": { | "// restconf_operation": { | |||
| "operation": "POST", | "operation": "POST", | |||
| "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels" | "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels" | |||
| }, | }, | |||
| "ietf-te:te": { | "ietf-te:te": { | |||
| "tunnels": { | "tunnels": { | |||
| "tunnel": [ | "tunnel": [ | |||
| { | { | |||
| "name": "mpi1-odu2-service", | "name": "mpi1-odu2-service", | |||
| "// __COMMENT__ identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI\ | "// comment identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI1", | |||
| \1", | ||||
| "identifier": 1, | "identifier": 1, | |||
| "description": "ODU2 Service implemented by ODU2 OTN Tunne\ | "description": "ODU2 Service implemented by ODU2 OTN Tunne\ | |||
| \l Segment @ MPI1", | \l Segment @ MPI1", | |||
| "// __COMMENT__ encoding and switching-type": "OTN (ODU)", | "// comment encoding and switching-type": "OTN (ODU)", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "switching-type": "ietf-te-types:switching-otn", | "switching-type": "ietf-te-types:switching-otn", | |||
| "// __NOT-PRESENT__ source": "Transit tunnel segment", | "// not-present source": "Transit tunnel segment", | |||
| "// __NOT-PRESENT__ src-tp-id": "Transit tunnel segment", | "// not-present src-tunnel-tp-id": "Transit tunnel segment\ | |||
| "// __NOT-PRESENT__ destination": "Transit tunnel segment", | \", | |||
| "// __NOT-PRESENT__ dst-tp-id": "Transit tunnel segment", | "// not-present destination": "Transit tunnel segment", | |||
| "// not-present dst-tunnel-tp-id": "Transit tunnel segment\ | ||||
| \", | ||||
| "bidirectional": true, | "bidirectional": true, | |||
| "// __ DEFAULT __ protection": { | "// default protection": { | |||
| "// __ DEFAULT __ enable": false | "// default enable": false | |||
| }, | }, | |||
| "// __ DEFAULT __ restoration": { | "// default restoration": { | |||
| "// __ DEFAULT __ enable": false | "// default enable": false | |||
| }, | }, | |||
| "// __COMMENT__ te-topology-identifier": "ODU Black Topolo\ | "// comment te-topology-identifier": "ODU Black Topology @\ | |||
| \gy @ MPI1", | \ MPI1", | |||
| "te-topology-identifier": { | "te-topology-identifier": { | |||
| "provider-id": 201, | "provider-id": 201, | |||
| "client-id": 300, | "client-id": 300, | |||
| "topology-id": "otn-black-topology" | "topology-id": "otn-black-topology" | |||
| }, | }, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2" | "ietf-otn-tunnel:otn": { | |||
| "ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2" | ||||
| } | ||||
| }, | }, | |||
| "provisioning-state": "ietf-te-types:tunnel-state-up", | "admin-state": "ietf-te-types:tunnel-admin-state-up", | |||
| "p2p-primary-paths": { | "primary-paths": { | |||
| "p2p-primary-path": [ | "primary-path": [ | |||
| { | { | |||
| "name": "mpi1-odu2-service-primary-path", | "name": "mpi1-odu2-service-primary-path", | |||
| "// __NOT-PRESENT__ te-bandwidth": "The tunnel bandw\ | "// not-present te-bandwidth": "The tunnel bandwidth\ | |||
| \idth is used", | ||||
| \ is used", | ||||
| "explicit-route-objects-always": { | "explicit-route-objects-always": { | |||
| "route-object-include-exclude": [ | "route-object-include-exclude": [ | |||
| { | { | |||
| "// __COMMENT__": "Tunnel hand-off OTU2 ingres\ | "// comment": "Tunnel hand-off OTU2 ingress in\ | |||
| \s interface (S3-1 -> AN1-1)", | \terface (S3-1 -> AN1-1)", | |||
| "index": 1, | "index": 1, | |||
| "explicit-route-usage": "ietf-te-types:route-i\ | "explicit-route-usage": "ietf-te-types:route-i\ | |||
| \nclude-object", | \nclude-object", | |||
| "unnumbered-link-hop": { | "unnumbered-link-hop": { | |||
| "// __COMMENT__ node-id": "AN1 NODE-ID", | "// comment node-id": "AN1 NODE-ID", | |||
| "node-id": "10.0.0.1", | "node-id": "192.0.2.1", | |||
| "// __COMMENT__ link-tp-id": "AN1-1 LTP", | "// comment link-tp-id": "AN1-1 LTP", | |||
| "link-tp-id": 1, | "link-tp-id": 1, | |||
| "// __DEFAULT__ hop-type": "strict", | "// default hop-type": "strict", | |||
| "// __DEFAULT__ direction": "outgoing" | "// default direction": "outgoing" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __COMMENT__": "Tunnel hand-off ODU2 ingres\ | "// comment": "Tunnel hand-off ODU2 ingress la\ | |||
| \s label (ODU2 over OTU2) at S3-1 (AN1-1)", | \bel (ODU2 over OTU2) at S3-1 (AN1-1)", | |||
| "index": 2, | "index": 2, | |||
| "explicit-route-usage": "ietf-te-types:route-i\ | "explicit-route-usage": "ietf-te-types:route-i\ | |||
| \nclude-object", | \nclude-object", | |||
| "label-hop": { | "label-hop": { | |||
| "te-label": { | "te-label": { | |||
| "ietf-otn-tunnel:tpn": 1, | "ietf-otn-tunnel:otn-tpn": 1, | |||
| "// __NOT-PRESENT__ ietf-otn-tunnel:tsg": \ | "// not-present ietf-otn-tunnel:tsg": "Not\ | |||
| \ applicable for ODUk over OTUk", | ||||
| "// not-present ietf-otn-tunnel:ts-list": \ | ||||
| \"Not applicable for ODUk over OTUk", | \"Not applicable for ODUk over OTUk", | |||
| "// __NOT-PRESENT__ ietf-otn-tunnel:ts-lis\ | "// default direction": "forward" | |||
| \t": "Not applicable for ODUk over OTUk", | ||||
| "// __DEFAULT__ direction": "forward" | ||||
| } | } | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __COMMENT__": "Tunnel hand-off OTU4 egress\ | "// comment": "Tunnel hand-off OTU4 egress int\ | |||
| \ interface (S2-3 -> AN1-7)", | \erface (S2-3 -> AN1-7)", | |||
| "index": 3, | "index": 3, | |||
| "explicit-route-usage": "ietf-te-types:route-i\ | "explicit-route-usage": "ietf-te-types:route-i\ | |||
| \nclude-object", | \nclude-object", | |||
| "unnumbered-link-hop": { | "unnumbered-link-hop": { | |||
| "// __COMMENT__ node-id": "AN1 Node", | "// comment node-id": "AN1 Node", | |||
| "node-id": "10.0.0.1", | "node-id": "192.0.2.1", | |||
| "// __COMMENT__ link-tp-id": "AN1-7 LTP", | "// comment link-tp-id": "AN1-7 LTP", | |||
| "link-tp-id": 7, | "link-tp-id": 7, | |||
| "// __DEFAULT__ hop-type": "strict", | "// default hop-type": "strict", | |||
| "// __DEFAULT__ direction": "outgoing" | "// default direction": "outgoing" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __COMMENT__": "Tunnel hand-off ODU2 egress\ | "// comment": "Tunnel hand-off ODU2 egress lab\ | |||
| \ label (ODU2 over OTU4) at S2-3 (AN1-7)", | \el (ODU2 over OTU4) at S2-3 (AN1-7)", | |||
| "index": 4, | "index": 4, | |||
| "explicit-route-usage": "ietf-te-types:route-i\ | "explicit-route-usage": "ietf-te-types:route-i\ | |||
| \nclude-object", | \nclude-object", | |||
| "label-hop": { | "label-hop": { | |||
| "te-label": { | "te-label": { | |||
| "ietf-otn-tunnel:tpn": 1, | "ietf-otn-tunnel:otn-tpn": 1, | |||
| "ietf-otn-tunnel:tsg": "ietf-layer1-types:\ | "ietf-otn-tunnel:tsg": "ietf-layer1-types:\ | |||
| \tsg-1.25G", | \tsg-1.25G", | |||
| "ietf-otn-tunnel:ts-list": "1-8", | "ietf-otn-tunnel:ts-list": "1-8", | |||
| "// __DEFAULT__ direction": "forward" | "// default direction": "forward" | |||
| } | } | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| } | } | |||
| B.2.2. JSON Code: mpi1-odu2-tunnel-config.json | B.2.2. JSON Code: mpi1-odu2-tunnel-config.json | |||
| This is the JSON code reporting the ODU2 head tunnel segment | This is the JSON code reporting the ODU2 head tunnel segment | |||
| configuration @ MPI1: | configuration @ MPI1: | |||
| ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== | =============== NOTE: '\\' line wrapping per RFC 8792 =============== | |||
| { | { | |||
| "// __LAST_UPDATE__": "October 23, 2019", | "// header": { | |||
| "// __TITLE__": "ODU2 Tunnel Configuration @ MPI1", | "last-update": "March 15, 2022", | |||
| "// __REFERENCE_DRAFTS__": { | "title": "ODU2 Tunnel Configuration @ MPI1", | |||
| "ietf-routing-types@2017-12-04": "rfc8294", | "reference-drafts": { | |||
| "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", | "ietf-routing-types@2017-12-04": "rfc8294", | |||
| "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\ | "ietf-te-types@2020-06-10": "rfc8776", | |||
| \2", | "ietf-layer1-types@2021-02-19": "draft-ietf-ccamp-layer1-types\ | |||
| "ietf-te@2019-04-09": "draft-ietf-teas-yang-te-21", | \-10", | |||
| "ietf-otn-tunnel@2019-10-23": "draft-ietf-ccamp-otn-tunnel-model\ | "ietf-te@2021-02-20": "draft-ietf-teas-yang-te-26", | |||
| \-08" | "ietf-otn-tunnel@2021-06-25": "draft-ietf-ccamp-otn-tunnel-mod\ | |||
| \el-14" | ||||
| }, | }, | |||
| "// __MISSING_ATTRIBUTES__": true, | "// missing-attributes": true, | |||
| "// __RESTCONF_OPERATION__": { | "// restconf-operation": { | |||
| "operation": "POST", | "operation": "POST", | |||
| "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels" | "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels" | |||
| } | ||||
| }, | }, | |||
| "ietf-te:te": { | "ietf-te:te": { | |||
| "tunnels": { | "tunnels": { | |||
| "tunnel": [ | "tunnel": [ | |||
| { | { | |||
| "name": "mpi1-odu2-tunnel", | "name": "mpi1-odu2-tunnel", | |||
| "// __COMMENT__ identifier": "ODU2-TUNNEL-ID @ MPI1", | "// comment identifier": "ODU2-TUNNEL-ID @ MPI1", | |||
| "identifier": 2, | "identifier": 2, | |||
| "description": "TNBI Example for an ODU2 Head Tunnel Segme\ | "description": "TNBI Example for an ODU2 Head Tunnel Segme\ | |||
| \nt @ MPI1", | \nt @ MPI1", | |||
| "// __COMMENT__ encoding and switching-type": "OTN (ODU)", | "// comment encoding and switching-type": "OTN (ODU)", | |||
| "encoding": "ietf-te-types:lsp-encoding-oduk", | "encoding": "ietf-te-types:lsp-encoding-oduk", | |||
| "switching-type": "ietf-te-types:switching-otn", | "switching-type": "ietf-te-types:switching-otn", | |||
| "// __COMMENT__ source": "AN1 Node-ID", | "// comment source": "AN1 Node-ID", | |||
| "source": "10.0.0.1", | "source": "192.0.2.1", | |||
| "// __COMMENT__ src-tp-id": "AN1-1 TTP-ID (1 -> 0x01 -> '0\ | "// comment src-tunnel-tp-id": "AN1-1 TTP-ID (1 -> 0x01 ->\ | |||
| \1')", | \ 'AQ==' in base64)", | |||
| "src-tp-id": "01", | "src-tunnel-tp-id": "AQ==", | |||
| "// __NOT-PRESENT__ destination": "Head tunnel segment", | "// not-present destination": "Head tunnel segment", | |||
| "// __NOT-PRESENT__ dst-tp-id": "Head tunnel segment", | "// not-present dst-tunnel-tp-id": "Head tunnel segment", | |||
| "bidirectional": true, | "bidirectional": true, | |||
| "// __ DEFAULT __ protection": { | "// default protection": { | |||
| "// __ DEFAULT __ enable": false | "// default enable": false | |||
| }, | }, | |||
| "// __ DEFAULT __ restoration": { | "// default restoration": { | |||
| "// __ DEFAULT __ enable": false | "// default enable": false | |||
| }, | }, | |||
| "// __COMMENT__ te-topology-identifier": "ODU Black Topolo\ | "// comment te-topology-identifier": "ODU Black Topology @\ | |||
| \gy @ MPI1", | \ MPI1", | |||
| "te-topology-identifier": { | "te-topology-identifier": { | |||
| "provider-id": 201, | "provider-id": 201, | |||
| "client-id": 300, | "client-id": 300, | |||
| "topology-id": "otn-black-topology" | "topology-id": "otn-black-topology" | |||
| }, | }, | |||
| "te-bandwidth": { | "te-bandwidth": { | |||
| "ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2" | "ietf-otn-tunnel:otn": { | |||
| "ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2" | ||||
| } | ||||
| }, | }, | |||
| "provisioning-state": "ietf-te-types:tunnel-state-down", | "admin-state": "ietf-te:tunnel-admin-auto", | |||
| "p2p-primary-paths": { | "primary-paths": { | |||
| "p2p-primary-path": [ | "primary-path": [ | |||
| { | { | |||
| "name": "mpi1-odu2-tunnel-primary-path", | "name": "mpi1-odu2-tunnel-primary-path", | |||
| "// __NOT-PRESENT__ te-bandwidth": "The tunnel bandw\ | "// not-present te-bandwidth": "The tunnel bandwidth\ | |||
| \ is used", | ||||
| \idth is used", | ||||
| "explicit-route-objects-always": { | "explicit-route-objects-always": { | |||
| "route-object-include-exclude": [ | "route-object-include-exclude": [ | |||
| { | { | |||
| "// __COMMENT__": "Tunnel hand-off OTU4 egress\ | "// comment": "Tunnel hand-off OTU4 egress int\ | |||
| \ interface (AN1-7 LTP)", | \erface (AN1-7 LTP)", | |||
| "index": 1, | "index": 1, | |||
| "explicit-route-usage": "ietf-te-types:route-i\ | "explicit-route-usage": "ietf-te-types:route-i\ | |||
| \nclude-object", | \nclude-object", | |||
| "unnumbered-link-hop": { | "unnumbered-link-hop": { | |||
| "// __COMMENT__ node-id": "AN1 NODE-ID", | "// comment node-id": "AN1 NODE-ID", | |||
| "node-id": "10.0.0.1", | "node-id": "192.0.2.1", | |||
| "// __COMMENT__ link-tp-id": "AN1-7 LTP-ID", | "// comment link-tp-id": "AN1-7 LTP-ID", | |||
| "link-tp-id": 7, | "link-tp-id": 7, | |||
| "// __DEFAULT__ hop-type": "strict", | "// default hop-type": "strict", | |||
| "// __DEFAULT__ direction": "outgoing" | "// default direction": "outgoing" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "// __COMMENT__": "Tunnel hand-off ODU2 egress\ | "// comment": "Tunnel hand-off ODU2 egress lab\ | |||
| \ label (ODU2 over OTU4)", | \el (ODU2 over OTU4)", | |||
| "index": 2, | "index": 2, | |||
| "explicit-route-usage": "ietf-te-types:route-i\ | "explicit-route-usage": "ietf-te-types:route-i\ | |||
| \nclude-object", | \nclude-object", | |||
| "label-hop": { | "label-hop": { | |||
| "te-label": { | "te-label": { | |||
| "ietf-otn-tunnel:tpn": 2, | "ietf-otn-tunnel:otn-tpn": 2, | |||
| "ietf-otn-tunnel:tsg": "ietf-layer1-types:\ | "ietf-otn-tunnel:tsg": "ietf-layer1-types:\ | |||
| \tsg-1.25G", | \tsg-1.25G", | |||
| "ietf-otn-tunnel:ts-list": "9-16", | "ietf-otn-tunnel:ts-list": "9-16", | |||
| "// __DEFAULT__ direction": "forward" | "// default direction": "forward" | |||
| } | } | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| } | } | |||
| B.2.3. JSON Code: mpi1-epl-service-config.json | B.2.3. JSON Code: mpi1-epl-service-config.json | |||
| This is the JSON code reporting the EPL service configuration @ MPI: | This is the JSON code reporting the EPL service configuration @ MPI: | |||
| ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== | =============== NOTE: '\\' line wrapping per RFC 8792 =============== | |||
| { | { | |||
| "// __LAST_UPDATE__": "November 19, 2019", | "// header": { | |||
| "// __TITLE__": "EPL Configuration @ MPI1", | "last-update": "March 15, 2022", | |||
| "// __REFERENCE_DRAFTS__": { | "title": "EPL Configuration @ MPI1", | |||
| "ietf-routing-types@2017-12-04": "rfc8294", | "reference-drafts": { | |||
| "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", | "ietf-routing-types@2017-12-04": "rfc8294", | |||
| "ietf-eth-tran-types@2019-03-27": "draft-ietf-ccamp-client-signa\ | "ietf-te@2021-05-16": "draft-ietf-teas-yang-te-27", | |||
| \l-yang-00", | "ietf-te-types@2020-06-10": "rfc8776", | |||
| "ietf-eth-tran-service@2019-03-27": "draft-ietf-ccamp-client-sig\ | "ietf-eth-tran-types@2021-07-07": "draft-ietf-ccamp-client-sig\ | |||
| \nal-yang-00" | \nal-yang-05", | |||
| }, | "ietf-eth-tran-service@2021-01-11": "draft-ietf-ccamp-client-s\ | |||
| "// __MISSING_ATTRIBUTES__": true, | \ignal-yang-05" | |||
| "// __RESTCONF_OPERATION__": { | }, | |||
| "operation": "POST", | "missing-attributes": true, | |||
| "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-eth-tran-service\ | "restconf-operation": { | |||
| \:etht-svc/etht-svc-instances" | "operation": "POST", | |||
| "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-eth-tran-servi\ | ||||
| \ce:etht-svc/etht-svc-instances" | ||||
| } | ||||
| }, | }, | |||
| "ietf-eth-tran-service:etht-svc": { | "ietf-eth-tran-service:etht-svc": { | |||
| "etht-svc-instances": [ | "etht-svc-instances": [ | |||
| { | { | |||
| "etht-svc-name": "mpi1-epl-service", | "etht-svc-name": "mpi1-epl-service", | |||
| "etht-svc-descr": "TNBI Example for an EPL over ODU2 Service\ | "etht-svc-descr": "TNBI Example for an EPL over ODU2 Service\ | |||
| \ @ MPI1", | \ @ MPI1", | |||
| "// __DEFAULT__ etht-svc-type": "ietf-eth-tran-types:p2p-svc\ | "// default etht-svc-type": "ietf-eth-tran-types:p2p-svc", | |||
| \", | "// comment te-topology-identifier": "ETH Black Topology @ M\ | |||
| "// __COMMENT__ te-topology-identifier": "ETH Black Topology\ | \PI1", | |||
| \ @ MPI1", | ||||
| "te-topology-identifier": { | "te-topology-identifier": { | |||
| "provider-id": 201, | "provider-id": 201, | |||
| "client-id": 300, | "client-id": 300, | |||
| "topology-id": "eth-black-topology" | "topology-id": "eth-black-topology" | |||
| }, | }, | |||
| "etht-svc-end-points": [ | "etht-svc-end-points": [ | |||
| { | { | |||
| "// __COMMENT__": "10GE Service End-Point at the access \ | "// comment": "10GE Service End-Point at the access inte\ | |||
| \interface (S3-1 -> AN1-1)", | \rface (S3-1 -> AN1-1)", | |||
| "etht-svc-end-point-name": "mpi1-epl-an1-1-service-end-p\ | "etht-svc-end-point-name": "mpi1-epl-an1-1-service-end-p\ | |||
| \oint", | \oint", | |||
| "etht-svc-end-point-descr": "Ethernet Service End-Point \ | "etht-svc-end-point-descr": "Ethernet Service End-Point \ | |||
| \at S3-1 (AN1-1) access link", | \at S3-1 (AN1-1) access link", | |||
| "service-classification-type": "ietf-eth-tran-types:port\ | ||||
| \-classification", | ||||
| "etht-svc-access-points": [ | "etht-svc-access-points": [ | |||
| { | { | |||
| "// __COMMENT__": "10GE Service Access Point at the \ | "// comment": "10GE Service Access Point at the acce\ | |||
| \access interface (S3-1 -> AN1-1)", | \ss interface (S3-1 -> AN1-1)", | |||
| "access-point-id": "mpi-epl-an1-1-service-access-poi\ | "access-point-id": "mpi-epl-an1-1-service-access-poi\ | |||
| \nt", | \nt", | |||
| "// __COMMENT__ access-node-id": "AN1 NODE-ID", | "// comment access-node-id": "AN1 NODE-ID", | |||
| "access-node-id": "10.0.0.1", | "access-node-id": "192.0.2.1", | |||
| "// __COMMENT__ access-ltp-id": "AN1-1 LTP-ID", | "// comment access-ltp-id": "AN1-1 LTP-ID", | |||
| "access-ltp-id": 1 | "access-ltp-id": 1 | |||
| } | } | |||
| ] | ], | |||
| } | "service-classification-type": "ietf-eth-tran-types:port\ | |||
| ], | \-classification", | |||
| "// __COMMENT__ ingress-egress-bandwidth-profile": "Outside \ | "// comment ingress-egress-bandwidth-profile": "Outside \ | |||
| \the scope of this JSON example", | \the scope of this JSON example", | |||
| "// __NOT-PRESENT__ vlan-operations": "Transparent VLAN oper\ | "// comment not present vlan-operations": "Transparent V\ | |||
| \ations", | \LAN operations" | |||
| "etht-svc-tunnels": [ | ||||
| { | ||||
| "// __COMMENT__ tunnel-name": "ODU2 Head Tunnel Segment \ | ||||
| \@ MPI1", | ||||
| "tunnel-name": "mpi1-odu2-tunnel" | ||||
| } | } | |||
| ], | ], | |||
| "underlay": { | ||||
| "otn-tunnels": [ | ||||
| { | ||||
| "// comment tunnel-name": "ODU2 Head Tunnel Segment @ \ | ||||
| \MPI1", | ||||
| "name": "mpi1-odu2-tunnel" | ||||
| } | ||||
| ] | ||||
| }, | ||||
| "admin-status": "ietf-te-types:tunnel-admin-state-up" | "admin-status": "ietf-te-types:tunnel-admin-state-up" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Acknowledgments | Acknowledgments | |||
| The authors would like to thank all members of the Transport NBI | The authors would like to thank all members of the Transport NBI | |||
| Design Team involved in the definition of use cases, gap analysis and | Design Team involved in the definition of use cases, gap analysis and | |||
| guidelines for using the IETF YANG models at the Northbound Interface | guidelines for using the IETF YANG models at the Northbound Interface | |||
| (NBI) of a Transport SDN Controller. | (NBI) of a Transport SDN Controller. | |||
| The authors would like to thank Xian Zhang, Anurag Sharma, Sergio | The authors would like to thank Xian Zhang, Anurag Sharma, Sergio | |||
| Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar | Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar | |||
| Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated | Gonzalez de Dios, and Hans Bjursrom for having initiated the work on | |||
| the work on gap analysis for transport NBI and having provided | gap analysis for transport NBI and having provided foundations work | |||
| foundations work for the development of this document. | for the development of this document. | |||
| The authors would like to thank the authors of the TE Topology and | The authors would like to thank the authors of the TE Topology and | |||
| Tunnel YANG models [RFC8795] and [TE-TUNNEL], in particular, Igor | Tunnel YANG models [RFC8795] and [TE-TUNNEL], in particular, Igor | |||
| Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their | Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their | |||
| support in addressing any gap identified during the analysis work. | support in addressing any gap identified during the analysis work. | |||
| The authors would like to thank Henry Yu and Aihua Guo for their | The authors would like to thank Henry Yu and Aihua Guo for their | |||
| input and review of the URIs structures used within the JSON code | input and review of the URIs structures used within the JSON code | |||
| examples. | examples. | |||
| This work was supported in part by the European Commission funded | This work was supported in part by the European Commission funded | |||
| H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). | H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). | |||
| This document was prepared using kramdown. | This document was prepared using kramdown. | |||
| Previous versions of this document was prepared using 2-Word- | Previous versions of this document was prepared using 2-Word- | |||
| v2.0.template.dot. | v2.0.template.dot. | |||
| Additional Authors' Addresses | Contributors | |||
| Yang Zhao | Yang Zhao | |||
| China Mobile | China Mobile | |||
| Email: zhaoyangyjy@chinamobile.com | Email: zhaoyangyjy@chinamobile.com | |||
| Sergio Belotti | Sergio Belotti | |||
| Nokia | Nokia | |||
| Email: sergio.belotti@nokia.com | Email: sergio.belotti@nokia.com | |||
| Gianmarco Bruno | Gianmarco Bruno | |||
| Ericsson | Ericsson | |||
| Email: gianmarco.bruno@ericsson.com | Email: gianmarco.bruno@ericsson.com | |||
| Young Lee | Young Lee | |||
| Sung Kyun Kwan University | Sung Kyun Kwan University | |||
| Email: younglee.tx@gmail.com | Email: younglee.tx@gmail.com | |||
| Victor Lopez | Victor Lopez | |||
| Nokia | Nokia | |||
| Email: victor.lopez@nokia.com | Email: victor.lopez@nokia.com | |||
| Carlo Perocchio | Carlo Perocchio | |||
| Ericsson | Ericsson | |||
| Email: carlo.perocchio@ericsson.com | Email: carlo.perocchio@ericsson.com | |||
| Ricard Vilalta | Ricard Vilalta | |||
| CTTC | CTTC | |||
| Email: ricard.vilalta@cttc.es | Email: ricard.vilalta@cttc.es | |||
| Michael Scharf | Michael Scharf | |||
| Hochschule Esslingen - University of Applied Sciences | Hochschule Esslingen - University of Applied Sciences | |||
| Email: michael.scharf@hs-esslingen.de | Email: michael.scharf@hs-esslingen.de | |||
| Dieter Beller | Dieter Beller | |||
| Nokia | Nokia | |||
| Email: dieter.beller@nokia.com | Email: dieter.beller@nokia.com | |||
| Authors' Addresses | Authors' Addresses | |||
| Italo Busi (editor) | Italo Busi (editor) | |||
| Huawei | Huawei | |||
| Email: italo.busi@huawei.com | Email: italo.busi@huawei.com | |||
| Daniel King (editor) | Daniel King (editor) | |||
| Old Dog Consulting | Old Dog Consulting | |||
| Email: daniel@olddog.co.uk | Email: daniel@olddog.co.uk | |||
| Haomian Zheng (editor) | Haomian Zheng (editor) | |||
| Huawei | Huawei | |||
| Email: zhenghaomian@huawei.com | Email: zhenghaomian@huawei.com | |||
| Yunbin Xu (editor) | Yunbin Xu (editor) | |||
| CAICT | CAICT | |||
| Email: xuyunbin@ritt.cn | Email: xuyunbin@ritt.cn | |||
| End of changes. 432 change blocks. | ||||
| 934 lines changed or deleted | 1018 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||