One document matched: draft-martinelli-ccamp-wson-iv-info-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 RFC6163 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6163.xml">
<!ENTITY RFC6566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6566.xml">
<!ENTITY I-D.ietf-ccamp-rwa-info SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-rwa-info-14.xml">
<!ENTITY I-D.ietf-ccamp-general-constraint-encode SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-general-constraint-encode-08.xml">
<!ENTITY I-D.martinelli-ccamp-wson-iv-encode SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-martinelli-ccamp-wson-iv-encode-00.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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 -->
<?rfc comments="yes" ?>
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-martinelli-ccamp-wson-iv-info-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 abbrev="WSON Impairments Information Model">
Information Model for Wavelength Switched Optical Networks (WSON) with Optical Impairments Validation.
</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>
<city>Monza</city>
<region></region>
<code>20900</code>
<country>Italy</country>
</postal>
<phone>+39 039 2092044</phone>
<email>giomarti@cisco.com</email>
</address>
</author>
<author fullname="Moustafa Kattan" initials="M.K."
surname="Kattan">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city>DUBAI</city>
<region></region>
<code>500321</code>
<country>UNITED ARAB EMIRATES</country>
</postal>
<phone></phone>
<email>mkattan@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>Monza</city>
<code>20900</code>
<country>Italy</country>
</postal>
<phone>+39 039 2091462</phone>
<email>ggalimbe@cisco.com</email>
</address>
</author>
<author fullname="Andrea Zanardi" initials="A. Z." surname="Zanardi"
role="editor">
<organization>CREATE-NET</organization>
<address>
<postal>
<street>via alla Cascata 56 C, Povo</street>
<code>38100</code>
<city>Trento</city>
<country>Italy</country>
</postal>
<email>andrea.zanardi@create-net.org</email>
</address>
</author>
<date year="2013" />
<!-- 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>CCAMP</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 Optical Impairments</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>
This document defines the Information Model to support Impairment-Aware (IA) Routing an Wavelength
Assignment (RWA) function. This operation might be required in
Wavelength Switched Optical Networks (WSON) that already support RWA and the Information model defined
here goes in addition and it is fully compatible with the already defined information model for WSON.
</t>
<t>
This information model shall support all control plane architectural options defined for WSON with
impairment validation.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
In the context of Wavelength Switched Optical Network (WSON), <xref target="RFC6163"/> defines the
basic framework for a GMPLS control plane. The associated info model
<xref target="I-D.ietf-ccamp-rwa-info"/> defines all parameters
required for the related RWA process. These references are the foundation but they do not consider
the Optical Impairment case.
</t>
<t>
In case of WSON where optical impairments plays a significant role, the framework document
<xref target="RFC6566"/> defines related control plane architectural options for an Impairment Aware
routing and wavelength assignment (IA-RWA). Options include different combinations of Impairment Validation
(IV) and RWA functions through control plane elements and operations (PCE, Routing, Signaling).
</t>
<t>
This document provides the information model
for the impairment aware case to allow the impairment validation function implemented in the
control plane or enabled by control plane available information.
This model goes in addition to <xref target="I-D.ietf-ccamp-rwa-info"/> and
it is independent from any architectural option described by the framework <xref target="RFC6566"/>:
it shall support all of them.
</t>
<t>
Computational Models for the optical impairments are defined by ITU standard body.
The currently available computation models
are reported in <xref target="ITU.G680"/> and only cover only the linear impairment case.
This perfectly fit with
scenario C defined in <xref target="RFC6566"/> section 4.1.1 and is considered in
scope with WSON activity.
The non-linear case is left for further study since currently no
ITU computational models are available for
an accurate optical impairment estimation.
</t>
<t>
The information model defined here provides a generic enough mechanism that could be easily
extended to
additional impairments models.
</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="Properties of an Impairment Information Model">
<t>
An information model may have several attributes or properties that
need to be defined for each optical parameter made available to the
control plane. The properties will help to determine how the control
plane can deal with it depending on architectural options chosen
within the overall impairment framework <xref target="RFC6566"/>. In some case
properties value will help to identify the level of approximation
supported by the IV process.
</t>
<t>
<list style="symbols">
<t>
Time Dependency.<vspace blankLines="0" />
This will identify how the impairment may vary
with time. There could be cases where there is no time dependency,
while in other cases there may be need of impairment re-
evaluation after a certain time. In this category, variations in impairments due to
environmental factors such as those discussed in [G.sup47] are
considered.
In some cases a level of
approximation will consider an impairment that has time dependency
as constant. In this Information Model we do neglect this property.
</t>
<t>
Wavelength Dependency. <vspace blankLines="0" />
This property will identify if an
impairment value can be considered as constant over all the
wavelength spectrum of interest or if it has different values.
Also in this case a detailed impairment evaluation might lead to
consider the exact value while an approximation IV might take a
constant value for all wavelengths.
In this Information Model we consider both case: dependency / not dependency
from a specific wavelengths. This property may appear directly in the
Information model definitions or in the related encoding.
</t>
<t>
Linearity.
<vspace blankLines="0" />
As impairments are representation of physical effects
there are some that have a linear behavior while other are
non-linear. Linear approximation is in scope of scenario C
of <xref target="RFC6566"/>.
During the impairment validation process, this property implies that the optical effect (or quantity)
satisfy the superposition principle, thus a final result can be calculated by the sum of each
component. The linearity implies the
additivity of optical quantities considered during an Impairment Validation process.
<vspace blankLines="0" />
The non-linear effects in general does not satisfy this property. The information model presented in this
document however, easily allow introduction of non-linear optical effects with a linear approximated contribution
to the linear ones.
</t>
<t>
Multi-Channel.<vspace blankLines="0" />
There are cases where a channel's impairments take
different values depending on the aside wavelengths already in
place. In this case a dependency among different LSP is
introduced and is typically a result of linear effects.
This Information Model neglect this effects
on neighbor LSPs.
</t>
</list>
</t>
<t>
The following table summarize the above considerations where in the first column reports
the list of properties to be considered for each optical parameters, while second column
state if this property
is taken into account or not by this Information Model.
</t>
<texttable anchor="table_optical_properties" title="Optical Impairment Properties">
<preamble></preamble>
<ttcol align="center">Property</ttcol>
<ttcol align="center">Info Model Awareness</ttcol>
<!-- First row -->
<c>Time Dependency</c>
<c>no</c>
<!-- Second row -->
<c>Wavelength Dependency</c>
<c>yes</c>
<!-- Third row -->
<c>Linearity</c>
<c>yes</c>
<!-- Forth row -->
<c>Multi-channel</c>
<c>no</c>
<postamble></postamble>
</texttable>
</section> <!-- END OF "properties of an impairment information model -->
<section title="Background from WSON Information Model">
<t>
In this section we report terms already defined for the WSON-RWA (not impairment aware)
as in <xref target="I-D.ietf-ccamp-rwa-info"/> and <xref target="I-D.ietf-ccamp-general-constraint-encode"/>.
The purpose is to provide essential information
that will be reused or extended for the impairment case.
</t>
<t>
In particular <xref target="I-D.ietf-ccamp-rwa-info"/> defines the connectivity matrix as the follow:
</t>
<figure align='left'>
<artwork align="left">
<![CDATA[
ConnectivityMatrix ::= <MatrixID> <ConnType> <Matrix>
]]>
</artwork>
</figure>
<t>
However according to <xref target="I-D.ietf-ccamp-general-constraint-encode"/> this definitions is further detailed
as:
</t>
<figure align='left'>
<artwork align="left">
<![CDATA[
ConnectivityMatrix ::=
<MatrixID> <ConnType> ((<LinkSet> <LinkSet>) ...)
]]>
</artwork>
</figure>
<t>
This second formula highlights how the connectivity matrix is built by pairs of LinkSet
objects identifying the
internal node connectivity capability due to internal optical node constrain.
It's essentially a binary information
and tell us if a wavelengths or a set of wavelengths can go from an input port
to an output port.
</t>
<t>
As a additional note, Connectivity Matrix belong to Node Information and is purely static.
Dynamic information related
to the actual usage of the connections are available through specific extension to link
information.
</t>
</section> <!-- END OF "Background from WSON Information Model" -->
<section title="Optical Impairment Information Model">
<t>
The idea behind this Information Model is to reuse the concept of the Connectivity Matrix and defines an
Impairment Matrix that summarize optical impairments provided by the Node and Links (i.e. fibers).
</t>
<t>
The goal of this document is not to rephrase content from <xref target="ITU.G680"/> but only
provide necessary building blocks that allow the IW-RWA process to apply the computational model
defined by such recommendation. <xref target="ITU.G680"/> computational models defined in section 9
provide information
to calculate the following optical parameters:
<list style="symbols">
<t>OSNR. Section 9.1</t>
<t>Chromatic Dispersion (CD). Section 9.2</t>
<t>Polarization Mode Dispersion (PMD). Section 9.3</t>
<t>Polarization Dependent Loss (PDL). Section 9.3 </t>
</list>
The recommendation <xref target="ITU.G680"/> call its computational model "transfer function" and details
formulas for a set of different optical equipments. For the purpose of this information model, only the set of
parameter is important.
</t>
<!--
<t>
Another recomandation useful to for this Information model is the <xref target="ITU.G697"/> defines
an encoding for all above parameters. and in
<xref target="encoding_considerations"/> we report some encoding consideration. The <xref target="ITU.G697"/> is
mainly oriented for monitoring so the purpose is only reuse parameter definitions for those parameters required
by Impairment Validation process.
</t>
-->
<t>
This Information Model makes the assumption that the each Optical Node in the network is able to provide it's
own contribution to above parameters.
To this extent the Information Model intentionally ignore all internal detailed parameters
that are used to by the formulas (i.e. "transfer function") but simply provide the object to carry results of
the formulas. However no assumption is made on how the Optical node get the result of
parameter contribution (e.g. computed, provisioned, known by design, etc.).
</t>
<t>
As an additional note, as reported in in <xref target="ITU.G680"/> Section 10,
each parameter can be reported as an OSNR contribution, in such way the Optical Node not necessarily embed
optical computational capability but can provide an approximated contribution to optical impairments.
</t>
<t>
With the above considerations this Information Model provides an abstract view for an optical node and link
to enable WSON protocol extension with optical impairments validation.
</t>
<section title="Node Information">
<t>
This model defines the Impairment Matrix as the following:
</t>
<figure align='left'>
<artwork align="left">
<![CDATA[
ImpairmentMatrix ::= <MatrixID> <ConnType>
((<LinkSet> <LinkSet> <ImpairmemtVector>) ...)
]]>
</artwork>
</figure>
<t>
Where:
<list style="empty">
<t>
MatrixID. Is a unique identifier for the Matrix. This ID shall be unique in scope
among connectivity matrices defined in <xref target="I-D.ietf-ccamp-rwa-info"/>
and impairment matrices defined here.
</t>
<t>
ConnType. This number identifies the type of matrix and it shall be unique in scope with
other values defined by WSON documents.
</t>
<t>
LinkSet. Same object definition and usage as <xref target="I-D.ietf-ccamp-general-constraint-encode"/>.
</t>
</list>
</t>
<t>
ImpairmentVector is defined as list of optical parameters associated to
the internal node connection.
</t>
<figure align='left'>
<artwork align="left">
<![CDATA[
<ImpairmentVector> ::= [<LinkSet>] <OPTICAL_PARAM> ...
]]>
</artwork>
</figure>
<t>
The optional LinkSet object enable wavelength dependency property as per
<xref target="table_optical_properties"/>.
</t>
<t>
OPTICAL_PARAM is an object representing an optical parameter. The Impairment
vector contain a set of parameters as identified by <xref target="ITU.G697"/>
since those parameters match the terms of the linear impairments
computational models provided by <xref target="ITU.G680"/>.
This information model does not speculate about set of parameters
(since defined elsewhere, e.g. ITU-T),
however it does not preclude
extentions by adding new parameters.
</t>
<t>
The model can be represented as the multidimensional matrix shown in the following picture
</t>
<figure align="left">
<artwork align="left"><![CDATA[
_________________________________________
/ / / / / /|
/ / / / / / |
/________/_______/_______/_______/_______/ |
/ / / / / /| /|
/ / / / / / | |
/________/_______/_______/_______/_______/ | /|
/ / / / / /| /| |
/ / / / / / | | /|
/________/_______/_______/_______/_______/ | /| |
/ / / / / /| /| | /|
/ / / / / / | | /| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| | / PDL
<LinkSet#1> | - | | | | | /| | /|/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| /
<linkSet#2> | | - | | | | /| | / PND
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /|/
<linkSet#3> | | | - | | | /| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / Chr.Disp.
<linkSet#4> | | | | - | | /|/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
<linkSet#5> | | | | | - | / OSNR
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<LS#1> <LS#2> <LS#3> <LS#4> <LS#5>
]]></artwork>
</figure>
<t>
The Connectivity Matrix from <xref target="I-D.ietf-ccamp-general-constraint-encode"/>
only defines the two dimensional matrix, containining only binary information,
through the LinkSet pairsa binary information.
In this model a third dimension is added by generalizing the bnary information through
the ImpairmentVector
associated with each LinkSet pair.
Optical parameter names in the picture are reported just
as an example while detailed definitions will go into specific
encoding drafts <xref target="I-D.martinelli-ccamp-wson-iv-encode"/>.
</t>
<t>
This representation shows the most general case however,
the total amount of information transported by control plane
protocols can be greatly
reduced by proper encoding when same set of values apply to all LinkSet pairs.
</t>
</section> <!-- "Node Information" -->
<section title="Link Information">
<t>
The same approach used for the Node information can be used at Link Level.
The Link information for WSON is extended in <xref target="I-D.ietf-ccamp-rwa-info"/>. This information model
provide the following additional extension:
</t>
<figure align='left'>
<artwork align="left">
<![CDATA[
<DynamicLinkInfo> ::= <LinkID> <AvailableLabels>
[<SharedBackupLabels>] [<ImpairmentVector>]
]]>
</artwork>
</figure>
<t>
DynamicLinkInfo is exactly the only already defined in <xref target="I-D.ietf-ccamp-rwa-info"/> while
ImpairmentVector is defined in the previous section. Is considered as optional since apply as an extention
to existing Link information.
</t>
<t>
In this case the list of contained optical parameters are associated to the link.
</t>
</section> <!-- "Link Information" -->
<section title="Path Information">
<t>
In case of a control plane with impairment validation awareness there's might be cases
where informations apply to
the whole path and cannot be composed by individual contributions of links and nodes.
The cases where this kind of information might be required are reported within
<xref target="RFC6566"/> (Section 4.2.2 IV-Canditates or Sharing Constraints).
</t>
<figure align='left'>
<artwork align="left">
<![CDATA[
<PathInfo> ::= <ImpairmentVector>
]]>
</artwork>
</figure>
<t>
[EDITOR NOTE: section to be completed].
</t>
</section> <!-- "Path Information" -->
</section> <!-- END OF "Optical Impairment Information Model" -->
<section anchor="encoding_considerations" title="Encoding Considerations">
<t>
Details about encoding will be defined in a separate document
<xref target="I-D.martinelli-ccamp-wson-iv-encode"/> however worth remembering that,
within <xref target="ITU.G697"/> Appending V,
ITU already provides a guideline for encoding some optical parameters.
</t>
<t>
In particular <xref target="ITU.G697"/> indicates that each parameters shall be represented by
a 32 bit floating point number.
</t>
<t>
As an additional consideration, actual values for parameters defined in the information models
are provided by the Optical Node and it could provide by direct measurement or from some
internal computation starting from indirect measurement. In any case the encoding
shall provide an the possibility to associate a variance with the parameter.
This information will enable the function implementing IV-RWA process to make some
additional considerations on wavelength feasibility. <xref target="RFC6566"/>
Section 4.1.3 reports
some considerations regarding this degree of confidence during the impairment validation
process.
</t>
</section> <!-- END OF "Encoding Considerations" -->
<section title="Information model versus Control Plane Architectures">
<t>
This section will briefly describe how the wholes set of informations defined by this
info model will match the architectural options
defined in <xref target="RFC6566"/>
</t>
<t>
The first assumption is that the RWA-WSON extentions are available and operationals.
To such extent, the RWA-WSON will provide the following information through it's
path computation (and RWA process):
<list style="symbols">
<t> The wavelenght connectivity (considering also the connectivity constrains
by limited reconfigurable optics).
</t>
<t>
The interface compatibility at the physical level.
</t>
<t>
The Optical-Elettro-Optical (OEO) availability within the network (and releater
physical interface compatibility as here above).
</t>
</list>
</t>
<t>
[EDITOR NOTE: to be completed]
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="Contributors" title="Contributors">
<figure align='left'>
<artwork align="left">
<![CDATA[
Tim Gibbon
Department of Physics
Nelson Mandela Metropolitan University
SOUTH AFRICA
Email: Tim.Gibbon@nmmu.ac.za
]]>
</artwork>
</figure>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not contain any IANA requirement</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;
<reference anchor="ITU.G680">
<front>
<title>
Physical transfer functions of optical network
elements
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="July" year="2007"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.680"/>
</reference>
<reference anchor="ITU.G697">
<front>
<title>
Optical monitoring for dense wavelength division multiplexing systems
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="February" year="2012"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.697"/>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2629;
&RFC3552;
&I-D.narten-iana-considerations-rfc2434bis;
<!-- A reference written by by an organization not a person. -->
&RFC6163;
&RFC6566;
&I-D.ietf-ccamp-rwa-info;
&I-D.ietf-ccamp-general-constraint-encode;
&I-D.martinelli-ccamp-wson-iv-encode;
</references>
<section anchor="app-additional" title="G.680 Essential information">
<t>TBD if we need some info instead of reading <xref target="ITU.G680"/> </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:14:31 |