[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Internet Engineering Task Force                       G. Martinelli, Ed.
Internet-Draft                                             G. Galimberti
Intended status: Informational                                     Cisco
Expires: January 17, 2013                                         L. Ong
                                                       Ciena Corporation
                                                           D. Ceccarelli
                                                                Ericsson
                                                             C. Margaria
                                                  Nokia Siemens Networks
                                                           July 16, 2012


                      WSON Optical Interface Class
                draft-martinelli-wson-interface-class-03

Abstract

   Current work on wavelength switched optical network includes several
   considerations regarding the interface signal compatibility.  In
   particular ingress and egress optical interfaces will require a check
   on several optical parameters to assess if the signal generated by
   the ingress interface can be compatible with the receiving interface.
   Current solution available encode all parameters in WSON protocol
   extensions while in this draft will propose an alternative method to
   keep into account the signal compatibility issue at protocol level.

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 http://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 17, 2013.

Copyright Notice

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




Martinelli, et al.      Expires January 17, 2013                [Page 1]


Internet-Draft        WSON Optical Interface Class             July 2012


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Existing WSON Signal Compatibility protocol extension  . . . .  3
   3.  Optical Interface Class  . . . . . . . . . . . . . . . . . . .  4
     3.1.  Concept  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Procedures . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Optical Interface Class Semantic . . . . . . . . . . . . . . .  8
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Application Code Mapping  . . . . . . . . . . . . . . 10
     A.1.  ITU-G.698.1 Application Code Mapping . . . . . . . . . . . 10
     A.2.  ITU-G.698.2 Application Code Mapping . . . . . . . . . . . 12
     A.3.  ITU-G.959.1 Application Code Mapping . . . . . . . . . . . 12
   Appendix B.  Encoding example  . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16


















Martinelli, et al.      Expires January 17, 2013                [Page 2]


Internet-Draft        WSON Optical Interface Class             July 2012


1.  Introduction

   The current work on Wavelength Switched Optical Network (WSON) define
   the need of assessing the signal compatibility during the routing and
   wavelength assignment (RWA) process.  In details, the [RFC6163]
   reports the ingress and egress interfaces and the regeneration points
   as places where the optical signal compatibility must be assured.  On
   how to evaluate this compatibility, there are several parameters
   identified according to ITU specification (e.g.  [ITU-G.698.1],
   [ITU-G.698.2] and [ITU-G.959.1] among others).  In particular the
   following set of parameters has been chosen: signal bit rate,
   modulation format, forward error correction (FEC).

   At the current state of art new high bit rates (40G/100G/flexgrid)
   and new modulation formats (e.g.  QPSK flavors) are already deployed
   in field.  Some of them are under standardization at ITU but it is
   not clear if and when there will be a dominating technology.  With
   the current realistic scenario, DWDM optical networks will have to
   manage different bit-rates as well as different modulation formats
   over the same link since different signal characteristics will
   coexist at the same time.

   To a further extent, WSON Control Plane needs consider the case with
   optical impairments awareness as detailed in [RFC6566].  In such a
   case, control plane will require some additional interface parameters
   to assess the optical feasibility path and, as a consequence, further
   WSON protocols extensions.

   Scope of this draft is to propose an Optical Interface Class
   identifier as a solution for the WSON signal compatibility problem.
   To some extend the idea is have protocol extensions independent from
   optical technology evolution by keeping the semantic of optical
   characteristics separated from protocol scope.  The final goal is not
   an encoding saving but rather a general abstract representation of
   some physical characteristics.

1.1.  Requirements Language

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


2.  Existing WSON Signal Compatibility protocol extension

   Within the current WSON activity the signal compatibility encoding is
   defined within the [I-D.ietf-ccamp-rwa-wson-encode].




Martinelli, et al.      Expires January 17, 2013                [Page 3]


Internet-Draft        WSON Optical Interface Class             July 2012


   In details, the following set of parameters is considered:

   o  Modulation Format.  Only NRZ currently defined.

   o  FEC, according to G.709 and G.975.

   o  Bit Rate.

   This list of parameters is defined by ITU and might be subject to
   change for two reasons: new values for existing parameters, new
   parameters required by new technology or control plane evolution.

   At the current status, the above encoding is going to be used within
   several WSON specific protocol extensions.

   o  OSPF [I-D.ietf-ccamp-wson-signal-compatibility-ospf] since the
      path computation function need to consider optical interface
      parameters as a constrain during the RWA process.

   o  RSVP [I-D.ietf-ccamp-wson-signaling] since during the signaling
      phase there is the need to know optical ingress and egress
      interface properties (and eventually interfaces at regeneration
      point).

   o  In addition in case of PCE control plane solutions, PCEP extension
      needs similar parameters as envisaged here
      [I-D.lee-pce-wson-rwa-ext].

   In case of any update from ITU standards regarding optical signals
   and interfaces all the above drafts making use of the same
   information needs an update.


3.  Optical Interface Class

3.1.  Concept

   The Optical Interface Class is a unique number that identify all
   information related to optical characteristic's of a physical
   interface.  The class may include other optical parameters releated
   to other interface properties.  A class MUST always include signal
   compatibility information.

   The content of each class is out of the scope of this draft and can
   be defined by other entities (e.g.  ITU, optical equipment vendors,
   etc.).

   Since event current implementation of physical interfaces may support



Martinelli, et al.      Expires January 17, 2013                [Page 4]


Internet-Draft        WSON Optical Interface Class             July 2012


   different optical characteristics, a single interface may support
   multiple interface classes.  Which optical interface class is used
   among all the one available for each interfaces is out of the scope
   of this draft but likely is an output of the RWA process.

3.2.  Procedures

   In term of RWA process one operation required is to assess the
   optical compatibility (LSP endpoint interfaces or regeneration
   intermediate endpoints).  This is done by checking if the two optical
   endpoint have the same Optical Interface Class value.  Note that, if
   a lightpath implementing an LSP needs regeneration, the complete LSP
   may have some additional intermediate optical enpoints where
   regenerations happens.

   The procedure of signal compatibility assessment become just a
   numbers comparison: if two Optical Interface Class are equals the
   signal compatibility constrain is satisfied.  GMPLS protocols don't
   have to implement any logic or optical knowledge related to signal
   compatibility.

   The procedure is easily generalized in case more than one class is
   available for each interface since it's sufficient to find two
   matching values between each optical segment of a WSON LSP.



      +---+    +----+   +----+     +-----+     +----+     +---+
      | I |----| N1 |---| N2 |-----| REG |-----| N3 |-----| E |
      +---+    +----+   +----+     +-----+     +----+     +---+
        cl1 <--------S1---------> cl1    cl1
        cl2                       cl2                     cl2
                                  cl3    cl3 <----S2----> cl3

                               LSP
         |<----------------------------------------------->|


                                 Figure 1

   As an example Figure 1 shows a case where the RWA process end up in a
   path that need a wavelength conversion (I, N1, N2, REG, N3, E).
   Optical interfaces are reported as cl1, cl2 and cl3.  Each optical
   interface involved in the path at nodes I, REG, E must satisfy the
   Optical Interface Class constrain.  The LSP is then composed by two
   optical segment: S1 using optical interface class cl1 and S2 using
   optical interface class cl3.




Martinelli, et al.      Expires January 17, 2013                [Page 5]


Internet-Draft        WSON Optical Interface Class             July 2012


   By using the Optical Interface Class concept every protocol
   extensions supporting WSON does not need to care about DWDM signal
   details and does not need to consider technology specific evolution.
   If a new values are standardized (e.g. new modulation formats become
   standard) or new parameters are required, wson protocols don't need
   any extensions.  In addition, in case PCE is used within a WSON
   control plane, this allows all optical parameters to be fully known
   only by the PCE and does not require the other element any knowledge
   of them.

3.3.  Encoding

   The following Optical Interface Class must be be used in proper TLVs
   for different WSON protocol extensions.

   In case an optical interface or a regeneration point will support
   multiple optical capabilities, a list of Interface Classes can be
   used.  Note that the concept of list is already defined in
   [I-D.ietf-ccamp-rwa-wson-encode].


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|     Reserved                |    OI Code Points             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Optical Interface Class                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Optical Interface Class  (Cont.)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 2: Optical Interface Class

   Where the first 32 bist of the encoding shall be used to indentify
   the semantic of the Optical Interface Class in the following way:

   S  Standard bit.

         S=0, identify not ITU code points

         S=1, identify ITU application codes

   With S=0, the OI Code Points field can take the following values:

      0: reserved





Martinelli, et al.      Expires January 17, 2013                [Page 6]


Internet-Draft        WSON Optical Interface Class             July 2012


      1: Vendor Specific Optical Interface Class.

   With S=1, the OI Code Points field can take the following values:

      0: reserved

      1: [ITU-G.698.1] application code.

      2: [ITU-G.698.2] application code.

      3: [ITU-G.959.1] application code.

   In case of ITU Application Code, there should be a mapping between
   string defining the application code and the 64 bits number
   implementing the optical interface class.

   As an example, Figure 3 shows how the encoding looks like in case of
   S bit equals to 1 and Code point equals to 3.


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|     Reserved                |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            G.959.1 Application Code                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            G.959.1 Applciation Code (cont.)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 3: Optical Interface Class example with ITU application code

   The mapping of the ITU Application Code over the Optical Interface
   Class is provided in Appendix A.

   It is worthwhile to have a rough estimation if the 64 bits are enough
   for matching the currently defined ITU application code and with this
   purpose we provide the current analisys.  The application code
   consist of the following 8 elements: DScW-ytz(v).  D is fixed, S has
   two values (1 bit), c has currently 4 values (for reference [RFC6205]
   has 4 bit reserved for this), W takes two values (1 bit), t is a
   placeholder with only one value defined, z has only 3 values defined
   (2 bits) and v has 3 values (2 bits).  In a rought esitimation, the
   number of information bits is at minimum 10 bit.  So 64 bit are
   enought also for future application code evolutions.






Martinelli, et al.      Expires January 17, 2013                [Page 7]


Internet-Draft        WSON Optical Interface Class             July 2012


4.  Optical Interface Class Semantic

   The semantic of the Optical Interface Class must be defined outside
   the control plane but it must be unique for all control plane for
   every control plane function or network node.  Within this
   hypothesis, we need to solve the problem on how to make any network
   element aware of the semantic behind the Optical Interface Class and
   make sure it can figure out the right value for its interfaces.

   An example of semantic is the "Application Code" within [ITU-G.698.1]
   and [ITU-G.698.2].  The Application Code could be easily represented
   by the Optical Interface Class index (or number).  This number might
   be used as an index to access a table containing all the values
   associated with a specific interface using mechanisms like Directory
   Services.  Note that each single interface parameter could be
   retrieved through a MIB.  As an example,
   [I-D.galikunze-ccamp-g-698-2-snmp-mib] gives another example on the
   Optical parameter specification includes the OII definition in
   compliance with [ITU-G.698.2] Chapter 5.3.

   Every time a new optical interface is defined or introduced into the
   market, only a MIB update will be required but there will be no
   impact on WSON protocols.

   Note also that the Control Plane may become aware of the Optical
   Interface Class semantic by a various of other ways like the network
   management system or manual provisioning.

   As a matter of fact in current WSON technology, standard and
   proprietary information must co-exist.  The introduction of the
   Optical Interface Class does not change or limit this possibility
   since the class identifier can be a means to access either public or
   vendor specific information.  In term of protocol encoding however,
   this solution has the advantage to limit eventually proprietary
   information in a fixed size field.


5.  Acknowledgements


6.  IANA Considerations

   Optical Interface code points needs to be assigned by IANA?

   All drafts are required to have an IANA considerations section (see
   the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
   for a guide).  If the draft does not require IANA to do anything, the
   section contains an explicit statement that this is the case (as



Martinelli, et al.      Expires January 17, 2013                [Page 8]


Internet-Draft        WSON Optical Interface Class             July 2012


   above).  If there are no requirements for IANA, the section will be
   removed during conversion into an RFC by the RFC Editor.


7.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.


8.  References

8.1.  Normative References

   [I-D.ietf-ccamp-rwa-wson-encode]
              Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "Routing
              and Wavelength Assignment Information Encoding for
              Wavelength Switched Optical Networks",
              draft-ietf-ccamp-rwa-wson-encode-14 (work in progress),
              April 2012.

   [I-D.ietf-ccamp-wson-signal-compatibility-ospf]
              Lee, Y. and G. Bernstein, "GMPLS OSPF Enhancement for
              Signal and Network Element Compatibility for Wavelength
              Switched Optical Networks",
              draft-ietf-ccamp-wson-signal-compatibility-ospf-08 (work
              in progress), April 2012.

   [I-D.ietf-ccamp-wson-signaling]
              Bernstein, G., Xu, S., Lee, Y., Martinelli, G., and H.
              Harai, "Signaling Extensions for Wavelength Switched
              Optical Networks", draft-ietf-ccamp-wson-signaling-03
              (work in progress), March 2012.

   [ITU-G.698.1]
              International Telecommunications Union, "Multichannel DWDM
              applications with single-channel optical interfaces", ITU-
              T Recommendation G.698.1, November 2009.

   [ITU-G.698.2]
              International Telecommunications Union, "Amplified
              multichannel DWDM applications with single channel optical
              interfaces", ITU-T Recommendation G.698.2, November 2009.

   [ITU-G.959.1]
              International Telecommunications Union, "Optical transport
              networks physical layer interfaces", ITU-T Recommendation
              G.659.1, February 2012.



Martinelli, et al.      Expires January 17, 2013                [Page 9]


Internet-Draft        WSON Optical Interface Class             July 2012


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [I-D.galikunze-ccamp-g-698-2-snmp-mib]
              Kunze, R. and D. Hiremagalur, "A SNMP MIB to manage black-
              link optical interface parameters of DWDM applications",
              draft-galikunze-ccamp-g-698-2-snmp-mib-00 (work in
              progress), June 2012.

   [I-D.lee-pce-wson-rwa-ext]
              Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing
              and Wavelength Assignment", draft-lee-pce-wson-rwa-ext-04
              (work in progress), April 2012.

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-09 (work in
              progress), March 2008.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC6163]  Lee, Y., Bernstein, G., and W. Imajuku, "Framework for
              GMPLS and Path Computation Element (PCE) Control of
              Wavelength Switched Optical Networks (WSONs)", RFC 6163,
              April 2011.

   [RFC6205]  Otani, T. and D. Li, "Generalized Labels for Lambda-
              Switch-Capable (LSC) Label Switching Routers", RFC 6205,
              March 2011.

   [RFC6566]  Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A
              Framework for the Control of Wavelength Switched Optical
              Networks (WSONs) with Impairments", RFC 6566, March 2012.


Appendix A.  Application Code Mapping

A.1.  ITU-G.698.1 Application Code Mapping

   This recomandation defines (see Section 5.3) the Application Codes:
   DScW-ytz(v) and B-DScW-ytz(v).  Where:





Martinelli, et al.      Expires January 17, 2013               [Page 10]


Internet-Draft        WSON Optical Interface Class             July 2012


   o  B: means Bidirectionals.

   o  D: means a DWDM application.

   o  S: take values N (narrow spectral excursion), W (wide spectral
      excursion).

   o  c: Channel Spacing (GHz).

   o  W: take values S (short-haul), L (long-haul).

   o  y: take values 1 (NRZ 2.5G), 2 (indicating NRZ 10G).

   o  t: take only D value is defined (link does not contain optical
      amplifier)

   o  z: take values 2 (ITU-T G.652 fibre), 3 (ITU-T G.653 fibre), 5
      (indicating ITU-T G.655 fibre).

   o  v: take values S (Short wavelength), C (Conventional), L (Long
      wavelength).

   An Optional F can be added indicating a FEC Encoding.

   Considering the 64 bits left to encode the application code for each
   ITU recomandation, the following encoding is proposed:


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |B|  p  |S|   c   |   W   |   y   |   t   |   z   |  v  |   s   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: G.689.1 Application Code Encoding

   Where (values between parenthesis refer to ITU defined values as
   reported above):

      B: = 1 bidirectional, 0 otherwise

      p (prefix): = 0 reserved, = 1 (D)

      S: = 0 (N), = 1 (W)





Martinelli, et al.      Expires January 17, 2013               [Page 11]


Internet-Draft        WSON Optical Interface Class             July 2012


      c: Channel Spacing, 4 bits mapped according to same definition in
      [RFC6205] (note that DWDM spacing apply here)

      W: = 0 reserved, = 2 (S), = 3 (L)

      y: = 0 reserved, = 1 (1), = 2 (2)

      t: = 0 reserved, = 4 (D)

      z: = 0 reserved, = 2 (2), = 3 (3), = 5 (5)

      v: = 0 reserved, = 1 (S), = 2 (C), = 3 (L)

      s (suffix): = 0 reserved, = 1 Fec Encoding

   With the following notes: values not mentioned here are not allowed
   in this application code, the last 32 bits are reserved and shall
   always be zero.

A.2.  ITU-G.698.2 Application Code Mapping

   This recomandation defines (see Section 5.3) the Application Codes:
   DScW-ytz(v) and B-DScW-ytz(v).  Since the format is exacly similar to
   Appendix A.1, this section only reports differences.

      W: take values C (link is dispersion compensated), U (link is
      dispersion uncompensated).

      t: take value A (link may contains optical amplifier)

   Also here an optical F can be added to indicate FEC encoding.

   In term of encoding applications codes follow exactly Figure 4 apart
   from the following differences:

      W: = 0 reserved, = 10 (C), = 11 (U)

      t: = 0 reserved, = 1 (A)

A.3.  ITU-G.959.1 Application Code Mapping

   This recomandation defines (see Section 5.3) the Application Codes:
   PnWx-ytz and BnWx-ytz.  Where:

   o  P,B: when presents they indicate Plural or Bidirectional

   o  n: maximum number of channels supported by the application code
      (i.e. an integer number)



Martinelli, et al.      Expires January 17, 2013               [Page 12]


Internet-Draft        WSON Optical Interface Class             July 2012


   o  W: take values I (intra-office), S (short-haul), L (long-haul), V
      (very long-haul), U (ultra long-haul).

   o  x: maximum number of spans allowed within the application code
      (i.e. an integer number)

   o  y: take values 1 (NRZ 2.5G), 2 (NRZ 10G), 9 (NRZ 25G), 3 (NRZ
      40G), 7 (RZ 40G).

   o  t: take values A (power levels suitable for a booster amplifier in
      the originating ONE and power levels suitable for a pre-amplifier
      in the terminating ONE), B (booster amplifier only), C (pre-
      amplifier only), D (no amplifiers).

   o  z: take values 1 (1310 nm sources on ITU-T G.652 fibre), 2 (1550
      nm sources on ITU-T G.652 fibre), 3 (1550 nm sources on ITU-T
      G.653 fibre), 5 (1550 nm sources on ITU-T G.655 fibre).

   The following list of suffix can be added to these application codes:

   o  F: FEC encoding.

   o  D: Adaptative dispersion conpensation.

   o  E: receiver capable of dispersion compensation.

   o  r: reduced target distance.

   o  a: power levels appropriate to APD receivers.

   o  b: power levels appropriate to PIN receivers.

   The following encoding is proposed:


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |B|  p  |       n           |   W   |     x     |   reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   y   |   t   |   z   |   s   |              reserved         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 5: G.689.1 Application Code Encoding

   Where (values between parenthesis refer to ITU defined values as
   reported above):



Martinelli, et al.      Expires January 17, 2013               [Page 13]


Internet-Draft        WSON Optical Interface Class             July 2012


      B: = 1 bidirectional, = 0 otherwise.

      p (prefix): = 0 reserved, = 2 (P).

      n: maximum number of channels (10 bits, up to 1024 channels)

      W: = 0 reserved, = 1 (I), = 2 (S), = 3 (L), = 4 (V), = 5 (U)

      x: = number of spans (6 bits, up to 64 spans)

      y: = 0 reserved, = 1 (1), = 2 (2), = 3 (3), = 7 (7), = 9 (9)

      t: = 0 reserved, = 1 (A), = 2 (B), = 3 (C), = 4 (D)

      z: = 0 reserved, = 1 (1), = 2 (2), = 3 (3), = 5 (5)

      s (suffix): = 0 reserved, = 1 (F), = 2 (D), = 3 (e), = 4 (r), = 5
      (a), = 6 (b)

   [EDITOR NOTE] if suffixes may be used together, the field has to be
   redefined as bitfield.


Appendix B.  Encoding example

   In this section we try to represent how the encoding will change
   considering the Optical Interface Class.  The main result of the
   Optical interface class will be not encoding saving in term of bytes
   but a simplified protocol support for new optical technologies.

   According to Section 5 of [I-D.ietf-ccamp-rwa-wson-encode] the
   encoding shall foresee a list of: Input Modulation Type, Input FEC
   Type, Input Client Signal Types.  All the basic objects has a lenght
   dependent on values carried on.  For example if the modulation format
   is a standard one, the related sub TLV will be 32 bits, if the
   modulation formart is a proprietary one the length is not known a
   priori.

   Using the concept of interface class the same object will likely
   become as the one represented in Figure 6.











Martinelli, et al.      Expires January 17, 2013               [Page 14]


Internet-Draft        WSON Optical Interface Class             July 2012


      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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     RB Set Field                              |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|E|                      Reserved                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type/length for Interface Class list              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Input Interface Class=1                         |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Input Interface Class=2                         |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Input Interface Class=3                         |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Processing Capabilities List Sub-Sub-TLV (opt)        |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type/length for Interface Class list              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Output Interface Class=A                        |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Output Interface Class=B                        |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 6

   With the following notes:

   o  Current draft just defines the Optical interface class encoding as
      3 words of 32 bits but, for usage within WSON protocol extentions
      a proper TLV header shall be defined.  In this case we represent a
      list since the original example in
      [I-D.ietf-ccamp-rwa-wson-encode] use lists.





Martinelli, et al.      Expires January 17, 2013               [Page 15]


Internet-Draft        WSON Optical Interface Class             July 2012


   o  Current example just represent input and output classes by numbers
      (1,2,3) and letters (A,B) since example only shows how encoding is
      simplified.

   o  Optical interface classes has a fixed size while basic encoding
      blocks of [I-D.ietf-ccamp-rwa-wson-encode] have sizes that varies
      depending on proprietary informations.

   As in the example above, the concept of Optical interface class is
   not to save encoding bytes but to keep the optical semantic outside
   of GMPLS protocols.


Authors' Addresses

   Giovanni Martinelli (editor)
   Cisco
   via Philips 12
   Monza  20900
   IT

   Phone: +39 039 209 2044
   Email: giomarti@cisco.com


   Gabriele M Galimberti
   Cisco
   Via Philips,12
   20052 - Monza
   Italy

   Phone: +390392091462
   Email: ggalimbe@cisco.com


   Lyndon Ong
   Ciena Corporation
   US

   Email: lyong@ciena.com











Martinelli, et al.      Expires January 17, 2013               [Page 16]


Internet-Draft        WSON Optical Interface Class             July 2012


   Daniele Ceccarelli
   Ericsson
   via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: daniele.ceccarelli@ericsson.com


   Cyril Margaria
   Nokia Siemens Networks
   St-Martin str. 76
   Munchen,   81541
   Germany

   Phone: +49-89-5159-16934
   Email: cyril.margaria@nsn.com


































Martinelli, et al.      Expires January 17, 2013               [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/