[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: STM-M out of STM-N (M<N)
Manoj,
furthermore when you use semi-transparent transport of a STM-64 in a STM-256 it is not possible to transport all the SOH of the STM-64 via the STM-256 as the STM-256 uses SOH for its own purpose. You can only tunnel some of the STM-64 SOH by transporting them in unused SOH of the STM-256.
Juergen
> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: Wednesday, November 14, 2001 9:57 AM
> To: manoj juneja
> Cc: ccamp@ops.ietf.org
> Subject: Re: STM-M out of STM-N (M<N)
>
>
> Manoj,
>
> I do not know what a STM-64c is. Such signal name is not
> defined in SDH.
> Sometimes people use this to indice a (physical) STM-64
> signal with a VC-4-64c
> inside. There is no naming yet around that I am aware of to indicate
> semi-transparent STM-N signal transport; for this email let
> me refer to it as
> STM-64st.
>
> When you need to transport a STM-64 signal in a
> semi-transparent manner via a
> STM-256, the content of the STM-64st is not-relevant; i.e.
> the user may change
> this content as (s)he likes. That's why the request is for a STM-64st
> connection.
>
> Note that this semi-transparent STM-N transport is a
> work around in
> the absence of full transparency that is offered by WDM and OTN
> networks. SDH equipment that is capable to support this must
> configure its AU pointer processors into adaptive mode;
> i.e. these
> AU PPs must follow the incoming AU structure. In terms
> of GMPLS, the
> STM-Nst contains a AUG-N signal.
>
> If I assume maximum transparency to be requested, the
> following overhead needs
> to be passed through: J0, RS DCC, MS DCC, K1/K2, E1, F1, E2,
> B1, B2, M0, M1.
>
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | ST=11 | RCC=0 | NCC=0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | NVC=0 | Multiplier (MT)=1 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Transparency (T)= 1 1 1 1 1 1 1 1 0 1 1 1 0 0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Concerning the label, there is essentially no definition of
> this in GMPLS
> SDH/SONET documents. We transport a STM-64st signal, not HOVC
> or LOVC signals
> for which the SUKLM label is specified. Nevertheless, I
> assume for this moment
> that the intention was to reuse the SUKLM label also here
> (Eric can we add this
> explicitly to
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt?). So for the
> case the AUG-64 within the STM-64st is transported in
> timeslot EDCBA=20000 in
> STM-256, this then results in S=65 and UKLM=0000:
>
> 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=65 | U=0 | K=0 | L=0 | M=0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Regards,
>
> Maarten
>
>
> manoj juneja wrote:
> >
> > Hi Marteen,
> > Thank You for u prompt response. I have
> another doubt relate
> > to this one. If I want to allocate STM64c within STM-256,
> then what will be
> > the difference between the label value if I allocate VC-4-64c within
> > STM-256. As per my understanding, the transparency should
> also be included
> > in STM64c request (generalized label request object) and
> label will be same.
> >
> > Please comment.
> >
> > Regards,
> > manoj.
> >
> > >From: Maarten Vissers <mvissers@lucent.com>
> > >To: manoj juneja <manojkumarjuneja@hotmail.com>
> > >CC: ccamp@ops.ietf.org
> > >Subject: Re: STM-M out of STM-N (M<N)
> > >Date: Tue, 13 Nov 2001 09:55:03 +0100
> > >
> > >Manoj,
> > >
> > >In pure SDH, you can not allocate STM-64 within STM-256.
> You can allocate
> > >VC-4-64c link connection within a HOVC link. The
> associated timeslot is an
> > >AU-4-64c, which is identified in EDCBA terminology with
> 10000, 20000,
> > >30000, or
> > >40000. If you look in my g707-gmpls-label-conversion
> document, you see that
> > >
> > >10000 maps on S U = 1 0
> > >20000 maps on S U = 65 0
> > >30000 maps on S U = 129 0
> > >40000 maps on S U = 193 0
> > >
> > >KLM in all cases is 000 (i.e. non relevant).
> > >
> > >As it is a contiguous concatenated signal, there is just 1 label,
> > >identifying
> > >the first timeslot. Assume you want to pass the VC-4-64c
> via AU-4-64c
> > >20000,
> > >then the label looks like:
> > >
> > > 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
> > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > | ST=6 | RCC=1 | NCC=64
> |
> > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > | NVC=0 | Multiplier
> (MT)=1 |
> > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > | Transparency (T)=0
> |
> > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >
> > > 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=65 | U=0 | K=0 |
> L=0 | M=0 |
> > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >
> > >Regards,
> > >
> > >Maarten
> > >
> > >manoj juneja wrote:
> > > >
> > > > Hi All,
> > > > If I want to allocate STM-M from STM-N (M < N)
> then what will be
> > >the
> > > > label value in GMPLS ? I mean to say if I get a request
> to allocate
> > >STM-64
> > > > from STM-256 link then what will be the label value
> (SUKLM) and how many
> > > > labels will be sent back in RESV message ?
> > > >
> > > > Please comment.
> > > >
> > > > Regards,
> > > > manoj
> > > >
> > > >
> _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> > >http://explorer.msn.com/intl.asp
> > ><< mvissers.vcf >>
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp