One document matched: draft-martinelli-wson-interface-class-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY RFC6163 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6163.xml">
<!ENTITY I-D.ietf-ccamp-wson-impairments SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-wson-impairments-07.xml">
<!ENTITY I-D.ietf-ccamp-rwa-wson-encode SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-rwa-wson-encode-12.xml">
<!ENTITY I-D.ietf-ccamp-wson-signal-compatibility-ospf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-wson-signal-compatibility-ospf-07.xml">
<!ENTITY I-D.ietf-ccamp-wson-signaling SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-wson-signaling-02.xml">
<!ENTITY I-D.lee-pce-wson-rwa-ext SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-lee-pce-wson-rwa-ext-02.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-martinelli-wson-interface-class-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title> WSON Optical Interface Class </title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Giovanni Martinelli" initials="G.M." role="editor"
surname="Martinelli">
<organization>Cisco</organization>
<address>
<postal>
<street> via Philips 12</street>
<code>20900</code>
<city>Monza</city>
<country>IT</country>
</postal>
<phone>+39 039 209 2044</phone>
<email>giomarti@cisco.com</email>
</address>
</author>
<author fullname="Gabriele M Galimberti" initials="G.M.G."
surname="Galimberti">
<organization>Cisco</organization>
<address>
<postal>
<street>Via Philips,12</street>
<city>20052 - Monza</city>
<country>Italy</country>
</postal>
<phone>+390392091462</phone>
<email>ggalimbe@cisco.com</email>
</address>
</author>
<author fullname="Lyndon Ong" initials="L.O."
surname="Ong">
<organization>Ciena Corporation</organization>
<address>
<postal>
<street></street>
<city></city>
<country>US</country>
</postal>
<email>lyong@ciena.com</email>
</address>
</author>
<author fullname="Daniele Ceccarelli" initials="D.C."
surname="Ceccarelli">
<organization>Ericcsson</organization>
<address>
<postal>
<street>via A. Negrone 1/A</street>
<city>Genova - Sestri Ponente</city>
<country>Italy</country>
</postal>
<email>daniele.ceccarelli@ericsson.com</email>
</address>
</author>
<date month="October" year="2011" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>ROUTING</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>GMPLS, WSON</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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 <xref target="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 <xref target="ITU-G.698.1"/> and <xref target="ITU-G.698.2"/>.
In particular the following set of parameters has been chosen: signal
bit rate, modulation format, forward error correction.
</t>
<t>
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.
</t>
<t>
To a further extent, the WSON activity will consider the case where the control plane has
optical impairments awareness as detailed in <xref target="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.
</t>
<t>
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.
</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Existing WSON Signal Compatibility protocol extension">
<t>
Within the current WSON activity the signal compatibility
encoding is defined within the <xref target="I-D.ietf-ccamp-rwa-wson-encode"/>. In details,
the following list of parameters is considered:
<list style="symbols">
<t>Modulation Format. Only NRZ currently defined.</t>
<t>FEC, according to G.709 and G.975.</t>
<t>Bit Rate.</t>
</list>
Note that this list of parameters is defined by ITU and might be subject to change due to
internal physics.
</t>
<t>
At the current status, the above encoding is going to be used within several WSON specific protocol extensions.
<list style='symbols'>
<t>
OSPF <xref target="I-D.ietf-ccamp-wson-signal-compatibility-ospf"/> since the path
computation function need to consider optical interface parameters during the
RWA process.
</t>
<t>
RSVP <xref target="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).
</t>
<t>
In addition, PCEP extension might need similar parameters as envisaged here
<xref target="I-D.lee-pce-wson-rwa-ext"/>.
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section anchor="Optical_interf_id" title="Optical Interface Class">
<section title="Concept and Procedures">
<t>
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.
</t>
<t>
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 compatibility while this would be teh case if the parameters
are listed explicitly.
</t>
<t>
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.
</t>
<figure align="center" anchor="lsp_class">
<preamble></preamble>
<artwork align="left"><![CDATA[
+---+ +----+ +----+ +-----+ +----+ +---+
| I |----| N1 |---| N2 |-----| REG |-----| N3 |----| E |
+---+ +----+ +----+ +-----+ +----+ +---+
class1 class1 class2 class2
|<----------------------------->|<-------------------->|
LSP
|<---------------------------------------------------->|
]]></artwork>
<postamble></postamble>
</figure>
<t>
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 <xref target="lsp_class"/>, two different Optical Interface Classes are required for
the given LSPs.
</t>
<t>
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.
</t>
</section>
<section title="Encoding">
<t>
The following Optical Interface Class must be be used in proper
TLVs for different WSON protocol extensions.
</t>
<t>
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 <xref target="I-D.ietf-ccamp-rwa-wson-encode"/>.
</t>
<figure align="center" anchor="interface_class_encoding" title="Optical Interface Class">
<artwork align="left"><![CDATA[
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
Where the first 32 bist of the encoding shall be used to indentify the sematic of the
Optical Interface Class in the following way:
<list style="hanging">
<t hangText="S"> <vspace blankLines="0" />
Standard bit set to 1 if use the code points to indentify ITU.T application codes.
</t>
<t hangText="OI Code Points"> <vspace blankLines="0" />
The following values are identified when the S bit is 0:
<list style="empty">
<t>0: reserved</t>
<t>1: Enterprise Specific Optical Interface Class</t>
</list>
When the S bit is set to 1:
<list style="empty">
<t>0: reserved</t>
<t>1: <xref target="ITU-G.698.1"/> application code.</t>
<t>2: <xref target="ITU-G.698.2"/> application code.</t>
</list>
</t>
</list>
</t>
<t>
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.
</t>
</section>
</section>
<section title="Optical Interface Class Semantic">
<t>
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.
</t>
<t>
An example of semantic is the "Application Code" within <xref target="ITU-G.698.1"/>
and <xref target="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 <xref target="ITU-G.698.2"/> Chapter 5.3.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>Optical Interface code points needs to be assigned by IANA?</t>
<t>All drafts are required to have an IANA considerations section (see
<xref target="I-D.narten-iana-considerations-rfc2434bis">the update of
RFC 2434</xref> 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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>All drafts are required to have a security considerations section.
See <xref target="RFC3552">RFC 3552</xref> for a guide.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&I-D.ietf-ccamp-rwa-wson-encode;
&I-D.ietf-ccamp-wson-signal-compatibility-ospf;
&I-D.ietf-ccamp-wson-signaling;
<reference anchor="ITU-G.698.1">
<front>
<title>
Multichannel DWDM applications with single-channel optical interfaces
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="December" year="2006"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.698.1"/>
</reference>
<reference anchor="ITU-G.698.2">
<front>
<title>
Amplified multichannel DWDM applications with single channel optical interfaces
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="July" year="2007"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.698.2"/>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC3552;
&I-D.narten-iana-considerations-rfc2434bis;
&RFC6163;
&I-D.ietf-ccamp-wson-impairments;
&I-D.lee-pce-wson-rwa-ext;
<!-- A reference written by by an organization not a person. -->
</references>
<section anchor="app-example" title="Encoding example">
<t>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.
</t>
<t>
According to Section 5 of <xref target="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.
</t>
<t>
Using the concept of interface class the same object will likely become as the one represented
in <xref target="optical_class_example"/>.
</t>
<figure align="center" anchor="optical_class_example">
<preamble></preamble>
<artwork align="left"><![CDATA[
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t>
With the following notes:
<list style="symbols">
<t> 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 <xref target="I-D.ietf-ccamp-rwa-wson-encode"/>
use lists.
</t>
<t> 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.
</t>
<t> Optical interface classes has a fixed size while basic encoding blocks of
<xref target="I-D.ietf-ccamp-rwa-wson-encode"/> have sizes that varies depending on
proprietary informations.
</t>
</list>
</t>
<t>
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.
</t>
</section>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:10:14 |