[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IP-Optical] GMPLS enhancements
Hi Eric and Maarten,
it is not a question of using G.707 or GMPLS. G.707 defines a transport plane technology (SDH) and GMPLS a control plane technology as you stated. The intend of GMPLS is to define a control plane for transport planes, exisitng ones or new ones, but not to define a transport plane of its own I assume. SDH is one transport plane technology. G.707 defines the signal structure for SDH. G.707 compliant equipment has not to support all features of G.707, e.g. it might not supprot contiguous concatenation. In addition vendor proprietary features exists. GMPLS should at least support the G.707 features (VC-11/12/2/3/4/VC-4-Xv/VC-4-Yc y=4,16,64). Vendor proprietary features (or tricks) can also be added or we should allow at least a mechnism to extend GMPLS with such features. However we have to ensure that the different features can be clearly distinguished. For standard and non standard contiguous concatenation that works fine as we define the number of concatenated VCs and the star!
!
ting slot. From these information it can be decided if it is supported or not by the equipment. The concatenation iformation is not orthogonal to the lable it indicates the bandwidth of the label like VC-11, VC-2 or VC-4 does.
You mentioned multiplexing and transport of e.g. four STM-1s each with its own multiplex and regenerator section OH. Yes it is possible and different proprietary solutions exists (not for STM-1, but for STM-16). One problem is , that you need addtional overhead in order to have supervision for the new entity. You have to use different indications for the different proprietary formats as they don't interwork.
As long as you are in your own network you can do what you want (except the regulation forces you to supprot specific features, which will be standard features). As soon as you have to go to antoher networ operator you need mutual agreement or use standard features.
Eric, I have some addtiona lcomments below. Specially with your view on layers I have problems.
Rgards
Juergen
> -----Original Message-----
> From: Mannie, Eric [SMTP:Eric.Mannie@ebone.com]
> Sent: Wednesday, February 21, 2001 11:34 AM
> To: 'Maarten Vissers'
> Cc: Ben Mack-Crane (E-mail); Greg Bernstein (E-mail); Bala Rajagopalan (E-mail); Debanjan Saha (E-mail); Michael Raftelis (E-mail); Shash Chatterjee (E-mail); Jeff Connell (E-mail); Vishal Sharma; 'ccamp@ops.ietf.org'; ip-optical@lists.bell-labs.com
> Subject: RE: [IP-Optical] GMPLS enhancements
>
> 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.
[Heiles Juergen] Restoration or protection is not part of G.707, G.707 does not prevent fast restoration.
>
> 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.
[Heiles Juergen] GMPLS changes the control of SDH networks, should not change the transport plane itself.
>
> 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.
[Heiles Juergen] GMPLS does not out rule G.707 and vice versa as stated above.
>
> > 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.
[Heiles Juergen] Proprietary SDH networks might support it and GMPS-SDH networks might not support it, all options exisits.
>
> 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.
[Heiles Juergen] SDH/Sonet is used world wide and I assume GTS uses it also. Do you have only islands of single vendor equipment that do not interwork with others? No! Some itnerworking issues exists, but that is the same as in the IP world. One vendor decides to implement RSVP only, the other LDP only.
> 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.
[Heiles Juergen] I have also some favors not to use the EDCBA numbering. It is not requried and might be too restrictive as you said.
>
> >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.
[Heiles Juergen] Here I have strong objections. SDH is a technology and not a layer. It constis of several layer networks and GMPLS should be aware of this. Otherwise GMPLS is too restrictive. We have these layers VC-12 and V-4 connections ca nbe setuo independtly from each other. A VC-12 can make use of a VC-4 connection betwen two points A and B. It doesn't have to care about which interfaces the VC-4 uses and what the postiion of the VC-4 within a STM-N is. Its no difference between multiplexing a VC-12 -> VC-4 -> STM-16 multipelxing and VC-4 -> STM-16 -> WDM multiplexing. It is multipelxing and the technology doesn't matter (e.g. WDM. TDM, PDH, SDH). It should be handled the same by the control plane. Network management systems handle WDM the same as TDM (SDH).
>
> 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.
[Heiles Juergen] That is not true. Assume that you have a SDH network with 4/4 (VC-4) and 4/1 (VC-12, VC-2, VC-3, VC4) switches. When you setup a VC-12 link connection from A to B you use a VC-4 taht goes fro mA to B and put the VC-12 into this VC-4. This VC-4 goes via intermediate VC-4 switches K and L. A and B have VC-4 and VC-12 switching functionality. The VC-4 is conected to STM-14 IF 1 at A and B. See figure below.
----------------- --- --- ---------------
| A -|1----| K |---| L |----1|- B |
| / | --- --- | \ |
| VC-11->VC-4- | | -VC-4->VC-11 |
| | --- --- | |
| -|2----| M |---| N |----2|- |
----------------- --- --- ---------------
----------------- --- --- ---------------
| A -|1----| K |---| L |----1|- B |
| | --- --- | |
| VC-11->VC-4- | | -VC-4->VC-11 |
| \ | --- --- | / |
| -|2----| M |---| N |----2|- |
----------------- --- --- ---------------
Now because of VC-4 path protection or restoration or rearrangments of the VC-4 for traffic engineering purposes the VC-4 is switched to a new path going via M and N using STM-16 IF 2 at A and B. For the VC-11 it is still the same VC-4. For VC-11 it doesn't matter if it goes via IF 1 or 2. It is only important that is uses the VC-4 which goes from A to B. It doesn't matter which interfaces the VC-4 uses. Note that the VC-4 connection could be contorlled via GMPLS or in the tradional way.
>
> 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.
[Heiles Juergen] I don't think so. Most IP routers support only non-channelized SDH/Sonet interface.
> >
> > Moreover, we want to be able to manipulate circuits of any size,
> > concatenated or not (e.g. an STM-7 or STM-255).
[Heiles Juergen] Do you want to manipulate STM-7 or VC-4-7c? A STM-7 doesn't exists. You can manipulate a STM-16 or STM-4 as a whole signal, but introducing additonal sub multipelx strucutures like a group of 7 VC-4 within a STM-16 should be avoided. SUpervision and maintenance flows for such new strucutres are not existing, which would screw up your whole network operations and management.
> 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 bra> nches 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