Use cases with Requirements for Packet Optical Integration (POI) Under ACTN Framework
draft-poidt-ccamp-actn-poi-pluggable-usecases-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Oscar Gonzalez de Dios , Edward James Echeverry , Reza Rokui , Nigel Davis , Bhavit Vadhadiya , Praveen Maheshwari , Italo Busi , Aihua Guo | ||
| Last updated | 2023-12-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-poidt-ccamp-actn-poi-pluggable-usecases-00
CCAMP Working Group O. G. de Dios
Internet-Draft E. J. Echeverry
Intended status: Informational Telefonica
Expires: 20 June 2024 R. Rokui
N. Davis
Ciena
B. Vadhadiya
Vi
P. Maheshwari
Airtel
I. Busi
Huawei Technologies
A. Guo
Futurewei Technologies
18 December 2023
Use cases with Requirements for Packet Optical Integration (POI) Under
ACTN Framework
draft-poidt-ccamp-actn-poi-pluggable-usecases-00
Abstract
This document provides general overarching guidelines for control and
management of packet over optical converged networks and focuses on
operators' use cases with requirements and network topologies. It
provides a set of use cases and requirements which are needed to
achieve full automation for control and management of the packet over
optical networks which comprise devices with mixes of packet and
optical functions where the optical functions may be provided on
coherent pluggables.
It is intended that other IETF drafts in this area reference this
draft and abide by the use cases and requirements in this draft.
The realization of these use cases is out of scope of this draft and
shall be covered in other IETF drafts.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://example.com/LATEST. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-poidt-ccamp-actn-
poi-pluggable-usecases/.
de Dios, et al. Expires 20 June 2024 [Page 1]
Internet-Draft POI Requirements December 2023
Discussion of this document takes place on the WG Working Group
mailing list (mailto:WG@example.com), which is archived at
https://example.com/WG.
Source for this draft and an issue tracker can be found at
https://github.com/USER/REPO.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 June 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Packet over Optical Converged Network Context . . . . . . . . 6
3.1. Traditional Architecture Deployment Model . . . . . . . . 7
3.2. Deployment Model with Coherent Pluggables . . . . . . . . 8
4. Converged Packet Over Optical Networks . . . . . . . . . . . 10
4.1. Logical view of control of converged packet optical
networks . . . . . . . . . . . . . . . . . . . . . . . . 10
de Dios, et al. Expires 20 June 2024 [Page 2]
Internet-Draft POI Requirements December 2023
4.2. Logical view of a converged device . . . . . . . . . . . 12
4.3. End-to-end optical network . . . . . . . . . . . . . . . 14
4.4. Complexity of optical network operation . . . . . . . . . 15
4.5. Converged packet optical network operation . . . . . . . 15
4.6. Commissioning of coherent plugs . . . . . . . . . . . . . 16
4.7. Generalized optical control . . . . . . . . . . . . . . . 16
5. Network Topologies . . . . . . . . . . . . . . . . . . . . . 16
5.1. Topo1 - Network topology with dedicated direct fiber . . 17
5.2. Topo2 - Network topology with shared direct fiber
network . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Topo3 - Network topology with shared switched fiber
network . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Topo4 - Network topology with shared resilient fiber
network . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.5. Topo5 - Network topology with symmetric plug and
xPonder . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6. Topo6 - Other Network Topologies . . . . . . . . . . . . 20
6. Operators' Use cases with Requirements for Automation of Packet
over Optical Converged Networks . . . . . . . . . . . . . 21
6.1. UC1: Infrastructure Discovery and Visualization of Packet
Optical Network . . . . . . . . . . . . . . . . . . . . 22
6.2. UC2: Inventory of packet optical network
infrastructure . . . . . . . . . . . . . . . . . . . . . 23
6.3. UC3: Monitoring of packet optical network
infrastructure:: . . . . . . . . . . . . . . . . . . . . 24
6.4. UC4: Optimization of packet optical network
infrastructure . . . . . . . . . . . . . . . . . . . . . 24
6.5. UC5: Optical service provisioning for creation of packet
infrastructure . . . . . . . . . . . . . . . . . . . . . 25
6.6. UC6: Provisioning of an end-to-end packet service . . . . 25
6.7. UC7 - Multi-layer visualization . . . . . . . . . . . . . 27
6.8. UC8 - Multi-layer assurance and troubleshooting across
packet and optical layers . . . . . . . . . . . . . . . 27
6.9. UC9 - Multi-layer optimization . . . . . . . . . . . . . 27
6.10. UC10 - Multi-layer pro-active maintenance and control
coordination . . . . . . . . . . . . . . . . . . . . . . 27
6.11. UC11 - Optical service pre-deployment assessment for IP
link creation . . . . . . . . . . . . . . . . . . . . . 29
6.12. UC12 - Restoration/protection of optical services . . . . 29
6.13. UC13 - Adaptive and dynamic routing Schemes protection for
IP services . . . . . . . . . . . . . . . . . . . . . . 30
6.14. UC14 - Other Requirements applicable to all use case . . 30
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . 32
de Dios, et al. Expires 20 June 2024 [Page 3]
Internet-Draft POI Requirements December 2023
Appendix A. Details of Operators' Requirements for Automation of
Packet over Optical Converged Networks . . . . . . . . . 32
A.1. R1: Support for "Coherent Plug Discovery" . . . . . . . . 33
A.2. R2: Support for "Network Discovery" . . . . . . . . . . . 34
A.3. R3: Support for "Network Visibility" . . . . . . . . . . 35
A.4. R4: Support for "Coherent Plug telemetry data" . . . . . 35
A.5. R5: Support for alarms telemetry across packet and optical
layers . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.6. R6: Support for PM telemetry across packet and optical
layers . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.7. R7: End-to-end provisioning and deletion of optical
services . . . . . . . . . . . . . . . . . . . . . . . . 36
A.8. R8: End-to-end provisioning and deletion of packet
services . . . . . . . . . . . . . . . . . . . . . . . . 36
A.9. R9: Multi-layer assurance across both packet and optical
layers . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.10. R10: Support operators' realization practices . . . . . . 38
A.11. R11: LAG extension . . . . . . . . . . . . . . . . . . . 38
A.12. R12: Optical path restoration / protection . . . . . . . 38
A.13. R13: Multi-layer control and maintenance operations . . . 39
A.14. R14: "Single functional entity" responsible for optical
services life cycle management . . . . . . . . . . . . . 39
A.15. R15: Support for operators' operational practices . . . . 40
A.16. R16: Support for multi-layer operational benefits . . . . 40
A.17. R17: Support for "greenfield" and "brownfield"
networks . . . . . . . . . . . . . . . . . . . . . . . . 41
A.18. R18: Optional higher level controller . . . . . . . . . . 41
A.19. R19: Support of both plugs and Transponders/Muxponders
(inc. Regens) . . . . . . . . . . . . . . . . . . . . . 41
A.20. R20: Various existing YANG Data Models shall be
accommodated . . . . . . . . . . . . . . . . . . . . . . 41
A.21. R21: Clear demarcation for holistic control of optical
network . . . . . . . . . . . . . . . . . . . . . . . . 41
A.22. R22: Support for urgent optical control actions . . . . . 42
A.23. R23: Minimize fragmentation of optical parameter
provisioning . . . . . . . . . . . . . . . . . . . . . . 42
A.24. R24: Direct path to relevant controller . . . . . . . . . 42
A.25. R25: Evolution to expected future controller deployment
approaches . . . . . . . . . . . . . . . . . . . . . . . 42
A.26. R26: Evolution to future packet processing deployment
approaches . . . . . . . . . . . . . . . . . . . . . . . 43
A.27. R27: Support for extensible control architecture . . . . 43
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
de Dios, et al. Expires 20 June 2024 [Page 4]
Internet-Draft POI Requirements December 2023
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT"
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
document are to be interpreted as described in [RFC2119].
The following terms abbreviations are used in this document:
* Coherent plug/pluggable: A small form factor coherent optical
module
* O-PNC: The control functions specializing in management/control of
optical and photonic functions (virtual or physical). See
[actn-rfc]
* P-PNC: The control functions specializing in management/control of
packet functions (virtual or physical). See [actn-rfc]
* xPonder: Short for Transponder and/or Muxponder
2. Introduction
Packet traffic has been transferred over optical networks for many
years blending the benefits of optical transmission and switching
with packet switching. Optical systems have been separated from
packet systems, both of which have had specific dedicated devices.
In many existing network deployments, the packet and the optical
networks are engineered, operated and controlled independently. The
operation of these packet and optical networks is often siloed which
results in non-optimal and inefficient networking. Both packet and
optical systems have had relatively independent evolution. Optical
systems have been developed with increasing capacity especially with
the emergence of coherent optical techniques.
Optical component design has continued to improve density to the
point where a whole coherent optical terminal system that use to
require many circuit packs can now fit onto a single small form
factor "coherent plug". Placing coherent plugs in a device with
packet functions can reduce network cost, power consumption and
footprint as well as improve data transfer rates, reduce latency and
expand capacity (note that in some cases, other engineering and
deployment considerations still lead to separate packet and optical
solutions).
de Dios, et al. Expires 20 June 2024 [Page 5]
Internet-Draft POI Requirements December 2023
Optical transmission/switching is analogue and requires complex and
holistic control. Consequently, coordination of control of the
coherent plugs (in a device with packet functions) with the control
of the rest of the optical network is highly desirable as this best
enables robust network functionality and simplifies network
operations.
The combination of these above trends along with the desire to select
best in breed components has led to the emergence of open optical
plugs that offer a standard bus for traffic and that use CMIS
[OIF-CMIS] between coherent pluggables and host device. These plugs
are such that a plug from vendor X can be installed in vendor Y's
device with packet functions etc.
An architecture analysis has been carried out by the MANTRA sub-group
in the OOPT / TIP group (Open Optical & Packet Transport / Telecom
Infra Project)
[MANTRA-whitepaper-IPoWDM-convergent-SDN-architecture].
This document provides guidellines for control and management of
packet over optical converged networks and it is divided into
following sections:
* Section 3 Packet over optical converged network context
* Section 4 Converged packet over optical networks
* Section 5 Network Topologies
* Section 6 Operators' Use cases with Requirements for Automation of
Packet over Optical Converged Networks
3. Packet over Optical Converged Network Context
A packet over optical network represents an efficient paradigm that
harnesses the power of both packet-switching and optical
technologies. In this approach, the overlay IP or MPLS packets are
transmitted through an underlying optical network. The fusion of
packet and optical networks offer a host of advantages, including
accelerated data transfer rates, diminished latency, and expanded
network capacity.
In general, two deployment models can be used to deploy the packet
over optical networks:
* Traditional architecture deployment model
* Deployment model with coherent pluggables
de Dios, et al. Expires 20 June 2024 [Page 6]
Internet-Draft POI Requirements December 2023
3.1. Traditional Architecture Deployment Model
The traditional architecture involves separation of the packet
network from the optical network as shown in Figure 1. In
traditional approach, the packet layer responsible for routing and
forwarding is decoupled from the underlying optical transport layer.
This approach offers several benefits, including the ability to scale
each layer independently, optimize resource utilization, and simplify
network management through centralized software control.
Disaggregation enables network operators to choose best-of-breed
components for each layer, fostering innovation and competition in
the networking industry. However, implementing and managing a
disaggregated network also comes with challenges related to
interoperability, integration, and maintaining end-to-end performance
across the various layers.
|----------| |----------|
| Packet | IP Link | Packet |
| Device |===================================| Device |
| 1 |\ /| 2 |
|----------| \ Grey / |----------|
\ Optics /
| |
............ | ......................... | ............
. | | .
. |---------| |-----------| |---------| .
. | xPonder |-----| Photonics |-----| xPonder | .
. |---------| |-----------| |---------| .
.......................................................
Optical Network = Photonics + xPonder
Legend:
==== IP Link
---- Optical fibers
++++ Coherent pluggables
xPonder: Muxponder or transponder
Photonics: ROADM + Amp + Regen
Figure 1: Packet over Optics Traditional Architecture Deployment
Model
de Dios, et al. Expires 20 June 2024 [Page 7]
Internet-Draft POI Requirements December 2023
3.2. Deployment Model with Coherent Pluggables
The second approach is to take advantage of the small implementation
footprint of the xPonder functions and to deploy these functions on a
single small form factor plug (aka Coherent pluggables) and then
place plugs directly into the packet devices as shown in Figure 2(A).
Placing this small form factor pluggable in a device with packet
functions can reduce network cost, power consumption and footprint
(when these benefits are not outweighed by other engineering
considerations). Depending on the application, distance between
packet devices, quality of fibers and so on it might be that there is
no need for a ROADM network, i.e., direct connectivity between packet
devices via plugs is possible.
By incorporating coherent plugs into routers, network operators can
achieve higher data rates, greater spectral efficiency, and improved
tolerance to optical impairments. This is especially valuable in
scenarios where traditional electronic signaling might encounter
limitations. Coherent plugs enable routers to leverage advanced
modulation schemes, digital signal processing, and error correction
techniques, enhancing their ability to handle complex optical
signals.
One of the key advantages of using coherent plugs in routers is the
potential to bridge the gap between long-haul and metro networks,
providing a seamless and efficient transition of data across various
network segments. This technology can contribute to the evolution of
high-speed data centers, interconnection between data centers, and
the overall growth of data-intensive applications.
as noted above, for some use-cases when the distance between packet
devices is short and optical power of pluggables are enough, the
photonics devices might not be needed as shown in Figure 2(B).
de Dios, et al. Expires 20 June 2024 [Page 8]
Internet-Draft POI Requirements December 2023
|-----------| |-----------|
| Packet | IP Link | Packet |
| Device +++++ ======================= +++++ Device |
| 1 |\ /| 2 |
|-----------| \ / |-----------|
\ DWDM Optics /
| |
| |-----------| |
|-----| Photonics |-----|
|-----------|
(A)
|-----------| |-----------|
| Packet | IP Link | Packet |
| Device +++++ ======================= +++++ Device |
| 1 |\ /| 2 |
|-----------| \ / |-----------|
| |
|-------------------------|
(B)
Legend:
==== IP Link
---- Optical fibers
++++ Coherent pluggables
xPonder: Muxponder or transponder
Photonics: ROADM + Amp + Regen
Optical Network: Photonics + pluggables
Figure 2: Packet over Optics Deployment Model with Coherent Plugs
In reality, the operators' packet over optical networks will most
likely be a combination of networks shown in Figure 1 and Figure 2
where the optical network contains both coherent pluggables and
xPonders as shown in Figure 3.
de Dios, et al. Expires 20 June 2024 [Page 9]
Internet-Draft POI Requirements December 2023
|-----------| |-----------|
| Packet | IP Link | Packet |
| Device +++++ =========================== +++++ Device |
| 1 |\ /| 2 |
|-----------| \ / |-----------|
\----------| |------------/
| |
|---------| |-----------| |---------|
| | | | | |
| xPonder |-----| Photonics |------| xPonder |
| | | | | |
|---------| |-----------| |---------|
| |
| |
|----------| / \ |----------|
| Packet |/ IP Link \| Packet |
| Device |====================================| Device |
| 3 | | 4 |
|----------| |----------|
Optical Network: Photonics + pluggables + xPonder
Legend:
==== IP Link
---- Optical fibers
++++ Coherent pluggables
xPonder: Muxponder or transponder
Photonics: ROADM + Amp + Regen
Figure 3: Packet over Optics Deployment Model with Coherent Plugs
and xPonders
4. Converged Packet Over Optical Networks
This section provides an overview of converged packet-optical
networks from various perspectives.
4.1. Logical view of control of converged packet optical networks
Figure 1 and Figure 2 represent two deployment models which can be
used to deploy the packet over optical networks. In reality the
operators' networks are mix of both deployments, i.e., operators will
have a packet over optical network which contains packet devices,
coherent pluggables, muxponders/transponders and photonics such as
ROADMs.
de Dios, et al. Expires 20 June 2024 [Page 10]
Internet-Draft POI Requirements December 2023
The high level control and management of such packet over optical
converged network is shown in Figure 4 where the "PACKET OPTICAL
NETWORK" contains any combination of devices with any mix of packet
functions and optical functions. These networks might include
coherent pluggables, muxponders/transponders and ROADMs.
As shown in Figure 4, the "PACKET AND OPTICAL CONTROLLERS" layer may
contain one or more packet and optical control functions which manage
and control the life cycle of end to end packet and optical services
including planning, fulfilment, assurance, optimization and
restoration.
Depends on operators' use-cases which should be supported by packet
over optical converged network, there might be a " HIGHER LAYER
CONTROLLER" (i.e., higher layer multi-layer Orchestrator or multi-
layer proxy).
Realization of this functional architecture is proposed by various
SDOs. For example, an architecture analysis has already been carried
out by the MANTRA sub-group in the OOPT / TIP group (Open Optical &
Packet Transport / Telecom Infra Project)
[MANTRA-whitepaper-IPoWDM-convergent-SDN-architecture].
Section 5 covers the requirements of these controllers to achieve
full automation in packet over optical converged networks.
de Dios, et al. Expires 20 June 2024 [Page 11]
Internet-Draft POI Requirements December 2023
|-----------------------------|
| HIGHER LAYER CONTROLLER |
| (MDSC) |
|-----------------------------|
^
|
v
|-------------------------------------|
| P-PNC & O-PNC |
| |
| |-------------| |-------------| |
| | Packet | & | Optical | |
| | Control | | Control | |
| | Functions | | Functions | |
| |-------------| |-------------| |
|-------------------------------------|
^
|
v
/----------------------------------\
/ PACKET OPTICAL NETWORK \
/ \
\ Packet and Optical Functions /
\ in various devices /
\----------------------------------/
Figure 4: Overall Control and Management of Packet over Optical
Converged Networks
4.2. Logical view of a converged device
All devices are essentially multi-technology, i.e., they support
multiple transport and signaling technologies. However, due to
implementation limitations and network deployment traditions, there
has been a strong division between devices that have sophisticated
optical functionality (with very limited packet capabilities) and
devices with sophisticated packet functionality (with very limited
optical capability). This division is dematerializing with the
emergence of devices that support both sophisticated packet and
sophisticated optical functionality (were both packet and optical can
be considered in themselves a multi-technology).
de Dios, et al. Expires 20 June 2024 [Page 12]
Internet-Draft POI Requirements December 2023
To enable necessary flexibility of deployment, the optical
capabilities are often made available on a coherent plug that can be
inserted into a host device. In this document the host device is one
with primarily packet functions. A coherent plug can also be used in
a device with primarily optical functions, with primarily storage
functions, with primarily wireless functions etc., where similar
considerations apply.
The coherent plug includes both the optical functions that provide
the transport and their control functions. It is necessary to access
the control data related to the coherent plug via interfaces on the
host devices. The combination of the host device and the coherent
plug can be considered as a packet-optical device.
The functions provided by the coherent plug include the line
termination functions of a traditional optical transponder. The
insertion of these functions into the host device removes the need
for grey optics between the host device and a transponder.
As depicted in Figure 5, in the packet-optical device there is a
clear demarcation between the functions and data that relate to
packet control and the functions and data that relate to optical
control where the boundary between packet functionality and optical
functionality is at the boundary between the plug and the host
device.
de Dios, et al. Expires 20 June 2024 [Page 13]
Internet-Draft POI Requirements December 2023
^
|
v
+-----------------------------------+
| |-----------| |----------| |
| | Packet | | Coherent | |
| | Function | | Plug | |
| | Control | | Control | |
| | Data | | Data | |
| |-----------| |----------| |
| . . |
| |-------------| . | ^
| |Packet | . | |
| |Control | . | v
| |-------------| . | +----------------+
| . . | | |
| |-------------| |----------| | |
| |Packet |<------->| Coherent |======| ROADM |
| |Function | | Plug | | |
| |-------------| |----------| | |
| | | |
+----------------------------------+ +----------------+
PACKET DEVICE with Plugs OPTICAL DEVICE
Figure 5: Packet device which contains coherent pluggables
4.3. End-to-end optical network
It is best to consider any network technology/protocol/application
from end to end. Each network technology provides infrastructure for
an overlay technology which may be another network technology or to
an actual application (storage, compute, etc.), i.e., it provides a
"link" with capacity etc. Considering the converged packet-optical
solution, the optical technologies provide infrastructure to the
packet technologies.
The optical network includes all functions that process optical
technologies and hence include functions on devices such as a ROADM,
an optical amplifier, a transponder and the functions on the coherent
plug. The boundary of the optical technologies is at the boundary
between the coherent plug and the host device.
Optical networks complexity depends upon transmission distance, need
for flexibility in the photonic layer and need for photonic
resilience.
de Dios, et al. Expires 20 June 2024 [Page 14]
Internet-Draft POI Requirements December 2023
4.4. Complexity of optical network operation
The operation of a network of coherent optical devices can be very
complex requiring careful consideration of various analogue
properties of the optical devices, of passive components and of the
current usage of the optical network. This complexity leads to the
need for a set of specialist optical control functions that have
traditionally been provided as part of an Optical Domain Controller
(similar to the need for specialist IP control functions).
4.5. Converged packet optical network operation
In a converged network it is necessary to combine the specialist
control functions for the packet network functions and specialist
control functions for optical network functions. There are various
potential solutions for this combining. In this document, it is
assumed that a higher layer controller will provide the solution
focusing on converged visualization, optimization, assurance etc.
It is important to recognize that in any real network deployment
there will be a mix of converged solutions and traditional solutions
where there will probably be a gradual evolution away from
traditional forms to converged forms. It will be necessary for any
control solution to deal with the mix and its evolution.
In all cases, it is necessary to evaluate options to determine the
best optical network solution (see [ITU-T_G.sup39] for engineering
considerations). Hence, in a network where there are various
solutions, even for situations where a basic direct grey interconnect
turns out to be the right configuration, it is necessary to analyze
the network in detail to determine this. Hence, it is necessary to
involve the optical control functions in all decisions about optical
network configuration.
For some restoration cases there is a need for near real time optical
configuration. The pluggable settings may need to be adjusted during
restoration control actions. For example, it is possible that
regeneration may be identified as required during a restoration
activity and that as a result of this or other considerations,
optical parameter changes, including wavelength and power may need to
be applied to a pluggable during normal operation.
de Dios, et al. Expires 20 June 2024 [Page 15]
Internet-Draft POI Requirements December 2023
4.6. Commissioning of coherent plugs
Commissioning of more capable, and hence expensive, coherent plugs in
routers tends to follow a just-in-time deployment pattern where the
pluggables are not installed in the host device until they are
required for service. The pluggables used in more challenging
applications require sophisticated photonic viability assessment.
The specialist photonic viability tools reside in the optical control
function set.
Where there is a need to install a new pluggable, the process will
operate in a relatively slow time frame. Once the pluggables are
detected by the optical controller the parameters of the pluggables
can be configured and progress through any necessary validation
testing on the optical network. This testing may involve the need to
control the pluggables optical parameters along with parameters of
other devices supporting the optical/photonic signals.
4.7. Generalized optical control
Industry is progressing towards generalized optical viability
functions but currently, these functions tend to be vendor specific
and reside in the vendor controllers. Current deployments tend to
have a generalized optical controller from a particular optical
device vendor controlling other vendor optical controllers. Where
optical control is discussed in this document, it is assumed to be
the collection of all optical control capabilities including whatever
assembly of vendor controllers and generalized controllers are
present.
Note that it is the expectation that a single optical controller will
provide the control functionality of all coherent plugs in a specific
host device regardless of the mix of plugs from different vendors.
5. Network Topologies
This section provides a set of packet over optical network topologies
starting with the most basic and progressing to the most complex. It
is expect that a network will evolve to a mix of many of the
structure identified in each of the following sections.
All the packet over optical use cases outlined in Section 7 will be
applicable to any on these network topologies.
de Dios, et al. Expires 20 June 2024 [Page 16]
Internet-Draft POI Requirements December 2023
5.1. Topo1 - Network topology with dedicated direct fiber
As depicted in Figure 6, this scenario considers a point-to-point
optical service over a short distance (e.g., up to 100 km) using
dedicated fiber. ([pluggables-operators-requirements], Page 4,
"Dedicated point to point connection Metro areas").
Note that there is no amplification and no protection in this
scenario.
Packet Packet
Device A Device B
+----+ IP Link (between Router Ports) +----+
| |.............................................................| |
| | | |
| | Optical Service (Plug-to-Plug) | |
| | ..................................................... | |
| |------| |------| |
| | | | | |
| |Plug A|===================================================|Plug B| |
| | | | | |
| |------| |------| |
| | | |
+----+ +----+
Figure 6: Network topology with dedicated direct fiber
5.2. Topo2 - Network topology with shared direct fiber network
This scenario extends Figure 6 by making more efficient use of the
fiber infrastructure.
As shown in Figure 7, this scenario considers a point-to-point
optical service over a short distance (e.g., up to 100 km) using a
physical optical network with DWDM filters and amplifiers.
([pluggables-operators-requirements], Page 4, "Dedicated point to
point connection Metro areas").
Note that there is no protection in this scenario.
de Dios, et al. Expires 20 June 2024 [Page 17]
Internet-Draft POI Requirements December 2023
Packet Packet
Device A Device B
+----+ IP Link (between Router Ports) +----+
| |.............................................................| |
| | | |
| | Optical Service (Plug-to-Plug) | |
| | ..................................................... | |
| |------| |------| |
| | | |-------| |-------| |-------| | | |
| |Plug A|======| Filter|======| AMP |======| Filter|======|Plug B| |
| | | ||==| | | | | |==|| | | |
| |------| || |-------| |-------| |-------| || |------| |
| | || || | |
+----+ || || +----+
|| ||
|------| || || |------|
| |==|| ||==| |
|Plug C| |Plug D|
| | | |
|------| |------|
Figure 7: Network topology with shared direct fiber network
5.3. Topo3 - Network topology with shared switched fiber network
This scenario extends Figure 7 by making more flexible use of the
fiber infrastructure.
As shown in Figure 8, this scenario considers a point-to-point
optical service over longer distance (e.g., up to 500 km) using a
flexible physical optical network with DWDM filters, amplifiers and
optical switching. ([pluggables-operators-requirements], Page 4,
"Point to point connection over metro/regional areas").
Note that there is no resilience in this scenario.
de Dios, et al. Expires 20 June 2024 [Page 18]
Internet-Draft POI Requirements December 2023
Packet Packet
Device A Device B
+----+ IP Link (between Router Ports) +----+
| |.............................................................| |
| | | |
| | Optical Service (Plug-to-Plug) | |
| | ..................................................... | |
| |------| |------| |
| | | |-------| |-------| |-------| | | |
| |Plug A|======| ROADM |======| ROADM |======| ROADM |======|Plug B| |
| | | | + Amp | | | | + Amp | | | |
| |------| |-------| |-------| |-------| |------| |
| | | |
+----+ +----+
Figure 8: Network topology with shared switched fiber network
5.4. Topo4 - Network topology with shared resilient fiber network
This scenario adds optical resiliency to the fiber infrastructure and
is applicable to both topologies shown in Figure 7 and Figure 8.
As shown in Figure 9, optical resiliency is achieved by providing
alternative path through the optical network. This may be achieved
by some combinations of restoration and protection. This scenario is
applicable to Figure 7 and Figure 8 and restoration additionally is
applicable to Figure 8.
Packet Packet
Device A Device B
+----+ IP Link (between Router Ports) +----+
| |..............................................................| |
| | | |
| | Optical Service (Plug-to-Plug) | |
| | ..................................................... | |
| |------| |----------------------| |------| |
| | | |-------| //| Photonics |\\ |-------| | | |
| |Plug A|==| OPS |// |----------------------| \\| OPS |==|Plug B| |
| | | | |\\ //| | | | |
| |------| |-------| \\|----------------------|// |-------| |------| |
| | | Photonics | | |
+----+ |----------------------| +----+
Legend:
OPS: Optical Protection Switch
Figure 9: Network topology with shared resilient fiber network
de Dios, et al. Expires 20 June 2024 [Page 19]
Internet-Draft POI Requirements December 2023
5.5. Topo5 - Network topology with symmetric plug and xPonder
This scenario shown in Figure 10 and extends network topologies
Figure 6 to Figure 9 where one end of an optical service is
terminated on a plug and the other end is terminated on a traditional
xPonder (transponder or muxponder) potentially with grey optics to a
packet device.
Packet Packet
Device A Device B
+----+ IP Link (between Router Ports) +----+
| |.............................................................| |
| | | |
| | Optical Service (Plug-to-xPonder) |-------| | |
| | ...................................| | | |
| |------| | | | |
| | | |-----------------------| | | Grey Optics | |
| |Plug A|====| Photonics |=====|xPonder|=============| |
| | | |-----------------------| | | | |
| |------| |-------| | |
| | | |
+----+ +----+
Figure 10: Network topology with symmetric plug and transponder
5.6. Topo6 - Other Network Topologies
* Network topology with shared switched fiber network with
regenerators: This is extension of topology Topo-3 Figure 8 when
the photonic network has regenerator.
* Asymmetric interconnect Network topology where the protection open
at one end but both protection legs are terminated on separate
xPonder or coherent pluggables.
* IP Lag Network topology where the IP link between two packet
devices are provided by multiple coherent plugs
* Practical network deployments which includes the mix of many
network topologies explained above.
de Dios, et al. Expires 20 June 2024 [Page 20]
Internet-Draft POI Requirements December 2023
6. Operators' Use cases with Requirements for Automation of Packet over
Optical Converged Networks
This section provides a set of packet over optical use cases which
are applicable to any network topologies in Section 5. These use
cases in turn drives the operators' requirements needed to support
the automation of packet over optical converged networks. The use
cases and requirements in this section are a combination of
functional and operational and are agnostics to their realizations.
See Appendix (A) for details of requirements.
These use cases are grouped into two categories, packet optical
infrastructure use cases and multi-layer/end-to-end use-cases:
Packet optical infrastructure use cases:
* UC1 - Infrastructure discovery and visualization of packet optical
network: Discovery of optical and packet network topology from L0
optical services to IP links
* UC2 - Inventory of packet optical network infrastructure:
Inventory of optical and packet networks infrastructure
* UC3 - Monitoring of packet optical network infrastructure:
Monitoring of the optical and packet networks infrastructure using
the telemetry data. This is consider one of the operational use
cases.
* UC4 - Optimization of packet optical network infrastructure:
Monitor the health of packet and optical infrastructure and
perform corrective actions if needed
* UC5 - Optical service provisioning for creation of packet
infrastructure: Provisioning of optical and packet network
infrastructure from L0 optical services to IP links
Multi-layer/end-to-end use-cases:
* UC6 - Provisioning of an end-to-end packet service: Provisioning
of L2/L3 packet services
* UC7 - Multi-layer visualization: From underlay L0 optical services
to overlay L3 packet services
* UC8 - Multi-layer assurance and troubleshooting across packet and
optical layers
de Dios, et al. Expires 20 June 2024 [Page 21]
Internet-Draft POI Requirements December 2023
* UC9 - Multi-layer optimization: This is an extension of use case
UC5 where the packet services will be considered as well
* UC10 - Multi-layer pro-active maintenance and control coordination
* UC11 - Optical service pre-deployment assessment for IP link
creation
* UC12 - Restoration/protection of optical services
* UC13 - Adaptive and dynamic routing Schemes protection for IP
services
6.1. UC1: Infrastructure Discovery and Visualization of Packet Optical
Network
The use case provides the discovery of packet over optical network
which is considered the multi-layer network infrastructure. It
includes:
* Discovery of optical physical network (e.g., equipments including
optical nodes and coherent plugs)
* Discovery of optical topology (i.e., adjacencies and links)
* Discovery of L0 optical services
* Discovery of packet physical network (e.g., equipments including
packet nodes)
* Discovery of packet topology (i.e., adjacencies and IP links)
* Discovery of "interdomain transitional links", i.e., links which
connect the optical network to and packet network
Using this information, the solution can discover the multi-layer
packet over optical network by correlating the IP links to L0 optical
services. Note that the mapping between IP links and optical
services might be 1:1, 1:many or many:1. As shown in Figure 11,
multi-layer network discovery provides the correlation between
various layers from optical services to packet network up to IP link.
de Dios, et al. Expires 20 June 2024 [Page 22]
Internet-Draft POI Requirements December 2023
<-- IP link between packet devices --->
<----- L2 Ethernet Service ---->
<---- Optical Service ---->
<--- Optical Fiber --->
|-----------| |-----------|
| Packet | IP Link | Packet |
| Device +++++ ========================== +++++ Device |
| 1 |\ /| 2 |
|-----------| \ Transitional / |-----------|
\ Link /
| |-----------| |
|-------| Photonics |------|
|-----------|
Figure 11: Multi-layer Network Discovery
Requirements driven by this use case:
* R1: Support for "Coherent Plug Discovery": The solution shall
allow the controller to discover the coherent plug state and to
configure the coherent plug operation. See
[draft-davis-ccamp-photonic-plug-control-arch-02]].
* R2: Support for "Network Discovery": The solution shall provide
the multi-layer "Network infrastructure Discovery"
([pluggables-operators-requirements], Page 5 requirement 1).
* R3: Support for "Network Visibility": The solution shall provide
the end-to-end multi-layer "Network Visibility and Visualization"
([pluggables-operators-requirements], Page 5 requirement 1).
* R15: Support for operators' operational practices: The solution
shall support existing operators' operational practices on packet
and optical network and services. See
[draft-davis-ccamp-photonic-plug-control-arch-02]. Please note
that this requirement is applicable to all use cases.
6.2. UC2: Inventory of packet optical network infrastructure
The discovery process provides inventory for network shown in
Figure 11.
de Dios, et al. Expires 20 June 2024 [Page 23]
Internet-Draft POI Requirements December 2023
6.3. UC3: Monitoring of packet optical network infrastructure::
This use cases covers the real-time collection of "Alarm Event
Notification" and "Performance Monitoring (PM)" telemetry data from
packet over optical network shown in Figure 11. In other words, by
collecting the telemetry data from following network objects, the
solution should be able to delete any deterioration to packet optical
network infrastructure.
* Optical physical network (e.g., equipments including optical nodes
and coherent plugs)
* optical topology (i.e., adjacencies and links)
* Optical services
* Packet physical network (e.g., equipments including packet nodes)
* Packet topology (i.e., adjacencies and IP links)
* Interdomain transitional links (i.e., links which connect the
optical network to and packet network)
Requirements driven by this use case:
* R4: Support for "Coherent Plug telemetry data": See
[draft-davis-ccamp-photonic-plug-control-arch-02]
* R5: Support for alarms telemetry across packet and optical layers:
his requirement mandates the real-time collection of "Alarm Event
Notification" telemetry data from both packet and optical layers
([pluggables-operators-requirements], Page 5 requirements 1 and
6).
* R6: Support for PM telemetry across packet and optical layers:
This requirement mandates the real-time collection of performance
Monitoring (PM) data from both packet and optical layers
([pluggables-operators-requirements], Page 5 requirements 1 and
6).
6.4. UC4: Optimization of packet optical network infrastructure
This use case employs the telemetry data collected from packet
optical network in use case UC3 to monitor the health of packet and
optical infrastructure and performing the corrective actions if
needed.
de Dios, et al. Expires 20 June 2024 [Page 24]
Internet-Draft POI Requirements December 2023
6.5. UC5: Optical service provisioning for creation of packet
infrastructure
Referring to Figure 11, this use-case provides the provisioning of
new optical services and new packet infrastructure (i.e., IP links).
In other words, this use case addresses the provisioning of new
optical services from plug-to-plug and mapping them to new IP links.
This use case covers situations when the IP network needs more
capacity which in turn means one or more new optical services need to
be provisioned. An optical service provides underly infrastructure
and hence provides capacity to the IP layer.
This use case involves the following steps:
* Determine the need for new IP capacity
* Identify where that capacity is needed and identify candidate
devices to be interconnected
* Assess the optical solution and viability
* Identify the appropriate coherent plugs
* Install and configure the coherent plugs
* Provision one or more optical services between plugs
* Perform test and validation of the optical services (including
plugs)
* Make the extra capacity available to the IP network (i.e., to IP
links)
Requirements driven by this use case:
* R7: End-to-end provisioning and deletion of optical services: The
solution shall support end-to-end provisioning and deletion of
optical services ([pluggables-operators-requirements], Page 5
requirements 2 and 3).
6.6. UC6: Provisioning of an end-to-end packet service
This use-case covers the end-to-end provisioning of a packet VPN
service between two ports of packet devices which are equipped with
coherent pluggables.
de Dios, et al. Expires 20 June 2024 [Page 25]
Internet-Draft POI Requirements December 2023
As depicted in Figure 12, before provisioning the packet service
between ports A and B on packet devices 1 and 3, two optical services
OS1 and OS2 should be created first and mapped to new IP link1 and IP
link2, respectively. Then, to facilitate L2/L3 VPN services, an IP/
MPLS TE tunnel or alternative technologies such as segment routing,
FlexAlgo or SRv6 are deployed. This approach allows for a more
versatile and adaptable network configuration to meet different VPN
requirements.
<------------------- VPN Service -------------------->
<-------------- IP/MPLS TE-Tunnels -------------->
<--- IP link1 --> <-- IP link2 --->
<---- ES1 ----> <---- ES2 ---->
<--- OS1 ---> <--- OS2 --->
<-OF-><-OF-> <-OF-><-OF->
|--------| |---------| |---------|
| Packet | A | Packet | B | Packet |
| Device +++ =========== +++ Device +++ =========== +++ Device |
| 1 |\ /| 2 |\ /| 3 |
|--------| \ / |---------| \ / |---------|
\ / \ /
\-----| | | |------/
| | | |
|---------------------------------------|
| Photonics (ROADM + Amp + Regen) |
| + |
| xPonder |
|---------------------------------------|
Legend:
ES L2 Ethernet Service
OS Optical Service
OF Optical Fiber
==== IP Link
---- Optical fibers
++++ Coherent pluggables
Figure 12: End-to-end Packet Services
Requirements covered by this use case:
* R7: End-to-end provisioning and deletion of optical services: The
solution shall support end-to-end provisioning and deletion of
optical services ([pluggables-operators-requirements], Page 5
requirements 2 and 3).
de Dios, et al. Expires 20 June 2024 [Page 26]
Internet-Draft POI Requirements December 2023
* R8: End-to-end provisioning and deletion of packet services: The
solution shall support end-to-end provisioning and deletion of
packet services ([pluggables-operators-requirements], Page 5
requirements 2 and 3).
6.7. UC7 - Multi-layer visualization
Referring to multilayer packet services shown in Figure 12, this use
case addresses the visualization multi-layer services from L0 optical
services to L2/L3 packet services. Note that this use case employs
use cases UC1 and UC2 where the multi-layer packet over optical
network is already discovered and inventorized.
6.8. UC8 - Multi-layer assurance and troubleshooting across packet and
optical layers
Consider the multi-layer packet over optical network depicted in
Figure 12. This use case uses UC3 to collect the alarm notifications
and PM telemetry data from both packet optical network infrastructure
and packet optical services, correlated them together and use this
correlation during the passive or pro-active multi-layer
troubleshooting and assurance.
Requirements covered by this use case:
* R9: Multi-layer assurance across both packet and optical layers:
The solution shall support the multi-layer assurance and
troubleshooting across packet and optical layers
([pluggables-operators-requirements], Page 5 requirement 5).
6.9. UC9 - Multi-layer optimization
This use case is an extension of use case UC8 where it employs the
telemetry data collected from packet optical network in use case UC8
to monitor the health of multi-layer packet and optical
infrastructure and services and to perform any corrective actions if
needed.
6.10. UC10 - Multi-layer pro-active maintenance and control
coordination
To achieve full automation across optical and packet layers, this use
case covers the cross layer control and maintenance operations.
Since the optical and packet layers are inter-dependent, any changes
to one layer will impact the services in other layer. For example,
if an optical link is out of service for maintenance, it will impact
one or multiple IP links and packet services.
de Dios, et al. Expires 20 June 2024 [Page 27]
Internet-Draft POI Requirements December 2023
This use case provides a pro-active approach (using make-before-break
scheme) by informing the other layer before doing any changes. For
example, operator can bring an optical link to maintenance. This
causes the L0 services using that optical link to be flagged as
maintenance which causes all IP links map to L0 services to be
flagged as well. This in turn allows the packet layer to drain the
appropriate IP links, tunnels and packet services which causes
graceful maintenance operations across network.
Considering packet optical network shown in Figure 13 where operator
would like to perform maintenance on optical fiber OF2. Before doing
so, operator can put OF2 in maintenance mode. Since "VPN service 1",
"TE-tunnel 1", "IP link 1" and "Optical service 1" are all mapped to
OF2, operator can put OF2 in "maintenance mode" which causes the
packet layer to drain IP link1 and potentially re-router TE-tunnel 1.
This pro-active approach causes graceful drainage of packet traffic
before maintenance.
<------------------------- VPN service 1 ----------------------->
<----------------------- TE-tunnel 1 --------------------->
Packet Packet
Device A Device B
+----+ +----+
| |<--------------------- IP Link 1 --------------------->| |
| | <--------------- Optical Service 1 --------------> | |
| | <- OF1 -> <- OF2 -> <- OF3 -> | |
| |------| |------| |
| | | |-------| |-------| | | |
| |Plug A|=========| ROADM |=========| ROADM |=========|Plug B| |
| | | | | ^ | | | | |
| |------| |-------| | |-------| |------| |
| | | | |
+----+ Operator would like to perform +----+
maintenance on this optical fiber
Figure 13: Network topology with shared switched fiber network
Requirements covered by this use case:
* R13: Multi-layer control and maintenance operations: The solution
shall support the "Multi-layer Control and Maintenance Operations"
across packet and optical networks
([pluggables-operators-requirements], Page 5 requirement 8).
de Dios, et al. Expires 20 June 2024 [Page 28]
Internet-Draft POI Requirements December 2023
6.11. UC11 - Optical service pre-deployment assessment for IP link
creation
During creation of a new IP link and before the creation of a new
optical service, this use case covers consideration for optical
viability, i.e., it considers the processes involved in evaluating
optical viability as part of the process of design of the realization
of a connection.
Note that the combination of the following two considerations means
that it is often not possible to simply turn on an existing physical
setup to cause further link capacity to be realized.
Optical transmission is an analogue technology where success is
influenced and impacted by real physical conditions and where
determining viability is complex. Other than for the most basic
short direct optical links, it is necessary to employ optical
viability tools to identify necessary intermediate components and
define optimum optical set-up.
Optical components are relatively expensive and are often not
deployed in the network until needed. As a consequence, there is
often no simple potential link opportunity, and instead understanding
of optical interconnectability relies on knowledge of semi-abstracted
interbuilding fibering, potential plug capabilities and device with
packet functions compatibility.
Requirements covered by this use case:
6.12. UC12 - Restoration/protection of optical services
Depend on the operators' requirements for resiliency on packet and
optical networks, some operators prefer to have restoration and
protection at optical layer. This use case integrates the optical
layer protection and restoration including expected configurations,
assurance, telemetry collection, optimization and path reversion in a
uniform fashion.
If an operator deploys an optical protection scheme, the resiliency
can be achieved in sub-ms. However, if they deploy a path
restoration scheme, the resiliency will not be in sub-ms range.
Requirements covered by this use case:
* R12: Optical path restoration / protection: Optical path
restoration / protection shall be supported
([pluggables-operators-requirements], Page 5 requirement 7).
de Dios, et al. Expires 20 June 2024 [Page 29]
Internet-Draft POI Requirements December 2023
6.13. UC13 - Adaptive and dynamic routing Schemes protection for IP
services
This use case complement UC12 and involves implementing and managing
adaptive and dynamic routing protocols to protect IP services against
interruptions and provide continuous service. It highlights the
importance of having flexible routing schemes that are able to
respond quickly to changes in the network and thereby maintain
optimal network performance and service assurance.
6.14. UC14 - Other Requirements applicable to all use case
There are a set of requirements shown below which are applicable to
all use cases. See Appendix (A) for details of these requirements.
* R10: Support operators' realization practices
* R11: LAG extension
* R14: "Single functional entity" responsible for optical services
life cycle management
* R16: Support for multi-layer operational benefits
* R17: Support for "greenfield" and "brownfield" networks
* R18: Optional higher level controller
* R19: Support of both plugs and Transponders/Muxponders (inc.
Regens)
* R20: Various existing YANG Data Models shall be accommodated
* R21: Clear demarcation for holistic control of optical network
* R22: Support for urgent optical control actions
* R23: Minimize fragmentation of optical parameter provisioning
* R24: Direct path to relevant controller
* R25: Evolution to expected future controller deployment approaches
* R26: Evolution to future packet processing deployment approaches
* R27: Support for extensible control architecture
de Dios, et al. Expires 20 June 2024 [Page 30]
Internet-Draft POI Requirements December 2023
7. Conclusion
This document has provided:
* An overview of converged packet over optical networks from a
control perspective focused on the implications of the deployment
of coherent plugs in devices with packet functions
* A set of requirements for the operation of a network including
coherent plugs
* A progression of use cases covering key areas of operations
focusing on coherent plugs
* A set of network topologies which illustrate various coherent plug
applications
This document has a broad coverage to encompass all existing and
future approaches to deployment and control of photonic plugs.
With the above coverage, this document is suitable to provide an
overarching framework for other IETF works on coherent plugs
including:
* A functional architecture for control of a multi-technology
network (especially a network including coherent plugs:
* Various physical realizations of the functional architecture
* Interaction of a control solution with devices that are equipped
with coherent plugs
* Interfaces and models to be used on the devices that are equipped
with coherent plugs
It is intended that other IETF drafts in this area reference this
draft and abide by the requirements, use cases in this draft.
8. Security Considerations
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
de Dios, et al. Expires 20 June 2024 [Page 31]
Internet-Draft POI Requirements December 2023
[OIF-CMIS] "OIF Implementation Agreement (IA) Common Management
Interface Specification (CMIS))", 27 April 2022,
<https://www.oiforum.com/wp-content/uploads/OIF-CMIS-
05.2.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
10.2. Informative References
[actn-rfc] "Framework for Abstraction and Control of TE Networks
ACTN", 19 December 2018,
<https://datatracker.ietf.org/doc/rfc8453/>.
[draft-davis-ccamp-photonic-plug-control-arch-02]
"Control Architecture of Optical Pluggables in Packet
Devices Under ACTN POI Framework", 1 January 2024,
<https://datatracker.ietf.org/doc/draft-davis-ccamp-
photonic-plug-control-arch/02/>.
[ITU-T_G.sup39]
"ITU-T Recommendation G.Sup39 (02/16): Optical system
design and engineering considerations", 26 February 2016,
<https://www.itu.int/rec/T-REC-G.Sup39-201602-I/en>.
[MANTRA-whitepaper-IPoWDM-convergent-SDN-architecture]
"IPoWDM convergent SDN architecture - Motivation,
technical definition & challenges", 31 August 2022,
<https://telecominfraproject.com/wp-content/uploads/
TIP_OOPT_MANTRA_IP_over_DWDM_Whitepaper-Final-
Version3.pdf>.
[pluggables-operators-requirements]
"Operator’s Requirements to support Router Optical
pluggable interfaces", 23 November 2023,
<https://datatracker.ietf.org/meeting/118/materials/
slides-118-ccamp-07-applicability-of-actn-to-poi-
extensions-to-support-router-optical-interfaces>.
Appendix A. Details of Operators' Requirements for Automation of Packet
over Optical Converged Networks
This appendix outlines the details of operators' requirements needed
for any control architecture to support the full automation of packet
over optical converged networks.
de Dios, et al. Expires 20 June 2024 [Page 32]
Internet-Draft POI Requirements December 2023
The requirements in this appendix are driven by a combination of
operational and functional considerations and are control solution
realization-agnostics.
A.1. R1: Support for "Coherent Plug Discovery"
The host platform (e.g., packet device) shall provide full access to
all properties of the coherent plug. This allows the controller to
access all config and telemetry information available from coherent
plug. As shown in Figure 14, once the coherent plug is inserted into
host platform, it shall be recognized by host platform, which shall
allow the full access to plug config and telemetry information on
interface (A). Once the host platform has full access to plug
information, it shall in turn allow this information to be accessed
by any controller on interface (B). In other words, both interfaces
(A) and (B) shall have access to all plug config and telemetry
information.
This will allow the controller to discover the coherent plug state
and to configure the coherent plug operation. See
[draft-davis-ccamp-photonic-plug-control-arch-02]].
All standard data and all proprietary data from the coherent plug
should be made available to one or more controllers by the platform
hosting the plug. The platform hosting the plug should not attempt
to interpret the plug data prior to making it available to a
controller. A generic approach to mapping the data to the interface
model should be adopted wherever possible. The data should be made
available with no intermediate transformation by the platform hosting
the plug. All notifications should be propagated transparently (see
requirement R4).
It is recognized that some aspects of the plug, such as electrical
power consumption, will need to be understood by the host platform
control functionality. These properties should be expressed clearly
by the plug in a standard, generic and consistent fashion.
de Dios, et al. Expires 20 June 2024 [Page 33]
Internet-Draft POI Requirements December 2023
^
|
v (B)
+---------------------------------+
| |-----------| |----------| |
| | Packet | | Coherent | |
| | Function | | Plug | |
| | Data | | Data | |
| |-----------| |----------| |
| . . |
| . (A) . |
| |-----------| |----------|
| | Packet | <------> | Coherent |====
| | Function | | Plug |
| |-----------| |----------|
| |
+--------------------------------+
Host platform (e.g., packet device)
Figure 14: Plug discovery by host platform
A.2. R2: Support for "Network Discovery"
The solution shall provide the end-to-end multi-layer "Network
Discovery" ([pluggables-operators-requirements], Page 5 requirement
1). It includes:
* Discovery of optical physical network (i.e., optical nodes and
fibers)
* Discovery of optical services
* Discovery of packet network (i.e., IP links and packet devices)
* Discovery of "interdomain transitional links", i.e., links which
connect the optical network to and packet network
Using this information, the solution shall discover the multi-layer
packet over optical network, i.e., correlation between IP links and
optical services. Note that there might be a 1:1, 1:many or many:1
relationship between IP links and optical services. As shown in
Figure 15 multi-layer network discovery provides the correlation
between various layers from optical underlay to packet overlay.
de Dios, et al. Expires 20 June 2024 [Page 34]
Internet-Draft POI Requirements December 2023
<-- IP link between packet devices --->
<----- L2 Ethernet Service ---->
<---- Optical Service ---->
<--- Optical Fiber --->
|-----------| |-----------|
| Packet | IP Link | Packet |
| Device +++++ ========================== +++++ Device |
| 1 |\ /| 2 |
|-----------| \ / |-----------|
\ /
| |-----------| |
|-------| Photonics |------|
|-----------|
Figure 15: Correlation between Optical underlay and packet IP
links overlay
A.3. R3: Support for "Network Visibility"
The solution shall provide the end-to-end multi-layer "Network
Visibility and Visualization" ([pluggables-operators-requirements],
Page 5 requirement 1).
This requirement covers not only the network visualization at
individual optical or packet layers, but the network visualization
across packet and optical layers.
A.4. R4: Support for "Coherent Plug telemetry data"
The host platform (e.g., packet device) shall provide full access to
all telemetry data from the coherent plug. This data shall be
streamed to one or more client controller(s) using an appropriate
agree protocol and this data shall be provided in a timely manner.
The data streamed shall include all alarms, PM reports, PM threshold
alerts and state changes (including both dynamic state and config
state) supported by the plug. See
[draft-davis-ccamp-photonic-plug-control-arch-02]
All standard data and all proprietary data from the plug should be
made available to one or more controllers by the platform hosting the
plug. The platform hosting the plug should not attempt to interpret
the plug data prior to making it available to a controller. A
generic approach to mapping the data to the interface model should be
adopted wherever possible. The data should be made available with no
intermediate transformation by the platform hosting the plug. All
notifications should be propagated transparently (see R4).
de Dios, et al. Expires 20 June 2024 [Page 35]
Internet-Draft POI Requirements December 2023
It is recognized that some aspects of the plug, such as electrical
power consumption and other parameters, will need to be understood by
the host platform control functionality which can help the host to
identify degradation/faults in the line and take routing decisions
based on that. These properties should be expressed clearly by the
plug in a standard, generic and consistent fashion.
A.5. R5: Support for alarms telemetry across packet and optical layers
This requirement mandates the real-time collection of "Alarm Event
Notification" telemetry data from both packet and optical layers
([pluggables-operators-requirements], Page 5 requirements 1 and 6).
The solution shall provide:
* Collection of "Alarm Event Notification" for both packet and
optical layers
* Alarm correlation across packet and optical layers
A.6. R6: Support for PM telemetry across packet and optical layers
This requirement mandates the real-time collection of performance
Monitoring (PM) data from both packet and optical layers
([pluggables-operators-requirements], Page 5 requirements 1 and 6).
The solution shall provide:
* Collection of "performance Monitoring" for both packet and optical
layers
* End to end performance management KPI across packet and optical
layers
A.7. R7: End-to-end provisioning and deletion of optical services
The solution shall support end-to-end provisioning and deletion of
optical services ([pluggables-operators-requirements], Page 5
requirements 2 and 3).
A.8. R8: End-to-end provisioning and deletion of packet services
The solution shall support end-to-end provisioning and deletion of
packet services ([pluggables-operators-requirements], Page 5
requirements 2 and 3).
de Dios, et al. Expires 20 June 2024 [Page 36]
Internet-Draft POI Requirements December 2023
Figure 16 shows a typical packet VPN service between two packet
devices. It also shows the multi-layer correlation between packet
service and the underlay optical networks. In addition to
provisioning and deletion of VPN services, the solution shall also
support the multi-layer visualization of such VPN services.
<------------------- VPN Service ------------------->
<-------------- IP/MPLS TE-Tunnels ------------->
<-- IP link --> <-- IP link -->
<---- ES ----> <---- ES ---->
<--- OS ----> <---- OS --->
<-OF-> <-OF-> <-OF-> <-OF->
|--------| |---------| |---------|
| Packet | | Packet | | Packet |
| Device +++ =========== +++ Device +++ =========== +++ Device |
| 1 |\ /| 2 |\ /| 3 |
|--------| \ / |---------| \ / |---------|
\ / \ /
\-----| | | |------/
| | | |
|---------------------------------------|
| Photonics (ROADM + Amp + Regen) |
| + |
| xPonder |
|---------------------------------------|
Legend:
ES L2 Ethernet Service
OS Optical Service
OF Optical Fiber
==== IP Link
---- Optical fibers
++++ Coherent pluggables
Figure 16: End-to-end Packet Services
A.9. R9: Multi-layer assurance across both packet and optical layers
The solution shall support the multi-layer assurance and
troubleshooting across packet and optical layers
([pluggables-operators-requirements], Page 5 requirement 5).
de Dios, et al. Expires 20 June 2024 [Page 37]
Internet-Draft POI Requirements December 2023
A.10. R10: Support operators' realization practices
The solution shall support the operators' realization practices where
the functional components for control and management of packet and
optical networks might be spread across controller in packet and
optical operational centers.
In general, the industry agrees on the functional components that are
needed for converged operations: there needs to be a multi-layer
controllers that spans both the packet and optical domains in order
to synthesize data from both domains and make optimal decisions
regarding utilization of assets to deliver high-resiliency and high-
performance network services. There is however a difference between
packet and optical controllers functional components and their
realization – there are different ways service providers can choose
to deploy the multi-layer packet over optical controllers including
coherent plugs to realize a solution that works in their specific
operational environment.
There are several realization approaches including a single control
fabric where the optical and packet control functions are deployed in
the cloud or simple distinct hierarchy.
A.11. R11: LAG extension
To de added ([pluggables-operators-requirements], Page 5 requirement
6).
A.12. R12: Optical path restoration / protection
Optical path restoration / protection shall be supported
([pluggables-operators-requirements], Page 5 requirement 7).
Depend on the operators' requirements for resiliency on packet and
optical networks, some operators prefer to have restoration and
protection at optical layer. In these scenarios, to provide the end-
to-end full automation across packet and optical network, the
automation solution shall integrate the optical layer protection and
restoration including expected configurations, assurance, telemetry
collection, optimization and path reversion in a uniform fashion.
If an operator deploys an optical protection scheme, the resiliency
can be achieved in sub-ms. However, if they deploy a path
restoration scheme, the resiliency will not be in sub-ms range.
de Dios, et al. Expires 20 June 2024 [Page 38]
Internet-Draft POI Requirements December 2023
A.13. R13: Multi-layer control and maintenance operations
The solution shall support the "Multi-layer Control and Maintenance
Operations" across packet and optical networks
([pluggables-operators-requirements], Page 5 requirement 8).
To achieve full automation across optical and packet layers, the
solution shall support the cross layer control and maintenance
operations. In these cases, since the packet and optical layers are
inter-dependent (see Requirements R1 above), modifying one layer will
impact the services in other layer. For example, if an optical link
is disconnected for maintenance, it will impact multiple IP links and
packet services. In these cases, the solution shall provide a pro-
active approach (using make-before-break scheme) by informing the
other layer. This allows the client layers to drain the appropriate
IP links, tunnels and packet services and allows graceful maintenance
operations across network.
A.14. R14: "Single functional entity" responsible for optical services
life cycle management
There shall be a "single functional entity" responsible for optical
services life cycle management. The following aspects of optical
service life cycle shall be managed and controlled by a single
functional entity in the network. See
[draft-davis-ccamp-photonic-plug-control-arch-02].
* Discovery of Optical network functions including coherent
pluggables, ROADMs, Amps, Regen, Transponder/Muxponder etc.
* Evaluation of optical services viability
* End-to-end Optical services configuration/modification from plug
to plug (or from transponder to transponder).
* Optical services telemetry collection and monitoring performances/
faults including the asynchronous notification collected including
coherent pluggables.
Note that this requirement addresses the optical control functional
aspects but not how they are realized in the network and not how the
information needed by the optical controller is collected from the
network.
de Dios, et al. Expires 20 June 2024 [Page 39]
Internet-Draft POI Requirements December 2023
A.15. R15: Support for operators' operational practices
Existing operators' operational practices on packet and optical
network and services shall be supported. See
[draft-davis-ccamp-photonic-plug-control-arch-02].
This requirement emphasizes that the current operator's operational
practices such as network planning, commissioning, provisioning,
assurance, optimization and protection/restoration for both packet
and optical networks shall be preserved whether the optical network
is deployed with coherent plugs or with traditional transponder/
muxponder. In other words, this requirement emphasizes that the
packet and optical control architecture shall deal with any network
deployment and administration approaches as coherent plugs are
deployed without imposing significant change to the operator's
current operational practices.
There will be significant benefit to operators allowing them to
continue to use their existing operational practices to provision and
monitor optical services end to end either between transponders/
muxponder or between coherent plugs.
For operators who have specific demarcation between operations of
packet network and optical network (with separate physically
partitioned controllers) as discussed, it is important that the
introduction of converged optical-packet devices does not force a
change to their existing operational practices.
As a network evolves, the operational practice may need to change,
however, it is clearly always the case that complex photonic
networking will require sophisticated dedicated control functions
regardless of how the administration is organized.
A.16. R16: Support for multi-layer operational benefits
The multi-layer packet over optical capabilities and operational
benefits among packet and optical controllers such as multi-layer
optimization, multi-layer assurance, multi-layer
resiliency/protection/restoration and multi-layer planning shall be
addressed for full automation in a packet over optical networks. See
[draft-davis-ccamp-photonic-plug-control-arch-02].
To support this requirement, there might be a need for a higher layer
controller to collect the configuration and telemetry data from both
packet and optical networks and implement various multi-layer
operational benefits.
de Dios, et al. Expires 20 June 2024 [Page 40]
Internet-Draft POI Requirements December 2023
A.17. R17: Support for "greenfield" and "brownfield" networks
The solution shall address both "greenfield" and "brownfield"
networks. See [draft-davis-ccamp-photonic-plug-control-arch-02].
A.18. R18: Optional higher level controller
Higher level controller shall be optional. See
[draft-davis-ccamp-photonic-plug-control-arch-02].
In some packet over optical networks, the higher level controller
might not be needed, depending upon the supported use-cases in that
network. Forcing the addition of a higher level controller makes the
deployment more costly and potentially more complex.
A.19. R19: Support of both plugs and Transponders/Muxponders (inc.
Regens)
The solution shall support a packet over optical network which
contains mix of plugs and Transponders/Muxponders (inc. Regens).
See [draft-davis-ccamp-photonic-plug-control-arch-02].
Many optical services will have a coherent plug in a packet device at
one end and a coherent plug, or coherent optics on some other circuit
pack type, in a non-packet device (e.g., storage, application
platform, optical regen) at the other end. The solution shall
support all current and expected configurations in a uniform fashion.
A.20. R20: Various existing YANG Data Models shall be accommodated
The solution shall enable the use of various existing YANG data
models. See [draft-davis-ccamp-photonic-plug-control-arch-02].
Currently used to configure/monitor coherent transponders (e.g.,
OpenConfig, IETF etc.), for configuration/monitoring of coherent
plugs in packet devices.
Note that possibly expand (new requirement) to indicate that the YANG
data model MUST define all the optical parameters to be exchanged
(e.g., power setting) between the network elements and the control
and also emphasize access between the plug and device along with
necessary mapping neutrality etc. (this was derived from draft-ietf-
ccamp-dwdm-if-mng-ctrl-fwk-13).
A.21. R21: Clear demarcation for holistic control of optical network
Holistic control of optical network shall follow clear demarcation.
See [draft-davis-ccamp-photonic-plug-control-arch-02].
de Dios, et al. Expires 20 June 2024 [Page 41]
Internet-Draft POI Requirements December 2023
Where there is network technology based responsibility partitioning,
the controllers should abide by the technology boundaries. The
packet controller shall control packet functions and the optical
controller shall control optical functions. The optical technology
includes coherent terminal functions and hence these shall be
controlled by the optical controller. The packet controller shall
not need to be exposed to coherent plugs optical attributes. Optical
technology is a separate, distinct and complex technology from packet
technology.
A.22. R22: Support for urgent optical control actions
Urgent optical control actions shall be supported in a timely manner.
See [draft-davis-ccamp-photonic-plug-control-arch-02].
During some of the operation and restoration/protection cycles of the
converged packet and optical networks, urgent action on the
configuration of the pluggable may be required where the decision to
take the action and the action detail are the responsibility of the
optical controller. For example, during the restoration and
protection of the Optical services, there might be a need for re-
tuning and re-coloring of optical services. This involves changes in
both the coherent plugs and ROADM networks.
A.23. R23: Minimize fragmentation of optical parameter provisioning
The solution shall minimize fragmentation of optical parameter
provisioning. See [draft-davis-ccamp-photonic-plug-control-arch-02].
It is highly beneficial to closely coordinate configuration parameter
settings across the optical network including pluggables as
inconsistent configuration can potentially cause disruption to other
photonic paths.
A.24. R24: Direct path to relevant controller
Network information shall take direct path to relevant controller.
See [draft-davis-ccamp-photonic-plug-control-arch-02].
It shall be possible to access all configuration information and
telemetry data available from the coherent plug as directly as
possible (ideally with no intervening transfer delays).
A.25. R25: Evolution to expected future controller deployment
approaches
Evolution to expected future controller deployment approaches shall
be supported. See [draft-davis-ccamp-photonic-plug-control-arch-02].
de Dios, et al. Expires 20 June 2024 [Page 42]
Internet-Draft POI Requirements December 2023
The solution shall be designed to provide a clear evolution path to
the probable future architecture (which is expected to be focused on
disaggregation of control). In this architecture it is expected that
control components with specific focused functions will have direct
access to the corresponding functions in target systems and that
asynchronous and simultaneous access to these functions will be
vital.
A.26. R26: Evolution to future packet processing deployment approaches
Evolution to future packet processing deployment approaches shall be
supported. See [draft-davis-ccamp-photonic-plug-control-arch-02].
The solution shall be designed to provide a clear evolution path to
support control of packet and optical functions deployed using
emerging strategies (e.g., virtual routers, cloud based functions)
where the network functions are not constrained by physical
boundaries. Operational approaches native to these environments
should be supported.
A.27. R27: Support for extensible control architecture
The control architecture shall be extensible. See
[draft-davis-ccamp-photonic-plug-control-arch-02].
The solution will allow addition of new capability whilst operational
where that capability may be vendor specific, technology specific,
application specific or generic and where the addition may be of a
new version of an existing function etc.
Acknowledgments
Authors' Addresses
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Edward James Echeverry
Telefonica
Email: edward.echeverry@telefonica.com
Reza Rokui
Ciena
Email: rrokui@ciena.com
de Dios, et al. Expires 20 June 2024 [Page 43]
Internet-Draft POI Requirements December 2023
Nigel Davis
Ciena
Email: ndavis@ciena.com
Bhavit Vadhadiya
Vi
Email: bhavit.vadhadiya1@vodafoneidea.com
Praveen Maheshwari
Airtel
Email: Praveen.Maheshwari@airtel.com
Italo Busi
Huawei Technologies
Email: italo.busi@huawei.com
Aihua Guo
Futurewei Technologies
Email: aihuaguo.ietf@gmail.com
de Dios, et al. Expires 20 June 2024 [Page 44]