Network Management Datastore Architecture (NMDA)
RFC 8342

Network Working Group                                      G. Bernstein
Internet Draft                                        Grotto Networking
Intended status: Standards Track                                 Y. Lee
Expires: May 2014                                                 D. Li
                                                                 Huawei
                                                             W. Imajuku
                                                                    NTT

                                                      November 12, 2013

        Routing and Wavelength Assignment Information Encoding for
                   Wavelength Switched Optical Networks

                  draft-ietf-ccamp-rwa-wson-encode-22.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on May 12, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Bernstein and Lee        Expires May 12, 2014                  [Page 1]
Internet-Draft   Wavelength Switched Optical Networks     November 2013

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.

Abstract

   A wavelength switched optical network (WSON) requires that certain
   key information elements are made available to facilitate path
   computation and the establishment of label switching paths (LSPs).
   The information model described in "Routing and Wavelength
   Assignment Information for Wavelength Switched Optical Networks"
   shows what information is required at specific points in the WSON.
   Part of the WSON information model contains aspects that may be of
   general applicability to other technologies, while other parts are
   fairly specific to WSONs.

   This document provides efficient, protocol-agnostic encodings for
   the WSON specific information elements. It is intended that
   protocol-specific documents will reference this memo to describe how
   information is carried for specific uses. Such encodings can be used
   to extend GMPLS signaling and routing protocols. In addition these
   encodings could be used by other mechanisms to convey this same
   information to a path computation element (PCE).

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents

   1. Introduction...................................................3
   1. Terminology....................................................4
   2. Resources, Resource Blocks, and the Resource Pool..............4
      2.1. Resource Block Set Field..................................5
   3. Resource Accessibility/Availability............................6

Bernstein and Lee        Expires May 12, 2014                  [Page 2]
Internet-Draft   Wavelength Switched Optical Networks     November 2013

      3.1. Resource Accessibility Field..............................6
      3.2. Resource Wavelength Constraints Field.....................8
      3.3. Resource Block Pool State (RBPoolState) Field............10
      3.4. Resource Block Shared Access Wavelength Availability
      (RBSharedAccessWaveAvailability) Field........................11
   4. Resource Signal Constraints and Processing Capabilities.......13
      4.1. Resource Block Information (ResourceBlockInfo) Field.....13
      4.2. Shared Input or Output Indication........................14
      4.3. Optical Interface Class List(s) Sub-Sub-TLV..............14
         4.3.1. Optical Interface Class Format......................15
         4.3.2. ITU-G.698.1 Application Code Mapping................16
         4.3.3. ITU-G.698.2 Application Code Mapping................18
         4.3.4. ITU-G.959.1 Application Code Mapping................19
         4.3.5. ITU-G.695 Application Code Mapping..................21
      4.4. Acceptable Client Signal List Sub-Sub-TLV................23
      4.5. Input Bit Rate List Sub-Sub-TLV..........................24
      4.6. Processing Capability List Sub-Sub-TLV...................24
         4.6.1. Processing Capabilities Field.......................25
   5. Security Considerations.......................................26
   6. IANA Considerations...........................................26
   7. Acknowledgments...............................................26
   APPENDIX A: Encoding Examples....................................27
      A.1. Wavelength Converter Accessibility Sub-TLV...............27
      A.2. Wavelength Conversion Range Sub-TLV......................28
      A.3. An OEO Switch with DWDM Optics...........................29
   8. References....................................................32
      8.1. Normative References.....................................32
      8.2. Informative References...................................32
   9. Contributors..................................................34
   Authors' Addresses...............................................35
   Intellectual Property Statement..................................36
   Disclaimer of Validity...........................................37

1. Introduction

   A Wavelength Switched Optical Network (WSON) is a Wavelength
   Division Multiplexing (WDM) optical network in which switching is
   performed selectively based on the center wavelength of an optical
   signal.

   [RFC6163] describes a framework for Generalized Multiprotocol Label
   Switching (GMPLS) and Path Computation Element (PCE) control of a
   WSON. Based on this framework, [RWA-Info] describes an information
   model that specifies what information is needed at various points in
   a WSON in order to compute paths and establish Label Switched Paths
   (LSPs).

Bernstein and Lee        Expires May 12, 2014                  [Page 3]
Internet-Draft   Wavelength Switched Optical Networks     November 2013

   This document provides efficient encodings of information needed by
   the routing and wavelength assignment (RWA) process in a WSON. Such
   encodings can be used to extend GMPLS signaling and routing
   protocols. In addition these encodings could be used by other
   mechanisms to convey this same information to a path computation
   element (PCE). Note that since these encodings are relatively
   efficient they can provide more accurate analysis of the control
   plane communications/processing load for WSONs looking to utilize a
   GMPLS control plane.

1. Terminology

   Refer to [RFC6163] for CWDM, DWDM, RWA, WDM.

   Refer to Section 5 of [Gen-Encode] for the terminology of Resources,
   Resources Blocks, and Resource Pool.

2. Resources, Resource Blocks, and the Resource Pool

   This section provides encodings for the information elements defined
   in [RWA-INFO] that have applicability to WSON.  The encodings are
   designed to be suitable for use in the GMPLS routing protocols OSPF
   [RFC4203] and IS-IS [RFC5307] and in the PCE protocol (PCEP)
   [RFC5440]. Note that the information distributed in [RFC4203] and
   [RFC5307] is arranged via the nesting of sub-TLVs within TLVs and
   this document defines elements to be used within such constructs.

   This document defines the following information elements pertaining
   to resources within an optical node:

     . Resource Accessibility <ResourceAccessibility>

     . Resource Wavelength Constraints <ResourceWaveConstraints>

     . Resource Block Pool State <RBPoolState>

     . Resource Block Shared Access Wavelength Availability
        <RBSharedAccessWaveAvailability>

     . Resource Block Information <ResourceBlockInfo>

Bernstein and Lee        Expires May 12, 2014                  [Page 4]
Internet-Draft   Wavelength Switched Optical Networks     November 2013

   gt;.  If those
   values are not supplied, the system will select values.  When the
   connection is established, <operational> will contain the current
   values for the local-port and remote-port nodes regardless of the
   origin.  If the system has chosen the values, the "origin" attribute
   will be set to "system".  Before the connection is established, one
   or both of the nodes may not appear, since the system may not yet
   have their values.

     <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
          or:origin="or:intended">
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
         <local-as or:origin="or:default">64501</local-as>
         <peer-as or:origin="or:default">64502</peer-as>
         <local-port or:origin="or:system">60794</local-port>
         <remote-port or:origin="or:default">179</remote-port>
         <state>established</state>
       </peer>
     </bgp>

C.2.3.  Removing a Peer

   Changes to configuration may take time to percolate through the
   various software components involved.  During this period, it is
   imperative to continue to give an accurate view of the working of the
   device.  <operational> will contain nodes for both the previous and
   current configuration, as closely as possible tracking the current
   operation of the device.

   Consider the scenario where a client removes a BGP peer.  When a peer
   is removed, the operational state will continue to reflect the
   existence of that peer until the peer's resources are released,
   including closing the peer's connection.  During this period, the
   current data values will continue to be visible in <operational>,
   with the "origin" attribute set to indicate the origin of the
   original data.

Bjorklund, et al.            Standards Track                   [Page 39]
RFC 8342                          NMDA                        March 2018

     <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
          or:origin="or:intended">
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
         <local-as or:origin="or:default">64501</local-as>
         <peer-as or:origin="or:default">64502</peer-as>
         <local-port or:origin="or:system">60794</local-port>
         <remote-port or:origin="or:default">179</remote-port>
         <state>closing</state>
       </peer>
     </bgp>

   Once resources are released and the connection is closed, the peer's
   data is removed from <operational>.

C.3.  Interface Example

   In this section, we will use this simple interface data model:

     container interfaces {
       list interface {
         key name;
         leaf name {
           type string;
         }
         leaf description {
           type string;
         }
         leaf mtu {
           type uint16;
         }
         leaf-list ip-address {
           type inet:ip-address;
         }
       }
     }

Bjorklund, et al.            Standards Track                   [Page 40]
RFC 8342                          NMDA                        March 2018

C.3.1.  Pre-provisioned Interfaces

   One common issue in networking devices is the support of Field
   Replaceable Units (FRUs) that can be inserted and removed from the
   device without requiring a reboot or interfering with normal
   operation.  These FRUs are typically interface cards, and the devices
   support pre-provisioning of these interfaces.

   If a client creates an interface "et-0/0/0" but the interface does
   not physically exist at this point, then <intended> might contain the
   following:

     <interfaces>
       <interface>
         <name>et-0/0/0</name>
         <description>Test interface</description>
       </interface>
     </interfaces>

   Since the interface does not exist, this data does not appear in
   <operational>.

   When a FRU containing this interface is inserted, the system will
   detect it and process the associated configuration.  <operational>
   will contain the data from <intended>, as well as nodes added by the
   system, such as the current value of the interface's MTU.

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>et-0/0/0</name>
         <description>Test interface</description>
         <mtu or:origin="or:system">1500</mtu>
       </interface>
     </interfaces>

   If the FRU is removed, the interface data is removed from
   <operational>.

Bjorklund, et al.            Standards Track                   [Page 41]
RFC 8342                          NMDA                        March 2018

C.3.2.  System-Provided Interface

   Imagine that the system provides a loopback interface (named "lo0")
   with a default IPv4 address of "127.0.0.1" and a default IPv6 address
   of "::1".  The system will only provide configuration for this
   interface if there is no data for it in <intended>.

   When no configuration for "lo0" appears in <intended>, <operational>
   will show the system-provided data:

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface or:origin="or:system">
         <name>lo0</name>
         <ip-address>127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

   When configuration for "lo0" does appear in <intended>, <operational>
   will show that data with the origin set to "intended".  If the
   "ip-address" is not provided, then the system-provided value will
   appear as follows:

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>lo0</name>
         <description>loopback</description>
         <ip-address or:origin="or:system">127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

Bjorklund, et al.            Standards Track                   [Page 42]
RFC 8342                          NMDA                        March 2018

Acknowledgments

   This document grew out of many discussions that took place since
   2010.  Several documents ([NETMOD-Operational] [With-config-state]
   [OpState-Reqs] [OpState-Enhance] [OpState-Modeling], as well as
   [RFC6244]), touched on some of the problems of the original datastore
   model.  The following people were authors of these works in progress
   or were otherwise actively involved in the discussions that led to
   this document:

   o  Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>

   o  Andy Bierman, YumaWorks, <andy@yumaworks.com>

   o  Marcus Hines, Google, <hines@google.com>

   o  Christian Hopps, Deutsche Telekom, <chopps@chopps.org>

   o  Balazs Lengyel, Ericsson, <balazs.lengyel@ericsson.com>

   o  Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz>

   o  Acee Lindem, Cisco Systems, <acee@cisco.com>

   o  Thomas Nadeau, Brocade Networks, <tnadeau@lucidvision.com>

   o  Tom Petch, Engineering Networks Ltd, <ietfc@btconnect.com>

   o  Anees Shaikh, Google, <aashaikh@google.com>

   o  Rob Shakir, Google, <robjs@google.com>

   o  Jason Sterne, Nokia, <jason.sterne@nokia.com>

   Juergen Schoenwaelder was partly funded by Flamingo, a Network of
   Excellence project (ICT-318488) supported by the European Commission
   under its Seventh Framework Programme.

Bjorklund, et al.            Standards Track                   [Page 43]
RFC 8342                          NMDA                        March 2018

Authors' Addresses

   Martin Bjorklund
   Tail-f Systems

   Email: mbj@tail-f.com

   Juergen Schoenwaelder
   Jacobs University

   Email: j.schoenwaelder@jacobs-university.de

   Phil Shafer
   Juniper Networks

   Email: phil@juniper.net

   Kent Watsen
   Juniper Networks

   Email: kwatsen@juniper.net

   Robert Wilton
   Cisco Systems

   Email: rwilton@cisco.com

Bjorklund, et al.            Standards Track                   [Page 44]