[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IP-Optical] GMPLS enhancements
- To: 'Maarten Vissers' <mvissers@lucent.com>
- Subject: RE: [IP-Optical] GMPLS enhancements
- From: "Mannie, Eric" <Eric.Mannie@ebone.com>
- Date: Wed, 21 Feb 2001 11:33:33 +0100
- Cc: "Ben Mack-Crane (E-mail)" <Ben.Mack-Crane@tellabs.com>, "Greg Bernstein (E-mail)" <GregB@ciena.com>, "Bala Rajagopalan (E-mail)" <braja@tellium.com>, "Debanjan Saha (E-mail)" <dsaha@tellium.com>, "Michael Raftelis (E-mail)" <mraftelis@whiterocknetworks.com>, "Shash Chatterjee (E-mail)" <schatterjee@whiterocknetworks.com>, "Jeff Connell (E-mail)" <jconnell@whiterocknetworks.com>, Vishal Sharma <vishal@jasminenetworks.com>, "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>, ip-optical@lists.bell-labs.com
- Delivery-date: Wed, 21 Feb 2001 02:36:01 -0800
- Envelope-to: ccamp-data@psg.com
Hello Maarten,
>It seems that you try to glue toghether two versions of SDH: the
>standardised SDH (G.707) and several proprietary extensions of SDH. Not
>mentioning this explicitly is highly confusing.
We try to glue to the industry. There are common practices and new practices
(e.g. fast restoration) that are not part of G.707 but that are highly
valuable to control. In addition, we consider SONET as well.
GMPLS is a new control plane, it is not proprietary, it is already a
reference in the industry, it is not being standardized by ITU-T and is not
part of G.707. GMPLS deliberately allows to change the classical behavior of
legacy SDH networks.
If somebody don't like GMPLS, he/she is not obliged to implement it - you
may just ignore GMPLS and use the regular G.707.
> It also suggests
>capabilities to be present which will not be supported in many of the
>SDH networks.
Not supported in SDH networks but supported in GMPLS-SDH networks.
There are also plenty of IP capabilities that are not supported in plenty of
IP networks, etc.
A profile is always welcome.
>In my opinion, you should therefore have separate entities in the LSP
>encoding type for standardised-SDH and proprietary-SDH; and idem for
>SONET. Standardised-SDH and proprietary-SDH equipment may not be able to
>interwork; only if proprietary-SDH equipment is configured as
>standardised-SDH equipment interworking will be possible.
About the regular (legacy) SDH interoperability, did you try it already ?
That's really not simple because there are plenty of differences between the
implementations. I heard many people saying that legacy SDH interoperability
doesn't exist.
Restricting the work to a super-minimal set of functionalities that must be
supported by *everybody* doesn't make sense for me. If someone doesn't
implement the capabilities that you want, you don't buy their box, that's
all.
>For standardised-SDH, the EDCBA number is defined in G.707 (10/00);
>G.707 (10/00) compliant equipment will support AU-4-Xc (X=4,16,64,256)
>timeslots as defined by the EDCBA numbering scheme only.
Our label supports this, and more.
>When we introduced the EDCBA numbering, there were no objections from
>any of the companies represented in ITU-T...
Because this numbering has nothing to do with what can be implemented, it is
just a numbering.
>As there is no intention to make one big label encompassing all
>transport layer signals, every layer should be taken individually. This
>includes MSn, HOVC and LOVC layers.
In the context of GMPLS, I see SDH as being one layer. In that layer we can
request pipes of different sizes and we can do some nesting of pipes, by
using the SDH mulitplexing rules. The fact that you have high order pipes
and low order pipes does not imply that we have two layers for SDH and that
we need separate label definitions as you said.
The proof is that one could decide to allocate a VC-11 and to specify
exactly where it is at each level of the SDH multiplex, i.e. by specifying a
full SUKLM label. In your proposal of having SDH high order labels and low
order labels, we will need to allocate and to return two labels at the same
time, it is in conflict with the principles of GMPLS.
Regards,
Eric
"Mannie, Eric" wrote:
>
> Hi Maarten,
>
> I think that you misunderstood some important things about the label,
I'll
> try to clarify in the following.
>
> First, as you know,
>
> - All AUGs ("STM-1s" ) in an STM-N are byte interleaved : no hierarchy,
> "flat" stuff !
> - The AUs, TUGs, TUs in an AUG ("STM-1") are nested following some
specific
> rules: "tree-like" hierarchy.
> - A label identifies the first time-slot (or component) of a particular
> signal, not the full aggregate.
>
> Consequently, you need separate values to identify the nesting (UKLM) and
> only one value to identify any component in the interleaving (S = index).
>
> We just need to identify ONE STM-1/AUG in a group of N STM-1s/AUGs. The S
> field is a simple index, it is flat and there is no reason to represent
> something flat as a hierarchy.
>
> So there is no reason to use E, D, C, B !
>
> And yes, one STM-1 can be seen as a time-slot if all STM-1s are
(logically)
> time-division multiplexed. For instance, if you want to transport four
> STM-1s "transparently" you will have four STM-1s, each one with an
> independent overhead. This can be achieved by interleaving the four
> overheads, or by tunneling the overheads. How this transparency is
achieved
> is proprietary in the data plane, different vendors have different
> solutions. At least we would like to have a standardized solution to
request
> and use it in the control plane. I understand your confusion since we
don't
> use a regular SDH/SONET, but their are common tricks that vendors are
> implementing and that are useful to control in a generic way via the GMPLS
> control plane.
>
> So, we are not 100% glued to G.707. The same apply for
> protection/restoration since we are not tied anymore to only the
> protection/restoration schemes standardized by ITU-T, the fast meshed
> restoration is an example.
>
> In addition, you want to indicate some fixed concatenation levels
(AU-4-4c,
> AU-4-16c, AU-4-64c and AU-4-256c) in the label. This is not appropriate
> since there are plenty of other different levels of concatenation, indeed
> all levels are possible, e.g. AU-4-7c. The concatenation is anyway better
> indicated separately, it is orthogonal with a label.
>
> Think also about contiguous concatenation for example, I could want to
> concatenate the 3rd, 4th and 5th STM-1/AUG, so I just need to say S=3 to
> indicate where begins my concatenation. Arbitrary concatenation is
commonly
> used.
>
> Moreover, we want to be able to manipulate circuits of any size,
> concatenated or not (e.g. an STM-7 or STM-255). With you proposal it would
> be impossible to do so since we can only encode the index of a few
> time-slots. We really need to encode the index of each possible STM-1/AUG.
> We go further than a pure G.707.
>
> Concerning your comment about SDH ADM and cross connect equipment that
may
> have separate Higher Order and Lower Order fabrics, please refer to our
> discussion that occurred two months ago when I explained the nesting of
LSPs
> and how it can be applied to SDH/SONET. One of the benefits of GMPLS is to
> allow different classes of equipments, those that can switch higher orders
> in the core and those that can switches lower orders in the metro/access.
> Indeed, you can design any kind of equipment. Circuits are just nested in
> circuits. That's why the higher part or lower part of a label
(respectively)
> can be zeroed to indicate irrelevant (see editorial bug that we discussed,
> should be corrected in the next version of GMPLS, S=0 is valid).
>
> Kind regards,
>
> Eric
>
> > Note that the latest version of G.707 (10/00) has defined a naming
> > structure for the AU's, similar to that for the TU's. AUs are now named
> > according the EDCBA structure (TUs are named according the KLM
> > structure). It is thus possible to replace the S,U number by the
> > standardised number E,D,C,B,A. The specification could be:
> >
> > 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
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | | E | D | C | B | A | K | L | M |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > For SDH, this is an extension of the numbering scheme defined in
> > G.707 section 7.3, i.e. the (E,D,C,B,A) and (K, L, M) numbering. For
> > SONET the K field is not significant and must be set to zero.
> >
> > Each letter indicates a possible branch number starting at the parent
> > node in the multiplex structure. Branches are considered as numbered
> > in increasing order, starting from the top of the multiplexing
> > structure. The numbering starts at 1, zero is used to indicate a non-
> > significant field.
> >
> > When a field is not significant in a particular context it MUST be
> > set to zero when transmitted, and MUST be ignored when received.
> >
> > 1. E indicates possible branches of a STM-256/OC786. It is not
> > meaningful for the cases of STM-64/OC192, STM-16/OC48, STM-4/OC12,
> > STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case.
> > E=1 indicates that the STM-256/OC768 is not further sub-divided
> > and contains an AU-4-256c/STS768c.
> > E=2->5 indicates a specific AUG-64 inside the given STM-256/OC768.
> >
> > 2. D indicates possible branches of either an AUG-64 or a
> > STM-64/OC192.
> > It is not meaningful for the cases of STM-16/OC48, STM-4/OC12,
> > STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case.
> > D=1 indicates that the AUG-64 or STM-64/OC192 is not further
> > sub-divided and contains an AU-4-64c/STS192c.
> > D=2->5 indicates a specific AUG-16 inside the given AUG-64 or
> > STM-64/OC192.
> >
> > 3. C indicates possible branches of either an AUG-16 or a
> > STM-16/OC48.
> > It is not meaningful for the cases of STM-4/OC12, STM-1/OC3,
> > STM-0/OC1 multiplexing and must be 0 in that case.
> > C=1 indicates that the AUG-16 or STM-16/OC48 is not further
> > sub-divided and contains an AU-4-16c/STS48c.
> > C=2->5 indicates a specific AUG-4 inside the given AUG-16 or
> > STM-16/OC48.
> >
> > 4. B indicates possible branches of either an AUG-4 or a STM-4/OC12.
> > It is not meaningful for the cases of STM-1/OC3, STM-0/OC1
> > multiplexing and must be 0 in that case.
> > B=1 indicates that the AUG-4 or STM-4/OC12 is not further
> > sub-divided and contains an AU-4-4c/STS12c.
> > B=2->5 indicates a specific AUG-1 inside the given AUG-4 or
> > STM-4/OC12.
> >
> > 5. A indicates possible branches of either an AUG-1 or a STM-1/OC3.
> > It is not meaningful for the case of STM-0/OC1 multiplexing
> > and must be 0 in that case. A=1 indicates that the AUG-1 or
> > STM-1/OC3 is not further sub-divided and contains an
> > AU-4/STS3c. A=2->4 indicates a specific AU-3/STS1 inside the given
> > AUG-1 or STM-1/OC3.
> >
> > 6. K is only significant for SDH and must be ignored for SONET. It
> > indicates a specific branch of a VC-4. K=1 indicates that the
> > VC-4 is not further sub-divided and contains a C-4. K=2->4
> > indicates a specific TUG-3 inside the VC-4. K is not
> > significant when the STM-1 is divided into VC-3s (easy to read
> > and test).
> >
> > 7. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It
> > is not significant for an unstructured VC-4. L=1 indicates that
> > the TUG-3/VC-3/STS-1 SPE is not further sub-divided and
> > contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8
> > indicates a specific TUG-2/VT Group inside the corresponding
> > higher order signal.
> >
> > 8. M indicates a specific branch of a TUG-2/VT Group. It is not
> > significant for an unstructured VC-4, TUG-3, VC-3 or STS-1
> > SPE. M=1 indicates that the TUG-2/VT Group is not further
> > sub-divided and contains a VC-2/VT-6. M=2->3 indicates a
> > specific VT-3 inside the corresponding VT Group, these values
> > MUST NOT be used for SDH since there is no equivalent of VT-3
> > with SDH. M=4->6 indicates a specific VC-12/VT-2 inside the
> > corresponding TUG-2/VT Group. M=7->10 indicates a specific
> > VC-11/VT-1.5 inside the corresponding TUG-2/VT Group carried
> > within a TU-11. M=11->13 indicates a specific VC-11 inside the
> > corresponding TUG-2 carried within a TU-12. Note that M=0 denotes
> > an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).
> >
> > Some examples:
> > EDCBAKLM
> > - 00220444 identifies TU12 (1,1,1) in a VC4 carried in AU4 (1,1,0)
> > in a STM-16/OC48
> > - 10000000 identifies AU-4-256c/STS768c in a STM-256/OC768
> > - 23450455 identifies TU12 (3,4,2) in a VC-4 carried in AU-4 (1,2,3,4,0)
> > in a STM-256/OC768
> > - 03210000 identifies AU-4-4c (2,1,0,0) in a STM-64/OC192
> > - 00241000 identifies AU-4 (1,3,0) in a STM-16/OC48 signal.
> >
> > The specification of the AU timeslot (2x AU-4-4c, 7xAU-4, 3xAU-3)
> > structure in a STM-16 could then consist of the following set of labels:
> >
> > EDCBAKLM
> > - 00210000 AU-4-4c (1,0,0)
> > - 00321000 AU-4 (2,1,0)
> > - 00331000 AU-4 (2,2,0)
> > - 00341000 AU-4 (2,3,0)
> > - 00351000 AU-4 (2,4,0)
> > - 00410000 AU-4-4c (3,0,0)
> > - 00521000 AU-4 (4,1,0)
> > - 00532000 AU-3 (4,2,1)
> > - 00533000 AU-3 (4,2,2)
> > - 00534000 AU-3 (4,2,3)
> > - 00541000 AU-4 (4,3,0)
> > - 00551000 AU-4 (4,4,0)
> >
> > For the contiguous concatenated signals (AU-4-Xc) the EDCBA numbering
> > scheme has the bandwidth implied. There is no need to code this
> > bandwidth seperately anylonger.
> >
> > Question related to the definition of "M":
> > ------------------------------------------
> > "M" defines 1st - 3rd VC-12 and 1st - 4th VC-11. As it is possible to
> > transport a VC-11 via a TU-12, I believe that the M range should be
> > extended with values 11 to 13 as follows:
> >
> > The M encoding is summarized in the following table:
> >
> > M SDH SONET
> > ----------------------------------------------------------
> > 0 unstructured VC-4/VC-3 unstructured STS-1 SPE
> > 1 VC-2 VT-6
> > 2 - 1st VT-3
> > 3 - 2nd VT-3
> > 4 1st VC-12 1st VT-2
> > 5 2nd VC-12 2nd VT-2
> > 6 3rd VC-12 3rd VT-2
> > 7 1st VC-11 in TU-11 1st VT-1.5
> > 8 2nd VC-11 in TU-11 2nd VT-1.5
> > 9 3rd VC-11 in TU-11 3rd VT-1.5
> > 10 4th VC-11 in TU-11 4th VT-1.5
> > 11 1st VC-11 in TU-12 -
> > 12 2nd VC-11 in TU-12 -
> > 13 3rd VC-11 in TU-12 -
> >
> > At intermediate points, the VC-11 in TU-12 is treated (by non-intrusive
> > monitors) as a VC-12. At the path endpoints however, the VC-11 is
> > treated as a VC-11.
> >
> > Coding the lower order VC (LOVC)/VT signals:
> > --------------------------------------------
> > SDH ADM and cross connect equipment may have separate Higher Order and
> > Lower Order fabrics. This decouples the TU identification from the AU
> > timeslot and associated physical port. I.e. EDCBAKLM label should be
> > split into separate EDCBA and KLM labels.
> >
> > Figure 1 illustrates an SDH ADM with 3 STM-N ports, a HO Fabric and "M"
> > VC4 termination points connected to the LO Fabric.
> >
> > The TU timeslots are defined with reference to a VC4 termination point.
> > The VC4 signal geenrated by a VC4 termination point can be transported
> > over any of the STM-N signals; there is no predefined relationship,
> > neither is there a permanent relationship (i.e. it is possible to
> > re-route the VC-4 without tearing it down, or tearing down the LOVC
> > connection over it).
> >
> > As such, the TU timeslots should be numbered with respect to its VC4
> > termination point, not with respect to the AU4 timeslot in an STM-N; The
> > AU4/STM-N part of the label may change over time, whereas the TU link
> > connection and TU connection point stay the same.
> > Resulting label should be "<VC4 TP number><K><L><M>".
> >
> > STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO
> > FABRIC
> > signal PORT timeslots | | Term. timeslots
> > | | Points per VC4 TP
> > | |
> > STM-N --- PHY --- "N" AU -------| |
> > timeslots |
> > STM-N --- PHY --- "N" AU ----------|
> > timeslots
> >
> > Figure 1 - SDH ADM with separate HO and LO Fabrics
> >
> > The HO Fabric contains the relation between AU number and VC4 TP number,
> > as well as between between two AU numbers (case of STM-N - AU - STM-N
> > connection).
> >
> > <-- phys. <--- EDCBA <--- VC4 <--- KLM
> > port AU TP TU
> > number number number number
> >
> > STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO
> > FABRIC
> > signal PORT timeslots | | Term. timeslots
> > | | Points per VC4 TP
> >
> > Figure 2 - numbering
> >
> > Regards,
> >
> > Maarten