[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: STM-M out of STM-N (M<N)
Soumen,
"Karmakar, Soumen" wrote:
>
> Does this mean that the STM64 signal type (as requested in sonet/sdh tSpec)
> can be carried in the STM256 link type ?
No; an STM-64 can NOT be carried in a STM-256.
> However this is possible by carrying the VC-4-64c with transport overhead
> only , even though the user specifies just STM64 signal type ?
A VC-4-64c + TOH [in SDH terms SOH] is the complete STM-64. A STM-64 can not be
carried by a STM-256. A user should thus not request this from the SDH/SONET
network, as its request will be rejected.
As a workaround for more transparency for the short term, a number of vendors
are adding the ability to transport a SUBSET of the user's STM-N SOH/OC-N TOH
bytes via the STM-M/OC-M (line) interfaces. I am referring to that as
semi-transparent STM-N (STM-Nst) transport. Some dedicated subnetworks will be
supporting this workaround, but do not consider this as a general available
feature in the network.
The mainstream SDH/SONET networks support LOVC/VT and HOVC/STS signal transport.
And via these two also PDH signal (DS1, E1, E3, DS3, E4) transport, and more
recently also Ethernet transport.
STM-N/OC-N transport is supported via pre-OTN/WDM line systems and photonic
cross connects as "STM-N/OC-N signal" transport. Switching is just fine in this
case, but monitoring the quality of service for performance and fault management
is very limited in this case. For the case of pre-OTN/WDM networks with a
control plane on top, some of these limitations can be removed by adding LMP.
The more general resolution (switched and non-switched networks) for this
monitoring issue is the addition of OTN. With the introduction of OTN, monitored
STM-N/OC-N signal transport will be supported via the ODUk signals (i.e. similar
to PDH over SDH/SONET).
> And the list of valid labels in this case should be
> S = 1,65, 129, 193 and UKLM = 0,0,0 ?
For the case of STM-64st connection setup these are the valid labels.
Note - STM-64st is essentially an AUG-64 with some of the
SOH/TOH as specified in the Transparency field.
For case of a VC-4-64c connection setup, these are also the valid labels.
> Furthermore in the example that you showed below with the following fields
> as :
> ST = 6 (VC4) , RCC =1, NCC =64, NVC =0, MT =1, T =0.
This is a request for a VC-4-64c connection.
> and why not
> ST = 11 (STM64) , RCC=0, NCC=0, NVC=0, MT= 1, T = 6 or 7 (110 or 111) ?
T_flag_1: RS layer transparency; i.e. RSOH transparency
T_flag_2: MS layer transparency; i.e. MSOH transparency
T_flag_3: RSOH J0 transparency
T = T_flag_msb ... T_flag_lsb = T_flag_3, T_flag_2, T_flag_1
T = 110 implies MSOH + RSOH-J0 transparency
T = 111 implies RSOH + MSOH transparency ==> i.e. T_flag_3 is redundant
T = 110 is a request for a STM-64 Multiplex Section connection which is also
transparent for RSOH-J0. This is not the same as a fully transparent STM-64
connection. I can not be supported by an SDH/sONET network as Juergen described;
it may be possible to support this signal over a series of SDH/SONET repeaters
(if these can pass through J0).
T = 111 (or better T = 11) is a request for a STM-64 connection (fully
transparent) and can only be supported by pre-OTN/WDM or OTN networks.
Regards,
Maarten
> assuming full transparency support.
>
> Thanks,
> Soumen
>
> > -----Original Message-----
> > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > Sent: Wednesday, November 14, 2001 12: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
> >
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