PCEP Extension for Flow Specification
draft-ietf-pce-pcep-flowspec-01
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9168.
|
|
---|---|---|---|
Authors | Dhruv Dhody , Adrian Farrel , Zhenbin Li | ||
Last updated | 2018-07-02 | ||
Replaces | draft-li-pce-pcep-flowspec | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
TSVART Last Call review
(of
-09)
by Joseph Touch
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 9168 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-pce-pcep-flowspec-01
Network Working Group D. Dhody, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track A. Farrel, Ed. Expires: January 2, 2019 Juniper Networks Z. Li Huawei Technologies July 1, 2018 PCEP Extension for Flow Specification draft-ietf-pce-pcep-flowspec-01 Abstract The Path Computation Element (PCE) is a functional component capable of selecting the paths through a traffic engineered network. These paths may be supplied in response to requests for computation, or may be unsolicited instructions issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 5575 defines the Flow Specification and describes how it may be distributed in BGP to allow specific traffic flows to be associated with routes. This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. 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 January 2, 2019. Dhody, et al. Expires January 2, 2019 [Page 1] Internet-Draft PCEP-FlowSpec July 2018 Copyright Notice Copyright (c) 2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Procedures for PCE Use of Flow Specifications . . . . . . . . 4 3.1. Capability Advertisement . . . . . . . . . . . . . . . . 5 3.1.1. PCEP OPEN Message . . . . . . . . . . . . . . . . . . 5 3.1.2. IGP PCE Capabilities Advertisement . . . . . . . . . 5 3.2. Dissemination Procedures . . . . . . . . . . . . . . . . 6 3.3. Flow Specification Synchronization . . . . . . . . . . . 7 4. PCE FlowSpec Capability TLV . . . . . . . . . . . . . . . . . 7 5. PCEP Flow Spec Object . . . . . . . . . . . . . . . . . . . . 8 6. Flow Filter TLV . . . . . . . . . . . . . . . . . . . . . . . 9 7. Flow Specification TLVs . . . . . . . . . . . . . . . . . . . 10 8. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 13 8.1. Default Behavior and Backward Compatibility . . . . . . . 14 8.2. Composite Flow Specifications . . . . . . . . . . . . . . 14 8.3. Modifying Flow Specifications . . . . . . . . . . . . . . 14 8.4. Multiple Flow Specifications . . . . . . . . . . . . . . 14 8.5. Adding and Removing Flow Specifications . . . . . . . . . 15 8.6. VPN Identifiers . . . . . . . . . . . . . . . . . . . . . 15 8.7. Priorities and Overlapping Flow Specifications . . . . . 15 9. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 19 10.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 19 10.3. Flow Specification TLV Type Indicators . . . . . . . . . 19 10.4. PCEP Error Codes . . . . . . . . . . . . . . . . . . . . 20 10.5. PCE Capability Flag . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 12. Manageability Considerations . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Dhody, et al. Expires January 2, 2019 [Page 2] Internet-Draft PCEP-FlowSpec July 2018 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 14.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction [RFC4655] defines the Path Computation Element (PCE), a functional component capable of computing paths for use in traffic engineering networks. PCE was originally conceived for use in Multiprotocol Label Switching (MPLS) for Traffic Engineering (TE) networks to derive the routes of Label Switched Paths (LSPs). However, the scope of PCE was quickly extended to make it applicable to Generalized MPLS (GMPLS) networks, and more recent work has brought other traffic engineering technologies and planning applications into scope (for example, Segment Routing (SR) [I-D.ietf-pce-segment-routing]). [RFC5440] describes the Path Computation Element Communication Protocol (PCEP). PCEP defines the communication between a Path Computation Client (PCC) and a PCE, or between PCE and PCE, enabling computation of path for MPLS-TE LSPs. Stateful PCE [RFC8231] specifies a set of extensions to PCEP to enable control of TE-LSPs by a PCE that retains state about the the LSPs provisioned in the network (a stateful PCE). [RFC8281] describes the setup, maintenance, and teardown of LSPs initiated by a stateful PCE without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled. [RFC8283] introduces the architecture for PCE as a central controller and describes how PCE can be viewed as a component that performs computation to place 'flows' within the network and decide how these flows are routed. Dissemination of traffic flow specifications (Flow Specifications) was introduced for BGP in [RFC5575]. A Flow Specification is comprised of traffic filtering rules and actions. The routers that receive a Flow Specification can classify received packets according to the traffic filtering rules and can direct packets based on the actions. When a PCE is used to initiate tunnels (such as TE-LSPs or SR paths) using PCEP, it is important that the head end of the tunnels understands what traffic to place on each tunnel. The data flows intended for a tunnel can be described using Flow Specifications, and when PCEP is in use for tunnel initiation it makes sense for that same protocol to be used to distribute the Flow Specifications that describe what data is to flow on those tunnels. Dhody, et al. Expires January 2, 2019 [Page 3] Internet-Draft PCEP-FlowSpec July 2018 This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. The extensions include the creation, update, and withdrawal of Flow Specifications via PCEP, and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the PCC. Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this in during the path computation. Flow Specifications are carried in TLVs within a new Flow Spec Object defined in this document. The flow filtering rules indicated by the Flow Specifications are mainly defined by BGP Flow Specifications. 2. Terminology This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer. The following term from [RFC5575] is used frequently throughout this document: Flow Specification (FlowSpec): A Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic, including filters and actions. Each FlowSpec consists of a set of filters and a set of actions. This document uses the terms &+-------------+-------------------------+---------------------------+ | Prefix | YANG module | Reference | +-------------+-------------------------+---------------------------+ | optical- | ietf-optical- | [RFCXXXX] | | imp-topo | impairment-topology | | | layer0-type | ietf-layer0-types | [I-D.ietf-ccamp-layer0-ty | | s | | pes] | | l0-types- | ietf-layer0-types-ext | [I-D.esdih-ccamp-layer0-t | | ext | | ypes-ext] | | nw | ietf-network | [RFC8345] | | nt | ietf-network-topology | [RFC8345] | | tet | ietf-te-topology | [RFC8795] | +-------------+-------------------------+---------------------------+ Table 1: Prefixes and corresponding YANG modules [Editor's note: The RFC Editor will replace XXXX with the number assigned to the RFC once this draft becomes an RFC.] 2. Reference Architecture 2.1. Control Plane Architecture Figure 1 shows the control plane architecture. Lee, et al. Expires January 9, 2022 [Page 5] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 +--------+ | MDSC | +--------+ Scope of this ID -------> || | || | +------------------------+ | | OPTICAL | +---------+ | | DOMAIN | +---------+ | Device | | | CONTROLLER | | Device | | config. | | +------------------------+ | config. | +---------+ v // || \\ +---------+ ______|______ // || \\ ______|______ / OT \ // || \\ / OT \ | +--------+ |// __--__ \\| +--------+ | | |Vend. A |--|----+ ( ) +----|--| Vend. A| | | +--------+ | | ~-( )-~ | | +--------+ | | +--------+ | +---/ \---+ | +--------+ | | |Vend. B |--|--+ / \ +--|--| Vend. B| | | +--------+ | +---( OLS Segment )---+ | +--------+ | | +--------+ | +---( )---+ | +--------+ | | |Vend. C |--|--+ \ / +--|--| Vend. C| | | +--------+ | +---\ /---+ | +--------+ | | +--------+ | | ~-( )-~ | | +--------+ | | |Vend. D |--|----+ (__ __) +----|--| Vend. D| | | +--------+ | -- | +--------+ | \_____________/ \_____________/ ^ ^ | | | | Scope of [I-D.ietf-ccamp-dwdm-if-param-yang] Figure 1: Scope of draft-ietf-ccamp-dwdm-if-param-yang The models developed in this document is an abstracted YANG model that may be used in the interfaces between the MDSC and the Optical Domain Controller (aka MPI) and between the Optical Domain Controller and the Optical Device (aka SBI) in Figure 1. It is not intended to support a detailed low-level DWDM interface model. DWDM interface model is supported by the models presented in [I-D.ietf-ccamp-dwdm-if-param-yang]. 2.2. Transport Data Plane This section provides the description of the reference optical network architecture and its relevant components to support optical impairment-aware path computation. Lee, et al. Expires January 9, 2022 [Page 6] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 Figure 2 shows the reference architecture. +-------------------+ +-------------------+ | ROADM Node | | ROADM Node | | | | | | PA +-------+ BA | ILA | PA +-------+ BA | | +-+ | WSS/ | +-+ | _____ +--+ _____ | +-+ | WSS/ | +-+ | --|-| |-|Filter |-| |-|-()____)-| |-()____)-|-| |-|Filter |-| |-|-- | +-+ | | +-+ | +--+ | +-+ | | +-+ | | +-------+ | optical | +-------+ | | | | | | fiber | | | | | | o o o | | o o o | | transponders | | transponders | +-------------------+ +-------------------+ OTS Link OTS Link <---------> <---------> OMS Link <--------------------------------> PA: Pre-Amplifieror BA: Booster Amplifier ILA: In-Line Amplifier Figure 2: Reference Architecture for Optical Transport Network BA (on the left side ROADM) is the ingress Amplifier and PA (on the right side ROADM is the egress amplifier for the OMS link shown in Figure 2. 2.3. OMS Media Links According to [G.872], OMS Media Link represents a media link between two ROADMs. Specifically, it originates at the ROADM's Filter in the source ROADM and terminates at the ROADM's Filter in the destination ROADM. OTS Media Link represents a media link: (i) between ROADM's BA and ILA; (ii) between a pair of ILAs; (iii) between ILA and ROADM's PA. OMS Media link can be decomposed in a sequence of OTS links type (i), (ii), and (iii) as discussed above. OMS Media link would give an abstracted view of impairment data (e.g., power, OSNR, etc.) to the network controller. Lee, et al. Expires January 9, 2022 [Page 7] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 For the sake of optical impairment evaluation OMS Media link can be also decomposed in a sequence of elements such as BA, fiber section, ILA, concentrated loss and PA. [Editor's note: text below related to [G.807] needs to be revised! [G.807] is now in publication process.] 2.3.1. Optical Tributary Signal (OTSi) The OTSi is defined in ITU-T Recommendation G.959.1, section 3.2.4 [G.959.1]. The YANG model defined below assumes that a single OTSi consists of a single modulated optical carrier. This single modulated optical carrier conveys digital information. Characteristics of the OTSi signal are modulation scheme (e.g. QPSK, 8-QAM, 16-QAM, etc.), baud rate (measure of the symbol rate), pulse shaping (e.g. raised cosine - complying with the Nyquist inter symbol interference criterion), etc. 2.3.2. Optical Tributary Signal Group (OTSiG) The definition of the OTSiG is currently being moved from ITU-T Recommendation G.709 [G.709] to the new draft Recommendation G.807 (still work in progress) [G.807]. The OTSiG is an electrical signal that is carried by one or more OTSi's. The relationship between the OTSiG and the the OTSi's is described in ITU-T draft Recommendation G.807, section 10.2 [G.807]. The YANG model below supports both cases: the single OTSi case where the OTSiG contains a single OTSi (see ITU-T draft Recommendation G.807, Figure 10-2) and the multiple OTSi case where the OTSiG consists of more than one OTSi (see ITU-T draft Recommendation G.807, Figure 10-3). From a layer 0 topology YANG model perspective, the OTSiG is a logical construct that associates the OTSi's, which belong to the same OTSiG. The typical application of an OTSiG consisting of more than one OTSi is inverse multiplexing. Constraints exist for the OTSi's belonging to the same OTSiG such as: (i) all OTSi's must be co-routed over the same optical fibers and nodes and (ii) the differential delay between the different OTSi's may not exceed a certain limit. Example: a 400Gbps client signal may be carried by 4 OTSi's where each OTSi carries 100Gbps of client traffic. Lee, et al. Expires January 9, 2022 [Page 8] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 OTSiG _________________________/\__________________________ / \ m=7 - - - +---------------------------X---------------------------+ - - - / / / | | / / / / / /| OTSi OTSi OTSi OTSi |/ / / / / / | ^ ^ ^ ^ | / / / / / /| | | | | |/ / / / / / | | | | | | / / / / / /| | | | | |/ / / -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- n = 4 K1 K2 K3 K4 Figure 3: MC Example containing all 4 OTSi signals of an OTSiG 2.3.3. Media Channel (MC) The definition of the MC is currently being moved from ITU-T Recommendation G.872 [G.872] to the new draft Recommendation G.807 (still work in progress) [G.807]. Section 3.2.2 defines the term MC and section 7.1.2 provides a more detailed description with some examples. The definition of the MC is very generic (see ITU-T draft Recommendation G.807, Figure 7-1). In the YANG model below, the MC is used with the following semantics: The MC is an end-to-end topological network construct and can be considered as an "optical pipe" with a well-defined frequency slot between one or more optical transmitters each generating an OTSi and the corresponding optical receivers terminating the OTSi's. If the MC carries more than one OTSi, it is assumed that these OTSi's belong to the same OTSiG. Lee, et al. Expires January 9, 2022 [Page 9] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 m=8 +-------------------------------X-------------------------------+ | | | | +----------X----------+ | +----------X----------+ | | | OTSi | | OTSi | | | | ^ | | | ^ | | | | | | | | | | -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- | n=4 | K1 K2 <------------------------ Media Channel -----------------------> Figure 4: Figure Caption TBA The frequency slot of the MC is defined by the n value defining the central frequency of the MC and the m value that defines the width of the MC following the flexible grid definition in ITU-T Recommendation G.694.1 [G.694.1]. In this model, the effective frequency slot as defined in ITU-T draft Recommendation G.807 is equal to the frequency slot of this end-to-end MC. It is also assumed that ROADM devices can switch MCs. For various reasons (e.g. differential delay), it is preferred to use a single MC for all OTSi's of the same OTSiG. It may however not always be possible to find a single MC for carrying all OTSi's of an OTSiG due to spectrum occupation along the OTSiG path. 2.3.4. Media Channel Group (MCG) The definition of the MCG is currently work in progress in ITU-T and is defined in section 7.1.3 of the new ITU-T draft Recommendation G.807 (still work in progress) [G.807]. The YANG model below assumes that the MCG is a logical grouping of one or more MCs that are used to to carry all OTSi's belonging to the same OTSiG. The MCG can be considered as an association of MCs without defining a hierarchy where each MC is defined by its (n,m) value pair. An MCG consists of more than one MC when no single MC can be found from source to destination that is wide enough to accommodate all OTSi's (modulated carriers) that belong to the same OTSiG. In such a case the set of OTSi's belonging to a single OTSiG have to be split across 2 or more MCs. Lee, et al. Expires January 9, 2022 [Page 10] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 MCG1 = {M1.1, M1.2} __________________________/\________________________ / \ M1.1 M2 M1.2 ____________/\____________ _____/\_____ ____/\____ / \/ \/ \ - - - +---------------------------+-------------+-----------+ - - - / / / | | / / / / / / | | / / / / / /| OTSi OTSi OTSi |/ / / / / / /| OTSi |/ / / / / / | ^ ^ ^ | / / / / / / | ^ | / / / / / /| | | | |/ / / / / / /| | |/ / / / / / | | | | | / / / / / / | | | / / / / / /| | | | |/ / / / / / /| | |/ / / -7 -4 -1 0 1 2 3 4 5 6 7 8 ... 14 17 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ n=0 n=17 K1 K2 K3 K4 Figure 5: Figure Caption TBA The MCG is relevant for path computation because all end-to-end MCs belonging to the same MCG have to be co-routed, i.e., have to follow the same path. Additional constraints may exist (e.g. differential delay). 2.4. Amplifiers Optical amplifiers are in charge of amplifying the optical signal in the optical itself without any electrical conversion. There are three main technologies to build amplifiers: Erbium Doped Fiber Amplifier (EDFA), Raman Fiber Amplifier (RFA), and Semiconductor Optical Amplifier (SOA). Nowadays, most of optical networks uses EDFAs. However, RFA has an attractive feature that it works in any wavelength band with a similar or lower noise figures compared to EDFA. On the other hand, RFAs consumes more power and are more expensive than EDFAs. Amplifiers can be classified according to their location in the communication link. There are three basic types of amplifiers: ILA, Pre-Amplifier and Booster. ILA is In-Line Amplifier which is a separate node type while Pre-Amplifier and Booster Amplifier are integral elements of ROADM node. From a data modeling perspective, Pre-Amplifier and Booster Amplifier are internal functions of a ROADM node and as such these elements are hidden within ROADM node. In this document, we would avoid internal node details, but attempt to abstract as much as possible. Lee, et al. Expires January 9, 2022 [Page 11] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021quot;stateful PCE" and "active PCE" as advocated in [RFC7399]. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Procedures for PCE Use of Flow Specifications There are three elements of procedure: o A PCE and a PCC must be able to indicate whether or not they support the use of Flow Specifications. o A PCE or PCC must be able to include Flow Specifications in PCEP messages with clear understanding of the applicability of those Flow Specifications in each case including whether the use of such information is mandatory, constrained, or optional, and how overlapping Flow Specifications will be resolved. Dhody, et al. Expires January 2, 2019 [Page 4] Internet-Draft PCEP-FlowSpec July 2018 o Flow Specification information/state must be synchronized between PCEP peers so that, on recovery, the peers have the same understanding of which Flow Specifications apply. The following subsections describe these points. 3.1. Capability Advertisement As with most PCEP capability advertisements, the ability to support Flow Specifications can be indicated in the PCEP OPEN message or in IGP PCE capability advertisements. 3.1.1. PCEP OPEN Message During PCEP session establishment, a PCC or PCE that supports the procedures described in this document announces this fact by including the "PCE FlowSpec Capability" TLV (described in Section 4) in the OPEN Object carried in the PCEP Open message. The presence of the PCE FlowSpec Capability TLV in the OPEN Object in a PCE's OPEN message indicates that the PCE can distribute FlowSpecs to PCCs and can receive FlowSpecs in messages from the PCCs. The presence of the PCE FlowSpec Capability TLV in the OPEN Object in a PCC's OPEN message indicates that the PCC supports the FlowSpec functionality described in this document. If either one of a pair of PCEP peers does not indicate support of the functionality described in this document by not including the PCE FlowSpec Capability TLV in the OPEN Object in its OPEN message, then the other peer MUST NOT include a FlowSpec object in any PCEP message sent to the peer that does not support the procedures. If a FlowSpec object is received even though support has not been indicated, the receiver will respond with a PCErr message reporting the objects containing the FlowSpec as described in [RFC5440]: that is, it will use 'Unknown Object' if it does not support this specification, and 'Not supported object' if it supports this specification but has not chosen to support FlowSpec objects on this PCEP session. 3.1.2. IGP PCE Capabilities Advertisement The ability to advertise support for PCEP and PCE features in IGP advertisements is provided for OSPF in [RFC5088] and for IS-IS in [RFC5089]. The mechanism uses the PCE Discovery TLV which has a PCE- CAP-FLAGS sub-TLV containing bit-flags each of which indicates support for a different feature. Dhody, et al. Expires January 2, 2019 [Page 5] Internet-Draft PCEP-FlowSpec July 2018 This document defines a new PCE-CAP-FLAGS sub-TLV bit, the FlowSpec Capable flag (bit number TBD1). Setting the bit indicates that an advertising PCE supports the procedures defined in this document. Note that while PCE FlowSpec Capability may be advertised during discovery, PCEP speakers that wish to use Flow Specification in PCEP MUST negotiate PCE FlowSpec Capability during PCEP session setup, as specified in Section 3.1.1. A PCC MAY initiate PCE FlowSpec Capability negotiation at PCEP session setup even if it did not receive any IGP PCE capability advertisement, and a PCEP peer that advertised support for FlowSpec in the IGP is not obliged to support these procedures on any given PCEP session. 3.2. Dissemination Procedures This section describes the procedures to support Flow Specifications in PCEP messages. The primary purpose of distributing Flow Specification information is to allow a PCE to indicate to a PCC what traffic it should place on a path (such as an LSP or an SR path). This means that the Flow Specification may be included in: o PCInitiate messages so that an active PCE can indicate the traffic to place on a path at the time that the PCE instantiates the path. o PCUpd messages so that an active PCE can indicate or change the traffic to place on a path that has already been set up. o PCRpt messages so that a PCC can report the traffic that the PCC plans to place on the path. o PCReq messages so that a PCC can indicate what traffic it plans to place on a path at the time it requests the PCE to perform a computation in case that information aids the PCE in its work. o PCRep messages so that a PCE that has been asked to compute a path can suggest which traffic could be placed on a path that a PCC may be about to set up. o PCErr messages so that issues related to paths and the traffic they carry can be reported to the PCE by the PCC, and so that problems with other PCEP messages that carry Flow Specifications can be reported. To carry Flow Specifications in PCEP messages, this document defines a new PCEP object called the PCEP Flow Spec Object. The object is Dhody, et al. Expires January 2, 2019 [Page 6] Internet-Draft PCEP-FlowSpec July 2018 OPTIONAL in the messages described above and MAY appear more than once in each message. The PCEP Flow Spec Object carries zero or one Flow Filter TLV which describes a traffic flow. The inclusion of multiple PCEP Flow Spec Objects allows multiple traffic flows to be placed on a single path. Once a PCE and PCC have established that they can both support the use of Flow Specifications in PCEP messages, such information may be exchanged at any time for new or existing paths. The application and prioritization of Flow Specifications is described in Section 8.7. 3.3. Flow Specification Synchronization The Flow Specifications are carried along with the LSP State information as per [RFC8231] making the Flow Specifications part of the LSP database (LSP-DB). Thus, the synchronization of the Flow Specification information is done as part of LSP-DB synchronization. This may be achieved using normal state synchronization procedures as described in [RFC8231] or enhanced state synchronization procedures as defined in [RFC8232]. The approach selected will be implementation and deployment specific and will depend on issues such as how the databases are constructed and what level of synchronization support is needed. 4. PCE FlowSpec Capability TLV The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV that can be carried in the OPEN Object [RFC5440] to exchange PCE FlowSpec capabilities of PCEP speakers. The format of the PCE-FLOWSPEC-CAPABILITY TLV follows the format of all PCEP TLVs as defined in [RFC5440] and is shown in Figure 1. Dhody, et al. Expires January 2, 2019 [Page 7] Internet-Draft PCEP-FlowSpec July 2018 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD2 | Length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value=0 | Padding | +---------------------------------------------------------------+ Figure 1: PCE-FLOWSPEC-CAPABILITY TLV format The type of the PCE-FLOWSPEC-CAPABILITY TLV is TBD2 and it has a fixed length of 2 octets. The Value field is set to default value 0. The two bytes of padding MUST be set to zero and ignored on receipt. The inclusion of this TLV in an OPEN object indicates that the sender can perform FlowSpec handling as defined in this document. 5. PCEP Flow Spec Object The PCEP Flow Spec object defined in this document is compliant with the PCEP object format defined in [RFC5440]. It is OPTIONAL in the PCReq, PCRep, PCErr, PCInitiate, PCRpt, and PCUpd messages and MAY be present zero, one, or more times. Each instance of the object specifies a traffic flow. The PCEP Flow Spec object carries a FlowSpec filter rule encoded in a TLV (as defined in Section 6. The FLOW SPEC Object-Class is TBD3 (to be assigned by IANA). The FLOW SPEC Object-Type is 1. The format of the body of the PCEP Flow Spec object is shown in Figure 2 Dhody, et al. Expires January 2, 2019 [Page 8] Internet-Draft PCEP-FlowSpec July 2018 One modeling consideration of the ROADM internal is to model power parameter through the ROADM, factoring the output power from the Pre- Amplifier minus the ROADM power loss would give the input power to the Booster Amplifier. In other words, Power_in (@ ROADM Booster) = Power_out (@ ROADM Pre-Amplifier) - Power_loss (@ ROADM WSS/Filter). 2.5. Transponders [Editor's note: The relationship between the transponder and the OTSi in the YANG model described in Section 3 needs further clarification and refinement.] A Transponder is the element that sends and receives the optical signal from a DWDM network. A transponder can comprise one or more transceivers. A transceiver can be seen as a pair of transmitter and receiver, as defined in ITU-T Recommendation G.698.2 [G.698.2]. A transponder is typically characterized by its data/symbol rate and the maximum distance the signal can travel. Other transponder properties are: carrier frequency for the optical channels, output power per channel, measured input power, modulation scheme, FEC, etc. From a path computation perspective, the selection of the compatible configuration of the source and the destination transceivers is an important factor for optical signals to traverse through the DWDM network. The YANG model defines three different approaches to describe the transceiver capabilities (called "modes") that are needed to determine optical signal compatibility: o Standard Modes o Organizational Modes o Explicit Modes 2.5.1. Standard Modes A standard mode is related to an optical specification developed by an SDO organization. Currently, the "Standard Modes" can only be referred to ITU-T G.698.2 [G.698.2] since G.698.2 is the only specification defining "Standard Modes" today. Nothing is precluding, however, to consider other specifications provided by any other SDO in the Standard Mode context as soon as such sepcifications will be available. An application code as defined in ITU-T G.698.2 [G.698.2] is representing a standard ITU-T G.698.2 optical interface specification towards the realization of transversely compatible DWDM systems. Two transceivers supporting the same application code and a line system matching the constraints, defined in ITU-T G.698.2, for Lee, et al. Expires January 9, 2022 [Page 12] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 that application code will interoperate. As the characteristics are encoded in the application code, the YANG model in this document only defines a string, which represents that application code. 2.5.2. Organizational Modes Organizations like operator groups, industry fora, or equipment vendors can define their own optical interface specifications and make use of transceiver capabilities going beyond existing standards. An organizational mode is identified by the organization-identifier attribute defining the scope and an operational-mode that is meaningful within the scope of the organization. Hence, the two attributes must always be considered together. It is the responsibility of the organization to assign operational modes and to ensure that operational modes are unique and unambiguous within the scope of the organization. Two transceivers can be interconnected, if they have at least one (organization-identifier, operational-mode) pair in common and if the supported carrier frequency and power attributes have a matching range. This is a necessary condition for path computation in the context of organizational modes. An operational mode is a transceiver preset (a configuration with well-defined parameter values) subsuming several transceiver properties defined by the optical interface specification - these properties are not provided for anoperational mode and are therefore not defined in the YANG model. Examples of these properties are: o FEC type o Modulation scheme o Encoding (mapping of bit patterns (code words) to symbols in the constellation diagram) o Baud rate (symbol rate) o Carrier bandwidth (typically measured in GHz) The major reason for these transceiver presets is the fact that the attribute values typically cannot be configured independently and are therefore advertised as supported operational mode capabilities. It is the responsibility of the organization to assign operational modes and to ensure that operational modes are unique and not ambiguous within the scope of the organization. In addition to the transceiver properties subsumed by the operational mode, optical power and carrier frequency related properties are modeled separately, i.e., outside of the operational mode. This modeling approach allows transponders using different transceiver Lee, et al. Expires January 9, 2022 [Page 13] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 variants (e.g. optical modules) with slightly different power and/or frequency range properties to interoperate without defining separate operational modes. Different optical modules (pluggables) from different suppliers typically have slightly different input and output power ranges or may have slightly different carrier frequency tuning ranges. The received channel power and the received total power are two parameters that can be measured by the receiver and can be provided by the transceiver in order to allow a controller to determine the expected performance of the end-to-end service taking into account the optical impairments along the path. An organization may define the operational modes to include the optical power and carrier frequency related properties following the application code approach as defined in ITU-T Recommendation G.698.2 [G.698.2]. In such a case, the explicit optical power and carrier frequency related optional attributes shall be omitted in order to avoid redundant information in the description of the transceiver capabilities. If these attributes are provided in addition to the operational modes including these attribute values implicitly, the parameter values provided explicitly replace the implicit values and take precedence. This shall, however, only be an done in exceptional cases and shall be avoided whenever possible. In case an implicitly given range is extended utilizing the explicit optional attributes, a path computation policy rule may be applied to select a value preferably from the range defined implicitly and to only select a value from the extended range if no path can be found for values in the implicitly defined range. Path computation policy is outside the scope of this topology YANG model. In summary, the optical power and carrier frequency related attributes shall either be described implicitly by the operational mode following the definition provided by that organization or shall be described explicitly when the optical power and carrier frequency related properties are not included in the operational mode definition. 2.5.3. Explicit Modes The explicit mode allows to encode, explicitly, any subset of parameters e.g., FEC type, Modulation type, etc, to enable a controller entity to check for interoperability by means outside of this draft. It shall be noted that using the explicit encoding does not guarantee interoperability between two transceivers even in case of identical parameter definitions. The explicit mode shall therefore be used with care, but it could be useful when no common Application Codes or Organizational Modes exist or the constraints of Lee, et al. Expires January 9, 2022 [Page 14] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 common Application Codes or Organizational Modes cannot be met by the line system. 2.5.4. Transponder Capabilities and Current Configuration The YANG model described in Section 3 defines the optical transceiver properties. They are divided between: a. Optical transceiver capabilities, describing how it can be configured b. Current transceiver setting, indicating how it is currently configured The transceiver capabilities are described by the set of modes the transceiver is supporting. Each mode MUST follow only one of the three mode options defined above (choice in the YANG model). The YANG model allows to describe the transceiver capabilities by mixing different modes. A transceiver may support some ITU-T application codes and in addition some organizational or explicit modes. A transceiver mode description comprises the following properties: o Supported transmitter tuning range with min/max nominal carrier frequency [f_tx_min, f_tx_max] o Supported transmitter tunability grid, the distance between two adjacent carrier frequencies (in GHz) o Supported transmitter power range [p_tx-min, p_tx_max] o Supported receiver channel power range [p_rx-min, p_rx_max] o Supported maximum total power, rx power for all channels fed into the receiver These optical transceiver properties are explicitly defined in the model for explicit and organizational modes, while they are implicitly defined for the application codes (see ITU-T G698.2 [G.698.2]). The set of optical impairment limits, e.g., min OSNR, max PMD, max CD, max PDL, Q-factor limit, are explicitly defined for the explicit modes while they are defined implicitly for the application codes and organizational modes. It is possible that the set of parameter values defined for an explicit mode may also be represented in form of an organizational mode or one or more application codes. The "supported-mode" container may provide two different lists with pointers to application codes and organizational modes, respectively. Lee, et al. Expires January 9, 2022 [Page 15] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 The current transponder configuration describes the properties of the OTSi transmitted or received by the transceiver attached to a specific transponder port. Each OTSi has the following three pointer attributes modeled as leafrefs: o Pointer to the transponder instance containing the transceiver terminating the OTSi o Pointer to the transceiver instance terminating the OTSi o Pointer to the currently configured transceiver mode Additionally, the OTSi is described by the following frequency and optical power related attributes: o current carrier-frequency o currently transmitted channel power o currently received channel power o currently received total power 2.6. 3R Regenerators Optical transponders are usually used to terminate a layer 0 tunnel (layer 0 service) in the WDM layer. If, however, no optical path can be found from the source transponder to the destination transponder that is optically feasible due to the optical impairments, one or more 3R regenerators are needed for regenerating the optical signal in intermediate nodes. The term "3R" regenerator means: reamplification, reshaping, retiming. As described in [G.807], Appendix IV, a 3R regenerator terminates the OTSi and generates a new OTSi. Depending on the 3R regenerator capabilities, it can provide functions such as carrier frequency translation (carrier-frequency), changes in the modulation scheme (modulation-type) and FEC (FEC-type) while passing through the digital signal except the FEC (the FEC is processed and errors are corrected). The 3R regeneartion compound function is illustrated in section 10.1 of [G.798.1], and sections 10.3 and 10.4 provide examples of a ROADM architecture and a photonic cross-connect architecture including 3R regenerators. Based on the provided functionality, 3R regenerators are considered as topological layer 0 entities because they are needed for layer 0 path computation in case the optical impairments make it impossible to find an optically feasible end-to-end path from the source transponder to the destination transponder without 3R regeneration. When an end-to-end path includes one or more 3R regenerators, the corresponding layer 0 tunnel is subdivided into 2 or more segments between the source transponder and the destination transponder terminating the layer 0 tunnel. Lee, et al. Expires January 9, 2022 [Page 16] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 3R regenerators are usually realized by a pair of optical transponders, which are described in Section 2.5 above. If a pair of optical transponders is used to perform a 3R regeneratator function, two different configurations are possible involving the pair of optical transceivers of the two optical transponders: o The two transponders can be operated in a back-to-back configuration where the transceiver of each optical transponder receives and transmits the optical signal from/to the same segment of the end-to-end tunnel. This means that each transceiver is operated in a bi-directional mode. Optical Transponder 1 Optical Transponder 2 +-----------------------+ +-----------------------+ | Transceiver | | Transceiver | |-------------+ +-----| |-----+ +-------------| --->| Receiver |---|Sig. |--->|Sig. |---| Transmitter |---> |-------------+ | | | | +-------------| <---| Transmitter |---|Proc.|<---|Proc.|---| Receiver |&0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FS-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Flow Filter TLV (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: PCEP Flow Spec Object Body Format FS-ID (32-bits): A PCEP-specific identifier for the FlowSpec information. A PCE or PCC creates an FS-ID for each FlowSpec that it originates, and the value is unique within the scope of that PCE or PCC and is constant for the lifetime of a PCEP session. All subsequent PCEP messages can identify the FlowSpec using the FS-ID. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. Reserved bits: MUST be set to zero on transmission and ignored on receipt. R bit: The Remove bit is set when a PCEP Flow Spec Object is included in a PCEP message to indicate removal of the Flow Specification from the associated tunnel. If the bit is clear, the Flow Specification is being added or modified. Flow Filter TLV (variable): One TLV MAY be included. The Flow Filter TLV is OPTIONAL when the R bit is set. The TLV MUST be present when the R bit is clear. If the TLV is missing when the R bit is clear, the PCEP peer MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), error-value 2 (Malformed FlowSpec). 6. Flow Filter TLV A new PCEP TLV is defined to convey Flow Specification filtering rules that specify what traffic is carried on a path. The TLV follows the format of all PCEP TLVs as defined in [RFC5440]. The Type field values come from the codepoint space for PCEP TLVs and has the value TBD4. The Value field contains one or more sub-TLVs (the Flow Specification TLVs) as defined in Section 7. Only one Flow Filter TLV can be present and represents the complete definition of a Flow Dhody, et al. Expires January 2, 2019 [Page 9] Internet-Draft PCEP-FlowSpec July 2018 Specification for traffic to be placed on the tunnel indicated by the PCEP message in which the PCEP Flow Spec Object is carried. The set of Flow Specification TLVs in a single instance of a Flow Filter TLV are combined to indicate the specific Flow Specification. Further Flow Specifications can be included in a PCEP message by including additional Flow Spec objects. 7. Flow Specification TLVs The Flow Filter TLV carries one or more Flow Specification TLV. The Flow Specification TLV follows the format of all PCEP TLVs as defined in [RFC5440], however, the Type values are selected from a separate IANA registry (see Section 10) rather than from the common PCEP TLV registry. Type values are chosen so that there can be commonality with Flow Specifications defined for use with BGP. This is possible because the BGP Flow Spec encoding uses a single octet to encode the type where PCEP uses two octets. Thus the space of values for the Type field is partitioned as shown in Figure 3. Range | ---------------+--------------------------------------------------- 0 | Reserved - must not be allocated. | 1 .. 255 | Per BGP registry defined by [RFC5575]. | Not to be allocated in this registry. | 256 .. 65535 | New PCEP Flow Specifications allocated according | to the registry defined in this document. Figure 3: Flow Specification TLV Type Ranges The content of the Value field in each TLV is specific to the type and describes the parameters of the Flow Specification. The definition of the format of many of these Value fields is inherited from BGP specifications as shown in Figure 4. Specifically, the inheritance is from [RFC5575] and [I-D.ietf-idr-flow-spec-v6], but may also be inherited from future BGP specifications. When multiple Flow Specification TLVs are present in a single Flow Filter TLV they are combined to produce a more detailed description of a flow. For examples and rules about how this is achieved, see [RFC5575]. Dhody, et al. Expires January 2, 2019 [Page 10] Internet-Draft PCEP-FlowSpec July 2018 An implementation that receives a PCEP message carrying a Flow Specification TLV with a type value that it does not recognize or does not support MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), error-value 1 (Unsupported FlowSpec) and MUST NOT install the Flow Specification. When used in other protocols (such as BGP) these Flow Specifications are also associated with actions to indicate how traffic matching the Flow Specification should be treated. In PCEP, however, the only action is to associate the traffic with a tunnel and to forward matching traffic on to that path, so no encoding of an action is needed. Section 8.7 describes how overlapping Flow Specifications are prioritized and handled. Dhody, et al. Expires January 2, 2019 [Page 11] Internet-Draft PCEP-FlowSpec July 2018 +-------+-------------------------+-----------------------------+ | Type | Description | Value defined in | | | | | +-------+-------------------------+-----------------------------+ | * | Destination IPv4 Prefix | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | Source IPv4 Prefix | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | IP Protocol | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | Port | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | Destination port | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | Source port | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | ICMP type | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | ICMP code | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | TCP flags | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | Packet length | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | DSCP | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | Fragment | [RFC5575] | +-------+-------------------------+-----------------------------+ | * | Flow Label | [I-D.ietf-idr-flow-spec-v6] | +-------+-------------------------+-----------------------------+ | * | Destination IPv6 Prefix | [I-D.ietf-idr-flow-spec-v6] | +-------+-------------------------+-----------------------------+ | * | Source IPv6 Prefix | [I-D.ietf-idr-flow-spec-v6] | +-------+-------------------------+-----------------------------+ | * | Next Header | [I-D.ietf-idr-flow-spec-v6] | +-------+-------------------------+-----------------------------+ | TBD5 | Route Distinguisher | [I-D.dhodylee-pce-pcep-ls] | +-------+-------------------------+-----------------------------+ | TBD6 | IPv4 Multicast Flow | [This.I-D] | +-------+-------------------------+-----------------------------+ | TBD7 | IPv6 Multicast Flow | [This.I-D] | +-------+-------------------------+-----------------------------+ * Indicates that the TLV Type value comes from the value used in BGP. Figure 4: Table of Flow Specification TLV Types Dhody, et al. Expires January 2, 2019 [Page 12] Internet-Draft PCEP-FlowSpec July 2018 All Flow Specification TLVs with Types in the range 1 to 255 have Values defined for use in BGP (for example, in [RFC5575] and [I-D.ietf-idr-flow-spec-v6]) and are set using the BGP encoding, but without the type or length octets (the relevant information is in the Type and Length fields of the TLV). The Value field is padded with trailing zeros to achieve 4-byte alignment. [I-D.dhodylee-pce-pcep-ls] defines a way to convey identification of a VPN in PCEP via a Route Distinguisher (RD) [RFC4364] encoded in ROUTE-DISTINGUISHER TLV. A Flow Specification TLV with Type TBD5 carries a Value field matching that present in the ROUTE- DISTINGUISHER TLV and is used to identify that other flow filter information (for example, an IPv4 destination prefix) is associated with a specific VPN identified by the RD. See Section 8.6 for further discussion of VPN identification. Although it may be possible to describe a multicast Flow Specification from the combination of other Flow Specification TLVs with specific values, it is more convenient to use a dedicated Flow Specification TLV. Flow Specification TLVs with Type values TBD6 and TBD7 are used to identify a multicast flow for IPv4 and IPv6 respectively. The Value field is encoded as shown in Figure 5. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd |S|W|R| Rsvd |B|Z| Src Mask Len | Grp Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Source Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Group multicast Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Multicast Flow Specification TLV Encoding The fields of the two Multicast Flow Specification TLVs are as described in Section 4.9.1 of [RFC7761] noting that the two address fields are 32 bits for the IPv4 Multicast Flow and 128 bits for the IPv6 Multicast Flow. Reserved fields (RSVD) MUST be set to zero and ignored on receipt. 8. Detailed Procedures This section outlines some specific detailed procedures for using the protocol extensions defined in this document. Dhody, et al. Expires January 2, 2019 [Page 13] Internet-Draft PCEP-FlowSpec July 2018 8.1. Default Behavior and Backward Compatibility The default behavior is that no Flow Specification is applied to a tunnel. That is, the default is that the Flow Spec object is not used as is the case in all systems before the implementation of this specification. In this case it is a local matter (such as through configuration) how tunnel head ends are instructed what traffic to place on a tunnel. [RFC5440]describes how receivers respond when they see unknown PCEP objects. 8.2. Composite Flow Specifications Flow Specifications may be represented by a single Flow Specification TLV or may require a more complex description using multiple Flow Specification TLVs. For example, a flow indicated by a source- destination pair of IPv6 addresses would be described by the combination of Destination IPv6 Prefix and Source IPv6 Prefix Flow Specification TLVs. 8.3. Modifying Flow Specifications A PCE may want to modify a Flow Specification associated with a tunnel, or a PCC may want to report a change to the Flow Specification it is using with a tunnel. It is important that the specific Flow Specification is identified so that it is clear that this is a modification of an existing flow and not the addition of a new flow as described in Section 8.4. The FS- ID field of the PCEP Flow Spec Object is used to identify a specific Flow Specification. When modifying a Flow Specification, all Flow Specification TLVs for the intended specification of the flow MUST be included in the PCEP Flow Spec Object and the FS-ID MUST be retained from the previous description of the flow. 8.4. Multiple Flow Specifications It is possible that multiple flows will be place on a single tunnel. In some cases it is possible to to define these within a single PCEP Flow Spec Object: for example, two Destination IPv4 Prefix TLVs could be included to indicate that packets matching either prefix are acceptable. PCEP would consider this as a single Flow Specification identified by a single FS-ID. Dhody, et al. Expires January 2, 2019 [Page 14] Internet-Draft PCEP-FlowSpec July 2018 In other scenarios the use of multiple Flow Specification TLVs would be confusing. For example, if flows from A to B and from C to D are to be included then using two Source IPv4 Prefix TLVs and two Destination IPv4 Prefix TLVs would be confusing (are flows from A to D included?). In these cases, each Flow Specification is carried in its own PCEP Flow Spec Object with multiple objects present on a single PCEP message. Use of separate objects also allows easier removal and modification of Flow Specifications. 8.5. Adding and Removing Flow Specifications The Remove bit in the the PCEP Flow Spec Object is left clear when a Flow Specification is being added or modified. To remove a Flow Specification, a PCEP Flow Spec Object is included with the FS-ID matching the one being removed, and the R bit set to indicate removal. In this case it is not necessary to include any Flow Specification TLVs. If the R bit is set and Flow Specification TLVs are present an implementation MAY ignore them. If the implementation checks the Flow Specification TLVs against those recorded for the FS-ID of the Flow Specification being removed and finds a mismatch, the Flow Specification MUST still be removed and the implementation SHOULD record a local exception or log. 8.6. VPN Identifiers VPN instances are identified in BGP using Route Distinguishers (RDs) [RFC4364]. These values are not normally considered to have any meaning outside of the network, and they are not encoded in data packets belonging to the VPNs. However, RDs provide a useful way of identifying VPN instances and are often manually or automatically assigned to VPNs as they are provisioned. Thus the RD provides a useful way to indicate that traffic for a particular VPN should be placed on a given tunnel. The tunnel head end will need to interpret this Flow Specification not as a filter on the fields of data packets, but using the other mechanisms that it already uses to identify VPN traffic. This could be based on the incoming port (for port-based VPNs) or may leverage knowledge of the VRF that is in use for the traffic. 8.7. Priorities and Overlapping Flow Specifications TBD Dhody, et al. Expires January 2, 2019 [Page 15] Internet-Draft PCEP-FlowSpec July 2018 An implementation that receives a PCEP message carrying a Flow Specification that it cannot resolve against other Flow Specifications already installed MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), error-value 3 (Unresolvable conflict) and MUST NOT install the Flow Specification. 9. PCEP Messages The figures in this section use the notation defined in [RFC5511]. The FLOW SPEC Object is OPTIONAL and MAY be carried in the PCEP messages. The PCInitiate message is defined in [RFC8281] and updated as below: <PCInitiate Message> ::= <Common Header> <PCE-initiated-lsp-list> Where: <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> [<PCE-initiated-lsp-list>] <PCE-initiated-lsp-request> ::= ( <PCE-initiated-lsp-instantiation>| <PCE-initiated-lsp-deletion> ) <PCE-initiated-lsp-instantiation> ::= <SRP> <LSP> [<END-POINTS>] <ERO> [<attribute-list>] [<flowspec-list>] Where: <flowspec-list> ::= <FLOWSPEC> [<flowspec-list>] The PCUpd message is defined in [RFC8231] and updated as below: Dhody, et al. Expires January 2, 2019 [Page 16] Internet-Draft PCEP-FlowSpec July 2018 <PCUpd Message> ::= <Common Header> <update-request-list> Where: <update-request-list> ::= <update-request> [<update-request-list>] <update-request> ::= <SRP> <LSP> <path> [lt;--- |-------------+ +-----| |-----+ +-------------| | | | | +-----------------------+ +-----------------------+ Sig. Proc. = Signal Processing Figure 6: Back-to-back 3R Regenerator Example o The two transponders can be operated in a configuration where each transponder performs the 3R regeneration function in one direction, one in forward direction (from source to destination) and the other in the reverse direction. In this configuration, the transceiver of each optical transponder receives the signal from one segment and transmits the regenerated optical signal into the adjacent segment. This configuration is also called cross- regeneration and each transceiver is operated in an uni- directional mode. Lee, et al. Expires January 9, 2022 [Page 17] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 Optical Transponder 1 +-----------------------------+ | Transceiver | |-------------+ +---------+ | --->| Receiver |---|Sig. --+ | | |-------------+ | | | | <---| Transmitter |---|Proc.<-+ | | |-------------+ +---------+ | | | +-----------------------------+ 3R in forward direction Optical Transponder 2 +-----------------------------+ | Transceiver | |-------------+ +---------+ | --->| Receiver |---|Sig. --+ | | |-------------+ | | | | <---| Transmitter |---|Proc.<-+ | | |-------------+ +---------+ | | | +-----------------------------+ 3R in reverse direction Sig. Proc. = Signal Processing Figure 7: Cross-3R Regenerator Example Due to the fact that 3R regenerators are composed of an optical transponder pair, the capabilitiy whether an optical transponder can be used as a 3R regenerator is is added to the transponder capabilities. Hence, no additional entity is required for describing 3R regenerators in the TE-topology YANG model. The optical transonder capabilities regarding the 3R regenerator function are described by the following two YANG model attributes: o supported-termination-type o supported-3r-mode The supported-termination-type attribute describes whether the optical transponder can be used as tunnel terminating transponder only, as 3R regenerator only, or whether it can support both functions. The supported-3r-mode attrbute describes the configuration of the transponder pair forming the 3R regeneartor as described above. Lee, et al. Expires January 9, 2022 [Page 18] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 More text to be added here! 2.7. WSS/Filter WSS separates the incoming light input spectrally as well as spatially, then chooses the wavelength that is of interest by deflecting it from the original optical path and then couple it to another optical fibre port. WSS/Filter is internal to ROADM. So this document does not model the inside of ROADM. 2.8. Optical Fiber There are various optical fiber types defined by ITU-T. There are several fiber-level parameters that need to be factored in, such as, fiber-type, length, loss coefficient, pmd, connectors (in/out). ITU-T G.652 defines Standard Singlemode Fiber; G.654 Cutoff Shifted Fiber; G.655 Non-Zero Dispersion Shifted Fiber; G.656 Non-Zero Dispersion for Wideband Optical Transport; G.657 Bend-Insensitive Fiber. There may be other fiber-types that need to be considered. 2.9. ROADM Node Architectures The ROADM node architectures in today's dense wavelength division multiplexing (DWDM) networks can be categorized as follows: o Integrated ROADM architecture with integrated optical transponders o Integrated ROADM architecture with integrated optical transponders and single channel add/drop ports for remote optical transponders o Disaggregated ROADM architecture where the ROADM is subdivided into degree, add/drop, and optical transponder subsystems handled as separate network elements The TE topology YANG model augmentations including optical impairments for DWDM networks defined below intend to cover all the 3 categories of ROADM architectures listed above. In the case of a disaggregated ROADM architecture, it is assumed that optical domain controller already performs some form of abstraction and presents the TE-node representing the disaggregated ROADM in the same way as an integrated ROADM with integrated optical transponders if the optical transponder subsystems and the add/drop subsystems are collocated (short fiber links not imposing significant optical impairments). The different ROADM architectures are briefly described and illustrated in the following subsections. Lee, et al. Expires January 9, 2022 [Page 19] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 [Editor's note: The modeling of remote optical transponders located for example in the client device with a single channel link between the OT and the add/drop port of the ROADM requires further investigations and will be addressed in a future revision of this document.] 2.9.1. Integrated ROADM Architecture with Integrated Optical Transponders Figure 2 and Figure 8 below show the typical architecture of an integrated ROADM node, which contains the optical transponders as an integral part of the ROADM node. Such an integrated ROADM node provides DWDM interfaces as external interfaces for interconnecting the device with its neighboring ROADMs (see OTS link above). The number of these interfaces denote also the degree of the ROADM. A degree 3 ROADM for example has 3 DWDM links that interconnect the ROADM node with 3 neighboring ROADMs. Additionally, the ROADM provides client interfaces for interconnecting the ROADM with client devices such as IP routers or Ethernet switches. These client interfaces are the client interfaces of the integrated optical transponders. . . . . . . . . . . . . . . . . . . +-----.-------------------------------- .-----+ | . ROADM . | | . /| +-----------------+ |\ . | Line | . / |--| |--| \ . | Line WEST | /| . | |--| |--| | . |\ | EAST ------+-/ |-.-| |--| OCX |--| |-.-| \-+----- ------+-\ |-.-| |--| |--| |-.-| /-+----- | \| . | |--| |--| | . |/ | | . \ |--| |--| / . | | . \| +-----------------+ |/ . | | . . | | . +---+ +---+ +---+ +---+ . | | . | O | | O | | O | | O | . | | . | T | | T | | T | | T | . | | . +---+ +---+ +---+ +---+ . | | . | | | | | | | | . | +-----.------+-+---+-+---+-+---+-+------.-----+ . . . .|.| . |.| . |.| . |.|. . . . | | | | | | | | TE Node Client Interfaces Figure 8: ROADM Architectiure with Integrated Transponders Lee, et al. Expires January 9, 2022 [Page 20] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 2.9.2. Integrated ROADMs with Integrated Optical Transponders and Single Channel Add/Drop Interfaces for Remote Optical Transponders Figure 9 below shows the extreme case where all optical transponders are not integral parts of the ROADM but are separate devices that are interconnected with add/drop ports of the ROADM. If the optical transponders and the ROADM are collocated and if short single channel fiber links are used to interconnect the optical transponders with an add/drop port of the ROADM, the optical domain controller may present these optical transponders in the same way as integrated optical transponders. If, however, the optical impairments of the single channel fiber link between the optical transponder and the add/drop port of the ROADM cannot be neglected, it is necessary to represent the fiber link with its optical impairments in the topology model This also implies that the optical transponders belong to a separate TE node [Editor's note: this requires further study]. . . . . . . . . . . . . . . . . . . . Abstracted ROADM . +-----.-------------------------------- .-----+ | . ROADM . | | . /| +-----------------+ |\ . | Line | . / |--| |--| \ . | Line WEST | /| . | |--| |--| | . |\ | EAST ------+-/ |-.-| |--| OCX |--| |-.-| \-+----- ------+-\ |-.-| |--| |--| |-.-| /-+----- | \| . | |--| |--| | . |/ | | . \ |--| |--| / . | | . \| +-----------------+ |/ . | +-----.---------|----|---|----|---------.-----| Colored OT . +-+ ++ ++ +-+ . line I/F . | | | | . . +---+ +---+ +---+ +---+ . . | O | | O | | O | | O | . . | T | | T | | T | | T | . . +---+ +---+ +---+ +---+ . . . . .|.| . |.| . |.| . |.|. . . . | | | | | | | | TE Node Client Interfaces Figure 9: ROADM Architectiure with Remote Transponders Lee, et al. Expires January 9, 2022 [Page 21] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 2.9.3. Disaggregated ROADMs Subdivided into Degree, Add/Drop, and Optical Transponder Subsystems Recently, some DWDM network operators started demanding ROADM subsystems from their vendors. An example is the OpenROADM project where multiple operators and vendors are developing related YANG models. The subsystems of a disaggregated ROADM are: single degree subsystems, add/drop subsystems and optical transponder subsystems. These subsystems separate network elements and each network element provides a separate management and control interface. The subsystems are typically interconnected using short fiber patch cables and form together a disaggregated ROADM node. This disaggregated ROADM architecture is depicted in Figure 10 below. As this document defines TE topology YANG model augmentations [RFC8795] for the TE topology YANG model provided at the north-bound interface of the optical domain controller, it is a valid assumption that the optical domain controller abstracts the subsystems of a disaggregated ROADM and presents the disaggregated ROADM in the same way as an integrated ROADM hiding all the interconnects that are not relevant from an external TE topology view. Lee, et al. Expires January 9, 2022 [Page 22] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 . . . . . . . . . . . . . . . . . . . Abstracted ROADM . +-----.----------+ +----------.-----+ | Degree 1 | | Degree 2 | Line | . +-----+ | + +-----+ . | Line 1 | /| . | W |-|------------|-| W | . |\ | 2 -----+-/ |-.--| S ******** ******** S |--.-| \-+----- -----+-\ |-.--| S | | * * | | S |--.-| /-+----- | \| . | |-|-+ * * +-|-| | . |/ | | . +-+-+-+ | | * * | | +-+-+-+ . | +-----.----|-----+ | * * | +-----|----.-----+ . | | * * | | . +-----.----|-----+ | * * | +-----|----.-----+ | Degree 4 | | | * * | | | Degree 3 | Line | . +-----+ | | * * | | +-----+ . | Line 4 | /| . | W |-|-|--*--*--+ | | W | . |\ | 3 -----+-/ |-.--| S | | +--*--*----|-| S |--.-| \-+----- -----+-\ |-.--| S |-|----*--*----|-| S |--.-| /-+----- | \| . | | | * * | | | . |/ | | . +--*--+ | * * | +--*--+ . | +-----.-----*----+ * * +----*-----.-----+ . * * * * . . +--*---------*--*---------*--+ . . | ADD | . . | DROP | . . +----------------------------+ . Colored OT . | | | | . Line I/F . +---+ +---+ +---+ +---+ . . | O | | O | | O | | O | . . | T | | T | | T | | T | . . +---+ +---+ +---+ +---+ . . . .|.| . |.| . |.| . |.|. . . | | | | | | | | TE Node Client Interfaces Figure 10: Disaggregated ROADM Architecture with Remote Transponders 2.9.4. Optical Impairments Imposed by ROADM Nodes When an optical OTSi signal traverses a ROADM node, optical impairments are imposed on the signal by various passive or active optical components inside the ROADM node. Examples of optical impairments are: o Chromatic dispersion (CD) o Polarization mode dispersion (PMD) o Polarization dependent loss (PDL) Lee, et al. Expires January 9, 2022 [Page 23] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 o Optical amplifier noise due to amplified spontaneous emission (ASE) o In-band cross-talk o Filtering effects (for further study) A ROADM node contains a wavelength selective photonic switching function (WSS)that is capable of switching media channels (MCs) described in Section 2.3.4. These MCs can be established between two line ports of the ROADM or between a line port and an Add/Drop port of the ROADM. The Add/Drop ports of a ROADM are those ports to which optical transponders are connected. Typically, this is a single channel signal (single OTSi), but principally this could also be a group of OTSi signals. The optical impairments associated with these MCs are different and the paths of the MCs inside the ROADM node can be categorized as follows: o Express path: MC path between two line ports of the ROADM (unidirectional) o Add Path: MC path from an Add port to a line port of the ROADM o Drop path: MC path from a line port to a Drop port of the ROADM Due to the symmetrical architecture of the ROADM node, the optical impairments associated with the express path are typically the same between any two line ports of the ROADM whereas the optical impairments for the add and drop paths are different and therefore have to be modeled separately. The optical impairments associated with each of the three types of ROADM-node-internal paths described above are modeled as optical impairment parameter sets. These parameter sets are modeled as an augmentation of the te-node-attributes defined in [RFC8795]. The te- node-attributes are augmented with a list of roadm-path-impairments for the three ROADM path types distinguished by the impairment-type. Each roadm-path-impairments list entry contains the set of optical impairment parameters for one of the three path types indicated by the impairment-type. For the optical feasibility calculation based on the optical impairments, it is necessary to know whether the optical power of the OTSi stays within a certain power window. This is reflected by some optical power related parameters such as loss parameters or power parameters, which are included in the optical impairment parameter sets (see tree view in Section 3). [RFC8795] defines a connectivity matrix and a local link connectivity list for the TE node. The connectivity matrix describes the connectivity for the express paths between the different lines of the ROADM and the local link connectivity list describes the connectivity Lee, et al. Expires January 9, 2022 [Page 24]<flowspec-list>] Where: <path>::= <intended-path><intended-attribute-list> <flowspec-list> ::= <FLOWSPEC> [<flowspec-list>] The PCRpt message is defined in [RFC8231] and updated as below: <PCRpt Message> ::= <Common Header> <state-report-list> Where: <state-report-list> ::= <state-report>[<state-report-list>] <state-report> ::= [<SRP>] <LSP> <path> [<flowspec-list>] Where: <path>::= <intended-path> [<actual-attribute-list><actual-path>] <intended-attribute-list> <flowspec-list> ::= <FLOWSPEC> [<flowspec-list>] The PCReq message is defined in [RFC5440] and updated in [RFC8231], it is further updated below for flow specification: Dhody, et al. Expires January 2, 2019 [Page 17] Internet-Draft PCEP-FlowSpec July 2018 <PCReq Message>::= <Common Header> [<svec-list>] <request-list> Where: <svec-list>::= <SVEC>[<svec-list>] <request-list>::= <request>[<request-list>] <request>::= <RP> <END-POINTS> [<LSP>] [<LSPA>] [<BANDWIDTH>] [<metric-list>] [<RRO>[<BANDWIDTH>]] [<IRO>] [<LOAD-BALANCING>] [<flowspec-list>] Where: <flowspec-list> ::= <FLOWSPEC> [<flowspec-list>] The PCRep message is defined in [RFC5440] and updated in [RFC8231], it is further updated below for flow specification: <PCRep Message> ::= <Common Header> <response-list> Where: <response-list>::=<response>[<response-list>] <response>::=<RP> [<LSP>] [<NO-PATH>] [<attribute-list>] [<path-list>] [<flowspec-list>] Where: <flowspec-list> ::= & Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 for the Add and Drop paths of the ROADM. These matrices are augmented with a new roadm-path-impairment matrix element, an add- path-impairment, and drop-path-impairment matrix element, respectively, which are defined as a pointer to the corresponding entry in the roadm-path-impairments list (leaf-ref). [Editor's note: this section is still work in progress] 3. YANG Model (Tree Structure) [Editor's note: tree view below always has to be updated before submitting a new revision!] module: ietf-optical-impairment-topology augment /nw:networks/nw:network/nw:network-types/tet:te-topology: +--rw optical-impairment-topology! augment /nw:networks/nw:network/nw:node: +--ro transponder* [transponder-id] +--ro transponder-id uint32 +--ro transceiver* [transceiver-id] +--ro transceiver-id uint32 +--ro termination-type-capabilities? enumeration +--ro supported-3r-mode? enumeration +--ro configured-termination-type? enumeration +--ro supported-modes +--ro supported-mode* [mode-id] +--ro mode-id string +--ro (mode) +--:(G.698.2) | +--ro standard-mode? standard-mode +--:(organizational-mode) | +--ro organizational-mode | +--ro operational-mode? | | operational-mode | +--ro organization-identifier? | | organization-identifier | +--ro min-central-frequency? | | frequency-thz | +--ro max-central-frequency? | | frequency-thz | +--ro minimum-channel-spacing? | | frequency-ghz | +--ro tx-channel-power-min? dbm-t | +--ro tx-channel-power-max? dbm-t | +--ro rx-channel-power-min? dbm-t | +--ro rx-channel-power-max? dbm-t | +--ro rx-total-power-max? dbm-t Lee, et al. Expires January 9, 2022 [Page 25] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 +--:(explicit-mode) +--ro explicit-mode +--ro supported-modes | +--ro supported-application-codes* | | -> ../../../mode-id | +--ro supported-organizational-modes* | -> ../../../mode-id +--ro line-coding-bitrate? | identityref +--ro max-polarization-mode-dispersion? | decimal64 +--ro max-chromatic-dispersion? | decimal64 +--ro chromatic-and-polarization-dispersion-penalty* [] | +--ro chromatic-dispersion | | decimal64 | +--ro polarization-mode-dispersion | | decimal64 | +--ro penalty | decimal64 +--ro max-diff-group-delay? | int32 +--ro max-polarization-dependent-loss-penalty* [] | +--ro max-polarization-dependent-loss | | decimal64 | +--ro penalty | uint8 +--ro available-modulation-type? | identityref +--ro otsi-carrier-bandwidth? | frequency-ghz +--ro min-OSNR? | snr +--ro min-Q-factor? | int32 +--ro available-baud-rate? | uint32 +--ro nyquist-spacing-factor? | decimal64 +--ro roll-off? | decimal64 +--ro xtalk-penalty? | int32 +--ro available-fec-type? | identityref +--ro fec-code-rate? | decimal64 +--ro fec-threshold? Lee, et al. Expires January 9, 2022 [Page 26] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 | decimal64 +--ro min-central-frequency? | frequency-thz +--ro max-central-frequency? | frequency-thz +--ro minimum-channel-spacing? | frequency-ghz +--ro tx-channel-power-min? | dbm-t +--ro tx-channel-power-max? | dbm-t +--ro rx-channel-power-min? | dbm-t +--ro rx-channel-power-max? | dbm-t +--ro rx-total-power-max? dbm-t augment /nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes: +--ro OMS-attributes +--ro generalized-snr? l0-types-ext:snr +--ro equalization-mode identityref +--ro (power-param)? | +--:(channel-power) | | +--ro nominal-carrier-power? decimal64 | +--:(power-spectral-density) | +--ro nominal-power-spectral-density? decimal64 +--ro media-channel-group* [i] | +--ro i int16 | +--ro media-channels* [flexi-n] | +--ro flexi-n l0-types:flexi-n | +--ro flexi-m? l0-types:flexi-m | +--ro otsi-group-ref? leafref | +--ro otsi-ref? leafref | +--ro delta-power? decimal64 +--ro OMS-elements* [elt-index] +--ro elt-index uint16 +--ro oms-element-uid? string +--ro (element) +--:(amplifier) | +--ro amplifier | +--ro type-variety string | +--ro operational | +--ro amplifier-element* [] | +--ro name? | | string | +--ro frequency-range | | +--ro lower-frequency frequency-thz Lee, et al. Expires January 9, 2022 [Page 27] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 | | +--ro upper-frequency frequency-thz | +--ro actual-gain | | decimal64 | +--ro tilt-target | | decimal64 | +--ro out-voa | | decimal64 | +--ro in-voa | | decimal64 | +--ro (power-param)? | +--:(channel-power) | | +--ro nominal-carrier-power? | | decimal64 | +--:(power-spectral-density) | +--ro nominal-power-spectral-density? | decimal64 +--:(fiber) | +--ro fiber | +--ro type-variety string | +--ro length decimal64 | +--ro loss-coef decimal64 | +--ro total-loss decimal64 | +--ro pmd? decimal64 | +--ro conn-in? decimal64 | +--ro conn-out? decimal64 +--:(concentratedloss) +--ro concentratedloss +--ro loss decimal64 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point: +--ro otsi-group* [otsi-group-id] | +--ro otsi-group-id int16 | +--ro otsi* [otsi-carrier-id] | +--ro otsi-carrier-id int16 | +--ro transponder-ref? | | -> ../../../../../transponder/transponder-id | +--ro transceiver-ref? leafref | +--ro configured-mode? leafref | +--ro otsi-carrier-frequency? frequency-thz | +--ro tx-channel-power? dbm-t | +--ro rx-channel-power? dbm-t | +--ro rx-total-power? dbm-t +--ro transceiver* [] +--ro transponder-ref? | -> ../../../../transponder/transponder-id +--ro tranceiver-ref? leafref augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point: Lee, et al. Expires January 9, 2022 [Page 28] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 +--ro sliceable-transponder-list* [carrier-id] +--ro carrier-id uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes: +--ro roadm-path-impairments* [roadm-path-impairments-id] +--ro roadm-path-impairments-id uint32 +--ro (impairment-type)? +--:(roadm-express-path) | +--ro roadm-express-path* [] | +--ro frequency-range | | +--ro lower-frequency frequency-thz | | +--ro upper-frequency frequency-thz | +--ro roadm-pmd? decimal64 | +--ro roadm-cd? decimal64 | +--ro roadm-pdl? decimal64 | +--ro roadm-inband-crosstalk? decimal64 | +--ro roadm-maxloss? decimal64 +--:(roadm-add-path) | +--ro roadm-add-path* [] | +--ro frequency-range | | +--ro lower-frequency frequency-thz | | +--ro upper-frequency frequency-thz | +--ro roadm-pmd? decimal64 | +--ro roadm-cd? decimal64 | +--ro roadm-pdl? decimal64 | +--ro roadm-inband-crosstalk? decimal64 | +--ro roadm-maxloss? decimal64 | +--ro roadm-pmax? decimal64 | +--ro roadm-osnr? l0-types-ext:snr | +--ro roadm-noise-figure? decimal64 +--:(roadm-drop-path) +--ro roadm-drop-path* [] +--ro frequency-range | +--ro lower-frequency frequency-thz | +--ro upper-frequency frequency-thz +--ro roadm-pmd? decimal64 +--ro roadm-cd? decimal64 +--ro roadm-pdl? decimal64 +--ro roadm-inband-crosstalk? decimal64 +--ro roadm-maxloss? decimal64 +--ro roadm-minloss? decimal64 +--ro roadm-typloss? decimal64 +--ro roadm-pmin? decimal64 +--ro roadm-pmax? decimal64 +--ro roadm-ptyp? decimal64 +--ro roadm-osnr? l0-types-ext:snr +--ro roadm-noise-figure? decimal64 augment /nw:networks/nw:network/nw:node/tet:te Lee, et al. Expires January 9, 2022 [Page 29] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 /tet:information-source-entry/tet:connectivity-matrices: +--ro roadm-path-impairments? leafref augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:connectivity-matrix: +--ro roadm-path-impairments? leafref augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices: +--ro roadm-path-impairments? -<FLOWSPEC> [<flowspec-list>] Dhody, et al. Expires January 2, 2019 [Page 18] Internet-Draft PCEP-FlowSpec July 2018 10. IANA Considerations IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry. This document requests IANA actions to allocate code points for the protocol elements defined in this document. 10.1. PCEP Objects Each PCEP object has an Object-Class and an Object-Type. IANA maintains a subregistry called "PCEP Objects". IANA is requested to make an assignment from this subregistry as follows: Object-Class | Value Name | Object-Type | Reference -------------+-------------+------------------------+---------------- TBD3 | FLOW SPEC | 0: Reserved | [This.I-D] | | 1: Flow Specification | [This.I-D] 10.2. PCEP TLV Type Indicators IANA maintains a subregistry called "PCEP TLV Type Indicators". IANA is requested to make an assignment from this subregistry as follows: Value | Meaning | Reference --------+------------------------------+------------- TBD2 | PCE-FLOWSPEC-CAPABILITY TLV | [This.I-D] TBD4 | FLOW FILTER TLV | [This.I-D] 10.3. Flow Specification TLV Type Indicators IANA is requested to create a new subregistry call the "PCEP Flow Specification TLV Type Indicators" registry. Allocations from this registry are to be made according to the following assignment policies [RFC8126]: Dhody, et al. Expires January 2, 2019 [Page 19] Internet-Draft PCEP-FlowSpec July 2018 Range | Assignment policy ---------------+--------------------------------------------------- 0 | Reserved - must not be allocated. | 1 .. 255 | Reserved - must not be allocated. | Usage mirrors the BGP FlowSpec registry [RFC5575]. | 258 .. 64506 | Specification Required | 64507 .. 65531 | First Come First Served | 65532 .. 65535 | Experimental IANA is requested to pre-populate this registry with values defined in this document as follows, taking the new values from the range 258 to 64506: Value | Meaning -------+------------------------ TBD5 | Route Distinguisher TBD6 | IPv4 Multicast TBD7 | IPv6 Multicast 10.4. PCEP Error Codes IANA maintains a subregistry called "PCEP-ERROR Object Error Types and Values". Entries in this subregistry are described by Error-Type and Error-value. IANA is requested to make the following assignment from this subregistry: Error-| Meaning | Error-value | Reference Type | | | -------+--------------------+----------------------------+----------- TBD8 | FlowSpec error | 0: Unassigned | [This.I-D] | | 1: Unsupported FlowSpec | [This.I-D] | | 2: Malformed FlowSpec | [This.I-D] | | 3: Unresolvable conflict | [This.I-D] | | 4-255: Unassigned | [This.I-D] Dhody, et al. Expires January 2, 2019 [Page 20] Internet-Draft PCEP-FlowSpec July 2018 10.5. PCE Capability Flag IANA maintains a subregistry called "Open Shortest Path First v2 (OSPFv2) Parameters" with a sub-registry called "Path Computation Element (PCE) Capability Flags". IANA is requested to assign a new capability bit from this registry as follows: Bit | Capability Description | Reference -------+-------------------------------+------------ TBD1 | FlowSpec | [This.I-D] 11. Security Considerations We may assume that a system that utilizes a remote PCE is subject to a number of vulnerabilities that could allow spurious LSPs or SR paths to be established or that could result in existing paths being modified or torn down. Such systems, therefore, apply security considerations as described in [RFC5440], [RFC6952], and [RFC8253]. The description of Flow Specifications associated with paths set up or controlled by a PCE add a further detail that could be attacked without tearing down LSPs or SR paths, but causing traffic to be misrouted within the network. Therefore, the use of the security mechanisms for PCEP referenced above is important. Visibility into the information carried in PCEP does not have direct privacy concerns for end-users' data, however, knowledge of how data is routed in a network may make that data more vulnerable. Of course, the ability to interfere with the way data is routed also makes the data more vulnerable. Furthermore, knowledge of the connected end-points (such as multicast receivers or VPN sites) is usually considered private customer information. Therefore, implementations or deployments concerned to protect privacy MUST apply the mechanisms described in the documents referenced above. Experience with Flow Specifications in BGP systems indicates that they can become complex and that the overlap of Flow Specifications installed in different orders can lead to unexpected results. Although this is not directly a security issue per se, the confusion and unexpected forwarding behavior may be engineered or exploited by an attacker. Therefore, implementers and operators SHOULD pay careful attention to the Manageability Considerations described in Section 12. Dhody, et al. Expires January 2, 2019 [Page 21] Internet-Draft PCEP-FlowSpec July 2018 12. Manageability Considerations TBD 13. Acknowledgements Thanks to Julian Lucek and Sudhir Cheruathur for useful discussions. 14. References 14.1. Normative References [I-D.dhodylee-pce-pcep-ls] Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for Distribution of Link-State and TE Information.", draft- dhodylee-pce-pcep-ls-11 (work in progress), June 2018. [I-D.ietf-idr-flow-spec-v6] McPherson, D., Raszuk, R., Pithawala, B., akarch@cisco.com, a., and S. Hares, "Dissemination of Flow Specification Rules for IPv6", draft-ietf-idr-flow-spec- v6-09 (work in progress), November 2017. [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/info/rfc2119>. [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>. [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, <https://www.rfc-editor.org/info/rfc5575>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. Dhody, et al. Expires January 2, 2019 [Page 22] Internet-Draft PCEP-FlowSpec July 2018 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>. 14.2. Informative References [I-D.ietf-pce-segment-routing] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", draft-ietf-pce-segment-routing-12 (work in progress), June 2018. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>. [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://www.rfc-editor.org/info/rfc5088>. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, <https://www.rfc-editor.org/info/rfc5089>. [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <https://www.rfc-editor.org/info/rfc6952>. [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <https://www.rfc-editor.org/info/rfc7399>. Dhody, et al. Expires January 2, 2019 [Page 23] Internet-Draft PCEP-FlowSpec July 2018 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>. [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <https://www.rfc-editor.org/info/rfc8232>. [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>. [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, December 2017, <https://www.rfc-editor.org/info/rfc8283>. Appendix A. Contributorsgt; ../../roadm-path-impairments/roadm-path-impairments-id augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:connectivity-matrix: +--ro roadm-path-impairments? leafref augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities: +--ro add-path-impairments? leafref +--ro drop-path-impairments? leafref augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities /tet:local-link-connectivity: +--ro add-path-impairments? leafref +--ro drop-path-impairments? leafref 4. Optical Impairment Topology YANG Model [Editor's note: YANG code below always has to be updated before submitting a new revision!] <CODE BEGINS> module ietf-optical-impairment-topology { yang-version 1.1; namespace "urn:ietf:params:xml" +":ns:yang:ietf-optical-impairment-topology"; prefix "optical-imp-topo"; import ietf-network { prefix "nw"; } import ietf-network-topology { prefix "nt"; } Lee, et al. Expires January 9, 2022 [Page 30] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 import ietf-te-topology { prefix "tet"; } import ietf-layer0-types { prefix "l0-types"; } import ietf-layer0-types-ext { prefix "l0-types-ext"; } organization "IETF CCAMP Working Group"; contact "Editor: Young Lee <younglee.tx@gmail.com> Editor: Haomian Zheng <zhenghaomian@huawei.com> Editor: Nicola Sambo <nicosambo@gmail.com> Editor: Victor Lopez <victor.lopezalvarez@telefonica.com> Editor: Gabriele Galimberti <ggalimbe@cisco.com> Editor: Giovanni Martinelli <giomarti@cisco.com> Editor: Jean-Luc Auge <jeanluc.auge@orange.com> Editor: Le Rouzic Esther <esther.lerouzic@orange.com> Editor: Julien Meuric <julien.meuric@orange.com> Editor: Italo Busi <Italo.Busi@huawei.com> Editor: Dieter Beller <dieter.beller@nokia.com> Editor: Sergio Belotti <Sergio.belotti@nokia.com> Editor: Griseri Enrico <enrico.griseri@nokia.com> Editor: Gert Grammel <ggrammel@juniper.net>"; description "This module contains a collection of YANG definitions for impairment-aware optical networks. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove Lee, et al. Expires January 9, 2022 [Page 31] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 // this note // replace the revision date with the module publication date // the format is (year-month-day) revision 2021-07-05 { description "Initial Version"; reference "RFC XXXX: A Yang Data Model for Impairment-aware Optical Networks"; } // grouping grouping transponder-attributes { description "Configuration of an optical transponder"; leaf-list available-modulation-types { type identityref { base l0-types-ext:modulation; } config false; description "List of modulation types the OTSi supports"; } leaf configured-modulation-type { type identityref { base l0-types-ext:modulation; } config false; description "Currently configured OTSi modulation type"; } leaf-list available-baud-rates { type uint32; units Bd; config false; description "list of available baud-rates. Baud-rate is the unit for symbol rate or modulation rate in symbols per second or pulses per second. It is the number of distinct symbol Lee, et al. Expires January 9, 2022 [Page 32] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 changes (signal events) made to the transmission medium per second in a digitally modulated signal or a line code"; } leaf configured-baud-rate { type uint32; units Bd; config false; description "configured baud-rate"; } leaf-list available-FEC-types { type identityref { base l0-types-ext:fec-type; } config false; description "List determining all the available FEC"; } leaf configured-FEC-type { type identityref { base l0-types-ext:fec-type; } config false; description "FEC type configured for the transponder"; } leaf FEC-code-rate { type decimal64 { fraction-digits 8; range "0..max"; } config false; description "FEC-code-rate"; } leaf FEC-threshold { type decimal64 { fraction-digits 8; range "0..max"; } config false; description "Threshold on the BER, for which FEC is able to correct errors"; Lee, et al. Expires January 9, 2022 [Page 33] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 } } grouping sliceable-transponder-attributes { description "Configuration of a sliceable transponder."; list sliceable-transponder-list { key "carrier-id"; config false; description "List of carriers"; leaf carrier-id { type uint32; config false; description "Identifier of the carrier"; } } } grouping optical-fiber-data { description "optical link (fiber) attributes with impairment data"; leaf fiber-type { type l0-types-ext:fiber-type; config false; description "fiber-type"; } leaf span-length { type decimal64 { fraction-digits 2; } units "km"; config false; description "the lenght of the fiber span in km"; } leaf input-power { type decimal64 { fraction-digits 2; } units "dBm"; config false; description "Average input power level estimated at the receiver of the link"; } Lee, et al. Expires January 9, 2022 [Page 34] Internet-Draft Opt. Impairment-Aware Topo YANG Model July 2021 leaf output-power { type decimal64 { fraction-digits 2; } units "dBm"; description "Mean launched power at the transmitter of the link"; } leaf pmd { type decimal64 { fraction-digits 8; range "0..max"; } units "ps/(km)^0.5"; config false; description "Polarization Mode Dispersion"; } leaf cd { type decimal64 { fraction-digits 5; } units "ps/nm/km"; config false; description "Cromatic Dispersion"; } leaf osnr { type l0-types-ext:snr; config false; description "Optical Signal-to-Noise Ratio (OSNR) estimated at the receiver"; } leaf sigma { type decimal64 { fraction-digits 5; } units "dB"; config false; description "sigma in the Gausian Noise Model"; } } Shankara Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: shankara@huawei.com Dhody, et al. Expires January 2, 2019 [Page 24] Internet-Draft PCEP-FlowSpec July 2018 Qiandeng Liang Huawei Technologies 101 Software Avenue, Yuhuatai District Nanjing 210012 China Email: liangqiandeng@huawei.com Cyril Margaria Juniper Networks 200 Somerset Corporate Boulevard, Suite 4001 Bridgewater, NJ 08807 USA Email: cmargaria@juniper.net Colby Barth Juniper Networks 200 Somerset Corporate Boulevard, Suite 4001 Bridgewater, NJ 08807 USA Email: cbarth@juniper.net Xia Chen Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jescia.chenxia@huawei.com Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Dhody, et al. Expires January 2, 2019 [Page 25] Internet-Draft PCEP-FlowSpec July 2018 Authors' Addresses Dhruv Dhody (editor) Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Adrian Farrel (editor) Juniper Networks Email: afarrel@juniper.net Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Dhody, et al. Expires January 2, 2019 [Page 26]