[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
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