The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Transparency flags for SONET/SDH
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
|
|