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

Re: STM-M out of STM-N (M<N)

To: Heiles Juergen <Juergen.Heiles@icn.siemens.de>
Subject: Re: STM-M out of STM-N (M<N)
From: Maarten Vissers <mvissers@lucent.com>
Date: Mon, 19 Nov 2001 12:40:08 +0100
Cc: "Karmakar, Soumen" <soumen@trillium.com>, ccamp@ops.ietf.org
Organization: Lucent Technologies
Original-CC: "Karmakar, Soumen" <soumen@trillium.com>, ccamp@ops.ietf.org
References: <AFC76835727DD211A7C20008C71EAF1E02291A41@MCHH230E>

Juergen,

Thanks... indeed my mistake. T=111 should be T=1, and T_flag_1 indicates
RSOH+MSOH transparency.

Regards,

Maarten

Heiles Juergen wrote:
> 
> Maarten,
> 
> one comment. My interpretation of the transparency flags is as follows:
> RS layer transparency means that also all higher layers are transparently transported (e.g. MS, AU). So the whole SOH should be transparently transported and it is not necessary to set the MS layer transparency flag in addition.
> 
> Juergen
> 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > Sent: Monday, November 19, 2001 11:04 AM
> > To: Karmakar, Soumen
> > Cc: ccamp@ops.ietf.org
> > Subject: 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

References:
- RE: STM-M out of STM-N (M<N)
  - From: Heiles Juergen <Juergen.Heiles@icn.siemens.de>

Prev by Date: relationship between adjacency and link
Next by Date: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Prev by thread: RE: STM-M out of STM-N (M<N)
Next by thread: SDH/SONET in GMPLS
Index(es):
- Date
- Thread