Re: OLI requirements

[Maarten Vissers <mvissers@lucent.com>]

The OLI work is in parallel to the work in ITU-T SG15 on OTM-LF
(Line-fabric) interface.

This OTM-LF interface is essentially a "virtual backplane" interface,
and has to support the applications that are typically supported on a
backplane in e.g. a SDH/SONET cross connect system, plus the specific
OTN applications (for the moment transport of OCh Overhead).

	"[from WD43, Q.14/15 meeting June 2001] The OTM-LF interface is a
multi-fiber parallel interface; it includes all fibers between OLS and
OXC used for traffic transport and the additional "funiculus" (umbilical
cord) or "Optical Supervisory Interface (OSI)"  interface (either on
fiber or copper). This funiculus/OSI carries all necessary information
as required by the applications between OLS and OXC; e.g. OAM, status
information and comms channels. It is a kind of supervisory channel, but
now between the trib interface side of the OLS and the OXC (instead of
between the line interface side of an OLS and the next OLS); see Figure
3."

Note - "OSI"/"funiculus" are alternative names for "OLI".

The OSI/funiculus has to interconnect one or more optical line systems
with one or more optical fabrics and/or with one or more client
equipment. I.e. a multi-point to multi-point configuration.




Up to so far, 10 applications are identified that may have to be
supported by a OTM-LF interface (text copied from WD43, Q.14/15 meeting
June 2001 http://ties.itu.int/u/tsg15/sg15/wp3/q14/0106/wd43-otmlf02.doc
):

4.1 Application 1: Connection Status

For the case OLS equipment contains ports with monitoring capabilities
(i.e. 3R points/transponders) it can detect the status of the individual
link connections while service is provided by the link connections. The
status of a link connection can be expressed by means of the signal fail
and signal degrade (SF, SD) condition determined by the appropriate
atomic function monitoring the link connection. The use of port models
based on ITU-T G.806, G.705, G.783 and draft G.798 most likely allows
re-using existing specifications. See section 11.

For the case of (link) connections not yet carrying service, the status
can be determined also using a scanner in optical fabrics which connects
cyclically a test generator and test monitor device/circuit to these
(link) connections. Coordination is of course required between the
optical fabric with the test generator and the one with the test
monitor.

4.2 Application 2: Port Management

Ports in an OLS may need to be managed as part of the connection
creation, release and modification actions (valid for both permanent
connections (setup by management plane) and for switched connections
(setup by control plane).

Port management is required for he case the port includes: 

- a monitoring or termination function (e.g. section termination, tandem
connection termination, path termination or non-intrusive monitor);
tandem connection monitor function may need to be activated/de-activated
and one or more MI_XXX (refer to G.806, G.705, G.783, G.798) signals of
termination and monitor functions may need a value to be assigned.

- a protection switch function; values may need to be assigned to
protection switching specific MI_XXX signals like bridge type
(broadcast/selective/permanent), protection architecture type (1+1, 1:1,
1:n, m:n, (1:1)n, with/without extra traffic), protection switching type
(uni-directional, bi-directional), protection operation type (revertive,
non-revertive), WTR timer, HO timer, SF and SD priority. [Note - this
functionality is most likely not part of initial OLS equipment.]

Although the equipment recommendations (ITU-T G.806, G.705, G.783, draft
G.798, ETSI EN 300 417-x-1 x=1..6) list all MI_XXX signals and the
equipment management function recommendations (ITU-T G.784, ETSI EN 300
417-7-1, ITU-T draft G.cemr, draft G.874) list the associated
pre-/post-processing for those MI_XXX signals, there is a need to tie
those signals to their applications and identify the subset of
applications that are to be controlled via the funiculus/OSI.

In addition, ports on the OLS needs management to suppress tributary
signal LOS alarms caused by an open matrix connection in the optical
fabric (and no light is output).

4.3 Application 3: OLS Discovery

The OLS equipment port (and its associated tributary slot (i.e.
wavelength) in the WDM line signal), which is physically adjacent to a
port on the optical fabric equipment should be automatically discovered
by the optical fabric equipment. As multiple OLS equipment will be
surrounding the optical fabric equipment, the discovery is about
relating the port X on the fabric to line port (i.e. OLS) Y and
tributary slot Z (Port X ó LinePort Y/TribSlot Z).

Note - not part of this application is the discovery of the adjacent
switch (optical fabric equipment) and link in between this switch and
the adjacent switch. This is part of the general control plane
functionality and addressed in that activity (ITU-T G.ason, G.disc).

4.4 Application 4: Status monitoring of funiculus/OSI interface and of
communications over it

The status of the funiculus/OSI interface and the communications over it
should be monitored. As this has similarities with EMS-NE communications
in management plane, most likely we can re-use existing requirements and
specifications from e.g. SDH/SONET networks. Q.14/15 experts may provide
further input here.

4.5 Application 5: Control Plane Communication

This application encompasses multiple control plane applications. Of
particular interest here are those applications which have their
application endpoints in the optical fabric equipment and the physically
adjacent OLSs.

Note - other control plane applications with application endpoints in
this and the next optical fabric equipment will be listed
(non-exhaustive) only, and will not be subject of this work item. It is
already part of control plane specifications (G.ason, G.dcm, G.disc, …).

The optical fabric equipment <=> physical adjacent OLS equipment control
plane applications are:
- to be added…

4.6 Application 6: Management Plane Communication

The Management Plane is supported by a Data Communication Network (DCN).
This DCN may use in-band Data Communication Channels (DCC) to
interconnect network elements at the management level without the need
for external communication means. The funiculus/OSI should support such
DCC, to be able continue this DCN in-band from OTM-n.m OSC via OLS via
optical fabric equipment via OLS to OTM-n.m OSC.

4.7 Application 7: OCh Overhead

In an all optical OTN network application (i.e. for case of an OLS trib
port without 3R point (transponder)), non-associated OCh overhead
(currently: OCh-FDI, OCh-OCI) must be transported between OLS and
optical fabric equipment. The funiculus/OSI should support the transport
of these OCh non-associated overhead signals.

4.8 Application 8: Protection Switch Endpoint Coordination

For the case the optical fabric equipment includes protection switch
functions supporting bi-directional switching, the optical fabric
equipment with the bridge and with the selector functions must
coordinate their protection switching actions via the Automatic
Protection Switch (APS) co-ordination communication channel. The
funiculus/OSI should support the transport of these APS signals.

4.9 Application 9: Protection Switch Functional Model Emulation

For the case an OMS, OCh or ODUk protection implementation does not
comply with its protection switch functional model (see annex B, which
is copied from
http://ties.itu.int/u/tsg15/sg15/wp3/q9/0106/cd/gen-lin-prot-v07.doc ),
BDI and BEI information should be communicated to and from the optical
fabric equipment via the funiculus/OSI. The optical fabric equipment
will select the BDI/BEI information from the "active" interface port and
forward this to both upstream "working" and "protection" interface
ports. This implements BDI/BEI equivalent to the "RDI/REI X-coupling"
indicated in figures B-3 and B-4.

4.10 Application 10: Auxiliary Communication

Depending on the specific requirements for OrderWire (OW) and Operator
Specific (OpSp) signals, there may be a need to continue those signals
beyond a single line system (OLS - OLS). In such case, the OW and/or
OpSp information should be transported via the funiculus/OSI.





Q.12/15 indicated that the work on this OTM-LF interface requires
detailed models of the interface ports at each end of the interface to
be available. Without such models, it will not be possible to complete
the specification; applications will most likely be overlooked and/or
only partly supported otherwise.

This equally applies to the OLI work; without accurate descriptions of
the transport functionality at each end of the interface supported by
the OLI, an incomplete specification will be the result.



Up to so far...

Regards,

Maarten
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard