|
Some questions about draft-zhang-ccamp-gmpls-g709-framework-00.txt: 1. “ 3.1.2.2. Optical channel data unit (ODUk) The
optical channel data unit (ODUk) provides adaptation of client signals via the Optical Channel
Payload Unit (OPUk) LO ODU (Lower order ODU) can be multiplexed
into HO ODU (higher order ODU), which is described in section
3.2.2. Currently, the following ODUk
types are defined: ODU0, ODU1, ODU2, ODU3, ODU4, ODU2e, ODUflex,
ODU3e1, ODU3e2. ODUk has a bandwidth/bit rate BR and a bit rate tolerance
T i.e. ODU(BR,T). The detailed bit rates and tolerance of the ODUk
signals (except ODUflex) are defined in [ITUT-G709],
[Gsup43]
and [G709-V3]. The bitrate
and tolerance of the ODUflex is dependent on the
client signal. HO ODUk types are: ODU1, ODU2,
ODU3, ODU4, ODU3e1, ODU3e2. LO ODUk types are: ODU0, ODU1,
ODU2, ODU2e, ODU3, ODU4, ODUflex. ODU3e1 and ODU3e2 can be treated
as LO ODU signals outside the domain in which these signals terminate. ” I
wonder why ODU4 is included as LO ODUk type. It cannot be multiplexed to any
higher order ODUk 2. “ Take the following Figure 6 as an example,
the single topology containing links and matrices
can be illustrated as follows: LO ODU Link #1: HO ODU2, support
transport of ODU0, ODU1, ODU2; LO ODU Link #2: HO ODU3, support
transport of ODU0, ODU1, ODU2, ODU3; LO ODU Link #3: HO ODU2, support
transport of ODU0, ODU1, ODU2; LO ODU Link #4: HO ODU1, support
transport of ODU0; LO ODU Link #5: HO ODU1, support
transport of ODU0; LO ODU Matrix A LO ODU Matrix B LO ODU Matrix C LO ODU Matrix D LO ODU Matrix E “ Why
link #4 and #5 do not support transport of ODU1? Is there any concept to do
this exception compared to the other links? Best Regards, Yechiel Rosengarten From: ccamp-bounces at ietf.org
[mailto:ccamp-bounces at ietf.org] On Behalf Of Fatai Zhang Hi
CCAMPers, You
know that there are lots of interests from both a technical and organizational
standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since
draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th
meeting. You
also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by
ITU-T SG15 in this October. Therefore, in order to control and manage the
OTN networks efficiently, OTN control is really important for the industry. Up
to now, we have five drafts about OTN control: To
promote better understanding or the discussions in Hiroshima meeting, we'd
appreciate your review and comments. Thanks Authors
of these drafts |