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

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/