RE: Lambda LSP establishment

[John Drake <jdrake@calient.net>]

fortunately, this is just your opinion

-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Tuesday, December 11, 2001 9:31 PM
To: manoj juneja
Cc: ccamp@ops.ietf.org
Subject: Re: Lambda LSP establishment


Manoj,

Forget the FA stuff, it is not appropriate in circuit networks. It only
applies
to MPLS. We should remove it when it is used in relation with PDH,
SDH/SONET,
OTN and pre-OTN. The text in sdh-sonet draft should state that if there is a
LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label with
"00KLM".

Regards,

Maarten

manoj juneja wrote:
> 
> Hi Marteen,
>             The concept of FA is mentioned for SDH/SONET in gmpls-sdh
> -sonet draft. It says that if u have a HOVC trail as a FA (advertized
> as a link) then u can allocate the lower level signals in it by making
> the higher bits of label as 0s (i.e. S and U}. This is fine for the same
> technology. What about the case where the TDM LSP has to be tunneled
through
> the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda
> etc.) ?
> 
> Regards,
> manoj.
> 
> >From: Maarten Vissers <mvissers@lucent.com>
> >To: manoj juneja <manojkumarjuneja@hotmail.com>
> >CC: ccamp@ops.ietf.org
> >Subject: Re: Lambda LSP establishment
> >Date: Tue, 11 Dec 2001 15:56:41 +0100
> >
> >Manoj,
> >
> >You refer to one wavelength to be available between A-E without
wavelength
> >conversion capability. This suggests that you operate at the OCh layer
> >network.
> >Then you specify the capacity of the 4 OCh link connections (A-B, B-C,
C-D,
> >D-E)
> >to be "C". Say that C is about 10 Gbit/s. You then assume that there is a
> >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C
and
> >E.
> >The result is that the OCh link connections C-D and D-E are transporting
> >the OCh
> >signal (of e.g. 2.5G). These OCh link connections are now in service and
> >not
> >longer available to an other OCh connection request. I.e. a request for
an
> >OCh
> >connection between A and E will be rejected.
> >
> >FAs are not applicable in the circuit layers. IF there is a trail in
server
> >layer X, then there is a link in its client layer Y. X and Y are thus
> >different
> >layer networks and signals.
> >
> >If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail
> >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
connection.
> >
> >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is
not
> >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> >
> >Regards,
> >
> >Maarten
> >
> >OCh link connections
> >
> >manoj juneja wrote:
> > >
> > > Hi All,
> > >         If I have 5 nodes A, B, C, D and E connected as shown. Assume
> > > that only one wavelength is available on the path A to E (no
wavelength
> > > conversion capability is there on the complete path). Let the capacity
> > > of the wavelength be C. Further assume a request arrives for
connection
> > > from node C to E for a line capacity of C/4. This request will be
> > > successful as we have available wavelength. Now If another request
> > > comes at node A to establish another connection from node A to node E
> > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request
> > > be successful as we have already allocated the wavelength ?
> > >
> > > If the previous connection from C to E of capacity C/4 had been
> > > advertised as a FA, in that case will the IInd request succeed ?
> > >
> > > If the previous connection from C to E of capacity C/4 had not been
> > > advertised as FA then what will be the fate of IInd connection ?
> > >
> > >        A <--> B <---> C <----> D <---> <----> E
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> ><< mvissers.vcf >>
> 
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com