WSON Optical Interface Class
draft-martinelli-wson-interface-class-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Giovanni Martinelli , Gabriele Galimberti , Lyndon Ong , Daniele Ceccarelli | ||
| Last updated | 2011-10-31 (Latest revision 2011-07-04) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-martinelli-wson-interface-class-01
Internet Engineering Task Force G. Martinelli, Ed.
Internet-Draft G. Galimberti
Intended status: Informational Cisco
Expires: May 3, 2012 L. Ong
Ciena Corporation
D. Ceccarelli
Ericcsson
October 31, 2011
WSON Optical Interface Class
draft-martinelli-wson-interface-class-01
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 May 3, 2012.
Copyright Notice
Copyright (c) 2011 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
Martinelli, et al. Expires May 3, 2012 [Page 1]
Internet-Draft WSON Optical Interface Class October 2011
(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 and Procedures . . . . . . . . . . . . . . . . . . 4
3.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Optical Interface Class Semantic . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Encoding example . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Martinelli, et al. Expires May 3, 2012 [Page 2]
Internet-Draft WSON Optical Interface Class October 2011
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.
Regarding how to evaluate, there are a list of parameters identified
according to ITU specification [ITU-G.698.1] and [ITU-G.698.2]. In
particular the following set of parameters has been chosen: signal
bit rate, modulation format, forward error correction.
At the current state of art new high bit rates (40G/100G) are under
development as well as new modulation formats and it is not clear if
and when there will be a dominating technology. In a current
realistic scenario DWDM optical networks manage different bit-rates
as well as different modulation formats over the same link. So in
general different signal characteristics will coexist at the same
time.
To a further extent, the WSON activity will consider the case where
the control plane has optical impairments awareness as detailed in
[I-D.ietf-ccamp-wson-impairments]. The Control Plane function
related to impairment awareness might require some additional
interface parameters to assess the optical feasibility path. In such
a case is likely further protocol extensions might be required just
to add some parameters.
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 a
simplified but general representation rather than encoding saving.
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]. In details, the
following list of parameters is considered:
Martinelli, et al. Expires May 3, 2012 [Page 3]
Internet-Draft WSON Optical Interface Class October 2011
o Modulation Format. Only NRZ currently defined.
o FEC, according to G.709 and G.975.
o Bit Rate.
Note that this list of parameters is defined by ITU and might be
subject to change due to internal physics.
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 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, PCEP extension might need 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 and Procedures
The Optical Interface Class will be a unique number that identify all
information related to optical characteristic's of a physical
interface. Since current implementation of physical interfaces may
support different optical caracteristics, a single interface may
support multiple interface classes.
In term of RWA process the only operation required to assess the
optical compatibility (interfaces or regeneration points) is to check
if the two optical endpoint have the same Class value. Note that if
a regeneration happens, the complete LSP may have more then two
optical enpoints since regenerations shall satisfy the signal
compatibility as well. 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 related to signal
Martinelli, et al. Expires May 3, 2012 [Page 4]
Internet-Draft WSON Optical Interface Class October 2011
compatibility while this would be teh case if the parameters are
listed explicitly.
This 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 segment of a WSON LSP.
+---+ +----+ +----+ +-----+ +----+ +---+
| I |----| N1 |---| N2 |-----| REG |-----| N3 |----| E |
+---+ +----+ +----+ +-----+ +----+ +---+
class1 class1 class2 class2
|<----------------------------->|<-------------------->|
LSP
|<---------------------------------------------------->|
Figure 1
In case the RWA process will result in a path that need a wavelength
conversion each interface involved in the wavelength conversion must
satisfy the Optical Interface Class constrain. As represented in
Figure 1, two different Optical Interface Classes are required for
the given LSPs.
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 parameter values are standardized (e.g. new modulation
formats become standard) the wson protocols and RWA don't need any
extensions.
3.2. 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].
Martinelli, et al. Expires May 3, 2012 [Page 5]
Internet-Draft WSON Optical Interface Class October 2011
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Optical Interface Class
Where the first 32 bist of the encoding shall be used to indentify
the sematic of the Optical Interface Class in the following way:
S
Standard bit set to 1 if use the code points to indentify ITU.T
application codes.
OI Code Points
The following values are identified when the S bit is 0:
0: reserved
1: Enterprise Specific Optical Interface Class
When the S bit is set to 1:
0: reserved
1: [ITU-G.698.1] application code.
2: [ITU-G.698.2] application code.
The Optical Interface Class encoding is a number 64 bits wides. In
case S=0 and OI code point is 1, the first 32 bits shall match the
IANA enterprise number.
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
elements. In this way the same class value will have the same
meaning on every 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.
Martinelli, et al. Expires May 3, 2012 [Page 6]
Internet-Draft WSON Optical Interface Class October 2011
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 a number represented by the Optical Interface Class. 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,
[draft-galimbe-kunze-g698-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
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.
Martinelli, et al. Expires May 3, 2012 [Page 7]
Internet-Draft WSON Optical Interface Class October 2011
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-12 (work in progress),
August 2011.
[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-07 (work
in progress), October 2011.
[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-02
(work in progress), September 2011.
[ITU-G.698.1]
International Telecommunications Union, "Multichannel DWDM
applications with single-channel optical interfaces", ITU-
T Recommendation G.698.1, December 2006.
[ITU-G.698.2]
International Telecommunications Union, "Amplified
multichannel DWDM applications with single channel optical
interfaces", ITU-T Recommendation G.698.2, July 2007.
[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.ietf-ccamp-wson-impairments]
Lee, Y., Bernstein, G., Li, D., Martinelli, G., Chen, M.,
Han, J., Galimberti, G., Tanzi, A., Bianchi, D., Kattan,
M., Schroetter, D., Ceccarelli, D., Bellagamba, E., and D.
Caviglia, "A Framework for the Control of Wavelength
Switched Optical Networks (WSON) with Impairments",
draft-ietf-ccamp-wson-impairments-07 (work in progress),
April 2011.
Martinelli, et al. Expires May 3, 2012 [Page 8]
Internet-Draft WSON Optical Interface Class October 2011
[I-D.lee-pce-wson-rwa-ext]
Lee, Y., Zhang, F., Casellas, R., Margaria, C., Dios, O.,
and G. Bernstein, "PCEP Extension for WSON Routing and
Wavelength Assignment", draft-lee-pce-wson-rwa-ext-02
(work in progress), July 2011.
[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.
Appendix A. 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 3.
Martinelli, et al. Expires May 3, 2012 [Page 9]
Internet-Draft WSON Optical Interface Class October 2011
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 3
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 May 3, 2012 [Page 10]
Internet-Draft WSON Optical Interface Class October 2011
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 May 3, 2012 [Page 11]
Internet-Draft WSON Optical Interface Class October 2011
Daniele Ceccarelli
Ericcsson
via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Martinelli, et al. Expires May 3, 2012 [Page 12]