The MPLS WG Archive

[Heiles Juergen <Juergen.Heiles@icn.siemens.de>]

The ITU has defined in G.692 "Optical Interfaces for Multichannel systems with Optical Amplifiers" wavelengths for the Optical Supervisory Channel OSC.
The defined wavelength is 1510 nm and 1480, 1310 nm as alternatives. These are all outside of todays EDFA bands.
G.692 is specific for SDH WDM systems. ITU iscurrently working on G.959.1 which will define the Optical interfaces for the Optical Transport Network OTN. The OSC normally runs between line amplifiers as the amplifiers require access to the OSC for management and control purposes. The OSC has therefore only to cross a span between line amplifiers. This can be achieved without amplification as the OSC bit rate is lower as the payload bit rate. Network operators don't won't to spent an in-band channel or the OSC as it can be used for revenue bearing traffic.
Note that it will get more and more difficult to standardize out-of-band OSC wavelengths as the bands used for payload channels will be extended more and more. Today we use the C and L band and a new S band below the C band is proposed. In addition Raman amplification will conflict with for example 1510 and 1480 nm OSCs. The ITU is currently discussing the need for a dedicaded OSC for the inter-domain interface. For the intra-domain, specially for long haul applications the interfaces will be vendor specific in any case as every vendor will optimize its system for maximum distance or maximum capacity. I don't think that we can achieve interworking for these interfaces.

Juergen

> -----Urspr> üngliche Nachricht-----
> Von:	Spencer.Giacalone@predictive.com [SMTP:Spencer.Giacalone@predictive.com]
> Gesendet am:	Dienstag, 5. September 2000 16:19
> An:	James V. Luciani
> Cc:	Spencer.Giacalone@predictive.com; mpls@UU.NET; Joseph.Abban@predictive.com
> Betreff:	Re: control channel lambdas
> 
> So is the specification of control lambdas an ITU area of work? Is there any agreement at this time on a wavelength, or just proposals? You say to "just pick one on the grid", but won't that effect interoperability?  What about determining/finding/checking/allocating redundant/diverse control channel Lambdas? Isn't it, err, important to insure that our control channels -are- in the range of EDFAs? I mean, might not there be a time when the control channel between 2 nodes is at maximum distance?
> 
> Okay, enough questions out of me...
> 
>  
> 
> Thanks, 
> 
>  
> 
> Spence
> 
>  
> 
> 
> 
> "James V. Luciani" <jluciani@tollbridgetech.com>
> 09/04/2000 04:05 PM AST
> Please respond to "James V. Luciani"
> 
> To: <Spencer.Giacalone@predictive.com>, <mpls@UU.NET>
> cc: <Joseph.Abban@predictive.com>
> bcc: 
> Subject: Re: control channel lambdas
> 
> 
> 
> 
> I have seen 3 general choices in literature:
> If the control channels are strictly hop by hop and you are running a short
> distance (i.e., no amplification needed for control channel) then there have
> been proposals to use 1310 or something at the end of the C band (e.g.,
> something on the ITU grid around 1510). The amplification and hop by hop
> restrictions are there because usually EDFAs do not usually amplify in these
> wavelengths (although I guess some do now).  Those wavelengths thus do not
> steal from the set of useful data carrying wavelengths which would be in the
> range of EDFAs.  BTW, many receivers are broad enough to receive 1310 even
> if built for C band (this is a bane as well as a boon); this was not the
> case for the tunable lasers for a while although I would not be surprised if
> you can find them now.
> If the restrictions on distance and amplication are not acceptable, then
> just pick one on the grid which your EDFAs cover.
> 
> --Jim
> 
> ---- Original Message -----
> From: <Spencer.Giacalone@predictive.com>
> To: <mpls@UU.NET>
> Cc: <Joseph.Abban@predictive.com>
> Sent: Wednesday, August 30, 2000 10:59 PM
> Subject: control channel lambdas
> 
> 
> > Can anyone point me in the direction of work that has been done to specify
> > what lambdas controls channels should use?
> >
> > Thanks,
> >
> > Spence
> 
>