]> KDDI

Japan ta-miyasaka@kddi.com

1Finity

Japan tochio@fujitsu.com

RTG TEAS Working Group ACTN MDSC inter-operator traffic engineering optical This document specifies an extension to the ACTN framework (RFC 8453) that enables coordination between the MDSCs of different operators, so that they can establish and operate end-to-end TE services cooperatively while each operator keeps full control of its own network and keeps its internal details private. As its concrete realization within ACTN, the extension defines the MDSC-MDSC Interface (MMI), a symmetric peer interface between the MDSCs of different operators, in which neither MDSC has authority over the other, and which complements rather than modifies the CMI and the MPI. The extension is independent of the underlying switching technology and applies to packet, optical, and multi-layer TE networks. Status information for this document may be found at . Discussion of this document takes place on the TEAS Working Group mailing list (), which is archived at . Subscribe at .

Introduction The Abstraction and Control of TE Networks (ACTN) framework defines a three-tier hierarchy of controllers, the Customer Network Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and the Provisioning Network Controllers (PNCs), connected by the CNC-MDSC Interface (CMI) and the MDSC-PNC Interface (MPI). ACTN also addresses multi-domain networks through a hierarchical arrangement in which a higher-level MDSC (MDSC-H) coordinates lower-level MDSCs (MDSC-L) by applying the MPI recursively. also describes how a VN can be built from resources operated by different operators, with one operator acting as a customer of another through the CMI. A growing driver of network operation across different operators is the rapid growth of AI workloads and the data center interconnection (DCI) traffic they generate. Distributed training and inference for large-scale AI models demand high-bandwidth, low-latency, and highly reliable connectivity between data centers, which are frequently owned by data center or cloud operators that are distinct from the network operators owning the wide-area transport infrastructure between them. Satisfying this demand requires high-quality traffic-engineered paths, and increasingly end-to-end optical paths, that are established cooperatively across the data center operator's network and the networks of one or more other operators . In these deployments the networks are operated by different operators, so no operator controls another and no single entity can see or manage all of the networks. Each operator owns and operates its own MDSC, and the existing ACTN mechanisms already support connectivity between their networks. What they do not specify is how independently controlled MDSCs coordinate their resource allocation decisions (e.g., the wavelength assigned to a WSON LSP, or the MPLS label or Segment Routing SID used across the inter-operator link) and keep the TE resources (see ) and constraints of the end-to-end path consistent across their networks. This document specifies an extension to the ACTN framework that enables coordination between the MDSCs of different operators, so that they can establish and operate end-to-end TE services cooperatively while each operator keeps full control of its own network and keeps its internal details private. As its concrete realization within ACTN, the extension defines the MDSC-MDSC Interface (MMI), a symmetric peer interface between the MDSCs of different operators. Unlike the hierarchical use of the MPI between an MDSC-H and an MDSC-L, the MMI assumes no subordination, and neither MDSC has authority over the other. The MMI complements, and does not modify, the CMI and the MPI. The extension is independent of the underlying switching technology and applies to packet, optical, and multi-layer TE networks. While the primary scenario is coordination between different operators, the same mechanism also applies within a single operator to networks that have independent control planes, for example where organizational, technological, or historical reasons prevent a single MDSC from having authority over all of them. It relates to and where possible reuses existing IETF work, including the ACTN VN model , the TE topology model , and the applicability of ACTN to packet-optical integration and to network slicing .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The terms CNC, MDSC, PNC, CMI, and MPI are used as defined in . This document additionally uses the following terms.

Operator:

An independent administrative entity that owns and operates its own ACTN stack, comprising a CNC, an MDSC, and one or more PNCs.

Domain:

A network controlled by a single PNC, as in . A domain belongs to one operator.

Multi-domain:

Involving multiple domains within a single operator, as in .

Multi-operator:

Involving multiple independent operators.

Inter-operator:

Between independent operators. This document defines inter-operator coordination between MDSCs.

MMI (MDSC-MDSC Interface):

The symmetric peer interface between the MDSCs of different operators, defined in this document.

TE resource:

A resource of a TE network that is allocated to an LSP, such as bandwidth on a TE link, a wavelength, a timeslot, or a label. The term follows the usage of , and the TE topology model represents such resources.

Usecase This section presents representative cases that motivate coordination between the MDSCs of different operators. In each case the participating networks belong to different operators, and an end-to-end service has to be built across them without any operator revealing its internal network.

Inter-operator optical connectivity A customer such as an enterprise, a broadcaster, or a research network needs a high-capacity, deterministic optical circuit between two sites that are reached through different operators' optical networks. Each operator operates its own optical transport network based on WDM and OTN, and the circuit has to cross more than one of them. Where the operators' networks support it, the circuit can be realized as an end-to-end all-optical path across their optical networks, avoiding optical-electrical-optical conversion at the boundaries . The operators' MDSCs coordinate to assign wavelength or spectrum at the border between their networks, to validate optical feasibility across the boundary, and to agree on the end-to-end optical budget such as OSNR and latency, while each operator exposes only its border capabilities and an abstracted view of its reachability.

Inter-operator IP traffic engineering A service such as low-latency financial connectivity, real-time media transport, or an enterprise VPN needs a traffic-engineered path that spans more than one operator's IP/MPLS network. Each operator operates its own IP/MPLS network, and inter-operator connectivity today relies on static peering with little dynamic TE coordination. The operators' MDSCs coordinate to reserve bandwidth at the inter-operator links and to compute a TE path that meets the end-to-end objective, while each operator keeps control of how the path is realized inside its own network.

Multi-layer interconnection for AI data centers Large-scale AI workloads, together with the power and siting constraints of large data centers, are driving operators to distribute data centers across multiple sites, which increases the traffic between them. These data centers are run by a data center or cloud operator, while the wide-area connectivity between the sites is provided by one or more network operators. The data center operator runs an IP or packet-optical network at each site, and the network operators provide the transport between the sites over OTN and optical (WDM) infrastructure, so the end-to-end service is both multi-layer and multi-operator. The data center operator's MDSC and the network operators' MDSCs coordinate to build a packet or IP connection that is carried over OTN or optical paths across those operators, agreeing on the interconnection points, the end-to-end latency and bandwidth, and the management of the shared resources, while each operator keeps its internal topology private.

Gap Analysis

Current ACTN and related IETF work defines the ACTN reference architecture shown in Figure 1. A single MDSC sits between the customer, reached through the CMI, and one or more PNCs, reached through the MPI, and it abstracts and coordinates the domains below it. For larger networks, ACTN allows the MDSC to be arranged hierarchically, with a higher-level MDSC (MDSC-H) coordinating lower-level MDSCs (MDSC-L) over a recursive MPI.

Figure 1 shows that multiple PNCs, each controlling one domain, are coordinated by a single MDSC. ACTN is defined together with, and complemented by, a number of other IETF specifications, summarized below. Base framework and models: the ACTN framework and the ACTN information model . Virtual network operations: the VN operations model . Packet-optical and optical transport: the applicability of ACTN to packet-optical integration and the optical transport network management model . Slicing and performance: the applicability of ACTN to network slicing and ACTN PM telemetry and autonomics .

Resources shared at the inter-operator boundary Section 5.5 of describes how a VN can be built from resources operated by different operators: in its Figure 10, Operator 1 obtains connectivity from Operator 2 as a customer, through a CNC that communicates with Operator 2's MDSC over the CMI, and that connectivity appears as a virtual link in Operator 1's network. This VN recursion is a valid way of connecting the networks of different operators, and this document does not replace it. It is coordination through a customer-provider relationship, and it leaves to the provider everything inside its network; it does not define how the two MDSCs agree on the resources they share at their boundary, or how they validate a path that runs through both networks. Figure 2 shows such a customer-provider relationship, in which the segment of Operator B lies in the middle of the path of Operator A.

end-to-end path: resource continuity and constraints hold end-to-end Figure 2: Inter-operator connectivity through the CMI ]]>

The two networks are connected by two boundary links, between a3 and b1 and between b3 and a4; Operator A controls one end of each (a3 and a4) and Operator B the other (b1 and b3). Coordination between the operators is needed at two levels: at these boundary links, and along the end-to-end path from a1 to a5.

Boundary links On each boundary link, the two ends have to agree on the TE resource used for the LSP, such as the wavelength of a WSON LSP or the MPLS label or SR SID of a packet LSP. Existing mechanisms cover part of this. The TE topology model represents the boundary links and, in its Section 4.3, correlates the links of topologies supplied by independent providers. Inter-domain MPLS and GMPLS signaling agrees on the label between the two ends of a boundary link, where a control plane runs across it. On the other hand, this document considers deployments in which no signaling protocol (e.g., RSVP-TE) runs across the boundary links between operators. This is a deployment assumption, not a restriction of ACTN, which allows a control plane inside each domain. In such a deployment, the agreement has to be carried over an interface between the two operators, and the CMI is the only ACTN interface that crosses the boundary. However, the models currently defined for the CMI do not specify it: the AP only identifies the access link, and the VN model has no attribute for the label or the wavelength used on it. What is missing, therefore, is a procedure by which the two MDSCs agree on the TE resource of each boundary link and configure the two ends consistently, for example how the label that b1 assigns for the LSP is communicated to the operator of a3 and applied there. This is coordination at the level of resources, beyond identifying the access link in a service request.

End-to-end TE path Along the end-to-end path from a1 to a5, some TE resources have to be the same on every link, such as the frequency slot of an optical path without wavelength conversion, and constraints have to be checked over all the links, such as the end-to-end latency and the optical signal quality. Neither can be settled from one segment alone: a slot chosen on a1 to a3 has to be free on b1 to b3 and on a4 to a5 as well. Here too, existing mechanisms cover part of this. BRPC computes a path across several domains without disclosing their internal topology, and the PCEP extensions for WSON compute the wavelength assignment, including wavelength continuity, within one PCE, leaving optical impairments outside its scope. This document does not replace these mechanisms. However, they do not specify what happens after the path has been computed, when Operator A and Operator B each allocate the resources of their own segments without a common MDSC above them: how the two MDSCs check that the resources chosen for their segments are continuous where the technology requires it (e.g., the same frequency slot on every segment) and that the constraints of the end-to-end path are met (e.g., the end-to-end latency and the signal quality), once both have chosen the resources of their own segments; how a later change on one side (e.g., a reroute) is reported to the other side and re-checked. Alternatively, Operator A could request a particular frequency slot from Operator B as part of the service request. Unless the service request also lets the two operators exchange candidate slots and re-validate the path, A would choose the slot without knowing which slots are free on b1 to b3 or how much signal degradation that segment adds, and a slot that B cannot provide, or a later change on either side, would start the request over. Closing these gaps requires coordination at the level of resources between the MDSCs that control the segments of the path, both when the resources are first allocated and when a change on one side affects the end-to-end path. Such coordination complements the service request and the path computation, and leaves each MDSC in control of its own resources. The MMI introduced in the following sections is the interface for it; this document does not assert that the same functions could not be added to the CMI. In summary, neither nor the mechanisms above specifies these procedures for the deployments considered here; they are the subject of this document.

What is missing None of the work above defines coordination between the MDSCs of different operators as peers, in particular for the TE resources at the boundary links and for the resources and constraints of the end-to-end path. The specific gaps are the following. No peer relationship between MDSCs. ACTN covers coordination across multiple domains and layers under one MDSC, and connectivity between operators through the customer-provider relationship of Section 5.5 of , but it does not define how the MDSCs of different operators coordinate as peers, where neither has authority over the other. This is the core gap, and the points below are consequences of it. Information disclosure between peers. Existing TE abstraction and information exchange mechanisms, including the abstraction levels of , support policy-controlled disclosure. Their application to the coordination of shared TE services between peer MDSCs, that is, what each operator discloses to the other (e.g., only the free frequency slots on its boundary links, or its whole abstract topology), requires further analysis; it is a choice separate from how much the two operators coordinate. No coordinated provisioning or assurance across operators. Existing mechanisms support path computation, provisioning, and monitoring within and across domains. What remains unspecified is the coordination between independently controlled MDSCs of the resource allocation (), of service changes, of the handling of a failure in one segment, and of the isolation of an end-to-end fault across the operator boundary. Service orchestration has a different scope. Inter-operator service orchestration is already defined outside the IETF, for example the MEF (now Mplify) LSO architecture , which provides inter-provider service orchestration and operational interactions, including ordering, service changes, and assurance. This document focuses on the coordination of TE constraints and resource decisions between ACTN MDSCs. The relationship between the two requires further analysis. The first gap, the missing peer interface between MDSCs, is the foundation for the others, and it is the focus of the extension defined in this document. The control-layer coordination defined here is complementary to service-layer orchestration such as MEF LSO, which can build on top of it.

Framework This document extends the ACTN architecture so that the MDSCs of different operators can coordinate directly as peers. Each operator keeps its own ACTN stack, namely a CNC, an MDSC, and one or more PNCs, unchanged. The extension adds the MMI between the MDSCs of different operators, as shown in Figure 3.

In the figure, each operator runs its own MDSC over its own PNCs and serves its own customers through the CMI, exactly as in . The new element is the MMI between the two MDSCs, which connects the operators as peers rather than placing one above the other. The MMI differs from the hierarchical use of the MPI between an MDSC-H and an MDSC-L in the following ways. Symmetry. Both MDSCs have the same role, and either one can initiate a request, so there is no parent and no child. No authority across the boundary. Neither MDSC can provision, change, or release resources in the other operator's network, and every action across the boundary follows from mutual agreement. Policy-governed disclosure. Each operator decides what topology and resource information it exposes to the peer, subject to negotiation between the two operators. Depending on the deployment and on the mechanisms reused (e.g., BRPC for path computation), the MMI may support some or all of the following interactions : Exchange of abstracted topology and resource information, at a level of detail each operator agrees to disclose. Cooperative establishment of end-to-end services, including agreement on the interconnection points and on the per-domain segments. Coordinated provisioning of the per-domain segments that make up an end-to-end service. Exchange of performance-monitoring information for the shared services, supporting end-to-end assurance. Within each operator, the CMI and the MPI between the MDSC and its PNCs continue to work as defined in , and the extension does not change them. The functions carried over the MMI, and the information it exchanges, are described in .

Policy and information exchange between operators Because the MMI operates across administrative boundaries, the two operators first agree, bilaterally, on what information they exchange and under which policy. This document considers the bilateral case; how information is propagated or aggregated across three or more operators is left for a future revision. This agreement covers the level of topology and resource abstraction each side discloses, the categories of information shared, the meaning of that information (e.g., whether a resource reported as available is unused, allocatable, or validated as usable), and how often it is updated. Depending on the deployment, the MMI may support interactions beyond per-service connection requests, including the exchange of abstracted topology and resource information, cooperative path computation, coordinated provisioning, and end-to-end assurance. This document describes these interactions at a high level; the detailed agreement mechanism and the MDSC-to-MDSC workflow are left for a future revision.

Requirements

Requirements on MDSC for inter-operator operation in section 3.2 of , multi-domain coordination and virtualization/abstraction are defined as the functions in MDSC. The Multi-domain means the domains that MDSC operates via PNCs and the coordination means that among MDSC and PNCs. Multi-domain operation is supported with the coordination and virtualization/abstraction. In inter-operator operation, each operator is responsible for providing an end-to-end service in coordination with other operators. Each operator is not required to expose the detail of internal topology, network resources and network elements to other operators, but is required to address the minimum information to provide an end-to-end path. So MDSC SHOULD have capability for creating and address the network information minimum enough to communicate with other MDSC(s) . Therefore, the requirements on MDSC for inter-operator operation are as below. MDSC SHOULD request to other MDSCs to create an end-to-end path per request from CNC connected to the MDSC. MDSC SHOULD have the capability of path calculation, path provisioning, and path management (e.g., fault management, performance management) in the domain MDSC controls and manages. The attributes of the path SHOULD be advertised to other MDSC(s) to create the end-to-end path. MDSC SHOULD have the capability of managing the network resource information addressed from other domains to create the path in the domain, with coordination of the request of an end-to-end path. MDSC SHOULD address the network resource information and network status information, e.g., performance monitoring and fault notification, to other MDSCs. The network information addressed to other MDSCs SHOULD be abstracted and minimized to what is needed for provisioning and maintaining the end-to-end service path as requested from CNC. The status information SHOULD be associated with the TE resource it refers to (e.g., the signal quality measured on a wavelength, or a fault on a link), so that the other MDSC can tell whether an advertised resource is usable for the end-to-end path. MDSC SHOULD address the network resource information immediately when it is changed and impacts on the management of end-to-end service path. The information SHOULD carry an indication of its validity (e.g., the time of the last update), so that the other MDSC can tell whether the information it holds is still current. MDSC MAY request other MDSCs for their network status information regarding the end-to-end service path. For the request, MDSC SHOULD reply in the scope of agreement between them. MDSC SHOULD NOT directly manage PNCs that belong to another operator; those PNCs are managed by that operator's own MDSC. A PNC SHOULD be managed by an MDSC of the same operator and SHOULD NOT be managed by an MDSC of another operator. Before allocating resources for a shared end-to-end path, MDSC SHOULD confirm with the other MDSC that the TE resources at the two ends of the inter-operator link match (e.g., the same wavelength, or the agreed label). MDSC SHOULD provide the other MDSC with the information needed to validate the resources and constraints of the end-to-end path (e.g., whether a frequency slot is free on its segment, the latency of its segment, or the signal quality of its segment), without disclosing its internal topology. ((Requirements on the relationship between MDSC and CNC will be added))

Requirements for Interfaces

Requirements for the MMI to be added if needed.

Requirements for the MPI between PNC and MDSC to be added if needed.

Requirements for the CMI between CNC and MDSC to be added if needed.

Interface Protocols and YANG Data Models for the MPIs to be considered...

Security Considerations The MMI crosses the boundary between two administrative entities, and every interaction over it is subject to the trust relationship between the two operators. The security considerations of apply. In addition, the MDSCs have to authenticate each other and authorize each other's requests according to the agreement between the operators; the information disclosed over the MMI is limited by that agreement; and an MDSC has to protect itself against requests from a misbehaving or compromised peer that would exhaust its resources, for example by reserving wavelengths or bandwidth that are never used. A more detailed treatment is left for a future revision.

IANA Considerations This document has no IANA actions.

Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. IOWN Global Forum MEF Forum A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it were a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework (RFC 8453). This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. FiberCop Vodafone Huawei Old Dog Consulting Cisco This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture. Old Dog Consulting Independent Huawei Technologies Old Dog Consulting Network abstraction is a technique that can be applied to a network domain to obtain a view of potential connectivity across the network by utilizing a set of policies to select network resources. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services that share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineered (TE) network that utilizes IETF technologies. It also identifies the features of network slicing not currently within the scope of ACTN and indicates where ACTN might be extended. In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability. This document provides an information model for Abstraction and Control of TE Networks (ACTN). China Unicom CAICT Huawei Technologies Old Dog Consulting Old Dog Consulting Many network technologies are operated as Traffic Engineering (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for detailed YANG Configuration and Management, effectively adding support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management (RDNM) to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs. Huawei Lancaster University Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA) Huawei Technologies Cisco This document provides YANG data models that describe the performance monitoring parameters and scaling intent mechanisms for Traffic Engineering (TE) tunnels and Virtual Networks (VNs). The models presented in this document allow customers to subscribe to and monitor the key performance data of the TE-tunnel or the VN. The models also provide customers with the ability to program autonomic scaling intent mechanisms on the level of TE-tunnel as well as VN. This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. [STANDARDS-TRACK] To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". In such an environment, a data-plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid (flexi-grid). Given the specific characteristics of flexi-grid optical networks and their associated technology, this document defines a framework and the associated control-plane requirements for the application of the existing GMPLS architecture and control-plane protocols to the control of flexi-grid DWDM networks. The actual extensions to the GMPLS protocols will be defined in companion documents. The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK] This document provides Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs). Path provisioning in WSONs requires an RWA process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical path computation.

Acknowledgments The authors would like to thank Deborah Brungard, Italo Busi, Daniele Ceccarelli, Dhruv Dhody, Shunsuke Homma, Daniel King, and Roberto Manzotti for their reviews and comments on this document.

Contributors 1Finity

Japan kuroiwa.reiko@fujitsu.com