Network Working Group Fernando Agraz Internet Draft UPC Category: Informational Yabin Ye Jianrui Han Huawei Expires: April 15, 2011 October 16, 2010 RSVP-TE Extensions in Support of Impairment Aware Routing and Wavelength Assignment in Wavelength Switched Optical Networks (WSONs) draft-agraz-ccamp-wson-impairment-rsvp-00.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 April 15, 2011. Abstract This document provides RSVP-TE extensions to support Generalized Multi-Protocol Label Switching (GMPLS) control of Impairment Aware Routing and Wavelength Assignment in Wavelength Switched Optical Networks (WSONs). Table of Contents 1. Introduction................................................2 agraz Expires April 2011 [Page 1] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 2. Architecture Overview........................................2 3. RSVP-TE Protocol Extensions..................................3 3.1. PATH message modification...............................3 3.2. RESV message modification...............................9 3.3. Error messages modification.............................9 3.4. Remote Q-factor Check...................................9 3.4.1. Remote Q-factor Request...........................10 3.4.2. Remote Q-factor Response..........................10 3.4.3. Remote LSP ACK/NACK...............................10 4. Security Considerations.....................................11 5. IANA Considerations........................................11 6. Acknowledgments............................................11 7. References.................................................12 7.1. Normative References...................................12 7.2. Informative References.................................12 8. Authors' Addresses.........................................12 9. Contributors...............................................13 1. Introduction [Imp-Frame] provides a framework for applying GMPLS and the Path Computation Element architecture to the control of WSONs to address the Impairment Aware RWA problem. ''Distributed WA and/or IV'' is one of IA-RWA path computation architectures described in the [Imp-Frame]. This document defines extensions to the RSVP-TE protocol to Carry physical layer impairments (PLI) information which will be used in the impairment validation process. The protocol extensions is implemented and emulated in the ''Dynamic Impairment Constraint Networking for Transparent Mesh Optical Networks'' (DICONET) project which is funded by European commission through the 7th Framework programme. The intent of this document is to show the result of DICONET project and provide an input related to OSPF extensions for CCAMP in IETF. 2. Architecture Overview As [Imp-Frame] described, in the non-impairment RWA situation [WSON- Frame] it was shown that a distributed wavelength assignment (WA) process carried out via signaling can eliminate the need to distribute wavelength availability information via an IGP. A similar approach can allow for the distributed computation of impairment effects and avoid the need to distribute impairment characteristics of network elements and links via route protocols or by other means. In this document we extend RSVP-TE signaling protocol to carry the PLIs related information for quality of Transmission(QoT) feasibility agraz Expires April 2011 [Page 2] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 check at the destination node. And we use OSPF-TE extensions to disseminate wavelength availability information which can be referred to [RWA-OSPF]. The IA-RWA algorithm at source node uses 1) topology information available in TED through OSPF-TE extensions, 2) wavelength availability information disseminated using OSPF-TE extensions, and other static PLI information preloaded or configured in database to compute route and wavelength assignment. The selected wavelength can be inserted in a suggested label object of RSVP-TE PATH message. Then the route is given to RSVP-TE protocol, which carries the wavelength availability information and other PLI related information (as discussed later). When the PATH message reaches the destination node, it invokes feasibility check. Once a feasible route and wavelength are chosen RSVP-TE sends RESV message towards the destination, which configures all devices along the path. In the following subsections we discuss detailed description of the extensions made to standard RSVP-TE protocols used in the Distributed WA and/or IV architecture. The OSPF-TE extension for wavelength availability information dissemination can be referred to [RWA-OSPF]. 3. RSVP-TE Protocol Extensions 3.1. PATH message modification In order to carry all the impairment related information, RSVP-TE PATH message has to be extended. The information required for impairment evaluation and feasibility check is the following: o The list of sections composing the proposed route o For every section o Optical parameters o Active LSPs list, specifying for every LSP .wavelength .input power .LSP id o Available wavelengths list, specifying for every wavelength .wavelength id agraz Expires April 2011 [Page 3] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 .input power (on the section) Due to the specific usage of the collected parameters, we decided to add a new object inside the PATH available object: the Optical Path Description object (OPD object), which contains all the additional information required for impairment evaluation and feasibility check. As input power is one of the important parameter for Q-factor evaluation it is worth to be signaled. Q-factor is an integrated parameter to estimate the optical signal performance taking into account physical impairments including noise, chromatic and polarization mode dispersion, crosstalk and filter concatenation effects, etc,. Q-factor evaluation is an optimal mechanism to verify if the service is feasible. But other parameter (e.g., OSNR) also can be replace of Q-factor. The protocol extensions in this document is dependent of this parameter which is used to verify the service feasibility. In the follow we take Q-factor for instance. Finally, OPD object may contain three TLVs: o AFFECTED_LSPS_TLV Contains an ordered sequence of affected LSP_ID fields, which is later used by SECTION_DESCRIPTION_TLV to identify the affected LSP, using identifier as the index of the position in the sequence. Index value of 0 is considered related to the new/current LSP, so first element of the sequence has index 1. 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Lsp_Id #1 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Lsp_Id ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Lsp_Id #M / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type, Length: TLV Header Lsp_Id[]: sequence of LSP_ID (which is source node address + serial number) o SECTION_DESCRIPTION_TLV agraz Expires April 2011 [Page 4] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 It is the TLV describing a section of the proposed route. It contains the full description of a section in terms of identifier, optical components and available wavelengths. Its structure is the following: 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SectClass | SEQ_Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / NodeId / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / SectInPower / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optical_Component #1 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optical_Component ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optical_Component #N / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Channels / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type, Length: TLV Header SectClass: IN, FIBER, OUT, TRANSPONDER, RECEIVER SEQ_Number: ID sequence number NodeId: ADDR_SUBTLV containing node id SectInPower: section's default input power (which is required for Q- factor evaluation) Optical_Component[]: ordered sequence of OPTICAL_COMPONENT_SUBTLV Channels: CHANNEL_LIST_SUBTLV ''SectInPower'' parameter is the default input power value for the section, which can be used for any wavelength whose input power is not specified in Channels field. ''Optical_Component'' is a ordered sequence of optical elements along the section. This TLV requires the definition of three SUB-TLVs: agraz Expires April 2011 [Page 5] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 o ADDR_SUBTLV It contains the ID of a node, in an IPv4 or an IPv6 address format. 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Word #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Word #K | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type, Flags, Length: SUB-TLV Header Addr: ID creating node Addr, depending on the type value, may be an IPv4 address (4 bytes, K=1) or an IPv6 address (16 bytes, K=4). o OPTICAL_COMPONENT_SUBTLV Describes any optical component of the current section. 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O| ptElemClass |C| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise_ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ParamValueList Word #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ParamValueList Word #K | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type, Flags, Length: SUB-TLV Header O: Custom/Standard optical element class OptElemClass: DCU, VOA, FIBER, AMP agraz Expires April 2011 [Page 6] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 C: Custom/Standard code Code: Code referring ElemClass Dictionary definition Enterprise_ID: ENTERPRISE ID (optional field) ParamValueList: List of K word containing instance parameters for the optical element. It is a sub-TLV list. The ''O'' and ''C'' fields refers to their following fields ''OptElemClass'' and ''Code'': a value of 0 states that the following class/code is a STANDARD code, otherwise it is a CUSTOM code. If a code is standard, an extra field (''Enterprise_ID'') has to be specified in order to have a univocal reference to the right component. In case of custom code, no ''Enterprise_ID'' is given. Standard classes and codes are supposed to be stored in a Dictionary (''ElemClass Dictionary'') and the generic parameters (e.g. attenuation) of referred elements are supposed to be retrievable just querying for their code. Instance parameters (e.g., length) are instead given in the ''ParamValueList'' section of the SUBTLV: for every standard element, it is defined a set of instance parameters which need to be specified. Conversely, custom classes/codes may not have their description stored, so all of their parameters may have to be specified in the ''ParamValueList'' section. From what said above, ''ParamValueList'' is specific for every kind of optical element, and the kind and order of specified parameters may vary from element to element. A detailed OPTICAL_COMPONENT encoding is presented in Appendix. o CHANNEL_LIST_SUBTLV It provides a list of all the supported channels (used and available wavelengths) specifying for each of them the input power on the section (if such parameter is not specified, the default section's input power specified in the SECTION_DESCRIPTION_TLV has to be used). agraz Expires April 2011 [Page 7] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Grid | C.S. | lowest frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Lsp_Info #1 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Lsp_Info ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Lsp_Info #Z / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type, Flags, Length: SUB-TLV Header Grid: ITU-T grid specification C.S.: Channel spacing used in a DWDM system Lsp_Info[]: LSP_INFO ordered sequence LSP_INFO is a data structure containing the wavelength and (optionally) the input power of a (active or new) LSP: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength |P| LSP_Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Power (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wavelength: Wavelength number (193.1THz +/- w*(channel spacing) P: Input power bit mask LSP_Index: Position of LSP in AFFECTED_LSPS TLV Power: Input Power (optional) ''Wavelength'' is a signed integer specifying a given wavelength in function of its ''cell spacing distance'' from the given pivot frequency of 193.1THz. ''p '' just tells the parser if ''Power'' field is present ( p = 1) or not (p = 0). agraz Expires April 2011 [Page 8] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 ''LSP_Index'' is the index value of current channel with reference to AFFECTED_LSPS_TLV's LSPs list given in the same OPD object. As explained earlier, index 0 is referred to available channels, so LSP are indexed in AFFECTED_LSPS_TLV starting from 1. Power is an optional parameter referring to the input power of the current channel on current section. If not specified, SECTION_DESCRIPTION_TLV's SectInPower parameter is used. 3.2. RESV message modification RESV message does not require any particular modification in order to implement described behaviors: the information transported is the same as the original RESV messages. 3.3. Error messages modification Error messages do not need per se any change. New error classes (due to impairment, resources unavailability, etc.,) can be translated as new error types, extending the set of the existing ones already defined by standard protocol. However, there are small changes in the way they are sent/handled. 3.4. Remote Q-factor Check The setup of a new LSP can potentially impact existing LSPs. Therefore, the destination node of the new LSP contacts the destination nodes of the affected LSPs in order to let them evaluate the impact of the creation of this new LSP over their existing ones. The proposed solution is to let the destination node to send a copy of the OPD to the destination nodes of the ''affected'' LSPs. Then the task of the affected destination nodes is to find out which part of the OPD object contains the information useful for their calculation. After performing the evaluation, the destination nodes of affected LSPs send back the responses to the destination node of the new requested LSP. Once all responses are received by the destination node of the new LSP, this node takes a decision and sends an ACK if LSP is finally approved or a NACK if is not approved to all affected destination nodes. So, (feasibility control module) FCM needs to find and query all others FCMs on the affected LSPs destination nodes. The full description of new LSP and the required information about affected LSPs (the OPD object in the PATH message) will be sent to local FCM module from signaling module when the PATH message reaches the destination node. Then the same message will be forwarded to all the remote FCMs running on the destination nodes of affected LSPs, agraz Expires April 2011 [Page 9] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 which in turn encodes it in the desired call to the local Q-tool. The remote FCM modules and Q-tool will extract required information from OPD object for the evaluation of the effect of the new LSP on the already established LSPs. For this purpose we have defined the following three messages described in next three subsections. 3.4.1. Remote Q-factor Request 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / OPD object / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.4.2. Remote Q-factor Response 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Grid | C.S. | lowest frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Frequency Bitmap / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Q-factor Values Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The bitmap encodes the wavelengths used by active affected LSPs on responding node. ''Q-factor Values Array'' is an ordered list of Q- factor values associated to such LSPs. 3.4.3. Remote LSP ACK/NACK The remote LSP ACK is the message sent by local FCM to remote affected LSPs FCMs to inform them that the new LSP passed the impairment check and will be established. It allows the remote nodes to update their database with the new values. The remote LSP NACK is sent when such a LSP fails the Q verification. agraz Expires April 2011 [Page 10] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Grid | C.S. | lowest frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Frequency Bitmap / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / LSP ID / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The bitmap encodes the wavelength used by activating LSP. The ''LSP ID'' contains the LSP_ID object identifying the activating LSP. 4. Security Considerations The use of control plane protocols for signaling, routing, and path computation opens an OTN to security threats through attacks on those protocols. The data plane technology for an OTN does not introduce any specific vulnerabilities, and so the control plane may be secured using the mechanisms defined for the protocols discussed. For further details of the specific security measures refer to the documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane. 5. IANA Considerations This document makes not requests for IANA action. 6. Acknowledgments This work is supported by DICONET project under FP7/2007-2013 - - GA nr 216338 agraz Expires April 2011 [Page 11] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 7. References 7.1. Normative References [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003 7.2. Informative References [Imp-Frame] G. Bernstein, Y. Lee, D. Li, G. Martinelli, "A Framework for the Control and Measurement of Wavelength Switched Optical Networks (WSON) with Impairments", Work in Progress, draft-bernstein-ccamp-wson-impairments-05.txt [RWA-ENCODE] G. Bernstein, Y. Lee, D. Li, " Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Work in Progress, draft-ietf-ccamp- rwa-wson-encode-05.txt [RWA-OSPF] Fatai Zhang, ''OSPF-TE Extensions for General Network Element Constraints'', Work in Progress, draft-zhang- ccamp-general-constraints-ospf-ext-00.txt. 8. Authors' Addresses Fernando Agraz Universitat Politecnica de Catalunya C/Jordi Girona, 1-3 D4-S107, 08034 Barcelona, Spain Phone: +34 9340107179 Email: agraz@tsc.upc.edu Yabin Ye Huawei Technologies Dusseldorf GmbH, Riesstr. 25,D-3.0G 80992 Munich, Germany Phone: 0049-891588344078 Email: yabin.ye@huawei.com Jianrui Han Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China agraz Expires April 2011 [Page 12] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 Phone: +86-755-28977943 Email: hanjianrui@huawei.com 9. Contributors Chava Vijaya Saradhi CREATE-NET Via alla Cascata 56/D-38123, Povo-Trento, Italy Phone: 0039-0461 408400 - ext. 401 Email: saradhi.chava@create-net.org Antonio Francescon CREATE-NET Via alla Cascata 56/D-38123, Povo-Trento, Italy Phone: 0039-0461 408400 - ext. 605 Email: antonio.francescon@create-net.org Intellectual Property The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into agraz Expires April 2011 [Page 13] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (c) 2010 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 (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. agraz Expires April 2011 [Page 14] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 Appendix Note that, all the encoding is relative to the processing of OPD. Various optical component types and component parameters type are defined in the following Table: agraz Expires April 2011 [Page 15] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 +---------------+-----------------------------+--------------+ |Component Type | Parameter Type | Wavelength | | | | Related? | +---------------+-----------------------------+--------------+ | |101=BitRate | Related | | +-----------------------------+--------------+ | |102=Power | Related | | +-----------------------------+--------------+ | |103=Center wavelength | Related | | | (for each channel) | | | 0=Transmitter +-----------------------------+--------------+ | |104=RefWavelength | Unrelated | | +-----------------------------+--------------+ | |105=Extinction ratio | Related | | +-----------------------------+--------------+ | |106=Modulation format | Related | | +-----------------------------+--------------+ | |107=Type of FEC | Related | +---------------+-----------------------------+--------------+ | |120=fiber type | Unrelated | | +-----------------------------+--------------+ | |121=fiber length | Unrelated | | +-----------------------------+--------------+ | |122=Dispersion parameter | Unrelated | | 1 = Fiber +-----------------------------+--------------+ | or |123=Dispersion slope | Unrelated | | 2 = DCM +-----------------------------+--------------+ | |124=Linear attenuation | Unrelated | | +-----------------------------+--------------+ | |125=Nonlinear parameter | Unrelated | | +-----------------------------+--------------+ | |126=Effective core area | Unrelated | | +-----------------------------+--------------+ | |127=PMD | Unrelated | | +-----------------------------+--------------+ | |128=Insertion Loss | Unrelated | +---------------+-----------------------------+--------------+ | 3=Attenuator |130=Attenuation | Related | +---------------+-----------------------------+--------------+ | |140=Responsivity | Related | | +-----------------------------+--------------+ | |141=Absolute threshold level | Related | | +-----------------------------+--------------+ | |142=Thermal noise density | Unrelated | | +-----------------------------+--------------+ | |143=power | Related | | +-----------------------------+--------------+ agraz Expires April 2011 [Page 16] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 | |144=inner filter type | Unrelated | | +-----------------------------+--------------+ | |145=inner filter order | Unrelated | | +-----------------------------+--------------+ | |146= inner filter Noise | Unrelated | | |equivalent bandwidth factor | | | +-----------------------------+--------------+ | 4=Receiver |147= inner filter 3-dB | Related | | | bandwidth | | | +-----------------------------+--------------+ | |148=inner filter center | Related | | |wavelength for each channel | | | +-----------------------------+--------------+ | |149=PMD | Unrelated | | +-----------------------------+--------------+ | | 41=residualCD | Unrelated | | +-----------------------------+--------------+ | | 42=Q value for each channel | Related | | +-----------------------------+--------------+ | | 43=ver for each channel | Related | | +-----------------------------+--------------+ | | 44=Insertion Loss | Unrelated | +---------------+-----------------------------+--------------+ | |151=Spontaneous emission | Unrelated | | | factor | | | +-----------------------------+--------------+ | |151=Amplifier Gain | Unrelated | | +-----------------------------+--------------+ | 5=Amplifier |152=Insertion Loss | Unrelated | | +-----------------------------+--------------+ | |153=in_power | Unrelated | | +-----------------------------+--------------+ | |154=out_power | Unrelated | +---------------+-----------------------------+--------------+ | |170=Filter Type | Unrelated | | +-----------------------------+--------------+ | |171=Order of the filter | Unrelated | | +-----------------------------+--------------+ | 7=Filter |172=Noise equivalent | Unrelated | | | bandwidth | | | +-----------------------------+--------------+ | |173=3dB bandwidth of the filter Unrelated | | +-----------------------------+--------------+ | |174=Centre wavelength for | Related | | | each channel | | +---------------+-----------------------------+--------------+ | 8=Node |180=Adjacent channel crosstalk Related | agraz Expires April 2011 [Page 17] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 +---------------+-----------------------------+--------------+ Note that regenerator parameters have not been defined since control plane extensions to handle regenerators are not considered in DICONET project so far. Other parameters are encoded in the following format: 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Value 0 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Value N / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ''Type'' field indicates the parameter type and ''Value'' field can have a variable size according to the size of parameter's data type. As it can be seen, the encoding is designed for storing more than one value. Depending on type of the parameter, it stores a single value or a list of values (the number of stored values could be obtained from the sub-TLV's length (clearly after subtracting header size) and the single parameter value length). Optical Component's Parameters SubType (Compact encoding): Basic encoding is easy to implement, but increases the overhead due to sub-TLV's header (e.g. in the case of single value parameter with 4 bytes the overhead is 100%). As the sub-TLV's parameters are mainly used in the OPD object (which are inserted in the PATH messages), the usage of such encoding may lead to increased overall packet size. So, instead of using a sub-TLV for encoding single parameter an efficient and less size-greedy approach is to encode the entire set of components parameters in one sub-TLV. This leads to the definition of the COMPONENT_PARAMETERS_SET SUB TLVs, based on the type of component. TRANSMITTER: agraz Expires April 2011 [Page 18] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Grid | C.S. | lowest frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Frequency Bitmap / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Bitrate Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Power Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Extinction Ratio Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Modulation Format Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / FEC Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wavelength Number: the number of wavelengths available on device Grid: ITU grid encoding CS: Channel Spacing encoding Lowest frequency: index of the lowest frequency in the bitmap with reference to the reference frequency Reference frequency: the reference frequency for the bitmap Frequency Bitmap: the bitmap encoding the available wavelengths / frequencies, according to the grid and cell spacing specified. It has a fixed length of 20 byte (for a maximum of 160 monitored lambdas) Arrays: Every Array field is simply a sequence of K values,with no additional headers and where K is equal to wavelength number. The type of value is related to the parameter (float or signed/unsigned 32 bit integer) FIBER/DCM: agraz Expires April 2011 [Page 19] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AttndB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aeff | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PMD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Insertion Loss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length of this sub-TLV is fixed, having only one instance of single value (not an array) parameter encoded in it. ATTENUATOR: 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Grid | C.S. | lowest frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Frequency Bitmap / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Attn Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This sub-TLV has a variable length and depends on the value of ''Wavelength Number''. RECEIVER: agraz Expires April 2011 [Page 20] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Grid | C.S. | lowest frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Frequency Bitmap / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filter Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filter Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filter NEBFactor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Filter Bandwidth Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responsitivity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Thermal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Power | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PMD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ResidualCD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Insertion Loss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Q Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / BER Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As it could be seen, such a sub-TLV includes the filter information. The length of this sub-TLV is variable, depending on the value of ''Wavelength Number''. AMPLIFIER: agraz Expires April 2011 [Page 21] draft-agraz-ccamp-wson-impairment-ospf-00.txt October 2010 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | nsp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GaindB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Insertion Loss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | inP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | outP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length of this sub-TLV is fixed, having only one instance of single value (not an array) parameter encoded in it. NODE: 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 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Grid | C.S. | lowest frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Frequency Bitmap / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filter Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filter Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filter NEBFactor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Filter Bandwidth Array / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | swxt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As it could be seen, such a sub-TLV includes the filter information. The length of this sub-TLV is variable, depending on the value of ''Wavelength Number''. agraz Expires April 2011 [Page 22]