One document matched: draft-agraz-ccamp-wson-impairment-rsvp-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 05:05:16 |