Internet DRAFT - draft-martinelli-wson-interface-class
draft-martinelli-wson-interface-class
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]
