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]