]> Cisco

Via S. Maria Molgora, 48 c 20871 - Vimercate Italy +390392091462 ggalimbe56@gmail.com

Vodafone

jeff.bouquier@vodafone.com

Cisco

AMOT ATRIUM Tower 19th floor TEL AVIV-YAFO, TA Israel ogerstel@cisco.com

Cisco

Research Triangle Park North Carolina UNITED STATES OF AMERICA brfoster@cisco.com

Cisco

daniele.ietf@gmail.com

Common Control and Measurement Plane This document extends the draft-ietf-teas-actn-poi-applicability to the use case where the DWDM optical coherent interface is equipped on the Packet device. It identifies the YANG data models being defined by the IETF to support this deployment architecture and specific scenarios relevant for Service Providers. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface)in the ACTN architecture. Discussion Venues Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (ccamp@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The full automation of the multilayer/multidomain network is a topic of high importance in the industry and the service providers community. Typically, the layers composing such network are the IP/ MPLS, (with Segment Routing) and the Optical ones. The requirements of high bandwidth availability and dynamic control of the networks are of capital importance too. The draft-ietf-teas-actn-poi- applicability specifies very well how to control and manage multilayer/multidomain networks using the Abstraction and Control of TE Networks (ACTN) architecture, see also . New DWDM Coherent pluggable optics, such as ZR and ZR+ , are enabling new multilayer network use cases where the DWDM interface is located within the packet domain equipment instead of being part of the Optical domain . ZR and ZR+ (and also CFP2-DCO) deployment in routers has already started and are expanding significantly. The way the DWDM pluggable are in general managed is not yet completely specified and defined by any standard and it is becoming an urgent matter to cover for Service Providers. Full end-to-end management solution of these DWDM coherent pluggable optics, leveraging on ACTN hierarchical architecture, is becoming critical to allow a wider deployment beyond simple point-to-point high capacity link scenarios between two IP/ MPLS routers. The ACTN architecture, defined in , is used to control the multi-domain network shown in , where each Packet PNC (P-PNC) is responsible for controlling its IP domain, which can be either an Autonomous System (AS), , or an IGP area within the same operator network. Each Optical PNC (O-PNC) in the below topology is responsible for controlling its own Optical Domain.

Reference multilayer/multidomain Scenario

shows how the Packet Node DWDM coherent Ports are connected to the ROADM ports.

Cross layer interconnection

Reference architecture and network scenario As described in and according to the Packet Optical Integration (POI) draft in which ACTN hierarchy is deployed , the PNCs are in charge to control a single domain (e.g. Packet or Optical) while the MDSC is responsible to coordinate the operations across the different domains having the visibility of the whole network multi-domain and multi- layer network topolgy. A specific standard interface (MPI) allows the MDSC to interact with the different Provisioning Network Controller (O/P-PNCs). Although the MPI interface should present an abstracted topology to the MDSC (hiding technology-specific aspects of the network and hiding topology details depending on the policy chosen) in the case of DWDM coherent pluggable located in the PN some information related to the physical component must be shared on MPI. The above statement is assumed as the Domain PNC (e.g. O-PNC) may not be able to get information from or set parameters to a node belonging to a different domain (e.g. P-PNC). The reason of this change is due to the following statements: O-PNC routing and wavelength assignment

• The MDSC can ask the O-PNC to set an optical circuit between two ROADM ports (A and Z). The O-PNC having the full Optical Topology network knowledge can calculate the Optical Path, the wavelength assignment (RWA), etc. K-circuits may be calculated and sorted based on some parameters (e.g. number of hops, path length, OSNR, etc.)

Optical Circuit Feasibility

• O-PNC can calculate the estimated OSNR for the A to Z circuits and sort them from the best to the worse performance or select the most suitable performance circuit. To verify the circuit feasibility the O-PNC needs to know the Transceiver optical characteristics, e.g. OSNR Robustness, DC capability, supported PDL, FEC, etc. For more details refer to draft-ietf-ccamp-dwdm- if-param-yang. The above parameters may not be directly retrieved from Packet Node by the O-PNC, (e.g. because the Packet Node supports only proprietary models or the Packet Nodes is not able to support dual writing operation or the Packet Node belongs to a different IP AS nor reachable by O-PNC), then they must be read by the P-PNC, shared to MDSC via MPI and finally to O-PNC. Other parameters like central frequency and transmit power are calculated by the O-PNC and must be provisioned to the Pluggable optics when the circuit is set-up.

Nominal Central frequency

• After having verified the Circuit Optical feasibility the O-PNC shares the channel central frequency to MDSC so that the MDSC can ask P-PNC to provision the Lambda to Router Pluggable.

FEC Coding

• This parameter indicate what Forward Error Correction (FEC) code is used at Ss and Rs (R/W) (not mentioned in G.698.2), it is used by the O-PNC to calculate the optical feasibility. The FEC coding list (FEC can be many) supported by the pluggable is an input for O-PNC, one coding is selected for a specific circuit and is shared (as output) to MDSC for pluggable provisioning.

Modulation format

• This parameter indicates the list of supported Modulation Formats and the provisioned Modulation Format. It is an input for O-PNC

Transmitter Output power

• This parameter provisions the Transceiver Output power.

Receiver input power range

• This parameter is the Min and Max input power supported by the Transceiver, i.e. Receiver Sensitivity. It is an input for O-PNC to properly calculate the optical power to set at ROADM port

Receiver input power

• This parameter is the measured input power at the receiver. It is an input for O-PNC to properly check the patchcord (between transceiver and ROADM) loss comparing it with the ROADM port received power.

operational-mode

• In order to make the MPI communication more efficient and improve the abstraction, the above (and more) parameters can be summarised by the operational-mode parameter. The operational-mode can be either standard ("application code" defined by ITU-T G.698.2) or organization/vendor specific. In both cases are strings of characters defined by ITU-T or by vendors. A pluggable may support several operational modes, those values are collected by the P-PNC and notified to O-PNC through the MDSC. They are used, by O-PNC, to check the circuit optical feasibility. For each transceiver the O-PNC will select only one operational-mode to be set, together with central frequency and TX power, in the pluggable though MDSC and P-PNC.

The above optocal parameters are related to the Edge Node Transceiver and are used by the Optical Network control plane in order to calculate the optical feasibility and the spectrum allocation. The parameters are read by the P-PNC from the DWDM pluggable and shared with MDSC to give the visibility of the pluggable characteristics. MDSC can use the info to understand the client capabolity and, again, share the same info to O-PNC for the impairment verification. On the opposite direction O-PNC can send to MDSC the values (e.g. operational mode, lambda, TX power) to provision the Client (Packet) DWDM Pluggable. The pluggable provisioning will be done by the P-PNC. For more details on the optical interface parameters see: . In summary the pluggable parameters exchanged from O-PNC to MDSC to P-PNC for end to end service provisioning are:

Use Cases The different services supported by the network are shown in . This draft is focused on the inter-layer link, the DCO links setting through the MC-links setting although the POI first goal is to set an IP service.

Cross layer interconnection | | | | | | | | | | +-------+ | Eth-link | +-------+ | | | <---------------------------------------------------> | | | | | | | | | | | | | | DCO-link | | | | | | DCO <-------------------------------------------> DCO | | +--+-------+--+ +--+-------+--+ ^ ^ | +-------+ +-------+ | | | OLS | | OLS | | | | | | | | +-----> | <-----------------------------> |<------+ inter-layer | | MC-link | | inter-layer link | | | | link +-------+ +-------+ IP-link = IP service, out of this document scope Eth-link = Ethernet connection DCO-link = Pluggable connection (OTSi connection) MC-link = Media Channel link (MC optical circuit) ]]>

The use cases supported by the models are: Inter Layer (or domain) Link discovery and provisioning

• The inter-layer links (or inter-domain links)are the interconnections (fiber) between the pluggable ports (in the Packet Layer) and the ROADM ports (in the Optical Layer). They are set in the Packet and DWDM nodes either manually (e.g. CLI) or via PNCs. The values identifying the inter layer links may be defined by MDSC which has the visibility of both IP and Optical layers. The "plug-id" could be used for this purpose.

Network topology discovery and provisioning

• MDSC retrieves the packet network topology from the P-PNC and the optical network topology from the O-PNC. MDSC collects and rebuilds the service topology based on the services information coming from P-PNC and O-PNC as described in draft-ietf-teas-actn- poi- applicability.

End to End Packet service provisioning / deletion

• MDSC is asked to set a Packet service between two Routers requiring additional connectivity bandwidth.

Optical Circuit provisioning / deletion

• MDSC is asked to set an Optical Circuit between two router ports (O-PNC will receive the same request from MDSC). This is specially needed during the network installation to provide Connectivity between two Routers, the IP link will be set up later using this optical tunnel.

LAG extension

• MDSC is asked to extend a service bandwidth. This may require more Router optical connectivity.

Optical Restoration

• O-PNC detects an optical network failure and reroutes the optical circuits to a different path (and lambda).

Network Maintenance Operations

• MDSC is asked to isolate part of the optical network for maintenance and coordinate the O-PNC and P-PNC to preserve the traffic during the maintenance operation.

Inter Layer Link discovery and provisioning The inter-layer links are set in the Packet and DWDM nodes either manually (e.g. via CLI or NMS) during the installation phase when the operator connects the Pluggable Transceiver to the ROADM port via fiber patch cord or is defined by the MDSC controller and provisioned via the PNCs. One method and model to define the Inter Layer Link is, for example, to assign a value to the patchcord (for Tx and RX directions) and store those values in the Pluggable and ROADM port provisioning when the fiber is connected between the two ports. This allows the PNCs to retrieve the values and share them with the MDSC for the correlation and check. Other smarter and automatic methods of patchcord discovery may be defined but are outside of this draft scope. The inter-layer link must be set (or clear) any time a new pluggable module is installed (or removed) and it is connected to the ROADM port with the fiber patchcord. When a new DCO is installed an inventory notification must be reported to the PNC and MDSC, the reported info are: It would be also possible to auto-discover the inter-layer (inter- domain) links between DWDM coherent pluggables and ROADM ports by checking the input/output power levels (and probably switching on/off the lasers of the pluggables). This would require the help of MDSC, O-PNC and P-PNC. The same methoc could be used to verify the provisioned connectivty. For further study in this draft.

Network topology discovery and provisioning The first operation executed by the P-PNC and O-PNC is to discover the network topology and share it with the MDSC via the MPI. The PNCs will discover and share also the inter-layer links (or connections) so that the MDSC can rebuild the full network topology associating the DWDM Router ports to the ROADM ports. Once the association is discovered the P-PNC must share the characteristics of Pluggable module with the MDSC and then MDSC with the O-PNC. At this point the Hierarchical controller (MDSC) and the domain controllers have all the information to commit and honour any service request coming from the OSS/orchestrator. The details of the general operations are described in draft-ietf-teas-actn-poi-applicability, while this draft describes how to operate the Pluggable module during the optical circuit set-up operation. As the Pluggable can be inserted or remove at any time it is relevant to have admin and operational state notification from the network to the PNC and MDSC.

End to End service provisioning / deletion The End to End service provisioning is a multilayer provisioning involving both the packet layer and the optical layer. The MDSC plays a key role as it has the full network visibility and can co- ordinate the different domain controllers' operations. The service request can be driven by the operator using the MDSC UI or the MDSC receives the service request from the operator OSS/Orchestrator. The workflow for the creation of an end to end service is composed by the following steps: NOTE: the Optical service may not be feasible due to optical impairments calculation failure. In this case the O-PNC will reject the optical circuit creation request to MDSC. It is up to the operator (through MDSC) to scale down (e.g. propose a 300Gb/s instead of a 400Gb/s service) the request or plan a network upgrade. Another point to note is the information sent by MDSC to O-PNC about the pluggable characteristics. In reality this info should be known by the O-PNC at network commissioning time when the Inter Layer Link is set or discovered. The pluggable information may have multiple instances when the pluggable support multiple bit rate (e.g. ZR+). In case of multiple bit rate (and multiple operational mode) the O-PNC can decide to propose to MDSC a different bit rate (higher or lower) calculated in base of the optical validation algorithms. That is: MDSC ask for a 400Gb/s bit rate while O-PNC proposer a 300Gb/s bit rate, instead of rejecting the circuit request.

Optical Circuit provisioning / deletion Upon receiving an optical service request from the OSS/Orchestrator, the MDSC starts performing the different operations to implement the optical service (e.g. from A to Z). As an alternative the service request can be driven by the operator using the MDSC UI. The steps of the workflow are: NOTE: the Optical service may not be feasible due to optical impairments calculation failure. In this case the O-PNC will reject the optical circuit creation request to MDSC. It is up to the operator (through MDSC) to scale down the request or plan a network upgrade. The same consideration done in the previus use case are applicable here.

LAG extension Upon receiving a LAG service request from OSS/Orchestrator, the MDSC start computing the different operations to implement the request. The MDSC would determine if an existing multi-layer connection exists between the routers participating in the LAG. If so, the MDSC would request the P-PNC to configure and add the new LAG bundle member link using this existing connection, and notify the OSS confirmation of the additional link. If more optical connectivity is needed, then the procedures defined in would be followed.

Optical Restoration For this use case the trigger for the Domain controller and MDSC to take actions is coming from the optical data plane when the O-PNC detects or is notified about an optical network failure (e.g. a fiber cut or a node failure). This kind of events affect the traffic and a number of optical circuits are lost. NOTE: the restoration may not be feasible due to optical impairments calculation failure. In this case the O-PNC will notify the optical circuit restoration failure to MDSC. It is up to the operator, through MDSC, to take actions and/or plan a network upgrade. In case the optical circuit restoration is revertible, is again O-PNC responsibility to monitor the failure after the fix and start the revert procedure to bring the restore path to the original route.

Network Maintenance Operations The maintenance operation is requested by the OSS when a part of the network needs a maintenance activity. There could be Packet network maintenance or Optical network Maintenance. As an alternative the maintenance request can be driven by the operator using the MDSC UI. The Packet network maintenance is simple and is addressed by the MDSC in cooperation with the P-PNC. The optical network maintenance is more complex and needs the MDSC coordination to ask the P-PNC to move away the traffic from the resources under maintenance in the optical network. That means MDSC has to search in the service DB whether a service is using a definite optical link and re-route the service to a part of the optical network not affected by the maintenance operation. Upon maintenance completion the MDSC will bring all the traffic back to the original route.

Optical Interface for external transponder in a WDM network This document proposes an augmentation to the ietf-interface module called ietf-ext-xponder-wdm-if. The ietf-ext-xponder-wdm-if, author note: define the model, is an augment to the ietf-interface. It allows the user to set the operating mode of transceivers as well as other operational parameters. The module also provides threshold settings and notifications to supervise measured parameters and notify the client.

Structure of the Yang Module ietf-ext-xponder-wdm-if is a top-level model for the support of this feature.

Security Considerations RSVP-TE message security is described in . IPsec and HMAC- MD5 authentication are common examples of existing mechanisms. This document only defines new UNI objects that are carried in existing UNI messages, thus it does not introduce new security considerations.

IANA Considerations This document registers a URI in the IETF XML registry . Following the format in , the following registration is requested to be made: URI: urn:ietf:params:xml:ns:yang:ietf-interfaces:ietf-ext-xponder- wdm-if Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry . This document registers a YANG module in the YANG Module Names registry . prefix: ietf-ext-xponder-wdm-if reference: RFC XXXX

References Normative References 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. GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer-granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid. This document updates RFCs 3471 and 6205 by introducing a new label format. Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed. Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors. Global wavelength semantics are not considered. In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols. [STANDARDS-TRACK] This memo describes the extensions to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid. 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. International Telecommunications Union International Telecommunications Union International Telecommunications Union Optical Internetworking Forum (OIF) OpenZR+ Multi-Source Agreement 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. This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. TIM Vodafone Huawei Old Dog Consulting Ericsson This document considers the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI)in the context of IP/MPLS and optical internetworking. It identifies the YANG data models defined by the IETF to support this deployment architecture and specific scenarios relevant to Service Providers. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface)in the ACTN architecture. Cisco Deutsche Telekom Juniper Juniper This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or by in phase of specification by) ITU-T G.698.2 or any other ITU-T recommendation. Use cases are described in RFC7698. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of a multi-vendor IaDI optical link. The use of this model does not guarantee interworking of transceivers over a DWDM. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Informative References The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community. This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.

Acknowledgments This document was prepared using kramdown.

Contributors Cisco

phbedard@cisco.com

Cisco

reldesou@cisco.com

Juniper

ggrammel@juniper.net

Cisco

prmanna@cisco.com

Vodafone

jose-angel.perez@vodafone.com

Vodafone

manuel-julian.lopez@vodafone.com