The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Apr> msg00130



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Transparency flags for SONET/SDH

  • From: Dimitri.Papadimitriou@alcatel.be
  • Date: Thu, 17 Apr 2003 12:17:56 +0200
  • CC: mpls@UU.NET
  • User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
  • X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at04/17/2003 12:19:37,Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at04/17/2003 12:19:39,Serialize complete at 04/17/2003 12:19:39

hi, see in-line

bhuvan laddha wrote:
> Hi,
> Thanks for the your valuable information ...
> 
> Please correct me for the following points :
> 
> 1.a.Are the following labels valid for GMPLS LSP of
> STS1 LINE SECTION TRANSPARENCY flag ?

see the paragraph just before section 4.
"Note: when a Section/RS or Line/MS transparent STS-1/STM-0/STS-
    3*N/STM-N (N=1, 4, 16, 64, 256) signal is requested, the SUKLM
    label format and encoding is not applicable and the label encoding
    MUST follow the rules defined in [RFC3471] Section 3.2."

in brief the rule is:
- fully transparent signal request -> G_LABEL_REQUEST and G_LABEL
   of rfc3471
- (non-fully) transparent signal request -> G_LABEL_REQUEST of sonet-sdh
   and G_LABEL of rfc3471
- sonet/sdh signal request -> sonet-sdh for both the G_LABEL_REQUEST
   and the G_LABEL


> Labels : S > 0  U > 0 K = 0 L = 0 M = 0 
> It means , the whole time slot ( label range ) from   
> ( s > 0 U > 0 K = 0 L = 0 M = 0 ) to 
> ( s > 0 U > 0 k = 0 L = 7 M = 9 ) get allocated .
> 
> 1.b.Now Can I use the next GMPLS LSP with the fully
> transparency STS1 signals for the same SONET Network
> Element [NE] ?
> ( pl. tell me whether we can have fully transparent as
> well as any transparency LSP on the same NE ... )

that's a data plane capability and by same NE what
do you mean interface/shelf/node (?)

> 1.c.If yes,the G_LABEL will get used for fully
> transparent LSP.
> Then same label value can get used for G_LABEL and
> SUKLM Label .
> So Is their any intelligence in hardware of Network
> Element [NE] to identify this?

the "labels" that we speak about here are processed
at the *control plane* level (internal or local mapping
rules are outside of the scope - see also rfc3471)

> 2. If I required the contiguous Label ( time-slot )
> for the SONET STS_3_SPE for NCC = 12 
> ( RCC flag Standard Contiguous Concatenation is set )
> ;
> Then time slot will be between 
>  S = i and  S = i + 12 ( i > 0 ) whereas others fields
> are from 0 to max values .
> label will be( S > 0 U = 0 K = 0 L = 0 M = 0 N = 0 )

here, just follow the rule only one label appears in the
label field which identifies the lowest time-slot
occupied by the contiguously concatenated signal

> 3. How do I get the sections 7.3.7 to 7.3.13 of G.707 
> ( or SONET ANSI [T1.105] materials ) ?
> Are these material freely avail on InterNet ?

www.t1.org

> Regards ,
> --- bhuvan
> 
> --- Dimitri.Papadimitriou@alcatel.be wrote:
> 
>>hi,
>>
>> > I want to know -
>> > 	whether Section 3.2 of RFC3471 is applicable for
>>any
>> > or fully transparent signal ?
>>
>>for fully transparent signal only (i.e. in the
>>second
>>statement it clearly refers to "full" transparency)
>>
>> >   	If that so, section 3.2 of RFC3471 doesn't
>>specific
>> > any format for SONET/SDH label.
>> > 	So, Is it fine to use generalized label in this
>>case?
>>
>>in this case, the G_LABEL of section 3.2 applies.
>>
>>thanks,
>>- dimitri.
>>
>>bhuvan laddha wrote:
>>
>>>Hi,
>>>
>>>I would appreciate clarification for the following
>>>points in the
>>>'draft-ietf-ccamp-gmpls-sonet-sdh-08.txt':
>>>
>>>1. Last paragraph of section 2. 'SONET and SDH
>>
>>Traffic
>>
>>>Parameters' states as 
>>>
>>>" The traffic parameters and label encoding
>>
>>defined in
>>
>>>[RFC3471]
>>>   Section 3.2 MUST be used for fully transparent
>>>STS-1/STM-0/STS-
>>>   3*N/STM-N (N=1, 4, 16, 64, 256) signal
>>
>>requests. A
>>
>>>fully
>>>   transparent signal is one for which all
>>
>>overhead is
>>
>>>left
>>>   unmodified by intermediate nodes, i.e., when
>>
>>all
>>
>>>defined
>>>   Transparency (T) bits would be set if the
>>
>>traffic
>>
>>>parameters
>>>   defined in section 2.1 were used."
>>>
>>>Whereas one of the paragraph of section 3. 'SONET
>>
>>and
>>
>>>SDH Labels' states as 
>>>
>>>" The label format defined in this section,
>>
>>referred
>>
>>>to as SUKLM,
>>>   MUST be used for any SONET/SDH signal requests
>>
>>that
>>
>>>are not
>>>   transparent i.e. when all Transparency (T) bits
>>>defined in section
>>>   2.1 are set to zero. Any transparent
>>>STS-1/STM-0/STS-3*N/STM-N
>>>   (N=1, 4, 16, 64, 256) signal request MUST use a
>>>label format as
>>>   defined in [RFC3471]. "
>>>
>>>
>>>I want to know - 
>>>	whether Section 3.2 of RFC3471 is applicable for
>>
>>any
>>
>>>or fully transparent signal ?
>>>  	If that so, section 3.2 of RFC3471 doesn't
>>
>>specific
>>
>>>any format for SONET/SDH label.
>>>	So, Is it fine to use generalized label in this
>>
>>case?
>>
>>>
>>>Please correct me if I missed something...
>>>
>>>__________________________________________________
>>>Do you Yahoo!?
>>>The New Yahoo! Search - Faster. Easier. Bingo
>>>http://search.yahoo.com
>>
>>
>>-- 
>>Papadimitriou Dimitri
>>E-mail : dimitri.papadimitriou@alcatel.be
>>Private:
>>http://www.rc.bel.alcatel.be/~papadimd/index.html
>>E-mail : dpapadimitriou@psg.com
>>Public : http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen,
>>Belgium
>>Phone  : +32 3 240-8491
>>
> 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com


-- 
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491